#ubuntu-devel 2005-08-15
<ogra> mem ?
<ogra> should work
<Burgundavia> ogra, what soc thing are you mentoring?
<Mez> I need a linux distro that'll run on this
<Mez> http://www.dsl-ltd.co.uk/products/6070spec.htm
<ogra> Burgundavia, the above :)
<Burgundavia> ogra, ubuntu-lite?
<ogra> Burgundavia, and graphical config tools... which is a bit odd for a bounty since all thing listed on the spec are already done fine upstream.... so the SoC student had not many options... but he made the best out of it :)
<ogra> Burgundavia, yep
<Burgundavia> ogra, yes. I was wondering the same thing. But the ndisgui thing is worth it
<ogra> you already saw it ? 
<Burgundavia> yes
<Burgundavia> poofyhairgui on the forums found it and posted it about it
<ogra> heh
<ogra> it'll be in universe soon ...
<Burgundavia> you can even download debs for it
<ogra> i know
<ogra> i reviewed them
<Kamion> daniels: please make xserver-xorg stop prompting me for questions in triplicate every time I upgrade it
<Kamion> lamont: libgl1-xorg-dev should be happier now
* ogra thinks one very odd thing about ltsp is, that if its run on a amd64 client from a x86 server powermanagement seems not to exist at all... my knees are melting under 2ghz amd64 power...
* Nafallo grumbles *
<Nafallo> users want to add breezy to install valknut :-P
<Nafallo> I'm trying to explain to them why it is a bad idea ;-)
<Mez> ogra: got any link for the ubuntu light project
<ogra> currently not... im on a thin clinet here 
<ogra> but something like www.ubuntulite.org ...
<Burgundavia> gah
* Burgundavia is stress testing ubuntu and his harddrive by kicking the power cable out
<paolo> Burgundavia, which SoC project is it?
<Burgundavia> paolo, which one?
<paolo> Burgundavia, the one you were talking about some lines ago.
<Burgundavia> paolo, ubuntu lite is LIghtweightDesktop or something
<Burgundavia> GraphicalConfigTools
<ogra> Mez, http://ubuntulite.org/wiki/index.php/Main_Page
<Burgundavia> ogra, any idea why most of the ubuntulite project has been done outside the official channels?
<paolo> Nice :-)  I'm a SoC-er too (but not for ubuntu)
<ogra> Burgundavia, because they were already existent and nearly done with their version 1 wher the SoC started
<Burgundavia> ah
<Burgundavia> paolo, what are you doing?
<paolo> Burgundavia, Haskell bindings for Cairo, and integration in the Haskell Gtk+ bindings <http://haskell.org/gtk2hs/>
<Burgundavia> hmm
<ajmitch> ogra: it'd be nice to see these people working in the existing development community
<ogra> ajmitch, yes... but you cant force people
<ajmitch> I know
<ajmitch> ogra: and I guess you tried recruiting them as MOTUs :)
<ogra> heh.... after they finished their projects... let them focus on their work now ;)
<Burgundavia> I think that people see Ubuntu has this giant monlithic entitiy
<Burgundavia> and they think it is hard to get involved
<HrdwrBoB> Burgundavia: but they see it as that because it works
<Burgundavia> I spend a lot of words/time on the forums telling people to join the official efforts (motu, doc team, etc.)
<HrdwrBoB> a whole lot of software that generally works well and together appears every six months
<ajmitch> they see the developers as far above the ordinary users?
<Burgundavia> yes
<Burgundavia> and Ubuntu is one of the easiest distros to get involved in
<ajmitch> I'd say
<ogra> thats because we have a split community.... forum people vs. mailing list people
* ajmitch rarely reads the forums
* ogra neither
<Burgundavia> most developers rarely read the forums
<HrdwrBoB> I rarely read either
<ogra> and i dont know any devs that do it
<Burgundavia> if you took all my posts on the forums, probably over half are "file a bug, devs won't read it here"
<tseng> if it wasnt for you, the bug would sit there forever
<azeem> the forums need to be more bidirectionally gated, to unite the communities
<paolo> Do you know which xorg packages defines "string literal" colors (if any) ?
<tseng> and people would get bitter because no one cared about their "bug report"
<ogra> azeem, they are
<Burgundavia> there is talk about extending launchpad login to the forums
<Burgundavia> but they use non-free software
<Lathiat> heh
<tseng> the current forums seems to want me to sign up every time i click my mouse
<pitti> seb128: still here?
<seb128> yep
<pitti> seb128: I pinpointed the bug on amd64, but it's nontrivial to solve
<pitti> seb128: is there any gdk function to determine the work area?
<seb128> oh, what is it?
<pitti> seb128: i. e. the screen size minus panels etc.
<pitti> seb128: it calls XGetWindowProperty to determine the desktop work area size
<pitti> seb128: on i386 this returns 32 bit ints, on amd64 it returns 64 bit numbers
<pitti> (in an array)
<pitti> so the coordinates are totally off on amd64 and you can't see the window
<seb128> there is no gdk function for that afaik
<pitti> but instead of brutally fixing that, I'd rather use a gdk function to determine the desktop size
<pitti> seb128: darn
<pitti> seb128: it almost seems that XGetWindowProperty has a bug...
<seb128> nautilus seems to do
<seb128>         XGetWindowProperty (display, RootWindow (display, screen_num),
<seb128>                             XInternAtom (display, "ESETROOT_PMAP_ID", False),
<seb128>                             0L, 1L, False, XA_PIXMAP,
<seb128>                             &type, &format, &nitems, &bytes_after,
<seb128>                             &data_esetroot);
<pitti> and I would feel bad if I just worked around that
<paolo> I think the problem is that xorg misses some packages other than the ones listed in the mail pitti pointed me before.
<seb128>         retval = XGetWindowProperty (GDK_DISPLAY (), GDK_ROOT_WINDOW (),
<seb128>                                      window_id_atom, 0, 1, False, XA_WINDOW,
<seb128>                                      &actual_type, &actual_format, &nitems,
<seb128>                                      &bytes_after, &data);
<pitti>     int result = XGetWindowProperty(GDK_DISPLAY(), win, workarea, 0,
<pitti>                                      max_len, False, AnyPropertyType,
<pitti>                                      &type, &format, &num,
<pitti>                                      &leftovers, &ret_workarea);
<pitti> seb128: format is 32 on amd64, although it returns 64 bit ints
<pitti> so 
<paolo> Could you tell me in which package is "showrgb" ?
<pitti>     guint32 *workareas = (guint32 *)ret_workarea;
<pitti>     rect.x      = workareas[disp_screen * 4] ;
<pitti>     rect.y      = workareas[disp_screen * 4 + 1] ;
<pitti> breaks
<ogra> why dont you use GDK_ROOT_WINDOW () instead ? 
<pitti> ogra: and determine its size?
<ogra> yup
<ogra> there are various others to use: http://developer.gnome.org/doc/API/2.0/gdk/gdk-X-Window-System-Interaction.html
<pitti> ogra: cool, do you know how to query the size?
<ogra> nope, never did that....
<pitti> this GetProperty thingy fails, so using it to determine the size of it leads to the same proble
<paolo> Sob.  In hoary showrgb is in xutils, but there isn't in breezy.
<paolo> Seveas, do you know if there is an online search for this kind of things?  Like "file -> package"
<ogra> pitti, gdk_window_get_geometry ()
<Kamion> paolo: http://packages.ubuntu.com/; but (a) it may be out of date and (b) showrgb is probably just missing at the moment, due to the in-progress xutils reorg
<ogra> pitti, http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#gdk-window-get-geometry
<paolo> Kamion, I was searching for that because of this error running emacs: 'Undefined color: "black"'.  And #freedesktop guys told me that string literals are defined in some file belonging to showrgb or something.
<pitti> ogra: doesn't fit, take a penalty card :-)
<ogra> heh
<pitti> ogra: that's only for gdk windows, not for X window IDs
<ogra> and a GDK_ROOT_WINDOW () isnt a gdk window ? 
<pitti> no, an X window id
<pitti> XGetWindowAttributes() - let's try that
<ogra> yeah
<ogra> hanst X a GetGeometry too ? 
<ogra> hasnt even
<luis_> mjg59: whaaaaa
<luis_> mjg59: I want my graphical boot now
<mjg59> luis_: I'm hacking on it
<mjg59> Stuff is being mean to me
<Burgundavia> mjg59, are lappys expected to be shipped this week?
<mjg59> Burgundavia: Yes
<Burgundavia> ok
<Lathiat> ooh nice
<luis_> you're all getting new lappys?
<Kamion> lamont: a give-back of nautilus/i386 once the buildd chroots have been repaired would be very much appreciated
<Kamion> (it sorta breaks the world through out-of-date nautilus-data_all.deb
<Kamion> )
<lamont> Kamion: ok...
<ogra> pitti, http://seth.positivism.org/man.cgi/3/XGetWAttr
<pitti> ogra: that's what I'm trying right now :-)
<ogra> :)
<Makako> Zquit
<Makako> Oops ;)
<Burgundavia> mjg59, I have placated the ravaging hordes at the forums with the news that Usplash is being worked on
<lamont> Kamion: pardon me while I rampage through all of main :0)(
<mjg59> Burgundavia: Hurrah!
<Kamion> lamont: fair enough :)
<Nafallo> lol
<ogra> mjg59, you could become ubuntu DPL (if we hadnt already a dictator) after finishing usplash... it will make you paparazzi-popular ;)
<mjg59> Haha
<Nafallo> hihihi
<Burgundavia> I also got to include the whinging of luis_ in there too ;)
<luis_> haha
<ogra> lol
<luis_> I'm not whinging, I'm trying to improve the livecd. ;)
<tseng> what happens if i apt-get usplash atm?
<luis_> <- master of subtle differences
<ajmitch> Burgundavia: laptops soon? great, means I might see it in 2 months :)
<ogra> tseng, you get a package installed ?
<luis_> ogra: what does that package do? :)
<tseng> ogra: good one.
<Nafallo> ogra: naah, that's apt-get install :-)
<ogra> tseng, err, actually you get an error :)
<Burgundavia> I installed usplash
<Nafallo> tseng: I belive it will tell you that usplash isn't a valid command :-)
<tseng> meh
<ogra> heh
<tseng> you guys are tools
<luis_> Burgundavia: and what did it do? :)
<Nafallo> hehehe
<mjg59> Burgundavia: Yeah, it might work soon
<Burgundavia> after my hardware testing by kicking power cord out, nothing happened
<ajmitch> that's a shame
<ajmitch> power cord testing isn't the most reliable though
<Burgundavia> no
<Burgundavia> but the ext3 journal recovered fine
<ajmitch> especially if you were installing something at the time
<Burgundavia> it had finished installing, luckily
<mjg59> Burgundavia: It won't do anything without initramfs
<mjg59> (and at the moment that won't quite work properly - give me a few minutes and there'll be a new upload)
<Burgundavia> ok
<lamont> Total 5917 package(s) in state Installed.
<lamont> Total 442 package(s) in state Needs-Build.
<lamont> Kamion: ^^^ have a nice day
<jbailey> lamont: You need a w-b state "B0rked"
<ogra> heh
<lamont> mind you, most of those 442 packages will fail again
<pitti> ogra: darn, that works, but gives the complete root window, not the workspace
<ogra> there must something similar for the workspace
<ogra> sorry phone...
<seb128> src/common/gst-package.c:64: undefined reference to `_'
<seb128> collect2: ld returned 1 exit status
<seb128> grumpf
<pitti> hey, wait...
<Lathiat> heh
<pitti> YAY, YAY, YAY
* pitti does the victory dance
<seb128> pitti \o/
<tseng> whats new pitti?
<sladen> ajmitch: I'm expecting to pick one up tomorrow
<pitti> seb128: how stupid...
<pitti> "If the returned format is 32, the returned data is represented
<pitti>        as a long array"
<pitti> seb128: i. e. even if format is 32, I have to use a long (64 bit)
<pitti> so if that is the spec, fine :-)
<seb128> pitti: why does it return 32 if the format is 64 ?!
<pitti> seb128: other way round 
* lamont -> home
<pitti> ask the X authors
<seb128> bah
<seb128> kick daniels? :)
<ajmitch> sladen: living in NZ has it's disadvantages
<HrdwrBoB> tell me, is there any reason why the gnome weather applet can't get the location from the timezone as a default
<seb128> it does
<HrdwrBoB> since recently?
<nickrud> Is there a way to see if a package is in the build queue?
<HrdwrBoB> it's defaulted to pennsylvania always for me
<HrdwrBoB> which is a long way from melbourne
<seb128> what locale do you use?
<seb128> maybe it uses the locale
<HrdwrBoB> en_AU
<HrdwrBoB> the timezone is a bit more specific though
<luis_> yes, because weather here in boston is just like the weather in miami!
<luis_> if it should try to guess at all, it should be from the address in about me
<HrdwrBoB> still in the right continent though
<luis_> guessing from timezone is basically useless unless you live in hawaii
<seb128> it picks Paris here
<HrdwrBoB> Your current time zone is set to Australia/Melbourne
<Lathiat> well on ubuntu you usually set a location at the start
<Lathiat> do other distros do similar?
<HrdwrBoB> that's precisely where I am
<luis_> you're in a small minority then
<Lathiat> i set mine to where i am too, heh
<Lathiat> Australia/Perth
<HrdwrBoB> luis_: well, for the small minority it would be correct
* luis_ tests building spanish livecd
<HrdwrBoB> and the the majority it would be in the right area at least
<pitti> good night everybody
<mjg59> luis_: You need usplash-0.1-2 (which will hit the archive shortly) and the latest initramfs-tools, then mkinitramfs -o /boot/initrd-foo
<luis_> coolio
<seb128> HrdwrBoB: they use the translation to set the default 
<luis_> thanks, dude
<mjg59> luis_: But be warned that it's very ugly right now
<mjg59> And doesn't really do anything useful
<pitti> good night
<luis_> if it can hide the text behind an arbitrary image which contains the string 'please wait', then it is a step up for me
<mjg59> luis_: Well, sort of
<mjg59> You'd need a couple of hacks for that
<Kamion> nickrud: you look in http://people.ubuntu.com/~lamont/buildLogs/Lists/, but you might want to get somebody who knows how to interpret those
<nickrud> Kamion, thanks, I'll see what I can see
<luis_> mjg59: anyway, I'll play with it
<mjg59> luis_: Basic idea is: splash appears. Scripts call command that writes stuff to splash. Splash vanishes after timeout.
<mjg59> There's still a tiny bit of work needed to get it to work on both sides of the root filesystem being mounted, but you could just up the timeout
* robertj pops off an email to ubuntu-devel to see if anyone else thinks its time the workspace-switcher applet find its way to /dev/null
<robertj> (what I really mean is that it probably shouldn't be on the panel by default)
<nickrud> Kamion, most of it is self explanatory  (at the level I needed:), thanks
<luis_> mdz, anyone else: where would it be best to discuss the liveCD? ubuntu-devel?
* luis_ has some questions about the breezy stuff, not sure if they are bugs, things that have merely changed since hoary, or what
<daniels> Kamion: worksforme
<mjg59> daniels: I've seen it to
<mjg59> o
<marcin> hi all 
<marcin> I got a propably simple question... but I cannot find an answer myself
<marcin> how you guys build packages in this way that they got *-ubuntu[somebuildversion]  suffix?
<bddebian> marcin: It comes from the changelog
<daniels> mjg59: it used to happen in the pre-hoary days, and I don't see what could've changed to make it come back.  of course, neither can I remember what I changed to fix it, exactly ...
* shaya pokes mdz
<ajmitch> daniels: I still get that, it came back recently
<marcin> bddebian: so for example: wget (1.9.1-10ubuntu2.1) in changelog does this trick?
<marcin> bddebian: and in fact - I know that 1.9.1 is version 
<daniels> headdesk
<marcin> bddebian: but what 10 and 2.1 is?
<marcin> bddebian: (in 10ubuntu2.1 suffix)
<bddebian> Hmm, I haven't seen a suffix like 2.1
<marcin> bddebian: well is is in ubuntu hoary - wget package - for example
<Kamion> marcin: generally because there had already been a -10ubuntu3 in breezy but a security fix to -10ubuntu2 needed to happen in hoary
<Kamion> (guessing)
<shaya> Kamion and they didn't want to go -10unbuntu2hoary1 :)
<Kamion> shaya: that would be really rather redundant and unhelpful, if you think about it
<shaya> it was a joke :)
<shaya> anyways
<shaya> is there a libgl-xorg-dev package anywhere?
<Kamion> codenames like "hoary" don't sort well
<Kamion> shaya: libgl1-xorg-dev
<marcin> Kamion: so this thing after 'ubuntu' is something like build version in rpms?
<shaya> Kamion: aptitude is giving me serious issues
<Kamion> marcin: no
<Kamion> shaya: it's fixed, may still be propagating to your mirror
<marcin> Kamion: hmm any naming convention guide?
<shaya> hmm
<Kamion> marcin: everything after the - is the package revision (as opposed to the upstream version number)
<shaya> I use archive.ubuntu.com
<Kamion> marcin: "ubuntu" is an indicator that we have made substantive changes in Ubuntu so we shouldn't automatically sync new versions from Debian, and instead must merge them
<Kamion> marcin: the bit before "ubuntu" is generally the revision of the corresponding package in Debian
<Kamion> normally speaking, the bit after "ubuntu" is just an integer. Don't mess about with extra 2.1 bits unless you know what you're doing and absolutely have to
<Kamion> so typically, Debian has 2.3.1-1, first Ubuntu revision against that is 2.3.1-1ubuntu1, second is 2.3.1-1ubuntu2, etc.; if Debian release 2.3.1-2, then the merged version would be 2.3.1-2ubuntu1, etc.
<marcin> Kamion: hmmm
<marcin> Kamion: ok then when we need to change from 1ubuntu to 2ubuntu?
<marcin> Kamion: ahh I think I get it - first digit is _Debian_ build indicator and last number after 'ubuntu' thing is _Ubuntu_ build indicator
<marcin> Kamion: right?
<Lathiat> mjg59: are you interested in hearing about usplash not working?
<mdz> luis_: ubuntu-devel, yes
<sladen> Lathiat: yes, in what case?
<Lathiat> sladen: on my laptop, boots, screen goes blank, no hard disk activity, alt+sysrq+b works, capslock doesnt
<Lathiat> hrm i just realised i have a vga=771 
<Lathiat> maybe tahts interfering
<sladen> Lathiat: it can't cope with vesa modes
<Lathiat> also
<Lathiat> it should respect nosplash
<sladen> Lathiat: it should probably check for, and ignore modes
<Kamion> marcin: right
<Lathiat> or not havign 'splash'
<sladen> Lathiat: from reading the code about an hour ago, it /should/ do that
<Lathiat> (because i had to boot a livecd to uninstall and reinstall the kernel to be able to boot again)
<Kamion> marcin: don't touch the bit before "ubuntu" unless you're merging new code from upstream or from Debian (which you generally shouldn't be doing at this stage of the release process without getting prior approval, anyway)
<Lathiat> i tried recovery mode and changing splash to nosplash
<Kamion> Treenaks: hmm, I read some documentation a bit more carefully, I think that hotplug thing is actually a busybox sed bug
<Lathiat> ill try without vga= and see what happens
<marcin> Kamion: and what about new packages that doesn't exist in Debian repository?
<ajmitch> marcin: they get -0ubuntu1, etc
<Kamion> marcin: either versioned as if they were Debian packages, or as ajmitch says
<sladen> Lathiat: 'splash' is not set for recovert mode.  nothing knows about 'nosplash'  it is  'splash' or ''
<Lathiat> sladen: well if i set nosplash
<Lathiat> sladen: thered be no splash
<Lathiat> sladen: nor did it work in recovery mode
<Kamion> I tend to use Debian-style versioning for new development, and -0ubuntu1 versioning for cases where we're temporarily running ahead of Debian
<Lathiat> bbs
<marcin> Kamion: ok
<Lathiat> i saved the old initrd this time :)
<Am|NickTaken> wtf, why does gmail-notify depend on straw (rss reader)
<ajmitch> Kamion: we mandate -0ubuntu1 for universe new packages
<sladen> Lathiat: nothing should happen at all in recovery mode.  Is that what you see in your case?
<Kamion> ajmitch: for universe that's reasonably sensible I guess, since much of that should be expecting similar packaging to show up in Debian as -1
<Kamion> ajmitch: however, I refer you to e.g. the recent usplash uploads
<Lathiat> sladen: nope, it still screwed up, however i just found out that i want the second version that was uploaded as without vga=771 i saw a kernel panic after some random foo 
<Lathiat> (cus init died)
<ajmitch> right, I mainly deal with packages that MOTUs review for universe
<ajmitch> where it's easiest just to have a consistent scheme, and try &get it into debian
<sladen> Lathiat: okay, so a kernel panic.  can you replicate it and record what the kernel paniced over?
<marcin> Kamion: btw you want always follow debian repositories?
<Lathiat> sladen: it had errors about the usplash_something-init, i saw a changelog entry about -s in the variables, so i'll get that new version and try it first
<marcin> Kamion: or is this possible to create some really _different_ packages for ubuntu?
<marcin> Kamion: (different - I mean different than in debian)
<Kamion> marcin: we can and we have
<Kamion> marcin: but try to limit it
<Amaranth> should i uninstall usplash? :)
<Kamion> marcin: the fewer *unnecessary* diffs we have versus Debian, the less work we have to do
<sladen> Amaranth: is it giving you problems?
<Kamion> sometimes the diffs are necessary, but don't do it just for the sake of it
<Amaranth> sladen: I'm not comfortable booting up to a live cd to 'uninstall' my kernel to fix any potential problems :P
<Lathiat> Amaranth: 'sok, backup your old initrd first ;p
<Lathiat> (then use the power of grub ;p)
<Amaranth> too late
<Lathiat> Amaranth: nah just reinstall your kernel image
<Lathiat> copy it
<Lathiat> and then run mkinitramfs again
<marcin> Kamion: ok anyway I want to package some software not much important for ubuntu
<marcin> Kamion: and I think that I create these packages mainly for myself
<Amaranth> Lathiat: ok, but if i just uninstall usplash and reinstall my kernel it should be fine, right? :)
<Lathiat> Amaranth: i guess?
<marcin> Kamion: especially while I want to break some debian rules (so propably no chance to adopt my package to debian)
<Kamion> marcin: the Debian policy is not there just for fun; it's a collection of good practice that's evolved over time. If you insist on breaking it you should be very sure of your reasons
<marcin> Kamion: I think I'm sure - especially while some packages adopted by ubuntu from debian are not installable
<Kamion> I would expect the universe folks to require Debian policy from new packages by default except where they've explicitly decided to do otherwise for good reasons, I think
<Kamion> dude, uninstallability's just about dependencies, it's not generally policy
<ajmitch> we do require policy compliance
<marcin> Kamion: but it is only one reason
<daniels> what reason is that?
<sladen> Amaranth: can you boot using the recovery-mode ?
<Amaranth> sladen: i haven't tried to reboot at all
<marcin> Kamion: and another is that some things are installed with packages but not available for user due to screwed up config files
<daniels> argh
<daniels> mjg59: sessreg comes from the xdm source
<Kamion> marcin: and you think Debian rules include "must be broken"?
<marcin> Kamion: anyway I'm too tired now to explain all of this it's too late (4:47 here)
<Kamion> marcin: some packages in Debian are buggy; that doesn't mean that fixing them involves breaking Debian rules
<marcin> Kamion: well maybe not all debian rules
<marcin> Kamion: to be more specific 
<marcin> Kamion: the thing I want to do is a bunch of packages for Emacs
<marcin> Kamion: and debian policy for emacs is pretty good
<marcin> Kamion: (overcomplicated - but good)
<marcin> Kamion: but there is a lot of broken packages - broken in different ways
<bob2> how does any of this justify breaking policy?
<marcin> Kamion: dependencies (for example: jde), broken config files (for example: dired-x - available in package but user needs to configure this by hand in .emacs file)
<Kamion> so far it sounds like you're just saying "I need to fix stuff that's broken", which is fine
<ajmitch> have you filed bugs in debian for these?
<Kamion> the thing I'm boggling at is purely "can't fix without breaking [unspecified]  Debian rules"
<ajmitch> at least for the issues that come from debian
<Kamion> that does happen, but it's rare, and I'd like to hear exactly what rules you think you have to break so that people can review that decision
<marcin> ajmitch: not yet because I know that they will give me a million of reasons why their policy is the best one and they will tell me to shut up ;)
<bob2> so, your complaint is "Debian Emacs Policy section $blah is buggy"?
<marcin> ajmitch: btw there are things that propably are ok in debian but not in ubuntu - like jde package - non installable in ubuntu due to problems with java
<Kamion> Ubuntu's founded to a large extent on Debian policy; if you think the policy is broken, you need to explain *why*
<Kamion> so that it can be fixed wherever's appropriate
<daniels> (and fixing it will usually involve getting it fixed in Debian, also)
<Amaranth> hrm
<Amaranth> xnest installs into /usr/X11R6/bin/
<sladen> Amaranth: I'm lost.  Are you wanting to uninstall because you're worried by other people's reports
<Amaranth> sladen: yeah
<Amaranth> sladen: doesn't matter though, i can't even make gdm work anymore :)
<Amaranth> time to see if usplash cuts
<Kamion> marcin: jde is uninstallable because bsh failed to build from source, which in turn is because kaffe is uninstallable; see http://people.ubuntu.com/~lamont/buildLogs/b/bsh/1.3.0-3/
<marcin> Kamion: I know that and I said that this is dependency problem
<Kamion> marcin: in turn, kaffe looks like it simply needs to be rebuilt for the C++ transition
<Kamion> I'll take care of that now
<marcin> Kamion: anyway the thing is that I don't want to broke all debian rules for emacs
<marcin> Kamion: I just want things to "just work"
<marcin> Kamion: and the problem is that there is really a lot of things in debian packages for emacs 
<marcin> Kamion: that doesn't work at all - regarding if installed or not
<ajmitch> Kamion: kaffe is on a list to be synced, I don't think the current version was building 
<Kamion> ajmitch: the current version *has* built
<marcin> Kamion: because propably maintainters think that emacs users are advanced one and they don't provide almost any config settings for emacs
<Kamion> marcin: so it sounds like you're attributing all sorts of awful motives to people that in all probability aren't there
<bob2> marcin: so, submit a patch for a sane default config
<marcin> Kamion: and in this way every emacs user needs to spend a lot of time hacking .emacs file
<ajmitch> Kamion: sorry, I was going by what other MOTUs had said
<Kamion> you'll never find out if you don't talk to the maintainer who did it that way. :)
<Kamion> we try to cooperate with Debian where possible, not just work around them :-)
<marcin> Kamion: to make things _just work_ while it is common procedure in emacs world ( ;) ) I don't thing it is good for ubuntu image
<Kamion> I have no objection to things just working - all I'm saying is that you seem to be being unduly pessimistic
<marcin> Kamion: well it is pretty hard to work with debian maintainers while propably their packages are maintained in simmilar way to their debian-emacsen mailing list
<marcin> Kamion: which is full of 'penis enlargement' spam stuff instead of real discussion
<Kamion> problems with the lists have very little to do with quality of maintenance
<Amaranth> well, i'm still here, i guess that's good :)
<Amaranth> what i supposed to see any difference?
<Amaranth> err, was
<Kamion> anyway you should feel free to sort things out in Ubuntu; I'm just trying to encourage you not to give up on cooperating
<marcin> Kamion: now I work on some build scripts that will create really huge amount of packages based on single *.el files
<marcin> Kamion: (something simmilar to garnome scripts but my scripts will create *.debs with emacs things automatically)
<marcin> Kamion: and these *.el libraries aren't packaged for debian yet
<marcin> Kamion: so I'll try to follow debian policy this time
<marcin> Kamion: but when I'll finish these packages I'm going to try some more difficult packages
<marcin> Kamion: and then we'll see
<marcin> Kamion: and now I need to go to bed, I'm too tired to talk logically
<marcin> Kamion: and my english sucks more and more in every minute ;)
<daniels> please don't automatically create .debs
<TerminX> is xorg -45 safe?
<TerminX> (yeah, I know 44 works but I feel like I have to ask ;) )
* bddebian hugs daniels 
<bddebian> OddAbe19: Are you in Lancaster?
<daniels> TerminX: yeah, -45 is marginally safer than -44, and -46 will be safer again
<Amaranth> latest version is actaully installable, that's a plus
<TerminX> okay, thanks.. wanted to make sure there wasn't any weird breakage upgrading from 44 to 45 as there was with, say, 36 to 44
<daniels> nah.  but if you don't have any problems with 44, 45 won't give you anything useful.
<daniels> 46 will fix xnest and a couple of other small things.
<Lathiat>  yay xnest
<Kamion> lamont-away: please dep-wait bsh on kaffe (>= 2:1.1.5-4); MOTU will need to sync to that to fix it, I think
<Kamion> ajmitch: you were right, it does need to be synced; 2:1.1.5-3 has some silly hardcoded dependencies (debian/shlibs.local) that were removed in later versions
<daniels> although, um, the server looks a little special on amd64
<daniels> so I guess it's kind of lucky that it's waiting on binary NEW
<daniels> or that it's totally FTBFS
<daniels> ARGH
<Kamion> new's empty ...
<daniels> seriously, I must have run rm *amd64* at some stage
<daniels> headdesk
<Kamion> whoops
<Amaranth> ok, has usplash worked sucessfully for anyone here?
<Lathiat> heh
<Lathiat> you want the new version
<Lathiat> that isnt in the archives yet
<Lathiat> is there some way to get mail when things move into the archives?
<Kamion> not for binaries, no
<Lathiat> damn
<Kamion> no i386 buildd has taken it yet; I assume they're still chasing up main backlog following the libgl1-xorg-dev fix
<Kamion> lamont-away: a lot of stuff seems to have failed due to lack of 'apt-get update' in the buildd chroot or similar ...
<daniels> if -46 builds on i386 and amd64, I'm going to upload it
<daniels> so it shouldn't be too far away
<daniels> (libosmesa being fixed also)
<OddAbe19> bddebian, yeah, why?
<Amaranth> hrm, cellrenderertext and mozilla don't agree on how to render this mix of ltr and rtl languages
<infinity> Kamion : The apt sources are refreshed before each build..
<infinity> Kamion : Example failure?
<Kamion> infinity: nautilus_2.11.91-0ubuntu1_20050810-0236-i386-failed.gz, oem-config_0.5_20050810-0236-i386-failed.gz, others
<daniels> i wonder if I can blame xorg's utter failure on amd64 on this
<infinity> The nautilus failures look more like dirty chroots to me.  Or something else hideously whacky.  I'll poke after I attack my lunch.
<infinity> Kamion : Of course, those kinds of failures also result in automatic give-backs, so if it is a transient archive issue, it'll sort itself.
<infinity> I'll still have a look at all the chroots in a few minutes though. :)
<daniels> Kamion: i assume the libgl1-xorg-dev thing was just causing problems for germinate?
<Kamion> daniels: no, it seemed to be causing a bunch of weirdly fucked-up buildd chroots after failed builds
<Kamion> or at least a lot of stuff was failing to build with cryptic messages from apt, may not have been screwed chroots
<infinity> The weirdly-fucked-up chroots were being caused by the dpkg segv, afaict.
<infinity> Which is unrelated.
<infinity> Unless your change managed to work around dpkg hating itself.
<Kamion> ah. I thought that was related to the uninstallability, though
<Kamion> because the segv was consistently on libglu1-mesa-dev, which is intimately related to libgl-dev providers
<Kamion> and it started happening at pretty much the same time
<infinity> mesag-dev, actually, but yes, those packages are a nasty incestuous group.
<Kamion> oh, it was libglu1-mesa-dev for me
<infinity> Oh, interesting.
<infinity> Well, I'll retry my testcase with the changes you've made and see if the dpkg segv is gone for me.
<Kamion> did you manage to save a tar of /var/lib/dpkg/info and the .deb it was trying to install?
<Kamion> would be nice not to lose the dpkg segv testcase
<infinity> Installing one deb never did it for me.  I had to install a massive set of packages in one rnu.
<Kamion> I was having trouble reproducing it consistently without re-debootstrapping
<infinity> s/rnu/run/
<infinity> elmo may or may not have taken a snapshot of the archive last night when we were disussing the issue.  I'm hoping he did, if it's not magically fixed.
<Kamion> well, we can always extract xorg -44 later at leisure
<daniels> right.  scott's fault. :)
<Kamion> and appropriate matching mesa
<Kamion> I tweaked libglu1-mesa-dev's libgl-dev alternatives, which will probably have helped matters too
<daniels> Kamion: i keep a source morgue of every xorg upload since hoary (except a couple of the weird-shit random uploads in the week I was at LinuxTag, since they disappeared before I got back and caught up), so we can rebuild at will.
<Kamion> but it's all uncomfortably debugging-by-voodoo
<Kamion> I've been going around trying to get stuff updated to the newer package names so that we can demote-to-universe/remove the old ones
<Kamion> which should also help consistency of hoary->breezy upgrades
<ajmitch> if there's any name changes that are affecting universe, notification would be good
<ajmitch> as I'm not sure if we're needing to rebuild packages with new build-deps yet or not
<daniels> Kamion: the hillarious part of all your mesa changes is that libgl1-xorg* will cearse to exist before breezy's out
<daniels> replaced by ... libgl1-mesa*
<infinity> Kamion : The only way to get upgrade consistency will be if sometihng directly depends on libglu1-mes (etc), since everything that depends on libgl/libglu depends on virtual packages.
<Kamion> daniels: yeah, I know, but in the meantime I really want to deconfuse germinate
<Kamion> it was doing shit like pulling in mesag3 because it was the primary alternative from libglu1-mesa or something like that
<Kamion> and that makes it hard to demote the old packages from main, which in turn means people are more likely to upload new stuff (build-)depending on the old names
<daniels> hm
<daniels> it should be letting the dependency be satisfied by the alternative anyway
<infinity> Yay, my dpkg segv is still there.
<Kamion> yeah, it wasn't though, I think because it looked at libglu1-mesa before looking at anything that depended directly on libgl1-xorg
<daniels> huh
<daniels> can't we all just use portage or something?
<Kamion> germinate's ordering-dependent in some cases; we have a couple of seed workarounds for it, but the right answer is to make primary alternatives consistent in main at least
<infinity> Kamion : Your mucking with package relations did nothing to help dpkg stop littering chroots.
<infinity> (glad it helped germinate though)
<Kamion> ah well
<Kamion> grr
<Kamion> daniels: please make libgl1-xorg.shlibs mention libgl1-xorg not xlibmesa-gl kthxbye
<daniels> Kamion: *cough*
<infinity> Kamion : Has libgl1-mesa already been promoted to main?
<Kamion> anyway, *my* primary alternative is to go to bed rather than poking at dependencies ...
<infinity> Kamion : If so, it's more future proof for us to just change those shlibs to be "libgl1-mesa | libgl1"
<infinity> (Since that's what we want in the end)
<Kamion> infinity: no
<infinity> Err, there is no libgl1-mesa.  It's mesag3... And it needs love.
<infinity> But, yeah.  I should go hump mesa's leg for a bit or something.
<Kamion> yeah, if that's going to take some complicated mesa/xorg interaction then I think I prefer the multi-step approach
<Kamion> while taking the point about having to go back and do it all over again later, at least we only end up with one layer of old packages lying around in breezy if we don't get it done in time, rather than two
<infinity> ;)
<Kamion> and I really don't feel good about germinate sucking in stuff that's NBS from xorg :)
<daniels> surely it should follow provides where the package is a pure virtual with only one provider
<infinity> No arguments on that one.
<Kamion> daniels: yes - such as?
<daniels> Kamion: ... xlibmes-agl?
<Kamion> xlibmesa-gl |   6.8.2-43 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
<Kamion> not pure virtual
<daniels> oh, argh
<daniels> can we please cull xlibmesa* from the archive?
<Kamion> that's what I'm trying to arrange
<infinity> If you drop xlibmesa completely, then the "xlibmesa-gl | libgl1" dep becomes a pure virtual.
<elmo> don't
<Kamion> hmm
<elmo> it's not showing up in rene
<elmo> which means something's still claiming to build it
<elmo> pls fix that first
<infinity> elmo : Not yet built on amd64, I assume that's the only issue.
<infinity> (the new source, that is)
<elmo> no, that doesn't matter
<elmo> rene looks at the source, which is always the latest
<elmo> bah, don't make me wake up
<Kamion>         o 6.8.2-43 [ia64, i386, sparc, amd64, powerpc] : libfs-dev, libfs6, libfs6-dbg, xfs, xlibmesa-dri, xlibmesa-dri-dbg, xlibmesa-gl, xlibmesa-gl-dbg, xlibmesa-gl-dev, xlibosmesa-dev, xlibosmesa4, xlibosmesa4-dbg
<Kamion> (rene's partial NBS list) - hppa maybe?
<daniels> daniels@ephemera:~/canonical/brainfreeze/xorg/monolith% grep xlibmesa-gl old/xorg_6.8.2-44_source.changes
<daniels>      + xlibmesa-gl* -> libgl1-xorg, libgl1-xorg-dev, libgl1-xorg-dbg
<daniels> (that's the changelog entry)
<infinity> elmo : Did you snapshot the archive last night so we can reproduce that dpkg segv?  (now would be fine too, I can still reproduce it as of right now)
<Kamion> it's not in xorg -44.dsc
<elmo> xfree86
<infinity> !
<elmo> claims to build it
<elmo> infinity: no, sorry, I didn't think of a cunning way to do it and forgot/got distracted by terranova
<Kamion> heh
<daniels> elmo: i don't see how this is problematic
<infinity> And why do we still have xf86 source packages at all?
<elmo> daniels: because if you remove stuff a source package claims to build the buildds think it needs to be built?
<elmo> xfree86 may have sneaked back in when I spethialed the sync blacklist a while back
<daniels> elmo: right.  so that's why we remove the source package that claims to build it.
<elmo> daniels: sure - I was more objecting to the principle of forcibly removing stuff in rene's partial NBS list
<daniels> elmo: yeah, fair enough
<infinity> Objection duely noted.  xfree86 source removal would be nice. :0
<daniels> if we could nuke xfree86, that would simplify a lot of things
<Kamion> oh, argh, speaking of partial NBS
<infinity> (probably would have been nice about a month ago...)
<elmo>    libxft1 | 4.3.0.dfsg.1-6ubuntu25 | amd64, i386, ia64, powerpc
<Kamion> tseng: please stop mcs building mono-assemblies-arch, I didn't spot that
<daniels> there's a lot of shit that's atrophied since hoary that would still be claimed by xfree86
<elmo> I take it we don't need that?
<daniels> yeah
<elmo> ok, removed, re-blacklisted
<daniels> elmo: we don't need anything that xorg doesn't build today
<ajmitch> Kamion: mcs source should be removed, it's all in the mono source package now
<elmo> ------------------- Reason -------------------
<elmo> [rene]  out damn spot, out
<elmo> ;)
<daniels> elmo: including libxp6, libxp-dev, libxaw8, libxaw8-dev, xmh, xdm (cough), xfs, etc
<infinity> Man, Lady MacBeth was so mean to that dog.
<daniels> elmo: heh
<elmo> daniels: once xfree86 disappears, rene will do her thing and someone who's awake and with katie privs can kill the rest
<daniels> elmo: awesome, cheers
<Kamion> elmo: do I have to know anything special to remove mcs? just melanie in the obvious way?
<Kamion> oh, sync blacklist, hmmmmmm
* Kamion runs away
<elmo> it just a file dude
<elmo> it's like the least katie part
<ajmitch> mcs source isn't in sid either, from what I can see
<Kamion> good point
<elmo> kamion: but yeah, melanie just works, you might want to prefix the removal with '[rene] ' to avoid silly fascism checks
<Kamion> how do we keep track of stuff removed from Debian?
<elmo> I have something that parses removals.txt
<elmo> I wrote it as punishment for logging the removals in such an incredibly unparseable format
<elmo> I haven't run it since UVF tho
* Kamion reads geri's head comment and giggles
<elmo> as tracking removals when we're not syncing new stuff gets insane fast
<daniels> i think lamont should write more katie tools
<daniels> that would be awesome
<Kamion> elmo: btw, did I ever ask you, how do you NEW stuff straight into universe the way you seem to do?
<elmo> Kamion: yeah, and I think I dodged the question, it's a disgusting hack
<elmo> kamion: basically, the problem is the override-source's-idea-of-componet stuff is an old-school warthogs-era hack,and only exists in jennifer
<elmo> lisa doesn't know how to do it
<elmo> so my straight to unvierse stuff, adds the overrides semi-by-hand, then moves the upload from new back into unchecked
<elmo> [yes, I rock.  I'm here all week.  thank you.] 
<Kamion> ah, right, I had wondered if it was something like that since I noticed lisa really didn't like the whole idea
<Kamion> after trying the obvious-looking thing in lisa and then having to unfuck the overrides
<elmo> c.f. 'new_universe' alias the katie user has
<elmo> for the 'semi-byhand' bit
<elmo> oh it's a script in ~/bin/ actually
<Kamion> niiiice
<elmo> :>
<elmo> yeah, not proud
<Kamion> I guess that has trouble with contrib/ and non-free/ stuff from Debian too
<elmo> one day... I'll fix lisa
<elmo> kamion: or anything that mentions universe or multiverse, yes
<daniels> i swear elmo and lamont are one and the same person
<daniels> because I was actually joking about lamont writing bits of katie
<daniels> now I'm not so sure
<elmo> dude, katie's obsolete for us
<elmo> elegant solutions are WAB
<Lathiat> wab?
* infinity laughs.
<raphaelpereira> hi
<raphaelpereira> hello?
<raphaelpereira> i found a bug
<raphaelpereira> and have a patch
<raphaelpereira> is this the right place?
<Lathiat> raphaelpereira: What is it for?
<infinity> bugzilla is probably the right place to document the bug/patch.
<raphaelpereira> which is the addres???
<raphaelpereira> it's simple
<raphaelpereira> and corrects all problems (i hope) related to hibernation on errors of  "scheduling while atomic"
<raphaelpereira> upon resume
<Lathiat> http://bugzilla.ubuntu.com
<raphaelpereira> ok
<raphaelpereira> do you wanna know or i just go there and report?
<Xyc0> I wanna know
<jsgotangco> its best to bugzilla though
<raphaelpereira> ok
<raphaelpereira> Xyc0, simple
<raphaelpereira> schedule while atomic problems probably is kernel bug
<raphaelpereira> i'm no kernel hacker
<Kamion> file the bug, then point him at it
<raphaelpereira> so, i workaround it
<raphaelpereira> ok
<raphaelpereira> sorry
<Kamion> no need to rehash it here
<Xyc0> That works
<Kamion> feel free to discuss pending issues with the patch here, though
<daniels> ummmmmmmmmmmm
<daniels> this is more special
<daniels> the only explanation I can come up with is that I did find ./ -name \*amd64\* | xargs rm -f
<daniels> 'cause debian/patches/600_amd64_support.diff was missing, so everything went into /usr/X11R6/lib64
* daniels boggles.
<Lathiat> umm
<Lathiat> how the hell did you manage that
<Amaranth> who needs amd64?
<Lathiat> haha Amaranth 
<Lathiat> you can get amd64 laptops for like $1100, maybe i should save up for a play
<Amaranth> with 2 hours of battery life, yay
<Lathiat> heh yeh
<Xyc0> Lap tops can get more then 2 hours?!?
<raphaelpereira> http://bugzilla.ubuntu.com/show_bug.cgi?id=11824
<raphaelpereira> sorry for the long time
<raphaelpereira> i didn't have an account
<Xyc0> no worries
<raphaelpereira> i have just noticed
<raphaelpereira> my time is wrong
<raphaelpereira> Xyc0, mine is last
<Xyc0> rgr
<Xyc0> raphaelpereira: Ill have to test this, bbl
<raphaelpereira> bbl?
<raphaelpereira> uau
<raphaelpereira> does someone knows what is the meaning of bbl?
<raphaelpereira> ok
<raphaelpereira> be back later
<Lathiat> be back later
<raphaelpereira> i figured...
<daniels> can we PLEASE try to keep this channel to discussion of Ubuntu development?
<raphaelpereira> sorry mr daniels
<jdub> Kamion: ping
<infinity> Kamion : Have all the old xfree/xorg binaries been removed from the archive by now?
<infinity> Kamion : Or are we still waiting on a cron.something to run?
<infinity> Kamion : I'm cleaning up all the buildd chroots right now, and would like to do a mass give-back to see if anything's slightly happier with the new world order once the old junk is gone.
<fabbione> infinity: what happened to the chroots?
<daniels> dpkg keeps segfaulting
<infinity> dpkg segfaults
<fabbione> ah
<fabbione> what version of dpkg?
* fabbione didn't notice here
<infinity> Anything in the last month?
<infinity> It's been going on for ages.
<infinity> Try "apt-get install libqt3-mt-dev mesag-dev" in a clean buildd chroot.
<infinity> (make sure it's clean first)
<fabbione> create-chroot test
<fabbione> argh.. EWINDOW
<fabbione> Package mesag-dev is not available, but is referred to by another package.
<fabbione> However the following packages replace it:
<fabbione>   x11proto-gl-dev
<fabbione> E: Package mesag-dev has no installation candidate
<infinity> You need universe on.
<fabbione> infinity: so what else can i test?
<fabbione> ok
<fabbione> infinity: nada.. latest mesa didn't build on sparc yet
<fabbione> any other test?
<infinity> That's the only "easily" repoducble testcase I have, though I know there are other killer package combinations too.
<infinity> (I just would have to look through build logs to find them)
<fabbione> ok....
<Burgundavia> jdub, red hat is already working with MIT with that $100 laptop. Looks like your vision of gnome on that laptop might become a reality
<Burgundavia> jdub, http://laptop.media.mit.edu/
<sivang> morning all
<Mithrandir> 'morning
<Treenaks> hi
<Mithrandir> daniels: you've _stolen_ my precious norwegian characters!
<daniels> Mithrandir: no I haven't.
<daniels> they work just fine.
<Mithrandir> no, they don't
<daniels> if you're having problems, follow my howto on -devel
<daniels> but bear in mind that -46, which I just uploaded, was the first sensible version to build on amd64
<daniels> if it still persists, I need a more sensible bug report
<daniels> is your keyboard layout set right?  does it try to set it and bomb out?  does setxkbmap -print look right?  does setxkbmap -print | xkbcomp - :0 help?  does setxkbmap -model pc105 -layout no help?
<daniels> but it's lunchtime
<Mithrandir> yes, no, yes, yes, restarting X seems to have fixed it.
<doko_> good morning
<Treenaks> Mithrandir: s nw you cn d weird Norwegian stuff again? :)
<Mithrandir> !
<Treenaks> we need a single code point for \o/
<Mithrandir> indeed, we do.
<paolo> Do we, provided we have the interrobang
<Treenaks> paolo: Unicode has a code point for the interrobang, so we have the interrobang.
<Mithrandir> whom should I talk with to get my bugzilla ID changed?
<robitaille> Mithrandir:  if you mean your email address, you can do it yourself
<infinity> Mithrandir : Yeah, just set it yourself, there's a 4 day delay or some such, then it switches over.
<infinity> Mithrandir : I did the same thing a couple months back.
<Mithrandir> inded I can.
<Mithrandir> indeed, even
<tepsipak1i> kamion: I can't preseed locales, is it known not to work? even if I set the default locale to be None, it is set as "en", and the locales that I want aren't generated
<tepsipak1i> this is with both hoary and latest breezy-netboot
<tepsipakki> damn typo
<\sh> Kamion: Kick my butt for what I done yesterday..it wasn't my purpose to upload this package without asking...
<Mithrandir> hi pitti
<pitti> Good mor*yawn*ing
<paolo> 'morning :-)
<\sh> morning pitti
<mvo> morning 
<ajmitch> hi pitti 
<sivang> moring pitti 
<sivang> s/moring/morning/
<pitti> Hi ajmitch, hi sivang 
<ajmitch> hi chmj 
<Burgundavia> who is in charge of UbuntuExpress?
<chmj> hi ajmitch 
<highvoltage> hi chmj 
<Mithrandir> ok, ooo2 working on amd64 with gtk looks.
<mdz> pitti: my firefox has become crashy as well
<mdz> Mithrandir: yay!
<pitti> mdz: same for mozilla
<pitti> mdz: and only on amd64, right?
<Burgundavia> mdz, what are the specific plans for the hoary-->breezy updater?
<Burgundavia> mdz, would it be possible for it to show the same screenshot tour as UbuntuExpress?
<Mithrandir> mdz: there is an mozilla-ooo and ooo-evolution, I guess you are fine with me not providing those on amd64?
<mdz> pitti: no, on i386
<mdz> Burgundavia: screenshot tour?
<Burgundavia> mdz, apparently UbuntuExpress will be able to show images while installing
<jdub> Burgundavia: nicely spotted
<pitti> mdz: hm, my i386 installation is not yet updated to the latest packages (libraries, not ffox itself)
<Burgundavia> jdub, now we just need Ubuntu on them...
<pitti> mdz: I'll upgrade, check if it becomes unstable and will try to single out the lib that caused that
<Mithrandir> mdz: and -kde is not even started yet. :-/
<Mithrandir> mdz: I'll finish up the gnome version before starting on ia32-libs-kde, I think
<mdz> Burgundavia: I would be much happier if UE could not display screenshots, but could in fact install Ubuntu
<Burgundavia> jdub, the doc team (myself and jsgotangco mostly) have been working on a new quickguide, ala the original spec. Rough draft at https://wiki.ubuntu.com/QuickTourDraft
<mdz> Mithrandir: do mozilla and evolution require more ia32 libs?
<jdub> YAY ORIGINAL SPEC!
* jdub checks it out
<sivang> jamesh: I get this when running ./autogen:
<Mithrandir> mdz: I _think_ they require mozilla and evo as 32 bit programs.
<paolo> Anybody uses emacs to develop on ubuntu-breezy? heh :-)
<jsgotangco> i do docbook stuff on emacs
<jsgotangco> psgml mode
<jdub> Mithrandir: you think multiarch is doable/sensible for breezy+1
<paolo> jsgotangco, do you know this error: Undefined color: "black" ?  I get this with every emacs I tried (emacs21, emacs-snapshot) - I think it's probably because of Xorg issues.
<sivang> jamesh: http://paste.uni.cc/7567
<jdub> Burgundavia: couple of comments
<Burgundavia> jdub, shoot
<jdub> Burgundavia: could do with a bit more copy where useful
<Mithrandir> jdub: yes.
<jdub> also, really got to zoom in on user-benefit features
<jdub> about-me, for instance, isn't a user-interesting feature
<jamesh> sivang: those are warnings you should ignore
<Burgundavia> jdub, what do you see those as?
<sivang> jamesh: ok, what is the source for them?
<jdub> so *some* breezy goals are user-interesting
<jamesh> sivang: they can only be fixed by updating the packages owning each of those .m4 files
<jdub> such as built in LTSP
<jdub> easier to use file manager
<Mithrandir> jdub: it's going to require some concentrated effort, though
<Burgundavia> jdub, file manager is somewhat mentioned, but could be tied together more
<jamesh> sivang: automake checks to make sure that autoconf macro definitions are of the form AC_DEFUN([NAME] , ...) rather than AC_DEFUN(NAME, ...)
<jdub> Mithrandir: elite
<sivang> jamesh: ah, I see
<jsgotangco> built in LTSP sounds good but quite advanced
<jdub> Burgundavia: yeah, bundle those micro-feature grains into user-benefit blobs :-)
<jamesh> sivang: since M4 is a macro expansion language, the AC_DEFUN(NAME, ...) form is dangerous if the macro gets defined multiple times
<jdub> jsgotangco: it can be explained pretty simply
<jdub> can just point to more information
<paolo> Which lisp is going to be builtin?
<Burgundavia> those who know what LTSP means will be excited
<jamesh> sivang: "AC_DEFUN(foo, bar)AC_DEFUN(foo, baz)" would define two macros: foo -> bar and bar -> baz
<Burgundavia> those who don't will ignore it
<jsgotangco> rights its a quick tour anyways
<jamesh> sivang: proper quoting would give just a single macro
<Burgundavia> jdub, anything else? like the style? anything you would remove?
<jdub> Burgundavia, jsgotangco: i'll pop over to -doc :)
<karlheg> Idea; please implement (RFI): A package that sets the system up for source level debugging of packaged software.  Perhaps if each package had an automatically generated companion package that contains the debugging symbols that have been stripped from the normal binary; GDB supports this.  I think it would be better than having separate debugging versions of libraries.  A gdb wrapper script should be able to set up the environment so 
<karlheg> that gdb picks up those symbols when it's run, right?  (I will look for a place in the UDU Wiki to place this idea)
<siretart> morning
<sivang> jamesh: ok, noted. pkg is here: http://muse.19inch.net/~sivan/lpint/lpint-bonnobo-0.0.tar.gz
<siretart> fabbione: around?
<JanC> karlheg : the udu wiki is merged with the normal wiki now AFAIK?
<Mithrandir> mdz: would you be ok with putting ia32-libs-gtk 4 into hoary?  It fixes printing for people using ooo-amd64
<mdz> Mithrandir: hoary-updates, you mean?
<mdz> Mithrandir: it depends on what the changes are
<Mithrandir> mdz: it wraps spadmin in the pango preload hack similar to what is done to ooo
<Mithrandir> it's been in breezy since may, but you wanted it to have a little time there to see that it didn't break anything before putting it into -updates
<sivang> jamesh: I've kept the way the patch is done, as evident from http://muse.19inch.net/~sivan/lpint/01_lpint_bonobo_src.patch
<siretart> ah, so it's not my fault that my ooo/amd64 cannot print? If I may help testing, tell me where I can download the packages to test ;)
<Mithrandir> siretart: from breezy
<siretart> oh. ok
<Mithrandir> http://archive.ubuntu.com/ubuntu/pool/main/i/ia32-libs-gtk/ia32-libs-gtk_4_amd64.deb
<jamesh> sivang: cool.  I'll take a look at it.
<jamesh> sivang: if you want to manage your changes, a bazaar branch might be easier
<sivang> jamesh: I will crete one today :)
<jdub> jbailey: still around?
<jbailey> jdub: Yup
<sivang> jamesh: it pretty cool using it in that ditributed format, and it's not as hard as it seemed first place (to operate baz, that is)
<jbailey> 'sup?
<seb128> mdz, Kamion: we are targetting a stable desktop this week to run a colony CD?
<mdz> seb128: yes
<seb128> k, here is the issue
<pitti> Hi carlos 
<seb128> cairo has changed its soname ... they were moving the API from some time with .so.1 on purpose, and the API is declared stable now so they bumped it to .so.2
<carlos> morning
<infinity> seb128 : Oh joy.
<seb128> but GTK using it, around ~70 main packages (200 packages) rdepends on libcairo1
<infinity> seb128 : API-compatible?... Cause a mass rebuild with no source changes isn't really tough.
<seb128> yep, API compatible with the current version
<pitti> seb128: can't we do that after the next colony?
<mdz> infinity: is NM going to happen or no?
<seb128> pitti: <seb128> mdz, Kamion: we are targetting a stable desktop this week to run a colony CD?
<seb128> pitti: that's why I ask ...
<mdz> it's been too long since the last milestone; we need one as soon as possible
<pitti> yes, this was planned for the feature freeze
<seb128> k
<infinity> mdz : Are you okay with reverting the resolvconf attempt and going with bind9?... If so, then yes, I think I'm in a position to say "it'll be ready well before breezy"
<seb128> I'll delay the cairo change for after the next colony
<mdz> infinity: the relevant deadline is feature freeze, rather than breezy release
<infinity> mdz : Dropping bind9 loses functionality (like bind views for VPNs), as well as making things not quite work optimally.
<seb128> GTK 2.8 should be out this week too, I'll do both updates after colony
<mdz> infinity: the issues with bind9 were resource consumption and security policy
<infinity> mdz : Well, it won't be perfect for feature freeze, but I can get it "pretty good" in a day.
<infinity> Resource consumption shouldn't be an issue, what's the security worry?
<mdz> infinity: we can choke a bit on resource consumption; security needs to be addressed
<mdz> infinity: no open ports in desktop
<infinity> If we're only binding to localhost, it should be okay.
<mdz> well, we weren't binding to localhost
<infinity> Well, that's easily fixed, then.
<Lathiat> mdz: it was but
<mdz> I'm not convinced of that
<Lathiat> another copy was running standard
<mdz> but I hope so
<Lathiat> from the init scfript
<Lathiat> not sure how you can address that without breaking everyones bind9 installs by not starting it by default
<infinity> mdz : Well, it's a tradeoff, cause allowing NM to depend on bind9 and rnu its own instance that only bindt o localhost means we need to ship a bind9 package that's DOA.
<infinity> mdz : Then again, we shipped postfix DOA with the last release, so I suppose it's something we're used to.
<mdz> infinity: I don't see why
<mdz> I thought NM already supplied its own config to bind
<infinity> mdz : Well, if I depend on bind9, it'll get installed, it'll by default run a cacheing nameserver on *:53 (and NM will also run its own instance on localhost:53)
<mdz> infinity: that's currently the case, yes.  but that's not what we want
<mdz> that's one of the things that needs to be fixed in order to integrate network manager
<infinity> mdz : Right, hence why I said we'd need to deliver bind9 DOA.
<infinity> mdz : Or ship two bind9 binary packages, one just for NM. (ick)
<mdz> infinity: that is not the right solution
<Mithrandir> split bind9 into bind9 and bind9-config where bind9-config is the set of current config files?
<infinity> mdz : I'm flailing for a solution that isn't one of those two.
<mdz> infinity: Mithrandir just mentioned one. another would be to suppress the default bind9 startup if NM is active
<infinity> Mithrandir : That still delivers bind9 DOA, unless the admin knows to install bind9-config. (unless you're suggesting NM provides it as a metapackage, but those packages coulnt'c onflict, cause it's perfectly reasonable to run two bind9 instances)
<Mithrandir> or bind9-daemon is just the daemon and bind9 is the config files + a dependency on bind9-daemon
<infinity> mdz : There's no reason not to run bind9 /and/ NM (though it's an odd setup, sure)
<Lathiat> mdz: so like an /etc/default/bind9 DONT_START_IF_NETWORKMANAGER_IS_INSTALLED or something?
<mdz> the important use cases are: desktop user gets NM + caching nameserver, server user gets "apt-get install bind9"
<infinity> Mithrandir : That's more workable, yes.
<mdz> infinity: it'd be a silly deafult
<mdz> default
<jstr> hello people.  I would like to help Ubuntu by coding.  Is there anyone here that I can talk to get started?
<mdz> jstr: yes
<infinity> mdz : How about the suggestion to split the damon binary into a seperate package, as above?.. That's very little effort on the packaging front, and would seem to solve the problem.
<mdz> infinity: it is one option
<Mithrandir> it means moving conffiles, but that's doable, just ugly.
<infinity> Mithrandir : No it doesn't, the conffiles would stay in bind9.
<mdz> Mithrandir: why?  the conffiles can stay in bind9
<infinity> Mithrandir : And just move the binary itself to bind9-bin.
<infinity> Mithrandir : That's the path of least reistance so far.
<Mithrandir> hm, true.
<mdz> infinity: what about interaction between NM and ifupdown?  is that all sorted?
<infinity> In that ifupdown has absolutely no clue about NM-managed interfaces?  No.
<mdz> I think that the reverse is rather the problem
<Lathiat> infinity: itd be nice if you could stop network-manager, and then start it and have it work again
<Lathiat> or just have it not eat my interfaces if i play with them
<jdub> infinity: so thom and i were talking about making ifupdown understand n-m
<jstr> sweet.  Well I am a comp sci student in australia.  I would like to do some open source work before I graduate so I have a nice looking resume.  I like using C, and have done a unit on C in UNIX, but i have also done units in C++, java, and heeps of boring things like UML and project management.... I plan to give at least a year of commitment to a project.
<infinity> jdub : Do you have logs of this?
<mdz> jdub: I don't think it should
<mjg59> Lathiat: Hm. It needs 0.1-2, which doesn't seem to have hit the archive yet
<infinity> jdub : I hate reinventing wheels.
<jdub> infinity: such as having static/dhcp/managed in interfaces, stuff like that
<mdz> jdub: I think NM should stay the hell out of the way if ifupdown is managing an interface
<jdub> infinity: i wish i did - i'll ping thom about it
<jstr> what group should i join?
<jdub> mdz: yeah, exactly, that's the idea
<Lathiat> mjg59: usplash?
<mdz> jdub: how does that equate to ifupdown understanding n-m?
<Lathiat> mjg59: i think the buildds were a little hosed last check
<jsgotangco> jstr: help the MOTU: https://wiki.ubuntu.com/MOTU
<infinity> mdz : Well, the design goal of NM was to have it manage things independently of other system tools like ifupdown.  OTOH, if they can be made to not hate each other, I'm not opposed to the concept.
<Lathiat> well ifup/down marks if it has brough tan interface up or down
<jstr> thank you
<Lathiat> n-m could look at that, and not touch the interface if its been brought up
<mdz> infinity: to rephrase, NM is broken if it interferes with existing ifupdown configurations
<mdz> infinity: that is a showstopper bug
<infinity> mdz : What if I bring the iface up with ifupdown, but then I want to fiddle with it (say, associate with another WAP) with NM?
<Lathiat> infinity: the real problem right now is that if you bring an interface up, it screws with it immediately, not if you click on something or whatever
<mdz> infinity: for a given interface, you should either use NM xor ifupdown
<doko> Mithrandir: could you use openoffice.org2_1.9.121-1ubuntu7 as a base for the amd64 packages?
<jstr> jsgotangco: is there a channel for MOTU?
<Lathiat> jstr: #ubuntu-motu
<jsgotangco> jstr: #ubuntu-motu
<Lathiat> jstr: http://wiki.ubuntu.com/MOTU
<jstr> thank you
<jdub> mdz: so the basic idea was configuring an interface as a managed interface
<jdub> infinity: thom should hve logs at home
<mdz> jstr: it's one of the first things on http://wiki.ubuntu.com/MOTU
<mdz> jdub: what we need is the "by tomorrow" solution
<mdz> which lets us get NM into desktop and start testing it
<mdz> otherwise it's not going to make breezy
<infinity> jdub : "iface eth0 managed", and then ifupdown doesn't own it, and "grep -v managed iface" are the interfaces NM should stay the hell away from?
<Mithrandir> doko: I'm using whatever is in breezy
<doko> Mithrandir: just freshly built.
<mdz> the day of reckoning is upon us
<infinity> jdub : That would require exactly 0 changes to ifupdown (since it'll just ignore those stanzas anyway), and could be hackable into NM..
<jdub> infinity: yeah, at least that's one of the ideas i started with - the conversation went from there (thom is looking for logs now)
<jdub> infinity: i like to dabble in simplicity 8)
<infinity> jdub : But how do you cover the "I just plugges a new USB wifi interface in that I didn't have before" use case?... Does NM just toss it into /etc/network/interfaces, so users don't have to set it to managed on their own?
<jdub> infinity: unconfigured in interfaces means it's up for grabs
<infinity> Having to update a config file to declare something as "managed" sounds kinda dodgy, I guess.
<mdz> infinity: interfaces which are configured in interfaces(5) should be left alone by NM.  others should be managed by NM.
<mdz> it's backwards
<jdub> yes
<mdz> there's no need to add new syntax either
<infinity> jdub : Ahh, then there's no need to declare something "managed" at all.
<jdub> thom's found the logs
<infinity> Gimme.
<infinity> :)
* jdub half remembers the conversation going this way
<seb128> hey jdub
<jdub> yo seb128 
<jdub> infinity: http://planetarytramp.net/nm-interfaces
* jdub pastes it unread ;)
<jdub> oh, hey, i made more sense then than i do now
<jdub> pitti: are you buying the "system bus restart means reboot time" stuff?
<alberto> hi
<alberto> someone in powerpc? ibook?
<alberto> I installed ubuntu in a iBook 12" G3
<pitti> jdub: we had this discussion on the utopia list
<jdub> pitti: yeah, saw it
<alberto> and sound in speakers is very low, when I play something it first sound a bit and after is ultra low
<Lathiat> alberto: This is a development channel for discussion of ubuntu devleopment, please goto #ubuntu for user support
<alberto> Lathiat: is a bug
<pitti> jdub: the argument is not bad, I didn't finally made up my mind about this yet
<alberto> alsaconf is not in alsa-utils
<alberto> that is a bug
<alberto> I'm sure
<mdz> alberto: it isn't a bug, and this isn't the place to report bugs
<mdz> alsaconf was intentionally removed
<pitti> alberto: please open the mixer and push up the DRC range (or disable DRC)
<pitti> jdub: we have reconnection patches for update-notifier and g-v-m, it is certainly possible for the battery applet, too
<pitti> jdub: if we can make it work with reconnection, I'd prefer that
<jdub> pitti: yeah
<pitti> jdub: what do you think?
<alberto> mdz: why was removed?
<mdz> alberto: it is obsolete
<jdub> pitti: i'd like to think we were not absolutely lame, but sometimes i wonder about the rh guys ;)
<alberto> ok
<mdz> alberto: you should never need to use alsaconf; if it isn't configured automatically out of the box, then that is a bug
<alberto> mdz: I am debian user since years ago, and I used to do all manually
<alberto> I thought that could be a bug, sorry
<infinity> jdub : Okay, you guys were talking a level of complexity beyond what we were just talking about here.
<infinity> jdub : And something that's not realistic for "can I have it done in a day? (or a few, if mdz cuts NM some slack)"
<seb128> jdub, pitti: we should probably drop on the "restart dbus on update". I've talked with walters on #gnome-hacker yesterday. Upstream/Redhat/Suse are not going this way, and dbus is going to be used by a lot of stuff, that will require some good patching all over the place and probably create some bugs ...
<jdub> infinity: well, if you ignore the mandatory settings stuff, it's exactly what we've just described
* infinity has to go bootstrap jbailey's biarch glibc/gcc stuff...
<jdub> infinity: n-m to own what interfaces doesn't
<jdub> infinity: (which, in effect, leaves interfaces as the mandatory settings layer for the time being)
<infinity> jdub : Yeah, and the crazy "ifupdown should talk to NM via dbus" stuff. :)
<pitti> alberto: does the DRC setting help?
<jdub> oh, that was early in the conversation
<jdub> much crack
<alberto> pitti: for sure
<alberto> I am happy XD
<alberto> :D
<infinity> jdub : Still, there was the valid point raised about "how the heck do I get a network when I boot in reocovery mode?"
<jdub> yeah
<nomed^> hi all .. just a question .. i sow that debian is workin on a script: xserver-xorg.init .. "http://necrotic.deadbeast.net/svn/xorg-x11/trunk/debian/changelog" is ubuntu planing something similar?
<alberto> why is disabled drc channel by default?
<infinity> jdub : If an interface can't be configured in /etc/n/i for NM to manage it, then you've got a catch-22 there.
<infinity> jdub : No network until the GUI comes up for the normal use case means recovery is much more difficult for the clueless.
<mdz> nomed^: no; we already solved this problem in a simpler way, but Petter wanted to do it differently
<jdub> infinity: in that case, our first run having a slight negative impact on recovery mode is probably something we can handle
<pitti> alberto: that's fixed in breezy btw
<jdub> infinity: won't the NM daemon do something sensible before the GUI is up?
<nomed^> mdz, could you give me a link or more infos about this .. ?
<mdz> nomed^: for the live CD, it is done by casper, for thin clients, it is done by ltsp
<infinity> jdub : Oh, yes, in runlevel 2 it will, but DBUS doesn't even run in runlevel 1.
<nomed^> mdz, ok thanks
<jdub> infinity: so i don't think we need to worry about recovery mode
<infinity> jdub : So, we should get a network when DBUS kicks in in rc2.
<mjg59> Lathiat: Hngk.
* _mvo_ curses at his network
<mjg59> Lathiat: Yes, usplash. Looks like it's the buildds
<infinity> jdub : I dunno.  It makes it much harder to do user-to-user support, if you have to tell someone how to manually configure their network interface before they can "ifup eth0 ; wget some_random_file ; perform fix"
<Lathiat> mjg59: indeed
<infinity> jdub : I'm not sure if losing that is really worth the shininess of NM being shoved in prematurely.
<mdz> infinity: "dhclient eth0" fills that use case nicely
<infinity> Oh, fair enough.
<jdub> infinity: it's not that hard, in the simple case, you should just be able to dhclient
<Lathiat> perhaps in recovery dhcp could be attempted on all interfaces or something
<jdub> infinity: and the non-simple case involves configuring interfaces ;)
<infinity> Alright, objection withdrawn then.  We can go with the simplest "if it ain't in interface, NM owns it" path, then.
<infinity> Lathiat : "recovery mode" isn't really a "mode" at all, it's just runlevel 1.
<daniels> paolo: undefined colour: black means that X is missing its RGB database, which is actually sort of somewhat true for new installs ...
<infinity> Lathiat : We don't do anything special in that mode, we just stop booting half way.
<Lathiat> infinity: you could add a grub flag tho 
<Lathiat> but true
<infinity> Well, yes.
<jdub> The following extra packages will be installed:
<jdub>   libslang2-dev
<jdub> The following packages will be REMOVED:
<jdub>   aalib1-dev libxine-dev slang1-dev
<jdub> The following NEW packages will be installed:
<jdub>   libslang2-dev
<infinity> We can parse /proc/cmdline and do something spiffy, but I'm not sure how worth it that is.
<jdub> The following packages will be upgraded:
<jdub>   libcaca-dev
<paolo> daniels, indeed.  I replaced the 4 lines long rgb.txt that comes with the default install with the 700+ lines long xorg one.  Now Emacs start correctly.  Should I file a bug?
<jdub> 
<jdub> seb128: know about that ^ ?
<infinity> "run ifup eth0" and "run dhclient eth0" are pretty much equivalent from a "I have no idea what either of those commands mean because I like mice" perspective.
<jdub> infinity: figlet in base -> "WELCOME TO RECOVERY MODE, THIS IS YOUR SHELL" :)
<jdub> having to use recovery mode is bad to start with
<mjg59> Hm. No exciting DCC announcements?
<alberto> thanks pitti and mdz 
<jamesh> not cowsay?
<jdub> mjg59: dude, the booth was EMPTY today
<daniels> paolo: no, I already have it in hand
<daniels> mjg59: HA HA HA
<mdz> pitti: my firefox crash is at 0xb7e9304d in nsCOMPtr_base::begin_assignment ()
<infinity> jdub : Agred, single user is not something we should ever have to dump anyone into.
<paolo> daniels, ok great.  It is also missing the binary "showrgb".
<daniels> paolo: yes
<mjg59> jdub: No Userlinux either?
<mjg59> "Jim Zemlin, executive director of the Free Standards Group, the organization behind the LSB, will be speaking at the DCCA's launch Tuesday at LinuxWorld."
<seb128> jdub: what are you trying to install?
<infinity> mdz : Alright, if we're agreed on the single user use case being irelevant, and that "not in interfaces means NM owns it", then I think we're good to go.
<jdub> seb128: libcaca-dev
<infinity> mdz : Assuming the bind9/bind9-bin split is acceptable for the other glaring issue.
<mdz> infinity: yes
<jdub> mjg59: saw bruce around
<seb128> jdub: I'm not maintainer for that :p
<jdub> seb128: cheeky :)
<seb128> jdub: xine is the one broken here
<jdub> yeah
<jdub> should depend on slang2
<infinity> mdz : Given that the current packages are in rather poor shape and poorly tested, I assume there's no argument with updating to a more recent CVS snapshot?  It's a bit less broken in general upstream, it seems.
<seb128> jdub: I'll fix that
<jdub> seb128: want me to turn it around for you?
<seb128> feel free :)
<jdub> dum-de-dum :-)
<Simira> morning, jdub 
<HiddenWolf> What's the deal with DCC anyhow? Looks like they're infighting even before launch, and everyone has a different idea about what it should/will be.
<jdub> HiddenWolf: falling apart before they can even announce.
<Lathiat> whats that the debian commercial thing?
<HiddenWolf> jdub: how so?
<jdub> HiddenWolf: sun wah and others bailing out
<HiddenWolf> jdub: omg. I'm not sure what I should think of that.
<jdub> how about, "oh, already?"
<mjg59> jdub: Sun Wah bailing out?
<Lathiat> sun wah?
<mjg59> I knew VA had
<Amaranth> not funny
<jdub> mjg59: was written up in eweek
<HiddenWolf> jdub: I'm doubting between "sucks to be debian" or just plain "sucks"
<jdub> HiddenWolf: note that DCCA is *not* debian
<Amaranth> xutils and xbase-clients are showing as obsolete in synaptic but lots of things use them :P
<mjg59> jdub: Eweek wrote about VA - Sun Wah still seemed positive
<HiddenWolf> jdub: yeah, I know. But they'll need some focus in order to get a grip, and this could have been just the thing.
<daniels> Amaranth: that'd be 'cause they don't exist in the archive in any version at the moment.  wait 'till the next pulse kicks.
<jdub> $ dpkg -L libxine1c2 | grep so$ | while read i; do ldd $i; done | grep slang
<jdub>         libslang.so.1 => /lib/libslang.so.1 (0xb7ef9000)
<jdub>         libslang.so.2 => /lib/libslang.so.2 (0xb7cd1000)
<Amaranth> oh!
<jdub>         libslang.so.1 => /lib/libslang.so.1 (0xb7eb2000)
<Amaranth> ouch
<jdub> ^ ha ha
<mjg59> HiddenWolf: If it had actually involved Debian in any way, it's possible that it would have led to good things
<Treenaks> jdub: omg?!
<Amaranth> xine links against both at once?
<jdub> er, even worse
<jdub> /usr/lib/xine/plugins/1.0.1/xineplug_vo_out_aa.so links against both at once
<HiddenWolf> mjg59: well, yeah, perhaps. if you give debian a say tho, you have to reach a concencus among thousands of devesl rather than a few CEO/CTO's - it'd be braindead rather than falling apart
<mjg59> HiddenWolf: Debian developers are never going to do anything to benefit a set of companies that aren't working with Debian
<Lathiat> it'l make good flamewords on ddl tho
<paolo> daniels, you do probably know it too, but I wanted to make sure: the xbase-clients package do install more or less nothing.
<HiddenWolf> mjg59: and there you have a reason for going outside of debian. :)
<mjg59> HiddenWolf: Right. Which probably means you shouldn't use their trademark...
<Amaranth> paolo: that's a feature, not a bug
<paolo> Amaranth, cool.  Do you know where to find everything missing there? (e.g. xfontsel)
<Amaranth> they've gone to a better place
<Amaranth> hrm, daniels is rubbing off on me
<HiddenWolf> mjg59: depends on how you do things. Perhaps the plan was to build a corporate debian deriviate.
<HiddenWolf> Amaranth: do we want to know? ;)
<mjg59> HiddenWolf: Which would still be a violation of the trademark
<jdub> HiddenWolf: which shouldn't use the trademark...
<HiddenWolf> mjg59, jdub, I never said they where smart, did I?
<Amaranth> hey, i thought ubuntu was the corporate debian derivitive ;)
<Amaranth> corporate == workstation
<HiddenWolf> Amaranth: ubuntu has debian and others wetting their pants, really.
<mjg59> Not so much Debian
<daniels> paolo: this is fixed in -46
<daniels> paolo: which is probably waiting in NEW
<mjg59> More the people whose revenue streams depend on people buying their distribution
<Amaranth> daniels: oh, xbase-clients has stuff in it again in -46?
<jdub> Amaranth: ubuntu is not a desktop/workstation OS
<highvoltage> HiddenWolf: Ubuntu relies on Debian.
<daniels> Amaranth: 'stuff in it' -> 'dependencies'
<HiddenWolf> mjg59: no, debian is just grinding its teeth.
<Amaranth> ah
<highvoltage> HiddenWolf: if Debian has to wet its pants, then Ubuntu has to too.
<paolo> daniels, great - thank you for the informations.
<mjg59> HiddenWolf: Uh. No.
<jstr> mdz:  Ive signed up for doing some work with MOTU.  Im just wondering if there is also some coding work that i can get involved with?
<HiddenWolf> highvoltage: I doubt it. If ubuntu gets things done, and debian does not, devels might choose to upload here rather than at debian. The projects rely on eachother, but if debian messes up, ubuntu might just be the bigger brother eventually.
<sivang> Amaranth: it will be excellent as a server too ;-)
<ajmitch> HiddenWolf: and we try & get things back into debian that we put into ubuntu
<Amaranth> HiddenWolf: the way we do things in universe would never scale to the level of developers debian has
<jdub> HiddenWolf: long term, perhaps, but short/medium term, not really
<HiddenWolf> Amaranth: I know, but organisations and methods change. as do goals. my piont was: Ubuntu is a wake-up call for debian, and they have to do it right, or they'll lose users first, then developers. 
<HiddenWolf> jdub: notice the eventually
<daniels> i don't think that ubuntu will ever function as a centre of more generalised development in such a way that it surpasses debian
<HiddenWolf> Amaranth: judging from that is going on now in debian, and this DCC thingy, Debian is not awake yet.
<paolo> daniels, is there a place where I can find this kind of informations by myself instead of begging here?
<daniels> we do two sorts of things: big, big things (gnome, xorg, nm, whatever) that get back, and small cool usability tweaks
<daniels> paolo: the xorg changelogs on breezy-changes
<daniels> HiddenWolf: i don't think DCC is any serious challenge.  it's not like any of those vendors (progeny, va, sun wah, linspire, xandros), have ever made any constructive effort to engage with debian anyway.
<HiddenWolf> daniels: let us hope we don't have to, but let's face it, ubuntu gets stuff done, debian, dcc or what they'll think of next, probably won't. That is hurting debian and it's reputation.
<Lathiat> wtf is sun wah
<Lathiat> ive never heard of it
* infinity runs off to bootstrap jbailey's biarch glibc/gcc changes.
<daniels> HiddenWolf: i think Debian does a lot more than you give it credit for.
<jdub> Lathiat: chinese commercialised debian
<Lathiat> jdub: ah
<Amaranth> HiddenWolf: Standing on the shoulders of giants.
<jdub> Amaranth: don't be rude
<Amaranth> ?
<jdub> HiddenWolf: debian gets our packages done... please don't take that for granted
<daniels> HiddenWolf: try scaling motu to 10,000 packages.  say what you like about debian, but it has a massive field of maintainer who generally care deeply about their packages, which we just cannot replicate unless we scale to the same degree.
<Amaranth> jdub: How was that rude?
<jdub> Amaranth: it was not originally said as a positive statement :)
<Lathiat> i was wondering that
<HiddenWolf> daniels: I know they're great, and I hope they stay great. I just don't see them moving forward. but let's drop it. only time can tell any way.
<Amaranth> jdub: It just means what you said.
<jdub> Amaranth: might want to check the history of it :)
<Amaranth> jdub: Ubuntu gets the cool things done because of what debian gives us.
<mjg59> Amaranth: The "Standing on the shoulders of giants" thing referred to a short person
<\sh> yes...a new ejabberd version
<mdz> jstr: it's too late to develop new features for the 5.10 release, but you can start working on something for 6.04
<jstr> thats fine.  is there a group that needs members?
<Mithrandir> doko: [Java framework] sunjavaplugin.so could not load Java runtime library:
<Mithrandir> file:///usr/lib/libgcj.so.6.
<Lathiat> mjg59: a giant can stand on another giant
<Lathiat> heh
<Lathiat> i think i took it the way amaranth did
<Lathiat> jdub: mm friday, avahi 0.1, :)
<Lathiat> altho ross thinks its not a 0.1 because it has documentation and man pages
<jdub> Lathiat: yay
<pitti> /usr/bin/ld: /tmp/ccVIzjHe.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
<pitti> /tmp/ccVIzjHe.o: could not read symbols: Bad value
<pitti> meh???
<Lathiat> nice
<daniels> i like `a local symbol'
<pitti> anyway,  -fPIC helped
<Lathiat> heh
<tseng> Kamion: better to just drop mcs completely.
<tseng> Kamion: i will mail elmo.
<doko> Mithrandir: hmm, can you try lib32gcj6 ?
<Mithrandir> doko: it's installed
<Mithrandir> doko: apart from that, ooo2-amd64 is there
<Mithrandir> (missing -kde, still)
<doko> yep, sunjavaplugin.so wants that ... don't know yet how to fix that. maybe edit sunjavaplugin.so and point it to the correct location?
<jdub> seb128: http://people.ubuntu.com/~jdub/xine-lib.diff
<Mithrandir> I would seriously want not to run sed on random .so-s :-P
<doko> s,/lib/libgcj.so.6,/lib32/libj.so.6, 
<doko> well, the applications should work, as long as you don't touch the java things ...
<doko> Mithrandir: and if you go this way, libofficebean.so is the other one to edit ...
<Kamion> tseng: no need, I already removed it
<Kamion> jdub: pong
<Kamion> infinity: sorry, I crashed, I'll have a look now
<daniels> gdb Kamion core
<daniels> (gdb) bt
<jdub> Kamion: hey, um, really sorry to lump you with this,
<jdub> Kamion: but we have a late goal we need to integrate for breezy
<Mithrandir> doko: I've nuked the openoffice2-officebean
<jdub> Kamion: think you may be able to manage this one quickly
<jdub> Kamion: reference document here -> http://forums.gentoo.org/viewtopic-t-365647.html
<Mithrandir> doko: problem is ooo2-base is mostly unusable without the java stuff.
<jdub> Kamion: need it to work out of the box on ppc
<Lathiat> jdub: haha thats interesting
<Kamion> jdub: not a hope. I cannot take extra goals right now, I'm sorry
<doko> Mithrandir: yes, that's known. although it's ugly, I chan check, if the hex-editing would help. The OOo2 build expects a JAVA_HOME, I cannot change that easily
<Kamion> I have two days to deal with everything I have to do for feature freeze, and three days to organise a wedding
* jdub chuckles
<jdub> Kamion: *love* :-)
<Mithrandir> jdub: that's utter crack.
* jdub dries his eyes ;-)
<Kamion> and also, that's ... what Mithrandir said. :-)
<Kamion> I hadn't even looked at the URL before refusing :)
<Kamion> wow, that's totally insane
<Mithrandir> it's _bad_ and utter crack. :-)
<jdub> :-)
<daniels> jdub: OH MY GOD, DUDE
<jdub> thought you'd enjoy that one :)
<Kamion> I'm really impressed that shit works at all
<Mithrandir> jdub: you need to lower your dose of bad drugs.
<Kamion> not impressed enough to actually use it, but ... ;)
<jdub> OUT OF THE BOX! :)
<daniels> can we kill xlibs-dev before feature freeze?
<Mithrandir> doko: I would rather ship an ooo2 without -base on amd64, really.
<doko> jdub: xine-lib 1.0.1 has issues with GCC-4.0 ... there are a new 1.0.2 and a 1.1 upstream
<jdub> doko: boh!
<Kamion> infinity: looks like elmo removed all that stuff though
<doko> Mithrandir: it's not just -base, you find the java stuff in other places as well. i.e. most wizards, docbook-save in oowriter
<jdub> seb128_: oops, wrong url anyway: http://people.ubuntu.com/~jdub/random/xine-lib.diff
<Mithrandir> doko: ew
<Lathiat> doko: i thought it all worked with free java stuff now? (or is it a stuff in main issue?)
<tseng> Kamion: ok.
<doko> Lathiat: it does
<seb128_> jdub: thanks :)
<Mithrandir> doko: can you provide me with something that ooo will find when looking for JREs?
<jdub> seb128_: you approve?
<jdub> seb128_: if that's okay, i'll try upping to 1.0.2
<doko> Mithrandir: ?
<Mithrandir> doko: I refuse to sed random shared objects to mangle paths, can't it have a search path or something?
<seb128_> jdub: do you need to Build-Depends on libslang2-dev ?
<seb128_> jdub: no you don't, libaa1-dev Depends on it
<crispin> daniels: where should the /etc/X11/X symlink point ? Mine is currently a broken link to /usr/bin/X11/Xorg
<Gandalfar> can anyone point me to more documentation about 'casper'?
<Kamion> seb128: indeed - much of the point of the aalib transition was to remove explicit slang dependencies
<jdub> seb128: ok, ta
<Kamion> unless you're actually using slang directly of course
* Mithrandir prods doko 
<jdub> nah, that was my add
<jdub> is it ok to build-conflict with slang1-dev tho?
<jdub> otherwise it can (and did) build against both
<Kamion> pretty unnecessary if you build-dep on libaa1-dev
<Kamion> given that there's never been a version of libaa1-dev (as opposed to aalib1-dev) that depends on slang1
<Kamion> but I guess it's ok
<doko> Mithrandir: not before feature freeze ...
<daniels> crispin: /usr/bin/X11/Xorg should point to /usr/X11R6/bin/Xorg
<jdub> Kamion: well, that's changed in this patch too, so i may as well not
<Mithrandir> doko: ok, any other good ideas?
<Lathiat> daniels: yay dbus patch works
<Kamion> daniels: oh! Xorg is a symlink to ../X11R6/bin/Xorg
<Kamion> daniels: can't do that, it's going to have to be an absolute symlink, considering that /usr/bin/X11 -> .
<Kamion> ... or not, it seems to work anyway, hmm
<doko> Mithrandir: please can you check out, if the java stuff actually works with the hack, I don't want to waste time adding a search path, and then it doesn't work anyway ...
<seb128> daniels: it points to /usr/bin/X11/Xorg too here
<daniels> yes
<daniels> /usr/bin/X11 -> /usr/bin, /usr/bin/Xorg -> /usr/X11R6/bin/Xorg
<seb128> and there is no /usr/bin/X11/Xorg
<Kamion> evidently the kernel is cleverer than I thought
<mvo> Kamion: I need approval for a update-manager upload (bugfix only)
<Kamion> mvo: what's in it?
<mvo> Kamion: more carefull mirror preserve and updates so that breezy source lines are created by default
<daniels> seb128: there's no /usr/bin/X11/anything
<mvo> hardly any code changes (~5 lines)
<crispin> daniels: thanks, that fixed it, although I notice now non-root can run X, is that intentional ?
<mvo> Kamion: I can do you a debdiff if you want
<Mithrandir> doko: segfault; the strings aren't the same length.
<doko> s,/lib/libgcj.so.6,/lib32/libj.so.6, 
<doko> they are.
<Kamion> mvo: that's fine
<daniels> crispin: 'can' or 'can't'?
<seb128> daniels: after a purge/reinstall /etc/X11/X point to /usr/bin/X11/Xorg here ...
<crispin> daniels: 'can'
<daniels> seb128: yes.  that's intentional.
<mvo> Kamion: thanks
<HiddenWolf>   Guys, why isn't there a pointer to the national ubuntu channels in the topic of #ubuntu?
<jdub> because there are buttloads of them ;)
<seb128> daniels: it's intentional to point to something not here?
<tseng> HiddenWolf: you could make/find an appropriate wiki page to link?
<jdub> doko: so, updating to 1.0.2 is beyond my meagre skills :)
<daniels> seb128: if x-common isn't installed already, install it
<daniels> seb128: if it is, then something went badly wrong
<seb128> daniels: it's installed
<HiddenWolf> tseng, I might
<seb128> ii  x-common       1.05           common files for X implementations
<daniels> seb128: 'then something went badly wrong'
<seb128> grumpf, k
<daniels> seb128: /usr/bin/X11 should point to /usr/bin
<Kamion> daniels: there's a batch of xorg uninstallables on http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html still; have you looked into them yet, or shall I?
<seb128> daniels: 
<seb128> $ ll /usr/bin | grep X11
<seb128> lrwxrwxrwx  1 root   root         14 2005-08-06 13:56 X -> ../X11R6/bin/X
<seb128> drwxr-xr-x  2 root   root       4096 2005-07-27 20:23 X11
<seb128> lrwxrwxrwx  1 root   root         17 2005-08-06 13:56 Xorg -> ../X11R6/bin/Xorg
<daniels> Kamion: let me get some sugar to prop myself up and sort it out, 'k
<jdub> (the bed in this hotel is *extremely* comfortable)
<john6000> can you make a update which changes grub? (if its not too hard)
<john6000> :-)
<doko> jdub: yep, maybe that can be done after feature freeze as a bug fix ...
<john6000> ok
<john6000> ty
<hmrocha> hi
<daniels> oh
<hmrocha> breezy has some problems with keyboard mappings
<hmrocha> after the upgrade, i've some characters
<hmrocha> i'm using a pt layout
<daniels> Kamion: i suspect that xb-c and xutils are uninstallable because they're still in NEW, maybe? x-w-s-c depends on them
<hmrocha> and i can type braces or brackets for example
<daniels> Kamion: failing that, I suppose more complete output would be nice
<ogra> jdub, try not to snore to loud into the channel please :)
<chz> hello
<Mithrandir> doko: hm, sed-ing seemed to work
<chz> never knew bout this channel, got referred by hmrocha from #ubuntu...having issues with breezy upgrade and understand that X is still very buggy....true..?
<Kamion> daniels: sorry, nothing in NEW
<Kamion> chz: this isn't a help channel, I'm afraid
<chz> Kamion: o...ok
<jordi> does anyone know if there's some effort from the Ubuntu folks to fix all the bugs in VEra and maybe get them release a new version?
<Kamion> daniels: xbase-clients Depends: xprop, xutils Depends: sessreg
<Kamion> daniels: xprop's in universe, I'll fix that now
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development (not support, even with breezy) | #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 | i386,powerpc live CD builds restored: http://cdimage.ubuntu.com/daily-live/current/
<Kamion> sessreg is nowhere
<doko> Mithrandir: ok, let's put this on a list, however that won't make it for feature freeze
<daniels> Kamion: thanks.  i'm working on sessreg now, just got to sort out a couple of fun political issues.
<Mithrandir> doko: ok, I'll just upload ooo-amd64 for now
<chz> Kamion: curious..what is this channel for ?
<Kamion> daniels: is it today/tomorrow kind of material
<Kamion> chz: development
<Kamion> s/material/material?/
<doko> daniels: if debconf priority is set to low, I'm ask for the xserver settings three times on an upgrade
<daniels> Kamion: i set it as a 'if you guys can't come up with anything compelling within the next couple of hours, I'm going to do it anyway'
<Kamion> chz: i.e. coordination among developers, discussion of bug-fixes and code for new features, etc.
<Kamion> daniels: cool
<daniels> doko: lies.  lies and deceit.
<daniels> Kamion: any compelling objections, of course
<Kamion> doko: s/low/low or medium/
<daniels> and which settings?
<chz> Kamion: towards Ubuntu distro...or applications?
<daniels> i want to know which versions you're upgrading from and to
<daniels> and which templates are getting asked
<Kamion> chz: mostly distro, but whatever's necessary
<hmrocha> is it easy to fix the keyboard issues?
<Kamion> daniels: for me it happens on every single upgrade; e.g. both -44 to -45 and -45 to -46
<hmrocha> maybe there is some misconfiguration in some keyboard package
<Kamion> I get the PCI bus id question at least, afraid I can't remember the exact list
<doko> Kamion: low
<chz> Kamion: interesting...thanks. i noticed the topic and am interested in helping with development. i will goto #ubuntu-motu as i see you are all busy...thank you anyway... =)
<daniels> Kamion: if you can trigger it again and find the exact questions, that would be good
<daniels> Kamion: because I cannot reproduce it here
<daniels> hmrocha: as kamion says, this is not a support channel
<Mithrandir> doko: ok, I'll look at -kde then upload ooo2 in the current state.  It's mostly usable
<ajmitch> daniels: I see the questions about pci id, & asking if I want to use kernel framebuffer
<hmrocha> daniels, i'm trying to work on a development issue here
<daniels> ajmitch: thanks
<hmrocha> daniels, since hoary was working
<daniels> hmrocha: it's not a development issue, it's a user support issue that happens to be with the development *tree*.  the two ideas are fundamentally different.
<doko> daniels: /Select the desired X server driver/Enter an identifier for your video card/Please enter the video card's bus identifier/RAM size of graphics card/Use Frambuffer?/
<Kamion> daniels: hmm, just a thought though, you might try in LANG=de_DE.UTF-8
<daniels> doko: thankyou
<daniels> i suspect they need some auto_answer akshun
<Kamion> hmrocha: daniels posted recently to ubuntu-devel@lists explaining certain things you needed to install
<daniels> did I mention that I hate the steaming pile of crap that we inherited in terms of xserver-xorg debconfiscation? and the fact that we made it even worse ...
<daniels> Kamion: in german?
<Kamion> that was what I happened to be in when it just happened to me, and I'm guessing it's doko's locale, that's all
<Kamion> daniels: was one of the metapackages supposed to depend on xkeyboard-config?
<Mithrandir> Kamion: well, I've seen it once in a while in nb_NO.UTF8, fwiw
<janimo> daniels, I got asked 3 times as well using default locale
<daniels> Kamion: x-w-s-c depends on it, xserver-xorg recommends it, and it should also be in the desktop seed
* pitti has to reboot
<Kamion> daniels: yeah, was wondering if x-w-s-c was low-level enough; that functionality used to be in xlibs-data or something, didn't it?
<daniels> Kamion: xlibs, yeah
<Kamion> could xlibs depend on it for the upgrade?
<ogra> somehow xinit is missing here in my test installs.... is that intentional ?
<daniels> Kamion: the reason xlibs didn't eepend on it is because xk-c was pre-depending on xlibs for a while
<ogra> it seems not to get pulled in by x-w-s-c
<daniels> ogra: no, and it will be fixed when a cd build contains xbase-clients -46
<ogra> or any of its deps
<Kamion> ogra: should be fixed in about fifteen minutes
<ogra> ah, great
<Kamion> on the archive, anyway
<Kamion> I'll wait for a CD rebuild until we have sessreg, then I can do the whole lot at once
<daniels> yeah
<doko> Kamion, daniels: I've only LANGUAGE=de_DE:de:en_GB:en , no LANG, no LC_*
<Kamion> $ sudo -u katie ./alicia.new slang1a-utf8 optional
<Kamion> I: Will change priority from required to optional
<Kamion> hooray
<ogra> pitti, main inclusion reports are only done for source packages, right ?
<pitti> ogra: yes; if not all debs are requested for main, this should be mentioned in the report
<ogra> sigh....
* ogra strikes half of the edubuntu main inclusion reports .... all kdeedu....
* pitti completes the AudioInfrastructure spec 
<Kamion> jdub: cool, if I'm reading this right, that xine-lib upload should be enough to chuck slang1 out of main entirely
<daniels> right, so xbase-clients and xutils are now entirely installable here
<Kamion> daniels: the xserver-xorg/amd64 one seems to be depending on -driver-atimisc when it isn't built
<Kamion> oh, -ati provides it
<Kamion> I'll reboot into an amd64 system and test
<daniels> you're right that it probably shouldn't dep -atimisc though, just -ati
<doko> seb128: gnome-menus has a python SyntaxWarning
<seb128> doko: I've noticed thankis
<jdub> Kamion: YAY!
<madduck> anyone seen Keybuk?
<doko> Mithrandir: 12893 and 13196 are still present with the new ia32-libs
<daniels> Kamion: Uploading via ftp sessreg_0.99.0-1_source.changes: done.
<daniels> Successfully uploaded packages.
<daniels> Not running dinstall.
<jdub> pitti: yay libnotify!
<pitti> jdub: ;-) just uploaded g-v-m that actually uses it now
<pitti> mvo wants to use it too
<Mithrandir> doko: which version of the fglrx driver?
<Kamion> daniels: hooray
<pitti> (or, I made him want to :-) )
<doko> Mithrandir: 6.8.0-8.14.14-0ubuntu3
<jdub> pitti: yeah, reacting to upload :)
<daniels> Kamion: (now watch it get rejected because I'm a complete meathead and screwed something up)
<Nafallo> daniels: xserver-xorg wants xserver-xorg-driver-v4l that is not installable on amd64 (-46).
<daniels> Nafallo: that's because it's waiting in binary NEW.  either that or I'm a meathead and screwed something up.
<janimo> when writing maininclusion wiki pages does every source package need a separate page or can they be put together if they are part of a larger meta?
<daniels> i'll take 'i'm a meathead and screwed something up' for $20, dennis
<janimo> I am thinking of xfce - same packager, same security record, same upstream
<Nafallo> daniels: hehe, oki. great job anyway! :-)
<janimo> I see it's done that way with koffice
* Mithrandir grumbles at whoever wrote the divert code for xorg-driver-fglrx
<Kamion> daniels: source looked fine to me anyway, processed
<daniels> janimo: koffice is a single source package
<Kamion> daniels: you can't end up with just one binary from a source package in NEW, it's all or nothing ...
<daniels> Mithrandir: the dude who did it for debian ... flavio?
<janimo> I see it depends on kivio & co 
<janimo> aren't those implicitely requested by that page?
<Mithrandir> doko: can you remove the xorg-driver-fglrx then add it again and see if it solves the problem?
<Lathiat> what is with kde and big fat source packages
<janimo> kivio,kword,krita,kspread are all built from same source?hmm, ok
<daniels> yes
<janimo> so returning to my question separate pages for separate source pkgs? (about a dozen)
<hmrocha> daniels, i upgraded to the last breezy, my keyboard is working again
<daniels> Kamion: thanks for shoving it through.  i'm going to go pass out on the couch or some shit.
<janimo> daniels, btw are there already known screenblack issues with libvgahw or should I file a bug? Using trident
<Mithrandir> Riddell: if you want to have ia32-libs-kde you need to have a kde which doesn't fall over if you look at it. :-/
<janimo> I saw debian had some miscompilation problem on that module a while back
<_d4vid> play Sido - Fuffies Im Club.mp3
<doko> Mithrandir: no, only if I deinstall the driver, make the ia32-libs update, and then reinstall the driver
<Mithrandir> doko: ok, that's right.  The driver is broken and should be fixed, then.
<Mithrandir> doko: I can do that, but it looked right from the first skim
<doko> Mithrandir: ok, not that important, doesn't effect the buildds
<Mithrandir> Riddell: ping?
<DanielN> seb128, ping
<seb128> DanielN: pong
<DanielN> did you tried the published patch on gnome bugzilla? (the keyboard thing)
<seb128> nop
<seb128> what bug is that? the crasher when adding new layout?
<Amaranth> *boggle*
<Amaranth> python2.4-apt build-deps on python2.3 and python2.3-dev
<seb128> lol
<DanielN> seb128, yes tat one
<seb128> it doesn't crash here
<seb128> so no point to try a patch
<DanielN> and the patch don't work... it says that only garbage is in the input file :)
<DanielN> so i can't test it too
<Mez> pitti: you still around?
<pitti> Mez: yes
<pitti> Mez: it's only 2pm here :-)
<Mez> pitti: I'm having lots and lots of problems with thunderbird and enigmail - It's crashing all over the place
<Mez> pitti: yeah, but you could have gone the pub for lunch or somehting
<Mithrandir> Mez: no, I haven't done guifications yet.
<Mez> Mithrandir, that's ok :D
<pitti> Kamion: there is a new upstream microrelease for notification-daemon (still universe, but scheduled for main); it incorporates my patches and fixes two other smal bugs; I reviewed the complete diff (not much). Permission to breaUVF?
<Riddell> Mithrandir: hi
<pitti> Mez: me too, ffox and moz crash, too since recently
<janimo> any way to tell apt-cache to only provide info about latest packages, not also on the ones installed
<Mez> pitti: I just realised I should be talking to infinity not you :D
<Mez> pitti, my FF is working fine, just my thunderbird sint
<Mithrandir> Riddell: hi, there you are.  It appears that the style loader in KDE becomes slightly unhappy when mixing 32 and 64 bit stuff.
<pitti> Mez: so far we don't have an official moz maintainer 
<Mez> pitti: fair enough :D but we need one... cause thunderbird is getting ridiculous
<pitti> agreed
<Mez> It's crashing neaar enough every time I try and send an email
<Mez> pitti: asac doesnt want to jump on the ubuntu train I presume?
<pitti> no idea
<Mez> pitti: I'm gonna try building 1.06-3 from debian
<Mez> see if that works any better
<pitti> would be interesting to compare the patches
<pitti> tbird has a proper patch system which makes this easy 
<Riddell> Mithrandir: hmm, not sure what to say to that.  style loader can get very tempremental about having been compiled with exact same version of gcc as qt, it should default back to a win95 style though
<janimo> pitti do you know if building a non-gnome enabled ff package would be troublesome?
<Mez> pitti: be interesting to see if the damn thing WORKS
<pitti> janimo: no, sorry
<Mithrandir> Riddell: ok, and you're fine with that, if ooo2-amd64 looks win95 style?
<Riddell> Mithrandir: what is 32 bit and what is 64 bit here?
<Mithrandir> Riddell: ooo2 is 32 bit, rest of the system is 64 bit.
<Mithrandir> that is ooo2 and any libs it needs.
<Riddell> Mithrandir: so qt and kdelibs are 32 bit?
<Mithrandir> they exist in both 32 and 64 bit versions, yes
<Mithrandir> elmo: please nuke the ia32-libs-kde 1 upload, it broke.
<Riddell> Mithrandir: which style are you set to use?
<Mithrandir> Riddell: no idea, I just installed kubuntu-desktop, made a test user and logged in in "KDE" through gdm.
<seb128> pitti: libnotify is main now?
<pitti> seb128: I added inclusion reports and g-v-m depends on it
<Riddell> Mithrandir: you need a version of qt, kdelibs and kde-style-lipstik all compiled with the same gcc version (and presumably all 32 bit)
<pitti> seb128: gnome-power and update-notifer want it, too
<seb128> pitti: k, so I can make gnome-applets using it now?
<pitti> yes
<seb128> cool, you rock
* seb128 hugs pitti
<pitti> hehe :-)
<pitti> seb128: upstream fixed n-d upstream now
<Mithrandir> Riddell: ok, and if I put anything kde-style-lipstik needs in /usr/lib32 instead of /usr/lib, it'll work?
<Riddell> Mithrandir: in theory, yes
<janimo> elmo, please sync ecosconfig has the correct wx2.4 depends in debian, thanks
<Mithrandir> Riddell: ok, let's see if we can make this pig fly, then.
<pef> hello
<Kamion> pitti: yes, that's fine
<seb128> can anybody try what keycode he gets for "volume down" with the gnome keyboard stuff?
<seb128> and for "media"
<Lathiat> 0xae here
<seb128> thanks
<seb128> same here
<Lathiat> dell inspiron laptop
<paolo> seb128, how do you bind them?
<seb128> mjg59: is "volume_down     0xa3" a typo? Seems to be 0xae
<Lathiat> theres a list of some on the wiki
<Lathiat> seb128: its hardware dependant..
<seb128> Lathiat: https://bugzilla.ubuntu.com/show_bug.cgi?id=13050
<seb128> Lathiat: are you sure?
<Lathiat> seb128: yes, while many may share similarities, it varies wildly
<Lathiat> look at one of th ekeyboard packages
<seb128> Lathiat: so it doesn't make sense to put defaults?
<Lathiat> seb128: you could try and find the "most common"
<seb128> how?
<Lathiat> get a list of various keycodes
<Mithrandir> Riddell: that was a theory.  It didn't appear to hold.
<Lathiat> try find similarities
<Lathiat> best way to do that
<seb128> Lathiat: very funny
<Lathiat> is to get one of the other shortcut packages
<Lathiat> which have definitions for lots of keyboards
<Lathiat> im trying to find one
<Lathiat> lieankd, hotkeys
<Lathiat> *lineakd, hotkeys
<Lathiat> fortunately mine matches that list apart from 0xa3
<seb128> same here
<Lathiat> i can tell you what my two normal keyboards have later this week
<mjg59> seb128: Looks like it, yes
<mjg59> Sorry, my mistake
<seb128> np, don't worry
<Lathiat> it'd rock if the volume buttons worked in gdm. :)
<Lathiat> or there was a mute button, or something
<Lathiat> for like, logging in in a lecture
<mjg59> Lathiat: The idea is to use hotkey-setup to map other keyboards to the "standard" (read "Microsoft") mappings
<Lathiat> mjg59: ah cool
<seb128> mjg59: what key is "music"?
<paolo> Here 0xae matches volum down.
<seb128> I've a "media" key "0xed" here
<mjg59> seb128: Hrm. Probably launch music player.
<seb128> mjg59: no, but the key .. is that a different of "media"? 
<seb128> my keyboard has few multimedia keys
<mjg59> seb128: Unsure
<rob^^^> that reminds me, Ive got a couple of keys that aren't recognized for binding purposes on my keyboard
<rob^^^> in the config utility, if I press it, it just sits there waiting for me to press a key
<seb128> mjg59: k, let's say the media is different from music 
<rob^^^> I think calculator, logoff, and sleep but im in OS X for now...
<Riddell> Mithrandir: what does this give you `strings /usr/lib/kde3/plugins/styles/lipstik.so | grep -i build`
<Riddell> s/lib/lib32/ presumably
<rob^^^> my keyboard does have both "My Music" and "Media" keys
<seb128> mjg59: k, I'm uploading the package
<mjg59> seb128: Rock, thanks
<seb128> rob^^^: is music "0xbc"?
<seb128> mjg59: np, thank you for the list
<rob^^^> seb: I can check, but I'd need to reboot. Is that okay?
<seb128> rob^^^: don't bother
<rob^^^> "Microsoft Wireless 
<seb128> rob^^^: the value is probably fine, I've uploaded with it ... we can fix it with an another version if somebody notice an issue
<rob^^^> err "Microsoft Wireless Natural MultiMedia Keyboard" (accidentally hit enter turning it over)
<rob^^^> (btw, it's a good keyboard)
<Lathiat> ugh those natural stupid pos
<rob^^^> I'v been toying about trying to hack up to cheap ergonomic keyboards to create to independent bluetooth keyboard halfs
<rob^^^> Natural is good. I'm mad they don't make a USB natural anymore though
<rob^^^> also you can get em for <$20, so thats a plus
<sladen> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html and http://www.nirvani.net/docs/Microsoft_natural_multimedia_keyboard_scancodes.html 
<rob^^^> why were sleep and friends not being assigned then? Are those in a reserved range or something?
<rob^^^> btw, there are a bunch of xml files in /System/Library/Keyboard\ Layouts on 10.4 that might prove helpful to someone
<rob^^^> can't assign those keys in OS X either
<rob^^^> http://developer.apple.com/technotes/tn2002/tn2056.html has more info
<Lathiat> yeh lineakd has similar
<Lathiat> and hotkeys
<Kamion> oh, bugger
<Kamion> libdps1 was only built from xfree86, and is now removed
<Kamion> but libmagick6 depends on it
<lu|sleep> could someone approve my non-member post to ubuntu-devel@ from last night?
<Kamion> seb128: could you please rebuild gnome-applets and gnome-system-monitor against libwnck18?
<ogra> lu|sleep, try to wake up jdub or get mako to do it
<lu|sleep> they are the only two moderators? OK.
* lu|sleep kicks mako
* lu|sleep kicks jdub, even though it is 6:22 AM where he is
<lu|sleep> mako should be awake, he has no excuse ;)
<ogra> heh
<rob^^^> some of these mails from -devel are rather sad "if we remove the workspace switcher app from the default panel there will be no reason for anyone to use Ubuntu! It will be Windows!"
<Amaranth> jdub is still on the west coast?
<seb128> Kamion: sure
<lu|sleep> Amaranth: LWE DF
<lu|sleep> s/DF/SF?
<lu|sleep> s/DF/SF/
<Amaranth> whatever you just said
<lu|sleep> he is at linux world expo san francisco
<mako> lu|sleep: hey
<mako> lu|sleep: i am awake.. but still pre-coffee
<lu|sleep> mako: I have a perfect task for someone not yet sentient
<lu|sleep> mako: I emailed ubuntu-devel last night,but am not subscribed; could you pull my email out of the queue?
<mako> lu|sleep: sure.. what's your email?
<lu|sleep> luis.villa@gmail.com
<mako> lu|sleep: cool
<lu|sleep> subject 'breezy liveCD issues' I believe
<mako> lu|sleep: i'll approve all future email from you too
<mako> lu|sleep: why don't you subscribe
<mako> lu|sleep: you know you can subscribe and then select to not recieve mail
* mako looks puzzled
<lu|sleep> oh, hrm, had forgotten about that option
<mako> well, it's a bit, er, counterintuitive
* lu|sleep generally needs to be on less *-devel* lists
<mako> that tends to be a smart option
<mako> ubuntu-devel is better than most
<mako> i've not followed debian-devel actively in a long time
<lu|sleep> it still looks pretty high traffic, though admittedly traffic I'm curious about
<rob^^^> lu: I dont have a problem with it, the key is to have your filters set up right to et it out of your inbox
<rob^^^> I still haven't changed my subscription mode to devel from digest though
<lu|sleep> rob^^^: I won't read it, and I don't like being on lists I don't read
<lu|sleep> no matter how well filtered it is
<Kamion> seb128: thanks. that's two of the three ubuntu-desktop uninstallables, and I'm fixing the other one now
<lu|sleep> (and I don't really believe in filters, either, except for bugmail, since it again leads to lists that don't get read)
<Lathiat> hrm
<Lathiat> i filter things
<Lathiat> makes it easy to look for specific things
<Lathiat> i dont really care to read all mail to the lists im on
<lu|sleep> if you need filtering to look for specific things, that means your mail software has poor searching :)
<Lathiat> i just pick things out that look relevant or interesting, and if someone mentions something i can pull it up later
<Lathiat> lu|sleep: no it means i already have all my lists split out, no need to setup a bunch of views or searches or whatever and then i can easily, on either mutt or evolution or thunderbird or webmail read through what i want
<Lathiat> (i read my mail with imap)
<mako> lu|sleep: cool, message approved
<Mithrandir> Riddell: buildkey=i686 Linux g++-4.* full-config
<lu|sleep> mako: thanks
<Riddell> Mithrandir: and `strings /usr/lib32/libqt-mt.so | grep i686`
<Mithrandir> Riddell: i686 Linux g++-4.* full-config
<Mithrandir> Riddell: that's not the problem, it doesn't complain, but it doesn't work either.
<Mithrandir> Riddell: it complained before
<Riddell> Mithrandir: so its still defaulting to win95 style?
<Mithrandir> Riddell: yes
<Riddell> Mithrandir: try rm -r ~/.kde ~/.kderc ~/.qt  and then launching openoffice
<pvanhoof> how secure would it be if I upgrade my breezy today? will xserver still work? :)
<pvanhoof> or is the xserver packager dude still not finished with his changes?
<pvanhoof> and/or how "unfinished" is it?
<pvanhoof> -- if I can get it working without having to recompile an X11 server/implementation, it's okay --
<Kamion> a few things are uninstallable and are being worked on, but it's mostly fine
<pvanhoof> Kamion, aha ok. But it's not "important" things today?
<pvanhoof> so I'll get my X environment up and running?
<Mithrandir> Riddell: it's a fresh user.
<pvanhoof> A few weeks ago I first had to fix a few xfonts problems .. I can manage such problems :p
<pvanhoof> but if the x package this time removes all bins in my /usr/bin/X11 :)
<Kamion> pvanhoof: nothing big, no
<pvanhoof> that wouldn't be cool
<pvanhoof> ok
<Riddell> Mithrandir: if you start kcontrol in appearance and themes->styles what is available?
<pvanhoof> going to upgrade the x-* packages tomorrow then ..
<pvanhoof> :)
<Kamion> pvanhoof: you might have to do a second install pass to cope with a small file overwrite bug in xserver-xorg / xserver-xorg-core
<pvanhoof> Kamion, doable :
<pvanhoof> :)
<Kamion> but that's just "run apt-get dist-upgrade twice"
<pvanhoof> I'm atm installing some of the trivial upgrades .. like the gstreamer ones etcetera :)
<pvanhoof> you guys have been working hard for the last three/four weeks :)
<pvanhoof> lol
<Mithrandir> Riddell: loads, lipstik is the chosen one.
<Mithrandir> Riddell: and, it appears it doesn't open anything matching lib32, but it's kinda hard to see because strace is icky
<Riddell> Mithrandir: try setting to plastik and see if openoffice loads with that
* infinity sobs quietly into his hands after watching glibc build forever, fail and making a 1-line change to fix it.
<Mithrandir> Riddell: hmm, it did then just complain about the buildstring.
<Mithrandir> Riddell: I'll hack around it.
<pitti_> seb128: do you know which part of gnome starts esd with the session?
<pitti_> seb128: I would like to change esd to autospawn by default, but the esd started by gnome session does not time out automatically
<Riddell> Mithrandir: what sort of hack?
<Mithrandir> Riddell: override open, I think.
<Mithrandir> similar to the pangohack in -gtk
<seb128> pitti_: gnome-session starts it
<seb128> pitti_: have you changed the autospawn key for /etc/esound/esd.conf ?
<pitti_> seb128: yes, and if I kill esd, then the following spawned esds work fine
<pitti_> seb128: the manpage says that autospawn is not recommended for sound events
<pitti_> seb128: but without autospawn I have a dilemma
<pitti_> seb128: if I remove the default device, esd still has an open connection to it, and thus the module is not unloaded and I don't get a hotplug notification
<pitti_> seb128: after I kill esd, then the modules are freed, and the device disappears
<pitti_> seb128: but I can't react to a removed device wihtout any hotplug notification
<pitti_> seb128: polypaudio solves this, but it's too late for breezy
<pitti_> seb128: ah, I think I know what to change, nevermind
<seb128> pitti_: what was it?
<sivang> jamesh: any news about the lib?
<seb128> sivang: did you send it? I didn't get the mail
<jbailey> infinity: Eh?  What happened?
<BenC> anyone know how to get back the ctrl+alt+Fn behavior in breezy's X?
<BenC> doesn't let me switch back to a vt like it should
<mdke> you need to sort out your xkb probably
<mdke> see this thread: http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/009421.html
<BenC> thanks
<Kamion> BenC: a dist-upgrade should sort it out, too
<Kamion> as of the last couple of hours
<BenC> ok
<BenC> yeah, that works now
<john6000> hello i have a suggestion
<john6000> in the install can you have a choice of either GRUB or lilo
<john6000> it would help everyone a lot
<HrdwrBoB>  the average user doesn't know or care
<john6000> but think of the advantages not disadvantages
<mdke> you have to think of both
<john6000> ok maybe you do
<john6000> you stick with your 0.8 grub even thow version 1 was out well before ubuntu 5.04 so why didnt you just use that?
<Kamion> I've sorted out john6000 in /query
<skora> nice.
<skora> now he's trying to give out incorrect info in the main channel 
* skora sighs
<chmj> shackan, ping 
<shackan> chmj, boing
<pitti> have to leave early today, cu tomorrow!
<bddebian> Heya
<Mithrandir> jbailey: any idea why I seem unable to override libc functions in an LD_PRELOADed object?
<doko> ouch, dpkg segfaults on the amd64 buildd as well ...
<\sh> doko: yes...but this is an old symptom...I reported that last week?
<WaterSevenUb> is anyone here using firestarter? I need to confirm a bug... in outbound connection events tab, click with the right button of the mouse. In my case, appears the same options as in an inbound event.
<WaterSevenUb> at least using a translated firestarter.. not sure if the same happens in pure english. In other words, select "outbound event" - "select with right button of the mouse" , compare the options with those of an "inbound event"
<WaterSevenUb> oops.. breezy is universe...
<carstenh> WaterSevenUb: LC_MESSAGES=C firestarter should start it in english
<mvo> seb128: do you know notification-daemon upstream? are they available on irc?
<koke> mvo: isn't it #galago? or it's another different thing?
<mvo> koke: I think that's it, thanks
<Kamion> damn, dpkg segfaults on the amd64 buildd are going to make my partman->partman-base transition painful
<Kamion> jbailey: does initramfs-tools 0.17 fix the install problem I reported?
<Kamion> jbailey: I need to make base-installer deal with initramfs-tools all of a sudden, so I need to be able to install it from scratch ;-)
<jbailey> Kamion: Dunno. Where's the report?
<jbailey> =)
<jbailey> Sorry, I'm not up on all my email atm.
<Kamion> #13334
<Kamion> (also #13335, less important)
<jbailey> 13334 is fixed, yes.
<Kamion> ah, you ship initramfs.conf but the sed hit mkinitramfs.conf
<Kamion> I assume initramfs.conf is right
<jbailey> Yup. =)
<jbailey> Fixed in 0.17
<jbailey> 13335 isn't, but I  hadn't hit that one.  Hmm
<Kamion> ok, will hack up something in base-installer for that
<jbailey> I usually drop a blank modules file in at upgrade time, but I suppose the user could delete it.
<jbailey> Kamion: Thanks! =)
<Kamion> jbailey: is there any equivalent of initrd-tools' DELAY in initramfs-tools
<Kamion> ?
<jbailey> Kamion: No.  If you want to break, just add 'break' to the kernel command line.
<jbailey> Kamion: Do you need a delay setting?
<Kamion> no, it's just that base-installer was setting DELAY=0 in mkinitrd.conf and I wanted to check the equivalent
<jbailey> Ah, makes sense.
<Kamion> it also sets ROOT=
<Kamion> should I omit that too?
<jbailey> Hmm
<jbailey> I wonder if it's ever the right thing to have it in the initramfs instead of the kernel command line.
<doko> Mithrandir: OOo2 1ubuntu8 should look in /usr/lib32 first
<seb128> mvo: ChipX86 on #gnome-hackers on the GNOME IRC ... why ?
<Kamion> d-i arranges for it to be on the kernel command line too; if that's enough, that's fine
<paolo> To the person mantaining Xorg: http://paste.ubuntulinux.nl/1111
<Kamion> paolo: I'm guessing daniels has gone to bed
<mdz> ogra: if you're having problems with the ldm password thing and using echo fixes it, you're encountering a unionfs bug
<mdz> ogra: the latest ltsp should worka round it
<ogra> great
<paolo> Kamion, ouch!  This is gonna be a problem, I think.
<Kamion> paolo: I'm checking now, if it's easy I'll release a quick bugfix
<paolo> Kamion, you rock.
<ogra> mdz, i have a themed version of ldm running over here... and fixed the cursors a bit last night... building a mousetrap for the window will get a bit trickier...
<madduck> mdz: did you see James Blackwell's post to the deity list?
<mdz> madduck: no
<madduck> mdz: if you have a minute...
<mdz> madduck: I am working
<madduck> mdz: it's not irrelevant. but take your time...
<madduck> http://lists.debian.org/deity/2005/08/msg00087.html
<mayco> the new xorg package gives an erro when installing: internal error: auto_answer() called with wrong number of arguments: db_input low xserver-xorg/config/write_files_section
<mayco> should I file a bug?
<madduck> mdz: i am just not sure that this is in accordance with bzr and hct plans.
<Kamion> mayco: paolo just mentioned the same thing, I'm investigating now
<mayco> okay
<Kamion> madduck: James Blackwell is a Canonical employee; it seems unlikely that it would be wildly out of step
<madduck> ok. i did not know. excellent.
<mdz> madduck: Bazaar 2 = bzr
<madduck> so now there is bzr, baz2, and hct. how the heck to make sense out of all those? :)
<madduck> mdz: then it's curious why James didn't just say so.
<Kamion> baz is converging with bzr
<madduck> that's what i thought.
<mdz> madduck: that would be a question for jblack, or #bazaar, or a bazaar mailing list
<fabbione> hey guys
<fabbione> enjoy the last days without me :)
* fabbione will be back soon to break the bones out of your computers
* Amaranth gets the gun
<janimo> hey fabbione, a question:
<janimo> is providing vmlinux (no full debug) possible for breezy kernel images?
<janimo> needed for oprofile 
<fabbione> janimo: i am in vac.. don't trust my answers.. my brain is fuly disconnected :)
<janimo> it's not the 150M scary package that's been rumored
<fabbione> janimo: if i will remember.. i might..
<janimo> I am not trusting them ;)
<janimo> cool, if I can I'll help
<janimo> have a good vac
<fabbione> janimo: you might want to look into kernel package. it's the one creating the .debs for the -images-
<janimo> ok I will, I just wanted to know if it would be ok or was there a decision against it
<fabbione> it shouldn't be an issue...
<janimo> I see the bug on debian requesting vmlinux ended unconclusively
<fabbione> but if you can gimme a patch, it will be faster
<janimo> ok then I put it on my TODO ;)
<fabbione> thanks
<bddebian> mako is IT? :)
<robitaille> "the and a mako it mako"?  
<mako> robitaille: watch planet in like 10 minutes .. you'll see
<jbailey> mako: Quick, everyone ddos mako's blog with the refresh button. =)
<mako> jbailey: it won't take all of you :)
<dieman> so
<mdz> lamont-away,infinity: livefs build on terranova seems busted (stale lockfile?)
<dieman> how long do old releases stay in the archive?
<dieman> im trying to size out new disks for a machine to move our mirror over to
<mattyJ> is mono currently broken in breezy (just want to make sure its not my setup)
<infinito> is there any way to make a pkg depend on another source pkg to build?
<fabbione> infinito: no
<infinito> fabbione: ummm, latest mail-notification needs evolution sources to compile an evo plugin...
<fabbione> infinito: are you sure you are not looking for something like evolution-dev ?
<Treenaks> Kamion: any news from the sysfs/grep/sed front?
<mdz> elmo: could you confirm that no live build is running on terranova, and upon confirmation, rm -f /home/buildd/buildLiveCD.lock ?
<infinito> fabbione: i think so... while compiling it looks for some .h files which seems not to be included on evolution-dev
<paolo> Kamion, what do you suggest?  If I power off the laptop, will xorg be broken when I turn it up again?  I mean, should I wait for the fix or it is not crucial?
<fabbione> infinito: it depends what it is looking for.. the includes might a) not shipped b) not be there anymore c) in other -dev packages
<infinito> fabbione: i've looked for the files on packages.ubuntu.com search and they seem not to be included in any pkg
<fabbione> infinito: than the best thing to do is to talk with the evo maintainer and see why they are not included. Are you 100% sure they come from evo source?
* sivang -> back
<sivang> lol
<Kamion> paolo: quick fix: edit /var/lib/dpkg/info/xserver-xorg.config as root, go to the very end, look for the pair of 'auto_answer db_input' lines, change '||' into 'true ||' on each of those two lines, and run 'dpkg --configure -a'
<infinito> fabbione: the files are evolution-2.2.1.1/mail/em-event.h and 3 more in this folder of evo source
<fabbione> infinito: than talk to the evo maintainer.
<fabbione> these files might not be shipped because they are not supposed to expose private evo interfaces
<Kamion> xorg fix uploading, anyway
<Kamion> infinito: packages.ubuntu.com isn't always up to date (not its fault, we only generate the Contents files it needs a bit irregularly)
<paolo> Kamion, do you mean the "true" part of this?  auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xorg/autodetect_video_card "true"
<Kamion> paolo: wrong line
<Kamion> paolo: you're looking for xserver-xorg/config/write_files_section and xserver-xorg/config/write_dri_section
<Kamion> but "true" in that position, yes
<infinito> Kamion: is there any way to look for a file between packages other than this?
<Kamion> infinito: not really
<paolo> auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xorg/autodetect_keyboard "$AUTODETECT_KB" || debug_echo "db_input xserver-xorg/autodetect_keyboard" ?
<paolo> Kamion, I think line numbers would be better :-)
<Kamion> paolo: yeah but deriving those from the source was tricky, and I was in a hurry :)
<Kamion> paolo: it's *right* at the end
<Kamion> paolo: lines 2048 and 2049
<paolo> 2048 is empty, 2049 is #vim:set ai et sts=2 sw=2 tw=80
<mvo> Kamion: permission to upload notification-daemon? it fixes a bug in the arrow placement when the target x-coordinate is set to the far right corner
<elmo> mdz: done
<Kamion> mvo: yes
<paolo> Kamion, how is the fix going to reach local apt?
<Kamion> paolo: meh, it might be somewhere else while partially configured. I've uploaded a fix, it's building
<mdz> elmo: thanks much
<paolo> Kamion, the mail hit breezy-change, good!
<paolo> changes, even
<pef> bye !
<pef> !bye
<paolo> To anybody on breezy - does xfont-terminus work for you?
<robitaille> mako... now your nick-changing act makes sense :)    
<mako> robitaille: it all makes sense eventually
<mdz> Kamion: thanks for the xorg fix; just noticed that it broke the livefs build
<mdz>     if $FANCYTTY; then
<mdz> that isn't valid posix sh, is it?
<mdz> where $FANCYTTY is 1 or 0
<Kamion> no; if $FANCYTTY were : or false, it would be
<Kamion> (idiom for doing booleans in shell without having to fork [)
<shaya> /usr/include/evolution-2.4/mail/mail-component.h:31:28: error: Evolution-Mail.h: No such file or directory
<shaya> seems to be a bug in evolution-dev package
<Kamion> mdz: for the purposes of UE review, does the installer team consist of more than me? :)
<Kamion> I'm just worried about being a blocker, considering my busyness level right now
<mdz> Kamion: that shell snippet was from the new lsb in experimental which attempts to merge our changes
<mdz> but as far as I can tell it has no chance of working at all in its current form
<Kamion> mdz: didn't lsb in unstable take our lsb-base ages ago?
<mdz> Kamion: hmm, so it did.  though we still have a diff relative to unstable, and experimental makes other changes
<mdz> oh, the version in experimental is older than unstable
<mdz> unstable seems to fix the syntax
<Kamion> indeed, should be NVIU'ed
<Kamion> lamont-away,infinity: please give-back partman-base once the chroot is fixed; that's a somewhat delicate transition there and I want to get it through
<Kamion> lamont-away,infinity: er, on amd64, that is
<Mithrandir> doko: ok, is it uploaded?
<Kamion> jbailey: just as a thought, would it be worth attempting to fetch RESUME from mkinitrd.conf in initramfs-tools' postinst?
<Kamion> migration, and all that
<marcin> hi all
<marcin> I got a question about general packaging procedure
<marcin> do you guys got some tools to build packages recursively?
<bddebian> Oh no, he's back :-)
<marcin> bddebian: hi :D
<Kamion> packages don't contain other packages, so there's no concept of recursion involved
<doko> Mithrandir: uploaded, but the build did fail ... the uno bridge now fails to build ...
<marcin> Kamion: right but I mean something to build a bunch of packages at once
<Kamion> you could try pbuilder
<Kamion> we use wanna-build/buildd/sbuild, but it's much more effort to set up; pbuilder is more designed for personal use
<Mithrandir> doko: ok, can you prod me once a working version is in the archive?
<marcin> I need to build a lot (about 400) packages with simmilar content
<Kamion> normally such things would all be built from a single source package
<Mithrandir> elmo: can you nuke the b0rked ia32-libs-kde upload for me, please?
<Kamion> if that is not possible, you're mostly on your own because that's quite an unusual thing to do
<Kamion> Mithrandir: I've done so
<Kamion> assuming you meant the orphaned .dsc in queue/unchecked/
<Mithrandir> Kamion: yes, thanks.
<marcin> Kamion: hmmm and how you guys synchronize your packages with debian repositories?
<marcin> Kamion: you do all 'manually' ?
<Mithrandir> marcin: no, it's usually done automatically, if we don't have any changes wrt the debian version
<Kamion> if we do have changes, there's a tool called merge-o-matic that files bugs against the packages for us with suggested merge output
<marcin> Mithrandir: you got some scripts or specific tools to perform this synchronization?
<Kamion> developers then review that output, tweak as necessary (or sometimes redo from scratch) and upload
<Kamion> but it's not rocket science, it's just three-way diff and patch application
<Mithrandir> marcin: yes, there's a tool which compares.  I don't think it's available, but it should be fairly trivial to write one which does the same.  Note that the merge-o-matic is another piece of machinery which is more complicated.
<Mithrandir> Kamion: and some attempts at extraction of different parts, AIUI
<marcin> Mithrandir: hmmm what machinery?
<Mithrandir> marcin: merge-o-matic, as Kamion just described
<Kamion> merge output publication, bugzilla interaction, that sort of thing
<Kamion> it's all fairly boring scriptage I think
<paolo> http://paste.ubuntulinux.nl/1115 do you know what it could be?  (I'm on an USB2 external drive breezy installation, I use initrd to load the usb modules)
<Kamion> paolo: the kernel just switched from initrd to initramfs, and base-installer doesn't support that yet. I'm working on it at this very moment.
<Kamion> but it will take me some hours
<paolo> Kamion, nice.  I can't reboot yet, so :-)
<Kamion> paolo: oh, is this in the middle of a fresh installation, or are you upgrading?
<paolo> The former.  I'm keeping it upgraded to the bleeding edge because I need this terminus font and I hope for xorg eating it at some point.
<Kamion> you're keeping it upgraded by repeatedly reinstalling? :)
<paolo> no no :-D  update/upgrade/dist-upgrade
<Kamion> so then you mean "the latter", not "the former"
<paolo> Sorry I misunderstood previously - I mean it's not an upgrade from hoary or something.
<Kamion> right, I'm asking whether you're actually in the installer right now
<paolo> Nope, the system is installed and I have rebooted it before this last xorg upgrades.
<Kamion> ok, disregard what I said, then
<Kamion> is initramfs-tools installed?
<paolo> Nope.
<Kamion> Hah, somebody forgot to update linux-image-*'s dependencies.
<paolo> I like being helpful :-)
<Kamion> jbailey: ^-- linux-image-*'s depends needs to change from initrd-tools to initramfs-tools
<paolo> Kamion, is there any doc about it?  I have found some HOWTO on ubuntuforums about how to make this external USB2 harddrive installation work.
<paolo> But it only talked about mkinitrd.
<mdz> Kamion: didn't it?
<mdz> oh, it didn't
<mdz> I had it installed already
<Kamion> paolo: it's very new, and I haven't even had time to look at it much myself yet
<mdz> Kamion: why should base-installer need to care, if the dependencies are correct?
<Kamion> mdz: because base-installer needs to put the resume partition into initramfs.conf
<mdz> ah
<Kamion> mdz: in order to do that, it first has to install mkinitramfs-tools
<Kamion> (so that the template config file is there)
<mdz> I thought initramfs-tools did that itself
<Kamion> it tries, but it doesn't have as much information
<Kamion> well, theoretically at least. in practice the code is similar at the moment, but I can easily imagine partman hooks to let the user identify the resume partition
<Kamion> perhaps in automatic installs
<Kamion> base-installer's fiddling is more relevant for initrd-tools really, but at the very least I'd have to disable it
<Kamion> and while I'm there anyway, it's not very difficult to make it do the analogous initramfs things
<mdz> for some reason I thought /etc/exports wasn't a conffile, but it is.  I'll need to do something about that for ltsp
* mdz wonders how evil /etc/exports.d would be considered
<mdke> Simira, nice work on the Tshirts :D
<mdz> argh, livefs builds still broken
<mdz> Setting up ubuntu-artwork (0.2.24-1) ...
<mdz> update-alternatives: unable to make /usr/X11R6/lib/X11/icons/default/index.theme.dpkg-tmp a symlink to /etc/alternatives/x-cursor-theme: No such file or directory
<paolo> Kamion, is there a specific reason because there is no "xfontsel" in every xorg released today?
<Kamion> paolo: probably still being modularised; the answer is the same for most missing binaries from xorg
<Simira> mdke: thanks :)
<paolo> Kamion, do you know how can I safely switch to the previous kernel?  So that I could reboot without messing with initramfs.
<Kamion> paolo: you can just install the initramfs-tools package and the kernel should then configure cleanly
<paolo> The following NEW packages will be installed:
<paolo>   busybox-cvs-initramfs initramfs-tools klibc-utils libklibc
<paolo> OK...
<Kamion>  yes
<mdke> Simira, do you envisage the thing becoming a fundraising initiative for Ubuntu?
<paolo> Kamion, http://paste.ubuntulinux.nl/1116  any clues about what it did?
<Kamion> mdz: looks like I should replace initrd-tools in the minimal seed with initramfs-tools, and bump initrd-tools out to supported?
<mdz> Kamion: why was initrd-tools seeded anyway?
<mdz> Kamion: I'm about to change the deps in l-s-2.6.12 unless you've already done it...
<Kamion> mdz: no, I haven't; possibly because we explicitly avoid considering the kernel packages in debootstrap, so it avoids confusion to seed their deps
<Kamion> paolo: interesting
<mdke> mjg59, around?
<Simira> mdke : I haven't really thought about it yet. I just provide t-shirts :p 
<Kamion> paolo: that will stop happening once the kernel image properly depends on initramfs-tools, because apt won't try to configure the kernel image while initramfs-tools is only unpacked as opposed to configured
<Kamion> paolo: nevertheless, it appears to have recovered successfully
<Kamion> paolo: (as I would expect)
<mdke> Simira, ok, but you must have thought about how much to charge right?
<paolo> Kamion, good - so are you saying it kept my configuration about initrd?
<Kamion> paolo: no, it's built an initramfs
<paolo> Kaloz, which I need to configure?
<Kamion> congratulations, you're a tester :)
<paolo> I'm very pleased to help - I hope it compensates the begging I did here :-)
<paolo> Furthermore I need the newer Gtk for my summer of code project, so messing with the bleeding edge was expected :-)
<Kamion> might want to check that your grub configuration refers to it properly
<Simira> mdke: sure. I take as little as possible, so it's mostly the cost of printing them and shipping. A little revenue goes to further t-shirt orders. If I'd make a webshop of it in time, a part will go back to Ubuntu.
<Kamion> actually, it should be fine
<paolo> initrd          /boot/initrd.img-2.6.12-6-386
<Kamion> I'm just rebooting my own test system now
<Kamion> yeah, that's actually an initramfs despite the name
<mdke> Simira, yeah, i reckon if Ubuntu was interested, you could charge a little more
<paolo> Cool.
<mdke> Simira, anyway, thanks a bunch for doing it
<Simira> :)
<Kamion> I get a ton of "sed: Unsupported comand I" on boot, but otherwise it seems fine
<paolo> What's wrong with sed.
<paolo> By the way, it's a good news.
<Kamion> nothing's wrong with sed
<paolo> Kamion, do you use any initrd customized options?
<Kamion> no
<paolo> OK.
<Kamion> udev is trying to use a GNU sed feature, which doesn't work with busybox
<Kamion> but it's only in cdsymlinks.sh, so it's cosmetic at that stage
<paolo> Hmm, udev here does strange things, too
<paolo> For example it does not create some devices like /dev/hda* and /dev/hdc* which are respectively the harddrive and the dvddrive of my laptop.
<eazel7> hi
<eazel7> is sessmgr package missing?
<mdz> mjg59: I whipped up an lsb init-functions which talks to usplash, but it looks like the fifo isn't there yet (on the real root)
<paolo> eazel7, I've all updated and it seems to not be there, is it a xorg one?
<eazel7> paolo yes
<eazel7> I updated at home and it was there everything was nice
<paolo> eazel7, it could be because of the modularization in act these days.
<eazel7> but now it's missing in the space again
<eazel7> lost in the space
<eazel7> yup... too modularized :-P
<paolo> Something is leaking, it will come.
<eazel7> paolo stop saying things like that
<eazel7> I think on sexual jokes :-P
<paolo> Missing? :-)
<Kamion> eazel7: sessmgr? do you mean sessreg?
<paolo> sessreg is there.
<eazel7> Kamion let me see
<eazel7> yup
<eazel7> sessreg
<eazel7> not here =(
<Kamion> sessreg is definitely there, I processed it this morning
<Kamion> if you're using a mirror other than archive.ubuntu.com, it may not have reached it yet
<eazel7> I've seen it at home
<eazel7> but now I'm at work and it disappeared =(
<paolo> eazel7, update, it's version 0.99.0-1
<eazel7> Kamion I was using ar.arch... when I got it, now I changed to archive.ubuntu.com and it disappeared in both
<eazel7> I've update a sec ago
<Kamion> $ ssh jackass sudo -u katie madison sessreg
<Kamion>    sessreg |   0.99.0-1 |        breezy | source, i386, ia64, powerpc
<Kamion> it's most definitely there.
<eazel7> don't know how to get it...
<eazel7> through the web page
<eazel7> it's a way, isn't it?
<Kamion> we've determined that it is not missing, so there's no development issue involved; please take the rest to #ubuntu
<eazel7> nope, it isn't
<paolo> * Update hardcoded initrd-tools dependencies to initramfs-tools
<mdz> paolo-changes?
* paolo changes
<paolo> Would you like a service like that?!
<Kamion> I'm fixing that udev warning spewage now; it's easily worked around
<paolo> Cool.
<mdke> during the install guide, my wifi network was brought up and worked perfectly, but it didn't give me a choice of various AP's around here, just plumped straight for mine. how did it know, and how come I didn't get given a choice?
<mdke> s/install guide/install process
<Seveas> mdke, pure black magic
* mdke nods
<ajmitch> it probably looked for the strongest signal
<mdke> that's what I figured, i just wanted to check
<ajmitch> or luck
<Kamion> it tries to do DHCP after association, to check
<mdke> yeah I saw that
<Kamion> and yeah, it just tries the blank essid
<Kamion> so probably strongest signal
<mdke> ah k
<Kamion> I'd like to improve that (bug #1242); but netcfg is a pig to work on
<Kamion> and I have no wireless cards that support scanning, annoyingly enough
<Kamion> and only one local AP for that matter
<mdke> well I only have one too, but there are a few closed networks around, i was just curious
<seb128> clearlooks is shipped by gnome-themes/gtk2-engines packages now, what is the correct way to make that ... just a Replaces on the previous package?
<seb128> or a Conflicts/Provides too?
<paolo> seb128, did you see the cairo issue we pointed out on #cairo with cworth?
<seb128> paolo: devhelp API?
<paolo> seb128, yup, the devhelp thing.
<seb128> I'm reading it atm
<paolo> Cool, thank you.
<seb128> paolo: what is basically the issue? We don't have libcairo-doc package?
<paolo> seb128, yes, no documentation is installed with libcairo1, nor with libcairo1-dev
<seb128> right
<seb128> Debian package has a -doc
<seb128> I've planned to sync with it but didn't come here yet
<paolo> seb128, also the cairo doc doesn't have a title, I don't know if the debian guys fixed it.
<seb128> not sure but that would be an upstream issue
<paolo> Yup, I notified them.
<paolo> I don't know how it goes for this kind of issues.
<paolo> seb128, if I could ask: it passed the announce for rhythmbox-0.9.0 but it isn't on the repos, is there a particular reason?
<seb128> mkdir .libs
<seb128> libtool: link: cannot find the library `/usr/lib/libdbus-1.la'
<seb128> 
<seb128> daniels !!!!!
<seb128> he keeps doing that
<seb128> dropping .la files and breaking other packages
<paolo> Argh :-)
<seb128> is somebody going to upload a hal package for that or should I do it?
<seb128>    * Remove *.la files from installation.
<seb128>      + Gross hack to remove dbus_bindings.{a,la} from python2.4-dbus.
<seb128> WTF
<seb128> Kamion, mdz: what is the right fix here? Changing dbus to install libdbus-1.la or doing a rebuild of other stuff to drop the .la mention?
* Kamion has no idea, I'm afraid
<seb128> k, all the stuff using hal are FTBFSing now
<seb128> thanks daniels
<elmo> seb128: dude, you are getting more bitter by the day
<elmo> I think soon you might wrap around, and become all happy and positive again ;P
<seb128> ah ah
<seb128> I'm not bitter :p
<seb128> I've just enough to do without having daniels making half of GNOME FTBFSing every week
<mdz> seb128: the .la file is supposed to be in a -dev package, right?
<seb128> mdz: the dbus upload has
<seb128>    * Remove *.la files from installation.
<seb128>      + Gross hack to remove dbus_bindings.{a,la} from python2.4-dbus.
<seb128> mdz: and the dropped the .la from the -dev too
<ogra> phew...
<seb128> but libhal.la mention it by example, which breaks the builds
<seb128> mdz: I guess the correct fix is to only drop the .la from the python dbus package?
<jbailey> Kamion: Yeah, that might work.  Right now I had been doing the same autodetection that the installer would do.
<mdz> seb128: I can understand removing it from the python package; that doesn't make sense.  but surely it should be in -dev
<seb128> mdz: k, I'm going to fix dbus then, thanks
<Kamion> jbailey: I think doing both would make sense
<jbailey> Yup
<Kamion> ok, udev upload fixing those warnings done, so re-mkinitramfs with that and all should be happy
<shaya> is anyone having a problem w/ initrd creation and new linux kernel?
<Kamion> shaya: install initramfs-tools
* jbailey looks to see where he missed specifying initramfs-tools
<Kamion> jbailey: mdz fixed it already
<shaya> missing dependecy?
<jbailey> Kamion, mdz: thanks.
<mdz> it should be building about now
<Kamion> shaya: right; there's a new kernel on its way
<mdz> -6.10
<shaya> would my old initrd have owrked?
<mdz> yes
<shaya> or would I have had to reboot to .10?
<shaya> ah
<shaya> so not hte biggest deal
<mdz> shaya: do you think it's at all feasible that the other change from http://www.fsl.cs.sunysb.edu/pipermail/unionfs-cvs/2005-August/000260.html broke things for me?
<mdz> it's either that, or some non-unionfs difference between our configurations, if you can't reproduce my bug
<Kamion> shaya: if you had the new linux-image-* unpacked, then configuring linux-image-* will fail initially, but then apt will retry after configuring initramfs-tools and all should be happy
<shaya> mdz: I made one line change and it worked
<shaya> yes
<shaya> everything's happy
<shaya> mdz: I guess it's possible the dentry.c change made some problems for you
<shaya> mdz: stick a printk() in that code to see if you're hitting it
<shaya> as it sort of would make sense
<shaya> as d_unhashed means unlinked
<shaya> and that's what bash is doing, unlinked file
<mdz> shaya: I'm going to try reverting to the same code you're using and see if that helps
<robertj> mdz: did you see my lowly post about whether workspace-switcher applet should remain on the default panel?
<shaya> mdz: in this case, it's not really the unionfs guys fault, this dentry revalidation is black magic, I've been looking for documentation about what it means, and havent found any
<mdz> robertj: no
<robertj> mdz: well err, that's pretty much the post...I've seen a few people lose apps on various virtual workspaces
<shaya> anyone here read long: ?
<shaya> login: that is
<robertj> mdz: basically I figure the people who need them can find them but the people who don't might not know how/be afraid to remove them
<mdz> robertj: as far as I'm concerned, that's a desktop team decision
<mdz> robertj: ->seb128
<robertj> oky
<seb128> I've not strong opinion on the topic but imho that's fine this way
<seb128> there is no real point to have an empty panel and it's quite useful
<robertj> it is useful but its bad if you don't know what your doing and manage to "lose your icons"
<seb128> next you will ask to configure with 1 desktop by default?
<robertj> yup
<seb128> there is other way than the applet to change desktop
<seb128> the real fix would be to set the number of desktop to 1
<paolo> Which automake/autoconf version do you suggest to install?  And why do you provide so many versions?
<seb128> because upstream provide those version
<robertj> yeah, I think I forgot to include that in my email, but yes, I'd think that would be needed as well
<seb128> robertj: that's not going to happen imho
<BenC> W: GPG error: http://bazaar.canonical.com ./ Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A817561ED2DFA262
<seb128> robertj: what you want is a linux with 0 feature so you are you sure users don't use something they may not know :)
<BenC> how do I get the pub key for bazaar release?
<robertj> seb128: I think the interface should be very plain by default
<seb128> paolo: I've 1.9 as default automake versionhere, works fine for GNOME
<robertj> that's why i'm against My Documents, My Music, My Whatever.
<seb128> robertj: you will not get any consensus on a such discussion imho
<seb128> that's basically why I've not replied to the thread
<robertj> Yeah, probably not. But it's a better way of doing things than having every application want to have itself on your panel and such.
<paolo> seb128, thanks.  OK works seamlessy for me too.
<seb128> you can try to go upstream, they will probably close it and maybe ping usability before
<paolo> seb128, about cairo "--enable-gtk-doc        use gtk-doc to build documentation default=no" that's probably the reason for the lack of documentation.
<seb128> paolo: I know why it lack it and the Debian package has a binary package for it, I just need to sync ... I'll do that after the colony CD from this week when uploading 0.9 and GTK 2.8
<seb128> paolo: thanks anyway :)
<mdz> shaya: still broken for me using 1.0.13 + the one-character fix
<shaya> hmm
<paolo> seb128, ok sorry.  Thank you, instead :-)
<shaya> weird
<seb128> paolo: no need to be sorry, don't worry :)
<mdz> shaya: are you using delete=whiteout?
<shaya> hmm
<shaya> no
<Kamion> BenC: it's /home/warthogs/archives/pqm@canonical.com.pub on chinstrap
<shaya> or not specifying
<shaya> let me see
<shaya> hmm
<shaya> this is funny
<shaya> mdz: sometime since I sent that message unionfs oopsed on me :)
<shaya> hit an assertion
<shaya> hmm, why are perl and perl5.8.7 hardlinks to each other?
<shaya> why is a hardlink better than a symlink (ala gcc)
<robertj> seb128: thanks for your suggestion. I sent it upstream at # 313167
<seb128> robertj: np
<Kamion> shaya: makes no particular difference in that case
<shaya> kamion: confused?
<shaya> oh
<shaya> perl
<shaya> sorry, lost focus
<kwa> join #ubuntu-motu
<sivang> seb128: did you hear from jamesh re lpint-bonobo ? (I sent him a link so he can review)
<seb128> no
<seb128> but you were supposed to send a mail to me and jamesh today no?
<sivang> I posted it on my web corner, and did it here, so I figured you'd notice (all the discussions were in this channel)
<seb128> nop, was quite busy and my IRC is not running when I'm not around
<seb128> I read some discussion
<seb128> but not pointer to a patch
<sivang> 10:19 < sivang> jamesh: ok, noted. pkg is here: http://muse.19inch.net/~sivan/lpint/lpint-bonnobo-0.0.tar.gz
#ubuntu-devel 2005-08-16
<seb128> k
<seb128> what UTC hour is that?
<sivang> seb128: probably where piware.de is located :) germany somewhere
<seb128> hum, k, I was already on IRC
<sivang> seb128: this was created with make distcheck, as jamesh instructed
<sivang> seb128: did you see my dead line extension email? (I mailed mdz, cc'd you) What do you think?
<seb128> I'm fine with a 2-3 days delay but ask mdz
<seb128> I keep patching other apps for the moment
<sivang> seb128: ok, that's cool. I'll ping him as well, btw gedit as an example patch is here: http://muse.19inch.net/~sivan/lpint/01_lpint_bonobo_src.patch
<seb128> I've read this one already 
<seb128> you put it on the wiki no?
<sivang> seb128: ah right :) I forgot
<seb128> hum, no, that's from IRC probably
<seb128> I don't get what you have listed on the wiki
<seb128> by example bug-buddy !?
<seb128> it has no menu
<sivang> seb128: remove it then, sorry, I guess that's are leftovers from my "about" boxes list that was moved here
<seb128> I've made a clear list, that's not a copy
<seb128> you have listed it ... anyway I'll clear it
<sivang> seb128: hmm, then maybe I added it, if I did I'm sorry. I really don't remember..:-/
<seb128> and what about all the applets? they don't have a menu neither
<seb128> you want to put that to the context menu?
<sivang> seb128: context menu being the one opened when you right click an applet?
<Burgundavia> mdz, thanks for the inkscape stuff. Sorry to be so nagging
<sivang> mdz: ping, did you get my email re lpint due date postpone?
<seb128> right
<sivang> seb128: then yes, doesn't it feel reasonable?
<mdz> sivang: yes, but what is the rationale?
<sivang> mdz: bonobo apps which I'd like to have done (+ the listed applets) which without it won't be ready, unless seb128 does it alone and finishes till tommorow :)
<seb128> there is not a lot of those, that's doable tomorrow
<seb128> if the lib is ready and jamesh push it with lpi sources
<sivang> okeydock, I don't mind at all. I just became too much busy at work this couple of days and that prevents me for helping out until next week :-(
<sivang> (begining sunday at weekend)
<sivang> seb128: actually are you sure you've seen http://muse.19inch.net/~sivan/lpint/01_lpint_bonobo_src.patch ? (it a new patch agains the lpint-bonobo lib)
<sivang> seb128: (it's not in the wiki)
<seb128> yeah
<seb128> you pointed it to jamesh today on this chan
<seb128> and I clicked on it
<sivang> seb128: ah ok :) just making sure, sorry for repeating myself
<seb128> np
<seb128> sivang: hum, did you read what I wrote yesterday about using launchpad-integration and not making a new source package?
<sivang> seb128: yes, ofcourse
<seb128> because your tarball seems to be a new source
<sivang> seb128: you mean use the same source for a couple of bin pakcages, make much sense 
<seb128> not a patch for lpi
<sivang> seb128: I thought that this sources can be included with the src pkg, and create several bin packages. also, why bonobo app need include the GTKUImanager stuff in the original lib? 
<sivang> seb128: that way only the relevant part is included in an app , and I use the launching callbacks so no code duplication
<sivang> seb128: (i.e. the code that lunches the browser at the right location)
<paolo> I don't mean to interrupt, but why isn't libgmp3 a real package?
<seb128> paolo: it has been rename to libgmp3c2 for the cpp transition
<seb128> sivang: "why bonobo app need include the GTKUImanager stuff in the original lib? " .. what do you mean?
<paolo> seb128, what could be done if a package relies on it, and doesn't install because of that?
<seb128> rebuild the package for the transition
<paolo> Aww, darcs take ages :-)  Thanks anyway.
<seb128> that means that the app and the libs are not built with the same gcc version
<Kamion> paolo: ping a MOTU and get them to rebuild it
<ajmitch> darcs is a special case because of ghc6 issues
<joefso> Did any of you guys ever ran ubuntu in UML?
<Kamion> ajmitch: ah
<mvo> Kamion: how do you feel about a upload of a update-notifier that uses libnotify too? pitti convinced me that it is a good way to get attention to the update
<paolo> Kamion, I'll try :-)
<seb128> mvo: gnome-applets uses it too now FYI :)
<mvo> seb128: it's nice and the notifications certainly draw attention :)
<Kamion> mvo: it sounds like an obvious thing for which to use libnotify, I'll admin
<Kamion> er, admit
<Kamion> discussion the other day indicated that update-notifier's icon often goes unnoticed, so I'd say yes, do it
<mvo> Kamion: thanks!
<Kamion> er, do we need notification-daemon in main?
<sivang> seb128: with the seperation, a Gtk app (glade, UIManager) is using the lib with only the funcs it needs, and a bonobo  apps will use their lib. Acutally jamesh suggested to make it a seperate lib (if I understood him correctly) to be able to seperate between the two from the pkging point of view. Won't it be easier to drop bonobo support that way? (trying to guess that what jamesh had in mind suggesting that)
<Kamion> shouldn't it be seeded or something?
<paolo> Kamion, they can't because other packages need fixing before :-(  Thanks for the hint anyway.
<seb128> sivang: I don't get what you say sorry
<seb128> $ ls lib
<seb128> callbacks.c  launchpad-integration.h  Makefile  Makefile.am  Makefile.in
<seb128> sivang: that's the launchpad-integration source from jamesh
<mvo> Kamion: pitti was taking care of it. IIRC he wanted to seed it and make it a recommend from ubuntu-desktop (so that people can remove it if they find it too anoying)
<sivang> seb128: maybe you can ping jamesh about it , sorry that I can't explain myself any better..:-/
<seb128> sivang: drop here a new callbacks-bonono.c instead of making a new source
<seb128> sivang: I'll
<sivang> seb128: it can be done, acutally with only modification of the .h file
<seb128> sivang: he probably meant to do a liblaunchpad-integration-bonobo.so and a libbonobo-integration-gtk.so
<Kamion> mvo: (a) that won't make the installer install it by default, because base-config deliberately runs aptitude --without-recommends; (b) I thought that was part of PackageSelection and deferred
<seb128> sivang: but using launchpad-integration current source, not by doing a new one
<mvo> Kamion: I don't know, sorry. but if gnome-applets use libnotify now too, it would make sense to have it in main, wouldn't it? 
<Kamion> mvo: libnotify's in main, notification-daemon isn't
<Kamion> I agree the latter probably should be
<sivang> seb128: ok, it has no effect that I used a "new" source, it was just easier for me to work on it that way. my callbacks.c (which uses his callbacks.c) code can be dropped into callbacks-bonono.c. but how do you make to .so(s) and allow an app to use funcs from them with one .h file?
<mvo> Kamion: let's discuss it again tomorrow when pitti is around, ok? 
<seb128> Kamion, mvo: notification-daemon has been fixed by pitti/approved by main
<seb128> it just need to be pulled any way ... maybe with the desktop ?
<Kamion> seb128: 23:32 < Kamion> shouldn't it be seeded or something?
<seb128> hum, k
* seb128 hides :)
<Kamion> the notification spec is weird: "The image should never exceed 200x100, but this should be thought of as a maximum size."
<Kamion> "Never do X. Furthermore, never do X."
<sivang> Kamion: lol 
<Kamion> infinity,lamont-away: about? I need a sessreg/amd64 build
<sivang> night all
<jasoncohen> mvo, hi, i was speaking with pitti earlier about adding a popup notification under the update-notifier icon telling users that there are security or bugfix updates available. Many users don't know that the red update-notifier icon means there are updates available and thus leave their system un-updated for long periods. pitti suggested I speak to you about this since you are the developer of update-manager & update-notif
<jasoncohen> ier
<mdz> lamont-away: have you made any changes to the livefs build scripts recently?
<mdz> lamont-away: I'm getting 403 on /current/
<jasoncohen> i was also thinking that the popup should only come up if the update is from hoary-security or hoary-updates. With the introduction of the official backports, it would be a nuisance to tell users to upgrade every time backports upped the version on a package
<mvo> jasoncohen: thanks for this suggestion. I added support for libnotify to update-notifier and will upload it now
<mdz> infinity: awake?
<jasoncohen> mvo, sounds great
<mvo> jasoncohen: the currently implemetation takes everything in the sources.list into account (and of course only stuff that is installed). so it will give a message if you have backports enabled and a package installed that could be upgraded. I understand that backports are not enabled by default so this should be ok?
<jasoncohen> with cron-apt, one can simply use an alternate sources.list. regular upgrades could use security.sources.list for example and a distribution upgrade (is this going to be in breezy?) can use the full sources.list
<jasoncohen> mvo, i'm seeing more and more users in #ubuntu with backports enabled
<jasoncohen> fortunately, i haven't seen any problems with packages in the official backports
<jasoncohen> i think it would be best to at recognize the high rate of backport usage and give users an option to "show only security and bug fix updates" - perhaps the default option - via an altnerate sources.list
<mvo> jasoncohen: the dist-upgrade tool will not make it for breezy (unfortunately)
<mvo> jasoncohen: let me check if I can't do some python-apt magic to figure about the available updates without using multiple sources.list
<jasoncohen> ok
<mdz> anyone else with buildd privileges on terranova?
<elmo> eh?
<paolo> Kamion, any news from the xorg/boot side?
<mvo> jasoncohen: I'm going to bed now, basic libnotify support is in and upload, more may be impossible before the feature freeze
<mvo> jasoncohen: thanks for your suggestions, I'm happy to talk to you again about it tomorrow/next days, just ping me
<jasoncohen> mvo, will do
<mvo> thanks
<marcin> Kamion: ping
* mvo goes to bed now
<Kamion> paolo: nothing more I need to do that I'm aware of. the xorg upgrade issue's fixed, the sed unsupported command thing's fixed
<Kamion> marcin: pong
<paolo> Kamion, I wonder if it's possible to dig further in the "missing binaries issue", tough.
<marcin> Kamion: sorry to bother you again but maybe you could tell me something more about maintaining
<Kamion> paolo: nothing to dig, it's a known work in progress
<marcin> Kamion: could you tell me how do you work on packages? I mean _practically_
<marcin> Kamion: have you got single development tree? what tools do yo use?
<Kamion> marcin: that's extremely vague and the answer would be very long
<paolo> Kamion, OK.  I'm rather new to all this stuff - thank you for the useful information :-)
<marcin> Kamion: or maybe you could point me to some kind of tutorial - but not maint-guide
<Kamion> marcin: I have a bunch of unpacked source packages organised in whatever way seems appropriate to me; the details are not really interesting
<Kamion> some of them are just stored on-disk as source packages, some are stored in one of various revision control systems
<marcin> Kamion: so you work on these packages 'manually' and you don't have something like a well organized 'factory' ?
<Kamion> eh?
<marcin> Kamion: for example scripts that could build new packages automagically
<Kamion> I use debuild to build source packages
<marcin> Kamion: for example you got a kind of template and some scripts - you define url to source
<Kamion> no, that would be pointless because the installer is far too varied for that, and that's what I spend most of my time on
<Kamion> I spend most of my time hacking code, not packaging stuff
<marcin> Kamion: and it could fetch and unpack and create development tree just with single command
<Kamion> I've never felt the need for that, I'm afraid
<marcin> Kamion: ok
<marcin> Kamion: and you don't know if there is something that could work like I just described?
<Kamion> if I need to create a new package, either I find the last roughly-similar one I did and borrow off it, or I just write it by hand - I've been a Debian developer for about four and a half years so it's kind of second nature
<Kamion> there's dh_make, and people have written various things like that for specialised purposes
<marcin> Kamion: mhmm
<Kamion> it's a bit limited
<marcin> Kamion: well then propably I'll develop 'yet another thing for specialized...'
<Kamion> but in practice, I spend most of my time either (a) dealing with incoming bugs, thinking about why they're happening, debugging, and writing fixes, (b) writing code to implement new features, (c) testing CD images and netboot installs
<Kamion> I don't spend very much time building development trees, so there's no need to optimise that process
<Kamion> I usually find that the maintainers of the devscripts package do it for me if I leave them alone long enough ;-)
<Kamion> (debcommit rocks my world)
<marcin> Kamion: ok I understand
<Kamion> and, I think if I *did* spend enormous amounts of time building factories for churning out packages, I'd be inclined to try to rearrange things so that there wasn't a need for so many packages
<Kamion> but it would depend on the situation
<Kamion> paolo: it's all daniels' baby, anyway; see http://wiki.ubuntu.com/XRoadmap
<Kamion> (of course the dates on that roadmap ran out a couple of months ago)
<marcin> Kamion: ok, thanks for help
<marcin> Kamion: I hope that I'll be able to upload something soon
<marcin> Kamion: so, back to work
<paolo> OK, goodnight folks :-)
<martinhj> the last breezy kernel upgrade left my machine unbootable.. could not detect my lvm partition on my hd.. what are the big differences?
<martinhj> I ended up in a busybox shell
<martinhj> the question is not for support, only want to find out if you know my problem - if I should file a bug or not
<jasoncohen> who deleted breezy goals?
<jasoncohen> https://wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<jasoncohen> it says the page no longer exists
<sklp> https://wiki.ubuntu.com/BreezyGoals
<sklp> is the new URL
<jasoncohen> thanks sklp 
<jasoncohen> will https://wiki.ubuntu.com/PackageDependencyManagement get done for breezy? specifically, will apt & synaptic remove the dependencies of a package you want to remove that were installed merely to satisfy dependencies
<bob2> apt-get shouldn't care
<bob2> aptitude already does
<jasoncohen> i know aptitude does but why shouldn't apt-get support that feature as well?
<jasoncohen> synaptic certainly should
<bob2> afaik, apt-get was originally a test app for libapt
<jasoncohen> "The apt package needs to be improved to provide support for the marking of automatic dependencies. This feature needs to be exported so that frontends like synaptic can make use of it too."
<bob2> yay for suspend to disk not working
<bob2> because firefox and X are consuming more ram than I have swap
<lifeless> rotfl
<Kamion> jasoncohen: we are *one day* from feature freeze; at this point you can probably expect that most features that haven't been making progress will slip
<Kamion> jasoncohen: of the auto-mark work, mdz said in the last goals meeting that he didn't think it had had enough testing to slam into breezy at this late state
<Kamion> s/state/stage/
<jasoncohen> Kamion, darn, thangs for the update
<jasoncohen> Kamion, when will we have a better idea what is going to be getting into breezy?
<whiprush> check the status page, it's pretty much up to date
<Burgundavia> jasoncohen, the decisions on deferring stuff is going to happen quite soon
<Burgundavia> jasoncohen, at which point the BreezyGoals page will be updated
<jasoncohen> how much time will high priority goals get past the feature freeze to complete their work?
<Kamion> depends on their potential for breakage
<Kamion> and user interface impact
<Burgundavia> jasoncohen, the UI freeze is aug 25th
<Kamion> the doc team need time to complete their work, which involves documenting the user interface, so they need something stable to work from
<Burgundavia> if the developers break that, the doc team will hunt them down and kill them slowly
<Kamion> I hope nobody's going to document oem-config at all really, otherwise I'm dead then. :)
<ajmitch> Burgundavia: only for main, I assume?
<Lathiat> heh
<Kamion> (since its UI isn't finished, and I'm about to go on holiday for two weeks)
<Burgundavia> ajmitch, UI is defautl desktop stuff
<ajmitch> Burgundavia: ok, great :)
<Burgundavia> ajmitch, we need time to get screenshots made
<ajmitch> it'd be a nightmare trying to document universe as well
<ajmitch> yes, I know
<ajmitch> which is why there can't be a last minute theme change this time
<Lathiat> heh
<Kamion> (the developers didn't want that last time either)
<mgalvin> ajmitch: ping
<ajmitch> mgalvin: yes?
<mgalvin> ajmitch: i committed those doc package updates, there is an email on the doc list about it as well, just so you know its there, any pointers are more than welcome
<ajmitch> ok, it's in docteam svn?
<mgalvin> yup
<mgalvin> i modeled it after kubuntu-docs which already has weekly builds going into kubuntu main
<jsgotangco> ubuntu-doc/gnome/debian?
<mgalvin> yup
<ajmitch> ok, checking out of svn
<mgalvin> cool, thanks for taking a look at it
<ajmitch> might take awhile :)
<mgalvin> sure, np, i am off to bed now away, no rush
<ajmitch> ok
<mgalvin> if i'm not around just drop me a line on the doc list about it
<mgalvin> thanks again :), g'night
<nomed^> hi all .. does a dpkg recovery tools already exist? a script that can recreate a dpkg status file ..
<bob2> "backups"
<bob2> or a little shell script using /usr/share/doc/
<Kamion> there are some automatic backups of status in /var/lib/dpkg/ and /var/backups/
<Kamion> but status is a primary file, it's not in general generated from information available elsewhere
<Kamion> it's the main dpkg working database
<nomed^> i needed this info because i was just doing some experiments with unionfs and an ubuntu based live cd
<nomed^> my idea was to use different layers ... and unify them .. add a new kernel or new packages would be really easy in this way .. but the status file is a big problem ..
<nomed^> thanks anyway
<Kamion> jbailey: wow, adding initramfs-tools to minimal adds like a megabyte to the debootstrapped set
<Kamion> what with busybox, klibc-utils, lvm2, mdadm
<jbailey> Kamion: Hmm.
<jbailey> Kamion: That dependancy could be weakened by moving the initarmfs install script to those various packages.
<jbailey> We just need to make sure then that a system  using md or lvm has the right packages installed.
<jbailey> Kamion: Is it going to cause you grief in the meantime?
<Kamion> oh, no, I was just noting the size increase
<Burgundavia> Kamion, what is the status of the windows stuff on the live cd?
<Kamion> base-installer actually already ensures to install mdadm and lvm2 before installing the kernel, I think because initrd-tools needed that
<Kamion> Burgundavia: no idea, I just copy it
<Kamion> I have no Windows systems on which I could look at it even if I wanted to
<Burgundavia> Kamion, is there going to be enough space for the breezy release?
<Kamion> Burgundavia: it may be reduced, depending on size constraints; we want to keep at least some of it there
<Burgundavia> ok
<Burgundavia> I am asking for our QuickTour marketing doc, that is all
<jbailey> Kamion: Ah, that makes sense.  Part of it is also that an older lvm2 results in a non-bootable system with 2.6.12
<jbailey> Kamion: I really want to see us work towards eliminating the option of doing your own kernel so that we can do proper dependancies with kernel packages and make promises based on it.
<ajmitch> yes, it showed up all sorts of fun :)
<Kamion> jbailey: is binutils-static really meant to depend on binutils?
<jbailey> Kamion: But I'm expecting this to be an uphill battle.  Something to bribe people over at the Fall Canonical conference.
<ajmitch> jbailey: users are always going to want to roll their own
<Kamion> jbailey: elmo will murder you in your sleep
<Kamion> (for no-homebrew-kernels)
<jbailey> ajmitch: Yes, thanks for the testing last night.
<ajmitch> no problem..
<jbailey> Right, but the question is always *why* are users rolling their own?
<jbailey> And can we eliminate the need for it.
<ajmitch> at best, you could document what users need to have for things to work
<ajmitch> because they're users, and they heard from a friend-of-a-friend..
<Burgundavia> jbailey, why not ask on the forums and lists?
<Kamion> the problem is that dependencies on kernel packages don't work even if nobody rolls their own kernels
<jbailey> Watching #ubuntu, rolling your own kernel seems to be more of a "I heard that you need to do this on Linux" than people actually meeting a need.
<ajmitch> sometimes people do it just to see what it's like
<Kamion> because generally you want to express a dependency on the running kernel, not on whatever kernels dpkg happens to think are installed
<jbailey> Burgundavia: Because I prefer to get flamed by friends before I go out and get flamed by strangers.  It's my style. =)
<Burgundavia> jbailey, ok
<Burgundavia> jbailey, I meant ask people about why they rolled their own kernels
<jbailey> Kamion: re: binutils-static only provides ld_static at the moment.
<Kamion> jbailey: (jessica wants to promote binutils to the debootstrapped set at the moment, which seems like crack)
<Kamion> jbailey: yes, but that's all we need in base, surely
<jbailey> Oh feh.
<Kamion> hooray, InstallerStage2Progress works perfectly on today's CDs
<jbailey> Next time someone sees our friendly dpkg maintainer can they poke him with a stick until he gives us the "Doesn't really depend on, but if it's installed, it needs to meet these constraints" header? =)
<Burgundavia> jbailey, Kamion would it be useful for me to ask on the forums about why people roll their own?
<Kamion> Conflicts: binutils (<< ${Source-Version}), binutils (>> ${Source-Version}) if you really must, but won't that make upgrades horrifically complicated?
<jbailey> Kamion: Assuming I didn't do some crack with a symlink and /usr/share/doc/binutils-static, it's not a critical thing.  Just a way of keeping irreproducable bugs from showing up.
<ajmitch> that does look a bit evil
<Kamion> Burgundavia: I don't think so; we have enough experience within the team of that
<Burgundavia> Kamion, ok
<Kamion> jbailey: oh, if you aren't depending on binutils, you'll have to ship copyright and changelog in /usr/share/doc/binutils-static/ anyway
<Kamion> so just drop the symlink?
<jbailey> Burgundavia: Not yet.  I want to work out the idea of "If noone rolled their own, how would this work" before eliminating the need for peopel to roll their own.
<Burgundavia> ok
<jbailey> Kamion: Yup
<Kamion> ah, I just reread your sentence and it makes more sense now
<jbailey> Sorry, I'm a bit tired.
<doko> good morning
<ajmitch> hi doko 
<doko> hi ajmitch 
<doko> Mithrandir: the OOo2 bootstrap succeeded, please test the sunjavaplugin.so in my home on chinstrap
<zwnj> i run "gucharmap --version". cvs gives me 1.4.2 but ubuntu's one gives 1.4.3.  what's the matter?
<Mithrandir> doko: cool, I'll do that just after breakfast.
<Lathiat> i wonder how freenode detectors TOR
<bob2> there's only so many exit nodes
<Lathiat> ah i thought it was like a p2p thing
<bob2> no
* Lathiat reads up on it
<Lathiat> ah, interesting
<Lathiat> hrm nautilus still has (null) for trash
<pef> hello
<Mithrandir> elmo: one of the members of the archive.ubuntu.com (.151) is giving ECONNREFUSED on port 80.
<tepsipakki> who should I bug about lrm-manager?
<tepsipakki> it doesn't find ld, because PATH is not set
<pitti> Good morning!
<ajmitch> morning pitti 
<ogra> pitti !
* pitti hides under the flood of pending main inclusion reports
<ajmitch> hi ogra :)
<ogra> pitti, we have a small problem....
<ajmitch> bbl..
<ogra> pitti, obviously there is a new open CAN for nvu... according to Burgundavia there is also a new upstream version and our current one is ftbfs because of XPrint bindings....
<ogra> so i think you can kip this one until we decided if we want the new upstream version... 
<ogra> s/kip/skip
<pitti> it's certainly justified in this case...
<Burgundavia> pitti, the new upstream is merely the stable
<Burgundavia> pitti, the current version is a half-asses unstable versin
<pitti> I'm not opposed, you have to convince mdz or Kamion :-)
<ogra> Burgundavia, whats wtong with "web development editor" in the tooltip ?
<ogra> wrong even
<ogra> :)
<Burgundavia> ogra, nothing, but the name needs to say something only that nvu, because very few hyperactive kids are going to stick around long enough for a tooltip
<Burgundavia> especially if we want to crack the Ritalin-addicted US market
<ogra> the bug says: The current tooltip is not Higgy.
<ogra> thats somewhat confusing :)
<Burgundavia> oh, the tooltip needs to be a verb
<Burgundavia> sorry, I forgot about that
<Burgundavia> Edit webpages or something similar
<ogra> Burgundavia, there is no indication you mean the text of the menu entry, it only talks about the tooltip... thats what i maent with confusing..
<Burgundavia> ogra, ok, the tooltip and the menu item need to change
<Burgundavia> ogra, made it more clear
<Mithrandir> oh joy, strace segfaults.
<Lathiat> haha
<Mithrandir> (with -c)
<Mithrandir> (when stracing 32 bit programs on amd64)
<infinity> Kamion : amd64 sessreg and partman-base builds rescued for you.
<seb128> daniels: around?
<jdub> morning seb128 
<seb128> hey hey jdub
<jdub> seberino, full of healthy seb goodness!
<seb128> ;)
<jdub> dude
<jdub> you are famous
<jdub> i met an ubuntu user today who said he used sebuild
<jdub> i am pleased to see that meme working its way around the world :)
<seb128> ah ah
<Treenaks> whoa.. the French even _laugh_ in reverse? :P
<seb128> doing thing the same way has everybody else would be boring :p
<Treenaks> seb128: that's a way of explaining it :)
<seb128> s/has/as/
<seb128> daniels, pitti: any reason to not ship /usr/bin/dbus-binding-tool and /usr/bin/dbus-viewer with dbus-utils?
<tepsipakki> is the current nvidia-glx known to be broken? it tries to run my flat-panel on 75Hz while it should use 60
<tepsipakki> worked on hoary
<pitti> seb128: I don't know these tools, but they can certainly be shipped if you need then
<pitti> them, even
<seb128> pitti: totem wants the first one
<pitti> seb128: uh, totem uses dbus now?
<seb128> pitti: every cool kids use dbus nowadays
<pitti> :-P
<seb128> "          Use DBus for plugin<->helper communication, with nice function
<seb128>           interfaces so it's all easy (no more totemMozillaObject::wait()),"
<pitti> right, get rid of these damn cars, use the bus!
<seb128> yeah, that's good for the planet :)
<pitti> yay, security bug in evolution *sigh
<daniels> seb128: sure, I'll fix that
<seb128> pitti: oh, I'm doing a gaim sync with Debian, cf the changelog for security fixes
<pitti> seb128: 1.5.0? thanks, I know the advisory
<seb128> daniels: hey. I've uploaded a version with the .la for the lib, it was breaking GNOME again ...
<daniels> seb?!?
<daniels> insert a tab in there wher eappropriate
<seb128> pitti: not yet, but they have patched 1.4.0
<pitti> cool
<daniels> how many libs was it in? i grepped over /usr/lib and didn't find one .la with it in
<seb128> daniels: and a bunch of other .la mention libdbus.la which break everything using hal
<seb128> daniels: libhal by example
<seb128> which is already a good candidate for b0rkages
<daniels> seb128: we could fix those ...
<seb128> daniels: and mdz agreed the -dev should ship the .la
<daniels> i'm trying not to ship *any* .la's
<seb128> daniels: I agree with that, we should not ship any, but we should make it a policy
<seb128> there is not point to change a few random package and breaking builds every time
<infinity> <parrot>Policy comes from common practice, not vice verse</parrot>
<Mithrandir> infinity: nono, that is in debian.  We're ubuntu. :-P
<seb128> daniels: 
<seb128> $ grep dbus-1.la /usr/lib/*.la | sed 's/:.*//'
<seb128> /usr/lib/libhal.la
<seb128> /usr/lib/libhal-storage.la
<seb128> /usr/lib/libnautilus-burn.la
<seb128> 
<seb128> daniels: I'm fine to rebuild both with the new dbus if that's the correct fix, but you were not arround and mdz said the -dev should ship the .la
<seb128> daniels: drop them while doing the upload for /usr/bin/dbus-binding-tool and /usr/bin/dbus-viewer if you want, we rebuild hal and n-c-b then and we are fine
<seb128> daniels: I was just trying to get GNOME building, if we want a colony CD this week ... :)
<pitti> Hi mvo
<seb128> hey mvo
<mvo> hey pitti, seb128 !
<seb128> infinity: could you kick rhythmbox build? It broke due to dbus .la drop yesterday and should build with current version
<pitti> mvo: n-d is ftbfs, your patch doesn't apply...
<infinity> seb128 : punted.
<seb128> thanks
<seb128> pitti: should I mention the CAN again with the Ubuntu changelog, or the previous entry from Debian is fine?
<seb128> pitti: http://packages.qa.debian.org/g/gaim/news/1.html
<pitti> seb128: if the CAN appears anywhere, that's fine
<seb128> cool
<pitti> thanks
<seb128> np
<pitti> cool,  so the patches are already split out
<pitti> I was afraid that I had to pull them from cvs agaihn
<seb128> :)
<daniels> seb128: ok.  when are you around tonight/tomorrow?  i'll do the upload while we're both here so we can keep the disruption as small as possible.
<seb128> I'm around for like ~12 hours from now
<seb128> daniels: but I can do the upload now with the 2 binaries to dbus-utils and without the .la and then rebuild hal and n-c-b
<seb128> so I can upload totem
<seb128> as you want
<daniels> seb128: want me to sort it?
<seb128> that's a trivial change ... if you agree than the 2 binaries go to dbus-utils I can do it 
<daniels> ok, sure
<seb128> will do so, thanks
<daniels> thank you :)
<seb128> np ;)
<Mithrandir> Riddell: I'm about to give up on getting kde to understand that it should look in /usr/lib32/kde3 for styles and such, you might want to pick it up.
<daniels> seb128: anything else you need?  i'm going to do another xorg upload tonight
<daniels> seb128: (if all goes to plan)
<seb128> daniels: fix Xnest? :)
<seb128> $ Xnest :1
<seb128> Could not init font path element /usr/share/X11/fonts, removing from list!
<seb128> Fatal server error:
<seb128> could not open default font 'fixed';
<seb128> 
<seb128> do you know what is the issue here?
<daniels> oh man I am so shit
<daniels> yes
<seb128> would be nice to fix that so sabayon can work ... :)
<daniels> yeah, that's a one-liner
<mdke> what is elmo's email addy?
<daniels> mdke: james.troup@
<daniels> seb128: unfortunately you need to *grow* the element, so you can't just edit the binary and pad the table with NULs
<mdke> daniels, thanks
<seb128> daniels: I can wait for next xorg upload, no hurry ... I local hack would not make a big difference, I want to upload a working version anyway :)
<daniels> seb128: ln -s /usr/share/X11/fonts/misc /tmp/fonts, change /usr/share/X11/fonts in Xnest to /tmp/fonts, and pad it with NULs
<seb128> k, thanks
<seb128> infinity, lamont-away: do you know what's going on with evolution 2.2.1.1-0ubuntu4.1 build? That's a upload made some time ago for hoary-updates
<infinity> ?
<infinity> I see no evolution in hoary-updates at all.
<infinity> Was it actually ACCEPTed?
<seb128> no clue
<seb128> "  to pool/main/e/evolution/evolution_2.2.1.1-0ubuntu4.1.dsc
<seb128> Announcing to hoary-changes@lists.ubuntu.com"
<seb128> yeah, I've an ACCEPTED mail
<pitti> infinity: it's still in the accpeted queue, but without debs
<infinity> Interesting.
<seb128> jul 19
<infinity> I see -0ubuntu4 in hoary, and nothing registered for hoary-updates or hoary-security.
<seb128> has anybody used hoary-updates out of this upload? :)
<infinity> Looks like a whopping 3 packages have successfully passed through hoary-updates.
<seb128> k
<infinity> xine-lib, kdenetwork, knetworkconf
<seb128> so why does it hate me? :p
<infinity> Not sure, but I'd whine to elmo.
<infinity> If cron.daily isn't exporting the current state of the queues/archive to wanna-build, I can't do anything about it.
<pitti> infinity: the source pkg is in accepted, but it didn't build
<infinity> pitti : Yes, see above.
<pitti> k
<infinity> pitti : From my POV, the source package doesn't exist.
<doko> ohh, is this the same case for dbus?
<infinity> doko : There's a dbus in limbo in hoary-updates too?
<infinity> If so, then yes.
<infinity> Like I said, those three packages above are the only three registered in wanna-build at all (all in state:Installed)
<chmj> pitti: ping
<infinity> Anything else uploaded doesn't seem to exist.
<infinity> elmo : Dude, cron.daily doesn't seem to be syncing the state of the hoary-updates archive with wanna-build.  There are complaints of ACCEPTED source packages that have never made it to w-b.
<infinity> There, that's about all I can do about it. :/
<infinity> (Well, if the source is actually sitting in the archive, I can force builds, but fixing the real problem is best..)
<janimo> daniels, do you know of existing issues with libvgahw and screen blackout or should I file another bug on the subject (trident card on laptop)
<daniels> janimo: it should be fixed via a gcc patch in -44 and above.  if not, file a bug on gcc because the fix was incomplete.
<_d4v_d> play Aggro Berlin - Schlampen (Bushido, Sido & B-Tight).mp3
<Mithrandir> Kamion: can you send me whatever code you have for MountingHDDFilesystems (or point me in the right direction at least)
<Lathiat> hrm
<Lathiat> apt doesnt fall back if a host has more than 1 ip
<Lathiat> e.g. archive.ubuntu.com has connection refused on 1 ip but not the other
<Lathiat> (and someone might wanna look at that)
<Mithrandir> Lathiat: I've already told elmo here, might want to drop him a mail as well
<Lathiat> Mithrandir: ok
<Treenaks> that, and apt should be fixed :)
<infinity> Both IPs work for me.
<infinity> As for apt, it just does what the resolver tells it to do.
<infinity> And the resolver will just pick a random IP from round-robin DNS.
<Lathiat> ok i lied
<Lathiat> *debmirror* doesnt fall back
<infinity> apt doesn't know or care that there are multiple IPs.
<ajmitch> the resolver can return a list of IPs, iirc
<Lathiat> infinity: well getaddrinfo will return a list of all ips
<Lathiat> and you can cycle through them
<Lathiat> (if 1 fails)
<Lathiat> like e.g., talnet
<Lathiat> err, telnet
<Lathiat> anyway i think its debmirror not apt, i wasnt thinking
<Lathiat> apt seemed to update ok
<Lathiat> also
<Lathiat> it just
<Lathiat>  fixed itself
<Lathiat> hrm some maintence might be being done
<Lathiat> cus the other one just went over now
<janimo> mvo, will notification be usable for something like disk full warning?
<seb128> jamesh: around?
<mvo> janimo: yes, but there will need for a daemon that actually monitors for disk-full
<infinity> A cronjob would probably be good enough.
<infinity> OTOH, notification seems a bit goofy.
<infinity> I keep getting wanred to reboot cause I installed a new kernel... Afetr I've rebooted (and not before)
<infinity> Yay.
<mvo> infinity: good point, there is this nice notify-send command
<mvo> infinity: that sounds like a bug to me :)
<infinity> Yeah, I think it may be "development release specific", though, so I haven't bothered to look into it.
<pitti> mvo: beware that notify-send currently hangs on powerpc, I'm sorting this out wit upstream
<infinity> (ie: it may have to do with update-notifier or gnome-panel being updated in the same apt run as the kernel, and so the applet doesn't fire until I log out and back in)
<mvo> right
<infinity> And in a stable release, the odds of yuu updating the panel stuff and the kenrel in the same go are slim.
<infinity> pitti, mvo : Is there a way to set a "clear on reboot" flag on a notifier message?
<infinity> It doesn't make sense to be told about a kernel upgrade after you've rebooted, for instance.
<pitti> infinity: no, the current kernel notification is broken anyway in several ways
<Lathiat> yeh thats annoyed me a few times
<pitti> infinity, mvo: I think the notification should not be shipped with l-i, but created in the postinst, and some init script should remove it
<mvo> that would be the easiest solution
<infinity> Well, this notify-send you speak of may be the ticket there.
<infinity> Assuming stuff sent by notify-send disappears into oblivion on reboot.
<pitti> infinity: it does
<pitti> infinity: the only problem is, package installation can' trigger it
<pitti> infinity: since this is entirely user-session stuff
<infinity> Hrm?
<infinity> notify-send only works on a user-by-user basis, you can't send a "system notice"?
<infinity> Then it wouldn't work for a diskspace cronjob either.
<pitti> right
<pitti> it's intended to be a desktop tool
<pitti> and it listens to the session dbus
<mdke> does anyone know if there are any bugs filed about the installer breaking laptop rescue partitions? I did a quick search and couldn't find any
<infinity> So, what's the "correct" way to just "send a notice to any currently logged in session", or similar?
<pitti> update-notifier, I think
<infinity> mdke : Define "breaking".
<pvanhoof> breezy problem
<pvanhoof> The following packages have been kept back:
<pvanhoof>   x-window-system-core
<mdke> infinity, for any definition of it
<pvanhoof> can it be fixed?
<infinity> mdke : Is parted eating your partition table, or is the partition being wiped out, or it it being unhidden/renumbered, ec?
<pvanhoof> startx does work :)
<mdke> infinity, in my case, i can't access it via the hotkey from bios, and if I start it from the grub entry that was added, i get a BSOD
<pvanhoof> but I'd prefer the package system to be correct
<infinity> pvanhoof : Try a dist-upgrade.
<pvanhoof> infinity, yeah I used that
<infinity> pvanhoof : If that doesn't work, try "apt-get install x-window-system-core" on its own, and see why it's refusing to install it.
<pvanhoof> -window-system-core: Depends: libgl1-xorg-dri but it is not going to be installed
<pvanhoof>                         Depends: libgl1-xorg but it is not going to be installed
<pvanhoof> hmm strange
<mdke> infinity, so you know of bugs filed on that subject?
<pvanhoof> it needs to remove some -dev packages, to get libgl1-xorg installed
<infinity> mdke : Hrm.  Rescue partitions are usually marked "hidden", and as such shouldn't end up being auto-added to GRUB, or touched in any way.
<seb128> jbailey: ping?
<infinity> pvanhoof : Which packages?
<Mithrandir> is there an easier way to test changes to the live cd than making a new one and burning a new disc?
<infinity> pvanhoof : That would most certainly point at a bug in those.
<pvanhoof> like .. libbonoboui2-dev libcairo1-dev libdbus-qt-1-dev libdevhelp-1-dev libeel2-dev libgail-dev libgail-gnome-dev libgal2.4-dev libgimp2.0-dev libglade2-de
<pvanhoof> there's more
<mdke> infinity, not this one I guess. It was added to grub as Windows 2000 and I can no longer access it by pressing the "Access IBM" button at the startup screen
<infinity> pvanhoof : That doesn't seem right at all.
<Mithrandir> mdke: that's because the MBR is overwritten.
<daniels> uhm
<infinity> mdke : Hrm.  If I hadn't wiped out the recovery partition on my Thinkpad, i could test this.
<daniels> works for me?
<Mithrandir> at least, afaik.
<pvanhoof> infinity, idd, I'm going to leave it like that :)
<pvanhoof> since I do need a development platform
<infinity> mdke : But it sounds like you, at some point, turned on the BIOS option to "allow recovery partitoin to be used/recovered by the OS"
<pitti> elmo: can I please have the evolution build-deps in concordia's warty and hoary dchroots?
<pvanhoof> infinity, I think xlibmesa-dri is causing the problems
<infinity> pvanhoof : Uhm, that's been removed from the archive.
<pvanhoof> but I removed them (the devel packages) and am now reinstalling them. And suddenly the packaging system is cool about installing x-window-system-core
<infinity> pvanhoof : Try 'apt-get --purge install libgl1-xorg-dri'
<pvanhoof> ah but it's going to install it
<pvanhoof> without any special rules
<pvanhoof> I had a lot of warnings like this
<pvanhoof> libgle3 depends on xlibmesa3-gl | libgl1; however:
<pvanhoof>   Package xlibmesa3-gl is not installed.
<pvanhoof>   Package libgl1 is not installed.
<pvanhoof>   Package xlibmesa-gl which provides libgl1 is to be removed.
<mdke> infinity, i received the laptop yesterday and haven't touched the BIOS
<infinity> That's fine.
<pvanhoof> dpkg: xlibmesa-gl: dependency problems, but removing anyway as you request:
<infinity> mdke : Ahh, then it could be Mithrandir's guess about the MBR, though I don't recall "Access IBM" using thr MBR.
<mdke> ok i'll report a separate bug and debug it with whoever is assigned to it
<infinity> pvanhoof : Those warnings are fine.  It's just apt forcing dpkg to do things in one run that it would rather do in several.
<pvanhoof> aha ok
<mdke> thanks infinity, Mithrandir 
<pvanhoof> almost downloaded all packages :). so installed will proceed in a few seconds
<pvanhoof> s/installed/installing
<Mithrandir> hmm, this shouldn't work:
<Mithrandir> db_input casper-udeb/snapshot/cow-device || true
<Mithrandir> I wonder why it does.
<Mithrandir> or, it probably doesn't
<pvanhoof> here we go
<pvanhoof> no significant problems ... testing x11
<pvanhoof> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<pvanhoof> startx -- :2 worked
<pvanhoof> going to reboot in a few minutes to test the new kernel. Has there been issues reported by somebody about the kernel?
<pvanhoof> or is it safe to reboot?
<pvanhoof> :p
<pvanhoof> -- oh I like that question --
<daniels> xlibmesa3-gl??
<pvanhoof> daniels, yes, it's removal was a bit problematic
<pvanhoof> it blocked the update of libgl1-xorg-dri .. and it forced me to remove +- 15 -dev packages first
<daniels> is that an upgrade from debian?
<pvanhoof> no well, hoary to breezy (5 weeks ago) and now a new upgrade
<daniels> bong ... someone must've hardcoded xlibmesa3-gl.
<pvanhoof> I managed to fix the fact that mkfontdir was missing a few weeks ago
<daniels> in any case, that's apt's fault
<daniels> mdz: is there anything we can do with apt to make upgrades like pvanhoof's above actually work?
<infinity> pvanhoof : Kay, that's hilighted a bug or two in breezy that we'll poke at.  So, your upgrade problems aren't all for nothing. :)
<pvanhoof> ok :)
<pvanhoof> that is one of my reasons for running breezy
<pvanhoof> so, great
<pvanhoof> installing gnome-devel (it looks like some packages from that collection have been removed)
<pvanhoof> libgnomemm2.0-dev: Depends: libgnomemm2.0-1c2 (= 2.0.1-2ubuntu3) but it is not going to be installed
<Amaranth> why isn't it going to be installed?
<pvanhoof> sec
<pvanhoof> libgnomemm2.0-1c2: Depends: libgtkmm2.0-1 but it is not installable
<pvanhoof>   libgtkmm2.0-1c2
<pvanhoof> E: Package libgtkmm2.0-1 has no installation candidate
<pvanhoof> so, a missing package
<pvanhoof> or incorrect dependency
<azeem> looks like libgnomemm got transitioned before libgtkmm?
<azeem> so needs a rebuild I guess
<pitti> infinity: btw, I just found another hanging hoary-updates package:  dbus (0.23.4-0ubuntu4)
<doko> pitti: yes, that was the thing as was asking before ...
<paolo> Are there channel logs?
<daniels> paolo: http://people.ubuntu.com/~fabbione/irclogs/
<daniels> hm
<daniels> what happened to xorg 6.8.2-10.1?
<daniels> speaking of things that just wandered out of hoary-updates
<infinity> mdz : Your LiveCD builds on terranova should be okay now, I just did a test run of all of them.
<pvanhoof> During the boot of my new kernel, I saw the message "Unable to find volume group "hda1"
<pvanhoof> luckily it did boot
<pvanhoof> :p
<paolo> daniels, is it espectable to not have xfonts-terminus working on the latest xorg?
<pvanhoof> this was, of course, a breezy kernel
<pvanhoof> is
<paolo> pvanhoof, it doesn't MAKEDEV hd[abcd]  for me too, but I boot from USB (/dev/sda)
<daniels> daniels@ephemera:~/canonical/brainfreeze/xorg/monolith% interdiff -z old/xorg_6.8.2-48.diff.gz xorg_6.8.2-49.diff.gz | diffstat | tail -1
<daniels>  56 files changed, 54 insertions(+), 15729 deletions(-)
<daniels> paolo: yeah
<pvanhoof> paolo, is it something that I can fix?
<paolo> daniels, aww - too bad :-)
<paolo> pvanhoof, unfortunately I don't know.
<pvanhoof> or something that I shouldn't fix
<pvanhoof> ok
<pvanhoof> it does take long for the kernel to mount the volumne
<paolo> pvanhoof, as a workaround you could create them by hand once it booted.
<paolo> pvanhoof, but it will not reduce that delay - I think.
<pvanhoof> ok
<pvanhoof> the delay is not a big problem .. 
<paolo> I wonder how can people code without a terminus-enabled Emacs! /me grins evilly
<pvanhoof> ok. other than that kernel issue
<pvanhoof> everything seems to work for me , breezy
<mvo> seb128: so gamin changed the semantic of FAMEvent.filename? it does no longer include the path? do you know what that was good for?
<seb128> mvo: API b0rkage?
<pvanhoof> aha, and the keyboard layout thing now works
<pvanhoof> cool
<seb128> mvo: nop
<paolo> daniels, could I help in any way for this font issue?
<pvanhoof> Error activating XKB configuration.
<pvanhoof> bleh :)
<mvo> seb128: very bad indeed, old gamin gave me complete pathes for changes files, new gamin does no longer do that
<seb128> mvo: bugzilla.gnome it please
<pvanhoof> bleh, no french charactes for me then
<mvo> seb128: is the new maintainer around on irc? I would like to have a word with him :)
<pvanhoof> is there a way to switch to us_intl for the keyboard on a breezy?
<pvanhoof> a way that works :)
<seb128> mvo: not that I know of, but you can probably drop him a mail
<seb128> what is the standard admin group ? adm or admin?
<paolo> admin
<seb128> grumpf, why does my user is to "adm" and /var/log files for adm too
<paolo> Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.
<paolo> seb128, It happened to me in this breezy install - it seems because I set a root password in the process.
<seb128> is the stock user on a stock install a member of admin or adm ?
<seb128> my /etc/group doesn't list "admin" as a group ...
<paolo> If stock != expert, I can't say.
<paolo> seb128, yes, you have to add the group and the line to /etc/sudoers, if you set a root password.
<paolo> (and the user to the group, obviously)
<omer> hello
<omer> I have seriously problem
<omer> I can't load the system
<daniels> paolo: not really, sorry
<omer> it a new install, on a new computer, amd 64
<omer> and yesterday I can
<omer> now, all I have is the grub command line
<infinity> Unpacking gconf2 (from .../gconf2_2.11.90-0ubuntu3_i386.deb) ...
<infinity> dpkg: error processing /var/cache/apt/archives/gconf2_2.11.90-0ubuntu3_i386.deb (--unpack):
<infinity>  subprocess pre-installation script returned error exit status 1
<infinity> Bah.
<infinity>  /var/lib/dpkg/tmp.ci/preinst: line 7: return: can only `return' from a function or sourced script
* infinity glares at seb128 
<paolo> daniels, no problem - I wish I could have ;-)
<daniels> infinity: is gtk bug
<pvanhoof> omer, doesn't sound like a big problem if you just installed it yesterday .. reinstall it? :)
<pvanhoof> omer, if you didn't "upgrade" something, you might have a problem with your harddisk or hardware
<omer> I just want to chwck out if there is another solotion
<omer> I have two old harddisk, not serial ata
<pvanhoof> omer, you can try booting with a livecd and see if the partition is still readable
<pvanhoof> if it is
<pvanhoof> mkdir /mnt/temp
<Kamion> Mithrandir: everything I've done's in the archive
<pvanhoof> mount /dev/hda1 /mnt/temp
<pvanhoof> chroot /mnt/temp
<pvanhoof> init 5
<omer> In the start I have on the computer serial ata
<Kamion> Mithrandir: it's in helper programs in partconf, mostly
<omer> It will take time to download the live cd
<omer> so, just to reinstall it?
<pvanhoof> omer, yes well, with nothing you can't fix things 
<pvanhoof> omer, that is the most easy solution for your problem, yes
<seb128> infinity: jbailey broke that's and I uploaded a fixed version like 1 hour ago
<omer> so I will reinstall it
<infinity> seb128 : Ahh, I must have just missed getting the fix on my LiveCD build.
<omer> There is a way to use my serial ata hardisk?
<pvanhoof> omer, and download the livecd once reinstalled
<omer> OK
<omer> I have a serial ata that came with the computer
<pvanhoof> omer, well, you can check whether the livecd finds your serial ata hd
<pvanhoof> if it does .. the installed will most likely detect the controller/ata hd
<omer> the installer don't recognize it
<pvanhoof> and then it should be possible to select it as the target device to put your / on
<omer> so I use in my old HD
<Kamion> Mithrandir: see near the end of http://people.ubuntu.com/~fabbione/irclogs/archived/2005-06/ubuntu-devel-2005-06-01.html for the last important discussion about it
<pvanhoof> omer, then it highly depends on your serial ata controller 
<pvanhoof> omer, if you can find kernel modules/support for it at the manufactorer of the controller: perhaps
<Kamion> Mithrandir: the thing about having a little script in partconf to extract the label which is then used by os-prober
<jbailey> seb128: Thanks for catching that.  I thought return was the same as exit in regular shell.
<omer> I have a disket with driver to windows
<jbailey> seb128: But apparently it's not C. =)
<pvanhoof> omer, you can also build a custom kernel and replace the one of the installer. Also note that you'll have to replace the final kernel with that one etcetera ... it's a lot of work
<pvanhoof> omer, that driver will not work
<infinity> jbailey : I've heard testing packages is a good idea.  <duck>
<omer> I know
<Kamion> Mithrandir: but anyway, as the IRC log indicates, colin.watson@canonical.com--2005/casper--automount--0 has the relevant live CD tweak; and I misspoke, that part isn't in the archive
<pvanhoof> omer, so basically .. use your old harddrive
<seb128> jbailey: hi, no problem :)
<omer> so I will continue working with the old HD
<omer> OK
<omer> thanks
<Kamion> Mithrandir: that's http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005
<jbailey> infinity: Right, and I tested upgrades from a previous version, from the problem version, and from the newer version as well as downgrades.
<jbailey> infinity: Forgot to --purge it. =)
<infinity> Tsk. :)
<infinity> I'll forgive you this once.
<pvanhoof> omer, if you can get the serial one working once installed and upgraded .. you might try reinstalled with the very latest unstable release build of ubuntu
<infinity> jbailey : I wouldn't care if it hadn't broken the LiveCD build. :)
<pvanhoof> s/reinstalled/reinstalling
<omer> It a bait dangerus to use unstable, not?
<Kamion> speaking of broken builds, gnome-applets and gaim are my currently-painful missing builds
<daniels> \o/ not xorg
<pvanhoof> omer, you should ask such questions on #ubuntu. Those people can help you
<pvanhoof> omer, but indeed, unstable is more dangerous than stable
<Kamion> ow, gnome-applets dep-wait libhal-dev
<omer> they send me here
<pvanhoof> lol. I see
<daniels> Kamion: libhal-dev should now be buildable again
<omer> I have problem with installing
<pvanhoof> omer, what the people here basically need to know is the manufactorer of your serial ata controller
<Kamion> infinity: give-back libhal-dev, please?
<Kamion> er, hal
<pvanhoof> and the version/id/make etcetera
<pvanhoof> and then they can tell you whether or not the device is supported
<omer> I can tall you what was writen on the disket:
<pvanhoof> sure
<omer> Silicon Image SATA RAID Driver for ATI RS480
<pvanhoof> you could try loading the module sata_sil
<pitti> elmo: heartbeat sync, please
<pvanhoof> during the installation
<Lathiat> silican image raid is fake raid
<Lathiat> fwiw
<Lathiat> so youll get the disks but not the raid
<Kamion> daniels: does that mean we know where that dpkg segfault came from?
<omer> If you can explain me exactly what to do it help
<infinity> Kamion : Done.
<pvanhoof> omer, I forgot the installation procedure acutally :). But I do know you need (in some expert mode) need to load that module using some option
<pvanhoof> Perhaps do the people on #ubuntu know how to do that.. or perhaps will somebody else answer it
<infinity> Kamion : And no, we have no idea where the dpkg segv is coming from yet. :/
<pvanhoof> basically .. if you can manage to load that module, it might work
<omer> All right, so I go back to there
<omer> thanks
<pvanhoof> since the support for your device would be implemented in that module
<infinity> Kamion : Other than the general cluster of packages that seems to tickle it, leading me to believe that if I just change enough control fields in the gl/glu clusterfuck, it'll magically go away.
<pvanhoof> and the kernel will only find your device if that module is loaded
<j^> whats the current plan for default audio output? alsa / polyp / esd?
<pvanhoof> not sure if the version of your device is also supported by the module
<Kamion> gaim was bitten by the gconf2 preinst thing
<pvanhoof> you'll have that check that
<Lathiat> hrm ive got 15 lines in my system tray again
<pvanhoof> gtg now omer  :)
<pvanhoof> hf
<Lathiat> somethings messing with it, perhaps udpate notifier ?
<Kamion> ok, so that should be most of the desktop problems
<Lathiat> seems to be a recent problem
<Robot101> gaim... gconf?
<omer> I try to check what I can
<Kamion> huh, no, imagemagick/amd64 too
<Kamion> infinity: that's another dpkg segfault casualty
<Kamion> infinity: yeah, that was my instinct too
<jbailey> Hmm..  13365 says that lilo passes root= as a *numeric* device?
<Kamion> shall I get working on that today? I can't really do significant more installer work before going on vacation; my main outstanding task is Colony 3
<jbailey> Ugh.  I thought I had managed to escape all the crappy magic constants.
<mvo> Lathiat: do you have a screenshot (if it is u-n faults, i would like to know :)
<infinity> Kamion : daniels just went through xorg and tore out a bunch of obsolete conflicts/replaces which will make it in the next upload, and I'm going to mangle mesa beyond repair, so we may get it worked around.
<infinity> Kamion : I'd rather, though, have someone attempt to debug the actual segv.
<infinity> Kamion : Keybuk's not had the time/inclination to look at it, but someone really should.  I'm sure we're tickling something hairy in the depths of dpkg that really should not be broken like this.
<infinity> Kamion : If you have the time to look at it, debugging dpkg would make me love you forever.  All I could get form it was an un-backtraceable smashed stack.
<Kamion> ok, makes sense
<Kamion> Mithrandir: I've NEWed ia32-libs-kde, guessing that'll make ooo2-amd64 entirely installable
<mvo> Kamion: is gnome-app-install-data waiting in NEW too?
<Kamion> Mithrandir: time to add it to the desktop seed?
<Kamion> mvo: yeah, processing now
<Kamion> mvo: why the split?
<Kamion> infinity: what was the reproduction case again?
<mvo> Kamion: it felt natural 
<infinity> Kamion : Pick one from a build log, there are dozens.  But the one that works 100% for me is "new --variant=buildd chroot ; apt-ge install libqt3-mt-dev mesag-dev"
<Kamion> mvo: it would have made sense if gnome-app-install were architecture: any, but it's architecture: all
<infinity> Kamion : Take a note of which packages get installed, so you can repeated --purge them and reinstall while debugging, if you don't feel like debootstrapping a fresh chroot every time.
<Kamion> infinity: oh, it works if you --purge? I'm sure that failed to reproduce for me before
<Kamion> but maybe I just fumble-fingered it
<mvo> Kamion: hm, right
<infinity> Kamion : it works for me if I purge back to a clean chroot and reinstall libqt3-mt-dev/mesag-dev again.
<infinity> Kamion : Same as the buildds, which I purge down to a clean chroot regularly.
<pitti> infinity: my security uploads are not built by i386...
<Kamion> infinity: ok
<infinity> pitti : i386 is a bit backlogged.  Should clear up shortly.
<pitti> ok, thanks
<infinity> pitti : I have one buildd offline for bootstrapping biarch stuff and another was offline debugging LiveCD issues, that's all.
<infinity> And.. I'm not actually sure what the other is up to.. <goes to check>
<pitti> infinity: ok, that's fine, just wanted to point it out if it had been a serious problem :-)
<infinity> Oh, building OpenOffice.  That'll kill anything.
<Lathiat> heh
<infinity> Kamion : Also, hal/amd64 died differently this time.
<infinity> Kamion : Completely unrelated to dpkg.
<Kamion> gar
<Kamion> mvo: I've accepted it for now since FF's today, but I think you might want to consider merging those packages again
<infinity> Kamion : I'll make someone else care about it.  I don't want to distract you from fixing my dpkg woes. ;)
<mvo> Kamion: ok, sorry for that. I will have to do another upload today, should I just merge it then?
<Kamion> mvo: that's fine, no problem
<setite> anyoen have an evdo card
<setite> im struggling to get mine to work on hoary
<DanielN> does someone know about libiw27?
<DanielN> it's broken i think
<Kamion> in breezy, use libiw28
<DanielN> ah
<Kamion> libiw27 is gone
<DanielN> then the debootstrap script mentioned in the wiki is wrong for breezy
<DanielN> DebootstrapChroot
<DanielN> but thanks Kamion 
<DanielN> someone should fix that
<Lathiat> DanielN: erm
<Lathiat> i go debootstrap breezy dir/ file:///home/lathiat/ubuntu
<Lathiat> and it works?
<DanielN> which debootstrap version are you using?
<setite> has anyone tested EVDO mobile modems under linux?
<Lathiat> setite: There all different. This is not a user support channel, it is for discussion about development of ubuntu, Please see #ubuntu for user support, for that sorta thing you probably wanna ask google.
<DanielN> argh
<DanielN> there are several more errors in that damn script
<Kamion> DanielN: no, there aren't
<Kamion> DanielN: you just can't use it with hoary's debootstrap package
<setite> i know where the support channel is.. i was just hoping there was someone in here who had one and could help.. thanks
* Lathiat has 0.3.1.4ubuntu4
<DanielN> Kamion, i don't use this one
<DanielN> i use the one told on wiki.ubuntu.com/DebootstrapChroot
<pitti> grrrr, this crashing ffox drives me crazy
<DanielN> will build an UML machine on a hoary server
<Simira> what is claire's nickname?
<Kamion> DanielN: oh that's kind of ancient, just build the version in breezy
<Kamion> DanielN: you should always use the current version in breezy
<DanielN> ok, so i run breezys debootstrap on hoary then?
<Kamion> DanielN: rebuild breezy's debootstrap package for hoary
<Kamion> actually, no, that's unnecessary now isn't it
<Kamion> just grab the .deb from breezy
<Kamion> I'll update the wiki to say that
<DanielN> ok, do that
<DanielN> and thanks for your hints ;)
<Kamion> DanielN: wiki updated
<DanielN> :)
<Kamion> thanks
<DanielN> np
<DanielN> thanks to you
<Amaranth> seb128: pyxdg 0.15 is out
<omer> did anyone here understanding in BusyBox? (ash)?
<seb128> Amaranth: cool, thanks
<infinity> pitti : Those missing builds should be rolling in.
<pitti> yay
<pitti> ah, pizza appointment...
<doko> carlos: ping
<carlos> doko, in a meeting sorry
<doko> Kamion, mdz: ok to upload a new l-r-m with updated avm modules for i386 and amd64?
<Zomb> are there any jigdo files for the Hoary DVD images?
<Zomb> eh, forget it, I found a DVD from the LinuxTag
<Lathiat> hehe
<elmo>         find /etc -name mediawiki.conf -exec rm -rf {} \; ;
<elmo> classy
<pitti> urgh
<ogra> elmo, thats only tuned the apache config....
<mbreit> elmo: could you sync bacula from debian unstable please? it fixes ftbfs and unmet dependency in breezy. thanks!
<siretart> elmo: could you please sync pong2 from unstable? 
<pitti> elmo: please sync heartbeat
<siretart> elmo: and besides, do you any news of the linode vserver for revu?
<pvanhoof> gnome-app-install-data wasn't installed after installing gnome-app-install
<elmo> ogra: no, it's ANY FILE called mediawiki.conf in ALL OF /etc
<pvanhoof> [breezy] 
<pitti> ogra: and mind the merciless -rf
<ogra> elmo, but mediawiki never installed such files... 
<elmo> ogra: then why is mediawiki removing them?
<ogra> it only stars with this package...
<ogra> probably because duck had one that installed the file in /etc ... which is wrong...
<ogra> starts to exist ... even
<ogra> original medaiwiki only stores settings and configs in the www root....
<ogra> elmo, would you feel better if i comment it out ? it does nothing anyway ...
<elmo> ogra: dude, this isn't about me feeling better, that's quite obviously a bug
<ogra> oki
<ogra> i'll fix t then...
<elmo> mbreit/siretart/pitti: done
<pitti> thanks
<pvanhoof> [breezy]  Problem: Most of the nautilus "Open with" settings are wrong
<elmo> siretart: we're still waiting on availability from linode, I'm afraid
<mbreit> elmo: thanks!
<seb128> pvanhoof: what do you mean "wrong"?
<pvanhoof> seb128, for example if I open with gedit, it doesn't open the file in gedit
<pvanhoof> and the default has been set to Firefox for .txt files
<pvanhoof> stuff like that
<pvanhoof> some are correct ..
<seb128> $ grep "text/plain" /etc/gnome/defaults.list
<seb128> text/plain=gedit.desktop
<pvanhoof> like pdf was correct
<seb128> what do you mean?
<seb128> "gedit file.txt" doesn't run gedit?
<seb128> "<pvanhoof> seb128, for example if I open with gedit, it doesn't open the file in gedit"
<pvanhoof> trying
<pvanhoof> hmm ok, not it does work :)
<pvanhoof> now
<seb128> NOTABUG
<ogra> elmo, any other things you spotted before i upload the new versiomn ?
<elmo> ogra: no
<ogra> yay
<pvanhoof> :p
<pvanhoof> indeed. now it's correct
<pvanhoof> perhaps I just had to restart nautilus after some upgrade
<pvanhoof> It was last session. So nautilus effectivly restarted since then
<doko> elmo: please can you remove atlas, blas, lapack, lapack99 and sync ghemical ?
<siretart> elmo: thanks for sync and update on linode.
<pitti> bah, I can't work like this
* pitti reboots to i386 to get a working browser
<janimo> elmo please sync ecosconfig,thanks
<elmo> janimo: please read my email
<madduck> jamesh: interesting blog entry. did you see mine (planet.debian.org)?
<omer> Hello
<omer> I have controller integrated by ATI SB400
<madduck> jamesh: also http://blog.madduck.net/debian/2005.08.10-arch-packaging.html
<omer> Which module shuld I load that it recognize by the installer?
<jamesh> madduck: I don't read planet debian much.  Is that the URL of your entry?
<madduck> one of the two. yes
<madduck> jamesh: http://blog.madduck.net/debian/2005-08-11-rcs-uploads.html is the other
<janimo> elmo, haven't got reply  but just got ACCEPTED from Katie. Thanks
<elmo> janimo: the reply says, please: a) ask for/about source packages not binaries and b) specify the version you want
<janimo> elmo, indeed I saw there are two versions of binaries on debian, but I thought a sync brings the newest source.
<janimo> I am confused I admit,but that tool is only used on x86 anyway AFAIK
<elmo> janimo: the point is sync works by source package; a) if you ask for a binary, I have to go and work out what source package to tell my tool [not much work, but it adds up across all sync requests] , b) if you ask for a binary, it's not obvious you know the other packages are being synced and have checked the implications of it
<janimo> actually I thought that what I asked for was a regular sync, did not notice differences.(binary only package?)
<janimo> just saw it has wxwidgets depends wrong and needed to correct that without an ubuntu1 or build1 patch
<janimo> indeed now I see what you mean
<janimo> I assumed the source has the same name, sorry bout that I'll be more careful next time
<janimo> thanks for the trouble
<pef> last upgrade render breezy unbootable (error on init :/)
<pef> somebody has this problem ?
<\sh> ok..hoary + portege r200 network card...== unusable
<ogra> \sh, use breezy... thats what you got this baby for ;)
<\sh> ogra: yes...this is easy now...pxeboot is working...
<\sh> what about daily cd? installable or should i use last colony?
<\sh> ok...trying colony 2
<Lathiat> mjg59: why is suspend to ram off by default? doesnt work often?
<ogra> Lathiat, i'd guess 80% .... 
<Lathiat> ogra: and to disK?
<ogra> 98 ? dunno, just guessing
<Lathiat> hm ok
<mvo> Kamion: permission for a update-notifier upload? it works correctly with the new gamin now (new gamin changed the meaning of a field in the FAMEvent structure under certain conditions and that breaks u-n)
<bddebian> Morning
<highvoltage> morning (good afternoon from +2GMT
<bddebian> Heh
<Lathiat> evening here :) +8
<Lathiat> heh that looks like some kinda stupid smiley
<bddebian> A goatee ? ;-)
<mvo> Kamion: and a gnome-app-install upload that fixes some missing icons, the package split and adds some support for mimetype searching
<omer> can you help me with kernek modules?
<janimo> what are the criteria for a source package to be deletable from the archives?
<omer> *kernel
<paolo> Is it a problem if a package installs gcc-4 and another gcc-3?
<Lathiat> no
<paolo> OK, I tought mplayer needed some update because it want to install gcc-3.3-base.  Thanks.
<\sh> hmmm
<mbreit> btw: who is responsible for adding/deleting NFUs on the buildds?
<\sh> to test if a dual install of ubuntu and windows xp is possible...well...toshiba delivered only a recovery dvd with it
<\sh> so it will delete all stuff from the hd when it's installed
<ogra> have fun partitioning :)
<azeem> how did y'all install Ubuntu on you X40s without a CD-ROM?
<\sh> is it possible to shrink ntfs partitions with the fdisk util?
<\sh> https://wiki.ubuntu.com/Installation/LocalNet
<\sh> mjg59: thx btw for this tip...
<ogra> azeem, PXE magic :)
<\sh> mjg59: but there is one mistake in the default config 
<azeem> ogra: cool
<ogra> :)
<\sh> filename="pxelinux.0"; should be filename="ubuntu/install/netboot/pxelinux.0";
<\sh> ok another try with breezy...rb
<\sh> brb
<infinity> mbreit : I am.
<mbreit> infinity: i have fixed noteedit in breezy, but it's on NFU...
<Robot101> Kamion: memdisk at http://syslinux.zytor.com/memdisk.php will let you load a grub floppy as an initrd
<infinity> mbreit : So that means you've updated libtse3?
<\sh> ok...default breezy colony 2 install is not possible...network device is not recognized
<\sh> explanation is on http://glozer.net/dynabook/dynabook.html#ethernet
<mbreit> infinity: no, i did not...? it builds fine in pbuilder on amd64...
<mbreit> infinity: i fixed building with gcc4... i have not noticed any other problems..
<\sh> where can I put an additional driver for the NICs into the install procedure? or do I have to change some seeds?
<infinity> mbreit : It was waiting on libtse3 to go through the C++ ABI transition.  Apparently it did so, and no one informed me.
* infinity stares at \sh.
<mjg59> mdz: That's correct - Jeff is working on that now
<omer> there is chanel to kernel question?
<mjg59> Lathiat: Yup
<Lathiat> mjg59: ok
<Lathiat> mjg59: be nice if there was an 'easier' way to enable it. :)
<mjg59> Lathiat: There will be in Breezy
* mjg59 goes out
<Lathiat> mjg59: and i can reported it workign on a HP nx6120 on hoary
<Lathiat> mjg59: if thats of any use, friends got it working great on theirs. :)
* ogra offers \sh sme sesame to change against \sh's poppy seed :)
<\sh> infinity: did I touch it? 
<mbreit> infinity: thanks for looking at it...
<ogra> some even
<infinity> \sh : Well, you've been my only point of contact to MOTU for the C++ transition, so I assumed you'd keep pinging me baout updates to frozenapps. :)
<\sh> infinity:  -- Oliver Grawert <ogra@ubuntu.com>  Wed,  8 Jun 2005 13:35:55 +0200
<ogra> infinity, the first libtse tranitione is ages ago... it was one of the firts packages of the abi transition
<\sh> infinity: ogra is boss motu...so blame him...I gave u all infos i had ... adn I'm working on the rest like an idiot
<\sh> *evilsmile*
<ogra> infinity, we have lists on the wiki for the transition... why was tse3 frozen ?
<infinity> mbreit : Anyhow, noteedit is unfrozen.  Should build soonish.
<ogra> oh, and a lot of transition bugs in bugzilla
<doko> infinity: please requeue OOo2 on i386, dpkg segfault ...
<\sh> ogra: what's the best way to put a new driver into the d-i...just the case, I don't have a external cdrom or floppy drive
<infinity> ogra : All C++ apps were frozen, and unfrozen as their depending libs became available.  It's a manual thing, though, so when people don't tell me, I don't always check.
<infinity> doko : YAY.
<ogra> infinity, ah... ok...
<\sh> infinity: but I didn't see it on the frozenapps.txt..tse3 it should give me some hints..but nothing
<ogra> i thought it was a general freeze that was dropped after the lib transition was done completely....
<infinity> \sh : I just removed it.
<infinity> ogra : The transition isn't done.
<ogra> i know
<\sh> infinity: no..I never saw it, when doko gave me once the url earlier on..i didn't see it on it..
<mbreit> infinity: thanks
<infinity> ogra : Still waiting on libace, libyehia, libxdb, libwaili and libcrypto__
<omer> Does ubuntu kernel suprut ATI SB400?
<infinity> \sh : Curious, it was on my list.  Oh well, no big deal.
<ogra> i havent had the time to look recently...
<infinity> doko, seb128, daniels : Apparently your packages not building on hoary-updates is a feature, not a bug.  They need manual approval by Kamion/mdz.
<HiddenWolf> infinity: lol!
<seb128> infinity: and they are not noticed on upload? it was waiting for like 3 weeks
<infinity> doko : Also, OOo2 is already (re)building on i386.
<infinity> seb128 : You may want to ping them.
<seb128> I ping mdz by bugzilla, he accepted the patch and I commented saying I did the upload
<seb128> k, next time I'll ping on IRC too :p
<seb128> thanks infinity
<seb128> s/ping/pinged/
<Amaranth> seb128: what would you say to putting gnome-menus 2.11.91 in backports? :)
<seb128> I don't use backports
<Amaranth> surprisingly it built fine against hoary and ran
<seb128> fcrozat made a patch to make it work with gnome-panel 2.10 for mandriva
<seb128> so I guess there is some issues
<Amaranth> <Layout> didn't work (odd) but the bugs in 2.10.1 were fixed and autoupdating worked (thanks to libgamin-dev build-dep)
<Amaranth> where is this patch?
<seb128> ask to him on #gnome-hackers
<seb128> he keeps speaking about that
<Mithrandir> Kamion: I thought it was in the desktop seed already?
<\sh> ok...will have a look later on this bloody ethernet problem...now I'm going :)
<Simira> Mithrandir : get home!
<doko> infinity: mdz did approve it in 7292
<infinity> doko : I believe it requires manual *intervention*, not just approval.
<pitti> mvo: oh, so you already sent the n-d patch upstream?
<mvo> pitti: only my patch about the arrow placement
<pitti> mvo: yes, that's what I meant
<pitti> mvo: my patches are already upstream, he prepares a 0.2.2 tarball, I tested it already
<mvo> yes, I wonder if he will like it. it looks a bit crude to me and to get it right there will be a lot more needed
<mvo> he hasn't answered me yet, may I scared him away :)
<pitti> he didn't answer to my last mail either, probably just busy (he is very cooperative and answered to my other mails)
<carlos> doko, ping
<mvo> oh, ok. nice
<pitti> Hi carlos 
<carlos> pitti, hi
<doko> carlos: pong
<ogra> whats wrong with the archive... ? i cant pull any source file and the builds break seem to too...
<carlos> doko, I'm ready to listen to you :-)
<ogra> hmpf...
<pitti> ogra: apt-get update seems to complain about wrong md5sums
<ogra> yep
<ogra> i also had 404s for the Package.gz files
<doko> carlos: just wanted to know, where I can update the wiki, and when we can start the first tests ...
<doko> pitti: where do you write the language data during a build?
<pitti> doko: you mean where a package stores po and pot files? anywhere in the source dir
<doko> pitti: where do you write them, when the package is built?
<pitti> doko: pkgstriptranslations tars them up into ../package_version_translations.tar.gz
<doko> pitti: in the parent dir?
<pitti> yes, where the debs, dsc, changes, etc. land
<doko> ok, and what does happen then?
<carlos> doko, pitti https://wiki.launchpad.canonical.com/RosettaFirefoxAndOpenOfficeSupport
<carlos> doko, pitti if you cannot edit it, tell me so I can ask extra permissions for you
<doko> pitti: ?
<ogra> debian/rules:11: /usr/share/cdbs/1/rules/simple-patchsys.mk: No such file or directory .... hmm... interesting
<pitti> doko: the buildd moves them to rookery:~lamont/translations
<carlos> doko, and Rosetta imports the .pot and .po files
<pitti> doko: rosetta and my scripts collect the tarballs from there
<pitti> ogra: missing cdbs b-dep?
<pitti> carlos: thanks
<ogra> pitti, haha
<doko> is the buildd stuff a laminity thing?
<pitti> doko: lamont set it up
<carlos> laminity?
<pitti> doko: why?
<ogra> pitti, the package is from DUCK, you wont find even traces of debhelper in there ;)
<pitti> carlos: lamont/infinity
<doko> pitti: ???
<carlos> oh!
<doko> pitti: because I have to export the damsn GSI files?
<pitti> doko: I mean, is there a bug in this process?
<pitti> aha
<carlos> doko, hmmm I thought we made clear we don't need to export the gsi files....
<ogra> laminity ? 
<ogra> a new description for buildd masters  
<ogra> ?
<doko> carlos: huh?
<carlos> doko, that's what we talked about importing first release without getting Rosetta imports
<pitti> doko: why isn't exporting the po files enough? (and pot)
<carlos> and reupload a -2 version with the updates and generating the .gsi on build time....
<doko> pitti: I DON'T HAVE ANY PO/POT FILES TO EXPORT
<carlos> I think we are having here a misscomunication...
<doko> carlos: did you read, why I did split the sources into two parts?
<pitti> doko: I though that was the mere point of using pootle???
<carlos> doko, dude, we agree on a way to prevent the .gsi export last week
<carlos> and it's in the spec
<carlos> and you agreed
<doko> pitti: all the conversions are done outside the build process
<carlos> what's the problem now? I mean, what am I missing?
<carlos> doko, you do it by hand?
<carlos> before the source upload?
<pitti> doko: why can't you call pootle in debian/rules?
<pitti> doko: (that was the idea actually)
<pitti> carlos: the spec is heavily truncated
<doko> pitti: you told me, that I have to include the imported language data in the diff. How do you do that from inside debian/rules ?
<carlos> pitti, really?
<carlos> hmm, let me check
<pitti> doko: I think we have a gross misunderstanding here
<pitti> doko: so again, the oo.o2 source package can call pootle in debian/rules to generate pot/po files, right?
<pitti> doko: this will create po files in the source pkg build directory
<pitti> doko: it is not necessary to include the po files in the package diff
<carlos> pitti, fixed
<pitti> doko: it is just necessary that they are present in the source build dir before dh_builddeb
<pitti> ^ this will call pkgstriptranslations, which collects the po files in a tarball
<doko> pitti: please don't include the conversion in the build process. we never did specify this. the extraction takes about 5min for each language on a fast machine
<pitti> doko: uh, doing it on the buildd was at least my original idea
<doko> pitti: I know, I don't need to include the po/pot files in the diff.
<pitti> doing it manually before each upload won't save you time, right? and it's error prone
<pitti> doko: we specified it: "#
<pitti> New script that uses the oo2po script from pootle, it will be executed in the openoffice.org2-l10n tarball so it creates a po/ directory storing there the .pot and .sdf files and a .po file per language available on that sourcepackage. This script will be executed on build time, just before the extract_po script.
<pitti> #
<pitti> "
<pitti> bah, silly ffox paste
<doko> no, I don't want to do it manually. I'm building the ooo2-l10n source package automatically from the ooo2 source package and the data provided from rosetta
<doko> carlos: thanks, the overview in the wiki is now more complete.
<carlos> doko, the changes done after your update came from pitti
<carlos> I didn't touch it yet ;-)
<infinity> Hrm, am I going to have to add a nick hilight on "laminity" now?
<Mithrandir> \lafty :-P
<infinity> I don't recall a LaTeX code for that one, you lose.
<doko> pitti: OOo2 doesn't work with pkgstriptranslations, there's nothing to strip besides some menu files
<carlos> doko, pitti please, could you agree on a procedure to follow on your side for OO and update the wiki so it's well documented?
<pitti> doko: that's why pottle is supposed to generate pot/po files on the buildd
<pitti> doko: why isn't that possible?
<pitti> we do it for all other packages
<pitti> carlos: btw, could you already try ffox po extraction?
<mjg59> Hm. So, on this machine, grub fails to work, X screws itself and the wireless does nothing
<carlos> not done yet, I was finishing with the fixes we need to be able to export language packs
<carlos> I will start with that today
<pitti> carlos: oh, export works now?
<infinity> mjg59 : Sounds like a success.
<carlos> pitti, the code that will fix them is done
<doko> pitti: it's a nightmare to debug, if something goes wrong. the conversion can be done offline. there's no reason not to do it offline
<carlos> pitti, now it's running on our test system
<carlos> but will take a while
<rob^^^> anyone else having problems with today's liveCD?
<carlos> so I think the data will be fixed on Sunday - Monday
<dieman> fucking hell
<dieman> i didn't know bazaar tracked inodes
<pitti> doko: ok, then shipping the po files in the package diff.gz is fine, too
<dieman> i moved to another disk
<doko> pitti: no, no po files in the diff.
<luis_> rob^^^: what kinds of problems?
<infinity> dieman : Yes, it's irritating.  Can't relocate working copies to other computers either.
<rob^^^> dunno, Buffer IO errors on virtual PC
<pitti> doko: hm, but if they aren't in the package diff, nor generated at build, where do you want to generate and put them?
* rob^^^ resets and tries again
<doko> on rookery, or somewhere else. where do you build the language packs?
<dieman> infinity: heh
<pitti> doko: I build them on rookery
<carlos> pitti, doko do we have Ubuntu packages for pootle?
<pitti> carlos: yes
<doko> carlos: apt-get is your friend
<dieman> infinity: well, anyhow, im just going to check it out, remerge the upstream im working with, and then copy back over the changes i was making to some conflicts
<pitti> doko: so if you want to generate them on rookery, I can grab them from there, too
<allee> siretart: ping 
<doko> pitti: I think, rosetta needs to get them. why do _you_ need them?
<pitti> doko: ok, right; I could directly import them into langpacks, but right, Rosetta needs them for import as well
<allee> doko: ping  capi und PCMCIA.
<rob^^^> first error is attempt to access beyond end of device
<rob^^^> hdc: rw=0, want=1279776, limit 970096
<allee> doko: I've got my B1 PCMCIA working but it's a bit hackish.  Do you have already any plans how to support PCMCIA?
<doko> pitti: ok, so I have to ask lamont/infinity how to move the files I need to rookery?
<doko> allee: later please
<pitti> doko: which files do you need? you mean, install pootle on rookery?
<allee> doko:'k
<doko> pitti: the sdf files, as described in the summary
<doko> s/summary/overview/
<pitti> doko: if you really need build-time generated files for the extraction, this seems really, really hackish to automatically transfer them
<pitti> doko: but yes, that would be laminity
<doko> pitti: why is it more hackish than transferring the po files?
<pitti> doko: not more, but would double the hack :-)
<pitti> doko: in fact there is a spec to remove the existing hack
<pitti> it's just not yet implemented
<infinity> pitti : Can't you just special-case OOo2 in pkgstriptranslations so you can grab the files doko needs?
<doko> pitti: and you propose to use your hack and add another one instead of doubling it ;-)
<pitti> doko: another idea: why not build ooo on concordia and generate pos there?
<infinity> pitti : If we're going to talk about hacks on hacks, I'd rather not be shipping even more out-of-band stuff if we can avoid it.
<pitti> infinity: of course I could
<infinity> (I'd really prefer is we were dumping this stuff in the .changes, but we're Not There Yet)
<infinity> s/is/if/
<pitti> infinity: we already talked about that spec, just ENOTIME, I guess
<infinity> Yes.
<infinity> Hence "Not There Yet."
<doko> pitti: what do I win with building on concordia?
<pitti> doko: I still don't understand why you don't want to call pootle on the buildd, but if there are reasons, I can change pkgstriptranslations to grab ooo files. So you need find -name "*.sdf"?
<pitti> doko: conc has build chroots, rookery not :-)
<carlos> doko, ok, thanks
<pitti> doko: ok, if exporting *.sdf is your preferred solution, I'm going to change pkgstriptranslations
<doko> pitti: how do I know, which languages should be built? You have to change the build code
<doko> pitti: where do you expect these sdf files?
<pitti> doko: anywhere, I'll just do a find -name "*.sdf" -exec cp ...
<doko> pitti: even in the source?
<pitti> (preserving the dir structure, of course)
<dieman> heh
<pitti> doko: yes
<dieman> gnu diff and its millionths of a second resolution
<doko> no, that's wrong
<pitti> doko: please don't expect pkgstriptranslations to know about packaging details
<doko> pitti: just search in debian, that's enough
<pitti> doko: copying files into the tarbal is fine, but I can't analyze control files in it
<pitti> doko: hm?
<doko> copying files into the tarball?
<doko> lets talk on the phone ...
<pitti> ok
<pitti> oh wait
<pitti> phone is broken ATM
<pitti> I call you
<doko> :-))
<Mithrandir> doko: is -10 uploaded?
<Kamion> mvo: yes and yes
<Kamion> Mithrandir: not for amd64 - but I'll take that as a "yes, please add it"
<Mithrandir> Kamion: yes, please add it. :-)
<Kamion> done
<Mithrandir> thanks
<ogra> heh, edubuntu-meta looks like the amd64 world imploded ...
<Kamion> http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html doesn't show particular amd64 damage
<mvo> Kamion: thanks
<Kamion> argh, what's up with gnome-python-extras?
<ogra> Kamion, see the changelog ... nearly all of minimal dissapeared... (i dont care for amd64 currently, so i dont mind to regenerate tomorrow..)
<Kamion> it was probably just a transient error when you updated; you should have thrown that away and tried again
<Amaranth> Kamion: gnome-python-extras needs to be rebuilt against libwnck18
<Kamion> ogra: please fix it today rather than tomorrow, if possible
* ogra tries to regenerate
<Amaranth> Kamion: same with serpentine
<Amaranth> well, serpentine uses g-p-e
<ogra> hmm
<ogra> 207	Preparing to replace libglu1-mesa-dev 6.2.1-5ubuntu5 (using .../libglu1-mesa-dev_6.2.1-5ubuntu5_amd64.deb) ...
<ogra> 208	Unpacking replacement libglu1-mesa-dev ...
<ogra> 209	E: Sub-process /usr/bin/dpkgdpkg-deb: subprocess paste killed by signal (Broken pipe)
<ogra> 210	received a segmentation fault.
<Amaranth> yay!
<ogra> thats how g-p-e looks in the amd64 buildlog
<ogra> ppc for comparison:
<ogra> 2063	grep: /usr/lib/libdbus-1.la: No such file or directory
<ogra> 2064	/bin/sed: can't read /usr/lib/libdbus-1.la: No such file or directory
<ogra> 2065	libtool: link: `/usr/lib/libdbus-1.la' is not a valid libtool archive
<ogra> 2066	make[3] : *** [nautilusburn.la]  Error 1
<Amaranth> *groan*
<ogra> i thought that was fixed ysterday
* Amaranth blames daniels for everything ;)
<Kamion> I'm looking into the dpkg segfault
<ogra> at least on ia64 you have a fine build :)
<Kamion> in my negative available time
<ogra> hmm, dpkg: serious warning.... that doesnt sound good
<infinity> libgl1-mesa contains no files?
<infinity> "THE WORLD IS BROKEN BECAUSE I SEGFAULTED EARLIER AND NOW I'M VERY CONFUSED!"
<infinity> ogra : That message?
<ogra> yay, my next changelog will have the same size :) just inverted the added/removed part in front
<ogra> 186	dpkg: serious warning: files list file for package `libglu1-mesa-dev' missing, assuming package has no files currently installed.
<ogra> exactly ...
<infinity> ogra : Which buildd?
<infinity> Kamion : Oh dear god, please fix it now.  I'll buy you a pony.
<ogra> 186	dpkg: serious warning: files list file for package `libglu1-mesa-dev' missing, assuming package has no files currently installed.
<ogra> ergh
<ogra> Automatic build of gnome-python-extras_2.11.4-0ubuntu2 on yellow by sbuild/amd64 1.170.5
<ogra> ^^ yellow
<mjg59> Hrm. I'm attempting to resize an NTFS partition in the installer. The partitioner keeps claiming it's the original size afterwards.
<Lathiat> assumedly its resizing th entfs and not the partition then?
<Kamion> infinity: it's in does_replace(), anyway
<mjg59> It ought to do both
<mjg59> But there's no DMA for the chipset in the installer
<Kamion> D000040: does_replace new=libglu1-mesa-dev old=x11proto-gl-dev (0:1.4+cvs.20050524-3)
<Kamion> D000040: does_replace ... no
<Kamion> D000040: does_replace new=x11proto-gl-dev old=libglu1-mesa-dev (0:6.2.1-5ubuntu5)
<Kamion> E: Sub-process /usr/bin/dpkg received a segmentation fault.
<Kamion> I'm wondering if it's deeply confused by the two packages replacing each other
<mjg59> Kamion: Any idea why ntfsresize would appear to fail?
<Kamion> mjg59: not right at the moment I'm afraid
<Kamion> I'm swamped
<mjg59> Oh. Hitting "Finish partitioning and write changes to disk" does nothing. I think it's broken.
<Kamion> /var/log/partman should help but unfortunately I don't have time to analyse it just now
<mjg59> Ah. ntfsresize has spewed errors all over the place.
<Kamion> possibly also /var/log/{syslog,messages}
<pef> re
<infinity> Kamion : That does sound deeply confusing indeed.
<infinity> Kamion : And easily fixed, since I intend to remove the file overlaps in mesa in the next upload.
<infinity> Kamion : You think that'll make it go away and stop hating me?
<infinity> Kamion : (Obviously, remove the overlaps AND the Replaces control field, not just the former)
<Kamion> infinity: I'm digging into it a bit more
<infinity> Kamion : Still, it should probably issue an error or something in such confusing situations. :)
<siretart> allee: pong
<Kamion> infinity: actually they don't replace each other, I was just being stupid
<infinity> Oh.
<infinity> Well, so much for that.
<allee> siretart: hi. I'm the one pestering you about revu today;)
<infinity> I still intend to tear out half the overlaps and replaces.
<infinity> Which will probably "fix" it.
<infinity> Given the incestuous relationship between xorg and mesa, I assumed the bug would be in the Replaces handling.
<allee> siretart: s/revu/revu reviewer/
<siretart> allee: ah, hi. I'm just reading you email ;)
<allee> siretart: sorry for the mess
<siretart> allee: no matter
<infinity> Argh.
<infinity> Kamion : Do you have an apt cache directory full of the packages you need to reproduce this?
<infinity> Kamion : I'm about to start mangling packages in an attempt to work around it in the archive, so...
<Kamion> infinity: yes
<Kamion> infinity: I'm just in the middle of a debugging build of dpkg now
<Kamion> I also have a local mirror which won't update for a while
<Kamion> if need be, I can make it not update tonight
<doko> carlos: I did talk with pitti about the extraction at the phone. you'll get the strings into rosetta ...  Is there a way for you to import some strings, but not present them for translation? i.e. the OOo2 help cannot be built at the moment, and so it would be some waste of time to translate it
<Amaranth> seb128: did you ever add smeg to the seeds?
<HiddenWolf> seb128, is gnome network tools supposed to keep an accurate count of incoming and outgoing traffic?
<BenC> any kernel-package maintainers here?
<seb128> Amaranth: yep, to desktop, why ?
<seb128> HiddenWolf: no clue
<Amaranth> seb128: just checking :)
<HiddenWolf> seb128: network tools has it's 'interface statistics' in the main window, that's why I ask.
<Kamion> BenC: jbailey should be around in a bit, I think
<seb128> HiddenWolf: that's probably the same as ifconfig
<carlos> doko, I'm working on a patch to "hide" some potemplates that are useless, we could use that
<infinity> HiddenWolf : Those counters wrap.
<carlos> doko, so the import is done, but the user will not see them until you ask me to activate it
<HiddenWolf> seb128: I figured. 
<carlos> doko, is that enough?
<infinity> BenC : kernel-package the package, or kernel-packaging in general.
<doko> Kamion: is it ok to upload a new l-r-m with a new driver version of the avm isdn drivers (and new drivers for amd64)?
<mjg59> Kamion: Ok, that was just caused by a corrupt filesystem
<infinity> BenC : ?
<HiddenWolf> infinity: one way or the other, it's off by a margin.
<mjg59> The installer didn't seem to pick it up, though. I'll file a bug?
<doko> carlos: sounds ok
<infinity> BenC : Either way, you probably want to ping #ubuntu-kernel
<infinity> HiddenWolf : Mine shows the same stats as ifconfig.
<Kamion> (gdb) p dep->list->version
<Kamion> $31 = {epoch = 268361688, version = 0x696e6520 <Address 0x696e6520 out of bounds>, revision = 0x58496e70 <Address 0x58496e70 out of bounds>}
<infinity> HiddenWolf : Oh, actually, today it doesn't. It's off by a factor of 2.  Odd.
<HiddenWolf> infinity: I know for a fact that I've downloaded a multitude of what ifconfig is reporting
<Kamion> doko: what does that get us?
<Kamion> mjg59: please
<Treenaks> HiddenWolf: ifconfig wraps around I guess?
<Kamion> infinity: ^-- point of segfault
<[SemTeX] > HiddenWolf: 32-bit counters...
<doko> avm support on amd64, more stable drivers on i386
<[SemTeX] > once you're over ~4GB, it will reset...
<Kamion> doko: ok, if you've tested it
<doko> it only effects the avm drivers, nothing else.
<HiddenWolf> I guess, that makes the statistics useless tho.
<infinity> Kamion : Huzzah.
<infinity> HiddenWolf : Those stats are generally useless, yes.
<HiddenWolf> If they're useless, why are they there?
<infinity> "Just cause"
<carlos> doko, I suppose that my patch will be applied in a week and a half
<carlos> doko, so perhaps it will appear for a couple of days
<carlos> in the mean time I can put there a "deprecated, don't use" message
<HiddenWolf> infinity: wouldn't it be a good idea to either make them useful or remove it from network tools?
<infinity> HiddenWolf : Probably.
<HiddenWolf> I'll go file a bug then.
<carlos> doko, pitti can I play with hoary's firefox packages or are they too different from breezy? (about language packs)
<doko> carlos: not my thing
<pitti> carlos: hoary has exactly the same upstream version now
<carlos> pitti, ok
<carlos> thanks
<Nafallo> hmm
<pitti> doko:  pkgstriptranslations_14_source.changes ACCEPTED
<Nafallo> pitti, carlos: then it might be good with those two translations to be synced automagically?
<Nafallo> i.e. firefox and firefox :-P
<pitti> this will - sort of - happen in the future
<pef> elmo: hi
<Nafallo> oki, kewl
<pitti> mdz: so we'll have another breezygoals meeting tonight?
<carlos> Nafallo, we are working now on that so it happens like with the other packages.
<Nafallo> carlos: other packages?
<ogra> hmm, amd64 buildd segfaults constantly, x86 seems completely gone now
<infinity> ogra : Sheer luck.  Kamion's hunting the segv right now.
<ogra> heh.... and hes standing on the x86 buildd to look into amd64 ?
<ogra> s/hes/he's
<Kamion> infinity: bingo. you owe me a pony.
<ogra> heh
<Kamion> Unpacking libglu1-mesa-dev (from .../libglu1-mesa-dev_6.2.1-5ubuntu5_powerpc.deb) ...
<Kamion> Replaced by files in installed package x11proto-gl-dev ...
<Kamion> straightforward uninitialised memory while copying the forward dependency chain during unpack
<elmo> we should run a buildd under valgrind
<Kamion> ironically, the segfault was triggered by a new debug message
<Kamion> it would've been fine if the debug message hadn't been there, because everything else checked verrel != dvr_none before looking at version
<infinity> Kamion : Your pony will be in the mail the moment a fixed dpkg builds.
<infinity> Kamion : That also backs up my assertion that fixing the file overlaps between x11proto-gl-dev and libglu1-mesa-dev would have cleared it up, but I'm much happier to see the bug fixed.
<Nafallo> infinity: you should have promised him a cow. those can be found in inflatable format :-).
<Kamion> it was triggered by unversioned Replaces
<Kamion> 'cos those never happen at all
<infinity> Yeah, and that will be fixed in mesa/x11proto on my next upload.
<infinity> Cause it looks very evil/wrong as it is now.
<Kamion> probably only happened when hitting the new "don't break when installing a package that is replaced" code
<infinity> Still, segv bad.  segv gone == good.
<infinity> Kamion : Have you uploaded a fixed package already?
<Kamion> just done
<Kamion> well, doing
<Kamion> wanna leave the mesa/x11proto uploads for a bit, just to make sure the problem goes away?
<infinity> Kamion : Yup, I'm just fixing them up locally.
<infinity> Kamion : They won't upload until tomorrowish.  I'll let the buildds chew on your changed dpkg overnight, with a mass give-back for good measure.
<carlos> pitti, bad news, moz2po creates lots of .pot files, so we will need to hack the script a bit
<carlos> like oo
<pitti> carlos: just cat'ing them won't work?
<carlos> pitti, to import them into Rosetta, yes
<carlos> pitti, the problem is the return path
<infinity> Hey, lookie there, the i385-amd64 biarch toolchain is finally done bootstrapping.
<carlos> pitti, we don't know which messages come from which files
<pitti> oh, po2moz needs split files, too?
<infinity> Well, finally half done, anyway.
<carlos> pitti, I think so 
* carlos checks...
<pitti> carlos: can't you quickly convert ffox to gettext?
* pitti ducks
<Amaranth> they don't use gettext?
<carlos> pitti, :-P
<carlos> pitti, don't think so ;-)
<carlos> pitti, hmmm firefox needs also the original files to get the language pack rebuilt...
<carlos> pitti, but it should not be a problem as the spec says that the same procedure applies to firefox
<pitti> carlos: it should be possible to sort that out with msgmerge, I guess
<pitti> carlos: i. e. generate the po files again and merge the relevant parts
<carlos> pitti, hmm good idea
<carlos> pitti, it's an easy and fast solution, yes
<jdub> mdz: ping
<carlos> pitti, I will play with the scripts a bit more and will dump my conclusions to the spec so you can review it tomorrow and see if it's doable on build time, ok?
<mjg59> Hm. The ATIXP IDE driver has failed to bind to the IDE interface on this machine, and hence I am without DMA
<mjg59> I think I need 2.6.12
<aigarius> infinity, thank for the mail, eased my mind. I was getting a bit tense - considering today being the final deadline and such. OTOH it did help me write faster :)
<Amaranth> wow i'm bored
<Amaranth> i just did a search for 'doc' in synaptic, went through the entire list of results, and installed about 100 of them
<jasoncohen> mvo, hi- so, update-notifier now has the ability to popup when an update is available? will you get a chance to allow it to differentiate between hoary-security/hoary-updates and backports?
<pitti> jasoncohen: that was the idea
<pitti> jasoncohen: I talked with mvo about this and we'll implement it that way
<jasoncohen> great
<jasoncohen> so the popup will only come up when it's security/bugfix or will it be an option?
<pitti> I agreed to offer an option to disable it, mvo?
<jasoncohen> yeah, does it have a close button so it can be easiy removed?
<pitti> jasoncohen: by default these popups remove automatically after 7 seconds, but in any case they do when clicking on them
<jasoncohen> ah, ok
<jasoncohen> pitti, so, if the popup comes up when the user isn't at the computer, they'll never see it?
<pitti> jasoncohen: I asked mvo to disable autotimeout for these security popups
<jasoncohen> good
<pitti> I think it makes sense in this case
<jasoncohen> yeah, because update-notifier doesn't necessarily update the apt cache when you're at the computer so you might never see the updates. this way, you know the user sees the popup
<mvo> pitti: I set the timeout to 60sec
<pitti> mvo: maybe disabling it completely would be suitable in this case?
<pitti> mvo: do you already offer to disable these?
<mvo> it's easy enough to do (disable it). it can't currently distinguish between backports and other updates (because of limitations of python-apt)
<paolo> note: on breezy the screensaver isn't "ubuntu-ed"
<jasoncohen> mvo, are you speaking of disabling the timeout or the popups themselves?
<mvo> jasoncohen: disabling the timeouts is very easy (but not done right now, only a big timeout is set). disabling the popups is implemented with a little blue action "Never show this message again"
<jasoncohen> ok
<mvo> isn't it already in the archive?
<jasoncohen> don't know- i'm running hoary
<mvo> I can add the needed support into pyton-apt, it's not too difficult, the problem is that today is feature freeze :)
<jasoncohen> so, you would have to do it today? how strict are the deadlines?
<mvo> yes, both the code for python-apt and update-notifier would have to be ready today (pretty much impossible). and I think we are pretty strict about deadline this time 
<pef> bye !
<jasoncohen> mvo, so, what can you get into breezy?
<janimo> ping doko
<mvo> jasoncohen: notifications are in (using libnotify), timeout can be removed without problem and "Never show this notification again" is in too. only the "show only security, but not backports" will not be ready
<doko> janimo: pong
<janimo> doko, pse didn't build I think it needs python-dev in BD
<jasoncohen> mvo, well, the most important stuff is already in. 
<janimo> spe
<jasoncohen> mvo, i tried to contact you earlier but i didn't see you online
<janimo> if it's in uni I can try fixing it
<mvo> jasoncohen: well, we will get it for breezy+1 then 
<doko> janimo: right, will fix it
<jasoncohen> mvo, ok
<mdz> morning
<mdz> jdub: pong
<mdz> pitti: hmm?
<elvirolo> hi
<jdub> mdz: don't remember, gotta run ;)
<elvirolo> i was wondering about something...
<mdz> seb128: yes, -updates uploads need manual approval, and I don't get any notification when they are waiting
<pitti> mdz: ISTR that somebody told us "we will meet every week on Thursdays now", but I could be wrong
<mdz> doko: updated avm modules = new upstream?
<doko> mdz: yes, asked Kamion about it
<pitti> mdz: Good morning :-)
<pitti> mdz: now that we have libnotify in main, can I add notification-daemon to ubuntu-desktop seed?
<seb128> mdz: hey mdz. Ok, next time I'll ping you on IRC when a package is waiting :)
<doko> mdz: and fixed the pcmcia_cs linking
<mdz> daniels: if there's a specific upgrade issue, send it to mvo for analysis
<elvirolo> Ubuntu Hoary is way better than Kubuntu in means of integration and simplicity ... will Kubuntu Breezy try and develop its own configuration utilities, and, to a larger extent, deliver a more integrated environment ?
<mdz> pitti: yes
<mdz> doko: ok, sounds fine
<mdz> doko: just don't break it ;-)
<doko> mdz: you did approve dbus for hoary-updates in the bug report, but it's not yet accepted
<doko> mdz: I'll let daniels do it if he updates the graphics stuff ;)
<pitti> doko: well, dbus is in the accepted queue, but it doesn't build and doesn't go into the archive for some reason
<infinity> pitti : ACCEPTED != INSTALLED.
<doko> pitti: ouch, any way for me to look at the reason?
<mdz> helena says these packages are waiting for approval:
<mdz> glibc     | 2.3.2.ds1-20ubuntu14 | source | 1 month old
<mdz> evolution | 2.2.1.1-0ubuntu4.1   | source | 3 weeks old
<mdz> dbus      | 0.23.4-0ubuntu4      | source | 2 weeks old
<mdz> kdelibs   | 4:3.4.0-0ubuntu3.4   | source | 2 days old
<mdz> I remember approving glibc, dbus and kdelibs
<seb128> you can drop the evolution one
<mdz> I remember it now that I read .changes
<seb128> pitti put the fix with today's upload
<mdz>    * debian/patches/05_bugzilla.patch:
<mdz>      - use the GNOME bugzilla to send bugs (Ubuntu: #12475).
<mdz> is that no longer important?
<pitti> mdz, seb128: I asked elmo to drop evolutio
<pitti> mdz: I included it into today's security update, it's a trivial one-line change in .desktop
<mdz> ah, ok
<mdz> I approved the rest
<mvo> mdz: a quick question about launchpad integration. do we want it for synaptic too? it means that the started ff (launched from the menu) is run as root
<pitti> mdz: so you have to manually approve -updates uploads? I uploaded evolution to warty-updates to fix that version, too, and it went straight in
<mdz> mvo: hmm, that's awkward
<pitti> infinity: is the i386 buildd still busy? awstats | 6.3-1ubuntu0.1 | source | 1 hour old
<mdz> mvo: can we enhance libl-i to drop privileges before launching the browser?
<mdz> pitti: yes
<mdz> pitti: when was that?
<infinity> pitti : You'll get them back shortly. :)
<mvo> mdz: I can certainly do that (if that's ok with seb128)
<pitti> mdz: this morning, maybe 9 hours ago
<mvo> seb128: is there a baz archive for liblaunchpad?
<sm> hi all. bugzilla, forums, wiki, lists, #ubuntu all come up dry.. if anyone knows why a minority of hoary users can't get cupsd to respond to web browser or gnome-cups-manager, I would appreciate any clue
<pitti> mdz: it appeared on warty-changes and everything
<mdz> pitti: interesting; maybe approval is only set up for hoary?
<elmo> nice
<elmo> oo2, oo2-l10n, gcc-3.4, gcc-4.0 and glibc
<elmo> concurrently
<pitti> mdz: the difference apparently is that there already was an -updates version of evolution, but not for the packages in your helena
<infinity> elmo : Yeah, "ouch". :)
<mdz> sm: the web interface is intentionally disabled; gnome-cups-manager should work though
<pitti> elmo: OMG, no wonder that I don't get a trivial arch-all perl package built...
<sm> not for me
<elmo> that's pretty much your worst case stress test scenario
<sm> I had to replace Listen with Port in cupsd.conf to get it to start up, but still not responding
* infinity bows.
<elmo> quick, someone upload xorg and a new kernel, and it'll be complete
<mdz>   ubuntu-desktop: Depends: gnome-app-install but it is not going to be installedE: Broken packages
<mdz> who broke it?
<pitti> elmo: 200 langpacks in addition maybe?
<elmo> pitti: langpacks are trivial for a buildd, even in bulk
<robitaille> mdz: face that problem a few minute ago...had to do "apt-get install gnome-app-install-data" to get things properly installed
<robitaille> s/face/faced
<mdz> robitaille: that won't fix this problem
<seb128> mvo: jamesh@ubuntu.com/launchpad-integration--devel--0
<mdz>   python2.4-gnome2-extras: Depends: libwnck17 (>= 2.11.4) but it is not installable
* infinity uploads xorg.
<mdz> mvo: please fix python-gnome2-extras
<seb128> mdz: the buildd needs a retry
<seb128> mdz: 
<seb128> The following packages have unmet dependencies:
<seb128>   libgksu1.2-dev: Depends: libgksu1.2-0 (= 1.3.1-1ubuntu1) but it is not going to be installed
<seb128>   libgksuui1.0-dev: Depends: libgksuui1.0-0 (= 1.0.5-1ubuntu1) but it is not going to be installed
<seb128> edd: Broken packages
<seb128> 
<seb128> according to the i386 build log
<robitaille> mdz: humm...worked for me maybe 30 mins ago.  but didn't look into it in detail.
<seb128> infinity: please give a retry to python-gnome2-extras build
<infinity> seb128 : Will do when I get a buildd back.
<mdz> yeah, those seem tob e intsallable now
<infinity> (Or I could kill OOo2... <cough>)
* infinity glances at doko.
<mdz> I don't see a python-gnome2-extras upload on -changes
<mdz> was it yesterday?
<doko> infinity: Mithrandir will kill you ... he's waiting for it to build the amd64 package
<infinity> Could have been.  Between biarch bootstrapping and dpkg segvs, the buildds have been unhappy.
<seb128> mdz: 2 days ago I think
<daniels> Kamion: no, we're just taking random stupid stabs in the dark
<seb128> mdz: the package is gnome-python-extras
<mdz> seb128: yeah, if it were 2 days ago I already read it and forgot about it ;-)
<daniels> Kamion: thanks for finding the segfault, you rock
<daniels> Kamion: your pony will arrive in the morrow
<mdz> there was a window yesterday where the desktop was actually installable, and I missed it due to livefs build script breakage, grr
<Kamion> mdz: I believe all the installability fixes are in progress; the dpkg segfault totally snarled up the buildds
<infinity> mdz : No worries, I'll babysit that build and retry the livefs build as soon as it goes through.
<infinity> I've been up/working too long to do anything that requires actual though anyway, and I have to sit up and babysit this biarch build, so it's not like I have anything better to do. :)
<mdz> Kamion: dpkg segfault?
<mdz> I missed that one
<infinity> For the last month or more, builds have been breaking horribly and chroots getting broken due to dpkg segfaulting while isntalling gl/glu-related packages.
<infinity> Turned out that dpkg segfaulted on an unversioned reverse-replaces corner case.  Kamion just uploaded a fix.
<infinity> (reverse replaces, as in unpacking the replaced package after the replacing package)
<pitti> infinity: uh, do we need to fix that in hoary, too?
<infinity> "need"?  Dunno.  But we probably should.
<infinity> It could make upgrades a bit sketchy.
<pvanhoof> aspell-nl: Depends: libaspell15c2 (> 0.60) but it is not going to be installed
<pvanhoof> yet libaspell15c2 is installed
<doko> pvanhoof: yes, known issue
<pitti> odd, I just got the same
<pvanhoof> doko, can I fix it?
<pvanhoof> temporarily
<doko> pvanhoof: ah, a workaround? don't know
* sm updates cups bug 13200, available for troubleshooting any time
<pvanhoof>  dpkg -i aspell-nl_0.1e-30_i386.deb
<jasoncohen> mvo, when will we see the changes outlined in https://wiki.ubuntu.com/PackageDependencyManagement. i was told they're not going into breezy
<mvo> jasoncohen: there is a bazaar apt branch that adds the needed support to apt. if you are curious, you can check it out and test it. it works pretty well for me, but it needs more real-life user testing
<mvo> (apt--auto-mark--0 from my baz archive)
<infinity> Is there a sane and rational explanation for why we appear to build openoffice.org2 twice, with two different source packages?
<pitti> infinity: once for code, and once for language packs
<jasoncohen> mvo, but it won't make it into breezy because of lack of testing?
<infinity> pitti : It appears that the langpack build also builds the code too, that's why I was asking.
<pitti> infinity: maybe doko can teach it to not build everything in vain?
<mvo> jasoncohen: unfortunately yes. it's a feature that basicly affects every user and every package managment operation so we need to be carefull with it 
<mvo> jasoncohen: I plan to make test packages available after the freeze for people that are curious 
<jasoncohen> mvo, ok, sounds good
<pvanhoof> doko, is somebody working on the aspell_nl issue?
<pvanhoof> I can forcefully install the current package, but it's not enabled the dutch language :-(
<doko> infinity: technically, you could try to uncouple the build system not to build code again, but it's currently not supported upstream. I think, that's the reason we do have compiler caches ;-)
<pvanhoof> s/enabled/enabling
<pvanhoof> regretfulyl I have no idea how aspell is to be configured
<doko> pvanhoof: correct, a fix requires updating the package, it's on my list. see the aspell changelog for the changes which must be made
<pvanhoof> ok
<pvanhoof> of this one? aspell-nl_0.1e-35ubuntu1_i386.deb
<infinity> doko : If the -l10n build ends up building all the code again anyway, then why have two source packages at all?
<infinity> doko : Is it not feasible to build all the binaries and langpacks from the same sourcde?
<doko> infinity: we do want to update the langpacks after the breezy release, without modifying the binaries
<infinity> Ahh, but isn't that supposed to be done out-of-band via rosetta and langpacks?
<infinity> (I guess that's a "down the road" thing, though)
<doko> yes, but currently, there are no source packages for langpacks, IIRC.
<mdz> pitti: dpkg in hoary didn't support that at all
<mdz> pitti: we talked about it in the context of langpack replaces
<infinity> Oh, good point.  That dpkg bug wasn't fixed until breezy (thus introducing the degv)
<infinity> s/degv/segv/
<pvanhoof>  cp /usr/lib/aspell-0.60/* /usr/lib/aspell/
<pvanhoof> temporary fix, doko
<Frafra> hi all
<Frafra> in the currents build
<Frafra> can i install nvidia proprietary drivers?
<Frafra> i've read that in colony 3 will be supported
<pvanhoof> doko, dictdir = $(libdir)/aspell-0.60 in the Makefile.am will install the dictionary files of aspell-nl in /usr/lib/aspell-0.60
<pvanhoof> whereas all of them are simply in /usr/lib/aspell/
<pvanhoof> oh and ..
<pvanhoof> I'd do something like $(libdir)/aspell-$(VERSION)
<pvanhoof> and I'd use targetdata = nl.multi nederlands.multi etcetera
<pvanhoof> and targetdir = $(libdir)/aspell-$(VERSION)
<pvanhoof> rather than this piece of junk Makefile.am
<pvanhoof> it's asking for problems
<pvanhoof> I guess that's an upstream problem ..
<pvanhoof> it's even using "ln" which isn't platform neutral
<pitti> mdz: IIRC Keybuk did a last minute fix to support Replaces properly?
<mdz> pitti: oh, you may be right
<pitti> mdz: http://changelogs.ubuntu.com/changelogs/pool/main/d/dpkg/dpkg_1.10.27ubuntu1/changelog
<pitti> mdz: we did that because of the langpacks, it broke the preview, remember? :-)
<mdz> it went into 1.10.27ubuntu1 and 1.13.2
<mdz> pitti: send mail to Keybuk about it for when he returns
<pitti> yes
<madduck> doko: coming to #pkg-zope?
<doko> carlos, pitti: updated RosettaFirefoxAndOpenOfficeSupport
<mdz> doko: will the ooo2 binaries be uninstallable or anything if we kill the ooo2-l10n build?
<doko> no, just some missing translations for the binary filters, not that important
<doko> mdz: ^^^
<mdz> the parallel ooo2/ooo2-l10n builds are blocking all the uninstallability fixes for the desktop
<doko> no, just kill it, but keep the ooo2 build. Mithrandir needs the binaries for the amd64 package
<infinity> Not going to bother killing it, it's almost done anyway. :/
<infinity> If you had said "just kill it" 3 hours ago, I would have happily done so.
<mdz> I was unconscious 3 hours ago
<mdz> and dreaming of waking up to fresh livefs builds ;-)
<infinity> Odd dreams.
* infinity sets about making -desktop installible on amd64.
<infinity> Oh, that's right.  hal is actually FTBFS on amd64 without dpkg's help.
<infinity> Bother.
<infinity> Does anyone for whom it's not 6am in their timezone want to look into it?
<pitti> infinity: ok
<infinity> pitti ; http://people.ubuntu.com/~lamont/buildLogs/h/hal/0.5.3-0ubuntu2/hal_0.5.3-0ubuntu2_20050811-1154-amd64-failed.gz
<pitti> infinity: "E: Sub-processdpkg-deb: subprocess paste killed by signal (Broken pipe)"
<pitti> infinity: that doesn't look like a normal error...
<infinity> pitti : Try the log above it (or the one below it when it rolls in)
<pitti> checking for BLKGETSIZE64... no
<pitti> configure: error: BLKGETSIZE64 is not defined
<pitti> WTF is that???
<infinity> That's the one.
<infinity> WTF indeed.
<pitti> *sigh*, booting to amd64, brb
<infinity> pitti : You could always try blaming jbailey.
<pitti> infinity: will it help?
<infinity> pitti : BLKGETSIZE64 is an LFS64 ioctl whicn, on amd64, should probably be an lias for BLKGETSIZE, so maybe it's a linux-kernel-headers bug..
<pitti> great to see that I'm supposed to fix things I don't understand :-)
<ogra> /usr/bin/libtool: line 6545: exec: dbus-binding-tool: not found
<ogra> GRRRR
<ogra> why dont we build that ? dbus-binding-tool seems nonexistent
<mdz> ogra: context?
<ogra> gnome-power
<pitti> infinity: no, it's one of these damn compiler "features":
<pitti> /usr/include/asm-x86_64/types.h:23: error: conflicting types for 'int64_t'
<pitti> /usr/include/sys/types.h:194: error: previous declaration of 'int64_t' was here
<ogra> it took me ages to get all bits and pieces togehter to have the build-deps fulfilled... and now that... :(
<seb128> ogra: sudo apt-get install dbus-utils
<ogra> seb128, nope
<seb128> how so "nope"?
<ogra> at least thas not what dpkg --contents shows me
<seb128> I've fixed this morning
<seb128> what arch?
<ogra> dbus-1-utils_0.35.2-0ubuntu2 ?
<seb128> 0.35.2-0ubuntu3 has it
<ogra> the buildd for x86 hasnt build since 15:00 GMT
<seb128> thanks OO.o2
<ogra> heh
<seb128> dbus_0.35.2-0ubuntu3_20050811-1302-i386-successful.gz
<ogra> i was worried it was mediawiki ;) it was the last one that builzt
<seb128> Filename: pool/main/d/dbus/dbus-1-utils_0.35.2-0ubuntu3_i386.deb
<ogra> strange
<seb128> change your mirror
<ogra> yup... just saw it... its not on de. yet
<ogra> (i normally dont compile on that machine... but amd64 is to borked currently)
<infinity> pitti : Looks like jbailey's fault to me.
<paolo> what's the correct way to get java on breezy?
<infinity> pitti : That first declaration is linux-kernel-headers, the second is libc6-dev, either way it's his breakage. :)
<pitti> infinity: not necessarily, gimme some minutes
<pitti> infinity: I'm digging into it
<infinity> pitti : Although, conflicting types for int64_t sounds pretty painfully wrong.
<pitti> infinity: in fact hal seems to screw up this on its own
<pitti> ./config.h:#define __s64 int64_t
<pitti> ^ __s64 is defined in l-k-h
<pitti> and hal aliases it _and_ includes types.h
<infinity> Fancy.
<pitti> *grumpf*
<infinity> Go hal.
<pitti> it uses AC_CHECK_TYPE, and if that fails, it defines it on its own
* pitti goes to figure it out and fixes
<mdz> pitti: is the new hal blocking desktop installability?
<infinity> mdz : Yes.
<mdz> gar
<infinity> mdz : Only on amd64.  Due to this bug we were just discussing.
<mdz> what's above it in the chain?
<pitti> infinity: why doesn't amd64 use 0.5.2 then?
<infinity> pitti : Depends on packages that no longer exist.
<infinity> Or some such.
<infinity> Or, rather, something else that is uninstallible is waiting on the new hal before it can build.  Or something.
<infinity> It all made sense to me 30 minutes ago when I discovered hal was the bottleneck.
<JanC> wtf, last kernel/initrd tries to use a non-existing volume group "hda6" instead of my /dev/hda6 partition ?
<infinity> Funny, jbailey was just bragging about how he'd had no complaints about initramfs yet.
<seb128> pitti: grah, g-v-m crashed again on update ... we should stop restarting dbus 
<mdz> infinity: yeah, when it wasn't the default yet
<mdz> and therefore about 5 people were using it
<infinity> mdz : Nah, just 30 minutes ago, from whatever airport he was in, he'd mentioned his surprise at the lack of fallout from the switch. :)
<mdz> it only landed yesterday; most of the world didn't upgrade until today
<mdz> and still more haven't rebooted yet
<mdz> amd64 is blocked by gnome-applets and gnome-app-install
<infinity> I rebooted pretty well instantly, out of fear that I'd have to get involved in some messy recovery.
<mdz> (at top level)
<infinity> And, oddly, I didn't.
<mdz> gnome-app-install I traced earlier to python-gnome2-extras, which just needed to be built
<infinity> mdz : Yup, I tracked that one down, too.
<infinity> The other direction is the hal problem.
<mdz> it doesn't seem to have a recent attempt
<mdz> http://people.ubuntu.com/~lamont/buildLogs/g/gnome-python-extras/2.11.4-0ubuntu2/
<mdz> the last one was a dpkg segfault
<infinity> <nod>
<infinity> Requeued already.
<mvo> mdz: I have a apt upload pending (send you a mail about it some days ago, a small bugfix in the dpkg<->apt communication). can I do that now is it inconvenient now (because of the buildd situation)?
<infinity> The buildd situation isn't much of a situation.  i386 will normalise in a few hours and it'll be like nothing happened.
<infinity> (Until I wake up tomorrow and do a mass give-back to catch everything that may have been screwed by the dpkg segv...)
<infinity> Right, that's why I need the new hal built.
<mdz> mvo: gnome-app-install-data just failed to install on amd64 for me
<mvo> mdz: yes, the fix is uploaded but not yet build
<mvo> mdz: it fails only on a upgrade, right? not for a new install
<infinity> mdz, pitti : The old hal refers to libdbus-1.la, so building against it fails, the new hal will be built against the new dbus and fix that.  gnome-python-extras won't build until we have it.
<mdz> dpkg: error processing /var/cache/apt/archives/gnome-app-install-data_0+20050809_all.deb (--unpack):
<mdz>  trying to overwrite `/usr/share/gnome-app-install/Mozilla.desktop', which is also in package gnome-app-install
<mdz> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<mdz> mvo: ok
<mvo> mdz: ok for g-a-i or ok for the apt upload? 
<mdz> mvo: g-a-i
<mdz> mvo: I cannot deal with apt or anything else until this situation is fixed
<mdz> our priority at the moment is working CDs
<{Seb}> i've got a few niggles with breezy and i don't know if they are known bugs
<{Seb}> first - i had to remove /usr/bin/X11 and symlink it to /usr/bin to get X to start
<mdz> pitti: I'm getting my amd64 upgraded so that I can look at hal; have you had any luck with it?
<pitti> mdz: I'm on it
<pitti> mdz: but its a bit tricky
<mdz> what the hell
<{Seb}> second - gnome-app-install is broken
<mdz> locales is generating EVERY locale
<pitti> needs some time, but I'll solve it
<{Seb}> and i had to force install gnome-app-install-data
<{Seb}> are these known bugs or should i file them in bugzilla?
<mvo> mdz: well, the upload is ready. but if you want to have a look first it can certainly wait. it contains only small (but importent) fixes
<mvo> {Seb}: it's a known bug, the fix is uploaded but not yet in the archive
<{Seb}> which ones?
<mdz> {Seb}: gnome-app-install is known; it has already been discussed here several times today
<mdz> {Seb}: for X, search bugzilla and report only if it is not there already
<{Seb}> also, my scroll wheel won't work
<{Seb}> i'll search
<{Seb}> breezy is look absoutly great
<ogra> pitti, something about BLKGETSIZE64 ?
<mdz> infinity: what's broken on the gnome-applets size?
<pitti> ogra: no, something entirely different, it just appears to be so
<mdz> s/size/side/
<pitti> YAY, hal builds!!!
<ogra> hooray...
<pitti> with a 178 KB patch..
<pitti> anyway, I'll throw it at the buildds to have something working, and I'll sort that out with upstream to find the real solution
<mdz> pitti: 178kb?
<pitti> mdz: upstream does weird things with datatypes, so I needed a find/sed to replace them all
<pitti> mdz: and I need to regenerate configure
<mdz> so 8k search/replace, 170k configure ;-)
<pitti> mdz: no, about 120 KB search/replace
<infinity> mdz : Out of date, waiting on new hal.
<mdz> wow
<infinity> mdz : So, both paths lead to hal.
<pitti> mdz: it's not a good patch, and not the final one, but I'll test it on some arches now and upload to have a quick solutuon
<mdz> pitti: ok
<pitti> wow, hal even works
* pitti tries on i386
<pitti> mdz, infinity: hal_0.5.3-0ubuntu3_source.changes ACCEPTED
<mdz> pitti: good timing for :03
<pitti> hehe :)
<pitti> awstats   | 6.3-1ubuntu0.1     | source               | 4 hours old
* pitti wants an i386 buildd
<mdz> pitti: is the firewall stuff landing or no?
<mdz> I need to know whether I need to implement the contingency for ltsp
<pitti> mdz: I asked carstenh about useful subsets, but most certainly not
<mdz> damn
<pitti> mdz: he doesn't even have packages yet
<ogra> SoC started way to late
<infinity> i386 buildds are coming back. One's here.
<mdz> pitti: please set it to deferred
<pitti> so not until tomorrow, but even this wouldn't yield much useful
<pitti> mdz: ok
<mdz> infinity: is hal building?
<infinity> Still not registered in wanna-build.  Give cron.daily some breathing room.
<pitti> mdz: oh, it's not even in the table yet
<mdz> pitti: add it to the deferred table
<mdz> seb128: how is launchpadintegration?
<seb128> mdz: ~25/30 apps patched 
<mdz> seb128: is there a list somewhere?
<seb128> I'll update the wiki
<seb128> a min
<doko> one ooo2 build did finish ...
<mdz> mvo: findingpackages is bust, I guess?
<infinity> Oh, hey php4 finally got shoved to universe.
<pitti>       php4 | 4:4.3.10-15ubuntu2 | http://archive.ubuntu.com breezy/universe Packages
<pitti>       php4 | 4:4.3.10-15ubuntu2 | http://archive.ubuntu.com breezy/main Sources
<pitti> well, almost...
<mdz> Someone else saved this page while you were editing! Please review the page and save then. Do not save this page as it is! Have a look at the diff of BreezyGoals to see what has been changed. 
<infinity> mdz : Can I sync php4 with Debian, and upload php-imap (which builds php4-imap and php5-imap) to universe?
<mdz> who ignored my lock?
<pitti> mdz: I just added Firewalls, but I didn't get a lock...
<infinity> pitti : The binries all got shoved to universe...
<mvo> mdz: FindingPackages gnome-app-install is in, but nautilus/mozilla integration is not done yet
<mdz> pitti: I made several edits, so I'm clobbering your changes
<pitti> mdz: I was told that I had the lock, sorry
<infinity> pitti : Not sure why the source didn't move.
<pitti> mdz: I fix it
<mdz> pitti: thanks
<mdz> infinity: packages moving between components is an entirely manual process
<mdz> infinity: send me email with the details
<mdz> (re: php)
<pitti> mdz: odd, how can this happen? race condition?
<seb128> mdz: https://wiki.ubuntu.com/LaunchpadIntegration
<ogra> infinity, btw, edubuntu has only hp5 deps let, i git them all sorted, so php4 could go completely to universe
<ogra> s/hp5/php5
<mdz> pitti: it is easy to overlook the message; are you sure it did not warn you?
<ogra> s/let/lefzt
<ogra> grmpf
<ajmitch> morning
<infinity> ogra : Excellent.  If edubuntu needs any php5 extensions we don't have packaged, you need to let me know, and ask mdz for permission to let me upload them. :)
<pitti> mdz: I remember having read the usual "you have locked 10 minutes" sign, but given my current mental state I could be wrong; nevermind for now
<Kamion> mdz: the dpkg segfault does appear to be present in hoary too, looking at the code
<ogra> infinity, oki... but i'm fine for now...
<Kamion> mdz: however, it really is quite a corner case, so I'm not that worried about it; we only ran into it because of very odd packaging
<pitti> Kamion: so it won't break the usual langpack use case?
<Kamion> mdz: you need to have something doing an unversioned Replaces on a package that's still active in the distribution, which is not a usual thing to do
<Kamion> pitti: hmm
<Kamion> you do have an unversioned Replaces there ...
<pitti> Kamion: I guess if the fix is easy we should update, but it's not super urgent, right?
<pitti> Kamion: I can't update langpacks before rosetta export is working anyway
<seb128> mdz: gnome-python-extras build failed again ... nautilus-cd-burner 0ubuntu2 needs to be built first and then gnome-python-extras
<infinity> seb128 : On it already, don't worry.
<seb128> mdz: due to dbus.la changes 
<seb128> daniels insisted to drop them
<Kamion> pitti: now you mention it, it looks to me as if it ought to break, but then I'm amazed it hasn't broken lots already
<pitti> Kamion: we didn't actually update hoary langpacks yet (ENOROSETTA)
<Kamion> pitti: yes, but that dpkg change happened some time before release
<Kamion> and before the last language pack upload for hoary
<Kamion> so, if it were going to happen I'd've thought we'd see it then
<Kamion> perhaps the circular Depends and bidirectional Replaces manage to insulate us from it
<Kamion> the fix is trivial, anyway, and I can probably prove that it doesn't break anything that wasn't already broken ;)
<pitti> sounds like a "5 free minutes to fix it" case for hoary-updates, then?
<pitti> haha, SuSE replaces mozilla in all stable releases to 1.7...
<infinity> Vindication!
<Kamion> pitti: probably, if the stress-test-by-buildd goes well
<_d4vid> hi all
<doko> Mithrandir: -10 is built on i386
<pitti> infinity, mdz: hal built on amd64
<infinity> pitti : I know, I've been babysitting it.
<infinity> Argh, I hate my laptop crashing every day.
* infinity blames daniels.
<pitti> mdz: btw, I tried to get the ffox crash on i386 by incrementally upgrading everything to the latest version, no luck
<Kamion> mdz: I assume removing l-r-m-2.6.10 from breezy is fine?
<pitti> night everybody!
<paolo> Goodnight pitti
<doko> Kamion: something wrong with the new lrm upload?
#ubuntu-devel 2005-08-17
<Kamion> doko: hmm?
<doko> nevermind, you did write .10 ...
<Kamion> yeah
<Kamion> although your latest upload doesn't build anywhere
<Kamion> rpm2cpio: /build/buildd/linux-restricted-modules-2.6.10-2.6.10.6/ati/fglrx64-6.8.0-8.12.10-1.x86_64.rpm: No such file or directory
<Kamion> oh, bah
<Kamion> sorry, I was looking at l-r-m-2.6.10. :-)
<doko> no, it only fails on ia64
<doko> should go to bed as well ...
<mdz> Kamion: yes
<Kamion> gone
<mvo> doko: around?
<mdz> infinity: how do we look?
<infinity> either 1 or 2 cron.dailes away, depending on how lucky I was with the timing of the last nautilus-cd-burner upload.
* infinity considers begging elmo for build-from-accepted again.
<elmo> wtf
<infinity> I'm impatient. :)
<elmo> what is with you guys and the chronic are we there yetting today?
<elmo> I'm going to buy y'all fucking calendars for the next meet
<elmo> and write <n> days till <next milestone> in every day
<mdz> elmo: I have a calendar already, and it says that today is feature freeze
* mvo goes to bed now
<Robot101> where's glxinfo/glxgears gone? :(
<infinity> Where it belongs.
<Nafallo> hehe
<infinity> mdz : Alright, looks like amd64 is 1 cron.daily away and i386 is two cron.dailes away.  I'll verify that with test builds a few seconds after all the right packages are in the archive.
<mdz> infinity: thanks
<mdz> elmo: did you look into why apt-ftparchive is incredibly slow on jackass?
<elmo> no, I just cry about it mostly
<elmo> it's not _actually_ that slow
<mdz> I think when we talked about it last, an strace was the next step
<elmo> relative to e.g. it's speed on newraff
<tseng_> mdz: beagle stuff is moving into debian, can we sync up?
<tseng_> mdz: same versions for now.
<mdz> tseng_: is beagle going to move into main for breezy?
<tseng_> mdz: yes, if we can get one more release in
<mdz> if not, we should take it out of the seeds
<tseng_> mdz: inotify is out of sync with breezy
<mdz> tseng_: so you want to clobber 0.0.12-0ubuntu3 with 0.0.12-1?
<tseng_> yes, and then 0.0.13-1 hopefully
<tseng_> ill have to pressure upstream about dates on that
<mdz> it's a bit late for that
<tseng_> then we can unseed it
<mdz> so 0.0.12 is no good?
<tseng_> performance is significantly bong without inotify, you are polling everything
<mdz> and what about gmime2.1?  that's the reason it isn't in main
<tseng_> but it works well enough, what do you think
<mdz> the last time we talked about it, you said gmime wasn't ready to move into main, and that blocked beagle
<elmo> mdz: /s/f.nny.c/log/apt-ftparchive.strace.$date, as of next cron.daily
<elmo> hopefully
<mdz> elmo: thanks
<tseng_> hm yes that was gmime, we moved to gmime2.1, much better.
<mdz> tseng_: no, that was gmime2.1
* tseng_ kicks his shell
<tseng_> mdz: i recently swapped it.  the packaging is sane now
<mdz> tseng_: so now it's ready to get a main inclusion report and move into main?
<tseng_> sure
<tseng_> if you dont like 0.0.13, I can try to backport inotify updates
<tseng_> see what happens.
<mdz> it's all pretty iffy at this point, considering that beagle still isn't part of the default desktop
<mdz> how much potential does it have to break things other than itself?
<tseng_> its pretty good at sucking up all your ram in lowmem systems
<luis_> define 'lowmem'
<luis_> :)
* luis_ has actually been using the 0.12 package pretty happily for a while
<mdz> elmo: hopefully the next cron.daily won't take >30m due to strace ;-)
<tseng_> I would expect 256 would be painful after awhile
<mdz> why, does it leak?
<elmo> mdz: uh, is strace that slow or you mean because of the sheer contents of log writing?
<tseng_> it spawns a few threads to index files at a time
<tseng_> with a mono process for each one
<tseng_> thats pretty heavy.. some shared
<mdz> elmo: both
<elmo> mdz: meh, ok, I'll take it out after we get one then
<mdz> elmo: strace is running right now
<mdz> it's now completely cpu-bound
<elmo> hmm, where did THAT cron.daily go
<elmo> taken out anyway
<elmo> 40K CS/s
<elmo> still think that's sane? :P
<mdz> cron.daily was already running at the time that you changed it
<elmo> uh
<elmo> how could that be?
<elmo> it's a shell script?
<elmo> it wouldn't re-read itself?
<mdz> well, at the time that you told me about it
<elmo> oh
<mdz> which was :38
<elmo> and it's done
<mdz> and I had been watching to see when it finished
<mdz> infinity: so I should be clear to trigger an amd64 livecd build now?
<elmo> 131Mb of strace...
<infinity> mdz : I don't show gnome-python-extras as installed yet, only uploaded.
<mdz> infinity: which version is the fixed one/
<infinity> 2.11.4-0ubuntu2
<mdz> python2.4-gnome2-extras | 2.11.4-0ubuntu2 |        breezy | amd64, ia64, powerpc
<mdz> python2.4-gnome2-extras | 2.11.3-0ubuntu1 |        breezy | i386
<infinity> Fun.  I guess updating wanna-build is the very last thing done post-cron.daily.
<elmo> yes
<elmo> it's punishment for asking about AA
<elmo> or perhaps inheirted from Debian; I'm not sure
<infinity> <snicker>
<infinity> Well, it makes sense.
<mdz> elmo: I've compressed and downloaded the strace; you can delete it
<infinity> You don't want to get clearing dep-waits before the packages are good and firmly installed in the arechive.
<Kamion> mdz: seems to me that using internal zlib/libbz2 rather than forking a bazillion decompressor processes would be an obvious place to start
<infinity> s/get clearing/go clearing/
<mdz> Kamion: forking an external compressor tends to be faster on SMP systems
<elmo> kamion: that was done to take advantage of auric's SMP
<Kamion> ah
<Kamion> but jackass is not SMP
<elmo> I'm still not convinced it's a win on this particular SMP box
<elmo> is too
<elmo> oh, hum, I disabled one CPU.  go me
<Kamion> only has one entry in /proc/cpuinfo
<elmo> I should bring that back
<mdz> ...
<mdz> GAH
<mdz> now xchat is uninstallable
<mdz> seb128 please stop uploading packages
<luis_> you just missed him
<mdz> if he's gone to sleep, that works too
<ajmitch> tseng_: so I'll drop the beagle-0ubuntu4 patch for now?
<tseng_> ajmitch: hm that patch is a trivial fix to a real bug
<mdz> infinity: we need xchat_2.4.4-0ubuntu2_amd64 in order to proceed
<Kamion> there are other problems too, gnome-app-install_* for instance
<ajmitch> tseng_: yes, you just asked for sync,so I'll hold off on upload for now
<mdz> Kamion: amd64 isn't complaining about gnome-app-install for the moment
<elmo> wow, woops
<elmo> bash  does NOT like for i in $(seq 1 1000000000000000000); do something; done
<Kamion> mdz: britney is
<Kamion> oh, sorry, not on amd64, but on i386
<infinity> xchat on its way.
<tseng_> ajmitch: eh well. im thinking out loud, to the chagrin of mdz
<mdz> Kamion: gnome-python-extras for i386 just accepted
<Kamion> that works
<mdz> so should fix g-a-i on i386
<mdz> i386 also has up-to-date xchat, so it might actually beat amd64
<mdz> amd64 presumably needs yet another cron.daily
<Kamion> and gaim_powerpc accepted, phew
<tseng_> ajmitch: as it stands im thinking to see how far we can track in breezy/universe and carry over to breezy+1
<Kamion> what's with gst-plugins0.8_powerpc?
<mdz> tseng_: if you can have the main inclusion reports in place today, we can throw it in desktop, watch the fun and see what happens
<Kamion> hmm, dep-wait xlibs-pic which was removed as NBS
<mdz> otherwise, I'm inclined to defer it
<Kamion> argh
<ajmitch> we need to get either packaging in pkg-mono svn, I think
<tseng_> ajmitch: we do, but that doesnt fix inotify, mem usage..
<Kamion> previous version spectacularly FTBFS due to missing gl-ish build-dep
<ajmitch> tseng_: I know
<ajmitch> mem usage has improved a lot, but it's still very heavy on my box
<tseng_> i just counted 70-100mb
<tseng_> which is brutal to 128-256 total
<tseng_> mdz: sorry, i always feel like I am "almost there", but I dont have any magic tricks to do on it
<tseng_> mdz: can we move it to breezy+1?
<mdz> tseng_: I just unseeded it
<tseng_> mdz: ok, how liberal do you feel about changes in universe with the seed gone?
<ajmitch> yeah, ~150MB within 10 sec of starting beagled
<tseng_> inotify would be a big win
<mjg59> Oh, yes, that's a point
<tseng_> ajmitch: ouch, but there is some shared
<tseng_> ajmitch: maybe 15-20 per process
<mdz> tseng_: go to town in universe
<mjg59> There's a couple of things I need to move to desktop
<ajmitch> mdz: great, it means I can hack on it too
<mdz> ajmitch: it's always been in universe
<tseng_> ajmitch: can you mail your patch to jose?
<mjg59> This machine is *so* entertainingly broken
<tseng_> ajmitch: i just mailed him about an evo-sharp fix as well
<ajmitch> mdz: I know
<ajmitch> tseng_: sure
<tseng_> we'll have to get him in the debian-mono group sometime
<mjg59> The timer interrupt is about 3 times too fast
<mdz> is there a python module which converts from (int)seconds to some nicely-formatted h/m/s or such?
<mdz> mjg59: can you be a bit more specific about moving things to desktop?
<mjg59> mdz: hotkey-setup and usplash want to be main/desktop
<mdz> mjg59: any non-main deps for either of them?
<mjg59> Nope (though usplash is currently in universe)
<mdz> so is hotkey-setup
<mjg59> Is it?
<mjg59> I uploaded it to main
<Kamion> mjg59: what piece tells the splash to go away?
<Kamion> mjg59: components are overridden
<Kamion> more or less
<mdz> mjg59: the destination component is determined by the seeds
<mdz> + germinate
<elmo> mdz: I don't think so - datetime.timedelta would be the obvious place but it bizarrely doesn't have an .hours or .minutes attribute
* Kamion is fixing gst-plugins0.8
<mjg59> Kamion: It times out after 15 seconds, it'll quit if the VT changes, you can send it a quit command
<robertj> has anyone else tried out todays i386 liveCD?
<mjg59> The 15 second clock is overridden every time a command is received
<robertj> It wasn't a happy camper under VirtualPC this morning and I didnt' have time to burn it at the office
<Kamion> mjg59: base-config will want to make it go away, I'd've thought
<mjg59> Kamion: Yeah. That's easy enough to do.
<mjg59> usplash_write "QUIT "
<Kamion> (why the space?)
<mjg59> Bug
<Kamion> 'k
<mjg59> It ought to work without, but doesn't. I haven't figured out why yet
<mgalvin> robertj: they are working on fixing the cds now
<mjg59> Can anyone remember how to get the kernel to use the pmtimer rather than the pit?
<robertj> mgalvin: great, just wanted to make sure someone noticed ;)
<mjg59> Ah. Clock=pmtmr, not clock=pmtimer
<mjg59> This laptop is ghetto.
<robertj> is there someone at canonical who has a cron job with cdrecord and wget ;)
<Kamion> mjg59: is that safe for use inside debconf (i.e. does it use stdin/stdout itself)?
<mjg59> usplash_write? It doesn't use stdin/out, but it doesn't explicitly close them
<mjg59> That can always be fixed
<Kamion> mjg59: not a problem
<mdz> yay, both gaim and xchat uninstallable on amd64 now
<Kamion> as long as it doesn't write to them
* mdz glares at seb128
<mjg59> What would worry me more is that if it's run after bterm has started, bad things might happen
<Kamion> mjg59: base-config doesn't use bterm
<elmo> mdz: if he's still uploading; it wouldn't take much to block any further ones ;)
<Kamion> it's whiptail
<mjg59> Oh, ok
<Kamion> mjg59: what happens if I call usplash_write when usplash isn't running?
<mjg59> Kamion: It fails silently
<Kamion> exit 0 or non-0
<mjg59> Return code of 0
<Kamion> ?
<mdz> mjg59: is usplash supposed to disappear after 5 seconds or so regardless of boot progress?
<Kamion> ok
<mjg59> mdz: Should be 15 seconds, but yes
<mjg59> If no commands are sent it assumes something has gone wrong and exits
<Kamion> I'll be paranoid and || true anyway
<mdz> and it's impossible to send commands because the fifo is buried on some mounted-over filesystem :-)
<mdz> if it is created at all
<Kamion> base-config doesn't need to die if usplash_write fails for whatever reason
<mjg59> Oh, the BIOS is FUCKED
<mjg59> mdz: Yeah - jbailey is working on that
<mjg59> It's under control :)
<mdz> mjg59: jbailey is gone
<mjg59> Gone?
<mdz> he's away until...monday? tuesday?
<mjg59> Ah, ok
<mdz> no, I mean he's DEAD
<mjg59> Ha
<mdz> on the bright side, i386 livefs build is chugging along happily
<mjg59> We'd discussed the problem. He had an implementation plan, but I don't know enough initramfs to make it work
<mjg59> mkinitramfs currently dies on some amd64, but that's easier to fix
<mdz> mjg59: what was the plan?
<mdz> you'd need to have usplash re-exec itself or something
<mjg59> Shift the chunk of filesystem with the fifo over onto the real filesystem
<mjg59> You can do this with initramfs because it's the same namespace
<mdz> you can't move an open fifo from one filesystem to another and expect it to work
<mjg59> (I'm told)
<mjg59> It's the same filesystem
<mdz> is not
<mjg59> mount --move, rather than mv
<mdz> unless you chrooted it
<mdz> oh god
<mdz> infinity: will we have gaim/amd64 in time for :30?
<robertj> btw, anyone here played with symphonyOS
<doko> infinity: l-r-m-2.6.12 did fail on i386 (dpkg segfault)
<mdz> doko: it's not a priority right now; we're trying to get desktop installable
<doko> mdz: anything outstanding which needs work?
<mdz> doko: i386 seems to be close, amd64 should just need some builds
<mdz> powerpc has uninstallable gnome-applets and gnome-panel, but I haven't traced it out
<mdz> Kamion may have
<mdz> i386 seems to have successfully installed and is doing filesystem/partition stuff
* doko powers up the powerbook
<infinity> mdz : Apparently not.  It's installed now though.
* infinity goes to trace powerpc.
<jelkner> hi all, can someone tell me how to change the default global umask?
<Kamion> mdz: not yet, no
<Kamion> I'm busy with gst-plugins0.8
<doko> there's a version mismatch between gnome-panel and gnome-panel-data
<infinity> mdz : PowerPC is sorted.
<infinity> mdz : gnome-panel is already built and uploaded, next cron.daily will make it happy.
<mdz> gnome-panel | 2.11.91-0ubuntu2 |        breezy | powerpc
<mdz> gnome-panel-data | 2.11.91-0ubuntu2 |        breezy | all
<infinity> Oh, that was this cron.daily even.
<infinity> Must still be running.
<infinity> (Note that the Packages file still says -0ubuntu1 for gnome-panel)
<doko> are recommends important?
<mdz> yeah, it is
<mdz> doko: not today
<mdz> once cron.daily finishes, I'll kick off a powerpc live build
<Kamion> it's finished
<mdz> and a new i386 one to get the latest stuff, though it at least has an up-to-date image
<mdz> amd64 failed
<Kamion> ubuntu-desktop is still uninstallable everywhere
<mdz> gaim still uninstallable, apparently
<mdz> Kamion: is your published britney output up-to-date?
<Kamion> mdz: yes, see the timestamp at the top
<mdz> gah
<mdz> bluez-bcm203x is uninstallable
<mdz> bluez-firmware isn't even in Ubuntu and probably never has been
* mdz glares at chmj
<Kamion> bluez-bcm203x comes from Debian contrib; why did we put it in main in the first place?
<mdz> chmj
<ajmitch> it's built from bluex-utils source
<Kamion> (i.e. it should've been in multiverse before, and then should've been moved to restricted?)
<ajmitch> s/x/z/
<elmo> hum
<elmo> I better see what else from !main we have in main
<mdz> and universe
<infinity> mdz : gaim missed cron.daily by 5 minutes, it'll be in :03.  You're on your own with the bluez mess. :/
<mdz> infinity: indeed
<mdz> infinity: just uploaded a fix for the bluez mess
<mdz> infinity: if gaim is sorted, I think anything else from here I can handle
<mdz> infinity: get some sleep ;-)
<elmo> EWW  bluez-firmware source is in main and produces contrib binaries?
<elmo> wtf?
<infinity> Does that even work?
<elmo> yes, unffortunately
<mdz> hmm, that explains how we got it
<elmo> I should break it, and beat whoever accepted it into Debian
<elmo> doko: ?
<elmo> there's a bunch of openoffice.org-hyphenation packages in !main in Debian, but in main for us
<elmo> hmm, and a whole bunch more in universe, crap
<elmo> http://people.ubuntu.com/~james/non-main-in-main-or-universe.txt
<infinity> Catchy filename;.
<infinity> I might see if aj wants to turn it into a song parody.
<infinity> It would also be better if it wasn't a 404.
<mjg59> Is gnome-power making main?
<elmo> http://people.ubuntu.com/~james/misc/non-main-in-main-or-universe.txt
<infinity> elmo : ecliple is apparently free now, hence why we had a flurry of activity to move it to main.  It just needs to be reuploaded to main in Debian as well.
<Kamion> gnu-standards is presumably just GFDL
<elmo> yeah it is
<infinity> eclipse, too.
<infinity> phpdoc is undistributable crap.  Just drop it on the floor.
<infinity> I thought Debian already removed it, but maybe not.
<elmo> no, that's uniq -d output
<elmo> so it must still be in Debian
<infinity> Right, I'll file a bug on jvw.
<infinity> I'm sure he was supposed to pull it pre-Sarge.
<jdub> pants off
<Kamion> god, I feel like a weenie sitting here typing 'apt-get update; apt-get dist-upgrade' every half-hour so I can see what's broken :P
<whiprush> pants on
<jdub> heh, it's not half feature-freeze time, is it? :)
<doko> elmo: I'll look at the hype tomorrow
<elmo> doko: k
<Kamion> mdz: it doesn't take me long to manually kick a seed update you know ;)
* jdub wonders why gcj and related foo is going to be installed
<Kamion> gcc-4.0 rebuild for i386/amd64 biarch probably
<doko> gcj? gij yes, but gcj?
<mdz> Kamion: we really ought to just eliminate that middleman entirely
<jdub> mmm, i didn't think i had anything that wanted java on my system previous to this update
<mdz> and have things pull from the archive directly
<doko> jdub: OOo2 ?
<Kamion> yeah, germinate is now kinda set up to be able to support that but I need to write a bit of code
<elmo> phpdoc killed
<jdub> doko: most likely suspect - though i wonder why gcj-4.0 is pulled in
<jdub> oh
<jdub> java-gcj-compat
<doko> jdub: that would be a mistake.
<jdub> pretty direct
<jdub> ok
<doko> no, java-gcj-compat-dev, but not java-gcj-compat
<Nafallo> hmm
<doko> jdub: the newest java-gcj-compat ?
<Nafallo> view the help menu in synaptic and tell me if you see a bug ;-)
<jdub> oo2 depends on j-g-c not j-g-c-d
<doko> yes, but j-g-c doesn't depend on gcj
<jdub> oh
<Kamion> http://people.ubuntu.com/~cjwatson/germinate-output/breezy/rdepends/gcc-4.0/gcj-4.0
<Kamion> nothing hugely obvious there
<elmo> oh christing fuck
<elmo> I clearly need to automate this and track packages being moved to non-free
<elmo> lincvs hasn't been in main in Debian since oldstable
<elmo> and is mega-obviously non-free
* Kamion tries to wrap his brain around the lincvs licence
<Kamion> as far as I can tell either it's free or it's totally non-distributable
<Kamion> I don't see how it can be both distributable and non-free
<doko> hmm, these are all build-depends ...
<doko> jdub: if you remove gcj-4.0, what is removed as well?
<jdub> i haven't installed it yet ;)
<jdub> just updating everything else first
<jdub> (big update, going to drill down to it
<elmo> Kamion: well.  hum, yeah
<elmo> I don't get it either TBH; AFAICS, it's GPLed for us
<Kamion> yeah, and the arguments in the bug about it being GPL-incompatible would merely mean it's non-distributable, unless it happens to be QPL-compatible
<Kamion> so confused
<Kamion> (and I tend to agree with you)
<elmo>    * Move to non-free because of some dubious license
<elmo>      clauses (Closes: #270461)
<elmo> sigh, I need to kick some ftp-ass ass
<Kamion> mdz: once u-d's installable, can I get an install CD build started first?
<Kamion> because I need to crash soon
<mdz> Kamion: sure, I'll need to do livefs builds before anything else anyway
<mdz> the cd build lock is yours
<Kamion> (it actually *has* locking now, too ...)
<Kamion> rather than "locking by typing 'ps ax' before you start building"
<doko> elmo: please could you add import portaudio from unstable, mythes from experimental? both not yet in breezy, OOo2 could be built with these external libs, currently the copies inside the OOo2 source are used
<Kamion> elmo: any chance you could kill off binary-hppa from whatever mirror little@auckland::ftp-private/ maps to?
<Kamion> I have a cheesy hack in cdimage to avoid syncing that, that I'd like to get rid of
<elmo> you mirror off auckland?
<elmo> are you serious?
<Kamion> it's what you last told me to do when I had rsync limit trouble
<elmo> is this on little, or a warez rsync?
<Kamion> on little
<elmo> christ, you should be using syncproxy
<Kamion> happy to
<Kamion> needs either a password or IP-unlimiting, though
<elmo> kamion: little@syncproxy.ubuntu.com::ubuntu/, same password
<Kamion> 'k
<mdz> ubuntu-desktop looks to be installable x3 now
<Kamion> elmo: I'm using ports.ubuntu.com for the ports/daily builds, hope that's ok
<Kamion> mdz: yep, CD build kicked
<elmo> Kamion: yep, fine
<mdz> livefs builds kicked as well
<mdz> all three are past the obviously-uninstallable phase
<Kamion> mdz: that bluez change had the effect of pulling pcmcia-cs into desktop
<Kamion> for bluez-pcmcia-support
<mdz> Kamion: would you rather have it installed dynamically?
<mdz> I thought we planned to stop doing that for pcmcia-cs too
<Kamion> hm, ok
<elmo> doko: hmm, done
<baskus> sklp, hi
<mdz> we made the necessary changes, but it was too close to release to make the switch iirc
<Kamion> I'm not thinking straight enough to remember what was going on
<jdub> mdz: now that i am more familiar with US meat, i am not so concerned about your vegetarian leanings
<Kamion> elmo: cdimage anonftpsync config changed; I'll test once this build's finished
<mdz> jdub: I wasn't aware that it was a source of concern for you
<elmo> Kamion: cool
<mdz> powerpc died early
<mdz> GAH
<mdz> dpkg: error processing /var/cache/apt/archives/foomatic-filters-ppds_20050720-1ubuntu1_all.deb (--unpack):
<mdz>  failed in buffer_write(fd) (9, ret=-1): backend dpkg-deb during `./usr/share/ppd/HP/HP-OfficeJet_350-pcl3.ppd.gz': No space left on device
<mdz> elmo: ^^ royal
<mdz> oh, nm
<mdz> that'd be out of space on the loop-mounted fs
<mdz> I think
<elmo> no it's in the real FS
<mdz> oh, goody
<elmo> /dev/md0               74G   74G  284K 100% /srv
<mdz> yeah, it's just a chroot at that point
<Kamion> oh, I need to re-mkinitramfs to try out usplash, don't I
<elmo> it was compiling gcc-4.0 at the same time
<elmo> why the heck don't the liveCD build scripts kill -STOP any existing build anyways
<paolo> daniels: any news about the font issue?
<elmo> okay, the bind mount situation on our buildds is out of freakin control
<elmo> buildd@royal:~$ mount | wc -l
<elmo> 50
<Kamion> mjg59: wow, jaggies :)
<mdz> I think a gray for anti-aliasing would be a good palette investment
<mjg59> there's better artwork coming
<mjg59> That's just demo stuff
<mdz> of course
<mdz> it looks surprisingly good for 16 colors
<elmo> 12G     build-hoary-live
<elmo> do we need that?
<mdz> no idea what that is
<mdz> what directory is it in?
<elmo> err /home/buildd/ ?
<doko> elmo: thanks
<Kamion> I assume the blank box is the FIFO migration thing mdz mentioned earlier
<mdz> Kamion: that, and that lsb-base hasn't been taught about usplash
<mdz> elmo: if it really is the stuff for hoary only, and not speshul naming, it should be able to go away
<mdz> elmo: if there are actual builds in there which pre-date the release, those can go
<mdz> mjg59: so is usplash expected to work on amd64?
<elmo> ok, I'll check when the rest of the du finishes
<doko> hmm, after a complete upgrade and reboot on ppc, pbbuttonsd stays at 100% cpu time, restarting pbbuttonsd lowers the cpu usage
<elmo> new binary packages in glibc on day of feature freeze
<elmo> yay deadlines
<doko> elmo: biarch support
<elmo> mdz: okay, so there's 30Gb in public_html which is an easier target
<elmo> how many days of history do you want?
<elmo> we have builds from 20050805
<mdz> elmo: any breezy live builds before today are garbage
<elmo> public_html isn't split by release, just distro
<elmo> and date
<elmo> but it's all august, so err, I guess it's breezy ;)
<Kamion> elmo: nah, I kicked off a warty live CD build just because I enjoy pain
<elmo> is the livecd really meant to be 3Gb?
<elmo> 2.6G    20050809
<jdub> it's more fun that way!
<mdz> heh, I forgot I'd installed this amd64 using the ubuntu-express prototype
<mdz> it has ubuntu-live installed on it
<Kamion> elmo: that's probably the uncompressed image
<Kamion> there's .fsimg and .cloop
<elmo> oh, christ, live CD would be on the machine with the 2, not 3 disk Xserve wouldn't it
<Kamion> why we keep the .fsimg, I'm not sure
<elmo> grr
<Kamion> oh, I know, we have to keep the previous one for partimage, probably
<mdz> Kamion: probably because it takes ages to compress/uncompress
<mdz> (and we need it uncompressed for partimage)
<Kamion> we don't need more than one previous one though
<mdz> I wouldn't be at all surprised if we overflowed CDs with the new cloops
<Kamion> well, two for safety
<mdz> one is plenty; it's expendable
<Kamion> jesus, there are five source CDs now
<Kamion> please write less code kthxbye
<Kamion> ooo2-l10n might not be helping there
<elmo> so can I trash the hoary fsimg stuff?
<mdz> elmo: so long as it's only data, and not code (scripts and such), yes
<mdz> certainly *.fsim
<mdz> *.fsimg
<elmo> -rw-r--r--   1 root   root   1613377536 Apr  9 04:34 new-livecd.kubuntu.fsimg-1024
<elmo> it's files like that
<elmo> -rw-r--r--   1 root   root   2146435072 May  4 05:21 old-livecd.base.fsimg-1024
<elmo> -rw-r--r--   2 buildd buildd 2146500608 Aug  9 04:41 old-livecd.kubuntu.fsimg-1024
<elmo> meh, 14Gb free, that should be enough for another buildd, till infinity wakes up
<elmo> mdz: want to try again?
<doko> Kamion: ooo2-l10n shoudn't add anything, which was there before
<mdz> elmo: running now
<mdz> i386 succeeded (29m)
<elmo> err, CRAP
<Kamion> doko: on the contrary; true, it adds no binaries to binary CDs, but it most certainly adds to source CDs
<elmo> I really shouldn't be up
<elmo> you'll have more luck if I re-enable the bind mounts
<mdz> and amd64 is home free
<Kamion> like, takes up nearly a third of a source CD
<`anthony> http://mail.python.org/pipermail/python-dev/2005-August/055342.html
<doko> Kamion: yes, adding 200MB to the source CD
<mdz> er, gnome-app-install doesn't depend on gnome-app-install-data?
<Kamion> mdz: gnome-app-install-data was removed again; there was no point since both are arch all
<mdz> oh, it's gone
<mdz> and it still doesn't replace/conflict
<Kamion> fortunately it was only there briefly
<Kamion> but yeah, it should
<Kamion> I suppose it would've been simpler if I'd just rejected the one with -data, but I wasn't sure how busy mvo was going to be for the rest of the day
<mdz> amd64 succeeded (35m)
<Kamion> I'm going to have to crash I'm afraid; if people could test the CD images that should be there in ~20 minutes (20050812), then please do, and fix stuff as necessary
<Kamion> I do not have a great deal of time tomorrow so I'll need help in order to get Colony 3 out
<elmo> mdz: does the livecd have a tailable/viewable log, do you know?
<Kamion> elmo: the build? it's in latest/
<mdz> elmo: yes
<mdz> it looks good so far
<elmo> well I re-enabled the bind mounts late, so I hope it's okay
<elmo> it was still unpacking in dpkg when i finished, so hopefully it will be
<mdz> I can always launch another one if it's broken
<mdz> assuming we have the space now
<Kamion> night
<mdz> night
<elmo> yah, should do
<Kamion> $ sleep 2000; for x in amd64 i386 powerpc; do ./breezy-daily-rsync install $x; done
<Kamion> score
<doko> elmo: the powerpc gcc-4.0 build did fail due to insufficent disk space. http://people.ubuntu.com/~lamont/buildLogs/g/gcc-4.0/4.0.1-4ubuntu2/gcc-4.0_4.0.1-4ubuntu2_20050811-2103-powerpc-failed.gz is this you or infinity?
<doko> Kamion: night
<elmo> doko: yes
<doko> elmo: polite answer ...
<elmo> doko: unless it's blocking mdz's current obession, please mail infinity; I'm dangerously tired to be doing stuff
<doko> elmo: will do
<jdub> heh, usplash is funny :)
<jdub> mjg59: is the post-initramfs bit readyish?
<robertj> jdub: why do you say that?
<jdub> which?
<mdz> jdub: no, it isn't particularly readyish; see the earlier discussion
<mgalvin> so when will the cds be ready for d/l or should i go to bed ;)
<jdub> ah, now i see, thanks :)
<elmo> mgalvin: I'm sure they'll be ready faster the more you ask
* jdub watches a kitten across the street fall over, dead
<mgalvin> when will they be read :p
<robertj> jdub: why did you say that usplash was funny?
<robertj> I hit a chicken the other day while it was crossing the road. It was only funny though because my wife asked where it came from.
<jdub> robertj: the current image is not particularly delicious
<robertj> jdub: indeed, it does fail to be scruptulicious
<robertj> jdub: what do you think about black backgrounds? They are uglyish but if the monitor scales down the screen image and draws a black border it looks less od
<jdub> for those screens, i think it's worth trying
<jdub> winxp's boot screen looks great
<Jimbob> *cough*
<sladen> jdub: it's the subtle fade that does the making-it-look-great
<robertj> and at 300x225 no less
<robertj> at least thats what the dimensions on this image I found on google images is
<sladen> robertj: 320x400 IIRC
<sladen> (for the later mostly blue screen with intro/scandisk text on it)
<cat> hey listen i want to be an ubuntu developer what do i do? to be one
<robertj> I make a move that we adopt  http://www.seizurerobots.com/tall1.gif as the new background
<whiprush> cat: check out #ubuntu-motu, good place to start
<elmo> mdz: are WE TEHRE yET?
<elmo> (that's my unsubtle hint that ppc appears to have finished)
<bddebian> robertj: Uhm, I don't think so :-)
<seth_k> yeah, me neither
<seth_k> it needs more oragne
<seth_k> orange
<bddebian> heh
<seth_k> and maybe pink highlights
<mdz> elmo: yes
<mdz> elmo: the CD builds are already done
<mdz> I'm downloading everything now to test it
<elmo> hmm - ok; do you think you'll need me anymore?
<elmo> as resident buildd-biatch, I mean
<mdz> no, I don't think so
<mdz> thanks, and good night
<elmo> night
<bddebian> The Amish have landed.. ;-P
<mgalvin> mdz: the first boot after the initial install panics when intalling in vmware-- Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<mgalvin> just so its known
<cat> hey i want to fixed existing packges where do i star?
<cat> any ideas?
<mgalvin> i am going to try installing on the machine itself too to test it
<bob2> "fix"?
<bob2> bugzilla.ubuntu.com has all the bugs for main
<Lathiat> mjg59: ping
<pef> hello
<mdz> daniels: any idea why the live CD is asking me two questions now, rather than the appropriate one? ("autodetect monitor?" + modes vs. just modes)
<daniels> mdz: that would be because you're reconfiguring, I guess ... maybe preseed xserver-xorg/autodetect_monitor=yes?
<daniels> s/yes/true/
<mdz> daniels: why did it change?
<mdz> (yes, casper uses reconfigure)
<mdz> xserver-xorg/autodetect_keyboard=true seems not to be working also
<mdz> (I get a us layout rather than dvorak)
<lifeless> can you autodetect a dvorak keyboard ?
<daniels> i'll look into the keyboard stuff; it changed because one of the most common use cases for reconfiguration would seem to be 'my configuration is broken'
<daniels> lifeless: based on what the installer uses
<daniels> mdz: i can shunt it to medium with -49 if you like
<daniels> mdz: (_monitor)
<mdz> lifeless: "autodetect" in this case means "infer the X layout based on the console layout"
<lifeless> ;)
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze
<mdz> daniels: wasn't it medium before? (yes)
<Mithrandir> daniels: (or somebody else with an x40): do you ever get eth0 to hang when resuming from suspend-to-disk?
<Mithrandir> with eth1 having fun values like: RX packets:27306 errors:4294967290 dropped:4294967294 overruns:4294967295 frame:4294967293
<daniels> mdz: what's the value of xserver-xorg/config/inputdevice/keyboard/variant?
<daniels> Mithrandir: not out of s4, but I need to rmmod it around s3
<Mithrandir> daniels: this is swsusp, is that s3?
<mdz> daniels: presumably whatever the default is (whatever ends up in the config generated in the livefs build chroot)
<daniels> mdz: well, knowing for sure would be nice
<daniels> mdz: given you have dvorak, it can now be a failure either to detect it altogether, or a failure to seed /variant correctly
<daniels> mdz: given we now use layout=us, variant=dvorak, so failure to seed variant gives you a us-layout keyboard
<mdz> I need to sleep soon, but this should be trivially reproducible with the 20050812 live CD builds
<Lathiat> swsusp i isnt an acpi s state
<daniels> mdz: sure, give me about three hours to download it
<Lathiat> or well, it can be with swsusp2, where it suspends to disk and then to ram, so if your battery doesnt run out, it resumes fast, if not, it resumes from disk. :) mmmm crack.
<mdz> the nice thing about long downloads is that you can do other things while they're happening
<daniels> mdz: yes, but it's less instant gratification for you
<mdz> I need to forego instant gratification in favor of sleep
<mdz> getting desktop installable was enough gratification for one day
<mdz> night all
<Mithrandir> see you, mdz
<jsgotangco> night
<pitti> Morning
<daniels> pitti: morning
<pitti> daniels: hasn't there been a printxkbmap or similar formery?
<pitti> $ zgrep printxkb Contents-i386.gz yields nothing
<torkel> pitti: xkbprint? (which is in xkbutils)
<pitti> ah, that was it, thanks
<torkel> np
<daniels> pitti: er, setxkbmap -print
<daniels> pitti: but yeah, printxkb if you want to generate a postscript file with what xkb thinks your keyboard might look like
<daniels> geometry in xkb is SUCH A CROCK
<ploum> Hello
<ploum> I'm writing doc atm for breezy installation.
<ploum> Is the current installer in the definitive state ?
<ploum> Can I take screenshot from the current installer ?
<Treenaks> I think it's best to wait with screenshots until the Preview Release is out
<Amaranth> isn't that like 5 days before the final release?
<Treenaks> Amaranth: no
<ploum> Treenaks, it's really too late for me. My editor want all before the end of this month :-(
<Treenaks> Amaranth: it's one month before the release
<Treenaks> ploum: hmm..
<jsgotangco> if its only the installer, its probably safe
<ploum> Treenaks, is there any big change planned ?  I can maybe wait for screenshots but I must write the text
<ploum> are current daly-iso a good preview of the breezy installer ?
<robitaille> ploum: https://wiki.ubuntu.com/BreezyReleaseSchedule  we are in a FeatureFreeze since yesterday. So no big changes are planned.
<jsgotangco> yeah
<ploum> robitaille, I knew about FeatureFreeze, but I had no idea about the installer.
<robitaille> but we all know how that turned out for Warty (artwork) and Hoary (Nautilis spatial mode)  :)
<Amaranth> if at all possible it might be a good idea to wait until the 25th
<ploum> I still didn't try daily iso. Is the installer really different from the hoary's one ?
<ploum> Amaranth, I will try to convince my editor (is "editor" the correct english word for a book publisher ?)
<Amaranth> yes
<Amaranth> well, you said the end of the month and that's only the 25th... :)
<ploum> Amaranth, well, officialy they want stuffes for the 19th !
<Amaranth> but i don't know how much of a difference there will be between feature freeze and UI freeze
<mdke> ploum, you'll have to tell your editor that it's their choice
<HiddenWolf> and yes, there are changes in the installer from Hoary
<HiddenWolf> most notably, lvm support and second-stage progress reporting
<HiddenWolf> imho.
<ploum> Indeed. That's quite a big change
<ploum> (I like lvm support :-) )
<HiddenWolf> ploum: lvm is nasty
<HiddenWolf> Or at least, fiddly and annoying
<HiddenWolf> At least as long as it's still buggy. :P
<doko> Kamion, mdz, elmo: please promote to main: libc6-i386 (amd64), libc6-i386-dev (amd64), libc6-amd64 (i386), libc6-amd64-dev (i386)
<pitti> doko: does that mean the end to ia32-libs and amd64-libs?
<pitti> (the beginning end, that is)
<ploum> HiddenWolf, well, I will tried this as soon as I have downloaded vmware :-)
<seb128> hey pitti ploum
<doko> pitti: yes, amd64-libs, don't know about ia32-libs yet
<pitti> seb128: Morning
<ploum> Hello seb128 
<Mithrandir> pitti: ia32-libs includes loads of other evil shit, though
<ploum> (anybody is aware of some free vmware debs for Ubuntu?)
<Mithrandir> note to self: do not put the code you need to look at to debug a live cd problem on the machine where you boot the live cd.
<pitti> lol
<seb128> hum
<seb128> lot of new bugs this week, I guess today is bug triage day
<ploum> seb128, do you want some help ? (if it is appropriate)
<seb128> pitti, mvo: when starting my GNOME this morning I got a stock notify bubble on the top/left corner of my desktop ... is that known?
<seb128> ploum: starting by sending upstream bug upstream would be nice :)
<mvo> seb128: is update-notifier and notification-daemon at the latest version?
<seb128> mvo: the version from 1am when I went to bed
<seb128> ii  notification-d 0.2.1-0ubuntu7 a daemon that displays passive pop-up notifi
<seb128> ii  update-notifie 0.40.2         Daemon which notifies about package updates
<mvo> seb128: please update update-notifier to 0.40.3
<mvo> that should make the problem go away
<seb128> k
<seb128> cool
<seb128> you fix bugs faster than I notice them
<pitti> update-notifier |     0.40.3 | http://archive.ubuntu.com breezy/main Sources
<pitti> update-notifier |     0.40.2 | http://archive.ubuntu.com breezy/main Packages
<pitti> humm
<pitti> ftbfs?
<Treenaks> seb128: people say that of you too, you know
<mvo> pitti: only on amd64 it seems
<pitti> mvo: that's my platform...
<seb128> "E: Package debhelper has no installation candidate
<seb128> Package debhelper is not available, but is referred to by another package."
<seb128> WTF
<seb128> (i386 build log)
<pitti> haha
<seb128> oh it did a retry which was fine 
<pitti> who has ever heard of debhelper?
<seb128> update-notifier_0.40.3_20050811-2335-i386-successful.gz
<mvo> pitti: the failed amd64 build looks like the fallout of the dpkg segfault problem
<seb128>  Table de version:
<seb128>      0.40.3 0
<seb128>         500 http://archive.ubuntu.com breezy/main Packages
<seb128> k
* seb128 updates
<siretart> hey folks
<seb128> hi
<pitti> Hi siretart 
<siretart> is there a ppc buildd admin here? how can I talk to?
<mvo> seb128: if it's not too much hassle for you, it would be nice if you could logout/login to see if the fix works for you too
<pitti> mvo: so a mere g-b should work?
<seb128> mvo: sure
<siretart> openhackware needs to be built on powerpc, explanation is in http://bugs.debian.org/322300. To whom can I talk about this issue?
<spike> hi there
<seb128> a min
<mvo> pitti: yes, it build on my own amd64 and on the other archs
<spike> anybody would pick up a discussion on loop-aes support on hoary?
<seb128> pitti: did you find your firefox crasher?
<spike> imho it's broken, I'd like confirmation on that before reporting a bug
<pitti> seb128: no, I couldn't reproduce it on i386
<spike> I've discussed the issue with Seveas yesterday, but I guess asking in here won't hurt 
<infinity> mvo, pitti, (everyone else): any fallout from the dpkg segvs will be sorted over time today, as I do a mass give-back of every failed package, after having verified that all the chroots have the new dpkg.
<pitti> seb128: I don't want to debug it now, I have some higher urgency things
<seb128> I've a crasher when closing epiphany after browsing https websites
<mvo> infinity: thanks!
<seb128> when is quite annoying
<pitti> seb128: 
<pitti>   4  0x00002aaab491f5e8 in NSGetModule ()
<pitti>   5  0x00002aaab491d5cf in NSGetModule ()
<pitti>   6  0x00002aaaafb10288 in NSGetModule ()
<pitti>   7  0x00002aaaafb09f42 in NSGetModule ()
<pitti>   8  0x00002aaaab0f8689 in PL_HandleEvent ()
<pitti> seb128: ^ that's ffox
<mvo> seb128: I think I asked you this before, but have you seen this before: Gtk-ERROR **: file gtkcontainer.c: line 2447 (gtk_container_propagate_expose): assertion failed: (child->parent == GTK_WIDGET (container))
<mvo> aborting...
<mvo> Trace/breakpoint trap
<pitti> seb128: but the crash happens consistently with moz, ffox, epy
<mdke> i see a bug assigned to "Matthew Garrett <old@broken.account>". Should something be done about this?
<pitti> seb128: and the same version in a hoary chroot works
<infinity> seb128 : The "can't find debhlper, oh my god!" issue is (i think) an apt bug that I need to talk to mvo/mdz about, but it's mostly harmless since, as you say, it gets retried.
<pitti> seb128: so I can't really believe that this is a ffox bug
<daniels> mdke: reassign it to 'mjg59'
<daniels> mdke: that'll autocomplete to the right thing
<mvo> infinity: if you can give me details, I can have a look
<infinity> seb128 : Basically, the failure is earlier on when apt tries to update, gets confused, and ends up having no packages in its packages list.
<mdke> daniels, ok thanks
<seb128> infinity: k
<Kamion> HiddenWolf: what do you mean, LVM support is new in breezy? (it's not)
<seb128> mvo: http://bugzilla.gnome.org/show_bug.cgi?id=300539
<HiddenWolf> Kamion: it's new that the installer wil default to lvm
<Kamion> ploum: if you decide to take screenshots before the UI freeze, it's your look-out when they change
<infinity> mvo : Seems to only happen when running apt outside the root (as sbuild does)... I keep meaning to get try to work up a test case for you and show you the problem, but -ENOTIME, and as I said, it's harmless, just annoying.
<Kamion> HiddenWolf: true. it may not stay that way
<mvo> infinity: ok, thanks. just ping me once you have time to tell me how to reproduce
<mvo> seb128: thanks!
<ploum> Kamion, UI freeze is on 25th ?  So I will wait..
<Kamion> ploum: yes
<Kamion> Mithrandir: at some point over the next two weeks, would you mind sorting out with fabbione which way we're going to swing on the LVM-by-default thing?
<mvo> seb128: lots of dups of this bug :)
<Kamion> Mithrandir: in the feature goals meeting, it seemed to me that the opinion was that it was too complex to be the default
<seb128> mvo: yeah, I've evo crashing like this like 10 a day ....
<seb128> not a surprise
<Kamion> and it needs to be sorted before UI freeze, really
<HiddenWolf> Kamion: you will agree with me that lvm is fiddly. We had a guy in the -nl channel the other day who was puzzled at why ubuntu wouldn't boot. Turns out he was installing on an lvm-partition set up for fedora
<seb128> mvo: if you have a bugzilla.gnome account please Cc you and put a comment, I'll try to poke some GTK guys
<Mithrandir> Kamion: sure, what's the spec name?
<mvo> I added me to the cc now
<Kamion> Mithrandir: InstallerVolumeManagement
<seb128> cool
<Mithrandir> Kamion: willdo
<seb128> mvo: comment maybe not needed
<seb128> mvo: let me ping them first :)
<Kamion> Mithrandir: thanks a lot
<mvo> seb128: that great, thanks :)
<Kamion> Mithrandir: ah yes, see the comment tagged 2005-07-14
<Mithrandir> Kamion: ok.  I also want to get evms support into the installer, but I guess it'll need a spec.
<doko> Kamion: are the CD's built?
<Mithrandir> Kamion: any idea why insmod on the live cd gives me -1 invalid module format when trying to insmod a module copied from a regular system?
<Kamion> doko: yes; I have not yet tested them
<Kamion> Mithrandir: ugh. doesn't ring a bell
<Mithrandir> Kamion: the module is unionfs, works fine in a normal system :-/
<ploum> Mithrandir, I've problem with evms on one computer
<Mithrandir> ploum: what kind of problems?
<ploum> The boot freeze when starting EVMS. (not every time, but frequently)
<ploum> the workaround was simply to remove evms
<ploum> (I've reported the bug and it's confirmed I think)
<Mithrandir> ploum: 13220, I presume?  It's unconfirmed
<doko> Kamion: the new glibc packages for amd64 are still in NEW, but they will breal ia32-libs until it's updated.
<mdke> what package should I file a bug with the wireless hotkey under?
<Mithrandir> ploum: does it just hang for a while or does it hang completely?
<Mithrandir> hmm, apparently gentoo has the same problem wrt insmod and unionfs
<pitti> moin ogra
<doko> on the amd64 boot, I see several times: sed: Unsupported command: I
<ogra> hey
<Kamion> doko: which boot?
<mdke> what is the reason that tab completion is not enabled by default? are there disadvantages to tab completion?
<Kamion> doko: I fixed that the other day
<Kamion> mdke: tab completion *is* enabled by default.
<doko> booting the 2.6.12-k8 kernel
<mdke> Kamion, not for my user
<doko> ohh, and no network :-(
<Kamion> mdke: the full bash_completion isn't loaded because it's slow, but basic tab completion is on
<Kamion> doko: which boot? initial installer boot, or reboot into installed system?
<mdke> Kamion, ah i see. i knew there would be some disadvantage to it
<doko> Kamion: sorry, the latter
<doko> the live cd still downloads ...
<tepsipakki> the new kernel breaks fb-console
<Kamion> doko: if you could try to track that down, I'd appreciate it. I was sure I'd fixed that in udev 0.060-1ubuntu4.
<tepsipakki> i've used vga=0x31A for grub, but now it displays nothing
<doko> Kamion: the sed thing?
<Kamion> doko: yes
<mdke> what package should I file a bug with the wireless hotkey under?
<doko> I'll look
<ploum> Mithrandir, it hang forever !
<HiddenWolf> Does anyone know if the ubuntu-calendar package is still active/
<Kamion> doko: sed /I is a GNU extension so doesn't work with busybox in initramfs
<ploum> (I've waited two hours ;-) )
<mvo> hey niran 
<niran> hey
<infinity> Oh, cock.
<infinity> Kamion : Due to sbuild using apt-get outside the chroot, it also ends up using the system's dpkg too.
<infinity> Kamion : So, I think we need that bugfiz in hoary-updates ASAFP.
<infinity> Kamion : s/fiz/fix/
<pitti> darn
<Kamion> infinity: bugger, ok, shall I do that?
<infinity> Kamion : Please, since you can also approve it. :)
<Kamion> hah, yeah
<Kamion> infinity: is it working well inside the chroot?
<seb128> mvo: update-notifier update works fine
<seb128> mvo: out of the "availabe" typo bug you got a bug for that one :p
<jdub> hey gang, how's it going?
<seb128> hey jdub
<jsgotangco> hi
<seb128> jdub: GNOME 2.11 rock! :)
* pitti still fights with warty's gaim
<jdub> yeah, it is beautiful
<Amaranth> pitti: 8 more months
<seb128> jdub: do you have any opinion on gnome-screensaver? Should we push it now?
<tepsipakki> seb128: yes please!
<pitti> Amaranth: I have a rather easy patch that worked fine for hoary and breezy, and applies, fine, builds fine, but completely breaks the ICQ plugin
<Amaranth> :/
<infinity> Kamion : My tests in breezy chroots have been good.
<seb128> jdub: anyway GNOME 2.10 had some regression like no menu editor and not real cool new stuff ... 2.11 has a lot of nautilus changes, evince, the notification stuff, etc ... ROCKING :)
<jdub> seb128: not for breezy
<seb128> jdub: why?
<jdub> seb128: really hasn't had much field testing
<Kamion> infinity: ok
<jdub> seb128: then again, perhaps it would be best to ship it now, before we do 6.04
<seb128> jdub: suse guys did a security audit, it's fine according to them. It work fine ...
<tepsipakki> i've tested gnome-screensaver, only annoyance is that it always locks the screen
<Treenaks> does it support xscreensaver hacks?
<Amaranth> i thought gnome-screensaver was going to be a 2.14 feature
<seb128> yep
<jdub> Treenaks: yes
<Treenaks> jdub: rock
<jdub> Amaranth: it exists already, but will most likely be in gnome for 2.14
<rubenv> might I assume that network-manager is deferred until breezy+1?
<seb128> jdub: hum. You say not for 5.10 but before 6.04 ... is there something between that? :p
<rubenv> (something that imho should've been in hoary already :-/)
<Amaranth> rubenv: it didn't really do much when hoary froze (did it even exist yet?)
<ploum> seb128, Gnome 2.11 rock indeed. But it sucks really....
<Treenaks> Amaranth: it existed
<jdub> rubenv: it was not even remotely close to ready for hoary, and only just close to ready for breezy
<seb128> ploum: explain?
<Treenaks> Amaranth: but it was a broken piece of donkey crap
<ploum> .. compared that what gnome 2.14 will be :-)
<seb128> ah ah
<jdub> seb128: i was offering a different view
<rubenv> Amaranth: from what I've been ready on the network-manager list, they're trying to do really weird stuff instead of just installing it like the other distro's do
<jdub> seb128: is thinking aloud abruti? :)
<Amaranth> 2.14 will hopefully have some themes using cairo :)
<seb128> jdub: AH AH
<jdub> Amaranth: clearlooks is already ported, richard has sshots
<Amaranth> rubenv: yes, the n-m maintainers in ubuntu are trying to make it not _suck_
<Amaranth> jdub: damn, i need to start idleing in #clearlooks again
<Treenaks> rubenv: yes, like making it work nicely with /etc/network/interfaces-defined interfaces
<Treenaks> rubenv: instead of barfing
<seb128> jdub: anyway I think we should give it a try now, we can roll back easily if required
<Kamion> rubenv: we don't particularly want to install bind9 as part of the desktop, thanks ;-)
<mjg59> mdz: usplash works fine on amd64
<jdub> Kamion: so weak willed! :)
<mjg59> jdub: jbailey has it designed, but not quite fully implemented
<mjg59> Lathiat: Hello?
* jdub doesn't have enormous objections to running bind9
<rubenv> Kamion: bind9 scales big, but doesn't start big
<Amaranth> i'd rather not have every ubuntu desktop in existance running bind
<daniels> Package: bind9
<daniels> Installed-Size: 700
<daniels> OH NOES
<jdub> Amaranth: when it doesn't listen publically, why care?
<Amaranth> *headdesk*
<Amaranth> duh :P
<jdub> "argh! but that's SERVER software?!"
<Kamion> rubenv: it's a horrific thing to include on default desktop systems, because you have to cripple it, which really pisses server admins off
* Amaranth removes himself from this arguement
<daniels> Kamion: 'cripple' -> 'listen on localhost'
<jdub> Kamion: that's only because we're not being creative
<jdub> Kamion: they don't really follow
<Kamion> jdub: being creative would involve using something SENSIBLE instead of bind9. :-P
<rubenv> also, the point of network-manager is to replace stuff like /etc/network/interfaces, why doing all the trouble undoing that?
<infinity> Kamion : The solution there was to split the binary to bind9-bin, and have NM depend on it.
<infinity> Kamion : So, apt-get install bind9 wouldn't be crippled at all.
<jdub> Kamion: bind9 is perfectly sensible, it's a small, robust, dynamically reconfigurable resolver
<Kamion> jdub: I realise there's a fine line between genius and insanity, but
<Kamion> bind9 small? in what universe?
<jdub> it's in main ;)
<daniels> Kamion: installed-size 700, dude
<Kamion> as resolvers go, it's enormous
<infinity> Kamion : Mostly, I need reassurance from you/mdz that this work won't be for naught, given that feature freeze has ostensibly passed.
<daniels> Kamion: we install more shit in xbase-clients that no-one will ever use, than bind9 :P
<Kamion> daniels: it's not actual disk space use I'm worried about, it's that AS A RESOLVER it's huge
<jdub> daniels: i believe Kamion is talking about runtime size
<Kamion> no
<Kamion> I'm talking about actual size compared to the size that a sensible solution would be
<jdub> oh, well, then i think you're clearly insane ;)
<Kamion> bind9 has 300000 lines of new code compared to bind8
<rubenv> Kamion: so the small extra cost of bind9 is too much that it weighs up to forcing crappy networking onto every laptop user out there?
<doko> seb128: no cairo 0.9 yet? ;-P
<rubenv> (for yet another 6 months)
<jdub> Kamion: why bother having a different solution that does the same stuff? it's like running something non-apache as a paersonal webdav server... crazy!
<Kamion> rubenv: please do not put words in my mouth. I'm not saying n-m shouldn't happen, I'm saying that if a better solution can be found we should do that instead.
<Kamion> jdub: the name server market is not nearly so one-sided as the web server market; they're not comparable
<seb128> doko: soname change, 200 packages to rebuild
<seb128> doko: we said after the colony coming
* Treenaks suggests powerdns
<jdub> Kamion: no one's managed to point out a name server that does what's rquired so far ;)
<Kamion> infinity: well, regardless of my personal feelings, my opinion right now is pretty much "whatever"
<doko> seb128: I love freezes ...
* rubenv suggests anything, if it's bad, unbreak it in breezy+1
<seb128> doko: yeah
<Kamion> jdub: iwj was convinced dnsmasq would do the job
<Kamion> I realise his last upload didn't work, but still
<infinity> Kamion : My personal feeling is that networkmanager probbaly isn't mature enough yet, but we can hammer it into shape to be "as good as what we have now, but with a bit more bling", so it's not like it would be a regression.
<seb128> doko: do you have some tools for massive rebuilds due to soname changes/transitions etc ?
<infinity> Kamion : dnsmasq loses out on bind's views, which are needed for robust VPN support.
<Kamion> infinity: hmm
<Kamion> that's a shame
<doko> seb128: yes, on concordia, CXX/auto or something
<seb128> doko: thanks
<seb128> pitti: any idea on http://bugzilla.ubuntu.com/show_bug.cgi?id=13395 ?
<infinity> Kamion : Well, I'll give it a bunch more thought over the weekend and propose some way forward to you and mdz (well, just mdz if you're gone by then)
<Kamion> I will be
<mvo> doko: did you got my message about avm pcmcia yesterday?
<Kamion> today's the last day I'll be around for a while
<infinity> Kamion : I've had too many buildd/infrastructure/transition issues to worry about until now.
<pitti> seb128: hm, no idea
<Mithrandir> doko: I'm going to have a bit of trouble to diagnose my "fcdsl dies all too often" problem, as I don't have that ISP any more.
<seb128> pitti: k, thanks anyway :)
<Kamion> HiddenWolf: (for what it's worth, the default where possible is actually "resize down the partition with most free space and autopartition what's left"
<Kamion> )
<seb128> ploum: thanks for the bug work :)
<infinity> Kamion : Have you approved your own upload?
<Kamion> infinity: not yet
<doko> mvo: sorry, yes: the modules should be in /lib/.../volatile
<jdub> infinity: so did "manage what's not in interfaces(5)" turn out to be ok, or do you want to also manage configured interfaces?
<infinity> Kamion : Wouldn't want to miss the :33 cron.daily. :)
<ploum> seb128, you are welcome
<HiddenWolf> Kamion: good default, but using lvm without having easily usable and obvious (gui?) tools to manage it is rather shakey
<infinity> jdub : The most workable solution for now is to just make NM's and ifupdown's interfaces mutually exlusive, yes.
<ploum> Wow, this bug is soooo coool ! http://bugzilla.ubuntu.com/show_bug.cgi?id=10078  Really weird, I like it !
<infinity> jdub : Something more clever could (and should, probably) be done for breezy+1, but we don't have the time or resources to do it OMG, RIGHT NOW!!
<seb128> ploum: isn't it :p
<jdub> infinity: cool, it's a good start
<Kamion> infinity: ARE WE THERE YET?
<Kamion> infinity: (done)
<Kamion> HiddenWolf: which is pretty much what I said above ...
<Amaranth> how come clearlooks is a seperate source package? i thought it was a part of gtk-engines now
<seb128> Amaranth: because gnome-themes doesn't ship the icon theme 
<Amaranth> Remenic says he isn't doing standalone clearlooks releases anymore, he is only working in gtk-engines
<jdub> infinity: are you on n-m list?
<Amaranth> :/
<Amaranth> so we're stuck with an outdated clearlooks?
<seb128> Amaranth: need to sort that out with thos
<seb128> Amaranth: it's not outdated
<Amaranth> 0.6.2 is not the latest release
<_d4vid> hi all
<Amaranth> Remenic was trying to show me the new progress bar, found out i don't have the latest release
<seb128> Amaranth: please have some tolerance
<infinity> jdub : Just lurking, currently.
<daniels> seb128: ARE WE THERE YET?
<seb128> Amaranth: this week had a new GNOME and feature freeze, I've had a lot of work and I've not sorted that yet
<daniels> seb128: CAN I HAVE AN ICE CREAM?
<jdub> infinity: cool
<seb128> daniels: NO ICE CREAM FOR YOU BEFORE FIXING XNEST :p
<ogra> YES !
<doko> Kamion: how do I mount an initrd image? the timestamp of the initrd image are older than the corresponding files in the udev package
<jdub> daniels: and xmkmf!
<Treenaks> daniels: and glxinfo
<jdub> *oh*, now it dawns on me
<jdub> my battery isn't displaying correctly because of the DSDT
<Kamion> doko: oh, then just 'mkinitramfs -o /boot/initrd.img-`uname -r`'
<jdub> which initramfs should've loaded
<seb128> jdub: have you tried the new "add to panel" dialog?
<daniels> seb128: IT IS FIXED ALREADY IS IT NOT
<daniels> jdub: ENOCARE
<daniels> Treenaks: ENOCARE
<jdub> seb128: ow, holy shit
<jdub> seb128: interesting tactic, thuogh needs some love
<seb128> jdub: yeah, that's the google bounty
<seb128> jdub: I've pushed it yesterday because of the feature freeze ... not sure if that's a feature :)
<doko> Kamion: must the kernel version run, for which I want to create the initrd?
<jdub> seb128: (given categories with one item, and a huuuuge miscellaneous category)
<seb128> jdub: will talk with vuntz, it should return from VAC today
<jdub> seb128: not sure it's worth the delta with gnome for this release ;)
<seb128> jdub: yeah, we need a way to sort that .. we are quite waiting on Vincent before doing some wrong :)
<Kamion> doko: dunno
<Kamion> damnit, I get that initramfs breakage too
<seb128> jdub: we can roll it back before UI freeze if needed
* doko reboot to the current kernel with non-working networking
<ogra> seb128, i'm not totally up to date, but is it intentional to have a "back" button in the dialog ?
<jdub> seb128: ok - happy to wait and see :)
<Kamion> doko: I don't think you should have to be running a matching kernel
<jdub> ogra: when you drill down to launchers, you need it (stupid ui)
<ogra> oh
<doko> Kamion: too late :-)
<siretart> so much shouting today?
<doko> Kamion: yes, that fixes it
<Amaranth> ENEEDEARPLUGS
<infinity> Kamion : AWTY?! (jesus, is cron.daily STILL running?)
<Kamion> it's done
* Kamion fixes initramfs-tools to work in the installer
<Kamion> so, London time, 11:03 cron.daily source, 11:33 cron.daily binary, 11:47ish CD build, 12:40ish rsync finished CDs, 14:00 return from wedding admin stuff and burn test DVDs, 14:30 tests, 15:30 tests done, release?
<Kamion> hmm
<doko> ohh, nice. kernel 2.6.12 switches eth0 and eth1 compared to 2.6.10
* infinity boggles.
<infinity> buildd-mail is OOMing on yellow?
<infinity> That's just plain wrong.
<ogra> doko, yes, there are some rports in the mailing list
* Mithrandir boggles too
<doko> ogra: so what is the right fix? add an alias for the module?
<ogra> doko, try /etc/iftab
<Mithrandir> doh, using a -686 module with a -386 kernel won't work. 
<mvo> seb128: making the gnome #300539 (evoultion/synaptic crash) a g_return_if_fail() (instead of a g_assert) will not do further damage it seems (so we have a plan B now ;)
<ogra> you can specify the device<->HW adress mapping there
<seb128> mvo: cool, comment on the bug saying that? :)
<doko> ogra: strange, the file is there, but it's not honored
<mvo> seb128: no, just tried it. it's not a real fix of course, but if gtk upstream does not come up with something better ...
<infinity> Okay, scratch that, buildd-mail OOMs on amd64 entirely... But only when trying to deal with this one log?
<infinity> Or, no.  When dealing with hoary-updates logs in general, it looks like.  WTF?
<Lathiat> mjg59: I have a problem with framebuffer on my laptop, where the whole thing gets pushed down 2 lines, with the bottom 2 lines being invisible and the top 2 just having a single pixel line down the side of each character spot (happens in the hoary installer, usplsah) -- anyway to fix that other than vga=771 which works? (that gets me 1024x768, and works, altho i think that breaks usplash, but works in the insatller)
<mjg59> Lathiat: Argh. Probably not, I'm afraid (other than fixing vga16fb)
<Lathiat> mjg59: hrm
<paolo> From the output of the last upgrade: http://paste.ubuntulinux.nl/1147
<Mithrandir> Kamion: easiest way to get a module onto the live cd?
* mvo reboots
<Mithrandir> hm, so now I have an unionfs livecd session
<Kamion> Mithrandir: wget
<Mithrandir> Kamion: well, the cd image itself.  I need to put unionfs in an udeb?
<Kamion> Mithrandir: yes
<Kamion> if you want it pre-pivot
<jdub> yay, initrds are now smaller
<Mithrandir> and make sure there's a dependency from casper to the udeb?
<Mithrandir> Kamion: that's part of the huuuuge kernel build process, isn't it?
<Kamion> or anna-install it, either
<Kamion> yeah
<Kamion> debian/d-i/blah
<Lathiat> mjg59: so.. whats wrong with vga16fb? :)
<jdub> anyone else using initramfs and DSDT.aml?
<Mithrandir> Kamion: ok, thanks.
<mjg59> Lathiat: It makes a couple of assumptions about video hardware that aren't necessarily true
<Lathiat> mjg59: is it an overly hard problem to fix?
<Treenaks> jdub: I'm considering it
<mjg59> Lathiat: No idea, I'm afraid
<Kamion> infinity: if you could make sure I get initramfs-tools_0.20_{amd64,i386,powerpc} before :33, I'd be eternally grateful
<Lathiat> mjg59: do you know what the assumptions are?
<Kamion> (ARE WE THERE YET?)
<jdub> $ grep -rl DSDT *; echo pants
<jdub> DSDT.aml
<jdub> pants
<mjg59> Lathiat: Afraid not
<Lathiat> mjg59: okie
<Lathiat> mjg59: cheers
<jdub> ^ in directory with un-cpioed initramfs
<jdub> bum
<mjg59> jdub: I don't think the initramfs support for DSDTs is fully done yet
<jdub> hrm, seem to recall jbailey mentioning kernel update required
<infinity> Kamion : If cron.daily ever finishes, I'll think about what I can do before the next one.
<mjg59> jdub: Yeah, it'll certainly be the latest kernel
<Kamion> infinity: it's done
<jdub> ah, feature freeze period is always so exciting :)
* jdub pictures uploads as wet tennis balls smacking against a wall
<infinity> Kamion : And so is your build (it's arch:all, by the way, no need to beg for three builds..)
<daniels> jdub: ...
<jdub> daniels: it's late.
<Kamion> infinity: oh, er, yeah. :)
<Mithrandir> hi Simira 
<jdub> daniels: fix xmkmf already. ubuntu relies on mgp.
<Simira> morning Mithrandir 
<seb128_> ploum: when you have a bug too you can change it to NEW
<Kamion> jdub: wet tennis balls> some of them stick
<paolo> Any clue about the gnome-app-install dpkg error?  It can't install via upgrade nor remove the package (error at: http://paste.ubuntulinux.nl/1147)
<Kamion> paolo: dpkg --purge gnome-app-install-data, repeat
<seb128_> paolo: dpkg -i --force-overwrite
<Kamion> mvo: could you make gnome-app-install Replaces: gnome-app-install-data, please?
<doko> ogra: is /etc/iftab honored, when the network interfaces are configured with "mapping hotplug" ?
<mvo> Kamion: yes
<paolo> Kamion: http://paste.ubuntulinux.nl/1150
<daniels> jdub: svgslides > mgp
<daniels> jdub: plus, most of us have hacked-up bling versions of svgslides :)
<Kamion> paolo: then what seb128 said, and then purge gnome-app-install-data afterwards
<Kamion> mvo: in fact replaces/conflicts I guess
<ogra> doko, no idea... i dont use "mapping hotplug" anywhere
<Mithrandir> what's the general i386 porting machine?
<daniels> Mithrandir: concordia
<daniels> dchroot -c breezy-i386
<pitti> Mithrandir: dchroot -c breezy-i386
<Mithrandir> ok, thx
<daniels> pitti: oh my god, we think alike!
<Mithrandir> I prefer to add a "linux32" as well, but thanks
<pitti> daniels: well, there aren't so many options :-)
* daniels goes to put CDBS in xorg, and patch debian/patches from within debian/patches :P
<Mithrandir> daniels: eeeevilneesssszz
<pitti> daniels: I never intended the latter
<Kamion> Mithrandir goes Hungarian
<pitti> daniels: btw, even Keybuk managed to patch debian/patches :-)
<daniels> hahaha
<paolo> Kamion, seb128_ : it makes sense, thank you very much.
<pitti> that reassured me a bit
<daniels> keybuk is special
<daniels> -49 built
<daniels> must be perfect
<paolo> Cool :)
<daniels> build time is now under an hour on my laptop
<daniels> used to be >= 2
<paolo> Even cooler.
<Kamion> -49 needed for live CDs?
<daniels> Kamion: somewhat, yes
<daniels> unless you assume that everyone either a) uses a US keyboard, or b) knows how to type on a US keyboard
<daniels> which, tbf, is not unreasonable
<paolo> Token Bucket Filter?
<Lathiat> to be fair...
<Treenaks> daniels: meet he Belgians, who use "azerty" layouts
<Kamion> daniels: how 'bout install CDs?
<Kamion> can I get those started?
<pef> elmo: hi
<sladen> Lathiat: try switching video stretch off and then booting without a vesa mode
<Lathiat> sladen: video stetch is off
<Lathiat> sladen: wasnt booting with a mode
<daniels> Treenaks: azerty is french also
<daniels> Kamion: for c3?
<sladen> Lathiat: /me thought he read  'vga=771'
<Kamion> daniels: yes
<Kamion> sladen: he said it *works* with vga=771
<daniels> Kamion: should be fine.  there's certainly nothing important fixed in -49 over -48.
<Kamion> ok, started then, thanks
<daniels> Kamion: as for lives, I don't know what the problem is
<daniels> Kamion: it could be that the keyboard detection doesn't get run at all, so everyone gets us, or it could just be that the variant setting gets utterly ignored, so you just end up with 'us' instead of 'us(dvorak)'
<Kamion> I may end up giving mdz the instructions on publishing colony releases
<Kamion> we'll see
<daniels> Kamion: how long are you off for?
<Kamion> back on the 30th
<ploum> we (belgians) don't use the same azerty layout as french...  silly
<daniels> ploum: i said that azerty was french, not that the belgian and french layouts are the same
<daniels> i mainly just use german as my litmus test for weird-shit layouts
<daniels> it's pc105, it's got a different key layout, and it's three-level.  if that works, I can be reasonably confident that most things generally work, and go running back to the comforting bosom of pc104/us.
<ploum> indeed ;-)
<daniels> jesus christ
<daniels> my desktop is far nicer for testing xorg than my laptop
<daniels> none of this fork-a-new-server crap
<ploum> seb128, enough bugzilla for me today ! I hope it was a bit helpful (there are some bugs you can mark as UPSTREAM)
<ploum> (oh, I've just seen they are now marked, nevermind)
* daniels stares at mdz.
<daniels>         Option          "XkbRules"      "xorg"
<daniels>         Option          "XkbModel"      "pc104"
<daniels>         Option          "XkbLayout"     "us"
<daniels>         Option          "XkbVariant"    "dvorak"
<daniels> perhaps bonghits will fix my keyboard layout
<daniels> (i.e., it works for me, dude)
<daniels> mdz: are you *sure* autodetect_keyboard was true?
<sladen> Kamion: well, that's what I *thought* Lathiat said.  But that is conflicted 6 lines up by 'wasnt booting with a mode'.  So maybe I'll just ignore both since my binary maths module gets a bit up set when I start feeding it quantum input sets :)
<daniels> also, AFAICT, XKB is far, far more clear and sensible than the console-data crap.  this is concerning.
<seb128> ploum: really nice from you, thanks again
<seb128> ploum: you can change the status yourself ... or don't you hve the bugzilla level for it?
<ploum> seb128, I don't have the level
<seb128> ploum: oh, you should have said so
<seb128> what email do you use?
<ploum> ploum@fritalk.com
<seb128> can any bugzilla admin give him the rights to change bug settings?
<seb128> thanks
<ploum> thank in advance
<seb128> you're welcome :)
<ploum> Good afternoon all, time to eat :-)
<seb128> enjoy your lunch :)
<ploum> ;-)
<Seveas> spike..?
<Seveas> I've confirmed it on i386 and filed it on malone (it's a universe package)
<spike> cool, tnx much
<spike> Seveas: can u point me to malone? isn't bugzilla.ubuntu.com the place for reporting bugs?
<ajmitch> spike: launchpad.net/malone
<spike> https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla
<spike> oh, k
<spike> yeah, googled it out
<ajmitch> which is the place for reporting universe bugs
<spike> uhm, just universe? what about bugzilla.ubuntu.com? the overall look and feel is unfinished/unused, but I saw bugs listed there
<ajmitch> universe bugs, for now
<spike> and since I'm on devel, what does it take to be a ubuntu DD? same ages that for debian?
<spike> k, tnx
<ajmitch> the best way to get started it to help out in universe, with the MOTU crew
<spike> or with some work and effort (and time of course) u can get in?
<\sh> morning
<spike> ok, I'll look into that, tnx
<spike> 'mornin \sh 
<ajmitch> hi \sh  
<\sh> who is the pro in things like ubuntu-installer
<spike> Seveas: btw, did u read the links I gave u yesteday? about the watermarking attack and stuff
<\sh> hey ajmitch 
<spike> Seveas: and would u mind some more discussion about the topic? there's another thing worth doing regarding that stuff...
<spike> another thing: on http://mirror.isp.net.au/ftp/pub/ubuntu/pool/universe/r/rlog/ I can see some libs I need, but apt-cache search rlog doesn't show anything, what am I missing? my mirror isn't up to date?
<Seveas> spike, I didn't get to reading them yet, most of my tome goes into studying for a network security exam
<spike> I c, nm
<Seveas> and rlog is only in breezy afaik
<spike> ah
<Mez> grr, what was the kernel update about?
<Mez> It broke my breezy
<Mez> mdz: ping
<spike> Seveas: any suggested way I can get it?
<ajmitch> Mez: initramfs 
<Seveas> spike, http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=rlog&searchon=names&subword=1&version=breezy&release=all confirms it
<Mez> so why has it broken my internet access?
<Mez> and why does it try to open my CD drive on boot
<spike> damn... mmmh
<Seveas> a good way is backporting it, add a deb-src for breezy to your sources.list, apt-get source it and use dpkg-buildpackage
<ajmitch> Mez: that's a new one for me - most 'it breaks' complaints I saw were related to lvm
<Mez> ajmitch, well, it says "/dev/cdrom: open failed: no such device
<Mez> Cannot find volume hda8
<Mez> but then boots up fine
<ajmitch> right, could be the same
<Mez> when I get into GUI though, It then has no net access
<Mez> I try and bring eth0 up, but I don't know how to get it to auto-configure 
<ajmitch> Mez: bugzilla!
<spike> Seveas: is there any place to look for backports?
<spike> ah, sry, missed ur last message
<Seveas> ubuntu-backports section :)
<Mez> ajmitch, at the moment I'm just asking how to get my network backup manually (I can bring eth0 up bt I dont have any IP address or anything)
<Seveas> hoary-backports*
<ajmitch> Mez: usually ifup will run what is needed
<Mez> ajmitch, I've been using ifconfig eth0 up
<Mez> ajmitch, I'll be back if  can get it to work
<\sh> hmm...
<\sh> If I set in the makefile of linux-source-2.6.12 the extraversion to 3-i386 and trying to build a module for 2.6.12-3-i386 (which is used by colony 2) do I have any chance to have load a newly compiled module in the initrd?
<tepsipakki> kamion: daily-netboot loops in partman
<Mez> ajmitch, where should ubuntu usually bring up the ethernet?
<Mez> weirdness... 
<Mez> I worked out what happened but I dont know how
<ajmitch> hm
<tepsipakki> mez: in /etc/rcS.d
<tepsipakki> sigh..
<ajmitch> he'll be back
<tepsipakki> I'm about to post a message on d-d-l about the runlevel-madness
<tepsipakki> but lunch first
<spike> yeeeeeeeeee, the backporting succeded
<spike> cool
<spike> tnx Seveas 
<spike> encfs worked too.. wonderful
<spike> Seveas: that's the other thing I wanted to mention... if u don't want to go loop-aes u can go encfs
<Lathiat> libxine got compiled without xvideo
<daniels> whoops
<daniels> i guess that'd be mine to fix too
<Lathiat> wondered why it was chunking so bad
<Lathiat> gxine told me :)
<Lathiat> whinge you need xv, whigne it was around at compile time
<Mez> hmmles
<Mez> I think I know what went tits up
<Mez> Kamion: ping
<Lathiat> daniels: if you want i'll send you a dbediff
<Lathiat> *debdiff
<Mez> oh yeah: mdz: unping
<daniels> Lathiat: a runtime dependency on libxv1?
<Mez> why are there no packges in bugzilla for the kernel?
<daniels> there are
<Mez> they dont show
<daniels> yes they do
<daniels> start typing 'linux' in
<daniels> note the array of choice
<daniels> a veritable plethora
<Nafallo> dpkg segfault didn't vanish?
<Nafallo> context: http://people.ubuntu.com/~lamont/buildLogs/e/ethereal/0.10.12-2ubuntu1/ethereal_0.10.12-2ubuntu1_20050812-1008-amd64-failed.gz
<Mez> daniels, I see linux-headers and linux-meta relating to the kernel
<Mez> daniels, I want to report on linux-source-*
<daniels> Mez: 'linus'
<daniels> er
<daniels> 'linux'
<Mez> daniels, just file against linux then - I assumed package names in bugzilla would be relevant to either the source package or the binary package
<pitti> infinity: is the amd64 buildd busy or down?
<daniels> pitti: i think it's busy
* pitti taps foot, waiting for the gaim amd64 build
<jdub> mjg59: ping
<mjg59> jdub: Hi
<jdub> yo
<mjg59> What's up?
<jdub> /msg :)
<lu|dinner> jdub: isn't it a little early where you are? 
<jdub> luis_: yes, but i am wired
<seb128> pitti: where is gimp20.mo with your language packs?
<jordi> nooo
<jordi> not that file
<jordi> I've been working on gimp20 all morning at work
<pitti> seb128: I noticed that some files just seem to be missing (xchat, too)
<pitti> seb128: I'll fix that next week, don't worry
<seb128> pitti: hum, is that long to fix?
<pitti> seb128: probably not, but long to find out why
<seb128> k
<seb128> luis_: around? Have you guys a way to copy a file on the liveCD if it doesn't come with a package?
<pitti> seb128: my problem is, I need to add another feature to the audio stuff, but the flood of security stuff delayed me
<pitti> seb128: I really need to sort that out before I continue bug fixing
<seb128> pitti: GNOME guys are rolling a GNOME liveCD for a french magazine and it's due on monday
<seb128> pitti: and they noticed gimp is not translatted
<pitti> grumpf
* pitti looks into it
<seb128> pitti: maybe they can copy the .mo with a hack, wait on luis_'s reply
<luis_> seb128: yeah, we can
<luis_> seb128: not pretty, but we can
<seb128> luis_: k, I'll reply that to the mail
<pitti> gimme 15 minutes to attempt to fix it
* jdub fears livecd based on breezy in user's hands
<luis_> s/pretty/maintainable/
<luis_> jdub: media!
<luis_> :)
<jammcq> jdub: hey
<jammcq> just got yer email, thanks
<jdub> yo jammcq 
* jammcq is home now :)
<seb128> luis_: you probably want today's gtk upload to, it fixes the fileselector crasher 
<jdub> luis_: they're not using it for a coverdisk, just a review?
<jammcq> and now, after flying all night, i'm heading to bed
<luis_> seb128: can you put that in the email?
<seb128> luis_: sure
<luis_> jdub: I wouldn't recommend it if I wasn't using breezy myself with fairly high confidence
<jdub> luis_: that sounds like a dodgy "yes, coverdisk" answer :)
<pitti> seb128: 
<pitti> $ zgrep gimp20.mo Contents-i386.gz |grep fr
<pitti> usr/share/locale-langpack/fr/LC_MESSAGES/gimp20.mo          translations/language-pack-fr-base
<pitti> it doesn't?
<pitti> oh, oops
<pitti> 8889548 May 25 00:45 Contents-i386.gz
<pitti> why isn't our Contents.gz updated?
<luis_> jdub: it is, AFAICT
<Mithrandir> pitti: it's supposed to be updated once a week or so, but it's a fairly expensive operation, so you wouldn't want to run it every 30 minutes.
<pitti> Mithrandir: right, but May???
<pitti> I downloaded it this morning...
<Mithrandir> pitti: mail elmo?  seems to be broken, I agree
<jdub> luis_: ha ha
<luis_> jdub: I haven't really been the one talking to the magazine, that is mostly the frenchies (marcus and dave)
<luis_> so I'm not entirely sure what I'm helping on at the moment, but yes, I believe it is a cover disc
<daniels> luis_: you're using breezy with a US-layout keyboard
<luis_> grr, friday already
<jdub> http://www.linuxformat.co.uk/blog/?p=21
<luis_> daniels: I am, though I believe marcus is with french, after installing extra packages
<daniels> luis_: mdz alleges that it's sort of non-specifically broken outside that, but I haven't had time to check, and it's also 2215 on Friday
<jdub> fucking...
<luis_> jdub: ?
<luis_> jdub: cheering on mjg59's college already?
<jdub> re the url
<luis_> daniels: it is broken by default on the livecds, missing a package, but I believe marcus identified and installed the missing package
<luis_> jdub: it is long, break it down for me ;)
<jdub> luis_: look at pretty pictures
<jdub> (and not so pretty)
<hmrocha> hi, why is browser the default mode of nautilus?
<daniels> luis_: if you could find out what it is, that would kick arse
<hmrocha> and why have you changed the behaviour of the left button to become what it used to be?
<hmrocha> always opening windows with the middle mouse button doesn't make to much sense
<jdub> hmrocha: you can also hold shift
<jdub> hmrocha: we've switched to browser mode and un-broken spatial to satisfy the needs of real users
<hmrocha> jdub, yes, but that way i would need to move my hand to the keyboard
<hmrocha> jdub, hmmm, good point there
<jdub> hmrocha: always good to keep one hand on each :)
<hmrocha> jdub, my mom didn't like spatial very much
<jdub> yeah
<Treenaks> My mom did :)
<jdub> pretty scary when you're not expecting it
<hmrocha> Treenaks, your mom is a XI century mom :)
<hmrocha> ups, XXI
<jdub> 1980's more like it :)
<Treenaks> hmrocha: my mom only knew about the on/off button until a few months ago
<hmrocha> my mom doesn't know what copy-paste is
<hmrocha> Treenaks, ok, you win :)
<hmrocha> jdub, ok, i agree switching to browser mode as default, users that use spatial can always switch back to it
<hmrocha> jdub, but why not leave the "open and close upper" with the left mouse button?
<Lathiat> because it was silly
<hmrocha> silly?
<hmrocha> most of the time you want to open and close the upper
<hmrocha> i rarely use the left mouse button to open a window, always the middle one
<hmrocha> that's silly!
<jdub> hmrocha: it really detracts from the spatial model
<jdub> ifwe could do spring-loaded folders, that'd go a long way to fixing the problem
<Treenaks> jdub: why can't we?
<jdub> hello patents
<Robot101> spring loaded?
<jdub> meet apple
<hmrocha> jdub, btw, are you the 10x10 guy?
<jordi> hmrocha: TOTALLY
<jdub> it's been implemented for nautilus, but we just can't do it
<jdub> hmrocha: yes, that guy
<Treenaks> jdub: scary.. when is the Classic Mac old enough for the patent to expire?
<hmrocha> jdub, you're the king, great speech at guadec
<Treenaks> jdub: can't be long
<jdub> maybe, worth checking out
<jdub> though i think they've done some update cheating patents
<hmrocha> hoary still has the open and close upper with the left button
<Mithrandir> Treenaks: spring-loaded folders was introduced in MOS8, so I imagine it'll still be ten years or so
<hmrocha> users won't like when switching to breezy
<Treenaks> Mithrandir: It was? I remember using it on either a classic or macos 7.x
<hmrocha> breezy will be released when? november?
<Lathiat> oct
<hmrocha> cool
<jdub> hmrocha: luckily, the efault will be browse mode, so only users who really care will get spatial (and they will want it working without close-behind)
<hmrocha> i will switch all my college computers from mandrake to breezy on christmas holidays
<Treenaks> Mithrandir: you're right... Filed: 	 June 11, 1993
<Treenaks> Mithrandir: http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=5583984.WKU.&OS=PN/5583984&RS=PN/5583984
<Lathiat> daniels: it says failed to find libXv.so or libXv.a
<daniels> Lathiat: during *runtime*??
<Lathiat> daniels: no, build
<daniels> oh, so missing b-d
<Lathiat> nope
<Lathiat> its there
* Lathiat tries something
<Kamion> tepsipakki: I've just removed partman, which is superseded by partman-base; that should sort that out
<Lathiat> daniels: solved it
<Lathiat> it wants --with-xv-path=/usr/lib
<Lathiat> who knows why
<Kamion> Nafallo: requires the hoary-updates upload I did
* Kamion throws tomatoes at Mez for pinging him without including any content
<tepsipakki> kamion: so I should change the preseed-file to use partman-base?
<`anthony> jdub: hey, in that third photo - it looks like from your talk. I wonder if you were swearing at the moment it was taken?
<Kamion> tepsipakki: preseed's irrelevant, the archive was just inconsistent
<Kamion> tepsipakki: give it an hour and try again
<Kamion> tepsipakki: (i.e. your netboot install was pulling in both partman and partman-base; they share all the same files => badness; udebs don't support Conflicts so you kinda lose)
<Kamion> well, they share all the same files except for their postinst, so you end up with two postinsts and two main-menu items etc. that both call partman
<tepsipakki> ah, ok
<hmrocha> a guy in #ubuntu was talking about google earth
<hmrocha> that a killer app that's making people reboot from linux to windows
<hmrocha> is there someone here with google connections to try to persuade them to port the app to linux?
<pitti> seb128: ok, I think I sorted out the gimp issue
<pitti> seb128: I' still puzzled about xchat, debugging now
<pitti> seb128, luis_: I will upload langpack updates today which include gimp
<luis_> pitti: thanks
<seb128> pitti: thank you ... just curious, what was the issue for gimp?
<`anthony> hmrocha: I would expect that google's already working on the mac and linux ports. The windows version is from the company (keyhole) that they bought.
<pitti> seb128: some packages cannot be imported automatically, gimp is such a problem case
<pitti> seb128: it has only one pot file, but several domains
<seb128> ah right
<pitti> seb128: so my scripts just used the library translations
<pitti> gimp needs to be fixed to create pot files for all domains...
<seb128> pitti: language-pack-fr-base: /usr/share/locale-langpack/fr/LC_MESSAGES/xchat.mo
<seb128> for xchat
<pitti> seb128: and that works for you?
<hmrocha> `anthony, cool :)
<pitti> $ locate xchat.mo
<pitti> /usr/share/locale-langpack/en_GB/LC_MESSAGES/xchat.mo
<pitti> I don't have a .de one
<`anthony> I have no sekrit knowledge in this area, just assumptions.
<seb128> pitti: let me install xchat
<pitti> seb128: it will certainly work, nm
<pitti> seb128: I straced, and xchat looks for the file, but it isn't there for de
<seb128> yeah, it does
<jdub> `anthony: probability high ;)
* seb128 reinstalls xchat-gnome
<daniels> Lathiat: i bet I know what that is
<pitti> seb128: uh, is there such a package? I can't find
<pitti> it
<Lathiat> daniels: that xines detection sucks?
<seb128> pitti: it's an universe package
<daniels> Lathiat: yes
<Lathiat> i looked at it
<pitti> seb128: odd, I have universe enabled...
<Lathiat> it explicitly check s the path you pass
<seb128> pitti: maybe it didn't build on amd64
<Lathiat> it even errors "cant find LibXv.so in <blah>"
<Lathiat> s/blah/blank
<seb128> pitti: apt-cache showsrc xchat-gnome?
<pitti> seb128: ah, that may be the reason
<pitti> xchat-gnome | 0.4-0ubuntu1 | http://archive.ubuntu.com breezy/universe Sources
<pitti> indeed
<Lathiat> i just built one with --with-xv-path and it seems to work
<daniels> Lathiat: right
<Lathiat> want a diff?
<pitti> seb128: so it *never* built for amd64, as it seems
<seb128> "/usr/bin/ld: cannot find -lperl"
<seb128> grumpf
<daniels> Lathiat: sure
<seb128> pitti: yeah, I've packaged it like 2-3 weeks ago and only 1 upload
<pitti> ah, ok
<pitti> nevermind
<seb128> why isn't perl supposed to be installed everywhere?
<pitti> only perl-base
<pitti> but not perl, or libperl
<seb128> k
<Nafallo> Kamion: why? that one is for breezy
* hmrocha is away: coding
<Kamion> Nafallo: yes, but apparently the buildds run dpkg outside the chroot sometimes
<Kamion> doko: um, libc6-i386 is not in the archive
<Kamion> (yet, anyway)
<Kamion> so changing something to depend on it at this point is very unhelpful, since we are trying to produce CDs
<doko> Kamion: yes, seen. but the dependency still has the ia32-libs alternative
<Kamion> hm, true
<Kamion> ok
<Kamion> not the -dev ones though, from the changelog?
<doko> the other one is a suggestion only
<Kamion> ah, ok
* Kamion is in a tearing hurry and not checking everything 100% ...
<doko> :-) you should prepare for tomorrow ...
<Kamion> I'm trying
<mvo> Kamion: tomorrow is the big day? 
<Kamion> yes
<ajmitch> I hope it all goes well for you
<Kamion> thanks
<mvo> Kamion: I wish you (and your gf) the very best for tomorrow :)
<Kamion> hopefully by tomorrow we shall be less stressed ;)
<jdub> Kamion: definitely not "by" :-)
<daniels> Kamion: i'm repacking the live cd now ... working as fast as I can, sorry
<jdub> Kamion: do cheek exercises tonight
<jdub> Kamion: to limber up
<Lathiat> daniels: http://bur.st/~lathiat/xine.debdiff - wfm(tm)
<Kamion> daniels: I've given mdz Colony release instructions now, so if all else fails he can do it or somebody else can be delegated to do it
<daniels> Kamion: cool
<Kamion> jdub: thppppt
<jdub> seriously
<jdub> my cheeks were hammered after wedding day
<jdub> it was harsh
<Kamion> never smiled so much in your life?
<mdke> I filed bugs #13396 and #13394 earlier as "UNKNOWN" - if anyone knows better than me what packages they should be under, I would appreciate reassigning. Thanks!
<jdub> not in such a compressed period, no ;)
<seb128> Lathiat: working on xine?
<Nafallo> Kamion: ooh. odd :-P.
<Lathiat> seb128: just makign Xv work so video playback doesnt totally suck balls. :)
<Lathiat> seb128: what work does it need?
<seb128> Lathiat: somebody to figure why backtrace are useless ... I guess it stripped 2 times or something like that
<bddebian> Howdy
<daniels> Lathiat: it needs to lose anything patent-encumbered it may have in it
<daniels> Lathiat: if xorg -49 fixes the apparent world-breaking bustage on the live cd or whatever it is, i'll do it on monday/tuesday
<Lathiat> daniels: so that means xine becomes as usefull as totem-gstreamer? :)
<daniels> also in main, and probably also the default for breezy
<ogra> GRRR, why is copy/paste this broken... it breaks totally here
<Treenaks> ogra: blame daniels :)
<ogra> seb128, is there a bug open about copy/paste its totally f*chked.... pasting from term to term takes minutes and blocks the target term totally...
<daniels> it's not an xorg thing
<Lathiat> daniels: is ffmpeg patent encumbered
<ogra> nope, its this damned gnome clipboard crap... i dont like it ...
<seb128> no such bug
<seb128> and the clipboard rocks
<ogra> not here though
<daniels> Lathiat: i think so, but not sure.  i'm going to go through and make a list and find out.
<Lathiat> hrm
<Lathiat> can the dll loader stay in so people can choose to get dodgy dlls if they want?
<daniels> i don't see why it couldn't
<daniels> i mean, we ship ndiswrapper
<Lathiat> right
<Lathiat> there not necesarily dodgy anyway fi you put them there yourself.. i suppose
<Kamion> mjg59: do we want usplash on the second boot into base-config? (maybe so, maybe not)
<pitti> infinity: warty/gaim on amd64 doesn't like me, is that still the crowded buildd?
<daniels> uhm
<daniels> Kamion: how much do you know about mastering live CDs?
<daniels> Kamion: i remastered the standard breezy live to have xorg -49 (using -BOGiE, so no new packages) and ... fuck, never mind
<mjg59> Kamion: Hrm. It might actually be easier not to do it.
<mjg59> Is there any way of telling?
<Kamion> mjg59: at the moment, it won't be, because it's in desktop
<Kamion> daniels: um. ok :)
<mjg59> Kamion: Oh, heh, yes. Ok, no problem then.
<mjg59> Kamion: Though in that case we need to regenerate the initramfs after usplash has been installed
<Kamion> we could potentially move it up later
<Kamion> mjg59: oh, yeah, forgot about that
<Kamion> mjg59: let's leave it where it is for now and think about promoting it later when it's more polished
<daniels> Kamion: *cough*ithinknothingisbeingstrippedinxorganymore*cough*
<Kamion> I don't want to move it for colony 3 anyway
<Kamion> daniels: oops
<daniels> Kamion: it would explain why the live CD is so frigging big
<daniels> this strip bug is going to kill me one day
<daniels> running on xfs, the xorg build when run from d/r fails to strip stuff with permission denied
<daniels> it's fine on ext3
<daniels> i can't make a smaller testcase, because it works from the command line
<Lathiat> ... wtf?
<daniels> so I had that combined with the fact that none of the modules were being stripped because they aren't under debian/xserver-xorg any more
<daniels> -> big live CD
<daniels> -> way too big to fit on a CD
<pitti> ogra: I currently process some main inclusion reports; please mentio
<pitti> n setuid/setgid apps
<pitti> ogra: e. g. atomix is setgid games
<ogra> oh...
<ogra> pitti, i didnt kow that this has to be done for unprivileged groups... i'll look over it today again
<pitti> ogra: nevermind, I look at the pkgs anyway
<pitti> just for the future
<ogra> oki
<ogra> they look better then expected ... security wise :)
<pitti> ogra: could you sort out the gcompris issues?
<Kamion> argh, why is hotplug not ifupping interfaces?
<ogra> pitti, sure will do it today
<pitti> ogra: xaos:
<pitti> Build-Depends: debhelper (>= 4), aalib1-dev, libpng3-dev, zlib1g-dev, xlibs-dev, svgalibg1-dev [i386] , dpkg-dev (>= 1.9.0)
<pitti> ogra: it also offers a
<pitti> x11 frontent
<ogra> yup
<pitti> can you please disable svgalib?
<ogra> oki
<pitti> ogra: the report says that the dependencies are all in main...
<Kamion> also please do the aalib transition: aalib1-dev -> libaa1-dev
<pitti> ogra: disabling should be easy since it is only on i386 anyway
<ogra> pitti, yup... i checked it on amd64 ... but didnt look close enough it seems
<pitti> ogra: there is no xaos package for i386, btw
<ogra> lol
<ogra> guess why :)
<jdub> seb128: you tried scaling totem/xine videos recently?
<seb128> jdub: scaling? like fullscreen, or changing the ratio?
<ajmitch> jdub: not built against xvideo, Lathiat had debdiff around :)
<jdub> both
<jdub> doesnt-- ah
<jdub> i was just rebuilding to see if that was the case
<seb128> works for me
<jdub> Lathiat: ping
<jdub> seb128: works, but looks ugly as sin :)
<seb128> yeah
<seb128> use totem-gst
<seb128> :p
<ajmitch> http://bur.st/~lathiat/xine.debdiff for your viewing pleasure
<seb128> blame jdub for the bug
<seb128> he touched xine :)
<jdub> right, i'll turn it around
<jdub> doko_: ping
<doko_> jdub: pong
<daniels> bloody frigging hell, create_compressed_fs has been running for ages
<daniels> ~45min on my reasonably beefy amd64
<jdub> doko_: you were going to spin xine 1.0.2 after feature freeze?
<Lathiat> jdub: pong
<doko_> or 1.1, I don't know yet
<jdub> doko_: hadess said there weren't too many differences
<jdub> Lathiat: n/m
<jdub> Lathiat: just pushing your xine change
<Lathiat> jdub: cool
<seb128> I got a mail from "one of the xine project leaders" who "would like to offer  
<seb128> any help the xine team and I can give you to resolve any outstanding  
<seb128> issues."
<jdub> elite
<doko_> jdub: ok, I give it a try next week
<seb128> I've replied/Cced daniels who is supposed to be working on xine
<daniels> (and still going)
<daniels> seb128: oi
<jdub> doko_: ok, i'm not making any massive changes anyway
<daniels> seb128: i replied too
<seb128> but if somebody else wants to work on that too let me know
<seb128> daniels: I know, I got the reply :)
<pitti> ogra: please watch out for build deps, they are not all in main
<ogra> pitti, oki
<doko_> daniels, seb128: ohh, no please do. just upload xmkmf before ;-)
<seb128> just pointing to other guy working on xine that if they need to ping an upstream ...
<daniels> bah, xmkmf
<jdub> go go go! :)
* jdub wants to give mgp his loving
<ogra> hey, what about xnest first
<Treenaks> ogra: jdub != daniels
<Lathiat> can someone send a test mail to lathiat@bur.st
<Treenaks> Lathiat: sent
<Lathiat> thanks
<ogra> Treenaks, xmkmf != xnest
<Treenaks> ogra: good point
<ogra> Treenaks, i need sabayon for edubuntu :)
<daniels> ogra: xnest is already fixed
<daniels> seriously, just autotool your crappy xmkmf-using apps
<daniels> you'll be grateful I made you
<jdub> INVALID SOLUTION PROVIDED, TARGETING SYSTEM ENABLED
<daniels> DUDE, IT'S XMKMF
<daniels> LET IT GO
<daniels> xmkmf : autotools :: banarama, milli vanilli, oingo boingo, duran duran : most everything else
<Treenaks> kmfdm?
<daniels> er, bananarama
<dilinger> Treenaks: mdfmk
<Treenaks> dilinger: not anymore
<Kamion> anyone with bright ideas for #13389, speak up
<Kamion> sorry, #13398
<dilinger> Treenaks: that was just 1 album, right?
<jdub> ooh, xine has polypaudio support
<daniels> run awaaaaaaaaaaay
<Treenaks> dilinger: afaik
<Lathiat> jdub: yeh i noticed taht too
<Treenaks> jdub: yes, but does it have xmms-plugin support, like mplayer does?
<jdub> daniels: that is not a valid solution. there are projects in our repos that use xmkmf now, and we need it to build them. "convert to autofoo" is entirely unreasonable, and hardly even worth raising.
<Treenaks> maybe for breezy+1?
<daniels> jdub: that may be why I have no intention of seriously dropping xmkmf
<daniels> jdub: but as it happens, there's not much that uses it, and it's really low-priority
<Lathiat> damnit vmware ate my control key 8again8
<Lathiat> and mjy shift key
<jdub> daniels: so be the signal, no point sending the wrong message
<Treenaks> Lathiat: press all of them at once
<Treenaks> Lathiat: then release
<Lathiat> aaawaaaaaaw
<Lathiat> whic ones/
<Treenaks> Lathiat: both ctrls, both shift
<Lathiat> awnope
<jdub> Treenaks: what would xine xmms-plugin support do?
<Lathiat> hheee
<daniels> jdub: i've been giving the same answer every hour for a couple of weeks now, it's starting to get old
<Lathiat> damnit
<pitti> OMG, nvu is a mess
<Treenaks> jdub: mplayer can use xmms input plugins to parse audio/video
<Lathiat> jdub; output sound or whatever with xmms plugins/
<Lathiat> ah input
<Treenaks> Lathiat: I think maybe output/effects too
<Treenaks> Lathiat: (yes, it's evil and scary)
<Lathiat> indeed
<Kamion> projects that use xmkmf> not anything in base like groff, oh no
<daniels> Kamion: groff uses it??
<Kamion> for gxditview, yes
<paolo-> Sigh!
<daniels> Kamion: well, fuck
<bddebian> Such language
* bddebian covers his ears ;-P
<paolo-> initramfs broke my USB initrd...
<Kamion> infinity,lamont-away: please clear the xlibs-pic dep-wait on gst-plugins0.8 everywhere; it's obsolete
<Lathiat> a jjj
<Lathiat> bah i cant change screen windwos
<Kamion> infinity,lamont-away: or rather, the gst-plugins0.8 dep-wait on xlibs-pic
<paolo-> I fixed it adding the modules to the proper file (/etc/mkinitramfs/modules) but then it break because it tries to load 8139cp instead of 8139too, argh.
<paolo-> Adding 8139too to that file and rebuilding the image did let the pc boot - but the network card was not configured.
<Kamion> paolo-: #13398
<paolo-> It needs a login, let me subscribe...
<Kamion> you don't need a login to view bugs
<Kamion> http://bugzilla.ubuntu.com/show_bug.cgi?id=13398
<paolo-> Ah, oops!  Right.
<paolo-> It is indeed it.
<paolo-> Is there a breezy-bugs ml, like breezy-changes one?
<jdub> paolo-: ubuntu-bugs -> no branch-specific list
<daniels> STILL RUNNING ARGH
<Lathiat> might be in a loop ;0
<Lathiat> that was supposed to be a smiley but my shift key doesnt work
* Lathiat restarts x
<Lathiat> small x, argh.
<seb128> paolo-: there is desktop-bugs list too
<paolo-> At least now this kernel/udev MAKEDEVs /dev/hd[abcd] *
<paolo-> seb128: what is it about exactly?
<seb128> paolo-: bugs from ubuntu desktop packags
<seb128> basically GNOME/fd.org/... packages
<pitti> seb128, luis_ : new langpacks uploaded (NEW: now super fluffy with gimp, xchat and other goodies)
<seb128> pitti: you rock :)
<Treenaks> fluffy rock?
<seb128> pitti: what was the issue for xchat/de ?
<pitti> thanks :-)
<pitti> seb128: infinite improbability influence
<\sh> gentlemen...does anybody has a linux-headers-2.6.12-3-386 package handy?
<pitti> seb128: I just generated an up to date tarball, imported it, and it was there...
<Mithrandir> oh well, I'm off for today.
<seb128> k
<pitti> Mithrandir: enjoy the weekend
<luis_> pitti: rock, thanks!
<Mithrandir> pitti: you too
<daniels> yow.  how is it that the europeans are already leaving for the weekend?
<pitti> daniels: because we have girlfriends...
<pitti> mine will arrive every minute...
<\sh> lol
<daniels> pitti: i was working the hardest when I was attached.  go figure.
<pitti> sounds like a happy relationship :-)
<daniels> hah
* luis_ recommends sending the gf to africa for two years if you want to join a startup
<\sh> damnit
<luis_> that worked for me!
<luis_> :)
<pitti> luis_: well, it's not that I would't look forward to seeing her again :-)
<pitti> it's just not very productive, agreed
<daniels> luis_: *south* africa?
<Nafallo> infinity: ping liferea
<pitti> --- gartoon-0.5.orig/debian/compat
<pitti> +++ gartoon-0.5/debian/compat
<pitti> @@ -0,0 +1,2 @@
<pitti> +4
<pitti> +4
<pitti> haha,
<pitti> double compatible :-)
<Nafallo> +8 :-=
<Nafallo> :-)
<pitti> ogra_: is there any reason that everything is doubled in gartoon?
<pitti> ogra_: debian/compat, debian/docs, dirs, postinst, etc.
<ogra_> doubled ? 
<ogra_> no idea, i didnt package it...  i'll look at it
<\sh> ok...gentlemen..I need some tips...
<daniels> aw3r4#@$@KJ#$
<daniels> sudo sh -c   3916.78s user 834.89s system 97% cpu 1:21:16.87 total
<\sh> 1. I need to replace the kernel in colony 2 and I need some hints how I can build the initrd stuff to start the ubuntu-installer...
<Lathiat> daniels: is it finished? ;p
<daniels> Lathiat: finally
<stratus> Where did the gnome keyboard layouts go on breezy? language-support-something? I just see U.S keyboard layout inside gnome-keyboard-preferences.
<Nafallo> daniels: nice password ;-)
<stratus> s/preferences/properties
<infinity> Nafallo : ?
<daniels> -rw-r--r--  1 root root 789M Aug 13 01:05 custom-breezy-live-i386.iso
<daniels> brilliant.  it actually GREW.
<infinity> Bah, close enough.
<daniels> thankyou, create_compressed_fs --best.  thankyou.
<infinity> Just get a bigger CD.
<infinity> Kamion : Done.
<Nafallo> infinity: what's up with liferea? the new version doesn't even have buildlogs.
<infinity> dep-wait on dbus-glib-1-dev ...
<pitti> ogra_: https://wiki.ubuntu.com/MainInclusionReportGartoon, can you please fix the small issues?
<Nafallo> infinity: hehe, nice. thanx :-)
<ogra_> pitti, i juast compiled it here... no doubled entrys...
<daniels> infinity: which doesn't exist anymore
<infinity> daniels : So I gather.
<daniels> libdbus-glib-1-dev
<infinity> Nafallo : Incorrect build-depends, or should I clear the dep-wait (may be stale from a previous upload)
<slomo> infinity: the newest version (0.9.4something) doesn't depend on dbus-glib-1-dev anymore... that was an older version
<slomo> infinity: it depends on libdbus-glib-1-dev now
<infinity> slomo : Alright, I'll clear the dep-wait.
<slomo> infinity: thanks :)
<pitti> Hey madduck 
<madduck> pitti: hi there. libc6 wrecked my irssi
* pitti points to jbailey
<daniels> gnarghareljasdfokjawer
<daniels> whatmustIdotoburnaDVD
<pitti> daniels: nautilus-cd-burner can burn dvds
<pitti> works fine
<daniels> pitti: from an ISO?
<pitti> daniels: sure
<pitti> daniels: right-click, burn, there you go
<paolo-> growisofs
<pitti> yes, that's what n-c-b does
<luis_> daniels: sent her to niger. Well, actually, she left, and I got a job at ximian when she'd been there about a month. Still, worked out well. ;)
<daniels> luis_: heh
<daniels> luis_: i started going out with this one girl two days before I left for two months for denmark/uk/matar.  masterful plan, that one.
<daniels> but I think my bitterness is offtopic here.
<infinity> Bitterness is never offtopic.
* jsgotangco is listening..heh
<pitti> ah, gf alert
<daniels> pitti: have a good weekend
<pitti> thanks
<ogra_> seb128, is there a policy for prerm scripts of gnome icon themes ?
<ogra_> seb128, for example gartoon runs just: rm -f /usr/share/icons/gartoon/icon-theme.cache
<ogra_> seb128, without any checks etc...
<ogra_> obviously this is done the same way in all icon themes i look at
<siretart> daniels: still here? could you please review https://wiki.ubuntu.com/MOTUGLUTransition for correctness?
<siretart> daniels: I want to be sure to take the right dependencies for GL and GLU headers, I just want to be safe
<daniels> argh german keyboard
<siretart> hehe, I don't like them either, but I'm surrounded by them here ;)
<pef> elmo: hi, are you here ?
<seb128> ogra: nop, that's a "to do" point
<ogra> seb128, so you agree that i can leave it this way for now ? pitti wanted me to change it for main inclusion of gartoon
<siretart> pef: you have much better chances if you actually say what you want from him ;)
<seb128> that doesn't seems to be quite correct
<daniels> where on earth is the pipe key on german keyboards?
<seb128> hum
<daniels> i'm stuck in the console trying to fix X breakage with a german keyboard layout
<seb128> no, it is correct
<pitti> daniels: alt+gr plus <>
<slomo> daniels: "altgr" and < ;)
<daniels> slomo: nope
<daniels> unless < is somewhere funny
<daniels> slomo: where is < ?
* Lathiat laughs
<slomo> daniels: it's left from the z (on us keyboards, y on a german one)
<pitti> daniels: left to Y
<pef> siretart: you're right
<daniels> siretart: libgl> libgl1-xorg-dev | libgl1-mesa-dev | libgl-dev
<ogra> seb128, its lik that in all icon theme packs ...
<daniels> pitti: that's my left shift key
<ogra> so i assume its ok :)
<daniels> oh, christ
<pitti> daniels: there must be a key in between...
<daniels> don't tell me that's the key I don't actually have
<daniels> pitti: pc104 vs pc105
<pitti> daniels: now you know how we felt during the xkb b0rkage
<pitti> daniels: I had to copy&paste pipes and backslashes from existing text files
<daniels> pitti: i'm stuck in the console!
<seb128> ogra: it does the trick for now, be somebody should write a dh_icontheme
<siretart> daniels: updated
<pef> elmo: hi, can you have a look at my package kvpnc on REVU ? It only miss one motu vote ;) ogra and slomo are ok http://siretart.tauware.de/revu/details.py?upid=343
<daniels> siretart: glu> libglu1-xorg-dev | libglu1-mesa-dev | libglu1-dev
<siretart> pef: please rather ask on #ubuntu-motu for reviews, not on #ubuntu-devel. The guys here have enought work for main ;)
<Lathiat> thanks daniels 
<pitti> daniels: loadkeys en doesn't work?
<daniels> pitti: yeah, I fixed it just then
<daniels> also, shells without vi mode are teh suck
<siretart> daniels: also updated
<Lathiat> siretart: time to get to work? :)
<doko_> daniels: which character should I send you, or did pitti already type it for you ;-P
<Lathiat> siretart: got a list generated?
<Lathiat> i spose my original one might apply
<siretart> Lathiat: not yet, feel free to update :)
<daniels> doko_: irc is on my laptop, which is fine.  my desktop is stuck in the console, now with a us keyboard layout, trying to fix on the live cd.
<Lathiat> siretart: ok
<daniels> thanks though
<Lathiat> daniels: ssh in? ;p
<Lathiat> well, befor eyou fixed it :)
<pef> siretart: yes, but I can't find elmo on #ubuntu-motu and I need his review
<daniels> siretart: er, libglu1-mesa-dev | libglu-dev
<daniels> siretart: and libgl1-xorg-dev | libgl1-mesa-dev | libgl-dev
<Lathiat> pef: err... why do you need elmos review?
<infinity> s/libgl1-mesa-dev/mesag-dev/
<infinity> (though, we should probably rename that)
* siretart completly confused now
<Lathiat> as am i
<infinity> Right.  Let's start over.
<pef> Lathiat: my package has ogra  and slomo approval, and ogra says it only miss elmo vote
<infinity> libGL -> libgl1-xorg-dev | libgl-dev
<infinity> libGLU -> libglu1-mesa-dev | libglu-dev
<Lathiat> ideally if we are going to change a name, it would be better to do it now rather than do this all over again
<infinity> No need to list mesag-dev at all, since it's provided by that alternate virtual (libgl-dev)
<siretart> infinity: and don't mention the mesa variants at all? are these dependencies to work also in current debian/sid?
<Lathiat>   zA  http://tieguy.org/tinder/
<Lathiat> oops
<Lathiat> ignore that
<infinity> Lathiat : We were told by the Powers That Be in release management to take this one step at a time to make it easier to just release 'whenever' even if we haven't managed to transition each and every package name.
<infinity> siretart : The two lines above will work in a sid system, but not in a sid autobuilder.
<Lathiat> except we'd have to change 3 bazillion packages all over again
<infinity> siretart : But we want them working in breezy buildds, not sid ones. :0
<infinity> Lathiat : I can change 3 bazillion packages in pretty short order if needs be.
<infinity> Lathiat : I wouldn't stress too much about it.
<elmo> pef: I'm nothing to do with MOTU reviews; someone is confused
<siretart> infinity: yes. But when preparing packages for debian, I'd like to get them compatible to ubuntu. Is there any chance to get more 'robust' dependencies?
<ajmitch> Lathiat: it doesn't take too long just for build deps
<infinity> siretart : These just plain will not match with Debian until Debian startes doing the same "break mesa out of Xorg" transition we're doing.
<infinity> siretart : Not much we can do about that, unless we want to halt modular X development for the sake of compatible build-deps (which is insane)
<ajmitch> siretart: we'll just go ahead & deal with the merges later
<Lathiat> infinity: right
<Lathiat> understandable
<pitti> ok, nice weekend everybody!
<pef> elmo: oh, sorry :)
<siretart> infinity: is this correct now? https://wiki.ubuntu.com/MOTUGLUTransition
<infinity> siretart : Build-deps are fine now, but the shlibs will most certainly not mention libglu1c2.
<infinity> siretart : They would probably be "libglu1-mesa | libglu1"
<infinity> siretart : Not that most people should care in the first place, since shlibs are auto-generated, and anyone hardcoding those deps should be shot.
<infinity> siretart : And then you need to update the section later about transitioning from xlibmesa-dev
<siretart> ok, I'm on it
<daniels> i hate the live cd and everyone associated with it
* infinity gets unassociated with the LiveCDs in a hurry.
* ogra GRRRs at his DSL
<ogra> pef, did you get my last message ?
<Lathiat> ogra: your last line was at 23:32 "so i assume its ok" talking to seb128 and timed out at 23:43
<ogra> ah
<ogra> pef, you ask elmo for a review ? *grin* he does that anyway... please find a third MOTU first 
<ogra> s/ he does that anyway/ he does that anyway for NEW packages/
<pef> ogra: [17:43]  <elmo> pef: I'm nothing to do with MOTU reviews; someone is confused
<ogra> ah
<pef> i'm a bit confused
<pef> :)
<jsgotangco> heh
<ogra> heh... dont worry
<ajmitch> pef: what is the package?
<pef> ajmitch : kvpnc
<ogra> kvpnc
* ajmitch will take a look
<pef> yeah :)
<\sh> ok...toshiba ethernet driver is running and ready to install breezy
<\sh> fabbione: ping
<ogra> \sh, he's on hiloday
<\sh> ah..who is working on the kernel>?
<ogra> err, swap i and o
<\sh> Kamion: ?
<\sh> aeh
<mdz> doko_: dealt with libc6-amd64*, libc6-i386* do not exist
<ogra> \sh, if you dont know it, nag the one who last uploaded ;)
<ogra> mdz !
<\sh> ogra: I'm not at home...I have to be carefull with the bandwidth here...only 1GB ;)
<mdz> mjg59: yes, usplash/amd64 works for me as well
<ogra> mdz, one freeze breakage approval please.... i didnt manage to stay awake long enough yesterday to finish gnome-power with new dbus and hal
<\sh> mdz: can u have a look at this http://www.syskonnect.com/syskonnect/support/driver/d0102_driver.html driver for actual sk98 ethernet drivers? (it's nice for the toshiba r200 laptops;))
<doko_> mdz: where is there another reference to libc6-i386 without a "| ia32-libs" ?
<mdz> ogra: if dbus and hal had been built and working, would it have been ready yesterday?
<ogra> yup
<mdz> doko_: jackass:[~]  madison libc6-i386
<mdz> zsh: exit 1     madison libc6-i386
<daniels> mdz: so I assume this debconf_copydb trickery doesn't result in config.dat containing the values when you're booted into it
<mdz> ogra: ok, get it in right away
<Nafallo> elmo: sync im-switch from debian please. will fix uim for us.
<ogra> mdz yay, thanks :)
<mdz> daniels: it has in the past
<mdz> ogra: don't forget to seed it
<daniels> mdz: ... what does it do *now*?
<mdz> daniels: exactly the same, unless someone broke it
<mdz> daniels: did you try the live CD or no?
<daniels> mdz: if you care to look at the config.dat of a booted live system, debian-installer/keymap is empty
<daniels> mdz: this is exactly what I'm doing now, having spent the last several hours wrestling with the bloody thing
<mdz> hmm, Kamion has left, hasn't he
<mdz> daniels: what exactly is making it difficult for you?
<mdz> that regex looks broken; did you try changing that?
<mdz> debconf-copydb -p '^(debian-installer/keymap|xserver-xorg/autodetect_keyboard$' configdb target_configdb
<mdz> missing ')'
<trygvebw> Will Breezy use Xorg 7.0?
<daniels> mdz: remastering it producing a 790MB image for no discernible reason and taking hours, stepping through casper in a german keyboard layout to edit 20xconfig without > or |, which I need
<daniels> mdz: #@$#@$(*#@$
<ogra> mdz, the package names changed... i think i'll need a NEW approval from elmo first and a new main inclusion report at least for the new separated power-manager package (preparing it now)
<ogra> (the report i mean)
<mdz> ogra: what?  there is another package beyond gnome-power?
<mdz> ogra: you said it was ready
<ogra> mdz, the system specific stuff was parted from the serspace stuff upstream
<ogra> userspace even
<daniels> mdz: even after fixing that regexp, debian-installer/keymap is empty by the time pivot_root is called
<daniels> mdz: i'm guessing this may possibly have something to do with our inability to detect the layout
<mdz> seems likely
<daniels> ...
<mdz> why did you need to remaster the CD?
<daniels> mdz: to get xorg -49 on there to see if that fixed things
<daniels> mdz: given you were asleep, and I'm not entirely sure about all of casper's weird-shit semantics
<Nafallo> elmo: thanx
<Nafallo> elmo: hmm, could you new it to? :-)
<daniels> that's where it stands, and 0220 on friday night sounds like a pretty decent time to stop working and possibly go to sleep.
<elmo> Description: frontend for gnome-powermanager
<elmo>  gnome powermanager manages battery stati, events and
<elmo>  powermanagement settings.
<elmo> ogra: please impove that
<ogra> ok
<jasoncohen> does hoary have new versions of dbus-1, dpkg, locales, dselect, kdelibs, and libc6?
<jasoncohen> i just saw the updates this morning- seems a bit strange
<Kamion> mdz: I'm still technically here, just about
<Kamion> jasoncohen: dpkg and dselect definitely yes, I think I saw the others in the queue too
<Kamion> see the hoary-updates mailing list
<mdz> Kamion: any obvious reason why debconf-copydb would have stopped working in casper?
<Kamion> mdz: none that I'm aware of; DEBCONF_DEBUG=20 may help but may not
<Kamion> it's been working in the installer to my knowledge
<Kamion> otherwise, I'm afraid you'll have to get someone to dig into cdebconf
<Kamion> mdz: as far as I'm concerned Colony 3 is blocked solid on #13398
<Kamion> so, you have mail about how to do a Colony release, since my drop-dead time for leaving is under an hour from now, and I'll probably be gone sooner
<mdz> Kamion: ok
<elmo> oh, shiny.  valgrind on amd64
<Treenaks> elmo: the non-crashing variety?
<elmo> mdz: would you consider UVFE-ing that?  it's a big jump (2.4 -> 3.0)
<mdz> elmo: does it have any reverse dependencies?
<infinity> I should hope not.  No good could ever come of depending on valgrind. :)
<elmo> ** kdenetwork has an unsatisfied build-dependency: valgrind
<Treenaks> infinity: firefox; Depends: valgrind :P
<elmo> is the only main one
<elmo> how about if I confirm kdenetwork still builds with 3.0?
<paolo-> Is it known that ubuntu-desktop is being kept back by apt?
<Kamion> shouldn't be, http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html doesn't list it
<Treenaks> paolo-: just manually apt-get install it
<paolo-> It tells me every time I do an apt operation, let's try install it manually.
<paolo-> OK.
<paolo-> It worked.
<Mithrandir> elmo: can you update kernel-wedge in the breezy-i386 chroot on concordia please?
<mdz> Kamion: if you're still here, a seed push would be handy
<elmo> Mithrandir: done, probably
<Kamion> mdz: done
<Kamion> and I think I'd best go
<Kamion> bye all!
<Mithrandir> elmo: cheers, thanks.
<mdz> Mithrandir: did you know if Kamion got around to tracking down the initramfs/installer issue?
<Mithrandir> mdz: he said he was going to a few hours ago, at least.
<Mithrandir> like, six hours ago:
<Mithrandir> 11:46  * Kamion fixes initramfs-tools to work in the installer
<Mithrandir> I don't know if he finished it, but I'd imagine so
<mgalvin> mdz: it is fixed on the .2 cd
<mgalvin> but there is still the hotplug nic issue
<mdz> yes, #13398
<mgalvin> yup
<pef> bye
<Mithrandir> mdz: I'm wondering if I should leave that to jbailey as he'll be back on Monday.
<mdz> Mithrandir: it isn't particularly a jbailey issue
<Mithrandir> mdz: it seems to be an initramfs issue?
<mdz> Mithrandir: no, it's a hotplug issue
<mdz> see Colin's comment
<TerminX> does anybody else have really really really small fonts in Thunderbird?
<\sh> gentlemen...toshiba portege r200 works with breezy
<ogra> out of the box ?
<Lathiat> .. sortof? :)
<\sh> ogra: no ways
<ogra> heh...
<\sh> ogra: there is a driver for the nic...default in 2.6.12 doesn't work.
<ogra> hope you documented it :)
<\sh> ogra: I will write a wiki page...but we should get this driver into our kernel
<\sh> because installing via network without a working nic driver...is a pain in da ass
<\sh> i had to break everything of the colony cd2 
<ogra> yes, i can imagine that
<\sh> replacing kernel, replacing initrd
<\sh> now I'm running 2.6.12-3-386 and modprobe -f magic for the driver...cause i didn't compile the driver with the right version settings
<Lathiat> heh
<\sh> and doing dist-upgrade in the background
<ben__> ok.. I just apt-get upgraded my amd64 box with the new libc
<SuperQ> it caused my box to spontaneously reboot, and then not boot anymore
<SuperQ> I got it up on a live CD, and was able to use dpkg --root=/foo to re-install the libc
<stratus> Where did the gnome keyboard layouts go on breezy? language-support-something? I just see U.S keyboard layout inside gnome-keyboard-properties
<mako> jdub: i think i may have won the t-shirt challenge
<mako> jdub: accidentally
* mako was a bit low on washing machine on his extended europe trip
<jdub> smelly mako!
<Mithrandir> jdub: I think you might be needing to send out multiple trucks of t-shirts by offering it like that on your blog. :-)
<Treenaks> Mithrandir: first I need a shirt :)
<jdub> Mithrandir: oh dear
<jdub> Mithrandir: i didn't think it would be read that way
<jdub> Mithrandir: good point :)
<dieman> fabbione: hey, 12247 has some new info in it, but i cant change its status because i dont own the bug
<dieman> fabbione: you may be interested and mark it as notabug
<Nafallo> dieman: he's on vacation ;-)
<dieman> Nafallo: ahh
<dieman> it can wait :)
<dieman> Nafallo: is he moving yet?
<dieman> i remember he was figuring out building a house
<Nafallo> dieman: other people know more about that I believe :-)
<dieman> heheh
<Simira> mako : ping
<mako> Simira: yes
<jdub> mdz: moderating now
<flipperface> scuse me, im on a toshiba satellite, and whenever i try to increase the volume in gnome, via the sound mixer it says that my registry is missing or corrupt and suggests i run gst-register.  I did a synaptic search for this package but it can not find it
<mgalvin> flipperface: this is not that place for support questions... but did you try gst-register-0.8
<mdz> jdub: moderating?
<jdub> mdz: your big fat email
<mdz> jdub: to ubuntu-devel?  I didn't get a mailman-o-gram about it
<jdub> http://www.uneasysilence.com/os-x-proven-hacked-and-running-on-an-ordinary-pc/
<jdub> ^ ha ha, ubuntu mentioned in osx on intel hack page :)
<luis_> yeah, sadly the torrent is already down
* luis_ wants to be able to run/test os/x stuff without having another box in the house
<ogra> mdz, from when is this anastacia list ? the edubuntu servers inclusion reports were there since yesterday morning, your list marks them all missing
<mdz> ogra: I wrote it this afternoon (my time), using https://wiki.ubuntu.com/UbuntuMainInclusionQueue
<ogra> oh, damned, they are all on https://wiki.ubuntu.com/EdubuntuMainInclusion, i havent linked them yet
<Burgundavia> ogra, that is odd. I add the link to edubuntu main inclusion stuff and told pitti about it
<ogra> pitti alread processed a lot.... i think e linked the finished ones
<Burgundavia> o
<ogra> already
<mdz> some things removed from the edubuntu seeds are still in edubuntu-meta due to the amd64 upload going MIA
<mdz> I'm emailing infinity about it
<ogra> do they affect the other arches ? 
<Nafallo> infinity: ping
<Nafallo> infinity: do you know the plan for xmodmap? ppl want it back :-).
<glick> hello
<glick> excuse me, how can i tell if my serial ports are working correctly?
<glick> i dont see any serial port driver loaded when i type in lsmod
#ubuntu-devel 2005-08-18
<sistpoty> ping elmo
<_d4v_d> hi all
<HeMan> Hi! Are people interrested in bugreports for breezy?
<Burgundavia> HeMan, yes
<Burgundavia> HeMan, in bugzilla or malone
<HeMan> oki, i'll see if my bug is reported in bugzilla, otherwise i'll post one
<HeMan> hmm, i've used bugzilla, but what is malone?
<HeMan> i just found malone
<tseng> malone aims to be a next generation bug tracker
<tseng> with hooks to upstream bugs and other distros
<tseng> to track the status of a bug on many levels
* Nafallo loves malone
* tseng loves dinner
<tseng> bbiab
<HeMan> for kernel-bugs, should i use bugzilla or malone?
<Nafallo> bugzilla
<fjp> Hi. Something you may want to check in your repo.
<fjp> For D-I, Colin recently renamed partman/partman to partman/partman-base.
<fjp> But for Debian, he forgot to change partman.templates to partman-base.templates in partman-base/debian/po/POTFILES.in
<fjp> This causes problems when building the package and maybe for translations.
<fjp> Mentioning it here because he's away for his wedding.
<mjg59> mdz: Cool, thanks for the confirmation
<mjg59> I need to add Mac code for it, but that should be easy enough
<tseng> mjg59: i doubt there is a fix for this, but usplash looks totally bong on my "widescreen" display
<tseng> thanks to scaling
<mjg59> tseng: Mm. Yes, I've noticed on mine.
<mjg59> It seems to depend on the quality of the scaling
<mjg59> But better graphics ought to deal with that...
<Burgundavia> mjg59, what do you think of my LaptopTestingTeam reorg?
<thierry> could someone check ubuntu bug 13416 ? I'd really like that someone check the patch... this also touch the motu team
<mjg59> Burgundavia: Haven't looked yet, I'm afraid
<mjg59> I'll do so in the morning - I'm nowhere near sober enough
<Burgundavia> mjg59, ok
<calc> i got my ubuntu 5.04 disks today :)
<martinald> hi
<martinald> is there an ubuntu marketing team?
<thierry> martinald : yes check https://wiki.ubuntu.com/MarketingTeam?highlight=%28marketing%29
<thierry> martinald : it's not big but there's one anyway
<martinald> that seems to explain a plan to make one
<martinald> "I'm interested in helping to set up an Ubuntu marketing project, covering"
<thierry> check this https://wiki.ubuntu.com/UbuntuMarketing?highlight=%28marketing%29
<martinald> ok thanks
<thierry> :)
<martinald> should i edit the wiki to add a link to that page?
<thierry> martinald : for anything else, check the wiki and if you don't find what you want, ask
<thierry> yeah would be a great idea
<martinald> ok
<martinald> ok, done.
<thierry> thanks
<martinald> ok, no offense, but this is a) way out of date and b) totally misguided (IMHO)
<martinald> i think this is a real, real shame because if 1% of the effort that goes into the technical side of ubuntu was put into marketing, you could see thousands more users
<whiprush> well, lucky for us you dropped by! :)
<martinald> heh.
<martinald> spreadubuntu seems to have stalled also
<whiprush> search for TheFridge in the wiki.
<martinald> right
<martinald> i'll be honest, it's interesting but i can't see anything like it happening
<martinald> because it seems priorities are all mixed up. for example, on UbuntuMarketing, marketing to _developers_ is above marketing to _users_ !!!
<martinald> and i don't understand the point of an ubuntu portal whatsoever
<martinald> why would users go to 'the fridge' for a 'picture gallery' when they could go to flickr and get a service that is far, far better, well designed and popular, for example
<whiprush> it's not for their personal pics.
<whiprush> it's for people to submit pictures of ubuntu events around the world.
<martinald> yes, but even still, flickr is likely to be far better for that
<whiprush> maybe.
<whiprush> but that's an implementation detail. It's just a wiki of ideas.
<whiprush> Feel free to add/change/contribute whatever you feel needs to be fixed.
<thierry> a bit like a like a news paper to say "eh! Ubuntu is great and see how people can help to market it"
<martinald> well the major problem for ubuntu seems to be that it doesn't know what it's market is, which is a really fundamental problem
<martinald> "that every Ubuntu user will want to set as their default homepage." but then goes on to say "Whoa, did you see The Fridge today? That X.org stuff is awesome!"
<martinald> for some reason I can't see 'every ubuntu user' wanting to see 'awesome x.org stuff'.
<thierry> well how firefox started to market their product? maybe we could learn from that?
<martinald> absolutely
<martinald> but you can't take too much away from that
<thierry> why?
<whiprush> a good number of those ideas are directly from spreadfirefox.
<martinald> firefox is a 4MB download and a 1 minute install that leaves the user no worse off if they don't like it
<Lathiat> similar to the livecd, a little longer download tho (that cant be avoided)
<martinald> ubuntu is a 650MB download and a 30 minute install which could easy destroy their entire dataset if they don't like it and install it wrong
<thierry> yeah but we have live-cd and free shipping cds so....
<martinald> yes, but then you lose the impulse part
<thierry> even if the shipping is quite long....
<martinald> it took me 4 months to get my hoary cds
<Lathiat> It's really hard to fullfill the impulse part really
<martinald> but let's not focus on that
<thierry> yep
<Lathiat> Altho
<Lathiat> can iso can be got in reasonablish times on more modern connections
<martinald> the trouble is that 50%+ of regular firefox users will of installed it on an impulse
<martinald> you really can't do the same for ubuntu, so if you try and copy firefox's methods too much you will not get far at all
<thierry> I think we should maybe set something like a "take your local ubuntu cds there or there thing" with a map....
<martinald> what?
<martinald> how do you mean?
* infinity yawns.
<thierry> imagine that me, you and about every contributor of ubuntu burn a couple of ubuntu cds and sign a page with where someone could meet them to get a cds... fast, near and they have a contact of someone that has already used the product...
<Lathiat> infinity: duder, is it broken to still have xlibmesa-gl-dev deps ?
<infinity> Yup.
* Mez sticks a sock in infinity's mouth
<Lathiat> ok
<martinald> there is too many problems with that
<thierry> of course not everyone will want to do that but if a couple of people in big cities do that, that would be great
<Lathiat> so i need to hti siretart with a stick
<martinald> you'd have to put your address on the public internet, which many are not happy with
<infinity> I thought he updated his wiki page to remove all mentions of it..
<thierry> martinald : yeah maybe you're right...
<Lathiat> didnt make much sense to me because xlibmesa-gl-dev is conflicted by libgl1-xorg-dev so thats a bit ugly for a start
<infinity> Or did he forget to update the "xlibmesa-gl -> xlibmesa-gl-dev" part?
<martinald> and very few people would have the effort to bother getting into their car or w/e and spending an hour driving to pick up some dodgey hand burned isos
<martinald> burnt*
<Lathiat> infinity: no he was specifically saying these dont need fixicn gas they build fine already (ones with just xlibmesa-gl-dev"
<thierry> martinald : well maybe we could do something the locoteams... 
<Lathiat> i'll harass him about it later :)
<infinity> Lathiat : Well, we've finally punted xlibmesa* from the archive completely, so he's wrong. :)
<thierry> well if they do it for windows why not for linux
<Lathiat> infinity: i still see it in my mirro ri just synced :P
<infinity> Lathiat : Uhm, where?
<thierry> martinald : seriously if current video games would work on linux, all my friends would have linux... but none of them want a dual-boot system because they all alreadu have word, and excel and all that stuff...
<infinity> Lathiat : It was in Universe by mistake, and got removed a few days ago.
<thierry> martinald : but when the new windows will come out, we will have the advantage be able to say " hey don't pay again! get linux! it's even better and free!"
<Lathiat> hrm
<Lathiat> it isnt
<Lathiat> why is it showing up in apt-cache show
<martinald> I think a site similar to www.apple.com/switch would work nicely for ubuntu
<martinald> but it'd have to be kept simple
<martinald> but really if I was told I could do what I want with ubuntu to make it marketable, i'd drop the ubuntu name and colourscheme straight away
<Lathiat> infinity: *confuzzled*
<Lathiat> infinity: oh
<Lathiat> maybe i still have it installed
<martinald> because they are horrible to market with. doesn't instill confidence or reliability which is really what's needed for an OS
<Lathiat> infinity: ah, yes. :)
<Lathiat> infinity: that was it
<Lathiat> infinity: my bad :)
<adamh> Is there an Ubuntu repository with qt4 packages?
<daniels> elmo: (talking about xrender)
<daniels> > Because it's been replaced with libxrender.
<daniels> Moved to universe.  If it should be removed from the archive, please request
<daniels> that in the usual way.
<daniels> elmo: please remove xrender source kthx
<mdz> it's customary to send those requests by email, actually
<infinity> mdz : edubuntu-meta rescued, amd64's having an issue with buildd-mail that I need to look into, either this weekend, or when I'm actually "back to work" on Monday, depending on how bored I get over the weekend.
<mdz> infinity: thanks
<Mez> Note to self: if you want to do anything with a CD, enable DMA
<Lathiat> whoah
<Lathiat> i just stuck an ubuntu live cd in from my box
<Lathiat> and it came up with some "sage bob software" thing
<Lathiat> (not an ubuntu cd)
<jdub> hrm?
<Lathiat> it says ubunut livecd on the front etc
<Lathiat> but the image on it isnt
<Lathiat> the others are fine tho
<Mez> Lathiat, is it one from shipit, or did you burn it yourself and mislabel ?
<Lathiat> shipit
<Mez> weirdness
<Mez> Sage = accounting
<Lathiat> yeh tis was some netherlands thing
<Mez> maybe it's mark's financial records :D
<Mez> :P
<Lathiat> haha
<Mez> I was about to say "quick steal his money"
<Mez> but then I thought "no, that'd be mean, he's a really nice guy, and thats no way to repay him for ubuntu" 
<jdub> Lathiat: can you copy down the batch number on the CD and mail it to jane.silber@canonical.com and mako@ubuntu.com ?
<Lathiat> jdub: wheres that put
<jdub> Lathiat: on the plastic bit at the middle
<Lathiat> dieman: ok
<Lathiat> err
<Lathiat> jdub: ok
* bur[n] er finally realized he can test breezy X apps using remote X from the 'failsafe' kernel even though X doesn't work locally :)
* bur[n] er just had to share his jubilation and gets back to playing with new rhythmbox
<jasoncohen> niran, how's goal 2 & 3 of FindingPackages coming along?
<niran> jasoncohen, i got some code in g-a-i that will help with letting people install programs for unknown mime-types
<niran> but i still have to get nautilus to actually ask for it
<niran> for installing from launchpad, it's pretty simple if it's limited to just launchpad, but i want it to be broader than that
<niran> so the format has to actually be sane, which is what i'm working on
<niran> the actual code there is pretty trivial
<jasoncohen> ah, hey
<jasoncohen> so, it'll all be in for breezy?
<jdub> we just passed feature freeze, so begging and pleading will be involved
<jasoncohen> jdub, FindingPackages is High Priority so niran should be fine
<jasoncohen> since the feature freeze makes an exception for high priority goals
<niran> jasoncohen, i think the most important part is already in
<niran> the unknown mime-types thing doesn't happen that often, and installing programs directly from launchpad doesnt seem that crucial
<jasoncohen> niran, the ability to install directly from a developer's site would be nice
<niran> jasoncohen, i think so too, but that wasn't even part of the original spec, i just tacked it on
<jasoncohen> which is what we discussed earlier. i think that would prevent a lot of users from trying to compile packages from source that are already in ubuntu
<niran> jasoncohen, it would take a lot of consensus for it to actually get adopted, and i still have to get the final format out for people to make sure it's sane
<Burgundavia> jasoncohen, remember that the spec only currently involves installing out of ubuntu repos
<jasoncohen> i know
<Burgundavia> jdub, my hackergotchi -- http://www.warbard.ca/temp/corey-blogface-small.png
<Burgundavia> jasoncohen, which might lead to issues with version numbers, etc.
<jasoncohen> the problem is that many new users especially have no clue what the ubuntu repos include and don't bother to check. if for example, someone sends them to the gaim site, they'll try to download an rpm or source
<bob2> where's the svn repository for the ubuntu documentation?
<Burgundavia> gnome-app-install should solve a lot of that
<Burgundavia> bob2, just a sec
<Burgundavia> bob2, https://docteam.ubuntu.com/repos
<niran> speaking of breezy goals, what's going on with the fridge?
<Burgundavia> niran, coming along apparently
<jdub> elmo: planet update please :)
<jdub> Burgundavia: on its way
<jdub> niran: keep an eye open for it soon, it will appear quietly :)
<niran> jdub, cool :)
<Burgundavia> jdub, thanks
<Burgundavia> jdub, your content creation gnomes have been notified. As soon as you have a fridge, I will have original content for it
<Burgundavia> jdub, thanks for buying into my new LaptopTesting reorged page
<davyd> does someone know about DBus# being broken?
<davyd> is a fix on the way?
<Lathiat> mjg59: so why use vga16fb and not vesafb?
<Lathiat> mjg59: like, usplash with vesafb worked nice for me, what does it break?
<Lathiat> mjg59: where usplash si that old one someone wrote ('splashy'?)
<Mithrandir> Lathiat: vesafb breaks suspend to ram.
<Lathiat> it does?
<Lathiat> worked for me
<Lathiat> lucky me :)
* davyd is also experimenting with usplash at the moment
<Lathiat> breaks here :(*
<davyd> is something meant to appear in the box?
<davyd> I have an Ubuntu screen and a white box
<davyd> then it goes back to console
<Lathiat> i dont think so\
<davyd> ok
<Lathiat> unfortuantely vga16fb breaks on my laptop
<Lathiat> the whoel thing moves down two lines
<Lathiat> and i cant see the bottom two
<Lathiat> adn the top two get 1 pixel lines down the side of each character
<Lathiat> (and images are the same)
<davyd> hmm, why is gdm is unresponsive lately?
<davyd> it seems to get worse each version
<davyd> is -6 the last kernel ABI we're going to see in Breezy?
* Lathiat disappears
<Treenaks> davyd: nothing is sure with kernel ABIs
<davyd> fair enough
<Mithrandir> davyd: I don't think so, but no firm decision has been made
<davyd> also, I have filed a patch for Toshiba bluetooth support that it would be nice to see in
<Treenaks> Mithrandir: One security fix could change it..
<Treenaks> davyd: \sh_away will like that
<davyd> the other thing for the R200 is you need to use Marvells sk98lin driver, which breaks other things
<Mithrandir> Treenaks: yes, for instance.
<davyd> I don't expect that will go in at all, so I'm going to take a swing at trying to build it as a separate module
<davyd> you're also still shipping an old version of xorg-driver-synaptics
<davyd> if you ship a new one, you get scrollpad support on Toshibas and others
<Treenaks> davyd: could you file a bug on that?
<Burgundavia> davyd, that would be nice, given I just got one of those
<davyd> Treenaks: the bluetooth and the trackpad are already filed
<davyd> did you want me to file the sk98lin thing too?
<Treenaks> davyd: why not
<davyd> I might have a play with that first
<davyd> see if I can get a driver building without having to patch the kernel
<glick> hello
<glick> scuse me i have a question
<Treenaks> have you tried on #ubuntu?
<glick> isnt it a security risk in .bash_profile to have PATH=~./bin:$PATH ?  shouldnt it instead be PATH=$PATH:~./bin
<glick> ?
<Burgundavia> jdub, g-a-i is moving to where run application used to be?
<jdub> that is where it should be, yes
<Treenaks> glick: that way you can't override /bin binaries with "better" ones in ~/bin
<Burgundavia> jdub, that is a good idea
<Treenaks> glick: so, it really doesn't matter much
<jdub> it was already mentioned in the bug
<Treenaks> glick: as long as "." is not in there
<Burgundavia> jdub, ah, ok
<glick> i can also put a nice trojan in someones ./bin
<Treenaks> glick: no you can't :)
<Burgundavia> jdub, my bad then. Never edit bugs at 1am
<Treenaks> glick: and if you can, you're already root
<Treenaks> glick: or you already have their account (which means there are better ways of trojanning, like editing ~/.bash_profile)
<jdub> mjg59: http://www.livejournal.com/users/kernelslacker/22975.html
<robitaille> jdub: maybe you should add Colin's blog on planet.u.c?   http://www.livejournal.com/users/cjwatson/  
<robitaille> especially if he adds wedding pictures soon...
<jdub> i'll have to wait for hiim to return to confirm
<jdub> i don't add unless it's a personal request
<jdub> Aug 13 01:30:51 ubuntu kernel: [4406450.192000]  ACPI: acpi_ec_space_handler: bit_width should be 8
<jdub> getting lots of those
<jdub> maybe four a second
<jdub> given the timestamp
<Treenaks> jdub: new laptop?
<HiddenWolf> jdub, what is happening with the ubuntu-calendar packages, do you know?
<mjg59> Lathiat: It breaks suspend/resume
<pef> morning
<Lathiat> What would cause a package to build but not enter the archives
<Amaranth> new binaries
<Lathiat> shouldnt have been
<Amaranth> they got lost in the ether
<Lathiat> hrm maybe weird version numbers are confusing me
<HrdwrBoB> electromagnetic radiation from satellite debris 
<Lathiat> Amaranth: how can i determine if somethign has new binaries
<Amaranth> compare it to the last build? :)
<Amaranth> or ask kamion or elmo of whoever else where it went
<Lathiat> heh
<Amaranth> err, or whoever else
<Lathiat> spose ican look in the build log
<Lathiat> to see what it generated
<Amaranth> yay, smeg is approved
<pitti> Hi
<Lathiat> hey pitti 
<Lathiat> pitti: new audio stuff rocks
<Lathiat> tried it out today
<Lathiat> however when i went to select the device in the sound box it was a blank adn disabled dropdown menu
<pitti> cool
<infinity> Lathiat : What built but didn't get into the archive?
<Lathiat> (normally its enabled with just my internal sound)
<pitti> Lathiat: known bug, will fix it soon
<Lathiat> infinity: its ok it wasnt anything
<Lathiat> pitti: ok cool
<Lathiat> infinity: i thought it might have been but i foudn the real problem
<pitti> Lathiat: this happens if your default device doesn't support dmix
<infinity> Lathiat : Which was?
<Lathiat> well im using dmix
<Lathiat> infinity: err i forget now, it was minaly my inexperience with dealing with these things :) (im doing universe unmet dep stuff)
<Lathiat> jdub: wow
<Lathiat> jdub: theres a whole tonne of these sagebobsoftware cds
<Lathiat> infinity: bah, you stepped on my gnomemm upload. :P
<Lathiat> or more, i tried to step on yours :)
<Lathiat> pitti: but yeh apart from that the audio stuff is rockign along
<Lathiat> it actually switched automatically, was that supposed to happen?
<Lathiat> (sounds like a good idea to me, but checking)
<Lathiat> also i think the time the notification is shown should be a little longer
<Lathiat> maybe another 5s
<infinity> Lathiat : Sorry, not trying to step on MOTU toes, just trying to clear up some of the more obvious FTBFS snags in the archive.
<Lathiat> infinity: heh 'sok, just happened i was doing it at the same time :)
<Lathiat> infinity: want to put http://bur.st/~lathiat/ubuntu/glademm.debdiff then too? :)
<infinity> Yeah, but it should also have a versoined build-dep on the gnomemm2.0 upload I just did.
<infinity> (And I was about to upload with that change...)
<Lathiat> ah ok
<Lathiat> now to figure out what package wouldnt build because of thsi
<Lathiat> i cant remember now
<Lathiat> ah gabber2
<infinity> There are a mess of packages waiting on these fixes, that's why I'm doing them.
<infinity> Saw a few dozen go by in my last mass give-back.
<Lathiat> vflib3 is waiting on xmkmf to exist again
<Lathiat> infinity: ghc6 needs bootstrapping and the current version is no longer installable, any idea what would be done about that?
<infinity> I'm in contact with Igloo to sort that out.
<Lathiat> ok cool
<infinity> It won't build with gcc-4.0 right now, but upstream is on the verge of releasing a point release that is buildable again.
<Lathiat> hm ok
<infinity> Should warrant a UVF exception since it's currently horribly FTBFS (causing us to be unable to bootstrap it)
<infinity> And a mess of packages build-dep on it, so yeah.  I'm sure I can squeeze it in.
<Lathiat> cool
<Lathiat> all these openoffice.org langpack unmets, will they be sorted?
<infinity> Not a clue.  I stay as far away from OOo as possible.  You may want to bug doko about it.
<Lathiat> ok
<Lathiat> want to see if we can get 0 unmet deps this release instead of 85. :)
<Lathiat> and certainly not 749. 
<infinity> Well, Kamion is doing regular britney runs on the archive, which should help.
<Lathiat> whats that?
<Lathiat> making sure things still build?
<infinity> (britney is Debian's "testing" script... We don't use it for testing migratoin, since we have no concept of testing/unstable, but it's handy for finding uninstallable packages, etc)
<Lathiat> ahok
<infinity> Making sure things still build is more my domain.  We run breezy-autotest, a constant rebuild of the archive to see what's becoming FTBFS over time.
<infinity> Now that the buildds are starting to get out of "oh my god, everything's broken, I need to put out fires!" mode, I should strat generating a bunch of valid bugs from breezy-autotest.
<Lathiat> ah righton
<Lathiat> heh
<Lathiat> infinity: about?
<infinity> Lathiat : Yes.
<Lathiat> infinity: is bumping the build-dep versions really required / what does that achieve?
<Lathiat> (vs just rebuilding it)
<infinity> Lathiat : In practice (ie: from the POV of the archive), it achieves very little.
<infinity> Lathiat : However, it makes bootstrapping the system from scratch much easier.
<concept10> Anyone here know who develops the ubutnu hardware database collector application?
<infinity> Lathiat : Which tends to be done with breezy-autotest. :)
<Lathiat> infinity: ah
<hunger> How can I turn off the splash screen? It is screwed up somewhat since I need to enter a password for my HDDs.
<Lathiat> infinity: just wondering if i should version the deps for all these packages im just marking for ebuilds..
<infinity> Lathiat ; But yes, I could have just given-back those failed builds and it would have had the same effect.
<Lathiat> theyll all have to pull in *c2 stuff anyway
<infinity> Lathiat : And I may get lazy and do that later for others.
<Lathiat> so its going to start on that version
<infinity> Lathiat : If you have a long list of rebuild requests (and an order to rebuild them in), feel free to mail that to me.
<Lathiat> infinity: so they dont need a changelog entry?
<infinity> Lathiat : I'm probably too lazy right now to add versioned build-deps for every single transitioned C++ package, but for some core libs, I prefer doing it the "right" way, so they don't end up in a broken state like gnomemm did.
<Lathiat> right
<infinity> Lathiat : If they're failed builds, they don't need to be reuploaded, just retried.  If they're in the archive with broken deps, they need  abumped changelog (1.2.3-1 -> 1.2.3-1build1, if it's a rebuild of a Debian-versioned package, 1.2.3-1ubuntu1 -> 1.2.3-1ubuntu2 if it's a rebuild if an ubuntu patched package)
<Lathiat> infinity: right so ones that are in the archive (in the case of most of these), a debdiff would be good to give to someone to upload?
<Lathiat> and eventually i might be able to upload them myself :)
<infinity> Aren't you an MOTU?
<Lathiat> not yet
<infinity> Oh, thought you were.
<Lathiat> im workign towards that goal
<Lathiat> like, im participating, doing things, but not yet one as such. :)
<infinity> Don't worry about a debdiff then.  It's faster for me to type "dch -i" than it is to apply a patch and check it.
<Lathiat> right
<infinity> So, just make up a list of "foo needs to be rebuilt against libbar, baz needs to be rebuilt against libquux", etc.
<Lathiat> ok
<Lathiat> quite a lot need some minor patch and stuff tho
<Lathiat> for gcc4
<Lathiat> or gl deps
<Lathiat> i'll try put what i can together :)
<infinity> <nod>
<hunger_> Damn... ubuntu is too unstable to use on this laptop:-( Maybe it is time to start rolling my own kernels again... even though the newest ubuntu kernel is an improvement in stability for me.
<Treenaks> hunger_: what's the problem then? and what kind of laptop?
<hunger_> Treenaks: IBM T43p, just stops suddenly.
<infinity> hunger_ : Same here with my T43.
<infinity> hunger_ : Have you had success with other kernels?
<hunger_> infinity: Great... at least I am not alone with this problem!
<infinity> hunger_ : I was setting my sights on the Xorg Radeon driver, rather than on the kernel.
<hunger_> infinity: Not really:-(
<infinity> Is your system PCI-Express or AGP?
<hunger_> infinity: X does not (always) start up here, so I think it is the kernel.
<hunger_> infinity: PCIe.
<infinity> Mine's a PCIe x300.
<infinity> Xorg always starts fine (unless I'm stupid enough to use radeonfb), but the system hardlocks one or more times per day.
<hunger_> infinity: I am guessing on the SATA drive at the moment. But that is just a guess.
<infinity> SATA should be rock solid.
<infinity> PCIe video isn't however.
<infinity> Xorg doesn't even support PCIe yet (it just sets the card up as classic PCI)
<hunger_> infinity: Xorg does not start due to udev not setting up /dev/input/mice.
<infinity> So, anything "heavy bandwidth" (which is just about anything, over pure PCI) could be crashing the X server.
<hunger_> infinity: But that is unrelated;-)
<infinity> I could be on a wild goose chase, though.
<hunger_> infinity: Well, I should have known better than getting the new stuff to run linux on;-)
<infinity> I'm going to build a new Xorg with a CVS snapshot of the radeon driver and see if things have improved at all on that front.
<infinity> New stuff is an adventure, though. :)
<infinity> (And the T43 series is rather hard to pass up..)
<hunger_> infinity: I need that damn laptop!
<hunger_> infinity: and it is soooo sweet... I just had to have it;-)
<infinity> I hear you.  I rather like mine too.
<infinity> Though, my girlfriend looks at me oddly when I scream at it once or twice per day because it's locked up again.
<infinity> :/
<infinity> Anyhow, I'm digging into it.
* Lathiat laughs
<infinity> Rest assured that if I have anything to say about it, breezy will be rock solid on this hardware by the time we release.
<hunger_> infinity: My gf looks at me oddly when I grin maddly at it for pride of ownership;-)
<hunger_> Any idea how to turn of that splash screen?
<infinity> Uninstall usplash.
<Lathiat> apt-get remove usplash ?
<hunger_> Won't that break dependencies?
<infinity> Oh, feh.  It was reseeded to desktop already?
<infinity> That's a bit premature...
<hunger_> Yeap... that breaks ubuntu and kubuntu-desktop.
<Lathiat> yeh i think so
<Lathiat> i didnt notice
<hunger_> I tried removing "splash" as a kernel option.
<Lathiat> yeh that doesnt work, its supposed to apparently but it doesnt
<infinity> I'd recommend just letting the *-desktop packages go for now, and reinstalling them later when usplash is less... Rough.
<hunger_> I do not mind the really *UGLY* image, but that I never get to a login prompt when running usplash...
<infinity> Oh, try "video=vc:8" if you are looking to find a prompt.
<infinity> That might do it for you.
<Lathiat> whats that do?
<infinity> Shunts the framebuffer off to nevernever land.  In theory.
<infinity> Not sure if vga16fb respects it.
<hunger_> infinity: hitting Alt-F1 is enough... then I get some error messages from usplash and my login prompt.
<Lathiat> unfortuantely vga16fb sucks on thi shardware
<hunger_> infinity: But it is somewhat counter-intuitive;-)
<infinity> hunger_ : You could also "sudo rm /usr/share/initramfs-tools/scripts/init-premount/usplash" and then regenerate your initramfs.
<infinity> But that's pretty hackish.
<hunger_> infinity: ARRRGGGGG! Who puts config stuff in /usr?
<infinity> It's not config stuff.  The initramfs hooks all go there.
<infinity> I'm assuming there's a way to override what initramfs does with real config stuff in /etc
<infinity> But I'm not sure jbailey's had the time to document much about it, and I've not played with it yet.
<hunger_> infinity: Which might belong in /var... 
<infinity> (Other than having installed it and noticed that it more or less works)
<infinity> Why would it belong in var?
<infinity> It's static data, belonging to the usplash package.
<infinity> It doesn't change.
<hunger_> infinity: It is system specific stuff, isen't it?
<infinity> Hence, not "variable"
<infinity> No, it's package-specific.
<infinity> Think of it like .desktop or update-menus files.  Except this is for initramfs. :)
<hunger_> infinity: Hooks are system specific... initramfs setup is definitly system specific.
<infinity> It's just one package's way of hooking into the larger scope.
<infinity> Like I said, I'm sure there's a way to specify how to muck with it in /etc, I'm just not sure what that is.
<hunger_> infinity: Why is there the same hierarchy in /etc again?
<infinity> You'd have to ask jbailey.
<infinity> I assume both are read.
<infinity> Gah, it's 00:37 and I need to be up in 6 hours.  Where does the time go?
* infinity -> bed.
<Zebaz> hello
<pef> bye
<Lathiat> jdub: did you do that xine upload?
<jdub> oh crap
<jdub> i did the patch but not the upload :)
<Lathiat> :)
<jdub> done
<HiddenWolf> jdub: what will be happening with the ubuntu-calendar packages?
<jdub> HiddenWolf: the art team will be handling them
<davyd> they cut them off, just like I said they would!
<davyd> and in their place was a picture of Ubuntu developers
<davyd> and then some people
<davyd> but I was vaguely on track ;)
<HiddenWolf> jdub: we haven't had a new one since april, and while the files get installed in /usr/share/backgrounds/ they do not show up in the gnome-change-background app.
<HiddenWolf> haven't since hoary pre-release, actually
<davyd> in April they cut us off, with elmo and mark and some other people
<davyd> (I can't remember who)
<Mithrandir> james, mark and matt
<davyd> so jdub, do you have secret UDU plans post l.c.a next year?
<jdub> there will not be a developer conference in january
<davyd> ok
<HiddenWolf> davyd: piont remains, the packages in the archive are now useless, since they don't show up in the change background app
<davyd> don't they...
<davyd> do they not install the XML files that are required?
<davyd> or did someone break something in GNOME?
<HiddenWolf> davyd: my guess is they didn't install an xml file. The april package shows up, older packages don't
<HiddenWolf> both hoary and breezy, btw
<m0rphx> dpkg -S gives me: xkeyboard-config: /etc/X11/xkb/rules/base.xml
<m0rphx> but after installing this package the file isn't there
<mdke> sladen, ping?
<Amaranth> m0rphx: dpkg -S shows you that the xkeyboard-config that you have installed now claims to have that file
<Amaranth> m0rphx: I'd say file a bug report.
<Amaranth> m0rphx: (sorry about the slow response, it is a weekend)
<Treenaks> Amaranth: bad excuse :)
<Amaranth> Treenaks: Hey, I took time out of my weekend to make dragging .desktop files from nautilus to smeg work, give me a break. :D
<Treenaks> Amaranth: the only valid excuse is "the SO is yanking me away from the keyb...fmjkgn" :)
<Amaranth> of course, the fact that this is my last day online (at least on cable) might have something to do with why i'm here...
<Amaranth> Treenaks: you'd better be getting something out of it :D
<ploum> hello
<ploum> Is there any bugzilla admin here ?
<ploum> seb128 asked that someone gives me enough right to mark bugs as UPSTREAM but I cannot
<Amaranth> ploum: see topic
<Amaranth> or not
<ploum> Amaranth, I've read the URL in topic, but I don't see the point here
<Amaranth> [13:57]  <Amaranth> or not
<Amaranth> ploum: there are 3 people who can give you editbugs and two of them aren't here
<Amaranth> i can't remember who the third is
<ploum> sorry, I taked the "or not" as ironic
<ploum> well, for the moment, I comment them as "can be marked as upstream"
<Simira> mjg59:ping
<benohite> hello
<benohite> does anyone know "zenity" ?
<luis_> benohite: what about it?
<benohite> about a script
<benohite> zenity allow to generate easely gdialog from script
<benohite> but i can't find doc on it
<Zomb> examples from dialog pkg maybe?
<benohite> sorry my english isn't so good i didn't understand :)
<Burgundavia> niran, you totally rock
<niran> that's what i like to hear
<niran> it seems like whenever i wake up and get to my computer, i'm being showered with praise
<niran> i can't say i don't like it
<Burgundavia> one minor UI point
<Burgundavia> what about have a tab for searches and a tab for the listing? the serach bar would always be visible, it would just switch you to the search tab
<Burgundavia> niran, why are you not mentioned in the about?
<niran> i'm on authors
<Burgundavia> ah
<niran> i didn't add the about, mvo did
<Burgundavia> ok
<niran> for the tab thing, i don't see how that would make it better
<Burgundavia> after I search, there is no easy way to get back to the listings
<niran> clear search?
<Burgundavia> clear search means that I clear the search bar to me
<niran> ah. hmm...
<niran> maybe clear results instead of clear search?
<Burgundavia> yes
<Burgundavia> oh, and the search function should probably remember previous searches
<Burgundavia> with typeahed
<Burgundavia> niran, should I just file bugs on these things?
<niran> that's sounds like a plan
<Burgundavia> ok
<niran> i'll fix the clear search thing
<Burgundavia> what about programs that are in the wrong section?
<Burgundavia> will that be automatically fixed?
<niran> if their desktop files have the wrong section, g-a-i will put them in that wrong section
<niran> but when those get fixed, they'll be fixed in g-a-i after i generate new data
<Burgundavia> ok
<Burgundavia> and you generate the data out of the archive?
<niran> right
<Burgundavia> ok
<Burgundavia> you also need to nuke gnome-app-install-data, as the package is now no longer seperated
<niran> Burgundavia, mvo deals with all the packaging details, and i think he knows about that one
<Burgundavia> niran, ah
<marcin> hi all
<marcin> could someone help me and tell how to create deb package with source which has one single file?
<marcin> and this file is available as just uncompressed source
<Burgundavia> marcin, #ubunut-motu is better place to ask
<marcin> Burgundavia: ok thx
#ubuntu-devel 2005-08-19
* xhaker is away (Away, bnc logging)
<Burgundavia> xhaker, please turn off your away mesage. It is quite annoying
<dabaR> Can I have operator status for #ubuntu-hr?
<jdub> Burgundavia: hrm, maybe we should come up with some better standards for how to document the laptops and so on
<jdub> Burgundavia: i'm sure mjg59 would have some ideas on what would be most helpful to him
<Burgundavia> jdub, there are two parts that I see. the hoary stuff is mostly for community members and thus needs to be organized well
<jdub> dabaR: you'll have to ask chanserv about who owns it
<jdub> hoary stuff?
<Burgundavia> the breezy stuff is for developers, so that bugs should mostly be in bugzilla
<Riddell> ivoks owns #ubuntu-hr
<Burgundavia> jdub, mdke and I had a disagrement about how to report
<Burgundavia> jdub, is it enough to have a report for any stable release and a rolling report for the latest development?
<jdub> i don't think the current release is all that relevant
<jdub> the goal is to make sure we know the hardware, and know what the devel branch supports
<Burgundavia> the current stable is useful for people looking to purchase a laptop
<dabaR> jdub: thanks.
<jdub> ok, i don't think that has much to do with the laptop testing team
<dabaR> Riddell: ya, he does, well, cool.
<jdub> we can document that stuff on a hardware support page somewhere
<Burgundavia> no, but we might as well get the marketing win on it
<jdub> Riddell: hey, have you seen fcrozat's XSETTINGS patches for KDE?
<jdub> Burgundavia: right, but that's a different issue
<Burgundavia> they did ask for a report on how the the current stable installs
<Riddell> jdub: I don't think so
<jdub> Burgundavia: sure, that's important to understanding where we're at from a benchmark release
<jdub> Riddell: might be handy for nicer results when running apps in either environment
<jdub> Riddell: fcrozat is an mdk developer, the patches might be in their cooker RPMs, but you can find him on gimpnet fairly regularly
<Riddell> jdub: looks like a fun idea that, I'll make a note to investigate
<Burgundavia> mjg59, ping
<Riddell> jdub: what was the KDE stall at linuxworld like?
<jdub> Riddell: they had a nice banner
<tseng> i bet it was blue
<jdub> Riddell: and at one point, they were getting people to shout out how much they loved kde for a xandros CD
<jdub> for a *xandros* CD
<jdub> insane ;-)
<whiprush> hahah
<whiprush> I wonder how many people threw it back
<mjg59> Burgundavia: Hi
<Burgundavia> mjg59, jdub and I were talking about standardizing the reports on the wiki
<Riddell> they really should have asked for kubuntu CDs in time, those things are worth shouting for
<Burgundavia> mjg59, what is most useful for you?
<mjg59> Burgundavia: I'm planning on writing a form for data submission, but..
<mjg59> Basically I want to know whether stuff on the laptop checklist works by default or not
<mjg59> If it doesn't, I want to know how it doesn't work and if it can be made to work
<Burgundavia> mjg59, is there any reason why we don't just do this on the wiki?
<mjg59> If it works, I want to know nothing more
<mjg59> Burgundavia: Is it trivial to create ways to input data on the wiki that will result in a standardised format?
<Burgundavia> yes
<Burgundavia> I will create a standard table that they could copy and then fill out
<mjg59> Burgundavia: Ah. In that case, then do it via the wiki :)
<mjg59> (I should point out that I've just got back from Kamion's wedding, and so am nowhere near sober. This seems to be a recurring theme)
<Burgundavia> mjg59, the advantage of the wiki is that anyone can see the data. A form they submit to you might get lost
<Burgundavia> mjg59, both Matthew East and myself have gotten emails about how to make certain things on our laptops to work
<mjg59> Ok, cool
<jdub> how was the wedding?
<mjg59> jdub: Excellent
<mjg59> (hic)
<jdub> :-)
<Burgundavia> I will build up a skeleton table and then ask for your comments
<mjg59> Burgundavia: Excellent, tanks!
<Burgundavia> mjg59, should be ready by monday
<Burgundavia> mjg59, quick question, do you care bout every point release in the development or only a rolling report?
<Burgundavia> mjg59, I mean, do I need to keep all the colony reports around?
<mjg59> Only a rolling report unless it's necessary to check whether something's reverted
<Burgundavia> ok
<Burgundavia> mjg59, I am off, pm me if you have any further comments/issues/ideas
<mjg59> Burgundavia: Will do. Thanks for the help!
<Diablo-D3> hows breezy coming?
<Diablo-D3> https://wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<Diablo-D3> didnt that url use to be valid?
<whiprush> remove the UbuntuDownUnder part
<whiprush> it's just /BreezyGoals now
<Diablo-D3> is breezy still really really unstable, btw?
<whiprush> depends I guess.
<Diablo-D3> depends on what, exactly?
* Diablo-D3 considers, say, debian sid stable.
<whiprush> Don't know, I don't track sid.
<whiprush> I don't have problems with it.
<Diablo-D3> you use any c++ apps?
<whiprush> firefox and tbird
<Diablo-D3> and they work fine?
<whiprush> yep
<Diablo-D3> any kde apps?
<whiprush> no
<Riddell> kde apps work fine
* Diablo-D3 ponders doing the upgrade dance then
<Riddell> it's X that doesn't work
<Diablo-D3> ...... erk?
<Diablo-D3> doesnt work in what way?
<Riddell> doesn't work in new and exciting ways each day
<Diablo-D3> eww
<Diablo-D3> https://wiki.ubuntu.com/%c2%b5buntu
<Diablo-D3> that looks cool
<Diablo-D3> Riddell: 2.6.12 is in breezy isnt it?
<Riddell> linux-image-2.6.12-6
* Diablo-D3 ponders
<Diablo-D3> broken X... new kernel....
<jdub> X is easy to get working
<Diablo-D3> cant see.... but its really shiney...
<Diablo-D3> jdub: just tell dpkg to hold X for me? ;)
<jdub> no
<Diablo-D3> rewind to the previously known working version?
<tseng> or read ubuntu-devel
<tseng> and follow a few simple steps
* Diablo-D3 should subscribe to ubuntu-devel
<Diablo-D3> hrm, how do I check what version of something is in linux-restricted-modules?
<bur[n] er> jdub: about X being easy to get working... got a wiki page or some kind of reference?
* Diablo-D3 just downloads 2.6.12 from breezy manually
<jdub> bur[n] er: have a look at recent threads on ubuntu-devel
<bur[n] er> right on, will do
* bur[n] er has been content with remote Xing from a hoary box, but local X would be nice :)
* bur[n] er loves step three: profit! :)
<bur[n] er> thanks jdub 
<mdz> Riddell: do we really only want krita in main, and not the rest of the koffice binaries?
<mdz> Riddell: (is there any reason not to move them all together?)
<mjg59> mdz: Is there anything I should be worrying about right at the moment?
<jdub> mjg59: balance, slurred speech, etc.
<mdz> mjg59: hunger, poverty, poor medical care...
<Riddell> mdz: I want krita on the CD because image manipulation is a missing feature from kubuntu, I'd be happy to have the rest in support, not sure what else it brings in
<jammcq> mdz: howdie
<mdz> Riddell: could you review the dependencies and see?  if there aren't any new deps, we should just put them all in supported
<mdz> jammcq: good evening
<mdz> jammcq: congratulations on the LTSP award
<jdub> Riddell: keep in mind that gimp is one of the first things we'd remove if space becomes more of an issue on the CD
<jammcq> mdz: i've got a new machine, and i'm loading breezy now, to test out ltsp integration
<mjg59> Ah, good, nothing of any great concern
<Diablo-D3> you hate gimp that much?
<jammcq> and thanks, we were all surprised with that award
<jdub> Diablo-D3: no, it's just not important for the vast majority of users. it's cool, but it doesn't apply to the GCF.
<jammcq> mdz: also, sbalneav is doing the same this evening
<mdz> mjg59: feedback starting to flow in from LaptopTesting?
<Riddell> jdub: GCF?
<mdz> jammcq: glad to hear it
<jdub> greatest common factor
<Riddell> mdz: will do
<mdz> jammcq: let me know if you have any questions not answered by the wiki
<jammcq> k
<jammcq> we should have some thin clients booting tonight
<jdub> jammcq: i'm seriously considering ordering one of your little thin client boxes - they were way sweet
<mdz> I'll be going out in 1.5 hours or so, and not back until quite late
<Diablo-D3> grr
* Diablo-D3 bangs head on desk
<mdz> and at that point perhaps a little drunk
<Diablo-D3> how the hell do I find out what version of madwifi is in a package of linux-restricted-modules
<mjg59> mdz: A bit, yeah
<jammcq> jdub: damn, I should have let you buy one that we had in sanfran, it would save you the shipping
<mjg59> mdz: The amd64 one is indescribable pain
<jdub> jammcq: 'sok, i should probably do something with the hardware i already have first, lest pia beat me up :-)
<jammcq> heh
* jdub is *sooooo* tempted to get a nice new desktop box with the google award money
<bur[n] er> awww... X is still b0rked for me :\  maybe next week ;)
<mjg59> jdub: Spend it on beer. Or me.
<paolo> jdub: SoC-er?
<mjg59> paolo: Nah, jdub is an open source luminary
<paolo> Oh.
<Diablo-D3> jdub: google...award... money?
<mjg59> jdub is teh best open source love magnet 
<mdz> mjg59: do you have the lsb-base changes ready for when jbailey fixes the fifo thing?
<mjg59> mdz: It's about 5 lines, but yeah
<Diablo-D3> I wonder if ubuntu has a changelog
<jdub> bur[n] er: it's not too hard to fix
<jdub> Diablo-D3: every package has a change log under /usr/share/doc/<package>/
<mdz> it's more like 10
<Diablo-D3> I meant for 'big' features that arent related to any one package
<Diablo-D3> http://lwn.net/Articles/142671/
<jdub> paolo: nup, i got an award at oscon for being noisy :-)
<Diablo-D3> like that
<mdz> we call those "release notes"
<mjg59> mdz: 5, 10. It's less than an order of magnitude.
<mdz> mjg59: I was musing over init scripts called by maintainer scripts post-boot
<bur[n] er> jdub: i did the apt-get install xkbutils thing and step 2 of --force-confmiss on the xkeyboard thing... but no dice... i still get a blue ncurses based screen saying X encountered an error and I can do nothing but hard reboot back to 'recovery mode'
<mjg59> Don't trouble me with your powers of 2.
<jdub> paolo: http://osdir.com/Article6677.phtml
<mjg59> mdz: Once usplash isn't running, usplash_write will exit silently
<jdub> bur[n] er: check the log, then - i bet you just need to run a dpkg-reconfigure to get the right font paths
<mjg59> I /do/ need to code usplash_read (for encrypted filesystems)
<mdz> mjg59: right, meaning that init scripts which currently print a message become silent
<mjg59> mdz: Mm? My plan was to do both
<mdz> oh, I see
<mdz> that's a fine idea
<mjg59> Then people can switch back to tty1 and see all the messages
<jdub> mjg59: will usplash be able to print characters on non-white? (is that box just a guide in current artwork?)
<mjg59> jdub: It can do, yeah
<jdub> cool
<bur[n] er> jdub: i hate to be a bother, but reconfigure what package??
<mjg59> I can't emphassise this enough
* jdub thinks black background will probably look the slickest
<mdz> mjg59: the box is actually a functional place where text can scroll
<mjg59> *the artwork is shit because I cannot draw*
<jdub> bur[n] er: xserver-xorg
<mjg59> mdz: Yes, but it's trivial to change this
<mdz> er
<mdz> s/mjg59/jdub/
<mjg59> The box is drawn by the code
<bur[n] er> thanks jdub, i'll give it a shot
<mjg59> It can draw a black box instead
<mdz> jdub: you can play with usplash_write to see how it looks
<jdub> mdz: do we *want* scrolling text on usplash sexiness?
<mjg59> jdub: There is scrolling text
<mdz> jdub: if it's going to stay up all the way through to gdm, it should probably give some idea of what's going on, yes
<mjg59> Well, scolling in the same way as the console
<paolo> jdub: cool - congrats :-)
<jdub> paolo: :)
<paolo> I'm a SoC, in fact :-P
<paolo> SoC-er even.
<jdub> mdz: i think i'd prefer something closer to the rhgb service title status
<mdz> jdub: how is that different from what we have?
<mjg59> jdub: It's more SuSE bootsplash than rhgb
<jdub> well, keep in mind that i haven't seen what it looks like post-initramfs
<mdz> it looks the same only with status messages / progress bar
<mjg59> We show the same text as would appear on the console, but in a more attractive manner
<mjg59> Switching it to something more abstract is rather more effort
<jdub> mjg59: one line at a time, or with scrolling lines?
<mjg59> jdub: Scrolling - otherwise stuff can vanish before you read it
* jdub thinks that's pretty reasonable tradeoff for looking elite
<mdz> speaking of which, am I the only one for whom the GNOME splash text has missing characters in it?
<jdub> if they want scrolling status, they can switch back to tty1
<mjg59> jdub: The current state is that a few lines of text are scrolled in the box
<jdub> should i be seeing usplash post-initramfs?
<mjg59> Not yet
<j^> why not just "Starting Services..."
<mjg59> Needs a touch more initramfs love
<jdub> rhgb just shows the service name currently starting
<j^> even thats too much imho
<mdz> because we spec'd this out 4 months ago and decided otherwise
<mjg59> jdub: What does it do in the case of failure? Display anything informational?
<jdub> and you can click a disclosure triangle to get the scrolly bits (you don't even have to switch tty)
<whiprush> yeah that > dropdown is neat
<mjg59> I think for now we go with a more attractive version of what we already have, and then redesign it in Breezy+1
<jdub> mjg59: you can pop open the hidden terminal with the disclosure widget if you care
* sladen hmmms about the state of usplash.
<mjg59> jdub: Urgh. Yeah, that's a bit more awkward to do since we don't run X
<mdz> jdub: we're not going to do user interaction, at least not in this iteration
<jdub> j^: it gives you an impression of progress
<jdub> mdz: not suggesting it (we have tty switching anyway)
<mjg59> In principle bogl can do mouse input, but it's not going to be pretty
<bur[n] er> jdub: possibly X is still broken with widescreen monitors??  
<jdub> it's cool that rhgb does it, but i don't think lack of error status is reason to make it have the scrolly bit on the sexy screen
<j^> jdub thats what a progressbar could be for: Starting Services... [|||||........] 
<jdub> j^: don't have any meaningful way to understand startup period
<mjg59> j^ progress bars are a complete arse
<bur[n] er> i reconfigured xserver-xorg, but I still get the curses based bluescreen with "Failed to start the X server (your graphical interface).  It is likely that you it is not set up correctly.  Would you like to view the X server output to diagnose the problem?"
<sladen> j^: and how long is the progress bar?
<jdub> bur[n] er: have you looked at the output?
<mjg59> They ought to increase at a linear speed, but we can't do that easily
<jdub> mjg59: have you looked at SMF?
<mjg59> jdub: TBH, our screen is not very sey
<bur[n] er> jdub: i can't... the screen is locked here... I can't even do ctrl+alt+f2 
<mjg59> jdub: Not yet. If it's possible in the future, I'll be happy
<jdub> mjg59: we can make it sexy :)
<bur[n] er> i can't ctrl+alt+bkspace either
<mjg59> s/sey/sexy/
<whiprush> bur[n] er: try ctrl-d
<mjg59> jdub: There's a limit to 640x480x16 colour sexiness
<bur[n] er> whiprush: :)
<jdub> mjg59: the windows one looks sweet, i don't think we'll have too much trouble
<mjg59> jdub: You think? I think we can do better than that, but I still don't think it'd look sexy
<j^> sladen does that matter? did you ever see a progress bar that had anything todo with the time it takes
<jdub> we must! WE MUST!
<sladen> with a bountie and some rub-in oil, anything can be made to look sexy...
<jdub> FAILURE IS NOT AN OPTION
<mjg59> j^: Progress bars that have no relation to the time it takes are teh suck
<j^> mjg59 use a spinning wheel
<mjg59> Nngh.
<jdub> rhgb has service name and a spinner
<mjg59> rhgb has better graphical primitives
<sladen> rhgb has VTE and a full gtk widget set
<mjg59> Yes
* sladen should do something about usplash, but doesn't want to get the blame if it still looks teh scuk0r
<jdub> sure, but i'm not suggesting we need to go that far to improve usplash sass value
<jdub> in terms of status, i'm trying to say that scrolly text smells, and a simple service name (or even just a single line of normal output) will be nicer
<j^> an image like http://www.neystadt.org/john/album/London2003/DSCN1246-London-Eye-Wheel.JPG  with turning wheel would be cool
<jdub> heh
<jdub> in sixteen colours, when full screen updates are quite slow? :-)
<sladen> lsb init works for standard Ubuntu packages;  you have to resort to screen-scraping unless you just use /etc/init.d/$name
<mjg59> jdub: You're not going to see most of those service names, and you're not going to get any useful diagnostic output
<bmonty> is https://wiki.ubuntu.com/Archive the only source of package mirror info??
<jdub> mjg59: you can switch to tty1 for diagnostic output if you need it
<jdub> mjg59: look at the windows startup screen - no diagnostic output
<mjg59> jdub: But that also sucks
<jdub> mjg59: same with the mac one
<sladen> j^: you're about 16777200 colours short of being able to do that
<mjg59> "Please press these obscure keys if you want to know what's going on"
<jdub> mjg59: for a desktop, that's not ridiculous.
<mjg59> jdub: It's not ridiculous once we have the infrastructure to log those failures
<jdub> (it's harder to get that output on mac and windows)
<mjg59> With our current infrastructure, if something fails on startup the user will never notice (assuming using your suggestion)
<mjg59> And that sucks
<jdub> it's not like they could do a whole bunch about it even if they could see it
<jdub> and it scrolls by quickly already anyway
<mjg59> No, but they'd know something was broken
<jdub> and they don't see all the output because gdm starts early
<sladen> they can't fix even if they do see it.
<mjg59> The alternative is that stuff just doesn't work and they have no idea whyt
<sladen> snap.  It'll just scare them into turning the computer off during fsck
<mjg59> gdm starts after everything that's important for the desktop
<jdub> mjg59: can we automagically switch to tty1 when an init script has an error?
<jdub> that at least is a major visual warning
<mjg59> jdub: Not in a terribly easy way
<mjg59> jdub: Especially given that it's expected for a couple of scripts to fail (ntpdate, for instance)
<mjg59> I guess we could fix those
* jdub is not convinced that seeing non-blocking startup errors is wildly useful on a desktop system anyway
<j^> what about fixing all those network scripts
<jdub> mjg59: yeah, that would uglify it unnecessarily
<bur[n] er> jdub: i see my X output and find that it can't find the "fixed" font and I should have x-window-system installed, but there is no package x-window-system... any ideas?  I promise, it's my last question for the eve ;)
<mjg59> jdub: If hal fails to start, we ought to tell the user
* bur[n] er feels like he's close
<mjg59> bur[n] er: Install xfonts-base
<sladen> j^: all those network scripts should be made to hook a callback for when the network status changes;  then ntp can at least do something sensible
<jdub> bur[n] er: if you do a dpkg-reconfigure xserver-xorg and have xfonts-base installed, it should work
<bur[n] er> mjg59: already newest version
<whiprush> jdub: this smf stuff jive license-wise?
<jdub> whiprush: CDDL, not a problem
<j^> sladen yup, and use NetworkManager/dbus for the network status
<jdub> (and the minor nits with CDDL sun is willing to fix)
<whiprush> interesting
<mjg59> CDDL isn't an obvious problem
<jdub> j^: we may get NM for breezy, but it's unlikely that we'll get that level of integration just yet :)
<mjg59> It's obviously meant to be a free software license. If there are any problems, they'll fix them
<mjg59> It's not worth the PR loss otherwise
<bur[n] er> aww... dpkg-reconfigure xfonts-base did the trick :)
<bur[n] er> thank you all so much!
<sladen> bur[n] er: I had that issue on my R31.  I didn't get to the root of where it wasn't finding the 'fixed' font.  but just installing xbase-fonts isn't enough
<j^> jdub i fixed NM today, including modem support http://bootlab.org/~j/bazaar/network-manager--ubuntu--5.11/
<jdub> rawk :)
<sladen> bur[n] er: ta, I'll try that
<bur[n] er> sladen: gl :)
<sladen> mjg59: having spoken to the people who made the decision;  up until 6 months before release they were expecting to use GPLv3
<whiprush> hmm, some people are claiming less than 10 second boot times.
<jdub> whiprush: you can get to a shell extremely quickly. but that's cheating. :-)
<j^> what about a bios with webbrowser?
<mjg59> sladen: GPLv3's existence would have made this easier
<sladen> j^: gcc lynx*.c -static -m8086
<sladen> mjg59: yes, their point of decision was 'needing' the patent crap
<sebest> i have a strange behaviour with breezy X, any key i type on my keyboard change the resolution of X
<sladen> mjg59: you would have enjoyed meet^flaming simon phipps
<bur[n] er> sladen: reconfiguring xfonts-base worked to get X up then?
<sladen> bur[n] er: dunno, I'll try
<jdub> man, oil-cooled PCs freak me out
<j^> jdub oil? its all about liquid nitrogen now.
<Riddell> mdz: https://wiki.ubuntu.com/MainInclusionReportLatexXFTFonts created, koffice added to supported
<sladen> is there any point gdm looping a failing X 3 times instead of just once?
<sladen> ...and then giving a message dialogue where the only way out is  Alt-SysReq-e
<sladen> bur[n] er: can you do  dpkg -S /usr/lib/X11/fonts/misc  and see what's owning it?
<bur[n] er> sladen: i have no misc directory in ....X11/fonts/
<whiprush> hmmm
<sladen> bur[n] er: alt-sysreq-r (reset keyboard) gets the Alt-Fn VT switching back...  GDM needs to not ask it's your-xserver-is-fucked on VT7...
<whiprush> was networkmanager deferred?
<bur[n] er> sladen: ctrl+d ?
<jdub> whiprush: undecided atm
<jdub> whiprush: afair
<whiprush> there's a patch sitting in #13070.
<mdz> Riddell: thanks.  feeling better
<mdz> ?
<Riddell> mdz: yes thanks (although I'm heading my flatmate coughing tonight, which is a bad sign)
<Riddell> s/heading/hearing/
<Riddell> mdz: what's your preference for smime support or demoting gnupg2?
<mdz> Riddell: is upstream any closer to a release?  it's a development snapshot, right?
<mdz> I'd prefer to demote it unless it's supported upstream
<sebest> my X is looking for XKeysymDB in /usr/lib/X11 but it is in /usr/share/X11 ...
<Riddell> "GnuPG 1.9 is the current development version of GnuPG.  Despite of
<Riddell> that, most parts (in particular GPG-AGENT and GPGSM) are considered
<Riddell> ready for production use."
<Riddell> http://lists.gnupg.org/pipermail/gnupg-announce/2005q2/000196.html
* mpt guesses it's rather difficult to take screenshots of usplash
<Lathiat> hrm, python-gtk2 is missing a dependancy on python-cairo
<sladen> mpt: while true; sleep 5; cat /dev/fb0 > screenshot; done
<mpt> "sleep 5"? It should have finished before 5 seconds is up :-)
* mpt ducks
<sladen> can somebody with a working breezy Xorg setup try  dpkg -S fixed | grep font  to see if you can turn up where the fixed fonts are living now
<OddAbe19> one sec
<OddAbe19> root@ubuntu:/home/oddabel #  dpkg -S fixed | grep font
<OddAbe19> console-data: /usr/share/consolefonts/grfixed.psf.gz
<OddAbe19> root@ubuntu:/home/oddabel #
<OddAbe19> one more sec
<sladen> OddAbe19: okay, thanks.  I think I've found the root cause elsewhere
<OddAbe19> Section "Files"
<OddAbe19> #       FontPath        "unix/:7100"                    # local font server
<OddAbe19>         # if the local font server has problems, we can fall back on these
<OddAbe19>         FontPath        "/usr/share/X11/fonts/misc"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/cyrillic"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/100dpi/:unscaled"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/75dpi/:unscaled"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/Type1"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/CID"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/Speedo"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/100dpi"
<OddAbe19>         FontPath        "/usr/share/X11/fonts/75dpi"
<OddAbe19> lol
<sladen> sssh.  /etc/X11/fonts/misc vs. /usr/lib/X11/fonts/misc
<bur[n] er> :)
<jp> wow
<jp> that's cool
<jp> :P
<sladen> daniels: xfonts-base is broken.  It's missing a symlink  /usr/lib/X11/fonts/misc -> ../../../share/X11/fonts/misc
<sladen> jdub: re: your example earlier.  I've just started GDM on a system with *nothing* running (result of several sysreq-e's) ...the result is just that I got a dialogue saying ''couldn't init HAL''.  The system doesn't actually seem to be affected otherwise!
<_d4vid> i haved problems with my firefox.. flash freezed my firefox.. now iam installed debian unstable version 1.0.6.2 works fine.. 
<quad> is there a problem with gdm in breezy? i get a message in my syslog that says something about gdm not being able to start greeter
<Diablo-D3> heh
<quad> my internet also only works for the fist 30 seconds i have it turned one!
<quad> *on
<whiprush> jdub: is there a "polish" keyword, or some kind of "it'd be easy, given attention
<whiprush> "
<jdub> hrm?
<whiprush> for example, bug 6853
* jdub doesn't understand the question, hopes the bug enlightens :)
<whiprush> It's been fixed in opensuse.
<whiprush> well, the icon is crap, sounds trivial to fix.
<jdub> *oh*
<whiprush> I was thinking of something like, is there a bugzilla keyword for "low hanging UI fruit."
<jdub> polish bug keyword :-)
<whiprush> right
* jdub read that as pole-ish, as in the country :-)
<whiprush> heh
<jdub> yeah, trivial or enhancement is appropriate
<jdub> but keyword... not really
<whiprush> gnome bugzilla has an easy_fix keyword, you think this would fit?
<jdub> i think we have one too
* jdub checks
<jammcq> mdz: ping
<jdub> yeah, easyfix
<whiprush> marked
<whiprush> jammcq: he mentioned something about going out tonight and getting drunk
<jammcq> hey jorge,jeff
<jammcq> hmm
<jdub> yo jammcq 
<whiprush> or something to that effect.
<jdub> jammcq: i didn't realise you guys got an LWE award - congrats!
<jammcq> jdub: yeah, we sure did :)
<jdub> ah bum
<jdub> is the image built in to usplash?
<jdub> bum, yes
<_d4v_d> see u all .. bye
<mdz> jammcq: pong
<ploum> Hello
<ploum> is there any bugzilla admin here ?
<Amaranth> ploum: It's still the weekend, I doubt it. :)
<ploum> Amaranth, just, I forgot it !
<ploum> for me, there's no difference between those days ;-)
<Lathiat> heh
<Lathiat> same
<ploum> well, so I've no more reason to not studying :-(
<sivang> MOrning all
<mdke> i'd like to test an alternative method of resizing my windows partition before installing Ubuntu, rather than using the install CD. Does anyone know a nice free solution?
<Lathiat> parted on a live cd?
<mdke> trying to pin down bug #13390
<Lathiat> run ubuntu live and install gparted
<mdke> Lathiat, doesn't the install cd use parted?
<Lathiat> probably
<mdke> i need an alternative
<Lathiat> theres also 'ntfsresize'
<Lathiat> it might use that 
<Lathiat> i dunno
<Lathiat> hell parted might even call that
<sivang> jamesh: around ?
<Amaranth> the only two i know of are parted and PartitionMagic
<Lathiat> yeh 
<davyd> I think it uses ntfsresize
<Lathiat> err
<Lathiat> is it just me
<Lathiat> or is his diagnostics partition in the middle of his linux partition
<davyd> hoary also does it without any logging to the d-i screen from memory
<Lathiat> oh
<Lathiat> its not
<mdke> partition magic is not free tho
<davyd> which is strange and wrong
<pitti_> Moin
<sivang> pitti: Moins Martin :)
<sivang> Doh, he logged off
<sivang> ah no he didn't :)
<sivang> mdz: Hi, did launchpad integration made feature freeze basically?
<sivang> s/basically/eventually/
<pitti> sivang: no, still here :-)
<mantiena> Hi all
<mantiena> mdz, hi, are you online ?
<sivang> pitti: yeah, I noticed - security work?
<mantiena> mdz, hello
<pef> hi
<mjg59> Hrm. Which package has xev ended up in?
<\sh> mjg59: i would like to help u but apt-file is not installable
<mjg59> Hrngh.
<mjg59> xmodmap has vanished as well
<highvoltage> really?
<mjg59> highvoltage: Well, it doesn't seem to be on my system
<siretart> mjg59: sorry for the bugreport. I couldn't imagine that celerons M do not support frequency scaling
<Lathiat> siretart: they dont?
<siretart> Lathiat: appearently not
<Lathiat> eww
<mjg59> siretart: No problem
<Lathiat> i guess theyre celerons
<mjg59> It's the distinguishing factor of them
<siretart> mjg59: is p4-clockmod not an option?
<mjg59> siretart: I don't think so - it's likely to be a Pentium M core, not a P4 one
<siretart> damn. gotta go. bbl
<mantiena> mdz, wake up ;)
<trygvebw> Hi. Is the GTK 2.8 in breezy compiled with Cairo support?
<tseng> yes
<trygvebw> okay :)
<trygvebw> great.
<trygvebw> Are there any icon sets or GTK themes that use Cairo?
<Lathiat> theres some beta clearlooks stuff
<luis_> where is that beta clearlooks in cvs?
<trygvebw> yeah, i saw that, but it's not avaiable, or..?
* luis_ was just looking for it, couldn't find it
<trygvebw> *available
<tseng> http://cvs.sourceforge.net/viewcvs.py/clearlooks/clearlooks-cairo/
<trygvebw> great
<luis_> oh, I thought it was on a branch
<tseng> sort of :)
<luis_> though
<luis_> hrm
<luis_> I thought all clearlooks devel was moving to gnome cvs?
* luis_ is very confused now
<tseng> huh, if i checkout clearlooks module i dont ahve that dir
<tseng> it is its own module
<luis_> http://cvs.gnome.org/viewcvs/gtk-engines/engines/clearlooks/src/ ?
<luis_> hrm
<luis_> thos's email seems to say that gtk-engines is canonical
<luis_> http://www.mail-archive.com/desktop-devel-list@gnome.org/msg02174.html
<trygvebw> so it's in gtk-engines?
<luis_> yeah
<trygvebw> ok.
<luis_> AFAICT that is the canonical one
<luis_> though it sure looks like there is some devel going on at sf.net still
<trygvebw> okay
<trygvebw> so i just download it from CVS and then configures it with ./configure --disable-crux --disable-hc --disable-industrial --disable-lightouseblue --disable-metal --disable-mist --disable-redmond --disable-smooth --disable-thinice --prefix=/usr
<trygvebw> huh
<trygvebw> oh well
<tseng> yeah so
<trygvebw> okay.
<tseng> clearlooks-cairo considered slightly unstable
<trygvebw> i guessed since it is in cvs only ;)
<trygvebw> *installed*
<trygvebw> hmm
<trygvebw> should i restart X maybe
<trygvebw> let's see...
<trygvebw> nope
<trygvebw> ahh
<trygvebw> i have forgot to upgrade gnome :)
<trygvebw> anything else i need to do?
<Lathiat> pray
<trygvebw> :/
<trygvebw> Is the GNOME in breezy broken?
<Lathiat> n o
<trygvebw> ok.
<jp> Is the X in breezy broken?
<tseng> no.
<trygvebw> so dist-upgrading is safe?
<trygvebw> or just upgrading gnome-desktop-environment?
<jp> tseng thanks
<jammcq> mdz: ping
<jp> the
<mdz> jammcq: pong
<jammcq> hey
<jammcq> mdz: do you have some time to go over a few issues with ltsp/breezy ?
<mdz> jammcq: sure
<jammcq> it's not launching a gui login screen for the thin client
<jammcq> I get a text login, but none of my user accounts work
<mdz> yeah, there are no user accounts on the client
<jammcq> also, after upgrading hoary to breezy, eth0 doesn't automatically come up
<mdz> the easiest way to debug is to chroot /opt/ltsp/i386 passwd root
<jammcq> I have to do a 'ifup eth0'
<mdz> jammcq: that's http://bugzilla.ubuntu.com/show_bug.cgi?id=13398
<mdz> once you've set a root password and can login, check /var/log/ldm.log
<sivang> mdz: ping, do you have a couple of minutes to talk about launchpad-integration ?
<mdz> sivang: ok
<jammcq> mdz: also, it is taking 5-1/2 minutes to boot a thin client
<sivang> mdz: has everything went ok? I see that evo was not patched (Accoridng to wiki page) and that applets were probably not addressed, were their any difficulties with the bonobo helper?
<jammcq> not exactly speedy, i'd say
<mdz> the new linux-restricted-modules infrastructure is a huge penalty for thin clients
<mdz> I think we'll probably have to disable it
<Lathiat> whys that?
<jammcq> what is 'linux-restricted-modules' ?
<mdz> jammcq: apt-cache show linux-restricted-modules-2.6.12-6-386
<mdz> Lathiat: because it takes a long time to do its work over NFS
<mdz> sivang: you need to ask seb128
<Lathiat> mdz: ah
<sivang> mdz: ah ok, I saw you last edited the page so I figured to ask you , thanks anyway
<mdz> sivang: I just reorganized it
<sivang> mdz: k, cool
<jammcq> also, I initially, I tried using my existing dhcp server, but I was unable to get ROOTSERVER to be anything other than the IP address of the DHCP server
<jammcq> so, I setup dhcpd on the breezy box, but had lots of problems because the breezy IP address was 192.168.254.149, and dhcpd had a hard time with that. 
<mdz> jammcq: is your existing dhcp server something other than ISC dhcpd?
<jammcq> yes, ISC dhcpd 3.0
<pef> bye !
<mdz> jammcq: you tried "next-server <ip address of the NFS server>;" ?
<jammcq> yeah, pxe doesn't honor that, so it wouldn't get the kernel from the right place
<mdz> that works fine with my thinkpad
<Lathiat> might depend on the bios
<Lathiat> and/or network chipset
<jammcq> i'm using an HP T5305 thin client
<jammcq> sbalneav had some problems last night too, but they were different.  he's getting a libc6 issue from the initramfs
<jammcq> his thin client has a via-533 cpu, and I wonder if there's something about the way glibc was built that the via doesn't like
<mdz> jammcq: hmm, can I get more detail about the initramfs issue?
<mdz> oh, I see
<mdz> initramfs-tools seems to be choosing to include the glibc used on the server
<jammcq> mdz: not till tonight, when sbalneav gets back online. he's out doing family things
<jammcq> hmm, server glibc is really NOT what we want for the client
<mdz> I don't think it should be fatal though
<mdz> the important stuff in initramfs uses busybox or klibc
<siretart> mjg59: around?
<mdz> klibc should be plenty to start a thin client
<siretart> mjg59: success with p4-clockmod with Celeron M, powernowd does throttle the cpu nicely
<jammcq> well, when scott gets back later, he'll have to explain what it's doing
<mdz> I only have one netbootable system which isn't an i686, and it's my router so I can't use it as a test platform
<mdz> should be trivial to fix though
<mdz> if he could file a bug in bugzilla against initramfs-tools, that would be great
<jammcq> k
<mjg59> siretart: Really? Gosh
<mjg59> siretart: I wouldn't recommend it - the latancy is quite poor with p4-clockmod
<siretart> mjg59: yes, I'm just writing a comment on the bugzilla entry
<mjg59> We ended up blacklisting it because of that. I didn't know it worked on Celerons, though
<siretart> mjg59: hey, it's still better than nothing
<mjg59> siretart: Arguably not :(
<siretart> huh? what problems will arise?
<jammcq> dhcpd seems to be doing odd things.  for instance, I have 'range 192.168.0.20 192.168.0.63', and it handed out an address of 192.168.0.244 to the client
<mdz> are you sure it's talking to the right dhcp server?
<mjg59> The processor doesn't speed up fast enough when an application needs CPU time
<Lathiat> if it saves power can be usefull to lock it down
<mdz> jammcq: ah, I know
<mdz> jammcq: you're using ltsp-server-standalone, which overrides the config file with /etc/ltsp/dhcpd.conf
<mdz> it should probably install /etc/dhcp3/README.ltsp or something
<jammcq> huh ?
<jammcq> ah
<jammcq> ooh, that's scary
<jammcq> that would explain my problem with 192.168.254.149 too
<siretart> mjg59: hm. true, indeed. openoffice2 starting quite sloppy. what would be the right solution then? improving speedstep_centrino?
<Lathiat> imho powernowd itself is slow
<Lathiat> the ondemand schedular in the kernel gives much better performance
<Lathiat> possibly less power saving but it wasnt terrible
<jammcq> but.... I am VERY impressed with how quickly breezy boots and gets to a login screen on the server
<mdz> jammcq: compared to Hoary?  I wouldn't expect a dramatic difference
<mdz> we made a lot of improvements in that area for Hoary though
<Keybuk> that being said, breezy does seem to boot a lot faster than hoary by sheer accident
<Keybuk> default install is about 10-15s faster
<mjg59> siretart: Having a non-crippled CPU
<luis_> slightly OT- anyone know if /etc/lsb-release exists in a standard debian install?
<siretart> mjg59: hey, thats a canonical laptop ;)
<highvoltage> luis_: perhaps you should ask on #debian
<mdz> luis_: I don't think any lsb packages are installed by default in Debian at present
<luis_> thanks, mdz
<mjg59> siretart: Heh
<mjg59> siretart: But seriously, there's no good way of supporting power scaling on Celeron machines
<siretart> mjg59: OK. I was just scared/confused by the error message from powernowd on bootup
<siretart> and I couldn't imagine that intel/ibm would sell such crippled cpu's
<jammcq> mdz: ok, i've got a root shell on the thin client. where is that ldm log file?
<mdz> jammcq: /var/log/ldm.log
<Lathiat> siretart: yeh its called celeron for a reason :)
<jammcq> yeah, found it
<Lathiat> i knew someone that used to say
<Lathiat> sell-air-on
<mjg59> siretart: Yeah, the message could possibly do with tidying
<Lathiat> (i say sell-err-on)
<Lathiat> mjg59: so whatever usplash is doing screws my console after resume (random cruft all over it
<jammcq> http://pastebot.geeksinthehood.net:8888/123
<Lathiat> yet vesafb works fine after suspend, hrm :P
<jammcq> mdz: check that url for the ldm.log file
<Lathiat> this is backwards to everyone else apparently :)
<mdz> jammcq: sounds like the X server didn't start; check /var/log/Xorg.*.log
<mjg59> Lathiat: To what extent?
<mjg59> X doesn't come back at all?
<Lathiat> no X works fine
<Lathiat> my *console* just doesnt work, it has cruft all over it and it doesnt do anything
<Lathiat> well it does things, random bits change all over the screen :)
<Lathiat> interestingly it runs from top to bottom
<mjg59> Are you running the latest X?
<jammcq> yeah, xorg.conf doesn't look complete
<Lathiat> where as the console is only 640x480 in the middle of the screen
<Lathiat> yep
<mjg59> Hm. Ok.
<mjg59> Interesting.
<Lathiat> this is with a nvidia card
<Lathiat> i am running the binary drivers, might be upsetting things
<Lathiat> (likely)
<mjg59> Ah
<Lathiat> i might try with nv
<mjg59> Can you try without?
<Lathiat> ok bbs
<mdz> jammcq: is it obviously corrupt?
<jammcq> http://pastebot.geeksinthehood.net:8888/124
<jammcq> it's just incomplete
<mdz> I worked around that bug in ltsp 0.46
<mdz> which I apparently forgot to upload
<jammcq> heh
<mdz> uploaded now
<mdz> meanwhile, people.ubuntu.com/~mdz/ltsp/
<mdz> you just need the new ltsp-client in the chroot
<jammcq> so, in chroot, can I just 'dpkg -i ltsp-client_0.46_i386.deb' ?
<mistik1> mdz: op yourself and do the invite
<mdz> jammcq: yes
* mode/#ubuntu-devel [+o mdz]  by ChanServ
* mode/#ubuntu-devel [-o mdz]  by ChanServ
<mistik1> now if you goto the webpage you will see ubuntu-devel in the list ;-)
<jammcq> mistik1: thanks buddy
<mdz> ok
<mistik1> I also have no problem with you creating a redirect to the site from a ubuntu-linux.org addy
<mistik1> my pleasure
<siretart> mjg59: are there any plans of adding tpb to main? I've seen a malone bugreport about trouble with the nvram module not loaded by hotplug/by default, and problems with permissions on /dev/nvram
<mistik1> jammcq: btw, I've been thinking about moving to the LISP pastebot which support anotations to the paste and such and such, what do you think of that?
<jammcq> mistik1: sounds cool
<jammcq> although we should carry on that conversation over at #ltsp
<mistik1> this way you could correct a paste that someone made instead of having to tell them what to do
<mistik1> ok, my appologies
<Lathiat> mjg59: ah ok works with nv
<Lathiat> mjg59: unfortunately i stil lhave that 2 line thing which makes my console useless
<Lathiat> and someone needs to teach google about AC power and to stop indexing when on battery
<Lathiat> err, beagle
<mjg59> Lathiat: Hrmph. Weird.
<mjg59> siretart: There's no secure way of adding it to main
<mjg59> Which sucks
<mjg59> I'll look at a cleaner implementation
<Lathiat> cleaner impl of?
<Lathiat> mjg59: so vesafb breaks suspend on most hardware?
<siretart> mjg59: what about the nvram module? Is the typical ubuntu user expected to do a 'echo nvram | sudo tee -a /etc/modules' himself? what are the problems with that?
<siretart> Lathiat: cleaner impl of tpb
<Lathiat> siretart: ah
<mjg59> Lathiat: Yes
<Lathiat> mjg59: do you have any idea how i can find a list of vesa modes for my specific hardware?
<mjg59> Uh. There shouldn't be specific vesa modes
<Lathiat> well apparently you can get some for liek widescreen 
<Lathiat> that vary 
<mjg59> The numbering is part of the standard
<mjg59> Oh, eww
<Lathiat> (just what ive heard, i could be wrong)
<mjg59> That's not strictly vesa, then
<Lathiat> so maybe not
<Lathiat> where can i get a list of vesa modes?
<mjg59> siretart: nvram probably ought to be autoloaded, but that won't help the tpb case
<Lathiat> (higher than those in the kernel docs)
<mjg59> Lathiat: I think the VESA spec is open
<Lathiat> mjg59: hrm is it ?
<siretart> mjg59: shall I file a but about nvram? against which package then? hotplug?
* Lathiat looks
<mjg59> Lathiat: http://www.vesa.org/Public/VBE/vbe3.pdf
<siretart> I know that this wont solve the tpb problem for itself. thats just a first step
<mjg59> siretart: Hmm. hotplug probably isn't the right choice - there's no way of it knowing
<mjg59> It probably ought to be in /etc/modules by default on x86 and amd64
<siretart> hm. I'll write a mail to ubuntu-devel, then
<Lathiat> mjg59: eeps why is usplash seeded in main already?
<mjg59> Lathiat: Because it's targetted at Breezy
<Lathiat> heh ok
<Lathiat> damn stupid hardware
<mjg59> Lathiat: It should be fine on any hardware that the installer was fine on
<Lathiat> mjg59: installer isnt fine either :)
<mjg59> Well, indeed
<Lathiat> im sure it worked at one point, way back, i should try the warty installer
<mjg59> So you disable vga16 during the install, and then usplash doesn't run either
<mjg59> So it doesn't break anyone
<Lathiat> well usplash still boots if you take splash out
<Lathiat> be good if you could fix that
<mjg59> Does it? Grah.
<mjg59> It's not meant to.
<Lathiat> yeh someone else mentioned it earlier but i'll try it again if you want
<mjg59> The script looks ok
<mjg59> Hrm
<Lathiat> theres also other random errors
<Lathiat> like i get a chroot: command not foudn adn stuff at the end of the boot
<Lathiat> know about that?
<mjg59> Yeah, there's some tidying up stuff needed in the initramfs stuff
<mjg59> I'm not sure why the chmod throws an error
<Lathiat> no path i assume
<mjg59>         chmod g+rw /dev/fb0
<Keybuk> heh @ ssh ... I appear to have just got a screenful of "Killed by signal 1."
<mjg59> Ought to be ok. Weird.
<Lathiat> i assume theres no path and you want /bin/chmod ?
<mjg59> Doesn't it give "chmod: no such file or directory" rather than "sh: chmod - command not found"?
<Lathiat> er
<Lathiat> let me look
<Lathiat>  /scripts/init-premount/usplash: 44: chmod: not found
<mjg59> Ah. Hm.
<mjg59> Yeah, maybe it needs a path, then
<Lathiat> mjg59: also my cpu speed has a habbit of getting stuck on 600mhz requiring you to stop, start, stop, start powernowd to get moving agian (i think its a kernel bug tho as doing stuff in /sys fails to) -- hard of that one? (pentium-m)
<mjg59> Hrm. Nope.
<mjg59> We'll probably switch away from powernowd, though
<Lathiat> and i've even seen it, with powernowd stop, drop and get stuck on 600
<Lathiat> i think that was only once tho
<Lathiat> mjg59: and use what?
<tseng> Lathiat: i think that is more just powernowd sucking
<tseng> but i see the same
<mjg59> Lathiat: ondemand
<Lathiat> tseng: well i thought that, except that if i restart it
<Lathiat> its still stuck
<mjg59> The kernel can do it on its own
<Lathiat> i have to restart it a second time
<Lathiat> mjg59: cool, that works better
<Lathiat> and echoing something into /sys gives some weird error
<Lathiat> but restarting powernowd twice seems to get it going again
<jammcq> mdz: ldm seems to be stuck in a loop. I see X for a second, then the screen blanks, and about 5 seconds of pause, and then it does it again.  Looking at the ldm python script, seems like either Xorg or the greeter is failing
<Lathiat> tseng: and yeh, thats mighty annoying
<tseng> that sounds like an x server or configuration problem
<tseng> gdm tries to restart X every 5 seconds
<jammcq> the Xserver seems ok, cuz I see the gray screen with X cursor, but then the screen goes away
<jammcq> it's not GDM
<jammcq> this is on a thin client, using ldm
<Lathiat> mjg59: heeres something interesting
<Lathiat> mjg59: if i turn video expansion on, it works fine
<mjg59> Lathiat: Haha
<Lathiat> same goes for the warty install
<Lathiat> broken with it off, works with it on
<mjg59> Ok - that'll be vbetool posting it oddly
<mjg59> Oh, I see what you mean
<mjg59> Hm. Not a lot we can do there, I guess
<Lathiat> (and by works i mean, vga16fb doesnt do the weird thing)
<mjg59> Except find someone who knows more about vga hardware
<Lathiat> heh yeh
<Lathiat> the isolinux boot screen seems to look right
<Lathiat> altho it wasnt scrolling down
<mjg59> Windows seems to manage
<mdz> jammcq: anything in the log?
<Lathiat> mjg59: yeh
<Lathiat> bios screen too
<jammcq> mdz: working on getting to the log
<mjg59> Lathiat: Is the bios screen graphical?
<Lathiat> mjg59: yeh
<Lathiat> mjg59: has a logo etc
<Lathiat> big thunking dell in the middle :)
<jammcq> mdz: ldm.log shows:   Didn't get the right output from the greeter
<mdz> jammcq: only that?
<jammcq> yep
<jammcq> I changed the 'while True' to 'if True' in ldm, to make it run only once
<mdz> yeah, i need to do something about that error reporting
<mdz> let me upgrade my chroot to current breezy and see if something obvious has broken
<jammcq> k
<jammcq> are you just doing 'apt-get upgrade' ?
<mdz> jammcq: you might try running the greeter by hand with an appropriate DISPLAY
<jammcq> but I don't have an Xserver running
<mdz> surely you have one somewhere on your network ;-)
<jammcq> ah
<jammcq> true enough
<mdz> I'm doing chroot/apt-get dist-upgrade
<jammcq> k
<jammcq> mdz:    ImportError: No module named cairo
<mdz> hmm, I wonder whose bug that is
<mdz> I think probably python-gtk or python-glade
<mdz> jammcq: can you paste the full backtrace?
<jammcq> sure
<mdz> jammcq: meanwhile, installing python-cairo should get it past that
<mdz> I need to do something about the error reporting in ldm; it ought to do something useful with the console
<Lathiat> mjg59: hrm, you should hastle daniels to get glxinfo in breezy
<mjg59> Lathiat: Haha
<no_paste> "jammcq" pasted "gtk greeter traceback" (6 lines) at http://pastebot.geeksinthehood.net:8888/130
<mjg59> Lathiat: I'm running out of daniels favours :)
<jammcq> there ya go
<Lathiat> glxgears would also be a usefull quick test
<Lathiat> mjg59: heh
<mdz> jammcq: python-gtk bug, thanks
<jammcq> mdz: all part of the shake out I guess :)
<mdz> this would have broken quite recently
<mdz> wednesday
<mdz> things should start being less broken in feature freeze
* mjg59 finally gets round to trying to track down ACPI breakage on the Thiknpad 240X
<mdz> 240X?  sounds old
<mjg59> It is
<mjg59> But it's lovely
<mjg59> Only problem is some weird yenta bug. It's probably biting other people too.
<mdz> jammcq: I'm keen to see what the performance is like with your thin client and ssh
<mdz> I was surprised at how fast it was for me, but my laptop is fairly beefy by thin client standards
<Keybuk> mdz: would you have any objection to syncing devscripts 2.9.4 from Debian?
<mdz> Keybuk: depends on what's changed
<Keybuk> added support for "bts block" and "bts unblock"
<mdz> that's all?
<Keybuk> a couple of bug fixes:
<Keybuk>   [ Julian Gilbey ] 
<Keybuk>    * bts: fix forwarded command (Closes: #320703)
<Keybuk>    * debchange: un-html-ise bug titles when using --closes
<Keybuk> 
<Keybuk>    [ Joey Hess ] 
<Keybuk>    * bts: Support new block and unblock commands.
<mdz> no objections
<Keybuk> k, I'll ask elmo
<mdz> Keybuk: you're back home now?
<Keybuk> yup
<Lathiat> mjg59: ehci, uhci, usb 1.1/2, which is which?
<mjg59> ehci - usb2
<mjg59> uhci and ohci are usb1
<\sh> ohci is compaq style usb1 isn't it?
<mjg59> Yes
<mjg59> Also seen in Apples and most add-on ehci cards
<\sh> hmm...lets wrap up my first stuff for laptop testing
<Diablo-D3> hey all
<Diablo-D3> is it me, or is it hard to find a list of what patches are applied to ubuntu's kernel?
<Seveas> Diablo-D3, linux-patch-ubuntu-2.6.10 - Ubuntu patches to Linux 2.6.10
<Lathiat> it is a tad hard, if you apt-get source linux-image-`uname -r` all the patches are in debian/patches
<Seveas> (please note that #ubuntu-devel is not a support channel, #ubuntu is for support)
<Diablo-D3> Seveas: not asking for support ;)
<Diablo-D3> I actually came here to start a discussion on pre-empt and low latency.
<Diablo-D3> but I wanted to see if the ubuntu kernel already had those first
<Diablo-D3> does anyone actually know if it does, btw?
<Seveas> Diablo-D3, grep -i preempt /boot/config-*
<Seveas> CONFIG_PREEMPT=y
<Diablo-D3> /boot/config-2.6.10-5-k7:CONFIG_PREEMPT=y
<Diablo-D3> /boot/config-2.6.12-6-k7:# CONFIG_PREEMPT is not set
<Diablo-D3> so... preempt has been turned off?
<Seveas> no
<Seveas> it's =y
<Diablo-D3> read 2.6.12
<mdke> looks like it's off
<Seveas> ah
* Seveas missed it
<mdke> Diablo-D3, there is a #ubuntu-kernel chan if it helps at all
<Diablo-D3> mdke: hah cool
<Keybuk> elmo: thanks (re: devscripts)
<Diablo-D3> its right to treat ubuntu as a desktop distro, right?
<Diablo-D3> it seems very odd not to have preempt and low latency in a desktop kernel
<Seveas> it's right to treat is as a distro suitable for the desktop, but not *just* as desktop distro
<Diablo-D3> Seveas: yeah, but if they wanted a server distro, wouldnt they just run debian?
<mdke> argh
<mdke> this is not really the place for such discussions Diablo-D3
<Seveas> indeed
<Diablo-D3> there doesnt seem to be a place for such discussions, mdke 
<Seveas> come to #ubuntu or #ubuntu-off-topic for that
<Seveas> #ubuntu-offtopic that is
<Diablo-D3> #ubuntu doesnt work because its full of morons who chatter too much
<Seveas> right, morons huh
<Seveas> good luck getting help/discussion then
<Diablo-D3> Seveas: lets face it, there are too many people asking help in there
<mjg59> Diablo-D3: People asking for help in a user support channel? Goodness.
<Seveas> Diablo-D3, come to #ubuntu-offtopic for this discussion. Not in here.
<Burgundavia> mjg59, ping
<mjg59> Burgundavia: Hi
<Burgundavia> mjg59, https://wiki.ubuntu.com/LaptopTestingTeam/ToshibaTecraA5 <-- first draft of a standard form. This is for my laptop. I will add/change to make it copy&paste operation
<mjg59> Burgundavia: Ok, excellent
<ajmitch_> how much more info will you want?
<ajmitch_> as much useful/relevant info as we can provide?
<Burgundavia> mjg59, if I forgot something, it is an accident, not intentional
<mjg59> Burgundavia: Looks good so far
<Burgundavia> mjg59, matthew east (mdke) is concerned about forcing peole to use one form
* mdke nods
<mjg59> It's going to become difficult to consolidate otherwise
<mdke> as a personal thing i don't like those tables
<mjg59> The aim of this is to provide information to users
<mdke> perhaps the whole thing should be consolidated from the start
<mjg59> Unless that information is presented in a consistent way, it's not very helpful
<Burgundavia> I think I can fix the table widths
<Burgundavia> or make it all one big table
<mdke> LaptopTestingHardware is already there, that could be used
<mjg59> mdke: I'm not that keen on it - the information isn't really fine-grained enough
<mdke> and testers could be encouraged to flesh things out in their own reports
<mjg59> And there's a lot of missing information
<mdke> mjg59, well small changes could be made to that table, but to be honest, if you want a consolidated record, it's going to be very difficult to have a lot of detail
<mdke> there is a limit to how wide a table can be ;)
<mdke> I like the LaptopTestingSpec as a guide
<ajmitch_> mdke: it's a good start, but I think more info can be better
<ajmitch_> but it depends on whether the info will be used for developers, or primarily users
<mdke> here is what I have done, for comparison https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadT43. mjg59 obviously if the decision is taken to change the Spec, that's no problem for me
<mjg59> mdke: By consolitdated I don't mean all visible at once - I mean a comparitive overview and a consistent way of finding out the details
<mdke> ah
<r0bby> is there a list of breezy bugs i can take a look at?
<Burgundavia> if it is for developers, it needs to be a fast read
<r0bby> :P
<mdke> Burgundavia, bugzilla is for developers, what you guys are talking about is for users
<r0bby> (not seeking support
<r0bby> :P
<mjg59> Users don't want to see "This works if you do this". They want to see "this works", and it's our job to make sure that it does
<mdke> agreed
<Diablo-D3> I dont know the context, but I agree with mjg
<Diablo-D3> linux has too much "works if you do this"
<mdke> mjg59, of course testers need to file a bug whenever something doesn't "just work"
<Diablo-D3> it needs more "plain simple works"
<mjg59> mdke: Absolutely
<ajmitch_> right, I thought the main context of the reports we filed was for developers
<mdke> btw tpb doesn't get installed out of the box
<mjg59> ajmitch_: Ah, sorry. It's both
<mdke> >_<
<mjg59> tpb can't be made to work out of the box
<mjg59> Not without rewriting it
<mjg59> It's a screaming security nightmare
<ajmitch_> hopefully the one I get to test will arrive in the next week or two :)
<mdke> mjg59, users don't want to hear that :p
<mjg59> mdke: Yeah. Instead we tell them "this doesn't work" until it does
* mdke nods
<ajmitch_> mjg59: if I get a thinkpad, I'll look at working on it :)
<Diablo-D3> what is tpb?
<mdke> anyhow those tables are hard to read
<mdke> IMHO
<mjg59> Diablo-D3: Thinkpad buttons daemon
<opi> hi guys
<Diablo-D3> ahh
<Diablo-D3> yeah, I can imagine
<Diablo-D3> laptop goodies are Evil (tm)
<Burgundavia> mdke, ajmitch_ mjg59 ok, tried one big table
<mjg59> ajmitch_: Heh. I know what you're getting - I can tell you if you want
<Diablo-D3> I wish there was a generic framework to make everything Just Work (tm)
<mjg59> Diablo-D3: In the long run, hal may help there
<ajmitch_> mjg59: that'd be good
<mdke> Burgundavia, big improvement
<tseng> ajmitch_: no spoilers!
<ajmitch_> tseng: well claire tells us before they're sent, apparantly :)
<mjg59> ajmitch_: Ought to be a Dell 510m
<Diablo-D3> mjg59: thats what people I know are hoping for
<mdke> Burgundavia, i still personally prefer <h>s and <li>s tho
<Diablo-D3> mjg59: but theres lots of other stuff that doesnt just work
<tseng> ajmitch_: oh. i need to find a fax machine, claire couldnt verify my clearsign for some reason
<opi> tseng: don't tell me :)
<Diablo-D3> mjg59: like, non-usbmsd cameras (and such) dont Just Work (tm)
<ajmitch_> tseng: right, I scanned & gpg-signed
<opi> tseng: I don't even know how to operate one ;)
<ajmitch_> mjg59: thanks
<tseng> opi: /me barely
<opi> ajmitch_: and it worked?
<mjg59> Diablo-D3: Stuff that plugs into the serial port is immense pain
<Diablo-D3> mjg59: I meant the usb ones that arent msd
<Burgundavia> tseng, opi that is why the local office supply place is great. You say fax and here is the number
<opi> tseng: well, there's allways time to learn new tricks ;>
<mjg59> Hrm. USB cameras ought to work.
<opi> Burgundavia: that's my plan ;)
<Diablo-D3> usb cameras that are MSD do work
<mjg59> libgphoto is supposed to deal automatically
<mdke> mjg59, did you see #13390 btw? looks like most of the thinkpad people have had it
<mjg59> mdke: Yeah, I had that when I got mine a few years ago
<Diablo-D3> mjg59: gphoto integration works now?
<mjg59> mdke: I think I may know a couple of ways around it
<mjg59> Diablo-D3: It's supposed to, but I have no hardware to test it with
<Diablo-D3> mjg59: ubuntu may be the first distro ever to have it working =/
<mdke> mjg59, that would be cool, its a fair blocker
<opi> btw: If I've submitted a bug to Malone
<Diablo-D3> the current redhat and mandrake and whatever else is popular releases completely fail here
<Burgundavia> mjg59, if you want to edit my page, go ahead
<mdke> mjg59, thank god I made rescue disks. I'm already on my second restore to factory settings
<opi> is is someone from MOTU noticed if the package has no MOTU-owner?
<ajmitch_> opi: for bugs?
<tseng> motu doesnt own every package
<opi> ajmitch_: yes
<Burgundavia> mjg59, once we are happy with the design, I will copy over to generic page and announce it
<opi> tseng: I know, that's why I'm asking
<ajmitch_> opi: no, they have to be assigned to MOTU for us to notice, or we watch #ubuntu-bugs
<tseng> oh, i see what you mean
<opi> tseng: what if a package is just imported
<Diablo-D3> (and yes, comparing to redhat and mandrake and whatever is important, if they get something right and Ubuntu doesnt, thats a bad thing)
<tseng> Burgundavia likes to assign those ones to the spam bin
<mjg59> Burgundavia: Excellent
<tseng> send to all motu
<Diablo-D3> of course, ubuntu gets so many things right <3
* ajmitch_ will bbl, work meeting
<mjg59> There should be a laptop-testing list next week
<mdke> mjg59, you think the tables work for readability? I still don't like em
<opi> ajmitch_: OK then, I'll try to fix it myself and I'll put it up to review
<Diablo-D3> mjg59: how do I join the laptop-testing team?
<mjg59> Diablo-D3: I'll post stuff once the list exists
<mdke> Diablo-D3, visit the wiki page
<Diablo-D3> mjg59: I have a popular laptop, a presario 7xx series laptop
<mjg59> mdke: I think they work for developer-level readability
<Diablo-D3> amd duron, via chip, twisterk video chip
<mdke> mjg59, if the testers are filing bugs, IMHO the wiki page is mainly for users
<Diablo-D3> quite a lot of these were manufactured, and they're quite unsupported at times =/
<Diablo-D3> like, I /still/ cant get the backlight to turn off, and I've been trying for a year now to do that
<opi> my Tecra8000 works almost flawless :)
<mjg59> mdke: The information from those pages will be grabbe and reformatted for end-users
<opi> you only need to kick ISA-sound a bit
<Diablo-D3> and it supposibly has a thermal chip, but its only supported by Compaq's own drivers
<Diablo-D3> and its not connected through the via686a chip, and the lm-sensors project has basically refused to support it
<mdke> mjg59, ok whatever you guys decide is fine, as long as a final spec is produced and we don't have to keep reformatting our reports
<opi> Diablo-D3: pita
<mjg59> mdke: What does fdisk claim the partition type of your recovery partition is?
<Diablo-D3> opi: very.
<mjg59> mdke: Ok, no problem
<Diablo-D3> I normally wouldnt care, but this laptop series has severe overheating issues
<Diablo-D3> and I mean /severe/
<Burgundavia> mjg59, how do we want to handle multiple people with the same laptop? should they just edit the same page?
<mdke> mjg59, if you post on the bug report how I can find out, I'll do it next time I reinstall Ubuntu (i've just restored to factory settings)
<Diablo-D3> the only way Ive found to fix it is to just have it run at the lowest dynamic cpu speed
<mjg59> mdke: Ok, thanks
<Diablo-D3> (cpufreq for the win)
<Diablo-D3> man, we need a #ubuntu-laptops
<Diablo-D3> or something
<opi> #laptops'r'us
<mdke> --> bed
<Diablo-D3> laptops are such pains in the ass
<Diablo-D3> why cant someone just make a totally standards compliant laptop
<Diablo-D3> one that works out of the box with a number of popular distros
<Diablo-D3> like, you know what I hate? having to manually install and setup the synaptic driver for the touchpad
<opi> Diablo-D3: too expensive to play with all the parts
<Diablo-D3> opi: yeah, but why the hell did compaq /make their own thermal chip/
<opi> no idea
<Diablo-D3> instead of using some popular chip that plugs into the via686a chipset
<Burgundavia> mjg59, what do you think about making it one big table for both releases?
<Diablo-D3> you know, /like everyone else did/
<Diablo-D3> I'd strangle Compaq, but someone beat me to it.
<opi> I'm lucky with Toshiba, with apcitool (I've packaged that: badly;-) I can even turn fan on/off and hibernate it ;)
<Diablo-D3> heh
<Diablo-D3> the fan is automatic on mine
<Diablo-D3> it ramps up the hotter the laptop gets
<opi> I think that people who did a electronic for this laptop, are/was brianless
<Diablo-D3> thats another thing, btw
<opi> imagine: fan starts at (let say) 40c
<Diablo-D3> lm-sensors is not automatically setup on any distro
<grover> the mfgrs need to be held accountable for bad thermal designs
<opi> fan kicks in, temp is going down to 39c
<opi> fan stops
<opi> it takes ~15 secunds to get to the 40c level again
<Diablo-D3> grover: no shit, I've heard stories where presario 700 series laptops literally melted
<opi> fan starts
<Burgundavia> opi, Diablo-D3 this discussion is probably best taken elsewhere
<opi> Burgundavia: right
<Diablo-D3> Burgundavia: I said that earlier
<Diablo-D3> Burgundavia: we need an #ubuntu-laptop
<opi> Diablo-D3: I'm there ;)
<mxpxpod> Diablo-D3 and opi: same here
<mjg59> mdke: Ok, I've updated the bug
<Diablo-D3> yay
<Diablo-D3> #ubuntu-laptop is open for buisness
<Burgundavia> mjg59, please take at look at  https://wiki.ubuntu.com/LaptopTestingTeam/ToshibaTecraA5 again
<mjg59> Burgundavia: Ok, that works nicely for me
<Burgundavia> mjg59, mdke suggested it
<Burgundavia> mjg59, for the function keys/special keys, do you want a keycode as well?
<mjg59> Burgundavia: If they generate one. Note that Breezy has much more support by default.
<Burgundavia> mjg59, ok
<mpt> oh, snap
* mpt was just editing the laptop pages
<Burgundavia> mpt, go ahead
<mpt> Is there a doc somewhere on how to install under a chroot?
<mpt> (is that even a useful testable configuration?)
* mpt doesn't even know what a chroot is
<mpt> Burgundavia: https://wiki.ubuntu.com/LaptopTesting updated
<Burgundavia> thanks
<mpt> Now making the https://wiki.ubuntu.com/LaptopTestingHardware table narrower
<Burgundavia> mjg59, what do we want to do with https://wiki.ubuntu.com/LaptopTestingHardware
<Burgundavia> mjg59, it is really that useful?
<mjg59> Burgundavia: Leave it for now, I'll worry about it later
<Burgundavia> mjg59, ok
<mpt> ah, good point
<mpt> Why are there many more rows in LaptopTestingHardware than there are subpages of LaptopTestingTeam?
<Burgundavia> mpt, shrink the table down
<Burgundavia> mpt, Hardware is old
<Burgundavia> the subpages are new and what we are going to be using in the future
<mpt> oh
<mpt> So should LaptopTestingHardware be nuked?
<mpt> (I didn't like that name anyway...)
<Burgundavia> no
<Burgundavia> just mention at the top that it is deprecated
<mpt> That Lakin guy just added himself to LaptopTestingHardware
<mpt> Lakin Wecker
<Burgundavia> yes
<Burgundavia> not a problem
* mpt hits the big red Cancel button
#ubuntu-devel 2005-08-20
<Burgundavia> what should I call the framework page to be copied?
<mpt> Something that makes it appear in the "Page templates:" list
<mpt> I don't know how that works
<mpt> maybe it needs to end in "Template"?
<mpt> LaptopTestingTemplate?
<Burgundavia> yes
<mpt> Is there an ETA on cdimage.ubuntu.com returning to life?
<tseng> works for me
<Burgundavia> mpt, can you copyedit the instructions at the top of LaptopTestingSpec ?
<mpt> whoa, thanks, tseng, you must have unclogged something
<tseng> mpt: hah i downloaded an iso a few moments ago
* mpt will one day have an Internet connection that lets him download an ISO in "a few moments"
<tseng> it was about 20
<mpt> That's about 32 MB/moment
<Burgundavia> shall we merge LaptopTesting and LaptopTestingSpec ?
<ajmitch_> mpt: I'd say that 'one day' won't be in NZ then :)
<mpt> "Yes, that's it", said the Hatter with a sigh: "it's always download time, and we've no time to burn the images between moments."
<mpt> Burgundavia: I was just about to suggest incorporating it into the LaptopTestingTemplate, with people deleting instructions as they fill stuff out, but I don't know how feasible that would be
<Burgundavia> Template is going to be something they are going to copy over
<Burgundavia> nothing more
<Burgundavia> probably better to have them seperated
<mpt> (see for example the intro of https://wiki.launchpad.canonical.com/LaunchpadProposalTemplate)
<Burgundavia> hmm
<mpt> (though those instructions can get away with being much more concise)
<mpt> yeah, separate pages is probably better
<Burgundavia> we need two pages
<Burgundavia> one for the instructions
<Burgundavia> and one for the table to be copied
<Burgundavia> mpt, you want to do that work?
<mpt> no, "fix laptop pages" wasn't on my list of things to do today
<mpt> I got distracted
<Burgundavia> mpt, ok
<Burgundavia> can do
<mpt> sorry
* mpt gets back to Ubuntu Help
<Burgundavia> np
<lakin> should I not have added myself to the LaptopTestingHardware?
<Burgundavia> lakin, see the spec page now
<Burgundavia> lakin, https://wiki.ubuntu.com/LaptopTesting
<Burgundavia> lakin, the template is currently being worked on
<lakin> k, brb phone
<lakin> Burgundavia, cool, these were the instructions I was looking for all morning. :)
<jdub> oh man
<jdub> first time in ages
<jdub> i have no uninstallable packages!
<jdub> yayyayayaya!
<mjg59> Heh
<jdub> whoa, and full installability of nvidia-glx on my desktop
<jdub> bongers!
<ajmitch_> jdub: yeah, things are looking up, even universe isn't horribly broken all over :)
<jdub> hrm
<jdub> and meanwhile, i can't do the same on my laptop
<davyd> can someone recompile xscreensaver to be Xinerama aware
<jdub> hrm
<davyd> ?
<davyd> that would be really rad
<jdub> hrm, dev packages
<Lathiat> davyd: try gnome-screensaver
<Lathiat> with the extrag oodness fo waiting 5 seconds for the password box to appear
<Lathiat> maybe 25 if your disk is being chewed by something
<davyd> Lathiat: yeah, I hear that's godawful slow
<Lathiat> i wish xscreensaver would look pretty again, tho
<davyd> is that because it's starting a process when you hit the button?
<`anthony> jdub: next thing you know, X will work.
<Lathiat> davyd: yeh, possibly with gnome deps too not just gtk (gnome_program_init vs gtk_init sucks)
<Lathiat> or it did a few months back anyway
<davyd> I could understand that
<Lathiat> like, several time suckier
<jdub> x works!
<ajmitch_> jdub: this from a nice fresh install?
<jdub> dunno
<jdub> haven't tried one of those yet
* jdub boggles
<jdub> xkb works on my desktop
<Lathiat> heh
<Lathiat> i've had working X for a few days now :)
<fabbione> morning
<pitti> Good morning
<daniels> morning pitti
<fabbione> hey pitti
<fabbione> hey kid
<daniels> morning fabbione
<pitti> Hi fabbione, back to work life? :-) How is your house now?
<fabbione> pitti: yeah i am back...
<fabbione> pitti: a bit better than before.. we almost managed to finish the garden room
<pitti> garden *room*? interesting
<fabbione> we had way more problems than expected with rotten wood and crappy work that has done before...
<fabbione> pitti: sort of porch...
<fabbione> i only need to lay the new floor and i am done
<fabbione> have to wait for my wife to finish the cement borders to avoid water to come in
<fabbione> otherwise the new floor would be damaged
<fabbione> pitti: i got your 3 tons of emails....
<fabbione> pitti: did you find anybody to work on it?
<pitti> fabbione: not yet... everybody is just so busy
<fabbione> MEH
<pitti> fabbione: I could ask Herbert if he could do Hoary as well
<fabbione> pitti: let me see if i can get BenC to do it... but he doesn't know the kernel build system yet. i am afraid
<fabbione> pitti: i definetely have no time for it..
<fabbione> i mean, i will check breezy.. but that's all i can do atm
<pitti> Hi JaneW 
<fabbione> morning JaneW
<JaneW> morning fabbione & pitti
<pitti> daniels: btw, did you get my email with the xorg CANs the other day? Can you please add them to the changelog in the next update?
<doko_> good morning
<fabbione> hey doko
<doko> fabbione: http://sourceware.org/ml/binutils/2005-08/msg00190.html
<mantiena> hi mdz 
<fabbione> doko: interesting :))))
<fabbione> doko: i am sure we can wait for them to apply and import the fix later
<fabbione> there are not that many pkgs FTBFS due to that
<sivang> Morning all
<pitti> Hi sivang 
<sivang> Hi pitti 
<mantiena> anyone can tell me where I can find newest ubuntu-express sources ?
<mantiena> at archive.ubuntu.com exist only old 0.3 version :(
<pitti> Hi marilize 
<marilize> pitti: Hi
<bob2> mantiena: didn't they include a url in the email to -devel?
<mantiena> bob2, source files doesn't exist at url I've found at http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/009560.html
<mantiena> I can download only .deb packages :(
<Lathiat> Hows that going anyway
<Lathiat> goign to be ready?
<bob2> er, I hope they're not using any GPL code in those packages then
<bob2> GPL violations are as uncool as getting your hand stuck in the blender
<Lathiat> <1123719929.4952.64.camel@localhost.localdomain>
<Lathiat> look for that message
<Lathiat> (has the sources)
<Lathiat> Date: Thu, 11 Aug 2005 02:25:29 +0200
<fabbione> infinity, daniels: ping?
<mantiena> Lathiat, thanks
<Lathiat> mantiena: nps
<infinity> fabbione : pong.
<fabbione> infinity: i still get the:
<fabbione> dpkg: error processing /opt/sparcbuildd/chroots/chroot-breezy/var/cache/apt/archives/libglu1-mesa-dev_6.2.1-5ubuntu5_sparc.deb (--unpack):
<fabbione>  trying to overwrite `/usr/include/GL/glu.h', which is also in package x11proto-gl-dev
<fabbione> has it been fixed and my cache is "dirty"? or is it still pending?
<infinity> x11proto-gl-dev Replaces libglu1-mesa-dev, so dpkg is supposed to take care of that automagically.
<infinity> Unless the dpkg in your base system doesn't handle back-replaces properly.
<fabbione> it's the latest one....
<infinity> What is your base system running?
<infinity> Both hoary (well, hoary-updates) and breezy handle this case correctly.
<fabbione> Version: 1.13.10ubuntu1
<fabbione> i think it's the latest one...
<\sh> ahhh...fabbione the master of the kernel
<fabbione> infinity
<mantiena> Lathiat, you are talking about this email http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/009560.html ?
<fabbione> infinity: but if you say it's working on our buildd, i will check mine later on....
<\sh> fabbione: any objections to include an ethernet driver into kernel 2.6.12? The Marvell Yukon driver in the actual kernel is not compatible with the latest marvell yukon nics..
<Lathiat> nope
<Lathiat> my message was a few days later
<fabbione> jamesh: meh.. a bit more background would be helpful.. 
<fabbione> \sh <-
<infinity> fabbione : You run breezy in the base system?
<\sh> fabbione: ok..laptop testing...toshiba portege r200 :) just installed it via pxe and the driver wasn't working...
<fabbione> infinity: i run breezy in the chroot... of course...
<Lathiat> look in the whole thread
<Lathiat> theres a few
<\sh> fabbione: I just read some pages about installing linux on this r200 and I found a hint to actual drivers for the marvell yukon network device.
<fabbione> \sh do you have a reference to a patch? are you sure it's not only missing PCI-IDS?
<infinity> fabbione : Yes, but the BASE SYSTEM.  What does it run?
<infinity> fabbione : sbuild uses apt-get and dpkg from the base system.
<fabbione> infinity
<fabbione> infinity: ahhhh sid...
<fabbione> infinity: an old version of sid
<infinity> Upgrade.
<\sh> fabbione: I checked...u can read as well: http://glozer.net/dynabook/dynabook.html
<fabbione> i guess i have to :)
<infinity> (Then you'll get segfaults instead... Unless you build the breezy dpkg on sid and install it)
<fabbione> \sh : ah ok.. no that patch won't go in
<fabbione> the driver from Marvell is sick
<fabbione> and the code has been severely rejected by upstream
<\sh> fabbione: actual driver source is on http://www.syskonnect.com/syskonnect/support/driver/d0102_driver.html
<mantiena> Lathiat, could you simply paste the url here ?
<Lathiat> mantiena: theres a bunch, just click the thread link at th ebottom fo that page
<Lathiat> mantiena: and get all the ones by the same person under that email
<mantiena> Lathiat, I need only source url
<\sh> fabbione: why is it sick? 
<Lathiat> mantiena: i told you, theres like 5 of them
<Lathiat> mantiena: sort through them 
<\sh> fabbione: the patch is working nicely and the driver is running smooth
<fabbione> \sh too much crappy code
<Lathiat> fabbione: shame
<Lathiat> it works tho ;p
<fabbione> \sh yes i know the code works, but it's unmaintanable
<Lathiat> really painful on the r200 as it has no cd drive so you need to netinstall
<\sh> fabbione: and the patch maintainer doesn't want to change this code? that's really bad, cause the work getting linux installed on this laptop is really to hard for the normal user
<Lathiat> \sh: what about the wireless driver
<\sh> i mean, even with the driver inside the kernel, and no external cd/dvd
<\sh> Lathiat: atheros...works out of the box
<Lathiat> cant pxe off it tho?
<\sh> Lathiat: problem is only, i don't have a wlan at home
<mantiena> Lathiat, sorry, but I did't find working url of newest ubuntu-express sources :(
<\sh> Lathiat: i just hacked myself into the neighbours wlan to test the connectivity and the connection
<Lathiat> heh
<\sh> Lathiat: and my pcmcia zyxel wlan card is not supported
<Lathiat> mantiena: http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/thread.html#9474
<Lathiat> mantiena: look at all the posts by "Javier Carranza"
<\sh> Lathiat: but setting up pxe for the normal user is even to hard or we are building a "ubuntu install pxe server" ;)
<Lathiat> \sh: you know what would rock
<Lathiat> \sh: a mode of the installer to start a pxe boot
<Lathiat> with a preseeded mirror config
<Lathiat> dhcp server etc
<\sh> Lathiat: u need a running apache for this...or we use the light-httpd
<Lathiat> \sh: thttpd would work
<Lathiat> or nfs
<\sh> no nfs
<Lathiat> why not nfs?
<Lathiat> so youd need udebs of dhcpd, atftpd, thttpd
<\sh> to much of a hassle...a small httpd is good enough to grab the packages from the cd
<Lathiat> and theyd need to be in main
<Lathiat> hrm
<\sh> ah...for that I have to play with d-i grmpf
<Lathiat> might try figure out how to do that
<\sh> but...the installer kernel doesn't support wifi at all...the madwifi drivers i didn't see while I was changing the initrd
<Lathiat> the insatller does wifi
<Lathiat> perhaps not for atheros
<Treenaks> \sh: the installer does weird wifi.. my prism54 works fine
<\sh> Lathiat: yes...for atheros u need only this madwifi
<Lathiat> my ipw2200 works
<\sh> k.k.k. what do i need for my hardware wishlist: wifi router, pcmcia wifi card, supported by kernel for my other laptop, usb-dvdrom, so i can install windows again on this little r200 bitch, red wine from stellenbosh and a lot of time to play around with d-i
<Lathiat> heh
<sivang> jamesh: I'd like to ask a few things about the translation domain, better be doing this here for benefit of others 
<jamesh> okay
<sivang> jamesh: could you please explain the misplace of the translation domain ? 
<jamesh> sivang: with the gettext system, there are two functions used to set up the translation domains
<\sh> fabbione: another question, cause I was fighting with the installer kernel to find the correct settings for compiling the module etc. which sourcepackage are u using for the installer kernel? or better to say, where can I find the sources for the installer kernel+layout and source package for the installer initrd
<jamesh> sivang: bindtextdomain() tells gettext that translations for a particular domain are stored in a particular directory
<jamesh> sivang: and textdomain() sets the default translation domain
<jamesh> sivang: so gettext("foo") will look up "foo" in the default translation domain
<jamesh> sivang: if you are writing a library, you don't want to depend on the default translation domain, since the application usually sets it
<jamesh> so there is a second API dgettext(DOMAIN, "foo"), which lets you specify which translation domain to translate the string in
<jamesh> bonobo_ui_component_set_translate() seems to translate the strings in the default translation domain, which is not appropriate for a library
<Lathiat> \sh: apt-get source linux-image-2.6.12-6-686 ?
<jamesh> since it would require that translations for the library's strings appear in the domains of all apps that use the library
<\sh> Lathiat: does it provide the installer initrd as well...cause the layout of the resulting initrd is different
<Lathiat> no idea
<Lathiat> that might be part of d-i
<crispin> mdz: should bug 13457 be closed now ? (its the python-gtk needs to depend on python-cairo)
<Lathiat> hrm one of archive.ubuntu.com's servers has died again
<pitti> moin mvo
<mvo> hey pitti! good morning all
<jamesh> sivang: does that explain the problem?
<sivang> jamesh: yeah, well, actually, I tried to find out about that exact feature of bonobo_ui_component_set_translate - it's corrolation with gettext, but the documentation was so sparse...So, this bonobo api functions triggers translation inside the specific app translation domain? were you able to find out if it also has any part in constructing the "physical" GUI ?
<robitaille> pitti: are we supposed to assign to you universe security bugs in Malone? https://launchpad.net/malone/bugs/1176
<jamesh> sivang: bonobo_ui_component_set_translate() is essentially bonobo_ui_component_set(), with an extra step that scans the XML fragment after parsing, and looks for attributes starting with an underscore
<pitti> robitaille: I saw the assignments, but I probably won't have time for them anytime soon
<pitti> CC'ing would be fine
<jamesh> sivang: it then sets an associated non-underscore attribute with gettext(underscore-attribute-value), and then loads the UI
<pitti> robitaille:  so if sb attaches a debdiff, I can review it
<jamesh> sivang: so that would translate in the app's translation domain rather than the library's one
<robitaille> pitti. ok.
<mantiena> Lathiat, thank you very much
<Lathiat> nps
<mdz> crispin: yes, I wasn't aware of it and independently discovered/fixed the same bug
<tepsipakki> kamion: now I got past the partman-phase, but after reboot the network is not set up
<\sh> mvo: apt-file is not installable ... fyi
<jdub> pitti: does the usb audio pluggy stuff do anything with input-only devices?
<pitti> jdub: not right now
<jdub> ok, ta :)
<pitti> jdub: would be easy enough to do so, should it?
<jdub> guess so
<jdub> btw, audio-in device is shown in the default soundcard dropdown
<mvo> \sh: ok, thanks
<mantiena> mdz, when are you will upload new ubuntu-express version to ubuntu archive ?
<mantiena> mvo, hi
<\sh> mvo: one of the perl libs is b0rked..
<mvo> \sh: libapt-perl needs to be rebuild
<mvo> mantiena: hey mantiena 
<mantiena> mvo, about 7 months ago you promised to fix ubuntu bug #2706 ;)
<\sh> *grmpf*
<ajmitch_> \sh: problems still?
<mvo> mantiena: hrm, yes. I have a pretty big patch for apt that fixes that. not yet accepted unfortunately
<mantiena> :(
<\sh> ajmitch_: suspend activated...
<mantiena> mvo, are there any hope to fix this bug in breezy ?
<ajmitch_> \sh: resume didn't work tho?
<mvo> mantiena: no :(
<ajmitch_> hi mvo :)
<\sh> ajmitch_: i'm checking...:)
<mvo> hey ajmitch_!
<\sh> hmmmm
<fabbione> who is the actual contact point for backports?
<fabbione> actually.. where is he?
<\sh> mez
<bob2> Mez, apparently
<fabbione> does he have a bugzilla email?
<fabbione> clearly my request of NOT backporting the kernel has been overruled..
<fabbione> and i sort of would like to reassign some stuff to him
<\sh> martin@sourceguru.net ?
<sivang> jamesh: ok, that's all clear now. Did you read _set_translate's code to figure that out?
<jamesh> sivang: yeah.  It's also apparent from the fact that _set_translate() doesn't provide a way to tell it what translation domain to use
<sivang> jamesh: I see. Now, where did you modify my code to reset the current working translation domain rather then the default set by a respective client app ?
<jamesh> sivang: I changed the part where the XML is constructed
<jamesh> sivang: instead of doing _label="untranslated-string", I generate it as label="translated-string"
<sivang> jamesh: as a side note, what does launchpad-integration.in is used for ? (is it used by python dist-utiles?)
<jamesh> sivang: creates the launchpad-integration script (put in $prefix/bin)
<sivang> jamesh: I also noticed you remove the support for adding tootips, I guess they are redundent?
<jamesh> sivang: menu items don't need tooltips
<ogra> hmm, why do i have to select the app if i choos to file a bug from the help menu ? 
<sivang> jamesh: ok, cool
<sivang> ogra: is it main?
<sivang> ogra: (support is there for stuff mostly in main, and in the desktop seed)
<ogra> its evo 
<sivang> ogra: for others, you need to use the picker
<sivang> ogra: evo is not yet done, or at least so I know. I need to ask seb about it when he goes online
<sivang> ogra: http://wiki.ubuntu.com/LaunchpadIntegration for ready apps
<ogra> ah, ok... its a matter o the app... i thought launchpad-integration could just grab the app name from the wnck list
<mvo> sivang: IIRC seb is not going to be around today. it's a public holiday in france
<\sh> hmmm...bluetooth only via patch...the chipset is recognized...but enabling bluetooth is only possible via acpi and for this, there is another patch which isn't included in kernel upstream and will never make it
<sivang> mvo: ah ok, well, then I'll wait for tommorow :) btw, what sudo changes did you add to lpint ? (I saw it on the baz log)
<mvo> sivang: some apps (gnome-system-tools, synaptic, ...) run from sudo and they drop root now before firing up mozilla
<sivang> mvo: that's a good behavior, no? (why should mozilla be fired up with privs)
<sivang> mvo: ah oops :)
<sivang> mvo: just read it carefully now
<mvo> :)
<pitti> daniels: hm, a lot of apps don't like restarts of dbus. What do you think about not restarting it on package upgrades?
<daniels> pitti: i've just been having this argument with gnome folk for a while now
<daniels> pitti: i'm still pretty convinced that we should be restarting it
<pitti> daniels: me too, on the utopia list
<daniels> pitti: battery-applet is getting changed to deal with it
<daniels> and we have the g-v-m patch
<daniels> oh, I should probably get on utopia-list
<pitti> daniels: I can probably fix g-v-m harder
<daniels> cool :)
<pitti> daniels: and I think mvo applied a patch for update-notifier
<\sh> hmmm
<daniels> cool
<mvo> yes, update-notifier should survive it too
<sivang> ogra: do you have the launchpad integration items in evo's help menu?
<ogra> i have "file a bug" there
<sivang> ogra: what do you get when you click it?
<ogra> a bug buddy like wizard...
<sivang> jamesh: one last thing, in my original bonobo lib, I had PKG_CHECK_MODULES(BONOBO, libbonoboui-2.0 >= 2.0 launchpad-integration) , since I was at the POV of depending on the package. How can a package depend on itself as in the new configure.ac ? :)
<sivang> ogra: that's the original evo item
<sivang> ogra: so evo, just hadn't been patched yet
<ogra> oh... i never recognized it :)
<sivang> ogra: hehe :) if you find any misbehavior in the worked apps, please let me know :)
<ogra> i'l do :)
<sivang> jamesh: (I take it that the rest of setup in the configure.ac file are just linearally incremnetal as the number of files you need to handle gets bigger)
<doko> daniels: did libxp-dev vanish, is there a replacement for the package?
<daniels> doko: a) yes, b) no
<pitti> mvo: I just fixed the reconnection patch of g-v-m; did you use the same code?
<mvo> pitti: yes, could you send the patch to me? 
<sivang> can anyone tell me how can I see annotate by a file name in baz?
<siretart> fabbione: around?
<pitti> sivang: annotate does not seem to work at all for me...
<pitti> sivang: oh, wait, it does
<BBB> pitti, ping
<pitti> Hi BBB
<BBB> hello
<pitti> sivang: baz annotate ./file works fine
<BBB> how hard would it be to get nl (dutch) translations on the default live-CD so we can order a whole bunch of those and hand them out for free?
<fabbione> siretart: yes
<BBB> (we'd like to hand them out at the biggest computer conference in the netherlands, we already have a stand, so we're now looking for PR material)
<daniels> BBB: see http://wiki.ubuntu.com/LiveCDCustomizationHowTo
<daniels> might be LiveCd instead of LiveCD
<siretart> fabbione: would you/ubuntu be interested in sparc hardware for buildds? A friend would like to offer 2 Sparc AXi with hosting
<daniels> BBB: but you just want to follow those instructions and install language-pack-nl and all its associated packages
<fabbione> siretart: yup :)
<daniels> what's the problem with sparc at the moment; is it mainly toolchain?
<fabbione> siretart: but it highly depends on what kind of access i can get to them
<fabbione> daniels: binutils, but there is a patch already around
<siretart> fabbione: I think they have 300mhz and about 30gb harddisk, we would setup it for you with whatever os you want and provide you an root account on that
<fabbione> siretart: perfect :)
<fabbione> siretart: that's all i wanted to know :)
<BBB> daniels, that method has one problem: we'd rather not produce the CDs ourselves, since they cost (a lot of) money, which we don't have. :)
<pitti> BBB: it's only on the powerpc and ia64 live CDs ATM because of space restrictions
<siretart> fabbione: if it is impossible to install hoary on that sparc, I would install that. otherwise I'd install sarge/sparc
<fabbione> siretart: given that we can't install ubuntu yet, a minimal debian sid will do
<fabbione> siretart: unfortunatly we need sid
<BBB> pitti, so how tough will it be to get you guys to make those CDs for us? :) impossible? or close-to-impossible (good enough for me :) )?
<fabbione> so you can install sarge and i can take care of upgrading. You will only need to keep an eye on it for the kernel upgrade
<fabbione> siretart: it is important for me that the 2 sparcs can sends email out and ssh in/out
<fabbione> + download via http
<BBB> I'm ok with making the ISO, but we cannot produce the CDs, it simply costs too much... ubuntu ships the live-CDs for free to interested parties, which is why we're so interested in it
<pitti> BBB: make == press? or make == generate image? the former is probably close-to-impossible (please ask mako and/or marilize), the latter is easy and you can do it yourself
<BBB> press
<siretart> fabbione: ok. one machine is at home (at me). will install sarge and give it joerg brendel (http://brendel-it.de).
<pitti> BBB: I'm not involved in the pressing process, but mako and marilize are
<siretart> fabbione: the other machine is at another frind, I'll arrange the installation
<fabbione> siretart: ok... thanks
<siretart> mail/ssh should be no problem
<fabbione> siretart: let me know when you are done so that i can start setting them up
<fabbione> speaking of which....
<siretart> fabbione: he uses ubuntu for hosting, so that his way of saying 'thanks' :)
<fabbione> maswan: ping?
<fabbione> siretart: ROCKING!
<BBB> pitti, ok, I'll bug them then, thnx so far :)
<BBB> mako, ping
<BBB> (step #2 :) )
<pitti> BBB: mako is in the USA and is probably asleep
<BBB> ok, I'll wait ~4 hrs then
<BBB> thnx again ;)
<siretart> fabbione: any preferences about partitioning?
<fabbione> siretart: hmm the 30GB are on one disk, right?
<torkel> fabbione: maswan is on vacation, I'm not sure how often he is here
<fabbione> torkel: ah ok.. are you one of the admins at umu.se?
<torkel> fabbione: well, at hpc2n.umu.se
<fabbione> siretart: if it's on one disk, than make swap at the end of the disk (2xRAM should do) and one big partition at the beginning
<torkel> fabbione: but I have another of the ACC guys in the room nextdoor
<fabbione> torkel: acc.umu.se is part of that?
<fabbione> torkel: oh i see.. well there is no rush.. 
<fabbione> dunno if they know about buttercup :)
<siretart> fabbione: OK
<fabbione> siretart: perfect
<siretart> I hope the machines will get online about end of this week
<fabbione> torkel: i will just wait for maswan to be back :)
<torkel> fabbione: nope. We (HPC2N) is the supercomputing center here. ACC is the computer club. maswan works at HPC2N though...
<fabbione> siretart: i have no rush.. it always take sometimes to put buildd's online anyway
<fabbione> torkel: ok.. don't worry.. i will just wait for maswan to be back :)
<torkel> fabbione: buttercup down? 
<fabbione> torkel: yeps...
<fabbione> it mostlikely need a powercycle
<fabbione> the kernel on that box keeps hanging hard
<torkel> fabbione: I poked the guy next door. He should take a look at it
<fabbione> torkel: thanks
<\sh> doko: ping
<\sh> fabbione: can u give me a hint on the initrd we are using for the installation media cds?
<fabbione> \sh the initrd is generated by debian-installer. i don't know all the details about it
<\sh> fabbione: so which package? apt-get source debian-installer? 
<fabbione> yes
<ogra> fabbione, laptop mission ? http://www.nextcomputing.com/powersparc.htm
<fabbione> ogra: ehehhe i have no such hardware
<ogra> hey, youre supposed to, youre the sparc guy here :)
<fabbione> ogra: not anymore.. we have Sparc God BenC now :)
<ogra> oh, true....
<ogra> infinity, around ? 
<infinity> No.
<ogra> heh
<doko> \sh: pong
<\sh> doko: isdnutils...libcapi20-dev depends on libcapi20-2 but from what i see isdnutils is generating libcapi20-3...some things are waiting as well for libcapi20-2 in the buildds and r not buildable
<ogra> infinity, somehow my xaos package is stuck on i386.... could you have a look whats keeping it stuck if youre around again ? 
<doko> ohh crap, missed that one ...
<infinity> ogra : Unstuck.
<ogra> (i suspect there is an older build)
<ogra> ah, thanks :)
<doko> \sh: sorry, no, which version?
<\sh> Version: 1:3.7.2005-07-09-2ubuntu1
<\sh> I tried to install libcapi20-dev...and it wants to have libcapi20-2 as dependency
<\sh> another one which is waiting for libcapi20-2 is bayonne
<\sh> (according to http://people.ubuntu.com/~lamont/buildLogs/Lists/breezy.all.i386)
<doko> according to the build logs, this version was never built ...
<\sh> doko: hmmm?!
<\sh> the source is in the archive..
<\sh> and all build attempts failed on the 15th
<daniels> seb128: morning
<daniels> seb128: the latest xorg changelog might be interesting
<seb128> hi daniels
<seb128> daniels: the "* Correct DefaultFontPath." part?
<daniels> yeah
<seb128> cool
<ploum> Hello
<ploum> is there any bugzilla admin here ?
<ajmitch_> ploum: ping ogra about it :)
<ogra> ajmitch_, huh ?
<ajmitch_> ogra: editbugs for ploum 
<rob^> is there a page somewhere listing the size of the different repos?
<ogra> ploum, have you read https://wiki.ubuntu.com/HelpingWithBugs ?
<ploum> ogra, yes. seb128 asked that someone grant me editbugs privilege
<ogra> ploum, you bugzilla login? 
<ploum> ploum@fritalk.com
<ogra> your even
<ploum> even ?
* Mithrandir grumbles at anna-install
<ogra> ploum, done, user the power wise ;) 
<ploum> ogra, thank you :-)
<ploum> have a nice day
<ogra> :)
<sivang> seb128: Hey :) 'sup? how many apps did you reach FF with?
<fabbione> torkel: thanks! buttercup is up again
<fabbione> torkel: mind to thanks the other guy for me?
<seaLne> his is there a problem with the bittorrent tracker?:
<torkel> fabbione: sure, will do...
<doko> ogra: do you handle the inclusion reports for edubuntu/gcompris?
<ogra> yep
<ogra> pitti, xaos is fixed... how do we handle this? do i notify you here or do i just add it to the report?
<pitti> ogra: add it to the report, please
<ogra> oki
<sivang> pitti: thanks, works well
<tseng> pitti: hi! was there a known problem with no sound in a clean breezy install?
<pitti> tseng: not really
<pitti> tseng: no sound == no detected audio card?
<tseng> it has the device, and i dont believe it is muted
<pitti> tseng: or some higher level issue like esd?
<tseng> i killed esd
<tseng> and switched gst to alsa
<Mithrandir> hm, live cd seems busted still.
<Mithrandir> gnome-session b0rken
<bob2> daniels: is "libtool: link: cannot find the library `/usr/lib/libXcursor.la'" iz kde bug?
<daniels> bob2: yeah
<daniels> bob2: work out which .la it's from and recompile that source package
<Riddell> bob2: what are you compiling?  and what does grep /usr/lib/libXcursor.la /usr/lib/*la bring up?
<bob2> daniels: ah, thanks
<bob2> daniels: does libtool need .la for static linking on linux?
<daniels> bob2: they don't need .la for linking anything on linux
<teprrr> so hmm
<Keybuk> oooOOOOH  usplash love
<bob2> it was teprrr who was trying to compile something
<bob2> 20:37:49        Riddell |  bob2: what are you compiling?  and what does grep /usr/lib/libXcursor.la /usr/lib/*la bring up?
<Keybuk> with a strangely empty white box in the middle of the screen
<bob2> teprrr: ^
<bob2> Keybuk: you're alive!
<Keybuk> aww, it didn't last long; it flipped back to the ordinary boot
<teprrr> Riddell, there's no libXcursor.la at all
<ogra> Keybuk, its only using a timeout for now afaik
<daniels> teprrr: that's the point
<Keybuk> ah, wondered whether it was the "mdadm: no raid arrays in control file [fail] " thing
<Riddell> teprrr: did you run `grep /usr/lib/libXcursor.la /usr/lib/*la`  ?
<teprrr> http://pastebin.com/337300 -- and there are tha la files around there
<daniels> teprrr: that's why you need to grep for it across /usr/lib/*.la
<teprrr> ah, didn't see that.. hmm.
<Keybuk> bob2: I am
<daniels> teprrr: ok, so either your installation is old and you need to dist-upgrade, or you've compiled stuff by hand and you now need to recompile it all
<bob2> teprrr likes to compile all the kde stuff him/herself
<teprrr> http://pastebin.com/337301 -- that's what the grep returns
<bob2> go kde
<teprrr> daniels, hmm. so this has been a bug in recent kde svn?
<Riddell> teprrr, bob2: it's nothing to do with kde per se, only when it was compiled
<daniels> teprrr: no, just changes to the underlying system.  packages deal with it fine.  if you compile it yourself, you lose.
<daniels> teprrr: so you need to recompile everything which produces those .la files, and in the correct order too.  enjoy.
<teprrr> ah, um, so who should produce those .la files then? or aren't you talking about libx*.la anymore but kde's .las?
* sivang yays. my bonobo helper wrapper works good in evo :-)
<Riddell> teprrr: what are you compiling?
<teprrr> well, this snapshot is anyways buggy.. will check if recompiling helps then
<teprrr> Riddell, hmm, tried to compile crystal clear style/windeco and konversation
<pitti> Mithrandir: by "broken live CD", did you refer to the missing kernel modules?
<pitti> Mithrandir: that's what I get with the current DVD
<Mithrandir> pitti: current live cd fails to log in for me.
<pitti> ah, right
<pitti> then the DVDs are differently broke
<pitti> n
<teprrr> Riddell-awa, well, hmm, at least nothing kde releated seems to link.. and it's about libXcursor.la always
<HiddenWolf> seb128, around?
<teprrr> and someone complained about same thing with libXrender.la, can't remember if (s)he was compiling kde stuff or what, though
<ogra> pitti, ping re gcompris...
<pitti> ogra: yes?
<ogra> pitti, i neither see a dependency on howl nor on svgalib... but i didnt remove it and nobody did do an upload since i wrote the report ...
<ogra> pitti, are you sure these two deps were there ? 
<pitti> ogra: odd, I can't see them any more
<ogra> i'm sure they were there....
<pitti> ogra: maybe I mixed up the package, nevermind then
<ogra> how can deps disappear ?
<Q-FUNK> hi.  who maintains the bazar branch of planner/main?
<ogra> pitti, no, no, you were right, they were in there... thats the strange part ...
<pitti> ogra: not on the source package at least, but maybe on a binary
<pitti> ah, now apt-get update works again
<pitti> ogra: this really stuns me...
<ogra> yup
<pitti> ogra: I updated the inclusion queue and the report, approved
<Riddell-awa> teprrr: then you need to grep libXcursor.la /usr/lib/*la
<ogra> thanks :)
<\sh> jesus I'm a touchpad noob
<highvoltage> \sh: are you praying?
<teprrr> Riddell-awa, I did it already
<teprrr> Riddell-awa, looks like current svn kdelibs compiled and linked fine
<teprrr> Riddell-awa, yup, and other seems to work fine now.. whines about wrong libstdc++ but that's minor problem :p
<teprrr> Riddell-awa, ouch, crystal clear doesn't link
<daniels> daniels@ephemera:~/canonical/mesa% dpkg-deb -c libgl1-mesa-dri_6.3.1.1-0ubuntu1_i386.deb
<daniels> [...] 
<daniels> -rw-r--r-- root/root   2547984 2005-08-15 21:34:39 ./usr/lib/modules/dri/r200_dri.so
<daniels> -rw-r--r-- root/root   2441808 2005-08-15 21:34:39 ./usr/lib/modules/dri/r300_dri.so
<daniels> [...] 
<daniels> -rw-r--r-- root/root   2440752 2005-08-15 21:34:39 ./usr/lib/modules/dri/unichrome_dri.so
* daniels giggles.
<Treenaks> unichrome DRI ?!
<daniels> built from mesa, no less ...
<mjg59> daniels: Do we have the DRM module?
<Treenaks> daniels: whoa.. now all we need is unichrome drm :)
<daniels> mjg59: EFABIO
<mjg59> Haha
<fabbione> daniels: ???
<daniels> (actually, they'll move to /usr/lib/dri when this debuild finishes, but the point remains)
<daniels> fabbione: you need to integrate the unichrome DRM module into the kernel.  savage and mach64 too. :)
<fabbione> daniels: haven't seen any patch floating around... :)
<daniels> fabbione: http://cvs.freedesktop.org/dri/drm/linux-core/
<daniels> fabbione: unichrome stuff is on unichrome.sf.net
<fabbione> daniels: yeah right :)))
<mjg59> daniels: Have the security isues been sorted?
<daniels> fabbione: eh, come on man
<daniels> fabbione: if nothing else, you NEED to get r300 drm in
<Treenaks> daniels: now if they only finished that siliconmotion driver... :)
<daniels> Treenaks: ha ha siliconmotion
<daniels> mjg59: with unichrome? probably not.
<fabbione> daniels: any reasons why they are not upstream yet?
<daniels> fabbione: they've only just now been enabled by default in xorg
<PzyCrow> Sorry if this is OT, but is it safe to have -dev packages from breezy installed on a Hoary system for Gnome development?
<fabbione> daniels: we will see soon...
<daniels> so yeah, as of -50 when I disable GL and DRI, the only two things left in xorg are servers and metapackages
<fabbione> daniels: if you can take over some hoary security stuff, i am sure i can manage to take care of DRM :)
<daniels> fabbione: ha ha ha
<daniels> fabbione: i'm too busy patching xpm stuff
<daniels> but I thought you maintained the kernel :P
<daniels> well, look
<daniels> if I can get you a patch, will you integrate it?
<daniels> (assuming it builds etc)
<fabbione> daniels: yeah sure...
<fabbione> a patch is enough...
<daniels> cool
<daniels> i'll try to do it later this week
<ogra> fabbione, are you the one to nag for ndiswrapper module inclusion for amd64 ? 
<fabbione> ogra: and the patch?
<ogra> fabbione, just add the arch... no extra patching... it works fine since hoary... (i uase it currently)
<fabbione> ogra: the patch to enable it in the kernel....
<mjg59> Hm. What's the gnome-power-manager status?
<ogra> mjg59, the recent one is in...
<mjg59> ogra: In main?
<ogra> mjg59, i left out the pm-scripts package
<mjg59> Ok, no problem
<ogra> mjg59, not yet.... hughsie changed the package name and splitted the packae in gnome-power-manage and power-manager :(
<fabbione> ahah
<fabbione> ops
<mjg59> ogra: Can you make sure that gets pushed?
<mjg59> (Assuming you feel the code is solid enough)
<ogra> i have one chrasher i want to sort with hughsie before 
<ogra> but i'll prepare the new main inclusion reports today
<daniels> hm
<ogra> i also have to look at the GDM_LOGUT stuff and how we get it in there.... hughsie wanted to work with a suid power manager binary in the backend, thats not necessary for us...
<daniels> so with -50, amd64 at least should spend more time extracting and patching the sources, running make includes/make depend, and make install and stuff like dh_shlibdeps, than it will in make World
* fabbione 's TODO list is endless
<doko> pitti: did you already had a look at the aspell packages?
<pitti> no, not yet
<pitti> but we already have aspell in main, don't we? 
<doko> aspell-*, i.e. aspell-fo
<pitti> doko: right, but aspell-* are just dictionaries, right? this seems to be utterly trivial
<pitti> elmo: please sync hpoj
<Mithrandir> pitti: what's so hard to support wrt pcsc?
<pitti> Mithrandir: if somebody comes along and says "this thing wrecked my smartcard", but nobody of us has a smartcard reader and this particular card, how should we support this?
<ogra> doko, what is -fo ? foreign ? 
<pitti> Mithrandir: I mean, if you are willing to do this support, that's fine for me :-)
<daniels> pitti: just like I do when they say 'xorg fried my random weird video card': laugh at them.
<pitti> ogra: Faroese
<ogra> ah
<daniels> ogra: as in 'foad'
<Mithrandir> pitti: I have a smart card reader so I could at least test it a bit.
<fabbione> pitti; that's not much different of what we already do for X and kernel....
<pitti> daniels: well, but video cards usually don't store valuable data 
<Mithrandir> pitti: well, I can't test random cards and readers, I just have what I got.
<pitti> fabbione: as I said, as long as you have fun with remotely debugging other people's hardware, that's fine for me
<pitti> Hi marcin 
<pitti> marcin: thanks again for the ekg support :-)
<Mithrandir> pitti: I would very much like to see it in supported and I don't think it's a heavy support-weight.  I was more wondering if you had something against it more than "I can't test this". :-)
<HiddenWolf> Anyone here willing to confirm a bunch of nautilus-cd-burner bugs in Breezy?
<pitti> Mithrandir: no, that's just my default answer for stuff that nobody wants to support :-)
<doko> daniels: first I read xlibs-dev, not xlibs-data ...
<HiddenWolf> seb128, I reported 13480, 81, 82, 84, 85. All are on hoary. I'm going on vacation for a week, while my harddrive is going RMA, so I'll confirm/close them in breezy next week.
<tepsipakki> doko: you maintain bash/bash-static?
<daniels> doko: kamion would kill me on my return if I hadn't fixed the 700 packages
<doko> tepsipakki: it depends on what you want ...
<tepsipakki> doko: ;)
<tepsipakki> doko: just a question: why does bash-static install the binary in /bin/?
<doko> daniels: it would be too late on Kamion's return to find you alive ;-P
<tepsipakki> shouldn't it install it as /sbin/bash
<tepsipakki> because that's the definition on /sbin, yes?
<doko> no s = system
<BBB> sbin = for super-user binaries (so sysadmin tools etc.)
<tepsipakki> ("static /bin")
<tepsipakki> hmm
<tepsipakki> in other unices it is static bin
<tepsipakki> but not in linux.. oh well
<tepsipakki> nevermind, then ;)
<HrdwrBoB> tepsipakki: in ancient history mostly :)
<tepsipakki> no, currently
<tepsipakki> tru64, solaris, aix ...
<tepsipakki> and we got all of them here
<tepsipakki> not even RHEL has a statically linked shell ;)
<ogra> tepsipakki, so /bin/sh is a link to /sbin/something ? 
<ogra> i cant see the benefit of this....
<tepsipakki> ogra: no, /sbin/sh is a binary of itself
<tepsipakki> as is /bin/sh
<tepsipakki> root has shell=/sbin/sh
<ogra> aha
<tepsipakki> try having an emergency first.. as one guy here just had when he f*cked up /etc/ld.so.preload ;)
<daniels> doko: hah
<tepsipakki> (that was on RHEL.. he had to use the recovery-cd)
<HrdwrBoB> tepsipakki: all you need statically linked is sash or as covered a boot CD
<tepsipakki> hrdwrbob: yes, seems to be installed here already, just that it wasn't clear for me why these weren't in /sbin
<bddebian> Hello
<Mithrandir> hmm, "User not known to the underlying authentication module".  That might be the reason for the live cd being busted. :-P
<ogra_> eeek..... 
<ogra_> language-pack-en cannotbe installed ? 
<lu|away> you didn't want english anyway.
<ogra_> the installer stops at the langpack installation...
<ogra_> and there seems no way around that... :(
<pitti> again??
<ogra_> yep
<ogra_> the console says its unauthenticated, offers Yes/No but Yes doesnt do anything
<pitti> ogra_: ah, mvo's playground then
<ogra_> AAAARGH ... and base-config doesnt let me out of the endless loop
<mvo> ogra_: I missed the background, can you please /msg me details? is only the langpack stuff unauthenticated? if so, where does it come from (what repo)?
<pitti> Hey seb128!
<pitti> already missed you
<seb128> hi pitti
<seb128> I've got 77 bugs mail since saturday
<seb128> that's quite depressive
<HrdwrBoB> depressing
<doko> seb128: don't upgrade gnome too often ;-)
<HrdwrBoB> unless you're going for have depressing, half impressive :)
<seb128> HrdwrBoB: thanks but I can make without people trying to make remarks on my english typos today
<seb128> doko: 70% are upstream wishlist, I'm considering starting to close this one saying upstream know about them
<seb128> 624 bugs, 164 non marked upstream
<seb128> cairo has the soname change too with like 200 packages to rebuild
<seb128> next week has a new GNOME version
<seb128> all is fine
<ogra__> *boggle*
<ogra__> 200 ?
<doko> seb128: will you rename libcairo1-dev to libcairo2-dev ?
<seb128> doko: no, libcairo-dev
<seb128> hum
<seb128> Debian guy did libcairo2-dev
<seb128> laybe doing the same
<seb128> s/laybe/maybe/
<doko> seb128: yes, that would be better ...
<seb128> why using a version on a -dev?
<doko> see the proposal on d-d ...
<seb128> I don't read d-d
<sivang> seb128: hi again, tell me, I see the gnome-games does not have lpint, and did you add it to the applets?
<seb128> "again"?
<sivang> seb128: you were offline , no ?
<seb128> I was on IRC 10min before lunch
<seb128> my internet dropped and I didn't reconnect
<sivang> seb128: ah, someone told me there is a holiday in french :)
<seb128> maybe you spoke to a ghost IRC
<sivang> seb128: so I was sure you went away for the day
<sivang> lol
<mvo> seb128: isn't today a public holiday in france? 
<sivang> seb128: btw, I updated the wiki page with evo , I saw it's also done
<seb128> mvo: yeah, but got 77 bug mails since saturday, and I decided I need to start cleaning some now
<seb128> sivang: thanks
<sivang> seb128: is there anything more I can help with lpint? 
<seb128> sivang: gnome-games is patched here, the issue is that it's setgid games so the lpi stuff doesn't work since it can go to /proc to get the details
<pitti> oh, nicd
<seb128> sivang: yeah, the non-patched packages (gnomemeeting, gimp, firefox, ...)
<sivang> pitti: is this some kind of a new daemon? nicd ?:)
<pitti> after system tools -> new login I get a dialog "choose server"
<seb128> pitti: just require a small API addition to specify the package name from the patch instead of using the magic for that
<pitti> with three times "Standard Server" options
<seb128> yeah
<seb128> I've noticed that too
<seb128> new gdm way to go!
<pitti> seb128: "<seb128> pitti: just require a small API addition to specify the package name from the patch instead of using the magic for that" -> ECONTEXT
<sivang> pitti: lpint, I assume :)
<seb128> pitti: I though the "oh, nicd" was for "gnome-games is patched here, the issue is that it's setgid games"
<sivang> seb128: all of the programs probably use gmome_init, so there would be no problem specify program name and pas it on to python code for tracking the package
<pitti> ah, that was a typo for "nice" and referred to that gdm bug
<seb128> pitti: yeah, I got it "<seb128> new gdm way to go!" :)
<sivang> seb128: ok, I'll checkout gnome meeting this evening. What about context menu for applets, will this be deferred for breezy+1 ?
<seb128> it was a part of the spec?
<seb128> I've not that on my list
<seb128> feel free to do patches for them
<sivang> seb128: k, cool, will they get accepted although we're after FF ?
<seb128> before UI freeze probably but you may want to ask to mdz
<sivang> seb128: ok, I will, thanks :-)
<seb128> np, thank you
<pitti> argh, this is totally broken, it offers me a dialog to choose a server, but then it doesn't find local servers *grumpf*
<seb128> pitti: you picked the wrong line :p
<seb128> try an another one
<pitti> yes, works now, thanks
<pitti> well, all lines said the same...
<seb128> pitti: yeah, this bug sucks
<Keybuk> pitti: <random> is there any particular reason that hal doesn't look in ~/.local/share/hal/fdi ?
<ogra__> seb128: do you know if a "random" feature is planned for gnome-screensaver ? you can currently select only one or none
<pitti> Keybuk: whose ~?
<torkel> ogra__: the CVS version has a random feature
<seb128> as said
<Keybuk> pitti: good point
<seb128> ogra__: we are probably going to delay it for next Ubuntu version
<torkel> ogra__: and I think you can change the gconf key directly in the current version
<Keybuk> Mine :)
<ogra__> seb128: in other news, it works very nice with all the screensaver hacks, i tried them out on the weekend :)
<seb128> ogra__: we would require a new version for some of this feature, and some glitch to fix, etc
<ogra__> seb128: shriek.... then i have to finish the lock screen
<pitti> Keybuk: local storage configuration should rather be done in g-v-m I think
<seb128> or make the work on gnome-screensaver to use the xscreensaver files
<seb128> (ie: split it to a -data or something)
<seb128> I'm too busy to work on that 
<ogra__> seb128: tats trivial...
<seb128> yeah, but still too busy
<seb128> CVS version has some new stuff
<ogra__> seb128: me too... edubuntu is going very slow
<seb128> using these data without having to copy them to gnome-screensaver 
<seb128> etc
<seb128> bah, you have to work on of the 2 solutions anyway
<seb128> s/on/on one/
<ogra__> i thought g-s was yours :)
<seb128> yeah, but it doesn't ship the graphical animations
<seb128> I'll ping mdz about that, but since feature freeze was some day ago ...
<ogra__> ok, i'll talk to mdz which path well go now... the missing random feature is a big drawback, we should get it in 
<ogra__> heh
<seb128> we can update to CVS version
<seb128>         * savers/personal-slideshow.xml: New theme file that loads
<seb128>         images from ~/Pictures.
<ogra> even after UVF/Feature freeze ?
<ogra> lets hear mdz first :)
<seb128> that's why I said it's probably going to be deferred
<BBB> mako, ping
<seb128> anybody with quite some uptime on his boxes around?
<seb128> that's for http://bugzilla.ubuntu.com/show_bug.cgi?id=13449
<pitti> seb128: I use to switch off my machine at night...
<seb128> me too
<tepsipakki> doesn't leak here
<tepsipakki> firefox does, though ;)
<tepsipakki> uptime on my laptop is 11 days
<tepsipakki> actually 12
<Keybuk> "In more than one way SuSE feels so much better than Ubuntu, and it's hard to resist all the small details and finishes Novell put into the product."
<Keybuk> -- http://www.ffnn.nl/pages/reviews/linux/suse-9.3-ftp.php
<mjg59> It'd be nice if some of them were mentioned
<davyd> SO THEY CAN BE STOLEN!
* lu|writing is surprised no distro (to the best of his knowledge) has written a good reviewer's guide
<davyd> FOR KLEPBUNTO LINUX
<lu|writing> 'here are the criteria we think are most important in assessing a distro'
<Keybuk> I think he liked YAST
<davyd> lu|writing: what is a reviewers guide?
<davyd> "please look at these these, for they are not broken"
* sivang guesses the broken link for evo on the top panel is a "known bug"
<lu|writing> davyd: 'here is the checklist of features/qualities that we would look at'
<Keybuk> he's also really comparing it against Kubuntu
<lu|writing> 'here is how we think we stack up, and perhaps how we think others stack up'
<lu|writing> 'we'll try to be forthright and include some categories you might think are important which we don't do so well at; here is why we don't do well, or why we think they are unimportant'
<sivang> seb128: are you aware of the broken evo link  from the main panel? (sorry if this is already in bugzilla)
<seb128> sivang: the panel is an user configuration
<sivang> seb128: but I didn't touch it, and it's a fresh breezy installation, and when I press the evo link form the main panle (next ot the yelp icon) I get "failed to execute child process evolution-2.2, no such file or directory"
<seb128> sivang: "daily install"?
<sivang> seb128: no, upgrade from a very old daily install
<doko> daniels: unstable does have libxaw8-dev, breezy not. any reason for it?
<sivang> seb128: it's under VMware, if this matters 
<seb128> no
<seb128> but the previous daily was bugged
<seb128> and the upgrade doesn't change the user config set by the bugged version
<sivang> seb128: I see, I need to try with a fresh daily then
<Nafallo> doko: what can I do to help out with the aspell mess?
<Nafallo> :-)
<doko> Nafallo: instructions are in the aspell changelog.Debian.gz / aspell doc dir. just tell me which package you start with
<Nafallo> doko: oki
<mpt> davyd: http://www.google.com/search?q=%22reviewer's%20guide%22%20(site%3Amicrosoft.com%20OR%20site%3Aapple.com)
<Mitario> lo everyone
<pitti> Hi Mitario 
<Mitario> cool mouse in X :)
<lu|writing> mpt: maybe not 110 pages ;)
<mvo> is it a known bug that resizing a partition with partman gives hardly any feedback (takes long and the progress bar stay on 0% for a very long time)?
<seb128> what's going on with the colony 3 CD?
<Keybuk> mdz said something about me needing to fix a hotplug bug which was blocking it
<seb128> Keybuk: thanks
<Keybuk> I'm just doing the 4-weeks-of-upgrade on my laptop now
<madduck> where do gcc maintainers hang out?
<mvo> wb ogra_ltsp 
<ogra_ltsp> >&
<pitti> Hi madduck 
<ogra_ltsp> :/
<madduck> hi pitti
* pitti points madduck to doko 
<madduck> pitti: i am already bugging him all day.
<madduck> there have to be others too, no?
<pitti> madduck: well, he is the Ubuntu gcc maintainer team :-)
<pitti> madduck: jbailey could also help, probably
<madduck> oh yeah.
<madduck> jbailey is not around. :(
<Treenaks> do I need to file a bug for every key that doesn't work out of the box on my laptop? :)
<ogra_ltsp> Treenaks, depends how "hot" the key is ;)
<Treenaks> ogra_ltsp: mute/volumeup/volumedown
<seb128> no
<seb128> or not on GNOME packages
<ogra_ltsp> Treenaks, thats a hotkez i guess
<Treenaks> ogra_ltsp: this is hoary btw :)
<ogra_ltsp> oh
<Treenaks> ogra_ltsp: waiting for a friend who's buying me some CDRWs to test breezy
<seb128> hoary has no default key value
<seb128> NOTABUG
<ogra_ltsp> ok, ignore me then.... i dont have such old stuff around here .... (only warty on a ancient laptop)
<ogra_ltsp> hmm, update-notifier shouldnt get started for unpriveleged users.... or at least i should get a error message after giving the password.... it asks for password and quits silently
* Treenaks rsync breezy-current & burns
<ubuntuguy> anyone: ndiswrapper will not modprobe insert. Modprobe reports a fatal error. Does anyone know how to fix this?
<trygvebw> ubuntuguy: which error?
<ubuntuguy> its not specific, it simply states fatal error can not insert
<teprrr> so hmm, Riddell-awa, is those .la files removed completely? or will they be back sometime?
<ploum>  To take screenshot of the breezy installation, I'm looking for a free (a in beer) virtualizer software
<ploum> Is there anything easily installable in Hoary ? (a 30 days trial of vmware or anything like that would be enough)
<trygvebw> vmware is easy to install
<ploum> trygvebw, last time, it was pain
<ploum> (two years ago)
<trygvebw> oh
<trygvebw> but two years is a long time ;)
<trygvebw> i installed it in ten minutes
<ploum> http://www.vmware.com/download/workstation.html : this one ?
<trygvebw> yep
<ploum> http://www.vmware.com/download/download.do?downloadGroup=WKST-5-LX no luck :-(
<trygvebw> :(
<trygvebw> hmm
<trygvebw> try QEmu then
<trygvebw> it's not very fast, but it works
<ploum> at least, I can install it with a simple apt-get :-)
<trygvebw> yeah :)
<ploum> is there any GUI like vmware ?
<Treenaks> qemu?
<trygvebw> no, but qemu is easy to configure
<ploum> (I must admit that vmware rocks once installed)
<trygvebw> yeah
<teprrr> there's kde frontend for qemu available from kde-apps.org
<ploum> it's just to take screenshots
<Treenaks> does vmware support OS/2 Wrap 3 ? :)
<trygvebw> yes
<Treenaks> qemu doesn't because of 1 missing "feature" :)
<trygvebw> :/
<trygvebw> i think so at least
<trygvebw> there is a #vmware btw
<Treenaks> trygvebw: "segment limits" is the feature
<trygvebw> oh
<trygvebw> :/
<mdz> morning
<pitti> Morning mdz
<seb128> hey mdz
<Keybuk> morning
<mvo> good morning mdz 
<seb128> mdz: any estimation for when colony 3 should be ready?
<mdz> seb128: T(13398 fixed) + N
<seb128> is that likely to be before wenesday?
<ogra> depends on N :)
<seb128> s/wenesday/wednesday/
<pitti> Am I the only one whose Ctrl+D doesn't work any more?
<seb128> pitti: context?
<seb128> what app?
<ogra> works here....
<pitti> seb128: bash
<tseng> pitti: wfm
<seb128> works for me (tm)
<pitti> i. e. quitting a ssh session, a terminal, etc
<ogra> even on a fresh edubuntu install
<pitti> 'grumpf*
<pitti> thanks for checking
<Keybuk> pitti: value of $IGNOREEOF ?
<pitti> Keybuk: not set
<Keybuk> or set -o | grep ignoreeof
<pitti> $ set -o |grep ignoreeof
<pitti> ignoreeof       off
<pitti> Keybuk: I didn't change any config files, I just dist-upgraded this morning
* pitti blames xkb and daniels
<Keybuk> no idea then
<pitti> thanks anyway
<seb128> pitti: oh, I've not  updated today
<Keybuk> is it saying "TYPE EXIT YOU LAZY FUCK" or just not working?
<pitti> seb128: -49 waits for you :-)
<mdz> Keybuk: how did the upgrade go?
<seb128> pitti: I'm not waiting for b0rkages :)
<pitti> Keybuk: no reaction at all :-) but that certainly forces me to do the former
<Keybuk> mdz: actually, it worked; I'm currently being baffled by the fact my initrd.img seems to be a gzip compressed cpio file and not a cramfs filesystem
<mdz> pitti: stty settings?
<pitti> $ stty
<pitti> speed 38400 baud; line = 0;
<pitti> eof = ^A; eol = M-^?; eol2 = M-^?;
<pitti> -iexten
<pitti> mdz: I don't believe that it is anything shell related
<mdz> Keybuk: not too baffled I hope, given all the discussion around initramfs ;-)
<mdz> pitti: eof = ^A
<Keybuk> I missed that discussion
<pitti> it stopped working on my server today, too
<Keybuk> do you have a pointer for it?
<mdz> pitti: stty eof '^D'
<mdz> Keybuk: wiki.ubuntu.com/EarlyUserspace
<pitti> mdz: hm, how do I type this? ctrl+v ctrl+D doesn't work
<Keybuk> ah yes, I just found that 0.1s before you gave me the link
<mdz> pitti: literally, cut and paste
<pitti> $ stty '^D'
<pitti> stty: ungltiges Argument ^D
<mdz> pitti: cut and paste what I wrote :-)
<pitti> ah, thanks
<pitti> yep, that works
<mdz> I have no idea why it would have changed for you; is this an Ubuntu system?
<seb128> mdz: is that likely to be before wednesday for colony
* pitti looks for the package that broke it
<mdz> seb128: it should be
<pitti> mdz: yes, upgraded today and broke today
<ogra> pitti, does it happen in console too ? 
<seb128> mdz: k, because I would like to make the cairo soname change for wednesday, there is a new GNOME version next week and that should be pushed and worked before
<pitti> ogra: no, it works there (given that the stty command I just typed doesn't apply to it)
<pitti> anyway, nevermind
<mvo> mdz: permission for uploadds of update-manager and gnome-app-install? (both are bugfixes only, do I actually need approval for bugfix-only uploads?)
<pitti> maybe some fancy binary output to my screen changed it somehow
<ogra> pitti, then i'd blame the X upgrade 
<mdz> mvo: no, no approval needed for bugfixes
<mvo> mdz: thanks
<Kronoss> someone knows  any file or command with the options of each filesystem type apart of man mount?
<highvoltage> cat /proc/partitions?
<Kronoss> in proc partitions are the partitions
<Kronoss> i want the options (ro, rw, user) specific of each type
<ogra>  /proc/mounts
<Kronoss> all the possible options
<ogra> but that doesnt show all
<Keybuk> mdz: hmm, that didn't help; the spec doesn't actually explain what the difference between initramfs and initrd is and why we'd want the former and not the latter
* Keybuk finds more things on the wiki
<mdz> Keybuk: initramfs is simpler, and doesn't require that cramfs patch that upstream rejected
<carstenh> /etc/mtab?
<Kronoss>  /etc/mtab have the mounted filesystems
<carstenh> zsh autocompletion?
<\sh> grmpf...
<Nafallo> smurfix: ping
<smurfix> Nafallo: 
<Keybuk> mdz: ah, I understand.  and I'm able to replicate that bug
<Nafallo> smurfix: is that a japanease sign? anyway, may I message you?
<smurfix> Nafallo: it's a "pong". Just ask.
<Keybuk> out of interest, why are we loading network drivers there?  Just because we can?
<mdz> Keybuk: NFS root
<Keybuk> ah, of course
<Keybuk> but we don't put l-r-m drivers in ther?
<smurfix> (as in "ping pong" -- )
<mdz> Keybuk: no
<mpt> cute
<mdz> NFS root on an encumbered wireless card -> you lose
<Keybuk> that all makes the nfs root stuff far more elegant though, I guess; no more compiling in the drivers you need
<mdz> they generally don't support netbooting anyway, I don't think
<Keybuk> ya know, I think that "can't be mapped reliably" message is unrelated
<mdz> Keybuk: yeah, I'm not at all sure what it's trying to say with that
<Keybuk> no, me neither
<mdz> Keybuk: but the bug is certainly valid
<Keybuk> I have a working net.rc now anyway
<mdz> so you feel that it is the correct solution as well?
<Keybuk> well, it's certainly one solution
<Kronoss> bye
<Keybuk> another might be to drop the "mapping hotplug" thing altogether
<mdz> another option would be to require that the user set a flag in mkinitramfs.conf if they want to use nfs root
<Keybuk> but not sure how that impacts ordinary networking stuff
<luigino> hello everyone.....
<mdz> ordinary networking stuff relies on that to get the interface brought up after the driver is loaded
<luigino> anyone here can tell me what should mean that :0. in this log message I've got: Aug 15 21:12:08 localhost entrance: Opened PAM session. luigino : :0. ^
<Keybuk> yeah, it causes the asynchronous dhcp rather than waiting for it during S40networking
<mdz> luigino: please see /topic
<mdz> luigino: try #ubuntu
<luigino> ok
<luigino> thx
<luigino> :)
<Keybuk> the hotplug networking and ifupdown stuff need to converge really
<doko> mdz: is http://people.ubuntu.com/~mdz/anastacia.txt still beeing updated?
<mdz> [TXT]  anastacia.txt           15-Aug-2005 18:50  6.9K  
<pitti> lamont-away: ping
<doko> Package: lapack3-pic
<Keybuk> for now, I think a net.rc is the right solution as it'll closer match what we'll get later aiui
<doko> Depends: lapack3 (= 3.0.20000531a-6ubuntu2), libc6-dev, refblas3-dev | atlas3-base-dev | libblas-3.so
<ogra> mdz, which seedlist does that script read ? squidguard was dropped days ago from the edubuntu seeds...
<doko> mdz, so refblas3-dev should take precedence?
<mdz> ogra: I believe it uses the one at ~cjwatson, which is updated a few times per hour
<ogra> strange thn
<ogra> then
<mdz> germinate is only re-run once per day
<ogra> i dropped squid and squidguard friday or even earier
<ogra> earlier....
<doko> elmo: last sync request for today: expect-tcl8.3 (5.43.0-3) from incoming
<mdz> mizar:[...nical/seeds/edubuntu/breezy]  baz update
<mdz> * tree is already up to date
<mdz> mizar:[...nical/seeds/edubuntu/breezy]  grep squidguard *
<mdz> supported: * squidguard # edubuntu
<mdz> ogra: ^^^
<mdz> Keybuk: what will we get later?
<ogra> weird... 
<ogra> mdz, http://people.ubuntu.com/~cjwatson/seeds/edubuntu-breezy/server this didnt change since friday
<Keybuk> basically all devices will be cold-plugged if required
<mdz> ogra: <mdz> supported: * squidguard # edubuntu
<Keybuk> I haven't kept up recently, I shall have to find out what plans exist that we can exploit for dapper
<mdz> ogra: also, the entry in anastacia.txt is for the edubuntu-server metapackage, not the Server seed
<mdz> ogra: the metapackage is only updated when you run the update script and upload a new source package
<ogra> yep-...
<mdz> but you need to remove it from supported also
<ogra> i thought its drawn directly from the seeds :)
<ogra> thanks 
<ogra> dear baz, please fall back to a installed editor by default if $EDITOR isnt set, kthnxbye
<Nafallo> doko: I start with aspell-sv
<Nafallo> doko: I guess buildX is the right thing to do with those?
<doko> Nafallo: not if you make modifications
<Nafallo> doko: I do. but those will probably not be synced till after breezy and debian should have had this transition by then I guess?
<doko> Nafallo: guessing is bad
<shaya> x-windows-system-dev depends on libxp6-dbg
<Nafallo> doko: hehe, oki :-)
<shaya> but acc to aptitude, that package isn't in the archive
<shaya> I have it installed, but aptitude marks it as obsolete/locally installed
<Nafallo> doko: seems to be easy changes. want me to take all of them? ;-)
<mdz> Keybuk: what did the old net.rc do?
<Keybuk> the old one got moved to the S41hotplug-net startup script
<Keybuk> it basically went "go! go! go!" to any waiting network plug events
<Keybuk> (they deliberately wait until after S40networking has started)
<Keybuk> that was removed a few months ago
<carstenh> shaya: Candidate: 6.8.2-10 500 http://archive.ubuntu.com hoary/main Packages
<carstenh> shaya: but it is not in breezy
<shaya> correct
<shaya> I'm talking about 6.8.2-49
<mdz> ogra: are you going to upload edubuntu-meta?
<ogra> mdz, yup, soon (after dinner)
<ogra> mdz, done
<mdz> ogra: ARGH
<ogra> ??
<ogra> what did i wrong ? 
<mdz> you need to read the changelog before uploading
<\sh> and fcked again the wifi card
<\sh> grmpf...reboot
<mdz> ogra: it looks like one of the downloads failed
<ogra> mdz, i did, whats wrong ? 
<ogra> oh, damned
<ogra> sorry 
<mdz> fortunately there is no minimal metapackage in edubuntu
<ogra> yep, and it seems to affect only ppc and unsupported arches.... regenerating
<mdz> there is one in ubuntu, though, and the same thing can happen there
* ogra makes note to self... dont do important updates while eating....
<mdz> it's just necessary to read over the changes after updating and before uploading, to make sure they are sane
<mdz> it is mostly automated but things can go wrong
<mdz> sometimes debootstrap seems to fail to download Packages and still exits successfully
<ogra> mdz, btw, how evil would it be if i made all the edubuntu config in a metapackae postinst ? i'd prefer that to a -config package
<mdz> ogra: too evil
<ogra> it would have the advantage that i could use debconf all over the place...
<mdz> the metapackages should be pure
<mdz> it makes no difference to debconf whether it is a metapackage or a real package
<ogra> true... but its a extra package.... but i was expecting this answer anway :)
<\sh> grrr
<ogra> \sh, broke your laptop again ? 
<shaya> is bugzilla messed up?
<shaya> "readahead" for package names doesn't seem to be working
<\sh> ogra: the r200 has a switch on the side, where u can enable or disable wifi
<ogra> heh... yeah, toshiba has this on all leptops
<\sh> ogra: but..even when it's disabled linux enables the wifi interface
<\sh> ogra: and then, try iwlist ath0 scanning...
<\sh> segfault and then ... kernel oops
<ogra> oh....
<\sh> ogra: correct...oh ;)
<ogra> i have a similar behavior with my ndiswrapper based card here (wlan0 remains even if i unplug the pcmia card) but i dont get a segfault ... you should track that
<ogra> seems related to your driver patch 
<\sh> ogra: hehe..actually I can't give the advise to buy this laptop for use with linux..actually he/she should be an adventurer
<ogra> heh...
<\sh> ogra: no..
<mdz> shaya: you were never able to reproduce the unionfs/bash bug, were you?
<\sh> ogra: the wifi is working with the madwifi drivers..out of the box
<\sh> when the switch is on...everything works fine
<ogra> \sh, i thought you had to patch a lot ? 
<\sh> ogra: not for wifi...for bluetooth i have to patch and for hibernate/suspend buttons and for the nic
<ogra> ah, i thought the wlan too...
<\sh> ogra: no sound, touchpad and wlan is working and the graphics card as well
<\sh> but the rest...my oh my
<\sh> ok...pcmcia is working as well..but my wifi card (zyair b-120) is not recognized...
<shaya> mdz: I only tried once, and it worked
<shaya> though it was a loopback nfs server, not a remote one
<mdz> I'm working around it by mounting tmpfs on /tmp
<mdz> but it's definitely still three
<mdz> there
<ogra> mdz, thats the one with the tcpdump workaround ? i still have it in ediubuntu daily from today
<mdz> ogra: tcpdump?
<ogra> yes, running tcpdump -i eth0 solves the nfs timeout probs....
<mdz> this is not an NFS timeout problem, but a unionfs problem
<mdz> http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-August/000904.html
<ogra> yes
<mdz> no
<mdz> we are talking about two different problems
<ogra> oh...
<mdz> you are talking about the bug where you get "NFS server ... not responding" at boot
<ogra> yep
<mdz> and I am talking about the one where bash here documents don't work
<mdz> I get the NFS timeout issue too sometimes, the first time I try to boot
<mdz> but the second time is OK
<mdz> some sort of race in initializing the card I think
<mdz> have you debugged it?
<\sh> ok...the sd card reader is not working at all
<ogra> hmm, mostly i hae tdpdump already running on the second try.... i'll keep an eye on it
<ogra> have even
<ogra> nope, i had other issues to workaround and debug today :) a lot...
<\sh> hmm...and usb devices are not popping up anymore
<\sh> only on my hp
<\sh> ok...this laptop is nothing for packaging
<Treenaks> \sh: why?
<Nafallo> is it October the third breezy releases?
<Treenaks> Nafallo: no, it's the first and only breezy release
<Treenaks> Nafallo: it's the third ubuntu release though
* Nafallo is in a LoCo-meeting :-)
<\sh> Treenaks: it's getting too hot and is too slow ,-)
<Nafallo> Treenaks: I was aiming for the date ;-)
<Treenaks> Nafallo: check the Calendar :)
<Treenaks> Nafallo: on the wiki
<Treenaks> I'm still waiting for mine
<Nafallo> ah, kewl
<Nafallo> Treenaks: thanx :-)
<zul> Treenaks: same here
<sivang> seb128: About gnome-games, why does having setgid on the games breaks lpint stuff ? (I would think that elevated privileges would allow it even more access to /proc then when it's run with the users' privs) 
<seb128> run a game and ls -l /proc 
<ogra> sivang, it doesnt elevate 
<sivang> ogra: sure. It only forks a privileged child to be able to write scores, I will try seb128's experiment :)
<seb128> no
<seb128> the binary is setgid
<jnc> hey.... silly user question here;  how do the linux-restricted-modules work now that they are in /lib/linux-restricted/modules/*/*.o ?
<jnc> i see that linux-restricted-modules-your_kernel_here-arch installs the madwifi *.ko files in /lib/modules/your_kernel_here/*
<jnc> yet the fglrx, nvidia, and i think the fritz stuff remain as *.o in /lib/linux-restricted-modules/*/*.o
<jnc> i'm wondering, how does this work to be loaded by the kernel?
<sivang> seb128: I entered the process "dir" (in /proc) and everything there is owne by root, that what you mean?
<jnc> i did not see any documentation for this change
<seb128> sivang: correct
<sivang> seb128: k, thx
<seb128> np
<sivang> seb128: do you know if jamesh has startd working on adding a function that gets package name / program name as an arg ? (I might take a shot at adding it myself)
<seb128> no
<sivang> seb128: k
<seb128> you don't want to patches remaining app, do you?
<seb128> I've the patch on my list of stuff to do
<madduck> C[C[C[C[C[C[C[C
<ogra> C[ ?
<sivang> seb128: ah ok :)
<madduck> sorry. GNU screen
<sivang> seb128: I will go on with the other apps
<madduck> but it's pretty much how i feel.
<seb128> thanks
<sivang> seb128: no prob, I have a feeling it's a bit more complicated to patch those remaing apps so it'll be more fun :)
<seb128> yeah
<mantiena> mdz, still online ?
<sivang> bah, I need to upgrade my chroot first. network is shaky grumpf
<sivang> seb128: and I gues you're also going to take care of adding the "general" launchpad items under the proposed "Help" menu on the main top panle? (as in the spec diagrem)
<concept10> Does anyone know who developed the Ubutnu hardware information collecting application?
<HiddenWolf> concept10: ogra did
<seb128> sivang: where should those point?
<ogra> concept10, whats the issue ? 
<concept10> Ahhh... glad you are here
<concept10> orga, I have a idea that i am trying to pitch
<concept10> ogra, sorry about that.  Anyway, I want to make something like the ubuntu hw collector that is distro neutral
<ogra> concept10, then you'll have to write it different... hwdb-client relies totally on a patched hal and lashal output
<ogra> lshal even
<sivang> seb128: IIRC, this should actually fire up the picker application, and let the user choose the non main app or the app that has not a help menu and fire the browser with the lp page
<concept10> ogra, so the distro basically has to have the same hal patch of ubuntu? Is this common among distros?
<ogra> concept10, nope...
<ogra> concept10, thats what i mean
<concept10> dammit
<seb128> sivang: we have no picker app atm
<ogra> concept10, you have to write it different
<ogra> concept10, grab the output from lsb-release, dmidecode and /proc as well as the lshal output.... format it in xml and you got the same
<ogra> but you'll have to write it completely different
<sivang> seb128: ah,ok sorry for making noise then
<seb128> np
<concept10> ogra, im not a full fleged programmer so I will need some help on it, I would just like to see something like the hwdb-client that updates a searchable database for all distros, this would be a great help for the linux community
<concept10> ogra, but I will attempt to do it.
<ogra> concept10, you'll have to find a programmer to do it, hwdb is not one of my higher rioritys in this release cycle...
* sivang pokes gnomemeeting's source
<concept10> ogra, Thats fine.  Thanks for the advice and insight.  Where may I grab the source of hwdb-client?
<mvo> ogra: #13496 -> aptitude/edubuntu bug
<hunger> How is network magic progressing for breezy? I installed network manager and that does not really do much (nm-applet does not even show an icon or anything).
<ogra> concept10, http://archive.ubuntu.com/ubuntu/pool/main/h/hwdb-client/
<ogra> mvo, yay, thanks
<HiddenWolf> ogra, cheering for bugs?
<ogra> HiddenWolf, cheering for a clean explanation of the issue that bugs me :) 
<HiddenWolf> Ah, that explains a lot.
<seb128> HiddenWolf: do you have a bugzilla.gnome account?
<ogra> mvo, what i dont understand is, why doesnt it happen in ubuntu ...
<HiddenWolf> seb128, yeah. Sorry about earlier. :)
<seb128> are we going to have fspot 0.1.0?
<ogra> seb128, its in universe, so its possible
<seb128> HiddenWolf: np, but we are really bug flooded for the number of people working on bugs, that would be nice than people who have some clue about bugs search for dups and send upstream bugs upstream
<HiddenWolf> seb128, I would, but my harddisk was dying and had to go RMA before 5pm. I'm about to go on vacation for a week, and did not want to forget.
<seb128> you could have noted instead of filling a pile of bugs good to close
<seb128> anyway no big deal
<seb128> and another hint: one issue by bug
<HiddenWolf> seb128, there was one bug that noted more than one thing, and only because these are closely related issues complementing eachother. 
<HiddenWolf> seb128, I appreciate the workload you're under, and I'll take better care next time, but don't take it out on those trying to help.
<seb128> clearing CDs and doing multi-session are 2 different issues
<seb128> HiddenWolf: "don't take it out on those trying to help"? what does that mean?
<HiddenWolf> seb128, never mind
<seb128> any english speaker to say that differently for me? :)
* lamont looks at http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary-backports.all.i386 and screams
<lamont> someone isn't gonna like those version numbers
<HiddenWolf> seb128, as I said, never mind, I didn't say anything.
<ajmitch> seb128: how long has f-spot 0.1.0 been out?
<seb128> HiddenWolf: I appreciate when people are trying to help, just I got ~80 bug mails a day, so I can do without duplicates :)
<seb128> HiddenWolf: and I'll find somebody to make me said that differently to be sure I've understood it correctly, don't worry :)
<seb128> ajmitch: today, I'm not an hurry, that was rather a question to know if that's a candidate for an UVF break
<ajmitch> seb128: it could be, if needed. I'll get it into sid asap
<HiddenWolf> seb128, Don't bother: my piont was, I get that you're buried under bugs, but I got you the first time, so leave it at that, since I already promised to do better, don't take your frustration out on me.
<seb128> HiddenWolf: I'm not frustated, I was just trying if you feel like pushing upstream bug upstream rather than here ... no big deal, I'll reply to them if you keep pushing them on ubuntu.bugzilla
<HiddenWolf> seb128, however, I respect you, and you're always correct. You just make me feel like an idiot, so I'd appreciate it if you'd do it only once. :)
<HiddenWolf> seb128, gnome.org makes me feel unwelcome, that's why I usually push them in ubuntu.
<seb128> HiddenWolf: that was not the goal, just wanted to point that we are kind overloaded by bugs, so if people can try to lower that, that's cool :)
<HiddenWolf> *g* seb128, ask me nicely, tell me where to look, and I might patch a few for you. ;)
<seb128> HiddenWolf: oh, what's wrong about gnome.org? Anyway you are welcome to push them on ubuntu, just search for duplicate including closed bug when you use a stable version and that's fine :)
<HiddenWolf> seb128, Whenever i post some bug on gnome.org, someone files a counter-bug to have that feature removed, and a discussion follows. :)
<seb128> ajmitch: 0.1.0 import photo for mass storage device, which is cool :)
<ajmitch> seb128: oh then I definitely want it in breezy :)
<seb128> HiddenWolf: ah ah, yeah, feature request are usually discussed :)
<HiddenWolf> seb128, but they usually start with "grumble, I didn't expect it and messed up badly, have it removed, now!" Kinda unwelcoming. :)
<HiddenWolf> seb128, IE: checking pop-mail at startup for evo
<seb128> evo guys are not a good example
<seb128> they are unfriendly on bugzilla (when they reply)
<HiddenWolf> some guy didn't check what he was doing and emptied his server. *chuckle*
<mpt> HiddenWolf: Wow, that's *exactly* the problem hp talked about
<mpt> "People just assume that FooBar was designed to eat your email, and humbly ask that you let them turn off this feature they don't like."
<HiddenWolf> *g*
<HiddenWolf> I can't feel really sorry for him. If you install something from cvs, just check a changelog.
<ogra> mpt, bah, just pop up a notification....
<mpt> ogra: As in, "FooBar just ate your e-mail. If you didn't want this to happen, you should have ..."?
<HiddenWolf> for the record, my bug was that it should only be turned on if the user had asked for automatic email checking.
<ogra> mpt, nah, rather something with progress bar and without close button :)
<mpt> without a cancel button, you mean
<ogra> both :) like a splash screen
<mpt> progress windows shouldn't have close buttons anyway :-)
<torkel> they should have a pause button instead :-)
<Nafallo> mako: ping
<mako> Nafallo: yeah
<Nafallo> mako: may I message you? :-)
<mako> Nafallo: yesyes
<seb128> does somebody wants to make a wiki page for cdrdao to main?
<seb128> that would be appreciate :p
<pitti> lamont: ping
<lamont> pitti: ack
<seb128> pitti: you don't feel like doing a cdrdao wiki page by any chance? :)
<pitti> seb128: hrmkay...
<seb128> thanks!!
<pitti> seb128: would tomorrow morning be enough?
<seb128> pitti: the rational is https://bugzilla.ubuntu.com/show_bug.cgi?id=13168
<seb128> pitti: any time you want, there is no hurry
<pitti> yep, we talked about the rationale, that's fine
<seb128> cool
<pitti> although some day some clever person should come along and write an universal libburn
<seb128> that's the plan
<pitti> and get rid of all those cli clients
<seb128> coaster guys were/are working on that, but that doesn't come fast
<pitti> oh, if it happens eventually, that's fine
<pitti> "Husch husch wird Pfusch", as a German saying tells... :-)
<ogra> heh
<seb128> pitti: apt-cache show libburn-1
<pitti> yay
<seb128> pitti: that's the one that coaster use
<pitti> and it actually works already?
<seb128> coaster kind of work, so I guess it does basic stuff yeah
<ogra> yup... coaster can burn data cds fine
<seb128> but it probably still needs some love before beeing pushed
<ogra> i never tried audio but heard it should work too
<ogra> pitti, ask mxpxpod, he's one of the upstreams
<shackan> cool, rhythbox can't stay up more than two ours without crashing..
<shackan> *hours
<seb128> what version?
<seb128> backtraces are welcome for crashes :)
<shackan> well, it eats 100% and I have to kill it, so no backtraces and no core dumps sorry
<seb128> what version?
<shackan> 0.8.99
<seb128> you know that you can get a backtrace of something eating CPU?
<seb128> upstream to current gst packages and rb 0.9 to start
<seb128> and gdb -p `pidof rhythmbox` when it hangs
<shackan> I guessed it could be done, but I'm too busy now to figure out how
<seb128> thread apply all bt
<seb128> k
<shackan> cool
<seb128> so no wonder if it's not fixed
<seb128> bugs are not magically fixed
<shackan> eh, I know
<shackan> mine wasn't a critique, just a comment :)
<seb128> yeah, but I would like to get that fixed
<seb128> that's likely to happen to other people too
<seb128> that's why if you can put a backtrace to bugzilla with the some details ... :)
<shackan> uh, with 0.9 it doesn't play -anything-, nor songs neither streams (which were causing me problems before), but I used it just this morning and was (almost) fine..
<shackan> sigh, I'll have to code in silence tonight :)
<shackan> it needs investigation though..
<seb128> does running gst-register-0.8 make any difference?
<seb128> what audiosink do you use?
<mvo> elmo: do you know what happend to my gnome-app-install upload from today?
<elmo> Rejected: no signature found in gnome-app-install_0+20050815_source.changes.
<pitti> Hi elmo 
<elmo> hi pitti 
<pitti> elmo: can you please sync hpoj?
<elmo> pitti: done
<pitti> thankxxx
<mvo> elmo: args, thanks
* mvo hits his head on the table
#ubuntu-devel 2005-08-21
* mvo goes to bed now
<seb128> 'night mvo
<mvo> night seb128!
<whiprush> sa`heal
<tseng> whiprush: wha`meal?
<whiprush>  that was me typing a cheatcode for a game into the totally wrong window. :)
<tseng> cheater!
<tseng> get back to the fridge
<Nafallo> whiprush: gamer!
* tseng starts wesnoth
<tseng> damn gamers
* Nafallo starts gnome-terminal
* jdub is fridging atm :-)
<Nafallo> jdub: thanx for showing up, reminds me to send you mail :-).
<Nafallo> jdub: sent :-)
<Nafallo> jdub: sent to correct address (hopefully) ;-)
<mxpxpod> is gnome-screensaver going to be the default at some point?
<jdub> mxpxpod: maybe not for breezy
<mxpxpod> jdub: is there a way to get it to use xscreensaver hacks?
<jdub> yes, it supports them straight out; you have to mod some config to show them though
<mxpxpod> ah, ok
<dabaR> is anyone awake and a op at #ubuntu? just to take voice from this guy that every few minutes tells us he is away, ClipS
<ogra> mxpxpod, sudo ln -s /usr/lib/xscreensaver/bouboule /usr/lib/gnome-screensaver/gnome-screensaver
<ogra> mxpxpod,  sudo ln -s /usr/share/xscreensaver/config/bouboule.xml /usr/share/gnome-screensaver/themes
<mxpxpod> ogra: ah, thanks!
<ogra> mxpxpod, would give you bouboule :)
<ogra> you can even just link the whole directory
<ogra> s/directory/directorys
<mxpxpod> now, to figure out the dpi problems I'm having with my monitor...
<mxpxpod> firefox fonts are huge and I've heard it has something to do with my xorg config
<mdz> lamont-away: around?
<lamont-away> yeah
<mdz> lamont-away: terranova and royal have either runaway live builds or stale lockfiles
<lamont> mdz: checking
<mdz> thanks
<mdz> king OTOH is chugging away merrily
<mdz> (I just tried to start a build on all three, and the terranova and royal ones are blocked on lockfile)
<LinuxJones> Can someone please pop into #ubuntu and kick ClipS he has notifications on and spams some useless bs every 2 minutes.
<lamont> mdz: terranova is mid-build on one, with one pending....
<lamont> royal I just killed the process, give me a couple minutes, and you can probably run one... 
<lamont> just a minute
<lamont> mdz: looks like royal is all cleaned up - holler if I lied
<mdz> I think I need to wait; apparently I need another cron.daily
<lamont> terranova is compressing one now, btw
<mdz> interesting
<mdz> base perhaps?
<mdz> I can't imagine desktop succeeded
<lamont> note that at 18:15 Pacific, all the chroots update, 20:15 is kubuntu, and 22:15 is ubuntu.  base starts at 00:00 pacific
<lamont> yes, base
<mdz> hmm
<mdz> chroots = buildd chroots, right?
<mdz> the livecd builds create a fresh chroot each time?
<lamont> yeah
<lamont> the livecd is a pseudo-root (aka chroot) built inside of another chroot.  and, uh, yeah, there might be a little bit of a race as the outer chroot is freshened in the middle of you doing something
<lamont> but the bulk of the time is spent either installing inside the inner chroot, or compressing the image, etc.  running binaries that require little, and change very infrequently
<mdz> so I should be clear to trigger all 3 once this upcoming cron.daily finishes?
<shaya> mdz: http://hdaps.sourceforge.net/ you guys should keep on an eye on this
<shaya> hd active protection system support for thinkpads 
<lamont> mdz: I would expect so
<mdz> shaya: mjg59 is probably interested
<mdz> lamont: do the builds not exit+cleanup when they receive a signal?
<mdz> last week I lost the ssh connection for the trigger and the lockfile stayed around forever
<mdz> (until I got infinity to clean it up)
<mjg59> The hdaps driver isn't actually useful until we get ide-queue freezing into the kernel
<mxpxpod> ok, why isn't mkisofs creating ISO 9660 format isos?
<lamont> mdz: ew
<mxpxpod> mkisofs -J -R -iso-level 3 -input-charset iso8859-1 -o blah.iso ma101_v2.4.zip
* lamont discovers a buildd-watcher optimization
<mxpxpod> isoinfo -i blah.iso CD-ROM is NOT in ISO 9660 format
<shaya> mjg59: game input!
<shaya> :)
<mjg59> shaya: Hnngh.
<shaya> mjg59: you never played marball madness? :)
<shaya> or any of those labrynth games
<mxpxpod> has anyone seen that problem on breezy?
<mdz> mxpxpod: it would be better to ask on #ubuntu
<mdz> lamont: also, I'm still getting a 403 on http://king.buildd/~buildd/livecd/kubuntu/current/livecd.kubuntu.manifest
<lamont> mdz: yep.
<mdz> lamont: is that just because it hasn't built in a while?
<lamont> pretty much - see the other window
<mdz> oh, hell
<mdz> all my CD builds have been broken because permissions on little's mirror are broken
<mdz> drwxr-sr-x  2 cjwatson cdimage 4096 Aug 15 20:34 /srv/cdimage.no-name-yet.com/ftp/dists/breezy/main/binary-i386/
<mdz> elmo: still awake?
<mdz> I like how it goes on to build the ISOs and everything and acts like it succeeded
<elmo> unfortunately
<mdz> elmo: can you bail me out?  was planning to spend the rest of the evening trying to make colony 3
<elmo> mdz: I chmod g+w'ed ftp/
<mdz> thanks
<mdz> there is an elmo40 over on #ltsp
<mdz> how confusing
<elmo> I can be elmo400 if it'd help
<mdz> elmo3.14159
* infinity grumbles at his laptop.
<infinity> Why wake up and work, when you can wake up and fight with your computer?  Yay.
<dilinger> infinity: who's winning?
<bob2> not england!
<infinity> dilinger : Well, it's booted now and I'm typing on IRC, which is a distinct improvement.
<calc> anyone know if the lib32 amd64 stuff is going to get libstdc++.so.6 soon?
<dilinger> infinity: maybe you need to move up a weight category.  wanna fight my 280? :)
<fabbione> morning
<infinity> dilinger : I'd love to, but I assume no one's managed to wrangle hosting for it yet.
<dilinger> :/
<dilinger> stephen was working on it, but i haven't heard any status updates lately
<infinity> Meh.  Just ship it to me.  Of course, intercontinental shipping for a machine that big probably costs more than the machine itself is worth.
* calc found the bug report and managed to make oo.o work :)
<mdz> infinity: any idea what happened to the kubuntu livefs build on king?
<mdz> infinity: it exited successfully, but didn't produce a cloop, and the log file sort of ends abruptly in the middle of what otherwise looks like a successful run
<mdz> Setting up ttf-bitstream-vera (1.10-3ubuntu1) ...
<mdz> Fontconfig error: Cannot load default config file
<mdz> Regenerating fonts cache...
<mdz> (END)
<infinity> mdz : Neat.  No idea, but I'll poke at it right now.
<mdz> I hope it didn't run out of disk or anything fun like that
<infinity> 52GB free right now.
<infinity> If it did, it's since righted itself.
<mdz> terranova exited successfully after 43 minutes and left a 0-byte logfile and no cloop
<infinity> Wow, you're getting all sorts of love today.
<mdz> such is my lot
<mdz> these are the rewards of building milestone releases
<mdz> on the bright side, the ubuntu ones actually built and mostly work
<infinity> kubuntu looks uninstallible anyway.
<infinity> mdz : Erm, which build on king died mid-sentence?
<infinity> mdz : All the logs look complete to me.
<mdz> kubuntu
<mdz> livecd-20050816.3-amd64.out
<mdz> oh, whoa
<mdz> it's complete now
<infinity> Output buffering of somee sort messing with your head, perhaps?
<infinity> Anyhow, you have 2 or 3 builds in a row with a log shockingly similar to that one.
* infinity goes to poke at terranova.
<mdz> I checked it well after the ssh exited
<infinity> Weird.
<mdz> yeah, I've uploaded a kubuntu-default-settings now which should fix that
<infinity> Oh, terranova is mid-build right now..
<mdz> oh?  the trigger exited
<infinity> A quick poke at the previous log leads me to believe that you'll fail with the same problem as king, though.
<infinity> The trigger could have exited cause you lost your connection, I suppose.
<infinity> Are you triggering from home, through chinstrap?
<infinity> Cause I lose connectivity over the proxy all the time.
<infinity> And there it fails.  Same as the log on king.
* infinity ducks out to prepare some security builds for pitti before he wakes up.
<mdz> amd64 install, amd64 live and powerpc install are all releasable by Colony standards
<infinity> 3 out of 6 ain't bad... :)
<mdz> if folks could download and test the current i386 daily install and live CDs, that would be helpful
<mdz> infinity: well, 100% of what I've tested so far ;-)
<Lathiat> i'll rsync mine up now
<Lathiat> whats the rsync server?
<Lathiat> rsync::cdimage.ubuntu.com ?
<Lathiat> ah, indeed
<mdz> +1 powerpc-live
<fabbione> hey mdz...
<fabbione> mdz: i saw you are planning to release Colony 3
<fabbione> what's the ETA for it?
<mdz> fabbione: it's 2/3 tested
<mdz> 2/3 tested by me that is
<fabbione> mdz: ok great...
<mdz> it needs more testing by other people
<mdz> like yourself :-)
<fabbione> mdz: meh.. i am still catching up on all the stuff post-holidays but yeah.. i can give i386 a shot
<fabbione> mdz: is i386 published already?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze | Current daily CD is a Colony candidate, please test
* fabbione starts rsync
<mdz> +1 i386-live
<mdz> known bugs: oo.o2/amd64 doesn't work, virtual console switching on the live CD is messed up so you don't see all of the messages, and the keyboard layout on the live CD isn't properly guessed
<mdz> but it's been so long since we had a proper milestone that I don't consider those showstoppers
<mdz> I'd really like to fix the keyboard layout thing on the live CD if I have time, but I expect I won't
<ajmitch> ouch, 5k/sec rsync
<mdz> hopefully that means lots of people are quietly testing ;-)
<ajmitch> I hope so :)
<mdz> I got about 250kbyte/sec on my set
<ajmitch> wget is doing about 30K/sec, so it could just be congestion somewhere 
<fabbione> i guess Global Crossing is actually doomed...
<fabbione> i can't even connect to .uk from .dk
<ds> I just accidentally uploaded a sid package to the ubuntu queue.  does this matter greatly?
<bob2> presumably it will be rejected for having an invalid suite name
<ajmitch> and for being a binary package
<ds> ok, cool
<mdz> and because your key isn't in the keyring
<mdz> that upload is doomed several times over ;-)
<mdz> infinity: my livefs build script just bailed (due to a bug in the script) and given past behaviour, I suspect the running builds, if any, either continued on or didn't clean up after themselves.  could you check?
<infinity> mdz : Any specific arch/target?
<mdz> infinity: kubuntu x3
<infinity> Looks to be still running, yes.
<mdz> all of them?
<infinity> Erm all except for powerpc, cause I can't reach the host..
<infinity> Ugh.
<infinity> You broke royal, didn't you? :)
<infinity> elmo : Royal fell over.  Are we ready for a new kernel yet?  Huh, huh?
<mdz> I sincerely hope elmo is asleep
<mdz> +1 i386-install
<mdz> I am 6/6 with the above caveats
<infinity> He claims to be asleep, yes.  On the other hand, he seems to dilingently review nick hilights when he wakes up.
<mdz> kubuntu/amd64 looks pretty happy
<fabbione> infinity: any idea why redhat cluster suite build log is not on people?
<fabbione> (for ppc)
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/r/redhat-cluster-suite/1.20050815-0ubuntu1/ <-
<mdz> anyone tested the daily yet?
<fabbione> mdz: still rsyncing here.. i have bw issues with global crossing towards uk
<Lathiat> mdz: im getting the i386 daily install and live atm
<Lathiat> rsync is nearly done on the install
<infinity> fabbione : Because it's still building?
<fabbione> infinity: meh.. i did upload it yesterday...
<fabbione> is ppc lagging behind?
<infinity> Hrm.  It built.  Curious.
<infinity> Never got uploaded (the binaries or the log..)
<infinity> Oh well, will fix.
<fabbione> ehehhe
<infinity> Probably has something to do with the 6 gig mail messages we were shoving around a day or two ago due to an infinite loop in a chroot.
<fabbione> ROTFL
<HrdwrBoB> nice work
<Lathiat> heh nice
<Burgundavia> mjg59, that standard format is paying off
<Lathiat> what standard?
<jsgotangco> whoa that's a lot of community entries
<Burgundavia> Lathiat, https://wiki.ubuntu.com/LaptopTestingTeam/Template
<Lathiat> oh
<Lathiat> right
<infinity> Oh, FFS.
<infinity> Maybe if postfix had been RUNNING on ross, the logs would have gotten off the machine.
<mike_douglas> I've creating a package for a python program that uses distutils. In setup.py, the program tries to check for dependencies. Should I remove this part since it isn't needed to build the package and rather specify it under "Depends:"?
<infinity> It's a good safeguard to make sure you got your biuld-depends right, why remove it?
<Lathiat> mike_douglas: it shouldnt be removed, you should have both
<mike_douglas> alright, thanks.
<infinity> fabbione : rhcs rescued, thanks for the heads-up.
<Mithrandir> mdz: it's ok for you if I upload the new casper with unionfs support (and turned on by default) as soon as the kernel udebs for unionfs are in the archive?
<infinity> Mithrandir : You might want to wait until he's blessed the current builds as "good enough" for colony 3. :)
<infinity> (Just a guess, though)
<mdz> Mithrandir: please don't
<Mithrandir> infinity: well, we need a new kernel which needs NEW love so it's not "today", it's more "tomorrow or so".
<Mithrandir> mdz: what about post-colony3?
<fabbione> infinity: thanks
<mdz> Mithrandir: feature freeze was last thursday
<mdz> I thought it was understood that that was a "maybe if we can squeeze it in before feature freeze" sort of item
<fabbione> humpf...
<Mithrandir> mdz: ok.  Do you want me to finish up the automount integration I've started on, or should that wait?
<mdz> Mithrandir: same story; it's time to run with what we have
<mdz> the preview release is sooner than you think
<Mithrandir> mdz: sure, I meant more so it's ready for breezy+1, but if you've got other stuff I should concentrate on, please tell me
<mdz> Mithrandir: first priority is to get oo.o2 working on amd64
<Mithrandir> that's just a missing dependency, but I'll get to that straight away.
<mdz> it's very important
<mdz> after that, fixing the d-i->xorg keyboard autodetection in the live CD
<mdz> basically, the caveats for colony 3
<mdz> which is going to go out despite these warts
<mdz> though I would like at least one confirmation that it works for someone other than me
<Mithrandir> I can test live, but I don't have a spare box for testing installs on yet.
* Lathiat will be testing i386 momentarily
<mdz> I reverted all the debconf-copydb stuff from casper and went back to the old way of doing it, and still it doesn't work properly
<mdz> it's beet bitrotting so long that it's probably been broken in more than one way
<Mithrandir> I'll give it a shot after doing ooo2-amd64
<Mithrandir> ls
<Mithrandir> argh
<doko> good morning
<Mithrandir> doko: should ooo2-core (on amd64) depend on or recommend lib32gcj6?
<doko> Mithrandir: should be put in the same places as java-gcj-compat, i.e. -base. you can use most things without java in -writer. If you depend on it, then you should add java-gcj-compat as well.
<Mithrandir> doko: so we should really have a java-gcj-compat32?
<doko> Mithrandir: No, we don't need a 32bit java interpreter at the moment
<pef> morning
<doko> Mithrandir: -core should depend on lib32stdc++6
<Mithrandir> doko: already done
<infinity> 19 out of 20 hunks FAILED -- saving rejects to file
<infinity> That's what I like to see, oh yeah.
<pitti> Good morning
<fabbione> hey pitti
* infinity starts applying patches by hand.
<Lathiat> ah nice
<mdz> I don't see language-selector in any menu
<mdz> where should it be?
<mdz> oh, it's there on the live CD
<mdz> but not on my desktop for some reason
<fabbione> mdz: i am going to upload the new ocfs2 tools as soon as you release Colony 3
<fabbione> mdz: the kernel stuff will follow immediatly after
<mdz> gah
<mdz> powerpc live CD builds are broken
<mdz> presumably due to royal being fucked
<mdz> infinity: I don't suppose we have a fallback plan
<infinity> mdz : Do we have one?  No.  Can I work something out in the short term?  Probably.
<mdz> infinity: if we can put the cloop image at some other URL, I think I can make that work
<infinity> Right, but that depends on me building said image on another machine first.  That's the rub.
<infinity> Let me go fiddle with adare.
<mdz> the image we have is fine; I don't need to build a new one
<mdz> in fact I don't want to
<mdz> because I tested that one
<mdz> I just need to wrap it up in a new CD
<infinity> Oh.  Well, then, do you have a copy of it somewhere?
<mdz> it's in the .iso on little; I can extract it from there
<infinity> Then I guess you're set. :)
<mdz> if you can put it at <somehost>/~buildd/livecd/ubuntu/current/blahblah that would make it trivial for me to get it going
<mdz> otherwise I need to mangle the scripts
<infinity> Sure, toss it on chinstrap with an MD5SUM, and I'll stick it on adare.
<infinity> If you do need new live images, however, it looks like adare is still (more or less) configured to make that happen, so holler if you need something freshened up before royal comes back.
<mdz> infinity: http://chinstrap/~mdz/filesystem.cloop
<infinity> http://adare.buildd/~buildd/livecd/ubuntu/current/livecd.ubuntu.cloop  <-- That good enough for you?
<mdz> looks right
<mdz> let me get an md5sum to confirm
<mdz> yep
<infinity> 1b9ee5f74f4041baade173264e96d613  current/livecd.ubuntu.cloop
<mdz> yeah, I just checked it
<infinity> :)
<infinity> Rock.
<infinity> Back to being pitti's slave then, if you're done with me.
<mdz> gah, I've been preempted by colin's scheduled daily build
<mdz> and I think that one generates jigdo files, too
<mdz> which means it takes AGES
<infinity> Never try to outsmart cron?
<infinity> Assuming his daily started when the archive was in the state you wanted it, it should be good anyway, no?
<infinity> Or was it too early?
<mdz> I think I've probably been screewd by the livefs builds too
<mdz> well, it's an install CD build
<infinity> Ahh.
<mdz> I don't even need an install CD build; the install CDs are good
<mdz> but we can't do two CD builds in parallel
<infinity> Bah, who needs infrastructure anyway.
<mdz> I'm going to have to do this in the morning
<infinity> You'll probably be happier about it then, anyway.  Staying up late and banging one's head against the same wall tends to hurt after a while.
<mdz> oh, that's the best part, it's an unending sequence of entirely different walls tonight ;-)
<infinity> Well, at least you've had variety, then. :)
<Mithrandir> mdz: ooo2-amd64 which should work out of the box just uploaded, I'm going to start fight the xorg-keyboard problem now.
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze!
<mdz> Mithrandir: ok, then tomorrow we can do new install and livefs builds
<mdz> and 2 of my 3 caveats about colony 3 can be removed
<pitti> Moin seb128 
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze! | Colony 3 will release today: please don't break anything
<paolo> 'morning! :-)
<infinity> mdz : Oh, like THAT will work.
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze! | Colony 3 will release today: don't break anything
<mdz> infinity: better?
<Lathiat> haha
<infinity> mdz : Something more like "seb128 : Please stop uploading for 2 days" might be better.
<seb128> hey pitti mdz infinity
<infinity> mdz : I'll pester elmo about getting royal alive as soon as I see him, but if it's a no-go, adare will be ready for you by tomorrow.
<mdz> infinity: I am fairly confident that I know which bits need twiddling in order to do royal->adare on my side
<seb128> infinity: he, that's not fair, I'm not uploading a lot for some days because of colony 3 :)
<infinity> mdz : Heh.  Good.  Then I just need to make sure it's ready to build breezy livecds.  Looks like the last live run adare did was hoary.
<fabbione> oh well.. time to upload a new kernel with ABI change...
* fabbione hides from mdz
<pitti> fabbione: just sent you a reply, everything settled?
<mdz> fabbione: I know where you live
<fabbione> pitti: looking at it now..
<fabbione> mdz: that will give me at least 12 hours to hide in another corner of the world :P
<mdz> fabbione: I don't need to do my own dirty work
<fabbione> mdz: eehhehe
<seb128> fabbione: if you go with a new linux I go with the new cairo and its soname change, he can't track 2 people in the same time :p
<fabbione> seb128: never underestimate the dark side of the force, young padowa
<mdz> good night
<fabbione> night mdz
<infinity> mdz : 'Night.
<mdz> I will sleep with one eye open to watch you two
<fabbione> pitti: dude.. the stuff you did send doesn't match what i have
<jsgotangco> lol
<mantiena> mdz, what is Ubuntu Express status ?
<seb128> 'night mdz!
<pitti> fabbione: hm? it's still the same list, I added two new issues (one not for you) and a CAN
<pitti> night mdz
<Burgundavia> jdub, mako if you need help with admining ubuntu-users, contact me
<fabbione> pitti: meh ok.. but CAN-2005-2457 is not part of zlib...
<fabbione>         . Fix check input buffer size in zisofs.
<pitti> fabbione: zisofs doesn't use zlib?
<pitti> meh, ok, I clean up the can assignments
<fabbione> "This uses the new deflateBound() thing to sanity-check the input to the
<fabbione> zlib decompressor before we even bother to start reading in the blocks.
<fabbione> "
<fabbione> it's an "extra" step on top of zlib
<fabbione> pitti: doesn't really matter.. it's all fixed here..
<pitti> ok, thankjs
<fabbione> i need to check one thing only...
<fabbione> pitti: 2456 is for the XFRM stuff...
<fabbione> did herbert extra patch got a CAN or is still part of 2456?
<jdub> Burgundavia: *boggle*
<fabbione> or should we mark it as stolen from head?
<Burgundavia> jdub, both you and mako travel a lot. I don't. Makes sense
<pitti> fabbione: ah, you mean Herbert's additional capability check?
<fabbione> pitti: yes
<fabbione> i understood that 2456 was for that patch
<pitti> fabbione: I don't have a CAN for this one yet
<jdub> Burgundavia: i was just thinking about how best to ask for helpers
<fabbione> pitti: ok.. so i will mark it as XXXX :)
<jdub> Burgundavia: like, only an hour ago or so
<fabbione> no big deal
<pitti> fabbione: yes, it's an additional check in the same coe
<pitti> code, even
<fabbione> pitti: yes i saw that...
<\sh> does anybody has a nice pointer to some good docus about creating udebs?
<Burgundavia> jdub, I recently sent 2 messages for -users, which I don't currently follow. Then I realized that they will probably never hit the lists because you and mako have no time to approve it
<jdub> yep
<jdub> if you don't follow it, do you really want to moderate it?
<jsgotangco> lol
<jsgotangco> i bet ubuntu-users has a ton of spam
<Burgundavia> jdub, I am about to start following it
<jdub> heh
<Burgundavia> indeed
* jdub has roughly given up
<jdub> it's fucking insane traffic-wise
<jsgotangco> i only see a fraction in ubuntu-doc but its getting on my nerves sometimes
<jsgotangco> its usually chinese text
<jsgotangco> heh
* Burgundavia thinks that with bugzilla+-users+breezy-changes == crazy
* Lathiat likes -devel,-sounder,-changes
<Burgundavia> oh, and that and about half the gnome mailing lists
<Treenaks> jdub: have you seen my planet-addition-request?
<jdub> Treenaks: yeah, but been travelling :-)
<Treenaks> jdub: ah, didn't know that :)
<jsgotangco> mmm tuxmagazine poll
<Treenaks> jdub: you're back on the right side of the date-line now? :)
<jdub> i think it's regarded as 'left' ;)
<Treenaks> jdub: hm.. you're right.. the left side is the right side :)
<jdub> i should put nicks on planet ubuntu
<jdub> i should also not use plone css
<jdub> bah, now you've got me fixing things :)
<Lathiat> mmm plone
<Lathiat> ask davyd about plone
<Treenaks> it should also underline links :)
<jdub> it'll do that once i kill plone css
<jamesh> jdub: a good proportion of launchpad.css is designed to undo plone.css ...
<jdub> heh
<fabbione> pitti: CAN-2005-2548 is only for warty. Both breezy and hoary are not affected (at code level at least)
<\sh> jdub: First 'nick' Lastname is good change for the planet
<jdub> \sh: i'll probably do it the same way as planet gnome
<\sh> jdub: rock :)
<Treenaks> jdub: btw, planet is _easy_ :)
<Treenaks> jdub: running a few of my own now too
<jdub> Treenaks: cool :) yeah, love it :)
<seb128> infinity: are some CD builds running and we should upload anything, or pushing new poppler/evince is fine as far as it doesn't break?
<pitti> fabbione: I know, it says "Breezy: n/a, Hoary: n/a, Warty: vuln"
<pitti> fabbione: should mean "not affected", sorry for the acronym
<carlos> pitti, morning
<fabbione> pitti: meh i read: Breezy: n/a, Hoary: n/a, Warty: n/a
<pitti> Hi carlos 
<carlos> pitti, I was able to generate .po files for firefox
<pitti> cool
<carlos> pitti, but we will need en-US.xpi included into the language pack package
<carlos> pitti, it's needed to get from it the msgids
<pitti> carlos: sure, we can include it into m-f-locale-en :-)
<carlos> well
<carlos> pitti, it's already included by default into mozilla tree
<pitti> carlos: but we can always extract it from the main deb, right?
<carlos> pitti, and I don't need it installed, just available from the source package
<pitti> carlos: ok, it should already be in the source
<carlos> pitti, Not sure if the main package has the .xpi package, I see a .jar file (the file that the .xpi contains)
<carlos> but the .jar file does not work, we need the .xpi
<pitti> carlos: ok, that shouldn't be a problem
<carlos> perfect then.
<pitti> carlos: let's take this into a private discussion to not clutter up the chan
<carlos> I don't have anything else to talk about now, I'm going to dump my research into the wiki and will take later, ok?
<\sh> wow...another new ubuntu user in this company
<_koke> mako: have you already discovered how to make sangria??
<Treenaks> _koke: it's on wikipedia
<Treenaks> _koke: (the recipe, that is)
<_koke> :D
<Lathiat> bugs with livecd ->
<_koke> mako: look at http://olea.org/la-receta-de-la-sangria/
<Lathiat> no network setup
<_koke> for a graphic one :9
<Lathiat> asks for X resolution, doesnt include my resolution in the list of defaults (had 1024x768, 640x480 selected, im 1680x1050)
<Lathiat> -> has a notice about having to restart becausea  new kernel was installed
<Lathiat> -> the "please press enter to activate this console" isnt cleared before switching to it to boot
<Lathiat> and thats it
<mdke> mjg59, ping?
<Nafallo> doko: pong
<mvo> anyone of the backports guys around?
<Lathiat> mdz: do you want to know about livecd bugs?
<seb128> he's sleeping
<Lathiat> ah ok
<seb128> but I guess he wants to know about bugs when he wakes up
<Lathiat> hrm also when i alt-tab to firefox the window goes black until i stop alt tabbing or alt tab off that window
<Lathiat> indeed
<Lathiat> was more wondering who the right person to hassle is
<Lathiat> also totem doesnt start
<Burgundavia> mvo, if the user breaks something with backports, you can close the bug
<seb128> Lathiat: doesn't start, like "crash"?
<mvo> Burgundavia: well, I would like to have givem him advice to fix the situation. it's the old "python-xdg" backport problem
<Burgundavia> mvo, you can do both. and point them at malone, as we support ~hoary backports now
<mvo> Burgundavia: oh, nice, thanks
<Burgundavia> mvo, done for you
<mvo> Burgundavia: is there documentation somewhere how  users are supposed to assign a bug against a backports repository? I would like to point my bugreport to it
<Lathiat> seb128: errors out about not being able to create initialize video
<Lathiat> seb128: but also has some ugly deref glib errors on the console
<Lathiat> also, the reboot item from gdm doesnt work
<Lathiat> and what kernel module makes /dev/input/mice because for some reason when i boote back to my system i dont have one
<Treenaks> Lathiat: restart udev
<Lathiat> Treenaks: what caused that?
<Lathiat> (cause it makes X fail to start)
<Treenaks> Lathiat: I had that last week, but it's solved now for me
<Treenaks> Lathiat: so I have no idea..
<Lathiat> weird
<Burgundavia> mvo, https://wiki.ubuntu.com//BugResponses
<Burgundavia> mvo, last response about universe, change to backports after copying
<ogra> mvo, does mdz know about #13496 ? 
<ogra> mvo, i heard he plans to roll colony 3 after he gets up today
<Burgundavia> ogra, you have about 6 hours to fix it then. It is 2am here
<mvo> thanks Burgundavia!
<Burgundavia> mvo, np
<Burgundavia> ogra, always trying to helpful ;)
<sivang> morning all
<mvo> ogra: I don't know if he knows (or not), but it shouldn't be hard to fix aptitude
<pitti> Hi ogra
<ogra> ah, ok
<ogra> moin pitti
<sivang> hey ogra ,pitti 
<sivang> Burgundavia: are you hungry already ? :)
<pitti> ogra: can you please merge the outstanding Edubuntu reports to https://wiki.ubuntu.com/UbuntuMainInclusionQueue?
<ogra> pitti, sure...
<pitti> thanks
<mvo> pitti: what do you think about adding a wordlist package to language-support-$lang? (#2132)?
<pitti> sure, no problem
<pitti> mvo: you mean wngerman, for example=
<pitti> ?
<mvo> pitti: yes
<seb128> does anybody has the spellchecking stuff working atm with evolution/gedit by example?
<seb128> the list of dicts are empty here
<sivang> seb128: the saem ehre
<sivang> err
<sivang> seb128: the same here
<sivang> bon jour seb128  :)
<seb128> hi
<sivang> seb128: it also finds ANY word as mispelled word
<seb128> that's because it has no dict
<seb128> who is working on spellchecking tools? doko?
<doko> seb128: yes, Nafallo is doing some work as well
<seb128> doko: any idea of why no dictionnary is listed by evolution/gedit/...
<seb128> I've aspell and aspell-en installed
<seb128> aspell-fr too
<doko> seb128: no
<seb128> k, thanks anyway
<seb128> Nafallo: maybe you know about the issue?
<sivang> seb128: I'm in a chroot, does it matter?
<Nafallo> seb128: aspell-en should work fine, aspell-fr is being worked on right now :-).
<seb128> Nafallo: does evolution or gedit list an english dictionnary for you? they don't here
<seb128> ii  aspell         0.60.3-5       GNU Aspell spell-checker
<seb128> ii  aspell-en      6.0-0-5        English dictionary for GNU Aspell
<seb128> $ aspell dicts
<seb128> en
<seb128> ...
<Nafallo> seb128: they do here, with same versions
<seb128> bah
<seb128> I had some bugs about that already
<seb128> that's weird
<seb128> grumpf
<seb128> after moving ~/.aspell* that works fine
<seb128> and for french too
<\sh> hmmm....trying to build bittorrent-gui against libwxgtk2.6-0-python...lets see...
<seb128> $ cat .aspell.conf
<seb128> lang french
<seb128> this file breaks the list of dicts
<Lathiat> i hate that stupid gui, it wont let you get more than 3 torrents at once, wont let you run a torrent seeding past the configured ratio and keeps nagging me to donate
<seb128> Nafallo: .aspell.conf with "lang french" breaks the list of dict, just moving it somewhere else fixes the issue
<\sh> Lathiat: and I was confused why bittorrent package is in main, and one of the resulting bin packages is in universe
<Lathiat> \sh: heh
<JaneW> does anyone know what's happeneing, if anything, with the ShtoomVoip BreexyGoal, was listed as Thom's...?
<JaneW> Breezy I mean
<ogra> ARGH
<\sh> JaneW: yes
<Lathiat> i think thats been deferred
<ogra> who edits the main inclusion queue ? 
<JaneW> \sh:?
<\sh> JaneW: doesn't look good...and I need to find a new machine where I can setup a new SIP Express Router
<JaneW> Lathiat: oic...
<pitti> ogra: not me
<\sh> so it will be breezy+1
<JaneW> ShtoomVoip is still listed as WIP - must I make it deferred?
<pitti> ogra: you have the lock ATM
<JaneW> and does it have a new owner? \sh? you perhaps?
<Lathiat> \sh: im willing to help out with that goal
<\sh> JaneW: no...it's thom..I just worked on the server base
<Lathiat> as i have some experience etc with voip stuff
<JaneW> ok, is thom still active on it?
<Lathiat> i thought thom left?
<ogra> pitti, yes, but i ran out inbetween... 
<\sh> woot?
<JaneW> Lathiat: indeed he did
<pitti> ogra: I made a quick change recently, but I didn't see a lock at that time; sorry
<JaneW> Lathiat: that's why I am a little confussed
<\sh> JaneW: please update me 
<JaneW> \sh: on what?
<\sh> JaneW: what is with thom?..when he left..
<JaneW> lemme find out more...
<ogra> pitti, nope, it was Riddell-awa, i just wasnt fast enough
<\sh> JaneW: cause when he's not around anymore for this..."dear god, I don't have any clue on shtoom"
<JaneW> \sh: well it seems you're IT ;)
<mjg59> mdke: Hi
<JaneW> thom confirmed that he is not working on it... so it currently has no owner or action
<\sh> JaneW: ok...
<ajmitch> lucky \sh :)
<ajmitch> btw hi ;)
<\sh> JaneW: so make it breezy+1
<mdke> mjg59, hi. I got an email from a guy with a T43, although with a slightly different spec. He asked what is the best way for him to help, should we work on the same wiki page? or should he do a separate one?
<\sh> and upgrade the owner to \sh
<JaneW> \sh: seriosly can I put your name there, AND yes that was my next question must I mark it as deferred?
<mjg59> mdke: A separate one might be good for now
<\sh> JaneW: yes seriously and yes to breezy+1
<JaneW> \sh: ok cool thanks - and congrats :)
<ajmitch> \sh: it's good to see people volunteer :)
<mdke> mjg59, cool. he's the third guy who has emailed me with help about the thinkpad :D what a community...
<\sh> hmmm
<\sh> what did i do..
<\sh> anyways
<ajmitch> \sh: signed away your soul, it's best if you don't think about it
<jsgotangco> its best to be silent as well *wink*
<Lathiat> \sh: well if your interested on working with it.. give me a yell.
<Lathiat> unfortunately shtoom has terrible latency
* ajmitch is sad that selinux will have to be deferred - was too much code to get reviewed in time for FF
<Lathiat> im not sure its suitable
<Lathiat> that or need to figure out why
<\sh> ok...I need an appartment in durban, I need some furniture, fast internet connection and a visa and a working permit ... 
<Lathiat> to my local asterisk server an echo test has 2s latency, with a hardware phone its instant
<\sh> JaneW: can you arrange this for me in ZA ,-)
<JaneW> \sh: np
<\sh> JaneW: ah...and a new job of course..and some tickets for the plane..
<JaneW> \sh: anything else?
<JaneW> :P
<\sh> JaneW: a new life *lol*
<ajmitch> \sh: you won't need a life, you'll be too busy hacking
<JaneW> \sh: I need one of those
<ogra> pitti, hmm, after i added all edubuntu stuff at the top of the lists, had 2 heart attacs because i lost the lock two times, i just recognized someone already has put all edubuntu stuff there alerady 
<\sh> JaneW: one of those?
<JaneW> \sh: new life - mines a bit frayed and burned out atm
<pitti> ogra: is everything really already promoted?
<ogra> tuxpaint: MainInclusionReportTuxpaint (Edubuntu, cannot be promoted until sdl-image1.2 is in main) ???
<pitti> ogra: or did you pick the wrong queue?
<ogra> pitti, thats sdl-ttf2.0
<\sh> JaneW: oh yes, I know this feeling...
<ogra> not sdl-image1.2
<pitti> ogra: please put the stuff in the unreviewed queue, not in "accepted and promoted"
<\sh> JaneW: take some time of.. play with husband+kids, have a trip to mauritius
<ajmitch> pitti: about selinux - pam's patch was big & intrusive, and passwd needed recoded to handle security context for /etc/shadow properly :)
<JaneW> brb coffee break, but please keep the goal updates coming - we need to get them all grean by the time mdz wakes up ;)
<ogra> pitti, so only the 5 left from desktop and the server stuff ? ok
<JaneW> s/grean/green
<pitti> ajmitch: we are past feature freeze, so no selinux for breezy anyway :-(
<JaneW> \sh: I'd LOVE to do that
<ajmitch> pitti: I know, just explaining why I didn't get it to you for review before FF :(
<\sh> JaneW: me too (c) aol.com...
<\sh> lunchtime now...laters ladies & gentlemen
<Treenaks> \sh: good idea :)
<pitti> seb128: https://wiki.ubuntu.com/MainInclusionReportCdrdao
<pitti> ogra: I also need to edit the queue...
<seb128> pitti: thanks
<pitti> seb128: does it work? does the /dev/cdrecorder issue (the malone bug) actually hurt?
<seb128> the duplicate stuff from nautilus works, so I guess it doesn't hurt no
<seb128> I'll play with that though
<pitti> seb128: I think we should definitively fix the O_EXCL thing
<seb128> hum, yeah
<marco_g> hi
<pitti> ogra: are you still actually editing?
<ogra> pitti, done
<marco_g> Is there an ubuntu team/channel for graphical designs?
<Mithrandir> marco_g: yes and yes, #ubuntu-artwork (iirc)
<tseng> https://wiki.ubuntu.com/ArtTeam
<marco_g> I am working on GRUB2 and I don't have a clue about grapical design, interface design, etc.
<marco_g> Mithrandir: Cool, thanks :)
<marco_g> tseng: Thank you.
<ajmitch> hey marco_g 
<marco_g> hey ajmitch :)
<pitti> ogra: please do not put reports for packages that are still in universe into "accepted and promoted"
<pitti> ogra: i. e. gartoon
<ogra> pitti, i didnt
<ogra> i didnt touch accepted and promoted at all 
<pitti> ogra: hm, who did? 
<ogra> looking ate the history....
<ogra> pitti, thats what i meant, i put my stuff on top and fter 10 mins formatting work i recognized they were at the bottom already and reverted my change
<pitti> ogra: then this was rather an accident, I suppose
<ogra> but i cant see it in the history...
<ogra> pitti, err, why got gcompris promoted already ? libassetml0 is missing....
<pitti> ogra: anastacia will detect thus
<pitti> this
<ogra> sure, but it wont build :/
<pitti> not?
<ogra> libassetml0 is a build dep... gnuchess is only a dep
<AndyFitz> tseng,  cheers for the ref
<pitti> ogra: hm, ftgl does not have a dynamic library?
<ogra> pitti, i dont see one...
<ogra> pitti,  FTGL binds OpenGL and FreeType together in order to offer and easy to use
<ogra>  and flexible text rendering library. 
<ogra> it seems to only glue between two existing libs
<pitti> ogra: yes, but packages which b-dep on it statically link against libftgl.a
<pitti> ogra: if this were a security sensitive lib, it would be a reason for rejection
<ogra> yes, it produces a -dev binary.... odd
<pitti> however, it seems uncritical, so I approved it
<pitti> this also resolves blender
<ogra> i wonder how such packages get into debian
<ogra> yay, thanks pitti :)
<ogra> pitti, please dont touch schooltool and friends for now, it seems mark approved a new upstream version, i have to see the packages first....
<pitti> ogra: can I reject www-config-common for now, and you remove the dep and sort this out with Adam?
<ogra> pitti, *sigh* yes ... :)
<pitti> ogra: and I can remove the Edubuntu subpage link?
<ogra> yup... its all on the queue site
<Nafallo> sabdfl: ping
<infinity> seb128 : Not sure if anyone else answered you, but go ahead and upload your fixed packages iff you're sure they won't break.  If you catch a build at the wrong time, there's nothing stopping me from restarting it.
<pitti> Riddell-awa: here?
<seb128> infinity: k, thanks
<mvo> pitti: isn't riddel at kde conference or something?
<pitti> yes, but he seemed to answer some questions
<mvo> ogra: normal ubuntu daily install has the same problem as edubuntu (#13496)
<mvo> pitti: ah, k
<mjg59> \sh: Could you possibly file bugs on the problems you're having with Breezy?
<ogra> mvo, yes, i suspected that... i already mailed mdz about it so he doesnt wildly start rolling colony images :)
<mvo> ogra: thanks
<doko> Mithrandir: s/java-gcj-compat/lib32gcj6/  , not added?
<Mithrandir> huh?
<doko> Mithrandir: your changelog
<Mithrandir> doko: it would be very useful if you stuck some pronouns and verbs into your sentences. :-P
<doko> Mithrandir: substituted java-gcj-compat with lib32gcj6, not added it?
<doko> Mithrandir: oh, in OO.o2-amd64
<ogra> infinity, a minute about wwwconfig-common ? 
<pitti> let him fix PHP first! :-)
<ogra> heh
<pitti> (just kidding)
<ogra> probably someone else has a opinion, if i create the postgres db without wwwconfig-common, i have to use sudo -u postgres psql ... in the postinst... or is there any other way ? i dont want to make moodle depend on sudo...
<pitti> ogra: that's my playground
<infinity> ogra, pitti : Give me 10-15 mins to grab and eat some food, then ping me again.
<pitti> ogra: I /msg
<doko> Mithrandir: $ strings /usr/lib/openoffice2/sunjavaplugin.so | fgrep gij
<doko> bin/gij
<doko> bin/gij-4.0
<ogra> yup
<ogra> infinity, i'm fine with the mysql stuff, i'll get it sorted... its enough if you just review it in the end ;)
<Mithrandir> doko: I have no idea what you are trying to tell me, could you _please_ speak in complete sentences rather than throwing seemingly random pieces of information at me and trying to make me puzzle it together myself?
<infinity> ogra : Then get pitti's advice on the pgsql stuff, yes.  And you want su, no sudo.
<infinity> s/no/not/
<ogra> infinity, i want neither ;)
<chmj> shackan: ping 
<pitti> infinity: right
<doko> Mithrandir: It's the same terse style as you did use in your changelog for the OO.o2 amd64 upload. I did ask for the reason, why you substituted the java-gcj-compat dependency with lib32gcj6 ? What is unclear=
<doko> s/=?/
<Mithrandir> doko: no, there wasn't a single "why" in any of the things you said.
<doko> I didn't mean "when" ...
<Mithrandir> doko: I understood you that lib32gcj6 was needed for java to work correctly with ooo2-amd64, but if that wasn't your intention, why can't you just say that?
<\sh> mjg59: ping
<doko> Mithrandir: I did say that, please say http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/009674.html
<doko> s/say/see/
<\sh> mjg59: I will start to file bugs during the weekend..when I get my usb dvdrom to test the rest of the list (dual boot, resizing etc.)
<mjg59> \sh: Ok, cool
<mjg59> Could you link to bugs about the bluetooth, acpid and ethernet problems?
<JaneW> mjg59: ping
<JaneW> mjg59: can you give me a line or 2 to use to update the LaptopMission goal please? It's still WIP right?
<Nafallo> daniels: morning :-)
<Lathiat> Nafallo: heh
<Nafallo> Lathiat: what? :-)
* daniels grunts.
<ogra> Nafallo, its late evening in .au ;)
<Nafallo> baah. listen to jdub, it is _always_ morning! :-)
<Nafallo> daniels: when will xmodmap hit the archive? :-)
<Treenaks> Nafallo: no, that's only in Australia
<Nafallo> Treenaks: in my appartment to ;-)
<daniels> Nafallo: i don't know
<Nafallo> daniels: oki. I will have to just /try/ to read me friends swedish-without-correct-chars a while longer then ;-)
<Nafallo> s/me/my/
<mjg59> JaneW: Laptops are being sent out, we're getting feedback
<Simira> mjg59 : the laptops for the testing team... are they models where there are known to be problems...?
<mjg59> Simira: Nope
<Simira> mjg59 : Ok. I've got lots. Haven't even managed to get a decent installation yet...
<mjg59> Simira: Cool. Please file bugs.
<Simira> mjg59 : and I've tried 3-4 times each day since friday... bugs are coming...
<mjg59> Simira: Heh
<JaneW> mjg59: ok, thanks
<Treenaks> Simira: breezy is/was very broken until a few days ago
<Simira> Treenaks : I downloaded a new version yesterday. Same faults.
<Treenaks> I'm still waiting for shipment
<ajmitch> Treenaks: a few people are, I think
<\sh> mjg59: sure :)
<pitti> doko: is libhsqldb-java still required in main?
<\sh> Simira: what laptop do u have?
<Simira> \sh : HP nc8230
<JaneW> is anyone working on Xen?
<Mithrandir> JaneW: Fabio has done some stuff on it, at least
<\sh> Simira: what r the problems? 
<Simira> \sh : uhm... want a list? If I try to install without turning off frambuffer, the screen goes black shortly after loading installation tools. The laptop won't reboot automatically after the first part of installation (ctrl-alt-del doesn't work either), and then it halts on different points of loading and installing packages. Mainly. 
<\sh> Simira: hoary or breezy colony 2?
<Simira> \sh: I use the daily build of breezy.  
<\sh> I think it's time to spend some minutes on "how to build installation media for ubuntu" and provide "special laptop kernels" ,-)
<\sh> Simira: try colony 2 :) this is my testing env
<Simira> \sh : ok, what's the difference? Laptop kernel? ;)
<\sh> Simira: Oh it starts with: have a laptop without a cd/dvd drive  and ends up with "kernel oops when wifi interface is switched off" ,-)
<ajmitch> \sh: ideally there'd be no need for a different kernel :)
<hunger> \sh: when I asked about laptop kernels I was yelled at for being stupid;-)
<siretart> fabbione: shall the sparc get linux 2.4 or 2.6 kernels?
<fabbione> siretart: 2.6.12 please
<fabbione> siretart: use the Debian packages.. they work fine
<fabbione> there is no need to compile anything
<\sh> ajmitch, hunger: right..but as fabbione told me, some drivers or patches are refused by upstream...and when I checked the patches for the portege laptop, they were all refused by upstream ,-)
<fabbione> or i will install the ubuntu ones..
<siretart> ok. will install with 2.6 sarge d-i
<hunger> \sh: with the centrino being so common nowadays I still think that is a good idea (at least having a pentium-m optimized kernel)
<fabbione> either way works for me
<siretart> ok
<doko> pitti: yes
<fabbione> siretart: note that if you install sarge, we can upgrade to breezy ;)
<hunger> how is network configuration currently done in breezy? the "debian" way does no longer work for me and network manager just seems to sit there doing nothing, too.
<siretart> fabbione: whatever suits better, you just have to tell me ;)
<fabbione> siretart: it's the same for me.. go for sarge..
<fabbione> we will touch delicate parts together
<hunger_> Was there a comment to my network question? My compi crashed once again:-(
<mvo> ping pitti
* pitti waves to mvo
<hunger_> linux is just so damn unstable on this box... or is it X?
<ogra> pitti, language-pack-gnome-en, language-pack-gnome-en-base seem to be MIA on the CD images is that intentional ?
<pitti> MIA?
<mvo> missing
<ogra> missing in action :)
<Nafallo> in action
<mvo> is that a seed problem?
* Nafallo ad-hocs mvo *
<pitti> ogra: I know the Debian term, but it didn't fit :-)
<Nafallo> :-)
<pitti> mvo: yep, these packages are not seeded yet
<pitti> mvo: thanks for the reminder
<pitti> mvo: I will fix the support packages now, then seed the rest
<mvo> pitti: thanks
<pitti> grmpf
<pitti> # apt-cdrom -m add
<pitti> Found 0 package indexes, 0 source indexes and 1 signatures
<pitti> edd: Unable to locate any package files, perhaps this is not a Debian Disc
<pitti> erm, sorry, my fault
<JaneW> what happened to FontHandling?
<ajmitch> JaneW: it didn't really get going
<Seveas> elmo, sabdfl, the CC meeting wants to be started, please come to #ubuntu-meeting :)
<JaneW> ajmitch: pity - so it is doomed to be deferred?
<infinity> hunger_ : network-manager is currently a no-go.  As for issues with getting your network configured via the normal means, that's most likely an #ubuntu question.
<pitti> Mithrandir: you know that openoffice.org2 is uninstallable in breezy?
<hunger_> infinity: The config did work till after the update I did friday night after spending a week AFK.
<hunger_> infinity: I was wondering whether some NM-related changes went in or something.
<daniels> JaneW: also, XRoadmap should be marked as deferred
<hunger_> infinity: And somehow you never get a decent answer to breezy-questions in #ubuntu anyway.
<JaneW> daniels: ok
<Mithrandir> pitti: it installed fine for me?
<daniels> JaneW: i assume firefox is just going to shower me in hate, so if you could please mark that as deferred, that'd be great, thanks
<Mithrandir> pitti: what does it fail on?
<JaneW> daniels: np, doing it right now...
<pitti> Mithrandir: I currently tried in a clean and up to date breezy amd64 dchroot
<daniels> JaneW: ta
<ajmitch> JaneW: sad to say, yes
<JaneW> daniels: but wasn;t that what was holding the build up? or was that just X not a whole roadmap?
<infinity> JaneW : The whole X roadmap hasn't been deferred, just parts of it.  Where it currently is is a (reasonably) useable state, just not quite where we wanted it to be.
<JaneW> daniels: reason? Deferred to Breezy+1 - no time to complete for Breezy?
<JaneW> daniels: ok well then part will stay in WIP, and I'll add a deferred section
<Lathiat> daniels: what will firefox shower you in hate about?
<daniels> JaneW: what's done now is done, and everything else has been deferred to breezy+1
<daniels> Lathiat: segfaults every time I try to edit hte wiki
<JaneW> daniels: ok, the part that's done , is it still being tested or is it 100% complete?
<Lathiat> daniels: oh, right
<daniels> JaneW: still a couple of warts but largely complete
<JaneW> daniels: ok, I'll make it implemented - when the warts are gone it can be complete ;P
<daniels> JaneW: heh
<sivang> can someone please remind me the order of dpatch-edit-patch args? $1 = new patch, $2 = last old in 00list or vice versa?
<Mithrandir> pitti: well, what does it fail on?
* daniels looks suspiciously at dpatch-edit-patch --help.
<pitti> Mithrandir: I /msg'ed you
<\sh> daniels: need help? ,-)
<daniels> \sh: hah
<sivang> daniels: lol, I wasn't aware it had an help option :)
<Mithrandir> mdz: can you promote libstdc++6 to main?  It's needed by ooo2-amd64
<ogra> Mithrandir, main inclusion report ....
<infinity> Mithrandir : Uhm, it's in main.
<infinity> Mithrandir : Half the archive depends on it.
<Mithrandir> uhm
<Mithrandir> mdz: lib32stdc++6, I meant.
<Nafallo> *s*
<infinity> That makes more sense. :)
<Mithrandir> heh
<pitti> doko: any idea why so many aspell packages are uninstallable?
<doko> pitti: we are fixing these at the moment
<pitti> doko: the installable ones depend on aspell, the uninstallable ones on libaspell15c2, is that the reason?
<Nafallo> pitti: they need a transition which I've started to help out with. they will be fine ASAP (girlfriend leaves today ;-) )
<pitti> doko, Nafallo: ok, great
<pitti> thanks
<doko> Mithrandir: should lib32gcj6 be included in main as well?
<Mithrandir> doko: I guess that makes a bit of sense, yes.
<doko> elmo: please sync python-tz from unstable (2005i-2)
<mjg59> mdz: I have a grub patch for you
<Lathiat> i just put a ubuntu ppc livecd in my x86 laptop
<Lathiat> is it normal to have a screwed directory listing?
<Lathiat> all items are '????????'
<HiddenWolf> Lathiat, why the heck would you want to do that? :P
<Lathiat> HiddenWolf: trying to see if any more of my ubuntu cds had the wrong image pressed on them
<ajmitch> Lathiat: hoary live cd?
<Lathiat> ajmitch: yeh
* ajmitch checks
<Lathiat> its ok i ejected adn stuck it back in and its fine
<Lathiat> weird
<ajmitch> odd
<Lathiat> ah i see what happened
<Lathiat> vmware took the dont eject bit off
<Lathiat> and it was mounted
<Lathiat> so i replaced the cd
<ajmitch> heh
<Lathiat> and i guess it was all confused
<seb128> elmo: can you drop evolution-data-server1.2 and pyphany packages?
<sivang> seb128: could you remind me what's the meaning of -1 as an index in launchpad_integration_add_items ?
<sivang> seb128: s/index/position/
<seb128>  * position.  If the position is negative, then it is used as an index
<seb128>  * from the end of the menu.
<seb128>  * The 3rd and 4th arguments are used to say whether to add a separator
<seb128>  * before and/or after the items. */
<seb128> that's the comment from the source file
<seb128> so -1 is 1 from the bottom of the menu
<sivang> seb128: darn, I forgot it also has an .h file :) thanks 
<seb128> np
<\sh> hmmm..
<\sh> nowxmsg is not in libwxgtk2.4-1-python
<\sh> strange
<pitti> infinity: whoa, what's wrong with the powerpc buildd?
<pitti> infinity: wrong clock as it seems
<elmo> probably 'cos I hard powercycled it
<pitti> ah, ok
<pitti> Hi sabdfl 
<sabdfl> hiya
<ajmitch> hi sabdfl 
<sabdfl> hey ajmitch
<ajmitch> afternoon mvo, how are you? 
<mvo> hey ajmitch! I'm fine, but todays kernel upgrade shuffled my interfaces around :/
<Lathiat> mvo: hrm that shouldnt happen
<Lathiat> mvo: at least, if they were there when you installed
<mvo> Lathiat: yes, both where there and in this order for a long time
<Lathiat> hrm
<Lathiat> see /etc/iftab
<infinity> pitti : Oh, royal?
<infinity> pitti, elmo : Clock looks okay to me.
<elmo> yeah me too, not sure what pitti's talking about
<pitti> infinity: http://hwdb.ubuntu.com/buildlogs/ shows a whole bunch of failed builds
<infinity> Oh, there's an easier explanation for that.
<ogra> pitti, not the fault of http://hwdb.ubuntu.com/buildlogs/ ;)
<infinity> They all did fail on the day stated, but didn't get mailed until today, cause postfix wasn't running.
<pitti> hm, ok, it seems that I just coincidentially picked one witha failed clock
<ogra> i think patchutils was missing on amd64 yesterday i looked
<pitti> it seems that most of the failures are genuine FTBFS
* ajmitch hopes vegastrike builds properly
<ajmitch> since I had to update the buggy gcc4 patch in debian :)
<\sh> doko: ping
<doko> \sh: pong
<siretart> fabbione: I had to install with 2.4 kernel, and had issues with the keyboard layout selector. Do you think it is wise to upgrade to 2.6 kernel (either sarge or sid) or should I leave the machine on 2.4?
<\sh> doko: nowxmsg is missing in the libwxgtk2.4-1-python packages...do u know why?
<doko> \sh: hmm, which version did have it?
<\sh> doko: no version at all...
<\sh> apt-file doesn't find anything
<\sh> but it should be in libwxtk2.4-python (our version is libwxgtk2.4-1-python)
<mvo> \sh: apt-file is fine again? 
<\sh> mvo: yes
<\sh> mvo: thx
<mvo> \sh: thank you for pointing out the problem :)
<doko> \sh: why do you believe it should be there?
<\sh> doko: bittorrent-gui (aka btdownloadgui) depends on it..
<\sh> oh no
<\sh> more trouble...w8
<\sh> can't load wxPython...
<ajmitch> \sh: import wxversion
<ajmitch> as in the wxpython changelog, seems to help it :)
<\sh> ajmitch: it's something else...
<\sh> hmmmm....
<\sh> damn
<\sh> I have to patch all this
<\sh> and the diff.gz changes the stupid orig.tar.gz but no debian/patches/* 
<\sh> who the hell is changing sources directly in the debianized sourcetree...*grmpf*
<infinity> \sh : Uhm, that's pretty common/normal.
<ajmitch> a few people do that
<infinity> \sh : debian/patches isn't a standard, by any means, the whole point of the diff.gz is to carry Debian changes.  It was only through time that more complex packages found a patch system to be more useful.
<infinity> \sh : I maintain packages that go both routes.  Complex ones with patch systems, and simple ones with changes in the diff.
<\sh> infinity: if you have a look on the bittorrent package, u'll see this is not even a oneline change they made
<infinity> I've had a look at bittorrent many times.
<infinity> In fact, I have this nagging feeling I promised someone I'd do an upload of it...
<\sh> infinity: I'll fix it now...in the way they did it :)
<infinity> Oh, right.  Mez wanted me to fix it.
<infinity> I had a fix pending, too.  Silly me.
<infinity> -ETOOBUSY
<infinity> Unread messages slip out of view too quickly. :/
<\sh> what was it?
<\sh> bittorrent-gui is in universe and not working as expected...actually it's not working at all...
<infinity> Something about broken wxgtk-python deps.
<\sh> yes
<infinity> Looks like a one-line fix.
<\sh> I'm fixing this right now :)
<\sh> no it's not
<infinity> Ahh, well the patch he sent me was.  I hadn't gotten around to testing yet. :)
<\sh> the runtime-dep is oneline...the fix for multiple wxgtk python versions installed is a 2 liner ,-)
<infinity> Oh fine, 3 lines then.
<infinity> Close enough. :)
<\sh> infinity: 10 lines ,-)
<\sh> ok...done
<bddebian> Howdy
<sivang> hey bddebian, 'sup ?
<bddebian> Hello sivang.  Not much unfortunatel. :-(  You?
<\sh> ok....fixed...
<\sh> now testing
<pvanhoof> how is x-server-* today?
<pvanhoof> will stuff work if I upgrade breezy today? :()
<pvanhoof> :)
<chmj> hey shackan 
<\sh> ok...going home...laters 
<shackan> heil
<jsgotangco> mako: so the debian bible is now out, congrats
<shackan> chmj, sorry for disapperaring, I'm working on the GUI now and yesterday I had to learn python and glade from scratch in about three hours (and obviously you can't test anything until there's a client to test with.. soo.. :-(
* shackan *sighs*
<chmj> shackan: uhmm.... ok 
<chmj> shackan: noticed there ware no updates 
<chmj> shackan: have you looked at the proposed specs from bluez mailing lists ? 
<shackan> yes, I'm weeding a lot of bugs out
<shackan> uhm, I'm subscribed to those.. but, what specs ? the dbus daemon you mean ?
<shackan> this? [Bluez-devel]  bluetoothd D-Bus interface proposals(draft 00.03)
<shackan> yesterday I took a look at kdebluetooth, and I realized that they're project has been worked on for almost two years by several programmers, and it's still beta, and I'm doing more or less the same thing, but in two months..
<shackan> *their
<shackan> chmj ?
<chmj> shackan: yes 
<paolo-> seb128: hi!  Is there any hope to get a more recent libcairo1 on breezy?
<chmj> shackan: the documentation they have there looks promising don't you think ? 
<fabbione> siretart: we need 2.6. breezy glibc don't support 2.4 anymore = we can't install/build on it
<paolo-> Hey shackan :)
<shackan> well, I emailed Claudio Takahasi a couple of times, it seems he's trying to do the very same thing as me, but with a different approach: he's writing tons of patches for the existing bluez-libs trying to force them into a dbus-capable program, I'm wrapping the existing bluez, unchanged, into a higher-lever api
<shackan> but, yes, the docs look good and I used some of it as a reference
<chmj> shackan: oh good, was gonna suggest that you use them as a reference 
<shackan> if I was going to show him the code he'd surely be interested, but he told me I'd rather speak about those matters publicly on the list, but posting *that* code on the list would be shameful :( (yes, I don't have much respect towards the way I code, especially when I'm in a hurry like now)
<JaneW> hi all please have a look at https://wiki.ubuntu.com/BreezyGoals there lots of green-ness happening. Let me know if any more goals have migrated to Green yet! Kthnxbye
<chmj> shackan: eheh, ok 
<paolo-> seb128: maybe these does work on ubuntu as well http://cairographics.org/packages/debian/ ?
<seb128> paolo-: hi. What is the issue with the current one?
<paolo-> seb128: the header files missing some functions
<seb128> paolo-: which one? I can patch that
<paolo-> cairo.h doesn't have cairo_surface_reference, cairo_surface_mark_dirty, cairo_surface_mark_dirty_rectangle.
<paolo-> cairo-features.h changed in some way but it's probably due to the newer releases
<seb128> /usr/include/cairo/cairo.h:cairo_surface_reference (cairo_surface_t *surface);
<seb128> it has this one here
<paolo-> That's strange, it does not appear here.
<seb128> $ nm -D /usr/lib/libcairo.so | grep cairo_surface_mark_dirty
<seb128> $
<paolo-> Err, surface_reference is there.  The other two are missing 
<seb128> same for cairo_surface_mark_dirty_rectangle
<seb128> the lib doesn't have these function, that's NOTABUG
<seb128> anyway, cairo will be updated after colony 3 you will have to wait
<paolo-> When will it be?
<seb128> the soname has changed and some 200 packages are to rebuild
<gilligan_> hi
<seb128> paolo-: when it's ready, cf topic :)
<paolo-> I'm writing the haskell bindings for the Google SoC and I have a timeline :-(  Sigh.
<paolo-> UH - today.
<seb128> paolo-: I'm sure than 2 functions don't make that of a big deal to change, for you, do they ?
<seb128> ie: can that wait 1-2 days?
<gilligan_> i'm looking for somes hints on how to reproduce/understand some hoary installation bug  -- installation stalls during 'Setting up primary installation repository..' and the only suspicous looking log output is  'debconf: Obsolete command TITLE Apt configuration called' -- unfortunately there is no strace in busy box -- any ideas what to look at.. ?
<paolo-> I can.  I didn't get it was "today" :-)
<paolo-> seb128: thanks much.
<seb128> paolo-: you're welcome
<HiddenWolf> huh, people are already using it, cool. :)
<gilligan_> hrm.seems like the problem is known but nothing has been done about it yet..
<struggler> I am having logout problems using sshd and I have the symptoms reported against 3.4P1
<struggler> The test created by Jani Jaakkola says that the hang on exit bug exists.  thoreuputic #ubuntu confirms this
<struggler> anyone interested?
<ogra> struggler, so if you got confirmed that its a bug, why not file it ? :)
<struggler> ogra: He confirmed the test, not that it is a bug, that is why I am asking here
<ogra> struggler, just file it then... we'll either confirm or drop it in bugzilla according to validity... see topic, everyone is very busy today
<struggler> ogra: thank you
<infinity> Is this the "if you start an application that leaves some fds open and then backrounds without properly closing them, then sshd hangs on exit" bug?
<struggler> infinity: yes
<infinity> Right, nothing new, then.
<infinity> Considered fixing the application that's leaving fds open? :)
<infinity> (Though, I thought sshd had a workaround for this now..)
<struggler> infinity: well, if I knew which application was leaving them.....
<ogra> infinity, it would be nice to have it fixed for ltsp before release though
<struggler> infinity: I'll try and figure out which one
<infinity> Well, what are you running and backgrounding before you try to exit?
<struggler> infinity: I'm not backgrounding anything, this happens after long shell sessions
<struggler> infinity: Apparently somebody isn't being nice and is leaving a file open, I'll go wading through the lsof output
<gilligan_> hm.. sorry to bother, but is it some kind of open secret that the hoary installation is utterly broken ?
<struggler> infinity: thanks
<infinity> gilligan_ : Are you sure it's not just a bad CD burn?
<infinity> gilligan_ : I've not seen that problem here.
<gilligan_> infinity, nope.. the CD is fine
<gilligan_> i had to kill /usr/bin/apt-cdrom -o Acquire::gpgv:: ...  in order to get on
<gilligan_> but then installing grub fails, simply because /sbin/grub-install is not available
<infinity> gilligan_ : Seriously, if apt-cdrom is having a conniption fit, it's almost got to be a bad CD (or broken hardware)
<infinity> gilligan_ : You can swear up and down that both are okay, but in thousands of successful installs, I've not seen this.
<gilligan_> i just unpacked the PC, and the burned the CD the 2nd time.. so i dont think so
<gilligan_> http://www.ubuntuforums.org/search.php?searchid=1422091
<gilligan_> it seems like i am by far not the only one experiencing this
<infinity> Ahh, what language are you using?
<gilligan_> American English
<infinity> There are claims in one of these threads that things are goofy under certain languages.  en_US wouldn't be one of them, though. :)
<gilligan_> right.. i've skimmed that but found it so horribly unlikely that i haven't tried it yet hehe
<gilligan_> but as i'm running out of options i'll give that a try
<gilligan_> eh.ah.. en_US would NOT be one of them? ok
<gilligan_> infinity, well this is for sure not my first ubuntu install.. but i've never exprienced these problems
<gilligan_> infinity, and although i think that the language setting thing from the forum is crap there actually does seem to be some problem with the hoary install
<gilligan_> i.e not a hardware/CD problem of mine
<Nafallo> jdub: ping
<infinity> gilligan_ : Well, I agree that apt-cdrom shouldn't be hanging (it appears to be hanging on wanting input, which it'll never get, cause it doesn't have a TTY), it will only do so if it thinks the CD isn't quite right.
<infinity> gilligan_ : You're welcome to file a bug and see if you can work it out with mvo.
<ogra__> do we have blackdown in multiverse already ? 
<ogra__> doko ? 
<gilligan_> infinito, i'll see if I can get it to install with this CD somehow -- as I said i already burned the iso twice so another broken CD is very unlikely
<doko> ogra__: no
<ogra__> doko, but its planned ? 
<infinity> gilligan_ : And others in the thread have claimed that lowering CD burn speed to something like 1x or 2x has magically solved it for them.
<infinity> (which points at a misbehaving burner)
<ogra__> doko, else i need a idea for a workaround for edubuntu... java availability is essential
<gilligan_> infinity, bunring speeds .. language settings.. sounds like lots of voodoo hehe
<infinity> gilligan_ : Language was way off base, but burning speed isn't voodoo.  High speed burns are quite often problematic.
<infinity> gilligan_ : I've had many errors on high speed burns on a variety of machines.
<mvo> gilligan_: do you have the complete command (with arguments) where it hangs? 
<gilligan_> infinity, yeah that's true.. but i only burned it 8x
<\sh> infinity: no root burning ,-)
<infinity> And there's mvo now.
<mvo> gilligan_: also I have done a lot of installs and apt-cdrom has never hung for me :)
<doko> ogra__: JavaRoadmap was deferred for breezy+1
<gilligan_> mvo, during 'Setting up primary installation repository' it always stalls at 25%
<ogra__> doko, totally ? its *really* essential for edubuntu 
<ogra__> doko, i dont see a prob in adding blackdown to multiverse
<mvo> gilligan_: can you see on the second console/log what command is run with what arguments?
<gilligan_> mvo, now I disabled the network device which solved the problem because apt does not even check for reprositories
<doko> ogra__: you are not allowed to ship a competing SDK ...
<mvo> gilligan_: so it hangs when trying to access the network probably. are you behind a firewall/proxy?
<gilligan_> mvo, i can rerun the installation with network enabled..
<ogra__> doko, i dont want to ship anything
<infinity> mvo : <gilligan_> i had to kill /usr/bin/apt-cdrom -o Acquire::gpgv:: ...  in order to get on
<ogra__> doko, i want it in multiverse
<gilligan_> mvo, i set up ipmasq on my powerbook
<ogra__> s/want/need
<doko> ogra__: -> elmo
<gilligan_> mvo, i tried fetching something with wget via console - which worked
<ogra__> doko, ok... i thought i heard sabdfl and you talking about it the other day
<gilligan_> so it can't be that it stalls because it waits for a connect
<mvo> gilligan_: so you killed apt-cdrom (with network) and the install continued after that? but if you install without a network then it works?
<gilligan_> i only noted the process I killed.. which was /usr/bin/apt-cdrom -o Acquire::gpgv::Options::==--ignore.. sorry, don't have the rest
<gilligan_> mvo, when I killed it I got some message 'finished scanning bla something' .. but appearently other things went wrong because grub was not even available .. /usr/sbin/grub-install was missing
<mvo> gilligan_: there have been reports about long delays while the installer tried to access a firewalled network. this would be my no1 guess right now. could you run the install to the point of the hang again?
<gilligan_> mvo, running the installation w/o network set up it does not even get to the point where it stalled before
<mvo> gilligan_: oh, interessting. what happend then? where did it stoped?
<gilligan_> mvo, as wget worked from console i don't think that its a firewall issue
<gilligan_> mvo, well running w/o network the whole installation works fine -- apt-cdrom just does not seem to be started at all
<gilligan_> mvo, but hold on.. i'll redo the whole installation with network just like before
<mvo> gilligan_: do you have a installed system now?
<mvo> gilligan_: if so, hold on and run apt-cdrom from it please
<gilligan_> booting it right now
<gilligan_> lets see if its fine
<gilligan_> afterwards i can repeat the installation to see where it stops and give you more details
<mdke> gah, trying the breezy installer and can't resize my windows partition, hoary was fine. Any ideas?
<gilligan_> ah,doh..accidently booted from cd again
<gilligan_> huh..  complains about some files in /lib having timestamp in future
<gilligan_> anyways.. let me try the installation again
<mvo> mdke: does it now work at all? or only take _very_ long?
<mvo> s/now/not/
<mdke> mvo, it seems to refuse to do it, after I enter the new size it just takes me back to the partition screen without my changes
<mvo> mdke: anything in the logs?
<mdke> where do I find them?
<gilligan_> tty4
<mvo> mdke: alt-f2, alt-f3, alt-f4
<mdke> looks like bug #7758?
<mdke> can't see the logs, the installer has moved on
<mvo> mdke: they will be copied to the harddisk after the install (/var/log/installer)
<mdke> ok
<mdke> the installer has crashed now during the next stage anyway :)
* mdke tries again
<gilligan_> mvo, its installing the base system now .. the problem should come up after that
<mdke> also in hoary i had wifi during the install, on breezy i don't
<mvo> mdke: that's just a bug
<mdke> looking
<\sh> mdke: madwifi? 
<mdke> no i think it is ipw2100
<gilligan_> man i've watched that progress bar quite some times today.. :)
<gilligan_> mvo: copying mirror configuration .. Setting up installation repository  --> and now it hangs again at 25%
<gilligan_> during "configuring apt..." that is
<gilligan_> right after I went through setting up a regular user & time zone settings
<mvo> gilligan_: can you do a ps ax on the shell?
<gilligan_> k.. what do u want me to look for?
<mvo> and /msg me the output?
<mvo> gilligan_: hm, you probably can't copy'n'paste :/
<gilligan_> hehe.. i was about to say :)
<\sh> grmpf..bittorrent is totally broken it seems
<mvo> ping ogra, ogra__ 
<Treenaks> ogra__: will hwdb be back?
<mitsuhiko_> Treenaks: hope so
<ogra__> Treenaks, yes, after preview freeze i'll have some more time for it
<Treenaks> (it would be nice to list the hardware IDs for the LaptopTesting laptops on the wikipages :))
<ogra__> currently i put all time into edubuntu and a bit into gnome-power
<\sh> ok..bittorrent + bittorrent-gui fixed
<HiddenWolf> ogra, how is edubuntu coming along?
<\sh> brb changing to another laptop for better working
<ogra__> HiddenWolf, some things are missing and it suffers from the common ubuntu problems wrt install CD
<ogra__> but that all will be sorted for preview ....
<Treenaks> I need an easier WEP key
<HiddenWolf> ogra__, cool!
<Treenaks> this is starting to suck, with all the re-installation :)
<mdke> turn it off :)
<Treenaks> mdke: and let my neighbours see what porn I watch? no way!
<HiddenWolf> Treenaks, too much ;)
<mdke> got some tech neighbours eh?
<Treenaks> mdke: at least 1
<carstenh> isn't wep insecure anyway?
<ogra__> carstenh, more secure then no WEP ;)
<carstenh> ogra__: but less secure than i.e. openvpn
<ogra__> sure
<Lathiat> or WPA
<Lathiat> it stops passers by
<mdke> hell MAC filtering will stop passers by
<Lathiat> no it wont
<Lathiat> depends what you mean by stop
<Lathiat> mac filtering will stop them using it
<ogra__> mdke, faking a MAC address is as easy as xworking around WEP
<Lathiat> it wont stop themf rom sniffing it
<Lathiat> and taht
<Lathiat> *that
<carstenh> .oO(mac-spoofing...)
<Lathiat> altho its harder on some wireless
<Lathiat> depends on the driver
<mdke> ogra__, you need to know the MAC address before faking it
<Lathiat> mdke: which is easy if theyre using the network at the time
<ogra__> mdke, yes, you need to sniff the arp requests
<mdke> ah
<mdke> oh well
<mdke> open networks are good anyhow
<Lathiat> yeh if i ever get busted for downloading something dodgy i can claim it could have been anyone :)
<Lathiat> besides if someone wants to use my wireless theyre more than welcome
<Lathiat>  no one has ever associated yet
<pitti> elmo: please sync clamav (yes, new upstream, but only a microrelease with two security patches, and universe)
<mike_douglas> Lathiat: I used to have that attitude, before I got a call from my ISP for using 60GB of bandwidth in one month.
<Lathiat> if i use too much bandwidth i get shaped
<Lathiat> no calls, no charging, etc
<Lathiat> so its not like it'd be devestating
<Lathiat> and i'd notice
<gilligan_> i just tried to resolve/reproduce some hoary installation bug with mvo but he had to leave .. anyone here working knowledgable about the installation routines etc.. ?
<gilligan_> s/working//
<mvo> gilligan_: leaving now (to play hockey!). it seems like on your burn the directory ".disk" is missing
<gilligan_> no i just checked.. its there
<gilligan_> i accdently checked the wrong dir before hehehe (/me hides)
<ogra__> mvo, you had #13496 on ubuntu too, right ? according to mdz it didnt occur at all to him
<pitti> seb128: wrt #13445, would you object to adding a dependency to python2.4-cairo in  python2.4-gnome2? I think hal-device-manager is not the right place to add it
<mike_douglas> I'm getting a "out-of-date-standards-version" with lintian, what is the latest Standards-Version?
<pitti> seb128: I can do it myself, just asking for your ack
<gilligan_> apt-cdrom is stuck .. strace reveals .. write(1,That is not a valid name, try again") .. write(1,Please provide a name for this Disc such as 'Debian 2.1r1 Disk1" ..
<gilligan_> its outputting that in a loop
<pitti> mike_douglas: 3.6.2
<Lathiat> pitti: i thought that already got uploaded
<Lathiat> for gtk2
<seb128> pitti: that's fixed for 2 days
<mike_douglas> pitti: thanks
<pitti> seb128: hm, I dist-upgraded this morning, but thanks; will check
<seb128> pitti: dup of #13457
<seb128> pitti: build issue
<seb128> hum no
<pitti> seb128: ah, ok, so I'm not completely dumb :-) thanks
<seb128> do you have pygtk 2.7.3-0ubuntu2 ?
<seb128>  pygtk (2.7.3-0ubuntu2) breezy; urgency=low
<seb128>  .
<seb128>    * debian/control:
<seb128>      - python-gtk2 Depends: python-cairo
<seb128> 
<seb128> mdz did that upload sunday
<Lathiat> python-gtk2 vs python2.4-gtk ?
<pitti> Version: 2.7.3-0ubuntu2
<Lathiat> err
<Lathiat> i mean
<pitti> indeed
<Lathiat> +2 on the end
<seb128> pitti: mdz screw, feel free to fix it :)
<Lathiat> indeed,
<Lathiat> needs to be in both really
<pitti> seb128: right, that's it
<pitti> seb128: it must be at python2.4-gtk
<seb128> I bet he updated control instead of control.in 
<seb128> and the changes got overwritten 
<Lathiat> python-gtk2 still depends on python-ciaro
<seb128> grumpf no
<Lathiat> but python2.4-gtk2 doesnt depend on python-gtk2
<seb128> pygtk is not a gnome-pkg format
<pitti> seb128: h-d-m -> python2.4-gnome2 -> libcairo, but no python-cairo
<Lathiat> pitti: you want gtk2 not gnome2
<seb128> pitti: python2.4-gtk2 should depends on python2.4-cairo
<pitti> seb128: right
<seb128> Lathiat: "<Lathiat> but python2.4-gtk2 doesnt depend on python-gtk2"
<seb128> Lathiat: that's normal, the non versionned version is here to depends on the current version
<seb128> no other way
<Lathiat> seb128: sure i was just pointing out
<Lathiat> thats why it doesnt work
<seb128> and python-gtk2 doesn't need to Depends on python-cairo
<seb128> it depends on python<version>-gtk2 which depends on python<version>-cairo
<seb128> pitti: you do the change?
<pitti> seb128: yes
<Lathiat> http://bur.st/~lathait/python-gtk2.debdiff
<Lathiat> err, http://bur.st/~lathiat/python-gtk2.debdiff
<seb128> pitti: thanks
<seb128> Lathiat: hum ... no offense but neither pitti or me need a debdiff to know how to fix a Depends
<Lathiat> i was just wondering if it was right
<seb128> the python-cairo Depends is not required but doesn't hurt
<Lathiat> and yes i know both of you have far more experience than i :)
<seb128> but that works yep
<mdz> seb128: I had to make that change in order to un-break LTSP
<trygvebw> has the name of breezy+1 been decided yet?
<seb128> mdz: you didn't put the python2.4-gtk2 Depends on python2.4-cairo on purpose?
<HiddenWolf> trygvebw, amuse me with suggestions? :)
<pitti> seb128: I'm sure that was just a small glitch
<trygvebw> HiddenWolf: nah :P
<trygvebw> i was just wondering ;)
<seb128> pitti: yeah, me too
<pitti> seb128: fixed, btw
<seb128> thanks
* Lathiat was fond of perk
<Lathiat> y
<seb128> time to discuss that == time to fix it * 5 :p
<bddebian> heh
<mdz> seb128: no
<mdz> seb128: the package you uploaded was broken; you could not even "import gtk".  I added the dep as a quick fix; it is not quite right
<seb128> mdz: k, that what we were discussing ... but the discussion is quite longer than required, pitti fixed it 
<seb128> mdz: yeah, sorry for that
<mdz> seb128: I didn't screw it; I just didn't fix it correctly :-)
<seb128> :)
<mdz> Mithrandir: lib32stdc++6 promoted
<mdz> Mithrandir: have you already uploaded the package which will depend on it?
<mdz> mjg59: grub patch?
<mdz> mantiena: ubuntu express status has been regularly posted to ubuntu-devel for the past week; subscribe to that list if you are interested in it
<cassidy> All main packages aren't supposed to have a entry into the bugzilla?
<\sh> cassidy: main == bugzilla reporting / universe == malone reporting
<pitti> Morning mdz
<pitti> seb128: btw, does that already qualify to get my "I fixed a gtk bug" badge? :-)
<\sh> cassidy: if the name is not there use unknown .. and file a bug in bugzilla for the missing entry
<cassidy> \sh:   yes i know, but don't find to report for gparted (main package)
<seb128> pitti: yeah, you have just won the pleasure to maintain GTK for a month and that FOR FREE :)
<seb128> pitti: congrats :)
<cassidy> \sh: ok, i will do that. thanks!
* pitti runs away screaming
<seb128> ah ah
<mdz> pitti: morning
<pitti> seb128: oh shit, now I'm the one who touched it last, I didn't think about that
<seb128> :)
<seb128> how do you think I get it? :p
<seb128> s/get/got/
<pitti> seb128: you were just *born* to be the gnominator...
<seb128> hahaha
<Mithrandir> mdz: yes, ooo2-amd64
<mdz> Mithrandir: -1ubuntu10-2?
<Mithrandir> yes
<mdz> Mithrandir: should be all set; would you check that it's all installable on amd64 now?
<mdz> then I'll roll CDs
<ogra_> yay
<mdz> at last count, kubuntu-desktop was uninstallable on amd64 (but apparently ubuntu-desktop was installable)
<mdz> never mind
<mdz> all desktops are uninstallable on amd64
<Mithrandir> huh?  They shouldn't be.
<mdz> as of Tue Aug 16 17:14:15 UTC 2005
<Mithrandir> why?
<mdz> http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html
<mdz> Binaries from ubuntu-meta 0.62 cannot be installed:
<mdz>     * ubuntu-desktop(amd64) 
<mdz> Binaries from openoffice.org2-amd64 1.9.121-1ubuntu10-2 cannot be installed:
<mdz>     * openoffice.org2(amd64)
<mdz> I promoted lib32stdc++6 well before the last cron.daily
<Mithrandir> so why can't -common be installed?
<Cimmerian> it says colony 3 will release, so i just thought i'd mention that the rootfs won't mount on stage two of todays breezy-install-i386.iso
<mdz> Mithrandir: you are asking me?
<mdz> Cimmerian: it does for others, so it's probably an initramfs driver issue.  please report to bugzilla under package: initramfs-tools
<mdz> Cimmerian: include lspci output
<Cimmerian> ok, will do, it's in a virtual machine (vmware)
<pitti> mdz, Mithrandir: lib32stdc++6 | 4.0.1-4ubuntu3 | http://archive.ubuntu.com breezy/universe Packages
<pitti> mdz: ^ that's the cause for half of the current breezy installability problems
<mdz> lib32stdc++6 | 4.0.1-4ubuntu3 |        breezy | amd64
<pitti> hmmm, odd
<mdz> I promoted it at :24; cron.daily at :33 should have resulted in it moving to main/Packages
<mdz> I guess we will see what happens at :03
<Mithrandir> mdz: yes, it's supposed to be installable just fine. :-)
<Treenaks> Is the "X doesn't generate a valid config file" bug known?
<Treenaks> (xserver-xorg/config/inputdevice/keyboard/model not set. Aborting.
<ogra> Treenaks, it works here... eve if the config isnt perfect
<mdz> it was known a couple of weeks ago, and fixed
<Treenaks> mdz: I'm using a daily breezy from about an hour ago\
<mdz> Treenaks: dated?
<mdz> 20050816 certainly worked fine for me
<mdz> and which CD?
<mdz> install or live?
<Treenaks> mdz: "current"
<Treenaks> install
<mdz> Treenaks: "current" points to a different CD depending on the time of day
<mdz> so that doesn't tell me which one you have
<Treenaks> mdz: how do I tell? is there  a file on the CD?
<Treenaks> md5s..
<Mithrandir> mdz: btw, I've tried to track down the d-i<->x keyboard problem most of the day and have halfway fixed it.
<Treenaks> summing
<mdz> Treenaks: /.disk/info
<gilligan_> anyone here responsible for hoary installer ? tried to track down some bug with mvo earlier on, but he had to leave
<Treenaks> mdz: 20050816
<mdz> Mithrandir: I fixed it last night before I went to sleep
<mdz> Mithrandir: casper 1.4
<mdz> well, I backed out the change which broke it
<mdz> Treenaks: it must be specific to your configuration, then
<Treenaks> mdz: I'll file it
<Treenaks> mdz: md5sum matches 20050816.6
<mdz> oh, that's not the same one I tested then
<mdz> Treenaks: info only says 20050816, but it's really 20050816.6?
<Treenaks> mdz: .disk/info says "Ubuntu 5.10 "Breezy Badger" - Alpha i386 (20050816)
<Treenaks> mdz: md5 matches .6
<Mithrandir> mdz: well, I got it mostly working with debconf-copydb
<pitti> Mithrandir: just apt-get updated, now lib32stdc++6 | 4.0.1-4ubuntu3 | http://archive.ubuntu.com breezy/main Packages
* gilligan_ slowly gets nuts
* ogra joins gilligan_ 
<ogra> why do i have sparc and hppa in edubuntu-meta, grrr... update fails constantly on these arches... i dont even need them... hmpf
<gilligan_> hoary won't install because apt-cdrom is stuck (strace shows its looping..) and warty install as alternative does not work because its stuck right in the beginning ingoring keyboard input
<siretart> hey, sparc rocks. I just installed one ;)
<ogra> siretart, there is no edubuntu for sparc :/
<ogra> but it breaks my update script for the meta package...
<ogra> as well as hppa....
<mdz> Mithrandir: oh, good
<lamont> mdz: http://bugs.debian.org/50572 for more on the whole 'WTH is RTC a module anyway?' discussion
<mdz> Mithrandir: I think I got to the point of realizing that we need to use debconf-copydb from cdebconf to copy from cdebconf to debconf, and decided that was too ambitious for colony 3 ;-)
<mdz> lamont: what discussion is that?
<lamont> that's the explanation on why I'm moving hwclockfirst.sh back from S22 to S18, and reintroducing a bug :-(
<ogra> AAAARGH 
<ogra> W: http://ports.ubuntu.com/ubuntu-ports/dists/breezy/main/binary-sparc/Packages.gz was corrupt
<lamont> OTOH, I'm working through having the kernel have CONFIG_RTC=y instead of =m, so we don't see said bug
<ogra> the fourth time now
<mdz> ogra: why don't you just take it out?
<ogra> mdz, is that ok ? 
<mdz> lamont: the amd64 bug?
<lamont> mdz: OTOH, I need to make sure that hwclockfirst.sh has a correct enough subset of hwclock.sh, etc.
<lamont> the 'hwclockfirst.sh bitches about RTC on $ARCH' bug, for arch = ... amd64 ...
<mdz> ogra: edit the update script and remove them from the architectures variable
<ogra> mdz, ok, thanks
* lamont is dragged out the door to lunch - back in about an hour.
<mdz> ogra: then remove all the *-hppa, *-sparc
<ogra> yep
<ogra> mdz, bte, we have the first running edubuntu install out in the field :)
<ogra> btw even
<ogra> with ltsp and icewm....
<mdz> that's great
<ogra> yup :)
<mdz> whmere?
<mdz> where?
<ogra> Petaris in #edubuntu ... dunno where he is located
<leonel> is it safe to move from hoary to breezy  ? does the  scary c++ things had passed ?
<leonel> I know it's under development but is it stable enough to use as a non critical desktop
<leonel> ?
<Nafallo> leonel: yea, but xorg remains without a few binaries :-)
<Nafallo> leonel: no, things are still changing.
<Nafallo> not much, but they are.
<leonel> i know
<leonel> but it's usable  
<leonel> or not ?
<HiddenWolf> leonel, mostly
<Nafallo> leonel: don't ask me. I've used it since it hit the archive ;-)
<leonel> Nafallo, jajaja
<leonel> HiddenWolf, that sounds like hold on 2 or 3  more weeks
<HiddenWolf> leonel, your call
<leonel> i know
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Feature freeze! | Colony 3 will release today: test the current daily and daily-live and report here
<mdz> ogra: it would be good if you could test the current CD build
<mdz> ogra: presumably your issue was specific to non-English installs
<stianj> after an upgrade after this friday, my breezy box went totally bananas, most Gnome applications either segfault or show this message: "Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed". Only happening to me?
<seb128> that's a known launchpad-integration warning, it doesn't hurt
<ogra> mdz, i will
<ogra> mdz, you mean ubuntu or edubuntu ? 
<seb128> stianj: this message is not what make your app crash. A backtrace would be nice 
<mdz> ogra: ubuntu, the build I just made
<ogra> (i will test tomorrows edubuntu daily anyway, sice i think it should be safe for installation if colony 3 works)
<ogra> ok
<Keybuk> seb128: random panel problems: no "Text Editor" and no "Run Application"
<\sh> when will colony 3 be ready to download?
<ogra> \sh, for testing.... now !
<ogra> \sh, for using ... after testing ;)
<seb128> Keybuk: "Run App" has been dropped on purpose, "Text Editor" is under Accessories
<\sh> ogra: harhar...I have to replace the kernel in any way :)
<seb128> Keybuk: is gedit installed?
<Keybuk> it isn't under my Accessories
<Keybuk> yeah, gedit is installed
<ogra> \sh, you need some test HW ....
<seb128> gnome-menu-spec-test  | grep gedit ?
<ogra> \sh, at least for the next release cycle
<stianj> ok... Then it's something different. As an example; my gdm crashes (restarts) at the instant I hit a button on my keyboard. Then I tried to remove gdm and just use startx, then X started, but some gnome-apps don't start at all (gnome-terminal, evolution..), and if I click the titlebar on any app, the app disappears, then comes back after a couple of seconds (but doesn't quit). It's really weird! I don't even know what component I should file a bu
<stianj> g on..
<Keybuk> the package doesn't appear to contain a .desktop file though
<Keybuk> seb128: returns nothing
<ogra> mdz, thats .8, right ? 
<seb128> gedit-common: /usr/share/applications/gedit.desktop
<\sh> ogra: ah well..yes...yeah...w8...yeah I just found m money tree...,-)
<Keybuk> hmm, I have that, yup
<seb128> Keybuk: do you have this file? If yes, did you play with a menu editor?
<ogra> \sh, shake it !!
<Keybuk> it doesn't appear in the menu editor either
<seb128> right click on the menu and edit
<seb128> hum
<\sh> ogra: only leafs..no money..shame
<stianj> seb128, it seems evolution crashes in libXcursor.so.1
<ogra> \sh, bah, what kind of money tree is that ?
<seb128> stianj: can you put a backtrace somewhere? ie pastebin.com ?
<ogra> \sh, someoe cheated you apparently...
<Keybuk> weird, I hate a .local/share/applications/gedit.desktop with NoDisplay=true in it
<Keybuk> s/hate/had/
<stianj> seb128, sure, but isn't that rather useless when Evolution isn't built with debug symbols?
<\sh> ogra: actually...I had it for 7 years now...but u know...now it's gone together with the money...:)
<seb128> Keybuk: that's it. Previous nautilus version had a bug, when changing the default app for a type the end by masking system desktop files like this
<Keybuk> why did Run Application go?
<ogra> Keybuk, alt-f2
<seb128> Keybuk: upstream decided that's not useful here, people use Alt-F2 or the menu entries directly ... I don't really agree with that, but that the kind of discussion where you never get everybody agreeing so the maintainers took the decision
<mdke> :(
<mdke> i use that all the time
<Keybuk> gah, I hate people hiding things in Keyboard Shortcuts
<ogra> seb128, i thought gnome-launch-box was supposed to replace it one day
<mdke> that will hit the intermediate users
<ogra> .... one far future day.....
<stianj> seb128, http://pastebin.com/338462
<Keybuk> "...you don't need to run applications..."
<seb128> ogra: there is no plan about that, this app is a quick hack not working well and not hacked for month
<ogra> seb128, i know, i followed it since you included it in hoary... and dropped it some weeks ago
<Keybuk> (I only noticed because I needed it to run gedit <g>)
<stianj> quit
<stianj> damn
<stianj> wrong window
<ogra> seb128, we should consider re-adding run application... its only a .desktop entry more... i agree with you that its bad to remove it
<seb128> Keybuk: http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00169.html
<ogra> s/a/one
<seb128> ogra: that's not a desktop file, that's some panel code
<mdke> if the Run Application tool is gone, more programs should have menu entries IMHO
<seb128> stianj: try changing your cursor theme maybe?
<seb128> stianj: which one do you use?
<seb128> stianj: gconftool-2 -g /desktop/gnome/peripherals/mouse/cursor_theme
<Keybuk> there are far lower hanging fruit than Run Application :-/
* Keybuk eyes "Take Screenshot", "About GNOME", etc.
* mdke hugs Take Screenshot
<Keybuk> mdke: PrintScreen isn't it? :)
<ogra> i think we should re-add it, even if its more then a .desktop file.... i thought its still gnome-run
<mdke> i hate it when people hide things in desktop shortcuts
<seb128> Keybuk: yeah, there is a bug open about "Take Screenshot" as well now
<mdke> *keyboard
<ogra> argh
<mdke> i'm with ogra for readding Run Application
<mdz> +1 breezy-install-amd64.iso
<seb128> ogra: no, it's some panel code ... but it's easy to put back if we want it. Nobody really complains, I'm not sure we should change now
<stianj> seb128, bah, it was my fault. I'm terribly, terribly sorry for wasting your time! (But you helped me find it :) Thanks!
<seb128> mdke: no need of keyboard, just use the menus
<seb128> stianj: np. What did you do? So if somebody else got the same issue I know what to reply ... :)
<ogra> seb128, i finally got used to alt-f2 , but i didnt know it would stay out of the panel
<\sh> libgl1-xorg-dri has installation problems
<Keybuk> *shrug* if we're cleaning up the other crap in the menu too, leave Run Application off
<\sh> /usr/X11R6/lib/modules/dri/gamma_dri.so is also in xlibmesa-dri
<seb128> Keybuk: there is no other crap for the Applications menu :)
<\sh> daniels: missed a eplaces?
<\sh> Replaces even?
<mdz> breezy-live-amd64.iso has broken oo.o2; rolling a new livefs for it
<seb128> Keybuk: but I don't have strong opinion on the question, I don't really care, I use alt-F2 :)
<Keybuk> seb128: me neither
<Keybuk> (leave it off the menu, I meant)
<Keybuk> there's crap in Places and System <g>
* Keybuk gets the patch gun out
<stianj> seb128, heh, lately pornview has segfaulted at startup, I was trying to fix that, and found out with strace that the last thing before it segfaulted it tried to open /usr/X11R6/lib/X11/icons/gnome/index.theme, so I symlinked /usr/X11R6/lib/X11/icons/default to that directory.. (and forgot before I restarted...) Sorry :)
<HiddenWolf> stianj, pornview, do I want to know?
<Keybuk> stianj: was it crashing on particular files?
<seb128> stianj: k
<seb128> stianj: but that should not make every app crashing ...
<Nafallo> HiddenWolf: pornview rocks! imageviewer with xinelib-glue :-)
<HiddenWolf> Nafallo, gnome ships with half a dozen imageviewers already, why would anyone want another one?
<Nafallo> HiddenWolf: gnome does not ship this one :-)
<Nafallo> HiddenWolf: cause you can use it for all your porn? both pictures and movies :-)
<HiddenWolf> i gathered that much.
<carstenh> pornview does not support svg :(
<Nafallo> carstenh: svgporn? LOL
<Nafallo> :-)
<\sh> mdz: for #11097 bugzilla is the correct position :) for cxx transitions
<mdz> \sh: pardon?
<ogra> \sh, universe
<\sh> ogra: yes..but cxx trans
<mdz> \sh: who told you that?
<\sh> mdz: because we filed all cxx trans bugs in bugzilla.
<mdz> \sh: why?  I asked for them not to be filed in bugzilla for universe packages
<mdz> as with all other universe bugs
<ogra> mdz, doko used bugzilla for cxx transition tracking, it was better to use then the wiki for this amount of packages, but universe shouldnt be in there...
<\sh> mdz: https://wiki.ubuntu.com/CxxLibraryList ->  For each library (for universe as well), create a bug report at [WWW]  http://bugzilla.ubuntu.com/, the subject/title must start with CXX transition: <source name> renaming ... (i.e. "CXX transition: libfoo renaming ...") (universe package can use UNKNOWN as th
<ogra> seb128, mdz did you two talk about the screensaver situation already ? 
<mdz> ogra: no
<mdz> \sh: who wrote that? doko?
<\sh> mdz: if he created this wiki page, then yes
<\sh> mdz: and if you do a query over bugzilla for CXX transition: you will see a lot of bugs for libs even from universe
<ogra> mdz, seb128 thinks gnome-screensaver isnt ready... i tend to agree that we'll at least will need the "random screensaver" functionality from CVS and we have no screensavers in a separate package to use them with gnome-screensaver.... on the other hand i stopped working on the lockscreen patch (85% done) ...
<mdz> \sh: I know
<seb128> I've not said it's not ready!
<mdz> \sh: and when I saw them, I posted a comment saying that they should not be there
<seb128> I've said feature freeze was previous week
<seb128> and we would require coming version
<seb128> and maybe to split xscreensaver to make a -data package
<doko> mdz: yep, all are marked with CXX, so they can easily be identified
<mdz> doko: they do not belong in Bugzilla, and they create work for me there
<ogra> s/isnt ready/isnt ready as it is now/
<ogra> seb128, :)
<mdz> +1 breezy-live-i386.iso for me
* mdz gestures pointedly at the last item in /topic
<doko> mdz: would it be ok to lower the severity of these, but not close them?
* ogra has 28% downloaded
<mdz> doko: it would be an improvement
* seb128 kicks the sucking download here, 3 hours to get a CD
<ogra> bah
<ogra> 1:27 here
<Nafallo> ogra: what are you? :-)
<stianj> seb128, no, it shouldn't crash everything, but it actually did
<ogra> Nafallo, ??
<Nafallo> dooh
<seb128> stianj: can you describe what you do to get this crasher?
<Nafallo> ogra: where are you? ;-)
<ogra> Nafallo, still in germany.... 1:27 to go for the CD download
<stianj> seb128, and what's up with pornview I have no idea :( It stopped working about a month ago... 
<ogra> :)
<\sh> ogra: update to 6mbit/s? ,-)
<stianj> it just segfaults..
<stianj> ok, it's easy :)
<ogra> \sh, 5km to the next headend... i have to thank the telekom that i get 768K here
<carstenh> s/768/1024/?
<stianj> seb128, ln -s /usr/X11R6/lib/X11/icons/default/ /usr/X11R6/lib/X11/icons/gnome
<Nafallo> ogra: haha, I thought it was the time ;-)
<ogra> Nafallo, *g*
<ogra> carstenh, nope, but i'm 'allowed' to pay for 1024 :)
<stianj> seb128, or you were maybe talking about pornview? It just started segfaulting at startup about a month ago after an upgrade... Have no idea why..
<ogra> carstenh, the signal normally breaks down to unusable at 4.5km
<carstenh> ogra: then the cd is either very small or your 768 are very fast
<\sh> ogra: hmmm...they should put a repeater between you and the VST
<seb128> stianj: nop, the cursor bug
<ogra> carstenh, wget shows 79.14K/s 
<carstenh> ogra: i think i remember a higher distance
<\sh> carstenh: 4km is the magical frontier normally...4.5km is good will, 5km a wonder >5km is hell
<ogra> carstenh, thats what they told me... after i made some trouble... since in te beginning they switched it to 256
<\sh> carstenh: copper lines...I think it's mounted on lampposts in ogras area ,-)
<stianj> seb128, that's just ln -s /usr/X11R6/lib/X11/icons/default/ /usr/X11R6/lib/X11/icons/gnome, and everything went bananas here..
<ogra> \sh, exactly
<\sh> ogra: really, I mean it was just a guess...
<stianj> seb128, it's 100% reproducible. Make that symlink and click on a titlebar (whichever)
<stianj> seb128, can you reproduce?
<ogra> \sh, except everything has its own pole ... one for power, one for phone...
<seb128> I'll try later
<seb128> I kind of use my apps atm
<\sh> and I'm sure, daniels forgot a Replaces: in the debian/control
<\sh> ogra: that's for sure...everything is iso9001 *lol'*
<stianj> seb128, hehe, ok :)
<\sh> else even
<stianj> should I file a bug regarding the pornview issue, or is pornview more or less abandoned?
<carstenh> ogra: the graph i saw was about the maximum distance of dsl at all, not the bandwidth the telekom offers, so i guess you are right :)
<rob^^^> are daily builds mirrored anywhere?
<\sh> carstenh: the higher the bandwidth, the higher the frequency (modulation) on the lines...the longer the cables, more biterrors occur..so the bandwidth decreases
<ogra> carstenh, i'd have a faster line if i could get one, i kind of live from this connection :) 
<\sh> ogra: ask QSC? they're working with better hardware...but using the same wires
<ogra> my next house will have a 10Mbit SDSL line ;) 
<ogra> \sh, i'm not sure i'll stay here, too much trouble with my silly landlord living in the cellar...
<\sh> ogra: eeks...yes...I forgot
<\sh> ogra: i have to find another flat as well...this flat is becoming to expensive.
<ogra> \sh, looks like we'll probably move to hessen, i leave the decision for the next house to suse ...
<Nafallo> SuSE?
<ogra> \sh, you have to find a better job, not a cheaper flat
<ogra> Nafallo, my GF susanne :)
<Nafallo> ogra: *puuh*
<ogra> heh
<\sh> ogra: I quote daniels: "harhar"
<\sh> ah...new job
<\sh> yes
<\sh> jane gave me some interessting links for immigrating to ZA and getting a working permit..lets check
<ogra> heh
<ogra> \sh, i know someone with a connection to an ostrich farm, i could get you a job if you need one :) 
<ogra> \sh, as .. hrm, cowboy ... hehe
<\sh> ogra: it's no joke...if I find a job in ZA somewhere in durban, cape town or joburg...I'll leave this country...starting from scratch
<ajmitch> \sh: why ZA?
<ogra> \sh, good plan, i'd join... but ETOOMANYANIMALS
<\sh> ajmitch: because I love this country...and u can do many things helping to develop the country there and help the people
<\sh> ajmitch: psst, the truth: because of the wine and the biltong there...and the steaks are tasting like steaks not like drugs ,)
<ajmitch> hehe
<\sh> ajmitch: and jeffreys bay is a good place for living  ;)
<ogra> \sh, hey, other people pay a lot for their testosterone shots
<\sh> ogra: man, warn me before u doing this...I just swallowed my cigarette
<ogra> \sh, so stay meateater in germany and just start bodybuilding.... soon there are chances you become mdz's gouvernor
<\sh> ogra: no ways...my goals are set: max. 3 years and I'm living in Durban near the beachfront or Jeffreys Bay or Hermanus..depends on my money and the job I'm getting there :)
<mdz> ogra: I thought he was from austria
<mdz> (the governor, not \sh ;-) )
<ogra> mdz, no reason to not replace him with a german :)
<\sh> about what are u talking? who should I replace?
<Nafallo> the good thing with ubuntu is that it is fun while it's no-fun :-)
<mdz> Nafallo: no-fun?
<ajmitch> \sh: ah, so it was wxversion to get bittorrent going? :)
<\sh> ajmitch: yes :) and bittornado as well...
<mdz> ogra: why is it taking so long for you to download if you had a copy of 20050815?  the changes are not large
<ajmitch> heh :)
<Nafallo> mdz: several wars on ubuntu sweden vs. a local lug for the SFD :-/
<Keybuk> what's the thing you put in a bug alias to indicate it's a debian bug?
<Nafallo> mdz: I found the role of peacemaker ;-)
<mdz> Keybuk: deb<bug number>
<Keybuk> #8627 is a general dpkg problem and not ubuntu-specific (and too hard to fix for just ubuntu at this stage)
<Nafallo> anyway, we will co-op again now :-)
<mdz> Keybuk: that's to associate it with an existing Debian bug
<Keybuk> is filling that in an alias and marking the bug NOTWARTY valid for this?
<Nafallo> after som phonecalls ;-)
<mdz> Keybuk: UPSTREAM would be the appropriate status
<ogra> mdz, because i dont have the iso anymore.... my burner is in the testserver i reinstalled ...
<ogra> i havent kept a copy... :(
<Keybuk> okies
<doko> mdz: please could you promote libcapi20-3 to main (was unbuildable for some time, therefore the late change)
<pitti> guys, can you please check whether you  have /etc/udev/scripts/removable.sh and call dpkg -S on it?
<mdz> doko: just a soname change?
<doko> yes
<mdz> not a new library?
<doko> no, we did have libcapi20-2, part of isdnutils ;)
<\sh> pitti: i have it, but dpkg -S tells me I don't have it
<mdz> doko: there is no libcapi20-3 in breezy
<doko> ?
<\sh> mdz: it's part of the new build of isdnutils of doko
<pitti> \sh: same for me, this is the cause for many of my bugs...
<mdz> ...which would be waiting in NEW
<doko> ok, that could be.
<mdz> doko: I've processed it; ping me again when it's in the archive so that it can be promoted
<\sh> pitti: so this could be the issue why on my portege the usb stuff is not popping up automatically? 
<ogra> pitti, same here
<pitti> ogra, \sh: yes, I have a lot of dup bugs which look similar
<\sh> pitti: w8..lemme have a look on the portege
<ogra> yippie, edubuntu desktop is installable again :-D
* HiddenWolf gives ogra a cookie
<ogra> thanks :)
<ogra> i was a bit to quick with including tuxpaint/math ... but want to have a usable CD tomorrow...
<seb128> pitti: nice catch for the udev bug!
<\sh> pitti: ok...on the last clean install on this portege no removable.sh is in /etc/udev/scripts
<pitti> ok, then I think we have found the root cause of a gazillion hotplug bugs
<pitti> thanks for checking
<pitti> so who kicked removable.sh??
<pitti> anyway, I'll put it back
<mdz> doko: what kind of changes are involved in "Upgrade to new aspell (old-style hashes). "?
<mdz> pitti: Keybuk touched it last ;-)
<Keybuk> "kicked" ?
<\sh> hmmm
<mdz> +1 breezy-install-i386.iso
<mdz> Keybuk: "made to vanish"
<Nafallo> anyone except fabbione know how stable the sparc port is?
<Keybuk> weren't me guv'na
<\sh> guys...when I copy the kernel config out of /boot/ and put it into a ubuntu kernel source tree...the resulting kernel should have the same symbol versioning as the running kernel?
<Keybuk> I debdiff'd before I uploaded <g>
<fabbione> Nafallo: stable for server install.... working out some issues with gnome and the toolchain atm
<doko> mdz: dependency changes only.
<fabbione> Nafallo: not all of universe is there yet.. main almost all
<doko> 1. Change "Provides: aspell6-dictionary" to "Provides:
<doko>    aspell6a-dictionary"
<doko> 2. Ensure dictionary files are installed to /usr/lib/aspell
<doko> 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
<doko>    (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).
<Nafallo> fabbione: not something for people to try out in a booth on SFD then? :-/
<mdz> doko: the kind that make uninstallable packages installable, or the kind which make installable packages uninstallable?
<fabbione> Nafallo: nope...
<doko> the former, of course
<\sh> ogra: name a good wifi scanner app in ubuntu
<fabbione> Nafallo: not something you can show as desktop
<mdz> doko: if this causes my CD builds to be broken, I will be very unhappy
<mdz> I am trying to prepare a Colony release
<ogra> \sh, dunno, #ubuntu-motu got spammed a lot by wifi-radar discussions, i dont have a use for such tools out here
<doko> mdz: all the aspell changes will unbreak things
<Nafallo> fabbione: oki, thanx :-)
<\sh> ogra: k...
<fabbione> Nafallo: no problem.. hopefully we will make breezy in a decent state
<fabbione> Nafallo: breezy+1 will be a dead line for me
<ogra> \sh, i'm pretty sure the next wifi is more ten 20km away
<ogra> then
<seb128> pitti: please stop restart dbus on upgrade, I'm borred to be slaped by dbus upstream and GNOME guys :/
<Nafallo> fabbione: nice :-)
<\sh> ogra: hehe :) 
<pitti> seb128: feature freeze?
<Mez> just wondering: wheres the fglrx kernel module gone?
<pitti> seb128: why do they slap you?
<seb128> pitti: restart is a feature?
<seb128> pitti: because they keep getting random weird bugs or crashs
<pitti> switching it off is easy, but why should we?
<pitti> the only thing that crashes is the battery applet
<seb128> pitti: and that's getting worst with the number of apps using dbus
<pitti> but daniels told me that this is cared for
<pitti> hmm
<pitti> I talked with daniels and jdub about this this morning
<pitti> maybe we four should talk about this again 
<seb128> pitti: we are going to loose this fight, we can't patch the world again upstreams
<seb128> pitti: I talked for 1 hours with walters on #gnome-hackers last week
<pitti> seb128: reminds me of win 2k, one reboot for every system change... :-/
<seb128> you already restart for an xorg upgrade
<seb128> no big difference for dbus
<seb128> keep it running, it keeps working for the session
<pitti> the session bus is not restarted
<pitti> we should try to limit the packages that require a reboot
<seb128> yeah, I agree
<seb128> but now a part of the desktop use dbus
<seb128> there is a branch of gnomevfs using dbus instead of bonobo
<seb128> and same for evolution
<seb128> and rhythmbox
<seb128> etc
<seb128> we are going to have to patch the world against upstream
<seb128> I'm not sure that's worth the efforts
<pitti> all of these things use the system bus?
<pitti> agreed, we can't patch them all
<pitti> patching g-v-m, update-notifier and battery-applet is still sane
<seb128> not sure, I've not tried all the stuff switching to dbus
<seb128> but take the print stuff and cups
<pitti> so to change this, we need to change just dbus itself and hal, AFAICS
<\sh> ok...coming back just now
<\sh> back with portege
<Keybuk> score!  I found a still-in-its-box PS/2 Mouse in the loft
<mdz> hmm
* Keybuk wonders what that came free with
<mdz> so I don't suppose anyone besides me has tested a live CD in the past few days
<mdz> because xresprobe seems to be broken
<seb128> still 1h30 to get mine
<\sh> mdz: tell me something else about libgl1-xorg-dri...is it a missing Replaces on xlibmesa-dri?
* ogra is at 34min
<Keybuk> ...now all I need is a PS/2 port; d'oh
<mdz> \sh: no idea, ask daniels
<pitti> mdz: I tested the dvd, but I didn't even come that far - stage1 b0rked because of missing kernel modules
<\sh> oh...and battery monitor crashed when I'm changing from battery mode to charging mode
<\sh> on portege at least
<mdz> pitti: I haven't even built DVDs
<mdz> whatever is there is presumably a broken weekly build from some time ago
<pitti> well, it is from August 13
<pitti> not so bad
<pitti> of course the live image can be much older
<doko> mdz: libcapi20-3 is in the archive
* Keybuk jumps off the dying server
* Mez pokes keybuk a little
<Keybuk> Mez: 'sup?
<Keybuk> sweet, I managed to really annoy X by unplugging the mouse during a click
<Mez> what time do the SB lug meetinsg normally run ... I might pop over to it this thursday if it aint too late for me to get the train back
<Mez> lmao @ keybuk
<Mez> er ...
<Mez> why did you do that
<Keybuk> dunno, I've never turned up for an SB lug meeting other than the one I talked at
<Mez> lmao ...
<Mez> gonna continue the trend?
<Keybuk> I generally don't remember them
<Mez> dont remember what#
<\sh> dear gnomes..please adjust your keyboard shortcuts for changing desktops
<Keybuk> that they're on
<Mez> to ctrl + tab
<\sh> argl...
<Nafallo> \sh: adjust them yourself ;-)
<Nafallo> \sh: ALT+F# wfm ;-)
<\sh> why not ctrl+tab+alt+t or something...is ctrl+f1 or alt+f1 to bad?
<\sh> Nafallo: well..actually it's my good will to use gnome at all...but sometimes I'm stucked
<\sh> and did I say that the portege is burning my left knee?
<Nafallo> :-)
<\sh> the fan is not starting at all...but it's quite hot
<Keybuk> Mez: debugging someone's mouse problem; and was leaning over when I unplugged it :p
<\sh> echo 'force_on: 1' > /proc/acpi/toshiba/fan
<\sh> nice trick to force cooling
<Nafallo> \sh: and to minimize the batterylevel? ;-)
<\sh> Nafallo: right now it's on the net ,-)
<\sh> hmm...last cigarette
<Nafallo> \sh: for life I hope :-)
<\sh> Nafallo: it's a dream..but it will last until tomorrow morning
<ajmitch> last one... until the next one, that is :)
<Nafallo> such weakness ;-)
<\sh> gnarf
<\sh> american scientist found out, that people wearing coloured glasses and smoking tobacco are the most creative and funniest people ever *eg*
<Keybuk> ok, that's really strange, the MAC address of my ethernet card has changed
<\sh> suddenly or with purpose?
<Keybuk> since I last net-booted
<Keybuk> oh, maybe that got changed with the system board
<Keybuk> it's changed from "Compaq Corp" to "Hewlett Packard" heh
<sladen> Keybuk: yes, it's burned into the eeprom
<Nafallo> lol
<Nafallo> :-)
<\sh> so with purpose...;)
<Nafallo> that's like the time so tried why a card could load both 8139too and 3c509 :-P
<Nafallo> but only would work with 3c509 ;-)
<Nafallo> -ETWOCARDS :-P
<mdz> fabbione: what changes did you make to portmap?
<mdz> it no longer has the correct default
<mdz> your changelog was rather nonspecific
<Keybuk> mjg59: ping?
* Keybuk wonders whether he can just add stuff to hotkey-setup without anyone minding
* mvo wonders what our "offical" way to copy a audio cd is nowday?
<pitti> mvo: I thought with serpentine? 
<Nafallo> with serpentine :-)
<mvo> pitti: I haven't found a "copy cd" with it
<Nafallo> ah, _copy_ cds
<mvo> yep :)
<Nafallo> nautilus-cd-burner I believe?
<mvo> does anyone know how? I right clicked on the cd but no "copy" or "duplicate" or something option
<mvo> oh, found it
<Nafallo> I got Copy Disk on my empty CD-rom ;-)
<mvo> hm, the right-click menu from the audio-cd on the desktop is different from the one in "computer". is this supposed to be?
<seb128> mvo: not sure
<mvo> seb128: it's pretty cool that n-c-b can copy now too :) does it use cdrdao for it?
<seb128> pitti: do you know why dpkg ask for not move/changed file: #12318 ?
<seb128> mvo: yeah, pitti has make a wiki page for it this morning (thanks pitti!)
<mvo> pitti++ 
<mvo> :)
<pitti> seb128: no idea, maybe it wasn't a conffile in the past or moved from one package to another?
<seb128> pitti: moved, no ... not a conffile file, maybe, thanks for the hint
* mvo goes to bed 
<ogra__> night mvo
<mvo> hey ogra__! how is colony going?
<ogra__> burning... ready for installation in 3 mins
<seb128> pitti: k, that was that ... the debian packagin has "rules:  perl -pi -e 's#^/etc/gdm/factory-gdm.conf\n##sm' debian/gdm/DEBIAN/conffiles"
<mvo> rock, fingers crossed that it works fine
<mpt> 1. Open it in Nautilus. 2. Try to drag stuff. 3. Weep hot tears. 4. I'm not sure what step 4 is. :-)
* mpt growls at gaim
<Nafallo> mpt: file a bug? :-)
<seb128> mpt: what is that supposed to do? works for me
<paolo-> Why is it called "Colony" ?:)
#ubuntu-devel 2006-08-14
<ne78> Does the php5 package of edgy includes pdo supports ? pdo is part of php5.1 and debian still miss it for 206 days (bug 348882)
<infinity> ne78: No.  It's on my TODO list.
<infinity> ne78: Upstream made it a pain to enable gracefully without building everything as one big static blob, so I've been playing with ways to work around that.
<ne78> infinity: http://people.debian.org/~dexter/dists/php5.1/ has it but it uses it's infame build system
<infinity> Yeah, I know dexter's done it, though I haven't poked through his patches yet.
<ne78> infinity: are you doing both the debian and ubuntu packages or just the ubuntu diff ?
<infinity> He's been entirely unwilling to ever actually contribute to the official packages (short of wanting to completely take them over), so it's a mess.
<infinity> ne78: I'm one of the Debian maintainers, and the Ubuntu maintainer, yes.
<ne78> infinity: yes that's what i understood from the mailing lists
<ne78> infinity: but in the mean we (the simple users) suffer :)
<infinity> Yeah, I have an apache and php TODO a mile long, but I'll get through it all eventually.
<infinity> I only allocate a certain amount of paid time to apache and php, and the rest is "spare time" effort, so it sort of "happens when it happens". :/
<ne78> infinity: shipping etch/edgy without PDO would be a grave error
<infinity> ne78: I've heard this opinion before.
<ne78> infinity: i mean php is a critical package (at least for servers)
<infinity> ne78: On the other hand, 3rd party applications RELYING on features only present in PHP 5.1 are broken by design, so I don't think it's as critical as people make out.
<ne78> infinity: nope they are not, the api before 5.1 was insane
<robertj>   * Start OLPC Edubuntu effort (first Thailand Beta due Jan 1th 2007) <- is Thailand the code name or is there some other tie-in?
<ne78> infinity: probably a nice thing would be a PDO wrapper for pre 5.1 i'm wondering if that exists
<infinity> ne78: I'm pretty sure it doesn't.  It would be a painful mess of interpreted code.
<infinity> ne78: And, sure, the APIs have always been crazy.  PHP is a hobbyist language, IMO, and should never be used for "big apps", but oh well.  It's happened.
<ne78> infinity: i heard the same thing about the IBM PC in 1981
<infinity> ne78: But distributing an app that doesn't run on, say, RHEL3, Dapper, Sarge, etc, etc, just because you don't like the old API is a bit pointless too.
<infinity> ne78: And it's still true of the IBM PC.  Shame that it won. :)
<infinity> ne78: Anyhow, PDO's on my TODO, I'll poke at what dexter's doing and cobble something together.
<ne78> infinity: that would be great
<ne78> infinity: thanks for the attention
<infinity> ne78: It also means rethinking and redesigning the Debian/Ubuntu PHP config system a bit to not explode with insanity with a mess of new modules.
<infinity> ne78: Which is also on my TODO.
<ne78> infinity: is it a mess atm ?
<infinity> ne78: It's pretty sketchy and broken right now anyway.  It will just get uglier if I have to ship twice as many module packages, and I'd rather not.
<infinity> ne78: I'd rather have mysql/mysqli/mysql_pdo all in one package, for example, and have a sane config system that deals with that.
<infinity> ne78: (Which is already planned, just not written)
<ne78> infinity: oh yes it would be simpler
<bddebian> Howdy
<Burgundavia> robertj: that would be the country
<robertj> Burgundavia: so is Thailand considering getting software from Canonical for OLPC?
<Burgundavia> robertj: I honestly have no idea
<Burgundavia> robertj: thailand is one of the countries getting stuff. And technically, it would be Edubuntu, not Canonical
<robertj> btw, has there been any talk about pairing down system tray icons & such? Rhythmbox, Ekiga, & Tomboy all need to keep their hands off my tray by default :)
<Burgundavia> robertj: if you have a better suggestion, please raise it upstream
<slomo> robertj: for tomboy you could use the panel applet instead
<bddebian> Heya Burgundavia, slomo
<Burgundavia> hey bddebian
<slomo> hi bddebian :)
<robertj> slomo: I think its more a desktop integration issue, because the panel applets really don't do alot
<robertj> slomo: they are great if you use it all the time, if not though, they just take up space
<slomo> isn't tomboy something you would want to use all the time or never?
<robertj> slomo: maybe, but it's being positioned as a stickynotes fill-in
<robertj> slomo: and more to the point, running the application sometimes doesn't open any doucments, it just puts the icon there
<robertj> and mom is very confused by that behvavior
<bddebian> Burgundavia: You still around?
<Kaleo|work> hello rodarvus 
<rodarvus> hello Kaleo|work 
<Kaleo|work> rodarvus: I posted a comment about the intel driver
<rodarvus> (leaving in a few minutes, though)
<Kaleo|work> on bug 54858
<Ubugtu> Malone bug 54858 in xserver-xorg-video-i810 "3d acceleration broken in Edgy Knot 1" [Medium,Needs info]  https://launchpad.net/bugs/54858
<ajmitch> Kaleo|work: having issues with it?
<Kaleo|work> yes ajmitch 
* ajmitch was going to file a bug about that one..
<Kaleo|work> :)
<ajmitch> since it's a different issue now for me
<Kaleo|work> rodarvus: it might interest you :)
<Kaleo|work> ajmitch: what is it ?
<ajmitch> that the DRI driver is not initialising properly, even though it loads
<ajmitch> I haven't traced much further than that in the code
<ajmitch> pretty much just what you have in the comment
<Kaleo|work> ah
<Kaleo|work> :)
<Kaleo|work> the syncing is in good progress
<Kaleo|work> need some polishing...
<Kaleo|work> thanks to rodarvus we're getting there !
<ajmitch> yep
<Kaleo|work> I had some hard time keeping track of the changes because of all these different packages
<rodarvus> all in all AIGLX is not really meant to be a supported configuration for X, but I'll try updating Mesa one more time (since it might also make sense for other reasons)
<ajmitch> I don't know if patching the expected version is the best option though
* ajmitch didn't spot anything obvious in mesa cvs/git
<rodarvus> (... a supported configuration for X ... on Edgy I mean
<Kaleo|work> rodarvus: the DRI does not work, not just AIGLX
<Burgundavia> bddebian: am now
<bddebian> Burgundavia: You are on the Games team?
<Burgundavia> bddebian: as much as a non-MOTU can be, es
<Burgundavia> yes
<bddebian> You are not an MOTU?
<Burgundavia> nope
<rodarvus> Kaleo|work: note that it might not even be fault of X. there is a missing point on the "new intel driver" equatation (agpgart module)
<bddebian> Burgundavia: Holy crap, I didn't know that
<Burgundavia> bddebian: ask your question anyway
<Kaleo|work> rodarvus: I just compiled mesa with the sources of the 10th of august
<Kaleo|work> +have
<Kaleo|work> rodarvus: and it seems to work flawlessly
<Kaleo|work> (talking about DRI here)
<rodarvus> fixes dri, you mean?
<rodarvus> nice.
<Kaleo|work> wouch, productive night
<ajmitch> Kaleo|work: good work
<bddebian> Burgundavia: I was just wondering if someone "leads" that team? :-)
<Burgundavia> bddebian: not really. Siretart mostly
<bddebian> Hmm, OK
<Burgundavia> bddebian: I have not put a concerted effort into games stuff for a wile
<bddebian> Burgundavia: Well I have been trying but man, it's ugly out there for decent games :-(
<Burgundavia> bddebian: there are some good ones, sadly most of them have serious license issues
<Burgundavia> I just had to talk the artists for Galaxy mage out of using CC-nc for their art
<bddebian> I had issues with the scourge data files too :-(
<Burgundavia> scourge is seriously messed
<Burgundavia> somebody needs to thwack them
<bddebian> In what way?  You mean the licensing for the data?
<Burgundavia> yep
<Burgundavia> they have "borrowed" stuff from other people
<bddebian> Aye, I e-mailed them :-(
<Burgundavia> what did they say?
<bddebian> http://pastebin.us/3044
<Burgundavia> ok, at least they are considering it
<Burgundavia> bddebian: openttd is probably 6 months away from being shippable
<bddebian> Well I was just looking for something to sink my teeth into but I suppose that's a lost cause as usual :-(
<Burgundavia> bddebian: looking for games to package?
<Burgundavia> bddebian: I would start with the pyweek stuff
<bddebian> pyweek?
<Burgundavia> http://pyweek.org/
<bddebian> Uhm
<pitti> Good morning
<Burgundavia> morning pitti
<bddebian> Morning pitt
<bddebian> +i
<bddebian> Gnight folks
<pitti> lifeless: I'm currently updating edgy's bzr to 0.9; do you know about test suite failures in test_external_diff_binary? ('external diff failed with exit code 2')
<pitti> lifeless: this happens in both rc1 and the final 0.9
<lifeless> there should be no test failures
* Burgundavia watches pass his Jedi hand over the bug
<lifeless> it builds on PQM which is a dapper box, and that rejects the commit if there are test failures
<Burgundavia> "there are no test failures"
<lifeless> pitti: are you using dato's package from debian ?
<pitti> lifeless: yes, I used 0.9~rc1 and updated to the final
<pitti> lifeless: i. e. the rc1 that's currently in sid
<lifeless> ok. FWIW dato has uploaded 0.9 final himself
<pitti> lifeless: the only Debian patch is a documentation typo fix
<pitti> lifeless: oh, uploaded where?
<lifeless> well, to sid
* pitti does not see it on http://packages.qa.debian.org/b/bzr.html or http://incoming.debian.org
* pitti waves to Hobbsee 
* Hobbsee waves back to pitti 
<Hobbsee> how are you doing, pitti?
<pitti> pretty fine, and you?
<Hobbsee> i have an assignment due in 49 hours :(
<Hobbsee> i found out about it about 2 hours ago.
<pitti> ouch
<pitti> Hobbsee: have a productive night shift then
<jdub> :-)
<jdub> hey pitti 
<pitti> jdub: hey Jeff!
<jdub> pitti: so i've tested a backport of edgy trac on dapper - working pretty good
<Hobbsee> pitti: no, i have to got to work tonight.  :(
<Hobbsee> hi jdub 
<jdub> pitti: can i do anything else to encourage a security release of it? :)
<jdub> hey Hobbsee 
<pitti> jdub: I'm not sure whether we can do official backports ATM (I think we can't)
<Hobbsee> i havent heard that we can
<pitti> jdub: well, 0.9.6-0ubuntu0.1 would work for me, too, if mdz approves the new upstream version
<jdub> pitti: this would be an upstream bumped security release
<jdub> ok, so it needs mdz love
<pitti> jdub: well, you can :) sending mdz a changelog and asking for approval would be enough encouraging :)
<jdub> ok!
<pitti> jdub: I can do the actual update myself then
<jdub> pitti: best to mail you and mdz, or is there a bug alias i should use?
<pitti> jdub: just use security@ubuntu.com
<jdub> ok
<jdub> thanks
* infinity wnonder what the deal is with this "nautilus-gksu" sitting in the new queue..
<infinity> Does anyone know what Gauvain Pocentek's nick is?
<Burgundavia> infinity: he ans seb128 are talking about it
<pitti> infinity: Gloubibolka or something like this (I'm sure you saw it before)
<infinity> pitti: Ahh, yeah.  Him.  He doesn't seem to be around.
<infinity> Burgundavia: "Talking about it" in the "seb's trying to make him revert it, so I should just hold off" sense?
<Burgundavia> infinity: there is a thread on -devel about it
<Burgundavia> just a sec
<Burgundavia> infinity: https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/019957.html
<infinity> Hrm, that's pretty inconclusive.
<pitti> lifeless: ah, the test failure happens with de_DE.UTF-8, but not with C; I'll file a bug
<lifeless> pitti: are you running 'make check' during the pacakge build ?
<lifeless> pitti: or 'bzr selftest' ?
<pitti> lifeless: the former
<lifeless> ok, good.
<pitti> lifeless: bug 56307, in case you want to add something
<Ubugtu> Malone bug 56307 in bzr "bzrlib.tests.test_diff.TestDiff failure in German locale" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56307
<pitti> infinity: any idea why krb5_1.3.6-1ubuntu0.2_source.changes (hoary-security) is not attempted to be built?
<infinity> pitti: Looking...
<infinity>   Package             : krb5
<infinity>   Version             : 1.3.6-4ubuntu0.1
<infinity>   Builder             : buildd+terranova
<infinity>   State               : Installed
* infinity looks suspiciously at pitti's 1.3.6-1ubuntu0.2 source upload, which is a lower version...
<pitti>       krb5 | 1.3.6-1ubuntu0.1 | http://security.ubuntu.com hoary-security/main Sources
<pitti> ^ this is currently in the archive
<infinity> Yeah, dude.  You uploaded the breezy-security update to hoary-security.
<infinity>  krb5 (1.3.6-4ubuntu0.1) hoary-security; urgency=low
<lifeless> whoops
<pitti> infinity: argh
<infinity> pitti: You can either try to get elmo to UNACCEPT all of those, or you get to fudge version numbers to fix it.
* pitti prefers the former
<infinity> elmo: Alive?  pitti needs some UNACCEPT love on jackass. :/
<pitti> infinity: I'll email him
<infinity> pitti: Check.  Make sure to be very specific about which ones need UNACCEPTing, to avoid back and forth. :)
<pitti> infinity: I can leave the right hoary one as it is, I assume?
<infinity> pitti: krb5_1.3.6-4ubuntu0.1*changes should do it, I guess.
<infinity> pitti: Yeah, if you leave the correct hoary one in place, I can fix wanna-build manually after elmo unaccepts the others.
<pitti> thanks
<pitti> infinity: ah, there is Gloubiboulga
<infinity> Err, wait.  Hrm.
<infinity> cron.daily no longer runs on jackass, which makes manually fixing wanna-build problematic...
<infinity> Well, I can sort that with elmo after the unaccept happens.
<jdub> pitti: YAY BZR 0.9!11
<pitti> jdub: \o/ the speed improvements were too tempting :)
<Gloubiboulga> pitti, infinity, hello, do you need me for something?
<pitti> Gloubiboulga: hello; Adam asked for your nick :)
<Gloubiboulga> ok :)
<pitti> mjg59, Kamion: can you please approve my u-d-a post?
<doko> pitti: ping
<pitti> doko: Guten Morgen
<infinity> Gloubiboulga: *poke*
<pitti> hey mvo!
<pitti> http://librarian.launchpad.net/3893988/buildlog_ubuntu-edgy-i386.bzr_0.9-0ubuntu1_FAILEDTOBUILD.txt.gz *gulp*
<imbrandon> ouch
<pitti> lifeless: ^ lots of test suite failures, didn't happen to me locally
* pitti hugs seb128 
<infinity> mvo: Hey dude.  What's the story with Gloubiboulga's gksu/nautilus-gksu split?  Have we decided this is definitely the Right Thing to do (ie: should I process the binaries from queue/new), or is this still a point of contention?
<seb128> hey pitti
<infinity> pitti: Looks like they're all "None" versus "0" breakage..
<infinity> pitti: Do you have the latest and greatest python installed, to make sure it's the same as the chroot?
<pitti> infinity: yes, fresh after today's dist-upgrade (which only pulled in a new totem)
<pitti> infinity: however, the ENOFILE errors might be the cause
<mvo> hey pitti, seb128!
<seb128> hi mvo
<infinity> pitti: Ahh, didn't catch that.
<mvo> infinity: the new gksu has a nautilus plugin that makes the package unsuitable for xubuntu, thats why the split
<lifeless> bte you TZ=UTC
<lifeless> theres a bug open and a fix for it
<pitti> oh, cool
<infinity> mvo: Right, but the split's okay by you, then?  And doesn't require any migration plan, because that bit's new anyway?
<mvo> infinity: yes, nautilus-gksu is new anyway. I looked over the diff and it looks ok
<infinity> mvo: Great.  I'll process it, then.  Thanks.
<seb128> mvo: using a Recommends or Suggests nautilus without splitting would be possible too no?
<infinity> mvo: Err, will it be ending up in ubuntu-desktop (and thus in main), or should I shove it in universe?
<infinity> mvo: (And if the former, can you update the seeds?)
<infinity> seb128: No, it links to the whole GNOME stack.
<seb128> infinity: right, but that doesn't mean we need a Depends ;)
<infinity> seb128: Unless you're suggesting not having proper shlibdeps (eek), it needs to be split.
<seb128> infinity: yeah, that's what I suggested, we do it for some other packages already
<infinity> seb128: IMO, if you ever have to override shlibdeps, you know you're doing something wrong.
<seb128> infinity: you can exclude that .so for the shlibs call
<mvo> seb128: do we want it in main? 
* infinity shudders.
<seb128> infinity: not really, I'm fine with having a nautilus file installed but not used if nautilus is not installed :)
<seb128> mvo: main, probably yes, it makes no sense to have a some binary from a main src package to universe, desktop I'm not sure, I think it clutters the context menu
<infinity> seb128: Yeah, but if it links to stuff that the rest of the package doesn't, library dependency breakage can occur.
<infinity> seb128: The whole point of versioned shlibs is a bit lost if you have binaries that don't declare proper dependencies.
<seb128> the point is to the have things working
<seb128> having a feature working if nautilus is installed and doing nothing otherwise is sort of working ;)
<seb128> anyway I'm fine with the split, my comment on the list is just that I would prefer to have that discussed with the Debian maintainer (who is upstream too) before being done
* infinity nods.
<mvo> seb128: agreed
<mvo> seb128: I will mail him
<infinity> mvo: If main-but-not-desktop is agreed upon, please update the seeds to put it in supported, and I'll toss it in main.
<seb128> mvo: the guy who did the split opened a bug on the BTS with the patch after I asked him to do that :)
* infinity waits for some sort of concensus. :)
<mvo> seb128: what bug number?
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382655
<Ubugtu> Debian bug 382655 in gksu "gksu brings the GNOME libs as dependencies" [Unknown,Open]  
<seb128> mvo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382655
<seb128> damn, too slow :p
<infinity> Hah, I win.
<mvo> :)
<infinity> At least Ubugtu appears to be smart enough to not be repetitive.  Cute.
<seb128> mvo: BTW the package should probably Depends on nautilus too
* infinity threatens to walk away from queue/new processing for a week if someone doesn't give him a main/universe decision.. :)
<seb128> infinity: main
<mvo> infinity: "main"
<infinity> Check.
<seb128> supported but not desktop
<mvo> *nod*
<Gloubiboulga> /me apologize for the gksu thing
<mvo> infinity: happy now :) ?
<Gloubiboulga> hi mvo, seb128 
<mvo> hi Gloubiboulga
<infinity> mvo: I'll be happy when you fix the seeds. :P
<seb128> Hi Gloubiboulga
<infinity> mvo: Anyhow, binaries accepted.
<mvo> hi Gloubiboulga, nothing to be sorry about. thanks for taking care for this
<mvo> infinity: thanks
<seb128> Gloubiboulga: np, just pinging the desktop team before changing something from GNOME is a good idea usually ;) And opening a Debian bug too :p
<Gloubiboulga> seb128, agreed :)
<pitti> lifeless: okay, I found the suggested patch on the ML and applied it to the package; seems to work fine
<pitti> lifeless: thanks for checking
<lifeless> np
<lifeless> hth
<pitti> (it's not yet applied upstream)
<mvo> infinity: seed updated too
* pitti yays precise test suite failures: "AssertionError: <Revision id A> != <Revision id A>"
<mantiena> Hi all
<mantiena> doko: hi, are you alive ?
<pitti> infinity: do you plan to update edgy/sid mysql to 5.0.24? .24 fixes CVE-2006-4031
<ogra> pitti, ping
<mantiena> doko: hi, are you alive ?
<mantiena> doko_: I wanna ask few questions about OpenOffice.org, wich is in dapper-proposed
<doko_> there it is.
<mantiena> doko: are there any important reasons (e.g. important bugs) why OOo 2.0.3-4dapper2 isn't in dapper-updates or backports ?
<mantiena> doko: I just wonder if I can try to use this version on workstations in my office
<doko> mantiena: see the filter bug reports
<raphink> hi
<raphink> I've got a problem with germinate
<raphink> the update script in (k)(x)ubuntu-meta packages don't seem to be able to use Germinate.py
<raphink> ImportError: No module named Germinate
<raphink> although I have installed the germinate package
<raphink> (or Germinate.pm maybe)
<raphink> germinate.py is present in /usr/lib/germinate/germinate.py though
<pitti> ogra: pong
<ogra> pitti, how hard would it be to add a --bind option to pmount 
<mantiena> doko: filter by wich criteria ?
<ogra> (even with a hardcoded dir if you want for secutity reasons)
<mantiena> s/wich/which
<ogra> s/dir/sourcedir/
<pitti> ogra: not that hard code-wise; but it needs to be restricted 
<ogra> indeed
<pitti> ogra: what should it do?
<ogra> pitti, ltspfs mounts in /tmp/.$UID/device now ...
<ogra> pitti, to get that on the users desktop i have two options:
<ogra> a) put a link on the desktop and make ugly changes to ~/.gtk-bookmarks etc
<ogra> b) mount --bind  /tmp/.$UID/device /media/$IP/device 
<pitti> ogra: why not have ltspfs mount it to /media/device?
<ogra> b makes everything work fine ...
<ogra> the prob is that i need root rights to exec mount :)
<ogra> thats why i think pmount is the right place
<pitti> ogra: so, why can ltspfs mount to /tmp, but not to /media?
<ogra> my prob is that ltspfs operates in userscpace
<pitti> ah, fuse?
<ogra> yep
<ogra> nodev 
<ogra> so i need a mount proggy that drops privileges but issues mount as root
<ogra> aka pmount :)
<pitti> it feels a bit like abuse
<ogra> hmm
* pitti ponders
<pitti> ogra: so actually the problem is just the displaying on desktop?
<pitti> ogra: so actually the problem is just the displaying on desktop?
<ogra> grr
* ogra kicks his wlan where it rally hurts
<ogra> *really
<ogra> pitti, well, no
<ogra> pitti, its also having the device in the bookmarks list and havong the right icon
<ogra> argh i'm going mad here 
<ogra> <ogra> pitti, its also having the device in the bookmarks list and havong the right icon
<ogra> <ogra> and being able to access it from openoffice
<pitti> ogra: and gnome-vfs does not show stuff in /tmp?
<ogra> the ltspfs mount cares for the /tmp dir not being accessible by anyone apart from the user who mounted
<pitti> ogra: it seems related to bug 50554
<Ubugtu> Malone bug 50554 in gnome-vfs "removable devices should only show up on the desktop of the user who can access them" [High,In progress]  https://launchpad.net/bugs/50554
<ogra> well, i'd like to be able to use the exisiting infrastructure
<pitti> ogra: i. e. gnome-vfs could also display mounts in !/media
<ogra> and g-v-m only picks up real mounts from /media
<pitti> g-v-m?
<ogra> isnt g-v-m responsible here ? 
* pitti assumes that is supposed to mean g-vfs
<ogra> oh, ok
<pitti> ogra: g-v-m doesn't display anything, it just mounts
<pitti> ogra: i. e. the icons you see on the desktop, panel, etc. are gnome-vfs' responsibility
<ogra> ah
<pitti> ogra: would it be possible to mount the stuff into the user's ~?
<ogra> is theer a config i can tweak to make it pick up /tmp/.$UID/ ?
<pitti> well, /tmp/$UID is fine, of course
<ogra> if i mount in ~ several people in here will slay me :)
<pitti> ogra: I think so, should be configurable with hal FDIs
* ogra looks secretly at iwj 
<pitti> ogra: let me play with that a little
<pitti> ogra: give me 5 minutes to start off that edgy powerpc install, then I'll look into it
<ogra> pitti, wow, cool, thanks for that
<pitti> arrgh
<pitti> ppc/live's ubiquity immediately dies and the alternate CD does not have kernel modules
<ogra> ??
<ogra> ouch
<pitti> ok, no edgy install today either
<pitti> ogra: does that look right for your use case?
<pitti> mkdir -p -m 700 /tmp/.1000/cdrom
<pitti> sudo mount -o loop,uid=1000,gid=1000 -t iso9660 download/ubuntu/edgy-alternate-powerpc.iso /tmp/.1000/cdrom/
<ogra> pitti, how will that work with non gnome desktops btw ? 
<ogra> yep
<ogra> apart from me not using a privileged user 
<pitti> well, structure-wise
<pitti> ogra: I cannot answer that for 'non-gnome'; every desktop will have its own method (and things like fvwm don't care about that at all)
<ogra> no, but we'll likely ship xfce additionally
<ogra> and many users want to use it with kubuntu
<ogra> neither uses g-vfs, but all check /media
* ogra cries
<ogra> pitti, 
<ogra> <ogra> no, but we'll likely ship xfce additionally
<ogra> <ogra> and many users want to use it with kubuntu
<ogra> <ogra> neither uses g-vfs, but all check /media
<pitti> I saw that
<ogra> ok
<ogra> my wlan dies every 2 mis here :(
* pitti still doesn't like abusing pmount for creating random bind mounts
<pitti> ogra: the AE again?
<ogra> AE ?
<pitti> airport express
<ogra> no, another linksys card
<ogra> but i usually have no probs with it
<ogra> no idea why it dies today :/
<pitti> ogra: are these loopback mounts?
<pitti> ogra: and, btw, HAL FDIs don't work here :/
<pitti>         if (mount->is_loopback ||
<pitti>             !(mount->is_user_mountable ||
<pitti>               g_str_has_prefix (mount->device_path, "/vol/"))) {
<pitti>                 return NULL;
<pitti> ^ oh, that's just for the drive, but we want only the volume
<pitti> ogra: ok, I located the spot in gnome-vfs which we'll need to patch for this, if we go that route
<raphink> ogra: do you have any idea about my germinate issue?
<pitti> ogra: ok, I located the spot in gnome-vfs which we'll need to patch for this, if we go that route
<ogra> does xfce use gnome-vfs ? 
<Gloubiboulga> ogra, xfce doesn't use gnome-vfs
<ogra> hmm
<StevenK> doko: Do you have any plans of updating python-support in edgy?
<doko> StevenK: yes, will need to sync these
<StevenK> doko: Excellent, then I can just sync.
<doko> StevenK: please wait until these tools are synced
<StevenK> doko: Certainly, I wasn't planning on otherwise.
<rodarvus> infinity, builds of xorg-server and xserver-xorg-video-i810 failed on powerpc, due to the archive issues of last Friday - these issues appear to be fixed now
<rodarvus> could you please retry the build of those two packages on powerpc for me?
<iwj> Urgh, my speling is awful today.
<pitti> rodarvus: enjoy bzr 0.9 in edgy :)
<ogra> grr
<ogra> why did they have to call the directory /media
<Treenaks> ogra: why not?
<ogra> its impossible to find something at google if you search for "gnome-vfs media"
<ogra> because it will always refer to the media, not to the dir
<rodarvus> pitti, thanks! :)
<HiddenWolf> gnome-vfs /media ?
<Treenaks> HiddenWolf: google strips non-word chars
<ogra> HiddenWolf, same 
<rodarvus> all of us will enjoy bzr 0.9 in edgy ;
<rodarvus> ;)
<ogra> even with quoting etc
<iwj> Wow, my X server is doing opaque move in software.
<ogra> but i still think we wont get around abusing pmount or writing something equivalent ... if it doesnt work with KDE and XFCE we cant make it an upstream feature, which we must
<HiddenWolf> Treenaks: hm, never had any trouble with that.
<ogra> HiddenWolf, find me a page then that explains how gnome-vfs uses media and why it does that, there is no trace for a /media in the source
<ogra> :)
<Riddell> ogra: what's this?
<ogra> Riddell, ltspfs
<ogra> local devices mounted on your desktop from thin clients
<rodarvus> ogra, "gnome-vfs \/media" doesn't works?
<ogra> rodarvus, no
<Treenaks> rodarvus: I want 0.9 in dapper ;)
<rodarvus> Treenaks, ask for a backport ;)
<HiddenWolf> ogra: http://developer.gnome.org/doc/guides/platform-overview/platform-overview.html#gnome-vfs guess you'd start there
<iwj> ogra: /media is set up by the installer I think.
<ogra> Riddell, pitti just wants to modify gnome-vfs to look in /tmp/.$UID (where we do the network mount from the client) but that would exclude KDE and XFCE 
<iwj> At least, some of it.
<rodarvus> Treenaks, pitti might be able to tell you how hard the package upgrade from 0.8 to 0.9 was, but I guess this is pretty straightforward stuff
<ogra> iwj, i want to know how gnome-vfs knows that it should monitor /media 
<pitti> ogra, Riddell: I'm happy to further discuss a lower-level solution
<pitti> Treenaks: sure, it's data compatible and all that
<Treenaks> pitti: ok, cool
<ogra> there must be something in the source telling it to do that and i seem not to be able to find it
<ogra> HiddenWolf, and that you found via google ? 
<HiddenWolf> ogra: pretty much
<HiddenWolf> ogra: I pretty much just pasted your question into google. ie: how gnome-vfs uses media. This document is the 5th hit and links to the fd.o spec and the gnome-vfs api docs
<ogra> which doesnt help all, i already looked there 
<ogra> but thanks for the effort 
<HiddenWolf> ogra: can't you ask the maintainer?
<ogra> sure, but i dont want to take to much of pittis time and i need to understad the process myself ...
<HiddenWolf> ogra: your call, but I guess that asking for a pointer would save you more time that it would cost him. :)
<HiddenWolf> Anyway, I have to run, best of luck.
<cbx33> ping mjg59 
<infinity> pitti: Yeah, should happen.
<pygi> sivang, poke?
<zul> hey
<TheMuso> c
<TheMuso> wc
<pygi> heno, hey, how is your student doing?
<mantiena> doko: Does bug #55874 exist in latest dapper packages from proposed-updates (OOo 2.0.3-4dapper2)  ?
<Ubugtu> Malone bug 55874 in openoffice.org "upgrading dapper -> fails as 'ooqstart' is in '-core' and '-gtk'" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/55874
<doko> mantiena: yes
<mantiena> doko: so, why it's unconfirmed ?
<mantiena> ;)
<sbalneav> pitti: Ping
<pitti> sbalneav: pong
<sbalneav> hey pitti, got time for a quick pmount request/discussion?
<pitti> sbalneav: about ltspfs mounting? ogra already asked me about this this morning, but go ahead
<sbalneav> Ogra's having internet trouble today.  I guess there's 2 problems with a vfs patch:
<sbalneav> 1) doesn't fix it for kde/xfce
<pitti> right
<sbalneav> 2) user can't easily do a file->open in OO.o, and then has to rummage trough /tmp
<mantiena> doko: btw, what couses bug #55874 ? it seems debian/rules is ok - it moves qstarter binary to ooo-core package
<Ubugtu> Malone bug 55874 in openoffice.org "upgrading dapper -> fails as 'ooqstart' is in '-core' and '-gtk'" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/55874
<sbalneav> so a pmount --bind to get us into the /media tree would be preferred.
<ogra> sbalneav, we should give pitti a little background info ;) ltsp will merge with our code in edgy+1, so we need to make our stuff upstream compatible ...
<pitti> sbalneav: TBH, I'm not a fan of adding random unrelated functionality to pmount, like bind-mounts
<ogra> i.e. have a generic solution thats not bound to a DE
<sbalneav> oh, sorry, tought you may have done that already.
<pitti> sbalneav: however, I do see that using /media is the way to go
<sbalneav> Is that a yes, then? :D
<pitti> sbalneav: thus, using a setuid wrapper seems to be appropriate, if no appropriate daemon is available
<ogra> thats a no to pmount changes :)
<zul> does anyone know why the builds are complaining that a dbg package doesnt exist when it should not exist in the first place?
<ogra> but a yes to a limited pount clone :=
<pitti> sbalneav: however, I would be much happier with a well-defined and small new suid wrapper
<ogra> :)
<ogra> *pmount
<pitti> sbalneav: does it have to be a bind mount, or is a symlink actually enough?
<ogra> nope
<ogra> symlinks dont work, tried that already
<pitti> sbalneav: and why not mount the volumes straight under /media rather than /tmp?
<ogra> probably if we add weird virtual hal devices 
<ogra> but with a 100 user setup that will make hal crazy i guess
<ogra> pitti, because the user has no write access in /mount
<ogra> and the mounter runs as user ... not as root
<sbalneav> ogra: is a setuid wrapper something we could do?  I could handle it.
<ogra> its 100% userspace ... from the filesystem up to the rest ...
<pitti> ogra: I mean, if you mount to /tmp because you cannot access /media and then invent a hack to bind /media to /tmp, why not use a cleaner solution to mount straight into /media?
<ogra> sbalneav, just take pmount, rip out all normal mount functionallity and et it only do bind mountig
<ogra> pitti, indeed
<pitti> sbalneav: well, pmount has a *lot* of stuff that's not required for the thing you want to do
<ogra> if we need a suid wrapper anyway
<ogra> sbalneav, also lets use the surce directory as hardcoded value, that minimizes possible security probs
<pitti> sbalneav, ogra: from what I see, the wrapper should just do an mkdir /media/foo, right?
<sbalneav> pitti: correct. The mount would happen as the user.
<pitti> once the directory exists, you can fuse-mount it just as /tmp/$uid
<ogra> no
<pitti> sbalneav: so, a small ltsp-related mkdir /media/foo suid wrapper seems safe, contained, and appropriate
<ogra> you still need to bind mount ithe dirs
<pitti> ogra: why?
<ogra> its more tan mkdir
<pitti> ogra: bind mount sounds just evil; why do you need it? 
<ogra> because the vfs'es wont pick it up as device if its not bind mounted
<pitti> ugh?
<pitti> well, that's something new :)
<ogra> ltspfs isnt seen as device 
<ogra> no, i told you this morning that we will need the bind mount :)
<pitti> I'd call that a bug in the VFSes
<ogra> and that there is no device
<pitti> ogra: yep, I assumed it was just for mirroring /tmp to /media
<ogra> no :)
<pitti> but anyway
<pitti> then the suid wrapper needs to mkdir and mount -o bind, okd
<pitti> s/d$//
<ogra> yep :)
<pitti> but that's still not much
<ogra> indeed
<sbalneav> ogra: ok, we can handle that.
<pitti> sbalneav, ogra: I'm happy to audit the code
<pitti> that is, if we agree to that solution
<ogra> sure
<ogra> i'll take everything that works and passes your eagle eyes :)
<pitti> so, ltspfsmount and ltspfsumount? :)
<sbalneav> pitti: You may audit our code on condition that you let me buy you a beer next conf :)
<pitti> sbalneav: hard, but acceptable :-P
<ogra> i'd say ltspfsmount {--add,--remove} ;)
<Amaranth> that's not very mount-y
<ogra> we dont need any mount-y code
<sbalneav> ogra: yeah, I like that better.  only 1 suid script to worry about :)
<ogra> its only used internally 
<ogra> exactly
<sbalneav> Mounties?  We have those in Canada.  Red tops, ride the horses, etc/
* ogra wonders why his net is stil up ... thats unusual
<pitti> sbalneav: heh, I remember them from my trip through Canada :)
<pitti> ogra? ogra? hey, where are you? 
<pitti> :)
<ogra> heh
<ogra> i painted my office over the weekend ... probably the orange pugment shields wlans 
<ogra> *pigment
<sbalneav> you painted your office.... orange? :)
<ogra> well, they call it terracotta :)
<gnomefreak> with orange walls its gonna be hard to sleep in office ;)
<ogra> feels a bit like working in a flowerpot :)
<Hobbsee_> ogra: you've tried this, so that you can compare?
<ogra> Hobbsee, sleeping in the office ? 
<Amaranth> working in a flowerpot
<Hobbsee> ogra: or working in a flowerpot.  either way.
* Hobbsee has slept in interesting places, like the library, before.
<ogra> well, i dont fit in any of the flowerpots around here :)
<ogra> but i imagine it feels similar
<Hobbsee> heh
* zul cant sleep anywhere weird
<iwj> Does anyone here know what a .chk file is ?
<Treenaks> iwj: can't 'file' tell you?
<Treenaks> iwj: (also, chk files are created by chkdisk in dos/windows, like files in lost+found by fsck)
<iwj> Treenaks: No, file says `data'.  It's something the Mozilla build system has spewed out and seems to be something to do with libnss.
<Treenaks> iwj: hm, maybe test data?
* iwj finds `The chk files are only required for FIPS140 mode, which you can enabled 
<iwj> with modutil'
<iwj> Hmm.  You may be right.
<iwj> (FIPS 140 requires algorithm self-tests with specific test vectors.)
<Treenaks> because the only other references I find are related to 'tomtom' GPS navigation devices
<Treenaks> (and I don't think _they_ do FIPS 140 on the voice data...)
<iwj> :-)
<iwj> I think the reference to FIPS-140 is convincing to me, so that means I know I need to ship it in case some fool turns on the FIPS-140 mode.
<ogra> iwj, .chk gets created from windows fsck usually
<ogra> usually with a number code as name 
<Seveas> ogra, but I find it hard to believe windows chkdsk messes with his firefox builds on Ubuntu ;)
<Hobbsee> Sev
<Hobbsee> Seveas: you never know :P
<iwj> That's definitely not what it is :-).
<ogra> Seveas, well, if he runs the windows build in a chrooted vmware setup or something :P
<ogra> indeed they shouldnt exist in linux :)
<Seveas> ogra, i find it hard to believe that iwj would run windows builds, given that the linux builds are annoying enough already ;)
<ogra> indeed ;)
<ogra> i wasnt serious 
<ogra> but windows is the only place i ever saw .chk files 
<Seveas> me neither -- serious mode is gone after trying to cash in a check from pearson today
<Seveas> I finally made money with Ubuntu 
<sbalneav> Seveas: Kanjii smiley.  Nice.
<bmon> sbalneav: isn't that hirigana? (sp?)
<iwj> seb128: Sorry about the ff nss breakage.  I think I have a fix and if we're lucky it might make it into the archive today.
<zul> heh...thats funny firefox just crashed
<BenC> anyone know when a fixed evo is going to be uploaded?
<seb128> iwj: np, but could you not upload a new version on friday afternoon without giving a try to other apps concerned or pinging the corresponding maintainers next time? :)
<BenC> sweet, iwj answers my question before I even typed it :)
<seb128> iwj: the GNOME bug has around 60 dups by know, ie. many users who had no MUA since friday and extra work for upstream
<pitti> iwj: since the new libnss or libnspr3 is not compatible with ffox 1.5, and ffox 2.0 does not work with the old library versions, does that warrant a soname bump?
<geser> bmon: I think it's U+30C4 KATAKANA LETTER TU
<pitti> iwj: or does your fix repair that abi compatiblity as well?
<seb128> pitti: how is it not compatible? (just curious)
<pitti> seb128: new libs + old ffox: ffox cannot use SSL
<pitti> seb128: old libs + new ffox: ffox crashes (according to Keybuk)
<seb128> pitti: are you sure that's not the same bug as the evolution one?
<bmon> geser: looks like you're right, been too long :)
<seb128> pitti: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/56118
<Ubugtu> Malone bug 56118 in evolution "Crashes on startup" [Unknown,Confirmed]  
<pitti> seb128: might very well be the same incompatiblity
<seb128> pitti: look the small example on that bug
<seb128> iwj: BTW the totem plugin crasher is because the new firefox doesn't link to libxpcom.so
<iwj> I don't know if this change fixes binary compatibility but I doubt it.
<iwj> But I'll do some tests.
<iwj> seb128: And yes, I'm sorry about making a mess.  I take your points.
<seb128> iwj: ok, thank you for considering that next time ;)
<iwj> Part of the problem is that there's a bit of libnss in the ff 2.0 beta firefox package.
<cbx33> ping Keybuk 
<BenC> cool, backing down to dapper's firefox lets me get email again :)
<pitti> BenC: LD_LIBRARY_PATH=/usr/lib/firefox evolution
<seb128> BenC: you can also use LD_LIBRARY_PATH=/usr/lib/firefox to start evolution
<BenC> oh well, I'll stick with this for awhile, thanks though
<iwj> Yes, you need that too.  I think it may be compatible the other way around without that.
<iwj> seb128: BTW, your nssinit.c program has insecure use of /tmp and shouldn't be run on a multiuser machine ...
<seb128> iwj: right, I picked some random path to give it a quick try on my box, I could have changed that before attaching to the bug
<iwj> Yes, new ff seems to work with old libnspr so I think it's compatible (no matter what the dependencies say).
<Keybuk> cbx33: 'sup?
<cbx33> Hi Keybuk , I realise you'r super busy, is there any chance of getting gisomount moved off of NEW and into the universe
<cbx33> I didn't realise I was sposed to ask someone once it got to NEW status
<cbx33> ogra mentioned that it may be an idea to ask someone
<ogra> well, after three weeks *i* would ask someone :)
<cbx33> heh :p
<Keybuk> cbx33: it'll processed in due course
<Keybuk> NEW checking requires a particular mind set
<Keybuk> not to mention some time
<cbx33> Keybuk, I understand
<Keybuk> is there any particular urgency for this?
<cbx33> forgive my intrusion
<cbx33> Keybuk, my first ubuntu package
<cbx33> what can I say :p
<cbx33> plus i think it would be useful for people at beta testing time
<cbx33> other than that, no
<cbx33> pardon my impatience ;) - ogra can vouch for that :p
<Zdra> hi, I got a crash just after installing new crash report system... I see that the generated file is 6Mo ! that's far too much for poor upload connections I think.
<pitti> Zdra: maybe I should add a button to remove the core dump, which will make it < 10 kB
<pitti> Zdra: however, it's a very useful piece of information
<cbx33> pitti, could it be optional?
<Zdra> pitti: maybe just gzip it ?
<cbx33> I was just gonna suggest that
<pitti> Zdra: it's already bzip2'ed
<mdz> Zdra: it's already compressed, naturally
<Zdra> hm
<cbx33> hehe, thought so
<mdz> pitti: perhaps we should offer two options "send full report" and "send partial report"
<pitti> cbx33: as I said, apport-gtk shows the file size, I could add a button to remove the dump
<pitti> mdz: apport-gtk does not actually 'send' the report, it just asks to file a bug and attach the file
<cbx33> mdz, sounds good, would it be an idea to say why?
<cbx33> like slow/connection fast/connection
<mdz> cbx33: "send full report (6 mb)" "send partial report (10 kb)"
<cbx33> yeh sounds good
<Zdra> great :)
<pitti> mdz: I could create a temporary file with a reduced report and offer/display this as well
<cbx33> hi pygi 
<Sp4rKy> hi
<Sp4rKy> please when start edgy translation ?
<dmg> pitti: I assume the backtrace is already in the report?
<seb128> Sp4rKy: ask to carlos on #launchpad
<Sp4rKy> seb128, thx
<seb128> np
<Zdra> pitti: tar -cjf compress the file from 6M to 4M
<pitti> dmg: yes, but only the one without debug symbols
<pitti> Zdra: ok, worth considering
<bddebian> Howdy
<iwj> Bah, test build died right at the end.
<dmg> pitti: so bzip2 pulls off another 2M.. I thought they were already compressed.  You're using gzip?
<pitti> dmg: well, the core is bzip2'ed, but then base64-encoded, and the rest of the info is just plain ascii
<dmg> ah, so there is some redundancy to be pulled out afterwards.
<pitti> right
<dmg> but if the resulting tar file has to be base64 encoded, it's just going to expand again.
<pitti> dmg: it doesn't need to be a tar
<pitti> dmg: the single file has all information
<dmg> pitti: sorry, this was in refernece to zdra's 'tar' comment.
<dmg> the only saving there would come from the -j, which re-bzip2's the info, but since the resulting file has to be base64-encoded again it's just going to expand out by whatever the base64 expansion ratio is.
<dmg> which is probably what bzip2 managed to pull out of the base64 encoded core file in the first place.
<pitti> exactly
<pitti> 6/8 :)
<pitti> (from the coredump)
<pitti> and maybe 50% from the rest
<dmg> but if the non-corefile version is only 10k, a saving of 5k on a 4-6M file isn't worth it.
<Zdra> ok so compression isn't a solution, I think for low upload 1M is a max
<pitti> dmg: launchpad should be able to handle binary data just fine
<pitti> dmg: I just made it ascii so that developers can look at the file
<pitti> and to keep it in debcontrol format
<wasabi__> Something keeps setting LANGUAGE in /etc/environment to en_US:en_GB:en
<wasabi__> I'd have expected en_GB to not be in there.
<wasabi__> I believe it's causing my trash to be known as a wastebasket. :0
<mdz> wasabi__: bug 10822?
<Ubugtu> Malone bug 10822 in localechooser "en_US users see en_GB strings all over?" [High,Fix released]  https://launchpad.net/bugs/10822
<wasabi__> Yeah looks like it.
<mdz> wasabi__: note that it's marked fixed
<mdz> since May
<wasabi__> Update regenerate /etc/environment?
<wasabi__> Could have been sitting there for awhile.
<wasabi__> And I just never noticed.
<mdz> not automatically, no
<mdz> it's possible that the language selector updates it. mvo?
<mvo> mdz: looking at the bug now. but it will not update /etc/environment unless explicitely done in the GUI
<mdz> mvo: that's what I meant.  I wanted to be sure that even if the user changes settings in the gui, /etc/environment doesn't get the en_GB stuff which resulted in bug 10822
<Ubugtu> Malone bug 10822 in localechooser "en_US users see en_GB strings all over?" [High,Fix released]  https://launchpad.net/bugs/10822
<mdz> wasabi__: did you check the mtime on /etc/environment?
<wasabi__> Naw, I edited it.
<wasabi__> Heh. Nice. I added english support in the gnome-language-selector, and it's removing Yelp.
<wasabi__> apt sillyness.
<wasabi__> Oh. Apparently it was removing a lot more than that, too.
<mdz> pitti: upgrading seems to remove bzrtools; is it obsolete or is a newer version needed for the new bzr?
<mdz> pitti: ah, looks like the latter
<pitti> mdz: I requested a sync for the newer Debian version
<mdz> pitti: yes, I just saw bug 56308
<Ubugtu> Malone bug 56308 in bzrtools "Please sync bzrtools (main) from unstable" [Untriaged,Confirmed]  https://launchpad.net/bugs/56308
<pitti> mdz: however, the old bzrtools and new bzr coexist for me package-wise (just generate a nasty warning)
<mdz> pitti: really?  bzrtools depends: bzr (<< 0.9)
<mdz> bzr 0.9 won't install without removing the current bzrtools in edgy
<pitti> mdz: but not conflicts:
<pitti> mdz: is depends << version useful at all?
<pitti> oh, hm
<pitti> mdz: ignore me, please :)
<mdz> it is in apt, at least
<pitti> mdz: ah, I just dpkg -i'ed the new bzr package
<iwj> seb128 (and anyone else): fixed firefox on its way.
<Riddell> carlos: ping
<seb128> iwj: cool, thank you
<Riddell> carlos: needed in #ubuntu-meeting
<carlos> ok
<Keybuk> pitti: dpkg doesn't "sanity check" the installation the same way apt does
<Keybuk> so it's possible to install something that should break another package's dependencies, provided you don't install that other package in the same run
<bddebian> Aye :-(  I've hit that
<iwj> This is a bug.
<iwj> It should refuse unless you say -B, and then it should deconfigure the other thing.
<ogra> how would it know about the other package if thats never been installed ? 
<pitti> ogra: it is installed
<ogra> ah
<pitti> ogra: i. e. I had bzrtools 0.8 installed and then dpkg -i'ed bzr 0.9
<pitti> that didn't break
<pitti> althought bzrtools 0.8 depends: bzr < 0.9 
<ogra> ouch 
<pitti> -t
<pitti> so I didn't even notice 
<ogra> i missed the backlog, sorry
<jcole> kernel hackers
<jcole> in the "apt-get source linux-source-2.6.15" package, which kernel file do i edit in ./debian/config/i386/ to make my changes?
<Keybuk> pitti: Debian #20471 or Debian #170825
<Ubugtu> Debian bug 20471 in dpkg "dpkg ignores conflict with unconfigured package" [Unknown,Open]  http://bugs.debian.org/20471
<Ubugtu> Debian bug 170825 in exim4-base "dpkg does not respect virtual dependencies when upgrading." [Unknown,Open]  http://bugs.debian.org/170825
<trappist> jcole: you copy the config to the root of the kernel source directory and say 'make menuconfig'... or make xconfig for a gui configurator
<pitti> Keybuk: ah, thanks
<Keybuk> hmm, Ubugtu bug there, it read the original package and subject rather than the current one
* doko starts hating powerpc
<wasabi__> Hmm. Nope. It just regenereated /etc/environment with en_GB
<jcole> rappist: ah
<jcole> ^^ trappist
<jcole> trappist: that will update the other configs as well?
<trappist> jcole: just realized what channel this was - /join #ubuntu please
<sabdfl> iwj: any idea on the firefox https issue i filed last night?
<sabdfl> it's blocking any serious work for me right now, w.r.t. bugs or specs or wiki
<pitti> sabdfl: ah, it's not working for you and you get an SSL error dialog? You need to upgrade libnspr4 and libnss3 to the latest edgy version (2.0beta)
<pitti> sabdfl: this will break evolution, but you can start it with 'LD_LIBRARY_PATH=/usr/lib/firefox evolution'
<thom> sabdfl: is your x60 running edgy? if so, does it reboot correctly?
<ogra> pitti, he's a thunderbirdie ;)
<pitti> ogra: well, I'm a muttie, but still use evo for calendar/contacts/tasks :)
<ogra> :)
* ogra is full evolutionist :)
<thom> pitti: muttie heh
<Surak> Is there a way to pass a parameter in isolinux to modprobe?
<tkup> is there some serious issues with ubuntu's LVM?
<tkup> I just can't create vg's at all
<sabdfl> thom: it did this morning, should i be nervous of a reboot?
<thom> hrm, interesting. previous edgy kernel hasn't rebooted once for me correctly
<thom> i've not tried the new one though
<sabdfl> what error do you see?
<thom> none; it gets to the end of shutdown but never actual powers off or reboots; just sits with a black screen but the status lights on, which smells to me like an acpi oddity
<sabdfl> pitti: i'm up to date edgy
<sabdfl> libnss3 is version 2:1.firefox1.99+2.0b1+dfsg-1ubuntu1
<sabdfl> https does not work with FF
<sabdfl> mjg59: what does usplash present a developer with, in terms of graphics API?
<sabdfl> if we wanted to hire someone to make nice bootsplash animations, what do we tell them they have handy?
<sabdfl> some sort of vesa lib?
* desrt can only assume sabdfl is behind these "I nvest alerts for ubuntu.com users!" emails
<sabdfl> ?
<sabdfl> spam
<desrt> stock spam :p
<ogra> you get invest alerts ? 
<desrt> like crazy
<desrt> they have a higher tendency to make it through the filters than penis spam
<ogra> i get "mailtransport failed" with nice zip or scr attachments from "postmasetr@ubuntu.com"
<ogra> lots of these
<desrt> i'm near the point of putting a block to incoming emails containing .doc/xls/ppt/exe/pif/scr/zip/...
<ogra> yeah
<desrt> i don't think anything useful has ever been emailed to me in this form
<tseng> someone send a dll to the mono list the other day
<tseng> and i had to fish it out of the spam box
<ogra> heh
<desrt> a .dll is an odd one
<desrt> most virii don't come like this
<tseng> i think it was in my procmail rule though
<desrt> i wouldn't have a procmail rule.  too high of a chance that someone might one day send me a .doc and expect that i got it
<Robot101> desrt: in postfix I have a rules file that bins stuff like that at SMTP time
<Robot101> desrt: meaning people get informative bounces
<desrt> i'd rather just reject the receipt
<desrt> yes.
<desrt> exactly like this.  give 'em a 550
<Robot101> ke
<Robot101>                   that at SMTP time
<Robot101> 18:48 < Robot101> desrt: meaning people get informative bounces
<Robot101> 18:48 < desrt> i'd rather just reject the receipt
<Robot101> 18:48 < desrt> yes.
<Robot101> GARHGAHR
<Robot101> http://www.securitysage.com/files/mime_header_checks
* desrt gives Robot101 some tums
<tseng> proof X clipboard blows
<tseng> and firefox makes it worse
<Robot101> why doesn't the terminal fill the primary selection when you right-click and go to copy the URL?
<Robot101> I never use the crapping menu for anything else, so I never go to right-click -> paste
<desrt> Robot101; i wrote my own rules for this
<tseng> because thats the "wrong" clipboard :/
<desrt> Robot101; for postfix... but i use sendmail and haven't been assed to switch yet
<mdz> slomo: any guess why libiec61883 isn't in Debian?
<Robot101> desrt: :-S
<desrt> my entire server infra is freebsd
<desrt> i'm switching it to ubuntu as soon as xen works properly
<Robot101> I just did an install today on etch, so if those patches etc make it into edgy it should be fine
<mjg59> sabdfl: The ability to draw boxes, lines and stuff
<tseng> desrt: did you manage to convince j5 to fix dbus?
<desrt> tseng; i've convinced him that it's a problem
<desrt> tseng; they're hashing it on on their list
<tseng> cool
<desrt> tseng; i imagine it'll be fixed by 1.0
<tseng> hot.
<tseng> I can't figure how to fix it in last-exit
<Keybuk> hmm... animated bootsplash
<Keybuk> you could take "MovieOS" too literally that way
<desrt> call gnome_vfs_init right inside of main
<Keybuk> "CANONICAL LTD"
<tseng> I did
<desrt> or dbus_g_thread_init
<Keybuk> "IN ASSOCIATION WITH THE UBUNTU COMMUNITY PRESENTS"
<tseng> and that too
<Keybuk> "A MATT ZIMMERMAN DISTRIBUTION"
<desrt> you have to call it _right away_
<Keybuk> "UBUNTU V - THE EDGY EFT"
<desrt> first line
<Keybuk> "STARRING FIREFOX 2.0"
<tseng> no shit?
<tseng> ok
<fabbione> "BASED ON A TRUE STORY OF FABBIONE FS'ES"
<LaserJock> Keybuk: haha, that's great
<HiddenWolf> Keybuk: awesome. :)
<Keybuk> when we get around to putting the alsa drivers into the initramfs, you could even have theme music
* Keybuk hunts out superman.mp3
<BenC> Keybuk: "eye of the tiger"
<zul> the theme from chariots of fire
<LaserJock> BenC: oh yeah
<ogra> BenC, ++
<LaserJock> zul: maybe a little boring
<Keybuk> just when you thought it was safe to boot your PC on April 1st ...
<desrt> BenC; at least 4 people now with that weird APIC bug... so i think we can rule out flaky hardware
<ompaul> scene one "sabdfl leaves the CC due to FF2 and https" 
<LaserJock> zul: that might fit for a 386 boot ;-)
<zul> LaserJock: heh...what do i know..:)
<tseng> desrt: farking hell, its fixed
<tseng> desrt: re, wrong bin
<desrt> tseng; told ya :)
<tseng> no, wrong binary
<tseng> I need to make it sooner
<desrt> i mean 'told you that the fix worked' :p
<tseng> writing it in liblastexit, binding to C#, calling *first thing in main*
<desrt> if -anything- in dbus is touched before you do the call then it's too late
<Riddell> ogra: do you have a bzr repository for hwdb-client?
<pygi> pitti, poke :)
<sabdfl> anybody else have a b0rked /etc/mailcap line 83?
<segfault> mine seems to be ok here, no fail when running update-mime
<BenC> sabdfl: audio/basic; /usr/lib/mime/playaudio '%s'; description=Basic uLaw Audio; nametemplate=%s.au
<BenC> that's what mine looks like
<BenC> probably different lines though :)
<segfault> mine is gnumeric.
<BenC> line numbers are probably pintless there
<BenC> pointless even
<tseng> desrt: not fixing it
<tseng> desrt: this might be a different bug
<sabdfl> BenC: application/x-sc is mine
<sabdfl> broken line
<tseng> desrt: unless iain has done something so evil as to call something before Main()
<segfault> sabdfl: true, mine is broken too @ line 103.
<icecrash> Kamion: short time for a question?
<tseng> how can i turn off this apport business?
<sbalneav> ogra: pingity
<mvo> anyone here who upgraded his apt already? to 0.6.45ubuntu3? can you /msg me the output of "apt-get install --install-recommends --fix-policy"?
<pitti> mvo: upgrading now
<mvo> pitti: thanks!
<pitti> mvo: ouch, dist-upgrade wants to remove gnome-app-install language-selector synaptic update-manager update-notifier
<mvo> pitti: then wait a bit - the stack is not yet rebuild for ppc
<pitti> mvo: I'm on amd64
<mvo> pitti: does dist-upgrade also wants to remove python-apt?
<geser> python-apt gets update here (amd64) together with apt and apt-utils
<seb128> ogra: around?
<pitti> mvo: no; however, p-apt is held back on a normal upgrade (which I'm doing ATM)
<ogra> seb128, only for some minutes, whats up ?
<seb128> ogra: 
<seb128> <lool> seb128: can we discuss gnome-screensaver a little?
<seb128>  seb128: is it on purpose that you do not build-depend on GL?
<ogra> err ...
<ogra> indeed its not if thats the case ...
<seb128> ogra: ok :)
<seb128> ogra: http://librarian.launchpad.net/3551080/buildlog_ubuntu-edgy-i386.gnome-screensaver_2.15.5-0ubuntu1_FULLYBUILT.txt.gz
<seb128> 	GL:                       no
<ogra> uild-Depends: cdbs, debhelper (>= 4.1.0), libdbus-glib-1-dev (>= 0.60), libxml2-dev (>= 2.6.0), libgconf2-dev (>= 2.6.1), libgtk2.0-dev (>= 2.7.0), libgnomevfs2-dev (>= 2.6.0), libgnomeui-dev (>= 2.6), libglade2-dev (>= 2.5.0), libpam0g-dev, libgnome-menu-dev (>= 2.11.1), libxau-dev, libxmu-dev, libxss-dev, libxxf86vm-dev, libxml-parser-perl, libexif-dev, libxxf86misc-dev, gnome-pkg-tools
<ogra> +Standards-Version: 3.7.2
<ogra> looks like a debian bug ... 
<ogra> thats the build-deps from the debian 2.14 package 
<ogra> i'll fix that asap
<ogra> (and file a debian bug ;) )
<ogra> bbl
<desrt> tseng; some weird constructors or something?
<pygi> pitti, when you'll have time for me? :)
<pitti> pygi: sorry, I didn't see your ping
<pitti> pygi: just ask :)
<pygi> pitti, our simple thingy about O_EXCL isn't that trivial as we thought :)
<pygi> pitti, btw. I'll need testers for libburn-on-cdrecord layer soon, so if you can find them for me ^_^
* pitti will be happy to try out stuff
<pitti> pygi: where's the problem?
<pygi> currently, I am thinking of following:
<pygi> - O_EXCL locking for systems where this is in use
<pygi> - no O_EXCL locking for systems where a O_EXCL rogue is
<pygi>   active (if such system can give up locking at all).
<pygi> - make libburn stop being an O_EXCL rogue in vanilla
<pygi>   operation.
<pygi> We have a problem deciding when the drive fds could be closed automatically.
<pygi> current idea is to close unused drives by a new
<pygi>   API-call issued by the application as soon as it
<pygi>   decides to give them all up but one.
<pygi>   Afterwards the application would not be allowed to
<pygi>   access other drives until libburn is shut down and
<pygi>   started again.
<pygi> o joy, sorry about this :)
<mdz> mvo: apt-get --fix-policy install does nothing for me here; is that expected?
<mdz> I expected to have at least one unsatisfied recommends, considering that I install most things with apt-get
<mdz> likewise with --fix-policy --install-recommends
<cbx33> bzr is broken in edgy :(
<cbx33> oh hang on
<cbx33> :S
<pygi> pitti, so thoughts? :)
* pitti catches up with backlog
<pitti> pygi: what is an 'O_EXCL rogue'?
<pitti> pygi: 'rogue' -> is that a process that uses O_EXCL to access a file?
<pygi> pitti, means it gives us troubles ^_^
<pygi> we've been testing with most kernels in existance lately :P
<pitti> pygi: hm, I never saw much trouble with O_EXCL in cdrecord; I'm afraid I don't understand the problem
<pygi> pitti, ah,oki ^_^
<pygi> but you'll be able to test the layer I was talking to you about once it's ready?
<pygi> it tricks app by making it think it uses cdrecord, but actually it uses libburn
<pitti> yes, I can burn a CD with it
<pygi> ok, thanks :)
<pygi> preparing something simmilar for mkisofs as well
<pygi> basicly, things look good on one side, and bad at other
<pygi> but hopefully we'll solve everything one day :)
<shackan> pygi, why is libburn better than cdrecord ?
<mdz> shackan: it's a library API rather than a command line program (and an unfortunate command line program at that)
<shackan> ah, fair enough :)
<pygi> shackan, in terms of features it's currently not better, and I am not sure will it ever be
<pygi> but we are making baby steps to the goal ^_^
<shackan> yes, you already told me :)
<pygi> pitti, at least any thoughts on: At what stage the stored drive fds could be closed automatically?
<pitti> pygi: in a library you cannot assume anything about the fd passing-around of the app
<pitti> pygi: I'd close them on an explicit close()/destructor/whatever function call
<pygi> so to close unused drives by a new  API-call issued by the application as soon as it  decides to give them all up but one. ideais any good?
<pygi> idea is*
<pygi> right ^_^
<pitti> pygi: why should the application keep unused FDs?
<cbx33> hi guys.  Why in edgy do I have to type the quotes button twice "
<cbx33> and when i do I don't get the right quotes mark?
<pygi> pitti, Afterwards the application would not be allowed to access other drives until libburn is shut down and started again.
<pitti> pygi: hm, this sounds as if your library looks for some ways to circumvent application bugs
<seb128> you speak about cd burning?
<pygi> seb128, indeed
<seb128> is that know that cdrecord doesn't work with user on edgy?
<pygi> pitti, :)
<pitti> seb128: hah, happens to me, too
<pitti> seb128: but apparently not to everyone
<pitti> seb128: it's on my list of things to fix
<seb128> pitti: we have some bugs about n-c-b and I've noticed cdrecord does the same
<pygi> pitti, the thing I just described seemed logical to me, but I am l looking for someone to tell me I am wrong :)
<pitti> seb128: some permission error in a sysctl?
<seb128> it's on my list of things to look to or find somebody knowing the code to look to :)
<seb128> pitti: "cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl"
<pitti> seb128: exactly
<seb128> "capset(0x19980330, 0, {CAP_SYS_RAWIO, 0, 0}) = -1 EPERM (Operation not permitted)
<seb128> write(2, "Error: Cannot gain SYS_RAWIO cap"..., 99Error: Cannot gain SYS_RAWIO capability.Is cdrecord installed SUID root?
<seb128> : Operation not permitted"
<pitti> seb128: so far I downgraded to the dapper version, but it gets time to fix it properly
<pitti> seb128: that's normal
<seb128> ok, I was not sure
<seb128> gettimeofday({1155586417, 764389}, NULL) = 0
<seb128> ioctl(3, SG_IO, 0xbf8ce52c)             = -1 EPERM (Operation not permitted)
<seb128> geteuid32()                             = 1000
<seb128> setresuid32(-1, 0, -1)                  = -1 EPERM (Operation not permitted)
<seb128> setresuid32(-1, 1000, -1)               = 0
<seb128> gettimeofday({1155586417, 764496}, NULL) = 0
<seb128> write(2, "cdrecord: Operation not permitte"..., 66cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl
<seb128> ) = 66
<pitti> the first one is the culprit apparently
<seb128> looks like
<seb128> iz linux bog?
<pitti> seb128: it's something introduced by the new cdrecord upstream version
<pitti> seb128: it wasn't done in the dapper version
<seb128> pitti: ah ok, and Debian is not having the issue? or they are going to kick cdrecord out anyway and don't care?
<pitti> seb128: I reported it to Debian ages ago (when I did the dapper merge for cdrecord), but it just got lost
<pitti> seb128: or, rather, they ignored it as 'worksforme'
<pitti> and indeed it works for some people
<pitti> seb128: just not for us poor lads :/
<seb128> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374685
<Ubugtu> Debian bug 374685 in nautilus-cd-burner "nautilus-cd-burner: fails to call cdrecord properly" [Grave,Open]  
<pitti> seb128: arrgh @ Joerg Schilling
<seb128> pitti: bug sort of turned to a "nice discussion" with upstream
<Lure> pitti: is this due to http://lwn.net/Articles/193516/
<seb128> right :/
<pitti> Lure: I doubt it, but possible
<pitti> Lure: it works with dapper cdrecord, breaks with edgy cdrecord, both with the very same kernel
<seb128> pitti: the debian bug has a "patch" (understand: comment some code)
<Lure> pitti: it seems that latest cdrecord uses more SCSI commands than before due to DVD add-ons - would need to dump SCSI CDB to see
<pitti> hi zyga
<pitti> seb128: yup, I saw that
<Lure> and since kernel filters it (even though I though that kernel just "eats" unsupported commands) it fails
<pitti> seb128: I'll look into it, but most probably I'll just comment out the added bits from the a03 version
<pitti> (those who cause trouble, anyway)
<seb128> pitti: ok, thank you
<pygi> pitti, anyway I won't bother you much anymore...we have a cdrtools maintainer at debian interested ^_^
<pitti> pygi: cool :)
<pitti> pygi: still, I'm happy to test
<pygi> pitti, ofcourse ^_^
<pitti> pygi: as I said, I do not understand why libburn needs to grab all devices and then release some of them again
<pygi> pitti, The official method to address a drive with libburn is to call burn_drive_scan() with the consequence that function open() is applied to any device file that could lead to a burner. open() stalls with devices which are ill or busy even if they are no burners or not intended for use with libburn.
<pitti> pygi: ouch
<pitti> pygi: in a scanning function you should use O_NONBLOCK and never O_EXCL
<pygi> pitti, I've got in a patch just today: 
<pitti> pygi: and immediately close the fd again
<pygi> - Persistent address is the device file address as found in
<pygi>     struct burn_drive_info.location .
<pygi> - The desired drive address is put into a whitelist.
<pygi>     The (currently two) drive enumeration functions of libburn query the whitelist before applying open() to a device. If the whitelist is not empty and if the candidate device is not listed, then open() is skipped and the device gets handled as if it did not offer read-permission. If the whitelist is empty, then all enumerated drives get opened. Thus traditional operation of libburn is not affected as long as the whitelist API function
<pygi> s are not used by the application.
<pitti> pygi: and then, once you figured out the device, you open it with O_EXCL|O_NONBLOCK and a timeout
<zyga> pitti: hello :)
<pygi> pitti, read my paste, this is the patch I commited today is all about
* zyga is married now :)
<pitti> yup, that makes sense
* zyga will have a son soon :)
<pitti> zyga: congratulations to you and your wife!
* zyga will (suprisignly) have time for ubuntu again :))
* pitti hugs and celebrates zyga
<zyga> thanks :))
<pygi> pitti, really? wow :)
<pygi> congrats zyga :)
<zyga> I need to get up to speed with edgy, fast
<pitti> pygi: but your quote was pretty orthogonal to opening modes :)
<pygi> libburn 0.2.1 : zyga's edition, lol:)
<pitti> zyga: dist-upgrade! now! break cd burning, firefox, evolution, and get crash reports slammed around your ears! :)
* pygi tries to decyher what would pitti mean with that :P
<zyga> pygi: ? :)
<zyga> pitti: pulling edgy-current now
<pygi> zyga, nothing, nothing, ignore me pls :)
<zyga> I don't want to break dapper, it's too lovely :)
<pitti> pygi: that edgy is, well, not as stable yet as we'd like it to be? :)
<pygi> pitti, I meant on: "but your quote was pretty orthogonal to opening modes :)" :)
* pitti yays at his first constraint solver in python that will help him with apport
<pygi> zyga, thinking of codename for libburn 0.2.1, hehe :)
<pitti> pygi: ah, well, I mean what I said; the whitelist strategy has little to do with open(2) modes
<pygi> pitti, right, open will be addressed by another commit/patch :)
<pitti> pygi: AFAICS, if the scan function uses O_RDONLY|O_NONBLOCK, it will only stumble over O_EXCL-opened devices (i. e. a currently progressing burning)
<pitti> pygi: and if the actual burning uses O_RDWR|O_EXCL|O_NONBLOCK, that should work fine everywhere and be on the safe side
<pitti> pygi: so, was your question about the first issue? ('will only stumble over...')
* pygi looks what the scan function uses now
<zyga> hey seb128 
<seb128> hi zyga
<seb128> zyga: what's up?
<cbx33> hehe something has gone wrong somewhere  hehehehe my karma:519846
<bddebian> Holy crap and I thought mine was high
<zyga> seb128: got married, moved, got promoted, have own place to live :)
<seb128> a lot :)
<zyga> seb128: and I'm back to ubuntu with my free time :)
<pitti> cbx33: heh, indeed, I have 1.83M now
<seb128> congrats for all that ;)
<bddebian> cbx33: Oh, I guess it has:  745229
<bddebian> pitti: Nicde
<bddebian> -d
<pygi> pitti, thanks for the help, I'll look into it more later tonight
<seb128> zyga: ah, nice, Ubuntu work is always welcome :p
<cbx33> i notice the top contributor has over 5million
<pitti> seb128: your karma must be negative by now
<pitti> due to int overflow
<bddebian> doh
<cbx33> seb128, congrats on the marriage :p
<seb128> pitti: heh, it was, I'm wondering how many times I did the whole range by now :p
<seb128> cbx33: that's not me :/
<zyga> cbx33: that's me
<cbx33> oh sorry
<cbx33> hehe
<cbx33> of course
<cbx33> I've been stuck in python code all evening...my brain musn't be working
<cbx33> congrats zyga 
* pitti hugs cbx33 to share the python coding brainwash :)
* cbx33 feels all pythony inside
* pygi feels all the joys of hardware programming and kernel mess ^_^
<cbx33> oooh pygi 
<cbx33> getting ya hands and feet dirty
<pitti> sounds like we all have lots of fun. great! :)
<cbx33> hehe indeed
<pygi> pitti, I looked at the mkisofs code...that thing is such a mess that I'd never look at it again :P
* pitti  python
<pitti> pygi: don't :)
<cbx33> pygi, you know your cd burner
<pygi> cbx33, ahm? :)
<cbx33> if you'd like an optional package remember gisomount
<pygi> cbx33, what should I do with gismount? (sorry, a bit exhausted with this libburn mess today :P)
<cbx33> i dunno
<pygi> why you mentioned it then ? :)
<cbx33> if they are just creating an iso with it, 
<cbx33> then they could use gisomount to mount that iso and browse it, or create md5sum
<cbx33> just mentioning it....soz pygi 
<pygi> does it burn cds? can it create ISO files?
<cbx33> remember my brain is fried too
<pygi> no worries :)
* cbx33 scurries away back to python
<cbx33> ahhhh o
<cbx33> home
<pygi> cbx33, but no really...can it burn cd's or create ISO files?
<cbx33> no gisomount can just mount the iso
<pygi> hm,oki ^_^
<pygi> cbx33, we should have "Burn-ISO-in-one-button" feature :)
<cbx33> well you can burn an iso from gisomount
<pygi> cbx33, using what?
<cbx33> but then you could just right click it and select burn
<cbx33> gnome cd record
<pygi> ah :P
<cbx33> but i could be persuaded to make a modification
<cbx33> :p
<pygi> cbx33, you'll test the libburn-over-cdrecord one day ^_^
<cbx33> heheh
<pygi> cbx33, just you laugh :)
<lemsx1> hello all
<lemsx1> i updated one of my dev boxes to Edgy (from Dapper)
<lemsx1> and i have a few (non-support-related) questions
<lemsx1> it seems that the new kernel (2.6.17-6-686 in my case) uses ide-scsi to mount drives
<lemsx1> that works fine for ext3 and swap filesystems, but for XFS it failed
<lemsx1> going back to the "stable" (dapper) kernel worked
<lemsx1> did i just hit a (known) bug?
<pitti> lemsx1: hm, my xfs partition was automatically transitioned and is mounted correctly
<pitti> lemsx1: does the /etc/fstab entry look reasonable?
<lemsx1> pitti: you have / as ext3 (or whatever) and some other partition as XFS ?
<lemsx1> pitti: yep. the only new thing in /etc/fstab is UUID:.... for /home (my xfs partition)
<pitti> lemsx1: yes, / on reiserfs, and my only xfs partition is a non-critical one (/mm)
<lemsx1> pitti: the error i was getting was some I/O buffer 
<lemsx1> pitti: perhaps is still in some log... let me see
<Seveas> lemsx1, sounds like a bug to me
<pitti> lemsx1: please file a bug with details (/etc/fstab, log files, dmesg, sudo fdisk -l)
<lemsx1> ok. i have XFS partitions on different disks at home, and i also updated that system to edgy. that one rebooted fine. i have to make sure that my partitions were mounted (all LVM stuff)
<lemsx1> pitti: ok. let's see if i can get the old dmesg
<lemsx1> [17179588.556000]  I/O error in filesystem ("sda3") meta-data dev sda3 block 0x218d6ff       ("xfs_read_buf") error 5 buf count 512
<lemsx1> fdisk -l will show as "hda" now. before it was showing under /dev/sda
<pitti> lemsx1: hm, you mean the other way round?
<pitti> AFAIK it was supposed to be hdX -> sdX (ide-scsi)
<lemsx1> pitti: i'm using the old dapper kernel now
<pitti> ah
<lemsx1> pitti: how can i turn off ide-scsi?
* pitti looks at Keybuk 
<Keybuk> hmm?
<gnomefreak> just a notice the latest apt and ff updates broke alot of things :(
<pitti> Keybuk: see above, there seems to be a bug in the ide-scsi transition
<pitti> Keybuk: for lemsx1 
<Keybuk> a bug?
<pitti> gnomefreak: known
<gnomefreak> ok
<Keybuk> that doesn't look like a bug to me
<lemsx1> Keybuk: indeed. give me details on how to get debug information for you... i'll open a bug shortly
<Keybuk> looks like a duffed filesystem
<Keybuk> lemsx1: I'd file the bug with the kernel directly
<Keybuk> it's not a transition problem, afaik
<lemsx1> Keybuk: ... it works with the old kernel (??)
<Keybuk> right, iz kernel bug
<Keybuk> btw, we're not using ide-scsi
<lemsx1> Keybuk: yeah, kernel. not the ide-scsi stuff. that worked
<lemsx1> Keybuk: what's used then?
<Keybuk> the kernel in general is dropping the IDE subsystem
<lemsx1> Keybuk: i saw sg and other scsi drivers were loaded
<Keybuk> and we're using new drivers that expose old "Parallel ATA" disks through the SCSI subsystem
<Keybuk> just like "Serial ATA" disks are already
<lemsx1> Keybuk: ah, ok. you mean the vanilla kernel,not just ubuntu. right?
<Keybuk> right
<zyga> oh!
<Keybuk> we're just testing it :)
<zyga> so no more hda? :)
<lemsx1> Keybuk: i see
<Keybuk> zyga: keep up ;)
<Keybuk> lemsx1: the upgrade should have rewritten your /etc/fstab to have UUID=... instead of the old /dev/hda names
<lemsx1> Keybuk: yep. that worked like a charm
<zyga> wow :)
<Keybuk> so the problem for you isn't that the filesystem isn't mounted
* zyga can't wait till edgy pulls :)
<Keybuk> the problem is that the filesystem isn't working through the newer driver
<lemsx1> Keybuk: thanks goodness that also works with the old kernel ;-) if not i'd need a live disk to fix it
<Keybuk> lemsx1: UUID= works in dapper <g>  we somewhat deliberately did that a release in advance knowing this was happening
<lemsx1> Keybuk: you hit the problem right in the head
<lemsx1> Keybuk: and i dunno if its' because it's XFS or what
<Keybuk> this could be a filesystem problem (ie. on disk, it's bad), it could be a filesystem driver problem (XFS bug) or it could be a driver problem
<lemsx1> Keybuk: the other partitions in the same drive worked fine ( / and swap )
<lemsx1> Keybuk: if it was a hardware problem, i'd get the same problem with the old kernel (from dapper)
<lemsx1> Keybuk: and that's what i'm using now. it works
<lemsx1> Keybuk: that leaves XFS driver and whatever other driver that does the SCSI translation
<Keybuk> *nods* I'd tend to agree
<Keybuk> make sure you attach lsmod output
<lemsx1> Keybuk: cool thing you did in dapper... sounds like Apple: shipping features turned off in new versions... way to go
<lemsx1> Keybuk: why UUID and not LABEL like redhat?
<Keybuk> UUID is supposed to be universally unique
<Keybuk> so in theory, two devices can never have the same one
<Keybuk> where two disks can quite easily be called "HOME"
<lemsx1> Keybuk: ok. i'll have to do some reading about UUID... i remember seeing the code in dapper's initramfs before (i'm the main devel of Splashy. i deal a lot with funky initramfs problems)
<Keybuk> part of the reason for the transition is that you'll now be able to use removable USB disks as part of your filesystem
<Keybuk> and it won't matter what order you plug them in
<pitti> lemsx1, Keybuk: in practice, too; the breezy installer labelled partitions after their mountpoint, with the result that I had three partitions with the label '/' after some time :)
<crimsun> lemsx1: do you use quotas?
<lemsx1> crimsun: no. no quotas
<lemsx1> and no lvm here either (i have lvm at home... i'll check in a few hours)
<sabdfl> infinity: ping
<mdz> seb128: thanks for fixing totem-mozilla
<Keybuk> sabdfl: slightly early for infinity yet, not even 0800 there
<seb128> mdz: np ;)
<mdz> Keybuk: one never knows with him
<tseng> desrt: I have no idea :/
<tseng> desrt: but i have a different traceback now than muine I think
<ajmitch> mdz: does f-spot fall under the desktop UVF exception, or shall I get one from you?
<tseng> desrt: if you're curious enough to see it I could reproduce, forgot to check in my bzr branch at work
<mdz> ajmitch: is it part of GNOME releases?
<mdz> there is no desktop UVF exception
<tseng> desrt: if you're not I am going to leave it to baris, who seems to be the guy who broke it.
<ajmitch> mdz: no, tomboy was added, f-spot not
<mdz> ajmitch: then it needs an exception, yes
<pitti> good night
<tseng> cya pitti 
<ajmitch> mdz: thanks, I'll ask when the release comes up soon
<Lure> latest apt-get update wants to remove adept* and kubuntu-desktop on Kubuntu Edgy: http://paste.ubuntu-nl.org/20593
<Lure> is this just temporary or should I file a bug?
<mdz> Lure: adept probably needs to be updated for the new apt
<mdz> I don't know whether someone is working on it already
<trappist> Lure: removing kubuntu-desktop won't have any effect
<sabdfl> mdz: any progress on ff2 https for those of us b0rked?
<sabdfl> bit of a deal-breaker, that one
<cbx33> indeed
<cbx33> I was trying to get a branch address from LP ealier and forgot :p
<mdz> sabdfl: I have no idea; I've never seen the problem
<tseng> sabdfl: have you really upgraded to ff2?
<mdz> tseng: it's in edgy
<tseng> the only time i saw ssl broken here was when firefox was held back
<tseng> and i had new nss with old firefox
<cbx33> yup busted in edgy
<tseng> or something like this.
<mdz> sabdfl: have you tried with a fresh profile?
<tseng> if i force ff2 it works for me
<mdz> cbx33: not exactly
<Keybuk> mdz: there's definitely a bigger problem
<Keybuk> if you either
<cbx33> mdz, ok, not working at 100%
<Keybuk> a) upgrade firefox and don't upgrade libnss/libnspr
<mdz> cbx33: not working for 100% of users
<Keybuk> b) upgrade firefox and upgrade libnss/libnspr
<cbx33> mdz, then we are agreed ;)
<Keybuk> c) upgrade libnss/libnspr and don't upgrade firefox
<Keybuk> then you're left with a broken machine
<Keybuk> a) causes firefox to break
* cbx33 did a dist-upgrade
<Keybuk> b) causes evolution to break
<Keybuk> c) causes firefox to break
<mdz> the evolution problem is fixed
<mdz> with the latest firefox build
<Keybuk> does the latest firefox build not cause the removal of ubuntu-desktop ?
<mdz> b) is the correct thing to do, a) and c) are silly (but should be enforced by dependencies)
<Keybuk> b) can only be done by removing locales, etc.
<mdz> I have no idea what you mean
<mdz> oh, you mean language-support
<Keybuk> yeah
<tseng> forcing firefox removes locale data
<mdz> yes, the locales have not yet been updated
<Keybuk> and the firefox theme too, iirc
<Keybuk> which is a dep of ubuntu-desktop
<mdz> the firefox theme doesn't work with new firefox yet
<mdz> no it isn't
<mdz> it's a dep of firefox
<mdz> (and not anymore)
<Keybuk> ah, maybe I misread that in aptitude's complaining then
<zul> hey
<mdz> sabdfl: is that what you did?  held back some packages to avoid removing language-support-en?
<mdz> if so, push ahead and you'll be fine
<Keybuk> how is losing language support "be fine" ?
<tseng> because sabdfl speaks native C
<sabdfl> interesting, fixed now, it was jammed on my version of the firefox ubuntu theme
<Keybuk> zsh: segmentation fault (core dumped)  dd if=/dev/zero of=/dev/null count=1000
<Keybuk> (in other news, really must track down who caused that and beat them to death)
<sabdfl> Keybuk: with a damp sponge, so it's really humiliating as well as, err, terminal?
<Keybuk> yeah, penalty for breaking dapper
<cbx33> For those who were in the CC meeting earlier requesting oggs of the new development ubuntu sounds http://www.progbox.co.uk/finals/
<cbx33> please note they are not finished, am looking for feedback on them
<mdz> Keybuk: "temporarily removing language-support-en" != "losing language support" by any stretch of the imagination
<mdz> cbx33: perhaps you have the same problem as sabdfl then
<cbx33> possibly, I can check tomorow, don;t have my vmware machine with me now
<Keybuk> mdz: *shrug*  I find it easier to just ignore the problem for a while ... it's only my laptop after all
<mdz> Keybuk: please file a bug about the lack of stricter dependencies regarding libnss
<Keybuk> mdz: I would, except Launchpad requires SSL <g>
<Keybuk> arguably the bug should be that libnss needs a SONAME change
<mdz> Keybuk: if it's against your religion to temporarily uninstall a package, then use a live CD
<mdz> or a different browser
<mdz> or a chroot
<mdz> you are resourceful
* Keybuk adds the <joke> tags around that
<lemsx1> Bug #56384
<Ubugtu> Malone bug 56384 in linux-source-2.6.17 "Can't mount XFS drive after upgrading to Edgy (from dapper)" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56384
<mdz> lemsx1: #ubuntu-bugs is the place where all new bugs filed in Ubuntu are announced
<lemsx1> mdz: ok. good to know
<pygi> Keybuk, I've been playing with sending movie over Dbus lately :)
#ubuntu-devel 2006-08-15
<jono> hey
<Keybuk> pygi: you sick man ;)
<pygi> Keybuk, ;)
<LaserJock> does update-manage hand dapper->edgy upgrades well?
<LaserJock> *handle
<LaserJock> I guess that might be a little more of an #ubuntu+1 question
<pygi> LaserJock, it does
<mdz> LaserJock: it has a preliminary upgrade mode for edgy which you should test, yes
<LaserJock> hmm, no man page for update-manager in Dapper, interesting
<LaserJock> I'm guessing update-manager -c -d will do the trick
<LaserJock> hmm, well it could use some more informative error messages :-)
<seb128> is there some other tool than gdb to get a backtrace? :)
<wasabi__> Hmm. What's the usual procedure for forcing a package to rebuild? Just a new upload?
<wasabi__> With no changes and a comment.
<Keybuk> yup, use VERSIONbuild1
<wasabi__> k
<wasabi__> ubuntu1build1?
<Keybuk> usually mention why you're forcing a rebuild
<Keybuk> for that, just do ubuntu2
<wasabi__> thought so
<wasabi__> thanks. just making sure.
<Keybuk> you only need to force a rebuild that way if it built already
<Keybuk> ie. soname change of underlying library
<mdz> seb128: catchsegv
<Keybuk> if the build failed, it doesn't need forcing
<wasabi__> Versioned dependencies moved away.
<wasabi__> So now it's uninstallable, etc.
* ..[topic/#ubuntu-devel:mdz] : 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 | 6.06.1 released
<seb128> mdz: thank you, that one doesn't crash but gets not bt neither :p
<wasabi> Oooh. Automatic crash reporting. I like.
<wasabi> Bit rough. Great addition.
<wasabi> Should attach a core file automatically. :)
<desrt> edgy's bugbuddy you mean?
<wasabi> Yeah.
<desrt> it uses the new HTTP technology
<desrt> very 90s :)
<wasabi> Heh.
<wasabi> It's just nice to have it.
<desrt> (thank god somebody finally implemented that) :)
<wasabi> Wonder if the plan is for it to do the reporting itself... including attaching this file.
<wasabi> Probably. ;0
<desrt> well
<desrt> you sort of have to ask the user "what were you just doing?"
<desrt> and sending in core files is extremely dangerous and sometimes unrealistic
<wasabi> Yeah. Simple questions, sure. But right now it makes you open launch pad, click new bug, submit, add attachment, paste /var/crash/_somefile.crash into the attachments. ;)
<wasabi> Yeah.
<wasabi> MS basically submits tailored core files.
<wasabi> Stack only or some such.
<seb128> desrt: I'm not sure you guys speak about the same thing, wasabi is speaking about apport
<wasabi> apport the new thing that just popped into edgy?
<wasabi> yup
<desrt> ya.  i don't know what that is :)
<seb128> apport is what you get notifying you that something crashed to edgy
<wasabi> replacing bug buddy, or in addition to?
<desrt> oh.  that's what i'm talking about
<seb128> desrt: sort of bug-buddy but not GNOME specific
<desrt> the new bugbuddy thing
<seb128> desrt: new bug-buddy is bug-buddy with xml-rpc for me ;)
<desrt> does it file to launchpad or bugzilla?
<seb128> desrt: bug-buddy? bugzilla! apport? it opens a browser on launchpad atm but save the informations to /var/crash too
<wasabi> bah. gnome settings daemon can't update xkb config
<seb128> desrt: the plan is to bug launchpad by xmlrpc and get automatic debug backtrace ... but that part is not done yet ;)
<wasabi> seb128: how are you planning on getting the bt? -dbg packages, or uploading a core file or something?
<seb128> for now it has the "detect crashes, a basic UI and bug dumps to /var/crash"
<seb128> wasabi: read the "Introducing automatic crash reporting in Edgy" mail from Martin on the -announce list
<seb128> it has all the details about that :)
<wasabi> k
<seb128> wasabi: basically a compressed coredump sent to a box which will get the bt
<wasabi> Ahh. Cool. That's what I was thinking.
<wasabi> A launchpad service that added that info to the bug reports just running, etc.
<poningru> wasabi: it was also in the dev mailing list
<wasabi> neato. fun to see it all coming togheter
<gnomefreak> mdz: i confirmed the bug and pitti had told me it was known so i didnt bother filing one but thank you
<gnomefreak> -but
<mdz> gnomefreak: what bug?
<gnomefreak> the ff bug
<mdz> which firefox bug?
<gnomefreak> the one you filed that apt breaks ff
<gnomefreak> bug 56394
<Ubugtu> Malone bug 56394 in firefox "Premature use of Breaks causes apt failure" [High,Confirmed]  https://launchpad.net/bugs/56394
<bluefoxicy> s/*/& we don't want that/
* bluefoxicy just upgraded firefox and it said "installing firefox would break firefox-ubuntu-themes, and"
<sabdfl> rhythmbox is looking *shiny*
<sabdfl> yum
<sabdfl> pretty is a feature!
<mjg59> Lalala.
* mjg59 rapidly implements the rest of his SoC project
* desrt colours mjg59 blue
<sabdfl> Doremi, would be more appropriate, gene-boy
<mjg59> desrt: Pf. I've got something with ticky boxes and if you tick them gnome-obex-server starts and stops
<mjg59> It does some other useful stuff too
<sabdfl> mjg59: did you see my questions about the new usplash magic?
<sabdfl> i have a cunning plan
<mjg59> sabdfl: Yeah
<mjg59> sabdfl: You can draw boxes in different colours
<desrt> mjg59; this sounds less impressive than i'd have imagined
<mjg59> desrt: Haha
<desrt> mjg59; i guess it's a last-minute job now?
<mjg59> desrt: Nah
<mjg59> It's all good
<sabdfl> mjg59: more than 16 colours? can you know the resolution and colour depth?
<mjg59> sabdfl: Basically, you can dump a pixmap onto the screen and draw boxes. You can move sections of screen around, too.
<mjg59> sabdfl: More than 16 colours is trivial, but not yet implemented. Yes, you can query the resolution.
<desrt> vuntz vuntz vuntz
<mjg59> desrt: As far as UI goes, you've got bluetooth enable/disable, discoverability, whether or not you're accepting obex file transfers, where they get saved to, that sort of thing
<bddebian> Howdy folks
<mjg59> desrt: Currently implemented as a hal addon, a simple GTK frontend and a session daemon 
<desrt> oh god.  a new session daemon.
<desrt> mjg59; do you also have that neat stuff where you can see bluetooth devices and their services in hal?
<mjg59> desrt: Yes
<desrt> do you have a hal method for hid attach?
<mjg59> Yes
<desrt> rock.
<desrt> that alone is awesome enough
<mjg59> And rfcomm binding
<mjg59> As I said, it needs UI
<mjg59> But that's easy enough
<desrt> some sort of client-side API for that might be nice
<mjg59> More of a client-side API than HAL?
<desrt> like int open_rfcomm_by_hal_uid (const char *);
<desrt> which gives an fd
<desrt> and handles all the binding and whatnot in the background
<mjg59> Hm.
<mjg59> Interesting idea.
<desrt> that's really what people want
<mjg59> Right now it binds, then once the binding is completed adds a device node name to the HAL properties
<desrt> so you're already most of the way there
<mjg59> Yeah
<mjg59> Should probably go in libbtctl
<desrt> to quote jeff: DOIT
<mjg59> And libbtctl should be ported to hal stuff
<mjg59> Without breaking API
<desrt> thank god my project doesn't care about API break
<mjg59> But I couldn't really be bothered redoing the libbtctl stuff when it wouldn't provide any user-visible difference
<jdub> desrt: starsky and hutch
<mjg59> So.
<mjg59> How should I provide the list of devices?
<mjg59> In the pointy clicky UI
<jdub> mjg59: A PIE MENU
<mjg59> Anyone other than Jeff?
<lifeless> mjg59: you should provide it in a clear manner
<desrt> jdub; thx.
<mjg59> lifeless: And it should also be functional
<lifeless> mjg59: you should provide it in a clear and functional manner
<lifeless> ^better ?
<mjg59> To be honest, I'm tempted to just provide one icon per device and a clicky "use" button
<mjg59> Since the number of bluetooth devices which have more than one useful function is small
<mjg59> And we probably wouldn't support them anyway
<desrt> like every cellphone ever?
<mjg59> desrt: Other than "Make this appear for DUN", what have you got?
<desrt> address book sync, modem, voice, ...
<mjg59> Address book sync should be application specific
<desrt> it's still an sdp-reported thingy
<mjg59> And on some devices, it's done over the serial connection anyway
<mjg59> Screaming nightmare
* ajmitch wonders what his phone supports
<mjg59> I have no idea what my phone supports
* mjg59 checks
<TheMuso> Believe it or not, there are actually BlueTooth braille displays.
<LaserJock> nifty
* desrt <rage/>
<jdub> TheMuso: hardcore
<TheMuso> jdub: Makes sense.
<jdub> TheMuso: guess it means dodging the whole "find the socket" thing, hey?
* mjg59 wonders what the Bluetooth Imaging profile actually is
<TheMuso> jdub: Yeah, and having to have the display close to the computer.
<shackan> mjg59, for printers ?
<TheMuso> Or not having to, in the case of bluetooth.
* ajmitch has nightmare flashbacks of doing bluetooth stuff with j2me
<mjg59> Ah, printers are one case
<mjg59> Another appears to be automatically downloading pictures when nearby
* desrt has random desire to kill the macbook
<sabdfl> desrt: are you seeing someone for those inanimate object issues?
<desrt> sabdfl; my apple certified repair technician
<shackan> mjg59, patched gnome bluetooth or did from scratch?
<sabdfl> jdub! how's life D-U?
<mjg59> shackan: No patches to gnome bluetooth yet
<shackan> ack
<mjg59> Mostly because that would involve Python
<desrt> sabdfl; unfortunately i need my laptop for the time being so i have to put up with the issues until i feel like saying goodbye to it for a few weeks
<mjg59> And Python scares me
<shackan> mjg59, wasn't g-b written in c ?
<mjg59> It's a mixture
<slomo> mdz: libiec61883 is not in debian yet because it was blocked by libraw1394... a newer version was needed but the old maintainer orphaned it and nobody took it until a month ago
<shackan> scary..
<mdz> slomo: we already have the newer version in edgy?
<slomo> mdz: both libiec61883 and new libraw1394 should get into debian soon
<slomo> mdz: yes, i updated it shortly after edgy opened
<mdz> slomo: ok
<bddebian> slomo: Define soon ;-)
<mjg59> If I've uploaded something to universe and it's hit NEW, do I actually need to do anything?
<slomo> bddebian: "soon" :) it blocks gst-plugins-good in debian and packages seem to be ready already, only waiting for a sponsor
<mjg59> I've spent long enough with the flies that I'm forgetting this stuff
<bddebian> slomo: Ah, cool, then I can play with mythtv :-)
<slomo> bddebian: we will have it sooner ;)
<LaserJock> mjg59: last I saw NEW had a large backlog
<bddebian> Aye :-(
<mjg59> Fair enough
<mjg59> I'll hack in usplash integration at some stage
<mjg59> Bling-tastic hibernate
<LaserJock> I think there's packages a month old in NEW
<LaserJock> so it could take a while
<bluefoxicy> <sabdfl> rhythmbox is looking *shiny*
<sabdfl> who processes NEW for universe?
<LaserJock> same as Main
<bddebian> sabdfl: Same folks as for main
<LaserJock> ubuntu-archive I imagine
<LaserJock> mostly Kamion?
<bddebian> and Keybuk
<bddebian> But iirc Keybuk said something about not being as involved in the licensing stuff?
<slomo> mdz: i've already written a MIR for it btw... shall i still disable the b-d for now or let it go on dep-wait and simply hope that the MIR will be approved soon? :)
<bluefoxicy> I don't see shininess... however I do "wtf python console" (rhythmbox AND gedit have python console plug-ins), which is leading me to "are we feature-bloating yet?"
<Keybuk> bddebian: hmm, no?
<Keybuk> I'm just as involved
<bddebian> Oh, sorry
<Keybuk> sabdfl: what's stuck?
* bddebian goes back in hiding
<slomo> Keybuk: when you process gnome-sharp2 from NEW please move it to main... it doesn't need a MIR as it's only code we have in main already. it was splitted off the gtk-sharp2 source package
<mdz> slomo: best to wait to upload with the build-dep until the report is approved, in case there are isuses
<mdz> issues
<mdz> once it's approved, fire away
<Keybuk> mdz: would "archive-fest" be a good use of the sprint, or not?
<Keybuk> ie. cleaning out source NEW, cruft, NBS, anastacia, etc.
<slomo> mdz: ok :)
<mjg59> sabdfl: If you want hibernate to have usplash bling, then NEW time would be a worthwhile investment
<mdz> slomo: libiec61883 accepted
<slomo> mdz: thanks :)
<mdz> Keybuk: if it'd be more efficiently done as a group, yes
<mdz> if it's individual round tuits, probably not
<Keybuk> it's round tuits of the right shape
<bddebian> w00t, thx mdz
<Keybuk> mjg59: what did you upload?
<mjg59> Keybuk: uswsusp
<Keybuk> was this the original upstream tarball?
<mjg59> No
<mjg59> It's somewhat hacked
<Keybuk> hmm
<Keybuk> shouldn't have CVS/* in it then
<Seveas> mjg59, would getting more than 16 color support mean merly poking at pngtobogl or is the pallette size currently really limited to 16 colors in libbogl itself?
<Keybuk> debian/copyright has problems (claims GPL v2 or above, source claims v2 only; missing copyright attributions)
<mjg59> Keybuk: Oh, tch.
<mjg59> Seveas: pngtobogl and a little work on libbogl
* Seveas just found his timewaster project for tomorrow
<Keybuk> mjg59: nothing blocking, but could you fix those in the next upload
<Seveas> thanks!
<Keybuk> accepted
<mjg59> Keybuk: Sure
<mjg59> Seveas: Ideally, drop the RLE stuff from pngtobogl entirely
<mjg59> Since we gzip it, it's entirely pointless
<mjg59> And it's just pain
<Seveas> so just a big array of palette indexes...
<Keybuk> slomo: accepted
<Seveas> (is svga still a palette or can it simply use rgblike values?)
<Keybuk> bddebian: around?
<bddebian> Yo
<Keybuk> bddebian: squashfs ... your upload seems to have made the package suddenly build lots of squashfs-modules-* packages
<bddebian> What'd I do now?
<mjg59> Seveas: Right now it's a 16 colour palette
<mjg59> Seveas: That's trivially changed. Basically, it just needs the mode numbers changing
<Seveas> mjg59, ok, thanks -- bedtime now but I'll poke at it tomorrow
<mjg59> Seveas: No problem
<bddebian> Keybuk: There are a bunch of module binary packages in debian/control
<lifeless> Keybuk: I uploaded a package yesterday, it seems to have gone awol
<lifeless> Keybuk: any chance you can have a poke for me ?
<lifeless> oh, nm, I was evidently smoking crack
* lifeless uploads the right changes file
<Keybuk> bddebian: right, but we ship those in our kernel packages
<Keybuk> it could be a side-effect of merging from Debian
<bddebian> Shit, I knew something would end up being incorrect
<lifeless> infinity: whats should I file probably-kernel- bugs/wishlists on ?
<Keybuk> they're all empty too :D
* bddebian turns in his badge
<Keybuk> heh, I wouldn't worry
<Keybuk> this package is a mess
<Keybuk> (from Debian)
<mdz> lifeless: depends on which kernel you're running
<mdz> lifeless: for dapper, linux-source-2.6.15 (though expect to be asked to test on a newer kernel for hardware-specific issues)
<mjg59> So, firefox
<mjg59> When did it stop accepting about:jwz ?
<desrt> xrandr really is an odd thing
<desrt> this is freakin' awesome for coding
<Burgwork> whip|lwe, ping
<lifeless> mdz: i'm running dapper
<lifeless> thanks
<lifeless> the issues are not driver related - its oprofile
<mdz> mjg59: maybe around the time that the (netscape.com) URL it redirected to went away
<desrt> does anyone know of a way to do a split in vim and tie the two buffers together so that the one is always immediately below the other in the same file?
<mdz> mjg59: so do i understand correctly that I can just go ahead and have powernowd try ondemand first, and if that succeeds, quit and don't run the daemon?
<infinity> sabdfl: Pong.
<mdz> he's left for the night
<infinity> lifeless: Kernel wishlists for spiffy new features should generally be filed against the devel release (ie" linux-source-2.6.17), unless you really think it's something we can stuff into a stable update safely.
<lifeless> infinity: well, one is a feature that we apparently have, but doesn't seem to work. The other would not affect the kernel - its just pulling out the debug data into a separate package for freaks like me
<lifeless> -> ubuntu-kernel if you like
<mdz> Keybuk: how is the init stuff looking?
<mjg59> mdz: Yes
<mdz> mjg59: we're increasingly overloading the powernowd init script. yahoo
<mdz> why does lists.ubuntu.com have no google juice at all?
<tseng> google juice puts alot of weight on hyperlinks
<tseng> but you would think one off ubuntu,com would be enough to get started..
<imbrandon> Results 1 - 10 of about 82 linking to lists.ubuntu.com.  <-- low number of incoming links probably
<mdz> searching for Ubuntu maliing list content turns up gmane, mail-archive, and loads of other stuff rather than lists.ubuntu.com
<imbrandon> mdz: if someone took the time to make a google site map that would help TREMENDUSLY with googles rankins and links
<imbrandon> mdz: http://www.google.com/support/webmasters/bin/answer.py?answer=34654
<imbrandon> it would tell google to crawl it at an interval we set and what urls to crawl like the archives
<imbrandon> kinda an advanced robots.txt
<jdub> oh, hrm. fglrx still doesn't work.
<jdub> mjg59: free 3d is not doable on a Radeon Xpress 200M (RC410) ?
<infinity> jdub: It will today, if I have anything to say about it.
<jdub> sweet
<jdub> in the mean time, i will dapperise a spare partition ;)
<poningru> can I annoy someone regarding which package to file a bug under?
<Keybuk> mdz: pretty good, should be in the archive before the sprint
<Keybuk> am mostly testing atm
<mdz> Keybuk: what does the upgrade process look like?
<Keybuk> pretty minimal at the moment, it just replaces the key parts of sysvinit and runs /etc/init.d/rc N
<Keybuk> so most things are unaffected
<desrt> who's responsible for the single-instance-app framework?
<desrt> i think i might want to use it in applets
<desrt> zul; ARGH.  hold on.
<desrt> freenode is preventing me from /msg'ing you
<zul> eh?
<zul> maybe i have been blacklisted :)
<desrt> no.  it's just lilostupid
<desrt> it's working now
<infinity> iwj: Argh.  Having firefox Depends on firefox-themes-ubuntu, but Breaks the only versoin available in the archive is a bit problematic.
<zul> night
<DShepherd> night
<excitatory> so, i just tried to install the php4-mysql package.. dpkg tried to execute some kind of config file or something (judging by the dpkg output) out of /tmp/php4-mysql.config.157021  -- which doesn't make sense to me since i mount /tmp with noexec, as i'm sure most of you do.
<excitatory> so like, is this an issue i would talk to the package maintainer about, file a bug, or shout at you guys in here about?
<LaserJock> excitatory: well, you could look at /var/lib/dpkg/info/ for the postinst script and see what it's doing
<LaserJock> excitatory: but really #ubuntu (for dapper), #ubuntu+1 (for edgy), and #ubuntu-bugs are the more appropriate places :-)
<excitatory> LaserJock: ok, sorry.  ..and thank you for your help.
<LaserJock> no problem
<mdz> Keybuk: is bootchart expected to be working in edgy?
<mdz> Keybuk: I get no /dev/.bootchart, 'bootchart bottom' hanging around and no love
<rodarvus> mdz, I've seen your email on removing Breaks: from packages until implementation is completed. xorg-server has Breaks: support for about two weeks now, and I haven't heard anything from users upgrading yet. Shall I remove it?
<mdz> rodarvus: did you use it in place of a Conflicts or in addition to a Conflicts?
<mdz> rodarvus: you should be able to tell from the email whether it will break in your circumstances
<mdz> the problem is that apt may tell dpkg to install a package which would cause Breaks to be dissatisfied
<rodarvus> xorg-server does not conflicts with the packages it breaks (only the replacement packages do)
<rodarvus> xserver-xorg-video-* conflicts with xserver-xorg-driver-*
<rodarvus> mdz, but yes, I think it might break apt upgrade
<mdz> then it should probably be reverted for now
<rodarvus> doing it now, thanks!
<rodarvus> just wanted to get your official ack on that
<Keybuk> mdz: I don't know of a reason it shouldn't ... it was certainly working a few days ago
<Hobbsee> mdz: w.r.t to the meeting, i would expect/hope to work with jono as well.
* Hobbsee is still reading
<Keybuk> mdz: just worked ok for me
<mdz> Keybuk: will try a more verbose boot
<mdz> I get a "chdir: No such file or directory" from an init-bottom script
<mdz> no output from the bootchart script that I can see
<Keybuk> sounds like your update-initramfs is broken/incomplete
<mdz> I ran it by hand and watched it; it should surely be complete
<Keybuk> try update-initramfs -u, etc.
<Keybuk> hmm, and the bootchart script was run in the initramfs?
<mdz> yes, there were processes running from it
<mdz> which weren't killed because /dev/.bootchart didn't exist
<Keybuk> that's odd
<Keybuk> /dev/.bootchart is made by that script
<mdz> indeed
<mdz> nothing should have mounted over /dev later, right?
<Keybuk> nope
<ajmitch> mdz: assign or subscribe ubuntu-release for UVF exception? cdbs needs some fixes
<mdz> ajmitch: subscribe, per DeveloperResources
<ajmitch> then the wiki needs changed
<mdz> hmm, worked on the second try with an identical initramfs
<mdz> spooky
<mike_zhang> who can show me a example of the database used by wanna-build?
<Keybuk> mike_zhang: wrong channel, try a Debian channel  (Ubuntu doesn't use wanna-build)
<mike_zhang> but I want to setup a buildd daemon on dapper
<mike_zhang> any suggestion?
* joshuapurcell is away: I'm busy
<pitti> Good morning
<desrt> pitti; hello.
<pitti> hey desrt
<rodarvus> pitti, good morning
<rodarvus> . o O ( about time I should go to bed )
* desrt was just thinking that
<pitti> heh, sleep well, guys!
<desrt> pitti waking up is a good indicator for those in eastern standard time to go to bed :)
<rodarvus> pitti, I won't give up so quickly ;)
<rodarvus> I'm not no EST (UTC-3 here), so even worse
<rodarvus> s/no/on/
<pitti> moin mvo
<pitti> mvo: I have an updated apt&friends system now; anything you want me to do for you?
<mvo> hello pitti
<mvo> pitti: could you plesae run (if you have 0.6.45ubuntu4): apt-get install --install-recommends --fix-policy ?
<mvo> and see what it suggests
<mvo> ?
<pitti> whoa
<mvo> a big list I guess :) ?
<pitti> mvo: http://paste.ubuntu-nl.org/20644
* pitti definitively does not want to add all this junk
<pitti> mvo: however, the removed packages are a bit worrysome
<mvo> yeah
<mvo> those are pretty bad decisions from the resolver
<pitti> mvo: dist-upgrade only wants to do that, BTW:
<pitti> Die folgenden Pakete sind zurckgehalten worden:
<pitti>   hal-device-manager hpijs libgcj7-jar
<pitti> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.
<mvo> this is what we would end up if we enable install-recommends as default
<mvo> the recommends lists of some packages are pretty odd
<mvo> e.g. nautilus recommends fam
<pitti> mvo: IMHO, before we do that by default, we need to clean up recommends
<mvo> -o Debug::pkgDepCache::AutoInstall=true will give details what package requested what package
<pitti> do you want that?
<mvo> pitti: I totally agree, I think we should talk in wiesbaden about it
<pitti> (output)
<mvo> not now, thanks
<Burgundavia> mvo: the tahi thing preventing ubuntu-desktop from installing. Known?
<mvo> Burgundavia: no, I will have a look
<Burgundavia> mvo: ttf-thai-t1wg
<mvo> pitti: thanks for the output, I will write a mail to ubuntu-devel explaining about the new feature and that we will most likely have to discuss this again
<Fujitsu> Is there a reason for Edgy's hal-device-manager to be displaying all PCI devices as `Unknown' now?
<mvo> Burgundavia: u-d seems to upgrade here, can I get put the output of "apt-get install ubuntu-desktop -o Debug::pkgDepCache::AutoInstall=true -o Debug::pkgProblemResolver=true" to a pastebin please?
<Burgundavia> can do
<Burgundavia> mvo: pastebin.ca/132309
<mvo> Burgundavia: thanks
<Burgundavia> cheers
<Burgundavia> mvo: fyi: only main and restricted enabled
<Burgundavia> mvo: looks like it might be a gettext issue and doko might have just uploaded a fix
<mvo> yeah, it looks like that is the root of the problem
<Burgundavia> right
<kagou> hi
<pitti> hi kagou 
<kagou> hey pitti
<kagou> who do i ask for ubiquity proposition ?
<Burgundavia> kagou: what is your idea?
<Burgundavia> kagou: and btw, proposition is usually used to english to ask someone to marry you. Idea is used more commonly
<StevenK> Maybe kagou does want to marry ubiquity.
<imbrandon> in that case as the father err keybuck 
<imbrandon> heh
<Burgundavia> StevenK: he could, but it might be a very cold marriage
<kagou> Burgundavia, searching bugs report on ubiquity crash on edgy i found 95 results. so i propose that when ubiquity crash, it show us the name of the process where it crash. (partitioning/formating/installing/configuring keyboard) ...
<Burgundavia> right, interesting idea
<Burgundavia> Kamion is the person to talk to, but he is currently on vacation
<kagou> i must precise that 95 results with "ubiquity crash" as name is not very efficient :p
<imbrandon> kagou: although i'm sure he would entertain a patch too when he gets back to look over along with the idea ;)
<kagou> i'm asking that also because as debsquad team member, it may help us a lot :)
<kagou> thanks men, i will wait for Kamion
<mjg59> jdub: Correct
<mjg59> jdub: (re: Radeon Xpress 200)
<Burgundavia> mjg59: one of these days I am going to update the fglrx page on the help wiki. Is there a good list somewhere of stuff that needs fglrx and stuff that can use r300? (and is that enabled by default for dapper or edgy?)
<sabdfl> mdz: is there an ethereal security review anywhere handy?
<Burgundavia> doko_: are we installing the gcjwebplugin by default?
<doko_> not yet
<Burgundavia> does it still have the security issue of not being sandboxed?
<doko_> the AccessController's are there, may need another update backport from the trunk/classpath-0.92
<Burgundavia> right, just wondering
<Burgundavia> given Fedora was trumpeting their crap, figured I would find out, for marketing reasons
<iwj> infinity: Err, I meant to remove the Depends.
<thom> mvo: with the DDTP enabled apt (ie, yesterday's) I'm seeing "dynamic mmap ran out of room" when i wasn't before, so I'm guessing the default Cache Limit needs to be bumped now
<iwj> infinity: Yes, I've just checked and I removed the D@epends.
<mvo> thom: thanks! could you please /msg me your sources.list ? just to get a idea how big it is
<thom> mvo: no problem
<slomo> mvo: a friend of mine has the same problem
<slomo> mvo: setting APT::Cache-Limit "141943904"; in apt.conf "fixes" it for him
<doko> mdz: "generic" ping
<seb128> doko: do you use gaim? :)
<doko> seb128: no, not really
<seb128> doko: do you have some account configured for it? I'm just curious to know if it crashes gdb for you too
<doko> seb128: I'm still running dapper
<seb128> hum, k
<ogra> hmm, no pitti ...
<seb128> who would be interested to track a gdb crasher with me? :)
<doko> yeah, I should upgrade before the spring ...
<ogra> doko, upgrade before the tulips bloom ;)
<seb128> doko: you have no edgy box at all? What are you doing since june? :p
<mvo> slomo: thanks
<doko> seb128: awaiting the pango-upload-to unstable-before-seb-vacation and see how OOo breaks :p
<antoine> seb128,  tu vois grace a moi tu bosses :p
* seb128 kicks antoine
<infinity> iwj: I think something about the Breaks/Depends handling is causing it to not upgrade.
<infinity> iwj: I can't remove firefox-themes-ubuntu because the old firefox depends on it, and I can't install the new firefox because it breaks firefox-themes-ubuntu.
<seb128> doko: don't touch pango :p
<seb128> infinity: http://launchpad.net/bugs/56394 
<Ubugtu> Malone bug 56394 in firefox "Premature use of Breaks causes apt failure" [High,Confirmed]  
<infinity> iwj: http://cerberus.0c3.net/~adconrad/argh.txt
<infinity> seb128: Thanks.
<seb128> np
* infinity starts forcing things.
<pitti> hello again
<seb128> hey pitti
<gnomefreak> infinity: let me know if it works with no issues please
<ogra> hey pitti 
<slomo> hi pitti :)
<infinity> gnomefreak: "dpkg --force-depends -P firefox-themes-ubuntu" followed by "apt-get -f install" followed by "apt-get dist-upgrade" appears to do the trick.
<gnomefreak> ok ill try it ty
<ogra> pitti, http://people.ubuntu.com/~ogra/ltspmount.c
<ogra> pitti, i'm not sure the execvl is ok ... but there we have a start from sbalneav
<geser> I could get past this firefox breakage with sudo dpkg --auto-deconfigure -i /var/cache/apt/archives/firefox_1.99+2.0b1+dfsg-1ubuntu2_amd64.deb
<gnomefreak> geser: no
<gnomefreak> geser: i tried everything to work around it except --force-depends and that seems to have worked
<pitti> hi ogra, moin slomo
<pitti> slomo: you'll get your MIR review today, promised
<pitti> ogra: I'll take a look at it
* ogra remembers to quickly do a fuse-utils MiR
<slomo> pitti: thanks :)
<pitti> ogra: what for?
<pitti>       fuse | 2.5.3-2.1ubuntu2 | http://archive.ubuntu.com edgy/main Sources
<pitti> ogra: binary promotions for main sources are no problem, I always approve full sources
<ogra> pitti, the fuse-utils binary package is in universe
<ogra> oh, ok
<ogra> and someone deleted my entries for ltspfs from the queue :/
* ogra re-adds
<pitti> ogra: how do you want feedback? inline quote with comments?
<pitti> per mail?
<pitti> ogra: or interactively via IRC?
<ogra> pitti, as its convenient for you :)
<pitti> I don't mind
<pitti> I'll mail you then
<ogra> great :)
<iwj> infinity: How annoying.  I think we need to fix apt to pass -B to dpkg.
<iwj> infinity: If you dpkg -iB firefox.deb it should work.
<mvo> iwj: just for every invocation of dpkg on "install"?
<iwj> mvo: Yes.
<iwj> Also, when it's done, it should dpkg --configure -a.  (It has that stupid bug where it tries to configure only the needed things, and can't cope, anyway.)
<iwj> But the former will be sufficient for the moment.
* iwj gets out the apt source.
<mvo> iwj: if that -b is all there is I can do it now, I will have to merge any patch to my bzr repository anyway
<iwj> -B, short for --auto-deconfigure.
<thom> mvo: i want to talk to you about the https patches for apt at some point
<iwj> mvo: If it's trivial for you to do it now then sure.  But I need to do some other things to apt anyway.
<mvo> thom: I have branch for this, it seems to be working for some people (also little testing so far)
<thom> mvo: nod. just a shame about the license and the fact it uses stunnel, which seems a bit mad
<mvo> iwj: its trivial for me, I would be interessted in what you plan to do
<mvo> thom: yes, that is why it is not merged :)
<mvo> thom: do you plan to work on it ? that would be awsome !
<iwj> mvo: Make apt want to upgrade things when Breaks is relevant.
<thom> mvo: work really needs it, so i may well
<mvo> thom: I was also considering to check a https based backend based on libcurl
<iwj> Although if the firefox/ff-themes-ubuntu thing is an example that may not be quite right ...
<thom> mvo: libcurl, or just gnutls with the existing http backend
<mvo> iwj: I added --auto-deconfiure to "--unpack" now. I assume that is correct? or is it also needed with --configure?
<iwj> No, not needed with --configure.  Thanks.
<Riddell> ogra: do you have a bzr archive for hwdb-client?
<ogra> yep
<ogra> on people
<iwj> pitti: Can I ask you some questions about mozilla-firefox-locale-all, which the ff2 broke ?
<pitti> ogra: mailed you the review result
<ogra> pitti, thanks :)
<ogra> Riddell, http://people.ubuntu.com/~ogra/bzr-archive/hwdb-client/
<pitti> iwj: if it is 'will you update the langpacks?', then 'yes, ASAP' :)
<pitti> iwj: sure, just go ahead
<ogra> pitti, hmm, english would have been easier to forward to sbalneav :) but i'll translate 
<pitti> ogra: oh, didn't think of that; sorry
<pitti> ogra: just do the first round of fixes, and in round 2 I'll write English
<iwj> pitti: Oh, if you're doing it then thank you very much ...
<iwj> I was just looking at it and I though `I'm bound to break it even worse if I mess with it'.
<Riddell> ogra: for the kde frontend I'll probably split the package into hwdb-client-common, hwdb-client-kde and hwdb-client-gnome
<Riddell> ogra: if that's ok
<pitti> iwj: it put it on my list on Friday, just the usual EBUSY
<ogra> Riddell, sure
<iwj> pitti: Right, OK.  Malone #56386.
<Ubugtu> Malone bug 56386 in mozilla-firefox-locale-all "Needs update for Firefox 2.0" [Critical,Confirmed]  https://launchpad.net/bugs/56386
<iwj> (FYI)
<iwj> Thanks a lot ...
* pitti assigns that but to him
<mvo> iwj: ok, done (in bzr now)
<iwj> mvo: Thanks.
<iwj> mvo: I don't see apt in BzrMaintainedPackages - does someone need to think about doing an upload ?
<mvo> ogra: what do you think about a additional "hwdb-client-gtk" ? this would make xubuntu happy because IIRC/AFAIK they can't ship it because of the gnome-canvas dependency (or can they)?
<iwj> Also, where is your bzr ?  IWBN to be looking at the latest source.
<ogra> i thought that was split out now
<ogra> mvo, a hwdb client without canvas would mean a rewrite (of the frontend at least)
<ogra> we talked about that ...
<mvo> iwj: http://people.ubuntu.com/~mvo/bzr/apt/
<mvo> iwj: apt--ubuntu is my branch
<mvo> iwj: I really need to put the apt package branch onto the main mirror :/ 
<ogra> pitti, do you mean we should drop the {become,drop}_root() functions completely from ltspmount ?
<ogra> (thats at least how i understand the comment)
<pitti> ogra: it does not make too much sense IMHO
<pitti> ogra: you can keep them, of course, if you fix the real/effective bug
<pitti> ogra: so that at least the getopt() call runs with euid != 0
<ogra> ok
<iwj> mvo: NP.  Do I want to be using your branch or something else ?
<mvo> iwj: yeah, you probably want to use my branch (the apt--ubuntu) one
<iwj> Right.
<mvo> iwj: we could also branch if this is a bigger thing
<mvo> iwj: and create a "apt--implement-breaks" branch
<mvo> iwj: and then merge it back, that has the advantage that mering this feature into debians apt is easy 
<iwj> I'll read the source first and then decide.
<mvo> s/is/will be/
<iwj> http://people.ubuntu.com/~mvo/bzr/apt/ doesn't contain an apt--ubuntu subdirectory.
<mvo> iwj: http://people.ubuntu.com/~mvo/bzr/apt/ubuntu/
<mvo> iwj: sorry
<iwj> NP.
<iwj> ian@anarres:/work/Dpkg-breaks-5/apt-bzr $ bzr branch http://people.ubuntu.com/~mvo/bzr/apt/ubuntu/ 
<iwj> bzr: ERROR: '_Branch' object has no attribute '_branch_format'
<iwj> ??   It's been a while since I tried to use bzr.  Perhaps I'm doing it all wrong ...
<mvo> iwj: does "bzr get" works on the same branch? 
<iwj> No, same message.
<iwj> But I RTFM'd and `get' isn't in the FM any more ...
<iwj> (If it ever was.)
<iwj> My debug log says:
<iwj> [ 3059]  Tue 12:04:42.776 ERROR: Not a branch: http://people.ubuntu.com/~mvo/bzr/apt/
<iwj> Oh, no, that was from before.
<mvo> iwj: let me try to re-push my data
<iwj> How odd, I have some extremely old version of bzr which apt wasn't updating.
<iwj> mvo: Well, it's working now.  Sorry to bother you.
<mvo> iwj: no problem
<pitti> Fujitsu: thanks for spotting the hal problem, I fixed it this morning
<Fujitsu> Thanks pitti :)
<Fujitsu> What was the problem?
<pitti> Fujitsu: wrong path to pci.ids
<pitti> Fujitsu: in previous releases it was in /var/lib/misc, now it is in /usr/share/misc
<Fujitsu> OK.
<Fujitsu> I suspected it had failed to locate the ID list.
<Fujitsu> How long ago is `this morning'?
<Fujitsu> That's 12 hours ago for me :P
<pitti> Fujitsu: hum, 4 hours or so
<Fujitsu> Ah.
<Hobbsee> hi pitti 
* pitti apologizes for using weaklu defined time references
* pitti hugs Hobbsee, hi!
<Fujitsu> That's the problem with long-distance communication >_<
* Hobbsee hugs pitti in return
<Hobbsee> Fujitsu: true.  it would be much better if the world was flat.
<Hobbsee> remind me to change that, when i've taken over the world. that we all use one timezone.
<pitti> Hobbsee: that was my idea!
<ogra> oh, it isnt ? 
<Hobbsee> pitti: i know, i was going to give you credit for it in a second :)
<Fujitsu> That was /my/ idea, pitti/Hobbsee/everybody.
<Fujitsu> :P
<Hobbsee> hah
<Hobbsee> no, it was pitti's idea.
<Hobbsee> i'll let pitti be one of my sidekicks when i take over the world.
<Hobbsee> he can fix bits of it
* pitti LGPLs the idea
<Hobbsee> heh
<pitti> Hobbsee: oh, will I get my own dog kennel in your palace?
<Hobbsee> pitti: sure :)  you can have a bed in the spare bedroom, i fyou want
<Fujitsu> It works much better now... Thanks pitti.
<pitti> cool
<HiddenWolf> pitti: ping
<pitti> hi HiddenWolf 
<HiddenWolf> pitti: sorry to bug you, but on my dapper box hal just died, I was wondering how to diagnose it
<HiddenWolf> failed to initialise on reboot, in fact
<pitti> HiddenWolf: https://wiki.ubuntu.com/DebuggingRemovableDevices, second half of the page describes the debugging procedure
<HiddenWolf> pitti: that 404's
<HiddenWolf> ah
<HiddenWolf> nm
<pitti> hm, WFM
<HiddenWolf> pitti: the comma did it. :)
<pitti> xchat does not select it :)
<HiddenWolf> xchat-gnome does
<HiddenWolf> Right, now it starts ok. :/
<infinity> irssi+gnome-termianl doesn't select the comma either.  Embrace the console. :P
<Hobbsee> konversatoin does :(
* Hobbsee should file a bug abotu that.
<Hobbsee> or maybe just whine at the maintainer about it
<pitti> Hobbsee: isn't that what a bug report is all about? :)
<Hobbsee> pitti: true that.
* Hobbsee files tons of bugs for pitti to fix then.
<Hobbsee> pitti: actually, i do want to pick your brains in a bit.
<Hobbsee> once i've read the mailnig list
<pitti> just give me some time to finish upgrading the firefox locales, then my brain is all your's
<Hobbsee> hehe
* Hobbsee pictures removing pitti's brain, and stirring it around with a large rod
<Treenaks> Hobbsee: while laughing maniacally?
<Hobbsee> Treenaks: no, probably not...
<Hobbsee> Treenaks: not in an evil mood tonight
<lemsx1> well, it seems it's true and XFS is broken in .17 kernels
<thom> lemsx1: current edgy seems fine with XFS, what are you seeing?
<lemsx1> thom: i open a bug about it yesterday with all the logs
<lemsx1> thom: but Otavio Salvador (Debian Developer) confirmed to me that XFS is indeed broken in .17 kernels
<lemsx1> thom: at least i didn't loose any data. i just couldn't mount the disk
<thom> 56384?
<lemsx1> thom: yes
<thom> well, as i said. xfs is working just peachily for me
<thom> and see ben's comments on the bug
<lemsx1> i'm attaching the extra info
<tseng> thom: you should whinge a whole bunch about it on planet debian
<tseng> thom: latest meme
<thom> tseng: seems that way yeah, i might whinge about reiser just to restore balance in the force
<lemsx1> thom: i'm guessing dmesg when using the offending kernel...
<thom> lemsx1: yes
<pitti> iwj: new ffox locales uploaded
<pitti> Hobbsee: ok, do you have any question for me?
<Hobbsee> pitti: sorry, havent read that far thru the mailing list yet
<pitti> ok
<Hobbsee> pitti: basically, it's "how does kde/kubuntu-desktop integrate in with the automatic bug reporting stuff" but the answer to that may well be further down the list
<tseng> is there any easy way to turn off the segfault catcher?
<tseng> i was working on development
<tseng> trying to fix my own crasher, and it was really slowing me down
<tseng> really churns the box cold for some second every time
<pitti> Hobbsee: I discussed that with Riddell 
<pitti> tseng: right now, only sudo /etc/init.d/apport stop, sorry
<pitti> tseng: with our current approach, the kernel already dumped core before we can decide 'we do not want a report for this'
<pitti> Hobbsee: so far he deemed the KDE crash reporter appropriate for edgy
<Hobbsee> pitti: cool.  i never found out what the result was, and was just curious.
<Hobbsee> ah yes.  i heard that
<pitti> Hobbsee: as long as kubuntu-desktop depends on apport, you will still get non-KDE crash reports
<pitti> Hobbsee: you'll just not have the apport-gtk frontend
<pitti> but that's not that important
<Hobbsee> pitti: true that, i was more thinking of integrating kcrash, and all the extra information that it seems this new thing will collect, like versions etc, straight into LP
<pitti> that still needs some brainwork
<Hobbsee> pitti: indeed.  as in, brain work on how/if it should happen, or how to do it?
<pitti> both
<pitti> Hobbsee: the Gnome equivalent of kcrash is bug-buddy, and we'll disable it by default
<Hobbsee> pitti: right.
<iwj> pitti: locales> Thanks!
<Hobbsee> pitti: feel like rebuilding debtags and adept?  that should fix the breakage, i'm told.
<Hobbsee> pitti: libapt-front first, i'm told
<mvo_> Hobbsee: I will take care of it
<mvo_> Hobbsee: I already patched/uploaded libapt-front
<Hobbsee> mvo_: oh cool.  that's what i thought
* Hobbsee wasnt sure if the breakage was kde specific, and therefore unlikely to get picked up by you
<Hobbsee> mvo_: apt doenst seem to have irrecovably broke this time.  thanks for that :)
<mvo_> pitti: can you please have a look at: http://librarian.launchpad.net/3901310/buildlog_ubuntu-edgy-i386.libapt-front_0.3.9ubuntu1_FAILEDTOBUILD.txt.gz (could the failure be related to the new ddeb generation)?
<mvo_> Hobbsee: heh :)
<mvo_> Hobbsee: apparently libapt-front is FTBFS :/
<Hobbsee> mvo_: i dont mind breakage that much.  but i *do* mind apt breaking, as tha'ts kinda hard to recover from.
<wasabi> xkb problems. Looks like g-settings-d can't set the config.
<wasabi> Not too familiar with this process.
<wasabi> Probably it's running xmodmap or equivilent in the background?
<mvo_> infinity: any clue about http://librarian.launchpad.net/3901310/buildlog_ubuntu-edgy-i386.libapt-front_0.3.9ubuntu1_FAILEDTOBUILD.txt.gz?
<Kaleo|dodo> rodarvus: there is something wrong with the lookup path of binaries linked dynamically with libGL I think
<Kaleo|dodo> rodarvus: bug 54858 still
<Ubugtu> Malone bug 54858 in xserver-xorg-video-i810 "3d acceleration broken in Edgy Knot 1" [Medium,Needs info]  https://launchpad.net/bugs/54858
<infinity> mvo_: Well, other than "It's pitti's fault", I'm not immediately familiar with the failure.
<infinity> pitti: See mvo's pasted log.
<mvo_> infinity: that is good enough for me, thanks
<rodarvus> Kaleo|dodo, how strange.
<rodarvus> Kaleo|dodo, is dri working for you, without workarounds?
<Kaleo> no
<Kaleo> only with the symlink
<rodarvus> it started working on the only test machine I have here, after the latest mesa upload)
<Kaleo> interesting
<Kaleo> I should wipeout the system and try with a fresh install
<Kaleo> rodarvus: eek, it's going to take hours
<Kaleo> rodarvus: any ideas to make sure that we have a bug ?
<Kaleo> rodarvus: concerning AIGLX and compiz, I have made some progress
<rodarvus> we have a bug. the real subject here is if its a bug in the source code (this would be an important bug), or in the upgrade scripts, which are failing to detect your machine (and possibly others) are missing a link
<sbalneav> pitti: pingie, two secs?
<rodarvus> Kaleo, dri and aiglx basically work here
<rodarvus> (on a freshly installed machine)
<rodarvus> freshly == about one week ago
<Kaleo> I see
<Kaleo> rodarvus: what procedure should I follow ?
<rodarvus> unfortunately, I need spending 100% of my time on other subject, right now (preparation to the sprint, next week, and edubuntu administrativia)
<rodarvus> so, any help figuring out whats the issue exactly is muchly appreciated
<rodarvus> Kaleo, try purging libgl1-mesa-dri from your system
<rodarvus> (+ any links you added manually)
<rodarvus> then reinstall it
<rodarvus> it would also be helpful to test the following situations, if at all possible:
<rodarvus> 1. fresh edgy installation
<rodarvus> 2. upgrade from dapper
<rodarvus> lunch time, bbl
<Hobbsee> rodarvus: enjoy :)
<Kaleo> rodarvus: have a good meal
<Kaleo> rodarvus: purging libgl1-mesa-dri and reinstalling it does not provide /usr/X11R6/lib/modules/dri/i915_dri.so that glxgears is looking for
<rodarvus> ahn
<rodarvus> gotcha
<rodarvus> Kaleo, try running xmoto instead of glxgears
<rodarvus> I bet mesa-utils just needs to be recompiled
<Kaleo> rodarvus: seems ok
<rodarvus> :)
<Kaleo> oh
<Kaleo> actually no
<Kaleo> libGL error: dlopen /usr/X11R6/lib/modules/dri/i915_dri.so failed 
<pitti> sbalneav: pong
<QuestionMarkCoun> Kamion: I have a problem with a iso-image created with cdimage. I have modified seeds and added some own packages. Now, when I try to install from this CD, installastion fails with "No installable kernel found... "
<pitti> mvo_: yes, that's my bug
<pitti> mvo_: I'll reproduce it locally and fix it
<pitti> QuestionMarkCoun: FYI, Kamion is on vac this week
<QuestionMarkCoun> oh ups...
<QuestionMarkCoun> anybody else here, who knows cdimage?
<sbalneav> pitti: Hey!  Great, sorry that code got sent to you so early!  It wasn't ready yet.  Thanks for the tips, I've fixed about all of them, but i'm a little unclear on what you'd like to see for the setuid stuff
<pitti> sbalneav: I don't want to prescribe you anything
<ogra> pitti, but you need to approve it :P
<pitti> sbalneav: the become/drop_root() functions, when done properly, are nice for catching errors
<sbalneav> Dude, I bow to your superior skills.  I'll do whatever you suggest! :)
<pitti> sbalneav: so, by all means, keep them
<QuestionMarkCoun> but I think my problem is not directly cdimage. I assume it has something to do ith gpg
<pitti> sbalneav: I just wanted to make sure that these are not security enhancements
<pitti> sbalneav: dance on the Las Vegas skyscraper tower at midnight, naked, with pom poms!
<thom> haha
* pitti tests how far he can go with the 'whatever you suggest'
<ogra> but record it please so we can put it on planet.ubuntu.com ;)
<pitti> hey thom!
<thom> hey mate :-)
<pitti> ogra: I actually thought it to become the edgy CD example video
<sbalneav> Errr, ok.   :)
<ogra> haha
* sbalneav shakes his bootay
* ogra shades his eyes 
<ogra> and Hobbsees
<pitti> sbalneav: I'll write the next audit in English, sorry
<Hobbsee> hah, yeah
* Hobbsee looked in the other direction seeing pitti's first suggestion.
<QuestionMarkCoun> where can I find information, how to setup my own gpg keyring for signing my cd?
<sbalneav> pitti: So, you're thinking I only need full root for the mount command, and just euid = 0 for the mkdir?  Am I getting that correct?
<pitti> infinity: oh, btw, before you lart me for the coreutils FTBFS, I know about it, and it'll be fixed soon
<sbalneav> I'll be blunt: I've never actually written an suid program before.  All of my code's either been totally userspace, or totally root :)
<pitti> sbalneav: don't worry, we'll get it solid enough soon
<pitti> sbalneav: shall I send you a translated version of the audit, or will ogra do the first round fix?
<sbalneav> ok, let touch up one or two more things, and I'll send you v0.2
<sbalneav> I'm already fixing round one.
<ogra> pitti, he's to fast for me 
<sbalneav> Just tryn' to help my buddy ogra :)
<sbalneav> pitti@ubunut.com?
<sbalneav> ubuntu?
<pitti> sbalneav: @ubuntu.com
<sbalneav> k, gimme 10
<pitti> mvo_: ah, I think I have a potential candidate for the break:
<pitti> Package: apt-index-watcher
<pitti> Depends: ${shlibs:Depends} ${misc:Depends}
<pitti> mvo_: there's no comma, that might confuse pkg-create-dbgsym
<pitti> if that's valid syntax, I'll fix it
<infinity> It's not valid syntax.
<Hobbsee> QuestionMarkCoun: try !gpg
<pitti> mvo_: saw above comment?
<Kaleo> rodarvus: some interesting stuff added to bug 54858
<Ubugtu> Malone bug 54858 in xserver-xorg-video-i810 "3d acceleration broken in Edgy Knot 1" [Medium,Needs info]  https://launchpad.net/bugs/54858
<QuestionMarkCoun> !gpg
<QuestionMarkCoun> ??
<Hobbsee> QuestionMarkCoun: in a channel with ubotu in it
<Hobbsee> QuestionMarkCoun: anything with ! in front of it is a bot command - usually a factoid
<QuestionMarkCoun> sorry... i am not using irc often
<doko> infinity, cprov: please requeue ecj-bootstrap on amd64
<cprov> infinity: around yet ?
<infinity> cprov: Yeah, I'm here, I'm on it...
<infinity> (Well, actually, I'll be doing a mass-give-back, but that's sort of the same as "on it")
<cprov> infinity: tks
<sbalneav> pitti: ogra: sent.
<LaserJock> *cough*LVM support in edgy kernel*cough*
<HiddenWolf> LaserJock: i've been running lvm's since hoary at least. :)
<cbx33> hi guys, I did an upgrade the other night, and upon rebooting lost all network devices
<LaserJock> yeah, but edgy's kernel doesn't appear to have it
<cbx33> LaserJock, I've gotten the kill stuff working in scp :D
<LaserJock> HiddenWolf: i.e. bug 54189
<Ubugtu> Malone bug 54189 in Ubuntu "LVM support forgotten in newest kernel update?" [Untriaged,Confirmed]  https://launchpad.net/bugs/54189
<zul> LaserJock: it shouldnt have disappeared something other must have been broken
<matt_> Kamion: We spoke a while ago about some changes to preseeds. I was wondering if you could answer a question of mine regarding udebs. Is there a specification for udebs? How is the debian installer instructed on what udebs to load? How could I create a udeb that stars after disk-detect but before partman runs? I have dug around in the initrd stuff and some other udeb code, but I have to admit that I am a bit lost.
<LaserJock> zul: true. I needed to change root= in grub to /dev/mapper/ubuntu-root to get my box to boot
<LaserJock> zul: I'm not sure what would be responsible for that
<elmo> matt_: kamion is on holiday
<matt_> Ah, can anyone answer this question? ;-)
<matt_> From what I have seen, udebs and related things are not well documented, if at all; and the only people who would be expected to understand their functioning in the d-i framework is the developers themselves.
<pitti> zul: ah, I just tracked down and fixed the cause of the xen-3.0 FTBFS and also added a test suite check for it
<zul> pitti: ah thanks..
<desrt> there is no dana; only zul!
<pitti> zul: I'll tell you when the fixed pkg-create-dbgsym is in the archive
<pitti> zul: the current version seems to be stuck anyway
<zul> pitti: yeah it is :(
<HiddenWolf> pitti: got a minute?
<pitti> HiddenWolf: yes
<HiddenWolf> pitti: I'm still having issues with hal on my freshly-installed dapper box. usbsticks mount fine, but my cdrom seems to be owned by root.
<pitti> HiddenWolf: cdrom == the device node /dev/whatever, or the mounted fs?
<HiddenWolf> the mounted fs
<HiddenWolf> I popped in a dvd, it doesn't show up for my user, but it does when I sudo nautilus
<pitti> HiddenWolf: is it a real CD, or a DVD with UDF?
<pitti> ah
<pitti> HiddenWolf: UDF has real permissions, and does not like uid/gid mount options
<pitti> I'm afraid there is no quickfix for that
<HiddenWolf> Can i work around it?
<pitti> HiddenWolf: do you have pmount 0.9.12 (edgy) or dapper?
<pitti> HiddenWolf: I did a small fix to 0.9.12 which should help a little (loosen umask)
<HiddenWolf> pitti: I'm running a pretty virgin dapper
<HiddenWolf> pitti: my usb-drive just stopped mounting too.
<pitti> HiddenWolf: hm, oh, wait, the DVD drive is certainly in /etc/fstab?
<HiddenWolf> nor a real cd
<HiddenWolf> yes, it is
<pitti> hey seb128 
<pitti> HiddenWolf: ok, in the fstab case, pmount cannot do anything
<seb128> hey pitti
<pitti> HiddenWolf: you might try to add 'umask=000' to the CD-ROM's option list in fstab
<pitti> seb128: go away, you have a holiday! :)
<seb128> pitti: I'm not around to work, don't worry ;)
<HiddenWolf> pitti: I guess hal is choking totally now
<seb128> pitti: I just joined IRC to speak to a friend ;)
<HiddenWolf> pitti: just plugged a pendrive in my usb hub, and it doesn't come up
<seb128> pitti: though, if you want to debug gdb with me I would not say no :p
<HiddenWolf> pitti: but mounted as root
<pitti> HiddenWolf: hm, sorry for that; can you please do the debugging steps on that wiki page and open a bug or mail me the logs?
<HiddenWolf> pitti: which mail would you prefer, I can mail them now.
<pitti> HiddenWolf: martin.pitt@ubuntu.com
<HiddenWolf> coming right up
<pitti> mvo_: bah, I'm just modifying pkg-create-dbgsym to cope with the previous Depends: line
<pitti> mvo_: but well, that cannot hurt anyway
<seb128> pitti: I'm wondering if something is not breaking -dbg packages
<seb128> pitti: is there any known issue?
<pitti> not known to me at least
<seb128> ok
<pitti> seb128: you mean the -dbg packages do not work any more?
<pitti> or some of them?
<seb128> because I've libglib2.0-0-dbg and nautilus-dbg and I got some crasher with no debug for those
<seb128> some
<seb128> $ gdb -p $(pidof nautilus)
<seb128> ...
<seb128> Reading symbols from /usr/lib/libgtk-x11-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libgtk-x11-2.0.so.0.1000.1...done.
<seb128> ...
<pitti> seb128: I have some special code in pkg-create-dbgsym that should make sure not to break *-dbg
<seb128> Reading symbols from /usr/lib/libnautilus-extension.so.1...(no debugging symbols found)...done.
<seb128> and I've nautilus-dbg installed 
<pitti> seb128: however, I'll add a test suite check for that case
<mvo_> pitti: oh, sorry. I was assuming that you would only do it if it was actually legal syntax
<pitti> mvo: well, it's not really, but since the package builds without pkg-create-dbgsym, I thought I'd fix it anyway :)
<pitti> seb128: I'll try that on my box in some minutes
<seb128> pitti: ok, thank you
<pitti> mvo: hmm, it seems pretty tough to convince dpkg-gencontrol to ignore this Depends: line; I think I'll defer that, now that you fixed it anyway
<bddebian> Howdy
<mvo> pitti: fine with me
<HiddenWolf> pitti: right, I'm going to stop bugging you, a reboot pretty much fixed it, save for the dvd. Only one question, I only have a haldaemon group, but no hal group, which debuggingremovabledevices mentions
<pitti> HiddenWolf: that's fine; I'll update the wiki page for 'haldaemon'
<HiddenWolf> pitti: excuse me for the trouble, and thank you.
<pitti> HiddenWolf: no worries, I didn't do anything :)
<pitti> HiddenWolf: does the umask=000 trick help?
<iwj> Right, well, I've found the bug that make firefox-themes-ubuntu fail to break utterly.
<HiddenWolf> pitti: commenting out the drive in /etc/fstab did it.
<pitti> HiddenWolf: hah, pmount to the rescue :)
<iwj> I wish there was a nice way to predict what apt will do.
<bddebian> Prayer?
<pitti> iwj: you mean the Breaks: field?
<mdz> doko: pong
<pitti> seb128: hm, at least my small demo package which produces a -dbg works fine
<mdz> sabdfl: ethereal security?  a contradiction in terms, I'd say
<pitti> hey mdz
<pitti> mdz: :)
<seb128> pitti: what do you call "works fine"?
<seb128> pitti: does nautilus-dbg from the archive works fine?
<pitti> seb128: if I install the -dbg, I get symbols
<pitti> seb128: trying nautilus now
<mdz> pitti: morning
<ogra> hmm
<ogra> debian drops netkit-inetd ? 
<elmo> mdz: it's in main :-P
<elmo> mdz: (that's why sabdfl was asking)
<mvo> iwj: do you know http://people.debian.org/~dburrows/model.pdf?
<ogra> in favor of openbsd-inetd
<ogra> do we follow that path ? 
<pitti> elmo: which package, ethereal? god beware...
<pitti> Hey Keybuk, how are you?
<bddebian> Heya Keybuk
<Keybuk> "morning"
<elmo> james@drescher:/srv/launchpad.net/ubuntu-archive/ubuntu/dists/edgy/main/binary-i386$ zgrep "Package: wireshark" Packages.gz
<elmo> Package: wireshark
<elmo> pitti: ^--
<pitti> seb128: I installed nautilus-dbg libglib2.0-0-dbg and now I get nice backtraces
<seb128> pitti: hum, k, so that's local b0rkage probably :/
<seb128> sight
<pitti> elmo: arrgh, who put it there?
<pitti> Keybuk: may it be that you accidentally put wireshark into main when you NEWed it?
<seb128> pitti: how do you get it crashing?
<Keybuk> pitti: it wasn't accidental
<pitti> seb128: I didn't, I just attached gdb and bt'ed
<Keybuk> pitti: wireshark is just ethereal renamed, and ethereal was in main already
<pitti> Keybuk: there is no MIR, and I would have never approved it
<pitti> Keybuk: certainly not, it's in universe in all stables
<seb128> pitti: gdb -p PID
<seb128> pitti: it does "Reading symbols from /usr/lib/libnautilus-extension.so.1...
<seb128> (no debugging symbols found)...done."
<pitti> seb128: gdb /usr/bin/nautilus `pidof nautilus`
<seb128> pitti: instead of 
<Keybuk> pitti: that's odd
<seb128> "Reading symbols from /usr/lib/libgnomeui-2.so.0...Reading symbols from /usr/lib/debug/usr/lib/libgnomeui-2.so.0.1590.1...done."
<seb128> for libgnomeui-dbg by example
<Keybuk> pitti: it certainly wasn't yesterday
<mdz> elmo: inadvertently
<Keybuk>   ethereal | 0.99.2-5ubuntu1 |          edgy | amd64, i386, ia64, powerpc, sparc
<Keybuk> or today
<Keybuk> definitely in main
<pitti> Keybuk: can you please fix it? I will be etherealny thankful to you :)
<pitti> s/fix/demote again/
<pitti> seb128: Reading symbols from /usr/lib/libnautilus-extension.so.1...Reading symbols from /usr/lib/debug/usr/lib/libnautilus-extension.so.1.1.0...done.
<seb128> pitti: ok, so just my box having the issue, weird
<pitti> seb128: dpkg -L nautilus-dbg|grep extension  shows the debug symbols for me; for you?
<Keybuk> pitti: doesn't seem to be seeded or dependend on by anything *shrug*
<Keybuk> sure
<pitti> Keybuk: right, it's in anastacia
<seb128> pitti: -rw-r--r-- 1 root root 83K 2006-08-08 17:50 /usr/lib/debug/usr/lib/libnautilus-extension.so.1.1.0
<Keybuk> how weird
<Keybuk> it must have been a dep or something at some point
<pitti> seb128: if you go into gdb and do 'symbol-file /usr/lib/debug/usr/lib/libnautilus-extension.so.1.1.0', what happens?
<seb128> (gdb) symbol-file /usr/lib/debug/usr/lib/libnautilus-extension.so.1.1.0
<seb128> Reading symbols from /usr/lib/debug/usr/lib/libnautilus-extension.so.1.1.0...done.
<seb128> Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
<pitti> seb128: objdump -h /usr/lib/libnautilus-extension.so.1.1.0|grep debuglink
<seb128> $ objdump -x /usr/lib/libnautilus-extension.so | grep .gnu_debuglink
<seb128>  22 .gnu_debuglink 00000024  00000000  00000000  000069b8  2**0
<seb128> what I was just looking at
<pitti> hm, looks fine
<seb128> yeah :/
<pitti> seb128: if you apt-get install --reinstall the library and -dbg, does it still happen? (maybe it's shadowed by a local build)
<pitti> seb128: i. e. a CRC mismatch
<pitti> seb128: you might have one package dpkg -i'ed from a local build and the other from archive.u.c</wild speculation>
<seb128> trying that now
<seb128> pitti: 
<seb128> Reading symbols from /usr/lib/libnautilus-extension.so.1...Reading symbols from /usr/lib/debug/usr/lib/libnautilus-extension.so.1.1.0...done.
<seb128> that fixed it :)
<seb128> thank you
<pitti> \o/
<pitti> seb128: *hug*
<seb128> I didn't know there was not sore of verification
* seb128 hugs pitti
<seb128> s/sore/sort
<pitti> seb128: the .gnu.debuglink has a CRC32 checksum
* ogra thinks seb128 has a weird sense of "having non work related conversations with a friend" :)
* pitti finds it funny to debug debugging
<ogra> heh
<seb128> ogra: yeah, enough time between replies to chat on that chan too :p
<ogra> hehe
<ogra> excuses
<seb128> pitti: ah? maybe want to debug bug #56391 then? :p
<Ubugtu> Malone bug 56391 in gdb "on edgy gdb crashes on xchat-gnome or gaim (by example)" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56391
<ogra> admit, youre addicted to coding
<pitti> seb128: *sigh*
<seb128> ogra: that's not really "coding" :)
<ogra> :)
<seb128> pitti: joke aside that bug is no fun, I can't attach xchat-gnome or gaim or .. to gdb on edgy
<pitti> seb128: gdb /usr/bin/gaim `pidof gaim` works just fine here, kthxbye :-P
<seb128> pitti: do you connect to a network?
<pitti> seb128: seriously, that's strange, too; what happens?
<pitti> seb128: yes, ICQ and jabber
<seb128> pitti: dunno, gdb gaim crashes gdb when connecting to a server
<seb128> does the same on the xchat-gnome crasher I described
<pitti> well, I'm not connecting to a server *right now*, but I am connected
<seb128> it was doing the same on update-manager when it crashed on previous apt ABI change
<pitti> seb128: let me attach gdb, disconnect and connect again
<seb128> pitti: attaching a running gaim is fine
<pitti> *shrug* works just fine
<pitti> maybe an i386 specific problem?
<Chipzz> seb128: I just tried attaching to a running nautilus; it worked (although my edgy install hasn't been updated in 2 or 3 days, if that matters)
<seb128> pitti: disconnecting and reconnecting doesn't crash it
<seb128> pitti: gdb gaim, (gdb) run does when using autoconnect
* pitti tries that
<seb128> pitti: might be
<pitti> seb128: ah, I misinterpreted your 'is fine' as 'will reproduce the bug', not as 'will not cause the bug'
<seb128> ah
<seb128> doko made me rebuild gdb with -fno-stack-protector some time ago but it makes no difference
<seb128> the dapper gdb does a "thread_db_get_info: cannot get thread info: generic error" but doesn't crash
<pitti> seb128: ok, I did gdb /usr/bin/gaim, now gaim connected to both icq and jabber
<pitti> what now?
<seb128> nothing, on my box that hangs for some seconds and I get a "gdb crashed" apport dialog ;)
<pitti> I can ^C, bt, cont
<seb128> k, you don't get the issue then :/
<pitti> :-(
<seb128> I'll try to find some other way to get it
<pygi> pitti, poke? :)
* pitti jumps, he is very ticklish
<pygi> k3b burns cd's  with libburn :)
<pitti> cool!
<pitti> pygi: you modified k3b to use libburn?
<pygi> pitti, why should I?
<pitti> pygi: or did you write a fronted for libburn that looks like cdrecord?
<pygi> the libburn-on-cdrecord layer I was talking to you about
<ogra> an ugly mask ?
* ogra thinks of scary carnival masks
<pitti> pygi: I'm just wondering, because k3b does not depend on libburn-1
<pygi> ogra, will just make transition easier, for now
<pygi> pitti, well, ofcourse it doesn't :)
<ogra> pygi, i know ...
<pitti> pygi: btw, is the libburn that's currently in the archive (and didn't change since hoary) the same libburn you are working on? or a different project?
<seb128> pitti: 
<seb128> "Stacktrace:
<seb128>  (no debugging symbols found)
<seb128>  Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1"."
<seb128> for an evolution crasher
<pygi> pitti, depends on how you look at it... the old upstream stopped development two years ago (altought they claim differently), and they say it's still being developed...so I just took it, and started working on it
<seb128> with a almost 40M coredump 
<pygi> Derek (as of old upstream) called it fork, but whatever
<pitti> pygi: ah, ok
<seb128> pitti: sorry for flooding you with different issues ;)
<pygi> pitti, it'll probably replace the old version in debian archive once we release 0.2.1
<pitti> seb128: no problem, what's the issue here?
<seb128> pitti: how come that a 40M coredump gives no bt? :)
<seb128> "Stacktrace:
<seb128>  (no debugging symbols found)
<seb128>  Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
<seb128> ThreadStacktrace:
<seb128>  (no debugging symbols found)
<seb128>  Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1"."
<seb128> that's what the it has for it
<pitti> seb128: hm, strange
<seb128> -rw------- 1 seb128 seb128 40M 2006-08-15 18:47 /var/crash/_usr_bin_evolution-2.8.1000.crash
<pitti> seb128: this is a recent crash, i. e. with kernel 2.6.17-6?
<pitti> oh, apparently
<seb128> it happens 1 min ago
<seb128> my evo just crashed :p
<ne78> Does the the current version of edgy support GLX_EXT_texture_from_pixmap in its opengl library ?
<seb128> happened
<slomo> pygi: replace what? cdrecord?
<pygi> slomo, no, no, libburn :)
<pitti> seb128: can you please try 'apport-retrace -s /var/crash/_usr_bin_evolution-2.8.1000.crash'?
<seb128> pitti: I got the evolution crashed dialog twice, maybe they conflicted?
<pitti> twice? interesting, another bug
* pitti hates bugs
<slomo> pygi: ok :) they're talking about removing cdrecord currently btw and replacing it with something else...
<pygi> slomo, who? that might be interesting :)
<slomo> pygi: debian
<pygi> slomo, links, people, anything useful pls? :)
<seb128> pitti: could be nice if /var/log/apport.log could list the binary name of the crash too
<slomo> pygi: woo... one moment :)
<pitti> seb128: bzr head does that now
<seb128> pitti: what is "apport-retrace -s /var/crash/_usr_bin_evolution-2.8.1000.crash" supposed to do?
<pitti> seb128: 0.11 has quite a few fixes already; I just want to finish one (quite big) before I upload it
<seb128> /var/crash/_usr_bin_evolution-2.8.1000.crash has still no bt
<pitti> seb128: it takes the core from the report and calls gdb again
<slomo> pygi: hm, it's on debian-devel... but the ml-archives are outdated :(
<pygi> slomo, ok, so could you please quickly fill me in on current situation? :)
* pygi knows he bothers too much
<slomo> pygi: unfortunately not ;) i didn't read the complete thread... at least it is decided to remove joerg schilling's version from the archive but it was still discussed how to replace it
<pitti> seb128: I guess I'll write another tool that extracts the coredump from a report and saves it into a file for further examination
<pygi> slomo, point me at least to someone who might know?
* mvo is away for a bit
<seb128> pitti: yeah, I was just trying to do that by hand :p
<pitti> seb128: it's three lines of python, I can quickly tell you if you want
<seb128> pitti: yes please :)
<seb128> I just want to try to attach gdb to it by hand
<bddebian> Has libiec61883-dev not hit the archives yet?
<Keybuk> bddebian: hmm?
<Keybuk> I only just NEW'd it, I wouldn't expect it yet
<slomo> bddebian: binary NEW last time i looked
<bddebian> Hmm, I thought it got accepted yesterday, sorry
<seb128> bddebian: src != binary
<bddebian> Aye
<slomo> pygi:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109 <-- the corresponding bugreport with much discussion about the license problems...
<Ubugtu> Debian bug 377109 in cdrtools "cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license" [Serious,Open]  
<iwj> pitti: Yes, I mean about Breaks.
<slomo> pitti: shouldn't the stuff in /var/crash also contain backtraces? it doesn't for me... is there something special needed to get them?
<pygi> slomo, oh, joerg again!
<iwj> mvo: Burrows> No, I hadn't.  Not sure I want to ...
<pitti> slomo: it should, yes, if you have kernel 2.6.17-6
<pitti> slomo: do you?
<slomo> pitti: ok, reboot :)
<slomo> brb
* mvo shrugs and is away
<pygi> slomo, Eduard ^_^
<pygi> slomo, he's being the one very interested in libburn ^_^
<mdz> mvo: eek!  --fix-policy --install-recommends -> 4 upgraded, 126 newly installed, 11 to remove and 12 not upgraded.
<mdz> mvo: looks like we have some recommends cleanup to do :-)
<slomo> hm, i get exim4 and tetex as recommends somewhere =)
<pitti> mdz: welcome to the world of sane dependencies :/
<mdz> a lot of packages seem to recommend their documentation
<iwj> I think that's pretty much SOP in Debian ...
<ogra> mdz, debian plans to drop netkit-inetd it seems in favor of openbsd-inetd (universe currently) do we want to follow that path in edgy ? or postpone it ? 
<mdz> ogra: it would be nice, but surely you have enough to do already
<ogra> do you think thats more than a MiR ?
<ogra> according to vagrantc who looked closer the configs are 100% compatible 
<ogra> so there should be no issues in just replacing one with the other 
<Keybuk> ogra: I didn't think we shipped an inetd anymore?
<ogra> Keybuk, edubuntu does (we ship ltsp by default)
<Keybuk> probably not worth the effort?  in edgy+1 we should be able to use upstart for that
<ogra> and currently netkit-inetd is the only one we support in main
<tseng> pitti: apport stop is no problem, thanks alot!
<ogra> well, i doubt they will drop it before edgy release ... 
<mdz> ogra: apt-cache showpkg netkit-inetd
<ogra> argh, right 
<ogra> sorry then ... lets wait for debia to do that work for us :)
<ogra> *debian
<bddebian> heh
<mdz> ogra: and we have both netkit-inetd and xinetd in main
<ogra> oh
<ogra> i always thought xinetd was in universe ... i admit i never checked 
<mdz> lamont: surely postfix shouldn't recommend resolvconf, at most suggest it
<mdz> zul: xen-edgy still has status Unknown in launchpad; would you update that to an accurate value?
<zul> mdz: sure
<sabdfl> thom: those x60 issues resolved?
<thom> sabdfl: not rebooted the new kernel actually
<sabdfl> ok, if i'm back in a minute or two, all's well :-)
<thom> hrrm, that's not looking good
<thom> http://www.vnunet.com/vnunet/news/2162306/first-open-source-java-promised
<mc44> haha I see all the "fun" packages are up for maintainence at http://www.ubuntu.com/employment :)
<sabdfl> yeah baby - all clear thom
<bddebian> mc44: Heh, no kidding :-)
<thom> sabdfl: nifteh
<Keybuk> what's the X60 like as a laptop?
<thom> Keybuk: i have th X60s and it's awesome
<elmo> Keybuk: do not question the cult of the thinkpad.  just submit and buy one
<Keybuk> have they put touchpads on them yet?
<thom> typically hitting 5 hours battery life, dual core obviously
<thom> and happily no touchpad 
<Keybuk> elmo: heh, can't afford a new laptop -- got to save up yet
<Keybuk> just interested in what the "current" shiny models are
<mc44> bddebian: you should defnatly aply for te X maintainer job :p
<elmo> GRR
<elmo> ok, so gnome-screensaver has gotten ridiculously buggy for me in dapper recently
<mc44> wow that was some bad spelling
<elmo> was it part of update-the-world?
<ogra> elmo, yes, whats wrong ?
<elmo> yes :-(
<bddebian> mc44: Nah I'm stupid and they all hate me :-)
<elmo> ogra: every so often when I come back to my computer, the screen is just blank
<ogra> hmm
<elmo> ogra: key presses and/or mouse movement don't do anything
<mc44> bddebian: just like X! :)
<Keybuk> bddebian: sounds like you're emminently qualified then
<elmo> ogra: switching to console and killing gnome-screensaver gets me X back
<ogra> hrm
* bddebian feels the love
<ogra> ati/nvidia involved ? 
* mc44 hugs bddebian 
<Lure> pygi, slomo: regarding cdrecord: http://lwn.net/SubscriberLink/195167/d4d37493df901eec/
<thom> Keybuk: the X-series stuff looks considerably better than the nc2400 for sure
<elmo> ogra: nope, R250, free drivers
<bddebian> Hmm, they don't mention pay scale ;-)
<mc44> for X they better give you their first born as well
<thom> Keybuk: and the 4200 is still on P-M
<Keybuk> thom: I'm certainly disinclined to return to HP at the moment, this one just hasn't lasted as long as I'd've liked
<ogra> elmo, r250 is not an ati ?
<elmo> ogra: yes it is?
<Keybuk> given my Latitude LS is *still* going, and still entirely rigid ... and this one is barely holding together
<thom> nod
<elmo> ogra: but I'm not using the non-free crap, is what I mean
<ogra> right 
<Keybuk> the thingsI'm least happy about is how quickly the screen has failed
<Keybuk> and that the battery life is virtually zero
<Keybuk> and the latter appears to be a charger problem not a battery problem
<ogra> elmo, can you see the 3d hacks previews in the screensaver config window ? 
<ogra> like antinspect or antspotlight
<elmo> hmm, there is no select screensaver
<elmo> cute
<elmo> I supsect this is because I use to have 'flame' selected and SOMEONE decided that wasn't a shiny enough screensaver
<elmo> so I no longer have it installed
<ogra> huh ? it should still be there
<ogra> ouch, no ... not if you dont have xscreensaver-data-extras installed
<ogra> which is in universe
<elmo> ogra: I'll try installing that
<ogra> i can move it to the main package if i know you like it :) i doubt anybody will object :)
<Keybuk> . o O { I remember, once, that we claimed we'd never break an existing user's configuration }
<ogra> Keybuk, right, but thats an upstream issue i wasnt aware yet ... it'll need to fall back to something sane ...
<QuestionMarkCoun> does anybody know, how to add a udeb to debian-installer Packages file?
* Keybuk smacks ajmitch upside the head
<bddebian> Doh
<zul> Keybuk: heh...what did he do now?
<Keybuk> requested a sync for cdbs
<zul> hah
<ogra> doit :) and we'll have a lt of fun :)
<ogra> *lot
<KhanReaper> How do I create my own udeb file? Most importantly, how do I have the debian installer load it after disk-detect and before partman? How does d-i know when to do this?
<LaserJock> Keybuk: I believe the reason he the sync of cdbs was to get some new python policy stuff
<Keybuk> LaserJock: and what about the Ubuntu changes to cdbs?
<LaserJock> umm, "Not my problem" ;-)
<Keybuk> heh
<Keybuk> LaserJock: I'm so not believing you if you ever request a sync and claim "ok to override ubuntu changes" <g>
<LaserJock> doh
<LaserJock> just trying to manage divergence ;-)
<Keybuk> ;)
<Keybuk> right, food time, back for TB
<QuestionMarkCoun> I want do build my own keyring udebs and debs... so I have to put my public key in them, right?
<QuestionMarkCoun> and when I get debian-installer to load my keyring.udeb with my public key in it, d-i will be able to verify the packages, which where signed with my private key, right?
<slomo> Keybuk: could you please move libiec61883 to main? MIR was approved by pitti some seconds ago and latest gst-plugins-good upload will need it
<Keybuk> slomo: sure
<slomo> Keybuk: thanks :)
<thom> sabdfl: http://haecceity.clearairturbulence.org/articles/2006/08/15/apache-2-2-finally-hits-debian 
<Toadstool> Keybuk: argh, gnomebaker hates me :) sorry for the noise
<bluefoxicy> Reading package lists... Error!
<bluefoxicy> E: Dynamic MMap ran out of room
<bluefoxicy> uh oh.
<rkd> if i wanted to begin to contribute to ubuntu as a programmer, what languages/gui toolkits should i learn?
<bddebian> C, C++, Python, Gtk, Qt... :-)
<slomo> bluefoxicy: fixed in latest apt
<slomo> bluefoxicy: workaround: add APT::Cache-Limit "141943904"; to apt.conf
<zyga> sabdfl: sun is open sourcing java, maybe we will have sun's java on ppc after all :)
<tseng> zyga: haha.
<pygi> zyga, where you saw that? :)
* pygi is out of the flows since he started working on libburn
<zyga> pygi: flashes on ./ and digg, it was a semi joke though ;-)
<pygi> zyga, ah ^_^
<Keybuk> they _are_ actually opening sourcing java
<Keybuk> however it's a bit like "you're gonna die! ... in 60 years or so"
<zyga> Keybuk: IMO they aleady have, it's just becoming legal to compile & ship it without sun's blessing
<zyga> i'll be a good thing in the long run
<slomo> hm, the buildds seem to be broken
<bluefoxicy> slomo:  thanks.  I was pretty sure I couldn't apt-get upgrade that away :)
<sabdfl> thom: cool, congrats
<mdke> who has access to the packages in dapper-commercial?
<mdke> core-dev?
<LaserJock> mdke: I wouldn't think core-dev even as I would think it would be Canonical specific
<tseng> i think mvo is mostly the man behind it
<LaserJock> yeah, mvo seems to handle those things
<mdz> what is gqview doing in main?
<mdz> sfllaw: ping
<ajmitch> Keybuk: cdbs was meant to be UVF exception, which I missed from the description - I had merged (& even tested) it locally
<Keybuk> ajmitch: wrong team for that then
<pitti> ajmitch: oh, did yo merge cdbs for the python policy fix?
<Keybuk> you wanted ubuntu-release, not ubuntu-archive
<ajmitch> Keybuk: yes, force of habit, it seems
<ajmitch> pitti: yes
<pitti> \o/
* ajmitch will push changes to bzr branch 
<pitti> ajmitch: I was just about to ask you about that :)
<ajmitch> it makes it much easier to merge the changes :)
<sfllaw> mdz: Pong.
<mdke> LaserJock: hmm. I filed a really simple bug about realplayer being in the wrong menu in Gnome, and no one has responded, although I think I'd be a 30 second fix
<mdke> I wondered if I should be going "upstream", if real produced the package
#ubuntu-devel 2006-08-16
<ajmitch> Keybuk: sorry, I can't unsubsribe -archive from that bug, description has been changed now anyway
<ogra> is there any lsof equivalent in python ? 
<tsdgeos> hi
<tsdgeos> who packages poppler for ubuntu?
<LaserJock> mdke: I'd talk to mvo
<LaserJock> tsdgeos: check the Lauchpad page
<slomo> tsdgeos: i made the last changes
<tsdgeos> slomo: someone told me you have zlib usage enabled
<Keybuk> ajmitch: it's probably easier to just ask mdz directly than file a bug
<slomo> tsdgeos: yes... there already is a bug about it upstream that it breaks under certain conditions
<tsdgeos> upstream lol
<slomo> tsdgeos: if this is fixed soon i'll leave it, otherwise disable it again
<tsdgeos> so it now our fault that you enable things that should not be enabled?
<tsdgeos> we already know its broken
<slomo> tsdgeos: https://bugs.freedesktop.org/show_bug.cgi?id=7798
<tsdgeos> that's because it's disabled
<Ubugtu> Freedesktop bug 7798 in general "Crash in StreamPredictor::getChar" [Normal,New]  
<tsdgeos> don't need to show me my bugs ;-)
<slomo> tsdgeos: why is there no warning or something written somewhere else about it that it must not be enabled? if it is meant to be disabled i'll disable it again, no problem :)
<tsdgeos> probably because we suck as a project
<tsdgeos> https://bugs.freedesktop.org/show_bug.cgi?id=3948
<Ubugtu> Freedesktop bug 3948 in general "Pdf fails when using zlib based decoder instead of xpdf one" [Normal,New]  
<tsdgeos> is older and is the bug i opened to convice the others to disable it
<tsdgeos> hey Ubugtu is nice, how many bugzillas does he know?
<tsdgeos> slomo: what also happens is that Jeff wrote the zlib based code and noone else knows much about it and he is not much around lately so it's diffcult to touch the code
<ajmitch> mdz: ping (cdbs UVF)
<slomo> tsdgeos: ok, so what's the reason why nobody changes it to be disabled? :) i'll disable it now for the ubuntu package again
<tsdgeos> slomo: it is disabled
<tsdgeos> no?
<tsdgeos> well, you mean disabled completely?
<slomo> tsdgeos: that or at least add some warning to the configure flag or have a warning in the README
<tsdgeos> yeah
<tsdgeos> you're right, i'll add a coment to the configure --help
<slomo> tsdgeos: thanks :)
<tsdgeos>   --disable-zlib          Don't build against zlib. This is the default value
<tsdgeos>                           as the zlib code is know to fail in some cases.
<tsdgeos> better?
<slomo> yes
<tsdgeos> oki
<tsdgeos> don't you love open source?
* tsdgeos commits
<tsdgeos> bye
<Keybuk> I can't help but wonder ...
<Keybuk> what happens if you pass a file descriptor (using SCM_RIGHTS) to a process that wasn't expecting one
<Keybuk> is that a way of preventing a file from being deleted?
<zul> hey
<ajmitch> hello zul 
<zul> hey ajmitch 
<imbrandon> 'ello everyone
<bddebian> Howdy
<lamont> mdz: I could drop resolvconf down to suggests if you want...
<madduck> lamont: out of curiosity, why did you list it as recommends in the first place?
<lamont> madduck: "standard reason"
<madduck> lamont: which is? i am sorry, but i really don't know.
<lamont> ("it seemed like a good idea at the time", or more specifically, someone convinced me it was a good idea)
<madduck> :)
<lamont> but then, at the time, nothing installed even recommends automatically....
<madduck> uh. revise! :)
<lamont> so it was one of those "whatever, if it'll shut you up" kind of thought processes... hence the lack of care about changing it back to suggests
* lamont will deal with that in the next day or 2.
<madduck> makes perfect sense. glad that mdz pointed it out.
<bddebian> bluefoxicy: You around?
<bluefoxicy> hi
<bluefoxicy> did I do something useful while I wasn't paying attention?
<bddebian> bluefoxicy: Hi.  Do you have any additional input on Bug #466 ?  I'm not quite sure what to do with it
<Ubugtu> Malone bug 466 in snort "Snort 2.3 Inline Support" [Wishlist,Needs info]  https://launchpad.net/bugs/466
<bluefoxicy> bddebian:  Additional input:  Snort 2.6 is out.  Snort 2.4 was also out.  Why are we so far behind?  :)
<bluefoxicy> bddebian:  besides that I'm fairly sure --enable-inline still requires a library we don't have.
<bluefoxicy> bddebian:  do you know what version of snort is in latest debian unstable?
<crimsun> http://packages.qa.debian.org/s/snort.html
<bluefoxicy> 2.3.3
<bluefoxicy> same here.
<bluefoxicy> I would not worry too much about inline until somebody decides to care about snort again.
<bluefoxicy> At this point I would say that most people who care enough about it are going to wind up building their own anyway, since version 2.3 is deprecated and I think 2.4 is also deprecated.
<bluefoxicy> actually, I'm going to file a bug on that :|
<mdz> lamont: I do want
<mdz> lamont: I don't think it should be installed with postfix by default
<infinity> lamont: "nothing installed recommends by default at the time"?  Bah.  We, the dselect users, collectively spit at thee.
<Fujitsu> Hahhaa/
<bddebian> bluefoxicy: So is it OK if I reject 466?
<Keybuk> infinity: what, you and elmo?
<infinity> Keybuk: And kamion.
<infinity> Keybuk: And iwj.
<bluefoxicy> bddebian:  can you defer it for later?
<bddebian> infinity: Hehe
<infinity> Keybuk: And that may be the entire dselect community. :)
<bluefoxicy> bddebian:  or is it all or nothing
<bddebian> bluefoxicy: I can leave it but if 2.3 is dead why bother?
<bluefoxicy> bddebian: I could change the description to 2.6 later, or you could kill it and I can open a new bug if we ever get 2.6
<bddebian> bluefoxicy: Why don't you package 2.6? ;-)
<bluefoxicy> bddebian: honestly?  Too lazy to figure out what files to split into what packages.
<bluefoxicy> (i.e. too busy playing Solar Jetman on my freshly modded NES)
<bluefoxicy> bddebian:  I'll take a crack at it maybe but I don't want to wind up being the new maintainer.
<Kaleo> mjg59: /etc/acpi/suspend.d/05-acpi-lock.sh does not check if the lock is triggered; see bug 31935 and patch proposed
<Ubugtu> Malone bug 31935 in acpi-support "ThinkPad, Fn-F4 leads to double unsuspend" [Medium,Confirmed]  https://launchpad.net/bugs/31935
* Fujitsu hits notification-daemon a bit.
<bddebian> bluefoxicy: Do you have an upstream source for snort?
<bluefoxicy> bddebian: somewhere on snort.org?  Or what do you mean upstream source?  just the source code right/
<bluefoxicy> http://snort.org/dl/
<bddebian> Yeah, just found that but I was just reading the Debian about re-distribution issues with 2.4
<bluefoxicy> bddebian:  oh?  I thought the code was gpl
<bluefoxicy> the rules are non-distributable but that doesn't matter, 1) there's release-time GPL rules; 2) a registered feed can be used with oinkmaster legally, but the user has to get it himself.
<bddebian> Aye, that's what the submitter says
<bluefoxicy> there was some FUD that there were "no GPL rules" and that "oinkmaster no longer works" at one place.
<bddebian> bluefoxicy: Are rules distributed in the current package?
<Keybuk> memo-to-self ... printf ("%d" % getpid ()) ... does NOT work in C
<bluefoxicy> bddebian:  it seems we have snort-rules-default, which snort depends on (which I think it shouldn't because rules can come straight from oinkmaster anyway... and they will destroy the files installed by snort-rules-default)
<bddebian> Hmm, I don't know if I want to "break" any more packages in Universe :)
<bluefoxicy> Keybuk:  you need a comma, not a %.  :)  *not helpful, but friendly*
<bluefoxicy> bddebian:  srd is just the gpl rules
<bddebian> bluefoxicy: Ah
<bluefoxicy> and they get released at every snort release so the version is the same as snort
<bluefoxicy> and then there was Hobbsee
<bddebian> bluefoxicy: The debian maintainer claims that the number of rules would drop from 3100 to like 30
<bddebian> Heya Hobbsee
<Hobbsee> hi bddebian 
<bluefoxicy> bddebian:  I claim we don't care because 1) the current ruleset is outdated, and outdated IDS/antivirus rulesets are USELESS (this is reactive security, it's useless by default); 2) Oinkmaster works, and snort is in general an alert system and not a protection (inline is a protection), so the user has to "know what he's doing"
<bluefoxicy> lemme make sure oinkmaster has 2.6 stuff
<bluefoxicy> -CURRENT seems to be 2.6 yes.
<TheMuso> c
<TheMuso> c
<TheMuso> crap
<Hobbsee> Keybuk: w.r.t eric, the only change that we may need to keep is that it replaces eric3, which doesnt exist on ubuntu anyway.  what changes thinking about?
<Keybuk> dunno, didn't look
<Keybuk> the tool just tells me that there were changes, and you didn't say in the bug that it was ok to override them
<Hobbsee> Keybuk: right.  well i confirmed it, so i'm not sure why you're asking for another confirmation :P
<Hobbsee> thanks for the syncs, btw
<Hobbsee> gnomefreak didnt, i'll bug him
* Hobbsee only ack'd the thing
* Hobbsee reconfirms it, with the required sentence.
<Keybuk> you just confirmed that the non-ubuntu-dev member wasn't trying to h4x0r us ;)
<Hobbsee> Keybuk: heh.  true
<Hobbsee> Keybuk: i think we're all getting lazy with the numbers of syncs being requested.
<Hobbsee> Keybuk: how do you know that i'm not trying to h4x0r us?  you've never met me.
<Hobbsee> in person, at least :P
<crimsun> (you're in ubuntu-dev, that's moot)
<Hobbsee> crimsun: they still havent met me to find out if i'm an axe murderer or out to kill everything off.  maybe i can just talk my way thru getting -dev rights.
* Hobbsee likes playing devil's advocate at times :P
<ajmitch> Hobbsee: enough of us have met you to sign your key, at least
<Hobbsee> point.
<ajmitch> and the same could apply to any of us
<Hobbsee> also true
<ajmitch> fo all we know, I could be trying to bring down the archive via cdbs, for example
<Hobbsee> true
<Keybuk> cdbs manages that all on its own
<Hobbsee> then we discuss levels of paranoia, and sensible ones.
<Hobbsee> haha
<Keybuk> Hobbsee: it's all about trust levels ... you hung around enough doing good works that you were passed for general upload access to universe by the Technical Board
<Keybuk> obviously you could have just been good so you could be bad once you got access
<Keybuk> but we didn't think so
<zul> Hobbsee: and here i am thinking that you are an axe murderer
<Hobbsee> Keybuk: that's true.
<ajmitch> plus we know where you live
<Hobbsee> zul: you may well be right.
<zul> Hobbsee: you sure you arent lizzie borden
<Keybuk> there's something very strange about an actor from the original Stargate movie turning up in the series playing something else
* Hobbsee hasnt heard of lizzie borden.
<zul> Hobbsee: google lizzie borden
* Hobbsee might eat something first.
<Hobbsee> zul: and you're in luck - i couldnt carry my axe with my textbooks/laptop/etc home last night.  so you'll get a few days where i cant axe murder you
<Hobbsee> hum.  i lost my .ssh key.
* Hobbsee deletes that off LP
<zul> Hobbsee: you have to find me first..
<Hobbsee> zul: point.
<zul> and i dont give out my address to no stinking axe murderers
<Hobbsee> hah
<Hobbsee> yay, debtags/adept stuff didnt get fixed.
<jdub> hrm
<jdub> apparently, i'm not getting any love out of the ng-ified madwifi in -6
<foo> err, I am getting this; The following packages have unmet dependencies: mplayer-nogui: Depends: libggi2 (>= 1:2.0.5) but it is not installable .. broken packages. I am on ubuntu, any ideas? This sounds like an RPM issue. I left that scene ...
<rodarvus> foo, #ubuntu
* Hobbsee waves to rodarvus.  
<rodarvus> hi Hobbsee :)
<foo> rodarvus: Uh, I asked in there. No one knows. 
<Hobbsee> rodarvus: you didnt manage to break my X!  shame on you!
<ajmitch> hello rodarvus 
<Hobbsee> foo: edgy/dapper?
<rodarvus> hey ajmitch 
<foo> Hobbsee: Dapper, 6.06
* Hobbsee looks
<foo> Thanks
<Hobbsee> foo: can you paste your /etc/apt/sources.list to pastebin please?
<foo> Hobbsee: http://paste.ubuntu-nl.org/20729
<Hobbsee> thanks
<foo> thank you
<Hobbsee> foo: line 22 and 23 - you're missing a "universe" before each multiverse
<Hobbsee> fix that, update sources list, no more problem, i expect
* foo crosses fingers
* Hobbsee actually tests it now.
<Hobbsee> foo: yep, there's your problem.
<Hobbsee> installs fine
<foo> Ah, thank you. I was questioning my switch from debian to ubuntu, but this PEBKAC.
<Hobbsee> foo: yeah.  there seem to be a *lot* of PEBKAC errors w.r.t sources lists now.  they redid the page on sources lists so it couldnt just be copy and pasted anymore.
<foo> Hobbsee: lame
* Hobbsee glares at whoever did it.
<bluefoxicy> ubuntu-desktop wants to be removed if python-support is removed; promote python-support to main or fix whatever... hm.  o.o
<Hobbsee> sarah@sarah:~$ show python-support | grep main
<Hobbsee> Filename: pool/main/p/python-support/python-support_0.4.1_all.deb
<Hobbsee> Filename: pool/main/p/python-support/python-support_0.3.8_all.deb
<Hobbsee> bluefoxicy: ^
<Hobbsee> bluefoxicy: it's already there mate
<bluefoxicy> Hobbsee:  cool, mine must be outdated.
* bluefoxicy avoids sarah connor jokes.
* Hobbsee wouldnt understand them anyway.  but it's likely wise, or else i might turn into a psycopathic bitch, you never know.
<bluefoxicy> Sarah Connor IS a psychopathic bitch
<bluefoxicy> she's the woman from the Terminator series
<Hobbsee> ah right
<bluefoxicy> in the first movie she's attacked by a robot from the future; in the second, she's in a psycho ward for believing she got attacked by a robot from the future, and has trained herself to tear the shit out of any more robots from the future she meets.
<Hobbsee> right
<desrt> bluefoxicy; sounds like terminator
<bluefoxicy> <bluefoxicy> Sarah Connor IS a psychopathic bitch\nshe's the woman from the Terminator series
<desrt> you left out "in the third one she's dead of cancer"
<crimsun> (thanks for spoiling T3, as I hadn't seen it!)
<bddebian> Heh
<desrt> you find out about that pretty close to the start
<infinity> crimsun: I'm pretty sure that discussing the plot of a movie isn't considered a "spoiler" three years after its release. :P
<infinity> crimsun: (Granted that means it probably only ran in Australia a month ago, but for everyone else in the world, there's no excuse)
<bddebian> hah
<TheMuso> hehe
<crimsun> infinity: of course not :)
* Hobbsee hasnt seen any of the movies.  sad, really :P
<TheMuso> Hobbsee: I am not much of a movie buff either.
<TheMuso> Except for some sci-fi/fanticy stuff.
* jdub wonders if there's such a thing as 'backuppcfs' (fuse way of getting to backuppc 'real' files)
<dooglus> when I run evolution, it complains a lot about "too many open files".
<dooglus> is there some way to increase the limit?
<dooglus> it's 1024 at the moment
<Keybuk> quest upstart% ./client -p 4950 status ping
<Keybuk> ping (stop)
<Keybuk> currently waiting
<Keybuk> quest upstart% ./client -p 4950 start ping
<Keybuk> ping (start)
<Keybuk> currently starting, process active
<Keybuk> quest upstart% ./client -p 4950 status ping
<Keybuk> ping (start)
<Keybuk> currently running, process active
<Keybuk> quest upstart% ./client -p 4950 stop ping
<Keybuk> ping (stop)
<Keybuk> currently running, process killed
<Keybuk> quest upstart% ./client -p 4950 status ping
<Keybuk> ping (stop)
<Keybuk> currently waiting
<Keybuk> \o/
* Fujitsu ?
* Fujitsu shudders.
<Fujitsu> That looks somewhat like a Symantec Ghost client's status log.
<Keybuk> replace "ping" with, say, "apache"
<Amaranth> Keybuk: yay
<crimsun> I'm thinking that's part of Keybuk's init New World Order.
<infinity> Keybuk: But ping is a way cooler service.
<Fujitsu> I guess so.
<Fujitsu> infinity, of course. Everything needs that service.
<Keybuk> infinity: it was the best example of a long-running process that I could think of
<Fujitsu> Apache's not important :P
<infinity> Keybuk: /usr/bin/yes
<Hobbsee> crimsun: oh dear.  scary init New World Order
* Hobbsee hides from it.
<poningru> ooh
<Fujitsu> I like it...
<Fujitsu> And replacing cron'll be fun :)
<Hobbsee> Fujitsu: yeah, but if he gets unhappy, he might just decide to break everyone's systems cos he can.
<Fujitsu> True.
<Keybuk> fortunately I'm always happy
* Fujitsu looks suspiciously at Keybuk.
* Keybuk chews on more Dried Frog Pills
* infinity wonders if he's the only one who's ever done "yes | sed 's/y/n/'"
<poningru> heeh
<poningru> nes??
<Fujitsu> infinity, you are.,
<Hobbsee> Keybuk: dried frog pills? sounds like fun
<infinity> poningru: No... "yes" is a binary that just outputs "y\n" forever until killed.  Handy to feed to scripts that want affirmative input.  I've done the above to feed negative input.
* Fujitsu runs away from scary evil doctor Remnant.
<Keybuk> infinity: I've done s/y/something else/ before
<Keybuk> but not /n/
* infinity assume that this makes him insane.
<jdub> it's the happy you have to watch out for
* poningru hides
<poningru> infinity: ah did not know that
* Fujitsu drops to the floor and starts convulsing, remembering the melding of dpkg and yes that was Automatix.
<infinity> What I really want is /usr/bin/guess that will semi-randomly output 'y' or 'n' on a whim, or perhaps based on time of day or mood.
<Fujitsu> I like it.
<Keybuk> /usr/bin/maybe ?
<Fujitsu> yes with attitude.
<HrdwrBoB> Usage: yes [STRING] ...
<infinity> HrdwrBoB: Oh, don't ruin my fun.  I've never read the docs for yes.  Ever.
<HrdwrBoB> heh
<infinity> HrdwrBoB: Though I suppose we all learn something new every day.
<HrdwrBoB> though TBH, it's like find|grep
<HrdwrBoB> it's easier/quicker to find|grep
<HrdwrBoB> than to mangle the damn find options
<poningru> rofl
<Fujitsu> Do we, infinity? You sure?
<jdub> HrdwrBoB: or be told off by find for getting them the wrong way around...
<infinity> Fujitsu: Well, I like to pretend I do, I can't speak for everyone, I guess.
<Fujitsu> Haha.
<HrdwrBoB> jdub: yeah, because if you can detect something is not ordered correctly, the correct course of action is to tell the user he/she's an idiot
<Fujitsu> Of course.
<HrdwrBoB> (and then fail)
<infinity> It doesn't fail, it just carries on.
<jdub> i'm waiting for
<jdub> find: warning: WHATCHOOTALKIN'BOUTWILLIS?
<Fujitsu> I think we need to modify all CLI applications to simply output RTFM\n when bad syntax is provided.
<Hobbsee> haha
<Hobbsee> that could be fun
<Keybuk> jdub: indeed, I never knew that you'd previously been a woman
<bluefoxicy> what
* bluefoxicy eyes Keybuk and jdub
<bluefoxicy> infinity:  yes n
<bluefoxicy> infinity:  'yes bitch' works too
<imbrandon> bluefoxicy: look man we all adults and we all have heard "adult" language but from you IMHO its take to extreemes a bit, can you try to tone it down a notch over all here in -devel ? not trying to start a flame , infact no direct response at all would be ideal but if you fell the need you are welcome to PM me. Just my 0.2c
<mneptok> arr!
<pitti> Good morning
<ajmitch> morning pitti 
<Hobbsee> hi pitti 
<pitti> hey ajmitch 
<pitti> moin Hobbsee 
<tepsipakki> hi there. Who could rebuild debian-installer for edgy? It would just need to pick up new versions of the udebs
<tepsipakki> ..because libnss-dns-udeb is fixed now
<Hobbsee> tepsipakki: any core dev should be able to do that
<tepsipakki> hobbsee: you ain't one, yet?-)
<Hobbsee> tepsipakki: they denied me :P
<tepsipakki> hobbsee: damn! :)
<Hobbsee> tepsipakki: yeah, darn.  hasnt been *that* much of a problem, cos i've been concentrating on uni, and universe
<tepsipakki> It'll come, eventually ;)
<tepsipakki> ..membership, that is
<Hobbsee> tepsipakki: got membership.  in fact, i get to approve other people's membership :P  core is the issue
<tepsipakki> hobbsee: ah yes, I got confused.. by "membership" I meant core :)
<tepsipakki> heck, I'm a member as well
<Hobbsee> tepsipakki: yes, iirc you had memberhsip at the same time as me
<tepsipakki> yes :)
<doko> cprov-ZzZ, infinity: does soyuz have difficulties picking up new uploads?
<infinity> doko: What are you missing?
<doko> infinity: gcc-snapshot
<doko> infinity: java-gcj-compat on amd64
<infinity> doko: FTBFS.
<infinity> doko: gcc-snapshot is just taking a while cause it's a universe package, and way back in the give-back queue.
* infinity retries java-gcj-compat and amd64.
<Keybuk> quest upstart% ./client -p 26881 trigger startup ping (start) starting, process 29326 active
<Keybuk> script (start) starting, process none
<Keybuk> script (start) running, process 29327 active
<Keybuk> startup event triggered
<doko> thanks
<Keybuk> \o/
<Hobbsee> infinity: you're rebuilding an architecture?  :P
<doko> Keybuk: got my mail about zope, CC'ed to Fabio?
<Keybuk> doko: yeah, but I didn't understand it
<Keybuk> you seemed to answer your own question *shrug*
<doko> ?
<Keybuk> how can you use bzr for Debian and Ubuntu when they freeze at different times ...
<Keybuk> ... use two branches
<Keybuk> call one "debian" and the other "ubuntu"
<doko> Keybuk: right, can we do that using the LP repository? technically: yes, is it wanted?
<Keybuk> yes, yes
<Keybuk> the LP repository is just a place to mirror it
<Keybuk> or store it
<doko> ok, thanks
<pitti> mvo: ok, so I fixed the Depends: parsing bug after all, since it also breaks caudium
<mvo> pitti: ah, nice!
* mvo hugs pitti
<kagou> who do i ask for daily iso builds ?
* pitti hugs mvo back
<doko> infinity: gnat-4.1 needs manual intervention, will query you
<pitti> TheMuso: ok, pkg-create-dbgsym 0.11 uploaded; as soon as it's in the archive, caudium can be given-back
<infinity> doko: Mmkay.
<infinity> pitti: And by "given-back", you mean "removed from the archive", right?
* infinity has yet to find anyone, other than caudium hackers, who actually uses caudium.
<pitti> infinity: well, TheMuso just pointed me to http://librarian.launchpad.net/3915685/buildlog_ubuntu-edgy-i386.caudium_2%3A1.4.7-14.1_FAILEDTOBUILD.txt.gz
<pitti> infinity: personally I don't care for caudium itself :)
<pitti> shawarma: ping
<pitti> shawarma: can you please merge asterisk again to pick up the security fix?
<tepsipakki> so, could some core-dev rebuild debian-installer for edgy?
<infinity> tepsipakki: Kamion tends to prefer to be the only person who uploads d-i, but I suppose I could make an exception, given that he's off...
<tepsipakki> infinity: thanks :)
<tepsipakki> infinity: I think there's no harm in uploading it.. the current version is broken anyway
<infinity> tepsipakki: Yeah, I know.
<infinity> tepsipakki: I broke it.  I should know. :)
<infinity> tepsipakki: I was counting on Colin doing a d-i upload before he took off on his vacation, but that didn't happen, s'all.  *shrug*
<Kaleo> mvo: anacron have a quite old change pending; see bug 36816
<Ubugtu> Malone bug 36816 in anacron "Anacron doesn't work with suspend/hibernation" [High,Confirmed]  https://launchpad.net/bugs/36816
<Kaleo> -have+has
<tepsipakki> infinity: :) I'll look forward to testing it today.. maybe I'll finally reinstall my laptop with edgy, too
<mvo> Kaleo: from what I see this needs to be added to acpi-support
<mvo> Kaleo: hm, maybe not ...
<mdke> mvo: do you have access to fix bugs in dapper-commercial?
<TheMuso> I'm wondering if anybody would be able to help me fix up a problem I am having with a universe merge. More specifically, the package fails to build on powerpc, whereas it succeeds on i386.
<TheMuso> The build log is http://www.themuso.id.au/ubuntu/xawtv-powerpc-build.log
<TheMuso> I recently did a merge for this package, which was uploaded. The package failed to build on ia64 and powerpc, but build alright on the other arches.
<TheMuso> There is now an updated merge, and since this problem still persists in the new version, I would like to include a fix to make it build successfully on all arches before I upload the merge.
<mvo> mdke: I should have, yes
<pitti> TheMuso: hmm, error: 'PAGE_MASK' undeclared could be a difference in l-kernel-headers?
<mdke> mvo: the slight problem is that I don't think bug reports are going to the right place. Take "realplayer" for example... it is getting reported on realplayer, but I think that refers to the package in multiverse.  bug 52484 would be a 30 second fix, but I don't think people who can work on dapper-commercial have got bug mail about it
<Ubugtu> Malone bug 52484 in realplayer "Realplayer is in Graphics submenu, not Sound & Video." [Untriaged,Confirmed]  https://launchpad.net/bugs/52484
<TheMuso> pitti: Not sure. The build chroots showed the same problem when the original merge was uploaded.
<TheMuso> I hadn't thought of checking on ppc at the time, as it built on i386, and a MOTU confirmed that as well.
<mvo> mdke: I fixed this in my latest upload
<mvo> mdke: its not gone accepted yet though
<mdke> mvo: cool, good news. what do you think about the issue of reporting bugs on dapper-commercial packages?
<mvo> mdke: maybe we could add a tag for those? or create a group? I guess a group is the better choice
<mdke> mvo: but do the packages exist for bugs to be filed on distros/ubuntu?
<mdke> distros/ubuntu/+source/opera doesn't exist, nor does /realplay
<stub> Launchpad is going down in 15 mins for its regular code update. Estimated downtime is under 10 minutes.
<mvo> mdke: hm, right
<TheMuso> Ok, it seems that powerpc doesn't have/use asm/page.h. For powerpc, it is only a stub, so I need the help of someone who understands the differences between powerpc and i386 framebuffer as well as the headers to work this one out.
<mdke> mvo: I guess LP isn't used for dapper commercial?
<mdke> s/LP/soyuz
<mvo> mdke: correct
<mdke> ah
<jamesh> infinity: it's as if you've never read a UNIX text book.
<jamesh> infinity: gar.  was in scroll back with you talking about arguments to "yes"
<jamesh> ignore me
<pygi> pitti, poke again :)
<pitti> hey pygi 
<pygi> hey hey pitti 
<pygi> I would have questions again :)
<pygi> why would I get "/usr/include/libburn/0/libburn/" instead of normal "usr/include/libburn/libburn/"?
<pitti> pygi: I don't know, broken build system?
<pitti> pygi: also, i/libburn0/ might be more appropriate
<pitti> pygi: well, usually one API is enough at a time, so /usr/include/libburn/ sounds sufficient as well
<pygi> pitti, broken build system yes, I  just don't know which part ^_^
<pitti> pygi: some Makefile.am part probably, but I know little about autofoo
<pygi> pitti, ahm,oki, will explore
<pygi> pitti, you wanna test libburn by burning iso file?:)
<pitti> I'll probably do it that way, sure
<pygi> you can already do so, if you are willing
<pitti> pygi: not right now, but maybe this afternoon? maybe you can mail me a link and some short instructions
<pitti> ?
<pygi> pitti, sure
<pygi> thanks for the help
<pygi> pitti, ah, weird me :)
<pygi> libincludedir=$(includedir)/libburn/@BURN_MAJOR_VERSION@/libburn
<pitti> ah, there you go
<pygi> should I add minor version, or there is no need to have two api's at a time?
<pitti> pygi: well, as long as the package has a pkgconfig file which matches that path, it doesn't matter so much, but it is still ugly
<pygi> pkgconfigdir=$(libdir)/pkgconfig
<pitti> pygi: why not simply remove the slash, then packagers have the freedom to support multiple APIs at a time
<pygi> you mean leave it at "$(includedir)/libburn"?
<pitti> no, libincludedir=$(includedir)/libburn@BURN_MAJOR_VERSION@/libburn
<pitti> pygi: ^ if packages are supposed to #include <libburn/foo.h> instead of #include <foo.h>
<pygi> right, I'll try and see :)
<pitti> well, you have to decide that (or look what packages do which already use libburn)
<mvo> bug #56125
<Ubugtu> Malone bug 56125 in apt "doesnt look like a cow" [Unknown,Unconfirmed]  https://launchpad.net/bugs/56125
<ajmitch> mvo: looks critical
* pitti agrees
<mvo> ajmitch: yeah. I think we need to make it at lesat "important"
<pitti> mvo: the proposed one looks really better, though
<mvo> I would like to de-brand update-notifiers "ubuntu cd detected". any suggestions for a new (more neutral) string? "Distribution CD detected"? "Packages CD detected" "CD with packages detected"?
<seb128> mvo: I don't really like those but I've no better suggestion
<seb128> mvo: is one extra string to translate for Debian really an issue?
<seb128> mvo: because the CD is not a random distribution one, it's an Ubuntu one ...
<mvo> not a big issue for debian, but for any derrived distro
<mvo> that is true
<seb128> you consider it as a "big issue" for any derrived distro?
<mvo> not really a big issue
<mvo> more a "nice-to-have"
<seb128> ah k
<seb128> right
<seb128> thinking about it
<seb128> but I think it's not easy to not mention that's an Ubuntu CD
<madduck> Keybuk: i'd love to know what e.g. initctl does that daemontools does not, or what initctl is in the first place, what the plans are, etc.
<madduck> Keybuk: google doesn't really reveal much, so maybe you would update your blog?
<Keybuk> initctl is just a control client for upstart
<madduck> it looks fancy
<Keybuk> upstart is an init replacement somewhere between launchd and init-ng, turning left at smf
<madduck> so one more thing we'll be discussing in cambridge. :)
<Keybuk> it's written from the point of view of "this is what we NEED" rather than "this is what users think we need to make their machine boot 0.2s faster"
<madduck> .oO(do i sense irony?) :^>
<Keybuk> the quick summary is that it's an event-based init daemon
<Keybuk> tasks and services are started by events
<Keybuk> and themselves cause events to occur
<madduck> so dependencies are handled?
<Keybuk> events include "startup", "writable-filesystem", "default-route up", etc.
<madduck> note that i see the point of initscripts-ng not in being a faster bootup, but simply the proper support of dependencies
<Keybuk> the problem with tools to reorder the static initscripts is that they don't actually solve any new problems
<Keybuk> they just take a bit of problem away from the distribution maintainers
<madduck> yeah
<madduck> which, in Debian, is a good thing. since we're less about distribution-wide coordination than Ubuntu
<Keybuk> they still don't cope with "what happens if the user plugs a USB hard drisk in at *this* point"
<madduck> ah, so you'll replace udev on the way? ;)
<Keybuk> no reason to replace udev
<Keybuk> udev works perfectly
<Keybuk> there will be a udev rule to provide a source of events for upstart
<pitti> hi Keybuk 
<madduck> Keybuk: sounds reasonable? and this will be available to Debian too, I assume?
<Keybuk> of course
<madduck> sweet
<Keybuk> I vainly hope that everyone will adopt it <g>
<madduck> Keybuk: you'll have to convince me in person. :)
* Keybuk makes a note to pack the thumbscrews
* madduck makes a note to bring a dictionary with the word "convince" highlighted and enlarged
<Keybuk> :D
<jono> hey
<Keybuk> hey Mr O'Bacon!
<jono> heya Keybuk :)
<Zdra> hi, will glade3 be part of edgy ?
<jono> Zdra, I was gonna ask the same question :)
<Zdra> everybody speaks about glade3 those days
<seb128> Zdra: I've planned to look at it today
<seb128> Zdra: I've played with the 2.9n package some days ago
<seb128> I'm not sure if it's supposed to be good enough to replace glade-2
<seb128> or if it should be a separate package
<seb128> opinions on the topic are welcome ;)
<Zdra> seb128: is it easy to build the program for testing ?
<TheMuso> c
<Zdra> buildep are in edgy ?
<seb128> Zdra: you know how to build a package?
<seb128> Zdra: yep, just take the src package from debian experimental
<Zdra> ok
<seb128> Zdra: maybe dpkg -i the deb from debian work, I've not tried
<seb128> Zdra: rebuilding it works fine on edgy
<Zdra> seb128: thanks I'll try that this evening when i'm back at home
<seb128> Zdra: np, let we know how it works for you ;)
<TheMuso> c
<TheMuso> curse it
<ogra> pitti, i have a very intresting gnome-vfs effect here
<seb128> ogra: "gnome-vfs effect"?
<ogra> if i mount /tmp/.ogra2-ltspfs/cdrom (without bind mounting) it gets picked up as /cdrom by nautilus
<ogra> seb128, yes
<rodarvus> doko, is the removal of libssp0 on latest gcc upgrade expected? (i.e., is it ok for me to proceed with upgrade?)
<seb128> the question was to get a description of the "effect" :p
<ogra> seb128, i have to moint --bind every other device i mount to fake a disk drive for nautils/gnome-vfs but if i call the mountpoint "cdrom" *anywhere* in the filesystem it gets picked up by nautilus
<doko> rodarvus: yes, it's provided by glibc
<seb128> ogra: ah, funny ;)
<ogra> i spend half of my morning to find out why i always have 2 cdroms if i bind mount it additionally in /media/ogra/cdrom
<rodarvus> doko, thanks
<ogra> does anyone from the distro team have a usb floppy drive he could bring to the sprint ? 
<ogra> btw, do we have a hardware list like last time ? would be handy i think
<Keybuk> with air travel such as it is as the moment, do you think it's entirely wise for people to bring exotic hardware? :)
<ogra> hmm, right 
<ogra> i forgot about that ... 
<seb128> Keybuk: many people are not going to flight though
<seb128> s/flight/fly
<ogra> i think a good third is 
<seb128> which means most of people are not flying :p
<ogra> right :)
<infinity> Keybuk: You're expecting people to bring liquid hardware?
<ogra> seb128, is there a way to suppress the eject itme in nautilus context menu ? 
<ogra> *item
<seb128> ogra: patch the source package
<seb128> ogra: no runtime option no
<ogra> hmm, k
<Keybuk> infinity: my AMD64 is liquid cooled ;)
<Keybuk> and it's luminous green in colour
<thom> Keybuk: then you deserve everything you get ;-)
<infinity> Just like all that glowing green nitro-- wait...
<Keybuk> thom: *shrug* it's about a zillion times quieter than fans
<pitti> ogra: g-vfs> that must be special-cased
<thom> i more meant the luminous green, but anyway :-)
<ogra> pitti, ltspfs on /tmp/.ogra2-ltspfs/cdrom type fuse (rw,nosuid,nodev,user=ogra2)
<ogra> pitti, thats the only cdrom i have mounted :)
<ogra> but it shows fine in the drivelist and on the desktop
<ogra> i wonder if it starts to enumerate them or something ...
<ogra> its not unusual that you have 20 active users on a ltsp server
<StevenK> Keybuk: My AMD64 is a shuttle based system, and has one fan which is whisper quiet.
<thom> StevenK: i don't think you can fit SLI in a shuttle ;-)
<StevenK> Yes, I doubt it.
<Keybuk> StevenK: how long does it take to compile open office?
<StevenK> I've never tried, actually.
<Keybuk> it's a fun benchmark
<StevenK> I've re-encoded video, if that can give you an idea.
<thom> moz or OOo are probably the best benchmarks
<Keybuk> didn't actually time any of the re-encodings I was doing on here :-/
<Keybuk> it's about 5 minutes an episode I think
<Keybuk> maybe a bit more
<StevenK> My AMD64 is wimpy, it's 40 minutes to go from .avi to .vob
<zul> at least you have one
<StevenK> http://en.wikipedia.org/wiki/GeForce_7_Series#GeForce_7950_GX2
<StevenK> There we go, SLI in a shuttle. :-P
<tseng> StevenK: so you can run glxgears really really fast?
<StevenK> At the moment, my AMD64 doesn't have 3D.
<StevenK> This will change very soon.
<ajmitch> StevenK: you're not missing much
<Keybuk> tseng: it's great for blasting monsters into kibbles
* StevenK misses playing UT2k4.
* ajmitch gets tempted to start up doom 3
<tepsipakki> infinity: thanks for the d-i upload, it works like a charm now
<\sh> moins
<infinity> tepsipakki: Cheers,
<tepsipakki> ..only to fail with usplash
<tepsipakki> ->lp
<infinity> tepsipakki: usplash failing to configure?
<tepsipakki> yes
<infinity> tepsipakki: No proc/fd/whatever?
<tepsipakki> yep
<infinity> tepsipakki: I'll give you a shiny nickel to rewrite that line in the postinst to make it work. :)
<tepsipakki> hm, haven't seen it yet.. i guess it's ugly?-)
<infinity> Not particularly, I'm just not sure why it doesn't work on some arches, and does on others.
<infinity> Baffling to me.
<infinity> The powerpc buildd doesn't trip on it, amd64 and i386 do.
<infinity> Local tests can't reproduce it.
<tepsipakki> it's lookin for /dev/fd/62 on my T23
<infinity>           IFS="x," read x y garbage < <(echo "$RET")
<infinity> (Note that RET="640x480, random junk" at this point)
<infinity> End goal is to populate x=640, y=480
<Riddell> ogra, mvo: both your hwdb-client bzr archives are out of date compared to the edgy package
<tepsipakki> infinity: here xserver-xorg/config/display/modes is preseeded, shouldn't it skip the IFS part if db_get fails?
<infinity> tepsipakki: It should, so it's obviously not failing.  Why would it?
<infinity> tepsipakki: If it's pre-seeded, I'd expect it to, y'know, have a value.
<infinity> (hence, not fail)
<tepsipakki> so the input is wrong, no?
<infinity> Not sure I'm following you.
<infinity> The /dev/fd/62 thins is all becaus of that sketchy redirect.
<infinity> Probably just saner to rewrite it to split the string using something other than IFS and read.
<tepsipakki> here the preseeded value is "1920x1200, 1600x1200, 1400x1050, 1280x1024, 800x600, 640x480", because of the different monitors around
<infinity> Right, which should give you x=1920; y=1200
<infinity> Try it on the command line.  It'll work fine.
<tepsipakki> but it's wrong on this laptop =)
<infinity> (base)adconrad@cthulhu:~$ IFS="x," read x y garbage < <(echo "1920x1200, 1600x1200, 1400x1050, 1280x1024, 800x600, 640x480")
<pitti> iwj: do you see any efforts to port the firefox 1.5.0.5 vulnerabilities to 1.0.x on that mailing list?
<infinity> (base)adconrad@cthulhu:~$ echo $x
<infinity> 1920
<infinity> (base)adconrad@cthulhu:~$ echo $y
<infinity> 1200
<tepsipakki> you see, it's simpler to preseed that to the xserver, but upslash should use something more robust maybe?
<infinity> tepsipakki: The fact that it's wrong is the fault of your presseed, but that's not what's breaking the postinst.
<tepsipakki> why can't it have a template of it's own?
<mjg59> Where would it get the information from?
<tepsipakki> hmm
<tepsipakki> is xserver-xorg configured before?
<tepsipakki> before usplash..
<mjg59> It's not guaranteed to be
<infinity> mjg59: Oh, hey, you're not supposed to be here.
<mjg59> Yeah, I don't have time to do the flies today now
<infinity> mjg59: Come up with a better way to parse that without the redirect.  It's breaking in the livefs builds, which sucks.
<mjg59> Not supposed to be in the lab out of hours
<mjg59> Oh man
<mjg59> Why don't they have /proc mounted?
<infinity> They do.
<mjg59> Then why does it break?
<iwj> pitti: No, I'm afraid not.
<infinity> Might be missing /dev/fd/whatever, I guess.
<infinity> I haven't poked into it deeply.
<mjg59> I guess in that case it'll just have to be other tools
<infinity> But it breaks on debootstrapping any new chroot.
<mjg59> X debconf nightmare
<mjg59> infinity: Fancy hacking something up with awk?
<infinity> Boy, do I ever.
<tepsipakki> ok, I'll fix my preseed-templates to preseed values that are actually usable on the target computer :)
<sladen> infinity: aren't /dev/fd/* symlinks to /proc/self/fd/* ?
<infinity> sladen: Or something like that, yeah.
<infinity> sladen: No idea why it's not working in a fresh debootstrap, I haven't had the time to look at it.
<infinity> (nor why it works on powerpc, but not i386 and amd64)
<\sh> ok...I have a serious problem with our grub package and a smartarray p600 sas controller...grub installs itself onto the /dev/cciss/c0d0 device, but when it should start, it gives us "GRUB Hard Disk Error"....with sles9 grub-0.94 without any cciss raid patches it works
<\sh> (dapper that is)
<sladen> \sh: if linux doesn't know what it is, the BIOS emulation will probably provide a good enough device to boot off;  what is grub set to boot off?
<\sh> sladen: linux knows about the smartarray controller...grub is configured to be installed in MBR (/dev/cciss/c0d0 aka hd0), /boot partition is (/dev/cciss/c0d0p1 aka hd0,0)
<\sh> sladen: strange thing is, in our grub package we have cciss_raid patches, but in sles9 they don't have any patches, but this 0.94 version works 
<sladen> \sh: I don't understand, why would you have patches to grub.  grub (TTBOMK) would just be using the int 13 bios services
<sladen> \sh: if grub has any patches, is grub configured to know to be setup up differently such that is uses them?
<\sh> sladen: the patches are for (as far as I read) for recognizing the different notation of the partitions ... (/dev/cciss/c\d+d\d+p\d+ instead of /deV/[h,s] d[a-z] \d+ 
<infinity> mjg59: PS, that was wine-induced sarcasm.
<infinity> mjg59: What are the rules with abusing stdout in a debconf-using postinst?  Okay, as long as it's all redirected and captured, right?
<Russel> hiho, i hope this is the right channel
<mjg59> infinity: Should be
<Russel> i wanted to suggest, to the package, which provides cp, that it should include the patch which enables cp -g ("grafical" informations about transfer)
<Hobbsee> hey, if i revoke my old key, and create a new key, and add it to LP, what happens with regarding uploading packages?
<Hobbsee> (key = gpg key)
<fabbione> Hobbsee: you want to ask in LP for that.
<Hobbsee> fabbione: right.  hello, btw
<fabbione> but probably once you revoke the old one, the new one should be recognized
<fabbione> i dunno if LP performs checks on key signs and stuff like that
<tepsipakki> russel: file a wishlist bug against coreutils on launchpad.net
<fabbione> hello :)
<Hobbsee> fabbione: yeah, i could get it resigned fairly easily, that's not much of a problem
<fabbione> Hobbsee: but do you actually have any reason to revoke the old key?
<Russel> tepsipakki: thx
<Hobbsee> fabbione: sort of
<fabbione> Hobbsee: well if it is an urgent reason i suggest to revoke the old key immediatly (get your upload sponsored) and get the new one signed and uploaded to LP
<fabbione> urgent as in compromised or something
<Hobbsee> fabbione: it's not really urgent, as in, it's not exactly compromised.
<fabbione> did you upload the private key to a key server?
<Hobbsee> but it probably shouldnt stay the way it is
<Hobbsee> the new one?  i havent even revoked the old one yet
<fabbione> did you upload the private key to a key server? <- old key ;)
<Hobbsee> dont know :P  i followed the guide on it on the wiki
<fabbione> ok :)
<Hobbsee> fabbione: so what's the answer then?  :P
<fabbione> Hobbsee: if i was you and suspected comprimise, i would revoke my key immediatly
<fabbione> and figure out later how to get the new one in
<fabbione> remember that uploads with your key gives away root on all people machine installing your packages
<Hobbsee> fabbione: it's not suspected comprimise per se.  it's not something that should stay that way though
<fabbione> well if you are not more specific, i can't be more specific
<rodarvus> Hobbsee, adding a new gpg key to your launchpad account is quite painless
<Hobbsee> rodarvus: yes, but does it get recognised with the keyring?
<rodarvus> create you new gpg key, upload it to a keyserver, wait about 5-10 minutes for the key to be mirrored
<rodarvus> sign the CoC with your new key, upload the signed gpg key to launchpad
<Hobbsee> right, okay
<rodarvus> Hobbsee, yes, as soon as the new key is uploaded you can start using it
<StevenK> rodarvus: Does the key need to be signed, though?
<rodarvus> by someone else? no.
<StevenK> It usually helps, though.
<rodarvus> would be nice, though
<rodarvus> (I mean, it won't stop you from uploading)
<sladen> Russel: http://launchpad.net/distros/ubuntu/+source/coreutils/+filebug priority "Wishlist"
<pitti> hi sbalneav 
<sbalneav> Hey pitti!!
* Hobbsee waves to pitti and sbalneav 
<sbalneav> Gonna finish off on the mounter today, address your points.  We're already testing functionality, so that part's working.  Thanks for the help
<infinity> Ugh, we have no WoT requirements for the archive anymore?  This is obvious, if I think about it, but I never thought about it.
<StevenK> pitti: Can I ask about the rails security update? Or is rails universe and you don't really look after it.
<sbalneav> Morning Hobbsee 
<Hobbsee> infinity: WoT?
<infinity> Now uploading is tied to people (quite likely) weak passwords in LP...
<StevenK> Web of Trust
<infinity> Hobbsee: Web of Trust.
<Hobbsee> infinity: ahh...right...of course
* infinity is suddenly concerned that people's dinky 8-char LP passwords will be cracked, their PGP keys replaces, and upload slipped in.
<infinity> Yay, paranoia.
<Hobbsee> hah. yeah
<pitti> hi StevenK 
* StevenK waves to pitti.
<pitti> StevenK: there's a bug about it, but right, it's universe, so I don't feel a particular urge for it
<pitti> StevenK: and it's fixed in edgy
<StevenK> I could fix it for Dapper.
<pitti> StevenK: that would be nice
<StevenK> pitti: I'll apply the patch to 1.1.2, but what version should I set it to?
<pitti> StevenK: https://wiki.ubuntu.com/SecurityUpdateProcedures has some hints about it
<pitti> StevenK: short from: increase by 0.1 ubuntus
<tepsipakki> infinity: I see that you uploaded a new usplash but something is keeping it from the buildd?
<infinity> tepsipakki: Patience.
<infinity> tepsipakki: I uploaded it 30 mins ago, the publisher runs at :03
<tepsipakki> =)
<infinity> tepsipakki: The source will be in the archive after this publisher run, it'll build around :45, then get published on the next :03.. Ish.
* wasabi_ orders book.
<Hobbsee> yay.  launchpad is timing out over my number of packages uploaded.
<Hobbsee> maybe that's telling me something :P
<infinity> Hobbsee: It's telling you that you're l33t.
<tepsipakki> infinity: but.. that means testing it will have to wait for tomorrow :)
<infinity> Hobbsee: Or that your LP account has been compromised and someone else is uploading as you. :P
<StevenK> pitti: I'd suggest edgy is updated to 1.1.6-1
<infinity> tepsipakki: OH NOES! :)
<Hobbsee> infinity: or just that soyuz is busted again.
<Hobbsee> imbrandon: true that
<pitti> StevenK: it is already, I requested a sync some days ago
<infinity> Hobbsee: Shh.  soyuz has no bugs, only inconvenient features.
<StevenK> pitti: Ah
<Hobbsee> infinity: haha, right.
<Hobbsee> infinity: inconvenient, undocumented ones?
<infinity> Hobbsee: Oh, they're documented, right here in #-devel.
<thom> infinity: are you gonna get apache synced for edgy, btw?
<Hobbsee> hah
<thom> (1.3 i mean)
<infinity> thom: Yeahp.  I can do that right now, actually.  Thanks for the reminder.
<infinity> Of course, I'll miss this publisher run.  Oh well.
<thom> oh well; as long as it done pitti will love us anyway
* pitti spreads love
<pitti> hey thom!
<infinity> thom: Synced.
<infinity> Or, would be if I uploaded the sync..
<infinity> Done.
<infinity> More wine.
<StevenK> pitti: rails 1.1.2-1ubuntu0.1 is building locally.
<StevenK> pitti: Create a new bug for the rails debdiff?
<pitti> StevenK: let's create a dapper task for the existing one
<pitti> StevenK: bug 55811
<Ubugtu> Malone bug 55811 in rails "Mandatory security update" [Unknown,Fix released]  https://launchpad.net/bugs/55811
<pitti> StevenK: I already created a dapper task
<StevenK> Just add a comment with the debdiff?
<pitti> StevenK: yes, please
<pitti> StevenK: well, you can set dapper task to 'fix committed', too
<pitti> I'll apply/upload it afterwards
<StevenK> pitti: Both done.
<pitti> StevenK: ugh, huge patch; I assume you tested this? :)
<pitti> StevenK: thank you, I'll do the rest
* Hobbsee revokes her key on LP too.
<StevenK> pitti: I'm just checking if the patch applied
<pitti> StevenK: applied fine, package ready for upload
<StevenK> pitti: Ah, I'm just unsure if the patch is applied at build time.
<StevenK> In fact, I don't think it gets applied.
<StevenK> pitti: Lemme dig.
<pitti> StevenK: hm, dpatch without patches/00list?
<StevenK> I saw that.
<StevenK> It seemed a little strange.
<pitti> StevenK: heh, debian/rules patch does not do anything...
<pitti> haha
<pitti> StevenK: the patches must be applied inline, too
* pitti larts the maintainer
* StevenK looks heavenward.
<StevenK> So we have all of these wonderful patches that don't get applied.
<pitti> no, they are already applied
<pitti> StevenK: check lsdiff -z package.diff.gz :)
<pitti> just for some totally uncomprehensible reason the package does not have a 00list, but instead the maintainer applied them manually
<pitti> Go Adam Majer
<StevenK> Ewwwwwwwwwwwwwwwww
<StevenK> pitti: Nice catch.
<StevenK> pitti: Should I apply it and redo
* pitti applies manually
<StevenK> ?
<pitti> StevenK: don't worry, I know how to patch -p0 :0
<pitti> s/0$/)/
<StevenK> That's ... sickening
<pitti> StevenK: incidentially, the package of my last security update (krb5) is broken in exactly the same way
<StevenK> pitti: I'm reminded of a certain Joel Klecker quote.
<pitti> StevenK: can you please give this thing a light test? the patch is quite intrusive
<pitti> and there's no compiler to catch obvious bugs :)
<StevenK> pitti: Rebuilding to actually pick up the patch.
* StevenK whinges about Debian maintainers.
<infinity> StevenK: Of which you are one...
<pitti> they all suck, believe me :)
<StevenK> Heh
* pitti hides his Debian hat
<StevenK> Given some of the crap I've uploaded, I'm willing to admit I suck.
<StevenK> Linda 0.1.*, for starters.
<StevenK> pitti: Right, with the patch applied, it builds, installs and I can run the built-in server with a rails app.
<pitti> StevenK: cool
* pitti uploads then
<StevenK> pitti: Excellent, thanks.
<BenC> oh sweetness!!
<BenC> someone changed the comment font in lp to a monospace font
<pitti> yep, finally no unreadable program output any more
<ogra> pitti, do you think the cdrom stuff i see is a bug ? (i'd assume so) else i'll need to handle cdroms differently in the ltspmounter scripts
<pitti> ogra: I'm not sure why it is special-cased in gnome-vfs
<pitti> however, it shouldn't actually be necessary any more these days
<ogra> it really ony seems to take effect if the mountpoint is called cdrom ...
<pitti> maybe it's a forgotten workaround from the pre-hal time
<ogra> well, theer seem to be also some hardcoded things ... if i mount anything to /media/ogra/floppy, it will get a floppy icon
<Keybuk> oh, wow, my computer goes so much faster without a dozen "yes" processes run
<Riddell> ogra: http://kubuntu.org/~jriddell/bzr/hwdb/
<Riddell> ogra: http://kubuntu.org/~jriddell/hwdb/
<aigarius> jordi: hi, I uploaded the po files for sbackup
<jordi> aigarius: great!
<jordi> I'll process
<jordi> wow, you already have translations?
<jordi> aigarius: approved. It'll take some minutes to appear
<aigarius> thanks!
<aigarius> jordi: is it normal that the language show up with no messages at this point? will the messages show up a bit later?
<aigarius> oh, I see them now
<jordi> aigarius: yes, and ok :)
<bddebian> Howdy
<jordi> aigarius: btw, I spotted a typo in your screenshot
<aigarius> I wish I had a penny everytime I heard that :D
<aigarius> maybe it is worth making a translation to en? (from the original Engrish)
<jordi> aigarius: no, just fix the original in your next release
<jordi> aigarius: "I guess the path you entered does not exists. Do you want to add this wrong path?"
<jordi> I would s/I guess/It seems/
<aigarius> jordi: yes, I know, but I am thinking big :)
<aigarius> thanks, will fix it
<jordi> aigarius: en translations are imho a bad idea normally
<jordi> en_US/en_GB, etc are ok, but not en
<jordi> "Do not backup files bigger then"
<jordi> aigarius: ^  s/then/than
<aigarius> that is my common mistake :)
<jordi> and you should use "Do not backup files bigger then %d Mb" as just one string here
<aigarius> there is an entry box in between :(
<jordi> ugh
<jordi> that's bad
<aigarius> I should really read the Gnome HIG sometime :)
<sbalneav> pitti: ping
<pitti> sbalneav: pong
<bluefoxicy> ouch
<bluefoxicy> multi-gigabytes of swap in use
* bluefoxicy kills evolution
<HiddenWolf> bluefoxicy: how could you, evolution is such a sweet little email app. :)
<bluefoxicy> HiddenWolf:  it was eating over a gig of ram.
<bluefoxicy> I closed firefox, thunderbird, and gaim for an extra 300 megs total.  I don't see wtf is eating 500M of memory.
<HiddenWolf> top doesn't show?
<bluefoxicy> I closed the 5 biggest apps on top o.o
<icecrash> moin
<lfittl> ogra: ping
<cbx33> hi any python dbus gurus here?
#ubuntu-devel 2006-08-17
<wasabi_> hmm. odd. upgrade from breezy to dapper just failed. lvm2 borked.
<pygi> who is up for a little cd burning test?
<welshbyte> cd burning, you say?
<pygi> welshbyte, yes, yes :)
<pygi> with thing other then cdrecord ^_^
<welshbyte> sounds interesting, what needs doing?
<pygi> welshbyte, svn checkout, compiling, testing :)
<pygi> svn co http://libburn-svn.pykix.org/trunk libburn
<pygi> bootstrap
<pygi> ./configure
<pygi> make
<pygi> cd test
<pygi> ./burniso
<welshbyte> on edgy, i'm guessing?
<pygi> and you'll see usage :)
<pygi> welshbyte, you can try on dapper as well
<welshbyte> oh, i thought it might be related to fixing bug 54828
<Ubugtu> Malone bug 54828 in linux-source-2.6.17 "cdrecord fails to burn cd's" [Untriaged,Needs info]  https://launchpad.net/bugs/54828
<pygi> welshbyte, eh :)
<pygi> welshbyte, partly it might be tho :)
<pygi> there is a libburn-over-cdrecord layer which should fix this bug, hehe :)
<welshbyte> sorry, have to get on with some work... just made my ears perk because this project needs that bug fixed properly to work on edgy
<pygi> welshbyte, "this project" as in?
<pygi> plo _
<pygi> oki :)
<erkanoz07> how can i every start up mii-tool -F 10baseT-HD automatic
<beshy> looks like firefox2 has slipped past edgy release
<Kaleo> did anybody notice higher memory usage with today updates ?
<Kaleo> (I did)
<bddebian> Howdy
<lastnode> mdz, ping
<mdz> lastnode: yes?
<lastnode> hi, have you got a sec to hear me out? if not, i can ping you later
<lastnode> sorry mdz, that would not have triggered you. my bad.
<Hobbsee> hi all
<lastnode> hi Hobbsee 
<mdz> lastnode: I will read what you say to me and respond when I can
<lastnode> mdz, ok. sorry to bother you. it's like this - i've been writing a small support layer application for my local distro (www.taprobane.org). it's basically a bash script which uses dialog / Xdialog to gather user input. Based on that input, it attaches the relevant logs (for example, if the user says something is wrong with X, it will attach Xorg.log etc) and sends it via http to a php script on the server side. now, I've managed to get thi
<lastnode> s working with wordpress via a plugin, and will be implementing XML-RPC shortly, to get it working with Joomla and other CMSs. I was just thinking, the server side script could also easily be modified to talk with launchpad, and if so, would any of your guys be up for a small demo?
<mdz> lastnode: sure
<lastnode> mdz, this idea actually came to me while helping out in #ubuntu. there were so many users who were coming in with problems, and we kept asking them to cat this log, and that log. i just thought, wouldn't it be simpler if a bash script could attach logs automatically, based on what is wrong with the system
<lastnode> mdz, you find some sample output here, if you'd like a quick peek - http://plaintealiterati.org/poetry/suport-request-from-thebignoobnoobfactorycom/
<lastnode> (in that example, the script has attached dmesg/lspci output)
<mdz> dark gray on black is very hard to read
<lastnode> sorry, that's not really a site meant for testing, but my personal hosting went down, so i had to use it
<lastnode> my apologies
<mdz> I don't think there's an XML-RPC API for the support tracker at present, but I don't imagine it would be hard to add one
<lastnode> so theoretically, this could be plugged in to anything - forums, mailing lists, even irc
<mdz> launchpad-users@ would be a good place to discuss it
<mdz> I'm not sure that support requests can have attachments either, to be honest
<lastnode> mdz, it's not attached really
<lastnode> currently curl sends it in the body of the text
<lastnode> the logs, i mean
<lastnode> and since i use curl, it even returns a nice html reciept to the user, which can be opened in a browser
<lastnode> and since the server side is loosely coupled, one could easily write a plugin that pasted new requests in an irc channel via a bot
<lastnode> in any case, i shall take this to launchpad-users
<lastnode> thank you
<mdz> we have a concept for something similar for bugs, which uses infrastructure we already have for gathering system information from installed packages
<lastnode> mdz, yes ive seen the bug info gatherer
<lastnode> it's pretty sweet
* infinity wishes people would contribute more to packages populating /usr/share/bug more usefully instead of reinventing this wheel every three months.
<bddebian> heh
<lastnode> this is er, more for support than for bugs, actually
<lastnode> is there a similar application for support? because ill stop this right now then :s
<infinity> lastnode: Sure, but if good info-gathering scripts are in /usr/share/bug, you can have a support request tool that says "ahh, your problem is with X, I'll run the stuff from /usr/share/bug/xorg" and such.  Leverage a system that's already in place, for the benefit of all bug/support tools.
<mdz> no, but it would be a good idea to use the same hooks for collecting data
<infinity> lastnode: I have nothing against something that's geared toward generic support requests instead of bug reporting.  It's a good idea.
<lastnode> is /usr/share/bug ubuntu specific, or is a standard across most distros?
<infinity> lastnode: It's Debian-specific.
<infinity> lastnode: Came from the original "bug" bug report tool, then also got used by "reportbug", and others since.
<lastnode> i see. that would work, really. the live cd im devving for is debian based as well. 
<infinity> lastnode: The general idea is that packages ship scripts in there to help bug/reportbug decide what extra info to attach.
* lastnode looks through /usr/share/bug
<infinity> lastnode: Some packages have really good stuff there already, many don't have anything there at all.  Contributions either to Ubuntu or directly to Debian to beef up the contents of /usr/share/bug would make me a pretty happy camper.
<lastnode> infinity, im just looking through the .sh scripts, and im not getting it
<lastnode> oh, right
* lastnode gets it after looking through apt/scripts
<infinity> Note the use of "presubj" as well, which is cool.
<infinity> reportbug/presubj is a good one.
<lastnode> you know what would be cool? if i could find a way to check if the distro is deb based or not, and then running a script that is appropriate
<infinity> Basically, some quick "have you tried this?" FAQ answers to spit out to the user before they go to the trouble of submitting a support request or bug report and feeling like a fool when they get a 1-line canned response.
<infinity> lastnode: Well, I'm not sure if it's true for all derivatives, but in general, most Debian derivatives will have /etc/debian_version on the system.
<lastnode> infinity, presubj files seem to be just plain text?
<infinity> lastnode: Other than that, it's pretty hard to tell.  The exitence of /usr/bin/dpkg doesn't really mean anything, I have it on some Solaris machine which are clearly not Debian-based, etc.
<lastnode> infinity, i could just check for the existence of /usr/share/bug :)
<infinity> lastnode: Yeah, presubj is just plain text presented to the user before they go to the effort of filling out an embarassing bug report. :)
<infinity> Like, for instance:
<infinity> (base)adconrad@cthulhu:/usr/share/bug$ cat vim/vim.presubj 
<infinity> Please use "vim -u NONE -U NONE" to verify that the bug you want to report
<infinity> isn't caused by a configuration error.
<infinity> Handy tips to prevent a user from spending a week tearing their hair out over a broken config.
<infinity> That sort of thing.
<lastnode> infinity, yeah that makes sense
<lastnode> infinity, so you were saying populating /usr/share/bug
<infinity> Ideally.  It's one of those "good for the community" things. :)
<lastnode> that would be basically writing .sh scripts that first present a presubj and then attach the necessary logs for that app?
<infinity> If we make /usr/share/bug more useful, everyone benefits.  Debian and reportbug, Launchpad and whatever bug reporting tools we end up with, you and your support requesting tool, etc.
<infinity> The presubj stuff is just read directly by the reporting tool, not displayed by the script.
<infinity> The script in there is just a script that spits a bunch of stuff to stdout, which your tool collect.
<infinity> Whether it's logs, debconf info, /etc/shadow, the sky's the limit.
<lastnode> infinity, yeah it echoes. hmm, i guess the best way to go about this is to write an if {} routine within my current script
<infinity> (I recommend against submitting patches to packages to output /etc/shadow in their bug scripts, though..)
<lastnode> infinity, where would i submit presubjs or scripts i write, for review?
<infinity> lastnode: As Debian or Ubuntu bug reports on the packages they affect.
<lastnode> cool
<infinity> lastnode: I'd prefer to see them as Debian reports, so we all get them, though duplicate reports in Malone and debbugs never hurts, if Ubuntu wants to be faster about integrating the changes.
<lastnode> i guess debian makes more sense, right.. to go upstream direct?
<infinity> s/hurts/hurt/
<lastnode> infinity, so launchpad-users@ is where i should go with this idea?
<infinity> lastnode: Well, that's where you should go if you want to discuss an XML-RPC interface for the launchpad support tracker.
<infinity> lastnode: Not necessarily for the rest of the conversation we had. :)
<Robot101> a
<infinity> b
<bddebian> c
<lastnode> d?
* infinity notes that sequence jokes always get less funny as more people jump on.
<lastnode> infinity, so i guess ill work a little more on this before taking it there
<bddebian> infinity: :-)
<lastnode> yeah like me too, me three
<lastnode> :\
<infinity> Though, creepy that we all had the same length nick, so it all matched up...
<infinity> The things you notice when you're suffering from the lightheaded effect of no breakfast...
<lastnode> infinity, i guess one could also write a plugin to input the data directly in to the launchpad db
<lastnode> although that would have to be by someone who already knows the architecture etc
<infinity> lastnode: Well, the XML-RPC interface would essentially be that anyway. :)
<infinity> lastnode: (but with a thin layer between you and the DB, obviously)
<infinity> lastnode: We're not too likely to open up the postgresql port to the world to actually write TO it. ;)
<imbrandon> abstration layers are good anyhow so if the db changes the app dosent have to ;)
<lastnode> yeah, of course
<lastnode> i meant via a db object
<infinity> The launchpad DB never changes!
<imbrandon> ;)
* infinity looks for an incoming fist from sabdfl.
<lastnode> like for the prototype wordpress plugin i just used the wordpress inbuilt calls
<imbrandon> hahaha
<lastnode> so that's above the db
<imbrandon> lastnode: a wp plugin for LP ? i would be interested in that
<infinity> lastnode: It would probably just be a really simple XML-RPC call passing a massive struct.  So, it's pretty easy to do.
<lastnode> imbrandon, no, for my help support script
<lastnode> if anyone is interested in looking at, or hacking my script a little, please let me know
<lastnode> :)
<lastnode> im still looking for a way to see if X is running on a box
<infinity> lastnode: Ideally, simple things like "submit a support request" or "submit a bug report" in launchpad should be an extra 2 or 3 lines of code in your application, if it's being done right.  If it's not, talk to me and I'll sit down with brad again and make sure it is. ;)
<imbrandon> lastnode: give me a url i wouldent mind poking at it a bit, i'm always hackin on wp
<lastnode> i want to use dialog and Xdialog accordingly
<lastnode> imbrandon, http://plaintealiterati.org/poetry/suport-request-from-thebignoobnoobfactorycom/ is some example output
<lastnode> ill have the source up soon
<imbrandon> k
<lastnode> i gotta go shower and get ready, today is tutorial day at apachecon
<lastnode> :)
<infinity> lastnode: [ -n $DISPLAY ]  && echo "We're running from X"
<lastnode> I don't wanna miss Rich Bowen's intro to apache :)
<lastnode> infinity, is $DISPLAY a good check?
<infinity> lastnode: It's what everything else in the world uses.
<lastnode> in some instances, could it be populated without X running?
<infinity> lastnode: For safety, you can also fall-back if xdialog doesn't run.
<imbrandon> lastnode: nearly everything checks for $DISPLAY
<lastnode> infinity, ok, because i asked in #bash and i was told it was a bad way to check
<infinity> lastnode: If $DISPLAY is populated withou an active display, the user's setup is broken.
<lastnode> :\
<lastnode> infinity, i didnt get that
<lastnode> anyway brb
<lastnode> imbrandon, ill mail you the source in a hour. just leaving, ill be online from the venue though
<lastnode> infinity, thanks a lot for the help/advice. rest assured ill be bugging you again, soon :)
<imbrandon> k imbrandon@kubuntu.org or brandon@imbrandon.com  either one
<Seq> does anybody know offhand what the debhelper tool is that automatically generates entries in the debian/changelog file in a package?
<bddebian> dch
<infinity> dch is in devscripts, not debhelper.
<Seq> bah, no wonder i couldn't find it. i was reading the manpage for the debhelper stuff :p
<bddebian> Whoops, I didn't even read the debhelper part :-)
<infinity> Anyhow, yes, dch can be used interactively, or fully-automatically.
<infinity> And is the bestest thing EVAR.
<bddebian> heh
<infinity> I could be exaggerating a bit, of course.
<LaserJock> just a tiny bit
<Seq> not by a whole lot, it is rather handy
<infinity> Uh oh.
<infinity> I retract it all, then.
<infinity> The day I agree with someone from Ontario, I suspect the world will end.
<Seq> not exaggerating by a whole lot i mean
<Seq> what, are you from Alberta or something? :)
<infinity> Seq: Yes. :)
<infinity> (I live in Australia now, but old habits are hard to break)
<Seq> well then i'm glad we disagree.. 'cause... yeah...
<Hobbsee> infinity: you *do*?  where?
<infinity> Hobbsee: Melbourne.
<LaserJock> infinity: I didn't know you were from Alberta, I'm from Montana (down south) ;-)
<LaserJock> I grew up watching Alberta plates go down the Interstate ;-)
<infinity> LaserJock: I've driven through your state at ridiculous speeds on countless occasions.  Never actually stopped for more than the few minutes required to collect my speeding tickets. :P
<Hobbsee> infinity: ahh..
<imbrandon> lol @ infinity
<LaserJock> infinity: you weren't around when there was no speed limit?
<LaserJock> that was fun
<infinity> LaserJock: I got ticketed then too. :)
<infinity> LaserJock: Apparently, 240km/h isn't a "reasonable and safe speed".
<Hobbsee> hah
<Hobbsee> scary
<LaserJock> ah yes
<sbalneav_> Anyone in here a udev maven?  Working on floppy support for ltsp.
<imbrandon> LaserJock: yea the 90's were fun ;) seems the world went nuts 
<LaserJock> ah, another canuck arrives :-)
<sbalneav_> Hm, keybuk's the guy I need, but he's not here.
<sbalneav_> Lets see how badly this goes :)
<bddebian> Anyone in here know why I would be getting this: 
<bddebian> ./configure --prefix=/usr
<bddebian> make: execvp: ./configure: Permission denied
<bddebian> make: *** [configure]  Error 127
<infinity> chmod +x configure
<bddebian> Why the hell would it have changed?
<bddebian> Hmm
<Hobbsee> ran dh_stripperms thru it, or whatever it is?
<bddebian> It is 0755
<Hobbsee> dh_fixperms
<bluefoxicy> 755 is ok o.o hmm.
<bluefoxicy> bddebian:  read the first line of configure.
<bddebian> What #!/bin/sh?
<bluefoxicy> make sure it's not using a non-executable interpreter, make sure if it says /bin/sh that edgy hasn't broken /bin/sh if you're on edgy, etc.
<bluefoxicy> that should cover all the obvious stuff.
<bddebian> It built fine until I added two dpatch files
<bluefoxicy> on to the inobvious:  Is there a sun spot above your house?
<bluefoxicy> ah.  o.o  Contents of said patches may be relevant.  :)
<bddebian> It is calling dh_fixperms, hmm
<infinity> bddebian: Generally that's done in the binary target, long after you've run configure.
<infinity> bddebian: And shouldn't affect anything except the contents of debian/packagename or debian/tmp
<bddebian> Aye, I wouldn't think so but I'm at a loss at the moment
<infinity> bddebian: You can always do a quick dpkg-buildpackage -rfakeroot -uc -us -S, and toss the source package somewhere for extra eyes.
<infinity> bddebian: Debugging based on pure guesswork isn't all that simple.
<bddebian> True
<infinity> Ergh, what's Luke Yelavich's IRC nick again?
<infinity> TheMuso: Dude.  That brltty change is 12 kinds of wrong.
<infinity> TheMuso: The .so symlink belongs on the -dev package.  If gnome-orca is trying to dlopen the library incorrectly, it needs to be fixed, not placated.
<infinity> s/on the/in the/
<TheMuso> infinity: I mentioned that upstream, and they said thats the way they want to do it.
<infinity> "they"?
<TheMuso> Mind you, I might look at the source of orca and change that then.
<Hobbsee> bddebian: that'll do it.
<infinity> TheMuso: Which upstream for what?
<Hobbsee> bddebian: you can use --exclude ./configure or whatever the syntax is.  i had to do that for libdvdread
<infinity> TheMuso: Shipping the .so in the library is always, always, always wrong.  It just points to bugs in other packages.
<TheMuso> infinity: Fair enough.
<TheMuso> I can't understand why they dlopen the bloody thing in the first place
<infinity> TheMuso: *shrug*... Who knows.  But since we know the true path to the library, just fix the dlopen call to look for libbrlapi.so.1 or whatever.
<infinity> TheMuso: And since the previous upload's so shiny and new, don't worry about trying to do evil Replaces magic to move the file back again, just revert the change and pretend no one will notice. :)
<TheMuso> Yeah. Its kinda weird when the calling code is in a shared library, and also links against the damn library as well.
<TheMuso> infinity: Ok.
<TheMuso> luke@marin:~/Projects/Ubuntu_Development/edgy/sources/kwlan$ objdump -p  /usr/lib/python-support/gnome-orca/python2.4/orca/brlmodule.so | grep NEEDED NEEDED      libglib-2.0.so.0 NEEDED      libbrlapi.so.0.4 NEEDED      libc.so.6
<TheMuso> Thats some weird shit.
<infinity> Err, wait.  It links to it AND dlopens it?
* infinity boggles.
<TheMuso> My point exactly.
<infinity> There's some serious crack cloud surrounding that one.
<TheMuso> I'll bet my bottom dollar that the code could be built without linking against it, if they dlopen it.
<infinity> TheMuso: Anyhow, please revert the brltty change ASAP, before the window of "hey, the bug only existed for an hour, just --force-overwrite and leave me alone" gets too wide.
<infinity> TheMuso: Then you can worry about fixing the above crack. :)
<Hobbsee> hah
<TheMuso> infinity: Ok.
<Hobbsee> but dont you love all those bugs, and the accompanying dupes?
<infinity> Hobbsee: Yeah, but it's less hassle to put up with an hour of bug reports than a debian/control that's completely unreadable because you now have two packages replacing each other for no sane reason.
<Hobbsee> infinity: hah.  how'd that happen?
<infinity> Hobbsee: Moving a file from A to B, then back to A.
<Hobbsee> now that really *is* on some seriously weird crack.
<Hobbsee> infinity: ah yeah, that'll do it.
<infinity> TheMuso: BTW, who sponsored that upload for you?  I'd like to berate them for a bit. ;)
<TheMuso> infinity: crimsun 
<Hobbsee> *hopes it wasnt me*
<TheMuso> Hobbsee: Its a main package.
<infinity> Hobbsee: Couldn't have been you, it's in main.
<Hobbsee> lucky
<Hobbsee> ah well, one less thing i can be blamed for :P
<infinity> crimsun: You and me, bike racks, after school.
<TheMuso> infinity: If I give you an URL to a debdiff, mind reviewing/uploading, just to make sure I'm doing what you suggested correctly?
<bddebian> heh
<infinity> TheMuso: Of course.
<TheMuso> infinity: Thanks./
<crimsun> infinity: yes?
* Hobbsee was thinking of the packages of TheMuso's she'd uploaded
<infinity> crimsun: You sponsored an upload of a package that moved an .so symlink from a -dev package to a library package.  Please don't. ;)
<crimsun> sorry
<infinity> crimsun: Just keep in mind that sponsorship is a quality control thing.  Be even more anal with sponsored uploads than you are with your own.
<infinity> (Heck, I'm anal when sponsoring for Kamion and jbailey when they've not got their GPG keys handy, and I'm pretty sure they're both 12 times brighter than I am)
<desrt> i can reliably make dd on dapper segfault
<TheMuso> infinity: http://www.themuso.id.au/ubuntu/brltty_3.7.2-3.1ubuntu1_3.7.2-3.1ubuntu2.diff
<desrt> this seems odd.
<TheMuso> A nice learning exercise.
<infinity> desrt: Doing something particularly weird with it?
<desrt> no.  not even.
<desrt> totally mundane.
<desrt> echo string > somefile
<desrt> dd if=somefile
<desrt> [boom] 
<desrt> when it goes to do the speed calculation it dies
<desrt> happens on edgy too >:|
<desrt> ah.  known problem. bug 42264
<Ubugtu> Malone bug 42264 in rosetta "locale dependant segfault for dd" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/42264
<infinity> TheMuso: That upload looks fine.
<TheMuso> Ok thanks.
<infinity> TheMuso: Though the reverted change does hilight that the previous change wasn't quite right.
<infinity> TheMuso: In the previous change, when you moved a file from package A to package B, you should have made package B "Replaces: packageA (<= Last-Version-With-That-File)"
<infinity> TheMuso: The fact that you didn't have to revert such a change means you forgot to do it in the first place. :)
* TheMuso is confused
<infinity> When a file moves between packages, you need to ell dpkg about it.  That's what the "Replaces" field is for.
<infinity> If you don't give dpkg a hint, you just get overwrite errors on upgrade.
<desrt> oh wait.  i know this one.
<TheMuso> infinity: Righto.
<desrt> read this : https://launchpad.net/malone/bugs/22335
<Ubugtu> Malone bug 22335 in ubuntu-meta "gnome-screensaver conflicts with ubuntu-desktop" [Medium,Fix released]  
<infinity> TheMuso: Anyhow, the new one's uploaded, bugginess in the archive should only last another hour or two, and most of the world is asleep, so screw 'em.
<desrt> it has a fantastic rant on the subject of exactly how to use replaces, etc.
<TheMuso> infinity: Thanks heaps. Tis much appreciated. Another little tidbit to commit to memory. :)
<infinity> desrt: Scott can be a bit exciteable. :)
<desrt> TheMuso; the rant in that bug is worth reading
<infinity> (Even moreso than I)
<desrt> infinity; i learnt a lot from him there :)
<infinity> You could learn the same thing from carefully reading Debian Policy. :P
<TheMuso> desrt: Thanks for the reading material.
<desrt> it's less dry this way :)
* TheMuso goes to read
<infinity> I think we should just tattoo a few key sections (Package Relationships and Detailed Explanation of the Unpack/Configure Phases) on the chests of each new MOTU.
<desrt> mental note . o O (( do not become motu ))
* TheMuso bookmarks that bug. :)
* infinity . o O (( I really need to buy a tattoo gun ))
<jamesh> infinity: I suppose it should be tattooed in mirror image
<jamesh> so it is easier to read in the mirror
<infinity> jamesh: Or, they could just hang out together and read policy to each other.
<TheMuso> Now to patch gnome-orca to be a little less crackful.
<desrt> just tatoo it upside down
<desrt> so when you look down at your chest it's there
<jamesh> infinity: because motus often hang out together with their shirts off?
<infinity> jamesh: Well, we *are* known for our "friendly" community...
<TheMuso> Actually, I'd need something that would create a braille tattoo on my chest, as that would help me more. :)
<Hobbsee> TheMuso: pins and needles
<infinity> jamesh: Ironic, given that we work for the same company, live in the same city, and I don't think we've ever once been out for a drink, with or without shirts.
<infinity> jamesh: To be honest, I don't even recall what you look like. :)
<infinity> Yeah, I never leave the house.  NERD PRIDE.
<TheMuso> Hobbsee: Yeah thats a start.
<infinity> TheMuso: You could do braille scarification, I suppose, but it would be delicate work.  Or really big braille.
<Hobbsee> infinity: what colour's the sky today?  :P
<TheMuso> haha yeah
<infinity> Hobbsee: Greyish.
<Hobbsee> infinity: ah.  you have a window then.
<TheMuso> The sky is blue here.
<infinity> Yes. :)
<jamesh> infinity: I don't live in Melbourne
<jamesh> infinity: I'm over in Perth
<infinity> jamesh: Oh, I could have sworn you did.  See?  Out of touch.
<infinity> jamesh: Maybe it's because we share an ISP, or just because I'm generally retarded.
<Hobbsee> jamesh: come over to the nice side of australia :P
<desrt> Hobbsee; oh.  you live in perth too, then?
<Hobbsee> desrt: nope
<Hobbsee> sydney
<desrt> oh.  i thought you said the *nice* side
* Hobbsee wonders why no one has done a whois to check.
<Hobbsee> indeed, i did
<desrt> sydney's a bit dumpy
<desrt> well, i tell a lie
<Hobbsee> ah.  it's covered by the hostmask, that's right
<StevenK> Sydney is *not* dumpy
<desrt> sydney's a lot dumpy
* StevenK glares at desrt.
<jamesh> Hobbsee: I'm on the nice side of Australia
<jdub> infinity: probably because like all americans, you have no sense of geography.
* jdub WINS
<infinity> jdub: Die.
<Hobbsee> hahaha
<jdub> infinity: mexican.
<Hobbsee> jdub: is just terrible at figuring out accents.
<jamesh> If I wanted to live in a place like Sydney I'd just go to the US
* jdub spanks jamesh 
<desrt> jamesh; represent.
<HrdwrBoB> if I wanted to live in a place like sydney I'd live in sydney
<stub> If I wanted to live in a place like Sydney I'd get therapy.
<HrdwrBoB> but fortunately I live in melbourne :)
<jdub> HrdwrBoB: mexican.
<jdub> stub: mexican.
<stub> I'm further north than you dude!
<jamesh> stub is in the northern hemisphere
<jdub> stub: excuses!
<stub> jdub: mexican!
<pitti> Good morning
<Hobbsee> hi pitti 
* StevenK waves to pitti.
<pitti> Hey Hobbsee 
<pitti> moin StevenK 
<infinity> Riddell: Ping.
<pitti> hey seb128 
<seb128> hey pitti
<test> hello all
<test> I want to create a automated Installed, that installs all the packages that I have right now, if possible also the same configs
<test> I want to create a automated Installed, that installs all the packages that I have right now... like the ubuntu installer, but then only with the packages that I have...
<tepsipakki> test: see pkgsync
<pitti> hey pygi 
<pitti> pygi: burn, baby, burn! :)
<pitti> pygi: currently testing and writing a mail to you
<pitti> G0SUB: ping
<pygi> pitti, thanks, thanks :)
<pygi> pitti, I shall have the layer ready for you next week or something
<pygi> if I manage not to sleep until then:P
<pitti> ah, burning completed
<pygi> pitti, with actual content on the cd? :)
<pitti> yes, seems so :)
* pitti completes mail and answers
* pygi reads mail once he gets it
<pitti> sent
* infinity rejoices as all the livefses are installable for the first time in ages.
<infinity> \o/
<pygi> pitti, you can erase cd with one of the test apps (I can't remember name offhand now)
<pygi> pitti, for speed selection, you can ofcourse, just not in the test app
<pitti> pygi: yep, I did (test/blank)
<pygi> right, right :)
<pygi> I'll put in a speed selection perhaps, and optional blanking integrated ^_^
<pygi> but that is just for test, anyway ^_^
<pygi> talk to you later pitti, and thanks for testing :)
<pygi> many more testing to come :)
<pitti> pygi: \o/
<fabbione> morning guys
<pitti> hey fabbione
<infinity> ./win 12
<infinity> Ergh.
<pitti> infinity: you won?
<fabbione> hey pitti
<fabbione> hi infinity 
<fabbione> does anybody know what export alutInit symbol?
<fabbione> oh openal
<whip|lwe> jdub: so, novell gave away a customized X60 with suse artwork painted on the lid. The guy who won it is the Ubuntu hacks author. :D
<jdub> whip|lwe: ha ha
<jdub> whip|lwe: congrats on your righteous win
<whip|lwe> thx
<whip|lwe> we got tons of pics, will blog tomorrow ... nite.
* jdub was considering blogging "even god and big hair couldn't win novell the golden bowl"
<whip|lwe> haha
<jack_wyt_> fabbione: i custom a kubuntu livecd, but i don't know how to set user passwd in squashfs/usr/share/initramfs-tools/scripts/casper-bottom/10adduser
<whip|lwe> wait until bill blogs the x60 with ubuntu running on it.
<fabbione> jack_wyt: sorry i don't do livecd
<jack_wyt_> fabbione: do you know who knows
<fabbione> jack_wyt_: Kamion and Mithrandir
<jack_wyt_> fabbione: thx
<infinity> jack_wyt_: What's the poine of having a password on a livecd?
<infinity> s/poine/point/
<infinity> jack_wyt_: Anyhow, see the line in that script with "set passwd/user-password-crypted U6aMy0wojraho
<infinity> "
<lastnode> imbrandon, back :)
<infinity> jack_wyt_: That blank password hash was make with:  mkpasswd "" U6
<infinity> jack_wyt_: mkpasswd something else, based on the password you want, and you win.
<imbrandon> heya lastnode i was just heading off to sleep, could you just shoot me an email for now and we'll chat again later on irc ?
<imbrandon> lastnode: imbrandon at kubuntu.org ;)
<lastnode> imbrandon, sure, will do :)
<imbrandon> thanks bro, gnight infinity fabbione jdub and *
<tepsipakki> is there any way to force the order on /etc/iftab during install? my laptop has both a wired and wireless devices and they are assigned randomly (eth0/1)
<tepsipakki> and I need to install from wired net
<tepsipakki> I don't remember dapper suffering from this
<mvo> tepsipakki: you may want to use iftab
<mvo> tepsipakki: oh, sorry - answering too quickly
<tepsipakki> mvo: ;)
<tepsipakki> I'm not sure if it's possible to make sure udev probes the devices in right order.. maybe not
<heno> could someone give me some advice on making seed changes?
<heno> gnome-orca has now been approved for main (but does not yet appear as such in LP)
<pitti> heno: sure, what do you want to do?
<pitti> heno: ah, it needs to be put into the right seed, and actually promoted by an archive master
<heno> I want to move gnome-orca to 'desktop' and relegate gnopernicus to 'supported'
<pitti> heno: ok, I'll guide you through the process in /msg
<heno> pitti: thanks!
<Riddell> infinity: pong
<infinity> Riddell: All the extra binary packages in the hwdb-client you uploaded.  Is that stuff all getting seeded and heading to main, or should I pop it all in universe?
<cbx33> hi all, any python-dbus gurus here?
<Riddell> infinity: they should be in main please
<Riddell> they're in the seeds, although I'll need to update the meta-packages
<Riddell> cbx33: a bit
<cbx33> Riddell: can I trouble you for a little bit of your time
<infinity> Riddell: Kay, cool.
<cbx33> in here or pm?
<Riddell> cbx33: here is fine
<cbx33> in dbus, there are DATA messages and such
<cbx33> by using the python bindings are these handled for us...
<cbx33> are these messages lower level?
<infinity> Riddell: Accepted.
<Riddell> thanks infinity 
<cbx33> Riddell: in this spec https://wiki.ubuntu.com/StudentControlPanelCompletion there is a little bit about execution of programs in the users session
<cbx33> ogra talks about the exectution of an application steps
<cbx33> now I have hacked up some little dbus testing code, which has a server and client
<cbx33> and the client can use the serverse classes/methods
<cbx33> but I never once explicitly say send a DATA or OK message
<cbx33> is that because these are handled at a much lower level by the python-dbus bindings?
<pitti> heno: ^ infinity has ftp master powers, if you send him a flower, he might promote gnome-orca :)
<infinity> pitti: gnome-orca's broken until TheMuso fixes it to stop being retarded.
<infinity> pitti: So, if it's going into a desktop seed or something, I'd prefer to wait until it actually works.
<pitti> ok, thanks for the hint
<pitti> I don't commit it yet then
<StevenK> I couldn't see what makes orca better than gnopernicus.
<StevenK> Aside from the fact that gnopernicus sucks.
<infinity> StevenK: It reminds people of dolphins?
<infinity> Which makes them crave tuna...
* infinity goes to get a can of tuna from the cupboard.
<StevenK> infinity: You have been going off on weird tangents that last few days ...
<Riddell> cbx33: can't say I've heard of DATA or OK messages, are you sure they're not just used in that spec as the messages to be sent?
<infinity> StevenK: I think I've pretty much completely lost my mind, that's why. :)
<StevenK> But that reminds me, I need to hack gnome-speech to talk to IBMTTS.
<cbx33> Riddell: no
<cbx33> they are in the official dbus spec
<cbx33> hang on I'll dig it out
<heno> StevenK: Orca has super scripting powers that allows it to adapt to different applications
<StevenK> heno: I'll mention Orca to my boss and he'll say, "Ewww, Python" :-)
<cbx33> they are used for authentication
<cbx33> Riddell: http://dbus.freedesktop.org/doc/dbus-specification.html
<cbx33> Riddell: http://dbus.freedesktop.org/doc/dbus-specification.html
<cbx33> whoops...laggy here sorry
<pitti> StevenK: heh, our's would say 'yay python' instead :-P
* StevenK is one of two people in the office who like Python.
<infinity> StevenK: So, you're saying you have a mirror on your cubicle wall?
<StevenK> infinity: No cubicle for me.
<StevenK> No mirror, either.
<pitti> infinity: it's so nice to work with a friendly colleague :)
<Riddell> cbx33: then you know more than me I'm afraid
<Riddell> cbx33: but having used the python-dbus bindings I've never come across that so I guess it's all hidden
<cbx33> Riddell: heheh, do you use service files to authenticate?
<cbx33> as described in the spec?
* StevenK gets a fourth phone call in ten minutes and sighs.
<StevenK> Oh look, it's my mother for the third time.
<StevenK> Kamion: Hey, aren't you on holidays?
<Riddell> cbx33: nope.  I just used it for talking to HAL
<Riddell> cbx33: the python-dbus source package has plenty of examples
<cbx33> yes that's where I got mine from
<cbx33> ok last question, if I was going to talk to the session or system bus, to ask it to start an application in the users session
<cbx33> where would I look for documentation on that
<cbx33> I've been to the moon and back and found none
* cbx33 definitely owes Riddell a beer
<Riddell> cbx33: if your programme is running as the user then it wants to talk to the session bus to do user stuff
<cbx33> ok cool
<cbx33> how do I find docs on how to address that bus
<cbx33> and it's associated methods
<cbx33> I presume we call on the methods in the bus to do that kinda thing
<Riddell> cbx33: I don't think it has any methods unless you define some
<cbx33> so how do I put the mssage on the session bus 
<cbx33> and who/what do I address it to
<cbx33> this is where my brain melts
<Riddell> cbx33: you need a program that defines the methods and sits there waiting for them to be called, and does something when they are called
<Riddell> so that's your server programme
<Riddell> and you need a client program to do the calling
<cbx33> well that's what I thought but on conversation with ogra, I got the impression there was one sitting there already
<cbx33> that would pickup a message like exec /usr/bin/firefox
<cbx33> and run with it
<Riddell> cbx33: not as far as I know, unless he already has some LTSP magic sitting there
<cbx33> Riddell: http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services - i don;t know whether this is what he was thinking about
<cbx33> Riddell: no this is all new code
<Riddell> cbx33: interesting.  guess you need to add a file to /usr/share/dbus-1/services/
<jdub> mjg59: is p4-clockmod sucky?
<cbx33> Riddell: for each app they are likely to want to start
<pitti> seb128: yay, I identified the cdrecord upstream change which is responsible for the non-root breakage
<pitti> seb128: it works well now again
<Riddell> cbx33: looks like it
<mjg59> jdub: Yes
<Riddell> man dcop is so much easier to understand than dbus
<mjg59> jdub: It changes the duty cycle on the CPU but doesn't drop the core voltage, so you get a linear reduction in power consumption tied to a linear reduction in performance
<mjg59> jdub: And the latency is a killer on a lot of machines
<jdub> aha
<mjg59> Modern P4s support cpufreq-centrino
<mjg59> If it's got the est flag in /proc/cpuinfo
<jdub> just realised it works with the quebecistani craptop celeron m
<jdub> so toying with it
<cbx33> sorry Riddell 
<cbx33> thanks so much for your help
<cbx33> how would I address the users session dbus message bus?
<cbx33> hehehe?
<Riddell> bus = dbus.SessionBus()
<mjg59> jdub: Right. The difference is that dropping the voltage means you get an exponential decrease in power consumption for a linear decrease in performance
<jdub> Kamion: is there a good edgy install image you'd recommend atm?
<Riddell> jdub: Kamion's on holiday.  knot 1 is the last known good
<mjg59> jdub: It's worth having a play. You'll get a little extra battery life
<jdub> Riddell: ok, thanks
<cbx33> Riddell: how do I target specifically to a user
<Riddell> cbx33: generally you'd connect to the same user as you're running as
<ogra> cbx33, you dont, at all
<ogra> read the spec
<ogra> (we also talked about it last time we discussed it, thats what the list parameter is for)
<ogra> as i said last time, make the client app just listen on the system bus and make it wait for messages
<ogra> (just copy the necessary parts from willowng, change the namespace and list of messages, and put the listening part from there into a small listening app that runs in the users session)
<cbx33> ogra: sorry I missunderstood
<seb128> pitti: rock!
<pitti> seb128: I'll upload it soon, it just FTBFSes with pkg-create-dbgsym, thus I need to fix that first
<seb128> oki
<pitti> seb128: I tested pygi's libburn, btw, it works fine
<seb128> pitti: fine enough to replace cdrecord?
<pitti> seb128: I only tested blanking and ISO burning so far, no .wav and multitrack stuff
<pitti> probably not yet
<pitti> but it might get there soon /me hopes
<seb128> ok, probably something nice to follow anyway
<seb128> yeah, would be nice
<tseng> is core-dev able to accept packages from NEW now?
<tseng> don't want to just try it if there is some policy or its unfinished
* sabdfl looks for an incoming tbird-quickfile from infinity/qeury hlk
<sabdfl> erk
<tseng> morn sabdfl 
<simira> morning sabdfl 
<sabdfl> hey guys
<Keybuk> tseng: no, just ubunutu-archive
<Keybuk> what's stuck in NEW?
<tseng> Keybuk: ajmitch explained it
<tseng> Keybuk: apperantly coredev was given super powers to be able to mark milestones for bugs in the short term
<tseng> Keybuk: which is probably worth an announce "hey, you guys can do pretty much anything atm, but we trust you not to"
<Keybuk> I didn't realise there were super-powers involved for that
<Keybuk> that's just Ubuntu-Bugs no?
<tseng> < ajmitch> I think the only compromise for now was setting core-dev as  distrorelease drivers
* tseng goes to work, forgot he saw anything
<Keybuk> dunno, can't tell
<Keybuk> seems to have been set as the driver for edgy
<infinity> sabdfl: It was uploaded yesterday...
<infinity> sabdfl: (within an hour or so of talking to you about it)
* mvo grumbles about the hotshot profile
<Ranbee> hi, can someone tell me if Edgy will support my computer?
<lastnode> Ranbee, #ubuntu+1 for EdgyEft questions please :)
<Keybuk> Laser_away: err, edgy is #ubuntu-devel
<Ranbee> OK thanks for the help :)
<Keybuk> meh
<Keybuk> Ranbee: what's your computer
<Ranbee> can i pastebin lshw?
<Ranbee> it's the dell sata raid i'm having problems with
<Ranbee> fakeraid
<Keybuk> does it work on dapper?
<Ranbee> no,  it installs, but then can't see the HDDs
<Ranbee> if anyone wants to see lshw this is it http://pastebin.be/2050/
<Keybuk> have you tried booting with an edgy live cd?
<Ranbee> no, i'll try it
<Ranbee> thanks
<Ranbee> sorry, i didn't think of that
<lastnode> Keybuk, sorry, i thought this wasn't a support channel. my bad.
<Keybuk> it isn't
<Ranbee> i'd spent so much time with Dapper i hadn't thought of trying Edgy, thanks for the help. i love Ubuntu and i'm using suse atm. i'm going to get Edgy now. bye
<rodarvus> is it on purpose that edgy-changes@ now receives emails for accepted binary packages? (I apologize in advance if this has been discussed before I arrived)
<Keybuk> no, it's a bug
<Keybuk> afaik, it's only those things processed out of NEW
<camcorder> hi
<camcorder> does thunderbird in ubutu use gtktextview widgets and gtkspell?
<Keybuk> so, that's err, kinda interesting
<Keybuk> both apt and aptitude think my system is fine
<Keybuk> yet "firefox (silly version number) breaks firefix-themes-ubuntu"
<infinity> Keybuk: And you have a problem with this?
<Keybuk> infinity: paint me silly, but I don't think dpkg and apt should disagree on the health of one's system
<infinity> apt doesn't support Breaks.
<infinity> It just passes --auto-deconfigure, so dpkg deconfigured firefox-themes-ubuntu, but didn't remove it.
<infinity> Suboptimal, IMO.
<infinity> At least, I'm guessing that's what's happened on your system.
<infinity> On mine, firefox-themes-ubuntu is gone, cause I forcefully removed it, so I can't say.
<Keybuk> yeah, and when apt does it's --configure -a at the end, you get the error because it tries to configure it
<infinity> Yeah, I'm thinking the Breaks implementation is less than perfect right now.
<Keybuk> I'm sure it's fine if you only use dselect ;)
<jdub> still can't remove dselect
* jdub waits for edgy+1
<Keybuk> remove-package.py -m '(keybuk) CLM' -b dselect
<infinity> Talk of removing dselect makes me sad.
<Keybuk> great, now there's a thunderstorm and my dog is trying to become one with my leg
<simira> hurrah...
<simira> it's supposed to be a thunderstorm here as well, but I can't see it
<Keybuk> ya know, I often think that thunderstorms were what first separated the geeks from everyone else back in the times of the caveman
<Keybuk> while the rest of the tribe were cowering in the back of the gaves, the proto-geeks were outside going "ooh, pretty lights"
<lifeless> according to a recent article, the folk doing cave art were pubescent male teenagers ...
<lifeless> cave paintings are graffiti
<mjg59> Tch.
<mjg59> I need to go out and get passport photos today.
<zul> fun fun
<Keybuk> lifeless: so the one with the hunters chasing the wildebeest is just a tag?
<lifeless> Keybuk: yep. sex and violence is all
<icecrash> hi
<tseng> Riddell: is it possible that kword could use libwv1?
<jdub> odd to boot a machine and get "/dev/hda1 has gone 1375 days without being checked, check forced."
<pitti> jdub: holy sh**, 4 years uptime?
<Keybuk> how long ago was it last checked?
<jdub> pitti: four years closet time, apparently ;-)
<lifeless> 1375 days
* jdub wonders which gnome it's running and stuff
<jdub> it has some blue glassy gnome logo graphical lilo monstrosity
<StevenK> jdub: Sounds like Fedora
<jdub> nah, it was custom
<StevenK> Ew, even worse.
<jdub> all my fault
<zul> tragic
<seb128> Keybuk: could you get glade-3 out of NEW? ;)
<Keybuk> seb128: no
<seb128> thank you :)
<Keybuk> because it's already in accepted ;)
<seb128> ah, cool
<seb128> thanks ;)
<Keybuk> NEW isn't a FIFO, it's more of a FISO
<Keybuk> (Shiniest out)
<seb128> hehe
<seb128> that's also why I pinged, looks like people would like to play with it ;)
* pitti hopes that seb128 will file more apport-gtk bug reports, so that he can try out glade 3
<Keybuk> (actually it's more that fundamentally it was from a known source and a new version of something already in the archive -- much easier to check)
<seb128> pitti: sure :)
<Keybuk> pitti: it popped up for valgrind again :-/
* pitti wonders whether valgrind actually installs a SIGSEGV handler
<Riddell> tseng: I doubt it, you'd have to compile it and see
<Riddell> tseng: seems like a downgrade though
<mvo> Keybuk: apt does not yet know about breaks at all
<mvo> Keybuk: and to make matters worse, apt does not run dpkg --configure -a, but dpkg --configure $list_of_stuff_it_thinks_that_needs_configuring
<pitti> Keybuk: added to TODO, will look at it
<zul> anyone seen Ben around?
<Hobbsee> zul: [23:20]  [Whois]  BenC has been idle for 3 hours, 29 minutes, and 25 seconds.  he might be here
<hunger> Hmmm... is libssp supposed to be a part of gcc now or not?
<pitti> hunger: it's actually integrated into libc 2.4
<hunger> pitti: Ah, great, so it should be removed.
<hunger> pitti: I am wondering as I see that lib popping in and out of my system during the last couple of upgrades:-)
<mwh_> how can I disable/delete a launchpad account? .. I know I'm asking a wrong place but are there a channel a bit more apropriate?
<Hobbsee> mwh_: try #launchpad
<mwh_> ah thanks
<desrt> is the plan to continue with the current madwifi/madwifi-ng setup for edgy?
<mjg59> No
<Hobbsee> hi mjg59 
<desrt> launchpad has some seriously demons inside of it
<Keybuk> desrt: edgy already only ships madwifi-ng
<desrt> *serious
<desrt> it just *butchered* this bug that i tried to comment on
<desrt> & it keeps trying to assign it to openoffice.org
<desrt> i 'reject' the task and it actually confirms it instead
<desrt> Keybuk; so it does.  nice.
<bddebian> Howdy
<sbalneav> Hey bddebian 
<sbalneav> Keybuk: can I pick your mighty, mighty udev brain for a sec?
<matthewrevell> Hi - I'm working on the next Ubuntu Weekly News. Are there any new apps in Edgy, this week, that you think should be mentioned?
<seb128> glade-3 :)
<matthewrevell> seb128: Cheers
<bddebian> mythtv when someone syncs it for me.. *hint, hint* ;-P
<matthewrevell> bddebian: Is that likely to go in this week?
<Keybuk> Hobbsee: ping?
<Keybuk> sbalneav: sure, what's up?
<Hobbsee> Keybuk: heya, what's up?
<Hobbsee> oh dear, if Keybuk's pinging me, something must be wrong...
<bddebian> matthewrevell: Not likely :-(
<Keybuk> Hobbsee: digikam-doc, digikamplugins-doc
<matthewrevell> bddebian: ah, okay. Thanks
<Keybuk> I can't find any licence in the tarballs
<Keybuk> I may be looking in the wrong place
<sbalneav> Keybuk: I've got a rule for a floppy link i.e. KERNEL=="fd*", SYMLINK+="floppy"
<Keybuk> sbalneav: I'd change that to fd[0-9] * for a start; there are other devices that begin "fd", but carry on
<sbalneav> I'd like to fire a RUN of a script, but I want to use the symlink, not the kernel, how'd I do that?
<sbalneav> ah, sure.
<sbalneav> good point.
<Hobbsee> Keybuk: right....i'll have a look here for them.
<Keybuk> sbalneav: which symlink?  there may be several
<Hobbsee> Keybuk: they came from debian, so...
<Keybuk> of course, the obvious answer is  RUN+="/path/to/script /dev/floppy" ;)
<sbalneav> Keybuk: On the simlink line?
<Keybuk> Hobbsee: aye, the docs contain an &underFDL; I guess that's sufficient *shrug*
<Keybuk> sbalneav: sure
<sbalneav> Ah!
<sbalneav> Brilliant.
<Keybuk> though if it were going in an Ubuntu package, it should be later
<sbalneav> thanks.
<sbalneav> ok, yes it will be, so how would I do that, then? :)
<Hobbsee> Keybuk: this one?  http://packages.debian.org/changelogs/pool/main/d/digikam-doc/digikam-doc_0.8.2-1/digikam-doc.copyright
<Keybuk> sbalneav: on Ubuntu, the symlink should be created by 65-$package.rules
<Keybuk> and the script should be run by 85-$package.rules
<Keybuk> so something like
<Keybuk> KERNEL=="foo[0-9] *", SYMLINK+="wibble"
<Keybuk> in the first, and
<Keybuk> KERNEL=="foo[0-9] *", RUN+="/path/to/script /dev/wibble"
<Keybuk> in the second
<Keybuk> (though nothing should be making a /dev/floppy symlink for other reasons)
<Hobbsee> Keybuk: perhaps more worrying is that i cant seem to find digikamplugins-doc on p.d.o
<Keybuk> image plugins
<sbalneav> Keybuk: Thanks!
<Keybuk> Hobbsee: I'm gonna have to reject them I'm afraid; there really is no Licence in this package
<Keybuk> so we have no permission to distribute afaict
<Hobbsee> Keybuk: okay, i'll bug allee/toma about it.
* Hobbsee wonders how they got it into debian
<Keybuk> yeah, all they need to do is ship one in a file at the top level, and I'd be happy
<Keybuk> it's just that right now it's "here's a bunch of code, let's pretend it's under the GFDL without actually saying so"
<Hobbsee> i thought you were always happy :P
<Hobbsee> yeah, true
<Keybuk> or, more pointedly, including any terms saying what they mean by "GFDL"
<Keybuk> for all we know, it's the "Go For Desert Licence"
<Hobbsee> haha
<Hobbsee> true that
<bddebian> hehe
<bddebian>  Google For Dummies License
<Lure> Firefox 2.0 delayed until Oct 24 - what does this mean for Edgy? http://www.theregister.co.uk/2006/08/17/firefox_delayed/
<bddebian> Hmm, I've killed the conversatation again.. :'-(
<Hobbsee> Keybuk: just bugged toma about it, he's the upstream person, it seems
<Hobbsee> or at least for debian
<Keybuk> bugs have been filed in Debian
<Hobbsee> Keybuk: ah.  it's in the docs.  still a dodgy excuse for a licence file.
<Keybuk> it's not in the docs
<Keybuk> I grepped
<Hobbsee> (00:54:19)  Toma: http://docs.kde.org/stable/en/extragear-graphics/digikam/ln-id2486821.html 
<Hobbsee> (00:54:35)  Toma: it is in the handbook themselfes
<Hobbsee> Keybuk: those ones?
<seb128> Lure: it means that edgy will likely not get it probably
<Keybuk> that paragraph does not appear anywhere in this source
<Hobbsee> Keybuk: i'm aware of that.  i've whinged, he'll look at it tonight.
<Hobbsee> seb128: dont we already have the alpha in there?  what happens then?
<Keybuk> lp_archive@drescher:/tmp/keybuk/digikam-doc-0.8.2$ find doc | xargs grep "Permission is"
<Keybuk> lp_archive@drescher:/tmp/keybuk/digikam-doc-0.8.2$
<Keybuk> the source MUST contain not only an explicit mention of a licence, but the actual licence text
<Hobbsee> Keybuk: true that.  i'm not arguing with you :)
<seb128> Hobbsee: no clue
<Keybuk> I've mentioned it to the Debian FTP Masters as well
<seb128> Hobbsee: need to be discussed probably
<Keybuk> it looks like there was a licence file in an earlier version (how it got through Debian NEW)
<Keybuk> but it's been dropped
<Keybuk> probably an upstream oversight
<Hobbsee> ah
<seb128> Hobbsee: either firefox 2.0 is on time and consider good enough to be shipped a few days before edgy, or a beta is shipped or firefox is reverted to 1.5
<Hobbsee> seb128: right, yep
<jdub> seb128: or, there is also the possibility of the day of judgement, at which point the version of firefox becomes relatively uninteresting (depending, of course, on whether the use of free software scores any god points or not)
<sbalneav> jdub: Ah! another fellow I was looking for.
<seb128> jdub: that too :p
<jdub> seb128: should probably factor this into future release plans
<jdub> hey sbalneav 
<sbalneav> jdub: is there a place in gnome where we can call a script or a function that gets executed before gnome-session ends?
<jdub> sbalneav: hrm, during logout? not sure. good question.
<sbalneav> kind of like .logout, but for gnome-session?
<matthewrevell>  /leave
<jdub> seb128: ^ ?
<Keybuk> slomo: ping
<seb128> jdub, sbalneav: I don't think so
<sbalneav> seb128: Hum :(
<Hobbsee> Keybuk: you've finally decided there are enough syncs to do a whole lot of them again, hey?
<Keybuk> Hobbsee: not doing syncs
<Keybuk> well, not currently
<Hobbsee> Keybuk: eh.  s/syncs/new stuff/
<Keybuk> there's not many atm outstanding anyway, I do those a few times a week
<Hobbsee> true
* Hobbsee filed some more
<Keybuk> same for NEW, do it a few times a week
<seb128> sbalneav: maybe one of the gdm scripts can be used for that
<Hobbsee> dont you love me creating more work for you?  :P
<Keybuk> I'm just rejecting some stuff that's sat in the bottom for a while
<bddebian> Uh oh
<Hobbsee> ah
<Keybuk> not actually much in NEW, certainly nothing's been in there for > 2 weeks
<seb128> jdub, sbalneav: PostSession from gdm?
<sbalneav> seb128: Unfortunately, this if for Ubuntu's LTSP, which uses ssh for the connection, not gdm
<seb128> ah :/
<Hobbsee> Keybuk: ah right.  dont think i've requested anything in NEW for a long while, actually
<ogra> Keybuk, in 60-symlinks.rules, there is a rule like:
<ogra> ENV{ID_CDROM}=="?*",            SYMLINK+="cdrom"
<Keybuk> ogra: yes
<Keybuk> must get rid of that sometime
<ogra> doesnt that mean the /dev/cdrom symlink will only point to the most recently added cdrom ? 
<Keybuk> s/recently added/randomly picked/
<Keybuk> yes
<ogra> (in case of multiple usb cdroms for example)
<ogra> why doesnt it use cdrom%n ?
<Keybuk> no %n for IDE devices?
<ogra> hmm
<sbalneav> I thought %n was the kernel device number?
<Keybuk> and if you have multiple devices, you need some cunning UI to select them
<Keybuk> at which point you should be using HAL and offering human names for the devices rather than "/dev/cdrom4"
<Keybuk> and then you can just use the proper /dev name instead of a symlink
<Keybuk> sbalneav: right, and for IDE devices that's the partition number, which CDs don't have
<sbalneav> ah
<Keybuk> (and, more pointedly, %n wouldn't work if you had both IDE and SCSI/SATA CD drives
<Keybuk> AND you'd end up with /dev/cdrom4 and /dev/cdrom7 rather than 0 and 1
<Keybuk> I didn't want to ship those symlinks in dapper, but mdz sulked and made me
<jdong|coreduo> Keybuk: are you a part of ubuntu-archive?
<Keybuk> jdong|coreduo: yes
<jdong|coreduo> Keybuk: what is the status of handling backports syncs?
<Keybuk> jdong|coreduo: there is no status
<jdong|coreduo> i.e. will it ever happen?
<Keybuk> judging by the increasingly large pile, I would guess that I'm not alone in wondering why they're assigned to us
<Keybuk> we have no idea how to do it
<Keybuk> or even if it's possible
<jdong|coreduo> mdz and others told me more than a month back that it's ready to be done
<Keybuk> they missed the "tell the people who have to do it" part out :)
<jdong|coreduo> :)
<Keybuk> I asked mdz a while back, and he said there was some code, somewhere in some file that's long since been deleted, that did it
<Keybuk> or something
<jdong|coreduo> according to mdz: "backports are exactly like syncs, but with a trivially modified source
<jdong|coreduo> package.  mia.py in the katie suite contains the relevant bits."
<Keybuk> it was very vague and hand-wavy
<jdong|coreduo> well.... how should this situation be handled, in your opinion?
<Keybuk> right, that's not a useful procedure
<Keybuk> *shrug* someone figure out how to do backports with the LP archive tools
<Keybuk> write the appropriate code, if necessary
<jdong|coreduo> ok.... :)
<Keybuk> write a procedure for the ubuntu-archive guys
<sbalneav> Thanks for the enlightenment, keybuck!
<jdong|coreduo> well, I'm completely clueless on how things work inside the LP/ubuntu-archive world :)
<Keybuk> if there's LP code required, you'd need a LP spec and time from the developers
<jdong|coreduo> ok
<Keybuk> I originally figured it was just me that missed the memo
<Keybuk> but nobody else has dealt with them either
<jdong|coreduo> interesting....
<jdong|coreduo> well, I just e-mailed mdz about the situation....
<jdong|coreduo> btw, for Edgy, is there any plan of getting ClamAV in main?
<jdong|coreduo> it really deserves a lot more security update attention than it's getting
<Keybuk> jdong|coreduo: is there a spec for that?
<jdong|coreduo> I'm not sure
<jdong|coreduo> but having all versions of clamav except Edgy vulnerable currently is just absurd!
<Keybuk> no spec = no plan
<Keybuk> jdong|coreduo: well, in the ideal world; you'd go to a web interface in Launchpad, select the source package you wanted, and the target backport archive, and click "Sync"
<Keybuk> and it'd just add a second publishing record for the target distro
<jdong|coreduo> I see
<Keybuk> however syncs at the moment are still very much by hand, downloading a source, generating a changes file, and uploading it
<jdong|coreduo> hmm
<infinity> Keybuk: Err, it can't just be a copied SPR, because it needs a mangled changelog and version number.
<infinity> Keybuk: That's what mia did.
<Keybuk> why do they need to be mangled?
<Keybuk> and I thought you went to bed? :p
<jdong|coreduo> Keybuk: the version number needs "~dapper1" appended
<jdong|coreduo> to make sure that come Edgy, the package would get overridden/upgraded properly
<Keybuk> see, like I said, nobody explained backports to the poor muggins who has to do them <g>
<Hobbsee> Keybuk: that's cos you're supposed to know everything?
<bddebian> Aye :-(
<jdong|coreduo> lol
<Hobbsee> mmm....backports...
<bluefoxicy> so is anyone else seeing apt refuse to install anything
<bluefoxicy> for the past 2 days now, in edgy?
* Hobbsee wants a backport of kopete 0.12.2.
<jdong|coreduo> so, again, at this point, what needs to be done for backports to get working?
<Hobbsee> bluefoxicy: not really enough info.
<bluefoxicy> Hobbsee:  firefox breaks firefox-themes-ubuntu (<= 0.4.5)
* Hobbsee wants kopete 0.12.2 in edgy, for that matter.
<Keybuk> jdong|coreduo: apparently we need a Soyuz version of "mia"
<infinity> bluefoxicy: apt-get --purge install firefox firefox-themes-ubuntu-
<Hobbsee> we're waiting on upstream's changelog.  mutter.
<Hobbsee> bluefoxicy: ah right.  i dont run the repo'd firefox
<bluefoxicy> infinity:  nod.
<Keybuk> bluefoxicy: purge firefox-themes-ubuntu
<jdong|coreduo> Keybuk: ok.... that seems out of my realm... :)
<bluefoxicy> Hobbsee:  well, apt is 1) Claiming I have broken packages, which NEED to be fixed before I can do anything; 2) Refusing to fix it, because the packages that I need will kill eachother in bloody, gorey death.
<infinity> Keybuk: I am in bed.  Honest.
<bluefoxicy> Keybuk:  that's what infinity just said.  :)
<bddebian> heh
<Hobbsee> haha
<jdong|coreduo> bluefoxicy: tried using dpkg to slap apt around a bit? :)
<Hobbsee> infinity: yes, but you arent asleep.
<Keybuk> bluefoxicy: yeah, edgy bug
* jdong|coreduo notes that clamav doesn't backport cleanly
<infinity> bluefoxicy: "dpkg --force-depends -P firefox-themes-ubuntu" would fix you up too.
<Keybuk> dpkg supports Breaks, apt hasn't a clue about it
<jdong|coreduo> oh well, clamav's not my problem anymore :)
<infinity> Hobbsee: LIES.
<Hobbsee> infinity: why do you want to be in bed yet anyway?  it's not that late...
<bluefoxicy> Keybuk:  ah.  I'm assuming also the firefox-themes-ubuntu needs an upload that hasn't happened yet?
<infinity> Hobbsee: No, it's not, but I have a morning meeting, followed by a reasonably full day.
<bluefoxicy> infinity:  ooh, I don't have to have the package file already?  :D
<Keybuk> bluefoxicy: right
<Hobbsee> infinity: ouchy.  that's right, 9am.
<Hobbsee> infinity: good thing you dont have to be at CC/TB - if you're in my timezone...
* infinity goes to check on his laundry.
<Keybuk> I can't be the only one who imagines people trawling Malone adding "GROVE STREET 4 EVA" to bugs whenever I hear about people "tagging" them, can I?
<bddebian> Nope :-)
<Spads> dd?
<Spads> mcm
<doko> infinity, cprov: please requeue gcc-snapshot on powerpc
<desrt> zul; i wonder if you realise that the xen-doc package is a copy of the kernel source code in which each file has been individually gzipped?
<Keybuk> doko: done
<zul> desrt: hmm.....good point
<zul> that was not the intention
<doko> Keybuk: thanks
<bddebian> OK, this is killing me..
<bddebian> make: execvp: ./configure: Permission denied
<bddebian> make: *** [configure]  Error 127
<desrt> zul; i sort of assumed as much :)
<bddebian> And yes configure is 0755
<zul> desrt: ill fix it in the next upload
<desrt> nice
<cortez> sorry to kinda ask a support question in here, but #ubuntu is a bit of a cesspit right now
<cortez> using strace I found that by having en_GB in $LANGUAGE, 'dd' is crashing because it can't find potfiles apparently
<Keybuk> yeah, it does
<cortez> so I tried to generate new locales, but 'dpkg-reconfigure -plow locales' doesn't work like in debian
<infinity> doko: Kay.
<Keybuk> cortez: that doesn't fix it anyway
<doko> infinity: Keybuk already did it
<cortez> Keybuk: oh, I see
<cortez> Keybuk: well, what's the equivalent to that in ubuntu, anyway?
<infinity> doko: Ahh, so he did.
* bddebian cries
<Keybuk> cortez: the same thing
<Keybuk> bddebian: noexec?
<cortez> on my box, it just regenerates locales
<zul> ok installer question what if the user chooses the username root what would happen?
<Keybuk> cortez: right, what were you expecting?
<cortez> on debian I'd get a curses screen asking me which locales I wanted to enable or disable
<Keybuk> zul: try it, let us know
<infinity> Keybuk: It used to offer a choice of locales to generate, until dapper.
<Keybuk> we moved that somewhere else, didn't we?
<infinity> cortez: You want to install language-pack-en-base to get en_GB, but I suspect you already have it.
<cortez> is there a bug report on this en_GB/dd crash issue, or should I file one?
<bddebian> Keybuk: ?
<Keybuk> infinity: he does already have it
<infinity> cortez: It's a known bug, IIRC.
<cortez> infinity: yeah, I do
<infinity> https://launchpad.net/distros/ubuntu/+source/coreutils/+bug/42264
<Ubugtu> Malone bug 42264 in rosetta "locale dependant segfault for dd" [Untriaged,Unconfirmed]  
<infinity> cortez: Anyhow, "LANG=C dd ..." should work.
<infinity> cortez: Not ideal, but yay bugs.
<lastnode> infinity, ping when you've got a sec?
<infinity> lastnode: I have a sec now, I suppose.
<lastnode> infinity, im trying to figure out which logs to attach for which situation
<lastnode> if you're free now, or later, please consider dropping by #taprobane, im trying to sort out the list with a friend of mine
<infinity> lastnode: Well, I'm heading to bed now, so if it's more than 2 or 3 mins, best for you to drop me an email, perhaps.
<lastnode> infinity, sure
<lastnode> ill do that, then
<lastnode> or ill catch you on irc later
<infinity> lastnode: Or that, sure.
<cortez> infinity: yeah, it's just weird.  I noticed this when I tried to install pdnsd
<bddebian> Keybuk: What do you mean by noexec?
<Keybuk> bddebian: is the filesystem mounted noexec?
<Keybuk> is the dynamic link loader +x ?
<Keybuk> is the #! line of configure right ?
<Keybuk> is that +x ?
<Keybuk> are either, or all three, on a filesystem mounted noexec
<Keybuk> selinux, or some other crazy-arsed system?
* Keybuk tries to remember other reasons for EPERM
<bddebian> Keybuk: Dunno it's pbuilder
<bddebian> Keybuk: It was working until I added two dpatches
<bddebian> Gaw this is pissing me off
<toma> Keybuk: ping
<Keybuk> toma: hi
<toma> Keybuk: hi, got a second for digikam*
<toma> Keybuk: what do you need to let it go through? a new upstream tarball?
<Keybuk> sure, what's up?
<Keybuk> yes, upstream need to release a new tarball with the licence text in it
<toma> Keybuk: allright, the statement within the doc is not enough?
<bddebian> Keybuk: Sorry to bug you but any more ideas?
<Keybuk> toma: there is no statement within the doc
<toma> Keybuk: hu? there should be
<toma> let me check that
<stub> carlos: I'm running the translation copy scripts at the moment
<toma> Keybuk: they have the underFDL and underGPL entities in the docbook
<BenC> Keybuk: well, I searched all of ubuntu/+bugs for devpts and sparc separately (15 bugs matched) and no sign of it
<toma> Keybuk: as usual those get expanded to the text from kdelibs
<elmo> BenC: ok, it's not mounted at that stage
<Keybuk> toma: that is not a full licence text
<toma> Keybuk: it would surprise me if all KDE packages with docs carry the complete text
<elmo> james@faure:~$ grep mount /dev/LOGFILE  | grep devpts
<elmo> + domount devpts /dev/pts -ogid=5,mode=620
<elmo> + mount -n -t devpts -ogid=5,mode=620 devpts /dev/pts
<Keybuk> the phrase "&underFDL;" contains no permission for Ubuntu to distribute and modify the source code
<Keybuk> toma: it would greatly surprise me if they did _not_
<Keybuk> usually it's in the COPYING file at the top
<Keybuk> elmo: right, so I'm not going entirely insane
<BenC> elmo: suck, it's actually working now
<Keybuk> BenC: though partially, it appears I'm getting premonitions of future bugs
<BenC> it mounted correctly
<elmo> benc: doh
<elmo> I wonder if it's because we remount it in the chroots?
<elmo> maybe that somehow affects the one in base?
<BenC> the chroots don't bind mount?
<elmo> benc: no, they directly mount, like:
<elmo> devpts-edgy /srv/chroots/edgy/dev/pts devpts gid=5,mode=0620 0 0
<elmo> except that use to say 'defaults' not 'gid=5,mode=0620'
<BenC> elmo: but then it should have worked all along
<BenC> ah
<BenC> elmo: I think that may have broken it then for your systems
<BenC> elmo: FYI, doing "mount -o bind /dev/pts /chroots/foo/dev/pts" works well
<BenC> it actually does what you want
<BenC> I use it for my chroots for proc,dev/pts,sys
<BenC> elmo: confirmed, if I mount my chroot devpts normally, and use -odefaults, then it breaks the root dev/pts
* bddebian decides to kill himself
<toma> Keybuk: cant find it for kdepim for example
<Keybuk> BenC: ok, this is just freaky ... I can find no discussion about this in my IRC logs ... and no e-mail either
<Riddell> toma: in kdepim the source files all have GPL notices
<BenC> Keybuk: that was one wicked dream you must have had about this :)
<Keybuk> BenC: I'll have cheese sandwiches again tonight and see if I get anymore <g>
<bddebian> hmm
<Keybuk> edgy may turn out to be the most bug-free release yet!  the secret, a developer who fortells the bugs before they happen
<toma> Riddell: but no full fdl text in the root
<BenC> hehe
<BenC> Keybuk: you can be like that woman on Medium, except you'll forsee security vulns and we can fix them preemptively
<Keybuk> toma: so it doesn't
<Keybuk> the sources do contain COPYING files though
<Keybuk> but those are for the GPL
<BenC> Keybuk: Wasn't cr3 having this problem on a machine without chroots?
<BenC> a machine he had locally?
<seaLne> but would killing Keybuk mean there would never be any bugs? :)
<toma> Keybuk: oki, so for this package the text is required, but not for kdepim, right?
<toma> Keybuk: is it ok for the next version of the docs tarball or are you refucing these?
<Keybuk> BenC: ah! that could be it
<Keybuk> yes it was
<Keybuk> BenC: and I bet he was running his LTP tests in a chroot
<Keybuk> there's a chroot in his mtab
<BenC> ok, I think we nailed it down then
<Keybuk> toma: I have rejected those
<Keybuk> also, Riddell, could you look at the other KDE docs and make sure they include the full FDL text somewhere if that's indeed their licence
<Keybuk> toma: it's required for kdepim, however for sanity's sake, I won't remove that from our archive yet
<allee> Keybuk: a full copy of GFDL is in most of the debian/copyright.
<allee> Keybuk: true for digikam*-doc
<Keybuk> debian/copyright is _NOT_ permission from upstream
<Keybuk> I mean, guys, this is the most basic tenet of packaging
<Keybuk> if the upstream tarball contains nothing that gives us permission to distribute or copy it
<allee> Keybuk: of course.  Permission get's included via &underFDL ;)
<Keybuk> then we DO NOT have permission
<bddebian> Hence is the problem with scourge :-(
<Keybuk> dude, that is not text giving us permission
<allee> Keybuk: I don't argue that there is nothing missing.  thing is what should be added.  (e.g. it's a bug in (our) release script that there's no copy of the GFDL in the tarball)
<Keybuk> we don't know what the "underFDL" attribute does
<Keybuk> for all we know, it could expand to a picture of Eric Raymond's butt
<bddebian> Frightening :-)
<Keybuk> right, the upstream tarballs need to contain a copy of the FDL somewhere, _and_ the source should ideally contain a comment saying that it is licenced under that
<kylem> suddenly, i'm not hungry anymore.
<allee> Keybuk: you have to hack deeply in the build system to get something else then GFDL without any invariant section ;)
<bddebian> kylem: :-)
<Keybuk> a top-level FDL file would imply that though
<Keybuk> allee: of course, the point is that somebody has to hack pretty deeply to discover that it's the GFDL that they're getting
<allee> Keybuk: yes, and no.  Just compile it.  That the way I did (and therefore didn't noticed your objections)
<Keybuk> that only gives us permission to distribute the compiled result though
<Keybuk> the source still doesn't contain permission to be distributed (or modified)
<allee> Keybuk: I assume you it's not enough to add a LGFL copy + a KDE standard doc license into the README?
<Keybuk> that's enough
<Keybuk> basically just as long as there's some text somewhere saying "you can distribute and modify this"
* toma diggs for the first doc tarball that went through debian
<allee> Okay.  that's  quickly fixed.
<allee> toma: I'm sure you will not find it there.  I pesters Renchi with lots of stuff missing.  But obviously did some fixes by hand, not adding to -doc release script :(
<Keybuk> allee: thanks
<allee> Keybuk: thx for your fresh eye.  They spot stuff other that looked dozend of times at it are unable to see anymore
<Keybuk> allee: heh, is a pretty standard NEW check ;)
<bddebian> OK, I totally regenerated the package and now it builds fine locally on Dapper but fails on an Edgy pbuilder build
<Keybuk> bddebian: still permission denied?
<bddebian> Yes :-(
<Keybuk> bddebian: tried strace?
<Keybuk> so at least we know what is failing
<bddebian> No, I've never used it :-(
<Keybuk> what fails?
<Keybuk> $ ./configure
<Keybuk> ?
<bddebian> Yes
<bddebian> dh_testdir
<bddebian> ./configure --prefix=/usr
<bddebian> make: execvp: ./configure: Permission denied
<bddebian> make: *** [configure]  Error 127
<Keybuk> can you pastebin the *entire* output?
<bddebian> Sure
<bddebian> Keybuk: http://pastebin.us/3287
<Keybuk> ok, change the package so there's an "ls -l ./configure" just before that line
<Keybuk> and try again
<desrt> -rw-r--r--
<bddebian> Keybuk: OK, thx
<mdz> Keybuk: are you sure about a top-level copy of the license being sufficient?  surely an explicit statement that the license applies to the software is necessary somewhere
<Keybuk> mdz: we've never enforced that in the past?
<Keybuk> there are many sources which contain a just a COPYING file
<mdz> I know it's not been enforced by us or Debian, but it's always seemed fishy to me
<mdz> er, why are we now mailing edgy-changes with every binary build?
<bddebian> I was wondering that also
<bddebian> Keybuk, desrt: You were correct
<bddebian> ls -l ./configure
<bddebian> -rw-r--r-- 1 pbuilder pbuilder 733412 Aug 17 17:24 ./configure
<bddebian> But how am I getting that in the package?  Am I going to have to chmod in rules?
<desrt> bddebian; i checked.  patch will preserve +x, so it's not that.
<desrt> bddebian; a quick chmod +x is a workaround that would definitely work...
<infinity> mdz: Soyuz bug, malcc's on it.
<mdz> infinity: #launchpad said the same, thanks
<bddebian> desrt: Thx but is it "correct" ?
<desrt> bddebian; what is "correct" is to find out what unsets +x on ./configure and beat it
<bddebian> What's weird is dpkg-buildpackage -us -nc... oh
<bddebian> Maybe it's clean
* bddebian feels stupid as always :-(
<bddebian> Shouldn't dh_fixperms -Xconfigure work?
<desrt> that would be a somewhat cleaner way
<bddebian> Doesn't seem to work :-(
<desrt> -X is exclude, you know
<desrt> that means "fix all but configure"
<bddebian> Right
<desrt> i think it's for post-install, though
<bddebian> Oh
<desrt> like, it does fixups in the install root
<desrt> if you really care to fix it properly do an ls -l configure at every point in the makefile
<desrt> and figure out at which point it is losing +x
<desrt> if not, just chmod +x it and be done
<bddebian> desrt: dpkg-buildpackage -S -sa doesn't run make does it?  Other than the clean rule?
* bluefoxicy emerald get!
<desrt> bddebian; the entire debian/rules file is a gigantic makefile
<bddebian> Aye
<desrt> are you still on this same problem? :)
<bddebian> Yes :(
<bddebian> I'm getting to the point of just doing chmod +x but I hate doing things "wrong"
<dmg> bddebian: ./configure's getting generated with the wrong permissions?
<dmg> bddebian: where is it being created from?
<dmg> patch?
<bddebian> No, the permissions are correct until I make the source package
<dmg> so it's something in the source package creation steps that remove the '-x'
<bddebian> Aye but I can't figure out why
<dmg> what programs run when the source package is generated?
<dmg> bddebian: I think keybuk is right -- strace would help here if you could narrow down the program that was actually changing the permissions.
<dmg> strace -o buildpackages.out -ff dpkg-buildpackage ....
<dmg> the grep through buildpackages for calls to chmod or other calls referencing configure
<dmg> not the most elegant way to solve your problem, but if something's changing the perms of that file, strace will catch it.
<Keybuk> something in the clean rule, usually
<Keybuk> or the configure script isn't in the tarball, but created by the diff.gz
<Keybuk> bddebian: perhaps you could upload the source somewhere for more eyes?
<dmg> which was why I asked if it ./configure was generated by patch
<bddebian> Keybuk: configure isn't in the tarball.  I had to do an autoreconf to generate it :-(
<Keybuk> ok, that _should_ generate it +x then
<sabdf1> how do I make a moin page redirect somewhere else?
<bddebian> Keybuk: It did but something changes it on building the source package
<Seveas> sabdfl, #REFRESH 0 http://somwhere/else
<bddebian> Keybuk: http://www2.bddebian.com:8000/packages/ubuntu/prismstumbler/  if you are interested at all :-)
<simira> I have an issue where Edgy seems to logout my session automatically after a while, or just drop my login; is this anything known?
<sabdfl> Seveas: thanks!
<sabdfl> wow, FF2 tab closing is spectacularly innovative and sadly wrong
<zul> heh
<Keybuk> sabdfl: I didn't notice anything special about it?
<sladen> simira: it's a bug even if it's not known yet!  And still needs reporting :
<sladen> )
<simira> sladen: appearantly. Just have to figure out where. And what...
<sladen> simira: gnome-session is maybe a good place to start, then the desktop wizards can repoint it as they help you debug it
<simira> sladen: yes. I intend to test it now, so I'll be idle for a little bit ;)
<sabdfl> Keybuk: it clutters up the tab bar, and changes behaviour based on the number of tabs
<simira> Just have to make someone change my wikiname first... who can do that?
<sabdfl> the old behaviour was preferable, imo
<Keybuk> sabdfl: right, I don't get what's "innovative" about it ?
<Keybuk> it's now the same as every other app on the desktop
<Keybuk> or is this some Microsoft definition of "innovation"? :p
<bddebian> doh
<Amaranth> Keybuk: I think the "innovative" bit is what happens when you have 20 tabs open.
<sladen> simira: Happy Wedding 12th day wedding anniversary btw
<zul> oh the scrolling bit?
<tseng> simira: oh wow I had no idea, congrats
<tseng> simira: (well, i knew of the engagement)
<poningru> there is an md5 mismatch in the sources list for main 
<poningru> edgy
<poningru> who do I report that to?
<simira> sladen, tseng : thanks
<tseng> its most likely not a real problem
<tseng> proxies ocassionally break apt checksums in my experience
<poningru> ah ok
<poningru> thanks
<tseng> if it is, it will be noticed and fixed.
<Keybuk> Amaranth: the close button is no longer hidden under the right-most tab? :p
<sladen> tseng: the NTL transparent proxies in the UK are a classic for doing that
<tseng> sladen: :/
<Amaranth> Keybuk: the close buttons disappear for all but the currently focused tab
<tseng> sladen: fortunately for me its self-imposed by apt-proxy
<tseng> or maybe by the web proxy in front of apt-proxy
<Keybuk> Amaranth: really, it doesn't do that here/
<Amaranth> Keybuk: open a shitload of tabs
<Amaranth> interesting, shitload is a valid word in whatever dictionary xchat-gnome is using...
<poningru> http://kb.mozillazine.org/Browser.tabs.closeButtons
<poningru> to switch back
<poningru> Amaranth: rofl
<HiddenWolf> Amaranth: xchat-gnome has issues, nothing new there. :)
<Amaranth> i use epiphany :P
<Amaranth> I wish epiphany had support for fx2's spell checking. I can see that words are spelled wrong but I can't get spelling suggestions.
<Keybuk> Amaranth: oh, I see
<Keybuk> that is very wrong
<bddebian> Damnit, do I really want to write a manpage? :-(
<slomo> bddebian: it would be nice to have at least ;) for which package?
<bddebian> slomo: prismstumbler :-(
<bddebian> And of course --help doesn't work so I can't even use help2man :'-(
<slomo> hm... so better write one... otherwise people won't know how to use it ;)
<welshbyte> bddebian: can't you take appropriate paragraphs from http://prismstumbler.projects.linuxtogo.org/ ? looks like the info is all there...
<Keybuk> doko: ping?
<bddebian> welshbyte: I probably can, I'm just lazy and I really don't care about this package other than closing two bugs ;-P
<bddebian> Is there any kind manpage generator package?
<Seveas> bddebian, vim
<pitti> bddebian: pod2anything, there is also a pod2man
* pitti likes pod
<bddebian> pod?
<bddebian> Seveas: Nano man, come on :-)
<Seveas> bddebian, ptfah
<LaserJock> I'm sure emacs has a mode for it
* bddebian vomits
<LaserJock> but it'd take me longer to figure out the mode then write the manpage by hand
<bddebian> Exactly :-)
<desrt> cc1: error: invalid option argument '-O0''
<desrt> that's a new one.
<Seveas> LaserJock, http://ubuntu-nl.org/~dennis/curves.jpg
<Seveas> desrt, did you see the extra ' there 
<desrt> hmmmm
<LaserJock> Seveas: hehe
<Seveas> probably you give it -O0' as argument
<bddebian> Seveas: Hahaha
<LaserJock> Seveas: some days, that's what it feels like for sure
<Seveas> LaserJock, I've been forced to touch emacs. I felt violated and never want to touch it again
<LaserJock> well, I fell in love with planner-el
<doko> Keybuk: pong
<LaserJock> that's my reason for using emacs
<LaserJock> that and I can do some real quick data cleaning with it
<Keybuk> doko: is gnat deliberately dropped from the older gcc sources?
<doko> Keybuk: yeah, need to update gcc-defaults ...
<doko> Keybuk: wait, I did update gcc-defaults, still in NEW?
<Keybuk> no, I'm just going through the outdate stuff looking for NBS
<allee> Keybuk: these will be READMEs in the next -doc tarballs: http://websvn.kde.org/branches/stable/extragear/graphics/digikam/README-doc?rev=574022&view=markup and http://websvn.kde.org/branches/stable/extragear/graphics/digikamimageplugins/README-doc?rev=574028&view=markup
<doko> NBS?
<Keybuk> doko: Not Built (by) Source
<Keybuk> allee: that appears to contain licence text :)
<allee> Keybuk: yeah.  I thought about adding COPYING.gfdl but decided to put all in one file
<sabdfl> night all
<rodarvus> doko, do you have plans to make python 2.5 the default for Edgy?
<rodarvus> (just curious :) )
<doko> rodarvus: no, probably not, although we will provide all modules and extensions for 2.5 as well.
<doko> let's talk about it next week
<rodarvus> *nods* surely, thanks!
#ubuntu-devel 2006-08-18
<pygi> elkbuntu, hey hey :)
<doko> seb128: hi font breaker ;-P
<seb128> doko: I broke some font?
<doko> some users did complain about new libcairo (?)
<seb128> doko: not that I know of
<seb128> doko: we got no bug about libcairo recently and nobody complained on IRC neither
<zyga> doko: how did the bug manifest itself?
<givre> Sorry, but if you speak abuout font problem, it's due to a compiz upgrade
<givre> http://www.compiz.net/topic-3116-fonts-are-now-complete-crap
<givre> from the quinn's repo
<seb128> if a binary package is renamed (actually a lib changing soname and shipping conflicting content (it should use a -common but the package comes from Debian like that)), what should be used. Replaces? Conflicts,Replaces?
<pitti> seb128: for a library, C/R seems appropriate
<seb128> ok, what I though, thank you
<pitti> seb128: Provides doesn't seem necessary for a library
<seb128> and it would be wrong
<seb128> since the soname changed
<pitti> that, too
<seb128> so it doesn't provide the previous one
<pitti> with soname libraries conflicting to each other, much of the reason for soname package naming is lost, though :/
<seb128> yeah, as said it comes from Debian
<pitti> s/soname libaries/library packages/
<seb128> and I spotted the error when uploading yesterday
<pitti> seb128: I hope the transition is not too big then
<seb128> but for some reason -0ubuntu1 got accepted from NEW and -0ubuntu2 rejected because the .orig.tar.gz was not found
<seb128> pitti: it's the glade-3 lib, no transition
<pitti> ah
<seb128> the Debian maintainer screwed and forgot to change the soname
<seb128> I spotted it like 5 min after upload
<seb128> but since the NEW approval screwed the fixed version I've to Conflicts, Replaces now :p
<bddebian> Heya folks
<lastnode> imbrandon, ping? :)
<imbrandon> lastnode: pong
<lastnode> imbrandon, wondering if you got an email, or if i misspelled the address
<imbrandon> lastnode: just going over my email now, sure put me on the group list
<imbrandon> might be a few days before i get totaly caught up thought to poke the code well ;)
<lastnode> imbrandon, sure, no hurry at all. btw the source is pretty old now, been doing some updates
<lastnode> imbrandon, you know of a site that might offer some temp svn access?
<imbrandon> hrm i could setup a svn server on imbrandon.com pretty easy i thinkor there is always sf.net
<imbrandon> thought about bzr ? bzr > svn ;)
<imbrandon> no server req either
<imbrandon> ;)
<lastnode> imbrandon, heh. for now, it would be safer to use something everyone knows how to? i know basically nothing about bazaar
<lastnode> imbrandon, i want to make this a little more stable and decide on a name before i reg on sf.net
<imbrandon> easy to get the basics, bzr checkout http://dsfgs   , bzr commit -m "comment here"
<imbrandon> ;)
<lastnode> imbrandon, is it free to sign up? i guess we could use it for now?
<imbrandon> free to signup for what ?
<lastnode> imbrandon, btw, some new output samples - http://dawnstudios.com/sandbox/mahangu/?p=16
<imbrandon> k
<lastnode> the 406 i mentioned in the email, seems to be server specific
<lastnode> imbrandon, i mean, bazaar server, would you host it?
<imbrandon> yea i can host , it requires nothgin but ssh accounts for sftp, i can setup it all up this evening and shoot you an email with a bzr primer, you could pick up the basics in 15 minutes, its realy nice
<lastnode> imbrandon, is the bzr source released yet?
<imbrandon> yes 
<imbrandon> apt-get source bzr
<imbrandon> ;)
<lastnode> sweet
<lastnode> im just wondeirng though
<lastnode> for my friends on debian
<lastnode> gentoo etc
<lastnode> how would that work?
<lastnode> from source?
<imbrandon> also LP can / will host bzr branches too for registered products
<imbrandon> bzr is in debian too, and it should run fine on any distro
<lastnode> imbrandon, you think LP will host something as obscure as this?
<imbrandon> sure , lets take this to a temp channell not to clutter up in here and i'll explain it a bit
<imbrandon> join #imbrandon
<DShepherd> i hear X is broke in edgy.. is it true?
<lastnode> imbrandon, #taprobane
<imbrandon> kk
<nixternal> daily/alternate doesn't fit on a disk ;(
<bluefoxicy> root     18435  ---    w|x  -------    syslogd          =ep cap_setpcap-ep  
<DShepherd> is there any plans for tracker to be in edgy? or available for installation?
<pitti> Good morning
<hunger> hi
<pitti> mvo: is there an easy way to disable this silly 'FutureWarning: apt API not stable yet' warning with the python apt module?
<StevenK> Remove the raise FutureWarning? :-P
<mvo> pitti: from warnings import warn
<mvo> pitti: warnings.filterwarnings("ignore", "apt API not stable yet", FutureWarning)
<mvo> err
<mvo> make that first line
<mvo> import warnings :)
<mvo> then import apt
<pitti> ah, cool
<pitti> mvo: much better, thank you
<mvo> pitti: I had a look at the python gettext code yesterday, what is the current langpack policy? if we have a mo file in the langpack use it, if not use the original translation? if that is the case I will fix the python script 
<pitti> mvo: no, the other way round
<mvo> aha, ok
<pitti> mvo: i. e. /usr/share/locale is prefered over /usr/share/locale-langpack
<pitti> to not break local builds
<mvo> doko: here? 
<doko> mvo: sure
<robtaylor> hmm, if i want to build a patched dapper kernel, do i just need to update changelong and do debian/rules bumpabi?
<robtaylor> s/changelong/chaiselongue/ s/chaiselongue/changelog
* robtaylor needs to wake up
<mvo> doko: I will do a updated gettext patch for the langpacks for python today, should I just upload it? or send it to you and you do it on your next scheduled upload?
<doko> mvo: please go ahead, but apply it for both python2.4 and python2.5
<mvo> doko: ok, thanks
<Riddell> mvo: do you have any examples of third party "channels" files?
<mvo> Riddell: try the "omnis" one in app-install-data-commercial
<Riddell> mvo: ah, that's where it is.  why the separate package?
<mvo> Riddell: because we exptected it to be updated quite frequently. and app-install-data is pretty big (some MB). that would be a pain for the users to download
<Riddell> right, thanks
<Zdra> Hi, is it normal that daily build are all over-sized ? What's the last daily which is <700M ?
<rodarvus> anyone running Dapper *and* using i810 is willing to test an updated version of the i810 driver for me?
<Zdra> rodarvus: I can
<StevenK> rodarvus: I can on amd64, if you like.
<Zdra> rodarvus: 0000:00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) --> that's ok to test ?
<rodarvus> StevenK, oh, I only have i386 locally - but it would be nice if you could recompile the package I generated on amd64
<rodarvus> Zdra, sure - I'm uploading the package right now :)
<StevenK> rodarvus: What are you doing without an amd64? :-P
<StevenK> rodarvus: But, sure, point me at source.
<rodarvus> Zdra, StevenK: http://people.ubuntu.com/~rodarvus/packages/xserver-xorg-driver-i810/
<rodarvus> Zdra, StevenK: thanks :)
<rodarvus> Zdra, it is not normal for daily builds to be oversized, but Kamion and Mithrandir are on vacations and thus, unable to care for them
<rodarvus> (they'll be back next week, though)
<Zdra> rodarvus: just dpkg -i and restart X and say if it starts ? or something more to test ?
<Zdra> rodarvus: ok
<rodarvus> yes, this is the most important test
<rodarvus> Zdra, please send me /var/log/Xorg.0.log, too
<StevenK> Heh, my first test is if the fragging thing builds. :-P
<rodarvus> rodarvus at ubuntu.com
* rodarvus crosses his fingers
<StevenK> rodarvus: And toes?
<StevenK> Whee, compiler warnings.
<rodarvus> Zdra, playing video & testing DRI would be nice too
<rodarvus> StevenK, please send me the .build so I can take a look at it, if it possible
<StevenK> rodarvus: Oh, damn you. :-P
* StevenK rebuilds it, this time through tee.
<rodarvus> StevenK, use debuild, it saves the .build automatically for you
<rodarvus> or even better, use pbuildere
<rodarvus> pbuilder
<StevenK> I am.
<StevenK> I wasn't aware that pbuilder saves logs.
<rodarvus> hmm, no it doesn't
<rodarvus> :)
<StevenK> -rw-r--r-- 1 steven users 53K 2006-08-18 21:17 ../xserver-xorg-driver-i810-1.6.5_amd64.build
<StevenK> Anyway, I've gotten you one.
<rodarvus> you need to pass --logfile for it to save the .build
* StevenK will keep that snippet in mind.
<rodarvus> (I added it to my helper scripts long ago and forgot)
<StevenK> Yeah, I have my own.
<StevenK> Well, it also installs.
* StevenK tries it.
<shackan> unrelated, but is xgl useable now with an i810 ?
<Zdra> rodarvus: ok it starts, movie are OK but glxgear is very slow and have errors
<rodarvus> Zdra, did glxgears used to run well on your previous driver?
<Zdra> what's your email ? I can send you logs and error msg
<rodarvus> rodarvus at ubuntu.com
<Zdra> rodarvus: yes
<rodarvus> oh, well.
<rodarvus> then this version of i810 driver really needs mesa 6.5
<rodarvus> and is unsuitable for a dapper update :/
<StevenK> rodarvus: It works.
<rodarvus> thats sad news because it fixes loads of other bugs
<StevenK> rodarvus: GL has never actually worked for me, though. :-)
<StevenK> steven@liquified:~% glxgears
<StevenK> ERROR!  sizeof(I830DRIRec) does not match passed size from device driver
<StevenK> It even goes bang now.
<rodarvus> StevenK, what "goes bang" means? :)
<rodarvus> sorry, non-native english speaker here
<HiddenWolf> rodarvus: doesn't work. :)
<HiddenWolf> rodarvus: goes bang -> blows up
<rodarvus> ahn
<Zdra> rodarvus: I send you logs by mail ;)
<rodarvus> HiddenWolf, thanks for the translation :)
<rodarvus> Zdra, I'm reading them now, thanks!
<Zdra> rodarvus: need more testing ? because I'm on public machines at university so I have to reverse to normal driver before quiting :p
<rodarvus> Zdra, no, that was all the testing I needed, thanks a lot for the test!
<StevenK> rodarvus: Right, sorry, I was afk.
<rodarvus> StevenK, thanks for testing it too!
<StevenK> rodarvus: You'd like the .build and Xorg.0.log?
<rodarvus> StevenK, sure
<StevenK> rodarvus: Sent.
<StevenK> Well, it's hit fiordland.u.c, anyway
<rodarvus> :)
<StevenK> rodarvus: So, is it going into Dapper?
<rodarvus> not really
<rodarvus> (at least, not now)
* StevenK ponders downgrading.
<rodarvus> StevenK, its up to you, really
<rodarvus> if you haven't noticed any new problem
<StevenK> rodarvus: Hopefully, I'm getting an Nvidia in a few weeks, so it might even get purged.
<lastnode> infinity, ping?
<tepsipakki> hi, ubuntu-desktop is uninstallable because of missing packages, and these should be rebuilt: at-spi, bluez-pin, bug-buddy, ekiga, evolution-webcal, gnome-mag, gnome-media, libgtkhtml2
<tepsipakki> ..against the new libgail, libbluetooth, libebook or libecal
<Hobbsee> doko: any reason you didnt subscribe the archive to tomcat5 sync request?  want me to fix it?
<doko> Hobbsee: no, have to check something first ...
<Hobbsee> doko: ah, cool.  just saw it come up in -bugs, and wasnt sure who had done it, if it was right, etc
* Hobbsee keeps seeing the odd bug done by a non-MOTU, where they havent actually subscribed anyone to get anything done with it
<simira> mvo_: any known issues with update-manager now? Something's not right with me at least
<mvo_> simira: no, sorry. I did not managed to reproduce this yet :(
<simira> mvo_: I meant if you had som other problems. I just got "Failed to download update-list", or something like that
<simira> mvo_: I can take some time next week to re-test and confirm or close the update-manager bugs I have reported, and you can have a hands-on look on those who remain.
<mvo_> simira: that sounds good, I would really like to figure what caused those problems
<robtaylor> mjg59: whats the right way to patch a dapper kernel?
<mjg59> robtaylor: I grab git, patch it, and send a diff to Ben
<robtaylor> mjg59: apt-get source linux-kernel-foo, patch, bump changelong and bumpabi?
<robtaylor> ah
<mjg59> But I don't think that's what you want :)
<mjg59> Bump ABI if ABI breaks
<zul> robtaylor: download the dapper git tree, create a patch and send diff
<robtaylor> probably not
<robtaylor> zul: i'm testing LTTng, i'm not sure ben would be interested in the patch ;)
<zul> LTTng?
<robtaylor> linux trace toolkit, new stuff
<zul> ah...edgy-git then 
<zul> wont get into dapper then probably if you do send a patch
<robtaylor> no, as mjg59 guess, i just want to build a dapper kernel package with all the crazy ubuntu stuff +LTTng
<robtaylor> later i'll see about getting it in edgy ;)
<ogra> Keybuk, can you promote ltspfs and ltspfsd to main ... pitti said its ok, even we have to fix stuff in the code
<robtaylor> zul: its probably just best to wait for it to go into kernel proper though, some bits are not considered clean enough yet
<desrt> robtaylor; is this a dtrace equiv?
<Riddell> mvo_: do you know that gnome-app-install isn't installable?
<robtaylor> desrt: well, yes and no
<robtaylor> desrt: its rather a different design (post-processeing rather than pre-processing)
<Keybuk> ogra: they don't appear to be approved
<ogra> Keybuk, they arent ... but i need them in main and pitti said its fine with him since we'll resolve open issues together at the sprint anyway
<desrt> robtaylor; but same idea, right?
* Keybuk looks at pitti
<desrt> robtaylor; in terms of what it does for me
<ogra> Keybuk, he's gone after telling me that :/
<robtaylor> desrt: well, in dtrace you can write scripts that do things at event points
<Keybuk> heh fair enough
<robtaylor> desrt: in LTT, you do the trace and then process the data
<Keybuk> we can always beat you to death next week if you're LYING
<desrt> oh.  i see what you mean.
<Keybuk> ...or if you bring those shorts again
<desrt> that's slightly less powerful.
<ogra> Keybuk, exactly ... or make me pay all the beer :)
<Keybuk> make sure you see them
<robtaylor> desrt: dtrace is heavier in terms of resource usage, but more dynamic and easier for sysadmins
<Keybuk> seed them
<ogra> yup
<Keybuk> done
<robtaylor> desrt: LTT is light, but you end up with more data and you can't make arbitary things happen when the events occur
<ogra> thanks a lot :)
<desrt> robtaylor; thanks for the description.
<robtaylor> desrt: there in't really an equiv of dtrace for linux yet :/
<robtaylor> desrt: np
<mvo_> Riddell: what is the error? seems to be ok here
<lfittl> ogra: any news about blender 2.42 / ffmpeg support as a plugin? (just out of interest)
<Riddell> mvo_:   gnome-app-install: Depends: python-gtk2 (>= 2.4.0) but it is not going to be installed
<Riddell>                      Depends: python-gnome2-extras (>= 2.11.3) but it is not going to be installed
<Riddell>                      Depends: python-gnome2 but it is not going to be installed
<Riddell> mvo_: I have python2.4-gtk2 not python-gtk2
<bddebian> Howdy folks
<geser> python-gtk2 is definitely there. have you tried to install it explicitly?
<ogra> lfittl, nope, had no time yet
<ogra> Keybuk, i have another small problem ... with udev on thin clients ...
<Keybuk> oh aye?
<ogra> for pre-plugged devices we write to a chache file (.delayed-mounts) so if the ssh socket from the login is available the deamon we run can mount them
<ogra> now thin client have a read only filesystem and only specific dirs and files get bind monted to a tmpfs 
<Keybuk> right
<ogra>  /tmp among them ... so we loose content of tmp during a small period of time on boot ...
<Keybuk> even real Ubuntu systems are read-only at the point udev runs
<ogra> our udev scripts usually write to /tmp/.delayed-mounts 
<Keybuk> why not /var/run, out of interest?
<ogra> well, /var/run would work as well ...
<ogra> doesnt matter whare 
<ogra> *where
<Keybuk> right, carry on
* bddebian pokes Keybuk just for "fun"
<ogra> hmm ... i get it ... i should exclude /var/run from the second time bind mounting to tmpfs i guess :P
<Keybuk> right ;)
<Keybuk> it doesn't matter so much whether you have one tmpfs, or a dozen different tmpfs
<ogra> yep
<Keybuk> they use the same pages anyway
<Riddell> enrico: I don't suppose you've any idea why debtags in edgy is broken?
<ogra> well, i missed the fact that we already have it as tmpfs but the ltsp code dates back to a time where that wasnt the case 
<Keybuk> this is amongst the reasons we have it as a tmpfs in the first place
<ogra> so it gets bind mounted a second time on thin client configuration :)
<Keybuk> several things udev runs need to write cache/pid/etc. files
<Keybuk> does that re-mounting not break network ?
<Keybuk> you'd lose /var/run/network
<ogra> no
<ogra> apparently not
<Keybuk> interesting, sure that lo is in there after the remount?
<ogra> nope, lo isnt there at all
<ogra> (and never wasnt)
<ogra> s/wasnt/was/
<Keybuk> that'd probably fix that too
<ogra> right
* ogra tries it out
<ogra> hmm, speeds up the boot a bit :)
<ogra> but i have no lo :)
<ogra> night be because i dont run the startup scripts for it ;)
<wasabi_> One of these days, I'll figure out how XKB works enough to fix it.
* wasabi_ beats xkb
<bddebian> wasabi_: Good luck with that :-)
<wasabi_> This system has had neverending problems with it. g-s-d can't set the xkb settings, setxkbmap can't.
<wasabi_> And try as I might I can't figure out how xkb even works. ;0
<ogra> yay, it mounts :)
<ogra> Thanks ! Keybuk 
<ogra> hmm
<moberg_> today there was a update to gnome-terminal, after I installed it, gnome-terminal crashes frequently
* bluefoxicy looks into kexec
<Seveas> moberg_, disable quinsstorms repos and yell at quinn
<Seveas> it's not an Ubuntu update
<lunitik> Sorry to disturb, where would be an appropriate place to discuss Community Council related issues?
<zul> at the community council
<lunitik> zul, which would be where? sorry, I was banned, since I have reviewed and signed the Code of Conduct and wish to be given another shot around the community... specifically #ubuntu
<bluefoxicy> Seveas:  from a politics point of view, nobody is going to go for making shutdown->restart restart Linux instead of the machine, are they?
<zul> you might want to try #ubuntu-ops
<lunitik> zul, will do, thank you
<Seveas> bluefoxicy, -EPARSE
<bluefoxicy> Seveas:  I'm looking at getting things to use kexec instead of actually reboot.  An MSI board I had took 18 seconds to reach grub; another user i know has an MSI board that takes 25 seconds to reach grub.  These are Athlon 64s.  I think my current gigabyte takes about 10 seconds
<Treenaks> bluefoxicy: kexec is nice, but what if you want to reboot into some other OS you're dualbooting?
<Seveas> it might be nice for lmanul, adding another button to th overcrowded logout dialog
<bluefoxicy> I'm thinking I can definitely say it's safe to make the "System Restart Required" dialoog kexec; I don't know about just replacing the current Reboot functionality
<bluefoxicy> Treenaks:  shutdown?  :)
<bluefoxicy> Seveas:  that would be confusing.  "Restart" "Reload"?  "WTF?" would be the reaction :)
<Treenaks> bluefoxicy: how safe is kexec?
<Treenaks> Seveas: Ubuntu should just use the upstream dialogs.. I do
<Treenaks> Seveas: they're great compared to the button mash
<bluefoxicy> Treenaks:  it's .... pretty old.  I believe it's maintained, it's been in there for a bit and IIRC Linus likes it so it's probably stable; some testing is needed, as with anything.
<bluefoxicy> oh
<bluefoxicy> you can load-panic too, something Linus wanted, kernel panic -> immediately load new kernel :)
<bluefoxicy> I don't see a way to load an initrd.  :(
* bluefoxicy notices the man page is incomplete!  --initrd=FILE         Use FILE as the kernel's initial ramdisk.  --append=STRING       Set the kernel command line to STRING.
<lunitik> Seveas is unwilling to give me a chance, is there another route I can take? I really want to be a good community member, and avoid disagreements entirely.
<lunitik> Only thing I can do to give back in provide support for people, and I plan to do that as well as I can.
<Seveas> lunitik, come to a community council meeting and do NOT mess in here -- this is not an escalation channel
<lunitik> I just want another chance.
<lunitik> Seveas, you've banned me from all the other Ubuntu related channels I know of now... when is the next council meeting?
<Seveas> lunitik, wiki.ubuntu.com/CommunityCouncilAgenda
<Seveas> fwiw, you can be active in other places besides IRC too
<lunitik> Seveas, not as effectively. I enjoy helping people on IRC. Disagreements happen on this medium though.
<Seveas> lunitik, which part of "do NOT mess in here -- this is not an escalation channel" is so hard to understand?
<lunitik> I do not like forums or mailing lists, its more difficult to really assist people. 5 years experience with Debian shouldn't go to waist simply because I'm not currently using Debian.
<lunitik> Seveas, sorry... I'll be at the meeting.
<pygi_> who feels like doing some testing right now? :)
<Seveas> pygi_, depends on how hard and hum much it might break
<pygi_> Seveas, might break none, I need testing for "libburn-on-cdrecord" layer
<Seveas> hmm, /me has no bank cds
<azeem> pygi: what are you using for that?
<pygi> azeem, I am writing that :)
<azeem> oh, o
<azeem> so you extend libburn, or you write a cdrecord replacement which uses libburn?
* pygi is libburn's upstream
<azeem> ah, you're one of the people forking it?
<azeem> I see
<pygi> azeem, that no good word, but whatever
<sivang> azeem: I understood it was abandomed by its maintainer, so that's not exactly forking ? 
<feloness>  33 check it http://www.goolook.ru/?ref_id=11389
<azeem> does anybody know whether a Ubuntu precense is planned for the Systems expo in Munich in late October?
* bddebian doesn't know anything :)
<zul> azeem: might want to check with jono
<pygi> Seveas, poke
<bluefoxicy> kexec_load function not implemented
<zul> hey rodarvus 
<bluefoxicy> shet.  It's on in edgy, not on in dapper.
<rodarvus> hey zul
<bluefoxicy> well, I guess it's time my laptop flirts with edgy.
<bluefoxicy> it worked
<bluefoxicy> but I had to patch /etc/init.d/reboot
<bluefoxicy> k I made a post on -devel@
<Keybuk> so, right, why isn't there an ssh-askpass-gnome-keyring ?
<bluefoxicy> it'll take 3 scripts, a tweak at /etc/init.d/reboot, and a poke at the System Restart Required dialog or wherever else you wanna use it.
<bluefoxicy> hi buk
<Amaranth> Keybuk: it'd be so cool to have that and pam_keyring, you could just login and have all your stuff work
<moberg_> is there any edgy isos available for download?
<welshbyte> moberg_: http://cdimage.ubuntu.com/releases/edgy/  WARNING: use at your own risk
<moberg_> welshbyte: sweet, i'm going to install edgy in a virtual machine and test an application that i'm developing
<enrico> Riddell: I had no idea it was broken, either...
<enrico> Riddell: any pointers?
<Riddell> enrico: debtags cat   just gives no tag for all items
<Riddell> it's the same source as in debian
<enrico> Riddell: can you send me a strace?
<enrico> Riddell: and a ls -la /var/lib/debtags
<enrico> Riddell: and a cat /etc/debtags/sources.list
<enrico> Riddell: and a apt-cache dumpavail|grep ^Tag | wc -l
<enrico> I think that's it
<Riddell> enrico: http://kubuntu.org/~jriddell/tmp/DEBTAGS
<enrico> Riddell: I suspect that the reason is having "tags apt://" in the debtags sources.list but no tags in the packages file
<enrico> Riddell: if that is the case, try adding "tags http://debtags.alioth.debian.org/tags/" to /etc/debtags/sources.list and run 'debtags update'
<Riddell> enrico: http://kubuntu.org/~jriddell/tmp/DEBTAGS-COMMANDS
<enrico> >apt-cache dumpavail|grep ^Tag | wc -l
<enrico> 0
<enrico> gotcha
<enrico> Riddell: that's it.
<enrico> Riddell: does changing the debtags/sources.list and updating solve the issue?
<Riddell> enrico: it does
<enrico> Riddell: then I guess either Ubuntu starts adding Tag: fields to the packages file, or the Ubuntu debtags ships getting the files from alioth
<enrico> or, getting the files from a local directory
<enrico> Riddell: debtags/sources.list supports file:// uris as well
<Riddell> enrico: how come debian doesn't have this problem?
<enrico> Riddell: Debian has Tag: fields in the Packages file
<Riddell> right
<_ion> o
<_ion> Whoops.
<zul> hey fabbione 
<desrt> zul; -6 gives no love for not rebooting
* desrt waits to see with .17
<zul> desrt: ok...
<Oestrelata>  13 check this http://www.goolook.ru/?ref_id=11389
<bluefoxicy> mdz:  ping, are you about?
<sladen> Keybuk: I had at the back of my mind dropping powernowd for edgy and switching to the in-kernel ondemand governor;  I'd forgotten about it, are you happy with it happening---it deals with issues involving multiple CPUs/cores
* bluefoxicy gets the clueb and whacks freenode's hub.
<RingerE> http://www.wsmfm.com/dogs/entries  vote for molly, the cockerspaniel... if she gets enuogh votes i win crap ;o)
<mjg59> rodarvus: Why does my libgl appear to be trying to open /usr/X11R6/lib/modules/dri/i915_dri.so rather than /usr/lib/i915_dri.so ?
<mjg59> Uh
<mjg59> /usr/lib/dri/i915_dri.so
<rodarvus> mjg59: configs/debian-dri is screwed. I'll upload a fix today
<mjg59> Ok, cool
<Kaleo> rodarvus: you're ace
<Keybuk> sladen: iirc, the ondemand governor does exactly the same thing as powernowd, no?
<Keybuk> adjusts the speed based on the current load
<pygi> Amaranth, poke
<Amaranth> pygi: that hurts
#ubuntu-devel 2006-08-19
<doko> infinity, cprov: (I know, weekend ...) please requeue libgtk-java on all archs
<raphink> anyone knows if it's possible to assign a value to a varible in make using an external command ?
<raphink> e.g. 
<raphink>         for image in seq -w 01 36
<raphink> doesn't work
<crimsun> you need to quote the seq command
<crimsun> $(seq -w 01 36)
<raphink> doesn't work either
<_ion>         seq -w 01 36 | while read image; do \
<raphink>         for image in $(seq -w 01 36)
<raphink>                 echo $(image)
<raphink>         endfor
<raphink> that won't work
<_ion>           stuff with $$image
<raphink> hmm _ion in make?
<_ion> _Each_ line is interpreted separately with sh, unless they're merged with the \ char. Also you need to type $$ in the Makefile to give $ to the shell.
<raphink> ah
<_ion> Also i prefer 'seq ... | while read foo' instead of 'for foo in $(seq ...)' because it allows the length of the sequence to be arbitrary without any concern for memory usage.
<raphink> ok
<raphink> doesn't seem to work though
<raphink> :s
<raphink> for some reason
<raphink> oh wait yes it does :)
<raphink> sorry
<raphink> thanks much _ion that helps a lot :)
<_ion> Anyway, http://johan.kiviniemi.name/tmp/example-Makefile
<bddebian> Howdy
<_ion> Howdy-how.
<raphink> woot
<bddebian> Heya raphink
<raphink> hi bddebian :)
<lastnode> imbrandon, ping?
<netdur> people with compiz respo, got libvte upgrade, it broke synaptic... this bug https://launchpad.net/distros/ubuntu/+source/vte/+bug/56862
<Ubugtu> Malone bug 56862 in vte "synaptic requires libvte.so.4, but upgrade of libvte removes it" [Medium,Unconfirmed]  
<ajmitch> ah, so it is the fault of 3rd party repositories
<netdur> gonna comment
<ajmitch> I'm rejecting anyway
<netdur> okay
<DShepherd> hey edgy users.. the X problem that was happening has it been fixed?
<ajmitch> DShepherd: not nearly enough info
<DShepherd> ajmitch: ok..
<lastnode> infinity, ping?
<Keybuk> File 'option.c'
<Keybuk> Lines executed:100.00% of 127
<Keybuk> option.c:creating 'option.c.gcov'
<Keybuk> yay test cases
<bddebian> Heya Keybuk
<Keybuk> :)
<robertj> Keybuk: has there been any discussion about attempting to automating package rebuilds for simple backports?
<Keybuk> how do you mean?
<robertj> Keybuk: lots of games have simple & relatively stable deps, so backporting is a snap
<robertj> the way I currently do it now is I take my sources.list %s/dapper/edgy, update, apt-get src foo, change sources list back & update again, then do the dpkg-buildpackage
<Keybuk> we have a theoretical backports acrhive
<robertj> ahh?
<robertj> "theoretical backports" archive doesn't google for me
<bddebian> heh
<lastnode> imbrandon, ping?
<bluefoxicy> Anyone know when mdz is usually around
<bluefoxicy> side question, is anyone from the kernel team here
<imbrandon> lastnode: pong
<sbalneav> I'm trying to debug some ltsp localdev stuff, so I've ugraded an edubuntu box to edgy.  Now my gnome-panel consumes 70% of my cpu :)  strace shows it to be stuck in a polling loop.  This a known issue that anyone's aware of?
<lastnode> imbrandon, got a sec?
<imbrandon> bluefoxicy: mdz is usaly arround after 7am london time or there abouts
<imbrandon> lastnode: sure
<bddebian> What the heck is diff --git in .diff files in debian/patches?
<lastnode> imbrandon, #taprobane? Ryan is there too, that's why
<bluefoxicy> 2am hm
<bluefoxicy> imbrandon:  any idea if I should ask anyone else about switching the name of the 386 kernel?
<mjg59> bluefoxicy: ?
<bluefoxicy> I saw mdz talking about benchmarking the 386 vs 686 kernels and possibly dropping the other kernels since they offer no performance increase
<bluefoxicy> and I looked, indeed, CONFIG_M486=Y; these are not i386, they're i486
<mjg59> Right
<imbrandon> probably the kernel team i would imagine benc mjg59 mdz etc in -kernel 
<mjg59> The fact that it's ever been called 386 is for historical reasons
<bluefoxicy> and i386 ubuntu is built with i486 instructions to boot.
<bluefoxicy> (cmpxchg ftw)
<mjg59> We've never supported 386
<mjg59> Nor has Debian since 3.0
<imbrandon> i386 is historical i think
<bluefoxicy> Yes.
<bluefoxicy> I don't think it would hurt to call the kernel linux-image-*-486
<mjg59> The standard kernel will be build for 586 SMP
<bluefoxicy> renaming the distro i486 would go ARGHFACYOUH@#( probably
<mjg59> The alternative kernel will be built for 486 UP
<mjg59> The *86 names will be dropped
<bluefoxicy> you're going to move to 586?  o.o
<mjg59> The standard kernel can't be 686
<bluefoxicy> I know
<mjg59> And there's approximately no performance difference
<imbrandon> not from userland apps anyhow
<bluefoxicy> There's no compelling reason to move to 586 that I can see; mdz and benc illustrated this with benchmarks.
<imbrandon> exactly
<bluefoxicy> I won't protest a move to 586 or 686 mind you
<bluefoxicy> I'm just surprised ;P
<imbrandon> now the x86 and x86_64 will still need to be seperated i think but thats a whole nother ball game
<bluefoxicy> of course
<bluefoxicy> USB printing breaks with the x86_64 kernel; and it can't be built with a fallback to x86
<mjg59> I doubt there are any 486 systems that can actually usefully run Ubuntu
<bluefoxicy> (which would be a waste of time)
<mjg59> The USB printing thing is just a bug
<imbrandon> bluefoxicy: realy ? usb printing worked afaik on mine 
<imbrandon> i need to check that
<bluefoxicy> imbrandon:  benc said something about it.
<bddebian> Anyone?  How do I properly generate a .diff file for a patching system using them?  I've never heard of --git and it doesn't even appear valid?
<bluefoxicy> If it was fixed bravo, offer the x86_64 one for x86
<imbrandon> my amd64 machine is still on breezy though so that might be part of it
<bluefoxicy> imbrandon:  32-bit userland, not 64-bit.
<imbrandon> its the file/web/nfs/nis server here at the house
<mjg59> bluefoxicy: Dude, x86_64 kernels are sort of missing x86 functionality
<bluefoxicy> it works fine with 64-bit userland.
<bluefoxicy> mjg59:  they don't BOOT on x86; but you could run 64-bit kernel on amd64 and keep 32-bit userland (flash...)
<imbrandon> ahh yea i dont have any 32bit userland stuff 
<mjg59> bluefoxicy: Erm.
<mjg59> bluefoxicy: What x86_64 one are we meant to offer for x86?
<mjg59> Oh, I see what you mean
<imbrandon> bluefoxicy: you can if you dont rely on dpkg , no dual arch support
<mjg59> No, that's still not acceptable
<bluefoxicy> mjg59:  you don't offer any now.  BenC explains this being due to USB printing not working from 32-bit userland on 64-bit kernel.
<mjg59> x86 userland depends on functionality that's not present in x86_64 kernels
<mjg59> Like vm86
<mjg59> amd64 userland has workarounds for that sort of thing
<bluefoxicy> hm
<imbrandon> isnt that a proc^Wdesign bug 
<mjg59> imbrandon: No
* bluefoxicy has seen gentooers run complete 32-bit userlands on 64-bit kernels.
* bluefoxicy shrugs.
<mjg59> imbrandon: Supporting 64 bit, 32 bit /and/ vm86 is pretty much impossible
<mjg59> bluefoxicy: They're not using vm86
<bluefoxicy> It's not within reach right now and not important.
<bluefoxicy> what is vm86
<imbrandon> bluefoxicy: me also thats why i'm confused i guess
<mjg59> Semi-virtualised x86
<imbrandon> infact i have 32bit userland in a chroot on sid
<bluefoxicy> vmware?
<imbrandon> and 64bit everything else
<mjg59> It lets applications run in something that looks like real mode under a protected mode OS
<bluefoxicy> oh what
<mjg59> Basically a compatibility kludge
<bluefoxicy> oh
<bluefoxicy> for dosemu
<mjg59> A somewhat important compatibility kludge, but still
<mjg59> On x86_64 kernels, we need to execute code in an x86 emulator instead
<mjg59> That works somewhat less well
<bluefoxicy> so you're talking about dosemu and wine, right?  :P
<mjg59> No
<bluefoxicy> then what
<mjg59> vbetool, usplash, X...
<bluefoxicy> o.O
<bluefoxicy> X is somehow tied to real mode?
<mjg59> Various chunks of X make int10 calls
<bluefoxicy> I don't remember my interrupt tables.
<mjg59> With the potential to fall back to the aforementioned x86 emulator
<bluefoxicy> mjg59:  is that a software interrupt to trigger another part of X?
* bluefoxicy guesses they set up a jump table... it's been so long since he's thought about this stuff.
<mjg59> No, it calls code in the video BIOS
<bluefoxicy> mjg59:  at any rate, on the performance stuff, I've run Dapper on 350MHz AMD K6-2 192M ram systems.  It's SLOW.  Takes 20 minutes to get into the livecd, took 5 tries to get it to finish installing without running outta memory (eventually I hacked up X to run ubiquity straight up)
<bluefoxicy> mjg59:  the video bios contains old x86 code that can't be updated then?
<bluefoxicy> (obviously it's on a hard-coded rom)
<bluefoxicy> I hadn't thought of that possibility.
<mjg59> The video bios contains old x86 code that knows how to drive the graphics card, and we don't
<mjg59> And yes, the livecd will be very slow when you don't have any RAM to use as cache
<bluefoxicy> mjg59:  is there a technical reason why vm86 can't be entered from long mode?
<mjg59> Dunno
<bluefoxicy> mjg59:  actually, I kept hitting the "Select your timezone" screen and the graphical map would force me to 2000% CPU usage and the CPU maxes at 100% and becomes 20 times slower :>
<mjg59> Linux doesn't implement it, and nor does Windows
<sbalneav> ah bug 52405
<Ubugtu> Malone bug 52405 in gnome-panel "gnome-panel eats 50% cpu for half an hour and flickers" [High,Confirmed]  http://launchpad.net/bugs/52405
<sbalneav> bad link in /etc/xdg/menu
<bluefoxicy> mjg59:  I'll file that under "fucking bad design" and make the comment that running an x86 video card on a SPARC or PPC sounds hard.
<mjg59> bluefoxicy: On PPC it's often impossible, but in those cases we have useful firmware to save us
<mjg59> On Sparc, we have x86emu
<mjg59> Alphas have always used x86 emulation to boot their graphics cards, anyway
<bluefoxicy> mjg59:  moving along, if you don't think Ubuntu is useful on 486 (maxes at what, 66MHz?  No I think my boyfriend has a 100MHz one or such...), why build it with the 486 instruction set at all?  Why not move to i586 instructions?
<mjg59> bluefoxicy: Because under some niche circumstances it might be useful
<mjg59> But not in the standard configuration
<bluefoxicy> yeah.  init=/usr/bin/adventure
<mjg59> Using the alternate CD, you ought to be able to produce a workable installation on a DX4
<bluefoxicy> nods.
<bluefoxicy> mjg59:  So here comes the ugly question.  Would such an installation be workable with GNOME and Firefox?  Or, directly, can we build Firefox for i586 in theory?
<bluefoxicy> (firefox, KDE, gnome, other big gigantic things...)
<mjg59> It's unlikely to be useful with GNOME, even building userspace for 586 over 486 wins you fuck all
<bluefoxicy> yeah
<bluefoxicy> http://wiki.ubuntu.com/ubuntu686 head towards the bottom
<bluefoxicy> https://wiki.ubuntu.com/ubuntu-i686 rather wtf.
<mjg59> Gngk.
<mjg59> Any perceived speed difference is unlikely to be due to the instruction set differences.
<mjg59> It's far more likely to be related to the rest of the crack
<bluefoxicy> yeah
<bluefoxicy> there's some nice gains in FP-emulation in i686 vs i386 (50% faster); but guess what?  We have an FPU!  :)
<bluefoxicy> the rest is statistically insignificant
<bluefoxicy> mjg59:  I'm hoping to get --hash-style used everywhere in Edgy+1
<bluefoxicy> mjg59:  also I've had various people tell me the buildd uses -Wl,-O1 everywhere, or that it only uses -Wl,-O1 in a few packages.  I'd like to know which it is.
<mjg59> cmov gains you, what? 1 instruction under optimal circumstances?
<bluefoxicy> cmov?
<mjg59> The useful 686 instruction
<bluefoxicy> what does it do
<mjg59> It's a mov that's conditional on the previous instruction
<mjg59> Avoiding you having to do an explicit check and jmp
<bluefoxicy> that sounds useful, just not ground-shakingly so.
<Chipzz> [ot]  http://forums.invisionpower.com/lofiversion/index.php/t199177.html [/ot]  :)
<bluefoxicy> mjg59:  I'll build flac with -save-temps and scan the assembly files and give you a rough significance :P
<bluefoxicy> mjg59: do you know anyone who has access to the buildd's setup?
<bluefoxicy> I would like to know the -Wl,-O1 thing, and everyone has been giving me things based on what they "know"
<bluefoxicy> but they all seem to "know" different things
<mjg59> No clue
<bluefoxicy>         cmov:   350
<bluefoxicy>         lines:  175072
<bluefoxicy>         percnt: .19991774812648510327
<bluefoxicy> mjg59:  ^^^ all of the .s files gcc emits when building FLAC without assembly optimizations.  0.2% of the instructions are escaped.
<bluefoxicy> (you said cmov saves you one insn right?)
<mjg59> Rather than jmc; mov; you can just do cmov
* bluefoxicy rebuilds for 485
<bluefoxicy> mjg59:  when and where would be a good time to discuss changes to the linker in Edgy+1?  It has to be addressed before Edgy+1 opens right?
<mjg59> Provide useful benchmarks. Write a spec.
<bluefoxicy> Michael Meeks has loads of useful benchmarks.  I can write a spec.
<bluefoxicy> Can I ream RedHat for being scum?  :<
<zul> actually redhat is quite useful for some things
<bluefoxicy>         lines:  191382 ... 16310 extra instructions when built for 486, that's 8% reduction!
<bluefoxicy> there's 860 excess lines being counted (ppc/as and ppc/gas files) ... 174212 on 686 and 190522 on 486 .. 16310 difference, 8.56% instead of 8.52%
<bluefoxicy> zul:  yeah, I just like to throw rocks at them
<mjg59> Wait. Are you optimising for the same processor in all cases?
<mjg59> Do bear in mind that not all instructions take the same number of cycles, and various other things
<bluefoxicy> mjg59: the first was built with CFLAGS and CXXFLAGS "-save-temps -march=i686" and the second with "-save-temps -march=i486"
<bluefoxicy> I could test for i486 with tune for i686
<mjg59> Yes
<mjg59> That would be somewhat more sensible
<bluefoxicy> zul:  the linker optimization thing though basically requires a swat at RedHat
<bluefoxicy> Michael Meeks came up with stuff he proposed on the binutils mailing list, after coding it, testing it, benchmarking it... then 9 months later Jakub spits out a re-hashed patch for 2 of Meeks' optimizations, and says that "the initial design was done by Ulrich Drepper; some discussion occurred with Michael Meeks, but nothing came of this and the design used is actually quite different"
<bluefoxicy> and Meeks pointed out that it looked like his prototype patches, but that he was too happy to see the stuff go in to quibble
<bluefoxicy> and I blinked and said, "Holy SHIT, they just blatantly ripped off his stuff and claimed it was theirs!"
<bluefoxicy> so yeah, I'm slightly biased at RedHat, don't mind me.
<bluefoxicy> mjg59:  176032 ... - 860 .. 175172, 960 instruction difference.  Only half a percent.
<mjg59> bluefoxicy: Right. So the big difference between the 486 and 686 is the tuning, not the instructions
<mjg59> buildds already tune for 686
<bluefoxicy> right, which brings me back to my benchmarks, which say yeah you'll get a gain on anything alike to floating point emulation, which is not much.  :)
<bluefoxicy> https://wiki.ubuntu.com/EdgyPlusOneToolchainRoadmap
<bluefoxicy> mjg59:  do you think it's safe to stick "get --hash-style support into our binutils via patch or upstream release; and use --hash-style=both" in Implementation?
<mjg59> bluefoxicy: It's safe to do anything in a spec
<bluefoxicy> or should I write a separate spec and stick "Examine usefulness of SomeSpec"
<mjg59> Note which bits are of higher priority and more likely to work
<bluefoxicy> nods
<bluefoxicy> I would love to see -Bdirect linking but it's not going to happen, there's maintenance issues with it (it breaks if you build glibc with it!) and some minor hit/miss issues (once in a while it breaks something... it also exposes bugs in stuff once in a while), which is an immediate no.
<bluefoxicy> Drepper is doing a good job of making sure it dies too.  It would threaten the usefulness of prelink, after all.
<Chipzz> bluefoxicy: with all the quarrel between redhat and novell about xen lately, it surprises me novell didn't fire back with that one
<bluefoxicy> Chipzz:  you saw that?
<bluefoxicy> yeah Meeks is a novel employee, I'd figure if they took notice they'd be like "AND YOU ARE A BUNCH OF THIEVES AU*#*" and we could all get the popcorn.
<Chipzz> bluefoxicy: if redhat ripped off suse with that gcc patch
<Chipzz> given the amounts of bad words form redhat about xen
<bluefoxicy> http://sourceware.org/ml/libc-alpha/2006-06/msg00095.html second paragraph; http://sourceware.org/ml/binutils/2006-01/msg00171.html and http://sourceware.org/ml/binutils/2006-01/msg00024.html being meeks.
<imbrandon> suse just needs to buy redhat and desolve them ;)
<Chipzz> heh
<bluefoxicy> http://sourceware.org/ml/binutils/2005-10/msg00436.html "Sorry to mail you directly Ulrich - but don't know where glibc /development cogitation occurs."
<imbrandon> speaking of suse /me needs to look at porting sax2 to ubuntu
<bluefoxicy> anyway does anyone want to keep talking politics or is there a useful topic to pick up?
<bluefoxicy> politics are fine with me; especially when RedHat's mascot is Carmen Sandiego :D
<imbrandon> lol i've had enough politics myself 
<mjg59> OH ARGH THIS IS ALL SO HORRIBLE
<imbrandon> ?
<mjg59> Bluez makes me sad
<imbrandon> heh never had a use for it so never touched it
<bddebian> Gnight peoples
<imbrandon> gnight bddebian
<mjg59> You are lost in a twisty maze of typedefs, all different
<bluefoxicy> lol
<bluefoxicy> mjg59:  what should I do with the psychotic stuff?
<bluefoxicy> https://wiki.ubuntu.com/EdgyPlusOneToolchainRoadmap updated btw
<mjg59> bluefoxicy: I recommend seeing a medical professional. The year of med school I have doesn't cover mental disorders.
<bluefoxicy> lol
<bluefoxicy> no I mean specs that are not likely to ever be carried out
<mjg59> Oh
<mjg59> I wouldn't bother mentioning them
<bluefoxicy> heh
<bluefoxicy> I've got a set that defines auditing/configuration/documentation/hardened kernel/source code auditing/hardened toolchain/vulnerability response as an organizational structure of the security team; basically I tried to mimic Hardened Gentoo
<bluefoxicy> and I'm not sure if it's ACTUALLY worth trying to make happen or if I should just sit on it
<imbrandon> zul: ping , still alive ?
<bluefoxicy> the security team already does source code auditing and vulnerability response, AFAIK
<imbrandon> Miguel de Icaza
<imbrandon> gah i hate this keymap
<kylem> 6
* bluefoxicy yawns
* imbrandon waits for kde4 kdelibs to compile again 
* nixternal whispers konvo
* bluefoxicy munches pizza and looks an at article he's writing.
<bluefoxicy> whew.  16 paragraphs.
<bluefoxicy> (my biggest one was 24; the prelink one was 15)
<imbrandon> heh, making a book bluefoxicy
<imbrandon> just teasin
<bluefoxicy> imbrandon:  just expanding my portfolio.
<imbrandon> more productive than me i guess, i'm just photoshopin my gotchi whil i wait on kde4 to finish up ( likely to be waiting a while )
<bluefoxicy> I'm learning from a couple gentoo guides and trying to persuade the LWN.net guys to let me send a series of 3 articles up (for a nominal price, of course-- this is going to pay for my Nintendo Wii) on some janitorial development tasks
<imbrandon> heh nice
<bluefoxicy> the first article fired off removing executable stacks; I spent a few days doing a number of these.
<imbrandon> yea i read a little about the gcc linking before you talked about it, was kinda funy i ran accross it twice in 2 days
<bluefoxicy> I also want to get in fixing code to compile PIC when it doesn't want to (how I'm going to make an ARTICLE about that I have NO idea; it's basically "do not use %ebx when doing assembly"); and removing ELF .text relocations (I can make a full article on this; the security considerations are amusing too)
<bluefoxicy> actually I can probably do the PIC thing
<imbrandon> heh
<bluefoxicy> instead of using registers you can declare variables and have gcc use them; I should probably explain the syntax.
<bluefoxicy> obviously the readers will include people who broke the shit in the first place; I understand LWN's audience is technically adept, but I'm CLEARLY discussing something they NEED to know.  :>
* bluefoxicy fixed the textrel in SDL the other day; Gentoo has had a patch for it forever though, so use theirs.
<imbrandon> ;)
<imbrandon> moins jdub
<jdub> yo
<jdub> pants off
<imbrandon> err i guess afternoon for you ;)
<jdub> word to yo momma
<jdub> <- back from paintball
<imbrandon> heh fun, i love paintball
<bluefoxicy> pants off wtf?
<bluefoxicy> this isn't #mutual-m.... wait, this place is full of computer nerds.
<lastnode> imbrandon, ping?
<pygi> hey hey pitti 
<Hobbsee> hi pitti 
<pitti> hey pygi
<pitti> hi Hobbsee 
<Hobbsee> :)
<pygi> pitti, whenever you feel ready to burn cd with k3b without cdrecord :)
<pygi> rather one day when it's not weekend :)
<pitti> pygi: heh, I have never used k3b :)
<pitti> pygi: I had used a simple cdrecord alias for years, and then nautilus-cd-burner for the sake of dogfooding
<pygi> pitti, ah,oki :)
<pitti> yes, and right now I'm just preparing my laptop for the sprint and pack my stuff
<pygi> :)
<imbrandon> moins pitti
<imbrandon> and pygi ;)
<pygi> hey imbrandon 
<pygi> imbrandon, ll eat you, you know that, right?
<pygi> and you know why,also :P
<imbrandon> heh , sorry benn slackin
<imbrandon> i should get to that tonight
<pygi> imbrandon, I hope :)
<Goshawk> hi,  why the file /etc/lsb-base-logging.sh is part of lsb-base in ubuntu ( http://packages.ubuntu.com/cgi-bin//search_contents.pl?version=edgy&arch=amd64&case=insensitive&word=lsb-base&searchmode=filelist ) while in debian it's part of the package usplash? ( http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=usplash&version=unstable&arch=amd64 )
<doko> pitti: http://librarian.launchpad.net/3935558/buildlog_ubuntu-edgy-i386.dpkg_1.13.22ubuntu6_FAILEDTOBUILD.txt.gz
<pitti> doko: thanks
<pitti> doko: something to hack on in the train tomorrow :)
<Tonio_> hi
<_ion> Hola.
<doko> infinity, cprov-afk: please requeue cairo-java on sparc
<sladen> "We also believe in proper law enforcement as cyclists are much more likely to be victims, rather than perpetrators, of bad road use."
<sladen> "We also believe in proper law enforcement as cyclists are much more likely to be victims, rather than perpetrators, of bad road use."
<\sh> moins
<imbrandon> heya \sh
<pygi> hey \sh
<irvin> hey \sh 
<cprov-afk> doko: done
* \sh needs some help in debugging a weird grub problem...
<doko> cprov-afk: thanks
<_ion> Re: https://wiki.ubuntu.com/LibAtaForAtaDisks; don't v1 swap partitions have UUIDs as well? Why aren't they listed in /dev/disk/by-uuid?
<sladen> nice.  2.6.17 crashes if you insert an PCMCIA IDE disk
<_ion> keybuk: Thoughts?
<_ion> Whoops, he isn't online.
<lastnode> anyone used the httplib python module here before?
<_ion> keybuk: Any thoughts? 151543 < _ion> Re: https://wiki.ubuntu.com/LibAtaForAtaDisks; don't v1 swap partitions have UUIDs as well? Why aren't they listed in /dev/disk/by-uuid?
<Keybuk> _ion: ever tried activating a v1 swap partition? :)
<Keybuk> you'd have to patch the kernel to support them again
<_ion> keybuk: Isn't v1 exactly what is used currently? :-)
<_ion> v0 is the old swap format.
<Keybuk> err, yes
<Keybuk> sorry
* zyga learns about swap partitions having a format :)
<Keybuk> in that case, yes v1 swap partitions may have UUIDs
<Keybuk> and if they do, they will show up in /dev/disk/by-uuid
<Keybuk> note *may* ... the installer never used to set one
<_ion> % dd if=/dev/zero of=swap bs=1M count=2; mkswap swap
<_ion> no label, UUID=d1937c2d-9b46-4675-8eef-159721d50d35
<Keybuk> one of the things that the uuid conversion does is add a UUID to any swap partition that's missing one
<_ion> Seems like a UUID is generated by default.
<Keybuk> right, by mkswap
<Keybuk> d-i doesn't use mkswap :)
<_ion> Oh, okay. :-)
<Keybuk> syndicate scott% cat /proc/swaps
<Keybuk> Filename                                Type            Size    Used    Priority
<Keybuk> /dev/hda5                               partition       1622524 0       -1
<Keybuk> syndicate scott% udevinfo -qsymlink -nhda5 
<Keybuk> disk/by-id/ata-HTS548040M9AT00_MRL242L2HA7L9B-part5 disk/by-path/pci-0000:00:10.0-ide-0:0-part5 disk/by-uuid/49fbf0dc-412a-4a8b-8469-6fa41cf9b78a 
<_ion> How to add an UUID to a swap partition by hand?
<Keybuk> uuidgen | perl -ne 's/-//g;printf "%c",hex $1 while(/(..)/g)' dd conv=notrunc "of=$DEV" obs=1 seek=1036
<Keybuk> (replace $DEV)
<_ion> Thanks.
<Keybuk> err
<Keybuk> uuidgen | perl -ne 's/-//g;printf "%c",hex $1 while(/(..)/g)' | dd conv=notrunc "of=$DEV" obs=1 seek=1036
<Keybuk> :p
<_ion> Is the edgy UUID conversion code available from somewhere?
<Keybuk> /var/lib/dpkg/info/volumeid.postinst
<_ion> Thanks again. :-)
<_ion> keybuk: Btw, the perl code in a slighty shorter (and one might say clearer) form: s/-//g;chomp;print pack("H*",$_)
<lastnode> infinity, ping?
<lastnode> imbrandon, ping?
<imbrandon> pong
<sladen> Keybuk: can that be added to mkswap ?
<bddebian> Howdy
<Keybuk> sladen: it could I guess
<bddebian> Morning Keybuk
<lastnode> imbrandon, there is this insane problem with httplib and urllib - t seems to cap the data after a certain number of bytes
<lastnode> returns 200 OK, but no data goes across
<imbrandon> hrm ok i'm about to head out soon i'll look when i get back
<lastnode> ok cool
<lastnode> thanks mate
<sladen> Keybuk: that would be most useful, people are more likely to use that to create swap partitions than the 'postinst' :)
<Mez> Kamion: pinh
<Mez> s/pinh/ping/
* Mez waves at Keybuk
<bddebian> Whoa, heya Mez
<Mez> bddebian, hello :D
<sladen> Keybuk: btw, do all the other mk.* creation tools generate a UUID automatically?
<bddebian> Anyone have the patience/time to explain the 0c2a transition crap to me?
<azeem> why should anybody want to explain crap to you?
<Nafallo> hehe
<bddebian> azeem: Becuase I try to help?
<azeem> bddebian: maybe, but calling things people put in a lot of thought "transition crap" won't help a lot
<azeem> I'm sure people will gladly answer if you ask a specific question about that transition
<bddebian> Did I say that their work was crap?  NO.  It's merely an expression.
<tseng> bddebian: you did, actually
<tseng> whether you think so or not
<bddebian> How so?
<tseng> "transition crap", pretty clear
<tseng> it helps to understand that someone might interpret something you wrote differently
<tseng> esp if they aren't native USians
<tseng> who say crap as a manner of speech all day
<bddebian> Gah, bbiam
<bddebian> OK, how about can someone please help me understand this ingenious wonderful 0c2a transitions stuff?  Better? :-)
<azeem> bddebian: what part did you not understand?
<bddebian> Well I got the concept but now I'm not sure how to handle something like osgcal
<bddebian> We did libosgcal0c2a because of the C transition
<bddebian> But now Debian is using the same toolchain (I think).  Do we revert back?
<azeem> Debian was doing c2a as well
<bddebian> Aye but for osgcal I only ever see a libosgcal0 not c2a
<pygi> will  be be dropping cdrecord as well, and use forked cdrtools?
<bddebian> azeem: I guess what I am asking is that if I merge osgcal from Debian, I am going to have to deal with conflicts/replaces, etc for the libosgcal0c2a stuff right?
<bddebian> See, it's crap to me because I'm too dumb to understand it :-)
<geser> if you merge it as libosgcal0 you must conflict/replace libosgcal0c2a
<bddebian> geser: That's what I thought, thanks
<geser> it's because both packages provide the same files
<bluefoxicy> man my hard disk is cranking.
<bluefoxicy> I need review for a spec I am going to try to propose for Edgy; is it automatically in the queue, or do I need to do something
#ubuntu-devel 2006-08-20
<pygi> hey ho neuralis 
<neuralis> hey there
* pygi cries
<_ion> * cry pygies
<pygi> _ion, no, really, this hurts very much
<_ion> What?
<pygi> _ion, are you sure you wanna know? :)
<pygi> _ion, it's about SoC, one of the students...
<_ion> Something tragic? :-(
<pygi> _ion, no, he's kinda blackmailing me
<_ion> Oh. :-(
<pygi> _ion, he made me talk with his wife even, I mean what...
<pygi> doko, poke
<pygi> you have time for me?
<pygi> I am in a middle of a crisis
* pygi wonders who else is SoC admin
<shackan> what happened?
<pygi> shackan, I wouldn't go in public anymore, altought you can scroll up if you really want
<shackan> I see
<doko> pygi: pong (going to bed in a few minutes ...)
<pygi> doko, ok, enjoy then
<Kaleo> does anybody know why there is no jigdo file for the live cds ?
<Kaleo> it would be awesome for testing
<sladen> Kaleo: the live CDs are just-a-big-500MB-file
<Kaleo> oh, inside the cd there is just this big file ?
<lastnode> imbrandon, ping?
<Burgundavia> mdz: can we get some spam filtering on the -owners mailing lists?
<lastnode_> imbrandon, ping
<imbrandon> lastnode_: wasup ?
<lastnode_> imbrandon, just to let you know im online for the day and am free for a brief chat whenever
<imbrandon> k
<lastnode> imbrandon, i encounter this wierd error where httplib puts a cap on data being sent via POST
<lastnode> so i wrote a fallback function that calls on curl, like before
<lastnode> ideally though, httplib would be the best, i reckon
<imbrandon> k
<lastnode> imbrandon, new source mailed to you
<imbrandon> okie cool
<lastnode> imbrandon, one super quick design related question when you have a sec :)
<lastnode> bah, i keep pinging people and timing out :\
<gorilla> Hi All, this might be off topic but is there a guide on backportting a package from edgy to dapper myself?
<dsas> gorilla: Not that I know of, checking the packaging guide at http://help.ubuntu.com/ may give some hints, and also searching the wiki.
<gorilla> dsas, thanks.
<dsas> gorilla: It should be just link syncing a package, but with a modified upstream tarball. Someone in #ubuntu-motu may know more.
<gorilla> motu?
<dsas> the Masters of the Universe - they're responsible for the universe + multiverse repositories.
<gorilla> oh :-)
<Bader> hi
<Bader> I've reported a bug 3 months ago and since nothing happened
<Ubugtu> Malone bug 3 in rosetta "Custom links for each translation team." [Wishlist,Confirmed]  http://launchpad.net/bugs/3
<Bader> Could someone change the status of #55291 and its importance ?
<Seveas> bug 55291
<Ubugtu> Malone bug 55291 in libextractor-python "Wrong version of package" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55291
<dsas> Bader: Is that bug filed with debian too?
<Bader> no
<Bader> it should but I don't know how to file it and thought that the bugs were backported to debian...
<dsas> You have to email debian to create bugs (see http://www.debian.org/Bugs/Reporting) I was just wondering, because this presumably is broken there too. 
<dsas> It's easier for us if debian has the fix yes, doesn't matter which way round it goes though.
<Bader> it's broken too since it's the original debian package
<dsas> Bader: Ok, I'll submit a debian bug then.
<Bader> thanks
<dsas> Bader: it seems debian have a newer release than ubuntu (see http://packages.debian.org/changelogs/pool/main/libe/libextractor-python/libextractor-python_0.5/changelog) is this the one that's fixed?
<Bader> dsas: yes
<dsas> Bader: Ok, i'll ask for a sync then.
<msikma> Hey guys, I'm from the Ubuntu art team, and I'm wondering if this is possible to create (splash screen): https://wiki.ubuntu.com/Artwork/Specs/EdgyArtworkPlan/Produce/Incoming?action=AttachFile&do=get&target=splashmichiel.png
<msikma> E.g. the text is in a slightly different place, as are the icons.
<sivang> lifeless: Rob, your email is your IRCNICK@ubuntu.com ?
<sivang> lifeless: some corrospondence between me and Etienne about lp-dependencies and I want to keep you in the loop.
<lifeless> sivang: no, robert at ubuntu dot com
<sivang> lifeless: cool, thanks
<lifeless> or robert dot collins at ubuntu dot com
<lifeless> or ... many others :0
<sivang> heh
<lifeless> Search for my name in google ;)
<msikma> Is there any dev from here willing to lurk in #ubuntu-artwork? We're working on polishing the artwork for Edgy, but too often we're left wondering whether something is possible or not.
<sivang> msikma: without being an authoritive answer or anything, just from my opinions, this screen short you pasted the URL too looks nice :-)
<msikma> Thanks :) But I really wonder whether the text can be further down that thing, otherwise I'd have to darken the splash image to ensure it's readable.
<sladen> Micksa: it looks like mdz is already in there.  Generally the secret is to highlight the nickname of the person you're after a response from by starting the line with  name: 
<sladen> msikma: ^^ ...assuming you address it to the right person :)
<msikma> I didn't know mdz was a dev
<msikma> Haha
<tseng> msikma: the text is drawn at the bottom of the image
<tseng> msikma: as its a png, you might be able to make a rectangular area at the bottom, transparent
<tseng> msikma: give it a try.
<msikma> tseng: but the background can be different, right? In my example, it's the typical default red/brown, but users can make that different?
<msikma> Ah, so it accepts 32-bit PNGs?
<tseng> I would assume
<tseng> anything else in gnome does.
<msikma> That way, it would be fixed quite easily.
<msikma> Thanks :)
<sladen> msikma: you can check out his virtal stats at  https://launchpad.net/people/mdz  don't be put off by the eyes, I think it was a full-moon that night
<msikma> Oh, there is one last thing that I wanted to ask. I've been working on a modification of the Human GTK theme. Do you think that it is possible to get the rounded edges of a window to be anti-aliased, like in this mock-up? https://wiki.ubuntu.com/Artwork/Specs/PolishHumanGTKTheme/Incoming?action=AttachFile&do=get&target=michielgtk12.png
<tseng> msikma: no.
<msikma> Not even with an image?
<tseng> not with metacity on standard X, anyway
<_ion> With Xgl + compiz, antialiased rounded window edges are already here.
<msikma> I don't really know how the system internally works, but it's true you can add images to the metacity, right? So I couldn't just use a 32-bit PNG?
<msikma> _ion: ah, I guess that is true. But then people would have to have them installed.
<_ion> The default X and the default Metacity do not do any compositing.
<tseng> i dont think you can add an image for the corner
<tseng> or someone would have already done this
<msikma> That's too bad :(
<msikma> Non-anti-aliased corners are so 1984
<tseng> the images are mainly the buttons on most themes
<tseng> and the bar is some combination of gradients
<msikma> So I guess that I'm stuck with aliased corners, then.
<tseng> we've lived this long
<tseng> it isnt exactly the worst problem we have
<_ion> msikma: Or switch to Xgl + Compiz. :-) But that's offtopic for this channel.
<msikma> Well, the thing is, though, it's a pretty annoying thing for the artists. From our perspective, Windows Vista will have anti-aliased corners, Mac OS X already does, and Ubuntu is going to be left behind a little bit. It's just a thorn in the eye since everything else is nicely anti-aliased.
<sivang> lifeless: oh! I see you now have an online and computer software version of the dictionary :-)
<lifeless> sivang: yes;0
<sivang> lifeless: btw, this is yours - http://www.ri.cmu.edu/people/collins_robert.html ?
<lifeless> no
<sivang> lifeless: k
<lifeless> theres at least two other Robert Collins's in open source
<sladen> msikma: the rounded corners are done with a 'mask', a grid of noughts and ones saying which pixels to lay down and which to 'punch out'.  There already a slight performance overhead from using that as it is.
<lifeless> but only one in squid/ubuntu/vcs 
<lifeless> however the first and third hits are me
<sladen> msikma: the secret is to make the corners look *good* even with that constaint, eg. to antialias against 50% (the normal background) and then to clip the result
<msikma> Still, just being able to do that with 2-bit transparency would be infinitely better
<tseng> meh, try it
<tseng> i am not sure why you expect us to know more about theming tricks than you
* sivang - > out (food)
<msikma> I don't know anything about how stuff internally works, unfortunately.
<sladen> msikma: 2-bit transparency is like mixing paints.  It's not actually transparency at all, what to have is a switch that says whether to fetch pixels from the left, or from the right
<sladen> msikma: sorry, "what we have is a switch that"
<msikma> From the "left or the right"?
<sladen> msikma: imagine two separate pictures hanging on the wall.  You have a choice for each final pixel whether you take it from the left, or the right picture
<sladen> msikma: one of those is your window, the other is the background---the 'rounded corner result' is the combination of taking one *or* the other (but not both) for each individual pixel
<msikma> Ah, so you just mean one from the top or the bottom.
<sladen> msikma: yes, that's why it's 1-bit.  It's a switch
<sladen> msikma: rather than a fader
<msikma> I do get how that works, but I just think that reworking it to have more comprehensive transparency would be a lot better, from an artist's point of view. It's just very old-fashioned, from my perspective, to have 1-bit transparency.
<sladen> msikma: oh, better analogy.  The light-switch in your living room, can either be on, or off.  It's can't be half way
<sladen> msikma: (unless you have a dimmer---but that would need an upgrade of the wiring electronics, which we don't have, except for compiz)
<_ion> msikma: The technology is already implemented with open source. It just needs to mature before it can be switched on by default for appropriate hardware.
<msikma> _ion: and by that, you mean compiz?
<sladen> msikma: it's is old fashioned.  It's a standard from about 1987 :)
<msikma> http://bugzilla.gnome.org/show_bug.cgi?id=345249 <-- I did file this report a while back...
<_ion> msikma: Actually xgl/aiglx is what makes it possible, compiz just makes use of it.
<msikma> Aha
<Ubugtu> Gnome bug 345249 in general "Window edges anti-aliasing request" [Enhancement,Unconfirmed]  
<msikma> Still, the thing is: we already have, for example, cursors that have 8-bit transparency, and the corners of a window certainly aren't that much larger than a cursor (unless you have an ungodly amount of windows open) so it would seem to a non-programmer like me that the overhead shouldn't be _too_ large.
<msikma> Well, I guess I'll just have to work around it.
<infinity> msikma: Cursors have a defined background.  Windows have to compose their background based on the other windows they're stacked on.
<infinity> msikma: The latter is much more effort.
<infinity> Oh, wait, I read "cursors" as "icons".
<infinity> We have 8-bit transparency in cursors?
<msikma> Yeah, the shadows are 8-bit transparency, I think.
<sladen> infinity: yeah, normally done in software as a result though, which is why the cursors 'lags'
<msikma> In any case, I believe that cursors are made by collecting 32-bit PNGs and then changing them into a different format.
<sladen> msikma: correct.  Cursors are also *always* at the top of the stack
<sladen> msikma: the transparent corners thing is easy when it's just a background and the window.  But imagine having 10 semi transparent  windows overlapping in different ways----that's when the problem gets hard; and the solution for that is to switch to a different method.  Unfortunately, that method isn't available everywhere yet
<sladen> msikma: just like not everyone has 21" monitors;  we have to produce something that looks good on both
<msikma> What about enabling it on those systems of which we know it will run?
<sladen> msikma: that's the idea.  But we *still have to make it look good* on the systems that can't
<msikma> Sure. So they will just see the aliased edges.
<msikma> Which isn't too bad either.
<lastnode> infinity, ping?
<sladen> msikma: basically at the moment you need to have XGL (which crashes as much as somebody learning to ski) or AIGLX which requires extensions to the X servers.  Currently the only cards fast enough are Intel, Nvidia binary, or ATI binary;  and we don't enable the binary drivers by default
<sladen> msikma: I think the edges were solved under 6.06 by having a 1 pixel black line around the edge, which instead creates maximum contrast and still looks good
<msikma> Actually, I think that it looked terrible. Which is partially why I went here to ask if anything better was possible. :P
<msikma> To put a black line around the edge actually seems like the opposite of what I would do. Which is to make an as clean transition between the metacity and the edges of the window as possible.
<infinity> lastnode: Hey, dude.  I vaguely recall that you wanted to talk to me about something or other, but I'm also thoroughly enjoying my weekend here. :)
<lastnode> infinity, sure mate, laters. :) have a good one!
<infinity> msikma: Given the technical limitations, I always felt that having rounded corners in the dapper them was just a mistake, period.
<msikma> Me too. I would actually much rather use non-rounded ones simply to get past this limitation. But it seems that some people disagree.
<lastnode> imbrandon, ping?
* lastnode goes back to python
<msikma> Something about Ubuntu being all about rounding, which I don't think makes much sense. If they want to define Ubuntu, they can't just say "Ubuntu is this and that, and that's why we need *insert random thing here*".
<infinity> Well, I'm also generally offended by rounded corners on windows, since the windows themselves are rectangular.  But I'm just anal about cleanliness.
<msikma> You should frequent the Ubuntu mailing list or IRC channel!
<msikma> Er, *art mailing list
<infinity> That would probably drive me insane. :P
<tseng> my participation for the artwork usually involves downloading the art from SuSE
<tseng> and changing it all as quickly as possible
<infinity> I'll just keep programming, and be (un)pleasantly surprised when a new default theme is shoved down my throat every few months.
<imbrandon> lol
<lastnode> i prefer non-rounded as well, but a lot of end users love rounded for some reason
<lastnode> i think from a design perspective rounded comes across as more "friendly" and "warm"
* imbrandon sticks to his purdy kwin
<tseng> I understand that isnt helpful, but I quickly tire of the lengthy arguments over art
<infinity> Yeah, I don't get it.  On WinXP machines, the first thing I do is switch back to the Windows Classic theme.
<msikma> I've been tempted to join #ubuntu-art for a long time.
<msikma> Since 5.04.
* lastnode removes tongue from cheek
<lastnode> infinity, ahaha, me too :)
<lastnode> but that's because the blue reminds of the BSOD
<lastnode> and i flash back to pre-puberty and windows 95 :s
<msikma> I just didn't want to join because I felt Ubuntu Artwork was pretty okay. But then Dapper came out.
<infinity> It's the massive waste of space from the huge rounded titlebars that annoys me.
<msikma> I think Dapper was a **major** step down.
<msikma> Art-wise.
<infinity> Dedicating all that space to widgets is annoying, especially on my 800x600 craptop.
<lastnode> msikma, pretty much everyone ive met has said otherwise though (end users)
<sladen> msikma: right it sounds like edgy will have a great theme to improve on it
<tseng> msikma: i dont know.. my suse art still looks great
* StevenK misses the discrete, little "<logo> ubuntu" on the desktop background.
<lastnode> infinity, on 800x600 id prefer if there were _no_ tutlebars
<msikma> Well, all they got to do is listen to me and all will be fine in the end :P
<sladen> msikma: I didn't mind the 6.06 theme once the gawd-aweful bright orange was toned down
<lastnode> didnt someone do a blog post of the progression of ubuntu art?
* lastnode goes to look for it
<msikma> sladen: that's my main issue.
<msikma> The window title is way too bright.
<msikma> I sometimes seriously have trouble reading what a title says.
<msikma> Then there's the non-existent-but-still-somewhat-existent window border (at the left, right and bottom). I just don't really see that as a good option.
<msikma> Then there's one last thing. I really think that Tangerine looks better than Human. There are just a couple of serious design mistakes that the authors of Human have made that simply make it less usable.
<msikma> Apparently, Human is the default because Ubuntu needs to look "unique" and "specific". As if the entirety of the artwork that has been made for it isn't already unique enough. Tangerine itself is unique to Ubuntu, too. I feel that if they want to use the artwork to market Ubuntu (i.e. "unique" is definitely a marketing decision), they should not harm the visual integrity of the system in order to do so, since that's just plain wrong.
<msikma> Marketing can be done in other fields than the icons, of all things.
<tseng> mark objects to the tango style in general
<msikma> But well, that's JUST ME.
<lastnode> has anyone got a sec to try out a wee python script? :)
<tseng> but if someone were to make a nice consistant set of themes
<msikma> If he objects to the Tango style, why is he letting a team remake Tango in raster and with sometimes just slight differences? The only icons that are _really_ different than the Tangerine equivalents are the folder icon and internet icon.
<tseng> that werent hideous colors and based on human icons
<sladen> msikma: Ubuntu has a pretty good trademark --- "brown"
<tseng> it might be able to go somewhere
<msikma> The thing is.
<lastnode> in most cultures society, brown signifies, the earth, something primeval, and i think that works for ubuntu
<msikma> What is the point of remaking, for example, the icon for services? Or the icon for the theme config panel?
<msikma> All the Human designers are doing is remaking those icons that are already in Tangerine and making it slightly different.
<msikma> And worse than the original, and not in vector.
<lastnode> it's a nice change actually, in an age where everyone is going for flashy, plasticky, bright greens and blues
<sladen> msikma: more to the point, why are they remaking them in raster?
<tseng> are you familiar with the term 'preaching to the choir'
<sladen> tseng: :)
<msikma> heh
<tseng> we are not artists however
<tseng> so we sit here and live with it, or very quickly swap themes
<msikma> I believe that Human might be a good thing. But it should not remake icons that are perfectly okay already and do not have _any_ use being slightly different to _anyone_, especially not the end user.
<msikma> Human should just be an extension to Tangerine that aims to change only a few core icons such as the folder icon.
<tseng> human will never mix with a tango base in its current form
<tseng> so its not really good in that case either if you ask me
<tseng> yeah, Industrial from SLED changes a half dozen icons
<msikma> Human is just ugly. Take the arrows. The reload arrow has a bogus size. The left/right arrows have no edges and a thick drop shadow. This completely ruins the contrast between the edges of the physical aspect of the arrow and the shadow itself.
<msikma> And the guys that are making it have the full support of Mark, are getting a whole bunch of money, and don't even work fast (how long has Human been in progress now?)
<msikma> It seriously makes me angry.
<tseng> who's getting money?
<msikma> oxygen-icons.
<msikma> http://www.oxygen-icons.org/
<tseng> what mark does with his money is his own business
<msikma> Indeed, but he's also making the system look less good while doing it. From an artist's perspective.
<tseng> what we do with ubuntu is somewhat open for debate
<tseng> w/i the schedule
<msikma> But apparently, it's "marketing" he's after. "Marketing" with icons is next to useless.
<msikma> I tried debating it on the mailing list but the discussion was hushed.
<tseng> yeah it is
<tseng> jimmac wrote on this
<msikma> Apparently "the decision is made", and "the decision is not up to you".
<msikma> He did?
<tseng> yes
* tseng looks
<tseng> you could argue its a biased source
<tseng> but he's been the key gnome icon developer since forever
<msikma> The bottom line is that Jimmac is a better designer than oxygen-icons.
<msikma> Look at their site. I'd say it looks awful.
<tseng> I agree
* Hobbsee notes that the oxygen icons will be being used in kubuntu.
<tseng> but again, I already knew human sucked 2 years ago
<msikma> They're just inferior designers and thus they might be able to pixel-push pretty well but they simply can't make icons as good as Jimmac can.
<msikma> I still wonder if it is possible to open up a discussion about this.
<tseng> yes, oxygen is pretty kde centric
<tseng> afaik
<tseng> msikma: it would be a disaster
<msikma> I remember there was once a community poll that got hundreds of votes with Tangerine winning.
<Hobbsee> tseng: indeed
<tseng> tangerine is a hack
<tseng> I don't see a reason to repaint everything in a bad orange shade
<tseng> beyond a few icons
<msikma> I agree. Just the core icons need to be remade in orange style because that's what's considered to be necessary (I also somewhat disagree but that, but whatever).
<tseng> things were made distinctive colors for a reason
<tseng> anyway, the only way to have a useful discussion at all is to do something better
<msikma> What I don't understand is why Human is remaking all the tiny icons as well that nobody really cares about. Honestly, ask anyone if they care whether their screen resolution icon looks like Tangerine or like Human. But still the Human makers are remaking those icons because they get paid for it.
<msikma> Tangerine is something better than Human.
<msikma> But it's still rejected.
<tseng> i am not sure its 'rejected' outright
<tseng> its int he default install
<tseng> and the fallback for human
<msikma> Why should anyone do something better if it'll just end up being rejected? It doesn't exactly give me a comforting idea that a _better_ design is not favored over a _worse_ design.
<tseng> tango/tangerine and human are slightly different in aim, if you get me
<tseng> human ~= industrial
<msikma> tseng: it's not the default icon set, thus it is rejected to me.
<tseng> industrial rethemes a few things in tangerine
<tseng> er, tango
<tseng> tango is the base of other themes
<tseng> not the default
<msikma> Human, an inferior icon set, was chosen over Tangerine, which I consider a big failure. I weren't around when the decision was made, but it would appear to me that most artists these days simply prefer Tangerine.
<tseng> im not sure you are getting me
<msikma> Tango is the base, I get it. And Human extends that base.
<msikma> That's what you're saying, right?
<tseng> "extends" is taken pretty loosely there
<msikma> But Human is an inferior extension.
<tseng> human has no relation to tango though
<msikma> And the decision to use it is backed by an extremely important guy who is _not_ a designer. That's what burns me the most.
<tseng> you make a few tango-styled icons on top of tango
<tseng> and be done.
<tseng> msikma: welcome to the club pal
<msikma> That's what Human should be, indeed.
<msikma> And it's not like oxygen-icons is ever gonna tell Mark "hey man, we remade a few core icons, and it should be fine now." because they want to keep getting paid.
<tseng> i have never seen anyone suggest that oxygen be the ubuntu icon theme
<tseng> mark can do as he wishes with his money
<msikma> I mean the company oxygen-icons, who are making Human.
<tseng> (they are?)
<Lure> msikma: oxygen icons are for kde4 and I doubt they are sponsored by Mark
<msikma> Yeah, it's been mentioned on the list a few times and they've sent mails.
<Hobbsee> Lure: we are having them in kubuntu though.
<Lure> Hobbsee: not until kde4 (due to license)
<Hobbsee> Lure: oh really?  i thought it was all gpl'd :(
<Lure> Hobbsee: no, intentionally they do not want releases before kde4 big-bang
<Hobbsee> Lure: oh i see.  darn
<Riddell> Lure is correct.  not sure what msikma is on about
<Hobbsee> Lure: didnt know that, thanks
<msikma> I don't mean the Oxygen Icons.
<msikma> I mean the COMPANY that is called Oxygen Icons. Or perhaps they're called differently, but that appears to be their site.
<msikma> Actually I'm maybe just very wrong.
<msikma> I don't know anymore.
<Riddell> msikma: oxygen is an icon theme. is made by volunteers for KDE 4, it's not funded by anyone
<Riddell> actually it was funded by SuSE at the start
<msikma> Well.
<msikma> Anyway, I think that I've made my point.
<msikma> :P
<tseng> you haven't done much of anything but gotten me to agree with you
<msikma> Well, that's one thing.
<tseng> nothings changed.
<msikma> That's for the future.
<msikma> If only I knew how to package icons sets. I'll look into that later.
<o_cee> anyone from the vmware team around?
<o_cee> just wondering if there's a new version of vmware-player-kernel-modules on its way for 2.6.17-6
<infinity> o_cee: We're going to be adding the vmware modules to rhe linux-restricted-modules package in the next upload, so there won't be a seperate package anymore.
<o_cee> infinity: sounds great. any eta on when that will be, soonish? won't bother fixing it temporarily then.
<infinity> o_cee: Next few days.
<o_cee> infinity: ok, thanks, will wait for that then :)
<bddebian> Howdy
<Yagisan> infinity, will that conflict with other vmware installs eg vmware workstation or server ?
<StevenK> Yagisan: Certainly not.
<StevenK> Vmware calls their modules different names for differing installs.
<Yagisan> StevenK, just wanted to make sure *before* possibly breaking my system
<StevenK> Yagisan: It's more fun if it you do it *after*.
<StevenK> s/it //
<Yagisan> StevenK, that was my breezy -> dapper upgrade of a live webserver. I'd rather not do that again o_O
<Yagisan> anyhow me >offtopic and going to bed
<Terlmann> do you people EVER FINISH a OS?*groans loudly in pain, bites on fingers..*
<Terlmann> Gonzo: list
<Terlmann> [PUPPETS] Gonzo: list
<Terlmann> hmm
<gorilla> Terlmann, you won't be missed.
<nowlin> hey everybody. when will the ned ati drivers enter edgy? im getting conflicts whit the new xorg
<nowlin> hey everybody. when will the ned ati drivers enter edgy? im getting conflicts whit the new xorg
* pitti waves
<Gloubiboulga> hi pitti 
<_ion> loop { 0.upto(359) {|i| self.hand_angle = i.to_f / 180.0 * Math::PI } }
<zul_> hey pitti 
<pitti> hi zul_ 
<sivang> hey pitti 
<simira> pitti: are you "here" now?
<sivang> infinity: what's that?
<sivang> oops
<sivang> I meant,
<sivang> _ion: what's that?
<pitti> simira: yes, in Wiesbaden
<pitti> hey sivang 
<Nafallo> sounds like beer :-)
<sivang> hey pitti , already in the distro sprint ?
<_ion> sivang: It's another way of saying "/me waves". :-)
<pitti> sivang: yes, arrived an hour ago
<sivang> pitti: so it will be during this week until the 27th ?
<pitti> sivang: yep
<simira> pitti: ok, I was having siesta then. See you in another half, I guess :)
<sivang> simira: you also in the distro sprint ? :)
<simira> sivang: yup. For some reason. I am probably not sprinting anything but ubuntu-no issues, I believe
<sivang> simira: Cool, If I were in EU, I would most certainly hop in for a visit myself.
<sivang> simira: and maybe grab mvo to help me some bits with home user backup's notification stuff 
* pitti restarts his session to fix the (*#$#*($# gnome-terminal
<simira> sivang: mvo's busy solving my update-manager bugs! Do you get anywhere abroad easily now, anyway?
<sivang> simira: easily as any one else complying with the new rules for flying, however, being on another continent makes the trip expansive and troublesome of just a quick visit.
<sivang> s/of/for/
<sivang> pitti: do you know if Sebastian Heinlien will also be there?
<pitti> sivang: no idea, but I suppose not; look at the wiki page
<bSON> font rendering suddenly got SIGNIFICANTLY better with the last dapper update, what did you do?
<Seveas> pitti, are you at the sprint hotel?
<pitti> Seveas: yes
<Seveas> pitti, would you mind doing /reconnect to test whether lilo didn't mess up with the k-line proof settings -- if you can't come back on: dennis@ubuntu.com/+31625235346
<robertj> random thought: has anyone investigated the possibility of putting pastebin in the base install? Usually I'm against this kind of thing, but it is 8k...
<zul_> there is other things to think about other than space to go into main but no 
* bluefoxicy continues to advocate attempting to get a functional system in under a gig!
<robertj> bluefoxicy: I wouldn't call living with pastebin living...
<robertj> err living without :)
<bluefoxicy> robertj:  ditch w3m, add links2, http://rafb.net/paste/ ?
<bluefoxicy> (why we have w3m is beyond me; has anyone tried to use the damn thing?)
<robertj> pah, we've got telnet, who needs a web browser too
<bluefoxicy> ditch telnet
<bluefoxicy> we've got netcat
<robertj> your right
<keescook> bluefoxicy: however will you negotiate telnet terminal settings?  ;)
<bluefoxicy> keescook:  if you can use telnet for a web browser, then you can use netcat for an ad-hoc terminal.
<bluefoxicy> subject to the same obvious implications.
<keescook> heheh.  :)
<bluefoxicy> where the fucking hell is-- ah, there it is, segment 13
<bluefoxicy> text: 002b04  rodata:  000b68 data: 000040 bss: 000138   total: 37e4
<bluefoxicy> converting to decimal..........
<geser> hello
<geser> could someone trigger a rebuild of gnome-mag?
<geser> the last failed because of a transient failure at libatspi-dev
<geser> hello
<geser> if a package build fails (on all archs) could it be retried again or is a new upload necessary?
<sladen> geser: why is it failing?
<geser> because a build-dependency wasn't installable at that moment but it is now again
<geser> it's about gnome-mag
<geser> see the build log http://librarian.launchpad.net/3949388/buildlog_ubuntu-edgy-i386.gnome-mag_1%3A0.13.1-0ubuntu2_FAILEDTOBUILD.txt.gz
<geser> a new upload of at-spi was uploaded at the same time as gnome-mag and it overlapped somehow and gnome-mag failed to build
<smurf> Anybody know whether doko was/is/will be around?
<Lure> sladen: is wireless key on dell inspirion 8100 supposed to get mapped into keycode? I have one user report that they would expect it to be mapped - see https://wiki.ubuntu.com/LukaRenko/Keycodes
<mjg59> Lure: Given that there's nothing to receive that code at the moment, no
<Lure> mjg59: if we have a fixed keycode, at least users can map it easily (xmodmap), but I agree this is not enough for out-of-box
<sladen> Lure: grep -i wifi /usr/share/doc/hotkey-setup/NOTES
<sladen> Lure: it appears that I was considering aliasing it to KEY_CONNECT
<Lure> sladen: I even though that all wifi keys were HW keys...
<geser> sladen: any info on how to trigger a retry on the rebuild of gnome-mag?
<Lure> sladen: you mention battery as 236, but edgy returns 241 - is just doc wrong or is this supposed to change?
<crimsun> geser: ask infinity to give it back
<crimsun> (it's really, really early in the morning for him)
<geser> will do, thx
<sladen> Lure: what does   grep BATTERY /usr/include/linux/input.h   give you?
<Lure> sladen: #define KEY_BATTERY             236
<sladen> good good
<mjg59> Lure: The value that X give will be different to the Linux value
<Lure> mjg59: so where does lnx -> X keycode mapping happen? Xorg?
<mjg59> Lure: Kernel
<mjg59> Lure: You really, really don't want to know the details
<bddebian> Heya pygi
<pygi> hey bddebian 
<Lure> mjg59: it is enough that I had too learn to much of xkb ... ;-)
<sivang> hi pygi 
<pygi> sivang, hello you :)
<mjg59> Lure: The kernel converts Linux keycodes (which appear from /dev/event) into things that look like AT keycodes (that appear from /dev/console)
<mjg59> X reads them from the latter
<mjg59> There's a table in /usr/src/linux/drivers/char/keyboard.c
<mjg59> x86_keycodes[] 
<mjg59> So for keycode 236, you look at the 236th entry and then take away 128, or something
<Lure> mjg59: I see - thanks for explaination
<pygi> sivang, poke, pm?
#ubuntu-devel 2007-08-13
<asac> well
<asac> please ignore the broken ubuntu3 package
<asac> if it induces complexity into prerm/postinst scripts
<asac> just fix those scripts done
<asac> pygi: ^^^
<asac> please bring up a branch asap
<asac> then it should be fine
<pygi> asac, well, scripts are fixed in ubuntu4 :)
<alex-weej> asac: you got any idea about my VPN problem in Gutsy?
<geser> alex-weej: the same problem as in bug #124238?
<ubotu> Launchpad bug 124238 in vpnc "[gutsy]  vpnc terminates directly after establishing a connection" [Undecided,New]  https://launchpad.net/bugs/124238
<alex-weej> geser: maybe -- NetworkManager (the daemon) just bails on me
<alex-weej> bug #131349
<ubotu> Launchpad bug 131349 in network-manager "NetworkManager crashed with signal 5 when attempting to connect to VPN" [Medium,New]  https://launchpad.net/bugs/131349
<geser> alex-weej: this might be unrelated but does setting up a vpn connection from a terminal works?
<alex-weej> can you believe esd manages to cause all GNOME apps to break?
<alex-weej> geser: sorry what did you say?
<geser> alex-weej: this might be unrelated but does setting up a vpn connection from a terminal works?
<alex-weej> geser: no idea how to do that
<alex-weej> geser: i can test it if you tell me how
<geser> see /etc/vpnc/example.conf
<alex-weej> 404
<alex-weej> on /etc/vpnc
<geser> try /usr/share/doc/vpnc/examples/vpnc.conf then
<alex-weej> geser: so no, it does not work. :P
<geser> you need a config file for your vpn
<alex-weej> don't have /usr/share/doc/vpnc
<geser> have you vpnc installed?
<alex-weej> i have no idea
<alex-weej> one moment
<geser> or do you use some other VPN?
<alex-weej> geser: i just use what Gutsy gives me
<alex-weej> i figure if it's giving me the option to configure a VPN, letting me configure a VPN, and then letting me log on to a VPN... i must have some facility to be on a VPN :P
<alex-weej> i'll install network-manager-vpnc
<alex-weej> this sounds promising
<geser> there seem to be 3 vpn plugins for n-m: network-manager-{openvpn,pptp,vpnc}
<alex-weej> oh...
<geser> which one you need depends on the vpn you want connect to
<alex-weej> i use PPTP
<alex-weej> so vpnc is not useful for me
<geser> then it's not a vpnc problem :)
<alex-weej> ok
* alex-weej apt-get removes vpnc :P
<alex-weej> ok, bed time
<alex-weej> gnight!
<thinh> anyone here?
* Hobbsee waves
* RAOF waves back.
<LaserJock> hi Hobbsee
<Hobbsee> heya RAOF, LaserJock!
<ajmitch> hi LaserJock, Hobbsee
<Hobbsee> heya ajmitch
<LaserJock> hi ajmitch
<fabbione> morning
<Hobbsee> morning fabbione!
<fabbione> hi Hobbsee
<Hobbsee> fabbione: why are you pointing people towards me?
<fabbione> Hobbsee: because you are one of the RM? :)
<Hobbsee> fabbione: one of.  i have no say.
<Hobbsee> or close to none
<fabbione> well on some stuff you do
<fabbione> and given what was discussed, you have enough knowledge and power to handle it
<ajmitch> more say than the rest of us
<Hobbsee> fabbione: besides, i'm not the RM.  'im only one of the release team.  the release team only has anything to do if the RM allows it :P
<Hobbsee> fabbione: i've got no idea what's happening, with our RM change.
<fabbione> Hobbsee: ok
<pitti> Good morning
<StevenK> Morning pitti
<pitti> hey StevenK
<Hobbsee> morning pitti!
* pitti hugs Hobbsee 
* Hobbsee hugs pitti
<doko_> good morning
<Hobbsee> morning doko
<siretart> grmpf. somehow my lvm devices don't appear in /dev/vg/name anymore. known problem?
<siretart> stuff segfaulting in /scripts/init-bottom ain't no good, are they?
<fabbione> nope
<siretart> I see 3 segfaults at the end of the startup
<siretart> don't we have a log of the startup process somewhere?
<siretart> isn't upstart supposed to do that somhow?
<siretart> hm. according to the manpage, it is logged to /var/log/boot, but that file only contains a '(Nothing has been logged yet.)'
<siretart> oh, that'll be bug #98955. hrmpf
<ubotu> Launchpad bug 98955 in upstart "logd not running" [Medium,Confirmed]  https://launchpad.net/bugs/98955
<pitti> hey seb128
<seb128> hey hey pitti
<siretart> filed as #132138. I'm available for further questioning
<siretart> hey pitti, hi seb128!
<seb128> hi siretart
<blazemonger> hello
<blazemonger> I have to say that the one thing i dont like as a pc newbie and os newbie is too many OS's have these fancy installs
<blazemonger> i say include a text mode installer in ubuntu
<mdke> sabdfl: around?
<pitti> blazemonger: you mean the one we have for ages? :-) (the alternate CD)
<pitti> blazemonger: in fact that one came first, the live CD installer was added relatively late (in Dapper)
<sabdfl> mdke: yes, what's up
<blazemonger> i'm interested in development
<blazemonger> but i don't feel like learning network security
<blazemonger> i'd like to develop applications for gnu linux and bsd in general
<siretart> blazemonger: cool. just go on and do it!
<blazemonger> what apps do i need to install
<blazemonger> which would you reccomend i do to secure my box? learn iptables manually or use a third party firewall
<siretart> blazemonger: sorry, this is not an educational channel. I'd suggest you ask in #ubuntu
<blazemonger> prob is i come from Amiga world
<blazemonger> but i seriously want to develop for ubuntu
<rulus> hi, can anyone point me to a guide to go from a Python bzr application branch to a .deb package? It's really hard to find it seems..
<siretart> rulus: I'd suggest to look at existing bzr packages, no?
<rulus> I'm spitting through Bughelper sourcecode atm
<sabdfl> asac: i found another AP that the X60 won't associate with
<sabdfl> also netgear
<sabdfl> combination of wpa_supplicant and dhclient works fine in both cases
<asac> sabdfl: do you use wpa_supplicant using a wpa_supplicant.conf file?
<sabdfl> yup
<sabdfl> super-simple
<asac> sabdfl: ok ... i will setup an example to do it the way network-manager tries it.
<sabdfl> http://pastebin.mozilla.org/183653
<asac> sabdfl: network-manager just sets ssid + psk
<asac> sabdfl: do you see 00:00:00:00:00:00 disconnect events in syslog?
<sabdfl> i see nothing like that, no
<asac> sabdfl: does it work without scan_ssid=1 as well?
<pygi> asac, good morning
<asac> pygi: hi ;)
<pygi> asac, working on creating branch as we speak
<pygi> ofcourse, versioned one ... so you'd have both ubuntu3 and ubuntu4 there
<asac> pygi: cool ... can you please commit changes and changelog changes in separate commits?
<pygi> asac, ergh, it just finished pushing stuff :-/
<asac> e.g. first do your changes for ubuntu3 -> commit ... then change ubuntu3 -> commit
<pygi> ah, yes, that's what I did xD
<asac> pygi: url?
<pygi> asac, https://code.launchpad.net/~mario-danic/gnash/trunk
<asac> pygi: please redo
<asac> pygi: you have to start from the existing branch
<pygi> aha xDD
<spike> hi, trying to package some java app. echo $JAVA_HOME -> /usr/lib/jvm/java-1.5.0-sun/, sun-java5-jdk is installed and that dir is symlinked to it
<spike> dpkg-buildpackage -b -rfakeroot -uc -us -> ... You must specify a valid JAVA_HOME or JAVACMD! make: *** [ant-sanity-check]  Error 1
<spike> running feisty
* pygi wonders why we cant delete a branch xD
<sabdfl> asac: i'll try tonight and see
<pitti> Riddell: kdesudo approved and promoted, so feel free to rebuild kubuntu-meta
<Riddell> awooga
<norsetto> wrong channel spike; try #ubuntu-motu
<Riddell> kiosktool, obexftp, kvkbd and opensync is the current Kubuntu main inclusion queue :)
<asac> pygi: reconnect :(
<pygi> asac, no worries
<asac> 11:02 < asac> and if you at it ... do as above ... for 2 new revisions you should at least have 4 commits ;)
<asac> 11:02 < asac> pygi: https://code.launchpad.net/gnash ... its the core-dev branch there
<asac> 11:03 < asac> hmm am i offline? or is launchpad down?
<pygi> asac, I saw the way you do commits, and found main branch, thank you :)
<asac> pygi: ok ... cool
<asac> sabdfl: reconnect ... in case you answered my scan_ssid questions :/
<sabdfl> asac: will test this evening
<Lutin> pitti: can you give-back aolserver4-ns{imap,openssl} on amd64 and aolserver4-ns{ldap,postgres} on amd64, i386, ppc please ?
<pitti> Lutin: done
<Lutin> pitti: thanks
<pygi> asac, ok, pushing changes for ubuntu3
<pygi> hopefully fine now  :)
<pygi> asac, breakfast now, you tell me if it's fine ^_^
<asac> pygi: ok let me check ;)
<asac> pygi: either it failed to push or http servers haven't been synched yet
<asac> pygi: https://code.launchpad.net/~mario-danic/gnash/trunk ... still just 2 revisions ... so i think it has not been synched
<pygi> asac, or push didn't happen xD
<pygi> something about merging, will solve
<pitti> stgraber: can you please give Riddell admin powers on the iso tracker?
<stgraber> sure
<asac> pygi: you need to --overwrite
<pitti> stgraber: thanks
<asac> pygi: as your initial branch is f***ed
<asac> :)
* pygi tries that magic
<stgraber> Riddell,pitti: done
<pygi> asac, Pushed up to revision 100.
<Riddell> thanks stgraber
<pygi> asac, ha, it worked xD
<asac> pygi: yeah!
<asac> pygi: looks good (judging from commit log messages)
<asac> pygi: please push ubuntu4 as well
<pygi> asac, will do so now
<asac> pygi: great!
<asac> pygi: maybe consider to setup your email properly
<asac> pygi:  Mario Danic <mario@rex>
<asac> :)
<pygi> ergh, right, well :)
<asac> pygi: in ~/.bazaar/bazaar.conf ... i have
<asac> [DEFAULT] 
<asac> email = Alexander Sack <asac@jwsdot.com>
* pygi will do that
<pitti> pygi: "bzr whoami"
<pygi> completely forgot, thanks pitti ;)
<pygi> asac, seems done
<asac> ubuntu4?
<asac> pygi: you can look at bzr log before pushing to verifiy if your email is correct
<pygi> asac, yes, ubuntu4
<pygi> now my mail is correct =)
<asac> stgraber: did you recently get ipw3945 connect to a hidden wpa net?
* pygi knows much more about bzr codebase then using it, ergh
<asac> pygi: fine
<pygi> asac, so all changes to gnash in bzr?
<asac> pygi: every package that has a release branch should not be released without getting those changes to release branch first
<asac> pygi: e.g. if you get a warning when running apt-get source gnash
<pygi> asac, kk
<asac> pygi: anyway ... sponsor should have known better as well ;)
<pygi> asac, will be better for the future now anyway :)
<asac> pygi: at best try to approache the Maintainer: for sponsoring first ;)
<pygi> asac, for ubuntu maintainer is most of the time motu or core-dev ;)
<pygi> not here tho =)
<asac> no problem ... we got it right now ;)
<pygi> yup ;)
<asac> oops
<pygi> what I did now? :)
<asac> look at bzr diff -r 98..
<asac> where did you resurrect this bunch of files from?
<pygi> I did a bzr add probably
<asac> pygi: http://pastebin.mozilla.org/183685
<asac> pygi: please redo ;)
<pitwalker> Hi, all! Anybody know an image manululator program (like gwenview) that can rotate serious files by manual click, andt DON'T modify the last modification time?
<pygi> asac, yup, that's a bzr add xD
<asac> its really important to never run bzr add without looking :)
<asac> and check before you commit with bzr diff
<pitwalker> I have problems vitw Gwenview 1.4.1
<asac> pygi: the basic idea is to always have minimal checkins that only contain changes that are documented in commit comment  ... but i guess you know ;)
<pygi> asac, I know, yes xD
* pygi isn't really as clueless as he seems :p
<stgraber> asac: no, all my wlan are public
<asac> stgraber: can you help to test that scenario for a few minutes when you get home?
<stgraber> asac: I'm at home (my last week of holiday :))
<pygi> asac, seems fine this time ;)
<pygi> asac, working on ubuntu4 now
<asac> let me know
<pygi> asac, is up, waiting for servers to sync
<pygi> asac, synced
<stgraber> asac: aren't hidden networks supposed to be shown in iwlist but with <hidden> as essid ?
<stgraber> asac: it doesn't seem to be the case here ... but that's the first time I use the hide ssid thing
<pygi> stgraber,                     ESSID:"<hidden>"
<pygi> :)
<pygi> iwlist eth1 scan ^_^
<stgraber> pygi: that's what I do, but I don't see my network :)
<stgraber> let's see if an AP reboot helps
<asac> stgraber: hmm
<stgraber> ok, it helped ...
<stgraber> buggy AP :)
<asac> ah
<pygi> asac, is the branch fine now?
<asac> stgraber: i guess it won't connect with nm .. but try anyway
<asac> pygi: let me look
<stgraber> asac: Aug 13 12:11:03 laptop kernel: [ 2188.668839]  nm-applet[6246] : segfault at ffffffffac106b90 rip 00002aeddeccaef6 rsp 00007fffce096010 error 4
* pygi doesn't think that sounds good :p
<stgraber> asac: I have that sometimes when trying to use the Other network thing
<stgraber> asac: but only ~ 1/3
<asac> stgraber: can you get a backtrace?
<asac> or submit the crash to lp ?
<stgraber> asac: I think so yes
<asac> stgraber: anyway ... could you setup the hidden network?
<stgraber> asac: btw, hidden network doesn't work
<asac> ok
<asac> can you try with wpa_supplicant.conf?
<stgraber> asac: it doesn't even seem to set the essid
<stgraber> sure
<asac> oh
<asac> stgraber: i think scan_ssid=1 ssid and psk should be enough
<asac> stgraber: look at http://ipw3945.sourceforge.net/ ... changes for 1.2.1 ... i somehow have the feeling that we need some fixes in there
<asac> like: Fix iwconfig essid any doesn't associate problem
<asac> like: Fix driver not make associate request when required
<asac> and: Fix hardware/software RF kill switch problem during module loading time
<asac> maybe those would fix our open network issues
<stgraber> asac: http://paste.stgraber.org/2509
<stgraber> asac: it sees the hidden network and doesn't connect ...
<stgraber> asac: "essid missmatch" :)
<pygi> stgraber, ap_scan=2 ?
* pygi uses that for hidden network
* Starting logfile irclogs/ubuntu-devel.log
* pygi opens the file
<asac> stgraber: from what i see in code for non-broadcast networks nm uses ap_scan 2
<asac>         if (!nm_ap_get_broadcast (ap) || is_adhoc || !supports_wpa)
<asac>                 ap_scan = "AP_SCAN 2";
<stgraber> ok
<stgraber> so none of both seem to work :)
<asac> stgraber: well would be intersting to see if .conf works
<asac> just to rule out that nm goes crazy somehow
<pygi> asac, daemon.log claims scan_ssid 1
<pygi> that ap_scan=2 was from my .conf file
<asac> yes
<Riddell> TheMuso: do you have to set GNOME_ACCESIBILITY=1 for accessibility stuff?
<stgraber> asac: it just associated :)
<asac> stgraber: through nm or manually wpa with .conf ?
<asac> pygi: so nm won't connect without that .conf?
<stgraber> asac: manually with wpa_supplicant
<pygi> asac, ofcourse it connects without .conf
<asac> how long did it take? does some timeout hit nm?
<pygi> asac, I use non-standard configuration file anyway
<asac> pygi: ok ... so you have no problems at all.
<asac> good to know ;)
<pygi> asac, nod =)
<pygi> asac, it worked in dapper (then I was working on the package :P), after that it didn't work (n-m) until now
<asac> strange ... so it started working in ubuntu9 ?
<pygi> no, no, I meant it didn't work until gutsy :)
<asac> ah
<asac> ok
<asac> thats more reasonable
<Mithrandir> iwj: are you interested in "omg, my raid didn't work" stories?
<pygi> asac, it was only once that n-m package was broken in gutsy, but we know which one, hehe :)
<asac> right!
<pygi> asac, had time to look at the branch perhaps? :)
<iwj> Mithrandir: Yes, but it's not primarily my version of the udev glue now so I may have to handwave rather.
<asac> pygi: so what cleanup would be needed to fix people that had ubuntu3 ?
<Mithrandir> iwj: it only stops the md device a lot of times in the initramfs, it doesn't appear to ever start it
<iwj> Weird.
<Mithrandir> iwj: if I start it by hand, all is good.
<stgraber> asac: is the minimal apport crash report enough for you (for the nm-applet crash), the big one crash firefox :)
<iwj> IIRC the scripts attempts to assemble it and if it fails try to delete it again.
<iwj> But this aspect may have changed like many of the others.
<Mithrandir> iwj: hmm, shouldn't I see some evidence of trying to start it?
<pygi> asac, something like flashplugin-nonfree has: http://pastebin.com/m36026788
<iwj> Yes.
<asac> stgraber: minimal? ... we need the full coredump i guess
<iwj> I think you should probably be talking to Scott.
<asac> stgraber: otherwise try to retrace locally
<Mithrandir> iwj: ok, I'll prod him when I see him around
<Mithrandir> iwj: thanks
<iwj> NP, sorry not to be more help.
<pitti> stgraber: at this stage it shuold have already updated the file in /var/crash/
<pygi> asac, just sending a correction there to show how should that dpkg --compare-versions look for gnash
<pitti> asac: the .crash file will work fine with apport-retrace, yes
<pygi> asac, http://pastebin.com/m5775c666
<stgraber> asac: it's a gtk_combox_box problem (when doing the set_model())
<asac> stgraber: NULL-deref or access to freed mem?
<asac> pygi: so it adds failed-upgrade code?
<pygi> asac, yup
<asac> pygi: ok can you please bump changelog ... use distribution UNRELEASED and then add that to gnash?
<pygi> asac, you mean add the needed changes to gnash?
<asac> yes
<pygi> I could try
<asac> open up branch by commiting new changelog
<stgraber> pitti: is the "full" report supposed to send everything you got after an apport-unpack ?
<asac> then modify ... and document and so on
<Lutin> Riddell: python-qt3 contains pyqtconfig.py, which brings a (missing) dependancy on python-sip4-dev. in debian, this file has been moved to python-qt3-dev (the only change) , maybe we should merge it ?
<stgraber> asac: http://www.stgraber.org/download/nm-applet/
<pitti> stgraber: yes, it is
<asac> stgraber: can you please install -dbgsym packages and redo?
<stgraber> pitti: so it'd have uploaded my 47MB coredump :)
<Riddell> Lutin: sure, if someone wants to do that (I can upload if given a debdiff)
<Lutin> Riddell: I've prepared a merge. I've got to go now, is it ok if I give the diff in a couple of hours ?
<Riddell> Lutin: sure
<Lutin> ok
<pygi> asac, can we just remove the old prerm script from the system? That's the easiest way to handle this
* pygi thinks at least
<asac> pygi: why not what was done by flashplugin-nonfree?
<pygi> ok, then that
<norsetto> shouldn't mozilla-mplayer be in multiverse (depends on mplayer, which is in multiverse)?
<norsetto> talking about feisty; for gutsy is indeed in multiverse
<pygi> asac, want me to commit?
<pygi> ergh, push
<pygi> asac, pushing
<pygi> asac, pushed
<asac> k
<pygi> please review that :)
<pygi> might be that we'll really have to remove old prerm but I think this should do
<asac> pygi: have you verified?
<asac> pygi: please test the upgrade path
<pygi> asac, no, I didn't test
<pygi> asac, ah, you want me to install ubuntu3 then?
<asac> pygi: if you sure i will review and upload
<pygi> asac, ok, will test then
<asac> pygi: yes ... verify that the fix fixes the breakage
<asac> pygi: at best double check ;)
<pygi> asac, understood sir!
<pygi> :p
<pygi> asac, building package of gnash will take some ages here =)
<Riddell> pitti: http://paste.ubuntu-nl.org/33565/  u-d-a posting
<asac> pygi: thanks
<pygi> asac, nah, thank you for pushing me to fix stuff :)
<pygi> asac, if it does fix the problem, you'll merge to mainline and upload?
<asac> pygi: obvioulsy yes
<stgraber> asac: http://www.stgraber.org/download/nm-applet/
<asac> stgraber: can you run "valgrind /usr/bin/nm-applet --disable-sm 2>&1 | tee /tmp/nm-applet.valgrind.log" as well please and attach both to a bug?
<Kmos> * added Dutch translation by Bart Cornelis. Closes: #436865
<Kmos> this is the only change on a package that can be synced
<Riddell> mvo: where is the original dpkgpm.cpp?  I can't see it in dpkg
<Kmos> it's a valid reason to request the sync ?
<Riddell> Kmos: sure (until UVF)
<Lutin> Riddell: here's the dif against the current python-qt3 ubuntu version: http://people.dunnewind.net/lutin/python-qt3_3.17.3-2ubuntu1.debdiff
<Kmos> Riddell: the UVF of gutsy is in which date?
<ogra> Kmos, https://wiki.ubuntu.com/GutsyReleaseSchedule
<Kmos> ogra: thx
<Riddell> Kmos: thursday
<Kmos> Riddell: yeah.. 16th, thx
<stgraber> asac: the valgrind immediately end with an error before nm-applet appears and apport report a crash from memcheck
<pygi> who do I poke to drop swfdec0.3 from archives?
<Riddell> pygi: file a bug with an explanation of why and subscribe ubuntu-archive
<pygi> Riddell, oki, thank you ^_^
<pygi> asac, no swfdec release after all, we'll get it in during UVF
<pygi> is there a branch for swfdec as well?
<\sh> hmmm....what do I have to do to have this "zoom out all windows from all desktops" on gutsy, running gnome?
<geser> \sh: you mean that one from compiz?
<\sh> geser: i think so...if this is enabled by default in tribe4 ;)
<geser> do you have desktop effects enabled and working?
<\sh> looks like...with open source radeon driver
<\sh> i have some shadows around my windows,..desktop effects is running...but I don't find any key binding for this effect..(if it's enabled in desktop effects)
<geser> I don't know the defaults for compiz, but you can change them easily with compizconfig-settings-manager
<geser> if you start ccsm check if "scale" is enabled below Window Management
<\sh> geser: but this tool isn't installed by default,
<geser> no
<\sh> just because i don't find it
<geser> it's in universe
<geser> you can also use it to look up the key bindings and configure new ones
<\sh> geser: k...installing it
<ogra> \sh, it works here if i move the mouse in the top right corner
<ogra> but no idea what the keybinding for that is
<\sh> ogra: nope not here
<ogra> might be because i have to use Xgl ... even though i wouldnt expect difference in compiz due to that
<Kmos> kernel 2.6.22.2 is out :)
<ogra> that will make kernel.org happy :)
<Kmos> and ubuntu too if the fix are applied :)
<Riddell> Lutin: uploaded pyqt3
<Riddell> thanks
<Lutin> Riddell: thank you
<asac> pygi: why do you think that swfdec will be released soon :) ?
<\sh> ogra:  geser: works as expected...thx :)
* Hobbsee waves
<Mithrandir> hi Hobbsee
<mvo> Riddell: that is part of libapt (apt-pkg/deb/dpkgpm.cc)
* Hobbsee stomps on Mithrandir's feet, and runs off
<Riddell> mvo: yep, got it.  adept doesn't use a fork but rather derives from the libapt version.  I'll keep looking at it for a bit but this may be beyond my abilities
<\sh> how can someone disable trackerd?
<mvo> Riddell: ok, that is fine, let me know and I have a look
<Hobbsee> pitti: good post
<pygi> \sh, there's that thing in the preferences I think
<pygi> Indexing preferences
<\sh> found it...but I think I have to restart trackerd to catch the new settings
<pitti> Hobbsee: thanks
<\sh> hmmm...
<\sh> update-notifier runs every 5 seconds?
<asac> pygi: can you please fix the trailing comma+whitespace in Npp-Application line as well?
<pygi> asac, possible =)
<pitti> Riddell: I think requiring specs to be implemented is a bit harsh; "beta available" is more suitable IMHO
* pygi looks about that
<ion_> I really like the new zoom plugin in copiz. Having a keybord shortcut to zoom the current window to fullscreen rocks.
<Riddell> pitti: ok, I'll change that
<pygi> asac, you want to have no whitespace between coma and id?
<pygi> comma*
<pygi> (just trying to make it right ^_^)
<Riddell> mdz: posting to u-d-a needing approval
<Hobbsee> Riddell: there should be others who are more here around, to unmoderate that...
<asac> pygi: yes
<asac> no comma nor whitespace at EOL please
<Riddell> Hobbsee: I don't see any
<pygi> asac, done
<Hobbsee> Riddell: pitti, Mithrandir
<asac> pygi: so did you verify your work?
<pygi> asac, still building xD
<Hobbsee> Riddell: either of them can
<Riddell> Hobbsee: don't seem to be admins of u-d-a
<pygi> asac, not too fast laptop =)
<Hobbsee> Riddell: i've had Mithrandir unmoderate a couple of posts of mine before.  they may just have the p/w or somethign
<Riddell> oh maybe they're moderators but not admins
<pygi> asac, ubuntu3 still being build :-/
<Hobbsee> Riddell: quite possible
<pygi> asac, feel free to build ubuntu5 from my branch, and send me the debs
<TheMuso> Riddell: I think it has been depricated. I do think that one has to se tanother environmental variable for standard GTK apps to use the framework however.
<pitti> Riddell: I'll moderate it
<xxxxx1> mornin' pitti and TheMuso
<pitti> hi xxxxx1
<Kmos> http://packages.qa.debian.org/w/wlassistant/news/20070812T161704Z.html
<Kmos> this one is valid for a request sync ?
<Hobbsee> wlassistant has ubuntu changes, i'm sure
<StevenK> I daresay I made them. Twitch.
<Hobbsee> StevenK: or did.  someone's synced it.
<Hobbsee> StevenK: https://bugs.launchpad.net/ubuntu/+source/wlassistant/+bug/117749
<ubotu> Launchpad bug 117749 in wlassistant "sync wlassistant 0.5.7-1 from debian unstable" [Wishlist,Fix released] 
<Kmos>  visualboyadvance (1.8.0-3) unstable; urgency=low
<Kmos>  .
<Kmos>    * visualboyadvance-gtk Depends on visualboyadvance (>= 1.8.0-2).
<Kmos>      (Closes: #434724)
<Kmos> this is important to sync ?
<Kmos> it's a dependency problem
<Hobbsee> debian bug 434724
<ubotu> Debian bug 434724 in visualboyadvance-gtk "visualboyadvance-gtk: depends on visualboyadvance but conflicts with a file in it" [Grave,Fixed]  http://bugs.debian.org/434724
<Hobbsee> Kmos: the only version in the system in ubuntu is 1.8.0-2, so we dont actually have a lower version that it can use.  however, whether that affects upgrades, etc
<pitti> kylem, BenC: can we go through the dapper.2 bugs when you wake up and are sufficiently coffeinated?
<Kmos> Hobbsee: so it's better not to sync
<Hobbsee> Kmos: unsure if there's a need to sync
<Kmos> it has Severity: grave; on debian bug
* Hobbsee thought you had to have the full C/R's on that, incidently
<Kmos> C/R's ?
<Hobbsee> conflicts & replaces
<Hobbsee> as well as depends
<Riddell> we do have versions >= 1.8.0-2, so depending on which versions it affects, it may need syncing
<Kmos> visualboyadvance-gtk if installed, doesn't provide visualboyadvance
<Kmos> so it can run
<xxxxx1> i think fglrx is not supported by xorg 7.2. anyone here is using fglrx on newer version of xorg on gutsy?
<Kmos> can't
<Riddell> mvo: adept's dpkgpm.cpp seems like a rewrite rather than anything else in libapt, I think the missing features would need to be added by manually by someone who understands what it's doing
<Riddell> mvo: it inherits from dpkgpm.cc in libapt but doesn't seem to use very much of it
<mvo> Riddell: ok, I take a look
<Riddell> mvo: thanks
<Lutin> pitti: can you give-back edbrowse, gtk2-engines-magicchicken and gnomescan amd64, i386 & ppc please ?
<xhaker> Hobbsee, Hi! fabbione advised me to let you know about my discoveries on libmtp
<Hobbsee> xhaker: greetings!
<Hobbsee> xhaker: what are they?
<\sh> wooha...trackerd is not allowed to index anything but takes 8.3 CPU time
<kylem> pitti, benc is on holiday this week, but i can do it if you'd like
<xhaker> Hobbsee, the main objective is to bring a libmtp package of the latest version, including many fixes and an improved device list (udev)
<Hobbsee> xhaker: right.  do the things that depend on support the newer version?
<Hobbsee> it looks like gnomad2, rhythmbox, mtp-tools and amarok are the things of interest, there
<\sh> how can I tell trackerd to not eat my cpu time...
<Kopfgeldjaeger> pitti: does installing the bcm43xx firmware now work on the live-cd?
<xhaker> Hobbsee, yes, almost there: mtp-tools is built from the libmtp source package.
<xhaker> Hobbsee, gnomad2 and amarok work
<xhaker> I've not tested rhythmbox
<xhaker> but if there was space for breakage it would be on amarok as a libmtp lead developer said in a response to a mail
<xhaker> Hobbsee, this testing was conducted because there was an API change, (two new fields in a struct and  new function)
<Hobbsee> xhaker: right
<Hobbsee> xhaker: assuming rhythmbox doesnt break too, it should be fine
<xhaker> Hobbsee, i cant even use my device with rhythmbox :D
<xhaker> must be a bug
<xhaker> or the plugin is a stub for things to come
<\sh> grmpf...every 5 seconds there is a nm poll...nm__policy_device_change_check: old_dev && new_dev!!
<Kmos> http://cdimage.ubuntu.com/dvd/20070811/report.html
<xhaker> Hobbsee, pygi did the libmtp6 packages for me. the udev rules should have GROUP="audio" so the files can be accessed by anyone
<Hobbsee> xhaker: right.
<\sh> oh god...I did tell trackerd to stop indexing everything, but it doesn't stop, and eats around 10m Resources....including 10% of cputime...
<Hobbsee> xhaker: assuming it doesnt break anything, i cant see a problem with it
<xhaker> Hobbsee, so who can package it and rebuild the rdepends?
<xhaker> :D
<Hobbsee> xhaker: you, pygi.  amarok's going to get rebuilt anyway, so you can ignore that one.
<xhaker> i think those are all packages in main
<AndyP> what's the logic behind having NoDisplay=true in gvim.desktop? i see it's getting some ubuntu-devel-discuss@ attention
<AndyP> doko: ^^ ?
<Kopfgeldjaeger> pitti: r-m just crashed after clicking on OK (bcm43xx, download wl_apsta.o from this google-code page). here the console output: http://www.ubuntuusers.de/paste/13726/
<pitti> Kopfgeldjaeger: that's useful, thank you
<pitti> Lutin: done
<pitti> Kopfgeldjaeger: it should work theoretically (bcm43xx fw on live CD)
<pitti> Kopfgeldjaeger: if not, please file a bug
<pitti> kylem: that would be good; when is a good time for you?
<ogra> pitti, we ship the bcm firmware ?
<Lutin> pitti: thanks
<kylem> pitti, do you have the list somewhere handy? i can look through them quickly then we can discuss it in an hour or two?
<pitti> ogra: no, downloading them from the web
<pitti> kylem: that would be good
<ogra> ah, k
<pitti> kylem: https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
<pitti> kylem: sort by assignee is most useful, I think
<pitti> kylem: there is kernel team, Ben and you, those assignees are not very suitable yet (that was part of what I wanted to discuss)
<kylem> ok.
<kylem> in how many hours does your work day end?
<alex-weej> is it cool to remove ubuntu-desktop yet or is it still responsible for bringing in some essentials?
<pitti> kylem: no Taekwondo today, so I'll be online for at least another 6 hours (with breaks in between, though, since we have to do some wedding preps)
<Hobbsee> pitti: you are going to provide pictures, now arent you?
<pitti> Hobbsee: of the wedding? sure I will
<Hobbsee> pitti: great :)
<StevenK> Photos of preparing for the wedding will be boring ... :-P
* Hobbsee beats StevenK with a rubber mallet
<StevenK> Ouch! That tickles.
<pitti> a honking one?
<Hobbsee> maybe a spiky one :P
<pitti> mhb: debian/restricted-manager-core.install is weird
<pitti> mhb: ah, I see, it's needed for the package split
<mhb> pitti: I am innocent, I tell you :-)
<mhb> pitti: kidding aside, what did I do?
<alex-weej> grr
<pitti> mhb: it's not common to hardcode python versions and meddle with usr/lib/python2.5/site-packages in maintainer files
<alex-weej> whatever file system ubiquity creates, grub never recognises. even with another ext3 partition on the same disk, grub picks that one up. but it just sees the installed file system as "unknown"
<bddebian> Heya
<pitti> mhb: but nevermind me, it's necessary due to the package split; s/2.5/*/ should do
<alex-weej> fscking it shows no problems. i'm stumped
<Kopfgeldjaeger> pitti: i thought this just 5 minutes ago while looking through the deb
<mhb> pitti: ah... sorry for that, I have never been goot at packaging.
<pitti> mhb: nevermind, was pretty much a think of mine
<pitti> thinko
<Lutin> seb128: would you mind having a look to bug 131596 ?
<ubotu> Launchpad bug 131596 in gtkmm2.4 "[Typo]  Typo in iconview.h causes FTBFS on other packages" [Medium,New]  https://launchpad.net/bugs/131596
<mhb> pitti: did you read the thread somewhere about translators wanting to have the %(os)s gettext line explained in a comment?
<pitti> mhb: I faintly remember
<pygi> asac, ergh, my computer turning itself off every 15 minutes
<bddebian> Hey gents, doko is our resident Java expert?
<mhb> pitti: I could add that if you don't mind
<pitti> mhb: not at all, please do
<pitti> mhb: can you please take a look at http://www.ubuntuusers.de/paste/13726/? error_invalid_text only occurs once in the entire tree
<Kopfgeldjaeger> pitti: i found the bug in r-m (live-cd)
<Kopfgeldjaeger> it's because universe isnt enabled while using the live-cd (see your FIXME in backend/bcm43xx.py). there are surely ways to avoid this (in worst case, with awk)
<pitti> Kopfgeldjaeger: hm, I remember fixing that a while ago (telling the user that the package repo is not available in a messagebox); I guess this broke in the refactorization for KDE porting
<Kopfgeldjaeger> pitti: may be, but it is not fixed in the newest r-m source package (trunk/RestrictedManager/backend/bcm43xx.py, line 50 / 51)
<Kopfgeldjaeger> *latest
<mhb> pitti: added the comment in my branch
<seb128> Lutin: will have a look
<pitti> Kopfgeldjaeger: hm; WTH?
<Kopfgeldjaeger> ?
<Kopfgeldjaeger> what about
<pitti> http://codebrowse.launchpad.net/~ubuntu-core-dev/restricted-manager/trunk/revision/martin.pitt%40ubuntu.com-20070801103055-sj5hmt3a9l3hc9u2?start_revid=martin.pitt%40ubuntu.com-20070813145619-49sgr6u6iywclg5b#RestrictedManager/core.py-s
<pitti> Kopfgeldjaeger: ^ that's where I added it
<pitti> mhb: ^ seems that didn't get merged for some reason?
<Kopfgeldjaeger> mom
<pitti> Kopfgeldjaeger: indeed, thanks for pointing out; it's not in trunk any more
<ogra> pitti, breaking all your stuff before leaving so we dont get bored ? :)
<pitti> ogra: I actually try to do some fixes
<ogra> heh, i know :)
<mhb> pitti: hmm, that reason was most-likely me overlooking a conflict somewhere
<mhb> pitti: I'll fix it then
<pitti> mhb: thanks
<pitti> mhb: please merge trunk first, I shuffled the files a bit
<pitti> mhb: RM/backend -> RM/handlers/, and I moved core.py back to RM/
<mhb> pitti: sure
<Kopfgeldjaeger> im not sure if it matters, but "software-properties-gtk -e universe" should enable universe (at least in feisty it seems to work)
<mathiaz> kylem: did you have a chance to look at the latest apparmor patches ?
<mhb> pitti: it seems http://boredklink.googlepages.com/wl_apsta.o is not valid anymore
<mhb> pitti: it's the firmware file URL link in broadcom handler
<mhb> pitti: shows 404
<Kopfgeldjaeger> mhb: argh
<kylem> mathiaz, yes.
<mathiaz> kylem: is there a chance it'll get into the kernel by FF ?
<mathiaz> kylem: cause I'm blocked on the new kernel version to update the latest userspace.
<kylem> yes.
<mhb> pitti: by the way, your code is executing "apt-cache show package", which shows a package even if the package is already removed from the system, the archives/ are clean and no universe enabled.
<mhb> pitti: so it probably won't show to the people that never installed it, but there would be another bug to close once somebody removes the package & universe and then tries to do this
<pitti> mhb: damn, so we should find another URL
<pitti> mhb: apt-cache show> What do you mean?
<mhb> pitti: there are several I googled up
<pitti> mhb: apt-cache show <universe package> does not display a package any more after disabling universe in apt sources
<mhb> pitti: it seems to do here, probably because I already had this package installed
<pitti> mhb: yeah, bcm43xx-fwcutter should have several in its README and/or postinst
<pitti> mhb: yes, when it's installed, it's fine
<pitti> mhb: but it tests that before
<mhb> pitti: well, it's not installed
<mhb> pitti: I uninstalled it, then removed universe
<mhb> still shows up
<pitti> mhb: that would be weird; doesn't here
<pitti> oh, hm, I didn't test it with a previously uninstalled package, I think
<pitti> mhb: so we probably do have to use apt-cache policy
<pitti> mhb: but *shrug* corner case for later
<mhb> pitti: shows up here, too
<mhb> pitti: I cannot either install or uninstall it (it's simply not here), but the messages show up
<pitti> mhb: nope, not here
<pitti> install pmount - purge pmount - remove universe from apt sources - apt-cache show pmount is empty
<geser> mhb: did you only uninstall it or did you purged it?
<pitti> purge
<mhb> pitti: no purging ,that might be it
<norsetto> keescook: ping
<keescook> norsetto: hi!
<norsetto> hi there :-)
<norsetto> keescook: just saw your note on eggdrop
<keescook> cool; yeah.  I haven't seen the Debian changes yet (1.1 isn't in the archives I've looked at yet)
<norsetto> keescook: its a merge; the fix is in incoming.debian.org, should be in the archives soon
<keescook> norsetto: merges need to include the upstream changes too; your patch didn't include the debian changes.  :)
<norsetto> keescook: let me check....
<keescook> diffstat -p0 /tmp/eggdrop_1.6.18-1.1ubuntu1.patch  shows only the changes I added
<norsetto> keescook: what I did was: I took the debian changelog, added your changes and the new ones to it (changed all the other files) and then made the debdiff
<geser> norsetto: add the new changelog entries as a comment to the bug
<geser> I guess that would be sufficient
<norsetto> keescook: so the debdiff only list the ubuntu specific changes, the debian ones come from the debian package to which my patch applies?
<keescook> norsetto: the patch (since it's a merge) needs to include all the changes against the orig.tar.gz (which hasn't changed).  You took the changelog but not the Debian changes between -1 and -1.1
<keescook> norsetto: as in, I do not see the debian -1 to -1.1 changes in the debdiff you attached.
<norsetto> you mean, all the ubuntu changes, before your changes!
<norsetto> keescook: of course, you are right
<norsetto> :-(
<norsetto> keescook: ok, so it would be better to use the ubuntu changelog and add the debian changes manually to it
<keescook> norsetto: heh, no problem; I just want to make sure the fix gets in.  :)  Do you have the diff between -1 and -1.1?
<geser> keescook: so the whole diff.gz should be uploaded?
<keescook> norsetto: what you did was fine, you just missed the Debian code changes.
<geser> keescook: or the debdiff between lastubuntu.dsc and merged.dsc?
<keescook> geser: no, just add the diff between -1 and -1.1
<norsetto> norsetto: its the 1st time I do a manual merge (one should not get used to grab-merge....)
<keescook> norsetto: yeah, it can get complex.  :)
<keescook> the steps would be:
<keescook> get the debian changes (-1 to -1.1)
<keescook> get the ubuntu changes (-1 to -1ubuntu1)
<keescook> apply the ubuntu changes to debian's -1.1
<keescook> debdiff between -1ubuntu1 and your new -1.1ubuntu1
<keescook> verify that the debian changes are in your debidff
<keescook> verify that the ubuntu changes are in your debdiff
<keescook> I think you likely did a debdiff between -1.1 and -1.1ubuntu1 instead of between -1ubuntu1 and -1.1ubuntu1
<norsetto> keescooK: indeed, thx for pointing this out, I'm preparing a new patch with an updated changelog
<norsetto> keescook: yes
<keescook> norsetto: sure, no problem; thanks for getting it prep'd!  :)
<geser> keescook: can you also look at bug #130348? this merge would fix CVE-2007-4074
<ubotu> Launchpad bug 130348 in festival "[Merge]  festival 1.4.3-21ubuntu1" [Undecided,Incomplete]  https://launchpad.net/bugs/130348
<ubotu> The default configuration of Centre for Speech Technology Research (CSTR) Festival 1.95 beta (aka 2.0 beta) on Gentoo Linux is run locally with elevated privileges without requiring authentication, which allows context-dependent attackers to execute arbitrary commands via the local daemon on port 1314, a different vulnerability than CVE-2001-0956. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4074)
<keescook> geser: sure, one sec
<geser> I hope I got all the necessary debdiffs attached to the bug now
<Nafallo> NICE!
<Nafallo> the damn bot knows about CVEs \o/
<infinity> Would be nicer if CVE summaries weren't notoriously inaccurate.
<ogra> or if the short description would actually be short :P
<keescook> geser: looks good to me; I'll upload it
<geser> keescook: thanks
<norsetto> keescook: sorry, still one question; I really would like to understand; I did the debdiff between -1.1 and -1.1ubuntu1 instead of between -1ubuntu1 and -1.1ubuntu1: in principle they are both right, or not?
<Hobbsee> norsetto: if it was with different upstream releases, that would effect which tarball and source you applied it against
<Hobbsee> norsetto: well, it still effects which source you apply it against
<norsetto> Hobbsee: sure, but its a merge; same tarball
<Hobbsee> norsetto: then it effects which source, ie which dsc you've used to unpack the tarball
<norsetto> Hobbsee: indeed, so the policy is always to merge from ubuntu to ubuntu?
<Hobbsee> ie, if you take -1ubuntu1 and -1.1ubuntu1, which is the changes in debian, if you apply them against the debian tarball, it'll bail on you
<Hobbsee> because the changes are already there, and it cant find the ubuntu entries
<Hobbsee> norsetto: the "Common Sense" policy is used - but yeah, tends to be ubuntu to ubuntu unless otherwise stated
<keescook> norsetto: with a _merge_, you need to do ubuntu-to-ubuntu debdiffs, yes.
<norsetto> Hobbsee: ok
<Hobbsee> keescook: and in the case that the tarballs differ, due to upstream versions?
<pitti> TBH I *much* prefer Debian-Ubuntu debdiffs for merges
<Hobbsee> keescook: where we tend to diff debian --> ubuntu, and apply that to the debian source?
<keescook> well, it depends on the thinking involved.  in norsetto's case, he's uploading a debdiff to be sponsored, in which case the u-u changes are needed
<keescook> for doing one's one merges, I agree with pitti: the d-u delta is important.
<norsetto> keescook: right; thats the bit I was missing
<keescook> pitti: the result is u-u though
<pitti> keescook: I usually compare the old and new d-u debdiffs
<keescook> pitti: if you scroll up, you'll see the steps I recommended, which follow what you mean
<norsetto> keescook: but if I use grab-merge, will that do d-u or u-u?
<Hobbsee> norsetto: both
<Hobbsee> norsetto: you get two .patch files
<keescook> norsetto: grab-merge will provide all of them, but if you use in the included changes tools, you'll get a dsc that will produce the u-u
<norsetto> because I always uploaded u-d :-(
* norsetto shuts his mouth :-X
<psusi> anyone got a moment to discuss https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain ?
<Kopfgeldjaeger> pitti: @wl_apsta.o here's a little mirror: xeve.de/down/wl_apsta.o . but thats not THE solution, why cant the driver be hosted on a ubuntu server?
<pitti> Kopfgeldjaeger: if we could do that, we wouldn't need the entire thing
<pitti> Kopfgeldjaeger: the problem is that we are not allowed to redistribute that thing
<pitti> Kopfgeldjaeger: if it was, we could just include it into our kernel (or at least l-r-m) and be done with it
<pitti> Kopfgeldjaeger: TEH SOLUTION comprises buying hardware from vendors which don't suck, I'm afraid :/
<Kopfgeldjaeger> ah.. hm... i knew that its "restricted" somehow (oh.. really? :d) .
<pitti> Kopfgeldjaeger: we even asked Broadcom whether we may redistribute it, but didn't get an answer (at least not a positive one)
* bddebian curses broadcom
<Hobbsee> night all
<pitti> bye Hobbsee
<Hobbsee> :)
<Kopfgeldjaeger> pitti: what about just creating a mirror list, and a mirror list mirror list? :d just like it works for TOR
<pitti> Kopfgeldjaeger: one level of indirection would be good, yeah
<norsetto> g'night Hobbsee
<pitti> Kopfgeldjaeger: point to a static URL in r-m, and we can then tweak that one
<Kopfgeldjaeger> yes
<tkamppeter> Can someone tell me which package provides the definitions of the autoconf macros AC_DISABLE_STATIC and AC_PROG_LIBTOOL?
<ijuz__> i guess: libtool
<kagou> tkamppeter, sorry for Bug #127152 i didn't have time to do tests. I will do this next week (end of holydays)
<ubotu> Launchpad bug 127152 in system-config-printer "Samba printers are not displayed" [Medium,Confirmed]  https://launchpad.net/bugs/127152
<tkamppeter> kagou, OK.
<tkamppeter> ijuz__, thank you I will try.
<tkamppeter> ijuz__, it was libtool. Thanks.
<psusi> anyone got a moment to discuss https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain ?
<pygi> mr_pouit, poke
<mr_pouit> pygi: pong
<pygi> mr_pouit, are you available in two hours for a discussion?
<bashelier> hello
<mr_pouit> pygi: I can try (but it'll be late in the evening)
<pygi> mr_pouit, ok
<mr_pouit> pygi: you aren't available to discuss now? (on #brasero for example?)
<pygi> mr_pouit, on #brasero I won't discuss
<pygi> discussion is useless there
<mr_pouit> pygi: why?
<pygi> mr_pouit, because metalgod refuses to listen?
<mr_pouit> don't you think you also don't want to listen? :] 
<mr_pouit> s/also//
<mr_pouit> *neither
<pygi> I think I listen, and know more about the situation then he does
<pygi> mr_pouit, you do what you think is right
<pygi> I won't argue anymore, I'm tired from that
<mr_pouit> pygi: the point is : I don't want gutsy to ship a half-working brasero
<pygi> mr_pouit, just see what I said above ;)
<pygi> I have nothing more to say on the matter
<mr_pouit> and for the moment, it think cdrkit is a better solution... libburn needs to be more mature
<pygi> mr_pouit, let's not go into that, I stated my opinion on that thousand times, ok?
<mr_pouit> pygi: if you don't want to discuss, what are we going to do with brasero? nothing,
<mr_pouit> :/
<pygi> mr_pouit, lemme quote:
<pygi> <pygi> mr_pouit, you do what you think is right
<pygi> mr_pouit, don't you agree that's the best?
<pygi> I won't stand in the way
<bashelier> hello pygi
<pygi> hey bashelier
<pitti> kylem: I'm about to leave for dinner and RL stuff; can we talk about the dapper.2 list at your morning tomorrow? they you have some more time to review the list
<kylem> pitti, certainly.
<psusi> anyone got a moment to discuss https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain ?
<pitti> good night everyone
<mdke> is control-center being used by default yet in gutsy? or are we still with the old preferences menu?
<bhale> preferences is back
<bhale> after a short run with the novell style CC
<mdke> bhale: thanks; is it going to stay that way until 7.10?
<seb128> yes
<mdke> seb128: thanks
<bhale> hi seb
<seb128> hey bhale
<mdke> seb128: is vanilla Gnome like that too?
<seb128> mdke: yes, we will likely switch when they do
<seb128> but there is still some work to be done and upstream reached freezes etc already
<mdke> seb128: ok, cool
<mdke> the documentation needs to be corrected upstream then too :)
<seb128> ;)
<tkamppeter> It seems that in a few minutes CUPS 1.3.0 will be released. Should we put it into Gutsy?
<Lutin> seb128: got some time to look at bug #131596 ?
<ubotu> Launchpad bug 131596 in gtkmm2.4 "[Typo]  Typo in iconview.h causes FTBFS on other packages" [Medium,New]  https://launchpad.net/bugs/131596
<seb128> Lutin: looking now
<seb128> Lutin: an extra ";" should not break anything, weird
<Lutin> seb128: yep, but seems to break some builds though
<seb128> are you sure it's due to it?
<Lutin> seb128: have a look at http://launchpadlibrarian.net/8189200/buildlog_ubuntu-gutsy-amd64.gmult_5.3-0ubuntu3_FAILEDTOBUILD.txt.gz
<seb128> right
<alex-weej> why do we use this terminology: "Sorry, the program "%s" closed unexpectedly" vs. "... crashed"
<mdke> because the word crash is associated with cars, not programs
<alex-weej> i'd be interested to see whether people understand the term "to crash" more than "to close"
<alex-weej> but the word "close" is associated with doors, not programs
<dobey> windows
<mdke> I don't think that's true
<dobey> you close windows
<mdke> hover over the x over there -->
<dobey> you don't crash a window when you click the [x] 
<ScottK> Some apps you do....
<alex-weej> "Close Window". We don't say "Close Program", we say "Quit" or "Exit"
<LaserJock> it has the same effect, bye-bye window
<bddebian> crap, I need a sync before a merge
<mdke> lol @ ScottK
<dobey> but maybe a good metaphor would be to use the wiimote, and "throw a baseball through the window" to close it
<alex-weej> Evolution crashes when i click the [x]  :P
<alex-weej> in fact this is exactly what made me notice this :P
<dobey> alex-weej: so quit unexpectedly is probably the better term. but crashed is not
<dobey> i think in windows the popup says quit
<alex-weej> "The application closed unexpectedly..." no it didn't, i just told it to f***ing close! :P
<dobey> "Sorry, the program '%s' has met with an untimely demise."
<mdke> "You might want to try program '%t' instead"
<alex-weej> actually it seems to say "Sorry, the program\n"%s" closed\nunexpectedly"
<alex-weej> a lot of GTK dialogs do that, never quite figured out why o_0
<alex-weej> acres of grey space
<dobey> probably bad pango math causing it to wrap wrong
<dobey> or something
<alex-weej> according to most menus, we seem to Close Files
<alex-weej> and Quit Files
<alex-weej> no mention of Windows or Programs :<
<seb128> Lutin: uploaded, next time could you add the LP: #nnnnnn to the changelog?
<Lutin> seb128: oh yeah, sorry, forgot it. thanks
<seb128> you're welcome, thank you for working on the change ;)
<psusi> iwj: ping
<bddebian> seb128: Don't yell at me for the vips sync request! :)
<doko> seb128: does libgtk2-perl just breaks on lpia, or is this general glib2.0 breakage?
<seb128> doko: no idea, I don't know about any glib2.0 or libgtk-perl current breakage
<bddebian> doko: !! Hi.  You don't happen to know anything about freemind do you?
<seb128> bddebian: the request looks ok ;)
<doko> bddebian: ?
<bddebian> seb128: Thx
<bddebian> doko: Are you the java "expert"?  Freemind currently ftbfs's because of j2re1.4 but I was able to build it with gcj
<bddebian> But I don't know the package well enough to know if it actually "works"
<doko> bddebian: so fix it, test it, and upload it
<bddebian> f****ck seb128 You haven't processed that have you?
<seb128> bddebian: no
<bddebian> Good
<bddebian> Damnit, how can I unsubscribe Ubuntu Archive?
<seb128> left column, unsubscribe
<infinity> You can't unsub a team you're not in.
<bddebian> Aye
* bddebian goes back in to hiding. :-(
<doko> seb128: iz a g' bug
<DarkSun88> Hi all
#ubuntu-devel 2007-08-14
<Kopfgeldjaeger> bye
<alex-weej> i've noticed that GTK List/Tree View scrolling is streaking a hell of a lot more in Gutsy than in Feisty
<Caesar> Can anyone tell me why Ubuntu chose to go for mounting devices by UUID rather than label? Pointers to the relevant discussion/blueprints fine
<ion_> Every partition has an UUID, but not necessarily a label.
<mthaddon> Caesar: don't have the details off the top of my head, but it's basically because UUIDs are device unique, so you can plug in two identical external hard drives, for instance, and it'll still know which is which and mount it correctly rather than just first in order
<ion_> Multiple partitions may have the same label, but not likely the same UUID.
<Caesar> Thanks ion_, mthaddon
<Nafallo> shouldn't displayconfig-gtk dep on xserver-xorg-video-vesa or something?
<RAOF> Nafallo: Why?
<Nafallo> isn't that part of the bulletproof-X thing that should fall back to VESA and just that app instead of showing the ncurses-based /var/log/Xorg.0.log?
<RAOF> Oh, maybe.  But still, displayconfig-gtk doesn't really need to depend on a specific X driver.
<RAOF> Maybe some other package wants to.  Our standard X packages already depend on all the various drivers, so...
<Nafallo> it does not. I have only vesa and ati installed right now.
<Nafallo> I need only one to satisfy the depends.
<Nafallo> xserver-xorg-video-all | xserver-xorg-video-1.0 | xserver-xorg-video
<RAOF> Aaaah.
<RAOF> Right.
<RAOF> But all of them are installed by default.
<RAOF> Maybe the xserver wants to depend on vesa & those.
<Nafallo> I'm not sure why it recommends them as well thou
<Nafallo> yea. vesa might be a good dep as well.
<Nafallo> bryce: you might want to read the discussion above this hilight :-)
<RAOF> Although vesa isn't actually cross platform, of course.
<bryce> ok
<RAOF> Hello x86 centicism!
<Nafallo> bryce: oh. I thought you was asleep :-)
* RAOF invents new misspelled words.
<Nafallo> bryce: what do you think? :-)
<bryce> it shouldn't depend on a driver, but I've been wondering if it should be a dependency of something
<bryce> I've got it hooked in via gdm, so gdm is one possibility.  Most of the files are kept in xorg, though, so that's another
<Nafallo> I guess it will actually need to be if we are going to use it as a fall-back :-P
<bryce> but I'm not certain what would be best
<Nafallo> right...
<bryce> in theory it would not be gdm-specific, if we could get a failsafe functionality in kdm
<bryce> but presently it only works with gdm
<RAOF> You could just recommend it in xorg, couldn't you?
<bryce> maybe
<RAOF> The "apt auto-installs recommends for metapackages" will get done for Gutsy, right?
<bryce> more importantly, we also need to decide about adding displayconfig-gtk to the seeds
<Nafallo> RAOF: should be a depend somewhere I think... we don't want users to accidently kill fall-back.
<RAOF> Nafallo: Eeeh, maybe.
<Nafallo> bryce: if I change xorg.conf to use at instead of ati it should kick in, right? :-)
<bryce> right
<Nafallo> I'll test that in a bit then :-)
<bryce> hang on; I've got a new version to upload
<Nafallo> oh. oki :-)
<bryce> it has a better auto-xorg.conf generator that will pull in your preferred keyboard settings, and get the pci stuff right
<Nafallo> I'll test it after upgrade then :-)
<Nafallo> gut feeling says it should be a dep of xserver-xorg rather than gdm :-)
<Nafallo> and maybe kill the recommends on -all packages at the same time. those are already first of alternative deps.
<bryce> ah yeah, good point
<RAOF> Nafallo: I think you still want to recommend them though, right?
<bryce> any other xorg changes we need while you're at it?
<Nafallo> RAOF: why?
<bryce> er, while *I'm* at it
<Nafallo> RAOF: it's redundant :-)
<RAOF> Because even if you've satisfied the dependency with a single driver, you still want to recommend all the drivers.
<Nafallo> bryce: not that pops out, but then I haven't looked that closely. just saw it when I was killing off some more packages from my harddrive :-)
<Nafallo> RAOF: why?
<RAOF> Nafallo: Because it's still useful?  It means people can just drop in any old graphics card and expect it to work.
<Nafallo> RAOF: it's the first dep, so goes in as default. if the user uninstalls those things he hopefully knows whats his doing.
<RAOF> True.
<Nafallo> Robot101: as long as we don't cut out the new and improved fall-back path that powerusers might not know about :-)
<Nafallo> bryce: maybe kill off ctrl+alt+backspace? ;-)
<bryce> ah yeah, I think I promised that, too
<RAOF> SAK is enough for anyone :)
<bryce> that one's going to be controversial
<Nafallo> s/Robot101/RAOF/
<RAOF> Oh, you're serious!
<RAOF> What's the rationale for that?
<Nafallo> bryce: yes :-)
<Nafallo> bryce: I'm tired of the discussions on the spec ;-)
<Nafallo> RAOF: kills data hard and fast if the user accidently hits it.
<Nafallo> causing dataloss
<Nafallo> thats the biggest I think :-)
<RAOF> Nafallo: Ok.  Yeah.
<bryce> well, I use ctrl-alt-bksp every day, multiple times, so will feel the pain of it going.  However, I figure anyone like me that actually does use and need it, probably is adequately knowledgeable to fiddle xorg.conf to turn it back on
<DShepherd> how easy is it to accidentally hit those key combinations? not very easy imho
<bryce> plus like Nafallo says, it's truly a data-loss issue, and since ubuntu is geared towards making rounded edges and such for users, I think it makes sense
<Nafallo> bryce: if not we need a graphical tickbox to turn it on somewhere :-)
<bryce> DShepherd: agreed, however I guess some users do.  It sounds like there's some apps that use keyboard shortcuts similar enough to that, that they do get hit
<RAOF> Can we (easily) catch it in a different way?  I suppose not, really.  That'd defeat the purpose.
<bryce> Nafallo: agreed; ideas on where it makes sense?  I was thinking displayconfig-gtk
<Nafallo> bryce: doesn't make sense I don't think. somewhere in gnome-control-center, and I'm sure KDE has an equivalent of that :-)
<DShepherd> bryce, ok. well as long as I can turn it back on :-) i have no problem-ish
<bryce> yeah I plan to leave a friendly comment in xorg.conf for us hackers
<Nafallo> bryce: keyboard shortcuts should be obvious. keyboard -> layoutoptions or whatsitcalled in english might be good as well :-)
<DShepherd> Nafallo, agreed
<DShepherd> sounds logical
<bryce> yeah the tricky thing is that this setting is in xorg.conf rather than in the gnome config
<bryce> but that should only take a sed or two ;-)  it'll just be a tad mussy
<Nafallo> hehe
<Nafallo> bryce: sed for the featurefreeze and fix it proper before release then :-)
<Nafallo> s/release/final/
<DShepherd> bryce, well.. its a 'hardcore' thing to do... so i dont think you need to find a place in the gui to turn it back on..
<DShepherd> bryce, it might just end up confusing us 'old' folks :-)
<bryce> DShepherd: yeah true
<DShepherd> bryce, i am going to the cli.. anyways..and I bet most people who are going to turn it back on.. are fairly familar with the CLI..
<DShepherd> bryce, but .. thats what i think..
* bryce nods
<bryce> well that's what led me to think that just sticking in a friendly comment in xorg.conf might be sufficient
<Nafallo> bryce: so upload and see what users do :-)
<bryce> but we'll see, I'm certain we'll get feedback on this one
<bryce> hehe
<DShepherd> bryce, you sure will..
<DShepherd> "I cant kill x. what happened?"
<DShepherd> "we disabled it but you can enabled it"
<DShepherd> "oh how"
<DShepherd> ....
<DShepherd> "ah. thanks"
<DShepherd> and life goes on!
<DShepherd> :-)
<bryce> "X is *too* bulletproof..."
<bryce> "This is a very annoying problem for me, as I am working with an
<bryce> application that uses Ctrl+Alt+End as a hotkey, and End is right above
<bryce> Backspace on my laptop keyboard."
<Nafallo> I think the consequences really does outweight the advantage :-)
<Nafallo> those that use it probably does it cause they are to lazy to ctrl+alt+f1 + login + sudo invoke-rc.d gdm restart
<Nafallo> :-P
<bddebian> Heya Nafallo
<Nafallo> hi bddebian
<DShepherd> bryce, question though.. would a 'newbie' have to reboot the machine to get X changes? cause that's so tedious..
<bryce> stuff in xorg.conf only gets parsed at X startup, so they'd at least need to restart X
<Nafallo> doesn't X get restarted on logout now?
<bryce> (which I'd generally do by just ctrl-alt-backspace, however in this case...)
<DShepherd> Nafallo, that's what i want to know..
<bryce> yup, just going back to the login screen should be plenty sufficient
<DShepherd> bryce, does it? ^
<DShepherd> bryce, kool.. well that ok for me
<Nafallo> then it's a non-problem.
<DShepherd> Nafallo, right
<Nafallo> I can't see any reason not to do it.
<DShepherd> Nafallo, same here.. bryce .. fire away
<Nafallo> and I would prefer logout/login before zapping stuff anyway :-)
<DShepherd> Nafallo, well....
<bryce> here's what I'm adding, lemme know if this looks ok - http://pastebin.ca/656398
<DShepherd> Nafallo, it depends for me :-) .. cause sometimes.. things just need to get zapped :-D
<Nafallo> there is always a risk of things hanging around while zapping. logout would kill things the proper way AFAIK
<DShepherd> Nafallo, i guess
<Nafallo> bryce: instead of changing the option, propose to comment it? :-)
<Nafallo> "use default"
<Nafallo> default behaviour even
<Nafallo> but that's just me not wanting to specify defaults in configs ;-)
<Nafallo> I'm fine with that wording :-)
<DShepherd> bryce, why not just say.. restarting x -- instead of making xorg terminate..
<bryce> ok
<DShepherd> Xorg.. which works..
<bryce> although technically it doesn't restart X, it just terminates it.  gdm is what restarts things
<DShepherd> bryce, point taken
<bryce> I'll say "exiting"
<DShepherd> bryce, but i knew that :-D
<DShepherd> hehehehehe
<Nafallo> because it is zapping :-)
<Nafallo> *s*
<bryce> quiz time
<bryce> xorg now auto-loads modules like dri, vbe, etc.
<Nafallo> I think terminate is good wording actually. Zap implies termination rather then exit :-)
<Nafallo> exit sounds to cleanish ;-)
<bryce> who knows how to *disable* an autoloaded module?
<Nafallo> why would you want to? I trust it to not load things I wouldn't need, right?
<DShepherd> bryce, well, right now. i dont
<bryce> there are some drivers which don't work properly with certain modules
<DShepherd> bryce, its not smart enough to know which module works best with which drivers?
<Nafallo> what DShepherd said... :-)
<bryce> not always
<bryce> answer here:  http://pastebin.ca/656409
<DShepherd> bryce, hmm...
<DShepherd> bryce, oh. well I know now
<bryce> I'm thinking of adding that to the xorg.conf - it would not be unlikely that someone editing their xorg.conf might need to be doing that, so this'd give them that clue
<Nafallo> I should have guessed :-)
<bryce> took me a while to figure that one out ;-)
<DShepherd> bryce, ok
<Nafallo> to logic? :-)
<bryce> hardly anyone will need that, but then, hardly anyone should need to touch their xorg.conf
<Nafallo> bryce: that one really should be in documentation rather then the conffile... again, gut feeling :-)
<DShepherd> Nafallo, i dont mind that though
<Nafallo> bryce: those that needs to know that know about /usr/share/doc/xserver-xorg/, right? :-)
<bryce> hmm, true
<Nafallo> DShepherd: I thought we wanted a smaller xorg.conf. that's why I'm a bit hesistant :-)
<bryce> ah, commented out lines don't count ;-)
<Nafallo> bryce: still clutter ;-)
<bryce> actually the reason I thought to add this is that for feisty, the dropping of the Modules section is new, and may confuse people
<Nafallo> more to read. harder for the n00b to find what he should do.
<Nafallo> most n00bs will probably be on IRC-channels asking anyway.
<Nafallo> and thats from #ubuntu-se experience :-P
<DShepherd> Nafallo, i vote to keep it in
<DShepherd> its just 8 lines.. and its good info
<DShepherd> no need to hide it :-)
<DShepherd> i think..
<Nafallo> sure. put it in. I'll take a look when I see the entire file instead ;-)
<StevenK> infinity: Ping, re: libnss-db again
<bryce> hmm, looks like it's not documented in the xorg.conf man page either.  I'll patch that up next time I do xorg-server
<Nafallo> bryce: you will soon, right? drop recommends, add depend and now manpage :-)
<bryce> the xorg upload will be tonight or tomorrow morning depending on when I can find a sponsor.  But the man page is over in the xorg-server package, so that's separate
<Nafallo> oki :-)
* Nafallo looks at StevenK 
<Nafallo> bryce: think you got a core-dev right there ;-)
<bryce> heh
<bryce> I've been having a build issue with xorg-server trying to sync to debian, probably a mesa mis-match.  So the man page change may have to wait a bit.
<Nafallo> oki
<bryce> http://people.ubuntu.com/~bryce/Testing/xorg/
<bryce> I'll post for upload once I've run it through my qa scripts, but the dexconf change is the only thing risky there
<bryce> bbl (dinner)
<keescook> LP uploads are down?
<Nafallo> bryce: I feel xorg-driver-video-vesa should be depend for xorg-server since displayconfig-gtk is and both are part of the fallback :-)
<pitti> Good morning
<sbalneav> Morning pitti.
<sbalneav> Say, you sprecken sie deutch, nein?
<sbalneav> If I install the language-support-de, and set LC_ALL=de_AT, LANGUAGE=de_AT, and LANG=de_AT on my login session, everything should be in german, correct?
<pitti> hey sbalneav
<pitti> sbalneav: LANGUAGE=de, but yes (if you want Austrian German :) )
<pitti> sbalneav: you can just select German in gdm's option menu (and just for one session)
<sbalneav> Ah, it worked
<sbalneav> Sorry, ltsp stuff, the new greeter.
<sbalneav> I selected de_DE.UTF8
<sbalneav> My system menu still says "system" in english
<pitti> sbalneav: that's ok, it's the same in German
<sbalneav> but under it, I have Einstellungen, Systemverwaltung, Info zu GNOME
<pitti> sbalneav: klingt Deutsch
<sbalneav> Du musst amboss oder hammer sein.
<pitti> lol
<sbalneav> Bonus points for guessing the german philosopher who said that.
<sbalneav> No googling, now
<pitti> no idea, sorry :/
<sbalneav> I'll give you a hint: he was saved by his mistress when Napoleon's sodiers invaded his house.  She beat them off with a stick.
<pitti> sounds like a communist
<sbalneav> Goethe
<pitti> wow
<sbalneav> I am a fount of useless trivial.
<sbalneav> err
<sbalneav> trivia
<sbalneav> pitti: What time does ogra usually wander in?
<pitti> sbalneav: relatively late, usually not before 0900 UTC
<pitti> mhb, Riddell: any idea about http://launchpadlibrarian.net/8800635/buildlog_ubuntu-gutsy-i386.restricted-manager_0.27_FAILEDTOBUILD.txt.gz ?
<pitti> mhb, Riddell: I don't have pyqtconfig either, but it builds for me
<doko_> good morning
<hat> hello
<hat> i have problem with VLC program
<hat> i want to open file py  UDP/RTP port by command line
<hat> how can i do that
<pygi> #ubuntu for support
<hat> ok Dear thanks
<fyrestrtr> is canonical planning to release launchpad as opensource? I would love to see how that is developed :)
<fabbione> fyrestrtr: you want to ask in #launchpad :)
<fyrestrtr> ah .. thanks.
<fabbione> no problem
<fyrestrtr> so many channels.
<fabbione> yeah no problem
<mdke> tracker is included by default in gutsy, right? Is it included in vanilla Gnome too?
<pygi> mdke, no, I don't think so
<mdke> right, that's what I thought too; thanks
<asac> morning
<pygi> hey asac !
<asac> pygi: hi
<pitti> mhb, Riddell: re my previous question, I got it (Debian bug 435855, was recently merged)
<ubotu> Debian bug 435855 in python-qt-dev "python-qt-dev: pyqtconfig.py shipped in both python-qt3 and python-qt-dev" [Serious,Fixed]  http://bugs.debian.org/435855
<Riddell> groovy
<Riddell> I had e-mailed you
<pitti> Riddell: thanks, just saw it
<StevenK> pitti: How do you feel about doing some NBS work? :-)
<pitti> StevenK: for you, always :)
* Hobbsee waves
* pitti hugs Hobbsee 
<StevenK> pitti: :-)
* Hobbsee hugs pitti :D
<StevenK> pitti: If you can wave vips through binary NEW, I'll upload nip2, and that should get two down in a publisher run or two.
<StevenK> pitti: I'll upload nip2 now. It has a versioned dependancy on libvips-dev, so it'll either fail and need to be given back, or just hit depwait and deal itself.
<pitti> StevenK: the latter should happen
<StevenK> pitti: My thought too, but just in case it doesn't. :-)
<StevenK> Uploading to ubuntu (via ftp to upload.ubuntu.com):
<StevenK> Connection failed, aborting. Check your network (111, 'Connection refused')
<StevenK> Hum.
<pitti> vips accepted
<StevenK> pitti: Thanks. Would you mind pointing a sysadmin at ^
<pitti> StevenK: poked
<pitti> StevenK: should work again
<StevenK> Just saw myself about 20 seconds before you said that. :-)
* StevenK pushes nip2's 8Mb orig tarball to drescher.
<_StefanS_> doko: hi, it seems like compiling in lpia is broken since yesterday
<doko> _StefanS_: what exactly?
<_StefanS_> doko: checking if C++ programs can be compiled... no
<_StefanS_> doko: configure: error: Your Installation isn't able to compile simple C++ programs.
<_StefanS_> :)
<_StefanS_> doko: all gcc, libstdc. headers, g++ and the like are installed. Along with build-essential. It worked yesterday
<doko> _StefanS_: please have a look at the config.log, it should have more details
<_StefanS_> doko: /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory
<_StefanS_> doko: got 100+ of lines with missing standard libraries
<doko> _StefanS_: ok, see it here as well, not with gcc-4.1, but with gcc-4.2
<Lutin> pitti: can you give-back freesci, mgcv, kernsmooth ppc and amd64, and libmail-box-perl, eric on i386 please ?
<_StefanS_> doko: can you fix it ? :)
<_StefanS_> doko: I have a few packages that need to be fixed in order to have all kde stuff done
<doko> _StefanS_: have to find the reason first ...
<_StefanS_> obviously :)
<pitti> Lutin: done; btw, no need to tell the arches, I'll just give them back on all that failed
<Lutin> pitti: ok :) . thanks
<StevenK> pitti: Would you mind seeing if nip2 has hit drescher? I haven't gotten an accepted mail, and it hasn't hit LP yet.
<pitti> StevenK: hm, it's not in accepted
<pitti> StevenK: in done, the last nip2 upload is seven weeks old
<StevenK> nip2_7.12.4-1ubuntu1_source.changes: done.
<StevenK> I uploaded that about 20 minutes ago ....
<pitti> *scratching head*
<pitti> I cannot find it anywhere
<pitti> StevenK: ah, got it
<pitti> StevenK: still in incoming
<pitti> for some reason
<StevenK> Ah. I was about to offer to re-upload it.
<Fujitsu> Not surprising that it's still there... when one part of Soyuz backend breaks the rest usually does too :(
<StevenK> pitti: Maybe the queue processor isn't running?
* pitti asks
<pitti> StevenK: ah
<pitti> IOError: [Errno 13]  Permission denied: '/srv/launchpad.net/ubuntu-queue/incoming/.lock'
<pitti> StevenK: ^ I just ran it by hand
<Fujitsu> Um...
<doko> _StefanS_: ok, found, wil be fixed soon
<StevenK> Ah. It's busticated.
<_StefanS_> doko: sweet :D
<Hobbsee> again
<_StefanS_> doko: thanks alot
<pitti> StevenK: no, I am, sorry
<pitti> StevenK: ran it as the wrong users
<Fujitsu> pitti: Wrong user?
<Fujitsu> Hahha, yes.
<StevenK> pitti: Heh
<pitti> Fujitsu: I'm a bit confused
<pitti> the cronjob belogns to lp_queue, but the lock file is owned by lp_upload
<pitti> ok, I got it; apparently the lock file was stale
<iwj> Stale lockfiles ??  Surely it should be using fcntl or flock ?
<pitti> StevenK: it's in done now
<pitti> iwj: I guess that's what it does
<pitti> iwj: but the lock file that lp_buildd creates and uses was owned by lp_upload, which made it except out with an EPERM
<pitti> I guess that was just a fallout from the uploader crash this morning
<pitti> StevenK: https://launchpad.net/ubuntu/+source/nip2/7.12.4-1ubuntu1
<StevenK> pitti: Thanks
<Lutin> pitti: would you know why this happens: http://launchpadlibrarian.net/8807191/buildlog_ubuntu-gutsy-i386.libmail-box-perl_2.070-1_FAILEDTOBUILD.txt.gz ? (bith packages are in universe and libtest-harness-perl is 2.64 in ubuntu)
<pitti> Lutin: I bet it's because perl-modules Provides: libtest-harness-perl
<pitti> Lutin: and apparently the dependency resolver isn't clever enough for that
<tkamppeter> hi pitti
<pitti> hey tkamppeter
<pitti> Lutin: I bet it fails on Debian, too
<tkamppeter> pitti, have you seen my mail yesterday? CUPS 1.3 is officially released.
<pitti> Lutin: just because Debian doesn't build arch:all on buildds, they won't notice
<pitti> tkamppeter: yep, I saw; not sure whether this kind of last-minute switch is something we should do
<pitti> tkamppeter: does it work with hplip and all the other drivers and backends that we have?
<pitti> libtest-harness-perl: already installed (=*=PROVIDED=*= >= 2.62 is satisfied)
<pitti> Lutin: ^
<Hobbsee> morning seb128
<tkamppeter> It will avoid a generation change for the gutsy+1 LTS when we do the change now.
<seb128> hi Hobbsee
<pitti> tkamppeter: true that
* Hobbsee hugs k3b
<tkamppeter> We will also have 2 months for bug fixing until Gutsy will get released.
<pitti> tkamppeter: right
<Lutin> pitti: ok, I see
<Lutin> thanks
<pitti> tkamppeter: so if you are prepared to have a look on the bug list, that's fine
<tkamppeter> And I think users will complain if they get CUPS 1.2 with their distro and CUPS 1.3 is released.
<pitti> tkamppeter: btw, can you test the hplip driver? I need to fix the apparmor profile and got some logs, but it would be nice to test it before I upload
<pitti> tkamppeter: most users won't care, I guess
<pitti> tkamppeter: gss is in universe, though, that needs a MIR and checking
<tkamppeter> pitti, some printouts with HPLIP I already did but I will do more testing.
<Lutin> pitti: but libtest-harness-perl is also a separate source package, why isn't that used instead of the provided version ?
<pitti> tkamppeter: the current cups in gutsy should fail with hplip with the aa profile enabled
<pitti> Lutin: see above line I quoted; the dependency resolver in the buildd does the wrong thing
<tkamppeter> Only problem which I have seen recently, but this is independent of the CUPS version, is the broken poppler filter.
<pitti> Lutin: that's an infinity problem, I'm afraid
<pitti> tkamppeter: right, printing pdf is busticated
<pitti> tkamppeter: geser attached the diff of the old and new .ps, was that conclusive somehow?
<pitti> tkamppeter: probably something we should forward to the poppler upstream guys
<tkamppeter> pitti, for this I have compiled the original pdftops as a workaround (not in the packages, only on my local box)
<tkamppeter> pitti, I think so, too, for them it is probably much easier than for us to fix it.
<pitti> tkamppeter: a nasty fallback hack if all else fails could be to modify cups' pdftops filter to use pdf2ps from ghostscript instead of pdftops from poppler
<tkamppeter> pitti, I will test the HPLIP with "sudo aa-complain cupsd" and send you the /var/log/syslog which contains the complaints.
<pitti> tkamppeter: I have that log already
<pitti> tkamppeter: I'll provide an updated profile; once I have it, can I send it to you for a final test?
<tkamppeter> pitti, yes, whre we have Ghostscript 8.6x now we can use Ghostscript as PDF interpreter.
<tkamppeter> pitti, yes, send it to me.
<pitti> tkamppeter: great, thanks
<Lutin> pitti: btw, when using requestsync -n , the email gets rejected from Malone it tries to affect ubuntu/%srcpkg, which does not exist. the following patch (http://people.dunnewind.net/lutin/requestsync.patch) should fix it, mind having a look at it ?
<tkamppeter> pitti, how can I see whether an already installed package is in main or in universe?
<Hobbsee> anyone know when dholbach gets back?  maybe seb128?
<seb128> Hobbsee: next week
<pitti> Lutin: ah, that makes sense, thanks
<Hobbsee> seb128: ah, great!  thanks.
<seb128> you're welcome
* Hobbsee can pick his brains then, then.
<pitti> tkamppeter: just use "rmadison -u ubuntu <package>"
<Lutin> pitti: np
<tkamppeter> pitti, thank you, did not know the rmadison command before.
<StevenK> Lutin: Ah ha. I can patch it if you like.
<StevenK> I have a devscripts merge pending upload as soon as I fix a few conflicts.
<pitti> please
<tkamppeter> There are two build-depends of the new cupsys in Universe: heimdal and libgss
<pitti> tkamppeter: erk, heimdal? doesn't it work with the MIT implementation?
<pitti> tkamppeter: (libkrb5-dev)
<pitti> tkamppeter: I would really like to avoid getting that into main again
<Lutin> StevenK: yep, thanks
<pitti> mhb: if you have some minutes, can you please look at bugs like bug 131483?
<ubotu> Bug 131483 on http://launchpad.net/bugs/131483 is private
<pitti> mhb: (public now)
<StevenK> Lutin: I'll try and sort out devscripts tonight.
<Lutin> StevenK: ok
<Fujitsu> Why does compiz keep eating my configuration on upgrades? And eliminating keyboard shortcuts, causing my machine to remain unlocked?
<mvo> Fujitsu: do you have the latest compiz from gutsy? that one is meant to give a much improved compatiblity with the old metacity keysettings
<Fujitsu> mvo: The latest one /broke/ them.
* pitti wonders where the setfacl command has gone to
<pitti> command-not-found claims it's in package 'acl' which does not exist
<Fujitsu> All the previous versions worked, but this one reset all my config again, and eliminated some keybindings which I can't work out how to restore.
<Fujitsu> pitti: I'm sure it's in acl...
<pitti> oh, I see, apt-get update md5sum mismatch *grumpf*
<mvo> pitti: the data for c-n-f is not up-to-date unforatunately
<mvo> Fujitsu: hrm, that is bad :/
<pitti> mvo: seems to work now
<mvo> Fujitsu: did all of them broke? or only some?
<pitti> setfacl: /dev/bus/usb/003/009: Operation not supported
<pitti> seems that our tmpfs doesn't support ACLs yet :/
<geser> pitti: # CONFIG_TMPFS_POSIX_ACL is not set (from /boot/config-2.6.22-9-generic)
<pitti> yeah
<Kmos> who look for ~ubuntu-main-sponsors ?
<Kmos> MOTU ?
<seb128> Kmos: the ubuntu-main-sponsors members
<seb128> Kmos: no, MOTU is for universe
<Fujitsu> mvo: I haven't used anything special other than screen-locking in the past.
<Kmos> seb128: errr.. ups, didn't check that
<mvo> Fujitsu: how did you setup that keybinding? via system/preferences/keyboard shortcuts? or by some other means?
<seb128> Kmos: why?
<Fujitsu> mvo: The former.
<Kmos> seb128: don't remember to check +members of it :) sorry..
<seb128> k
<Fujitsu> mvo: It's still set there.
<seb128> no problem ;)
<mvo> Fujitsu: I think I can reproduce the issue, c-a-L does not work for me too
<mvo> Fujitsu: I'm investigating
<Fujitsu> mvo: Oh, good :)
<Fujitsu> Thanks!
<mvo> geser: the problem with the decorator is that I have currently no idea what to do when no gconf is available in the decoration plugin (i.e. when kde is used). I need to look/think about it (re #128557)
<pitti> hey Keybuk
<Zic> have just passed to gutsy, and I noticed that the decorator of window was... smaller than normally. On my small screen, it is annoying: /
<pitti> Keybuk: FYI, I just tried hal with CK and ACL magic
<Zic> same problem since Tribe 2 iirc
<Keybuk> ello
<Kmos> gparted is used in live-cd installation for set partitions ?
<Keybuk> pitti: how did it go?
<pitti> Keybuk: unfortunately our kernel doesn't enable ACLs for tmpfs, so it doesn't actually work :-(
<pitti> Keybuk: however, it builds, and the debug output actually calls a reasonably looking setfacl command
<mvo> Fujitsu: ctrl-alt-l used to work for you with compiz? but it does no longer, is that correct? I'm wondering what eats that keybinding currently
<Keybuk> pitti: yeah, I nagged the kernel guys about that a few weeks ago
<Keybuk> could you try a kernel with acls enabled and see what happens?
<Mithrandir> Keybuk: are you interested in boot failures with / on md?
<Mithrandir> (gutsy)
<pitti> Keybuk: I'll build one
<Keybuk> Mithrandir: sure
<Mithrandir> Keybuk: it tries to start, but ends up just stopping md0 a whole lot of times.  If I do break=mount and start the raid by hand, it works.
<Keybuk> stopping md0?
<Keybuk> what does md0 consist of?
<Mithrandir> [   39.000120]  md: md0 stopped.
<Mithrandir> it's a raid1, so sda2 and sdb2
<Fujitsu> mvo: It worked until about 48 hours ago, AFAICR.
<mvo> Fujitsu: ok, thanks
<Mithrandir> root=/dev/md0 is passed from the kernel command line.
<Kopfgeldjaeger> hi
<Keybuk> Mithrandir: is there anything raid/md related in scripts ?
<pitti> Keybuk: 'k, kernel build started
<Mithrandir> Keybuk: doesn't appear to be, no.  (find /usr/share/initramfs-tools/scripts -name \*md\* -o -name \*raid\* doesn't return anything)
<tkamppeter> pitti, I have rechecked the build dependencies of CUPS and I have found out that one can build it with all new features not needing anything from Universe.
<pitti> tkamppeter: yay, cool; gss didn't look that bad, but heimdal was; so it builds with MIT krb?
<Keybuk> Mithrandir: ok; way to debug it is to break before udev is started, do that script manually by hand running udevd --verbose > /dev/udevd.log 2>&1 or something, delete the script, and then allow things to resume normally
<ogra> Mithrandir, wasnt that in hook-functions ?
<Keybuk> then we'll have a log of what udev received and did
<tkamppeter> pitti, I could use libkrb5 from main instead of heimdal from Universe and libkrb5 also brings the GSS API, so I could drop libgss.
<ogra> Mithrandir, oh, sorry thats only the module loading
<tkamppeter> pitti, yes CUPS 1.3 builds with MIT libkrb5.
<pitti> tkamppeter: splendid!
<pitti> tkamppeter: does your package have all of our current patches applied?
<tkamppeter> What is the bad of heimdal? Insecure? Unmaintained? Pulling a lot of Universe dependencies?
<pitti> tkamppeter: I think one or two might have been accepted upstream
<Mithrandir> Keybuk: that script == the ./init-premount/udev script?
<pitti> tkamppeter: not particuarly, but maintaining two implementations in main is just overhead
<tkamppeter> pitti, I have merged the CUPS with your newest with all patches which Mike did not fix upstream in 1.3.
<pitti> tkamppeter: cool; did you get any serious merge conflicts?
<tkamppeter> pitti, you are right libkrb5 and heimdal do the same thing.
<Keybuk> Mithrandir: premount one
<Keybuk> Mithrandir: yes
<tkamppeter> pitti, no problem with the merge. I had to rediff some patches because Mike did changes at places close to our changes, but all worked fine.
<Mithrandir> Keybuk: thanks, I'll try that.
<pitti> tkamppeter: I should upload that to Debian as well then if it doesn't break PPDs etc. which worked for 1.2
<tkamppeter> pitti, CUPS 1.3 with the new dependency settings built fine on my local system, now I am running it through pbuilder.
<pitti> tkamppeter: it even works with the current AA profile? cool
<tkamppeter> pitti, Foomatic PPDs pass the new cupstestppd without warnings, the HP PostScript PPD of my LaserJet 3390, too.
<Lutin> hum, sorry for asking, but isn't that: http://launchpadlibrarian.net/8807886/buildlog_ubuntu-gutsy-amd64.mgcv_1.3-24-1_FAILEDTOBUILD.txt.gz somehow related to a gcc issue ?
<Lutin> (or maybe feature which I'm not aware of. if so, sorry for the noise)
<Mithrandir> Lutin: ouch.  Looks toolchain-related, yes.
<tkamppeter> pitti, pbuilder test passed. Will replace the packages on my server by the current ones.
<pitti> tkamppeter: thanks
<Lutin> Mithrandir: actually - just tested on my box and it seems to be gcc-4.2 only
<Kopfgeldjaeger> pitti: does the fwcutter "create" more files than (?) the .fw file?
<pitti> Kopfgeldjaeger: yes, should be some 7
<tkamppeter> pitti, "ldd /usr/sbin/cupsys" shows all new features really being built in: Kerberos, Zeroconf, LDAP, ...
<tkamppeter> pitti, one test which I did yesterday is also system-config-printer. It works perfectly with CUPS 1.3.
<pitti> rock
<pitti> tkamppeter: ok, so here's my plan: I update the AA profile now, send it to you, you test it with a real hplip setup, and if it works, I'll update the packages?
* ogra really has to look at the new cups hal backend for gutsy+1 and ltsp
<tkamppeter> pitti, now I have replaced the packaqes on my server. The files have the same names as before, but now they are with main-only dependencies, full-featured, and pbuilder-checked.
<pitti> ogra: it's installed by default in ubuntu now
<ogra> pitti, not in thin client chroots
<pitti> ogra: and I flipped g-c-m to s-c-p in edubuntu seeds, too for now (I think)
<pitti> ogra: right, not in chroots; that would be a bit heavy IMHO
<ogra> pitti, i need a proper forwarder for all the hal backends to talk  to the users session
<tkamppeter> OK pitti, I have also uploaded my compiled binaries so you can download them to quickly do your AA tests.
<ogra> (in ltsp)
<pitti> ogra: but usually the thin clients would print to the printer connected to the server, no?
<ogra> pitti, the plan is to have the session hal talk to the clients HW at some point
<pitti> tkamppeter: I need amd64 binaries, but don't worry, it's just replacing the file in /etc/apparmor.d/
<ogra> pitti, nope, we have locally attached printers and ltsp even has the opportunity to set up a diskless netbooting printserver for a whole company
<ogra> pitti, currently ltsp clients emulate a jetdirect printer and forward whats coming in on port 9100 1:1 to the printer device
<pitti> ogra: ok, that's a bit more advanced
<pitti> ogra: but on the server side the magic should just work now
<tkamppeter> pitti, as you can modify seeds, can you check whether the following packages go onto the CDs of Ubuntu/Xubuntu/Edubuntu/Server and add them to the seeds if needed:
<ogra> right
<pitti> tkamppeter: wrt magic, s-c-p still defaults to using the gdi driver instead of splix
<pitti> tkamppeter: you can check that yourself by looking at the .manifest/.list files (on cdimage)
<tkamppeter> splix, m2300w, pxljr
<pitti> tkamppeter: splix is still in universe, so that won't
<pitti> tkamppeter: apt-cache rdepends for the other two doesn't show anything, so 'no'
<tkamppeter> pitti, I will check this, but as this is a bug and not a feature I have now more worked on features, like s-c-p, CUPS 1.3, ... bugs can also get fixed after UVF.
<pitti> tkamppeter: yeah, that's perfectly fine
<pitti> let's get cups 1.3 in
<tkamppeter> pitti, why is splix in universe, it was approved (by you) to go into main: https://wiki.ubuntu.com/MainInclusionReportSplix
<tkamppeter> pitti, can you move it into main?
<pitti> tkamppeter: yeah, can do
<pitti> tkamppeter: erm, it *is* in main, sorry
<tkamppeter> m2300w, pxljr are in main, too?
<pitti> see madison, yes
<tkamppeter> So then I think it is no problem to seed these three. They are not very big, as they are drivers for only a few printers.
<Lutin> Mithrandir: same thing happens with kernsmooth (gcc 4.2 too)
<pitti> tkamppeter: m2300w is quite big (0,5 MB)
<pitti> tkamppeter: splix and pxljr are trivial, right
<ogra> Hobbsee, ....
<ogra> <sbalneav> I'll give you a hint: he was saved by his mistress when Napoleon's sodiers invaded his house.  She beat them off with a stick.
<ogra> <pitti> sounds like a communist
<ogra> Hobbsee, are you a communist ?
<tkamppeter> Yes, m2300w seems to have some color profiles whereas the others are for BW lasers
<doko> seb128: is inkscape gnomish? if yes, please have a look at the build failure on lpia
<pitti> I was referring to sbalneav's quote
<ogra> pitti, bah, context makes it only half as funny :)
<Hobbsee> ogra: uh...wha?
<tkamppeter> pitti, but would be great to have m2300w on the CDs, to one more class of printers which simply works.
<Hobbsee> ogra: where was that
<pitti> tkamppeter: any chance to downsize it a bit? using bzip2, splitting out docs, or sth?
<ogra> Hobbsee, a quiz about goethe quotes between sbalneav and pitti this morning :)
<Hobbsee> ogra: ahh...
<Hobbsee> ogra: green aliens have no particular pollitical affiliation, neither any things like communism.
<Hobbsee> ogra: green aliens have no need for them.
<ogra> lol
<Hobbsee> ogra: but clearly, it wasnt me.  your quote mentions "a stick".  the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  is *the* stick.
<pitti> tkamppeter: can you please replace /etc/apparmor.d/usr.sbin.cupsd with http://people.ubuntu.com/~pitti/tmp/usr.sbin.cupsd and test with hplip?
<ogra> Hobbsee, but it seems it has german ancestors ;)
<Hobbsee> ogra: unfortunately, green aliens have no german ancestry.
<ogra> Hobbsee, well, looking around me in this country i often doubt that :)
<Hobbsee> ogra: :)
<tkamppeter> pitti, the size of m2300w comes from the color profiles in /usr/share/m2300w/0.51/psfiles/
<pitti> tkamppeter: you probably need to do "sudo aa-enforce cupsd" to tell AA to reload the profile
<pitti> tkamppeter: hm, bzip2 compression doesn't help
<_StefanS_> doko: hey got your mail :) - the keep build failure you're referring to, what exactly do you want me to look ?
<doko> _StefanS_: let the package build without failure? ;-P
<_StefanS_> doko: argh :) - then push the updates now :D
<_StefanS_> doko: you screwed up the gcc :)
<_StefanS_> doko: I will just wait those 2-3 hours... and get back to you.
<Hobbsee> ogra: besides, i'm not a mistress :P
<mhb> pitti: hi, I'll take a look
<Mithrandir> Hobbsee: nor do you usually attack Napolean's soldiers?
<Hobbsee> Mithrandir: no.  i didnt even attack my boss today, come to think of it.
<Fujitsu> Mithrandir: That's what she wants you to think.
<ogra> Mithrandir, do you think sh met one ?
* Hobbsee just attacks those who tickle her.
<pitti> mhb: good morning; thanks!
<mhb> pitti: ah yes, I know where that one comes from
<mhb> pitti: I can fix it in a jiffy
<pitti> cool
<Mithrandir> Hobbsee: no, you don't. :-P
<Hobbsee> Mithrandir: okay, and a few others as well :P
* Fujitsu watches Hobbsee stomp on Mithrandir's feet.
* Mithrandir is levitating today, so she'd fail if she tried.
* Hobbsee throws icecubes at Mithrandir instead.
<Hobbsee> Mithrandir: why are you levitating?
<Mithrandir> Hobbsee: why not?
<Mithrandir> (or, because then you can't stomp my feet)
* ogra wants some icecubes as well ... europe is warm ...
<Hobbsee> Mithrandir: because then you'll have insane ideas.
<Hobbsee> ogra: how warm?
<Mithrandir> 19C here
<ogra> only 25C here
<siretart> 25 degrees in my office :/
<ogra> but warm enough for ice cubes
<Hobbsee> pft
<geser> Mithrandir: you should get some steel-capped shoes for the next time Hobbsee tries to stomp on your feet
<StevenK> ogra: It's 12 degrees here, I'll swap you.
<Mithrandir> geser: spiked steel-capped shoes might be fun
<Hobbsee> you europeans dont know real heat
<Kmos> bug 131311
<ubotu> Launchpad bug 131311 in Ubuntu "tribe cd images not being produced for powerpc" [Undecided,New]  https://launchpad.net/bugs/131311
<Fujitsu> About 8 degrees here.
<Mithrandir> Hobbsee: sure we do.  It's not hot here now, for instance.
<ogra> just warm :)
* Fujitsu shakes a fist at 42 degree summer days.
* Spads basks in a 16 degree summer day
* Hobbsee takes her second jacket off, after all this talk of heat.
<Nafallo> bryce: didn't find anyone to upload for you? :-)
<Hobbsee> Mithrandir: it does occur to me that i'll have to learn to cope with the cold, in europe
<Mithrandir> Hobbsee: it's not cold here either.
* Fujitsu likes European winters.
<Hobbsee> Mithrandir: for a non-australian value of "not cold"
<Nafallo> Fujitsu: good for you :-P
<ogra> Hobbsee, just wait another year or two, global warming willo adjust that for you :)
<Hobbsee> ogra: excellent!
<Nafallo> ogra: I don't like the outcome of that this year. far too much rain...
<Mithrandir> Hobbsee: pft, you claim it's cold when it's still fine to walk around in shorts and t-shirt.
<Nafallo> :-P
* Kmos it's 21C here
<ogra> yeah its turning tropical here as well, warm and humid all the time
<Kmos> Portugal :)
<StevenK> Spads: That isn't summer ...
<Nafallo> Mithrandir: surely only fine for vikings like us ;-)
<Spads> StevenK: Why not?
<Spads> It's only August
<Hobbsee> Mithrandir: for you, yes.  i tend to be a little thin, and therefore freeze.
<Mithrandir> Hobbsee: you claim I'm fat? ;-P
<Nafallo> lol
<ogra> Mithrandir, you work for canonical :P if you are not yet, you will be soon :P
<Hobbsee> Mithrandir: no. just not as thin as i happen to be.
<Spads> <Mithrandir> DOES THIS ROBOT PRINCESS CROWN MAKE ME LOOK FAT?
<Hobbsee> :P
<Fujitsu> O_o
<Hobbsee> Mithrandir: probably a good thing
* Nafallo gives Mithrandir more pizza
<mhb> pitti: it seems to be fixed
* Hobbsee steals the pizza, and munches
<mhb> pitti: (now in my branch)
<Nafallo> true. Mithrandir has skills in the kitchen. he shouldn't be allowed to eat pizza ;-)
<Lutin> pitti: can you give-back nethack please ?
<Hobbsee> Nafallo: skills in cooking, or skills in poisoning?  or are these not mutually exclusive?
<Nafallo> Hobbsee: I've only experienced the first of those skills :-)
<ogra> Hobbsee, skills in dishwashing ?
<Hobbsee> ogra: or them.
<pitti> Lutin: kicked
<Lutin> thanks
<Mithrandir> Hobbsee: I have yet to to kill anybody with my food.
<Hobbsee> Mithrandir: that you'll admit to
<Mithrandir> true
<Hobbsee> Mithrandir: or is that just to soften them up, so you can go take them to your cave and eat them?
<jwendell> Hi, seb128
<jwendell> seb128, do you use clearlooks?
<Mithrandir> Hobbsee: yeah.  meat > skin and bones.
<xxxxx1> mornin' people
<Hobbsee> jono: ping
* Hobbsee waits for the contentless_ping.pl to kick in
<infinity> Hobbsee: You sent jono a contentless ping, please try again with some useful content, kthx.
<jono> Hobbsee: pong
<infinity> (better?)
<jono> infinity: arf arf :)
<Hobbsee> infinity: no.  :P  that's not the correct response
<Hobbsee> You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<Hobbsee> *that* is the correct response
<infinity> Mine's better.
<Hobbsee> infinity: maybe i'll change mine.
<Hobbsee> infinity: it's useful for random people pinging me, when i dont want to speak to them :P
<infinity> I find that I don't often want to speak to anyone, so just pretending to be asleep (do people still believe I sleep?) works well.
<Hobbsee> infinity: ahh.  and most people dont think to check a /whois
<Hobbsee> infinity: unfortunately, most of the people to do with irc *do*.
<Hobbsee> also, connecting in as LongPointyStick is also effective
<geser> ah, Hobbsee reveals all her secrets
<Hobbsee> geser: no, not all.
* Hobbsee has most effective ways of hiding
<Hobbsee> geser: i havent revealed why i have this particular real name, for eg.
<geser> Hobbsee: why have you this particular real name?
<Hobbsee> geser: to avoid excessive amounts of harassment
<Hobbsee> geser: seriously.  i'd go from being harrassed multiple times each week, at times, to zilch.
<Hobbsee> from randoms in #ubuntu, and wherever else.
* Hobbsee is still stunned over that
<dendrobates> hobbsee: harassed how?
<infinity> Hobbsee: OMG, UR A GIRL LOL?!
<infinity> Hobbsee: A/S/L!!!
<elkbuntu> infinity, dont be silly. girls dont exist on teh intarweb
<Kmos> lol
<Kmos> another one :)
<geser> elkbuntu: only as .jpg?
<elkbuntu> geser, well a request for one of those usually accompanies these conversations
<Hobbsee> infinity: 93.  green alien.  antarctica.
<geser> elkbuntu: :(
<elkbuntu> Hobbsee, i think geser failed to get the reference. do you have the link handy? :)
<Hobbsee> !women
<dendrobates> http://www.urbandictionary.com/define.php?term=a%2Fs%2Fl
<ubotu> The women and men of the Ubuntu women project hang out in #ubuntu-women. Encouraging women to use linux? Read http://www.tldp.org/HOWTO/Encourage-Women-Linux-HOWTO/ for some suggestions compiled by women who use Linux on how to do so effectively.
<Hobbsee> bah
<Hobbsee> !girl
<ubotu> Girls dont exist on the internet.  See http://www.escapistmagazine.com/print/17/27
* Hobbsee tries not to make a reference about "big and curvy".
* Hobbsee hides from elkbuntu
<dendrobates> I had actually never seen A/S/L before.   I am so sheltered/old.
<elkbuntu> Hobbsee, oh? do i hear you right? you want to be thrown in a pool? :
* Hobbsee rofl's
<Hobbsee> elkbuntu: i think you do.  or you want the other
<elkbuntu> Hobbsee, if you continue, i will hold you under :
<Hobbsee> you couldnt.  you wouldnt dare.
<Hobbsee> elkbuntu: but does this mean you'll refuse to be my room mate?  :P
<elkbuntu> Hobbsee, between this conversation and 'the other side of the wall'... likely
* Hobbsee tries not to laugh too loudly, or bash something
* Hobbsee tries very hard nto to think about the other side of that wall
* elkbuntu tries to choose between choking on water, or shorting out her laptop
<Mithrandir> elkbuntu: turn, choke.
<Mithrandir> or rather, turn, spill water on floor
<elkbuntu> Mithrandir, that was no freudian slip, i know ;)
* Hobbsee shoudl so not be being evil, like this.
<elkbuntu> Hobbsee, i agree
<Hobbsee> Mithrandir: were you ever evil, btw?
<Hobbsee> elkbuntu: actually, i dont thikn i should remind Mithrandir.
* Hobbsee shuts up
<Mithrandir> Hobbsee: no, I'm nice
<Hobbsee> Mithrandir: oh good
<elkbuntu> Mithrandir, a perfect little angel, right?
* Hobbsee snorts
<Mithrandir> yup
<Hobbsee> sure sure
* elkbuntu plucks one of Mithrandir's wing feathers.
<Hobbsee> hiya evand.  welcome to the madhouse.
<evand> good morning Hobbsee, everyone
<geser> elkbuntu: seen the movie "Dogma"?
* StevenK sighs, and plays "Find the missing right curly in a 1,300 line perl script" again.
<viviersf> is beagle or tracker gonna be installed by default in gutsy ?
<elkbuntu> geser, dont think so, no
<evand> tracker is, isn't it?
<pygi> sadly :P
<StevenK> elkbuntu: Matt Damon, Ben Affleck as angels of death. Oh, and Jay and Silent Bob.
<StevenK> Stupid movie.
* elkbuntu doesnt watch many movies.. attention span too short :
<StevenK> Oh, who'd have guessed?
* StevenK hides.
* elkbuntu thwaps StevenK with a long pointy hobbsee
<StevenK> Ha
* Hobbsee is not long and pointy!
<StevenK> elkbuntu: Can you find where this missing curly is supposed to be? :-P
* Hobbsee does not work well as a throwing implement, either.
<elkbuntu> StevenK, i can give you a hint. 'the last place you look'
<elkbuntu> have fun! :D
* StevenK throws Fujitsu at elkbuntu 
<geser> elkbuntu: except you look there first, then it's the first place you would search
* StevenK sighs, and comments out half the script.
<StevenK> Grah. Now dch is broken.
<StevenK> "2.10.7-1ubuntu1" -> "2.10.7-1ubuntu1ubuntu1"
* Fujitsu breaks dch further.
<Kano> hi, how about only starting X in init 5
<Hobbsee> StevenK: ...impressive
<Chipzz> Kano: no
<thom> ubuntu doesn't really differentiate runlevels
<Chipzz> Kano: runlevels are different in debian/ubuntu than in RH
<Kano> i know that
<Chipzz> than why do you ask?
<Chipzz> *then
<Kano> but there is no way expect single user mode not to start X
<Kano> or is there another option to get rid of x
<Chipzz> sure there is
<Kano> and how it is called
<Chipzz> start in some other runlevel than 2
<Kano> haha
<Kano> as 2-5 are the same
<Kano> what should that do
<Chipzz> then file a bug to have gdm not start in some other runlevel then 2
<Kano> 5 is the runlevel where it should start
<Chipzz> no it is NOT
<Fujitsu> Kano: In RH that is where it starts.
<Kano> Fujitsu: and in many other distros too
<Fujitsu> Probably because they're RH-based.
<StevenK> 2-5 are the same by default. If you change that, the system should respect it. If it doesn't, it's a bug.
<Chipzz> last time I checked, unless you are some important debian developer you do not get to dictate how each run-level is used...
<broonie> This comes from Debian which has done this since forever.
<Kano> thats right, and i always changed the runlevels ;)
<Chipzz> StevenK: it may be considered a bug (/waste of runlevels) that runlevels 2-5 are not differentiated
<Kano> i have got a gfx card which does not init with ati or vesa driver
<Kano> only with fglrx
<Kano> need to stop x from loading, without splash option i can get rid of the splash at least - as this does not work too
<StevenK> Kano: Then drop the single user?
<Kano> but i would not consider to use single user mode as good workaround
<StevenK> s/the/to/
<thom> so just delete the symlinks in the other runlevels. that's why we provide them; it's a user customisation
<Kano> do you really think i dont know thi
<Kano> s
<thom> so why do you think it should change globally?
<Kano> i am using primary your live systems for testing
<Chipzz> thom: which do get recreated the next time the package is upgraded...
<thom> Chipzz: nope
<thom> if they do, that's a bug in the package
<StevenK> keescook: Are you around?
<Kano> and why are the kernel patches i proposed not acceptet? there are only simple pci id addons
<Kano> i dont like to write 100 pages of bug reports to get em in
<Kano> i tried it once, nothing changed
<Hobbsee> Kano: surely you'd ask the kernel team that...
<Kano> the only thing that was solved was the fuse update
<Kano> also your ntfs-3g is outdated, get the update from sid
<Kmos> in Gnome: Menu "System" -> click on "About Ubuntu" , it doesn't work.. can't open file xml file..
<Kano> this is a major package for write support, should be always current
<thom> whining in this channel is a perfect way to get people to ignore you; please follow the procedures like everyone else
<Kano> ok. sid still did not add it ;) but it is on mentors
<Kano> and it works
<tkamppeter> pitti, are you there?
<Kano> http://mentors.debian.net/debian/pool/main/n/ntfs-3g/
<mjg59> Kano: Point us at the bug in launchpad and it'll get fixed
<pitti> tkamppeter: back
<mjg59> Kano: Otherwise it's unlikely that it will be. You've been told that on several occasions
<Kano> mjg59: i added 5 test bugs, only one solved
<mjg59> Kano: Numbers?
<Kano> why should i waste my time?
<mjg59> Kano: Because, right now, you're wasting *our* time
<pitti> tkamppeter: any luck with the updated AA profile?
<mjg59> And you're the one that believes there are issues
<Kano> i know they are issues
<Kano> i dont "believe" it
<mjg59> Kano: Then point us at a bug report precisely describing the issues and your proposed resolution
<mjg59> Or, alternatively, spend the next five years failing to get them fixed
<Kano> it cant be the point to write a endless description when i even attach the fix
<mjg59> Kano: Yes, it can. We don't alter packages without understanding the problem.
<Kano> then ubuntu will always be not that optimized than it could be
<Kano> just because of ignorance
<infinity> Kano: Applying patches that aren't well-explained is a surefire way to break things.
<StevenK> infinity!
<StevenK> infinity: *poke* :-P
<infinity> Kano: If you know the fixes are correct, surely you know how to explain why that is?
<infinity> StevenK: OW.
<Kano> infinity: i do not always own the hardware that requires em
<mjg59> Kano: If you point me to a launchpad bug containing a description of the problem and a patch, then I will get any kernel fixes applied
<Kano> but others use the patches versions and they work
<mjg59> But without that, it's not happening
<Kano> mjg59: it really seems you dont know who i am
<tkamppeter> pitti, no, I had to return to complain mode to get my HP printer printing.
<pitti> tkamppeter: can you please send me the dmesg output?
<pitti> tkamppeter: so we need some more iterations (not entirely unexpected)
<mjg59> Kano: Until I've seen your name on a significant number of patches that have been accepted into the upstream kernel, it doesn't matter who you are
<StevenK> infinity: I'd like to get yada killed before UVF, which is sneaking up ...
<tkamppeter> And looking into /var/log/syslog I see 100s of lines PERMITTING, no BLOCKING or similar.
<StevenK> Well, killed would be nice. Demoted is the current goal.
<mjg59> Kano: We have no reason to believe tht your patches are automatically better than anyone else's - as a result, they will go through the same procedure
<Kano> mjg59: currently the ubuntu kernel + 3 applied patches use serveral kanotix user without problems. you can be sure that adding the right pcis to the right modules does not hurt
<mjg59> Kano: No, I can't be certain
<mjg59> We have a significantly larger number of users than you
<pitti> tkamppeter: yeah, in complaint mode it will be PERMITTING, in enforce mode REJECTING
<mjg59> And we need to be able to explain to upstream what these patches do
<StevenK> And the explanation "Because $USER said so" doesn't cut it.
<mjg59> In the time you've taken arguing here, you could already have filed usefuland appropriate bugs
<Kano> mjg59: i will add the 2 bugs for the other kernel patches only if you definitely add em in next kernel
<Kano> otherwise it is useless
<mjg59> Kano: If you explain them adequately, it will be done. I can't promise it will happen for the next kernel.
<infinity> Kano: The only person that ultimatum harms is you.
<mjg59> But it will be done before release.
<Kano> infinity: search for the bugs from Kano in your launchpad
<tkamppeter> pitti, so all these PERMITTINGs are complaints? S I should tell on which files they are?
<infinity> Kano: I have bugs open in Debian that are twice as old as Ubuntu.  I don't run around saying "I'll never file another bug until you fix those ones, nyah nyah nyah."
<pitti> tkamppeter: please send me 'dmesg | grep audit'
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128289
<ubotu> Launchpad bug 128289 in linux-source-2.6.22 "VIA southbridge Intel id missing" [Medium,Triaged] 
<Kano> one of the 3 bugs
<mjg59> Kano: A bug where you failed to provide any useful information in the bug
<tkamppeter> pitti, these ones come if s-c-p scans for printers:
<tkamppeter>  PERMITTING
<kylem> so why are you attaching things to bugs instead of following documented policy.
<tkamppeter>  r access to /dev/bus/usb/004/001 (hp(22433) profile /usr/sbin/cupsd active /usr/sbin/cup
<tkamppeter> sd)
<tkamppeter> (same for the other USB devices)
<mjg59> Kano: The useful information was added 10 days ago
<Kano> mjg59: i always have to ask other ppl to write that because i told you already that i do not own the hardware!
<tkamppeter> PERMITTING
<tkamppeter>  r access to /dev/parport0 (hp(22433) profile /usr/sbin/cupsd active /usr/sbin/cupsd)
<Kano> and 10 days... is it added?
<mjg59> Kano: And I keep telling you that we cannot apply patches to the kernel unless we know wht they do
<mjg59> Kano: Half the kernel team is currently on holiday
<broonie> Kano: Often a link to eg, a mailing list thread discussing the patch would help.
<pitti> tkamppeter: ooh, I see, the raw printers and parallel ports
<tkamppeter> Either AppArmor is blocking the device files or the hp CUPS backend.
<pitti> tkamppeter: I only allowed /dev/lp* and dev/usb/lp*
<pitti> tkamppeter: I'll add that
<mathiaz> tkamppeter: if the profile is in complain mode, there shouldn't be any blocked access.
<pitti> tkamppeter: raw access to all USB devices is pretty evil, though
<mathiaz> tkamppeter: and since it's PERMITTING, it means the access has been granted.
<Kano> the 4 other bugs about avm drivers are still NEW. added the same day
<pitti> tkamppeter: does hplip really talk to the raw devices or does it just scan the entire /dev and talks to usblp* or lp*?
<Kano> you add drivers that can not even work without patching
<mjg59> Kano: l-r-m will tend to be handled at a lowerpriority than the core kernel
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/128296
<ubotu> Launchpad bug 128296 in linux-restricted-modules-2.6.22 "avm drivers need pci_register_driver instead of pci_module_init" [Undecided,New] 
<tkamppeter> pitti, HPLIP is accessing bi-directionally for printing, too. The lines with the raw devices I got also while printing.
<tkamppeter> And I got also this one, but do not know by which action:
<pitti> tkamppeter: ok, seems it needs it then
<tkamppeter> PERMITTING
<tkamppeter>  r access to /usr/share/hplip/data/models/models.dat (python(22432) profile null-complain
<tkamppeter> -profile active null-complain-profile)
<Kano> i think abi changes should be known to you ...
<pitti> tkamppeter: that looks weird; can you please mail me your entire dmesg output?
<tkamppeter> and a lot on the various Python files of HPLIP:
<tkamppeter> PERMITTING
<tkamppeter>  r access to /usr/share/hplip/base/service.py (python(22432) profile null-complain-profil
<tkamppeter> e active null-complain-profile)
<pitti> tkamppeter: please, don't spam the channel, just mail it
<xxxxx1> hello pitti
<pitti> hey xxxxx1
<tkamppeter> pitti, the logs are on their way.
<tkamppeter> pitti, I have also found out why your printer is not set up with the SpliX driver.
<pitti> oh?
<tkamppeter> pitti, s-c-p is not isolating the model name correctly from the PPDs. Open s-c-p, "Add Printer" and then look at the models under "Samsung". Your model appears twice, once correctly as "ML-1610" (with only "gdi") and second as "ML-1610, 1.0" (with SpliX).
<pitti> yep
<tkamppeter> hal-cups-utils selects "ML-1610" because this is an exact match of the real model name.
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132454
<ubotu> Launchpad bug 132454 in linux-source-2.6.22 "Add a necessary PCIID for Santa Rosa's PATA controller" [Undecided,New] 
<Kano> high prioity as you can not even boot with new laptops
<ijuz_> with the ide_generic option you can, but that is of course ugly
<Kano> yes it is ugly
<Kano> i tested the patch, the use can use his cdrom just fine
<mjg59> Kano: Is already in git
<Kmos> there is any wiki about HAL debugging, ?
<StevenK> Lutin: devscripts uploaded.
<Riddell> mvo: how can we add kubuntu-restricted-extras to app-install-data?
<Lutin> StevenK: cool, thanks :)
<Kmos> mjg59: so that one can be fix commited ?
<mjg59> Kmos: Wait for confirmation. I'm not sure it's hit the main tree yet.
<Kano> mjg59: whats the current git checkout command
<Kmos> mjg59: i set it to confirmed
<infinity> pitti: Is there a pending MIR or something to get abiword's build-deps in main?
<pitti> not that I know of
<infinity> pitti: It's been happily not building since May...
<infinity> pitti: Needs liblink-grammar4-dev, apparently.
<infinity> Who's in charge of Xubuntu these days?  I assume they should care..
<pitti> infinity: gpocentek?
<infinity> https://wiki.ubuntu.com/MainInclusionReportLinkGrammar
<infinity> Looks like you did approve it, no one ever fixed the overrides.
* infinity goes to do that now.
<Lutin> mvo: pbuilder-satisfydepends-gdebi seems broken, because it passes the --root option to gdebi, which now requires an argument
<Lutin> pitti: gpocentek stepped down from xubuntu. janimo and mr_pouit are the guys who care for it :)
<pitti> I see
<seb128> jwendell: no, I use the Human theme
<infinity> pitti: Fixed.  Sorry to bug you, should have search the wiki first.
<jwendell> seb128, ah, did you see my comment on bug 106124?
<ubotu> Launchpad bug 106124 in gtk2-engines "Clearlooks, tooltips and notifications are gray now instead of yellow" [Low,Fix released]  https://launchpad.net/bugs/106124
<pitti> infinity: np, thanks for fixing it
<infinity> s/search/searched/
<broonie> Apparently someone rewrote it to do some hideous XML stuff with no obvious understandig of xML at some point.
<broonie> ECHAN
<seb128> jwendell: no
<seb128> jwendell: reading now
<seb128> jwendell: open a bug on bugzilla I would say
<pitti> tkamppeter: I updated the profile on people, can you please test again?
<pitti> tkamppeter: copy it, and do 'sudo /etc/init.d/apparmor reload'
<pitti> iwj: can we two kill some MIRs today? dendrobates needs some urgent ones (the pam/ldap stuff)
<infinity> StevenK: You recently had to beat intltool into submission, right?
<infinity> StevenK: Does this look familiar? http://launchpadlibrarian.net/8806474/buildlog_ubuntu-gutsy-lpia.inkscape_0.45.1-1ubuntu3_FAILEDTOBUILD.txt.gz
<dobey> infinity: rerun intltoolize --force --copy
<Lutin> mvo: maybe just replace --root $CHROOT by --root=${CHROOT:-/} would be ok ?
<dobey> autoreconf doesn't rerun intltoolize
<seb128> dobey: is that an intltool bug?
<pitti> tkamppeter_: wb
<dobey> seb128: no. all the INTLTOOL_$GNUTOOL stuff is gone in 0.36, so if you are using the new intltool.m4, and old intltool-foo.in, it breaks
<pitti> tkamppeter_: I updated the profile on people, can you please test again? copy it, and do 'sudo /etc/init.d/apparmor reload'
<dobey> and autoreconf causes the new intltool.m4 to get pulled in i think
<dobey> seb128: it's probably prudent to get autoreconf patched to support re-running intltoolize
<seb128> k
<dobey> if needed
<dobey> brb
<iwj> pitti: Does it need doing before FF ?  I'm very short of time.
<tkamppeter> pitti, I had an interruption here. Did you say anything to me before "tkamppeter_: wb"?
<pitti> tkamppeter: yes, but I said it again
<pitti> iwj: yeah, that's why it is urgent
<pitti> iwj: I'll review some as well
<iwj> Let me look.
<iwj> libpam-ldap, *auth-client* ?
<pitti> iwj: and libpam-mount, and libnss-ldap
<dendrobates> iwj: libnss-ldap , not libpam-mount
<dendrobates> pitti and iwj:  this is my first MIR, so I apologize in advance f they are crap.
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132466
<ubotu> Launchpad bug 132466 in linux-source-2.6.22 "Add T-Sinus 111card to hostap_cs driver to be able to upload firmware" [Undecided,New] 
<Kano> mjg59: is it now enough to confim that the patch works...
<tkamppeter> pitti, I have added some test results to our private chat.
<pitti> tkamppeter: weird, I didn't get anything;
<pitti> tkamppeter: ah, you aren't registered
<iwj> pitti: TBH libnss-ldap and libpam-ldap seem like the main questions here.
<pitti> iwj: yeah, the auth client stuff should be trivial (I didn't look at it yet)
<iwj> They don't have a hugely nice security history and they're put right in the most critical place.
<pitti> iwj: yeah, I know; the question, however, is less about whether or not to put them in main (since it's a feature goal), but rather to check their sanity etc.
<iwj> Err.
<iwj> If the question isn't whether to put them in main then there is no point doing the MIR, surely ?
<iwj> "Executive Override"
<pitti> well, if they are really broken, we wouldn't of course
<iwj> Or do you mean you want to review them for (a) hideously broken and/or (b) easy fixes ?
<tkamppeter> pitti, so I will mail you the full syslog
<pitti> iwj: in that case we would note down the complaints, have the guys fix them, wash/rinse/repeat
<iwj> OK, that makes sense.
<iwj> I think the lib*-ldap are the meat.  Do you want me to take those two ?
<pitti> iwj: oh, if you are comfortable with grabbing both of them?
<iwj> Well, I think they'll be similar.
<pitti> iwj: I'll look at the other stuff then (that should take less time per report)
<iwj> I can't guarantee to spot the next vuln though.
<pitti> iwj: no, I don't think we should expect to get a full audit
<seb128> hum
<seb128> what the heck?
<tkamppeter> pitti, you have mail
<seb128> ah, command-not-found looking weird
<iwj> pitti: OMG   4088 pam_ldap.c
<pitti> tkamppeter: updated again; I think it should do now, since I basically disabled all confinements of hplip (that's not a regression anyway)
<pitti> tkamppeter: that version also fixes the gazillion null-complain-profile noise
<keescook> hiya pitti :)
<pitti> hey keescook! *hug*
* keescook hugs pitti
<pitti> kylem: do you have some time today to discuss the dapper.2 list?
<Hobbsee> heya keescook!
* keescook hugs Hobbsee too!
<Hobbsee> :D
<keescook> :)
<tkamppeter> pitti, there is still the following:
<tkamppeter> REJECTING rw access to /dev/tty (bash(6719) profile /usr/sbin/cupsd active /usr/sbin/cupsd)
<kylem> pitti, yup.
<tkamppeter> but it prints
<pitti> tkamppeter: yeah, I deliberately don't allow that
<pitti> tkamppeter: cool!
<pitti> tkamppeter: thanks a lot; I'll upload that now to get it fixed, and look into cups 1.3 after the discussion with kyle
<tkamppeter> pitti, job has successfully completed.
<pitti> \o/
<tkamppeter> pitti, started system-config-printer and looked for device auto-detection. All devices appear, HPLIP-driven printers. network printers, and my Bluetooth cell phone.
<pitti> tkamppeter: erm, is that cellphone able to print? :-)
<tkamppeter> pitti, no, or simply Samsung does not provide a Linux driver for it (would be nice to have a fax driver).
<tkamppeter> pitti, but at least it asks for the PIN when one sends a job to it. So one can see that the Bluetooth backend works.
<pitti> cool
<pitti> tkamppeter: heh, indeed, a fax driver would be a nice gadget
<psusi> iwj: ping
<tkamppeter> pitti, what did you mean with " thanks a lot; I'll upload that now to get it fixed, and look into cups 1.3 after the discussion with kyle"
<iwj> psusi: Content free ping isn't very interesting.
<pitti> tkamppeter: I don't discuss cups with kyle; just saying that I'll look into cups afterwards
<psusi> iwj: hey... was wondering how dpkg triggers is coming?
<Riddell> calc: see this? https://lists.ubuntu.com/archives/kubuntu-users/2007-August/019536.html
<tkamppeter> Will you add this profile now to the CUPS 1.3.0 package which I have made available to you or should I re-upload that package with the new apparmor profile?
<psusi> iwj: I thought we would have it in gutsy, but it looks like it hasn't made it upstream even yet?
<iwj> I'm working hard on it when I'm not being asked about it :-).  It'll be in for FF but not very well tested.  I'll probably break everyone's stuff :-).
<seb128> pitti: do you run gutsy on you powerpc?
<psusi> FF?
<pitti> seb128: yes, I do
<seb128> pitti: does "gst-inspect-0.10" crash?
<pitti> seb128: except that I downgraded the kernel again since suspend to ram broke between gutsy's -8 and -9
<pitti> seb128: booting
<seb128> pitti: thanks
<psusi> iwj: you are still just working on it privately?  I didn't see it in the dpkg git repo
<iwj> It's all on my local disk, yes.
<iwj> In fact TBH I've been too busy coding to do any playing with git so I'll probably upload to Ubuntu first and mess with git later.
<psusi> ok... definately check out git when you get a chance... it is awesome... I've been tracking the linux kernel develeopment with it... it is incredible to update after linus tags a new -rc1 and see all the thousonds of changes woven into the kernel from all of his dozens of liutenents and submitted by hundreds of contributors
<psusi> most of which have been sitting in other repos for testing for weeks or months, but all are now in the mainline for -rc1
<pitti> seb128: doesn't crash here, but it's already some weeks old; dist-upgrading now
<tkamppeter> pitti, you have put your new profile into the old CUPS 1.2.x now? Will we stay with CUPS 1.2.x in Gutsy?
<pitti> tkamppeter: yes (so that it gets out of my eyes), and no (I'll still update it)
<seb128> pitti: ok, thanks
<tkamppeter> pitti, should I merge 1.3.0 with your 1.2.12-3ubuntu3 now or will you do it?
<pitti> tkamppeter: if you have your package current against ubuntu2, that's fine
<pitti> tkamppeter: ubuntu3 just updates the AA profile, that's trivial
<psusi> iwj: you should be able to use triggers to things like shut down apache once, update several apache related packages, then start it back up at the end right?  rather than restrting it dozens of times?
<pitti> tkamppeter: I'll probably update the Debian trunk first and re-merge the Ubuntu changes
<tkamppeter> pitti, yes, I have now a cupsys 1.3.0-0ubuntu1 with your newest profile now, I only need to upload it to my server.
<pitti> tkamppeter: cool, thanks
<iwj> psusi: Would you mind if we had this conversation after feature freeze ? :-)
<psusi> hehe... sure ;)
<tkamppeter> pitti, I am currently replacing the source files on the server.
<tkamppeter> pitti, files on the server are replaced now.
<tkamppeter> pitti, I have another question: Will CUPS work with other filter-style drivers than HPIJS, like foo2zjs, m2300w, pxljr, ...
<bddebian> Heya
<pitti> tkamppeter: by default those backends have the same privileges as cupsd
<pitti> tkamppeter: so if they need configuration files or special programs to work, they might break
<tkamppeter> pitti, these are not backends, these are executables in /usr/bin, which are called via foomatic-rip.
<tkamppeter> REJECTING
<tkamppeter>  x access to /usr/bin/foo2zjs-wrapper (bash(22239) profile /usr/sbin/cupsd active /usr/sb
<tkamppeter> in/cupsd)
<tkamppeter> pitti, I think this is a big problem, as every driver would need its own entry in the AppArmor profile. Especiallyt for users printers will not work out-of-the-box if they would install a distro-independent driver package from the manufacturer or from OpenPrinting.
<pitti> tkamppeter: we should probably allow execution of /usr/bin/*
<pitti> tkamppeter: with the same privs as cupsd
<pitti> instead of picking particular programs
<tkamppeter> pitti, yes, and this is not dangerous, as only root can write into this directory or modify the files in there.
<iwj> pitti: Well, libpam-ldap consists of about 4kloc of flabby C code which implements complicated logic for pam in terms of libldap.  I haven't found any howlers reading it just now but I'm pretty sure it has more bugs than the ones found so far.
<pitti> tkamppeter: can you please replace "/usr/bin/env ixr," with "/usr/bin/* ixr" and remove the other /usr/bin lines? then /etc/init.d/apparmor reload
<iwj> pitti: What more did you want to know ? :-)
<tkamppeter> pitti, still a problem will be the distro-independent driver packages from OpenPrinting. They install into /opt and add the directory with the executable filters to the system's PATH, via an entry in /etc/profile or in /etc/profile.d/*.
<iwj> I wouldn't want it on the security boundary of any machine I cared about.
<iwj> But then that's true of web browsers too and I have to run those ...
<pitti> iwj: a general impression of "this code is maintained upstream, it has a good chance to actually work" and such, I think
<iwj> I have no reason to think it doesn't work.
<pitti> tkamppeter: yeah, it's no problem to add /bin/*, /usr/local/bin/*, /sbin/* etc., too
<iwj> Upstream is a small company who do appear to be active.
<pitti> tkamppeter: oh, they modify a system configuration file? urgh
<tkamppeter> pitti, and also /usr/lib/cups/driver/* /usr/lib/cups/filter/* /usr/lib/cups/backend/*, as drivers also bring files to be put into these directories.
<pitti> tkamppeter: those are already covered
<tkamppeter> pitti, how do you think one should do distro-independent driver packages? Somehow they need to be connected with the system.
<Kmos> bug 130203
<ubotu> Launchpad bug 130203 in Ubuntu "MoM creates package against wrong tarball when tarballs are different" [Undecided,New]  https://launchpad.net/bugs/130203
<Kmos> what package to fill this bug against ?
<tkamppeter> pitti, after adding /usr/bin/*, /usr/sbin/*, /sbin/* and /bin/* my LaserJet 1020 (foo2zjs) prints.
<iwj> pitti: libnss-ldap is about 17kloc in total of which at least half is actually used by us.  The latest upstream version has a probably hard-to-exploit buffer overflow bug which was reported to Debian in December 2006.
<pitti> tkamppeter: ok, I did that change in svn
<pitti> iwj: they didn't fix that yet? hmm
<iwj> And for which a fix has been in Debian since June 2006.
<iwj> TBH I don't think I properly understand the basis for the yes/no decision.  I don't much like these packages.
<pitti> iwj: in this case the question is more like "what do we need to fix on those packages before we can support them?"
<iwj> What do you do with 10kloc of security authorisation code written by idiots to fix it to make it secure ?
<pitti> iwj: sounds exactly like the thing I'd put on a CD by default and ship worldwide :-P
<iwj> Go for it then :-).
<pitti> *cough*
<iwj> OK, `idiot' is probably overly harsh.
<iwj> It's not absolutely terrible.
<xhaker> whats the subject here?
<iwj> I think the bug rate will be comparable to that from other excessively extensive C code.
<iwj> xhaker: libnss-ldap
<iwj> (and libpam-ldap, earlier)
<pitti> tkamppeter: /opt> allowing cupsd to read everything below /opt/ is no problem; for execution, do those drivers have a certain structure?
<pitti> seb128: latest gst-inspect behaves for me
<tkamppeter> pitti, in general in /opt every supplier can do everything he wants under /opt/<supplier>/, accordint to the FHS there is no required structure.
<pitti> tkamppeter: ok; let's not worry too much about /opt then, I'll whitelist it
<pitti> tkamppeter: do you think that /opt needs write privs, too? or do these drivers generally use /tmp/ and /var/spool/?
<alex-weej> mvo: you there?
<tkamppeter> pitti, write privs are not needed in /opt. They use /var/opt/..., perhaps also /tmp/...
<tkamppeter> And there should also read access for everything under /usr/, as some drivers, like m2300w have some extra files, but these only need to be read by the driver.
<tkamppeter> Opening read access to /usr/ should be no problem, as there is no private data. Only world-readable system files.
<pitti> tkamppeter: read /usr/ is more or less covered (/usr/lib/** and /usr/share/**)
<pitti> tkamppeter: people.u.c. profile updated
<pitti> tkamppeter: so that should work with those three drivers you mentioned above
<tkamppeter> /usr/lib64, /usr/X11R6/?
<mvo> alex-weej: yes
<alex-weej> mvo: when you created the ubuntu theme for notification-daemon, was it a copy and paste job from the standard theme?
<alex-weej> just there is a fair bit of delta now :/
<pitti> tkamppeter: /usr/X11R6 is deprecated
<mvo> alex-weej: it was
<tkamppeter> pitti, foo2zjs is working with your new profile.
<pitti> tkamppeter: and the cupsys package doesn't use /usr/lib64
<tkamppeter> pitti, what happens if a driver uses a shared library and we are on a 64-bit box?
<alex-weej> mvo: PM
<dendrobates> pitti iwj: Is it your opinion that libpam-ldap is not of sufficient quality to be supportable?
<pitti> tkamppeter: shared libs are not the problem, that's already allowed by #include <abstractions/base>
<tkamppeter> pitti, is this also valid for libs linked at run-time, via libdl or so?
<pitti> tkamppeter: yes
<tkamppeter> pitti, then /usr/lib64 is really not needed.
<pitti> tkamppeter: ok, I committed the changes to the svn
<tkamppeter> pitti, do the AppArmor profile entries for cups-pdf fix https://blueprints.launchpad.net/ubuntu/+spec/pdf-printing-cups-as-default
<pitti> tkamppeter: I made the profile work with cups-pdf, yes
<pitti> tkamppeter: (and did a small fix to cups-pdf itself for that)
<tkamppeter> I mean part 3 there. part 2 and part 1 are easy to fix then.
<tkamppeter> pitti, does cups-pdf already auto-create the PDF queue (part 2)?
<pitti> tkamppeter: part 3> it's not too bad ATM, I had a look at it when fixing the package
<pitti> tkamppeter: part 2 is not done, you have to manually add the queue
<tkamppeter> pitti, I mean with fixing part 3 also if an AppArmor protection assures the security, so that privilege-dropping can be dropped.
<pitti> tkamppeter: not sure what you mean
<pitti> tkamppeter: cups-pdf drops root privs to user privs for actually writing the file
<tkamppeter> pitti, part 2 we can do easily, by simply adding an "lpadmin ..." line to the post-install script.
<pitti> that's good, that's robust, it's upstream, I see no reason to change that
<tkamppeter> pitti, it does already? Even better, then part 3 is really fixed.
<pitti> tkamppeter: it might be possible that it could be tightened, but it's not too bad ATM
<tkamppeter> For fixing part 2 see my comment in bug 82674
<ubotu> Launchpad bug 82674 in cups-pdf "add/remove the PDF printer in CUPS at installation/removal time" [Medium,Confirmed]  https://launchpad.net/bugs/82674
<iwj> pitti: I've written two report conclusions into those two MIRs.  I think the decision now is political so if you don't mind I would like to bow out.
<iwj> You should ask The Management whether there is, as I say, a "compelling reason" for inclusion.
<pitti> iwj: I just read it, thanks for you analysis!
<iwj> You're welcome.
<calc> Riddell: as best as I can tell Retroshare has nothing to do with openoffice.org
<Riddell> I'll assume he's talking nonsense and ignore it then :)
<calc> Riddell: perhaps the person meant open office as a general term
<pitti> keescook: btw, your SSP main rebuilds are complete?
<keescook> pitti: they're not finished, but the bulk of things that looked interested are done: http://people.ubuntu.com/~kees/needs-stackprotector-build.txt
<keescook> I'll do a few more; why do you ask?
<pitti> keescook: oh, it just came into my mind, since I'll start the universe rebuilds for Maintainer: now
* keescook nods
<seb128> pitti: thanks, that depends of the powerpc model, I've found the corresponding Debian bug
<pitti> tkamppeter: debian/patches/68_edit-config.dpatch> funny, I was just thinking of actually updating this patch to our configuration changes; you said that it was fixed upstream, how so?
<pitti> tkamppeter: doesn't upstream use per-language templates for the config file any more?
<pitti> tkamppeter: in ubuntu-disable-browsing.dpatch you changed "BrowseAllow @LOCAL" to "BrowseAllow all"; IMHO @LOCAL is a better default for printing
<pitti> tkamppeter: oh, wait, my 'patch of patch' reading skills are weak; upstream changed that default, as it seems
<pitti> tkamppeter: 68_edit-config.dpatch> ah, I see how that works now. cool!
<pitti> there goes our biggest patch
<bryce> Nafallo: it was pointed out that the CtrlAltBkspace spec still needs a final approval first
<pitti> tkamppeter: 1.3 works great here
<bryce> Nafallo: I've put in a request for an official decision on that.  Otherwise everything else looked ok.  Hoping to have it uploaded some time later today.
<iwj> dpkg is no longer built with -Werror.
<Nafallo> bryce: ouch :-/. what about the xserver-xorg-video-vesa depends in the same place that deps displayconfig-gtk? :-)
<Nafallo> bryce: should make most sense IMO :-)
<bryce> it was recommended not to have low level components like xorg or gdm depend on higher level gnome apps like displayconfig-gtk, so that change won't be made
<Kopfgeldjaeger> anyone reported rt73 chipset (rt2x00 module in gutsy) working??
<pitti> bryce: why do you think it is bad to just seed displayconfig-gtk?
<bryce> oh, I don't think it's bad - in fact I just now put in a request to evand and cjwatson to do that for the desktop seed
<bryce> pitti: I was just not clear on what to do - you gave me two options and I just picked the wrong one.  ;-)
<bryce> Nafallo: regarding having a depends on -vesa, I'm not sure on that one.  technically bulletproof-x should allow use of vga and/or the framebuffer, I just haven't been able to get it working with those configs yet
<Nafallo> bryce: :-)
<pitti> bryce: oh, I can seed it
<bryce> pitti, ah that'd be great
<Nafallo> bryce: maybe have displayconfig-gtk dep on those drivers that work as fallback might be the best for now then. even if a bit ugly.
<pitti> bryce: done
<bryce> no, because displayconfig-gtk's primary use case is not bulletproof-x but rather the screen settings configuration, which by design is driver-independent
<pitti> bryce: now we need to rebuild ubuntu-meta, so that ubuntu-desktop actually depends on it; how urgent is this?
<Nafallo> bryce: right... that was my though yesterday as well :-P
<pitti> bryce: (it'll be done next Monday for the next tribe anyway)
<bryce> pitti, not urgent
<Nafallo> pitti: next tribe :-)
<bryce> pitti, if it can be done by tribe-5 that'd be fine
<Nafallo> bryce: bulletproof-x metapackage? ;-)
<pitti> bryce: it will, it's part of the standard procedure
* Nafallo hides
<Kopfgeldjaeger> pitti: do you know the state of the rt2xxxx chipsets in gutsy? or do you know where to find information about?
<pitti> Kopfgeldjaeger: no, I don't have such a thing
<Nafallo> Kopfgeldjaeger: works better than in previous versions.
<Kopfgeldjaeger> Nafallo: with rt2x00 or the "legacy" drivers?
<Nafallo> Kopfgeldjaeger: they are working hard to get into the vanillakernel now from what I've seen.
<Nafallo> Kopfgeldjaeger: rt2x00
<Kopfgeldjaeger> rt2x00 does support network-manager, doesnt it?
<Nafallo> Kopfgeldjaeger: did when I tried. that has improved a lot in gutsy I must say.
<Kopfgeldjaeger> Nafallo: im going to buy a usb dongle with rt73 (rt2571w) chipset i think
<Nafallo> Kopfgeldjaeger: nice. my experience was with rt61pci
<Nafallo> Kopfgeldjaeger: rt61 on a pcicard even :-)
<Kopfgeldjaeger> Nafallo: interesting. what would you say: will it work ootb (i CAN compile, but of course it would be cool...) ?
<Nafallo> Kopfgeldjaeger: I can't say. but I would be surprised if it didn't.
<Nafallo> Kopfgeldjaeger: I know the drivers are in linux-ubuntu-modules
<Nafallo> or whatsitsname
<Kopfgeldjaeger> Nafallo: sound good.
<bryce> heya glatzor
<glatzor> servus bryce
<glatzor> bryce: it seems that we are in main now :9
<bryce> glatzor: good news - displayconfig-gtk is now in main, and has been added to the desktop seed so now will be installed by default
<glatzor> bryce: urgs
<glatzor> bryce: could you please send me your patch as email?
<bryce> sure
<glatzor> launchpad included some html statements
<bryce> ok
<Nafallo> bryce: bzr ;-)
<bryce> I used bzr to make the patch ;-)
<Nafallo> glatzor: bzr ;-)
<ugi> hi all
<glatzor> bryce: the infimporter should now work too.
<bryce> excellent, yes I saw that code when I was reviewing
<glatzor> the module is now shipped in guidance-backends
<glatzor> but you can also call it from the command line to add monitors to our database
<ion_> Hm. Would it be feasible to have the physical size of screens in a monitor database? That would be for monitors that dont report the size or report a wrong size. If X knows the correct size (from DDC or the DisplaySize setting), it calculates the correct DPI value whatever the resolution is.
<pitti> tkamppeter: still here?
<glatzor> ion_: right.
<bddebian> Go pitti, go keescook... :-)
<psusi> ion_: sounds reasonable... I know I have been pissed at windows for years because it simply assumes all monitors have a dpi of 96 no matter what their size or resolution
<bryce> glatzor: cool, I'll plan on learning to use that
<bryce> glatzor: for bulletproof-x I've added in some code for blacklisting monitors based on their edid info
<ion_> psusi: Yeah. Its really nice to have about the same font size on all monitors when the font setting is the same.
<bryce> I'm getting that via get-edid, however that's not installed by default, so I'm pondering if there's something better to use
<psusi> ion_: I just love how a 12 point font is NEVER actually shown as 12 point in windows
<bryce> glatzor: does dcg have this capability already, that I could just reuse?
<ion_> *Especially* since the monitor DPIs are going to get higher and higher year by year, and some day were going to have freely scalable UIs. Then knowing the DPI value is an absolute necessity.
<psusi> yea
<psusi> dpi keeps getting higher so windows just renders the fonts smaller and smaller making it harder to read instead of easier, as it should be
<psusi> so most people end up just running in a lower resolution so they can still read the fonts
<glatzor> bryce: no, guidance just calls the scripts
<glatzor> /usr/sbin/ddcprobe
<bryce> hmm, ok.  maybe I'll get that added to the seeds too.  presently the blacklist is empty so it's not important yet
<Skiessi> :/ It's not good that aMSN or Pidgin doesn't let me add people whose email address doesn't end with hotmail.com, msn.com etc.
<infinity> Err, of course pidgin does...
<Skiessi> o_o Are you sure?
<infinity> Just give the full email address for the contact...
<Skiessi> nope
<wasabi> pidgin always has for me
<wasabi> i have a dozen people on msn like that
<infinity> Works For Me.
<wasabi> NOTABUG
<infinity> I don't use a Microsoft address.
<infinity> And most of my friends don't either.
<xhaker> true
<xhaker> you can add whatever you like
<jdstrand> cjwatson: I was playing with tasksel to try to add an openssh task, and when I run the updated tasksel on feisty, I get aptitude failed (100)
<jdstrand> cjwatson: the tasksel file is at http://paste.ubuntu-nl.org/33735/
<jdstrand> cjwatson: is there a known problem on feisty?
<jdstrand> cjwatson: just tried with gutsy's version.  same thing.  :(
<superm1> jdstrand, I believe cjwatson is on vacation atm.
<jdstrand> hmm.. shows he's online.  oh well
<superm1> online but idle for many hrs.
<mathiaz> jdstrand: cjwatson is on vacation this week.
<jdstrand> thanks
<infinity> jdstrand: Lots of us are always online, doesn't mean much.
<jdstrand> yea, I wasn't suggesting he was actually online.  :)  Just saw he wasn't away and went for it.
<keescook> Keybuk: yay, sometimes, if I boot really quickly mdadm segfaults in getinfo_super0 (sb is NULL, it seems) wheee race conditions.
<Keybuk> heh
<mathiaz> infinity, seb128: I've added a debdiff to bug 128548
<ubotu> Launchpad bug 128548 in samba "Enable net usershare?" [Wishlist,In progress]  https://launchpad.net/bugs/128548
<keescook> and I've now baffled the linux timer experts with my getnstimeofday() hang.  I think I need different hardware.  ;)
<mathiaz> infinity, seb128: it should enable net usershare for the samba package.
<Zero_> HI, somebody can put the bug 128165 as milestone in tribe-6 ?
<ubotu> Launchpad bug 128165 in netcfg "Installation of Network put a wrong DNS, crashing the Installation" [Undecided,Confirmed]  https://launchpad.net/bugs/128165
<sabdfl> asac: hi... dropping the scan_ssid line does not reproduce the problem
<sabdfl> when using NM, i can connect to wpa_supplicant using wpa_cli and if i ask for status it is scanning
<asac> sabdfl: so you say the previous package did work for you, right? let me build a package for you ... amd64 or i386?
<sabdfl> asac: no, i don't know if it ever worked, i just arrived in SA last week
<sabdfl> and it didn't work on two networks out of three
<sabdfl> i can manually connect to both networks using wpa_supplicant with the config I pasted up for you
<sabdfl> then sudo dhclient eth1
<sabdfl> as long as I've killed NM and wpa previously of course
<sladen> sabdfl: what happens if you do  watch -n0 iwconfig eth1   whilst letting NM attempt to connect
<sladen> sabdfl: here I've met a couple of networks were the network successful associates, even gets an IP, and then 5seconds later NM "gives up" and yanks the interface down
<sladen> ...everything /has/ worked (briefly) but NM hasn't realised it
<ion_> siretart: I think gxine may need a rebuild, since it links to libmozjs.so, which doesnt exist in libmozjs0d.
<sabdfl> sladen: that's interesting, i'll try as soon as the tech board meeting is done
<bdmurray> bryce: is xvmc supposed to be working with -intel now?
<rgl> hello.
<rgl> what version of gnome will gutsy have?
<bryce> bdmurray: I expect so.  I've seen some xvmc bug reports passing through but haven't had a close eye on them.  Is something broken?
<pygi> rgl, 2.20, but #ubuntu pls ;)
<rgl> pygi, how is that possible if gnome 2.20 is scheduled for sept 12?
<pygi> rgl, easy ... release is in october :)
<rgl> pygi, oh you are right.  gag. for some reason I though gutsy was going to be released in this month *G*
<bdmurray> bryce: it doesn't work for me for whatever that is worth. ;)
<bryce> you using it with mythtv, or...?
<bdmurray> bryce: on my laptop with hd video just to see
<bryce> hmm
<mvo> if anyone is using compiz, I would like to see feedback on https://wiki.ubuntu.com/CompizTeam "Status of Xv video"
* ion_ takes a look
<ion_> mvo: Works with nvidia-glx 1:1.0.9631+2.6.22.2-9.7
<mvo> ion_: thanks!
<mvo> ion_: wiki updated
<ion_> mvo: I have to play video in fullscreen mode and use the dont redirect fullscreen windows setting, though. Video played through compiz is absolutely too slow on this hardware (which is quite old).
<mvo> ion_: oh, that is interessing. what card do you use?
<ion_> mvo: Ive been meaning to report a bug about it, btw. The redirect setting doesnt always work. I have yet to do some testing, but seems like it stops working after a SDL program has been in fullscreen mode, and restarting compiz doesnt seem to help. Restarting X is required.
<mvo> ion_: oh, that is interessting. what card is that?
<ion_> nVidia Corporation NV28 [GeForce4 Ti 4800 SE] , Pentium III 500MHz
<mvo> ion_: where do you set the setting? in the nvidia-control panel thing?
<ion_> ccsm
<ion_> CCSM  General Options
<ion_> The second to last item in the General tab.
<mvo> ion_: ok, I think I can do some testing on a more recent 6600 tomorrow
<geser> mvo: do you know what happened to the recent xserver-xorg-video-ati for amd64? it build but didn't hit the archive yet
<ion_> mvo: Ive been hoping that the compiz video plugin makes the video playback fast enough so that i dont need it. Hopefully some player implements support for it soon. :-)
<mvo> geser: I think some mirrors (e.g. de.archive.u.c) are outdated
<geser> mvo: even p.u.c still shows the old version (and I use archive.u.c)
<ion_> mvo: Im quite sure the slowness isnt because of the GPU, but because of the processor, btw.
<mvo> geser: I got the new version today (well, one new version)
<mvo> ion_: I see, p3-500 is really no longer top-of-the-line
<ScottK> seb128: Riddell suggested I ask you about getting Bug #132543 processed.  It's got a significant bug fixed I'd like to get in before UVF if possible.
<ubotu> Launchpad bug 132543 in pypolicyd-spf "Please sync pypolicyd-spf 0.4.1-1 from Debian Unstable (Main)" [Medium,Confirmed]  https://launchpad.net/bugs/132543
<seb128> ScottK: I'm processing syncs request at the moment, will be synced
<ScottK> seb128: Great.  Thanks.
<geser> mvo: I see it now too, I expected it on the archive sooner as it was uploaded 3 days ago
<mvo> geser: indeed
<ion_> mvo: Xv-via-compiz uses a *lot* more CPU power than plain Xv. The compiz video plugin should yield performance enhancements to compiz-wrapped Xv. I just hope theyre enough. :-)
<mvo> ion_: compiz-video plugin needs patches for the application that uses Xv unfortunately
<xhaker> mvo, will they be carried out?
<ion_> mvo: Yes.
<mvo> xhaker: its not easy, I hope someone will find time to patch gstreamer, currenly there is only a mplayer patch
<mvo> and that will not work on embedded mplayer (i.e. mozilla plugin for example)
<ion_> Actually, gstreamer shouldnt be patched, but a new output plugin should be created.
<mvo> even better
<xhaker> mvo, i had some luck modifying the videosink to gstreamerGL
<ion_> Also i dont like the fact that the mplayer patch modifies the Xv plugin. A mplayer should also get a separate output driver for compizvideo.
<mvo> indeed, but I think david just didn't want to spend too much time on it, it seems to be more of a proof-of-concept
<ion_> It does allow it to fall back from compizvideo to Xv *while a video is playing*, but the cost is high: maintaining and enhancing the functionality becomes more difficult and it becomes next to impossible to implement the entire video pipeline differently when thats needed. For instance, where Xv only allows one to render subtitle and OSD overlays to the video itself (their resolution is poor if the video resolution is poor; they cant be shown outside ...
<ion_> ... the video image), the compizvideo plugin should render the overlays to separate composited layers at the display devices resolution.
<vdepizzol> Hello. There is a bug/blueprint anywhere informing that ubuntu should come with gnome-backgrounds package installed?
<dobey> check launchapd
<Riddell> tkamppeter: awake?  do the files in hplip-firmware run on the local CPU or on the printer?
<Riddell> tkamppeter: also do you know what licence they are under?
#ubuntu-devel 2007-08-15
* Starting logfile irclogs/ubuntu-devel.log
<fabbione> morning
<bderrly> evening
<calc> grr wake up hobbsee
<calc> rather come back you were here 1hr ago
<ajmitch> heh
<calc> she has been marking bugs as duplicates that aren't actually due to a misunderstanding of the bug
<calc> hopefully she's the only one who has been doing it so that she has a list of them to fix quickly
<calc> apparently marking anything that was broken due to new glib/gtk as a duplicate of the openoffice bug
<calc> of course i didn't even know what the cause was until the past day or so
<calc> so its not her fault
<TheMuso> calc: She does idle on here as LongPointyStick as well.
<DShepherd> hehe.. nice nick
<calc> TheMuso: oh ok
<calc> LongPointyStick: hey sarah?
<StevenK> Her other client is mainly for logging.
<StevenK> calc: So, what is the cause?
<calc> StevenK: oh ok
<calc> StevenK: improper (or non-existent) initialization of glib/gdk/gtk before calling a function
<calc> StevenK: in openoffice case there was a call to gdk_screen without initialization
<StevenK> Neat.
<StevenK> Are you fixing it with a patch, or is upstream?
<calc> StevenK: a guy at redhat has a fix, but i'm not sure if he considers it good enough for general use yet, i sent him an email letting him know it works for ubuntu (its not even really needed on fedora) and to see if he wants to commit it upstream
<calc> i should know something in probably 12hr or so
<thully> i'm curious if anyone here knows about getting in touch with Ubuntu developers.  I've had many issues (mostly laptop-related, but some having to do w/the general desktop) and I haven't been able to get good developer response...
<calc> thully: i'll let you know a secret... you are in the right channel
<thully> The thing is - I have filed bugs, and e-mailed devs who have commented on bugs, and I feel like I might as well send my info to /dev/null...
<calc> thully: i'm sorry to hear that, people try to get to the reports as quickly as possible but sometimes things get dropped :(
<calc> thully: what particular issue?
<thully> a few
<calc> thully: some developers have many hundreds of bugs to take care of
<calc> thully: for example anything involving openoffice is for me, so just ping me and i'll try to look at it
<thully> The thing is - I've also been using Debian (I'm actually on Etch now), and I get their bug system fine
<thully> You just find the maintainer/team, and they usually answer...
<thully> calc: unfortunately none of my issues involve OpenOffice
<calc> thully: ok :)
<tonyyarusso> Is there a 6.06.2 in the works?  I just saw a debian-installer note in dapper-changes.
<calc> tonyyarusso: yes eventually
<calc> tonyyarusso: i'm not sure if there is a projected release date yet
<tonyyarusso> That upload would seem to suggest it's soon, in my head at least.
<thully> Most of my issues have to deal with laptop stuff - suspend to RAM, brightness controls, synaptics touchpad, ACPI C-states, and so on...
<calc> https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
<calc> thully: ah ok you might ask in #ubuntu-kernel if you don't hear anything back, sounds like all of that is probably kernel related
<thully> not necessarily synaptics, though - that's an X.org driver...
<calc> thully: ah yea
<calc> tonyyarusso: apparently the existence of the release isn't public yet, or at least not on wiki.ubuntu.com yet
<calc> tonyyarusso: but yea what you see in the upload is correct there will be one
<tonyyarusso> calc: interesting
<calc> and i think 8.04 will be the next LTS
<thully> One thing that has me WAY confused is "triaging".  In Debian (and almost any other project) , you simply report the bug, give enough info, and people look at it.  What is the deal with the triage process?
<bderrly> thully, have you ever been to the hospital emergency room? it is the same idea: a nurse will categorize the incoming patients in order of importance
<thully> who does this in Ubuntu, anyway?  I've generally had an experience where if I report a bug, it just sits on "new" for months at a time, no matter what information I attach to it...
<johanbr> Often done by members of the ubuntu bug squad, I believe.
<thully> is it possible to do this myself?  I've been reporting bugs in software for years, so I generally know what I'm doing...
<RAOF> thully: You need to be in the ubuntu-qa team to have priority-changing privileges, but you can do all the rest.
<thully> sorry, my connection was just reset by that darned Peer :)
<StevenK> RAOF: http://www.worldofwarcraft.com/patchnotes/test-realm-patchnotes.html
<StevenK> RAOF: Note the top item under General.
<RAOF> StevenK: Oh, hell yes!
<StevenK> RAOF: So, now you just need to wait for patch 2.2.0 to hit.
<RAOF> Wooooooot!
* RAOF runs around the room
<StevenK> ... on fire
<thully> OK - what I'm wondering is- how does a Bug go from "Confirmed" to "Triaged"?  I've gone through the triage steps and confirmed some of my bugs in the past, but they don't get marked "Triaged"...
<lifeless> thully: #ubuntu-bugs is the right channel for that question, the bug triage team hang out there
<LongPointyStick> greetings
<ajmitch> hello Hobbsee
<Hobbsee> calc: ah, thanks.  i'd suspected the same myself.
<StevenK> Morning pitti
<pitti> Good morning
<ajmitch> morning pitti
* Hobbsee hugs pitti.  morning pitti!
* pitti hugs Hobbsee and ajmitch back
<Hobbsee> :)
* ajmitch departs work & considers dinner
<Hobbsee> pitti: do you want to answer a licencing question, or send it to u-a@l.u.c?
<pitti> Hobbsee: I'd prefer u-a@, I'm no licensing expert
<pygi> pitti, available for a little review?
<Hobbsee> pitti: cool, ok
<pitti> pygi: review of what?
<pygi> pitti, libmtp
<pygi> https://bugs.launchpad.net/ubuntu/+source/libmtp/+bug/132554
<ubotu> Launchpad bug 132554 in libmtp "[needs review]  libmtp 0.2.1 [needs upload] " [Undecided,New] 
<pitti> pygi: can you please add an URL to the orig.tar.gz?
<pygi> pitti, will do so now
<Mithrandir> Hobbsee: what's the question?
<Hobbsee> Mithrandir: in #ubuntu-motu
<pygi> pitti, done!
<pitti> pygi: erk, ABI bump
<pygi> pitti, yup, I know
<pitti> pygi: there are 4 reverse dependencies which need to be rebuilt and tested against this
<pygi> pitti, but brings support for new hardware and brings no problems
<pygi> pitti, been there, done that
<pitti> well, 3 (mtp-tools is in libmtp)
<pygi> from the bug report: All rdepends build properly against it. :)
<pitti> pygi: debdiff looks good to me
<pygi> good sign :)
* StevenK waits for sparc to catch up.
<pitti> pygi: uploaded
<pygi> pitti, thanks :)
<pitti> np
<tonyyarusso> cjwatson: I sent you a message a while back concerning Keyspan driver.  Was wondering a) if you received it, b) if anything's happened on that front
<ArneGoetje> tonyyarusso: cjwatson is on vacation this week.
<tonyyarusso> cjwatson: I have http://www.keyspan.com/products/usb/USA19HS/, which has firmware and drivers included in the vanilla 2.6 kernel tree, but which have not been included in Debian/Ubuntu due to licensing problems, as explained on http://www.keyspan.com/downloads-files/developer/linux/.  I was wondering if it could be evaluated for inclusion in linux-restricted, per the advice of someone else.
<tonyyarusso> ArneGoetje: ah, hrm.  e-mail to -devel better you think?
<ArneGoetje> tonyyarusso: probably
<\sh> morning all...
<\sh> does anyone has a clue how the we determine if a graphics card is able to have "Composite" extension enabled?
<\sh> s/the//
<pitti> \sh: mvo can tell you stories about it
<pitti> \sh: look at /usr/bin/compiz, that does exactly that
<mjg59> Composite is supported on all cards
<mjg59> But I don't think that's what you're asking
<pitti> \sh: yeah, for s/cards/driver/
<pitti> ideally it would also blacklist cards, though
<pitti> some are just too old and slow to sensibly support it
<pitti> (with our drivers anyway)
<RAOF> pitti: We do
<RAOF> Oh, sorry.  EPARSE.
<\sh> pitti, mjg59 : the problem I had was with an ati radeon 9600 card (desktop) (128MB ram) and with the oss ati/radeon driver
<pitti> \sh: same here; compiz works OOTB on my radeon 9200, but the ati driver is way too slow
<\sh> the little ati radeon m22 (r300 card) works on my laptop nicely with compiz on gutsy, but the desktop card doesn't...desktop effects aren't working
<RAOF> Really?  I think that might be a Ubuntu-specific problem then.  People happily run compiz on 9200s
<pitti> RAOF: well, as I said it works, but some operations like resizing windows are painfully slow
<RAOF> Ah, but not in general?
<\sh> could it be, that this is an dist-upgrade issue from feisty to gutsy? I had some troubles with the latest updates from feisty (oofice and ttf-opensymbol package) and after upgrading to gutsy the same problems...
<pitti> RAOF: in general it's just a bit sluggish
<RAOF> People in #compiz-fusion are probably not quite as performance-sensitive as you :)
<pitti> RAOF: I guess you could get used to the speed after a while, but I find it annoying after a while
<\sh> I'll do a clean install with gutsy media this evening ... let's see
<pitti> RAOF: it's just a poor old G4 800 MHz, that might contribute to the problem :)
<RAOF> :)
* TheMuso should try gutsy/compiz on his G4 1.42 mini soonish. That has a 9200 with 32MB of RAM.
<thully> devs - where would be the best place to discuss a few laptop issues I've been having as of late?  I've reported them (or commented on them) and they've for the most part sat in launchpad limbo...
<thully> A few of the issues include 122682, 37234 (granted, more of a feature request - but quite a significant one), and 128653
<thully> I've also got 124642, but I just reopened that one - apparently my MacBook likes to make funky noises in some ACPI C-states, but only with certain kernels
<thully> I guess I dunno what to do from here - I want to help on these issues, and the whole laptop support area in general, but I haven't been able to find much (I saw a laptop team, but it looked like it mostly consisted of mjg59 and a few people who posted their specs/results).
<mdke> thully: you could try the laptop-testing mailing list.
<thully> That's as dead as a doornail - check the archives
<mdke> seems slightly less dead than laptop-devel
<mdke> thully: maybe give it a try, if you don't get anywhere you could try the main development lists
<thully> OK
<lifeless> where do test-install-reports go these days ?
<pitti> lifeless: https://iso.qa.stgraber.org/
<lifeless> shame its not a ubuntu.com name
<lifeless> hmm
<pitti> yeah, but it hopefully will be in the future
<lifeless> I have a 36 step-to-install document
<lifeless> its not clear what issues are bugs, and what are not.
<lifeless> that web site doesn't give me any hint as to what I should do in this situation.
* lifeless punts to ubuntu-devel
<pitti> we usually file bugs and link them in the install reports
<lifeless> right, but where do I write up my report ?
<pitti> lifeless: if you click on a particular ISO, you'll see the tests you can do with it, and if you click there you can submit your's
<lifeless> its hellishly slow
<lifeless> slower than launchpad
<lifeless> ok, none of the tests match what I did
<pitti> weird, it's not any slower than any other webpage (faster than LP in any case for me)
<pitti> might be my geographically close location :)
<lifeless> its https and lots of separate requests
<pitti> I guess that thing is in .de
<lifeless> this is known as 'bad'
<Hobbsee> it's faster than LP here
<Hobbsee> which is weird
<pitti> heh, only 6 hops here
<StevenK> pitti: libvips10c2a, libvips10-dev, libcgal1, hylafax-doc and hat-ghc6 can be NBS'd out at your leisure.
<pitti> yay
<lifeless> pitti: my mail has hit ubuntu-devel
<lifeless> (if you are interested)
<pitti> I am
<stgraber> lifeless: about the "I think the ISO testing web pages
<stgraber> should include some guidance for adhoc tests"
<stgraber> (crappy copy/paste ...)
<stgraber> It's possible to add a link to a wikipage for each tests, but we need people to do so :)
<pitti> StevenK: hm, ppu-fortran needs a rebuild on i386 and ppc for getting rid of libmpfr1
<pitti> StevenK: killed, merci
<stgraber> (the Ubuntu Server have a link to what to a test description (if you click on the icon next to the test name))
<stgraber> pitti: It's hosted in France with some nice peerings for Germany (and Switzerland by the same)
<stgraber> (and yes it'd need more RAM :), 256MB being a bit short but that's what you have when you pay 20 for a server :))
<lifeless> stgraber: well, I'm not saying that there need to be links to each test
<pitti> stgraber: I also pay 20 for my colo, but I could just buy another gig and have them build it in at no additional monthly cost (just the price for the RAM bar, of course)
<lifeless> stgraber: I'm saying that when someone does a test which is not covered, what should they do ?
<lifeless> I installed a crypted, lvm'd, desktop.
<lifeless> thats not even a minor variation, its a massive variation, because of the impact on partitionining, on whether the right packages *can* be there, of using universe...
<Lutin> pitti: can you give-back mgcv and kernsmooth please ?
<lifeless> anyone know if gconf database is arch specific?
<mvo> mjg59: are you around? I'm writting up the discussion of the techboard meeting now and I wonder if the performance problem for 3d apps in compiz affects all video drivers or only nvidia. I can not see it here on my ati system (in a quick and unscientific test)
<pitti> Lutin: done
<mvo> pitti: hm, looks like restricted-manager is currently unable to enable the nvidia driver at all :/ did you got a bugreport about this already?
<pitti> mvo: hm, no, works quite fine for me; what does it do?
<mvo> pitti: if I use it with the apperance capplet (--check-composited) it will give me a message that I need to enable the driver, then I click ok and nothing appears to happen
<mvo> pitti: xorg.conf is not rewriten at least
<mvo> I think the download worked earlier
<mvo> pitti: this is a fresh tribe-4 install
<pitti> mvo: oh, can you please try with latest r-m?
<mvo> pitti: ok, I will do that in a bit (machine has no network yet)
<pitti> mvo: thanks; if it's still broken, please get back to me
<mvo> ok, thanks
<pitti> mvo: it indeed was broken for very new or very old cards (nvidia-glx-{legacy,new})
<mvo> mine is neither :)
<mvo> 6600
<\sh> mvo, I heard you are the compiz master...upgraded feisty to gutsy, having a ati radeon 9600 card (agp desktop) running xorg with ati oss driver, but enable desktop tells me, that it's not working
<\sh> mvo, could it be, that this is an upgrade issue, or is ati radeon 9600 not supported from xorg-ati oss drivers?
<mvo> \sh: can you please put the output of ".xsession-errors" to a pastebin? after you tried to enable it?
<\sh> mvo, can do it this evening :) because it's my home machine :)
<\sh> mvo, but sure will do
<mvo> \sh: ok, please do that then :)
<mvo> \sh: it has some verbose output that will help me diagnose the issue
<mvo> everything else is guesswork
<\sh> mvo, better to install gutsy from scratch or just leave my installation like it is (upgraded gutsy from feisty)
<mvo> \sh: upgraded should be fine
* mvo always upgrades
<\sh> mvo, cool...you'll get the output around 20 :)
<pitti> infinity: btw, what's the difference between dpkg --print-{,installation-}architecture?
<pitti> infinity: I changed that in apport now as per your recommendation a few days ago
<pitti> infinity: and I made it DTRT on lpia
<Riddell> keescook: are you doing poppler packaging these days?  0.5.91 is out
<pitti> Riddell: desktop team usually, but I can look into it, too
<pitti> Riddell: maybe it fixes PDF printing again :)
<pitti> Riddell: hm, http://poppler.freedesktop.org/ doesn't mention it
<pitti> Riddell: ah, download works, though :)
<asac> hmmm any idea where i can get a plain ubuntu.{png,xpm} ?
<Riddell> :)
<Riddell> asac: canonical.com has an artwork page
<asac> i knew i was missing the obvious ;) ... thanks!
<asac> Riddell: wiki?
<Riddell> that too, but the public website had one made recently
<asac> hmmm
<Riddell> http://www.canonical.com/logos
<asac> where is that linked from?
<Riddell> irc logs now :)
<asac> hmmm i want just the image ... not the text
<asac> ... maybe i have to cut it then
<Riddell> launchpad.net/ubuntu
<Riddell> or, crop
<asac> yeah :)
<lifeless> is there something to configure which compiz plugins are active?
<Fujitsu> lifeless: compizconfig-settings-manager or something similarly named.
<mvo> lifeless: what Fujitsu says
<lifeless> what package is it in? (its notinstalled )
<mvo> lifeless: what HW do you have that made the system freeze when enabling effects? is that a i945?
<Fujitsu> lifeless: compizconfig-settings-manager is the package, AFAIK.
<mvo> lifeless: compizconfig-settings-manager is the pakcagename (universe)
<lifeless> 00:02.0 VGA compatible controller [0300] : Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller [8086:27a2]  (rev 03)
<mvo> with the "intel" driver I assume?
<lifeless> yes
<mvo> lifeless: I wonder if 32bit/64bit makes a difference here
<ajmitch> Fujitsu: an impressive package, doesn't even start for me
<Fujitsu> ajmitch: WFM
<ajmitch> python ImportError
<ajmitch> afaik I have the latest compiz crack installed
<geser> must be an new error as it worked for me yesterday
<ajmitch> or just a broken package on my system
<tkamppeter> hi pitti
<pitti> hey tkamppeter
<pitti> tkamppeter: currently discussing the firmware issue
<tkamppeter> pitti, Tim Waugh has modified the add-printer wizard so that it asks for the queue name only after printer and model selection, in time before the UVF. I have packaged it, see your mail.
<pitti> tkamppeter: rock!
* pitti sends a  Tim Waugh for being a great upstream
<geser> ajmitch: just upgraded ccsm to 0.5.2+git20070814-0ubuntu1 and it still WFM
<pitti> tkamppeter: with a nice default name now, I assume?
<ajmitch> geser: it was referring to an undefined symbol in a library
<ajmitch> geser: and I'm not using any 3rd party packages either :)
<pitti> tkamppeter: will have a look later, currently attacking new poppler version (cross your fingers that it fixes PDF printing :) )
<infinity> pitti: To be honest, I'm not sure if there is a difference anymore, I'd have to look at the code.
<pitti> infinity: --p-i-a is not even documented
<infinity> pitti: I know. :)
<infinity> pitti: Ahh, there we go.
<infinity> pitti: Okay, --print-architecture used to do the same thing as dpkg-architecture (call a compiler, other silly thing), while --p-i-a just dumped the current dpkg arch.
<infinity> pitti: Since 2005 or so, --print-arch was fixed to do what --p-i-a used to do, and then --p-i-a was aliased to --p-a, so they're the same (and both correct) now.
<infinity> pitti: I just live in the past, apparently.
<ajmitch> geser: I had old libcompizconfig0 installed, I guess it's a bit loose with shlibs
<pitti> infinity: ah, good; I guess I'll revert it then to stay on the documented side
<geser> ajmitch: bug mvo about it
<infinity> pitti: Probably safer, though if a dpkg dev ever drops --p-i-a, there will be an uproar from both the Debian and Ubuntu buildd maintainers who have it hardcoded all over the place (due to the old switch historically not quite doing the right thing)
<pitti> tkamppeter, geser: rock! new poppler fixes pdftops
<geser> yeah
<tkamppeter> pitti, great, then this showstopper is fixed.
<pitti> can anyone on current gutsy please test whether opening http://fixnum.org/public/fullcircle/fullcircle-issue01-english.pdf in evince crashes?
<geser> pitti: Segmentation fault (core dumped)
<geser> on amd64
<Mithrandir> pitti: works fine for me on i386
<pitti> geser: cool, thanks; with new poppler it works fine
<Fujitsu> Works on i386 here.
<tkamppeter> pitti, default printer name is derived from the model, and if the model was not auto-detected derived from the selected PPD.
<pitti> so seems bug 123116 is fixed as well
<ubotu> Launchpad bug 123116 in poppler "evince-thumbnailer crashed with SIGSEGV in Object::fetch()" [Medium,Fix committed]  https://launchpad.net/bugs/123116
* pitti downgrades poppler just to verify
<pitti> $ evince-thumbnailer -s 128 file:///tmp/fullcircle-issue01-english.pdf  /tmp/xx
<pitti> Segmentation fault (core dumped)
<pitti> yep, confirmed
<pitti> Riddell: updated and tested with evince and pdflatex; it doesn't seem to break ABI this time around, but if you could test it with kpdf and koffice it would be good
<Riddell> koffice doesn't use poppler
<pitti> oh, right
<Riddell> and neither does kpdf in gutsy right now, since it needed the new version, it's high on my list to port the poppler patch to kde 3.5.7
<pitti> Riddell: ah, I see; right, I had to do that for texlive, too
<pitti> Riddell: some minor things only, though, like UGooString -> GooString
<pitti> tkamppeter: please register, so that we can /msg
<pitti> tkamppeter: bug 132646 explains the problem
<ubotu> Launchpad bug 132646 in hplip "firmware files do not have any license" [Critical,Triaged]  https://launchpad.net/bugs/132646
<pitti> tkamppeter: I'll binary-NEW hplip now to make desktop installable again, but this should be sorted out with upstream eventually; can you contact them please?
<tkamppeter> pitti, now /msg should work.
<\sh> btw...is someone working on those screenlets for c-f?
<lifeless> mvo: I have no idea.
<Fujitsu> \sh: screenlets?
<RAOF> \sh: Not really for c-f :)
<\sh> Fujitsu, http://compiz.org/Desktop_Screenlets
<gaara> ANY1 HERE READY TO HELP?
<ogra> no
<ogra> thats not a support channel
<Riddell> mvo: if I run /usr/share/update-notifier/notify-reboot-required should update notifer give me a popup saying to reboot?
<mvo> Riddell: touch /var/lib/update-notifier/dpkg-run-stamp too
<Riddell> mvo: ok, that did something, what is it that touches /var/lib/update-notifier/dpkg-run-stamp ?
<mvo> Riddell: a configuration option added from update-notifier
<mvo> Riddell: that is dropped into /etc/apt/apt.conf.d
<Riddell> mvo: so for adept should I make an update-notifier-common package with notify-reboot-required and that apt option?
<mvo> Riddell: yes, that sounds perfect, then it can drop its 10-adept-periodic file too
<Riddell> mvo: ok, I'll implement the adept side before playing with u-n packages
<mvo> Riddell: ok
<Riddell> mvo: does anything delete the dpkg-run-stamp and notify-reboot-required files?
<mvo> Riddell: notify-reboot-required lifes on /var/run so it gets autoamtically removed and the dpkg-run-stamp is just a stamp file, no need to remove it, its monitored with inotify
<Riddell> right
<Riddell> mvo: do you know of anything which currently uses the upgrade hooks?
<mvo> Riddell: the kernel I think, hal
<Riddell> mvo: they use reboot-required but not the scripted upgrade hook
<Riddell> as far as I can tell anyway
<\sh> hmm..firefox is using some of those upgrade hooks, isn't it?
<Riddell> dunno, asac?
<\sh> they are copying things back and forth, at least since i had a look at the source package the last time, during feisty devel end or gutsy devel start, I'm not sure anymore
<\sh> and wine should have at least this "reboot needed" notification hook , because of wine-server and mdz' bugreport
<asac> \sh: firefox installs restart notification hints ...yse.
<\sh> asac: not this update notification for restarted firefox?
<\sh> s/ed/ing/
<asac> i don't understand your question ;)
<asac> its an update notification to restart firefox
<\sh> asac, yeah...didn't read properly :(
<mvo> Riddell: oh, sorry. firefox uses one of the upgrade-hooks
<Riddell> asac: so it does, thanks
<asac> but its not perfect that way
<asac> its often too late to restart firefox when binaries have been replaced
<asac> if user is out of luck he gets notification after firefox crashed ;)
* \sh ran once or twice into this problem ;)
<Riddell> "Please execute the asoundconf(1) set-default-card macro" wow, that's not very user friendly
<pitti> Riddell: WTH?
<ogra> sexy
<ogra> Riddell, where do you get that `
<ogra> ?
<\sh> with a nice blue background, I would say: vista baby vista  ,-)
<Riddell> ogra: alsa-lib upgrade hook
<ogra> ouch
* ogra didnt upgrade since tribe4
<Riddell> it only runs [ -f ~/.asoundrc.asoundconf ]  so I guess you have to have played around with your sound card settings previously
<Riddell> it's not a new script
<Riddell> seb128: you're on holiday!
<seb128> hi Riddell, yeah I know ;)
<Riddell> seb128: but while you're here, does anything in gnome have an update-notifier upgrade hook?
<seb128> not that I know, but better to ask mvo, he probably knows about package using hooks
<pitti> hey seb128
<seb128> hey pitti
* Hobbsee waves
* highvoltage waves across the ocean to Hobbsee 
<pitti> hey Hobbsee
<Hobbsee> highvoltage!
<Hobbsee> hiya pitti :)
* Hobbsee hugs pitti
<geser> Hi Hobbsee
<Hobbsee> hi geser
<ogra> meh, since when does evo complain that i didnt add attachments to my mails ...
* ogra shakes his head
<Riddell> ogra: it might do if your e-mail talks about something being attached?
<ogra> Riddell, right, it said something like that ... bad is if someone in a thread added that content... you have the question on every reply then
* lamont notices that splix and dovecot both build-depend things in universe.
<lifeless> holy crap that would be insane
<Hobbsee> i would assume it would detect quoted mail, and know not to ask for that
* lifeless hopes its in a plugin and thus nukable
<ScottK> In Kmail you can edit the regex that's used for the function.  I don't know about Evolution.
* lamont is reminded why he's happy evo has never been his mailer
<ogra> lifeless, thanks for the pointer, its indeed a plugin called "Attachment Reminder"
<Hobbsee> ogra: thunderbird doesnt do such rubbish.
<Hobbsee> thank goodness
<ogra> Hobbsee, well its a neat feature if you like it i guess ... and its just one clieck to disable it
<Hobbsee> ogra: true, but you're stuffed if you ever use another client, or webmail
<Hobbsee> ogra: better to teach yourself to attach the attachments first, then write the email.
<ScottK> Hobbsee: I think ogra is searching for a real mail client.  Mind you he didn't particularly find one IMO.
* ScottK ducks.
<Hobbsee> Scotta
<Hobbsee> ScottK: all mail clients suck.  some just suck a little less.
<ScottK> We can all agree on that, I'm pretty sure.
<ogra> ScottK, no, i'm trying to use what i deliver to my users so i can comprehend their errors and bugs :P
<ScottK> Ah.
<ScottK> That would be another reason.
<ogra> and evco isnt that bad ...
<ogra> *evo
<Mithrandir> ogra: depends on whether you have many folders or not.
<Mithrandir> it doesn't handle a couple of thousand folders, for instance.
<ScottK> I tried it before I tried Kmail and didn't much like it.  I tried Kmail and just quit looking.
<Hobbsee> kmail is the *only* kde app that manages to confuse me.
<ScottK> Can evolution use maildir for it's mail store yet?
<ogra> Mithrandir, i think in total i'm over 300000 mails atm stored in 45 folders
<Hobbsee> ogra: that's seriously too much email....
<ogra> it handles that quite well
<ogra> Hobbsee, i like complete local mail archives (and oi love evos search options, TB cant cope here)
<Hobbsee> ogra: true
<ogra> speed is the only issue ...
<ogra> but with that amount of mail its an issue with every mail app i guess
<ScottK> ogra: I found switching from mbox to maildir helped significantly on speed.
* ogra didnt use mbox since several years 
<Mithrandir> ogra: I have ~12M across 1400 folders, down from about 6.5k folders which just took too long to check them all.
<ogra> ScottK, actually since i switched to evo which offered that as default back then
<ScottK> OK.  Didn't know that about evolution.  Maildir/Mbox is a big performance difference application differences aside.
<ogra> Mithrandir, oh, i only have one folder on the server that i check and leave sorting to filters ....
<Mithrandir> yes, I filter into those folders.
<ogra> s/one folder/one incoming folder/
<ogra> but server sided i guess ...
<ogra> i leave the filtering to evo as well ...
<tkamppeter> pitti, ping
<pitti> tkamppeter: still here
<lifeless> what does 'policy timeout is not valid' when trying to suspend mean?
<Kmos> "running /scripts/init-bottom"
<Kmos> it's part of which package?
<lifeless> many
<highvoltage> initramfs-tools
<lifeless> its a directory of scripts
<highvoltage> (amongs others, yes)
<Kmos> bug 132289
<ubotu> Launchpad bug 132289 in Ubuntu "[gutsy]  segmentation fault during boot in /scripts/init-bottom" [Undecided,New]  https://launchpad.net/bugs/132289
<Kmos> it's about this bug
<ogra> Kmos, thats likely not even related to initramfs ...
<ogra> something *inside* is having a segfault
<ogra> to fix that bug you have to find out what exactly produces it
<Kmos> ogra: it's kernel related
<Kmos> ?
<ogra> unlikely ... its likely an app dying in the initramfs
<pygi> xhaker, poke?
<xhaker> pygi, rock on
<Kmos> ogra: what logs should I ask for ?
<Kmos> kernel generala ?
<Kmos> *general
<stdin> Bug #131961
<ubotu> Launchpad bug 131961 in initramfs-tools "segfault when booting 2.6.22-9-generic" [Undecided,Confirmed]  https://launchpad.net/bugs/131961
<xhaker> ogra, can it be udevd?
<pygi> xhaker, pm
<ogra> as i said, i doubt thats kernel related, to debug that you need to enter the initramfs during boot and find out whats dying ...  Kmos, thats a pretty advanced bug
<Kmos> :(
<Kmos> ogra: can you take care of it ? =)
<ogra> Kmos, no
<ogra> (i'm working fulltime on other stuff already but i assume the right people have seen it already)
<Kmos> i hope so :)
<Kmos> stdin: bug 132385 another seg fault
<ubotu> Launchpad bug 132385 in Ubuntu "Kubuntu shows three mysterious segfaults on VT1." [Undecided,New]  https://launchpad.net/bugs/132385
<stdin> Kmos: same bug
<Kmos> :))
<Kmos> stdin: dupe done, thx
<jdong> but but... that one is for *kubuntu*
<ice-phoenix> hi
<jdong> ;-)
<jdong> lol
<ice-phoenix> can someone help me with kubuntu
<Hobbsee> !jdong | jdong
<ubotu> jdong: jdong is Hobbsee: jdong: yes, but you're FULL OF CRACK!
<jdong> :)
<Hobbsee> ice-phoenix: you probably want #kubuntu
<jdong> how is everyone doing?
<ice-phoenix> tnx
<lamont> Keybuk: thoughts on 132536?
<lamont> pitti: requestsync doesn't like me
<Hobbsee> lamont: why?
<lamont> because I didn't have a deb-src line, I'm betting
<Hobbsee> that'll do it
<tkamppeter> pitti, I think we should put the 20_...nonroot... patch back into system-cups-manager. It makes the tool more universal. For example on systems without local CUPS daemon (pointing to a server via client.conf) s-c-p will work only with the patch. We should rename the patch to tell what it really does.
<lamont> tkamppeter: as long as the name isn't 20_gaping_security_hole.patch
<lamont> Hobbsee: that and the fact that apt-cache madison doesn't seem to find things with ~ in the name or some such
<Hobbsee> lamont: it doesnt use apt-cache madison anymore, afaik
<Hobbsee> lamont: it uses rmadison -u ubuntu and rmadison
<lamont> OTOH, that's just me hacking around the fact that dinstall hasn't run yet, so I'm using the local version, which is a backport to dapper
<lamont>  raise Exception('apt-cache madison does not contain %s/%s' % (sourcepkg, release))
<lamont> bad requestsync
<lamont> lying
<jdong> wait, apt-cache madison doesn't find what?
* jdong has been using that command forever
<lamont> jdong: it could be requestsync lyiung
<jdong> could be
<jdong> apt-cache madison has never failed on me
<jdong> knock on wood
<Hobbsee> lamont: you're using feisty, i take it?
<Hobbsee> hiya calc
<lamont> -mix.mmjgroup.com 1374: apt-cache madison postfix/2.4.5-3~0.6.06
<lamont> -mix.mmjgroup.com 1375: apt-cache madison postfix | grep 2.4.5-3~0.6.06
<lamont>    postfix | 2.4.5-3~0.6.06 | http://archive.mmjgroup.com  Packages
<lamont>    postfix | 2.4.5-3~0.6.06 | http://archive.mmjgroup.com  Sources
<pitti> lamont: hm, I thought it would use rmadison nowadays
<Hobbsee> pitti: it does.
<pitti> lamont: are you on feisty then? that one still used apt-cache madison IIRC
<lamont> pitti: remind me where to freshen requestsync from?
<pitti> tkamppeter: alright, makes sense
<StevenK> From devscripts
<lamont> because I'm running ~/bin/requestsync still...
<lamont> and yes, feisty
<StevenK> lamont: I can put a copy on a webserver, if you wish
<Hobbsee> lamont: http://wedontsleep.org/~sarah/requestsync
<lamont> nah
<pitti> copying
<pitti> lamont http://people.ubuntu.com/~pitti/scripts/requestsync
<pitti> tkamppeter: I'll rename it then and put it back
<lamont> requestsync postfix 2.4.5-3~0.6.06
<lamont> Unknown option: u
<lamont> is that bad?
<Hobbsee> lamont: why specifying -u?
<lamont> Hobbsee: that's the latest requestsync from you and pitti
<lamont> running on feisy...
* lamont backports the gutsy package
<Hobbsee> lamont: sounds like rmadison screwup
<pitti> lamont: aah
<pitti> lamont: rmadison -u -> you need gutsy's version
<tkamppeter> pitti, thanks.
<Hobbsee> lamont: i presume you've already got it, but http://wedontsleep.org/~sarah/rmadison FWIW
<pitti> tkamppeter: \o/ I mastered to convince s-c-p to print a page size specific custom test page
<lamont> I want an option to edit the requestsync message before it gets signed
<tkamppeter> pitti, you mean that you have a Ubuntu test page .ps file which prints on any page size like the original CUPS test page?
<pitti> tkamppeter: I did it in a rather generic way
<pitti> tkamppeter: s-c-p now checks whether there is a file /usr/share/s-c-p/testpage-<papersize>/ps
<pitti> tkamppeter: it reads the papersize from the PPD
<pitti> tkamppeter: if the papersize is not set, or there is not test page for that papersize, it falls back to the cups default test page
<pitti> tkamppeter: http://people.ubuntu.com/~pitti/tmp/04_custom_test_pages.patch -> WDYT?
<tkamppeter> I think it is a good idea. Send me the patch and I will apply it upstream.
<lamont> and then he forgets to add the text that was why he couldn't use the script.
<lamont> the postfix sync request should include the fact that it's currently in incoming...
<pitti> tkamppeter: I'll send it to Tim with some explanations
<lamont> pitti: my bad. ^^
<pitti> lamont: ah :)
<pitti> lamont: just send it as a bug followup
<pitti> tkamppeter: the nonroot patch should go to upstream then; it didn't look Ubuntu specific at all
<tkamppeter> pitti, have upstreamized the 20_... patch now.
<pitti> tkamppeter: ah, you have commit access, right :)
<tkamppeter> pitti, I am upstream of s-c-p since last week, too. Did I not tell you?
<pitti> tkamppeter: you did, but I wasn't aware of that ATM :)
<tkamppeter> pitti, so you can send the patch to me and I upstreamize it.
<pitti> tkamppeter: is http://people.ubuntu.com/~pitti/tmp/04_custom_test_pages.patch good for you? Or shall I mail you and Tim for comments from him, too? (might be better)
<tkamppeter> pitti, I will try it-
<tkamppeter> pitti, but note that Tim has fixed a lot of issues after I have done the last package we are 5 SVN revs further now.
<pitti> tkamppeter: ok, I'm doing an upload now with the ubuntu test pages and bug 107766 fixed
<ubotu> Launchpad bug 107766 in system-config-printer "system-config-printer adds menu item the same as gnome-cups-manager's menu item" [Medium,In progress]  https://launchpad.net/bugs/107766
<tkamppeter> pitti, I have applied your test page patch to s-c-p installed into my system and it ptints the original CUPS test page on my A4 laser and on my small 10x15 photo printer.
<tkamppeter> Should the A4 laser not print a special test page?
<pitti> tkamppeter: right, that's fine
<pitti> tkamppeter: of course you need the actual files, too :)
<pitti> tkamppeter: I put them into the s-c-p package now
<pitti> tkamppeter: just put a .ps file into /u/share/s-c-p/testpage-a4.ps
<pitti> tkamppeter: (if your printer paper size is configured as a4)
<pitti> tkamppeter: if there's good new stuff upstream, we can look into updating the package a couple of more times, no problem
<tkamppeter> pitti, test page patch is upstreamized now.
<pitti> \o/
<pitti> my first s-c-p patch
<tkamppeter> pitti, I really thought about repackaging from upstream now, as Tim has donme a lot:
<pitti> tkamppeter: sure, if you feel like it
<tkamppeter> Fixed bug 131848
<ubotu> Launchpad bug 131848 in system-config-printer "system-config-printer.py crashed with RuntimeError in save_serversettings()" [Undecided,New]  https://launchpad.net/bugs/131848
<pitti> tkamppeter: please wait until my current upload hit the mirror (in about 50 minutes)
<tkamppeter> fixed bug 132227
<ubotu> Launchpad bug 132227 in system-config-printer "Configuring a new printer should be easier and have better defaults" [Wishlist,Fix released]  https://launchpad.net/bugs/132227
<pitti> tkamppeter: wow! I filed that only two hours ago
<tkamppeter> Fixed redraw issues and added "Please wait" messages.
<pitti> oh, no, I mixed that up with the 'default selection' bug
<tkamppeter> Improved model matching
* Hobbsee looks for alberto milone's contact info
<tkamppeter> pitti, I do not need to wait for the mirrors, I download the sources directly from the Launchpad. is 0.7.71+-svn1399-0ubuntu2 the newest one.
<evand> Hobbsee: https://launchpad.net/~albertomilone/ ?
<pitti> tkamppeter: right, that would work
<Hobbsee> evand: ah, that one.  thanks
<evand> you're welcome
* Hobbsee goes to whinge
<Keybuk> lamont: bogus
<Hobbsee> greetings, Keybuk
* dobey kicks launchapd
<Keybuk> oh wait, maybe it isn't
<pitti> tkamppeter: TTYL, I need to disappear for some two hours
<Keybuk> iwj: udev doesn't build, FTBFS in watershed/libnettle somewhere
<Keybuk> lamont: why does there need to be a /usr/lib/libvolume_id.so ?
<lamont> well, if you want things to use it...
<infinity> Keybuk: To link against it..?
<Keybuk> what's wrong with /lib/libvolume_id.so :)
<lamont> that's not used by ld
<lamont> is used by ld.so
<infinity> Keybuk: The same thing that would be wrong with shipping /lib/libc6.so
<lamont> so the library package delivers /lib/libvolume_id.so, and the -dev package delivers the symlink in /usr/lib/libvolume_id.so
<lamont> Keybuk: see "debian-policy 8.4 Development files"
<Keybuk> ahh
* Keybuk just copied all this from Debian at the time; I never looked too hard :p
<lamont> interesting, since ubuntu udev versions are all >>>>> debian versions (which have a 0. in front of the ubuntu version)...
<Keybuk> yeah I changed the version :)
<lamont> any future need I have for versioned depends on udev?  we'll just forget about that
<lamont> actually, it'll just mean that I hack debian/rules to notice that we're on ubuntu, and manually verify that a late enough version is installed, or fail.  somehow, I'm not really looking forward to that
<iwj> Keybuk: Oh, really ?
<Keybuk> iwj: dunno, it builds ok this time
<Keybuk> strange thing
<iwj> Hrm.
<Keybuk> I'll upload if, if LP mails me, I'll bug you again :p
<lamont> Keybuk: util-linux currently build-depends: libvolume-id-dev (>=0.113)
* iwj finds a syntax error in perl-modules.deb's DEBIAN/control.
<lamont> which ubuntu always meets.  since dapper.
<lamont> so WTH did we gratuitously make our version >>>> debian?
<lamont> it's not like we can go back
<Keybuk> because upstream asked us to
<Keybuk> and our udev packages are so different anyway that everything that touches it needs to be checked
<Keybuk> so it wasn't a bad thing
<lamont> ok.  I'll believe you
<dobey> hey, does Scott James Remnant ever pop on irc?
<Keybuk> no :)
<lamont> the .so thing showed up when I was debdiffing the merged util-linux source
<lamont> dobey: only his brother does, as Keybuk.
<dobey> ah
<Hobbsee> Keybuk: you really should change the real name on your client, to fool people.
<Hobbsee> it's *far* more fun that way
* lamont was wondering why Hobbsee was sending him off to some sarah's public_html tree
<lamont> although only for about 10 seconds
<Hobbsee> lamont: :)
<Hobbsee> lamont: it's a good dumping ground.  the server is actually StevenK's, which i have a shell account on.
<tkamppeter> doko, ping
<doko> tkamppeter: pong
<tkamppeter> doko, biff, can you upload the new system-config-printer packages which I mention in my mail? Thanks.
<russ_> hi :) Anyone know there way around the file structure for Python on Ubuntu?
<russ_> My Question is:  I want to install a Python library, I know how to do this in Windows (c:\Python25\lib\) where do I put it in Ubuntu?
<ScottK> russ_: This channel isn't for support.  I'll help you with your problem in #ubuntu-motu if you come over there.
<russ_> ah ok, sorry for coming to the wrong place :-S
<russ_> thanks
<doko> tkamppeter: done
<tkamppeter> Thanks, doko, the two bugs got automatically closed now.
<slestak_> cjwatson: do you need any testers for your recent putty port?
<bddebian> Heya
<Hobbsee> slestak_: he's on leave
<slestak_> Hobbsee: k, thx.
<ScottK> It looks like soyuz fell over on https://launchpad.net/ubuntu/+source/zekr/0.5.1.dfsg-0ubuntu1 - " Failed to upload".  I'd appreciate it if an archive admin would have a look at it.
<\sh> mvo, ping
<\sh> mvo, you wanted to have the .xsession-logfile for the problem I have with the radeon card: http://de.pastebin.ca/658429
<\sh> lspci gives me: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AQ [Radeon 9600] 
<\sh> 01:00.1 Display controller: ATI Technologies Inc RV350 AQ [Radeon 9600]  (Secondary)
<\sh> brb
<\sh> back
<mvo> \sh: thanks
* Hobbsee hugs mvo in greeting
* mvo hugs Hobbsee
<Hobbsee> :)
<\sh> mvo, i tried just now to use the PCI 1:0:1 (secondary controller) but this doesn't work at all
<mvo> \sh: can I have the ouput of glxinfo and "LIBGL_ALWAYS_INDIRECT=1 glxinfo" please as well? it looks like for some reason your card does not support the subset of features that compiz requires. you use the "ati" or "radeon" driver I assume?
<\sh> mvo, ati oss driver
<\sh> mvo, glxinfo http://de.pastebin.ca/658439
<\sh> mvo, glxinfo with libgl_always_indirect setting: http://de.pastebin.ca/658441
<mvo> \sh: can you put /var/log/xorg.0.log somewhere too? my current theory is that your card is simply not support with propper 3d
<geser> \sh: did the drm module load the r300 microcode? (see in dmesg)
<Riddell> mvo: when I compile update-notifier it puts the gconf .schema file in /etc/gconf/schemas/ instead of /usr/share/gconf/schemas/
<\sh> mvo, http://de.pastebin.ca/658447 xorg log
<\sh> geser, moment I check
* Starting logfile irclogs/ubuntu-devel.log
<attunix> Isn't there a command where if I have multiple boot screens installed, it lets me choose which one? Because I did sudo apt-get install ubuntustudio-desktop. Later, I removed it, but the boot screen (with the loading bar) remained. Please help.
<xhaker> doko, eclipse 3.3?
<doko> xhaker: go ahead
<xhaker> doko, do you have any plans to push it into gutsy?
<doko> xhaker: sure, if you have packages ready
<xhaker> doko, sorry i don't have any. i was passing my eyes through the archives and checking the packages i use most so i can see if i help there
<xhaker> doko, do you think it'd be hard to make a package for eclipse using the previous version sources?
<doko> xhaker: talk with man-di on #ubuntu-java
<xhaker> thanks :)
<iwj> OMG it works and I'm going to upload it.  I wonder where all the bugs are ?
<iwj> (it = dpkg-triggers)
<Seveas> iwj, scary... :)
<ion_> iwj: Yay!
* ion_ high-sixes iwj
<sabdfl> yowser
<sabdfl> did we just drop dselect from main or from u-desktop?
<attunix> How do I install the ubuntustudio-desktop file? Apt-get gives me "E: Couldn't find package ubuntustudio-desktop."
<tkamppeter> pitti, you're back?
<pitti> tkamppeter: almost, back in ten
<iwj> ion_: It's just tricking me, I think.  I'll upload it and then tomorrow morning there'll be howls of protest in my inbox and irc client.
<tkamppeter> pitti, doko has uploaded my newest s-c-p package. Now it is really nice, "Please wait" pop-ups and no non-redrawing freezes.
<ion_> iwj: :-)
<ion_> Perhaps i should document my thoughts about how the s-c-p UI should be improved.
<ion_> just for consideration.
<bryce> \sh_away: great to hear - was reinstalling mesa what did it?
<tkamppeter> ion_, report your s-c-p improvement suggestions as a bug on Launchpad. Tim Waugh is bug contact of s-c-p and so he will get notified immediately.
<tbf> what's the reasoning behind installing .la files
<tbf> ?
<Mithrandir> none, we should remove them from the face on the planet.
<tbf> Mithrandir: well: $ dpkg-query -S libgtk-x11-2.0.la
<tbf> libgtk2.0-dev: /usr/lib/libgtk-x11-2.0.la
<tbf> does gutsy still install them?
<Chipzz> tbf: that's a bug; unfortunately, the .la files have to be removed in a specific order
<Chipzz> iirc top-to-bottom
<Chipzz> which means that a package like gtk+ which is very low in the stack will be one of the last packages to have that bug fixed
<tbf> Chipzz: ah. ok.
<verwilst> if i do an apt-get source linux-source-2.6.22, do i need to do a debuild?
<verwilst> will that build all the kernels?
<pitti> tkamppeter: cool
<tkamppeter> pitti, did you already go through the MIR for cups-pdf?
<pitti> no, not yet
<tkamppeter> pitti, I would like to close this blueprint before the UVF.
<xhaker> hmm
<xhaker> UVF for main and universe are simultaneous?
<shaya> what package does one report bugs in the live cd in
<shaya> basically, it wont work reliably on my Abit IP35-Pro motherboard (P35 chipset) if it doesn't boot w/ irqpoll option
<mjg59> shaya: kernel
<mjg59> linux-source-2.6.22 (assuming you're testing gutsy)
<shaya> yes
<shaya> it dumps to the initrd shell
<shaya> some sata errors that are hard  to catch w/o serial console
<shaya> filing
<shaya> filed
<shaya> if you need more info, feel free to ask
<verwilst> is there a way, during a debuild of linux-source, to build only 1 kernel
<verwilst> ?
<verwilst> now it's building all of them :)
<verwilst> which will take ages
<mdke> verwilst: maybe try #ubuntu or #ubuntu-kernel for that question
<verwilst> okido
<ijuz__> you can delete some config files
<ijuz__> there is this directory with the config.generic and for other archs/cpu-arch just delete the ones you don't want
<alex-weej> mvo: are you sure you merged my patch into the new version of notification-daemon properly? i'm still getting the old pie chart with -ubuntu6
<mvo> alex-weej: hrm, it should be in, I can have a look tomorow
<alex-weej> i just got the latest source package
<alex-weej> changelog entry is there
<alex-weej> same old 01_ubuntu_theme.patch
<mvo> hmmmm
<mvo> is the version on launchpad ok?
<alex-weej> the version on launchpad?
<alex-weej> i'm sorry i only see a package for feisty on launchpad
<mvo> alex-weej: I mean, the patch you added on LP is ok? its different and all?
<alex-weej> that would have been a pretty big error on my half if i uploaded the old version... let's see
<alex-weej> mvo: no it's right: http://launchpadlibrarian.net/8822330/01_ubuntu_theme.patch
<alex-weej> bug is https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/132512
<mvo> alex-weej: ok, then it was my bad :( sorry for that, I will do a new version tomorrow
<ubotu> Launchpad bug 132512 in notification-daemon "New pie chart code for the Ubuntu Notification Daemon theme" [Undecided,Fix released] 
<alex-weej> mvo: no problem
<bo0bi3> hey ro0m
<calc> asac: tested tribe-4
* asac listens
<calc> asac: its still hosed, i'm starting to think its the kernel
<asac> calc: so wpa psk still doesn't work?
<asac> or open net?
<calc> asac: i tested using a recompiled version of feisty wireless-tools and wpasupplicant and even then it wouldn't work
<calc> on an open net
<calc> didn't work for a aes wpa2 either
<asac> ok
<asac> open net is known to be broken
<calc> tribe-4 as is didn't work either
<calc> for me to test the kernel though means i will need to actually install it (ugh) ;)
<asac> so far i have received just one negative on wpa with broadcast ssid
* ajmitch has been having issues with wpa psk & NM recently as well
<asac> calc: http://ipw3945.sourceforge.net/
<asac> read changes 1.2.1
<asac> (we have 1.2.0)
<asac> i think that will cure the open net scenario
<ajmitch> asac: has this only been with ipw3945 so far?
<asac> * Fix driver not make associate request when required
<asac> * Fix iwconfig essid any doesn't associate problem
<calc> asac: i also completely firmware reset both of my routers today for other reasons, so it shouldn't be an issue with them
<asac> ajmitch: most issues we have are ipw3945
<ajmitch> asac: ok, my ipw2200 problems may be different then :)
<calc> asac: are we able to get an updated ipw3945 driver?
<ajmitch> given that I was able to associate & get an ip address a couple of times
<asac> ajmitch: i want to hear as much info as possible
<calc> ajmitch: maybe... we don't know what is the causing the problem yet though
<calc> ajmitch: i can occassionally get an address, but not today
<calc> ajmitch: its very uncommon for me to get an address under gutsy though
<ajmitch> asac: at one point it was just repeatedly asking for the key, I haven't often been using my laptop at home though
<asac> calc: I asked a few days ago in #ubuntu-kernel on how to prepare a test-package, but didn't get an answer
<calc> ajmitch: seen that myself under gutsy tribe3 also
<ajmitch> it had been very stable until recently
<asac> calc: i will try mailing-list after feature-freeze
<calc> should i be able to run the old feisty kernel on gutsy still?
<calc> if so i can try doing that on this box
<ajmitch> though my laptop went about 4-5 weeks without a dist-upgrade
<asac> ajmitch: thats hard to say then
<ajmitch> asac: I can test again tonight
<asac> ajmitch: a tighter regression window would be more helpful
<asac> ajmitch: can you try to downgrade if you see the issues with latest?
<ajmitch> which part? kernel, n-m?
<asac> nm
<asac> until you find that it works
<ajmitch> ok
<calc> too bad there isn't a way to install gutsy at a day granularity to go back and find when it broke
<calc> would take a lot of disk space to keep that many debs around though
<asac> calc: i think with vmware you could do daily snapshots
<stgraber> asac: are you sure we are running 1.2.0 in current Gutsy ? (modinfo tell me : version:        1.2.1mp
<stgraber> )
<calc> i couldn't compile old nm on gutsy, but it fails with old wireless-tools/wpasupplicant even at the ifup level
<stgraber> (and crappy copy/paste as usual)
<calc> asac: how would i get the old daily snapshots though?
<asac> stgraber: i am not 100% sure ... from what i know we have 1.2.0 + a backport of the security issue fixed in 1.2.1
<calc> asac: i mean going back in time and getting old gutsy debs to track it down
<asac> calc: you can manually get them from launchpad iirc
<stgraber> oh, I would need to give 1.2.2 a try when I have a moment then
<calc> asac: that would be very time consuming in case the problem isn't something we think it is
<asac> calc: which version did you try to compile?
<asac> stgraber: you sure 1.2.1 is 1.2.1?
<guignome> a filesystem with versioning could maybe do that
<calc> 0.6.4-6ubuntu7 <- i think it was that one
<calc> i just recompiled current gutsy against old libiw since it didn't work
<stgraber> asac: no, that's what modinfo tell me but the kernel guys can show whatever they want :)
<asac> stgraber: yes ... from what source is that shipped from again?
<calc> you know i'm going to verify that using ifup works on the feisty cd also
<asac> stgraber: let me look into that changelog again
<calc> since i haven't tested that yet
<mdke> is the current daily-live reasonably usable?
<mdke> anyone know?
<stgraber> asac: it's in : linux-ubuntu-modules-2.6.22-8-generic
<calc> i'll be back in a few minutes, verifying that feisty cd works like i expect it to
<asac> stgraber: thanks ... with s/-8-/-9-/ it works :)
<asac> stgraber: hmm according to changelog of that its 1.2.1
<asac> maybe 1.2.0 fixes things for us ;)
<stgraber> asac: with -9 I have no suspend to ram :)
<Lure_> asac: anything else I can do to help solve bug 126494 ?
<ubotu> Launchpad bug 126494 in network-manager "wired network shown as disabled after boot" [Undecided,New]  https://launchpad.net/bugs/126494
<asac> stgraber: if i read the changes for 1.2.1 on http://ipw3945.sourceforge.net/ they just look too much related to be a coincident
* stgraber agrees
<asac> 1. Fix driver not make associate request when required
<asac> ...
<asac> n. Fix hardware/software RF kill switch problem during module loading time
<asac> i mean it reads like i read reversed bugs here ;)
<stgraber> :)
<asac> in about box on that page it reads:
<asac> (any version ending in .0 is 'stable')
<asac> maybe we are not supposed to use 1.2.1?
<stgraber> asac: what's feisty's version ?
<stgraber> asac: 1.2.0 ?
<asac> 1.2.0mp
<asac> however i always received claims that feisty stopped to work with some upgrade
<asac> s/always/also/
<asac> stgraber: can you try?
<stgraber> I'd need a livecd with latest feisty kernel on it to test
<asac> maybe you can build modules with old ipw?
<asac> in gutsy?
<calc> asac: disregard my earlier report, i determined i was doing something wrong with feisty cd, testing on gutsy again now
#ubuntu-devel 2007-08-16
<calc> asac: about to test gutsy wpasupplicant to see if it is ok
<asac> stgraber: do you have i386 or amd?
<stgraber> asac: Core2Duo, so I can run both, but running amd64 currently
<asac> ok you feel scared enough to try a modules build?
<asac> or brave ;)
<stgraber> ipw3945 seems funny to buld as it requires some extra thing like ieee80211 (I tried to quickly build it 10 minutes ago :))
<asac> stgraber: so whatelse is needed?
<asac> did you try to build a -modules package?
<asac> i mean did it fail to build or did you run in troubles using the module?
<stgraber> I just had problem manually building it (no package, just grab the code and typed "make")
<asac> stgraber: the most current gutsy package with replaced ipw source appears to build for me
<asac> do you want that package?
<calc> looking too close at the problem makes it go away :\
<calc> its working at the moment on the gutsy cd again
<calc> i'm going to reboot it and see how it goes a second time
<asac> calc: you sure it was not fixed?
<calc> asac: well it did fail when i tried it before on tribe-4 cd via network manager directly
<calc> i have managed to get it to repeatedly fail at the ifup level the first time it tries to connect to the wpa2 network
<stgraber> asac: I can build it and test on my linux-with-broken-suspend-to-ram-2.6.22-9 :)
<calc> but it works everytime for the open network
<calc> at ifup level
<calc> need to see if it repeatedly works at the nm level
<asac> stgraber: ok thanks ... just replace the three source files
<calc> of course something similar happened for tribe-3 when it starts working it generally keeps working for that boot session
<calc> i'll do some more tests and report back to you
<asac> ok
<stgraber> yeah, pbuilder finished build swfdec 0.5.1 on Gutsy :)
<asac> nice
<asac> does it ship flashplugin-alternative ?
<stgraber> yep, my father will be happy once I'll have backported it to feisty PPC
<stgraber> I don't think so
<stgraber> let me check
<stgraber> asac: no it doesn't
<asac> hmm ... ok
<asac> is that ment to be uploaded?
<stgraber> I just took the packaging of the 0.4 version we currently have in Gutsy and tweaked the packaging a bit to have it working on Gutsy
<stgraber> not really, even if it'd be something interesting as 0.5 adds Youtube support
<stgraber> I'm doing it for my father who's a PPC user and then can't have the plugin wrapper
<stgraber> oh, it works really fine with video !!!
<calc> asac: ok NM is crap
<calc> asac: so far it looks like wpasupplicant with ifup works though
<calc> asac: NM in tribe-4 can't even see my broadcast ssid for the wpa network
<calc> asac: or at least it only sometimes displays it
<calc> asac: i think earlier it was showing up for NM
<calc> asac: regardless NM can't connect to the open ap either
<calc> asac: i'm not sure how NM can screw that up since it uses wpa to do the connection (i think?)
<calc> asac: i think i may have found something actually useful
<calc> asac: doing some final narrowing down and verifying the failure is 100% reproducible on my box
<calc> asac: right now it is looking like wpa-group/wpa-pairwise (not sure if both) are required to connect properly
<calc> asac: to connect to a wpa network i mean to say
<effraie> stgraber: what are you looking for your ppc?
<effraie> stgraber: if your looking for a(better) flash support, iirc, gnsh support youtube video in gutsy (and has been backported to feisty)
<ion_> Unfortunately it doesnt seem to be able to keep the video and the audio in sync.
<effraie> :|
<effraie> i'm ppc user, and i use donwloadvideo firefox extension + mplayer + ppc-codecs
<effraie> works fine
<effraie> not very userfriendly, but efficient
<asac> calc: what do you mean by < calc> asac: right now it is looking like wpa-group/wpa-pairwise (not sure if both) are required to connect properly
<asac> required by whom?
<calc> asac: required by wpasupplicant, but then it just started working without them, its a pita to debug
<calc> asac: now its working completely right
<calc> but still not working at all under NM
<asac> calc: wpa or unencrypted?
<asac> ah ok
<calc> wpasupplicant seems to be working for both via ifup
<calc> but occasionally it can't connect, so i'm trying to determine why that happens
<calc> i got it to do a string of failures on the wpa via ifup earlier
<calc> then i added wpa-group/pairwise and it connected so i thought that helped
<asac> calc: do you get errors like "cannot connect to wpasupplicant" in syslog/daemon.log
<asac> ?
<calc> asac: when using NM or with ifup?
<calc> btw NM can't see my wpa network at all most of the time at least on tribe-4
<asac> NM
<calc> i don't recall seeing that but i can look at it again
<asac> welll if it cannot connect to wpasupplicant it is blind .. yes.
<asac> its not the exact error message
<calc> NM can see my open network but not the wpa one
<asac> search for something related
<calc> ok i'll test that along with a couple other things and get back to you
<asac> fine
<xhaker> asac, there is a typo in n-m. "Caught terminiation signal"
<asac> xhaker: lol
<calc> asac: if i connect via ifup then shut down the interface and connect via NM it works
<calc> asac: also it seems NM can sometimes see the wpa network, not sure if it just takes longer to see it or what
<Kmos> asac: bug 132431
<ubotu> Launchpad bug 132431 in flashplugin-nonfree "package flashplugin-nonfree 9.0.48.0.0ubuntu8 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [Undecided,New]  https://launchpad.net/bugs/132431
<calc> asac: but yes NM is connecting to wpa properly even when it doesn't work
<asac> calc: what does that mean?
<asac> "even when it doesn't work"
<asac> ?
<asac> Kmos: he probably had a bad revision
<asac> before and the rescue measures crimsun tried didn't work out?
<asac> Kmos: oh syntax error
<Kmos> :)
<asac> Kmos: log reveals it was upgrade ubuntu4->5 which broke for him
<asac> not ubuntu8
<Kmos> and 9.0.48.0.0ubuntu5
<Kmos> so it's fix
<Kmos> fixed
<asac> i hope
<Kmos> the problem is that i run apport after one or two days later
<Kmos> and it got the current version installed
<Kmos> and not the one that crashed
<Kmos> but in the log we can see it
<asac> no idea ... lets keep our eyes open if we receive more reports ...
<Kmos> after i've got upgrade to 8, it installs fine
<Kmos> so it happens in -5
<calc> asac: still here?
<calc> asac: found something even more odd out about the situation
<calc> asac: it connects to the open ap as soon as it boots apparently, NM doesn't realize it, if I then try to connect to the network via NM it doesn't work loses the ip address and will not connect via NM to it again
<calc> asac: at least after several attempts anyway
<calc> i'm not sure if that is the reason it only sees the open ap since it was already connected to it before NM came up (maybe?)
<asac> probably
<calc> but it doesn't see the wpa one during this test
<asac> i guess your nm has issues to connect to wpasupplicant
<calc> i tried removing the auto line for the wireless in /etc/network/interfaces but that apparently disables wireless for NM also
<asac> you never denied nor confirmed that
<asac> please do so
<calc> asac: er yea i did
<calc> asac: i looked in the log and there were no obvious error messages
<calc> asac: and there were responses from wpa in the log
<calc> 18:29 < calc> asac: but yes NM is connecting to wpa properly even when it  doesn't work
<calc> 18:30 < asac> calc: what does that mean?
<calc> 18:30 < asac> "even when it doesn't work"
<calc> sorry didn't notice that question
<calc> i meant it connects to the wpasupplicant even when it doesn't get an address
<calc> and never fully connects
<calc> er to the network
<calc> so it connects to wpasupplicant but can't connect to the network
<calc> if i try connecting with wpasupplicant via ifup it seems to work most of the time and then starting NM back up and switching back and forth seems to work
<asac> what kind of responses do you see from wpasupp?
<calc> this is all very flakey still though
<asac> you can connect with wpa_cli while nm is working
<calc> normal stuff like "OK" etc
<asac> try what scan_results give you in wpa_cli shell
<calc> ok
<calc> i'll bring the laptop in here, not much room but its easier to test in here by my desktop
<calc> asac: i get the 00's timed out message like before
<calc> it looks like its running dhclient even while still timing out
<calc> in wpasupplicant
<calc> so it finally fully timed out and died
<calc> now going to test with ifup
<calc> ok ifup worked
<calc> then i shut the interface back down
<calc> then connected via NM
<calc> it shows connected but forgot to run dhclient
<calc> show it shows the signal bar, etc likes its good to go but with no ip at all
<calc> and it still doesn't show the wpa network (calc)
<calc> if i later run ifup eth1 (without the wpa entries in interface) it gets the ip address
<calc> i proceeded to turn off NM via the applet then back on
<calc> and now it doesn't see any networks at all
<calc> ah the open one "vinther" showed back up
<calc> shows connected again but without trying to get a dhcp address
<calc> so it has none, but the signal bar shows like it is connected
<calc> doing things via ifup/ifconfig NM is completely oblivious to
<calc> tried restarting the dhcdbd and then connecting and it still refuses to run dhclient when it connects
<calc> so at this point i can probably run gutsy but without NM disabled since it seems completely broken on my machine
<asac> calc: maybe your ap needs a reboot?
<asac> :)
<calc> asac: no, using ifup it works 100%
<calc> asac: i can run ifup eth1 after telling NM to connect and it immediately gets an address
<asac> and ifup is configured to use supplicant?
<calc> NM doesn't even attempt to run dhclient
<calc> asac: no even without it set to use supplicant
<calc> asac: NM connects but doesn't run dhclient
<asac> what do you mean by "it connects" ?
<calc> so its already connected at that point and ifup just runs dhclient on the connection
<asac> associate?
<calc> yea it is associated
<asac> do you see that associate event in syslog?
<calc> it seems NM is just a pile of crap at least from what i have seen while testing it today, no offense intended to you
<asac> well .. nm has to deal with all kind of stuff
<asac> if unexpected things happen it might get confused
<calc> asac: not sure if what i am seeing is the association or not
<calc> says something like this:
<calc> NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.
<calc> then nothign else
<calc> i ran ifup eth1 and got an ip
<calc> i don't see any stages past 2 of 5
* iwj uploads.  Bedtime.
<iwj> Goodnight all.
<asac> night iwj
<calc> asac: after restarting NM it doesn't associate any more
<asac> me too
<iwj> Hopefully I won't be too late getting up as a result of this session ...
<rbraley> use case: Ryan has an ubuntu livecd and wants to install it for a friend who wants software raid and an easy graphical installer. He does not want to have to download an alternate cd and waste a disk.
<asac> calc: sorry bedtime for me as well ... hopefully i can look into these ipw3xxx issues more closely next week again
<xhaker> asac, don't forget the typo
<xhaker> ;)
<summer_s4> how do i join?
<xhaker> cjwatson, already back?
<Pici> summer_s4: join what?
<summer_s4> nvm
<calc> asac: ok, it appears the ipw3945 issues may reside inside network manager
<Mez> hmm, here's a thought
<Mez> it'd be nice if when you install off the live CD... any changes you make are made to your install too (wouldnt take much - just a copy of the home dir would do a lot of it!)
<wasabi> Uh huh. You can do that.
<Mez> CAN
<Mez> but does it do it as default ?
<xhaker> \sh_away, i see you there.
<xhaker> ajmitch, care to take a look at bug #132853
<ubotu> Launchpad bug 132853 in libmtp "[needs review]  libmtp 0.2.1 udev rules file fix [needs upload] " [Undecided,New]  https://launchpad.net/bugs/132853
<ajmitch> xhaker: sorry, why me? :)
<xhaker> you're awake
<ajmitch> & at work
<xhaker> sorry, i thought it was fine to ask
<ajmitch> subscribe the correct sponsors team
<ajmitch> ubuntu-main-sponsors in this case
<xhaker> do i assign it to them?
<ScottK> No, subscribe
<ajmitch> no, subscribe
<jk-> hi
<jk-> do i get laughed at for asking about building cross gcc packages? :)
<xhaker> ajmitch, ScottK: thanks :)
<calc> asac: it seems to work somewhat better with an upgrade from feisty -> gutsy on hard disk
<calc> asac: not sure how it would fare on a fresh install
<calc> asac: if it doesn't work a fresh install that would indicate its some sort of configuration issue
<mneptok> i am the very model of a modern major-general
<StevenK> mneptok: ... vegetable, mineral ...
<StevenK> I have so forgotten the words to that song.
<pitti> Good morning
<mneptok> pitti: hoy
<StevenK> Morning pitti
<StevenK> pitti: Do you feel like processing some syncs for me? :-)
<pitti> StevenK: can do
<StevenK> infinity: Ping, re: libnss-db. I want to get it uploaded before UVF hits.
<StevenK> pitti: Bugs 132846, 132854, 132855 and 132858
<ubotu> Launchpad bug 132846 in xemacs21-packages "Please sync xemacs21-packages (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/132846
<ubotu> Launchpad bug 132854 in libgig "Please sync libgig (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/132854
<ubotu> Launchpad bug 132855 in mt-daapd "Please sync mt-daapd (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/132855
<ubotu> Launchpad bug 132858 in gem "Please sync gem (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/132858
<StevenK> Shush, ubotu
<jk-> libgig?
<jk-> is that under a sensible license now ?
<jk-> oh wait, that's just linuxsampler, nevermind :)
<StevenK> Heh
<pitti> yay, the first ppc live CD for ages
<StevenK> pitti: \o/
<StevenK> pitti: Your leave starts tomorrow, or today?
<StevenK> pitti: I remember my wedding - I invited nearly everybody from $WORK. Out of an office of 20 people, there was 3 people there on my wedding day.
<pitti> StevenK: today afternoon
<pitti> StevenK: kind of hard in the Canonical environment :)
<StevenK> Indeed. :-)
<StevenK> Lots and lots of video-conferencing gear. :-P
<pygi> xhaker, poke
<StevenK> pitti: Thanks for the syncs. :-)
<pitti> StevenK: np
* Hobbsee syncs StevenK
<Hobbsee> morning pitti!
<StevenK> Same version that's in Debian. :-P
<pitti> hey Hobbsee
<pitti> lol
<fabbione> morning guys
<pitti> hey fabbione
* Hobbsee throws icecubes at fabbione in greeting
<fabbione> oh yeah
<Hobbsee> hmm, adept-notifier is not installable anymore
<Hobbsee> update-notifier-common no longer exists
<siretart> morning folks!
<Hobbsee> morning siretart!
<siretart> pitti: before you get an heart attack the next time you do source NEW, may I /query you?
<pitti> siretart: of course
<Hobbsee> he might bite, though
<Hobbsee> morning mvo
<mvo> hello Hobbsee
<rbrito> Hi there.
<rbrito> I am having a hard time getting gutsy working on a PowerPC here.
<rbrito> I am not familiar with the development process of Ubuntu (but I am on the New Maintainers queue of Debian) and I would like very much to have Ubuntu working on PowerPC.
<Hobbsee> #ubuntu+1 for gutsy support, please see the /topic
<rbrito> Can anybody tell me who should I contact so that PowerPC is not a port, but an official, supported platform?
<Hobbsee> oh, hmmm.
<Hobbsee> then that probably does apply to here
<rbrito> Hobbsee, I'm not looking for support. I'm offering support. :-)
<Hobbsee> rbrito: yeah, figured that after i hit enter :)
<rbrito> I just don't know how the process works in Ubuntu.
<Hobbsee> rbrito: you'll need to wait for the majority of europeans to wake up, for a start
<rbrito> How does a platform qualify for being released as a proper release and not as a port?
<rbrito> Hobbsee, yes, those damned timezones...
<rbrito> I still have not went to bed... :-(
<rbrito> I'm more like a zombie here.
<Chipzz> rbrito: 07:36 < pitti> yay, the first ppc live CD for ages
<Chipzz> FYI :)
<asac> calc: wierd
<rbrito> asac, the gutsy dailies had a problem with the ide-core module not being loaded...
<rbrito> It was really strange.
<Mithrandir> rbrito: supported> make sure there's a sufficient commercial demand for support services for ppc.
<rbrito> And this persisted even after I completed an install and installed a newer kernel (and the ramdisk was redone).
<rbrito> Chipzz: Hummm... That message is from what day? :-)
<pitti> I tested the current ppc daily, and the session immediately crashes for me and returns back to gdm; I blame compiz :)
* pitti hugs mvo
<rbrito> Mithrandir: commercial support?
<rbrito> I see that the way that Ubuntu qualifies the platforms for release is quite different from that of Debian...
<rbrito> :-(
<mvo> pitti: can you give me the output of .xsession-errors please?
<pitti> mvo: I'll file a bug next week
<Mithrandir> rbrito: uh, being a port vs a supported architecture doesn't say anything about whether they're released as part of the release process or not.  Where did you read that?
<mvo> pitti: when I tested the daily from yesterday ubiquity did not want to instal
<mvo> pitti: ok, I'm behind with bugs :(
<rbrito> I would like to offer help in getting my hands dirty in the very little spare time that I have, but I don't know how the process works with Ubuntu...
<rbrito> And I would really like to use an Ubuntu distribution on some computers that I will be giving for some charity purposes...
<rbrito> Mithrandir: well, being a port has meant for PowerPC that it doesn't even boot, unfortunately. :-(
<Mithrandir> rbrito: no, that doesn't follow.  The reason ppc has been busted is nobody has cared about it properly.  That doesn't have anything to do with it being a port or not.
<rbrito> Mithrandir: you are talking with one person that cares and that would love to help. :-)
<rbrito> I just don't know what are the proper procedures to be a "Ubuntu Developer".
<rbrito> I surely would like to help.
<Mithrandir> rbrito: https://wiki.ubuntu.com/MOTU is a good starting point.
<Mithrandir> also, filing bugs with patches is always helpful.
<Mithrandir> given that lots of developers don't have ppc systems, they might break PPC without intending to, and without anybody filing bugs, breakage goes unnoticed.
<rbrito> Mithrandir: I already have filed a bug regarding this and another person has the same problems that I have.
<rbrito> Isn't MOTU just for packaging regular packages?
<rbrito> Sorry for my ignorance of the Ubuntu way of things...
<rbrito> mvo: Do you take care of compiz?
<mvo> rbrito: yes
<Mithrandir> rbrito: you start by doing MOTU stuff before you can get into core-dev who can upload any package in the distro so you can fix problems yourself.
<rbrito> mvo: you might have a good laugh at the screenshots that I posted from my system:
<rbrito> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/123263
<rbrito> I am willing to test as much as I can.
<rbrito> Mithrandir: thanks for the information. I will look into that.
<ubotu> Launchpad bug 123263 in compiz "tribe-2 has severe problems due to screen effects enabled by default" [Undecided,Incomplete] 
<rbrito> mvo: I'm using a Matrox G400 in that computer...
<mvo> rbrito: that looks indeed quite bad. if matrox does not work, we can blacklist it
<mvo> rbrito: does that happen with more recent compiz/xorg too? i.e. tribe-4 etc
<rbrito> I can experiment whatever is necessary to get things working..
<rbrito> I take backups daily. :-)
<rbrito> mvo: I don't know, but I can test it and get back to you.
<Chipzz> rbrito: today :)
<rbrito> What timezone are you in?
<mvo> rbrito: that would be nice
<mvo> rbrito: a lot got done between tribe2 and tribe4 :)
<rbrito> :-)
<Chipzz> rbrito: me (and mvo too I think) are CET
<Chipzz> (Central European Time)
<rbrito> mvo: as you can see from my verbose reports, I am quite willing to help get things working.
<rbrito> I don't measure efforts.
<rbrito> I can do whatever is needed to get it working...
<rbrito> This is my main workstation... :-/
<rbrito> Ok, I'm almost going to bed (had spent a good amount of time studying), but I needed to get those points communicated...
<rbrito> The Matrox problem and the PowerPC problem...
<rbrito> mvo: BTW, my Matrox card *can* work with GLX enabled under Debian's X server.
<rbrito> But since I only have 16MB of VRAM, it isn't sufficient for a resolution of 1280x1024, which is what Ubuntu automatically detects on my system...
<rbrito> mvo: those screenshots and pictures that I took look quite nasty, huh? :-(
<mvo> rbrito: ok, that makes sense, 16mb vram is way too small for the textures, so it should not run compiz
<rbrito> mvo: but compiz gets started... (At least it did when I tried to boot).
<rbrito> Is that a case of blacklisting my Matrox card, then?
<mvo> rbrito: yeah, that is the problem that needs to be adressed, it should not get started. we either need to blacklist your card or find a heuristic about cards with too little memory
<rbrito> This would be a huge step into getting gutsy in shape for that computer...
<rbrito> Right...
<rbrito> The second option would be better, of course, if it doesn't amount to a huge effort.
<pitti> infinity: btw, apport is good for lpia now
<pitti> infinity: adding to wiki page
<rbrito> mvo: if you want me to run any particular test, please let me know and I will get back to you.
<mvo> rbrito: not currently, thanks
<rbrito> mvo: you're welcome.
<rbrito> Thanks.
<rbrito> BTW, regarding the PowerPC port, who is in charge in Ubuntu?
<pitti> rbrito: nobody in particular ATM
<rbrito> (If there is one person or group in charge of it, that is).
<rbrito> pitti: do you want me to test anything to see how things go with PowerPC?
<rbrito> The ide-core module isn't being loaded, unfortunately.
<rbrito> I have to load it manually...
<pitti> rbrito: sure, testing the current live CD and reporting bugs (preferably with solutions) would be great
<pitti> rbrito: it's entirely a community port now, so everyone who wants to improve it is warmly welcomed to do so :)
<pitti> rbrito: I didn't have that problem on my old G4 800, though
<infinity> pitti: Huzzah.
<infinity> pitti: Not that I expect it to get used, mind you...
<pitti> infinity: we shuold alter the seeds then
<rbrito> In fact, I almost compiled a kernel without modules for the iBook that I have here, but I didn't have time I and I judged that it would be best to communicate so that others would know about it.
<infinity> pitti: The moblin seeds are entirely up to Tollef at this point, I'm leaving it to him to decide what is and isn't going to be used.
<infinity> pitti: But, I'm happy with trying to get (most of) main happy with lpia regardless, so people can feel free to mangle the seeds at will.
<rbrito> pitti: I filed this bug regarding PowerPC
<rbrito> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/126146
<ubotu> Launchpad bug 126146 in initramfs-tools "gutsy doesn't boot completely on powerpc (dup-of: 131150)" [Undecided,New] 
<ubotu> Launchpad bug 131150 in initramfs-tools "IDE drivers not loaded at boot with powerpc" [High,Confirmed] 
<rbrito> mvo: thanks for marking the bug as confirmed.
<rbrito> pitti: If there is anythng that I can do to help, please let me know.
<tkamppeter> hi pitti
<mvo> rbrito: do you still have problems if you disable compiz (i.e. failsafe gnome session) ?
<mvo> rbrito: i.e. is the resolution still too hight for the card then?
<rbrito> The iBook that I have here is maily for delivering classes and I would love to get rid of this proprietary operating system that I have installed.
<pitti> hey tkamppeter
<rbrito> mvo: I went back to a terminal and changed things in the xorg.conf file...
<tkamppeter> pitti, what about the seeds, the MIR, and the UVF
<rbrito> mvo: I don't quite remember, but I can test it.
<rbrito> I will report that back tomorrow, is that OK?
<rbrito> When are the images generated?
<rbrito> I can grab a fresh image and see how it works...
<pitti> tkamppeter: I'll have a look at the MIRs later, but there's no hurry; seed changes are not bound by FF/UVF
<tkamppeter> OK
<rbrito> mvo: But if I recall correctly, even when I chose vesa, it had a high resolution.
<virgilio> hi all, I just installed gutsy alpha 4 and updated all the system. After that I've tried to install kubuntu-desktop package to swith to kubuntu, but the proccess can't start due to a dpendency problems with adept
<mvo> rbrito: sure, tomorrow is fine
<mvo> rbrito: I just want to check if we have two bugs here (one that ocmpiz runs and the second that even without compiz the resultion is too hight for the card)
<Riddell> virgilio: I know what that is
<Riddell> mvo: did you upload the new update-notifier?
<Riddell> mvo: doesn't look like it, I'll upload now
<mvo> Riddell: thanks
<rbrito> mvo: the resolution of 1280x1024 runs fine here.
<rbrito> mvo: I have Debian installed right now and I am using 1400x1050 and I don't have any problems...
<rbrito> mvo: Or do you mean other problems?
<rbrito> Well, it's almost 6am and it is way past bed time... :-)
<rbrito> Thank you very, very much for everybody that helped.
<rbrito> This community is superb.
<asac> stgraber: managed to build 1.2.0 module yet?
<Hobbsee> [19:38]  <Saied> this is the error: GPG error: http://security.ubuntu.com feisty-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key
<Hobbsee> who's in charge of that?
<\sh> fck...golem.de reported about the hacked community administrated server...this is bad really bad
<asac> Hobbsee: if you get that error as well then ask pitti / keescook
<Hobbsee> asac: ENOFEISTY.  that was in #ubuntu
<pitti> elmo rather
<pitti> only elmo and cjwatson have katie powers
<pitti> weird, works just fine for me
* StevenK wonders when -security is getting sucked into LP.
<StevenK> pitti: How much longer in your working day? :-)
<pitti> StevenK: 1.5 hours, I think (plus most probably the meeting tonight)
* StevenK nods.
<StevenK> pitti, Mithrandir: Would you mind bumping the priority of the libgig sparc build? It's going to cause NBS work, but I'd rather get it through NEW first.
<\sh> who removed the uwn with the news of the hacked servers?
<pitti> StevenK: done
<StevenK> pitti: Danke
<pitti> oh, you guys scared me
<pitti> seesm that hack affected some external mirrors, not security.u.c at all
<StevenK> Hrm?
<StevenK> Heh. Build of 5000.
<StevenK> Er, build score
* StevenK tries to get infinity's attention.
<Lutin> pitti: can you give-back kdebindings, mt-st and lmtest please ?
<pitti> Lutin: nothing to g-v for mt-st, kicked the rest
<StevenK> pitti: libgig has built everywhere, would you mind waving your magic touch over it?
<Lutin> pitti: didn't notice mt-st was synced yesterday :) . thanks
<pitti> StevenK: *jedi wave* libgig is not in new. this is an illusion
* Hobbsee turns pitti into an illusion, while waiting
<StevenK> Whatever you say, pitti
<pitti> Riddell, Hobbsee: any idea about the adept uninstallability?
<pitti> ... and language-selector-qt ?
<Hobbsee> pitti: we blame mvo, i think
<Hobbsee> pitti: looking at backscroll, the adept should fix itself
<pitti> Hobbsee: I like those
<Hobbsee> pitti: cant see the l-s-qt, but i've not done full updates yet (so i dont download adept twice)
<infinity> StevenK: ?
<pitti> Hobbsee: it's still on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
* pitti sighs on sparc
<StevenK> infinity: libnss-db! UVF is rapidly approaching.
<pitti> calc: is there any chance to get OO.o built on sparc, to solve that mess? ^
<infinity> StevenK: It's not a new upstream version. :P
<infinity> StevenK: (But yes, yes, I know)
<Riddell> pitti: yes, it needs a new update-notifer, which I've uploaded this morning
<StevenK> pitti: Nope. It looks like OO.o has to fail on one random architecture per major version number ...
<pitti> StevenK: well, this time it's a gcc ICE, so not actually calc's fault
<StevenK> Neat!
<mvo> Hobbsee: that is the usual line, right :P ? "blame mvo"
<Hobbsee> pitti: because it hasnt gone thru yet
<Hobbsee> mvo: yes.  or calc.
<Hobbsee> mvo: but you're today's target.
<StevenK> ICE me harder, gcc.
<pitti> mvo: "itz (apt|gtk) bug"
<pitti> StevenK: duh, and we'll use such a beast (ICE) to get to our honeymoon :)
<Hobbsee> pitti: besides, i thought you didnt care :P
<pitti> Hobbsee: I do care about archive installability :)
<Hobbsee> pitti: meh
<Hobbsee> pitti: that's overrated
<pitti> and yes, even for KDE :-P
<Hobbsee> :P
<StevenK> pitti: What does ICE expand to? You so aren't using a complier error to travel. :-)
<pitti> StevenK: "InterConnect Express" (something like that); German high-speed train
<StevenK> Ahhhh
<pitti> StevenK: http://www.hochgeschwindigkeitszuege.com/germany/index_ice_3.htm
<pitti> duh, I'm so OT here, it hurts
<Hobbsee> pitti: nice.....
<StevenK> Hah. Way cool. I can read about one word in twenty on that page ...
<pitti> StevenK: http://en.wikipedia.org/wiki/InterCityExpress might be better :)
* Hobbsee can get the vague idea of the page
<pitti> Hobbsee: "Train. Fast. Slick. White."
<StevenK> Oh, so can I. "It's a fast, expensive train."
* StevenK grins and high fives pitti 
<Hobbsee> pitti: :)
<ajmitch> pitti: have a good vacation then :)
<ajmitch> pitti: so can we switch to f-spot as default photo importer now? :)
<pitti> ajmitch: still a week until it starts, but thanks
<asac> calc: are you on i386?
<asac> calc: you upgraded your real install now, right? we try to replace your ipw3945.ko module?
<infinity> pitti: Thanks for the locales work.  You rock.
<pitti> infinity: no problem
<pitti> tkamppeter: so, cups-pdf could be much more defensive and cautious, but I couldn't find an immediate attack
<ogra> seb128, my little calendar from the clock applet is a popunder with compiz ...
<ogra> (instead of staying above all other windows it stays below)
<Hobbsee> calc: ping
<Hobbsee> mvo: we've changed.  it's now all calc
<Hobbsee> s fault.
<Hobbsee> cprov: hiya
<cprov> Hobbsee: hi there
<mvo> Hobbsee: haha, happy to hear that I'm off the hook for now .)
<infinity> mvo: Can I blame you for things instead?
<Hobbsee> mvo: just for now.
<mvo> infinity: I answer only to compiz issues and you do not even run X on your systems (and if you do, you only use it to display xterm). so I will ignore you
<infinity> mvo: Hahaha.
<mvo> :P
<Hobbsee> mvo: then again, why does the apt manual document an option that doesnt exist?
<infinity> mvo: I've upgraded to gnome-terminal.  I'm totally 21st century now.
* mvo grumbles about X-less freaks
* mvo applauds to infinity :)
<mvo> Hobbsee: which one would that be?
<Hobbsee> mvo: apt-get purge foo
<Hobbsee> mvo: apt-get remove --purge foo appears to work, but not the other
<mvo> *cough* mumble mumble *cough*
<infinity> mvo: I did actually have a question for you, though.  When you do libapt-pkg ABI bumps and reupload the world, do you use versioned build-deps, or do you just go with the "wait until apt is built before I upload" procedure?
<Hobbsee> hehehe
* mvo has a important  appointment
<Hobbsee> mvo: sure you do.
<Hobbsee> infinity: the latter, it seems
<mvo> infinity: versioned build-depends
<infinity> mvo: Cause if it's the latter, my having apt/libapt on hold in the lpia chroots will mean everything's built against the old ABI.
<Hobbsee> oh, hmm.  then i got it wrong, the last time i uploaded it
<mvo> unless I forgot about those (that happens sometimes I figure), but that is the drill
<infinity> mvo: Okay, cool.
<infinity> mvo: S'all I wanted to know.
<Hobbsee> mvo: another one, compiz-fusion-plugins-unofficial isnt something we distribute, and my apt-cache is not lying?
<rgl> hello.
<dobey> ogra: there is a patch in opensuse to fix that. don't know if it has been submitted upstream though
<Hobbsee> mvo: that's hte second report we've had about conflicts with it and c-f-p-m.
<mvo> Hobbsee: I have not uploaded it, I know nothing about it. it sounds scary
<rgl> Any ideia why gtkmozembed core dump on ubuntu?
<Hobbsee> mvo: indeed.
<mvo> Hobbsee: it probably comes from a third party repo (/me looks at treviho)
<Hobbsee> mvo: likely.
<ogra> dobey, ah, nice, thanks ...
<dobey> i thought there was anyway
<dobey> i don't see it in the source rpm though
<dobey> it's an easy fix though
<dobey> bbiab
<\sh> mvo, bryce: one question or one sugeestion regarding yesterdays problem with libGL.so.1.2 (they are both in xorg-driver-fglrx and libgl1-mesa-glx), can't we divert this lib in xorg-driver-fglrx and on removal put the divert back in place, so that libGL1.so.1.2 is back to normal libgl1-mesa-glx lib?
<mjg59> Isn't that what's done?
<\sh> mjg59, if it would be like that, I hadn't to --reinstall libgl1-mesa-glx somehow
<\sh> after removal of fglrx driver
<\sh> but I could check the source
<mjg59> Well, something else could be broken
<infinity> \sh: We definitely divert properly, I wrote all that myself.
<infinity> \sh: And I suspect it's not been touched since, for fear of disturbing the delicate ecosystem that is my maintainer scripts.
<\sh> infinity, hmm...so something else went wrong...but what could trigger this behaviour?
<infinity> \sh: What was the problem, exactly?
<\sh> infinity, I installed xorg-driver-fglrx (which was wrong) and after removing the package I just couldn't use the libGL.so.1.2 from libgl1-mesa-glx
<infinity> \sh: Note that I actually use xorg-driver-fglrx on feisty, and know it's doing the right thing here, I can check gutsy in a chroot, though.
<\sh> infinity, so i had to --reinstall this mesa-glx package
<\sh> infinity, to get the right libGL.so.1.2
<infinity> \sh: That's either a bug, or something went very wrong just for you.
<infinity> \sh: gutsy?
<\sh> infinity, yepp
<infinity> Let me check quickly.
<\sh> infinity, hmm...the preinst and postrm scripts are looking ok for me...
<\sh> (looking at the source)
<infinity> \sh: Works correctly here.
<seb128> ogra: bug #131050
<ubotu> Launchpad bug 131050 in compiz "[gutsy]  Clock applet calendar/timezones opens under focused window" [Undecided,New]  https://launchpad.net/bugs/131050
<\sh> really strange...I'll check again this evening if I can reproduce it
<ogra> seb128, ta
* Hobbsee goes thru the ubuntu-devel moderation queue
<Hobbsee> yay, spam!
<xxxxx1> mornin'
<Kopfgeldjaeger> can anybody tell me how to set the cursor into a gtk.entry with pygtk?
<Chipzz> Kopfgeldjaeger: wrong channel
<Kopfgeldjaeger> Chipzz: i know. asked in the right channels already :d
<Chipzz> Kopfgeldjaeger: and I have already pointed out to you that this channel isn't for such questions...
<Chipzz> Kopfgeldjaeger: that's no excuse to ask here
<Kopfgeldjaeger> Chipzz: ok, i just thought here are some pygtk coders.
<Kopfgeldjaeger> Chipzz: ok.
<Chipzz> *sigh*
<Hobbsee> oh, twitch
<jwendell> agoliveira, around?
<agoliveira> jwendell: Yep :)
<jwendell> agoliveira, hi!
<agoliveira> jwendell: Hello
<jwendell> agoliveira, that new arch, lpia, is for ubuntu mobile?
<agoliveira> jwendell: yes
<jwendell> agoliveira, will it be ready for gutsy?
<agoliveira> jwendell: Well, the final version is target to be gutsy + 1 but we do will have something for gutsy.
<jwendell> agoliveira, is that chip the same as run in nokia devices (n800, etc) ?
<agoliveira> jwendell: No. Check this out https://wiki.ubuntu.com/MobileAndEmbedded/FAQ
<jwendell> agoliveira, thanks ;)
<agoliveira> My pleasure.
<bddebian> Heya
<doko> slomo, seb128: why does libgdiplus have to build its own copy of cairo?
<seb128> doko: no idea, I don't even know what libgdiplus is
<calc> asac: it seems to be working so far on the upgraded to gutsy
<calc> asac: which seems odd
<asac> calc: lots of things are odd ... so open network works? or wpa?
<calc> asac: connects to both fine
<calc> asac: i'll have to back up my install when i have time and do a fresh install to see if it breaks there as well
<calc> asac: i have done a fresh install of gutsy in the past ~ tribe2 iirc and it didn't work at all
<asac> calc: please remove all things from keyring et al and see if things work good again :)
<asac> calc: do you have i386?
<calc> asac: so i'm not sure if this is working due to it being an upgrade or not
<asac> calc: would you be brave enough to try to use 1.2.0 module to see if it breaks more or less?
<calc> asac: yes i386
<calc> asac: i can try it, but right now it seems to work 100% on the upgraded from feisty
<asac> calc: yes ... but i would be interested to see if things break for 1.2.0
<calc> asac: ok
<asac> calc: let me copy that .ko file for you (i have no idea if it will work at all)
<asac> or if you need a different ipw3945d as well
<asac> calc: can you tell me in which package the ipw3945d resides?
<calc>  dpkg -S /sbin/ipw3945d-2.6.22-9-generic
<calc> linux-restricted-modules-2.6.22-9-generic: /sbin/ipw3945d-2.6.22-9-generic
<mathiaz> kylem: Thanks for updating apparmor. Is there anything I can test now ? Or should I wait for the next kernel upload ?
<kylem> i'll be uploading it today, i meant to build test debs for you, but unfortunately they were amd64 (i forgot to use my i386 chroot)
<Mithrandir> siretart: cdrtools> why?
<kylem> the only problems i had merging the AA stuff was conflicts due to context, so there shouldn't be any borkage introduced.
<Chipzz> doko: not sure why it needs to, but I saw some blog post on monologue ("planet mono") that the latest version (possibly VCS) can use the system cairo (though it's not recommended)
<siretart> Mithrandir: I talked to pitti about that
<mathiaz> kylem: ok. So I should be able to test the new stuff by tomorrow.
<siretart> Mithrandir: why not? I think it should be fine for multiverse.
<kylem> ok.
<Mithrandir> siretart: because we have wodim which is the same, but with less crack licence.
<\sh> doko, eclipse on gutsy doesn't find java (sun-java6-jre installed) ;)
<pygi> Mithrandir, allow me to interfere?
<siretart> Mithrandir: can we take this to /query?
<Mithrandir> pygi: please. :-)
* pygi feels he shouldn't be doing this but oh well
<doko> calc: in the past you could find the fc patches at http://cvs.fedora.redhat.com/ , but this location probably has moved
<pygi> Mithrandir, cdrkit is just much more broken cdrtools :)
<doko> \sh: then please fix it
<siretart> Mithrandir: you did notice that I want to have it in multiverse, did you?
<Mithrandir> siretart: yes, I did.
<\sh> doko, hehe...i don't have any clue about it...or it's a bug which I produced myself...I don't know ;)
<doko> Chipzz: any reason for "not recommended" ?
<Mithrandir> pygi: wouldn't it then be better to spend effort on improving cdrkit than cdrtools?
<doko> no time for eclipse
<\sh> I just reboot my machine again
<siretart> and you did recognize that I repackaged if from scratch, including the debian/copyright, which I have been working on for days together with schily, es?
<pygi> Mithrandir, actually, we won't be improving any of those =)
<\sh> doko, I'll look into it, when it's there after the reboot
<\sh> brb
<Mithrandir> siretart: yes.
<pygi> Mithrandir, cdrtools would be worked on by joerg, and nobody works on cdrkit anymore ... we have no much things to do there
<siretart> Mithrandir: I don't intend to spend lots of efford in cdrtools. just package it and keep it as it is in multiverse
<Chipzz> doko: not recommended or not supported; I think the latter
<calc> doko: yea caolan sent me the cvs revision number of the change and I tested it, it works for Ubuntu so I will be adding that to the next upload fixing the rest the problems from my first upload
<Chipzz> still experimental IIRC
<siretart> Mithrandir: if you reject the upload, I'm happy to forward the reject message to joerg
<doko> Chipzz: sure, but *why*
<Chipzz> doko: dunnow; just relaying something I recall reading ;)
<siretart> Mithrandir: improving cdrkit requires a lot of upstream knowledge which I don't have and I'm not that interested in
* calc bbl
<Mithrandir> siretart: I'd rather not want to be dragged into a discussion with upstream; I really, really don't like his discussion style.
* siretart neither
<siretart> I've had a few hours phonetalk with him.
<Chipzz> doko: http://pages.infinit.net/ctech/poupou.html
<siretart> I've come to the conclusion that his license is not what I would personally call free, but should be fine for multiverse
<Mithrandir> siretart: it seems to me that the source ships bits under CDDL and bits under the GPL and those are used by common code.
<siretart> I'm happy to read your reject rationale if you come to another conclusion
<Mithrandir> siretart: this is just from reading the copyright file, so I might be mistaken.  Am I?
<doko> calc: http://cvs.fedora.redhat.com/viewcvs/devel/openoffice.org/?root=core
<calc> doko: thanks
<siretart> Mithrandir: there is gpl code (mkisofs), that uses a cddl library.
<siretart> Mithrandir: according to upstream, he compares this to running binaries under a non-free os, which is even mandated by the fsf
<mathiaz> seb128:
<siretart> Mithrandir: there are more hairy bits in the licences, namely the additional restrictions to cdrecord/cdrecord.c. that bring me to the conclusion of non-free
<mathiaz> seb128: I've added the net usershare to the samba package
<Mithrandir> siretart: it's not, since running on non-free OS-es is covered by the system libraries exception.
<seb128> mathiaz: I've read that, thanks
<siretart> Mithrandir: I need to leave now, my gradma is ill, let's discuss this tomorrow, okay?
<mathiaz> seb128: bug 128548
<ubotu> Launchpad bug 128548 in samba "Enable net usershare?" [Wishlist,In progress]  https://launchpad.net/bugs/128548
<Mithrandir> siretart: sure, that's fine.  Hope she recovers.
<Mithrandir> siretart: just ping me when you're aroudn.
<mathiaz> seb128: it needs to be sponsored. Would this be possible after FF ?
* pygi would also like to hear about the outcome of the discussion, as he's interested in the topic, but doesn't want to get dragged into that discussion again :)
<seb128> mathiaz: after FF it'll require a freeze exception
<seb128> mathiaz: I can sponsor the upload now if you want
<bddebian> Any chance someone can get to qca2 in New?
<mathiaz> seb128: well it's not really a bug fix. It's more a feature - that's why I'd like to get it into main before FF
<seb128> bddebian: any hurry to it?
<seb128> mathiaz: right
<bddebian> seb128: Not necessarily, just need it for the psi from Debian experimental but for now I'm going to try to build it locally and if all goes well I'll just upload psi
<seb128> infinity: any opinion on the patch attached to bug #128548?
<ubotu> Launchpad bug 128548 in samba "Enable net usershare?" [Wishlist,In progress]  https://launchpad.net/bugs/128548
<seb128> bddebian: NEWed
<bddebian> seb128: What's NEWed?
<seb128> bddebian: ?
<seb128> bddebian: what did you just ask for?
<bddebian> Oh sorry, I'm asleep :-(
<bddebian> Thank you
<seb128> you're welcome ;)
<Mithrandir> seb128: any chance I could ask you to NEW ubuntu-meta too?
<seb128> Mithrandir: looking
<Mithrandir> cheers
<seb128> Mithrandir:
<seb128> $ dpkg -I ubuntu-mobile-dev_1.63_i386.deb | grep Depends
<seb128> $
<seb128> is that on purpose?
<seb128> ups
<seb128> ignore what I wrote :p
<seb128> is that for lpia only?
<Mithrandir> it's mostly useful for lpia, but I think we might see people wanting to do development both i386 and amd64 systems.
<Mithrandir> and the depends line is a bit on the short side, yes.  That's partially due to a germinate bug, and partially because I haven't gotten around to adding more bits to it.
<seb128> Mithrandir: ok, no problem, NEWed
<kagou> tkamppeter, have you packaged today cvs version of s-c-p ?
<kagou> hi seb128
<seb128> lu kagou
<Hobbsee> mvo: are you interested in http://pastebin.ubuntu-nl.org/33936/?
<mvo> Hobbsee: everything current on that system?
<Hobbsee> mvo: it's not mine.  #ubuntu+1
<seb128> Hobbsee: ldd /usr/lib/python2.5/site-packages/compizconfig.so | grep local?
<Hobbsee> seb128: no output
<seb128> Hobbsee: libcompizconfig0 installed version?
<Hobbsee> seb128: --> -bugs.  someperson
<Hobbsee> seb128: (it's not mine)
<Hobbsee> seb128: looks to be outdated.
<Hobbsee> seb128: but the update manager is broken, and he's on a live cd.
<seb128> k
<Hobbsee> seb128: mvo sorry, i thought he'd be a *little* more helpful
<mvo> Hobbsee: no problem
<seb128> that's alright
<Hobbsee> this is *precisely* why we should break X for about a week, during development
<auTONYmous> I'm getting a problem with update-manager 0.59.2 debs
<auTONYmous> oops...I mean update-notifier
<auTONYmous> If anyone wants to look at the errors from apt: http://www.pastebin.org/632
<Hobbsee> auTONYmous: https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/132941
<ubotu> Launchpad bug 132941 in update-notifier "Package 0.59.2 broken" [High,New] 
<auTONYmous> hobbsee: thanks, I was looking for a bug reported for that
<StevenK> And 0.59.3 was uploaded ~ 25 minutes ago
<tkamppeter> kagou, no, but there are some new things which I can package.
<loswillios> hi
<kagou> ok tkamppeter
<loswillios> How can I trigger a manual build of linux-restricted-modules?
<loswillios> the nvidia.ko module from nvidia-glx/linux-restricted-modules-2.6.22 wasn't shipped
<loswillios> so I figured I have to compile /lib/linux-restricted-modules/2.6.22-9/nvidia myself, somehow
<auTONYmous> okay, second problem: can someone answer why my system doesn't reboot properly using Ubuntu kernels?
<kagou> tkamppeter, big improvements have been made on s-c-p since 1 month :)
<tkamppeter> kagou, everything except today changes are already in our package, don forget to do you daily update on your Gutsy.
<kagou> tkamppeter, yes i know, i was just curious to  test today change in cvs (auto detection of non text ppd)
<kagou> i'm downloading cvs to make tests
<jetscreamer> m-a a-i nvidia ?
<iwj> Yay.  Serial update-initramfs should now be a thing of the past (well, when everything finally bubbles through).
<Amaranth> woohoo
<Amaranth> no more HD churning initramfs generation 5 times in one apt run
<iwj> Most people will have one more time when that happens, since you only get the new behaviour if the upgrade is running with the new dpkg.
<Keybuk> iwj: talk to mvo about upgrade pre-requisites
<iwj> Keybuk: Yes.
<iwj> Nothing goes wrong if dpkg is done later - you just don't get the benefit.
<mvo> iwj: we could use it as a test-case for the pre-requists, the code is ready, then we know that it works for the next lts
<mvo> iwj: but lets talk about it tomorrow, today I'm pretty packed with $stuff
<mvo> iwj: great work on the triggers btw, a wonderful feature :)
<iwj> mvo: Sure.
<iwj> Don't thank me until you've not had your status file eaten :-).
<elmo> iwj: can triggers be used to batch ldconfig?
<iwj> elmo: I think so yes, although I'm not sure how broken the system is between unpack and ldconfig run.
<elmo> iwj: neato
<tkamppeter> kagou, I have now packaged the current SVN state:
<tkamppeter> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/system-config-printer/
<kagou> tkamppeter,  oh ?! Nice. Do you want that i test it ?
<kagou> tkamppeter, wow s-c-p new gui/wizard is far better.
<kagou> tkamppeter, but we have a regretion. Media default size for paper size do not use local preferences (Letter instead of A4)
<kagou> tkamppeter, both in automatic or manual printer addition
<geser> Riddell: re bug #130640: have you an idea what to do with pbuilder-uml which has currently an unmet dep on rootstrap? should it be dropped then?
<ubotu> Launchpad bug 130640 in rootstrap "Please sync rootstrap (universe) from Debian unstable (main)" [Undecided,Invalid]  https://launchpad.net/bugs/130640
<tkamppeter> kagou, can you do a bug report on Launchpad because of the Letter/A4 problem? Tim will then see this and fix it.
<Riddell> geser: you'd need to ask the linux team to remove the black list (#ubuntu-kernel)
<slomo> doko: because upstream is insane and wants to use private cairo api... this is fixed with 1.2.5, it can be built against an external cairo then
<geser> Riddell: ok
<kagou> tkamppeter, i think that i should wait for your uprade of s-c-p before
<kagou> no ?!
<Chipzz> seb128: what should be the correct (filesystem) location for .devhelp files?
<Chipzz> /usr/share/gtk-doc/html/$package/ or /usr/share/doc/$package/html/ ?
<tormod> kylem, any chance you can look at the debdiff in bug #114793 ? I am getting a little impatient :)
<ubotu> Launchpad bug 114793 in linux-wlan-ng "linux-wlan-ng fails compilation" [Undecided,Confirmed]  https://launchpad.net/bugs/114793
<kylem> yeah
<seb128> Riddell: could you have a look at bug #132941?
<ubotu> Launchpad bug 132941 in update-notifier "Package 0.59.2 broken" [High,Confirmed]  https://launchpad.net/bugs/132941
<Riddell> seb128: fixed in 0.59.3
<seb128> Riddell: read the comments please
<xhaker> pygi, poke
<\sh> did anyone fixde the update-notifier-common package?
<Riddell> doh
<seb128> \sh: read what I just wrote to Riddell
<\sh> seb128, yepp...just saw it now
<seb128> Riddell: could you fix it before we get a zillion of dups? ;)
<kylem> tormod, it looks ok.
<Mithrandir> mvo: apt ftbfs
<mvo> Mithrandir: on lpia?
<Mithrandir> mvo: in general
<Mithrandir> http://launchpadlibrarian.net/8846083/buildlog_ubuntu-gutsy-i386.apt_0.7.6ubuntu6_FAILEDTOBUILD.txt.gz
<seb128> Mithrandir: you might want to tell to iwj, he did the dpkg-trigger upload
<Mithrandir> indeed.
<Mithrandir> iwj: apt FTBFS with your latest upload.  Any chance you could unbreak it?
<Riddell> seb128: done
<seb128> Riddell: thanks
<mvo> iwj: did you commit your upload into some sort of vcs? or could you give me a debdiff so that I can keep the bzr apt repository into sync again?
<mvo> iwj: aha, it looks like the repo is in sync, thanks for that
<Mithrandir> mvo: can you just fix it, then? :-)
<mvo> Mithrandir: yes
<Mithrandir> that'd be wonderful
<evand> Can someone sponsor a Ubiquity upload before FF at 20:00?: http://people.ubuntu.com/~evand/upload/ubiquity_1.5.9_source.changes
<iwj> Mithrandir: Yes.
<iwj> mvo: I pushed to the repo.
<iwj> It built for me obviously.
<iwj> Mithrandir: Will fix now.
<mvo> iwj: yes, thanks for that, I'm uploading a new version now, that should fix the ftbfs
<mvo> iwj: no need, its taken care of
<iwj> mvo: Oh, that was quick!
<iwj> Thanks.
<iwj> I should have run automake && autoconf in the tree before checkin/upload ?
<iwj> (at a guess from the log)
<mvo> iwj: yes, I have a debian/rules arch-build rule for this
<mvo> ok, need to run, I will be back for the meeting
<doko> seb128: is this strict dependency really needed? libglib2.0-data depends on libglib2.0-0 (>= 2.13.7-1ubuntu5)
<doko> breaks slow buildds
<xhaker> doko, i couldn't get in contact with man_di to talk about packaging eclipse 3.3, could you merge the remaining changes from debian then?
<doko> xhaker: sorry, no time. please do it yourself
<\sh> gosh...dpkg is broken too
<Mithrandir> \sh: no, it's not.
<\sh> The following packages have unmet dependencies:
<\sh>   dpkg: Breaks: apt (< 0.7.6ubuntu6) but 0.7.6ubuntu4 is installed
<\sh>         Breaks: aptitude (< 0.4.6.1-1ubuntu2) but 0.4.6.1-1ubuntu1 is installed
<\sh> Mithrandir, or yxou fixed it already ;)
<iwj> apt was FTBFS (my fault) and aptitude build-deps on the new apt.
<iwj> So you just have to wait for the new apt to be built by the buildds.
<iwj> Although it's a bug in (the old) apt that it let it get into this state.
<\sh> Mithrandir, ok it's not dpkg ;)
<iwj> It ought to have held back the new dpkg.
<Mithrandir> \sh: the archive being inconsistent isn't a bug in dpkg.
<iwj> \sh: Or are you saying apt is saying it doesn't want to install the new dpkg because of this dependency ?
<iwj> In which case that's exactly what it's supposed to do.
<\sh> iwj, the problem is I want a pbuilder chroot and debootstrap failes because of installing dpkg because of broken apt deps..anyway..dinner...wife is calling
<iwj> OIC.  Well, that happens.  It's a development distro :-).  It'll be fixed soon.
<ion_> dpkg doesnt seem to have the Vcs-Bzr field. :-(
<\sh> iwj, but the main cause is: I want to try to fix eclipse not finding any installed sun jre6
<seb128> doko: why is -data installed on the buildd?
<doko> seb128: the indep package is already available, the arch package not.
<seb128> doko: right, but libglib2.0-0 only Recommends -data, why is this one installed?
<seb128> doko: -data should not be required nor installed on a buildd
<doko> because recommends can be installed by default?
<seb128> are the buildds doing that now?
<doko> seb128: anyway, why the overtight dependency?
<seb128> it's a bug
<seb128> and I'll fix it
<seb128> I'm just curious to know why -data is installed ;)
<doko> seb128: ok, thanks
<seb128> are Recommends installed on buildds?
<doko> seb128: to be more concise: breaks my installations where the buildd's are too slow
<seb128> ah, k
<doko> seb128: another thing: where's the pyspi project home?
<seb128> dunno, I think dholbach has uploaded it
<doko> iwj: when you submit your autotest reports for main, on a supported architecture, please could you set the priority to high, and the milestone to a tribe/beta?
<iwj> Can I do that in the email I use to submit the bug report ?
<doko> don't know
<iwj> If so then yes.  If not then no :-).
<iwj> I'll look into it.
* iwj mails himself as a reminder.
<ion_> PEBKAC probably, but i cant find the VCS branch for dpkg.
<iwj> ion_: What VCS branch ?
<ion_> Any branch that the dpkg-triggers functionality has been pushed to. :-)
<iwj> It hasn't.  Are you on debian-dpkg ?
<ion_> Nope.
<iwj> Playing with the dpkg git is on my todolist for tomorrow.
<ion_> Ok
<iwj> If you're desperate, look at the dpkg in the archive and diff it against what was in the archive err yesterday ish.
<iwj> (See changelog)
<ion_> Hehe, thats what i was just about to do. :-P
<ion_> Not really desperate, but id like to look at the code for fun.
<wasabi> man i am about tired of lvm/md bugs
<wasabi> just expierenced a feisty system wher elvm.conf wasn't copied to the initramfs... and somehow md detection wasn't working.
<wasabi> So it built the vg's with the md components.
<\sh> doko, ping eclipse, it's not eclipse it's somehow that the sun-java6-jre is not setting it's JAVA_HOME in /etc/jvm
<asac> calc: did i give you the .ko file?
<calc> asac: nope, not yet
<asac> calc: http://people.ubuntu.com/~asac/ipw3945.ko
<asac> calc: please keep a backup of the old one :) ... and be prepared that things will break ;)
<calc> asac: ok
<calc> asac: should i try this with the live cd version?
<calc> asac: regular up to date gutsy seems to mostly work (for whatever reason)
<asac> first try with your current (working) setup ... to see if it works at all
<asac> if it does then try livecd i guess
<calc> asac: also note that keybuk has similar issues with ipw3945 as well
<calc> asac: ok
<calc> ok i'll see how it does on my installed version, brb
<tormod> kylem, thanks. Will you upload it?
<kylem> i can, yes.
<tormod> kylem, great, thanks a lot!
<pef> hello
<xhaker_> anyone with time to sponsor a libmtp upload?
<pygi> xhaker_, didn't we upload that already? :)
<xhaker_> pygi, bug #132853
<ubotu> Launchpad bug 132853 in libmtp "[needs review]  libmtp 0.2.1 udev rules file fix [needs upload] " [Undecided,New]  https://launchpad.net/bugs/132853
<xhaker_> seems the rules section where the perl foo is runs two times! :D fixed it with a better regex
<xhaker_> small debdiff
<pygi> xhaker_, it'll be uploaded, no worries :)
<xhaker_> I'm looking into eclipse right now
<pygi> xhaker_, good catch btw ;)
<xhaker_> pygi, thanks :)
<pygi> would be good if we noticed that before initial upload, but oh well :P
<xhaker_> I had no idea the rule would run two times.(
<pygi> oh well =)
<xhaker_> pygi, i've seen some upload requests bearing only a debdiff, is that "cool" to do?
<pygi> xhaker_, for debdiff as small as yours it would be fine, otherwise not really :)
<calc> asac: fails invalid module format
<asac> which kernel/modules package?
<calc> ii  linux-image-2.6.22-9-generic               2.6.22-9.25                          Linux kernel image for version 2.6.22 on x86
<rgl> OT: which tools do you guys use to capture a video on the desktop?  like, doing a screen cast.
<calc> and after trying to revert to original driver NM couldn't associate any more so i disabled NM and used ifup which worked perfectly as expected
<tormod> rgl, https://wiki.ubuntu.com/CreatingScreencasts ?
<rgl> tormod, funny just found it too.  thx :)
<pygi> asac, if you're here (and I dont know if you are) read what I told you in motu, and I'm after swfdec now
<asac> pygi: i will answer ... let me eat ;)
<pygi> asac, fine, bon appetit :P
<\sh> doko, when you are awake (tomorrow ;)) without JAVA_HOME set to the jre home, eclipse wont start...and seeing that nothing set /etc/jvm/ configuration this could be the fault...I don't know how to fix that, damn
<xhaker_> \sh, eclipse? what are you doing?
<\sh> xhaker_, finding the error why eclipse doesn't like our sun-java-6
<\sh> xhaker_, it tests against /usr/lib/jvm/java-1.5.0-sun but not against /usr/lib/jvm/java-6-sun
<\sh> and can't start because of that...so setting JAVA_HOME is the temp bugfix for now
<xhaker_> \sh, i was doing a merge/sync with debian
<\sh> xhaker_, cool...when this fix this issue with java 6 ;)
<superm1> mvo, ping.  i had a quick question about python-apt
<xhaker_> \sh, i'll show my "fake" debdiff
<mvo> hey superm1! sure, fire
<superm1> mvo, when marking a page to be installed via markInstall, it's also marking the "Recommends"
<superm1> is there a way to change this behavior?
<superm1> *page = package :)
<mvo> superm1: use can use "apt_pkg.Config.Set("APT::Install-Recommends","0") in your script
<xhaker_> \sh, http://pastebin.com/m50ac206 i don't know if this is the right way to do it..
<superm1> mvo, okay sweet, thanks
<desertc> Hello - Under what Ubuntu package catagory would Intel's open source drivers fall for their 3D graphic chipsets?
<mvo> cheers superm1
<mr_pouit> seb128: are you working on gcalctool, or can I fix the desktop file to show in xfce as well?
<desertc> I am curious to watch the development and integration of this initiative.
<xhaker_> \sh, take in mind the debdiff is fake because pbuilder is acting up :) waiting for apt
<tormod> desertc: xserver-xorg-video-intel ?
<desertc> tormod: Thank you.
<\sh> xhaker_, apt is there :)
<seb128> mr_pouit: what change is that?
<seb128> mr_pouit: bug number?
<\sh> xhaker_, dpkg is held back
<\sh> xhaker_, but looks fine with the debian/extra/java_home add
<xhaker_> \sh, what about the changelog entry? i don't know if i should have put ubuntu in the version or not
<mr_pouit> seb128:
<mr_pouit> +-OnlyShowIn=GNOME;
<mr_pouit> ++OnlyShowIn=GNOME;XFCE;
<\sh> xhaker_, yepp...you have to put ubuntu in the version because of the change of java_home
<wasabi> hmm. udevd question. How do I disable a rule temporarily?
<wasabi> is moving the file out of the way good enough?
<seb128> mr_pouit: could you sent the change on bugzilla?
<\sh> ok..time to stop for today
<\sh> good night everybody
<mr_pouit> seb128: ok, no problem, I'll forward it
<seb128> mr_pouit: feel free to patch the package (and update to the new version), we try to send distro changes upstream though
<Nergar> hello
<Nergar> i have a question
<Nergar> why was gparted removed from the installation wizard?
<sistpoty> cjwatson_: mind to give some feedback about evand's application for motu? (preferrable to the MC list ;)
<Mithrandir> sistpoty: cjwatson is on vac, so don't expect a quick answer
<sistpoty> Mithrandir: ah, k thanks... how long is he on vac?
<Mithrandir> this week, iirc
<sistpoty> k, thx!
<cypherbios> mvo: I just reuploaded the new files, could you sponsor that upload?
<mvo> cypherbios: yes, if that is still possible (not sure about universe freeze etc)
<cypherbios> mvo: yeah, I know. I'm afraid it's a little too late for the automatic upload, perhaps some manual intervention may be required
<mvo> cypherbios: I will try to figure out the status in #ubuntu-motu, if nothing is done, please just nag me about it again tomorrow, its rather late here already
<sistpoty> mvo, cypherbios: iirc we're in UVF for universe, so you'd need a UVFe for new upstream versions. everything else can go through imo
<superm1> mvo, using this as an example, that still appears to not be working. http://paste.ubuntu-nl.org/33987/  .  Does it need to be done differently when I use apt rather than apt_pkg's .Cache ?
<superm1> mvo, in that example, mythweb is getting marked (as its a Recommend for mythtv-backend-master)
<sistpoty> superm1: sorry again for the delay with your application for motu :/
<marek> Geert, senneth, exg ping.
<superm1> sistpoty, no biggie, especially if its a +1 you eventually give :)
<sistpoty> superm1: s/give/gave ;)
* superm1 needs to check his email more often apparently :)
<sistpoty> hehe
<cypherbios> mvo: OK, I'll be waiting for this. just to note, it's very important (for the program's users) having this version in gutsy, as it fixes a lot of bugs since the feisty's version
<cypherbios> thanks
<seb128> does anybody know if that's possible to direct one canal from an audio input to stereo output using alsa and how?
<mvo> superm1: I think the issue because its in Section: multiverse/metapackages, let me dig for a workaround
<superm1> oh i had heard from LongPointyStick  that metapackages in main automatically set recommends to be installed, but it didn't happen in universe/multiverse
<wasabi> lastlog and faillog are silly files
<mvo> superm1: it does now
<superm1> mvo, likely because ubuntu studio was needing their metas to do that?
<mvo> superm1: we got bugreports that it does not work :)
<wasabi> anyway to make cp skip the file it's working on? blah.
<mvo> superm1: I think it should be enough to disable the install-recommends-sections
<superm1> mvo, so are there more sections then that would need it done too (Other than the one APT::Install-Recommends you mentioned)?
<superm1> oh you mean APT::Install-Recommends-Sections
<wasabi> wonder how long it takes my systme to chew through 700GB of zeros.
<sistpoty> seb128: imo it's possible, and iirc I dunnit once, let me dig for some references...
<seb128> sistpoty: thanks
<mvo> superm1: yes, I need to lookup the exact synatax, but its basicly overwriting apt::install-recommends-sections
<alex-weej> mvo: n-d? :)
<mvo> alex-weej: *cough*
<alex-weej> mvo: i can put a note on launchpad if you want
<mvo> alex-weej: please do that
<alex-weej> mvo: changed back to In Progress
<mvo> alex-weej: thanks, what was the bugnumber again?
<alex-weej> 132512
<sistpoty> seb128: sorry, seems like it all changed since I tried it, but maybe http://alsa.opensrc.org/index.php/Playing_stereo_on_surround_sound_setup_%28Howto%29 may give some hints
<mvo> alex-weej: strnage, when i download http://launchpadlibrarian.net/8822330/01_ubuntu_theme.patch and debdiff it against -ubuntu6 I see no changes
<seb128> sistpoty: no problem, thank you for the url
<sistpoty> np
<alex-weej> mvo: it's a drop in replacement 01_ubuntu_theme.patch
<alex-weej> you probably want to diff the diffs :P
<mvo> debdiff should give me that
<mvo> in theory :)
<alex-weej> mvo: if you want the changes in some other form just tell me how to get them and i'll do it for you
<alex-weej> i'm pretty clueless with debian packages
<mvo> alex-weej: is there a notify-send thing that I can use to see if the patch works?
<mvo> or a small python test script
<mvo> I have to admit that I'm puzzled currently
<alex-weej> mvo: i tried myself, not that i know of. i was signing on to my GMail account to test the Gossip notifications :/
<alex-weej> mvo: when i do an apt-get source notification-daemon, the patch isn't changed
<mvo> ok, and I assume you did restart notification-daemon before the test :) ?
<alex-weej> the entry in the changelog is
<alex-weej> mvo: killall in postinst :P
<Riddell> evand: any more ubiquity uploads likely before tribe?
<evand> Riddell: probably.  I'm fixing one that was done earlier today, and then we'll have at least one more as there's a bug in LanguageSetupApply
<evand> Riddell: If you'd like I can keep you posted on the status
<Riddell> so long as its in before the end of monday it'll be fine
<evand> ok
<mvo> alex-weej: *cough* my bad *cough* I uploaded a new version and its hopefully fixed with this. thanks again for the patch
* mvo goes to bed now
<alex-weej> why wasn't debdiff working?
<alex-weej> lol ok, goodnight...! :P
<doko> Riddell: any idea how to pass compiler options to sip? All documented stuff like passing CXXFLAGS= to the configury doesn't work
<Riddell> not really, sip is a mystery to me
<Mez> I thought you were on about the protocol then
<superm1> regarding the issue i was trying to track down with mvo, it appears that I need to override /etc/apt/apt.conf.d/01ubuntu's items, does anyone know how is this done (without editting the file)?
<sistpoty> gn8 everyone
<Keybuk> superm1: what's wrong with editing the file?
<Keybuk> it's in /etc for a reason!
<superm1> Keybuk, it's for an app that will be installing things
<superm1> but i dont want to change the rest of the system's behavior
<superm1> just when things will be installed within this app
<superm1> so i guess i could just edit it temporarily....
<superm1> i was hoping there was just an 'Unset' method similar to the Set method that can be used normally :)
<doko> Riddell: the problem is that we need to further split the generated c++ files, or lower the optimization to -O1. known deficiency with gcc versions >= 4.2. but the generated sip code is sick as well ...
<tck> any word one when the landscape client beta will be released?
<ogra> doko, ping
<ogra> doko, oh, unping i see the nbd failure was fixed already
#ubuntu-devel 2007-08-17
<Keybuk> http://www.flickr.com/photo_zoom.gne?id=1137422377&context=set-72157601482712397&size=o
<Keybuk> ^ I like that pic; and I've flown three of them so far :)
<ogra> at the same time ? :P
<Keybuk> no :)
<ogra> :)
<ogra> nice :)
<Keybuk> flown Tango Oscar (the orange one at the back), and Victor Victor & Victor November (two of the tree at the front)
<sladen> Keybuk: when you've collected all seven, you can move on to borrowing mark's
<Keybuk> sladen: no, I *really* can't :p
<Keybuk> I dread to think the amount of training needed to fly a Global
<ogra> cant marks polit train you during business flights ? you just need to change your name to "claire" and become PA :)
<ogra> *pilot
<sladen> could have learnt the preflight by heart if you'd been paying attention next to the pool in Sevilla
<ogra> heh
<Keybuk> ogra: not sure, I think for jets you need certain numbers of hours and ratings, not to mention simulator hours, until you're even allowed to sit in the seat
<Keybuk> sladen: I know the pre-flight checks for a Robin HR-200 pretty well :p
<Keybuk> bit of a different class though
<sladen> and even then it doesn't stop you stepping on the wrong pedal ;)
<Keybuk> http://www.airliners.net/open.file?id=1078886&WxsIERv=Ebova%20UE-200-120O&Wm=0&WdsYXMg=Jryyrfobhear%20Nivngvba&QtODMg=Jryyrfobhear%20Zbhagsbeq%20%28RTOJ%29&ERDLTkt=HX%20-%20Ratynaq&ktODMp=Whar%203%2C%202006&BP=1&WNEb25u=Wvz%20Tebbz&xsIERvdWdsY=T-JNIA&MgTUQtODMgKE=Cerivbhfyl%20ertvfgrerq%20T-IRPN.&YXMgTUQtODMgKERD=735&NEb25uZWxs=2006-07-20%2012%3A38%3A27&ODJ9dvCE=&O89Dcjdg=344&static=yes&width=1024&height=695&sok=JURER%20%20%28ert%20%3D%2
<Keybuk> 0%27T-JNIA%27%29%20%20BEQRE%20OL%20cubgb_vq%20QRFP&photo_nr=1&prev_id=&next_id=0840691
<Keybuk> (ouch, URL!)
<Keybuk> and you know what
<Keybuk> you can cut it all out
<Keybuk> http://www.airliners.net/open.file?id=1078886 vs. http://www.airliners.net/open.file?id=1221850
<ogra> you even got a pilot cap :)
<Keybuk> lol, that's not me :)
<ogra> heh
<Keybuk> it is my favourite plane though
<Keybuk> it's slightly more responsive than the other three allegedly identical ones :p
<sladen> I find this when dating triplets
* Keybuk chokes
* mneptok wants one of the remanufactured Grumman Geese
<doko> bryce: please could you check if gcc-3.4 is really needed on lpia?
<doko> mesa ...
<Keybuk> mneptok: but can you fly it?
<ogra> Keybuk, worst case you can drive it with a paddle on the next sea :)
<mneptok> Keybuk: dunno. never sanded on water on purpose >:)
<mneptok> *landed
<Keybuk> "Fly, yes ... Land, no!"
<mneptok> Keybuk: http://www.antillesseaplanes.com/
<ogra> no pricelist
<mneptok> if you have to ask ... yadda yadda
<dobey> heh
<Keybuk> $2,200,000 for the turbine model
<Keybuk> $1,300,000 for the piston
<dobey> 2.2's not too bad
<dobey> totally worth the extra mil
<Keybuk> "Whilst it is theoretically possible to complete a course of PPL training on a MEP aeroplane the candidate is required to have 70 hours flight time as pilot in command (PIC) of aeroplanes before making licence application. It is therefore assumed that the applicant for a MEP class rating will be in possession of at least a valid PPL (A) and have 70 hours experience as PIC before commencing the course. There are no planned solo exercises
<Keybuk> on the course."
<Keybuk> spoil sports
<ogra> well, 70h arent to much
<ogra> anyway, bedtime ....
<keescook> iwj: still here?  I saw the "trigger activated" stuff, but it never ran in the end...
<keescook> is this perhaps because the running dpkg was old?
<keescook> Riddell: kdesudo was broken out of kdebase-core ?
<killown> how do I to set flags optimization gcc in apt-build sources packages?
<killown> I want to build with it flags : -O3 -march=prescott -mmmx -msse -msse2 -msse3 -mfpmath=sse -fomit-frame-pointer -pipe
<killown> debian/rules  file here >> http://rafb.net/p/hKbKd144.html
<sladen> killown: I think you also need  -fomg-faster
<killown> sladen, ?
<RAOF> -funroll-loops :)
<ion_> Better use -O999
<ion_> It might not get optimized enough otherwise.
<killown> 
<RAOF> killown: To answer your actual question, misugided as we think it is, you'd be after setting (or appending) to CFLAGS
<sladen> killown: /etc/apt/apt-build.conf
<killown> sladen, make_options="" or options="" to set flags >> -O3 -march=prescott -mmmx -msse -msse2 -msse3 -mfpmath=sse -fomit-frame-pointer -pipe ??
<wasabi> hmm. there a way to convince the installer to install to a hard coded device name without having to select it from a list? It can't recognize my non-MBR partitions. =)
<wasabi> Oh there it goes.
<wasabi> haha, error informing the kernel about modifications to the device md0p1    that's scarey.
<Seq> has anybody noticed increased temperatures on laptops while trying gutsy? I'm just trying to determine if I should file a bug or whether it's just my system
<ion_> If anything, it should decrease, thanks to dynticks etc. :-)
<Seq> ion_: i know, which is why i decided to try it out
<ion_> Anything spurious in tops listing?
<Seq> i have a macbook, so it was always fairly warm, but it gets rather hot under gutsy, and the fan seems to always be going now as well
<Seq> ion_: no, and both cores are scaling properly. powertop seems to be saying my power useage is around 17W (depending on brightness) and it shoots up under load, so I'm assuming it is not that
<fabbione> Seq: best would be to grab a dmesg from both feisty and gutsy and see if there is any relevant difference
<fabbione> perhaps it's just a bug in the kernel
<Seq> fabbione: thats possible. I was also curious if it could be the new intel driver vs the i810 one, as the graphics could use a fair chunk of power
<Seq> also, I'm not using compiz as I'm assuming that could make a difference
<fabbione> Seq: it's worth starting from the bottom.. check dmesg to see if there is a diff first.. then try to revert the gfx driver and proceed one step at a time
<Seq> I have an error loading DSDT from initramfs. Is that only used when loading a custom DSDT?
<Seq> is there a way to check if the hard disk spins down correctly?
<shirish> sorry to disturb you folks, but anybody knows what should i install to get wxwidgets2.8.4 in gutsy?
<darius> evening all
<darius> anyone have a few mins to let me pick their brains about the package installer and ubuntu package development
<dariuskane> anyone awake?
<dariuskane> anyone awake? have a few package questions Im hoping to find a few answers for
<mdke> who's in charge of the certification courses?
<Riddell> keescook: kdesudo is a separare programme that has never touched kdebase
<Hobbsee> hi Riddell
<fabbione> doko_: ping?
<doko_> fabbione: pong
<fabbione> doko_: hey.. i have a couple of questions for you...
<fabbione> doko: did you get my email about glibc?
<doko> yes
<fabbione> doko: do you have an ETA for it to hit gutsy?
<fabbione> feisty will take longer and we know
<doko> with the next upload
<fabbione> ok cool thanks
<fabbione> next thing is about gcc-4.2 on sparc.. david is hunting down that bug that miscompiles the kernel
<fabbione> expect a patch soonish
<fabbione> even if it's not critical for gutsy it would be good to have it ready so that we can do more testing on the compiler before gutsy+1 opens
<doko> yes, that would be nice. does this one have an upstream pr`
<doko> ?
<fabbione> doko: not sure.. but davem is on it... that's enough for me
<fabbione> doko: he says that it might be also a kernel bug.. but he just started looking into it
<Mithrandir> seb128: is it intentionally that gstreamer0.10-plugins-base-dbg depends on gstreamer0.10-gnomevfs, while gstreamer0.10-plugins-base doesn't depend on the gnomevfs one?
<seb128> Mithrandir: yes, the binaries are splitted but not the dbg
<seb128> Mithrandir: so the dbg depends on all the binaries
<Mithrandir> seb128: ugh. :-/
<seb128> Mithrandir: install the -dbgsym and ignore the -dbg ;)
<seb128> those are splitted
<Mithrandir> seb128: until we have the debug symbols in Ubuntu itself, no.  I'm working on the mobile-dev seed
<seb128> ok
<Mithrandir> I'll just exclude the gstreamer debug symbols for now
<seb128> do you need -dbg packages in -dev? can't you use apport and retrace?
<Mithrandir> I'd like to have them there by default, since it's helpful for having a good development environment.
<seb128> ok
<Chipzz> hi, a little question (I looked this up in the debian policy but found nothing relevant): is the devel section used for development files of applications, or rather for development tools?
<Riddell> both
<Riddell> see gcc for example
<Chipzz> for example:
<Chipzz> devel/epiphany-browser-dev
<Chipzz> devel/gedit-dev
<Chipzz> devel/glabels-dev
<Chipzz> should these be in devel or in libdevel ?
<doko> mvo: bug 70420 seems to be another one with the wrong pickling behaviour, which is fixed now. just close it?
<ubotu> Launchpad bug 70420 in python2.4 "crash while loading Anwendungen-"Hinzufuegen/Entfernen" dialoge" [Undecided,New]  https://launchpad.net/bugs/70420
<mvo> doko: yeah, I think so
<Riddell> the tribe 4 freeze announcement talks about https://wiki.ubuntu.com/PackageInconsistencies but that seems like just a redirect page, what was on it?
<Riddell> ah, found it
<iwj> keescook: That's not supposed to happen.  It may be a bug.  What exactly were you doing ?
<Riddell> anyone able to read this over for sanity?  http://paste.ubuntu-nl.org/34042/
<mvo> Riddell: looks ok to me
<Riddell> thanks
<Ng> don't suppose anyone is using compiz with -intel on an 855GM?
<Riddell> Mithrandir: ubuntu-devel-announce post for moderation
<Mithrandir> Riddell: approved
<Riddell> thanks
<Riddell> ubuntu daily alternate amd64 oversized, there's no language packs on it, what should be removed?
<Riddell> language-support-en maybe
<seb128> does anybody know how to redirect an input canal to a stereo output using alsa (the source is mono)?
<fabbione> seb128: afaik mplayer can do that, but i don't recall the optiosn
* Fujitsu wonders why trackerd isn't respecting SIGTERm
<seb128> fabbione: well, that's not to play a media file, that's to have the sound of a guitar directed correctly in stereo
<fabbione> seb128: ok, but you can look how mplayer code does it :)))
<tsmithe> seb128, gotta run, but what about using the "route" plugin in asoundrc?
<seb128> tsmithe: I don't about it, thanks for the hint, I'll have a look
<tsmithe> no probs :)
<tkamppeter> hi doko
<doko> tkamppeter: hi
<tkamppeter> doko, did you get my two mails yesterday, about new system-config-printer and cupsys packages?
<tkamppeter> Can you upload these packages for me?
<doko> hmm, is pitti offline?
<Mithrandir> doko: I hope so.  He's getting married.
<doko> today?
<tkamppeter> pitti is currently really offline, according to my xchat.
<Mithrandir> doko: ttbomk, yes.
<Hobbsee> Mithrandir: you mean he *didnt* take his laptop into the church????
<tkamppeter> Perhaps they do not have WLAN there.
<\sh> or his wife told him: Laptop or Marriage...you decide
<Riddell> Mithrandir: further ubuntu-devel-announce post for moderation
<asac> crimsun: hey ... do you have any idea what happened to the "accept license" in flashplugin-nonfree?
<asac> crimsun: i remember that it was displayed by the debian package once ... but it apparently doesn't do this anymore
<Mithrandir> Riddell: approved
<Riddell> thanks
<Riddell> evand: on today's kubuntu live CD, ubiquity won't let me past the language page, the cursor remains as the busy cursor and the next button isn't enabled
<iwj> Riddell: I've dealt with those MIRs you asked about.  Two are approved; one is ftbfs for me; one I have some questions about.
<Riddell> iwj: ok, thanks, I'll have the kvkbd packager look at that fail and the kdebluetooth packager look at your obexftp question (or maybe Mithrandir can answer it, I seem to remember he's involved with bluez)
<iwj> Riddell: Right.  I hope that's helpful.
<iwj> Let me know if you want me to look again, etc.
<iwj> Riddell: FYI, re the Tribe 5 freeze, there's a bug report about triggers from Kees which may or may not be an actual bug.  He mentioned it to me on IRC last night.
<iwj> If it's true I'll probably fix it but I trust that can be done later today or early next week ?
<Riddell> iwj: got a bug number?
<iwj> No.
<Riddell> iwj: sure, freeze isn't until tuesday
<iwj> Just a one-line irc comment as yet :-).
<iwj> Right, thanks.
<StevenK> Hrm. Who's archive day is it?
<pygi> StevenK, you're motu-uvf member, right? ^_^
<StevenK> Let me deny everything.
<pygi> StevenK, o com'on!
<StevenK> pygi: Hrm? What's up?
<pygi> StevenK, just a little review & exception approval & upload =)
<pygi> bug #133052
<ubotu> Launchpad bug 133052 in swfdec0.4 "[needs review]  swfdec0.5.1 [needs upload] " [Undecided,New]  https://launchpad.net/bugs/133052
<Riddell> StevenK: the archive manager for today is in church all day
<StevenK> Ah. pitti. Weddings don't take all day. :-)
<Riddell> he'll be busy consumating afterwards, I can take archive requests if you have something that needs done
<zul> StevenK: yes but the nervousness and going what am i getting myself into does ;)
<StevenK> Riddell: I doubt that. I got married two years ago. All you do after is collapse and sleep. :-)
<StevenK> Riddell: I'm working on NBS stuff - Are you able to NBS out gaphor-lib and libgig3c2, and push libmtp through NEW?
<StevenK> Riddell: After libmtp gets published, then I'll upload a rebuild only of amarok, rhythmbox and gnomad2.
<pygi> StevenK, 1)isn't libmtp already published (?) and can we pretty please get this fix in?
<pygi> https://bugs.launchpad.net/ubuntu/+source/libmtp/+bug/132853
<ubotu> Launchpad bug 132853 in libmtp "[needs review]  libmtp 0.2.1 udev rules file fix [needs upload] " [Undecided,New] 
<Riddell> I've not done deleting packages before, it may not be a good time for me to start
<Riddell> iwj: what was your kvkbd build failure?  it builds fine in a pbuilder for me
<StevenK> Riddell: That's okay.
<Hobbsee> Riddell: live on the edge a little :P
<StevenK> pygi: libmtp *source* is, the binaries aren't.
<pygi> StevenK, right :) And can we get that little fix in? ^^
<Riddell> StevenK: being in UVF as we are, is there a paticular reason for a new mtp version?
<pygi> Riddell, a lot of new hardware support
<StevenK> Riddell: And it was uploaded yesterday, before UVF
<Riddell> evand: ubiquity in ubuntu quietly died during the install part http://muse.19inch.net/~jr/tmp/debug
<pygi> two days ago actually =)
<Riddell> evand: and as mentioned, in kubuntu it breaks on the language page http://muse.19inch.net/~jr/tmp/debug-kubuntu
<Riddell> evand: also d-i says it can't install a kernel, does it need rebuilt?  the udeb list seems up to date to me
<StevenK> pygi: I can upload it for you, if you wish
<pygi> StevenK, that would rock, thanks =)
<Hobbsee> yay, StevenK can do all the sponsoring
<Riddell> StevenK: sneaky :)
<StevenK> Riddell: :-)
<pygi> StevenK, it's pretty important fix for libmtp package :)
<pygi> that swfdec is also important, but not as much as this fix
<StevenK> Hobbsee: Nuh uh, I'm doing it for NBS stuff
<Riddell> StevenK: accepted
<StevenK> Riddell: Thanks
<StevenK> Hrm. It shouldn't really change previous changelog entries, but it's correcting the day.
<StevenK> pygi: Correct the diffstat, it's useless
* pygi wonders what happened with diffstat
<StevenK>  swfdec0.5_0.5.1.orig.tar.gz |binary
<StevenK>  1 file changed+
<pygi> StevenK, ok, and in what way to correct it?
* pygi just tried again, got the same
<StevenK> diff'ing the two tarballs is pointless
<StevenK> Unpack both of them, diff -urNP <old> <new> | diffstat
<StevenK> And libmtp is uploaded
<pygi> StevenK, thanks, gonna diffstat now
<pygi> StevenK, done
<pygi> lunch now
<\sh> hmmm....under gnome, the window manager action "move to another workspace ->" and selecting e.g. workspace 3 doesn't work with compiz somehow, but moving the window from actual workspace to the left or right works
<\sh> or did i miss one plugin?
<evand> Riddell: tbh, I'm not sure yet.  I just noticed the bug yesterday when I was building the new version.  I'll let you know though.
<Riddell> evand: which bug?
<evand> crashing on install
<tkamppeter> riddell, biff
<Riddell> evand: and the other two bugs?
<Riddell> tkamppeter: pardon?
<pygi> back
<tkamppeter> Riddell, you perhaps do not know this expression of IRCish, it means that I have sent an e-mail to you.
<Riddell> maybe an expression from before my time :)
<Riddell> tkamppeter: I'll upload those for you now
<tkamppeter> Riddell, thanks.
<evand> Riddell: other two bugs?  I see you mentioned d-i not installing a kernel, that's new to me and I'll check it out.  Is there another bug?
<Riddell> evand: the kubuntu ubiquity one
<evand> ahhh, sorry, it's early.  I skimmed that and though it was the bug I mentioned yesterday.  That bug is my fault, I'll fix it today.
<Riddell> tkamppeter: for system-config-printer the version is 0.7.71+-svn1406-0ubuntu1 but your changelog says "Subversion snapshot r1399"
<Riddell> should that be r1406?
<tkamppeter> riddell, this is a cut-and-paste mistake in the ChangeLog, I have corrected that in the new package.
<Riddell> tkamppeter: ok, that and cupsys uploaded
<tkamppeter> Riddell, thank you
<tkamppeter> Anyone here is using an HP printer with HPLIP?
<Riddell> tkamppeter: yes (I think I do anyway)
<Mithrandir> no idea if I'm using hplip, but I have an HP printer, yes.
<Hobbsee> elmo: ping @ planet ubuntu stuff
<tkamppeter> Riddell, which version of HPLIP are you using (start the hp-toolbox from the command line and see the output in your terminal).
<elmo> Hobbsee: ?
<Hobbsee> elmo: is it accepable for planet to have the constant envy posts?
<tkamppeter> Mithrandir, do "lpstat -v" and your HP printer should show with a URI starting with "hp".
<Hobbsee> elmo: i would have thought it constituted as advertising, and if everyone did it, planet would flood.  see http://albertomilone.com/wordpress/?p=1115 and http://albertomilone.com/wordpress/?p=117 for more info
<Mithrandir> device for OfficeJet-Pro-K550: socket://skriver.local:9100
<Mithrandir> tkamppeter: ^^; so no.
<Mithrandir> it's ethernet-enabled, after all.
<Riddell> tkamppeter: HP Linux Imaging and Printing System (ver. 1.7.3)
<Riddell> HP Device Manager ver. 9.0
<Hobbsee> elmo: ( i was the developer who emailed him, obviously)
<elmo> Hobbsee: err, I don't know - who are you asking me as?
<Hobbsee> elmo: as one of the people who has a fairly good idea of what belongs on planet and doesnt, and as one of the debian planet people too.  also, as one of the people who was at the planet editorial policy specs.
<tkamppeter> Mithrandir, go to a box running a completely updated Gutsy (update if needed), start system-config-printer, choose "New Printer", choose an entry like "HP OfficeJet Pro K550 <IP> HPLIP" and create a new print queue with this one by doing the remaining steps of the wizard. Then try to print through this queue and also start the "hp-toolbox".
<Hobbsee> elmo: (ie, not as a canonical sysadmin)
<tkamppeter> Riddell, are you still on Feisty? Do you have access to a Gutsy box? Or at least to a Gutsy live CD?
<Mithrandir> tkamppeter: will that work when the printer is just on the network?
<elmo> Hobbsee: well
<Riddell> tkamppeter: this is on gutsy
<tkamppeter> Mithrandir, yes, and the best is HPLIP makes also all non-printing functions available on network-connected devices, like scanning, ink level readout, nozzle cleaning, download of pictures from memory cards, ...
<Hobbsee> elmo: i'm just of the opinion that it only relates to a subset of people, and that the same information can be conveyed using a repository, rather than posting to planet for every single deb update.
<tkamppeter> Riddell, you did not do your Debian morning gymnastics: sudo apt-get update; sudo apt-get dist-upgrade
<elmo> Hobbsee: I'd tend to agee with that, but
<Hobbsee> elmo: sure, advertising the fact that it exists is fine, from time to time, but showing the changelog for every update, and asking people to upgrade each time is....not planet content, i would ahve thought.
<Hobbsee> elmo: but?
<Mithrandir> tkamppeter: it doesn't list "HP officejet pro k550 $ip HPLIP", only the already set-up printer.
<elmo> Hobbsee: and I'm fine with an individual asking him to stop, but I'm not sure it's something (the threadbare) guidelines we have in any discourages
<Hobbsee> elmo: i guess i'm more asking "am i correct in asking him to stop, or am i out of line?"
<tkamppeter> Mithrandir, are you in the add-printer wizard? And are you sure that your system-config-printer is really up-to-date?
<elmo> Hobbsee: I think it's fine for you to do so
<Hobbsee> elmo: right.  and therefore others.
<elmo> sure
<Hobbsee> elmo: thanks
<Mithrandir> tkamppeter: seems to be up-to-date, yes.
<Mithrandir> ii  system-config-printer 0.7.71+-svn1406-0ubuntu1 printer configuration GUI
<Mithrandir> tkamppeter: I believe I am in the wizard - I click the "New printer" icon, it says "searching for printers" for a little while, then gives me http://err.no/tmp/Skjermdump-Ny%20skriver.png
<tkamppeter> Mithrandir, this looks strange for me. Can you do "hp-makeuri 10.0.0.184" and post the output here?
<Mithrandir> : tfheen@xoog ~ > hp-makeuri 10.0.0.184
<Mithrandir> error: HPMUDEXT could not be loaded. Please check HPLIP installation.
<tkamppeter> Mithrandir, this is bug 132670 Can you subscribe to the bug and fopllow the instructions in my postings there? Thanks.
<ubotu> Launchpad bug 132670 in hplip "[gutsy] hplip toolbox doesn't start" [Undecided,Incomplete]  https://launchpad.net/bugs/132670
<Mithrandir> tkamppeter: do you want the reports here or in the bug?
<Mithrandir> tkamppeter: anyway, done
<Riddell> tkamppeter: I now have "HP Linux Imaging and Printing System (ver. 2.7.7)" and it says "error: HPMUDEXT could not be loaded. Please check HPLIP installation." and fails to start
<Hobbsee> anyone got an opinion on https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/122039 ?
<ubotu> Launchpad bug 122039 in ubuntu-meta "[Gutsy]  unnecessary packages in ubuntu-desktop dependencies?" [Undecided,Confirmed] 
<tkamppeter> Mithrandir, thank you very much. Seems that some libraries are not found by HPLIP.
<Riddell> seb128: are you planning to do anything about bug 118745?  we have a script in guidance that runs on login for kubuntu that sets the DPI which you could use
<ubotu> Launchpad bug 118745 in libgnome "Font sizes in Gutsy are vulnerable to bad X.org DPI detection" [Medium,In progress]  https://launchpad.net/bugs/118745
<tkamppeter> Riddell, bug 132670, can you follow the instructions there?
<ubotu> Launchpad bug 132670 in hplip "[gutsy] hplip toolbox doesn't start" [Undecided,Incomplete]  https://launchpad.net/bugs/132670
<Mithrandir> tkamppeter: I'm off for the day, so if you need anything more, tell me and I'll see if I can oblige when I'm around again
<tkamppeter> Mithrandir, Riddell, anyone else, someone has an idea what is happening here (look into the strace log)?
<seb128> Riddell: I would like to get bryce opinion on this one, not sure why the dpi detection is so wrong and that looks like something that should be improve in xorg, not hacked around by some extra script
<Riddell> seb128: I suspect DPI detection is a fault of monitors as much as X
<seb128> what does the guidance script do?
<seb128> it does determine dpi by some way if it makes the situation better, why can't that be done by xorg itself rather?
<tkamppeter> Mithrandir, thanks for your log, this has helped me localizing the problem. In the package there are libraries missing (which are on my system due to a former upstream installation of HPLIP 2.x).
<Mithrandir> open("/usr/lib/libhpmud.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
<Mithrandir> tkamppeter: ^^ that one is probably the problem
<Mithrandir> as you diagnosed yourself at about the same time
<tkamppeter> Yes, that's it. I am now correcting the packages, so 2.7.7-0ubuntu4 will work.
<tkamppeter> Mithrandir, that is really strange that these libraries got included in the older package version, as I had to add a missing line to debian/hplip.install now.
<Chipzz> Hobbsee: FWIW +1 on removing the envy posts
<Hobbsee> Chipzz: suggest you comment on the relevant post
<Chipzz> Hobbsee: but I tend to look at it more from the angle that the whole idea of envy is totally misguided and should be discouraged
<Hobbsee> Chipzz: well, i suspect there will be some posts of that nature as well
<Chipzz> I haven't tried it yet, but chances are that it fucks with the regular packaging and causes problems on upgrades
<Hobbsee> Chipzz: but then again, arent we now blocking upgrades from those who have used automatix and envy?
<Hobbsee> and other "helper" scripts?
<Chipzz> Hobbsee: I knew about automatix, but not about envy?
<Mithrandir> mvo: ^^ ; we discussed this at UDS, has it actually been implemented?
<Hobbsee> Chipzz: i thought the plan was for that too
<Hobbsee> Mithrandir: the automatix part certainly has
<Chipzz> and are we blocking upgrades? I thought we were blcoking bugreports with apport?
<Hobbsee> oh wait, maybe that's for apport only yet
<Mithrandir> Chipzz: we should be telling the user "You have done stuff to your system which we believe will break the upgrade, sorry."
<Chipzz> anyway, would I be correct in stating that envy is misguided and dangerous?
<mvo> Mithrandir: not yet
<Chipzz> Mithrandir: we should be, but are we yet?
<Chipzz> Mithrandir: btw, are you tfheen@ubuntu.com ? :)
<Hobbsee> Chipzz: [00:46]  <mvo> Mithrandir: not yet
<Hobbsee> Chipzz: no, he's people.eater@ubuntu.com
<Chipzz> Hobbsee: :P
<Hobbsee> :P
<mvo> especially for envy (later version do not break anything) I would rather like to work around the issue, but its unfortunately not trivial to setup a testcase
<Hobbsee> Chipzz: (yes)
<mvo> I haven't looked at automatix in a while, not sure what this is currently doing
<wasabi> yay dpkg triggers
<wasabi> congrats. =)
<Mithrandir> Chipzz: yes, I am, why?
<joelbryan> anyone interested on the ubuntu-based distribution I made?
<wasabi> is that statement supposed to make us interested?
<joelbryan> http://picasaweb.google.com/joelbryan.juliano/AMADesktop2007
<joelbryan> see for yourself
<wasabi> that background looks like apples.
<Chipzz> Mithrandir: I was looking at a list of packages for a certain reason (seeing in what packages .devhelp files are stored), and I noticed libhildonfm2-dev was in section devel, and I was wandering if that's a mistake (should it be in section libdevel?)
<Chipzz> but I may be wrong on that
<Hobbsee> joelbryan: anything interesting, apart from a new background and gnome start thing there?
<Mithrandir> Chipzz: it should, yes.  File a bug and sub ubuntu-archive?
<joelbryan> Hobbsee: nothing more, that's all.
<Chipzz> nothing important really
<joelbryan> If I have more developers, other than myself, it should be really interesting
<joelbryan> heheh
<Hobbsee> joelbryan: so you want to poach current ubuntu developers, who are your upstream.  interesting.
<Mithrandir> Chipzz: I like bugs for unimportant bugs too.
<Chipzz> Mithrandir: but maybe you can clear this up (I asked here earlier but didn't get an answer yet): is section devel for development files from programs (ie not development files from libraries), or is section devel for programming tools?
<Mithrandir> Chipzz: devel is not for -dev packages from libraries, that's what libdevel is for.
<Chipzz> yes, I know that
<Chipzz> :)
<Chipzz> but development files from programs, say, gedit and epiphany
<Chipzz> should they go in devel or libdevel?
<joelbryan> Hobbsee: if that's what you think, then it's not really it is, just want to show it of, and give some gratitude
<Hobbsee> joelbryan: it looks cool, yes.
<elkbuntu> joelbryan, is this going to only include stuff from the official ubuntu repositories?
<joelbryan> so, I just want to give some gratitude to the people who make ubuntu.
<joelbryan> that's all.
<joelbryan> thanks!
<asac> stgraber: i saw that i can add releases for mozilla.qa.stgraber (at least i get to a form when i click on the link) ... is all setup already?
<mathiaz> wasabi: did you get a chance to look at bug 118977 ?
<ubotu> Launchpad bug 118977 in samba "winbindd will not start do to invalid cache path" [Medium,Incomplete]  https://launchpad.net/bugs/118977
<Lure_> Mithrandir (or any other buildd admin): can you give back kdepim (depend is now in main)
<seb128> mr_pouit: did you get bug #127439 using the mist theme?
<ubotu> Launchpad bug 127439 in gnome-themes "there is no small "Terminal" icon in the stock pack" [Low,Incomplete]  https://launchpad.net/bugs/127439
<Mithrandir> Lure_: it's depwait, so will be retried automatically
<Lure_> Mithrandir: ok, thanks - was not sure about it
<wasabi> mathiaz: The patch is a fix for an existing patch.
<wasabi> mathiaz: And it's possible the fhx.patch file has already been fixed by vorlon (debian)
<wasabi> fhs
<wasabi> I'll have to reexamine it.
<wasabi> thought it looks like the last merge was a month ago, and I've delt with this since
<mathiaz> wasabi: your report stated that winbindd doesn't work OOTB.
<wasabi> ootb == ?
<mathiaz> wasabi: out of the box
<wasabi> Ahh yes, at the time of filing, that was correct.
<mathiaz> wasabi: what's your configuration ?
<mathiaz> wasabi: I've setup a winbindd infrastructure and it works for me.
<wasabi> THe bug was regardless of configuration. Winbind should have quit almost immediatly upon starting.
<mathiaz> wasabi: should ? why ?
<wasabi> Sorry, have to bbl.
<wasabi> The bug explains it pretty clearly. ;)
<mathiaz> wasabi: The bug was set an high importance. I'm trying to understand why it's high.
<mathiaz> wasabi: the only case where this would be annoying is the case of a laptop user which is not connected to the domain.
<wasabi> Because at the time of filing it, winbind was unusable.
<wasabi> It would not even start.
<wasabi> The idea is it would create winbindd_cache.tdb in /var/cache, then go check for it in /var/lib, and fail.
<wasabi> soryr, im at work right now, i'll be in and out
<mathiaz> wasabi: ok.
<daniele_982> hello all
<daniele_982> i'm a user of debian and ubuntu and i want know if there're a solution for a big bug of gutsy (and prevoiusly Feisty): http://wiki.ubuntu-it.org/ErroreTTY
<superm1> infinity, cprov pointed me at asking you for some weirdness happening between sbuild or pbuilder.  using sbuild (on a PPA), a script in /usr/share/PACKAGE/bin/SCRIPT_NAME is turning up -rw-r--r-- root/root  , whereas if i build it locally with pbuilder, it is marked as -rwxr-xr-x root/root.  Same source package for both, any ideas why this is happening?
<beuno> Riddell: ping
<sistpoty> superm1: maybe a different umask is set in sbuild/pbuilder?
<superm1> sistpoty, should I just manually override it in debian/rules then?
<superm1> it's a bit odd for that to happen i'd think though, since its marked executable in the .orig.tar.gz
<sistpoty> superm1: I think so. Maybe dh_fixperms will also do that for you, not too sure w.o. reading the manpage though ;)
<sistpoty> superm1: if you cp the file somewhere, umask comes into effect (just test with creating a dummy file, changing permissions and cp it to a different file=
<superm1> so then perhaps sbuild is copying rather than moving files
<sistpoty> superm1: no, both sbuild and pbuilder don't copy or move files. that's what is done from debian/rules ;)
<superm1> hehe right.
<superm1> i'm just a bit perplexed as to what setting in pbuilder is causing it to work as expected then
<superm1> since i use cdbs and don't manually copy the files around
<sistpoty> superm1: I guess looking at the build system of the software might give you some clue then (just look at what make install does, in case it uses Makefiles=
<superm1> k sistpoty .  i'll poke around :)
<daniele_982> sme italian here?
<daniele_982> *same
<sistpoty> daniele_982: I'm not, but have you tried searching for the bug in LP yet?
<daniele_982> sistpoty: yes yes a lot of people and a lot of different solution but not one good. This is ridicule because the same bug is present in feisty (not in edgy) and the installer has still this problem
<sistpoty> daniele_982: what's the launchpad bug number/link?
<daniele_982> sistpoty: there're a lot of number/link if you search /bin/sh: can't access tty; job control turned off and than (busybox) there're a lot of link
<tkamppeter> riddell, your uploads of system-config-printer and cupsys seem not to have arrived yet. I do not see them on Launchpad.
<keescook> Riddell: in feisty, kdesu is part of kdebase-bin.  in gutsy kdesu is part of kdesudo (a new-in-gutsy package) and kdebase-bin (diverting to the kdesudo version).  The kdesudo version is broken (detects tty as "unknown") where as the kdebase-bin version is fine.  see bug 132456.
<ubotu> Launchpad bug 132456 in kdesudo "User account 'remembers' admin password" [High,Triaged]  https://launchpad.net/bugs/132456
<keescook> iwj: I was doing a dist-upgrade in gutsy.  half the time the initramfs hook ran, and nearer the end, I started seeing the trigger reports, but when it finished there was no final initramfs build
<Riddell> tkamppeter: https://launchpad.net/ubuntu/+source/cupsys/1.3.0-2ubuntu2 is there
<keescook> note that I ran out of disk space a few times during the whole thing so I can  dpkg --configure -a and apt-get -f install in the middle, so I'm pretty sure I confused dpkg to no end
<keescook> iwj: it's why I didn't file a bug -- I can't reproduce it, and I think I was entirely to blame.  ;)
<Riddell> tkamppeter: system-config-printer was my fault, that should be it uploaded now
<tkamppeter> Riddell, thanks.
<daniele_982> sistpoty: you have seen???
<sistpoty> daniele_982: I'm looking... (and trying to do other things at the same time ;)
<beuno> Riddell: I'll be putting the tribe5 release page together
<iwj> keescook: Hmm.
<Riddell> keescook: well sudo is supposed to remember your password
<iwj> Did you see dpkg say `Processing triggers for update-initramfs' ?
<Riddell> beuno: at https://wiki.kubuntu.org/GutsyGibbon/Tribe5 ?
<iwj> I'm still not convinced there's no dpkg bug so if you don't mind I'll quiz you a bit more.
<keescook> Riddell: right, but it is supposed to be tty-bound.  in this case, all ttys are open since it thinks every tty is named "unknown"
<beuno> Riddell: yeap yeap
<keescook> Riddell: look in /var/run/sudo/$USER/ and compare the behavior of kdesudo and kdesu.distrib
<iwj> keescook: If you have a log of any kind that would be ideal.
<keescook> iwj: which would be helpful?  I don't have stdout/stderr any more (rebooted)
<Riddell> beuno: great, thanks
<beuno> Riddell,  :D
<iwj> Damn, adsl glitch.
<Riddell> keescook: and is that a problem in practice?
<iwj> keescook: Hmm.  /var/log/dpkg.log would perhaps be helpful.
<iwj> Next time the session transcript please :-).
<sistpoty> daniele_982: I can find only three bugs searching for "/bin/sh: can't access tty"
<sistpoty> daniele_982: and none of these seem related :/
<keescook> Riddell: I view it as a security vulnerability, since programs could attempt to run kdesudo, and if the user _ever_ ran kdesudo during their session, the new program would get root access without password prompting.
<keescook> Riddell: it is a regression IMO
<daniele_982> sistpoty: for example https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129817
<ubotu> Launchpad bug 129817 in linux-source-2.6.22 "install fails: busybox (initramfs): can't access tty: (/dev/sda trouble?)" [Undecided,Incomplete] 
<Riddell> keescook: but with X aren't most programmes run from the same tty anyway?
<keescook> Riddell: no, each terminal is a new tty (x apps from the menu yes, same tty)
<bddebian> Heya folks
<Riddell> sure, so for users who don't use a command line, this doesn't make any difference
<keescook> Riddell: agreed, but it still needs fixing.  :)
<sistpoty> daniele_982: ah, k... maybe you'd want to ask in #ubuntu-kernel then (as it appears to be a kernel bug). However don't expect it to be top priority, as the kernel causes lots of subtle and hard to debug bugs
<bddebian> Any of you folks know about all of the postinst's failing connecting to mysql on /var/run/mysqld.sock ?  Is this because of initramfs?
<tkamppeter> Riddell, doko, biff
<keescook> iwj: 133172 has the log now
<daniele_982> sistpoty: ok but this problem are present in Feist with a old kernel
<LaserJock> seb128: is the easy-codec stuff working for rhythmbox and totem?
<tkamppeter> Mithrandir, Riddell, you can fix your printing now with the packages from http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/hplip/binary/ (32-bit, on 64-bit you need to rebuild the sources or wait for the mirrors)
<bddebian> LaserJock: So now that you're core-dev you can't even hang out with us low-lifes anymore eh? ;-P
<seb128> LaserJock: totem only
<Riddell> tkamppeter: great, I'll upload that now
<LaserJock> seb128: blah, will rhythmbox get it by release? That's a pretty big regression.
<seb128> LaserJock: it never had it, how is that a regression?
<Riddell> keescook: I'll have a think about how to do that
<LaserJock> seb128: Feisty had libgimme-codec which worked
<keescook> Riddell: the "old" kdesu works correctly... what is the requirement to use this new kdesudo version of it?
<seb128> LaserJock: no, the libgimme-codec was only used some weeks, the feature has been moved to gstreamer, and feisty only has easy codec installation for totem
<LaserJock> seb128: blah, ok. I guess I must have just used it during those "some weeks"
<iwj> keescook: So during your log you saw a message about update-initramfs not being run and that it would instead be run later ?
<Riddell> keescook: the old kdesu always thinks it needs a new password (even when it didn't)
<Riddell> it also randomly broke at times
<seb128> LaserJock: it never worked in rhythmbox
<Riddell> seb128: does gnome use /usr/share/autostart ?
<seb128> LaserJock: the code is non trivial for rhythmbox that's why it has not be done
<iwj> keescook: I mean, that's what you saw to stdout between 12:59 and 16:22 ?
<iwj> keescook: Can you check to see if you have  /var/lib/dpkg/triggers/Deferred  and what is in it ?
<seb128> Riddell: /etc/xdg/autostart
<keescook> iwj: correct.  what I actually saw were instances of update-initramfs running, and then later "trigger activated", and finally a prompt without a final update-initramfs being run.
<iwj> keescook: Hmm.
<keescook> Riddell: oh, heh.  I almost think that's a better situation, but then, I don't like sudo.  ;)
<keescook> iwj: I have the file; it is empty
<iwj> keescook: Definitely wrong.  And this was all in what you think was one dpkg run I take it.
<iwj> Could you dpkg -i volumeid.deb or some similar file ?
<Riddell> keescook: it's not really, we got loads of "kdesu runs as root even when I don't enter a password" bugs since it didn't really need a password at all
<Riddell> seb128: ok, I'll get someone to move the restricted-manager autostart file there
<keescook> iwj: the final portion I noticed was during one single run of dpkg, yes.  However, there had been at least 2 prior runs getting packages into half-installed states.
<iwj> Yes.
<seb128> Riddell: it's already there?
<Riddell> seb128: it's in /usr/share/autostart, not /etc/xdg/autostart
<iwj> I mean, the bit where the triggers were apparently being activated but not happening was in the final run.
<seb128> Riddell: I've it in both
<iwj> And you haven't run dpkg since ?
<Riddell> seb128: when?
<Riddell> seb128: am looking at today's ubuntu live CD
<seb128> Riddell:
<seb128> $ dpkg -L restricted-manager | grep autostart
<seb128> /usr/share/autostart
<seb128> /usr/share/autostart/restricted-manager.desktop
<seb128> /etc/xdg/autostart/restricted-manager.desktop
<seb128> using 0.28 version
<keescook> iwj: ah-ha! trigger activated, no final run.
<keescook> Setting up volumeid (113-0ubuntu7) ...
<keescook> update-initramfs: deferring update (trigger activated)
<keescook> followed by my prompt.
<keescook> (from "sudo apt-get --reinstall install volumeid")
<iwj> keescook: Weeble.
<iwj> dpkg -s initramfs-tools
<iwj> |grep Status
<keescook> Status: install ok installed
<keescook> Version: 0.85eubuntu17
<seb128> Riddell: what version do you use?
<tkamppeter> Riddell, thanks.
<Riddell> seb128: 0.28
<iwj> keescook: cat /var/lib/dpkg/triggers/update-initramfs
<keescook> cat: /var/lib/dpkg/triggers/update-initramfs: No such file or directory
<Riddell> seb128: what version do you have?
<iwj> keescook: That's definitely broken.
<keescook> which package should install that file?
<seb128> rodarvus: " using 0.28 version"
<iwj> dpkg is supposed to invent it.  It's complicated.
<keescook> ah, okay
<iwj> Looking at your log I have a theory.  I won't be able to debug it today but thanks a lot for your help.
<Riddell> seb128: most peculiar, I only have the file in /usr/share/autostart/ on both the live CD and my installed desktop
<keescook> iwj: sure, let me know if you need more details.  :)
<seb128> Riddell: the /etc might a conffile left over from an earlier version
<iwj> If this is causing you a problem, reinstalling initramfs-tools should fix it.
<iwj> If you could try that now then that would be helpful.
<keescook> sure, one sec
<seb128> Riddell: anyway you can just edit debian/restricted-manager.install
<Riddell> mhb: can you do that?
<keescook> iwj: it's doing an update-initramfs without talking about a trigger.  trying the volumeid reinstall now...
<Riddell> seb128: do we want r-m to be run on the live CD?  I don't think we do
<ion_> iwj: I dont have /var/lib/dpkg/triggers/update-initramfs either.
<keescook> iwj: yup, that fixed it.  "trigger activated" and then a "Processing triggers..."
<seb128> Riddell: not sure, better to ask to pitti on monday
<ion_> initramfs-tools 0.85eubuntu17
<Riddell> seb128: ok
<iwj> ion_: That's nice to know.  It means the bug will be easier to reproduce :-).
* iwj milestones bug 133172 for tribe-5.
<ubotu> Launchpad bug 133172 in dpkg "triggers did not run at the end of dpkg" [High,Confirmed]  https://launchpad.net/bugs/133172
<mhb> Riddell: okay
<iwj> keescook: Thanks for your report and your help.
<mr_pouit> seb128: I am going to check the mist theme & targa pictures bugs
<seb128> mr_pouit: ok,t hanks
<seb128> I've to go now
<seb128> see you on monday
<keescook> iwj: you bet!  I've added my commandline log with the failure and fix too now.
<bddebian> Gahh
<ScottK> Goo?
<bddebian> ScottK: This mysql thing bugs me and I don't know who to bug about it
<ScottK> bddebian: #ubuntu-server
<bddebian> Why #ubuntu-server?
<ScottK> Because mysql is one of the packages they tend.
<bddebian> Ahh, OK, thx
<soothsayer> Anybody have advice on how to bump a patch to a newer version of a package. That is, patch applies against 1.0, want to modify it to apply against 1.1
<Kmos> soothsayer: ask at #ubuntu-motu
<soothsayer> Kmos: Okay
<elmo> does anyone know if christer edwards IRCs?
<mdke> elmo: yes, he does occasionally I think
<elmo> mdke: do you know as what nick?
<elmo> (haha spads)
* mdke checks LP
<elmo> oh he's not here, bother
<mdke> Zelut
<elmo> mdke: right - sorry should have thought of LP
<mdke> seems online :)
<sistpoty> LaserJock: nice mail about revu... not all arguments are right (e.g. mailing list of revu nowadays only accepts mails from revu) but you definitely hit the gist, that we need to define a spec what the opimal workflow for package reviews should be
<sistpoty> LaserJock: oh, -> motu ;)
<Mithrandir> tkamppeter: given that printing works just fine using jetdirect, I'll wait until something hits gutsy.
<ion_> Yay for hplip no longer using a permanently running daemon!
<tkamppeter> Mithrandir, the HPLIP fix is in place. Simply update and check whether your HPLIP gets 2.7.7-0ubuntu4 Then everything should work fine with HPLIP (and system-config-printer will set up queues for your printer with HPLIP automatically).
<mathiaz> keescook: I'm having a look at ldap-auth-config package.
<mathiaz> keescook: dendrobates asked me to add detection of previous libnss_ldap and pam_ldap files.
<mathiaz> keescook: what's the standard way to issue warning messages to the user from a postinstall script ?
<mathiaz> keescook: I'd like to say something like "You need to migrate it by hand." and stop there.
<mathiaz> keescook: is echo enough ?
#ubuntu-devel 2007-08-18
<jdstrand> mathiaz: why not debconf message?  echo may get lost.
<keescook> mathiaz: I think debconf or Debian.NEWS (is that the right file) is the way to go.  Check with mvo?  I haven't actually done that before.
<keescook> Riddell: something went wrong with my mythtv/mythplugins upload yesterday (it never hit soyuz somehow), can I just re-upload it, or do I need a full UVFe for it?
<Riddell> keescook: just upload
<keescook> Riddell: okay, thanks, trying again.
<keescook> ah! I see what happened.  I mis-generated the changes file and forgot the orig.  I'm dumb.
<rbrito> Hi there.
<rbrito> Is there anybody seeing problems with the PowerPC port here?
<rbrito> Especially today's build?
<rbrito> I have some quite psychedelic colours on my framebuffer.
<rbrito> This doesn't happen with MacOS X or with Debian.
<rbrito> And it didn't happened with earlier builds of gutsy...
<rbrito> It is unusable, unfortunately.
<rbrito> Has anybody seen this?
<rbrito> I have an iBook G3 600MHz with a Rage Mobility M3.
<rbrito> Old vintage with 8MB of VRAM.
<rbrito> I would like to help with the port (as I mentioned yesterday here, I don't know how platforms qualify as "supported" under Ubuntu).
<rbrito> Under Debian, I know the procedures for qualification of a port...
<rbrito> But I would like to help get Ubuntu working fine in as many computers that I can.
<rbrito> Also, this bug is a complete show-stopper:
<rbrito> https://bugs.launchpad.net/bugs/126146
<ubotu> Launchpad bug 126146 in initramfs-tools "gutsy doesn't boot completely on powerpc (dup-of: 131150)" [Undecided,New] 
<ubotu> Launchpad bug 131150 in initramfs-tools "IDE drivers not loaded at boot with powerpc" [High,Confirmed] 
<rbrito> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/124369
<ubotu> Launchpad bug 124369 in linux-source-2.6.22 "gutsy dailys wont boot on powerbook 3,5 (dup-of: 131150)" [Undecided,New] 
<rbrito> We seem to have unfortunate situations here with the bootstrapping process.
<rbrito> :-(
<rbrito> Can anybody help?
<rbrito> I am willing to test anything that I can.
<rbrito> Anybody can help?
<minghua> rbrito: I think the best bet is filing a bug report.
<minghua> rbrito: also it's (close to) weekend, so many developers are probably not here.
<rbrito> minghua, Thanks for your answer.
<rbrito> I already filed a bug report...
<rbrito> https://bugs.launchpad.net/bugs/126146
<ubotu> Launchpad bug 126146 in initramfs-tools "gutsy doesn't boot completely on powerpc (dup-of: 131150)" [Undecided,New] 
<ubotu> Launchpad bug 131150 in initramfs-tools "IDE drivers not loaded at boot with powerpc" [High,Confirmed] 
<rbrito> But it has not seen much attention. :-(
<rbrito> And it is quite important now to support the powerpc platform.
<rbrito> I say this because Apple is cutting support for all PowerPC computers that were based on any chips up to G3 with the next release of MacOS X and, thus, there is quite a lot of users that would benefit from a fine Operating system that Ubuntu Linux is.
<bhale> I believe the fastest g3 is 500mhz or so, which is getting a little old for a full blown GNOME/KDE desktop
<bhale> xubuntu might be a good choice
<rbrito> bhale, no, I have a G3 here that is 600MHz and I have used G3 computers that were 900MHz.
<rbrito> Stock from Apple.
<rbrito> My iBook has 640MB of RAM.
<bhale> thats not bad
<stgraber> bhale: I have a Powerbook G3 working fine with KDE even with compiz and things like that
<rbrito> stgraber, so, it seems that the userbase of PowerPC is not that small, at least. :-)
<rbrito> I would be happy with just fluxbox, but not having the boot process working makes things harder.
<stgraber> rbrito: well, it's more of a test/builder computer, my work laptop being a nice Core2Duo :)
<rbrito> I am not even considering using compiz and all the superb stuff.
<stgraber> yes, I also had that ide thing, I'll try doing a test with fixed initram when I have a moment
<rbrito> stgraber, I don't have that much luck with my hardware, being in here in Brazil.
<rbrito> stgraber, I would volunteer to be a tester.
<rbrito> As you can see in the following bug report, I usually take my bugreports quite seriously and in a detailed fashion:
<rbrito> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/123263
<ubotu> Launchpad bug 123263 in compiz "tribe-2 has severe problems due to screen effects enabled by default" [High,Confirmed] 
<rbrito> I usually do my best.
<rbrito> bhale, I also have an older PowerMac that is dual-processor (inherited from my uncle).
<rbrito> It has, though, an upgrade of processor to a G3 450MHz.
<rbrito> bhale, and, as you can see here, I have a bit of experience with older PowerPC machines:
<rbrito> http://lists.debian.org/debian-powerpc/2005/04/msg00434.html
<rbrito> stgraber, Do you have anything that I could test now?
<rbrito> I eagerly want to help.
<rbrito> Actually, I would love to see PowerPC supported back to the same level that it was before...
<rbrito> Not as a port.
<rbrito> And talking about ports, are there mirrors of ports.ubuntu.com?
<rbrito> I have done some quick searches and found none...
<rbrito> My download rates from ports.ubuntu.com are terribly slow. :-(
<rbrito> Having PowerPC with a good supported status would be superb.
<rbrito> But I can't even install it due to the bugs that I pointed above... :-(
<rbrito> I can really test any images that are around.
<rbrito> I am willing to be a guinea pig and help get my laptop in working conditions so that I can deliver some classes...
<rbrito> With a modern distribution.
<rbrito> well, it seems that there is not much momentum to help the PowerPC port... :-(
<rbrito> I'd love to be helpful to the distribution...
<Trewas> rbrito: you could not have picked a more desperate time to bring it up here as it is middle of the night in europe (where many of the devels are) and weekend :)
<rbrito> Trewas, sorry, the differences in timezones...
<Trewas> not that I have anything to do with the development of ubuntu... just a side note
<rbrito> I thought that Ubuntu had developers in the Americas...
<rbrito> Trewas, that's ok.
<ScottK> rbrito: There are some.
<rbrito> ScottK, but would there be any involved with the boot process?
<rbrito> I would like to help.
<ScottK> Not that I know of.
<rbrito> It seems to be a moderately trivial fix...
<ScottK> European week day is your best bet.
<ScottK> You could also attach a patch to the relevant bug.
<rbrito> ScottK, Oh, ok. I guess that I will have to wait.
<rbrito> The fix is just an echo ide-core > /proper/module/loading/file
<rbrito> That's it.
<ScottK> I'd still make a patch and attach it.  It's more likely to be looked at.
<rbrito> But the bug persists in that even with newer kernel images than 2.6.22-6 (I tried 2.6.22-9) the problem surfaces...
<rbrito> ScottK, Ok, I think that I will have to do that...
<rbrito> Well, I'm going now.
<rbrito> Thank you very much for all the help you've provided.
<rbrito> I really hope to have PowerPC better supported in tribe-5 and in the final release.
<rbrito> See ya
<keescook> what's the right replacement for libmyspell-dev in Depends?  (bug 133062)
<ubotu> Launchpad bug 133062 in ifrench "FTBFS (Package libmyspell-dev is not available)" [Medium,Triaged]  https://launchpad.net/bugs/133062
<minghua> keescook: libhunspell-dev, it seems.
<keescook> minghua: cool, thanks.
<bddebian> heya
<prabs> hi guys, just wondering if we get karma points for uploading .po too? or is it for the things we do in launchpad that counts?
<Fujitsu> prabs: That's more of a #launchpad question.
<xhaker_> !find jni.g
<xhaker_> !find jni.h
<ubotu> Package/file jni.g does not exist in feisty
<ubotu> File jni.h found in classpath-common, firefox-dev, gcc-snapshot, j2sdk1.4, java-gcj-compat-dev (and 9 others)
* netjoined: irc.freenode.net -> kubrick.freenode.net
<fabbione> NOTICE: ubuntulog is going down for a few hours for maintainance
* Starting logfile irclogs/ubuntu-devel.log
<fabbione> well.. all back online
<pygi> xhaker_, poke
<SimIJskes> hello
<SimIJskes> i have patched libpoppler so that it delegates some font name translation to fontconfig, is there anybody else working on this subject?
* ..[topic/#ubuntu-devel:Riddell] : 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 | UVF in place
<Riddell> SimIJskes: isn't that something for upstream?
<SimIJskes> you tell me. i only like to include it in ubuntu
<StevenK> Mithrandir: If you're around, do you mind NBS'ing some binaries  out of the archive?
<SimIJskes> Riddell: do you know of a motu developer who likes to adopt this?
<Seveas> SimIJskes, such changes really should go upstream...
<Seveas> SimIJskes, and libpoppler is in main, so not the domain of the MOTU
<SimIJskes> Seveas: it's only a little patch.
<SimIJskes> Seveas: who does main?
<croftj> Hi Yall
<croftj> Hi, I'm trying to find a list of packages that come standard on ubutnu or kubutnu, can anyone point me there?
<RAOF> croftj: Check out the dependencies/recommends of [k] ubuntu-desktop.
<croftj> Help me, I'm not a ubutnu user so I'm not familiar with the web site. Is that under the docs?
<croftj> Found it! http://packages.ubuntu.com
<Fujitsu>  /win 16
<Fujitsu> Oops.
<croftj> Have yall checkout the suse build server? Lets you build packages for lots of distributions. Pretty slick
<DarkSun88> Hi all
<norsetto> hiya
<Mithrandir> StevenK: preferably not, unless it's urgent?
<croftj> Hi
<Dreadddddd> Preved amerikan4egi!!!
<StevenK> Fujitsu: I'm guessing https://bugs.launchpad.net/ubuntu/+source/ion3/+bug/115142 can be closed?
<ubotu> Launchpad bug 115142 in ion3 "New distribution conditions based on trademark claim" [Medium,Confirmed] 
<terrorX> greeting's ?
<Dreadddddd> terrorX    ?
<Dreadddddd>    greeting's ?
<terrorX>  
<terrorX>   
<terrorX>  
<terrorX>     )
<elkbuntu> eep
<Dreadddddd> davay
<terrorX> zdrasti tela! =)
<terrorX> xotya vsyo ravno ne poymut ni razu )
<Dreadddddd> elkbuntu epp herself
<Dreadddddd> :\
<elkbuntu> Hobbsee, Dreadddddd and terrorX are spamming
<terrorX> stuka4 ebu4iy
<Dreadddddd> 4ootta spamming ?
<terrorX> wi a russian people?
<terrorX> a naverno nenado bilo
<Dreadddddd> terrorX #help
<terrorX> iii
* mode/#ubuntu-devel [+o Hobbsee_]  by ChanServ
* mode/#ubuntu-devel [+b *!*@91.145.199.181]  by Hobbsee_
* Dreadddddd was kicked off #ubuntu-devel by Hobbsee_ (Hobbsee_)
* mode/#ubuntu-devel [+b *!*@85.114.172.235]  by Hobbsee_
* terrorX was kicked off #ubuntu-devel by Hobbsee_ (Hobbsee_)
<Hobbsee_> op
<elkbuntu> :)
<Hobbsee_> finally.
<Hobbsee_> stupid slow connection.
<Hobbsee> hi LongPointyStick
<LongPointyStick> oh, so we are here
<phoenix_> hey
<phoenix_> i got a via vt8251 chipset
<phoenix_> doesnt detect my drives
<phoenix_> can it be added or can u point me to a feisty driver
<phoenix_> only found dapper
<phoenix_> dapper driver that is
<phoenix_> http://www.viaarena.com/default.aspx?PageID=420&OSID=45&CatID=3270&SubCatID=167
<Hobbsee> suggest you try #ubuntu for support
<phoenix_> ther we go :)
<phoenix_> Hobbsee,  i was just wondering will ther be vt8251 drivers or kernel modudles for gutsy or feisty ?
<phoenix_> only found dapper ones
<Hobbsee> i have no idea, and it is a weekend.
<phoenix_> oh well
<phoenix_> thkx for answering tho
<Hobbsee> ogra: impressive way to misspell my name.  i dont think anyone's ever managed it *that* way before.
<fabbione> Hobbsee: where is that?
<norsetto> hmmmm, not that I didn't try :-)
<Hobbsee> fabbione: distro team meeting
<fabbione> oh i see
<geser> Mithrandir: ion3 moved into non-free in Debian. Should we follow and move it into multiverse?
<Mithrandir> geser: yes.  Done.
<Mithrandir> (and thanks)
<geser> ion3-scripts and ion3-mod-ionflux should also be moved to multiverse as they depend on ion3
<Mithrandir> geser: thanks, fixed.
<geser> Mithrandir: please give-back kde4addons on amd64 and powerpc. Thanks.
<Mithrandir> geser: gegebt-back
<asac> pygi: huh?
<asac> pygi: why gnash? thought you were on swfdec?
<pygi> asac, I'm on everything xD
<pygi> asac, swfdec is packaged and reported bug about it (not swfdec-mozilla yet tho)
<asac> pygi: what did you do to gnash? can you pleaes tell me?
<pygi> asac, because of that upgrade from 3? we talked about that xD
<pygi> asac, just did work on my branch, uploaded nothing
<asac> ah ok
<asac> pygi: so is revision 102 exactly the same that is uploaded as ubuntu4?
<asac> pygi: i read "for people with ubuntu3 and ubuntu4 packages
<asac> "
<asac> is ubuntu4 broken as well?
<asac> ok nevermind
<pygi> asac, no, ubuntu4 isn't broken
<pygi> asac, but it needs modification so people with 3 could safely upgrade
<asac> yeah i saw that now ... i just was a bit confused by changelog wording
<asac> but thats ok
<pygi> you should test that fix, so we're sure it's fine
<pygi> kk :)
<asac> i will before the upload ;)
<pygi> asac, swfdec0.5.1 here: https://bugs.launchpad.net/ubuntu/+source/swfdec0.4/+bug/133052
<ubotu> Launchpad bug 133052 in swfdec0.4 "[needs review]  swfdec0.5.1 [needs upload] " [Undecided,New] 
<pygi> I'll work on swfdec-mozilla today or tomorrow, or so
<pygi> soon anyway xD
<asac> sure ... tell me when its there ... i will do both at once then
<pygi> oki =)
<asac> does swfdec have a branch as well?
<pygi> asac, nop, because you said you wanted mainline branch to be part of motu
<pygi> asac, and I can't do that
<pygi> but I can create my personal branch if you wish
<ScottK> swfdec0.5 will be a new package, right?
<asac> pygi: yes please do
<asac> actually i think we should name the source package just swfdec
<ScottK> Either way, it'll be a new source package.
<asac> technically yes
<asac> politically i would say no :)
<pygi> asac, personally, I like the way it is now
<pygi> asac, for now at least
<pygi> asac, because Company uses version as part of soname
<pygi> asac_, what's the last thing you saw? xD
<asac_> pygi: i will ping you again ... have to reboot gateway because of kernel upgrade ... and more importantly reset my modem
<asac_> pygi: i saw 20:10 < asac> politically i would say no :)
<asac_> nothing more
<asac_> cu soon
<pygi> asac_, I didnt got that :)
<pygi> laters =)
<asac_> oh
<asac_> hehe
<asac_> yeah
<asac_> bye
<pygi> wb asac
<pygi> asac, so what you didn't saw from me is:
<pygi> <pygi> asac, personally, I like the way it is now
<pygi> <pygi> asac, for now at least
<pygi> * ryu (n=chris@unaffiliated/ryu) has joined #ubuntu-devel
<pygi> <pygi> asac, because Company uses version as part of soname
<asac> well ... but having a new source package for each single new version is not really great
<pygi> asac, we have new source package anyway
<asac> yes ... but if we drop version from it now we won't have that next time
<pygi> asac, ah, k
<asac> since company offered to track abi if we care ... we should probably let him know that we care :)
<pygi> asac, :P
<pygi> nod =)
<pygi> asac, ok, my suggestion follows: do it like swfdec0.5 now, and when we get proper abi from Company, do it the right way?
<pygi> or you want to do it now
<asac> better do it now ... otherwise we just put load on source NEW reviewers
<asac> having versioned binaries is enough for now
<pygi> oh well, k
<pygi> asac, Baby was searching for you in #gnash
<asac> yeah ... tomorrow i will join that channel again :)
<asac> thanks!
<asac> ok i will join now
<pygi> asac, :D
<rgl> hi
<asac> hi rgl
<rgl> OT: how can I configure xvncviewer to not trap the F8 key?
<sbalneav> rgl: Wrong channel for that, Try #ubuntu
<rgl> sbalneav, I did.  but noone answers. :D
<sbalneav> Then maybe no-one knows.
<Seveas> rgl, then this is still the wrong chan
<rgl> thats why I asked here. :D
<sbalneav> rgl: have you read the man page? It tells you in there.
<rgl> sbalneav, oh you are right.  I'm sorry :-(
<geser> Mithrandir: when I asked for a give-back for kde4addons some hours ago, did you do it for gutsy or for feisty-backports?
<crimsun> asac: WRT flashplugin-nonfree, cf. Debian #398666
<ubotu> Debian bug 398666 in flashplugin-nonfree "flashplugin-nonfree: fails to install with debconf "noninteractive" with message "download or license refused"" [Grave,Open]  http://bugs.debian.org/398666
<asac> crimsun: that is still open
<asac> crimsun: did you remove that because of this?
<crimsun> asac: no, the Debian maintainer did
<asac> crimsun: ok we need it ... its pretty illegal to not display it afaik
<asac> crimsun: do you have an idea how to resurrect it?
<asac> e.g. what the exact changes were?
<crimsun> asac: Bart's changes are in 9.0.21.78.1; essentially, you'd need to revert his debian/templates and debian/config changes
<crimsun> (change the default download to "no" for starters)
<asac> crimsun: default download == display license?
<crimsun> asac: yes.
<crimsun> asac: it's Template: flashplugin-nonfree/httpget
<asac> how easy is it to decouple that ?
<asac> i mean we have to ask user to accept that license everytime
<asac> ... so debconf for that is just wrong ... or do i miss the point here?
<asac> let me look that ugly package :(
<crimsun> it wouldn't be terribly difficult to decouple, but it is messy as you imply.
#ubuntu-devel 2007-08-19
<asac> its really messy
<asac> httpget template isn't sufficient
<asac> it doesn't display the license ... at least from what i see
<asac> it just says: you can find it somewhere on adobe.com :/
<crimsun> take a look at http://launchpadlibrarian.net/5118162/flashplugin-nonfree_9.0.21.78%7Eubuntu1.tar.gz and http://launchpadlibrarian.net/5118163/flashplugin-nonfree_9.0.21.78%7Eubuntu1.dsc
<crimsun> that's the last version that offered it IIRC
<asac> crimsun: i might be a moron  ... but it doesn't build for me
<asac> dpkg-genchanges: failure: cannot read files list file: No such file or directory
<asac> i just build it with dpkg-buildpackage -b
<crimsun> (https://launchpad.net/ubuntu/feisty/i386/flashplugin-nonfree/9.0.21.78~ubuntu1)
<crimsun> arg
<asac> and it fails
<crimsun> http://launchpadlibrarian.net/5118980/flashplugin-nonfree_9.0.21.78%7Eubuntu1_i386.deb
<asac> ah
<asac> :)
<asac> now i see :)
<asac> i am on amd64
<crimsun> right, you added amd64 support :)
<asac> its interesting that it really fails to tell me that the problem is my architecture
<asac> just fails like crazy
<asac> crimsun: that package didn't ask me a thing :(
<asac> crimsun: why the hell does he do all this "use already existing local tar.gz" stuff?
<asac> crimsun: any idea?
<asac> i feel tempted to just drop all this and redo the package from scratch
<crimsun> asac: to not redownload the tarball.  Feel free to redo it if you'd like.
<asac> crimsun: when would you want to not redownload tarball?
<asac> crimsun: the only situation i can imagine is --reinstall
<crimsun> asac: there's also version x.y.z-Aubuntu1 -> x.y.z-Aubuntu2
<crimsun> (or A -> A+1, for that matter{
<asac> ah
<asac> thanks for giving me those obvious ideas ;)
<crimsun> ;)
<asac> the problem i see is ... whatever i do now ... if its more than one line it will certainly be wiped on next merge by someone :)
<asac> i will think about this
<asac> and talk to mvo on how to best display that license
<crimsun> great :)
<asac> at best directly displaying the original license url ... like firefox plugin wizard does
<crimsun> many/most people I've introduced to Ubuntu Gutsy just use whatever Firefox provides instead of installing the flashplugin-nonfree package, but I realise that doesn't accomodate Opera and Konqueror
<asac> crimsun: have you seen the new plugin installer wizard of firefox (which is why i ran into this licensing thing) ?
<asac> crimsun: http://people.ubuntu.com/~asac/pfs/screens/pfs1.png
<asac> you can now find/install apt packages ;)
<crimsun> read about it but haven't used it
<asac> sure ... what do you mean by "whatever firefox provides" ... iirc we don't install flash by default ... do we?
<asac> ah ... i see :) ... they use the package plugin-finderwizard pops up :)
<crimsun> right.
<asac> sorry for being tired ;)
<nixternal> wi6
<nixternal> err
<alex-weej> asac: great news about the apt support in ubufox
* alex-weej is chuffed
<Mithrandir> geser: given-back in gutsy too now
* Starting logfile irclogs/ubuntu-devel.log
* #ubuntu-devel  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<alex-weej> doesn't the new Bootloader Manager screw up the automatic list generation?
<alex-weej> i can't help but get the feeling it should be editing an intermediate configuration
* #ubuntu-devel  [freenode-info]  why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup
<xhaker> !find jni.h
<ubotu> File jni.h found in classpath-common, firefox-dev, gcc-snapshot, j2sdk1.4, java-gcj-compat-dev (and 9 others)
<ProN00b> can anyone file a bug for me ? vino-server (and other vnc servers) aparently depend on an US keyboard layout to work correctly
#ubuntu-devel 2008-08-11
<Hobbsee> here's an interesting question....
<Hobbsee> why does the printer on the LAN keep starting up, whenever I turn my machine on, and it logs in?
<johanbr> BenC: A garden variety Belkin. Don't remember the exact model.
<bep> i read that there is going to be a folder in the home dir named Private which is encrypted. is this going to be by default or an option?
<BenC> Hobbsee: it reacts to cups scanning for printers, maybe?
<Hobbsee> BenC: does that happen automatically on boot now?  it only started a couple of days ago
<BenC> Hobbsee: I've no idea, just guessing :)
<persia> Hobbsee: You're sure it's boot and not login?
<Hobbsee> persia: it may well be.
<persia> bep: Under discussion: see https://wiki.ubuntu.com/EncryptedPrivateDirectory
<nxvl> Hobbsee: i didn't understand your comment
<nxvl> Hobbsee: did you meant to upload ppa packages into a universe/ repo instead of into main/ (on the ppa)?
<Hobbsee> nxvl: which comment?
<nxvl> Hobbsee: http://nvalcarcel.aureal.com.pe/?p=235#comments
<nxvl> (on my blog)
<nxvl> persia: did you know how to relibtoolize a package? i'm having problems with courier's merge
<Hobbsee> nxvl: oh.  no.  it's just that anyone can upload a package that a MOTU / core dev has uploaded to their ppa, or a team ppa that they're in, directly to the main archive.
<nxvl> Hobbsee: as a debian sync? but a ppa sync?
<nxvl> Hobbsee: http://paste.ubuntu.com/35777/
<nxvl> err
<nxvl> persia: http://paste.ubuntu.com/35777/
<Hobbsee> nxvl: effectively
<nxvl> oh!
<Hobbsee> nxvl: but anyone can upload it, and say it was you.
<nxvl> i didn't knew that
<Hobbsee> it'll be your signature on it.
<nxvl> that can't be right
<RAOF> nxvl: As in - someone can grab the signed .changes file by guessing a URL.  Once they have that, they can upload to Ubuntu (or Debian, if you happened to be a DD).
 * RAOF hopes that's a sufficiently vague description.
<persia> RAOF: It gets awfully close to describing an implementation.
<persia> Anyway, this is something for #launchpad. not here.
<RAOF> Right.
 * ScottK gives nxvl cheers for his blog post.  We should all be more paranoid.
<nxvl> ScottK: :D
<nxvl> ScottK: i was thinking on how can i use ppa'a and still trust them
<nxvl> ScottK: and that was the result
<ScottK> Of course that result assume IP's can't be spoofed.
<nxvl> persia: can you take a look at the pastebin i have just give you and point me to some document or something?
<nxvl> (if you know what the issue can be of course)
<ScottK> Which, AFAIK, is for practical purposes a reasonable risk to accept.
<persia> nxvl: You make the assumption that I'm able to respond to things within 7 minutes.  The pastebin is open.  courier is in universe, so #ubuntu-motu is a better place (and I'll answer there)
<nxvl> persia: right
<nxvl> i always have problems with ubuntu related channels
<nxvl> :D
<nxvl> so, to make in clearer, is this channel like ubuntu-core or something?
<nxvl> is not just general development
<nxvl> ?
<nxvl> s/development/ubuntu development/
<persia> Well, some universe stuff to, but focused on development of the bits that fit in the flavours that ship, or issues that pertain to all of Ubuntu.
<nxvl> ok
<nxvl> understood
<nxvl> :D
<lukehasnonam1> soren: Just to let you know, I'm suffering a similar problem in nm-applet bug #92570
<ubottu> Launchpad bug 92570 in network-manager-vpnc "nm-applet dissapears after connecting to vpn" [Undecided,Confirmed] https://launchpad.net/bugs/92570
<lukehasnonam1> not with VPN, but occasionally when connecting to a wireless network (or attempting to) nm-applet will disappear (but still be running), and the wireless connection will not be active. I didn't think to kill networkmanager an restart to fix the problem.
<lukehasnonam1> g2g
<emgent> moin people
<ion_> benc: Btw, as you have the Ubuntu kernel changes as a series of commits that are regularly rebased against upstream, you might find stgit more useful.
<dholbach> good morning
<Burgundavia> morning dholbach
<dholbach> hi Burgundavia
<ion_> niÅ
<dholbach> hi ion_
<dholbach> was "turning off the 'would you like to have sticky keys enabled?' question" ever discussed somewhere?
<dholbach> if so, I'd like to bring it up again
<persia> I rather like that feature.  Why would we want to disable it?
<dholbach> or the popup needs to be fixed to pop up at the right place and not prevent anything else from happening
<dholbach> it's very confusing the way it is now
<dholbach> I'm just discussing the question popup
<persia> I guess.  What is the use case for holding down a key that long when one is exceedingly unlikely to want sticky keys?
<gaurdro> I dunno if any of you can do anything about it but someone just reported a spammer in #ubuntu.
<persia> gaurdro: If you're looking for IRC stuff, you might want #ubuntu-irc
<dholbach> persia: right, I could just train myself not to press it down while I'm thinking about how to finish a sentence or something
<dholbach> but still the pop-under-block-anything-else-thing is broken :)
<persia> dholbach: Heh.  That tends to me when it pops up for me, or when I'm selecting *lots* of individual files in nautilus.
<persia> On the other hand, I don't know how else to make ti blindingly obvious for those with mobility issues.
<persia> s/me/be/1
<dholbach> it just happened to me when KVM was also doing its own weird focus grabbing and some other application of mine popped up - that was very confusing
<persia> OOh.  That specific interaction sounds like it might be a bug :(
<pitti> Good morning
<pitti> asac: thanks, will move to -updates
<StevenK> Morning pitti
<dholbach> hiya pitti
<StevenK> pitti: Can I bug you for some syncs for NBS goodness and bug-fixing goodness?
<pitti> StevenK: yes, I want to do some syncs, too; what do you need?
 * StevenK files the last one.
<pitti> StevenK: oh, you can just tell me here, but bugs are okay, too
<StevenK> pitti: Bugs 256280, 256803, 256806
<ubottu> Launchpad bug 256280 in clutter-cairo "Please sync clutter-cairo 0.8.2-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/256280
<ubottu> Launchpad bug 256803 in bluez-libs "Please sync bluez-libs 3.36-1 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/256803
<ubottu> Launchpad bug 256806 in clutter-gst "Please sync clutter-gst 0.8.0-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/256806
<StevenK> pitti: The last one is clutter-perl, bug number coming
<StevenK> pitti: That pulls everything aside from python-clutter from clutter's multiple NBS listings, but upstream doesn't have a pyclutter 0.8 :-(
<pitti> StevenK: clutter-gst needs a fakesync (different orig.tar.gz, see bug), the other two are done
<StevenK> pitti: So -1ubuntu1
<StevenK> For clutter-gst ?
<pitti> StevenK: -1build1
<StevenK> pitti: I'll munge it together
<pitti> StevenK: thanks
<persia> StevenK: Do we want the entire BlueZ 3.36 stack?  It seems like rather a few of the libraries have been updated since we last pulled.
<StevenK> persia: I was going to upload my merge of -utils 3.36 after dealing with -gst
<persia> StevenK: I was also thinking about -firmward, -hcidump, -gnome and obex-data-server.
<persia> s/ward/ware/
<StevenK> persia: Let me empty my stack first
<persia> StevenK: OK.  Hit me when you get more clear: I was looking at this with Whoopie yesterday.
<tkamppeter> pitti, hi
<StevenK> pitti: Should we NBS out clutter 0.6 and break python-clutter, or leave it?
<pitti> StevenK: ah, so python-clutter is unfixable in principle ATM?
<StevenK> pitti: Upstream are still stuck at 0.6.2
<StevenK> pitti: There is no branch upstream for 0.8
<StevenK> pitti: I can try and crowbar it into building against 0.8
<pitti> StevenK: sure, let's NBS the libs then; we can't keep them around forever anyway
<pitti> StevenK: oh, hang on
<StevenK> pitti: Hm?
<pitti> StevenK: python-clutter as in the source package doesn't exits
<pitti> ah, it's pyclutter
<StevenK> Mmmm
<pitti> StevenK: there are no rdepends to pyclutter
<pitti> StevenK: so it's fine to leave it broken until upstream updates
<StevenK> persia: You're welcome to check out my merge of -utils
<tkamppeter> pitti, have you seen my new upload of the PDF filters into the CUPS SVN?
<pitti> tkamppeter: yet a new one this morning? no, not yet
<pitti> tkamppeter: as I wrote you yesterday, I uploaded the version from yesterday to experimental
<tkamppeter> Sorry, I did not see the mail. Now I have found it.
<tkamppeter> pitti, now the following is missing to fix the blueprint:
<pitti> tkamppeter: nothing new in svn, so I guess I did the current one
<pitti> tkamppeter: I just synced it to intrepid, too
<tkamppeter> - texttopdf and pdftoijs
<tkamppeter> - GTK apps (seb128) and OOo (calc) outputting PDF instead of PS
<tkamppeter> pitti, I mailed heno (as the approver of the Blueprint) about this but he never amswered me. Is he on vacation?
<pitti> tkamppeter: he should be online this week
<tkamppeter> pitti, was heno on vacation last week?
<pitti> not sure
<pitti> argh, wiki.ubuntu.com uses OpenID now, and seems to break editmoin :(
<persia> pitti: It just wants a new cookie
<pitti> persia: I updated it, but it doesn't work
<persia> pitti: Odd.  Worked for some people.
<persia> StevenK: Where is the merge?
<StevenK> persia: I can put it online and point you to it?
<pitti> tjaalton, bryce, jcristau: did you hear about reports about utterly slow keyboard repeat rate after switching to the xorg input hotplug? I can't change it any more in the GNOME keyboard prefs either
<tkamppeter> doko, slangasek, you have done changes in the gsfonts package recently, I need your help
<persia> StevenK: Sure.  The stuff I forward-ported from Whoopie should be able to be dropped, but I'm happy to test.
<pitti> tkamppeter: they are at debconf this week
<tjaalton> pitti: someone blamed it being too fast
<tkamppeter> pitti, how should the gsfonts problem be solved? I have never done anything with fonts.
<slangasek> tkamppeter: "recently" == 2005, I guess...
<pitti> tkamppeter: why does ghostscript need to ship the same fonts as gsfonts? maybe we can throw them out of ghostscript again if they are the same?
<pitti> or drop gsfonts?
<tkamppeter> slanagsek, the third changelog entry is already 2005. this package seems not to change very often.
<slangasek> tkamppeter: indeed
<tkamppeter> pitti, ghostscript ships the fonts, but the files have different names. So there are probably certain measures needed for backward compatibility,
<tjaalton> pitti: I agree that changing the rate in the capplet doesn't seem to have an effect
<slangasek> pitti: yes, I think "pick one or the other" is the proposal.  Now that I realize which package gsfonts is, I'm worried about taking the ghostscript versions of these fonts without some sort of regression-testing, because fixing bugs in gsfonts was always quite painful
<tkamppeter> I prefer to use the fonts coming with GS, to eliminate a package and so make maintenance easier.
<slangasek> it doesn't make maintenance easier if it turns out that there's a net increase in bugs... :)  which I don't know, but fear
<tkamppeter> If only GS needed gsfonts. I removed it already, but there are other packages also needing gsfonts: gsfonts-x11, libwmf0.2-7, xpdf-reader
<tkamppeter> So perhaps I split the fonts which come with Ghostscript into its own package and then make an "or" dependency.
<pitti> I don't think gsfonts-x11 is even necessary any more, debian bug 97307
<ubottu> Debian bug 97307 in gsfonts "gsfonts: gsfonts should 'Provide:' itself under the former name "gsfonts-x11"" [Normal,Open] http://bugs.debian.org/97307
<pitti> tkamppeter: maybe we shuold ask the Debian maintainer and open a debian bug about it
<pitti> oh, ugh, that bug is oooold
<pitti> so, ignore that bug for now
<tkamppeter> pitti, I think this is the best solution, and when Debian has sorted it out, it will find the way into Ubuntu (Intrepid+1) by itself.
<pitti> tkamppeter: intrepid, not intrepid+1
<pitti> it's a waste, and if Masayuki Hatta doesn't have an idea, we have to improvise
<StevenK> persia: http://people.ubuntu.com/~stevenk/bluez-utils/
<pitti> StevenK: I NBS-removed the clutter stuff and the ones without rdepends
<StevenK> pitti: \o/
<persia> StevenK: Looks reasonable to me: I especially like the reclosure of 191704
<StevenK> persia: Shall I upload it then?
<persia> StevenK: It's probably worth noting that it fixes 211252 as well (for bluez-utils).
<StevenK> persia: Which bit?
<pitti> calc: do you plan another OO.o upload for alpha-4? If so, could you switch the boost build deps to 1.35?
<persia> StevenK: Upstream ships http://bluez.cvs.sourceforge.net/bluez/utils/sdpd/request.c?r1=1.22&r2=1.23&view=patch in 3.36
<persia> Mind you, if it's SRU-worthy (regression), it still needs hardy tasks approved, so Whoopie's debdiffs can be tested in the normal manner.
<pitti> Riddell: do you have an eye on the various out-of-date problems for kde* on http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_outdate.html? there are some FTBFSes
<pitti> Riddell: if you touch them, maybe you can flip the build dependencies to boost 1.35?
<StevenK> persia: Hm? That's shipped as a patch?
<StevenK> persia: You've lost me somewhere
<persia> StevenK: The candidate patch waiting in U-M-S for intrepid/bluez-utils for 211252 is only a backport of that fix from upstream.  3.36 has it applied upstream, so with the merge, it doesn't need to be tracked separately.
<StevenK> persia: Oh, right.
<StevenK> persia: Should I sprinkle the bug into the changelog
<StevenK> ?
<persia> Please :)
<persia> If you're at it, and want to approve the hardy tasks, that would be an extra bonus.
<StevenK> Bug 211252
<ubottu> Launchpad bug 211252 in obex-data-server "Cannot recieve files using bluetooth" [Undecided,Confirmed] https://launchpad.net/bugs/211252
<StevenK> Oh that's right, it requires -core-dev blessing
<StevenK> persia: -utils blessed for Hardy, Intrepid
<persia> And now that you've done such an excellent job with the merge, I don't get an upload.
 * persia goes to look at bluez-gnome 0.28 in hopes of restoring the count
<persia> Thank you.
<StevenK> persia: It needs approval for obex-d-s, too?
<persia> StevenK: Yes, but that's fixed in intrepid, and Kenny and Whoopie are already very much on top of it for hardy.
<StevenK> persia: New merge line for -utils: * Merge from Debian unstable. (LP: #211252)
<StevenK> persia: Unless you want  - This version adds support for recieving files? :-P
<persia> StevenK: Nah: it only breaks for people with Symbian: it's really a workaround for a bug there.
<StevenK> persia: Uploaded.
<persia> StevenK: Excellent.  Thank you.
<StevenK> Just missing out on the publisher run started
<persia> That's OK.  There's only two people who were willing to test that on intrepid anyway (of those affected and following the bug), and it probably wants the updated bluez-libs sync anyway.
<StevenK> persia: It explicity Build-Depends on it.
<persia> StevenK: Indeed.
<StevenK> pitti: Bug 256816 (clutter-perl) can be synced
<ubottu> Launchpad bug 256816 in clutter-perl "Please sync clutter-perl 0.8.0.1-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/256816
<StevenK> pitti: The publisher is mid-run, and it Build-Depends on stuff newer so that at worse case it will DEPWAIT
<pitti> StevenK: done
<StevenK> pitti: Danke
<StevenK> pitti: primero is spinning on gnunet-fuse again :-(
<elmo> pitti: please rescore the build to -1
<elmo> (once it finished, I've just killed the hung process)
<StevenK> elmo: What is actually hanging?
<pitti> hm, didn't I do that already? seems that the prio adjustment cronjob resets it
<elmo> StevenK: gnunet-update in the postinst
<elmo> StevenK: infinity says it's a hppa TLS problem
<StevenK> Woot!
<elmo> *shrug*
<elmo> pitti: are you sure it was -fuse?  the gnunet packages seem to breed like rabbits
<pitti> not 100%, just that I did that for 2 gnunet-* packages
<pitti> still shown as "currently building"
<pitti> will set to -1 as soon as they are shown as FTBFS
<elmo> oh, there's no backlog
<elmo> that's possibly why
<pitti> oh, wow
<StevenK> pitti: primero has moved on, you can probably rescore now
<pitti> hm, since it's properly FTBFS now, should I even?
<pitti> if I leave it like that, it won't be reattempted
<elmo> pitti: oh, bonus, please leave it like that
<pitti> IMHO we should only give it back once it's fixed
<StevenK> Haha
<StevenK> pitti: A build score of -1 is special?
<pitti> StevenK: I don't actually know if it's special, but it's veeery low :)
<StevenK> Hah. Half of -perl's builds have hit DEPWAIT
<StevenK> pitti: They'll sort themselves out, right?
<pitti> depwaits are retried automatically, yes
<soren> pitti: I just noticed you removed workrave from the seeds.. Has it been replaced, or do we just not care about it anymore?
<pitti> soren: the latter, rather, seems to be relatively dead upstream
<soren> Aw, pity.
<elmo> err?
<elmo> it had a release in July
<pitti> (just parrotting seb128)
<soren> pitti; Workrave 1.9.0 released (2008-07-14)
<seb128> pitti: I didn't say that?
<pitti> âª I'm not quite dead yet â«
<seb128> I just said we can be on sync on debian if it's universe
<pitti> seb128: hm, then I misunderstood you?
<pitti> ah
<seb128> and it was not on the CD anyway
<seb128> do we have a real interest to keep it in main?
<pitti> not an urgent one, AFAICS?
<seb128> it's rather a geek tool
<pitti> well, I wouldn't say "geek tool", everyone who types a lot can use it
<soren> I don't care much which component it's in. I was just curious if its removal from the DVD meant that there was something cool and new that I was supposed to use instead. :)
<pitti> but the standard typing break which we install by default might suffice for people, I don't know
<soren> I'm sure we'd the a lot of good-will from physiotherapists and the like if we installed it by default :)
<soren> s/the/get/ (how did that happen?)
<seb128> pitti: I don't know of anybody out of canonical who use a typing break application...
<StevenK> Woot, clutter-perl broke on hppa since libgstreamer-perl is broken. Yay, hppa. \o/
<pitti> seb128: neither do I
<StevenK> pitti: Uploading a build1 for libgstreamer-perl so it can be installable on hppa.
<pitti> StevenK: hppa's uninstallability is hideous ATM, so unless there is someone who is actually interested in hppa and fixes it in a concerted effort; so I wouldn't waste effort on fixing individual cases only
<StevenK> pitti: Isn't that lamont? :-P
<pitti> hppa has 417 out-of-dates ATM
<StevenK> Woot
<pitti> and 325 uninstallable packages in main
<pitti> really, ignore it
 * StevenK watches libopenh323 build
<StevenK> Since it causes asterisk to FTBFS. :-/
<pitti> TheMuso: I might have missed it, was there any decision about denemo and libaubio? denemo dep-waits on it
<persia> pitti: Wasn't that waiting on feedback from edubuntu folk?
<pitti> persia: I really don't know
<persia> My memory is that edubuntu required denemo in main, rather than it having anything to do with ubuntustudio, but I may be mistaken.
<pitti> right
<tkamppeter> pitti, slangasek, I have uploaded a ghostscript with fonts split off now. So bug 255485 is fixed.
<ubottu> Launchpad bug 255485 in ghostscript "ghostscript has a 300% size increase" [High,Fix released] https://launchpad.net/bugs/255485
<pitti> tkamppeter: ah, so it builds its own gsfonts package now, and the original gsfonts package is obsolete?
<pitti> tkamppeter: ah, read the bug reply; thank you!
<pitti> bryce: any idea about the inkscape FTBFS?
<pitti> StevenK: libmatchbox needs libxsettings now; MIR or drop?
<StevenK> MIR, I'll prepare one
<pitti> thanks
<pitti> StevenK: ah, that explains the matchbox-window-manager depwait, too
<StevenK> Blink. Rebuilding openh323 makes asterisk actually build
<StevenK> pitti: I'm plotting to upload asterisk for NBSing libct3, but it looks like I need build1 openh323 first :-/
<StevenK> pitti: And I'm not sure why the rebuild fixes it, but it stops libopenh323 having undefined symbols
<pitti> StevenK: ABI break without soname bump somewhere?
<mpt> Has anyone uploaded a package to Launchpad that hasn't been built yet? (This is for testing a Launchpad bug)
<persia> mpt: Do you mean never tried, or just not yet built?
<StevenK> pitti: Mmmm, somewhere.
<mpt> persia, never tried
<StevenK> mpt: Stuff is building very quickly nowish.
<bryce> pitti, news to me.  I can look into it tomorrow.
<pitti> bryce: you didn't get a mail?
<mpt> ok
<tjaalton> bryce: whot is already on it :)
<StevenK> mpt: I'm about to upload a new package if that helps you.
<pitti> mpt: I just did
<pitti> mpt: libsub-uplevel-perl
<bryce> pitti: nope
<pitti> mpt: sorry, it built already
<mpt> heh, too quick for me
<pitti> mpt: do you mean "finished building" or "not yet attempted to build"?
<mpt> pitti, not yet attempted
<mpt> I'm trying to reproduce bug 51220
<ubottu> Launchpad bug 51220 in soyuz "Package pages say Failures: None when Not yet built" [Undecided,Invalid] https://launchpad.net/bugs/51220
<StevenK> mpt: If you want to race Launchpad, I'm just about to upload openh323
<persia> mpt: Reproducing that is hard unless the build queue is long.
<mpt> StevenK, and you're ~stevenk, right?
<StevenK> mpt: Yes
<persia> Has anyone a package currently waiting in NEW?  That would do it.
<mpt> ok, I'm ready
<pitti> mpt: https://edge.launchpad.net/+builds -> no pending builds, sorry
<StevenK> Beg pitti to set the buildds to manual? :-P
<mpt> heh, it's not that important
<pitti> mpt: yes, I can temporarily disable one architecture, if you want me to
<mpt> nah
<StevenK> mpt: Done
<StevenK> (Uploaded)
<pitti> mpt: if one arch is enough? or does it need to be "needs-build" on all arches for it?
<persia> pitti: Won't help: as soon as one arch starts the build, the condition is reset.
<pitti> ok
<mpt> it's not showing up on https://edge.launchpad.net/~stevenk/+related-software
<StevenK> And lpia and hppa have already grabbed it
<mpt> meh
<mpt> never mind then :-)
<mpt> thanks anyway
<StevenK> mpt: I suspect that page needs to wait for the source to be published
<StevenK> And stuff is building before the source is published
<persia> Yes, it does wait on source publication (just checked a couple non-published sources)
<persia> mpt: Try back in November :)
<mpt> November?
<mpt> Because that's the next sync from Debian?
<StevenK> Actually, the end of October when the archive is freezing would probably work too
<persia> mpt: Right.  During autosync, there is almost always a queue > 1 hour.  Sometimes this happens just becore freezes, but a couple days before an alpha soft freeze tends to be a quiet time.
<mpt> ok
<persia> mpt: If you want to try earlier, it's worth checking during the last few days before FeatureFreeze, BetaFreeze, FinalFreeze, and Release, but it depends on how much we procrastinate (ideally these are bad times to find a full queue)
<StevenK> Surely the package sitting in unaccepted would be suitable?
<StevenK> s/the/a/
<persia> StevenK: My experience is that I don't get an entry on /+me/+packages until after it gets accepted.
<persia> Then again, I last checked that closely during a release run at the Gutsy release, so I may well be mistaken.
<StevenK> Oh, so the bug is with /+me/+packages
<StevenK> Then you need to wait for the build queue on every arch to be full
<persia> Well, that URL isn't even supposed to exist any more :)
<StevenK> Or >= 1
<persia> Sufficiently large to allow for registration of source publication prior to package builds.
<persia> mpt: You might check with calc: an OOo build might be enough to block things following it.
<StevenK> persia: That ties up one buildd
<StevenK> Per arch
<StevenK> i386 has 3
<pitti> bryce: ah, seems to be due to new poppler API; I have a look at it
<persia> StevenK: Ah, right.
<StevenK> persia: You need an OOo build and a gcc build and a firefox build
<pitti> bryce: debian bug 488170, I'll merge
<ubottu> Debian bug 488170 in inkscape "inkscape: with libpoppler3 0.8.3-1: crashes when opening PDFs," [Serious,Closed] http://bugs.debian.org/488170
<persia> Well, there are other offenders also.  ghc6 is one.
<StevenK> Ah ha.
<bryce> goddamn poppler ;-)
<StevenK> intltool-update.in -> /usr/share/intltool/intltool-update.in
<StevenK> And dpkg-source ignores deletion of symlinks. Blah.
<asac> pitti: thanks
<asac> btw, i am currently fighting some hard-disc issue :(
<pitti> bryce: seems that patch worked; I'll do the boost change, too, and upload
<bryce> ok cool
<bryce> I've really been neglecting inkscape lately.  I need to look into it some more.
<bryce> (xorg's a time sink all by itself)
 * asac reboots again, forcing a fsck
<mvo> asac: you know that the recovery menu has a fsck option now?
<pitti> bryce: argh, there's a further FTBFS, looking
<pitti> bryce: ah, that's bug 238223
<ubottu> Launchpad bug 238223 in inkscape "build failure with gtk+-2.13.x: /usr/include/gtk-2.0/gtk/gtkctree.h:110: error: âGtkCListâ does not name a type" [Undecided,New] https://launchpad.net/bugs/238223
<Spads> pitti: blast from the past, bug#26653 seems to need reopening
<pitti> Spads: the real bug is bug 247909, and seb128 seems to be on it
<ubottu> Launchpad bug 247909 in claws-mail "clawsmail ftbfs with gtk+-2.13" [Undecided,Fix released] https://launchpad.net/bugs/247909
<pitti> Spads: (in gtk+2.0)
<Spads> bug 26653 is a postgres bug
<ubottu> Launchpad bug 26653 in postgresql-common "postgresql-common 24: Causes complete logrotate failure" [High,Fix released] https://launchpad.net/bugs/26653
<pitti> Spads: oh, I thought that was a followup, sorry
<Spads> sorry, I failed at ubottu triggering :)
<pitti> Spads: seems to be debian bug 277652 ?
<ubottu> Debian bug 277652 in logrotate "logrotate doesn't work properly when a package is removed" [Normal,Open] http://bugs.debian.org/277652
<Spads> ah, possibly
<RAOF> Man, our kernel's responsiveness under IO load is really, really bad.  Is a bug the best way of communicating this?  Is #ubuntu-kernel likely to be interested?
<cpufreak> RAOF: try a different scheduler?
<asac> mvo: oh. didnt know that ;)
<RAOF> Possibly.  Reading the dpkg database shouldn't render the entire UI unresponsive for > 3 sec.
<cpufreak> is it a problem that only started occuring since you changed kernel? - or has your system always been dire under load.
<asac> mvo: can i fsck individual drives there? or just "all"?
<Spads> pitti: hmm, that bug peters out with a suggestion to make missingok more global in logrotate.d, which seems like a good idea given that this breakage occurs.
<pitti> Spads: no, that suggestion is bogus IMHO
<RAOF> cpufreak: No, Hardy didn't have the same sort of rottenness.
<mvo> asac: currently its all, but I have some code that builds a list so that it can be selected, I haven't come around to clean it up and push it though
<Spads> pitti: ah, so is it a root bug in logrotate that needs fixing overall then?
<pitti> Spads: we aren't going to change a million conffile in Debian and break compatibility of logrotate "just because"
<pitti> Spads: yes, I think so
<RAOF> I'll fiddle around with schedulers, see if anything gets better.
<asac> mvo: cool ;)
<Spads> pitti: I admit ignorance, but the suggestion was just one conf file and I have yet to see a logrotate file that did not already use missingok.
<pitti> Spads: why just one conffile?
<pitti> Spads: to fix this globally, missingok would need to be the default and essentially dropped altogether?
<Spads> pitti: the suggestion was to put it in /etc/logrotate.conf before the logrotate.d was included
<pitti> Spads: right, but that woudl change global semantics; I don't really like that, people can use logrotate for non-debian packages as well
<pitti> so *if* missingok is deprecated, it should be removed altogether
<pitti> instead of being a "mandatory option"
<pitti> so either way it is a bug, IMHO
 * Spads nods
<pitti> Spads: I subscribed to the bug now, I'll merge the fixed version when it comes
<Spads> okay thanks.
<elmo> pitti: this caused us to run up 24Gb of log files on a machine; if we hadn't been monitoring disk space, it probably would have caused service outage.  when this is fixed, it'd be nice to consider it for an SRU
<pitti> elmo: I agree
 * pitti creates an Ubuntu bug for that and links it
<elmo> pitti: thanks
<pitti> elmo: do you happen to know in which release it regressed?
<pitti> it should still be ok in dapper at least
<elmo> pitti: yeah, we haven't seen this on dapper or edgy, only hardy
<pitti> ok, thanks
<elmo> (we never ran feisty or gutsy in enough quantity to notice)
<elmo> + either way
<pitti> Spads, elmo: FYI, bug 256891 if you want to subscribe
<ubottu> Launchpad bug 256891 in logrotate "missingok does not work" [High,Confirmed] https://launchpad.net/bugs/256891
<Spads> pitti: thanks, will do
<davmor2> Today's alternative is failing to install grub :(
<ion_> Whatâs the error?
<davmor2> ion_: The 'grub' package failed to install into /target/.  Without the GRUB boot loader, the installed system will not boot.
<pitti> davmor2: anything on the Alt+F4 console?
<davmor2> pitti: the error scrolled off the screen when I transfer over I'll try it on another test system and see if I get the same issue.
<davmor2> I'll open a bug if so and add the logs to it.  Will it help to run it in the developer mode for the log files and if so what is the kernel command to do that?
<pitti> davmor2: the error should be somewhere in /var/log/ as well
<pitti> so getting/looking at those files should help
<pitti> davmor2: or just try it again and watch alt+f4 ?
<davmor2> pitti: I'll do that :)
<pitti> davmor2: thanks, appreciated!
<davmor2> pitti: grub-installer: info: Calling 'apt-install grub' failed
<davmor2> hang on
<davmor2> pitti: above it, it says: dpkg: error processing grub (--configure):
<davmor2> subprocess post-installation script returned error exit status 1
<persia> davmor2: What does it say right after "Setting up grub ..."
<davmor2> persia: ï»¿dpkg: error processing grub (--configure):
<davmor2> followed by the subprocess line
<persia> Ah.  Sometimes there is more between "Setting up ..." and "subprocess ..."
<davmor2> persia: no such luck :)
<persia> Yeah.
<davmor2> persia: pitti: I'll try it on another test machine just to confirm that it isn't a hw issue but it'll have to wait till after lunch now :)
<TheMuso> pitti: re aubio, I don't know. I thought ogra was taking care of it... Well thats what he said to me when it was first brought up during the sprint.
<pitti> TheMuso: ok, thanks (ogra is ill, BTW)
<TheMuso> pitti: Ok I just remember him saying he would write an MIR.
<geser> pitti: Hi, do you know why there are no ddebs for packages from -security?
<pitti> soren: do you have some time to look into the libvirt0-dbg uninstallability and the qemu recommends of libvirt0?
<soren> pitti: Not really, but there's no way around it :)
<soren> pitti: I'll look at it now.
<pitti> soren: I can do the upload for qemu as well if you are busy, but I don't know why libvirt0 Conflicts: to libvirt0-dbg
<soren> Err... Because they..
<soren> Oh, unversioned?
<soren> pitti: yeah, that's not right.
<slytherin> Can anyone of the archive admins move jftp to universe? bug 256609 resolved recently makes the it build with openjdk and hence all the build/runtime dependencies are now in main or universe.
<ubottu> Launchpad bug 256609 in jftp "Compile packages with default-jdk (openjdk)" [Wishlist,Fix released] https://launchpad.net/bugs/256609
<ScottK> slytherin: The usual way to handle that would be to file a bug, have it reviewed by a Universe sponsor and then they'll subscribe the archive-admins
<slytherin> ScottK: I know. I just thought if someone was around it would be done faster. :-D
<ScottK> Well an IRC ping is good for getting it down nor or not at all.  Particularly when moving something to a more Free component, I think documentation is good.
<slytherin> ScottK: Ok. Will file a bug now.
<ScottK> urgh.  Can't type ...getting it done now or not at all ...
<tkamppeter> The build server does hnot build packages for the lpia architecture currently. All uploads fail.
<persia> tkamppeter: DO you have an example?  I had some builds succeed recently.
<tkamppeter> persia, ghostscript has built on all platforms except lpia.
<pitti> slytherin: can do
<persia> tkamppeter: Odd.  Build failure appears to be problems linking to libpoppler, but poppler built cleanly on lpia on the 31st.
<persia> tkamppeter: Have you tried in a local lpia chroot?
<pitti> slytherin: moved jftp to universe
<mvo> could someone please translate http://paste.ubuntu.com/36542/ for me? something like "file does not exist?"
<mvo> (pt_PT I think)
<persia> mvo: My Portuguese is rusty, but I think it is "device or file not found".
<persia> Or yes, does not exist.
<soren> mvo: It's strerror(ENXIO)
<soren> if that helps..
<mvo> soren: it does a bit, the error comes straight from dpkg
<geser> does somebody know why there are no ddebs for packages from -security?
<pitti> geser, infinity: ^ macaroni tries to pull ddebs for -security; seems that the dak buildds don't have the ddeb hack installed?
<pitti> geser: I guess that will be fixed at least when security-in-soyuz finally becomes a reality
<soren> mvo: That's interesting.
<soren> mvo: It's trying to open /var/lib/dpkg/info/libgtksourceview2.0-common.list.
<soren> mvo: And gets ENXIO.
<slytherin> pitti: thanks.
<soren> mvo: That can only mean that that file got replaced by a device node, which does not correspond to anything in the kernel (i.e. unknown major/minor node)
<pitti> soren: thanks for libvirt update
<soren> pitti: +s.
<soren> :(
<pitti> heh
<mvo> soren: that is pretty nasty
 * soren whistles innocently
<soren> mvo: Yeah. do you happen to know which filesystem?
<mvo> soren: give me a sec, I dig out which bugnumber it was
<geser> soren: have you some time to review 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
<mvo> soren: bug #253822 - I'm happy to assign to dpkg :)
<ubottu> Launchpad bug 253822 in update-manager "Ubuntu Gutsy Gibbon's upgrade to 8.04 doesn't work" [Low,Incomplete] https://launchpad.net/bugs/253822
<soren> mvo: of course you would :) it's not dpkg's fault, though.
<soren> mvo: Something has mangled his filesystem, I'm afraid.
<mvo> soren: it was worth a try, wasn't it ;)
<soren> Heh :)
<soren> i've followed up on the bug.
<mvo> thanks
<soren> np :)
<soren> geser: I'll take a look
<soren> geser: Looks good. I'll do a quick test and upload. Thanks.
<lamego> my system is totally is randomly freezing (8.04), are there any analysis instructions for system freezes ?
<persia> lamego: First, differentiate a system freeze from an interface freeze (remote access tools are good for this).  In the case of a system freeze, use the wiki instructions on debugging the kernel; in the case of an interface freeze, use the wiki instructions on debugging X.
<lamego> it's a system freeze, ok, I will search on the wiki
<soren> geser: Uploaded. thanks!
<lamego> there is no meaningful info on the logs :\
<Chipzz> pitti, StevenK: http://log.emmanuelebassi.net/archives/2008/08/stuck-with-me/
<Chipzz> pitti, StevenK: (wrt pyclutter)
<davmor2> pitti: persia: Test just failed at the same point on different hw same error.  Do you want a bug report forming?
<pitti> davmor2: that would be nice, since it's release critical; I'll have a look at it ASAP then
<pitti> davmor2: please tell me the number after you filed it?
<davmor2> pitti: what log files etc do you need?
<pitti> davmor2: /var/log/syslog from the installation environment would be nice, if you can copy them to somewhere
<pitti> davmor2: "anna-install ssh" (or so?) might help
<pitti> davmor2: but I'll see to reproduce it locally, too
<pitti> just have a phone call coming, so can't do it right now
<davmor2> no probs I got it down to a fine art :)
<asac> pitti: could you take a look whether my NM announcement sitting in -announce moderator queue or whether it got lost somewhere?
<mvo> pitti: pedro_ did the verfication for #255666 (zdesktop in app-install-data-commercial) - if that could go into -updates, that would be great
<davmor2> pitti: bug 256989
<ubottu> Launchpad bug 256989 in ubuntu "Intrepid: Ubuntu Alternative grub install fails" [Undecided,New] https://launchpad.net/bugs/256989
<pitti> davmor2: thanks a lot!
<davmor2> pitti: any thing else you need from the debug files?
<pitti> mvo: done
 * mvo hugs pitti
<pitti> davmor2: hm, can't say yet, just returned from the call; will take a look at the bug and try to reproduce; it doesn't sound machine specific
<pitti> davmor2: thanks a lot so far
<davmor2> np's
<davmor2> I've got the files on usb drive if you need any anyway just ping me :)
<pitti> davmor2: I guess I have to manually debug the postinst and find out why it's failing
<pitti> asac: approved from u-s-a@ queue
<asac_> usa?
<pitti> erm, u-d-a
<asac_> pitti: i didnt get any mail that it "awaits moderation" ... is that a feature?
<davmor2> pitti: Pass I have no idea what you guys do it just works after :)  It a pain that evand and cj are away :)
<tkamppeter> pitti, I will do another upload of CUPS to the debian SVN in some minutes. My first approach of addition of the new PDF filters made all CUPS libraries and executables being linked against Poppler, and this caused to be all packages dependent on CUPS to need libpoppler for building.
<tkamppeter> pitti, can you quickly upload the new CUPS into Debian and sync it into Ubuntu, so that I can continue uploading dependent packages? Thanks.
<pitti> tkamppeter: yes, I can; just tell me when you are done with the changes
<tkamppeter> pitti, I have committed it now.
 * liw thought Debian was frozen
<tkamppeter> pitti, tell me when it is in Ubuntu, so that I know when I can continue uploading.
<pitti> liw: no reason to stop uploading to experimental :)
<liw> pitti, ah, experimental, that's always unfrozen yes :)
<Keybuk> awesome, someone found the lego instructions http://www.peeron.com/cgi-bin/invcgis/scans/1496-1/2?ct=1
<pitti> that just gives me an error
<davmor2> pitti: seems stgraber is having the issue with grub in vm too
<soren> vm as in kvm?
<pitti> davmor2: if we are lucky, it's just a temporary glitch due to the new kernel that landed in Ubuntu yesterday
 * soren wonders if his patch somehow got dropped
<soren> davmor2: Do you have a bug reference?
<davmor2> soren: bug 256989
<ubottu> Launchpad bug 256989 in ubuntu "Intrepid: Ubuntu Alternative grub install fails" [Undecided,Confirmed] https://launchpad.net/bugs/256989
<RicardoPerez> mvo: hi, are you busy? i would like to comment you about a bug package descriptions
<soren> kirkland: Could that be related to your changes, perhaps?
<soren> kirkland: The bug mentioned 4 lines up, that is.
<mvo> RicardoPerez: what is the bugnumber
<RicardoPerez> Bug #156278
<ubottu> Launchpad bug 156278 in ddtp-ubuntu "Package description is only partially translated to spanish" [Undecided,Confirmed] https://launchpad.net/bugs/156278
<kirkland> soren: 256989?
<soren> kirkland: Yup.
<kirkland> soren: doubtful.  according to the changelogs here: https://launchpad.net/ubuntu/+source/grub , my changes haven't been committed yet.
<tkamppeter> I have sent an e-mail to heno last week and did not get any answer. Can someone mail to heno and tell him that he perhaps does not get mail from me (spam filter or so)? Thanks-
<kirkland> soren: could you sanity check that changelog for me?
<ion_> Perhaps grubâs postinst should just have âexit 0â at the end. :-)
<mvo> RicardoPerez: thanks for brining that bug to my attention, have you checked if the amule trasnlation finally made it into intrepid (http://archive.ubuntu.com/ubuntu/dists/intrepid/universe/i18n/Translation-es) ? I see two possible reasons for the lack of the translation, one is a bug in the software that gets them from LP and puts them into the archive, the other one is that we just did not run the import often enough and missed hardy (also t
<mvo> hat sounds unlikely because you mentioned that it got translated a while ago?)
<RicardoPerez> I'll see now if the translation is in intrepid
<mvo> thanks
<RicardoPerez> I just see that the translation is not in the intrepid's Translation-es
<RicardoPerez> neither in Hardy's
<soren> kirkland: Oh, I thought you said that cjwatson had sponsored them.
<RicardoPerez> this is the translation: https://translations.edge.launchpad.net/ddtp-ubuntu/ubuntu/+pots/ddtp-ubuntu-universe/es/552/+translate
<mvo> RicardoPerez: thanks, that means there is a bug in the script that collects/generates the translations
<pitti> tkamppeter: uploaded to Debian and Ubuntu; so the .debs should be in the archive at 20:00 CEST
<RicardoPerez> mvo: thanks to you. I don't know if this problem affects only to amule
<soren> kirkland: I didn't even bother to check, I'm afraid. Sorry about the noise then.
<mvo> RicardoPerez: ok, I have a look. the current system will only write out the package translation if all bits of the description can be translated, that might be a reason
<mvo> RicardoPerez: probably not, but that looks like a good example
<soren> kirkland: Oh.
<kirkland> soren: no worries, i'm knee deep in grub at the moment actually
<soren> kirkland: https://edge.launchpad.net/ubuntu/+source/grub-installer
<RicardoPerez> mvo: is there any difference in the generation procedure from universe to main?
<soren> kirkland: So some of the changes were certainly sponsored.
<RicardoPerez> mvo: i ask you that because i don't know if the problem could appear in main too
<kirkland> soren: ah, right.  that's grub-installer, which is what the cd uses, so that's a distinct possibility
<kirkland> soren: I'll look at the bug ASAP
<mvo> RicardoPerez: the generation is the same, but for universe it needs to go through more data, maybe that triggers the bug?
<RicardoPerez> move: i don't know, actually. i can't see the problem in main, presently
<mvo> interessting, I will keep that in mind when debugging the problem
<RicardoPerez> i would like to do more investigation in order to get if the problem is in main too
<RicardoPerez> mvo: thank you very much. some spanish translators are sad because his work are not being finally used...
<mvo> RicardoPerez: I totally understand that, please tell them that I'm sorry and that I'm looking into it
<RicardoPerez> mvo: of course, thanks a lot for your attention :)
<RicardoPerez> mvo: by the way: the problem is in main, too
<RicardoPerez> i just see that
<RicardoPerez> the following translation is not in Translation-es in hardy: https://translations.edge.launchpad.net/ddtp-ubuntu/ubuntu/+pots/ddtp-ubuntu-main/es/36/+translate
<RicardoPerez> translated on 2006-08-16
<RicardoPerez> is not in intrepid's Translation-es, neither
<RicardoPerez> i just commented that in the bugreport
<pitti> soren: any idea why /dev/kvm isn't in group kvm any more?
<soren> pitti: I can't imagine why. It's fine on my system
<soren> (which hasn't been rebooted for afew days, though)
<pitti> soren: other q, can I boot a 64 bit image on a 32 bit installation somehow?
<pitti> soren: (I have a 64 bit capable cpu)
<soren> pitti: Depends on your kernel.
<pitti> soren: grep kvm /etc/udev/rules.d/* -> nothing, BTW
<soren> pitti: If it's a 64 bit kernel, but 32 bit userland, you're fine.
<pitti> soren: ah, great; I'll install a 64 bit kernel then
<soren> $ grep kvm /etc/udev/rules.d/*
<soren> /etc/udev/rules.d/45-kvm.rules:KERNEL=="kvm", NAME="%k", GROUP="kvm", MODE="0660"
<soren> pitti: You don't have /etc/udev/rules.d/45-kvm.rules ?
<pitti> nope
<mvo> RicardoPerez: thanks
<soren> pitti: That's um...
<soren> pitti: Really? Wow.
<RicardoPerez> mvo: thanks to you again :)
<pitti> soren: trying dpkg -S 45-kvm.rules now
<soren> It's certainly from the kvm package.
<pitti> soren: nothing found; maybe it got dropped from the package recently, and you just have it as an obsolete conffile?
<pitti> soren: grep 45-kvm.rules /var/lib/dpkg/status  for you?
<soren> pitti: erk... How did that happen?
<pitti> merge error? I don't know
<soren> Must be. *facepalm*
 * soren goes to fix.
 * pitti notices that installing the 64 bit kernel overwrites his 32 bit kernel package
<pitti> but *shrug*
<pitti> soren: thanks muchly
<pitti> but we have last-good-boot, so I should be safe :) brb
<soren> pitti: New kvm in the pipes..
<poningru> I created a deb package using dkms, I was wondering if anyone had any idea on how to include your gpg signage just like in normal pbuilder
<poningru> pitti, ^^ ?
<mdz> soren,pitti: I noticed /dev/kvm permissions being wrong as well
<mdz> soren,pitti: and I also have no /etc/udev/rules.d/*kvm*
<RainCT> pitti: what license has http://people.ubuntu.com/~pitti/scripts/buildd.py?
<mdz> soren: ah, I see your upload fixed it
<mdz> soren: what caused it to go missing?
<mdz> (dh_installudev I mean)
<geser> poningru: does dkms create also a source package?
<poningru> geser, yes that is an intermediary step
<poningru> one does dkms build
<poningru> and then dkms makedeb
<poningru> which gives you a deb
<poningru> geser, ^^
<geser> poningru: then you can call debsign on the .dsc to sign the source package
<poningru> oh!!
<poningru> DOH
<poningru> thanks
<geser> the debs itself aren't signed
<poningru> just the dsc?
<geser> poningru: yes
<geser> poningru: why do you want to signed it?
<soren> mdz: I'm not entirely sure. Debian accepted almost all my changes a few months ago, but apparantly not the dh_installudev rule. I must have missed that fact when I did the merge.
<poningru> geser, I thought it was good practice in general to sign one's packages
<poningru> I dont really care that much but still...
<soren> mdz: I'm rather surprised Debian doesn't ship it.
<mdz> poningru: signing .debs isn't particularly common
<mdz> signing the archive is generally more useful
<ScottK> Probably a good idea if distributing outside an archive.
<poningru> mdz, I dont really have an archive
<poningru> mdz, the reason for signing the deb is because I am sharing it through rapidshare
<mdz> poningru: why not put it in a Launchpad PPA instead?
 * soren calls it a day
<ScottK> mdz: It's unsigned there.
<pitti> poningru: unpack the source, debuild -S
<pitti> poningru: usually you would use debsign to sign the sources.changes, but since dkms doesn't give you one, you have to rebuild the source
<pitti> RainCT: buildd.py> I couldn't care less; public domain
<mdz> ScottK: yes, but at least it's in an archive, the hosting is free and it does the builds for you
<pitti> oooh, I just rebooted, and I have compiz now
<pitti> seb128, mvo: ^ w00t!
<RainCT> pitti: Okay, so we can put it into ubuntu-dev-tools as GPLv2+ (all the other files there are GPL)?
<seb128> pitti: that must be an error
<pitti> RainCT: fine for me
<RainCT> jpds: ^
<seb128> pitti: nothing changed that should do that
<poningru> mdz, yeah plan on doing that soon-ish
<RainCT> pitti: Great, thx :)
<ScottK> mdz: Given the current state of the art in DNS cache poisoning, I think relying distribution of any unsigned code is not entirely prudent.
<pitti> seb128: well, I haven't rebooted since middle last week or so, just hibernate/resume
<pitti> meh, my cursor keys don't work in kvm
<pitti> did anyone else notice that?
<mdz> ScottK: it is no worse than what he is doing today in that regard, and significantly better in others.  what is the issue?
<pitti> soren: any idea about cursor keys in kvm?
<pitti> soren: oh, and btw, running 64 bit kernel works fine now, amd64 alternate boots
<ScottK> mdz: I thought he was trying to sign it so it would be an improvement.  PPA offers convenience at the expense of security compared to that.
<mdz> last I checked, nobody used dpkg-sig anyway, so the signatures don't get verified
<pitti> soren: they do work under normal X, and in the kvm window in ctrl+alt+2
<poningru> pitti, thanks
<poningru> pitti, what vid card do you have?
<jernejovc> hi, what's the name of xscreensaver dev library package in ubuntu?
<mdz> jernejovc: what are you looking for inside?
<jernejovc> mdz:I need it for compiling kde4powersave: X11_Xscreensaver_LIB (ADVANCED)
<mdz> jernejovc: oh, I thought you meant xscreensaver the application (which doesn't have a dev library)
<mdz> jernejovc: perhaps it wants libxss-dev?
<mdz> (which is the X11 screensaver library)
<jernejovc> mdz:aaah yes, that's it, I was searching for that, thank you very much indeed :)
<jernejovc> See you later, thanks for your help!
<kirkland> slangasek: ping me regarding grub, if you come around
<tkamppeter> On which channel one can talk about Launchpad/web site problems?
<kirkland> slangasek: i have updated bug 33649 with a comment, in case I'm not around when you see this
<ubottu> Launchpad bug 33649 in debian-installer "root raid installs have bad grub config" [High,Confirmed] https://launchpad.net/bugs/33649
<Keybuk> why does evince move and resize its window when the document I'm viewing changes?
<tseliot> tkamppeter: try on #launchpad
<pitti> poningru: intel gma945
<poningru> ah
<poningru> wait what!!!
<poningru> AWESOME
<poningru> so removal from the blacklist then?
<mdke> can anyone shed any light on what is causing the build error here - https://bugs.edge.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/256619/comments/3
<ubottu> Launchpad bug 256619 in gnome-user-docs "please upload gnome-user-docs from bzr" [Undecided,Incomplete]
<geser> mdke: the last time I had a similar error, adding --disable-scrollkeeper to the configure call helped
<geser> this works only if configure knows this option
<mdke> geser: do you know if scrollkeeper has been replaced in intrepid?
<mdke> I wonder if the reason that the build worked for me is that I was building on my hardy machine
<mdke> i know it was in the works to get rid of scrollkeeper
<tjaalton> pitti: check that you have correct kb model in kvm
<mdke> from the changelog nothing seems to have been done to it
<slangasek> kirkland: hi, ok, will look at that (asynchronously)
<kirkland> slangasek: sounds good, thanks.
<geser> seb128: do you the state of scrollkeeper/rarian in intrepid?
<pitti> tjaalton: ah, there is a cmdline switch for it? I never needed to fiddle with this so far
<mdke> geser: does --disable-scrollkeeper have any side effects?
<geser> mdke: I don't know, that was the proposed fix from seb128 for a similar build error
<tjaalton> pitti: is it a new install? it should be correct then. I meant that in gnome you need to make sure the model is evdev
<pitti> gnome!
<pitti> tjaalton: I'm not even getting past d-i
<tjaalton> pitti: hehe, ok :)
<pitti> tjaalton: cursor keys don't work in gfxboot nor in d-i
<slangasek> mbiebl: ping
<pitti> and I wasn't really able to finish the install without cursor keys
<mdke> geser: ok then, I'll suggest it on the bug, thanks
<pitti> aside from that, kvm is unbearably slow again today, so I'm switching to vmware for now on my other box
<seb128> geser: you lack some verb there?
<mdke> seb128: "know"
<seb128> mdke: they are updatodate?
<mdke> seb128: the question was meant to be whether scrollkeeper has been demoted in favour of rarian yet
<mdke> I have had a build error with gnome-doc-utils and geser was helping me diagnose it
<mdke> gnome-user-docs, sorry
<geser> seb128: one of the build errors where the build fails when calling scrollkeeper-update (see bug #256619 for log)
<ubottu> Launchpad bug 256619 in gnome-user-docs "please upload gnome-user-docs from bzr" [Undecided,Incomplete] https://launchpad.net/bugs/256619
<geser> my suggestion was to add --disable-scrollkeeper if configure supports it
<seb128> yes, that's what should be used for packages
<seb128> the scrollkeeper update is ran on the client side and should not be ran during the build
<mdke> seb128: does adding that have any side effects?
<seb128> otherwise rarian is in main and used at runtime in intrepid but scrollkeeper has not be demoted and since most packages still build-depends on it it's used in builds
<mdke> ah, interesting, thanks
<seb128> mdke: no, it's made exactly for this usecase
<mdke> seb128: so should packages be moving to rarian?
<mdke> like ubuntu-docs, for example, calls scrollkeeper-update in the postinst I think
<seb128> not especially, rarian provides scrollkeeper
<mbiebl> slangasek: pong
<mdke> seb128: so there is no point amending that? One of the main problems with ubuntu-docs recently has been that it can take a long time running scrollkeeper-update, and we get a lot of bug reports from people who run out of memory during that or just get bored and interrupt the process
<seb128> mdke: which means when scrollkeeper will me moved to universe rarian will be use automatically
<mdke> seb128: I wondered if it is really necessary to run scrollkeeper-update
<seb128> mdke: intrepid should have no such issue since rarian is installed and used a runtime and the scrollkeeper-update rarian command should not have this issue
<mdke> seb128: ok, understood. Thanks for explaining that to me
<slangasek> mbiebl: hi; could you have a look at bug #211631? (the comment at the bottom is the one most relevant to you, I think)
<ubottu> Launchpad bug 211631 in wpasupplicant "CIFS/SMBFS issue (was not resolved on #207441)" [Medium,Confirmed] https://launchpad.net/bugs/211631
<slangasek> mbiebl: I suppose I should have subscribed you to this bug as well, I only just now noticed you don't appear to get dhcdbd bug mail :)
<pitti> seb128: seahorse binary NEWed, FYI, so feel free to upload libcryptui-dev rdepends
<bradleat> #ubuntu-motu
<bradleat> sorry
<seb128> pitti: thanks
<pitti> tkamppeter: I just looked at the splix FTBFS; so that build can be reattempted once the new cups is in the archive, right?
<seb128> pitti: seahorse-plugins is buggy so I'm waiting on a new tarball, they didn't change the translation domain and some other things so there is some conflict between searhose and seahorse-plugins
<mbiebl> slangasek: problem is, that /usr could be on NFS
<pitti> tkamppeter: (which is the case now; given back splix)
<mbiebl> I agree that NM and dhcdbd could be moved later in the shutdown sequence, but not after S31
<slangasek> mbiebl: then this is a regression compared to pre-NM behavior :/
<mbiebl> slangasek: it is
<mbiebl> the only way to fix this, is to dump the idea of /usr via NFS
<slangasek> or dhcdbd is in the wrong place
<pitti> speaking of that, dhcdbd is deprecated, isn't it? asac?
<mbiebl> yep, it's gone with NM 0.7
<pitti> n-m doesn't depend on it any more, and it moved to universe
<slangasek> ah
<slangasek> well, that helps then...
<mbiebl> still, as soon as NM is shutdown, the interfaces are brought down.
<pitti> does NM need to be shut down at all?
<pitti> there's no init script for it, and rightly so IMHO
<mbiebl> pitti: there is, at least on debian
<pitti> mbiebl: yes, but not in intrepid's n-m packages
<pitti> Debian didn't pervasively kill nonsensical rc0/6 K scripts yet
<emgent> Bug #256880
<ubottu> Launchpad bug 256880 in ubuntu "ubuntu helps spreading windows viruses" [Undecided,New] https://launchpad.net/bugs/256880
<emgent> LOL!
<pitti> wine bug?
<mbiebl> pitti: well, if you want to shutdown NM cleanly, it should be done before dbus is killed.
<mbiebl> and dbus is kill by sendsigs
<pitti> mbiebl: but isn't the sendsigs kill axe enough? or does it cause the n-m error messages on shutdown?
<mbiebl> you'll get an awful lot of error messages on stdout/stderr if you kill NM by sendsigs
<pitti> right, I noticed
<pitti> but that's mostly a cosmetical problem, right?
<pitti> or does it cause any actual grief?
<liw> would anyone be interested in giving system-cleaner (command line version) a try? it's in my PPA (https://launchpad.net/~liw/+archive), packaged for hardy?
<liw> I'm interested in any and all feedback, particulary on the usability of the command line interface
<mbiebl> pitti: you mean besides a crashing NM on every shutdown?
<pitti> mbiebl: that's the bit we need to fix, yes :)
<pitti> but I mean actual problems with network connections, VPNs, /usr on NFS, or whatnot
<mbiebl> I'd say that dispatcher scripts will no longer be run, stuff like that.
<infinity> pitti: /usr on NFS and using NM are kinda mutually exclusive things...
<pitti> erm, true that
<infinity> pitti: Unless you move NM to /, and allow a default root NM config.
<mbiebl> infinity: [20:46] <mbiebl> the only way to fix this, is to dump the idea of /usr via NFS
<pitti> so it should just die a little more gracefully then?
<pitti> infinity: initramfs! initramfs!
<infinity> mbiebl: We can't ever "dump" the idea, but saying that "NM users can't have remote /usr" seems sane.
<pitti> well, at least not for their primary ethernet
<infinity> The two use cases (roaming networks, versus very static networks of machines sharing filesystems) seem pretty mutually exclusive anyway.
<pitti> you can still use it for other stuff, like VPNs
<infinity> Can't see how I'd want /usr-over-NFS on my laptop in a hotel.
<infinity> pitti: Okay, yeah, you could use /etc/n/i for the primary connection and NM for VPNs, but that would "just Work" anyway.
<Chipzz> infinity: maybe the hotel provides you with laptops and /usr-over-NFS ? :)
 * Chipzz ducks :P
<mbiebl> anyway, about the samba unmount issue: wouldn't it be better to do that wie a dispatcher script?
 * Chipzz thinks NM is a fundamentally broken concept, anyway
<infinity> (I would like to see NM be able to do very basic interfaces(5) stanza creation via gksudo for static entries, though.
<infinity> )
<infinity> Since it all feels like it should be in one spot.
<mbiebl> infinity: 0.7 will allow for something like that
<pitti> especially since it is supposed to supersede network-admin
<infinity> Exactly.
<soren> pitti: Not quite yet. We're trying to work it out, but evdev is no fun at all to deal with.
<pitti> soren: ah, so that's a known problem and not just my stupidity?
<soren> pitti: Oh, yes.
<mbiebl> pitti: you were asking, why NM needs to be shutdown at all (and deconfigure the network interfaces)
<mbiebl> it guess it's basically the same, why we have a S36ifupdown
<soren> mdz: Oh, apparantly Debian frowns upon packages providing udev rules, so they have rules for kvm in their udev package instead.
<mbiebl> pitti: another way to address the issue would be, to be able to shutdown NM without it bringing down the interfaces.
<mbiebl> that way it wouldn't matter, when we stop NM during shutdown.
<pitti> mbiebl: you mean we'd still need net interfaces even after sendsigs?
 * soren wanders off again
<mbiebl> pitti: sure, S31umountnfs.sh is run after sendsigs
<pitti> how weird
<mbiebl> pitti: it's basically the /usr on NFS issue again.
<mbiebl> you musnt't have processes blocking /usr
<mbiebl> so you have to kill all processes in advance.
<mbiebl> another idea would be, to split up umountnfs.sh
<mbiebl> on that unmounts *non*critical net filesystems and is run pretty early during shutdown
<pitti> right
<pitti> so the "make n-m die gracefully" would be to die silently and leave the network state alone?
<pitti> that should work AFAICS, and avoids introducing yet another shutdown init script
<mbiebl> pitti: yes, it should solve the net fs issues.
<Chipzz> I don't see why NM should shutdown the network when it's shutdown in the first place
<pitti> right
<Chipzz> but like I said: I consider NM to be fundamentally broken in the first place :P
<pitti> well, if it spawned VPN daemons, it should shutdown those, presumably
<Chipzz> and not just in that regard
<liw> acpi should work on desktop machines, not just laptops, right?
<mbiebl> pitti: well those vpn daemons would be killed by sendsigs.
<mbiebl> dunno about other type of connections like gprs etc. which NM supports in 0.7
<mbiebl> if it is necessary to correctly deconfigure such a connection.
<pitti> davmor2: I could reproduce the grub error, but chrooting into /target and apt-get -f install works; hmm
<davmor2> pitti: I got no idea that's why I test rather than fix :)
<pitti> davmor2: just telling you that I can reproduce it
<davmor2> :)
<davmor2> pitti: reading the bug report kirkland couldn't on server so what have done/not done that desktop have?
<pitti> davmor2: I'll test it again on tomorrow's alternates; might really just be bad timing with the new kernel
<pitti> alternates are built at a different time
<kirkland> davmor2: I'm just now testing on 32bit/alternate
<pitti> kirkland: I tested amd64 alternate from today
<kirkland> davmor2: can you confirm: e8690886f89ef8e9c92ed86a6fbb5790 *intrepid-alternate-i386.iso
<kirkland> pitti: ah, okay, you did reproduce it...
<pitti> yes
<davmor2> kirkland: 2 ticks i'll run it against the iso to be sure
<kirkland> pitti: given your statement about tomorrow's alternates, i'm going put this bug aside for now
<pitti> yeah, me too
<pitti> if it still happens tomorrow, I'll have a deeper look
<kirkland> pitti: i'm confident my recent grub work could not have caused this
<davmor2> kirkland: just to confirm the iso md5sum match
<kirkland> davmor2: gotcha, okay
<davmor2> kirkland: pitti:  I'll be smoke testing again tomorrow morning between 8-12 am uk time so I can test an alt first and ping you early if that would help?
<johninlex> hello all
<johninlex> is this where everyone is for 8.10???
<pitti> bwah mono
<johninlex> thank you all fro having it posted up top
<MetaMorfoziS> Hi all
<MetaMorfoziS> I don't know, but if any help needed with testing on eee 1000h, then i can help with it
<pitti> MetaMorfoziS: we are always happy about people testing the alphas on various hardware
<pitti> MetaMorfoziS: we'll release alpha-4 next Thursday, so please feel free to grab that, test it on the eee, and report your results
<pitti> does today's live CD start properly for anyone? I just get a hang when X starts
<sbeattie> pitti: you might ask over in #ubuntu-testing
<hwilde> anybody got wireless roaming problems with lwapp?  :((
<pitti> zul: just checking, php5 is still FTBFS, does that cause any problems for alpha-4?
<pitti> zul: it's fine from the installability side of things, but I don't know which functional stuff it fixes
<Nafallo> pitti: we haven't got a php-based installer yet? ;-O
<BenC> Is it a known issue that evolution is doing really whack shifting effects when I compose an email?
<BenC> slangasek: ping
<seb128> BenC: bug #255805
<ubottu> Launchpad bug 255805 in gtk+2.0 "evolution compose widget not updating correctly" [High,Triaged] https://launchpad.net/bugs/255805
<norsetto> hey seb128, just wondering, is libgail18 supposed to go away?
<seb128> norsetto: yes, it's in libgtk now
<norsetto> seb128: ah ok!
<norsetto> seb128: thx, so, I guess gnome-main-menu has to be rebuilt (since its binaries still depends on it)
<tkamppeter> pitti, thanks, then I will upload ghostscript now, as I had to fix some small bugs there.
<seb128> norsetto: gnome-main-menu needs to be updated to the new upstream version now that we have nm0.7
<seb128> norsetto: I'm not sure the current version will build using nm0.7
<norsetto> seb128: ok, let me see into that
<seb128> cool, thanks
<seb128> norsetto: http://ftp.acc.umu.se/pub/GNOME/sources/gnome-main-menu/0.9/gnome-main-menu-0.9.10.tar.gz
<norsetto> seb128: got it, thx
<norsetto> seb128: oh well, looks like RAOF is on it (bug 234769)
<ubottu> Launchpad bug 234769 in gnome-main-menu "update to new gnome-main-menu" [Wishlist,Confirmed] https://launchpad.net/bugs/234769
<tkamppeter> pitti, ghostscript is uploaded now.
<pitti> tkamppeter: for pdf workflow?
<seb128> norsetto: good
<slangasek> BenC: hi
<BenC> slangasek: Hey...I have an acpi-support upload to get rid of toshiba stuff (new tlsup driver makes it obsolete)...anything I should be wary of on an upload, or do you want the debdiff first?
<slangasek> BenC: an upload to intrepid, right? :)
<BenC> slangasek: of course :)
<slangasek> BenC: no concerns from me, then. :)
<BenC> slangasek: thanks...I'm holding it off until after alpha4 (when the next kernel upload happens)
<slangasek> ok, cheers
<emgent> hello people
<calc> how do you do the firefox string replacement bookmark thing?
<calc> set keyword to foo and the part you want to replace with %s (or something like that)
<asac> pitti: yes, dhcdbd is deprecated. there is a new alternative called "dhcpcd" however ;) ...
<asac> mbiebl: i dont shutdown NM at all at shutdown atm
<asac> mbiebl: not sure if that was the topic above though ;)
<mbiebl> asac: dhcdbd and dhcpcd serve different purposes
<mbiebl> dhcpcd is an alternative dhcp client, dhcdbd was simply a dbus wrapper for dhcp3-client
<asac> mbiebl: which is also a dhcp client ;)
<mbiebl> asac: huh?
<mbiebl> anyway, the problem still persists as S31unmountnfs.sh is run after sendsigs
<asac> mbiebl: so after forcefully killing NM?
<hwilde> anybody got wireless roaming problems with lwapp?  :((
<macd> Ive been asking around gnome, gtk, ubuntu for a few days with no ideas
<macd> Any gnome/gtk app that utilizes the save as dialog box, takes about 4 or 5 minutes to show up, ideas why?
<macd> Attempts to strace any gnome/gtk app also result in X hard locking
<macd> Or GDM I really cant tell
<tormod> bryce: I need some sponsor love, can you look at bug #255446? you did that package last time
<ubottu> Launchpad bug 255446 in laptop-mode-tools "please merge laptop-mode-tools 1.45-1 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/255446
<bryce> sure
<tormod> bryce: thanks a lot
<RAOF> asac: Here?  gnome-main-menu is complaining about missing NM dev headers, but my network connection is sucking and I can't grab the source.  It seems to believe that nm-glib should contain nm-device-802-11-wireless.h and nm-device-802-3-ethernet.h.
<RAOF> asac: If you're not here, don't worry.  My network will eventually stop sucking and I'll be able to work out what's happening.
<asac> RAOF: nm-device-wifi.h and nm-device-ethernet.h its now called
<asac> RAOF: what does gnome-main-menu do with those?
<RAOF> Well, FTBFS at the moment.  But what it will do with those is use them to build its network status thingy.
<RAOF> So g-m-m requires NM 0.7, but not to recent a snapshot? :)
<asac> RAOF: network status is fie, but whatfor the device headers?
<asac> fie==fine
<RAOF> I haven't investigated much yet; it looks to be wanting to call nm_get_device_info to get AP, bitrate, netmask, etc.
<wgrant> asac: Why aren't the NM VPN plugins built from the NM source package?
<wgrant> They seem to be there.
<RAOF> Ah, well.  gnome-main-menu obviously needs more work than just fixing missing headers.
#ubuntu-devel 2008-08-12
<asac> wgrant: historic reasons
<asac> RAOF: where are those headers includedd?
<asac> i dont see anything that looks like a header include with nm-device :)
<RAOF> asac: In main-menu/src/network-status-agent.c
<asac> RAOF: thats just NetworkManager.h
<asac> which is shipped in network-manager-dev
<RAOF> asac: It already includes that.  At least, I think it does... :)
<RAOF> Anyway, I'll have a better look later; it doesn't appear that it'll be trivial at this point.
<zul> pitti: yeah I know about it, Im trying to find a fix for it having no luck
<rexbron> Hey, when is the new upstart slated to hit ubuntu? Will it make it into intrepid?
<nxvl> upstart?
<rexbron> upstart.ubuntu.com
<foxxtrot> Question about packaging for python.  The package has a Python Module, and a script which acts as a program which interfaces with the module.  Should this be split into two packages?
<rexbron> perhaps my question is best directed at Keybuk :)
<rexbron> foxxtrot: Would another application be able to make use of that module?
<foxxtrot> Yes it was designed to be developed against, however it is a pretty special purpose scientific package, so I'm unsure if anyone would want the Python module but not the application
<rexbron> foxxtrot: Consider splitting the module out into its own binary package
<foxxtrot> That's what I was thinking, felt it was worth checking.  Unfortunately, the package doesn't have a true Makefile, so I'm going to have to see if the setup.py can be set up to 'install' to the debian/ directory
<rexbron> foxxtrot: --prefix=
<rexbron> something like python setup.py install --prefix=$(CUR_DIR)/debian/tmp/
 * rexbron cant remember off the top of his head if that is the correct varriable
<foxxtrot> The INSTALL file seems to be indicating --home= which doesn't seem nearly as correct as --prefix= would be, but the code backs it up.
<rexbron> and foxxtrot, #ubuntu-motu is a more appropreate place for general packaging questions :)
<foxxtrot> Fair enough
<foxxtrot> I'll join that channel as well then
<persia> Does anyone happen to know why sl-modem-daemon is in restricted rather than multiverse?  I can't find any reverse package relationships that would keep it there.
<TheMuso> persia: The source for the kernel driver afaik.
<TheMuso> If not the source for all of it.
<persia> TheMuso: sl-modem-source is already in multiverse.  Am I missing something?
<TheMuso> persia: Are they not from the same source package?
<persia> TheMuso: They are.
<nxvl> Keybuk: ping
 * persia files a bug on sl-modem to solicit more response.
<Dekans> Is it normal to have X11 and gkt libs dependencies with tomcat ??
<Dekans> on ubuntu server i don't want those useless libs
<Dekans> I downloaded tomcat from its official website instead
<persia> Dekans: Unfortunately.  I believe that Koon just fixed that for intrepid, but please file a bug on similar issues.
<Dekans> I don't understand these dependencies
<Dekans> Ah ok
<Dekans> perfect
<Dekans> :)
<Dekans> understood
<persia> You'll find that the issue is that the JRE depends on X.  Getting that which can be headless to use a headless JRE is work in progress.
<Keybuk> nxvl: I am actually here
<Keybuk> what's up?
<nxvl> Keybuk: rexbron have just make me notice upstart
<Keybuk> ?
<nxvl> Keybuk: what the state of it, and when can be start to safetly play with it
<Keybuk> do not use for now
<nxvl> i'm installing it on a VM
<nxvl> just for testing
<persia> Keybuk: No?  Why not?
<Keybuk> persia: because it's just about to undergo a fundamental redesign
<Keybuk> so anything you do now won't work next month
<persia> Oh, next month?  That's actually fairly positive news.  I thought maybe intrepid+1.
<Keybuk> well, yeah, intrepid+1
<Keybuk> certainly not going to land anything like that for intrepid
<Keybuk> not until we hire a new desktop team lead anyway :p
<Dekans> where can we suggest new apps to integrate in the repos ?
<rexbron> Keybuk: so is 0.5 stable enough for intrepid?
<Keybuk> no
<rexbron> ok
<Keybuk> well
<Keybuk> it's stable
<persia> Dekans: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<Keybuk> but I don't really want to support it ;)
<persia> Keybuk: Should packages that use it now migrate away from it?
<Keybuk> no packages use it now
<persia> Err, yes some do.
<Keybuk> which?
<persia> ume-config-common is an example.
<Keybuk> does it use it in vaguely sane ways?
<persia> /etc/event.d/session handles running startx in the absence of GDM.
<Keybuk> sounds fair
<Keybuk> won't be hard to convert later on
<persia> OK.  So use is acceptable, but users should be prepared for a migration for intrepid+1?
<Keybuk> exactly
<persia> (and upstream isn't going to support the current version)
<Keybuk> you'd have a migration if we shipped 0.5
<Keybuk> so I'd rather skip that migration in Ubuntu
<Keybuk> so 0.3 -> 1.0 will be a migration
<nxvl> Keybuk: < Keybuk> not until we hire a new desktop team lead anyway :p ?
<Keybuk> nxvl: then I can go back to development full-time
<nxvl> Keybuk: as in you won't accept it, or as in you are quiting?
<nxvl> oh
<nxvl> ok ok
<rexbron> Keybuk: us studio guys are looking at writing some upstart jobs and are looking for a nice clean way to manage them (chaning values then restarting the job). I saw that 0.5 has dbus support
<Keybuk> nxvl: I'm stepping down, thus the job description on the website
<Keybuk> rexbron: right, it does
<Keybuk> but d-bus has lots of bugs
<nxvl> Keybuk: i don't understand
<Keybuk> and upstart is a great tool for finding bugs in other pieces of software
<nxvl> Keybuk: as in it's not what you expected?
<Keybuk> especially security bugs
<Keybuk> nxvl: after 18 months of management, I've decided that my heart lies with development
<nxvl> yeah
<Keybuk> nxvl: so am stepping down as the ubuntu desktop team lead, and going to become a developer full-time again
<rexbron> well, faling that, calling start and stop from a subprocess shell works, if not as elegantly :P
<nxvl> after 4 months in advisory i have decided the same
<Keybuk> nxvl: this can't happen until we hire a new team lead
<nxvl> :D
<nxvl> Keybuk: but still in the ubuntu-desktop team?
<Keybuk> nxvl: I'll be moving to the ubuntu foundations team
<Keybuk> which better fits the stuff I hack on
<nxvl> foundations as in platform?
<lifeless> mm concrete
<Keybuk> right
<nxvl> or is it a new team?
<nxvl> ah ok
<TheMuso> lol
<Keybuk> lifeless: I do the plumbing, that goes under the concrete
<Keybuk> but above the water mains
<lifeless> Keybuk: not the girders?
<nxvl> i feel better to know that Keybuk is not going away :D
<Keybuk> rexbron: 0.5 was an attempt to fix the problems we had with 0.3
<Keybuk> rexbron: instead it created lots of fascinating new problems
<Keybuk> rexbron: and thus didn't solve anything
<rexbron> Keybuk: I see
 * jdong sees that he is joining Keybuk on the dark capacitative touchy side with his new shiny iPhone 3G :D
<persia> Consider it integration and compatibility testing...
<jdong> :)
<RAOF> That's the sort of integration testing I can get behind. :)
<jdong> oddly I do agree with his two cents on Linux's API fragmentation
<jdong> in the little bit I did experiment with writing native iPod Touch apps, I found it surprisingly easy to learn
<RAOF> I've heard Objective-C isn't evil.
<jdong> it's not bad. Perfectly bearable
<jdong> maybe it's just because it's different and for that sole reason satisfies the nerd inside me
<jdong> but from the perspective of an internet-enabled smartphone, the iPhone is still one of the best things I can get here in the states
<jdong> the after-market modding community is simply enormous too
 * jdong wishes there's a way to buy free time to explore all this stuff
<persia> jdong: One can purchase free time.  One saves up, and declares that one is on sabbatical for N months.  As long as one pre-arranges the end of the sabbatical, it's fairly safe.
<calc> wow the new lenovo W700 is amazing, but huge
<calc> http://www.engadget.com/2008/08/12/lenovo-intros-the-monstrous-thinkpad-w700-and-we-get-our-hands/
 * calc isn't sure amazing is enough to describe it
<StevenK> How huge?
 * persia suspects about 30 minutes of battery life
<cody-somerville> Can anyone shed a bit of insight onto as to why Packages.gz failed the md5sum check in the Xubuntu cd build? http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/xubuntu/intrepid/daily-live-20080811.log
<pwnguin> calc: thats just terrible
<StevenK> persia: While pedalling furiously?
<persia> StevenK: And flapping one's arms vigorously.
<pwnguin> calc: toshiba makes some nice traditional tabletPCs
<StevenK> persia: :-D
<StevenK> That isn't a laptop, that's a desktop that you can close.
<RAOF> I was tempted by 17" laptops when I bought mine.
<RAOF> I'm glad I didn't; I didn't really know how I'd be using it.  My next laptop will be smaller :)
<Chipzz> StevenK: saw my comment yesterday about pyclutter?
 * StevenK likes his X40
<StevenK> Chipzz: I did, thanks. "Exercise patience, and upstream will release 0.8."
<Chipzz> or "SVN is in a more usable state"
<RAOF> Maybe upstream would like to release clutter-sharp sometime, too.  Grr.
<StevenK> RAOF: My next laptop will be something about the same size of my current X40, or a little bit larger.
<Chipzz> StevenK: you could consider shipping an svn snapshot?
<calc> i think i will get an X200 for my next machine or whatever replaces it by then
<persia> StevenK: The difference is that it has a battery.  While not so common now, the all-in-one models with flip-close keyboards were very common here a couple years ago, but no battery at all, so momentary loss of mains shut it off.  Consider it an integrated UPS.
<calc> i would like better than 1280x800 though for resolution
<StevenK> Chipzz: I could. I think pitti and and I are happy enough to leave it broken for the moment.
<StevenK> persia: Haha, point.
<calc> the X200 supposedly can last ~ 9hr on the 9cell battery :)
<persia> calc: Sure, but the W700?
<Chipzz> StevenK: I was actually trying to point out (yesterday) that it wouldn't have to NBS'ed out of main if you shipped an svn snapshot, but ok :)
<persia> Also, I've not had best success with claims: my current laptop claims 8 hours, but I rarely get more than 5.
<Chipzz> not using it anyway ;)
<RAOF> StevenK: How big is the X40?
<calc> persia: W700 is too big for me, 15" really is too big as well, which is what i currently use
<calc> persia: oh i don't know about what the W700 claim is
 * RAOF 's next laptop is likely to be a toss-up between a 13" thinkpad and a macbook.
<persia> calc: Too big for weight, or too big because of your luggage?
<StevenK> RAOF: 12.1 inch
 * persia is exceedingly happy with the CF-Y7, although the sound needs a bit of debugging.
<RAOF> Yeah, that's maybe _slightly_ small.  Although maybe a couple of years at 13" will make it seem more reasonably :)
<StevenK> RAOF: The screen is a little small, but the keyboard is *lovely*
<calc> persia: luggage
<calc> persia: weight generally isn't an issue on the airline i fly, they don't even check carryon
<calc> of course i would rather not lug a heavy bag either
<persia> Ah.  I care about weight more for walking about than for planes.
<StevenK> This is the main reason I like the X40. :-)
<StevenK> And terms of the laptop, charger and second battery, it's ~ 2kg
<calc> persia: i don't walk much living in Houston
<StevenK> calc: You're married to your car?
<calc> everything is too spread out, urban sprawl
<calc> the closest restaurant that i like is ~ 7km roundtrip, thats a fairly long walk in 40C weather
<calc> to even get out of my neighborhood, only houses here, it would take walking ~ 3km roundtrip to get the entrance, heh
<calc> no sidewalks, etc
<calc> i walked to the 7km place one day since my wife had my car
<calc> had to walk out into a 7 lane 70kph road to get around some really bad ground
<RAOF> Some places in America appear to suck like that; I've only been to Portland, which seemed reasonably pedestrian-friendly, but my partner went to Oak Ridge recently and it was definitely the opposite.
 * persia boggles at the very existence of a 7 lane 70kph road being within 7km of a residential area
<calc> they have a datasheet on the W500 (not W700) and it says with 9cell battery up to 8.3hr on integrated video
<StevenK> 70kph, or mph?
<calc> 45mph
<RAOF> I think I'd go mad in those places.  Cars suck.
<pwnguin> meh
 * ajmitch is far too used to walking everywhere
<pwnguin> an auto's already a requirement where i live
<persia> Anyway, given https://launchpad.net/+builds shouldn't we be uploading or something?
<StevenK> Why? :-)
<calc> actually one way it is only actually 0.7km from my house to the 45kph road
<pwnguin> 45kph
<calc> er 45mph
<pwnguin> thats like what, 10 miles an hour?
 * calc is typoing
<calc> 45mph/72kph (i think is the proper conversion)
<pwnguin> its too damn hot here to go walking anyways
<pwnguin> except when it's too cold or raining
<pwnguin> snowing, or tornadoing
<calc> pwnguin: yep very hot here
<calc> i probably keeps it warmer in my house than it is outside for most people here ;-)
<calc> there aren't any trees around so the aircon can't keep it very cool
<pwnguin> granted, england could probably fit within the area between metros where i live, all of which predate the car and highway
<calc> around 25.5C inside
<calc> england is pretty large but has a lot of people stuffed into it
<calc> well larger than many states in the US other than texas
<pwnguin> england, or the uk? ;)
<calc> UK 244,820 km^2 60.5Mil people : TX 696,241 km^2 23.9Mil people
<calc> well even england is larger than many states (i think?)
<StevenK> What about Australia? :-)
<calc> australia is just a big desert ;-)
<calc> kinda like the west side of texas
<pwnguin> huh, actually the UK's bigger than i thought
<lifeless> calc: england != UK
<calc> england by itself is 130,395 km^2 50.7 Mil people
<calc> lifeless: i know :-P
<calc> lifeless: i forgot to lookup just the stats on england at first
<calc> so england by itself is less than 1/4 the size of texas but has 2x as many people
<pwnguin> which means you can probably visit the people you know without going too far ;)
<calc> about 11.5x the population density of texas
<calc> of course there is the part about texas being a lot of desert too
<pwnguin> there's also washington, alaska and california :P
<calc> relatively no one lives in alaska
<pwnguin> heh
<pwnguin> you're the one who cares about density
<pwnguin> but yes, you get paid to live in alaska
<calc> 0.41 km^@
<calc> er 2
 * persia looks down at all the absurdly low population density counts
<pwnguin> and there's still nearly no takers
<calc> 1,717,854 km^2 with 683,478 people
<pwnguin> persia: yes well, that comes from not using the land to actually grow enough food :P
<persia> My local prefecture contains ~ 12 million people in ~ 2,187 km^2
<lifeless> persia: and whats the food shortfall from that land?
<lifeless> persia: you can't count other regions for generating food, without lowering your population density :)
<persia> lifeless: Not sure.  It does include a fair amount of argricultural produce area, but most lifestock and grain is imported.
<persia> Within the entire country, it's something like 90% sufficient, but that takes the numbers to significantly lower density
<persia> (only about 621 km^2 is metropolitan)
<persia> RIght.  126 million in 377,835 km^2, but ~70% is mountains that are good for neither people nor food.
<lifeless> see
<lifeless> if you measure the closest regular polyhedron capable encompassing my body you can get awesome population density
<lifeless> but it doesn't mean shit :)
<persia> Still, about 1000 people / km^2 for non-mountainous terrain
<Chipzz> Keybuk: If I understand correctly, upstart isn't used atm anyway except as a wrapper around the current init-scripts, and a couple of other "minor" things (like terminals) etc, and that installing it is optional and has to be done manually by the user?
<wgrant> Chipzz: No. Upstart replaced sysvinit in Edgy
<wgrant> If you're using >= Edgy, you're using Upstart.
<wgrant> Unless you've done something very strange and likely stupid.
<persia> Chipzz: Rather, there is a wrapper around initscripts that make them upstart compatible.
<Chipzz> I'm using gutsy IIRC, but I distinctly recall installing upstart manually
<Chipzz> then again, this install is several releases old
<wgrant> update-manager should have installed Upstart on any upgrades to Edgy.
<Chipzz> persia: that's what I meant :)
 * Chipzz uses apt, not update-manager
<wgrant> Erm
<wgrant> Verboten.
 * Chipzz is old-school like that :P
<persia> apt works, as long as one ensures one has the dependencies of the selected metapackages.
<Chipzz> wgrant: erm, I've been running debian unstable/experimental since... lemme think
<Chipzz> about 6 or 7 years ago
<wgrant> persia: It's officially discouraged and unsupported...
<wgrant> Chipzz: As have others.
<Treenaks> wgrant: even on server installs?
<persia> wgrant: Really?  update-manager mostly just calls python-apt or synaptic (which uses libapt).  The important part is the metapackage definitions.
<Chipzz> wgrant: do not worry. I know my way around
<Treenaks> wgrant: where I have no gui
<Chipzz> wgrant: I *do* know how to fix problems when they occur
<persia> Treenaks: update-manager-core contains CLI tools
<wgrant> Treenaks: Yes. do-release-upgrade.
<Treenaks> wgrant: yes, but what if I'm running intrepid _now_ and upgrade every day?
<Chipzz> wgrant: I am a sysadmin for profession, and use debian all the time
<wgrant> Treenaks: Then you are expected to know what is going to go wrong. And you haven't got such big jumps.
<ScottK> Treenaks: It's only needed when upgrading from one release to another (e.g. gutsy -> hardy) not when upgrading within a release.
<Treenaks> oh yes, I've used d-r-u for that since it was introduced
<ScottK> Chipzz: I've done that too and have generally be successfull.  It did bite me once rather badly.
<wgrant> persia: It also knows about upgrade quirks. For example, doing a manual dist-upgrade to Hardy would generally leave you with a fairly unworking system, due to evms changes.
<Chipzz> ScottK: heh. I've gotten myself out of pretty bad situations with debian already :)
<Chipzz> like a broken libc :P
<persia> wgrant: I guess.  I think that's just a workaround for bugs in the package dependencies.
<wgrant> persia: There was no proper way to handle evms with dependencies.
<Chipzz> transferring a running system from one HD to another one with debootstrap, and other crazy shit like that
<persia> wgrant: Quite possibly.  That the facility for handling quirks is there doesn't mean that the evms stuff wasn't set up non-ideally to begin with.
<dholbach> good morning
<pitti> Good morning
<dholbach> hi pitti
<pitti> asac: aieeee
 * pitti hugs dholbach
 * dholbach hugs pitti back :)
<bigon> could someone give back pymsn on hppa?
<pitti> bigon: nothing to give back; it's built and arch:all
<bigon> pitti, s/pymsn/pygtk
<bigon> doh
<pitti> bigon: done
<bigon> thx
<lukehasnoname> Good morning, mates.
* pitti changed the topic of #ubuntu-devel to: archive: SOFT-FREEZE for Alpha 4 | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tkamppeter> Anyone was in contact with heno recently?
<cody-somerville> Recommends installed by default makes me want to cry now :/
<mdke> tkamppeter: I had an email exchange with him last wednesday, if that helps
<mdke> dholbach: hi! Seb told me that the gnome-user-docs build error can be fixed by passing --disable-scrollkeeper to configure, but I see from debian/rules that this is already the case. I don't have any idea why the build fails
<mdke> ah, hi seb128
<seb128> hi mdke
<mdke> seb128: that build error on gnome-user-docs, I notice that debian/rules already contains this:
<mdke> DEB_CONFIGURE_EXTRA_FLAGS += --disable-scrollkeeper
<mdke> is there anything else I can do to fix the build error?
<seb128> so that doesn't work for whatever reason, does the configure call during the build uses it?
<mdke> I don't know :(
<seb128> if the configure option is there look at what changed in the source which broken the option
<mdke> hmm
<mdke> i will have to get an intrepid chroot and test the build there
<bigon> mdke, maybe switch to rarian-compat
<tkamppeter> mdke, thanks. I have sent an e-mail to heno last Monday, sent a reminder last Thursday or so and also yesterday and did not get any answer.
<dholbach> mdke, seb128: you could pass it to ./autogen.sh as well
<seb128> dholbach: that should not make a difference, that's not an autotools option but a configure one
<NCommander> morning seb128
<seb128> hello NCommander
<NCommander> how goes it?
<mdke> bigon: I'm not sure I'm confident enough to make such a large change to gnome-user-docs though
<dholbach> seb128: I just thought that autogen.sh would run configure at the end as well
<mdke> dholbach: do you have a log of the build? Are you able to answer seb's question about whether configure is calling the option during the build?
<seb128> dholbach: it does, but if using the option for the configure doesn't work it should not make a difference, no?
<dholbach> mdke: no, I just copied that portion of the log
<dholbach> seb128: I agree, it shouldn't
<seb128> NCommander: busy but good, what about you?
<NCommander> seb128, my day kinda weird. I had a good firefighting drill. I got an AM ... and I'm coding on dak
<NCommander> So uh, yeah, when does the sky fall
<seb128> ;-)
<mdke> dholbach: ah, ok
<NCommander> Oh, and I found packages in Debian which had invalid signatures to top it all of
<NCommander> So yeah, weird day
<seb128> sounds rather a good day ;-)
<seb128> NCommander: not looking for updates to do then?
<NCommander> seb128, I can if it will help my MOTU quest ;-)
 * NCommander is hit mortal combat style
<pitti> seb128: do you have a gnome-games upload in the pipe? if not, I'd like to upload a new version which uses lzma
<pitti> seb128: we need to downsize the alternates
<seb128> pitti: go for it
 * pitti goes for it
<seb128> NCommander: http://download.gnome.org/sources/conduit/0.3/conduit-0.3.13.1.tar.gz
<NCommander> seb128, what category of difficulty does this fall under ;-)
<seb128> pitti: just curious but how much lzma wins in this case?
<seb128> NCommander: it's a standard update so should not be too hard
<pitti> seb128: I expect some 3 MB (that was measured on gutsy, but shouldn't be much different nowadays)
 * NCommander knocks on wood
<pitti> seb128: not as impressive as ia32-libs (22 -> 10 MB) or libgl1-mesa-dri (13 MB -> 3 MB), but still not to be sneezed at
<seb128> pitti: we still have ia32-libs on the cd?
<pitti> seb128: no, we don't, it just was the first package we lzma'ed
 * pitti holds that trophy
<seb128> I see ;-)
<pitti> the mesa lzmaification should rescue the kubuntu amd64 alternate
<pitti> and the ubuntu amd64 one is now slightly oversized as well
<NCommander> seb128, how much do you know abotu dsc files?
<seb128> NCommander: enough for what I need to do, which means not a lot ;-)
<NCommander> seb128, do you know if the Changed-By field ever exists in the dsc, or does it only live in the .changes?
<seb128> no clue
<persia> NCommander: Only in .changes
<NCommander> persia, ok, that greatly simplifies this dak patch :-)
<asac> pitti: ;)
<pitti> seb128: ok, forget gnome-games, for -data lzma doesn't save much any more for some reason
<seb128> pitti: it's already bziped, it was a 3 megas win over non-zipped?
<pitti> seb128: are you sure?
<pitti> ar t /var/cache/apt/archives/gnome-games-data_1%3a2.23.6-0ubuntu2_all.deb |grep data
<pitti> data.tar.gz
<pitti> seb128: I got that 3 MB from https://wiki.ubuntu.com/dpkg-lzma
<pitti> but it only shrinks to 12.9 MB now
<pitti> gnoem-games itself shrinks from 1.2 MB to 700 KB, but that's much less of a saving
<seb128> pitti: no, I though, but apparently now
<pitti> 12.6 MB with bzip2
<pitti> so that's about as much air as we can drop from it
<davmor2> pitti: iso's have just finished up dating I'll let you know in a few minutes if it is still playing up :)
<asac> pitti: ArneGoetje: just updated langpacks from PPA ... think the current ones (5th Aug) are worth a try.
<asac> (from firefox perspective)
<pitti> asac: for hardy-proposed you mean?
<asac> pitti: yes ;)
<asac> pitti: well. the last ones were broken. just wanted to emphasize that the new ones are working again ;)
 * pitti hugs lzma, thanks for saving 10 MB with a single mesa upload
<asac> let me check that they fix the bug they are supposed to fix ;)
<pitti> asac: right, thanks a lot for confirming
<asac> pitti: yes. it fixes antoher but the finish folks have long been waiting for
<pitti> ArneGoetje: so it seems that hardy-proposed langpack updates are unembargoed again now :)
<asac> e.g. you can now search in the location bar again
<asac> so please roll them to -proposed
<asac> (before launchpad lands a new feature that makes the current po2xpi processor break again :))
<asac> ArneGoetje: 5th aug langpacks appears to be good
<pitti> Riddell: so, I think the kubuntu alternate amd64 should be within limit again in the next round
<pitti> davmor2: ah, thanks; I start testing the current alternate amd64 now
<Riddell> pitti: oh great, what did you do?
<pitti> Riddell: build mesa with lzma, which deflates libgl1-mesa-dri from 13 to 2.8 MB
<Riddell> lovely
<pitti> Riddell: I diffed the i386 and amd64 .list files, and didn't see anything relevant
<pitti> just curious that the amd64 one is so much bigger
<pitti> Riddell: btw, are you aware ouf the various KDE out-of-date packages?
<pitti> AFAICS kdebase and kdegraphics are just NBSes, but kdegames is a real FTBFS
<pitti> however, there are still rdepends on kghostview and khelpcenter, so I can't kill them yet
<ArneGoetje> asac: ok...
<asac> ArneGoetje: thanks
<ArneGoetje> pitti: crontab for hardy langpacks disabled. You can shift them over to -proposed. :)
<pitti> ArneGoetje: copy in progress; I estimate that everything is built and published in about 12 hours
<ArneGoetje> pitti: thanks :)
<pitti> (should be less)
<pitti> mvo: do we need a g-a-i data update for alpha-4?
<mvo> pitti: I prepared one, but didn't manage to upload last night, is it ok (freeze wise) to upload it now?
<pitti> mvo: sure
<mvo> (funny, I asked in #ubuntu-release some minutes ago)
<mvo> execellent, thanks!
<ArneGoetje> pitti: how do I build a package with lzma? I'd like to try that on my ttf-arphic-uming font package...
<pitti> ArneGoetje: dh_builddeb -- -Zlzma
<ArneGoetje> pitti: thanks
<pitti> and a Pre-Depends: on dpkg (>= the version which introduced it)
<pitti> which I of course forgot to apply to mesa, darn
<pitti> Pre-Depends: dpkg (>= 1.14.12ubuntu3)
<pitti> ArneGoetje: ^
<ArneGoetje> pitti: thanks
<pitti> ArneGoetje: btw, if you already have a deb with standard gzip compression, it's quicker to check what lzma brings with:
<davmor2> pitti: Fail
<pitti> ar p /var/cache/apt/archives/gnome-games-data_1%3a2.23.6-0ubuntu2_all.deb data.tar.gz | gunzip | lzma -9 | wc -c
<pitti> davmor2: darn, so that requires actual work; thanks for testing
<davmor2> pitti: would it help to test kubuntu alt and see if theres a diff between the desktops?
<pitti> davmor2: I guess it won't for that grub bug, but independently  from that testing other images is always appreciated :)
<pitti> so if you have the time and the bandwidth, it would be great
<davmor2> pitti: I'm an iso tester dude it's what I do :D  I got 22 up-to-date iso's
<pitti> 22! you rock!
<davmor2> we put together and iso-dl-script to rsync the iso's for testing :)
<ArneGoetje> pitti: hmm... the current one uses bz2. So, it won't bring much... from 9.3M to 7.8M...
<pitti> ArneGoetje: well, 1.5 MB is pretty good
<ArneGoetje> pitti: ok, so I'll give it a try
<pitti> ArneGoetje: that's about the size of oversizedness we regularly have to fight :)
<pitti> or a small langpack
<ArneGoetje> pitti: he he he... :)
<ion_> We could always compress the debs with a lossy compression.
 * soren chuckles
<pitti> data.tar.flac :)
<ion_> pitti: Hmm. I wonder if anyone has tried to compress arbitrary data by doing a lossy compression and then appending a diff from its result to the original. Probably doesnât work very well on arbitrary data instead of e.g. audio.
<pitti> ion_: but which kind of lossy compression do you want to try?
<pitti> ion_: I am willing to bet that the sum of lossy compression plus diff is higher
<ion_> Didnât think that far. :-)
<ion_> Yes, thatâs what i meant with âdoesnât work very wellâ. :-)
<pitti> since the diff has to contain more entropy than the lossy compression saves
<pitti> since it has to contain the knowledge about the errors in lossy compression as well
<pitti> we just need that fractal Borg algorithm, and they'll all compress to 1 byte
<ion_> :-)
<ion_> Well, everything could be âcompressedâ to its checksum and length. All we need is something that decompresses it quickly enough. :-)
<ArneGoetje> pitti: ok, the new deb has 7829330 compared to 9678278 before...
<pitti> that's pretty good
<ion_> âPlease wait. Bruteforcing sha1: a4153fa1756bb709fea51d8c7169c4710cc9fe6d, length: 2083350 to cups_1.3.8-3_i386.debâ
<pitti> ion_: too bad that hashes aren't bijective :)
<ArneGoetje> pitti: uploaded to rookery: ~arne/ttf-arphic-uming/
<pitti> wrt. the current empathy discussion, how do I add my @ekiga.net SIP account? it doesn't seem to have a field for the SIP server?
<davmor2> pitti: Riddell: Kubuntu alternate fails before grub issue.  libxine1-ffmepg: Depends: libavcodec51 (>= 3:0.svn20080206) but is not installabe :(
<emgent> moin
<Riddell> davmor2: humph
<davmor2> Riddell: Pleasure :)
<davmor2> pitti: Riddell: I'm just checking the live installs to ensure that they work (crosses figures)
<Mirv> mvo: hi, thanks for another ddtp update. could I add "ddtp translations" to http://www.hs.fi/kaupunki/artikkeli/P%C3%A4%C3%A4kaupunkiseudun+joukkoliikenteen
<Mirv> bah
<Mirv> https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline
<Mirv> so that they'd be somewhat officially be updated before release ca. at that point?
<mvo> Mirv: yes, I think that makes sense
<Mirv> mvo: yep, if there is no problem updating them so close to relase (I guess not)
<pitti> davmor2: yay, I think I got it (grub failure)
<davmor2> cool:)
<mvo> Mirv: there is a risk, but its small
<davmor2> live has red and grey blocks instead of usplash again but it seems to be working other than that :)
<pitti> davmor2: yeah, known problem
<pitti> BenC: I analyzed bug 256989 and I have a solution for alpha-4; input from you whether it's the truly right solution appreciated
<ubottu> Launchpad bug 256989 in grub "Intrepid: Ubuntu Alternate grub install fails" [High,In progress] https://launchpad.net/bugs/256989
<davmor2> pitti: gvfs-backends issue due to out dated componants? known or not?  It tells me to upgrade to libldap-2.4-2, libhal1, libcromerr2, libbluetooth2
<pitti> davmor2: upgrading new libs is ok, there will always be new packagaes in the current stage of development
<pitti> davmor2: however, what's teh gvfs-backends issue?
<davmor2> pitti: I don't know I hit the apport crash to see if it was reported and it popped up the upgrade to these versions window
<pitti> davmor2: oh, I see
<pitti> davmor2: so, don't worry about it for now, and report it once the system is installed and updated
<pitti> davmor2: chances are high that it is already reported, though
<davmor2> looks like some of the upgrades are in place to update so I'll do that reboot and see if the issue is still there
<Mirv> I added now mention of ddtp translations (preferring doing those in Debian) and removed Firefox because those are now in language packs
<pitti> davmor2: uploaded grub; after it's published, I'll rebuild new alternates
<pitti> that should bring them back in size and fix the install
<davmor2> pitti: cool ping me when they are up I'll update the iso's and retest
<pitti> davmor2: thanks, mate
<pitti> Riddell: ok, let's fix that uninstallability for the next kubuntu alternate, too, shall we?
 * pitti pokes
<Riddell> pitti: I'm away (at akademy), not really able to look at it
<pitti> Riddell: ah, I see; I'll give it a spin
<pitti> I wonder why it doesn't appear on http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html
<pitti> oh, hang on
<pitti> ffmpeg?
<davmor2> pitti: I dropped a message on #kubuntu-devel about it too
<pitti> I bet it's due to some "ffmpeg thou shalt not be on CDs" germinate blacklisting
<davmor2> pitti: mixer-applet2 crashes :( damn it
<pitti> seb128: btw, you are still attached to the amd64 retracer
<davmor2> bug 255554 :(
<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
<seb128> pitti: yes, I'm cleaning the "can't be retracer because 7.04 and 7.10 have no retracer" list
<seb128> davmor2: what about it?
<seb128> pitti: do you need something?
<joaopinto> Hello, my system is freezing randomly, I have found how a way to reproduce it, it hangs when starting a game, should I file the bug against the kernel, or the video driver ?
<davmor2> just letting you guys know
<pitti> seb128: don't worry
<seb128> davmor2: what is special about it?
<seb128> davmor2: and there is 10 duplicates so we know about it
<seb128> joaopinto: do you have anything in the xorg or syslog logs? can you ssh to the box when it's frozen or not?
<davmor2> seb128: np's
<joaopinto> I didn't tried to ssh, it's a workstation, I would need to install ssh and go to other system
<seb128> davmor2: do you have a way to trigger it? does it prevent the applet to do something?
<seb128> pitti: in fact I'm attached to the i386 retracer, the amd64 one should be available
<joaopinto> [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 1412721 emitted: 1412727 <- found this on kernel.log
<davmor2-away> seb128: no it crashed on reboot
<joaopinto> I have tried the sysreq key (I had some vague idea it was expected to cause a kernel dump)
<seb128> davmor2-away: we still need informations on the bug if you can get a valgrind log or describe how to trigger it
<joaopinto> SysRq : HELP : loglevel0-8 reBoot Crashdump tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks
<joaopinto> I am not sure my random freezes are related to the game start freeze
<Mirv> mvo: the ddtp translations do not containt at least some of the universe translations I did two days ago. should they be there? I've also had some suspicions of not all Debian translations being imported, but no real proof.
<Mirv> (it's hard to remember/know when debian translations were done with regards to when merge to ubuntu was done)
<Mirv> mvo: and I mean I did those universe translations in ddtp-ubuntu two days ago in Rosetta
<mvo> Mirv: that is expected, if it was just two days ago
<mvo> Mirv: I fixed some stuff in the export code and did not yet request a new export of rosetta
<mvo> Mirv: I will do that today though (hopefully that means it will be available tomorrow then :)
<Mirv> mvo: ok, cool
<davmor2-away> seb128: will do when I get back I'll ping you and find out exactly what you need
<seb128> davmor2-away: thanks
<pitti> Riddell: right, libxine1-ffmpeg pulls in libavcodec51 which is a no-no
<mvo> Mirv: about the missing debian import bits, I would be very interessted if you can find some clues about those, I think the import works ok, but I'm not sure, its a multi stage process currently, so there may be bugs
<pitti> mvo: I guess bug 255545 fix might make it to alpha-4, but we won't actually change the CDs accordingly?
<ubottu> Launchpad bug 255545 in apt "requires uncompressed Packages files on CDs" [Medium,Fix committed] https://launchpad.net/bugs/255545
<mvo> pitti: I can upload a fixed apt now, I'm not sure what the plan is though, colin is away this week
<pitti> mvo: right, so no hurry for an upload
<mvo> pitti: I guess I could look at the required cd building changes (also that is new terain for me, but if we need the space)
<pitti> mvo: long-time we need the space, but I'm ok with a4
<pitti> (I hope)
<pitti> Riddell, siretart: so, kubuntu desktop pulls in phonon-backend-xine, which depends: libxine1 which recommends: libxine1-ffmpeg
<pitti> Riddell, siretart: and on top of that libxine1 depends: libxine1-plugins (which also pulls in libavcodec)
<pitti> Riddell, siretart: does it make any sense to change the dependencies of xine, or shall we drop phonon-backend-xine from the seeds?
<pitti> i. e. is it better to ship a reduced xine on kubuntu and let easy-codec-installation (does it work for kde?) worry about libavcodec, or is it better to not ship xine at all?
<pitti> Riddell, siretart: argh, dragonplayer pulls in libxine1, too
<Riddell> (it's in main for a reason)
<mdz> seb128: gnome-session is segfaulting during login for me
<mdz> but apport doesn't trigger for some reason
<seb128> mdz: do you have a stacktrace?
<seb128> are you sure it's a segfault?
<mdz> seb128: no, but I will get one.  I had to downgrade gnome-session in order to get logged in
<mdz> [   63.025472] gnome-session[6222]: segfault at 70706120 ip b776b263 sp bfa719a4 error 4 in libc-2.8.90.so[b76f4000+158000]
<mdz> [  139.337706] gnome-session[6934]: segfault at 70706120 ip b76a3263 sp bf8aac84 error 4 in libc-2.8.90.so[b762c000+158000]
<mdz> [  409.272432] gnome-session[7643]: segfault at 70706120 ip b77ef263 sp bf9f45c4 error 4 in libc-2.8.90.so[b7778000+158000]
<seb128> to what version did you downgrade?
<mdz> 2.22.1.1-0ubuntu2
<seb128> urg
<mdz> that was the next most recent one in the pool
<mdz> pitti: do you have any guess why apport didn't trigger for my gnome-session segfault?
<seb128> mdz: oh, that's hardy?
<mdz> gnome-session | 2.23.6-0ubuntu1 | http://archive.ubuntu.com intrepid/main Sources
<mdz> gnome-session | 2.22.1.1-0ubuntu2 | http://archive.ubuntu.com hardy/main Sources
<mdz> seb128: yep
<seb128> ah ok
<pitti> mdz: is there anything in /var/log/apport.log, and is apport enabled in /etc/default/apport ?
<mdz> pitti: the answer to your second question is yes. will check the first
<pitti> mdz: if it crashes that often, you might have hit the "at most 3 reports per program per day" threshold
<mdz> pitti: there are errors in apport.log, but it's difficult to correlate because there are no timestamps
<pitti> so there already might be a /var/crash/_gnome-session_.crash
<mdz> pitti: I have two .crash in /var/crash from today
<mdz> pitti: but neither of them is gnome-session
<pitti> mdz: weird, no timestamps?
<pitti> mdz: can you put the file somewhere, or does it have anything s3kr1t?
<mdz> pitti: oh, it has timestamps, just earlier on
<mdz> pitti: http://people.ubuntu.com/~mdz/temp/apport.log
<mdz> seb128: bug 257250 with a copy of .xsession-errors
<ubottu> Launchpad bug 257250 in gnome-session "gnome-session segfault during login" [Undecided,New] https://launchpad.net/bugs/257250
<pitti> mdz: weird, is there no /proc mounted by any chance?
<mdz> pitti: definitely mounted
<mdz> pitti: on an unrelated note, I noticed that apport triggers the kernel's hung task timeout
<joaopinto> seb128, I am able to login to the frozen system using ssh, I have also checked the instructions on how to generate a kernel bug report using SysRq
<joaopinto> now I just want to make sure I will be reporting the bug into the proper package
<seb128> joaopinto: that's like an xorg issue if you can ssh
<seb128> likely
<pitti> mdz: do you get a proper report if you do: bash -c 'kill -segv $$'
<joaopinto> well, after killing X I just got garbage, and keys kept not working
<seb128> mdz: hum ok, a stacktrace and a valgrind log could be useful
<seb128> mdz: I'm wondering if having /etc/xdg/autostart trackers autostarts and tracker not installed create issues
<mdz> pitti: yes I do
<mdz> seb128: I can test installing tracker
<pitti> mdz: hm, I have no idea right now why /proc/pid wasn't available at that time
<seb128> mdz: or move those autostarts away
<joaopinto> well, I am going to to file the bug against xserver-xorg-video-intel
<mdz> pitti: I also noticed that update-notifier shows the wrong program  name when it contains a '_' (same char used to replace '/' in the path)
<mdz> seb128:  I have a meeting now but will look at this more after
<pitti> oh, true that
<joaopinto> and hope it's the same problem for my random freezes, which are really annoying on a primary workstation :\
<mdz> pitti: is that apport's bug or update-notifier's?
<pitti> mdz: apport plugin in u-n
<seb128> mdz: ok, let me know how it goes
<pitti> but to fix that properly, it requires coordination from both
<seb128> lunch time
<pitti> so preferably I'd fix it in apport-checkreports and change the communication between u-n and a-checkreports
<joaopinto> seb128, since I am unable to CTRL-ALT-F1, shouldn't it be a kernel issue ? Isn't the kernel managing for the console switch ?
<seb128> joaopinto: look to the logs for errors but xorg or applications can steal keyboard events
<StevenK> joaopinto: Run 'sudo chvt 1' from ssh
<seb128> joaopinto: there is some compiz bugs which broke vt switching
<joaopinto> hum, that's odd, I though such combination would be identified at a lower level
<joaopinto> StevenK, the system is frozen, I can only login remotelly
<StevenK> joaopinto: Then run it after you've logged in remotely is what I'm suggesting
<joaopinto> seb128, ok, I am still missing something, xorg stealing keyboard events from kernel :P ?
<joaopinto> StevenK, ok, will try
<joaopinto> anyway I just want to be sure I will pick the proper component, maybe the intel video driver is really the better choice
<joaopinto> but again, shouldn't killing X release the keyboard lock ?
<pitti> siretart: so how was the "xine in main" deal meant originally? AFAIK we had xine on the kubuntu CDs in hardy as well, without pulling in libavcodec
<StevenK> pitti: You did a little NBS didn't you? I didn't see libct3 this afternoon in the list
<pitti> StevenK: killed it last night, yes
<pitti> calc: what's your plan wrt. OO.o? if you want to push some fixes into a4, we need the upload today, otherwise I'd just move the milestoned bugs to a5?
<pitti> tkamppeter: any idea about bug 251111? the import error might point to a missing dependency? or is it already fixed in the current s-c-p?
<ubottu> Launchpad bug 251111 in system-config-printer-kde "Intrepid: Kubuntu printer dialogue doesn't open" [High,Triaged] https://launchpad.net/bugs/251111
<Riddell> pitti: that should be fixed now
<pitti> Riddell: thanks
<Riddell> pitti: guess I forgot to add the bug to the changelog, I'll clos eit
<pitti> ScottK: what's the status of bug 247332, do you want to see it in alpha-4? is it ack'ed/tested, and thus just needs sponsoring, or is the patch not complete yet?
<ubottu> Launchpad bug 247332 in postfix "Please add a script to allow filter services to be programatically added to master.cf" [Wishlist,In progress] https://launchpad.net/bugs/247332
<ScottK> pitti: It's needing lamont to get some time to look into it.  He said he thought he'd get to it tonight.
<joaopinto> uff, I found my bug is reported since Dapper
<StevenK> pitti: Sorry, no MIR today, I'll do it tomorrow, and point you at it
<persia> pitti: In response to your question yesterday, the thread at https://lists.ubuntu.com/archives/edubuntu-devel/2008-August/002612.html has been started to deal with denemo
<pitti> persia: ah, thank you!
<pitti> davmor2-away: http://cdimage.ubuntu.com/daily/20080812.1/ there we go
<dholbach> emgent: do you think you can forward the Homepage field update changes to Debian too?
<emgent> yeah, I'm sending them now.
<emgent> btw, hi dholbach :)
<dholbach> ROCK ON
<dholbach> :)
<davmor2> seb128: ping
<davmor2> pitti: up-dating now :)
<emgent> dholbach: http://daniel.holba.ch/really-fix-it/ clean page?
<emgent> uhm no, now work.
<emgent> sorry.
<emgent> :)
<dholbach> it's harvest now
<dholbach> really-fix-it is dead
<Keybuk> slangasek: is a release freeze a bad time to upload a rewrite of upstart? :)
<emgent> http://apu.debconf.org:8000/Salon_del_mar.ogv.m3u
<davmor2> seb128: I've rebooted my machine and it doesn't crash again :(
<seb128> davmor2: ok, as said not easy to get details on the issue, but it's also not a really annoy issue
<Hobbsee> Keybuk: he's on holidays, so...
<Keybuk> oh, of course
<Keybuk> debconf
<davmor2> seb128: could it be down to a change in applet that gnome is remembering?
<Hobbsee> Keybuk: on that basis, it might be a good time.  it'll either work fine, in which case, he won't kill you, or it won't work, in which case, you'll have more time to prepare, and run :)
<seb128> davmor2: what do you mean? no, it's likely a crash, could be happened when closing the session and be displayed on next login
<davmor2> seb128: okay it came up after a reboot from upgrade.  So I've done a sudo reboot see if it fires off again
<slangasek> Keybuk: <mumble, gnash>
<davmor2> seb128: Ah strange now I get gvfsd-trash error :(
<seb128> davmor2: would be nice to get a valgrind log for this one too, there is a zillion duplicate too
<pitti> davmor2: yay, installing grub worked now
<davmor2> pitti:  I'll confirm it shortly :)
<davmor2> seb128: how do you get the valgrind log?
<seb128> davmor2: https://wiki.ubuntu.com/Valgrind
<davmor2> ta
<pitti> X still hangs when starting the session, but that seems to be a driver/compiz problem which by and large happens in kvm/vmware
<seb128> davmor2: cd /usr/lib/gvfs, sudo mv gvfs gvfs-binary and create a gvfs wrapper which calls valgrind /usr/lib/gvfs/gvfs-binary
<pitti> tjaalton, bryce: ^ any idea about it? gdm works, then it hangs when starting the session
<seb128> davmor2: don't forget to install gvfs-dbgsym gvfs-backends-dbgsym libgtk2.0-0-dbgsym too
<tjaalton> pitti: which card?
<pitti> tjaalton: hm, whatever kvm/vmware do; if this is news to you, I'll try some further debugging and open a bug report with logs et al
<pitti> bbl, testing desktop cd on real iron
<tjaalton> pitti: so the host freezes, or just the guest?
<mdz> does anyone know what pulled libchipcard-tools into desktop?
<mdz> it looks like perhaps it's been fixed already, but it ended up on both of my intrepid systems
<mdz> and is not marked automatically installed
<mdz> or am I the only one who has it unexpectedly installed?
<tedg> mdz, I have it installed too.  No idea why.  Does it make chocolate chips cookie cards? :)
<mdz> tedg: it wakes up every 1000ms or so and scans over sysfs, to help you reduce your battery life
<seb128> mdz: apport not working on gnome-session is likely a due to policykit
<mdz> seb128: is it a bug?
<seb128> pitti: ^ should we drop the noptrace change in unstable?
<seb128> mdz: no, it's a security measure, see  bug #202314
<ubottu> Launchpad bug 202314 in policykit "gnome-panel crashes are not reported" [Low,Fix released] https://launchpad.net/bugs/202314
<seb128> mdz: https://bugs.edge.launchpad.net/ubuntu/+source/policykit/+bug/202314/comments/6
<ubottu> Launchpad bug 202314 in policykit "gnome-panel crashes are not reported" [Low,Fix released]
<mdz> pitti: crash reports from the guest session end up mode 000; is that a bug?
<mdz> seb128: thanks
<mdz> seb128: that's marked fixed; did it regress?
<mdz> seb128: I can reproduce the gnome-session crash easily, but it will be tricky to catch it in gdb
<seb128> mdz: as pointed in pitti's comment we decided to have the security patch on stable versions, so it was added to hardy
<seb128> mdz: and I guess pitti_live didn't drop it yet in intrepid
<mdz> oh, I see
<pitti_live> hi
<seb128> hey pitti_live
<pitti_live> I just booted the current live, and I have a strange theme
<mdz> pitti_live: is this something we should add to a release checklist?
<pitti_live> that sounds like a g-s-daemon crash?
<seb128> pitti_live: should we drop the noptrace policykit patch again?
<pitti_live> seb128: I thought I did already?
<seb128> pitti_live: in intrepid? the changelog doesn't mention that, you added it back to hardy stable for security reasons
<pitti_live> hm, g-settings-daemon is running, but the theme is still wrong
<pitti_live> seb128: yes, I thought I disabled it again when merging 0.9, let me check
<mdz>     - 02_noptrace.patch.disabled: Disable ptrace() and core dumping for
<mdz>       programs using libpolkit for security reasons; not enabled during
<mdz>       development.
<mdz> the patch seems to still be disabled, which means ptrace should work
<seb128> mdz: ok, that was a guess, might be due to something else
<mdz> pitti: I see a lot of "another apport instance is already running, aborting"
<seb128> but I don't think we got any gnome-panel or gnome-session apport crash in intrepid which is a bit weird
<mdz> glxinfo seems to be crashing too; I wonder if that's blocking it from seeing the gnome-session crash
<pitti_live> seb128: kill -SEGV panel works and gives me an apport report, so that confirms that the ptrace patch is off
<seb128> ok, that was a guess, sorry for the noise
<pitti_live> $ metacity --replace
<pitti_live> Window manager warning: Failed to load theme "Human-Murrine": Failed to find a valid file for theme Human-Murrine
<pitti_live> aah
<pitti_live> that sounds like a missing dependency
<seb128> pitti_live: human-theme is installed?
<Ng> asac: the new NM 0.7 hardy PPA stuff seems fine, although the openvpn bit isn't working for me on hardy
<pitti_live> seb128: yes
<pitti_live> seb128: ah, /usr/share/themes/Human-Murrine/ is more or less empty, just a gtkrc
<pitti_live> no pngs or anything
<pitti_live> seb128: do you happen to know, what's supposed to be the default, NewHuman or Human-Murrine?
<seb128> no clue
<pitti_live> ok, will talk to kwwii
<seb128> grep gtk /usr/share/gconf/defaults/* ?
<pitti_live> fun, if I manually select Human-Murrine in appearance, it works
<mdz> pitti_live: I'm still getting invalid problem reports for guest account crashes
<pitti_live>  /usr/share/gconf/defaults/10_libgnome2-common:/desktop/gnome/interface/gtk_themeHuman
<pitti_live>  /usr/share/gconf/defaults/16_ubuntu-artwork:/desktop/gnome/interface/gtk_theme      Human-Murrine
<mdz> pitti_live: do you set special rlimits on the guest session?
<pitti_live> mdz: I didn't change the apparmor profile yet
<mdz> oh
<pitti_live> mdz: it's still curious, because AA is per process, not per user
<pitti_live> thus, I limit gnome-session only
<pitti_live> apport is forked by the kernel and thus shouldn't be affected
<pitti_live> but I didn't investigate that yet
<mdz> pitti_live: there are a bunch of apparmor errors about /dev/zero in the guest session as well
<davmor2> seb128: Right I think I've selected everything for install.  So I create a new file call it gvfs and add #! /bin/bash (nl) valgrind /usr/lib/gvfs/gvfs-binary.  Is that correct?
<Ng> asac: having said that, disabling wireless via the applet just now froze my machine for a few seconds (no input movement, audio buffers repeating), but it did come back.
<pitti_live> TheMuso: I still get the squeaking sound from pcspkr with the live cd startup; maybe we should just blacklist that silly module altogether, if all your workarounds in alsa and pulse don't work?
<seb128> davmor2: no, you renamed gvfsd-trash to gvfsd-trash-binary and create a gvfsd-trash which calls valgrind /usr/lib/gvfs/gvfsd-trash-binary --log-file=/youruserdir/gvfs.log for example
<seb128> davmor2: you can use gvfs-%p.log so it'll not replace the log at next login
<StevenK> pitti: How come gnustep-back0.12 has missed your pruning? It only has hppa rdepends
<asac> Ng: did you get the -openvpn from PPA?
<StevenK> pitti: Which means gnustep-back0.12-art can die too
<asac> Ng: the hang is a driver issue
<asac> Ng: if you have the chance to test them, please also test vpnc and pptp
<davmor2> seb128: but is the idea behind the wrapper right I've never written one?  Or is it just a file called gvfsd-trash with the valgrind line in?
<Ng> asac: I don't have vpnc/pptp setups unfortunately. going by the logs it seemed like NM was trying to ask me for auth details for the openvpn connection, but it shouldn't need any, my key is passwordless (and indeed if I tell the openvpn init scripts to make the connection, they don't ask for any further details)
<seb128> davmor2: correct
<asac> Ng: if its the latest openvpn from network-manager ppa, please open a bug and give me the number ;)
<Ng> asac: ok
<asac> Ng: as usual attach complete syslog taken after reproducing ;)
<asac> Ng: and whatever you think is important/special
<seb128> davmor2: that's because you don't run gvfsd-trash, GNOME does that for you, so the easier way to get a valgrind log is to trick the command this way
<Ng> asac: will do
<asac> good
 * seb128 grrrr at apport being so slooow
<davmor2> seb128: ah okay ta
<pitti> StevenK: yay
<pitti> okay, I get the same theme bug in the guest session, too
<pitti> hm, and kwwii is on holidays ...
<pitti> mdz: right, I get the same exceptions under the guest account
<mdz> pitti: which? glxinfo crash? gnome-session crash? invalid .crash file?
<johanbr> asac: After installing network-manager-vpnc from the ppa, the Add button under VPN is still greyed out.
<pitti> mdz: invalid .crash file and /proc/12345 does not exist
<mdz> pitti: interesting
<mdz> pitti: I got the latter on a regular account
<mdz> pitti: do you get 'another apport instance is already running'?
<pitti> mdz: no
<pitti> oh, indeed my log files show the same exception for a regular account, too
<pitti> wth?
<asac> johanbr: ok. i think vpnc needs a special UI
 * pitti runs /usr/share/apport/testsuite/test-apport kernel
<johanbr> asac: Okay. I had network-manager-vpnc-gnome installed before, but that get removed when I upgraded.
<pitti> mdz: ^ indeed, this is very brittle, and fails at different tests in different runs
<johanbr> "...got removed"
<mdz> seb128: I can reproduce the gnome-session crash in Xephyr, will have a backtrace soon
<asac> johanbr: ok. i dont find it in hardy archive
<seb128> mdz: good thanks
<pitti> mdz: since I didn't change that code for ages, I'll diff the relevant kernel bits, maybe something changed since .24
<ion_> johanbr: Thanks for having people trigger my hilight constantly. ;-)
<johanbr> ion_: ?
<ion_> johanbr: Heh, nothing. I just happen to have our given name in hilight list. :-)
<johanbr> asac: network-manager-vpnc-gnome | 0.6.6svn3381-0ubuntu1 | http://ubuntu.media.mit.edu intrepid/universe Packages
<johanbr> ion_: ahh, okay. Sorry. :)
<ion_> Heh
<seb128> johanbr: I guess those have not been ported to nm 0.7
<asac> johanbr: have you restarted your system after installing that package
<mdz> seb128: backtrace is in bug 257250 now.  it is segfaulting trying to print some error message
<ubottu> Launchpad bug 257250 in gnome-session "gnome-session segfault during login" [Undecided,Incomplete] https://launchpad.net/bugs/257250
<asac> seb128: i have updated all the vpn packages in ppa yesterday
<johanbr> asac: The -vpnc-gnome package is no longer installed, but I did restart after installing network-manager-vpnc, yes.
<asac> seb128: i dont see the gnome one at all here
<seb128> asac: gnome what?
<seb128> mdz: what arch do you use?
<mdz> seb128: i386
<seb128> mdz: I've a patch, I can give you a package to try in 2 minutes
<mdz> seb128: cool, once I have it I can try to find out what's causing the error (since apparently it's not happening for others)
<Ng> asac: found a similar bug report from earlier this afternoon and added a comment/log. bug 257246
<ubottu> Launchpad bug 257246 in network-manager "NM0.7 / Hardy: DBUS methods missing with OpenVPN plugin" [Undecided,Invalid] https://launchpad.net/bugs/257246
<Ng> my errors aren't entirely the same, so maybe it should have been a separate bug
<mdz> pitti: if I disable apport, it writes a core file OK
<mdz> pitti: is there any way to turn that into a .crash so that it can be easily retraced etc.?
<pitti> mdz: you can feed it to stdin of /usr/share/apport/apport <pid> 11 0
<pitti> mdz: but it expects a pid to work on, which is gone with a normal core dump
<davmor2> seb128: I just don't seem to get a trashcan anymore :(
<mdz> pitti: but <pid> won't exist
<pitti> mdz: you can probably fake it well enough by restarting and using that pid
<mdz> pitti: that worked, thanks
<calc> pitti: yea the release was delayed please bump the a4 to a5 as you mentioned
<pitti> calc: done, thanks
<calc> pitti: thank you :)
<pitti> asac: can you please give me a quick heads-up for bug 232392?
<ubottu> Launchpad bug 232392 in nss "Ubuntu builds of libnss lack ECC support" [Unknown,Fix released] https://launchpad.net/bugs/232392
<pitti> asac: it has a patch and is marked for alpha-4; if it should land in a4, it needs to be uploaded today
<seb128> mdz: http://people.ubuntu.com/~seb128/gnome-session_2.23.6-0ubuntu2_i386.deb
<mdz> seb128: crashes in the same place
<seb128> hum, weird
<mdz> except the format string is slightly different
<mdz> "Unable to parse command: %s"
<mdz> seb128: looks like it's /etc/xdg/autostart/smart-notifier.desktop which triggers it
<seb128> mdz: new deb at the same place, does it make a difference?
<seb128> mdz: the error is Terminal= which is invalid in one of the .desktop installed
<mdz> seb128: smart-notifier.desktop has Terminal=False
<mdz> seb128: I've attached it to the bug
<seb128> did you try moving it away?
<mdz> seb128: yes
<seb128> that fixes the issue?
<mdz> seb128: yes
<mdz> seb128: all the other .desktop have Terminal=false (lowercase)
<seb128> ok thanks, I've enough informations to work on it now
<mdz> seb128: changing it to "false" fixes the issue as well
<seb128> did you try the new deb and the .desktop buggy version?
<mdz> seb128: trying now
<mdz> seb128: new .deb still crashes
<mdz> e444a6ed41a0aa749f5eb056d9ad8979  gnome-session_2.23.6-0ubuntu2_i386.deb
<mdz> a362c18f9cdce8255a31736b1c31659f  /usr/bin/gnome-session
<seb128> mdz: cd8cc4c0958cd74240eda2f0dd478a1a  gnome-session_2.23.6-0ubuntu2_i386.deb
<seb128> mdz: anyway don't bother I've enough information to work on it without having you testing
<pitti> tjaalton: aah, the X hang in vm could actually be bug 246969, I'll test that
<ubottu> Launchpad bug 246969 in linux "[Intrepid] snd_pcsp module causing lockup when running as a VMWare guest" [Medium,Confirmed] https://launchpad.net/bugs/246969
<tjaalton> pitti: see, X has no bugs ;)
<pitti> BenC: WDYT about that bug? ^
<BenC> pitti: Interesting
<pitti> BenC: in particular about blacklisting snd_pcspkr by default?
<BenC> pitti: Makes me happy
<pitti> BenC: we have two RC bugs on the "caveats" list since the last couple of alphas, would be nice to at least provide a workaround IMHO
<pitti> BenC: ok, then I might just do a module-init-tools upload for that and see who beats me up :)
<mdz> seb128: shall I file a bug on smart-notifier as well about the bogus .desktop?
<mdz> seb128: or is it not bogus?
<seb128> mdz: yes please, the specification says it should be "true" or "false"
<mdz> seb128: filed bug 257321 and purging smart-notifier from my system ;-)
<ubottu> Launchpad bug 257321 in smart-notifier "Syntax error in /etc/xdg/autostart/smart-notifier.desktop" [Undecided,New] https://launchpad.net/bugs/257321
<seb128> thanks ;-)
<davmor2> pitti: just to confirm grub works :)
<mdz> pitti: should I file a bug report to track whatever is causing the test failures in apport?
<pitti> mdz: that would be good, please assign it to me
<pitti> might be a kernel prob, but apport will do for now
<buggs> hoi
<buggs> bryce, i'm here because of the xrandr problem here: https://wiki.ubuntu.com/X/Projects
<pitti> yay, ubiquity now has an "automatically sign in" checkbox
<superm1> ah i knew it was in oem-config, glad it made it to ubiquity too :)
<mdz> pitti: test-apport kernel fails reliably for me on * Check that collected system groups has nonempty user groups information
<mdz> pitti: done, bug 257326
<ubottu> Launchpad bug 257326 in apport "Misses some segfaults on Intrepid" [Undecided,New] https://launchpad.net/bugs/257326
 * mdz notices the we-love-pitti team in launchpad
<pitti> mdz: thanks
<pitti> ugh, kvm lockup
<asac> johanbr: ok. just saw that i didnt upload the -vpnc package to hardy yet
<asac> johanbr: thats now done
<asac> so in a few ours you should get a better package
<mdz> pitti: I've also filed bug 257331
<ubottu> Launchpad bug 257331 in linux "apport triggers hung task timeout" [Undecided,New] https://launchpad.net/bugs/257331
<johanbr> asac: Sorry, but what does the hardy package have to do with the 0.7 package in intrepid?
<pitti> mdz: ah, good idea
<pitti> meh, does editmoin work for anyone else with wiki.u.c.? stopped working for me some days ago, even after updating my cookie
<asac> johanbr: ok. then i didnt get you right
<asac> johanbr: if you have opened a bug, i will come to it soon
<asac> pitti: testing and if good uploading nss. thanks for prodding
<asac> pitti: uploaded
<pitti> asac: is there a spec for the new network-manager, where I could take a "release notes" paragraph from?
<pitti> asac: I guess you want it mentioned in the alpha-4 notes :)
<johanbr> asac: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/257336
<ubottu> Launchpad bug 257336 in network-manager "vpnc UI not built in n-m 0.7" [Undecided,New]
<pitti> bryce, tjaalton: I added a stanza about new X and input hotplug to https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview ; I'd appreciate a review and corrections/amendments
<pitti> asac: please feel free to fill out the networkmanager section here ^
<seb128> emgent: is adding a webpage in the control really worth having local change for a package which was in sync before!?
<emgent> seb128: i opened bug in BTS too
<emgent> i hope that new debian commit is again a sync for ubuntu
<asac> pitti: added to TODO ... on my way out; ill see if can add that section when i come back
<seb128> emgent: still, do you really think it's worth having divergence?
<seb128> emgent: can't that be reported to debian so it'll be part of the next syncs?
<emgent> seb128: in the next debian commit is again a sync, homepage field is more util in packages.ubuntu.com
<seb128> emgent: you are creating extra work for everybody there (need to have ubuntu changes, then to file a sync request, etc)
<emgent> seb128: i know it`s a minimal issue
<seb128> emgent: what was so urgent that you could open the debian bug, wait for them to do the change and sync?
<seb128> couldn't
<emgent> ok understand
<seb128> thanks
<emgent> np thanks to you
<seb128> it's better for everybody to keep packages in sync when that's possible
<seb128> changing a control description is usually not a real compelant reason to bring divergence
<tjaalton> pitti: looks good, although it's RC6 :)
<asac> johanbr: what was your bug id again?
<johanbr> asac: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/257336
<ubottu> Launchpad bug 257336 in network-manager "vpnc UI not built in n-m 0.7" [Undecided,New]
<asac> johanbr: i dont think there is a ui still needed
<johanbr> asac: Can you add vpnc connections with the editor?
<asac> johanbr: yes ... you need the network-manager-vpnc package > 0.7~~
<johanbr> asac: that's installed
<asac> which version?
<johanbr> 0.7~~svn20080807t145225-0ubuntu2~nm2
<asac> johanbr: killall nm-applet
<asac> then nm-applet from a console
<asac> what errors do you see when going to the VPN tab
<alex-weej> setting "Normal" "Effects" in gnome-control-center activates compiz but doesn't seem to set the /apps/gnome-session/gnome-wm key to "compiz" -- it stays as metacity
<alex-weej> this is broken, ya?
<johanbr> asac: none
<asac> johanbr: which network-manager-gnome-package version?
<tjaalton> pitti: fixed
<asac> johanbr: err, s/-package/ package/
<johanbr> asac: ahh, there's an update for that. Let me try...
<asac> johanbr: upgrade everything to latest from PPA
<totopalma> hi :)
<totopalma> Riddell, can you take a look at bug #250459 please? :)
<ubottu> Launchpad bug 250459 in net-snmp "Example in snmpcmd man page shows wrong parameter" [Undecided,Confirmed] https://launchpad.net/bugs/250459
<totopalma> tseliot, hi :)
<tseliot> totopalma: hi ;)
<mathiaz> totopalma: It's on my sponsoring list - I'll have a look at it later today
<totopalma> mathiaz, ah, ok :)
<Riddell> totopalma: not today I'm afraid (still at akademy0
<johanbr> asac: installing the new network-manager-gnome improved things a bit. Now I get the UI, but the OK button is greyed out, even after I've filled out all the account info.
<alex-weej> when i cat a /dev/input/eventX file shouldn't i get some data when i, e.g, stroke my touchpad or press keys?
<asac> johanbr: for met just "gateway" + "group" enabled OK
 * asac out .... will be back later
<johanbr> asac: got it. Works for me.
<asac> cool
<johanbr> Stupid mistake on my part.
<kirkland> TheMuso: any chance  you're around?
<emgent> pitti: one question, rapache is backported in hardy and I have one fix to apply (applyed in intrepid now).
<emgent> i can fix it in hardy too or i should ask another backport ?
<emgent> ScottK ?
<kirkland> slangasek: hi, ping me if you come around and have a few minutes for grub/raid
<LaserJock> emgent: you are asking if you should upload to hardy-backports directly or ask for a new backport?
<emgent> LaserJock: correct
<LaserJock> emgent: ScottK would know for sure, but I believe if it's a no-change backport it's supposed to go through the normal backporting process rather than direct upload
<tseliot> superm1: how did you fix this bug (i.e. which way did you choose)? https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/254969
<ubottu> Launchpad bug 254969 in nvidia-graphics-drivers-71 "package nvidia-glx-71 None [modified: /var/lib/dpkg/info/nvidia-glx-71.list] failed to install/upgrade: subprocess pre-installation script returned error exit status 2" [Undecided,Confirmed]
<Adri2000> Riddell (as it's your day) or any archive admin: amsn hardy sru (bug #243722) received sufficient positive feedback now I think, and it's been 7 days since it was approved in -proposed (I think it's the minimum time, but can't find it on the wiki), so could you move it to -updates please?
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,Fix committed] https://launchpad.net/bugs/243722
<tjaalton> tseliot: nvidia-glx-* should Conflicts: xorg-driver-fglrx
<superm1> tseliot, just conflicts: nvidia-glx-*
<superm1> listing all 4 of them
<superm1> eg nvidia-glx-71,nvidia-glx-96 etc
<tseliot> superm1,tjaalton: there are at least 2 ways to do it
<tseliot> the easiest solution (for us) is what you suggested
<tseliot> something a bit harder would be Conflicts, Replace, Provides and some diversions
<tseliot> superm1,tjaalton: so that you won't have to uninstall one driver before you can install the other
<tacone> tseliot: what's the status of your xorg parser ?
<tseliot> I'm ok with either solution
<tseliot> tacone: it works well and should be introduced soon. Why are you asking?
<tacone> because I am working to a parser either (apache conf).
<tseliot> tacone: I mean, did you ask because you're planning to use my parser?
<tjaalton> tseliot: it's much cleaner this way
<tacone> currently your api is different from what we're looking after, and also apache conf is a little different. but I could reuse some code, maybe.
<tacone> tseliot: also may I ask you if you tried augeas and what do you think of it ?
<tseliot> tjaalton,superm1: let's use Conflicts since it will make maintainance easier
<superm1> tseliot, ok
<tseliot> tacone: no, sorry I haven't tried augeas yet
<tacone> tseliot: ok, thank you
<tseliot> superm1: ok, I'll add the Conflicts to my packages soon.
<superm1> tseliot, the fglrx won't see the changes until 8-8
<superm1> no use doing another upload until then since they are still broke anyway
<superm1> due to the xorg 1.5 abi junk
<tseliot> superm1: right. I'm doing the same for my 2 legacy drivers
<giacomo> hello
<LaserJock> hmm, not sure if it's just me or not but Hardy seems to be getting buggier the longer I use it
<LaserJock> it'd be interesting to see if that's a general trend
<\sh> LaserJock: regarding desktop or server?
<LaserJock> desktop
<LaserJock> a few days ago my network stopped working right after resuming
<LaserJock> and today the gnome clock applet seems to not work
<\sh> ah...I use kde 4.1 from ppa..there are no bugs ,-> just tasks to be finished ;)
<LaserJock> but those are just the latest "regressions" I've encountered
<LaserJock> \sh: many many tasks ;-p
<\sh> LaserJock: not so many tasks then the desaster bug from vmware today
 * \sh needs to switch to gnome at some time again to see the state..
<LaserJock> \sh: I managed around 2 days on KDE 4.1
<LaserJock> a big improvement from 4.0 for sure, but it seems to me like KDE must be designed by people with large resolution monitors
<LaserJock> because all the windows/widgets are huge on my laptop
<norsetto> LaserJock: we care for the visual challenged
<\sh> LaserJock: nope...when you adjust the sizes to your needs, it fits also on a 1024x768 low form factor display
<LaserJock> hmm, on my 1440x900 laptop it's quite cramped
<\sh> LaserJock: on this t43 1400xsomething it fits very nicely..,much better then on my 1280x1024
<slytherin> doko: Can you please take a look at bug 256949? It is within your jurisdiction. :-)
<ubottu> Launchpad bug 256949 in java-common "Wrong value for symlink default-java causes build failures on powerpc" [Undecided,New] https://launchpad.net/bugs/256949
<\sh> LaserJock: but do you think the errors are coming from updates to your used software?
<\sh> LaserJock: or more a side-effect of new upgraded libs?
<LaserJock> \sh: well, that I don't know
<doko> slytherin: ohh, please fix
<LaserJock> there have been so many Gnome updates I just don't know where to even begin
<LaserJock> and I'm not sure if it's Gnome itself in the case of the network problems
<slytherin> doko: The observation I have put in the bug ia based on analysis of source package. I don't have access to powerpc machine to verify.
<\sh> LaserJock: because what I saw in the past was "we are upgrading libX" after that "app Y" doesn't work anymore, and the error message is just "can't connect to X display" even when it's set in the current session and I see my X running..very strange
<doko> slytherin: well, it sounds plausible =)
<slytherin> doko: ok, I will attach a debdiff in 5-10 minutes and let you know.
<LaserJock> \sh: hmm, seems my laptop is 1280x800, perhaps that's why KDE seems so cramped
<\sh> LaserJock: oh those 16:9 displays...I'm happy to got rid of this laptop I had...
<slytherin> doko: just let me know if my understanding is correct i.e. jvmdir is the variable to be referred.
<LaserJock> though Gnome seems noticeably better in terms of screen real estate
<LaserJock> perhaps I just can't find the "shrink it all" switch in the KDE settings ;-)
<\sh> LaserJock: ah this, ask Riddell because we simplified it *eg*
 * \sh runs
<didrocks> doko: Hi Matthias
<didrocks> I do not understand very well your comment on the bug #203636
<ubottu> Launchpad bug 203636 in sun-javadb "replace icedtea-java7 references with openjdk-6 references" [Undecided,Confirmed] https://launchpad.net/bugs/203636
<didrocks> do you want me to replace Depends: openjdk-6-jre | sun-java6-jre | j2re1.6 , libhiglayout-java, libwoodstox-java, , java-wrappers (>= 0.1.4)
<didrocks> by Depends: default-jre-headless,
<didrocks>  libhiglayout-java, libwoodstox-java, , java-wrappers (>= 0.1.4)
<didrocks> for instance?
<slytherin> didrocks: he meant to add dependency on 'default-jre | java2-runtime' instead of openjdk-6-jre | sun-javar-jre etc. I shuld have told you that myself. I overlooked. :-(
<didrocks> slytherin: no pb. Indeed, I just removed the java-7 dependency. Ok, I will replace "openjdk-6-jre | sun-java6-jre | j2re1.6" by "default-jre | default-jre-headless", is it correct?
<didrocks> ok, I see that on https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-July/000460.html
<slytherin> didrocks: It is either 'default-jre | java2-runtime' or 'default-jre-headless | java2-runtime-headless'. Headless if the package does not any UI classes like AWT and SWING.
<didrocks> yes, I am currently reading that. I will inspect the code to see if it needs it or not. More stuff to deal with so :)
<didrocks> thanks a lot slytherin
<doko> the point is, that we might have different jres/jdks on different archs, and just depending on openjdk gets you the wrong one one these archs
<slytherin> doko: I have just added debdiff for the powerpc problem. Should I subscribe main-sponsors or are you are going to take care of it immediately?
<didrocks> doko: yes, someone pointed me to the ML when you explained that. I must admit I forgot itâ¦
<didrocks> time to sleep, by all ;)
<kirkland> pitti: BenC: either of you around?
<TheMuso> pitti: Ok, I'll grab the latest daily today and investigate. If it still exists for me, I'll look into blacklisting the module, however I am concerned doing that will get rid of all PC speaker support in Ubuntu altogether, and people like myself still find the PC speaker useful sometimes, but if thats our only option...
<TheMuso> kirkland: I'm around now.
#ubuntu-devel 2008-08-13
<kirkland> TheMuso: no worries, I think I figured it out ;-)
<TheMuso> kirkland: ok.
<tormod> TheMuso: the pc speaker issue, can it not be fixed by lowering the priority of the device some way, like the index=-2 for modems and usb devices?
<TheMuso> tormod: That has been done for alsa, its pulseaudio thats the issue, as well as the volume for the pcsp alsa device, at least on the hardware I have. If pcsp is muted, then for me at least, there is no sound from the pc speaker when pulse initializes it.
<tormod> TheMuso: what criteria does pulseaudio use for selecting the primary sound device?
<TheMuso> tormod: Unless the user has set a configuration to use a particular device, pulse uses the first device it finds.
<tormod> and it does not go through them in alsa order?
<TheMuso> tormod: It goes through them in the order that hal lists them.
<tormod> I am sorry I don't know how these things are stacked
<TheMuso> tormod: But thats no longer the issue. The pc speaker will never be used by default any more, but the crackling/squeaking sound people get is the issue.
<tormod> ok
<mardi_soir> hello
<RAOF> Oh, curses.  Pulseaudio's getting killed with "Soft CPU limit exhausted" messages again.
<crimsun> more context?
<jdong> I think RAOF is playing cheapskate CPU socialist government with his shell server ;-)
<RAOF> crimsun: Run pulseaudio.  Play some music.  At some point pulseaudio will be killed with SIGXCPU.
<LaserJock> crimsun: you know, the thingamagiggie bug in the whatchamacallit
<crimsun> RAOF: erm, 8.10? more detail? :)
<RAOF> crimsun: 8.10, updated as of this morning, just started happening.
<crimsun> interesting, I'll pull a daily-live shortly
<RAOF> This _has_ happened before, though.  I forget what happened then, though.
<pushax> hi all.  A question. Which html engine as the most interoperability?
<LaserJock> pushax: I'm not sure this is the best channel to answer that
<RAOF> pushax: In what way do you think that's on-topic for #ubuntu-devel?  Also, there's nowhere near enough information; what do you mean by "interoperability"? :)
 * RAOF watches the SIGXCPU signals being ruthlessly caught by gdb.
<pushax> ROAF as I want to develop and application but want ti to run also on other systems with minimal changes.
<RAOF> pushax: Still off-topic, but both firefox & webkit should be nicely portable.
<pushax> KHTML/webkit seems to the be well supported.  I'm fairly new to linux.
<pushax> what is the default engine on Gnome?
<pushax> is gecko a complete web engine?
<pushax> brb
<lifeless> gecko is the core of firefox
<lifeless> webkit is the core of safari
<pushax> does gnome has a web layer?
<LaserJock> pushax: Gnome's default web browser, epiphany, has used gecko, but I think webkit is also being worked on
<RAOF> Epiphany is moving removing the pluggable backends and supporting just webkit, but it's apparently not going to make 2.24
<pushax> thanks gyes
<pushax> I wanted soem base, before jumping into reading
<LaserJock> hmm, KDE and gnome seem to share the same autostart systems
<LaserJock> that seems slightly inconvenient
<RAOF> I believe KDE respects the X-KDE-StartOnlyInKDE key, fwiw.
<LaserJock> but does Gnome respect X-Gnome-StartOnlyInGnome ?
<LaserJock> that's what started this all, Gnome-do was starting in my KDE session and screwing up some things
<LaserJock> then I disabled it from KDE and it disappeared altogether from Gnome
<LaserJock> hmm, KDE needs to respect X-GNOME-Autostart-enabled I think
<Hobbsee> i presume so, but has someone pointed out prior to this point that the information printed on the 8.04 cd sleeves is incorrect?
<ajmitch> Hobbsee: which info is that?
<Hobbsee> ajmitch: the stuff about the default option being deleting all data on your computer.
<dholbach> good morning
<Hobbsee> hey dholbach
<dholbach> hiya
<\sh> moins dholbach
<lukehasnoname> I know it's supposed to be a recovery console, but doesn't anyone think it's insecure to have the recovery console (root) not be password protected?
<lukehasnoname> What good is locking my screen when a friend (enemy) could reboot, go into recovery and have root control?
<dholbach> hi \sh
<realist> lukehasnoname: if your enemy has physical access, you've already lost the battle
<RAOF> lukehasnoname: That's what luks is for.
<lukehasnoname> sudo passwd root
<lukehasnoname> luks...
<RAOF> Encrypted hard drive.
<realist> RAOF means; encrypted root partition
<lukehasnoname> ah, yes.
 * \sh just fixes all the ESX servers in our company...grmpf 
<RAOF> Failing that, physical access trumps everything (and, of course, not even failing that given sufficient encouragement).
<realist> Which still wont protect you from someone attempting the frozen memory reboot technique.
<lukehasnoname> I'm also thinking of the general population, who won't have any idea to encrypt / or to change root's pass.
<RAOF> lukehasnoname: It's a trade-off between convenience and (a little) security.
<lukehasnoname> true.
<\sh> most people won't know how to access a machine without a password...it's only a promille of the world population
<realist> lukehasnoname: I happen to agree with you, by the way. Setting a root password is still a "good idea"
<RAOF> The alternative to "no password required for recovery access" is "the root password that you typed once 2 years ago when instaling the system and you've now forgotten is required"
<StevenK> Which Windows can do.
<realist> RAOF: in which case you can still boot from a recovery disc, chroot, and passwd
<RAOF> realist: Indeed.  So what has your root password on recovery access given you?
<\sh> realist: that's what bios boot security is for
<realist> RAOF: false sense of security :-)
<RAOF> realist: Right :)
<StevenK> \sh: Sure, and you reboot a server remotely, and then have someone type the password. No, bad.
<realist> StevenK: reboot remotely... from alternate boot media?
<\sh> StevenK: hmmm? remote insight boards are quite common in our days
 * \sh doesn't need remote hands to do the usual work
<realist> \sh: or a remote kvm
<StevenK> I tend to not like remote KVMs
<\sh> realist: I'm HP fan ;) so I have ILO :)
<StevenK> They do horrid things like want Java
<realist> I'm a Sun fan, so I have an ok> prompt via serial console ;-)
<realist> StevenK: not 'real' kvms
<StevenK> The "real" remote KVMs tend to cost large sums of money
 * realist truely dislikes those web-based remote consoles (eg. Dell RAC, or IBM RSA)
<realist> StevenK: there's a nice market there for an open source (hardware/embedded) alternative
<Treenaks> nice or niche :)
<spm> fwiw, even encrypted partitions can deliver a false sense of security: eg Attacker holds gun to head of (liked vs disliked :-) ) co-worker: "give me the code or bang". There's always a way around, just depends on how much effort an attacker is willing to invest.
<RAOF> spm: Or the person with physical access could add a hardware keylogger, or whatever.
<spm> RAOF: sure. or take the unencrypted backup tapes :-D
<RAOF> Indeed.  Whatever.  Physical access > *.
<spm> Hence: Defence in Depth. Physical. Personnel. Logical. (sorry for lecture mode. used to teach this crap... ;-) )
<lukehasnoname> spm, a/s/l
<lukehasnoname> haha
<lukehasnoname> I believe I am one of the younger people to hang around here on the IRC.
<spm> lukehasnoname: us grumpy old farts were young once. just remember that. :-P
<lukehasnoname> I'm sure. I've been realizing that more and more recently
<pitti> Good morning
<StevenK> Morning pitti
<pitti> emgent: it's always better to do a normal upload to intrepid only, and an automated backport to hardy
<Hobbsee> pitti!
<pitti> emgent: manual uploads to *-backports should be avoided, and require a special rationale
<pitti> kirkland: I am now
<pitti> TheMuso: I already blacklisted it yesterday; testing and input appreciated
<pitti> TheMuso: I know that it isn't ideal, but I think it's still better than living with those eternal squeaks and hangs
<pitti> TheMuso: and if we don't have another solution, we can still re-enable kernel support for the old module?
<pitti> hey StevenK, moin Hobbsee
<TheMuso> pitti: Yeah I saw, I found a fix for the original problem I tried to fix in alsa-utils. I simply needed to move the calls to mute the pc speaker card to 0. It should be fine now. I have yet to upload alsa-utils, but I've tested the fix locally and it works.
<pitti> TheMuso: but how is that different, in principle?
<pitti> TheMuso: pc speaker keyboard beeps won't be audible?
<TheMuso> pitti: Its because I forgot that udev calls the alsa init script for individual cards, so the reset for pc speaker mute wasn't being called.
<TheMuso> pitti: Pc speaker beeps will still be audible. That is a different control for the mixer of the pcsp card.
<pitti> TheMuso: ah, I see
<TheMuso> If you were to load the pcsp module now, and check the mixer, you will notice a few controls, one is PC speaker which is the beeps.
<TheMuso> The Master volume is separate and the one we are wanting to quash.
<pitti> TheMuso: other thing, the reported hangs at session start in vmware et al, that won't change with changing the volume, will it?
<TheMuso> pitti: I don't know. I don't have VMWare to test with.
<pitti> TheMuso: happened to me in kvm, too; not very reliable, seems to be a race condition
<pitti> I had it hang in vmware and kvm three times, then tried half a day later, and had it working in kvm
<TheMuso> pitti: Is it anything to do with sound?
<pitti> TheMuso: that's just what bug 246969 claimed
 * TheMuso looks
<pitti> no bugbot?
<StevenK> Nope, ubotu is MIA
<pitti> TheMuso: when I experienced the bug, playing the startup sound through pcsp took half a minute or longer, which could be well perceived as 'hanging'
<TheMuso> pitti: Right, but the startup sound will not play through PC speaker any more, the only thing that can still be heard is crackling, which I have now found a better fix for.
<pitti> TheMuso: how did you fix the former?
<pitti> i. e. ignoring the card if it's there?
<TheMuso> pitti: Patched pulseaudio to make sure that the last device it loads support for is pcsp.
<TheMuso> pitti: Pulse doesn't ignore it, it just loads pcsp support last.
<TheMuso> With my patch.
<pitti> TheMuso: how does that help? if you don't have any other card, pcsp is the one that gets used
<TheMuso> Prior to that, hal was giving pulse a list of devices, with pcsp at the top of the list.
<pitti> and in VMs you very often don't have any other card
<TheMuso> pitti: THis is true. I can blacklist the pc speaker from being used with pulseaudio entirely, however I have had some users say that pcsp is sometimes useful with pulse, believe it or not.
<TheMuso> back in a bit
<\sh> oh what a day...esx update works out of the box
<Treenaks> \sh: it'd better, after yesterday
<\sh> Treenaks: well, updates via update manager are still not working...but suspending all vm-machines, and applying the issued update package manually from the commandline works as expected..and all machines are coming back without any errors
<TheMuso> back
<TheMuso> pitti: Ok, after the alpha, I'll blacklist the PC speaker from pulse altogether, and we can unblacklist it.
<superm1> pitti, I remember you had some chatter going on about usplash and uvesafb a week or so ago.  "should" things be stable on it right now?
<pitti> superm1: stable in the sense of "it didn't change", but it's still broken
<superm1> pitti, okay wasn't sure if i was having isolated incidents that i should file bugs on
<superm1> but that clears that up :)
<tjaalton> pitti: ok if I upload xorg which drops input devices from xorg.conf (irrelevant now anyway, and possibly only confusing)?
<pitti> tjaalton: the a4 candidate CDs are in the middle of building
<tjaalton> pitti: doesn't touch existing conf's
<tjaalton> pitti: hum, ok
<pitti> tjaalton: do you think that is critical for a4? if so, it's doable, just asking
<tjaalton> pitti: not critical, just that people might be confused by seeing entries in the conf that have no meaning
<tjaalton> forgot to upload earlier.
<pitti> would you be fine with uploading it on Friday?
<tjaalton> pitti: sure, no problem
<pitti> if you are concerned that people get confused about it, feel free to add a caveat to the release notes (https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview)
<pitti> tjaalton: ok, thanks
<tjaalton> pitti: ok, that would work
<tjaalton> pitti: done
<pitti> TheMuso: oh, I just noticed that livefses are reeeally old, so they just didn't contain your latest fixes
<pitti> ok, not that old, 20080808 built
<pitti> now they fail with "couldn't find xresprobe"
<StevenK>  xresprobe | 0.4.24ubuntu8 |         hardy | source, amd64, i386
<StevenK>  xresprobe | 0.4.24ubuntu8 | intrepid/universe | source, amd64, i386
 * pitti fixes livecd-rootfs
<StevenK> pitti: ^
<pitti> right, I was told xresprobe isn't necessary any more
<TheMuso> pitti: right.
<pitti> siretart: here by chance?
 * pitti points tkamppeter at the soft freeze and the topic; please try not to break anything in intrepid ATM :)
<ion_> tkamppeter: How would one go about testing the new PDF pipeline used by CUPS without wasting paper? I could of course print blank sheets, but is there a way to simulate and print the filter chain without printing?
<Hobbsee> ah yes, that reminds me.  really should track down that printer bug.
<ion_> Uh, s/simulate and print/simulate and dump/
<pitti> ion_: you could set up a file:// queue?
<ion_> pitti: Thanks
<pitti> if you found out, that would make some nice test scripts
<slytherin> Can anyone please sponsor the fix for bug 256949? I expected doko to do that by now, but he seems to have forgotten or missed it.
<ubottu> Launchpad bug 256949 in java-common "Wrong value for symlink default-java causes build failures on powerpc" [Undecided,Confirmed] https://launchpad.net/bugs/256949
<pitti> ion_: cups upstream has a test suite and runs it during build, but unfortunately the new filters aren't covered by that yet
<pitti> slytherin: doko is on a conference
<ion_> Ok
<slytherin> pitti: so does that mean he will be available soon?
<pitti> slytherin: no, not before next week
<pitti> slytherin: I can upload that for you
<tkamppeter> ion_, you can creat a printer which prints into a file. At first do
<tkamppeter> cupsctl FileDevice=yes
<tkamppeter> Then create a queue with URL file:/tmp/printout
<tkamppeter> /tmp/printout will be of the format what the printer expects.
<pitti> slytherin: uploaded, thanks
<ion_> Alright
<slytherin> pitti: Thanks. :-)
<pitti> slytherin: once it's built and in the archive (ideally in about 1:10 hours), feel free to toss a list of packages to me which should be reattempted to build on powerpc
<slytherin> pitti: sure.
<tkamppeter> ion_ to get a PDF printing workflow you need a driver which already accepts PDF. This is currently gutenprint and other CUPS-raster-based drivers (others to follow).
<tkamppeter> Second, use PDF as input format, by either using KDE or Qt apps for printing or by sending PDFs directly (lpr -P <printer> <file>.pdf).
<pitti> tkamppeter: let's hope that once Mike integrates those filters upstream, they'll get tested in the test suite eventually
<tkamppeter> pitti, I hope so, too, but he did not answer to CUPS bug 2897 yet ...
<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
<ion_> tkamppeter: I noticed cupsfilter and tried cupsfilter -p /etc/cups/ppd/HP_LaserJet_2300.ppd /usr/share/doc/gdb/refcard.ps.gz. It began processing it correctly by running /usr/lib/cups/filter/pstopdf, but that script failed because PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin/usr/bin (note the last item).
<ion_> tkamppeter: I mean, cupsfilter itself printed: DEBUG: envp[6]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin/usr/bin"
<ion_> tkamppeter: % strings =cupsfilter | grep usr/bin
<ion_> %s/filter:/usr/bin:/usr/sbin:/bin/usr/bin
<pitti> slytherin: the build made it quickly enough, so the after the next publisher (in 1 hour) it will be avilable
<slytherin> pitti: Cool. I will keep list of packages ready. Should I split them by main/universe?
<pitti> slytherin: for retrying the builds? not necessary
<pitti> slytherin: I'd just appreciate if you could do the list with just spaces, no commas, and no "or", "and", etc. in between, so that it is cut&pasteable
<slytherin> pitti: sure
<tkamppeter> ion_ so the CUPS code contains a bad path? Looks like a bug in CUPS. But as all needed directories are there, this should not be the source of the problem.
<tkamppeter> ion_, but cupsfilter has one problem: It does not report what the actually used filter chain is.
<ion_> tkamppeter: Iâm about to send a diff for cupsfilter. Oh, and it seems to print which filter commands it runs.
<StevenK> pitti: Remind what needed libxsettings in main?
<tkamppeter> ion_ for me
<tkamppeter> cupsfilter -p /etc/cups/ppd/x.ppd ~/walking-map-portland-1.pdf > x
<pitti> StevenK: matchbox-window-manager and libmatchbox
<tkamppeter> says that gziptoany and no other filter was invoked, strange, as nothing is gzipped here.
<tkamppeter> pitti, all printing-related uploads which I am doing currently cannot break the installation or the CD size. They do not introduce new dependencies.
<pitti> "famous last words" :) , well, just be careful
<pitti> breaking printing would be bad enough :)
<tkamppeter> pitti, they are mainly changing PPD files and such so that PDF printing will work. Alpha 4 users should test the PDF workflow.
<pitti> tkamppeter: right, but many alpha-4 CDs are already done
<pitti> kubuntu is missing still, rest should already work
<tkamppeter> If certain jobs do not print we have still two months to fix these cases.
<Ng> ./win 69
<Ng> gar
<lifeless> nice number there
<Ng> I really need to alias /win to /fail given how often I manage to type something else first ;)
<tkamppeter> ion_ for better testing you should create a queue printing into a file and set debug mode. Then yiou can see the actual filter chains in error_log
<ion_> tkamppeter: Alright
<mcadetg> hi, I've a problem with lib/firmware when trying to compile/install vanilla kernel on ubuntu via the git/debian way...
<mcadetg> I think the main problem is that dpkg -i linux-image tries to install firmware in /lib/firmware instead of /lib/firmare/$(uname -r)
<mcadetg> can I configure this somewhere under the debian control directory?
<ion_> tkamppeter: http://heh.fi/tmp/cups_1.3.8-4.debdiff
<StevenK> pitti: Thanks, MIR coming soon.
<tkamppeter> ion_, thanks. Please do also report a bug to CUPS upstream: http://www.cups.org/str.php
<ion_> tkamppeter: Will do.
<tkamppeter> ion_ I have found also another cupsfilter bug: I can print a JPG in a regular queue but not via cupsfilter. Seems that cupsfilter does not see all conversion rules.
<StevenK> pitti: MIR for libxsettings is bug 257541
<ubottu> Launchpad bug 257541 in libxsettings "MIR for libxsettings" [Undecided,New] https://launchpad.net/bugs/257541
<StevenK> pitti: I thought you NBS'd out gnustep-back0.12?
<pitti> not yet, still wrestling with CDs
<StevenK> pitti: If not, gnustep-back0.12 gnustep-back0.12-art libgnustep-base1.14 libgnustep-gui0.12 can all go.
 * pitti -> back in ~ 1 hour
<ion_> tkamppeter: I tried cupsfilter -m application/vnd.cups-postscript /usr/share/doc/gdb/refcard.ps.gz with the patched cupsfilter, it did gziptoany | pstops, i.e. didnât do gziptoany | pstopdf | pdftopdf | pdftops. Should it have done that?
<echo6> I'm looking for a method of enforcing mount read-only,  especially on a livecd,  there appears to be no way to enforce this using hal policies / gnome-mount. Is it possible that this can be remedied in future releases. Where should I post/email to bring this to the developers attention??
<ion_> tkamppeter: Iâll try with a file printer next.
<kirkland> pitti: hi, i was working on grub and I saw that both you and benc had also made some changes...  however, I was working off of a bzr branch, but I couldn't find your bzr branches
<pitti> kirkland: I didn't do a bzr branch, just a regular upload; it doesn't have Vcs-Bzr:
<pitti> kirkland: if it is in bzr, can you please add the Vcs header?
<pitti> kirkland: my debdiff is attached to the bug
<kirkland> pitti: hmm, when I do an apt-get source of grub, i see ....
<kirkland> NOTICE: 'grub' packaging is maintained in the 'Bzr' version control system at:
<kirkland> https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu
<slytherin> pitti: This is the list of packages with FTBFS on powerpc - ant bsh jakarta-log4j libjaxp1.3-java libmx4j-java libservlet2.4-java libxerces2-java sacjava libjdic-java
<pitti> kirkland: oh, whoops *brown paperbag*
<pitti> kirkland: sorry, I'll commit my change then
<dholbach> this is the most hilarious piece of feedback on the Global Bug Jam: http://daniel.holba.ch/blog/?p=167#comment-92989
<kirkland> pitti: cool, thanks.  i was thoroughly confused :-)
<kirkland> dholbach: :-D
<kirkland> dholbach: good point...  lady bugs are too cute to be a representative of truly nasty bugs :-)
<dholbach> kirkland: tell kwwii - he did the logo :)
<pitti> slytherin: all given back
<kirkland> dholbach: ;-)  if you want an ugly bug, you have to go with a flea or a tick :-)
<pitti> kirkland: oh, right, the bzr branch is horribly out of date
<thorwil> uglier bug availabale for reuse: http://thorwil.files.wordpress.com/2008/01/banner_bugs_01_i.png ;)
<pitti> kirkland: seems that we first need to commit the last 5ish uploads first
<kirkland> pitti: i think benc may have done the same thing, possibly
<kirkland> pitti: i have a bug fix for #33649 in https://code.launchpad.net/~kirkland/grub/33649b
<ion_> Missing a âs
<pitti> kirkland: maybe you can grab the debdiffs from https://edge.launchpad.net/ubuntu/+source/grub and commit them one by one into the ubuntu branch? (sorry, I am pretty busy with RMing for alpha-4)
<kirkland> pitti: let me see what I can do....
<pitti> kirkland: oh, hang on, owned by -core-dev
<kirkland> pitti: i'll do the work in my own
<kirkland> pitti: and you can merge from there
<pitti> kirkland: I'll commit them here, don't worry
<pitti> kirkland: the raid fixes in the UNRELEASED commits are not yet in intrepid, right? (you are the current changelog owner)
<kirkland> pitti: that is correct
<pitti> ah, they were recently merged by slangasek
<kirkland> pitti: kees gave verbal approval of those changes before the bzr/dsc diversion was discovered
<kirkland> pitti: slangasek merged a downlevel version of that patch...  he asked me to fix a couple of things before releasing
<kirkland> pitti: revision 841 in lp:~kirkland/grub/33649b is what i need sponsored and committed
<pitti> kirkland: ok, all uploads committed to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu, and pushed
<kirkland> pitti: awesome, thanks
<kirkland> pitti: hang on...
<pitti> merging your branch now
<kirkland> pitti: that is a downlevel version of grub-install_better_raid.diff
<pitti> 'that'?
<pitti> pending merges:
<pitti>   Dustin Kirkland 2008-08-11 This commit adds some smarts (back) into the handling of the multiple
<kirkland> pitti: oh, wait...  looks like http://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/changes is still showing new commits
<pitti>     Dustin Kirkland 2008-08-11 slightly different approache to this problem, per IRC with slangasek...
<pitti> kirkland: ^ that's what bzr merge lp:~kirkland/grub/33649b gives me now
<kirkland> pitti: yes, that one is right
<pitti> conflicts:
<pitti>   Text conflict in debian/patches/grub-install_better_raid.diff
<kirkland> pitti: a few seconds ago, Rev 839 was the top entry on http://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/changes ;-)
<pitti> kirkland: hm, maybe you can merge your branch against /ubuntu again, now that I pushed everything, and resolve the conflict?
<pitti> I think you are in a better position to do that
<kirkland> pitti: okay, let me do that
<pitti> dendrobates, kirkland, zul: will the server team do the alpah-4 server CD testing again? (VMs are ok)
<kirkland> pitti: yeah, i can help with some of that
<kirkland> pitti:  i need to test a bunch of this raid stuff
<pitti> kirkland: yes, don't worry, please finish that first
<StevenK> pitti: Did you commit your livecd-rootfs changes to it's bzr branch?
<pitti> StevenK: yes, I did
<StevenK> pitti: Too distracted to do NBS stuff?
<kirkland> pitti: will these grub changes make it onto that iso?
<pitti> kirkland: I was just going to say, by default I wouldn't upload it, since most of the CDs are done already
<pitti> and it sounds like intrusive changes
<pitti> I'm always open for pings why this or that upload must make it to the CDs, of course
<kirkland> pitti: hmm, well, mainly because this stuff really needs testing.  i can probably live without it
<StevenK> pitti: If you're open for NBS stuff, please sync sear from Debian, no Ubuntu changes, builds fine, etc, etc, hand-wavy
<kirkland> pitti: try: https://code.launchpad.net/~kirkland/grub/33649b
<StevenK> pitti: If you commited, did you push? I can't see your changes by pulling from it.
<pitti> StevenK: *cough* try again
 * StevenK grins
<StevenK> That looks better.
<StevenK> Ah, and the sync too. Way cool.
<pitti> StevenK: gnustep NBS goo removed, thanks
<StevenK> pitti: From the directory too, or that needs a regen after a few go-rounds?
<pitti> StevenK: just from the archive
<slytherin> pitti: all packages build except one which has FTBFS for some different reason.
<pitti> still needs publisher, et all
<pitti> kirkland: merged, pushed; feel free to pull from lp:~ubuntu-core-dev/grub/ubuntu into your branch
<StevenK> pitti: It's actually 'et al' :-)
<pitti> I know, tpyo
<kirkland> pitti: cool
<StevenK> Teehhe
<pitti> yohooooo
<pitti> ubuntu livefs builds
<StevenK> \o/
<pitti> first since Sunday
<kirkland> well, if you want to get really technical, it's "et alii" or "et alia"  :-)
<StevenK> Or "et alibi" when refering to text
<StevenK> Or "et alia" as well
 * StevenK points kirkland at 'dict "et al"'
<kirkland> StevenK: agreed ;-)
<pitti> kirkland: btw, was it ever discussed to provide some helper script/app to move all secret data like gpg and ssh keys, the gnome and firefox keyrings, to ~/Private/?
<pitti> kirkland: I'm pondering using ecryptfs instead of complete LUKS-lvm for performance reaons on my next desktop install
<pitti> but I always have to manually move them across, etc.
<kirkland> pitti: \o/
<kirkland> pitti: it was discussed....  but the reception was cold/lukewarm
<kirkland> pitti: i like the idea though
<broonie> Perhaps .Private or similar since those are usually in hidden directories?
<kirkland> pitti:
<kirkland> rkland@t61p:~$ ls -al Private/
<kirkland> total 24
<kirkland> drwx------  6 kirkland kirkland 4096 2008-08-08 03:13 .
<kirkland> drwx------ 93 kirkland kirkland 4096 2008-08-13 06:40 ..
<kirkland> drwx------  2 kirkland kirkland 4096 2008-08-13 06:12 .gnupg
<kirkland> drwx------  4 kirkland kirkland 4096 2008-08-13 06:21 .liferea_1.4
<kirkland> drwx------  4 kirkland kirkland 4096 2008-02-14 06:59 .mozilla
<kirkland> drwx------  2 kirkland kirkland 4096 2008-07-26 21:49 .ssh
<kirkland> drwxr-xr-x  9 kirkland kirkland 4096 2008-08-12 14:17 .evolution
<kirkland> pitti: that's what I'm running in my Private on a daily basis
<kirkland> pitti: kees suggested liferea as a pseudo-stress test, as he's had trouble with that dir on NFS mounts before
<pitti> kirkland: ah, you are putting the entire .mozilla there? including cache?
<kirkland> pitti: yup
<sistpoty|work> must be for some reason :P
<kirkland> pitti: i'm symlinking everything back to their natural homes
<pitti> kirkland: ah, I was just going to ask
<pitti> usually I keep ~/.gnupg where it is and set secret-keyring /media/PittiCrypt/gpg/secring.gpg
<pitti> (from the time I used a LUKS-encrypted usb stick to carry my secret stuff)
<kirkland> pitti: that's a good idea
<kirkland> pitti: one thing to consider....
<pitti> because the pubring is huge and not sensitive
<kirkland> pitti: you're going to want encrypted swap as well
<pitti> and just my secret ssh key, not the entire dir
<kirkland> pitti: in that passphrases could get swapped to disk
<pitti> kirkland: well, I'm trying to achieve some more speed
<kirkland> pitti: right, totally
<pitti> kirkland: usually most programs should use mlock() properly, but that doesn't help for hibernate, of course
<kirkland> pitti: encrypting all of /usr, /lib, and so forth is a waste
<kirkland> pitti: i'd love to get your feedback on encrypted Private, if you do it
<zul> pitti: I can do some of it
<pitti> zul: great, thanks
<pitti> zul, kirkland, dendrobates: we don't need exhaustive coverage, but at least some smoke test and the particular server features you are interested in; e. g. no need to exercise all partitioning options, since they are the same on the normal alternates
<tseliot> pitti: I've been hacking on Jockey today and now it is possible to distinguish between a recommended version of a driver and the other versions
<tseliot> pitti: the only thing I'm not sure about is how you would like to highlight the recommended version: bold, underline, etc.
<tseliot> pitti: I've got the following screeshots of the gtk GUI (the last screenshot is of the QT4 gui):
<tseliot> http://albertomilone.com/ubuntu/jockey/jockey-bold.png
<tseliot> http://albertomilone.com/ubuntu/jockey/jockey-underline.png
<tseliot> http://albertomilone.com/ubuntu/jockey/jockey-recommended.png
<tseliot> http://albertomilone.com/ubuntu/jockey/jockey-kde-bold.png
<tseliot> pitti: let me know what you think
<pitti> tseliot: how does jockey find out which driver is recommended?
<tseliot> pitti: I had to add an is_recommended() method  to XorgDriverHandler. It can only return False. The NVIDIA handler overrides this method with one
<pitti> tseliot: ah, shouldn't that be on Handler, not just on XorgDriverHandler?
<tseliot> which uses nvidia-common and returns either True or False if self.package == recommended
<tseliot> pitti: I can move it there if you wish
<pitti> mpt might have an opinion, too, but personally I like the [recommended] best, since it's most obvious
<tseliot> pitti: then I added this to backend.info:  'is_recommended': str(h.is_recommended())
<pitti> tseliot: that sounds good; please adapt the test cases accordingly
<tseliot> pitti: and both GUIs will see if self._(info['is_recommended']) is True or False and set the markup accordingly, that's all
<tseliot> pitti: ok
<pitti> tseliot: please don't call _() on boolean values
<pitti> tseliot: those are not strings which need to be l10n'ed
<tseliot> pitti: where?
<pitti> tseliot: tseliot| pitti: and both GUIs will see if self._(info['is_recommended'])
<tseliot> pitti: ah, right, I'll use info['is_recommended'] instead
<pitti> right ... == 'True'
<pitti> (I know, it's weird, but doesn't work otherwise over D-BUS)
<tseliot> pitti: yes, I know that it's a string and not a bool. Otherwise it wouldn't have worked here ;)
<tseliot> pitti: which screenshot do you prefer?
<pitti> tseliot: as I said, the [recommended] one; mpt, WDYT?
<pitti> oh, not online
<tseliot> pitti: sorry, I didn't see it
<pitti> tseliot: which one do you prefer?
<tseliot> pitti: maybe the one in bold
<tseliot> pitti: I will also clean up the x-kit part of Jockey
<pitti> tseliot: btw, the place where you should use _() is the actual string, like '<b>[%s]</b>' % self._('recommended')
 * ion_ shivers at explicit âselfâ.
<tseliot> pitti: and isn't it info['is_recommended'] ?
<pitti> tseliot: no, info['is_recommended'] is the boolean, whereas 'recommended' is the string you show (or not) in the UI
<pitti> ion_: jockey's AbstractUI._() is magic, it translates keyboard shortcuts in GNOME and KDE, etc.
<pitti> so that we avoid duplicating strings just because of & vs. _
<tseliot> pitti: sorry, I meant info['name']
<pitti> tseliot: I'm confused, what's with name? what's the question?
<tseliot> pitti: ok, I see your point now.
<tseliot> pitti: info['name'] is the one which we put in the row of treeview
<tseliot> and therefore the one which we put in bold or whatever
<tseliot> if we add the "[Recommended]" string to the name
<tseliot> then we'll have to translate Recommended too
<tseliot> pitti: it's ok, don't worry
<pitti> right
<tseliot> pitti: therefore if we choose to use the word "Recommended", I will add it to ui.py
<tseliot> pitti: oh, and you don't mind if I use nvidia-common to detect the recommended version, do you?
<pitti> tseliot: as long as that logic is in the NvidiaHandler, that's fine
<tseliot> pitti: yes, it's only there. Ok, then
<tseliot> pitti: also, is there anything I can do for the progress bar or are you waiting for packagekit?
<pitti> ouch, apparently grub created a menu.list with /dev/hda1 in that amd64 desktop install, but it's boot=/dev/sda1
<pitti> tseliot: I don't think full PK will make it, that dbus-glib bug is a real blocker, and I don't know a workaround
<pitti> tseliot: so I guess we have to resort to using python-apt, and its progress callbacks
<tseliot> pitti: ok, I'll have a look at it then
<pitti> tseliot: great! (sorry, no time this week, I am the RM in charge for alpha-4)
<pitti> and problems pop up all over the place, as usual
<tseliot> pitti: no problem, I'll see what I can do.
 * pitti hugs tseliot
<tseliot> ;)
<pitti> kirkland: do you happen to know, do we still put things like root=/dev/hda1 into grub's menu.list?
<pitti> I mean, do we *mean* to
<pitti> (on my desktop installation I just have root=/dev/mapper/foo, which is fine)
<kirkland> pitti: i'm not sure i understand your question
<kirkland> pitti: my laptop is root=/dev/mapper/vg0-lv0, like you say
<pitti> kirkland: I mean, shuold I get UUIDs or device nodes in menu.list?
<kirkland> pitti: UUIDs, i think
<kirkland> pitti: my RAID-testing vm has root=UUID=29175762-644b-439d-a763-ab15298ef799
<kirkland> pitti: which is /dev/md0
<pitti> kirkland: right, in an alternate install I get UUIDs, in a desktop install I get device nodes
<pitti> which causes a boot failure for me
<kirkland> pitti: i should think that UUIDs would be preferred
<pitti> since the desktop install added /dev/hdXX, but the device node is /dev/sdaXX
<pitti> kirkland: absolutely
<kirkland> pitti: for that reason ^  :-)
<pitti> argh
<kirkland> pitti: does ubiquity use something different?
<pitti> and ENOCOLIN to tell us how it's all plumbed together
<pitti> kirkland: apparently
<kirkland> pitti: see the grub-installer package
<kirkland> pitti: that's what's run in the alternate installer at least
<kirkland> pitti: i have no idea about the desktop
<pitti> "Cannot determine root device. Assuming /dev/hda1"
<pitti> bummer
<pitti> kirkland: ah, no /etc/fstab, so it's probably not grub-installer
<kirkland> pitti: ah
<pitti> does anyone happen to know some bits about ubiquity? in particular, which part writes (or currently fails to write) /etc/fstab?
<cr3> pitti: would you happen to know which wiki page describes the process for renaming a package in intrepid?
<pitti> cr3: I don't think we have one
<cr3> pitti: hm, what would you recommend I do?
<pitti> best option: avoid it
<pitti> second best: upload the new package with a Conflicts/Replaces/Provides: old-name
<pitti> and have a transitional package under the old name which depends on the new name
<pitti> and keep that transitional one until the next LTS
<cr3> pitti: regarding the transitional package, I'm not sure how I understand how it can depend on the new name when the new package conflicts with the old name
<cr3> pitti: also, is the transitional package just an empty shell in order to address dependency concerns?
<sistpoty|work> cr3: the magic is the combination of conflicts and replaces of the new package, which will force the transitional package to uninstall (at least iirc)
<cr3> sistpoty|work: cool, I'll give it a whirl
<seb128> pitti, mvo: would it be possible to add an apport hook in compiz to report what nvidia binary driver is being used? there is lot of crashes in libGL coming from nvidia users and I'm not sure where to reassigning those nowadays
<jorgenpt> Hiya. Is this the right channel to ask about packaging?
<jorgenpt> (i.e. creating packages)
<seb128> jorgenpt: not really, try #ubuntu-motu rather
<jorgenpt> Ok, thanks. :)
<pitti> seb128: right, so far you just know that a reporter is using any nvidia-driver-*, not the version
<pitti> anyone with nvidia on intrepid? does "modinfo nvidia" show the version anywhere?
<seb128> MacSlow: do you use nvidia on intrepid?
<MacSlow> seb128, I'm not on intrepid on my nvidia box yet
<seb128> ok
<MacSlow> seb128, what issues are there?
<MacSlow> general Xorg or compiz?
<seb128> MacSlow: just to reply to pitt's question before
<MacSlow> ah
<seb128> MacSlow: no, just trying to include informations on the nvidia driver version in compiz bugs because they are often due to the nvidia driver
<tjaalton> pitti: I've got one back home, but it's not on currently
<pwnguin> i hear rumors that the new nvidia triage system is to mark them "wontfix" and ask users to run "nvidia-report-bug.sh" instead
<tjaalton> right
<MacSlow> seb128, pitti: for some reason I always use -> glxinfo | grep "OpenGL version"
<tjaalton> there are hundreds of nvidia/fglrx bugs that we can do nothing about
<MacSlow> seb128, pitti: never modinfo
<MacSlow> seb128, pitti: at least regarding graphics-drivers
<seb128> tjaalton: I don't aim to do something about those, they should just not be assigned to compiz
<seb128> tjaalton: and knowing what libGL is used would help to reassigning to mesa or nvidia drivers too
<tjaalton> seb128: for the time being you can assign them against nvidia-graphics-drivers-*
<pwnguin> -*?
<tjaalton> versino
<tjaalton> -on
<seb128> tjaalton: I did reassigning the new one to -177 but I'm not sure that's right
<seb128> tjaalton: that's why I was asking
<seb128> tjaalton: looks like some recent nvidia update makes compiz crash a lot in intrepid
<tjaalton> seb128: maybe -177 for all of them, since the others are a dead end
<seb128> ok will do that, thanks
<tjaalton> mine works, GF8600GT
<seb128> and again one, grrr
<tjaalton> heh :)
<pitti> seb128: a specific compiz.py package hook can just do some dpkg -l nvidia* of course
<pitti> seb128: but if it can be seen from modinfo, we can extend the generic "NonfreeModules:" field
<seb128> pitti: that would be nicer
<seb128> bug #256340 is this new nvidia crash
<ubottu> Launchpad bug 256340 in nvidia-graphics-drivers-177 "compiz.real crashed with SIGSEGV in _nv000071gl()" [Medium,New] https://launchpad.net/bugs/256340
<seb128> can we add "crash on any package in _nv000071gl()" as a hook?
<pitti> if there are so many, then a bug pattern might be adequate?
<seb128> pattern I mean
<pitti> seb128: s/hook/pattern/?
<pitti> yes
<seb128> not "so many" yet, but I reassigned 3 of those today already
<seb128> and who knows how long it'll take to get a fixed nvidia update
<pitti> seb128: "_nv000071gl () from /usr/lib/libGLcore.so.1" in StackTraceTop should do
<pitti> StacktraceTop, even
<pitti> seb128: but we don't have packageless patterns, so for now it should be against compiz
<seb128> pitti: right that was my question, the "any package" part
<seb128> I guess compiz will get most of those crashes
<seb128> so that should be good enough
<seb128> pitti: hum, there is a retracer or apport bug somewhere
<seb128> pitti: see bug #257124
<ubottu> Launchpad bug 257124 in evolution "evolution crashed with SIGSEGV in g_closure_invoke()" [Undecided,New] https://launchpad.net/bugs/257124
<seb128> pitti: it has eaten all the attachments
<pitti> seb128: whoops, WTH? did you see that more often?
<seb128> pitti: a few times since yesterday yes
<pitti> https://bugs.edge.launchpad.net/ubuntu/+source/evolution/+bug/257124/+activity shows additions, but no removals
<ubottu> Launchpad bug 257124 in evolution "evolution crashed with SIGSEGV in g_closure_invoke()" [Undecided,New]
<seb128> pitti: I bounced you the launchpad mail about the attachments removal
<pitti> seb128: thanks
<seb128> pitti: and since when does the retrace change the private status? I though somebody had to check the stracktrace before doing that?
<pitti> seb128: it's only supposed to do that for duplicates
<pitti> seb128: it removes attachments, makes it public, marks it as a dup
<pitti> maybe it crashed on the latter
<seb128> I'll keep an eye and let you know about buggy cases
<pitti> anything in the retracer log for that bug?
 * pitti chases another alpha-4 failure ATM
<seb128> pitti: 08/13/08 11:15:45: retracing #257124 exit status: 0
<pitti> seb128: did it say that it is a dupe?
<seb128> pitti: the bug has been retraced twice
<pitti> aaaah
<seb128> maybe that's a buggy case
<pitti> I bet apport got confused and tried to mark it as a dup of itself
<seb128> pitti: I did retag it since the first retracing failed to produce a good stacktrace
<pitti> but that would be weird
<pitti> we often retag
<seb128> well the log is weird, it's only line for this bug
<seb128> usually there is a
<seb128> "E: You must put some 'source' URIs in your sources.list
<seb128> Report has no crash signature, so retrace is flawed
<seb128> Duplicate check negative"
<joaopinto> has anyone else experienced bug 254060 ?
<ubottu> Launchpad bug 254060 in sysvinit "checkfs does not interrupt the boot process when expected" [Undecided,New] https://launchpad.net/bugs/254060
<seb128> anyway I'll keep an eye on it
<joaopinto> It turns the system unusable with a regular boot
<james_w> joaopinto: I think there may be another bug on that
<joaopinto> I get into gdm with the warning that my home dir is not available, checked with ps, checkfs was still running
<james_w> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/255563
<ubottu> Launchpad bug 255563 in sysvinit "Parallel fsck breaks boot when / is being fsck'd" [High,New]
<james_w> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/255562
<ubottu> Launchpad bug 255562 in sysvinit "Parallel fsck leads to unhelpful error message at login" [High,New]
<james_w> they're the ones I was thinking of
<joaopinto> My symptom is different. My system seems to boot normally and gdm runs fine. Shouldn't I get the "Do you want to skip?" notice ?
<joaopinto> oh, its equal to the second bug
<joaopinto> time to set mine as duplicate
<joaopinto> I would also appreciate if someone could check bug 254177 , since it is not a clean install, I may have changed some configuration related to the problem
<ubottu> Launchpad bug 254177 in schroot "Chroot setup failed: stage=setup-start on Intrepid" [Undecided,New] https://launchpad.net/bugs/254177
<pwnguin> there's a lot on the ML about CD space -- does the install CD use lzma-squash?
<pwnguin> err, squashfs-lzma
<tjaalton> pitti: modinfo nvidia does not say anything about the version
<pitti> tjaalton: thanks
<broonie> tjaalton: the nvidia module prints its version when it loads, if there's not been much kernel output it should be in dmesg
<tjaalton> broonie: true
<devfil_> pitti: can yo do the giveback at php5 source? it builds fine
<pitti> devfil_: nothing to give back, it already built fine
<devfil_> pitti: I'm looking http://qa.ubuntuwire.com/ftbfs/, maybe it needs to be updated, however great
 * pitti hopes that the sync flood won't break the alphas
<pitti> Keybuk: you don't happen to have an ubiquity expert up your sleeve?
<pitti> Keybuk: I'm afraid we have to release alpha-4 without desktop CDs, I don't think that there's a way for me to learn ubiquity code and do the rest of the release until tomorrow :(
<Keybuk> heh, *I* haven't got evan ;)
<Keybuk> I think he's chasing Mark's stewardess round San Francisco or something <g>
<pitti> lol
<Keybuk> (desperately trying to prove to the world that he's not gay - despite being in SF, and wearing the cowboy hat he got in TX :p)
<pitti> ok, can't help it then
<superm1> pitti, what sort of trouble is it?
<pitti> superm1: bug 257580
<ubottu> Launchpad bug 257580 in ubiquity "desktop install does not install fstab, causing boot failure" [Critical,Confirmed] https://launchpad.net/bugs/257580
<pitti> and the isntaller syslog doesn't talk about fstab at all, until grub-installer fails on its absence
<superm1> i thought partman is actually responsible for spitting out the fstab?
<pitti> superm1: right, but I didn't find anything helpful in the partman log either
<superm1> pitti, could you perhaps run ubiquity in debug mode and attach the same types of information?
<pitti> superm1: sure
<pitti> superm1: how did that work again, sudo UBIQUITY_DEBUG=1 ubiquity ?
<superm1> pitti, i thought ubiquity -d should do the trick
<pitti> superm1: that seems to work, yes
<superm1> pitti, there should then be an extra log that is in /var/log/installer after you get your failure too
<pitti> superm1: reading partman-target scripts now, but it doesn't even seem to get to finish.d
<pitti> nor does it give any helpful log info in the partman log...
<pitti> grep target /var/log/partman is completely empty
<mpt> ArneGoetje, did you see S'orlok Reaves' message about Burmese input on ubuntu-devel-discuss@?
<pitti> superm1: done
<superm1> pitti, okay i'll take a glance this afternoon and see if anything stands out to me
<pitti> superm1: thank you
<pitti> superm1: I wonder why it works in d-i, but not in ubiquity; it uses the same code, shouldn't it?
<superm1> should be
<ArneGoetje> mpt: yes
<ArneGoetje> mpt: didn't have time to answer yet
<mpt> ok
<LaserJock> seb128: is your last comment in bug #248163 still the plan?
<ubottu> Launchpad bug 248163 in gnome-system-tools "Network menu item missing in Intrepid Alpha 2" [Wishlist,Triaged] https://launchpad.net/bugs/248163
<seb128> LaserJock: yes, nm0.7 is in intrepid and it allows to do static configurations, what exactly can't you do using it?
<LaserJock> static eth0
<seb128> it allows to do that
<LaserJock> spent 20min this morning trying to get it to work
<seb128> asac: ^
<LaserJock> whenever I try the "OK" button is greyed out
<LaserJock> it won't save any configuration
<LaserJock> unless it's DHCP
<seb128> LaserJock: here it's right click on the nm icon, edit connection, select the connection, change, IPv4 settings, enter the infos
<LaserJock> right
<LaserJock> when I do that the "OK" button is greyed out
<seb128> LaserJock: did you enter the prefix informations, it's a different column and not intuitive
<LaserJock> so all I have is "Cancel" which is less than helpful
<LaserJock> yes, I filled it out completely as far as I know
<seb128> ie, you need to set the network mask there
<LaserJock> yep
<LaserJock> every column and entry line is filled in
<LaserJock> search path, etc.
<seb128> LaserJock: what "prefix" did you use?
<LaserJock> 255.255.255.0
<seb128> I just tried setting an IP and a mask and the ok is unblocked
<seb128> can you make a dialog screenshot?
<LaserJock> yeah, just got to do some rebooting since I have to do networking in Hardy ;-)
<seb128> ah
<LaserJock> brb
<pitti> asac: do you have some time for the "NM 0.7" section in https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview ? or, alternatively, tell me what to point out?
<seb128> LaserJock: wait
<LaserJock> seb128: yeah?
<seb128> LaserJock: I get the issue when selecting "manual"
<LaserJock> yeah
<LaserJock> is that not what I want?
<seb128> LaserJock: anyway "network-manager has a bug" is not a good reason to install network-admin
 * LaserJock is used to "DHCP" and "static"
<seb128> LaserJock: let's fix the bug rather
<LaserJock> seb128: well, it's a lot more convenient that NM, but I understand your point
<seb128> LaserJock: it was working when I tried some time ago, must have been broken since
<LaserJock> NM is generally a pain in the butt for me
<seb128> LaserJock: let's make NM convenient? if the dialog is not easy enough to discover or the UI sucks could you make suggestions?
<seb128> LaserJock: well, there is no reason the "edit connection" in network-manager could not be similar to network-admin
<LaserJock> it's just that it does everything automatically and I'm rarely in an environment where networking should be automatic
<seb128> LaserJock: the way forward is to fix network-manager, not to write a buggy, complicated, written in perl, non actively maintained, application
<LaserJock> for instance, it seems to try to fight between wireless and eth0
<pitti> LaserJock: really? what's a good use case of not using dhcp in an eth network nowadays? (that's an honest question, I'm curious)
<seb128> LaserJock: I've used nm0.7 to configure my wired static eth interface and that works fine
<LaserJock> can I tell it to use one or the other without constantly shutting stuff off and on?
<LaserJock> pitti: I have no idea, I've just never found a use for DHCP personally
<pitti> as in, it would make things too easy and just work? :)
<LaserJock> pitti: at uni we're all static IPs, at home I like to assign IPs so I can easily port-forward
<LaserJock> most of it (uni) is out of my control
<seb128> you can assign IPs using dhcp too ;-)
<pitti> LaserJock: static IP assigment doesn't collide with dhcp
<pitti> to the contrary, you have a central management for them
<pitti> that's what I do for our house (8 flats with 8 families)
<LaserJock> well, I'm not going to argue networking with the experts ;-)
<pitti> we need to keep IPs for the way our ISP does its accounting
<pitti> LaserJock: no, I was just really curious about use cases for manual setting of IPs
<ion_> Yeah, DHCP is really useful for assigning static IP addresses.
<pitti> because I think it's cumbersome, error prone, and quicky becomes unmanageable
<pitti> so I wondered whether there are cases where dhcp isn't adequate
<LaserJock> pitti: I've only got one place (uni wifi) that uses DHCP
<sistpoty|work> pitti: if you don't have a dchp server... e.g. spontaneous lan party with friends in a garage *g*
<pitti> and whether we might mitigate those
<sistpoty|work> (good old days)
<pitti> sistpoty|work: for that I'd recommend ipv4ll :)
<sistpoty|work> heh
<pitti> plug a cable between the two, and there they go negotiating an 169.254. address
<pitti> (works since feisty)
<LaserJock> pitti: so in my case not using DHCP is just a matter of 1) uni doesn't do it for ethernet yet 2) in my house it was easy to assign IPs
<pitti> sistpoty|work: that's a good use case, actually, and one where the particular IPs don't matter at all, just that they are all different and in the same subnet
<pitti> LaserJock: 1) is a very good reason, of course (your ISP doesn't give you one)
<LaserJock> yes, that's the troublesome case, because right now Intrepid gives me *no* network connectivity at the uni
<LaserJock> it used to be eth0 was a given and wireless was hard to set up
<LaserJock> we're quickly going the opposite ;-)
<pitti> LaserJock: back to /etc/network/interfaces then? that should work
<pitti> nm should ignore the interface in this case
<LaserJock> yikes, maybe
<LaserJock> that's what I used to do
<LaserJock> but then NM would barf, and cause problems
<pitti> that's where network-admin saves its configuration, too
<pitti> LaserJock: that needs to be fixed then
<LaserJock> ok, maybe I'll give it a go and see
<pitti> (independent of any shiny GUI)
<pitti> it's an upgrade issue, and all that
<pitti> LaserJock: ok, thank you!
<LaserJock> first I'll try to see if there's something in the NM connection editor that'll let me save the config
<LaserJock> it seems like it *should* work in the UI, so it's perhaps a bug there
<LaserJock> and if I can keep NM around without it causing problems it'd be nice
<Keybuk> ooh
<Keybuk> I made LWN
<Keybuk> http://lwn.net/Articles/293689/
<LaserJock> apps seem to be wanting to use NM more and more to determine network connectivity, which is a real pain
<ion_> Subscription required
<Keybuk> ion_: LWN is well worth the fee
<liw> I second that
 * sistpoty|work heads home... cya
<tseliot> pitti: does progress_cb exist (in oslib)?
<tseliot> pitti: you use it in OSLib.install_package()
<LaserJock> sooo, got it to work
<LaserJock> NM still has "OK" greyed out but /etc/network/interfaces had the information
<LaserJock> but resolve.conf was empty
<LaserJock> so once I put the nameservers in resolv.conf and ifup eth0 I got a connection
<pitti> tseliot: it's a function passed as a parameter to install_package()
<pitti> tseliot: install_package() has to call it regularly with current progress numbers
<pwnguin> if the ACM can publish Linux proceedings to the wider public
<pitti> tseliot: see the dummy implementation in the ubuntu branch
<tseliot> pitti: I had a look at backend.Backend.install_package() and at jockey-gtk (from the ubuntu branch). Did I missing anything?
<pitti> Keybuk: interesting, I wasn't aware that our udev rules delta was still that big
<pitti> tseliot: the thing which calls apt-get with a dummy feedback is jockey/oslib.py, install_package(), in teh ubuntu branch
<pitti> that ideally would use python-apt and real progress
<pitti> Keybuk: (why does that remind me of Mao so much? "WTF - Your rule?" -- "My rule!"
<tseliot> pitti: yes, I saw it and backend.Backend.install_package() calls OSLib.inst.install_package() right?
<tseliot> pitti: what I don't get is what the parameters passed to OSLib.inst.install_package() mean
<tseliot> pitti: the name of the package and either True or None, right?
<tseliot> pitti: but according to install_package in oslib, the 2nd argument should be a function
<pitti> tseliot: no, as the docstring says, it's the name of the package, and a function
<pitti> def my_progress_cb(phase, cur, total):
<pitti>     foo
<pitti> OSLib.inst.install_package('pmount', my_progress_cb
<tseliot> pitti: maybe I'm looking at the wrong branch. Let me get the code again
<tseliot> pitti: ubuntu-core-dev/jockey/ubuntu right?
<pitti> tseliot: yes, sounds right
<pitti> tseliot: the callback is defined in the GUI, the OSLib implementation calls it
<tseliot> pitti: in which directory do I find the file with the example? tests, example, jockey?
<pitti> tseliot: example for what?
<tseliot> pitti: OSLib.inst.install_package('pmount', my_progress_cb
<tseliot> the one you mentioned before
<pitti> tseliot: oh, I just invented that from scratch in IRC
<pitti> tseliot: the ubuntu branch's oslib.py has an implementation using apt-get
<tseliot> pitti: yes, I've noticed that
<tseliot> pitti: and does this call in backend mean anything? OSLib.inst.install_package(package, hasattr(self, '_locations') and self.install_progress or None)
<tseliot> pitti: I'm just trying to figure out where is the function which you pass to install_package() together with the name of the package.
<pitti> tseliot: ah, that's a bit tricky, it should have a comment
<pitti> tseliot: you know what "condition and a or b" does in Python?
<pitti> tseliot: similar to C's ? :
<pitti> tseliot: if condition is true, the value of that expression is a, if condition is false, it's b
<tseliot> is it like the conditional operator "?"
<sbeattie> LaserJock: what did you do to figure out how to get a static address in Network Manager?
<tseliot> yes, it's like that
<tseliot> pitti: I knew it only in C and not in python
<LaserJock> sbeattie: well, in my case I put in all the information but it won't let me save it
<pitti> tseliot: ah, there is a comment
<LaserJock> sbeattie: but when I looked at /etc/network/interfaces it was all there
<sbeattie> LaserJock: I can't even get it to do let me enter information under xubuntu
<LaserJock> sbeattie: hmm
<pitti> tseliot: so in practice that means that self.install_progress is the function that oslib install_package() calls
<sbeattie> LaserJock: http://www.nxnw.org/~steve/tmp/xubuntu-network-manager.png
<pitti> tseliot: hasattr(self, '_locations') is a way to check if your object is a dbus.service.Object instance (at least the best I could fine)
<pitti> tseliot: s/fine/find/)
<sbeattie> If I unclick "auto eth0" it just automatically requests a new dhcp address.
<tseliot> pitti: ok, it makes sense now
<LaserJock> sbeattie: if you right click on NM do you get "Edit Connections"
<pitti> tseliot: JFYI, it's not exactly like C's ? :
<sbeattie> LaserJock: ah, for some reason when I right-clicked before I didn't get anything, but there it is.
<pitti> tseliot: "TRUE : 0 : 1" is 0 in C, but "True and 0 or 1" is 1 in Python
<pitti> tseliot: (due to the way 'and' and shortcut evaluation work in Python)
<pitti> tseliot: but for everything that isn't regarded as False, i. e. 0, None, [], {}, and set(), the and/or construct works
<pitti> tseliot: I don't use it often, but sometimes in my tired hours I get lazy :)
<pitti> bbl, doing install testing
<tseliot> pitti: aah, thanks for the explanation
<pitti> tseliot: so the short rule is "and/or works as long as the "true-case" value is not False
<tseliot> pitti: ok
 * tseliot > dinner. bbl
<mdz> something is causing all of my Places to be opened in totem-xine rather than nautilus
<mdz> can someone give me a pointer as to where to look for the problem?
<Treenaks> mdz: the mime database?
<Treenaks> (and the new xine package vs the old one)
<ted2> mdz: See what the command "gnome-open" does with the directories.
<mdz> ted2: it does the right thing
<mdz> MimeType=x-content/video-dvd;x-content/video-vcd;x-content/video-svcd;
<mdz> seems correct enough
<ted2> mdz: That's really odd.  Places in the panel?
<mdz> ted2: yes
<mdz> ted2: the Bookmarks menu in nautilus does the right thing
<ted2> Makes me want to just blame the panel then, if all those work.
<mdz> happens both with the stock bookmarks like Pictures, as well as those I've added
<mdz> I don't know why the panel should have a different idea of how to handle file types
<mdz> or where its settings would be if it did
<ted2> The problem is that you've got a lot working :)
<ted2> I don't see any settings for that either.  How odd.
<ted2> totem-xine is the new konquerer.  :)
<mdz> aha, I found it
<mdz> /home/mdz/.local/share/applications/mimeapps.list:inode/directory=totem-xine.desktop;nautilus-folder-handler.desktop;
<mdz> I wonder where that came from
<mdz> I must have done 'Open with...' to launch totem-xine on a DVD folder
<mdz> I wonder why it didn't affect gnome-open or nautilus
<ted2> They both must have hard coded directory.
<kirkland> mdz: ping, regarding the degraded RAID y/n prompt
<seb128> mdz: nautilus doesn't look at this to open directory, it just open those
<seb128> mdz: gnome-open is still using gnome-vfs and doesn't look at mimeapps.list which is a new gio thing
<superm1> pitti, i identified what's happening re the fstab
<superm1> pitti, it looks like it gets created properly, but when the filesystem copy begins, it gets overwritten by the one thats in the squashfs
<jpds> pitti: In your buildd.py, are MOTU/core-dev capable of using the "rescore" operation, or is that just for buildd admins?
<pitti> re
<pitti> jpds: that's just for buildd-admins, I believe
<jpds> pitti: OK, thanks.
<pitti> superm1: oh, bugger
<superm1> pitti, i think i've gvot an idea of a quick hack that might get around it
<superm1> pitti, not necessarily the way that evan and colin will want to put in the end, but that should suffice for a4 to get out the door
<pitti> superm1: in ubiquity, or in livecd-buildfs? (removing fstab, perhaps)
<superm1> pitti, in ubiquity
<superm1> pitti, although removing fstab in livecd-buildfs would probably solve it too
<pitti> superm1: a hack in ubiquity could be tested right on the live CD, so that's a bit safer
<pitti> superm1: what's the plan, like stash it into /etc/fstab.real, and move it over after squashfs copying?
<superm1> pitti, okay give me a sec and verify that it works on this end (i'm doing an install here).  i'll post a diff momentarily
<pitti> superm1: you rock
<pitti> superm1: I just compared the squashfses in hardy and intrepid
<pitti> hardy has a default fstab, too
<superm1> pitti, some extra magic was added recently in ubiquity that does a file by file unlinking if files exist though
<superm1> pitti, which i believe is what's triggering this
<superm1> pitti, http://paste.ubuntu.com/37224/ appears to resolve it for me.  if you want to go the ubiquity route, i'll add that to ubiquity bzr and get an upload ready for it
<pitti> superm1: ah, I see how http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/2753 has caused that
<pitti> superm1: maybe we should just revert that commit for now?
<superm1> pitti, well i believe that commit is correct, this is just an odd exception because its the only file written to etc prior to the squashfs copy
<pitti> superm1: right, that would have been my next question
<pitti> 'do we create any other files in /target before copying'
<superm1> pitti, since partman has to run so early, i think this is the only one that it happens with.
<pitti> ok, there are a couple of files matching "fstab" in my system, but none prefixed with etc/ (except for /etc/fstab)
<pitti> superm1: so I believe your hack should work
<pitti> superm1: so, let's use that for a4
<pitti> superm1: did you already run a full install test with this applied? or shall I?
<tkamppeter> pitti, I need your help.
<pitti> superm1: how should we go on, do you have time to prepare the branch and test the fix? and I'll do the uploading/beating throuhgh publisher/CD rebuild/test afterwards? I need 30 minutes for getting some food
<pitti> tkamppeter: what's up? I'm about to leave for half an hour
<superm1> pitti, i just ran through an install and it did work
<pitti> superm1: rocking
<tkamppeter> pitti, can you send an e-mail to heno telling him that I sent him several e-mails and did not get any answer from him. Perhaps some spam filter does not let my e-mail come to him.
<superm1> pitti, i can add it to the branch right now if you can upload from the branch after i add it
<pitti> superm1: sure, will do
<pitti> checking out in the meantime
<pitti> tkamppeter: he's on holiday
<Keybuk> Why are kernel developers so afraid of patches?
<pitti> Keybuk: as in "not a git commit but a flat file", or as in "accept changes from other people"?
<Keybuk> accept changes
<Keybuk> I strongly object to having udev rules like this:
<Keybuk>   KERNEL=="hw_random", NAME="hwrng"
<Keybuk> especially in the default, hard-coded, non-modifiable udev rules
<Keybuk> that says the kernel calls it one thing, but everybody calls it something else
<pitti> you mean, then the kernel could just name it hwrng right away? agreed
<Keybuk> (including the LANANA Device Names list)
<Keybuk> exactly
<Keybuk> a *one line* patch to the kernel fixes that
<alex-weej> fight the power
<Keybuk> I also object to having rules like this:
<alex-weej> doesn't ubuntu maintain its own git repo of the kernel anyway?
<Keybuk>   KERNEL=="mice", NAME="input/mice"
<Keybuk> the kernel could just include DEVNAME=input/mice in the uevent
<tkamppeter> pitti, until when? I asked here a lot and no one could tell me this.
<pitti> superm1: what do I need to do to turn this into a source package?
<superm1> pitti, me to push one more commit, and then debuild -S -sa should do it
<superm1> pitti, you might need to run debian/rules update-local too though
<superm1> or debian/rules update
<superm1> it's been a while since i made a fresh tree to see
<pitti> superm1: if you have a ready-made checkout, maybe you can build the source pacakge, too, put it somewhere, and I just sign it?
<tkamppeter> pitti, it is about https://blueprints.edge.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format why I want to talk with heno.
<pitti> superm1: AFAIK it needs to fetch/include some packages fromd-i?
<superm1> pitti, yeah that's what the debian/rules update stuff does
<pitti> tkamppeter: according to the holiday calendar he should be back next Monday
<pitti> superm1: local checkout still running, remote checkout in developer chroot might screw it up, I dunno
<pitti> superm1: ah, debian/rules update looks good
<pitti> it fetches them from teh archive
<pitti> superm1: ok, nevermind, I think I got it right
<pitti> superm1: debdiffing my created source against 1.9.8 is sane
<pitti> superm1: so I just wait for your second commit
<pitti> superm1: that's just UNRELEASED -> intrepid and tag?
<superm1> pitti, doing it right now, i was looking up the last part to do
<superm1> modifying configure* and then debian/changelog and then its good to go
<superm1> pitti, okay if you pull revno 2767, that should be good to go
<pitti> got it
<pitti> superm1: uploaded
<pitti> superm1: thanks muchly!
<superm1> pitti, great.  no problem :)
<pitti> now I head out for a bit and let it build and publish
<tkamppeter> pitti, you can access a holiday calendar? Can I do so, too?
<pitti> tkamppeter: I don't think so, no; sorry
#ubuntu-devel 2008-08-14
<johanbr> asac: Unfortunately I've been really busy and will be busy for the next few weeks, so I haven't had time to look at vpnc not working. Not sure if you have had time to take a look...
<asac> johanbr: thats ok. i think there is a real issue. ill test myself as soon as possible
<pwnguin> did anyone else get quasi mailbombed at their ubuntu.com address?
<Adri2000> any archive admin could please move the amsn sru to -updates? (at least the hardy one)
<pwnguin> so it wasn't me!
<shaya> is intrepid suffering from whats in here?
<shaya> http://pavelmachek.livejournal.com/60867.html?view=123331#t123331
<shaya> 2.6.26.1 bug?
<shaya> my T42p fan has been going crazy lately
<Hobbsee> ask in #ubuntu+1, where the users of intrepid usually hide?
<Hobbsee> (although some developers are running intrepid)
<TheMuso> Is anybody else able to boot the latest ubuntu amd64 intrepid daily in kvm under hardy?
<NCommander> TheMuso, I'm running the latest ubuntu amd64 intrepid on real metal if that helps
<TheMuso> NCommander: No, it doesn't. I am also doing so on another box.
 * NCommander plays with dak
<moquist> if I have multiple binary packages building from a single source package, should the package name prefix in templates be the source package name, or the binary package name(s)?
<RAOF> moquist: You mean foo.install, foo.preinst, etc?
<moquist> i.e., src pkg moodle builds moodle-mysql and moodle-postgresql. should templates have only moodle/... entires, or moodle-mysql/..., moodle/..., and moodle-postgresql/... ?
<RAOF> moquist: They should be binary package names.
<RAOF> I'm not sure what you mean by "templates" in this setting.
<moquist> RAOF: OK, so Template: <binpkg>/<question>
<RAOF> This is debconf, right?  I've approximately no experience there :)
<moquist> RAOF: http://rafb.net/p/wSgfUZ27.html
<moquist> line 62 should maybe read: Template: moodle-mysql/dba_password
<moquist> RAOF: yes, debconf
<RAOF> I'm not sure, but my *guess* is that you'd actually need it to be in a different templates file; one for the moodle-mysql binary package, one for the moodle-postgresql binary package, etc.
<RAOF> That's a guess based on the behaviour of other tools; I'm not familiar with debconf.
<james_w> hey moquist
<james_w> I think binary package name is correct
<james_w> if there are any that apply to both then you can do shared entries
<RAOF> So, I've got a question in return: how does one switch the CPU and IO schedulers at runtime?  I'd like to see if different schedulers have better than the abysmal interactive performance I'm currently seeing under IO load.
<james_w> RAOF: there's a sysfs key
<RAOF> james_w: I suspected as much.  Any details of the top of your head?
<james_w> just searching now
<james_w>  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor looks pretty good
<james_w> for the CPU at least
<RAOF> That's going to be the CPUFreq governor, not the scheduler
<RAOF> IE: when should I throttle the CPU back.
<james_w> oh, yeah, sorry
<james_w> find /sys -name "*sched*"
<james_w> that lists a couple of things
<james_w> perhaps block device schedulers can be changed, but not others
<RAOF> Yeah, possibly.
<moquist> james_w: hi! and thx
<moquist> that was my guess, too
<moquist> just one templates file, even though I have moodle.config and moodle-mysql.config, right?
<moquist> (it builds, so I'm guessing that's right)
<james_w> I'm not sure, I can't remember how it works
<moquist> well, I'll test soon. :)
<james_w> if you have moodle.templates then try installing -mysql, it will soon fail if you need two
<james_w> I'm glad to see you're still fighting away at this
<moquist> me too...I'm not sure of the timing here, but I still have hopes of getting this into debian in time for it to get pulled into intrepid
<moquist> james_w: if you have a moment, I'd appreciate your thoughts on http://revu.ubuntuwire.com/details.py?package=vpnywhere
<james_w> Debian is frozen which may be a hiccup
<james_w> but there is still time
<james_w> moquist: is this related?
<moquist> james_w: only in that it's a package I made. we discussed this one a couple times at UDS. *shrug*
<james_w> that's fine
<james_w> I'll take a look tomorrow. It's late and I've been drinking, not helpful for review.
<moquist> james_w: heh - cheers, then. :)
<warren> Is chvt located at /usr/bin/chvt on Ubuntu?
<james_w> warren: yep, apparently
<warren> k
<cathyal> is the indian language hindi possible on irssi?
<cathyal> or say on x-chat
<cathyal> any indians in the room
<cathyal> anyone good with translations
<ScottK> cathyal: This is an English channel.  You might try #ubuntu-in
<cathyal> thanks
<bryce> heya james_w
<james_w> hey bryce
<james_w> bryce: did you see Federico's patches?
<bryce> james_w, couple bzr questions for you if you have a moment?
<james_w> sure
<bryce> could you come to #inkscape?
<bryce> actually nevermind, I'll ask here and just copy answers...
<james_w> I can do that
<bryce> last time we looked at switching to bzr for Inkscape, the two issues that stopped us were a) Windows UI, and b) EOL handling
<bryce> james_w: do you know if the status on either of these has changed drastically in the last few months?
<james_w> for a) Mark Hammond (big pywin32 dude) has been contracted to make TortoiseBzr rock, and work is starting to progress on that
<james_w> there's also bzr-gtk and bzr-qt, which are improving a lot, especially the latter I believe, which is apparently more windows for some reason
<james_w> for b) there is work ongoing, 1.6 out this week will kind of be able to do it, but you would probably want 1.7, out next month to have it work well
<bryce> thanks for the answers james.  probably when those changes hit, Jon Cruz will take an interest
<james_w> cool
<james_w> bryce: do you have an opinion on Federico's patches?
<bryce> I peeked at the screenshot and it looks like nice eye candy
<bryce> we're not to FF yet, so I think we could definitely pull the patch in
<bryce> it's up to seb128 though.  he might prefer waiting until the patch is upstream
<james_w> yeah, it's up to seb128
<james_w> I was going to reply to ask about theming
<james_w> I don't know how it picks the colours, but the one in the screen shot wouldn't sit well in Ubuntu
<bryce> I'd gotten a suggestion from mirco on how to pick colors from the current theme
<bryce> I can find it and forward it if you're interested
<james_w> that would be good
<james_w> it's something we want anyway, but may help with this
<dholbach> good morning
<pitti> Good morning
<StevenK> Morning pitti
<dholbach> hi pitti
<pitti> dholbach: btw, no sponsor bugs for me in the next two weeks, please (I'll be on holiday the next two weeks, and wrestle with alpha-4 this week)
<nxvl> nooooooooo
<nxvl> what are we going to do without pitti for 2 weeks!
<nxvl>  /o\
<nxvl> :D
<dholbach> pitti: OK
 * dholbach hugs super-pitti
 * nxvl HUGS pitti too
<dholbach> pitti: what do we do in cases where we sync a new package from debian and it ftbfs, but we have a patch for the ftbfs already?
<dholbach> sync, then upload the fix?
<dholbach> get the fix to debian, then sync?
<StevenK> Does it FTBFS in Debian too?
<dholbach> bug 256821
<ubottu> Launchpad bug 256821 in ubuntu "Please sync glusterfs 1.3.10-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/256821
<dholbach> seems it doesn't
<StevenK> What's the patch?
<dholbach> it's in the bug
<StevenK> Ah, I know why that is
<pitti> dholbach: Keybuk told me that it is cleaner to sync and then apply the patch
<StevenK> dholbach: I suspect that is libc6 2.8 fall out
<dholbach> pitti: OK, I'll ack then sync then
<nxvl> dholbach: that's an ubuntu only issue due the compiler flags IIRC
<pitti> dholbach: that is, for MoM, otherwise it doesn't matter at all
 * pitti hugs back nxvl and dholbach
<StevenK> I suspect Debian will hit the same issue when they hit libc6 2.8
<pitti> I forwarded a couple of "glibc 2.8 ftbfs" patches to Debian, they were all gladly accepted
<nxvl> dholbach: https://wiki.ubuntu.com/CompilerFlags
<nxvl> dholbach: under -D_FORTIFY_SOURCE=2
<StevenK> nxvl: Given the error, I doubt it's because of compiler flags
<nxvl> StevenK: that error is listed on that wiki
<nxvl> but i haven't check it closer
<nxvl> pitti: can you please confirm me about the versioning of this package, i find it odd
<nxvl> pitti: http://revu.ubuntuwire.com/details.py?package=mythstream-parser-google
<StevenK> nxvl: So, fix the error. libc likes it when you call functions correctly.
<nxvl> i have patched it before
 * nxvl looks
<pitti> nxvl: indeed it is
<pitti> nxvl: two ubuntus in the version number sounds wrong; the uploaded should make up his mind whether it's a native or upstream project
<nxvl> pitti: thank you, can i quote you on revu?
<pitti> sure
<nxvl> :D
<nxvl> StevenK: taking a closer look to the patch in that bug report is exactly what it says on the wiki
<nxvl> dholbach: i hardly thing it is an ubuntu only bug
<dholbach> nxvl: I asked Neil to forward the patch
<nxvl> s/hardly/really/
<nxvl> dholbach: i would test it in debian before sending it, or ask the DM to include it for downstream compatibilty
<nxvl> because they won't find it as a bug
<nxvl> found it
<dholbach> nxvl: <StevenK> I suspect Debian will hit the same issue when they hit libc6 2.8
<nxvl> mysql-gui-tools_5.0 has the same problem
<nxvl> and fixed
<nxvl> dholbach: yeah, maybe it is a libc issue
 * nxvl checks in experimental
<kirkland> pitti: how are the alpha4 cd's coming along?
<pitti> kirkland: nobody tested the new desktop CDs in the last 7 hours, doing that now; but I hope they'll work now
<pitti> kirkland: by and large they should be okay now
<kirkland> pitti: cool, i'll do some server testing in the morning
<pitti> kirkland: servers look pretty good, 9/10 tests done
<kirkland> pitti: oh, zul must have kicked some butt then :-)
<kirkland> pitti: when does the archive re-open?  when can i get a fix for mdadm sponsored?
<pitti> see http://iso.qa.ubuntu.com/qatracker/build/all
<kirkland> yup
<pitti> we urgently need kubuntu testing, and ubuntu desktop
<kirkland> pitti: okay, i'll see what I can do tomorrow ;-)  i'm calling it a night
<nxvl> StevenK: it builded without problems on sid (libc6 2.7-13) and in experimental (libc6 2.8+20080809-1) so it may be a compiler flag issue
<nxvl> just tested
<nxvl> pitti: that reminds me, how are the complierflags, libtool, libc changes managed? thay take place only at the start of the development cycle or at any time?
<superm1> pitti, i know i was seeing some gvfsd trash related crash after install on the desktop disks
<superm1> i wasn't at a location that i could submit a crash report when i was seeing it though
<pitti> superm1: yep, plenty of reports about that one
<pitti> nxvl: pretty much at the start usually
<superm1> pitti, ah okay then i wont worry about reproducing it again
<pitti> nxvl: since they are very prone to break a lot
<pitti> superm1: right
<nxvl> pitti: yes, that why i was thinking about it, since if they change we will need to rebuild a big part of the archive to check for breakages
<pitti> nxvl: that is, in Ubuntu we generally limit it to the start of a cycle; in Debian, changes happen during cyles, too, since they are much longer
<nxvl> :D
<nxvl> pitti: thank you for clarification
<pitti> superm1: ubuntu desktop CD, ubiquity works fine now; thanks again
<superm1> pitti, no problem.  glad it was easy to identify :)
 * mneptok douses pitti in chocolate and kerosene
<StevenK> Chocolate *and* kerosene?
<StevenK> I've heard about dark chocolate, but that's a little much. :-P
<lifeless> only after you burn it
<pitti> mneptok: owch
<mneptok> pitti: it's just that i think of you as hot and sweet. or something like that. :P
<Treenaks> mneptok: are you part of the Pitti Fanboy team on launchpad yet then? :)
<torkel> mneptok: CrÃ¨me pitti? :-)
<mneptok> Treenaks: i refuse to join any club that would have me as a member. i have some prinicples.
<Treenaks> mneptok: maybe you'll be rejected, I'm not the team admin
<pitti> re
 * pitti drops a metric ton of gummybears onto mneptok
 * mneptok gleefully frees himself
<mneptok> NOM NOM NOM
<liw> "NOM NOM NOM"?
<Treenaks> liw: http://www.urbandictionary.com/define.php?term=nom
<liw> thanks
 * lukehasnoname is away: sleep
<ion_> lukehasnoname: Thanks a lot for the information! We were just wondering about that.
<ion_> liw: The equivalent of "nam" in Finnish. :-)
<ion_> Hm, perhaps not exactly.
<seb128> pitti: arg, it did it again, bug #257803
<ubottu> Launchpad bug 257803 in gedit "gedit crashed with SIGSEGV in g_type_check_instance()" [Undecided,New] https://launchpad.net/bugs/257803
<seb128> pitti: the retracer removed everything including the debug stacktrace
<mdz> pitti: bug 195749 doesn't include a DistroRelease field...is that because we need to add it to the kernel hook?
<ubottu> Launchpad bug 195749 in openjdk-6 "java hangs then crash in libc6/kernel" [Undecided,Incomplete] https://launchpad.net/bugs/195749
<pitti> seb128: hm, if it does that often, maybe stop it for now?
<pitti> mdz: that was reported with the aaaaancient kernel hook (which we never really used in our kernel pacakge)
<pitti> indeed that one didn't add OS info, like DistroRelease
<mdz> pitti: ah, ok
<mdz> pitti: that was the first apport-kernel bug I have seen, didn't notice how old it was
<seb128> pitti: it just does when retracing again a bug
<seb128> pitti: I did retag this one because the retracer didn't have the new gedit version yet
<tseliot> pitti: I managed to write something which should work with the way you implemented the progress bar in Jockey. I had to subclass apt.Cache. Now I have only a question on progress_cb(phase, current, total): phase is either 'download' or 'install' but what are "current" and "total"? Is current the current percentage of work and total 100% or do you have something different in mind?
<pitti> tseliot: the only requirement is that current eventually reaches total
<pitti> tseliot: could be number of pacakges, or percent, or whatever you need
<pitti> total == 1.0, and current = 0.37, or total = 1000 and current = 372
<pitti> or total == 5 (packages) and current == 2 (second package)
<tseliot> pitti: great, I'll use the percentage
<tseliot> pitti: oh, another thing, is it ok if I make the apt part run on a different thread?
<pitti> tseliot: sure, if that helps
<tseliot> pitti: yes, that's what I used in my implementation
<pitti> seb128: it's done in apport/crashdb_impl/launchpad.py, close_duplicate(); nowhere else; so I think the duplicate detection is on crack and tries to mark the bug as a dup of itself
<seb128> pitti: maybe it needs a "if dup_number == bug_number" case?
<pitti> seb128: I think a simple "if id == master: return" at the top of that function should be a good enough patch for the retracers until I'm back from vacation; please report a bug agout it
<pitti> seb128: 'zactly :-P
<seb128> pitti: ok thanks
<pitti> seb128: if you do that in the chroots, the next apport package update will overwrite it, but then we should have a better solution anyway
<seb128> pitti: ok, I'll do the change
<seb128> thanks!
 * seb128 hugs pitti
<slytherin> Can anyone please tell me if anyone is working on packaging elisa 0.5.5?
<pitti> lool: ^
<lool> Hey; I'm not currently, but philn might have prepared something in pkg-gstreamer svn
<lool> At least 0.5.4 is ready there
<lool> And 0.5.5 should be easy to get
<lool> slytherin: ^
<seb128> lool: do you know if somebody from the mobile team will do the cheese 2.23 update?
<lool> seb128: Gary said he was interested, but this was a while ago
<lool> seb128: I'm basically the sponsor here; we had hildon bits to push in earlier cheese, but this now all upstream and merged and all
<seb128> lool: right, I let the updates on the side because I don't use cheese and you guys do it usually but we had none of the 2.23 update
<lool> I don't even have a webcam, so I'm quite a bad tester for cheese  ;)
<seb128> right, me neither
<seb128> anybody interested to update cheese?
<lool> seb128: If you like, drop tremolux an email and ask him for a status update?
<seb128> lool: ok, I'll do that, thanks
<lool> seb128: I'm happy to do the reviewing and sponsoring of his work or of somebody's else; it just doesn't make sense for me to do it as I don't have a webcam to test!
<seb128> right
<slytherin> seb128: I can test cheese on intrepid. I will see if I can update it to but that will be after Monday.
<seb128> slytherin: ok, thanks
<slytherin> lool: Thanks for elisa info. I hope I will find it in repositories before FF. :-)
<ogra> seb128, !!!
<ogra> Unable to retrieve message
<ogra> Cannot create folder lock on /home/ogra/.evolution/mail/local/Inbox: Too many open files
<ogra> my evo misbehaves
<seb128> hey ogra! nice to see you back, how are you?
<ogra> fine, thanks :)
<seb128> ogra: close and restart it?
<seb128> it seems to leak file descriptors in some cases
<ogra> i wasnt actually bad apart from the 15 mins .... they only kept me locked in for a week to do tests
<ogra> lets see, closing now
<ogra> ah, yeah, better now
<seb128> cool, there is a bug about the issue already so no need to open one
<ogra> seb128, beyond that it seems to have gotten slower over the last week ...
<seb128> since the 2.23.6 update you mean?
<ogra> after the initial upgrade from hardy to intrepid it took about 1-2sec switching folders
<seb128> that's the first version using sqlite for summary storage
<ogra> now that can take up to 5-10
<seb128> there is still some optimization work needed
<seb128> they are working on it a lot, wait for tarball next week to see if things are better
<ogra> yeah, i just noticed it seems to have degraded since the first upgrade
<seb128> the new code was not really optimized for some cases
<seb128> I had evo freeze for some seconds when using my bugmails box for example, which was due to the hidden messages handling
<ogra> (i'm not complaining, just giving feedback :) )
<seb128> I hide everything which is read there, they fixed the bug in svn
<seb128> but there is likely some other non optimized cases
<seb128> they are working on it and really responsive to issue reported so file a bug if you still get the issue in the new version
<ogra> yeah, i have no hidden msgs ... but lots of folders wih big amounts of mails
<tseliot> pitti: I get this error now: http://pastebin.com/m4371b4c0 . If I run my program outside of Jockey it works well. Maybe is it because of what you do in dbus_sync_call_signal_wrapper() (in backend). I wouldn't know. Any ideas? It's all in my branch: ~albertomilone/jockey/ubuntu-core-xkit
<ogra> seb128, right, i'll wait for the next tarball, lets see :)
<pitti> tseliot: what do you try to do?
<pitti> tseliot: do you call a function which takes very long to execute?
<tseliot> pitti: I only clicked on a new driver, typed in the password for policykit and then that error shows up
<tseliot> pitti: I use python-apt to install the package
<pitti> tseliot: maybe d-bus is not thread-safe enough to do that, I don't know :(
<tseliot> pitti: if you have a look at install_package in oslib you will see what I'm doing
<pitti> tseliot: sorry, no time right now
<tseliot> pitti: ok, no problem. I'll see if I can find something with Google about the error
<seb128> tseliot: you are not subscribed to the nvidia-graphics-drivers-177 bugs?
<seb128> tseliot: there is quite come crasher for nvidia users in intrepid for some days when using compiz, I've reassigned bugs there
<tseliot> seb128: yes, I'm subscribed. I've been very busy though. What's the number of the bugreport?
<seb128> tseliot: are you sure you are subscribed? you are not listed on bugs
<tseliot> seb128:  I see it in my "bugs" folder in my mail client. I'm part of the X team
<seb128> ah ok
<seb128> tseliot: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bugs, all the crashes in _nv*
<tseliot> seb128: ok, let me have a look at those reports
<seb128> tseliot: they don't seem really useful, I just wanted to let you know that quite some nvidia users seem to have compiz crashing in intrepid
<tseliot> seb128: thanks for bringing this to my attention
<seb128> you're welcome ;-)
<tseliot> seb128: BTW do you have a look at my 3 lines patch here? http://bugzilla.gnome.org/show_bug.cgi?id=546969
<ubottu> Gnome bug 546969 in Screen resolution "The GUI components do not always reflect the current situation" [Normal,Unconfirmed]
<seb128> tseliot: GNOME will roll new tarballs next week, I'll try to get the patch reviewed before that
<tseliot> seb128: thanks a lot ;)
<seb128> thank you for working on the bug ;-)
<didrocks> hi all ;)
<didrocks> pitti: when you will have the time, I'm interesting to know how NBS are calculated.
<didrocks> Indeed, it seems to not look at package dependencies as some times, we have 3 dependecies for one source package. ldd on the binary seems to not put the same result...
<MaximLevitsky> The desktop effects currently doesn't respect ccsm settings, will this be fixed/
<MaximLevitsky> ?
<MaximLevitsky> I meant if I select advanced/basic there the custom settings are cleared
<MaximLevitsky> I would like to use this dialog to switch between compiz and metacity, but without alerting the settings
<persia> didrocks: NBS is based on declared binary package dependencies.  This may not match the current source package (if successful builds have yet to publish (common in cases where the build fails)), and may not match ldd or similar tools depending on both the correctness of the analysis of those tools and the declared dependencies.
<mneptok> persia: konban-wa
<persia> ããã°ãã¯
<mneptok> persia: the convincing argument. "you can lose weight just by blinking in the summer."
<didrocks> persia: thanks a lot and that guide me through my second (big) technical questions: how ${shlibs:Depends} are calculated regarding build dependencie, it assumes runtime ones? :)
<persia> didrocks: man dh_shlibdeps for an overview, and read /usr/bin/dh_shlibdeps for the details.
<didrocks> ok, I will give it a look ;)
<Adri2000> any archive admin could please move the amsn sru to -updates? (at least the hardy one)
<sistpoty|work> didrocks: if you're looking for insight, https://wiki.ubuntu.com/MOTU/School/LibraryPackaging might be helpful (but it's quite a read)
<didrocks> sistpoty|work: thanks for the link, I will add it to my reading schedule :)
<MaximLevitsky> I have one quesion, is the 'NEEDED' section needed :-)
<MaximLevitsky> without it linker won't find the symbols?
<sistpoty|work> MaximLevitsky: well, you could do without, if the shared object defines all the symbols itself I guess, but I wouldn't know a use case for this right now
<MaximLevitsky> sistpoty|work: I don't understand you (I once did a deep research on linking, but forgot most of it now)
<MaximLevitsky> I mean if a library needs a symbol from external library, does it have to add that library as NEEDED ?
<sistpoty|work> MaximLevitsky: yes
<MaximLevitsky> sistpoty|work:  this is great
<MaximLevitsky> sistpoty|work: I remember that I once tried to understand how to write a depends.exe equivalent for linux
 * sistpoty|work wouldn't know what a depends.exe is in the first place *g*
<MaximLevitsky> Long long time ago (about 8 years from now I used and programmed in windows_
<MaximLevitsky> depends.exe shows you what libraries(dlls) are needed for this application, and for each dll, it shows list of symbols
<MaximLevitsky> that app use, and list  of symbols that dll exports
<sistpoty|work> so a mixture of ldd and objdump, right?
<MaximLevitsky> http://www.dependencywalker.com/
<MaximLevitsky> more or less, but it gets the information directly from .exe, and .dll
<MaximLevitsky> linking is a bit different there
<MaximLevitsky> each app has a list of dlls that it needs
<MaximLevitsky> and for each dll there is a list of symbols it needs
<MaximLevitsky> here in ELF there is just a list of all symbols
<MaximLevitsky> so to know from where the symbol come, one needs to know what libraries the app needs
<MaximLevitsky> I was thinking that ld.so just searches all libraries on the system for any symbol
<MaximLevitsky> using cache to speed this up
<sistpoty|work> erm, no. library resolution is done exactly with the NEEDED entries
<MaximLevitsky> sistpoty|work: this is just great
<MaximLevitsky> sistpoty|work:  although if I were to write such program, I will probably need to parse outputs of objdump and ldd, right?
<MaximLevitsky> elf probably has platform specific differencies
<sistpoty|work> MaximLevitsky: sorry, am not 100% sure about ELF internals, but I guess I'd use objdump (or readelf) as a base
<MaximLevitsky> Btw ldd is just a frontend to ld.so
<MaximLevitsky> just a script that exports some env variable, and then runs the program, and this makes ld.so output the depedencies, and exit
<MaximLevitsky> this is what I remember from that old study
<MaximLevitsky> sistpoty|work:  another interesting this is that global data variables in a library are reverse exported
<MaximLevitsky> app exports the variable to the library
<MaximLevitsky> sistpoty|work: thanks for information
<MaximLevitsky> Btw, why all devel packages install .a libraries?
<MaximLevitsky> who uses static linking those days?
<MaximLevitsky> As I understand to write code against a library you need .h files and .so normal library, thats all
<ogra> Keybuk, if i run telinit 6 (or shutdown -r -now) and get "Unable to send message: Connection refused", do you have a hint for me for what i should look to make that functional ?
<ogra> (that shows up recently in my classmate installer out of the blue)
<Keybuk> ogra: not running init?
<ogra> right, i run a script that fires up the cmpcinstaller
<ogra> but it used to work in the last builds
<ogra> (about a week ago)
<ulaas> anyone interested on  an initramfs issue with hardy? or #ubuntu is the way?
<Keybuk> if you're not running Upstart, you obviously can't do things like change the runlevel?
<ogra> was there any change in hardy-updates within the last week ?
<ogra> i dont need to ... i used to just run "reboot -fp" which should just trgger the kernel
<Keybuk> no, no change
<Keybuk> if you do reboot -f, you are just telling the kernel
<ogra> but thats getting stuck ... so i looked at shutdown ...
<Keybuk> if it's getting stuck, that's a kernel bug
<ogra> ah, k so it must be a kernel issue
<Keybuk> telinit and shutdown won't work, and I would be surprised if _they_ worked last week ;)
 * ogra waits for smb then 
<ogra> who apparently built the new classmate kernel for colin last week
<ogra> Keybuk, thanks that was the missing info :)
<ogra> no, i never used or tried telinit or shutdown ... i just didnt understand why they exposed the msg
<ogra> but its logical since i ont use upstart or normal init
<pitti> jpds: yay, great to see buildd.py getting so many improvements :)
<seb128> pitti: oh? where?
<pitti> seb128: ubuntu-dev-tools 0.39ubuntu1
<seb128> ah good
<pitti> one thing less to maintain personally in my ~/bin :)
 * pitti kills the one on people.u.c.
 * pitti sobs at the obviously broken listadmin
<lool> And I was looking at launchpad web pages to see buildd status, sigh
<pitti> lool: buildd.py does that as well
<lool> I think I'll hack buildd to unset https_proxy though
<lool> pitti: Yeah, that's what I discovered!
<pitti> I also have yet another wrapper giveback which calls buildd.py repeatedly with a set of packages
<lool> pitti: That I was stupidly browsing web pages instead of typing a command line!
<pitti> but that's trivial
<pitti> lool: wiki.ubuntu.com/Specs/GettingRidOfTheDesktop
<lool> pitti: EPAGE
<Hobbsee> broken listadmin?  :(
<pitti> just shows "nothing in queue" for all lists
<Hobbsee> ah, yes.
<pitti> which made me first think "wow, thanks elmo for installing a great spam filter"
<Hobbsee> hahahaha
<Hobbsee> yes, that's what i thought, too
<pitti> but when I actually looked at the web page, they are full with requests
<Keybuk> who's Chris Coulson?
<james_w> Keybuk: he's a bug triager, quite active currently
<Keybuk> does he IRC?
<Hobbsee> Keybuk: as ChrisCoulson
<Hobbsee> apparently
<X-Seti> I may have a bug for you guys, this is ubuntu 8.04, and 8.10 with 1Gig of ram installed, Swap is being heavy used, alot of HD activity. ?
<X-Seti> I know this isnt the support channel, but whats been changed since 7.10?
<liw> "almost everything" is a good guess
<ion_> You installed and started the memory-hungry piece of software.
<X-Seti> is there a way to reduce HD load, running a server like this, im ganna go through some HDÅ
<X-Seti> I know the beauty of ubuntu, but ive never seen it be so HD heavy
<X-Seti> ok, im going to debug a tool i think might be the problem and postbin you the outs..
<liw> X-Seti, use the top command (on the command line) or gnome-system-monitor or some other tool to see what is using the memory; before you know that, any changes you make are pure guesswork
<ion_> Hit > once in top and it sorts by memory usage.
<X-Seti> interesting.
<liw> "RSS" is the relevant column, I think
<X-Seti> trying to compare something, i have 2 machines with 8.10 and 8.04
<X-Seti> i think the problem is network manager
<ion_> How much resident memory has it allocated?
<pitti> seb128: ugh; apt-get install from relatively small (retracer) chroots: 12.1 MB pidgin vs. 31.6 MB telepathy
<pitti> (packed .debs)
<seb128> pitti: be careful, pidgin is a GTK application where telepathy uses the GNOME stack
<seb128> pitti: you should try to apt-install it on a livecd rather
<pitti> right, it pulls in libcamel, e-d-s and a lot of stuff we already have
<pitti> seb128: I guess in the end we just have to change the seeds, build a CD, and look what comes out of it
<pitti> seb128: did you stop the amd64 retracer on purpose after the chroot upgrade?
<ulaas> pitti: where should i go for my boot problem with hardy kernels..
<ulaas> i use an md array for root
<pitti> ulaas: which problem?
<ulaas> pitti: upgraded from dapper to hardy with do-release-upgrade. now initramfs prompt comes at boot with new kernels. my old dapper kernel boots fine. I have my / on raid1 md
<seb128> pitti: oh, no, I switched to the i386 one while it was doing the upgrade and forgot to reconnect to the screen and restart it
<ulaas> pitti: any recommendations?
<pitti> meeting
<pitti> ulaas: I'd check the root parameter in grub, and which devices are present in the initramfs shell (/dev/...)
<pitti> ulaas: I don't know how well you know linux, like "/dev/" -- at which level should we guide you?
<pitti> seb128: restarted
<pitti> ulaas: it could be that the newly built initramfs somehow missed the lvm and mdadm packages, or the root device changed
<seb128> pitti: danke
<ulaas> i have built the initrd  a few times manually as well. i have tried to comment out uuid entries in fstab and replace with /dev substitutes. i may be able to check if initramfs loads the correct modules but i think it does. you can guide me hardcore :)
<ion_> tkamppeter: Hm, so there must be a change to /usr/share/ppd/openprinting/HP/hp_LaserJet_2300.ppd.gz in order to get the PDF filter path to work for my printer? Is that something that could be done automatically?
<ulaas> i am just near the my server! and can try anytink you ask right away..
<ulaas> pitti: as more info i ve tried -16 and -19 both generic and server
<tkamppeter> ion_, for now all CUPS Raster drivers and all foomatic-rip-based drivers run through PDF, at least when the input datra
<tkamppeter> data is PDF or an image.
<pitti> ulaas: ah, UUIDs are good, please keep them
<pitti> ulaas: are they present in /dev/disks/by-uuid/ in the initramfs prompt?
<ulaas> pitti: i am rebooting now...
<tkamppeter> Today I will upload an updated foomatic-db to make also all RICOH PPDs use the PDF workflow.
<tkamppeter> ion_, native PostScript printer PPDs do not do a PDF workflow as they have no cupsFilter line. Try to force the PDF workflow by:
<ion_> tkamppeter: Yeah, this is a postscript printer.
<tkamppeter> 1. Add "application/vnd.cups-pdf application/vnd.cups-postscript 0 pdftops" to /etc/cups/mime.convs
<ion_> tkamppeter: Could the cups package itself do that?
<tkamppeter> 2. Remove the executable bit from "pstops"
<tkamppeter> 3. Restart the CUPS daemon
<ion_> tkamppeter: Because if it could, i could prepare a patch.
<tkamppeter> Then report whther printing still works for you, especially whether you can supply options to the jobs and the options are correctly executed by the printer.
<tkamppeter> Try also to priont from OOo with options.
<ion_> Ok, iâll do that.
<tkamppeter> ion_, patches welcome
<ulaas> pitti: booted into initramfs. i can see that the by-uuids are there. but may be different from the ones than fstab? should i make sure?
<Keybuk>  15:06:28 up 136 days,  5:02,  1 user,  load average: 10.29, 4.75, 2.52
<Keybuk> eep
<pitti> ulaas: are you using only RAID, or LVM etc. as well?
<pitti> ulaas: does it have a particular error message? cannot "find" or "mount" the root fs, etc.?
<ulaas> only raid. and i get Alert! cannot find /dev/root error. there is no /dev/root  instead i have /dev/rootmirror/root and also swap
<ulaas> oh wait i have /dev/root
<pitti> ulaas: what is the root= parameter in grub?
<ulaas> pitti : good question i have lilo
<pitti> ulaas: lilo.conf has the parameters, too
<ulaas> pitti: will boot into old kernel and let you know. but before what do you thÅnk about the uuids. if they are different in fstab and by-uuid folder, does it effect?
<pitti> ulaas: yes, definitively
<pitti> they need to be identical to the letter in order to find the partition
<ulaas> pitti: cool. will check that first
<ogra> pitti, did my initramfs-tools and casper changes from yesterday make it on the CDs ?
<ogra> (or was there some kind of freeze in place i missed)
<pitti> ogra: the alternates are from Tuesday, so not there
<pitti> the desktops got rebuilt due to the ubiquity bug, so it should be there
<ogra> casper :)
<pitti> check the .list/.manifest files :)
<ogra> good
<ogra> i need some testing of that stuff and promised colin to have it in alpha4
<ogra> bah
<ogra> casper 1.138 :(
<ogra> one version to old
<pitti> sorry, I wasn't aware that you needed to squeeze something on alpha4
<ogra> i was late only pushed it in last night
<ogra> the builds are from yesterday afternoon
<ogra> well, thats hw it goes :/
<ogra> *how
<ogra> colin wanted ot have support for live on 256M back in place but i guess that then has to wait for alpha5
<ogra> the code is at least there now
<ulaas> pitti: uuids are ok. i have checked lilo.conf and root=/dev/mapper/rootmirror-root. worth a try for /dev/rootmirror/root ?
<pitti> ulaas: hm, /dev/rootmirror/root doesn't sound standard at all
<pitti> ulaas: ideally it should just be root=UUID=DEADBEEF
<ogra> pitti, in case you run nto any showstopper and rebuild, please please ping me so i know the stuff went in
<ulaas> pitti: if you are positive that lilo is ok with uuids i can punch it in..
<pitti> ogra: don't think so, sorry; I'm about to release, all images are tested
<ogra> oki
<pitti> ulaas: lilo shouldn't care
<pitti> ulaas: it's just a parameter passed to the kernel
<pitti> ulaas: lilo only cares about your /boot/ partition
<pitti> which you have to set in, erm, lilo is been a while...
<pitti> ulaas: right, root = /dev/whateveryourrootpartitionis in lilo.conf
<ulaas> pitti: i am always ok with grub if it suports md boot partitions. does it?
<ulaas> ok i will try root=/dev/rootmirror/root
<pitti> ulaas: sorry, that was BS, don't believe me
<pitti> ulaas: the /boot partition is figured out by lilo automatically, taken from the image= parameter
<pitti> ulaas: so boot=UUID=12345 should work
<pitti> ulaas: I don't think grub can have /boot on RAID; ICBW, but don't rely on it
<ulaas> pitti: deal! I ll let you know.
<pitti> ulaas: argh
<pitti> ulaas: not boot=UUID, but root=UUID, of course
<pitti> ulaas: sorry, doing too much other stuff
<ulaas> pitti: dont worry. i got it
<pitti> ulaas: you should be able to change that on the lilo prompt, shuoldn't it? then you don't need to re-lilo all the time
<ulaas> pitti: i believe it depends if you set that up.? what was that? "prompt" in lilo.conf?
<pitti> yeah
<tseliot> pitti: I did it!!! We have nice progress bar now in Jockey!
 * pitti dances around
<pitti> tseliot: yay!
<tseliot> pitti: I have yet to try the KDE progress bar though. The mechanism works.
<tseliot> pitti: gobject.threads_init() and glib.init_threads() are required for threading, that was the problem
<pitti> tseliot: I wouldn't have known that either
<tseliot> pitti: let's thank Google then ;)
<ulaas> pitti: done! uuid is good. Should i file a bug? if yes for which component?
 * tseliot tries jockey-kde
<pitti> Keybuk: which package rewrote devices to UUIDs on upgrade again? udev?
<pitti> ulaas: we might not have an automigration for lilo, I'm not sure; I think Keybuk needs to take over here
<pitti> ulaas: but glad to hear that it worked
<ulaas> pitti: hmm not yet! :) Ä± have appended from lilo prompt. when it is in lilo.conf it is a syntax error. can it be with quoets? ("")
<ulaas> lets google
<pitti> ulaas: according to man lilo.conf, you can use key = "value"
<Keybuk> pitti: I think it's in udev or vol_id
<ulaas> Ä± am a genius :) so as you are :)
<ulaas> Keybuk: i think you watched the conversation.
* pitti changed the topic of #ubuntu-devel to: Alpha-4 released! | archive: open | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ulaas> Keybuk: do you need somethink from me? this may be an important one. from LTS to LTS may be a common upgrade
<Keybuk> ulaas: err?
<Keybuk> assume that I did not watch a conversation
<tseliot> pitti: the funny thing is that now Jockey installs the driver only if I start the backend with sudo...
<pitti> tseliot: as opposed to getting it autolaunched from d-bus?
<tseliot> pitti: however the progress bar works for kde too
<tseliot> pitti: yes
<BenC> Can someone please tell gnome-terminal to stop crashing when I try to select text with the mouse
<pitti> tseliot: try changing the .service file to use --logfile=/tmp/jockey-backend.log
<pitti> tseliot: last time it was due to d-bus not setting any $PATH
<pitti> tseliot: or other environment variable
<dholbach> BenC: I filed the bug yesterday - seems it's fixed in vte upstream already
<pitti> tseliot: oh, and --debug, of course
<ulaas> Keybuk: ok.! i have upgraded my dapper to hardy. which is on a raid1 MD array. then i goot initramfs prompt with hardy kernels when booting. old dapper kernel boots fine.
<pitti> tseliot: then you get a nice log even from autospawned daemon
 * pitti phews and is glad that alpha-4 is out
<Keybuk> ulaas: no idea without extensive debugging, I'm afraid
<BenC> dholbach: ah, thanks, saves me the time of filing a bug...any chance you have a deb of the fixed version?
<ulaas> Keybuk: after a research with pitti he found out that root=UUID=dhjdhdh is better than what dapper had.
<ulaas> Keybuk: in lilo.conf
<pitti> Keybuk: do we do lilo.conf automigration to uuids?
<Keybuk> no
<pitti> Keybuk: or just in grub's menu.list?
<pitti> ok, that explains it then
<dholbach> BenC: no, I'm sorry - I leave that to mvo and seb128 :)
<Keybuk> if we do, it'll be in lilo's postinst
<Keybuk> we may skip raid, lvm, etc.
<seb128> mvo: ^ can you do the vte update?
<Keybuk> since we didn't deal with those in dapper
<Keybuk> and we may have forgotten lilo since
<ulaas> Keybuk: so people wÄ±th MD roots may have the same problem right?
<mvo> seb128: yes
<seb128> thanks
<mvo> dholbach: what is the bugnumber?
<Keybuk> ulaas: only if they use lilo
<dholbach> mvo: need to check
<seb128> mvo: http://download.gnome.org/sources/vte/0.17/vte-0.17.2.tar.gz
<ulaas> Keybuk:  i see! if you are not interested with details i gotta go.. do you?
<pedro_> mvo: bug 256769
<ubottu> Launchpad bug 256769 in vte "gnome-terminal crashed with SIGSEGV in vte_terminal_extend_selection()" [Medium,Fix committed] https://launchpad.net/bugs/256769
<mvo> thanks pedro_
<Keybuk> ulaas: not at the moment, sorry
<Keybuk> others will be interested
<ulaas> Keybuk: no problem i am a registered member at launchpad. Easy to find.
<ulaas> pitti: thanks for the quaility time :)
<seb128> dholbach: could you do the brasero update sponsoring? tomorrow is an holiday and I've still lot to do today, would be nice to have the new version uploaded though
<tseliot> pitti: basically I get the policykit dialog, then the progress bar shows up for a few seconds without progressing and nothing happens. Here's the log: http://pastebin.com/m33310df0
<dholbach> seb128: will do
<seb128> dholbach: danke
<pitti> tseliot: hm, seems you need to add some logging.debug() calls of your own
<tseliot> pitti: ok, I'll do it and see what happens
<seb128> dholbach: could be interesting to use http://svn.gnome.org/viewvc/brasero?view=revision&revision=1084 too in the update if you can, upstream asked to try the change, that can wait for next version too though
<seb128> dholbach: don't bother, they roll tarball often enough
<dholbach> seb128: ok
<asac> pitti: congrats on getting alpha-4 out in time
<pitti> asac: thanks
<pitti> I almost forgot how painful that was :)
<asac> pitti: so the the livecd fix from mario work?
<pitti> asac: yes
<seb128> does anybody else have refresh issues in emacs in intrepid?
 * seb128 hugs pitti
<asac> pitti: cool, rock on.
<seb128> pitti: does that mean we can upload crack again? ;-)
<pitti> seb128: go wild!
<seb128> ;-)
<pitti> seb128: vim is fine *duck*
<asac> yay ... me looking at what NM snapshot might be wild enough ;)
<seb128> pitti: I'm using gedit ;-)
<seb128> asac: do you know about static config not working in nm0.7?
<seb128> asac: the ok button stays inactive
<tseliot> mvo: would it be possible to make apt.Cache.commit() look like this? def commit(self, fetchProgress=None, installProgress=None, optionalObject=None):
<asac> seb128: it has rough edges
<asac> seb128: which button?
<asac> seb128: ah static IP
<asac> (for a moment i thought you meant "system config"
<asac> )
<asac> seb128: wireless?
<seb128> asac: right click on the nm icon, edit connection, choose a static interface, edit, ipv4 settings, set to manual, the button stay unactive
<seb128> asac: no, wired eth
<tseliot> mvo: never mind, ignore my request
<asac> seb128: i think i saw that issue when i was still on that snapshot. but i am long gone on more recent snapshots. its fixed there. upload will probably happen today or tomorrow ( i am trying to flash out final issues in VPN)
<asac> seb128: you could check that in ~network-manager PPA ... or just wait a few more hours
<seb128> asac: ok, so need to open a bug
<asac> seb128: i dont think so.
<seb128> ok cool
<asac> seb128: did you add DNS server as well?
<seb128> I don't need the change, somebody just raised the issue on the chan yesterday
<asac> ah ok
<seb128> asac: I tried to file all the entries, ip, mask, gateway, dns, domain, etc
<seb128> but the button stays unactive
<asac> ok. then thats really the issue i vaguely remember
<seb128> I'll try after the update
<asac> thanks
<dholbach> seb128: done
 * seb128 hugs dholbach
<seb128> thank you
<dholbach> de rien
 * dholbach hugs seb128 back
<soren> Anyone still on hardy and wants to test a kvm fix for me? It's supposed to fix X in Intrepid guests. (not the mouse stuff, though. Just getting X rolling)
<dholbach> soren: me me me me!
<soren> dholbach: Awesome. Kernel version?
<soren> -20, by any chance?
<soren> amd64?
<dholbach> -20 amd64, yes
<soren> Whee.
<soren> dholbach: I'll just compile them especially for you :)
<dholbach> soren: give me the love!
<soren> dholbach: http://people.ubuntu.com/~soren/kvm-test/
<soren> dholbach: sudo bash -c 'rmmod kvm-intel ; rmmod kvm ; insmod ./kvm.ko ; insmod ./kvm-intel.ko'
<soren> (or amd, obviously, if that's what you're on)
<dholbach> just a minute
<soren> Sure.
<tseliot> pitti: problem solved. I had to set os.environ["PATH"] and os.environ["DEBIAN_FRONTEND"] in oslib. Now it works.
<pitti> tseliot: hah, $PATH again
<soren> dholbach: Wow, those modules are big...
<soren> dholbach: Er... I'm sure there's some sort of reasonable explanation for that.
<soren> Ah, they're not stripped.
<pitti> tseliot: did you set DEBIAN_FRONTEND to noninteractive?
<tseliot> pitti: yes
<pitti> tseliot: interesting, which program does python-apt call? I thought it was pure python
<tseliot> pitti: only mvo can answer to this ;)
<pitti> tseliot: or strace -f -e execve :)
<mvo> tseliot: hm? I missed the earlier part
<mvo> aha
<tseliot> mvo: jockey starts a dbus service which should call python apt when requested by the client
<mvo> tseliot: that is a good question, I think that dpkg gets unhappy when it can not find certain apps, so if the path does not include e.g. /sbin it could fail I guess
<pitti> aah, indeed, that was it
<pitti> because in my first version I called /usr/sbin/apt-get, and that just failed with the same error (dpkg wanting $PATH)
<pitti>         env = {
<pitti>             'DEBIAN_FRONTEND': 'noninteractive',
<pitti>             'PATH': '/sbin:/usr/sbin:/bin:/usr/bin'
<tseliot> mvo: ok, this would make sense
<pitti>         }
<pitti> tseliot: ^ is what I have
<pitti> tseliot: I believe that shuold work for python-apt as well
<tseliot> pitti: no, it doesn't
<pitti> oh?
<pitti> tseliot: you need more in $PATH?
<tseliot> pitti: this is why I had to use os.environ
<pitti> tseliot: right, of course
<pitti> tseliot: I meant the variables and their value
<dholbach> soren: so the modules work and everything?
<dholbach> soren: I'm not going to die or something?
<tseliot> pitti: ah, ok then you're right
<pitti> tseliot: I can pass it to subprocess.Popen()'s env argument, with p-apt you can't
<soren> dholbach: No, they should be fine.
<tseliot> pitti: yes, I noticed that. I didn't pay enough attention to this and I ended up assuming that the env dictionary would magically work
<pitti> ah, no
<tseliot> pitti: of course not, I didn't notice that it was a simple dictionary...
<dholbach> soren: now I should be able to boot the intrepid kernel and X starts?
<tseliot> pitti: I'll clean the files a bit and push this commit soon
<soren> dholbach: That's the theory, yes.
<tseliot> mpt: can you give an advise on Jockey's UI, please?
<pitti> tseliot: is x-kit still in http://bazaar.launchpad.net/~albertomilone/xorgparser/main/
<soren> dholbach: You mouse might still be acting up, but X should come up.
<tseliot> pitti: yes, it's there
<dholbach> soren: black screen, let me try without xorg.conf
<soren> Ok, so there's more to it than I thought. The patch I applied there fixes it in Intrepid.
<seb128> ArneGoetje: hi, do you plan to add the hunspell dictionnaries to the language support writting depends for languages where those are available?
<soren> dholbach: I ran the command I sent?
<dholbach> soren: yes, just re-ran everything to make sure the modules weren't loaded before I started, trying again
<ArneGoetje> seb128: yes
<seb128> ArneGoetje: ok good, thanks
<dholbach> soren: no... no love here :-/
<soren> dholbach: Ok. Thanks for testing.
<pitti> tseliot: hm, if I run "PYTHONPATH=. tests/run", I just get failures with No such file or directory: '/home/martin/ubuntu/tmp/xorgparser/xorg.conf'
<seb128> ArneGoetje: that's still missing for the spellchecking spec and feature freeze is soon
 * dholbach hugs soren
<pitti> tseliot: shouldn't this work on a temporary file which is created in setUp() or so?
<tseliot> pitti: you can override the default settings. The default xorg.conf is the file included in the tests directory
<tseliot> pitti: therefore you should enter that directory and run ./run from there
<tseliot> pitti: or you can have a look at the README to see how "run" works
<mvo> BenC: new vte uploaded to fix the crash when selecting text
<tseliot> pitti: why do you call progress_cb with only 2 arguments when you remove packages and 3 when installing them?
<BenC> mvo: thanks!
<seb128> bigon: hi, bug #257189 is because the omf directory is not shipped in any deb
<ubottu> Launchpad bug 257189 in empathy "No ghelp:empathy" [Low,Confirmed] https://launchpad.net/bugs/257189
<pitti> tseliot: aah, thanks
<pitti> tseliot: because there is no 'phase' on uninstall
<pitti> tseliot: README, tsk, noone reads that...
 * pitti hugs tseliot, just kidding
<tseliot> pitti: fine, I just wanted to make sure that it could work
<tseliot> pitti: ;)
<pitti> peopel should totally rename them to SECRET_STUFF_CLASSIFIED.txt
<Keybuk> pitti: I think i might stir up more controversy in the kernel/plumbing community next week
<Keybuk> by suggesting that the kernel just make device nodes in /sys, so all udev has to do is chmod(), chown() and make symlinks in /dev
<tseliot> pitti: or PLEASE_DO_NOT_READ_UNDER_ANY_CIRCUMSTANCE.txt
<pitti> tseliot: PYTHONPATH=. tests/run  -i tests/xorg.conf doesn't work either, though
<tseliot> pitti: what's the error?
<pitti> No such file or directory: '/home/martin/ubuntu/tmp/xorgparser/xorg.conf'
<pitti> tseliot: I'd just like to call the test suite during build of the package
<tseliot> pitti: and is there such file?
<pitti> tseliot: no, it should be xorgparser/tests/xorg.conf
<pitti> tseliot: if I specify -i tests/xorg.conf
<pitti> no?
<tseliot> the answer should be in settings.py
<tseliot> pitti: ^^
<pitti> inputFile = "tests/xorg.conf"
 * pitti recognizes the code structure in tests/run :)
<tseliot> pitti: can you paste this into settings.py? http://pastebin.com/d1fd6d7d
<pitti> tseliot: no difference
<tseliot> pitti: it works here. Did you install the package before running the tests?
<pitti> tseliot: no, I run it with PYTHONPATH=.
<pitti> tseliot: anyway, debian/rules could use
<pitti> (cd tests; PYTHONPATH=.. ./run)
<pitti> that works
<pitti> tseliot: that could look like
<pitti> common-post-build-indep:
<pitti> erm, "::" at the end
<pitti> common-post-build-indep::
<pitti>         (cd tests; PYTHONPATH=.. ./run)
<pitti> provided that ./setup.py clean or debian/rules clean removes the test output and settings.py again
<tseliot> pitti: does it work if you run each test singularly?
<metavoid> pitti, does ubuntu have gnomesu installed by default, or with what *su it goes with?
<tseliot> pitti: BTW I have just pushed an update to my xkit branch of Jockey. I have yet to clean xorg_driver.py and to add the tests though.
<pitti> metavoid: gksu and gksudo
<metavoid> pitti, that's a problem :(
<metavoid> pitti, i'm looking for a common su for several distributions
<pitti> tseliot: btw, do you have the python-apt change in a separate branch?
<pitti> tseliot: I could merge that quickly into trunk, whereas I can't merge/upload the xkit branch so quickly
<pitti> tseliot: (I'm currently reviewing/uploading x-kit, but that needs to get to the archive and main first)
<tseliot> pitti: I can create a new branch for the apt part
<pitti> tseliot: the two are unrelated, right? so it's easier to review if split by feature
<pitti> tseliot: oh, sorry, there's something that slipped past me before: the package name needs to be python-xkit
<pitti> tseliot: Python policy for consistent package names
<pitti> tseliot: shall I create a branch with my changes?
<tseliot> pitti: yes, they don't depend on each ether
<pitti> tseliot: I'll do some minor tweaks to x-kit packaging and upload
<tseliot> pitti: sure, thanks
<tseliot> pitti: ok, I restored the original nvidia.py, fglrx.py and xorg_driver.py. The rest should be ok. It's all in this branch: ~albertomilone/jockey/ubuntu-core-apt
<pitti> sudo dpkg -i ../python-xkit_0.3.4_all.deb
 * pitti whistles
<pitti> tseliot: ok, uploaded, will beat through NEW in a minute; I put my changes into bzr; can you please do "bzr pull lp:~pitti/xorgparser/packaging-fixes"?
<tseliot> heh
<tseliot> pitti: sure
<pitti> tseliot: if you pull, it won't be a merge, but since I used your branch for Vcs-Bzr:, pull will look cleaner
<mpt> tseliot, any specific part of it, or the whole thing?
<pitti> ^ I think that refers to "how to represent the recommended driver"?
<tseliot> mpt: we need to highlight the recommended version of a driver when more than 1 is provided. Have a look at these screen shots: http://albertomilone.com/ubuntu/jockey/jockey-bold.png
<tseliot> http://albertomilone.com/ubuntu/jockey/jockey-underline.png
<tseliot> http://albertomilone.com/ubuntu/jockey/jockey-recommended.png
<tseliot> http://albertomilone.com/ubuntu/jockey/jockey-kde-bold.png
<hwilde> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/244779
<ubottu> Launchpad bug 244779 in gvfs "permission denied when removing a directory via SSH" [Low,Incomplete]
<tseliot> pitti: ok, pulled
<pitti> tseliot: please review bzr log and the diffs, and let me know if anything is unclear to you, or you have objections
<mpt> That intro text is depressingly long
<hwilde> mpt, thats ok nobody reads it :)
<mpt> If it was shorter, more people would read it
<hwilde> you could do one of those lightbulby things for the curious
<mpt> tseliot, what's the difference between "Enabled" and "In use"?
<tseliot> mpt: Enabled means installed and set in the xorg.conf (I guess) while In use means that the module is loaded
<hwilde> you can enable proprietary drivers for something that is not in use, like maybe a removable media
<hwilde> doesn't quite apply to your video card
<superm1> hwilde, really?  i thought that it won't show up on the list unless the hardware is detected
<hwilde> like a wireless card
<hwilde> you can enable atheros or whatever, but it won't be in use if you eject the card
<tseliot> hwilde: you can try it with your toaster too ;)
<pitti> tseliot: that branch has some is_recommended changes, I guess those are leftovers and I can kill them from that merge?
<pitti> +        col1.set_attributes(text_renderer, markup=3)
<pitti> tseliot: ^ what does that do?
<pitti> tseliot: is that for the 'recommended' string?
<mpt> hwilde, so something can switch from "In use" to "Not in use", or vice versa, without a restart?
<tseliot> pitti: no, don't remove them, that's the way we highlight the recommended driver version
<hwilde> mpt,  I think it would switch from "In Use"  to "Enabled"
<pitti> tseliot: hm, when I merge from ubuntu-core-apt, bzr st says it is also merging in x-kit support et al
<pitti> tseliot: support for recommended driver should be merged to trunk, not to ubuntu
<tseliot> pitti: col1.set_attributes(text_renderer, markup=3) says that column 3 should use the markup (e.g. <b></b>)
<mpt> hwilde, but it's already marked as "Enabled"
<pitti> tseliot: I think I'll just cherrypick the last 3 commits and merge the recommended parts to trunk
<pitti> tseliot: oh, I see, the last commit was "remove x-kit stuff" :)
<tseliot> pitti: yes, right ;)
<pitti> tseliot: I guess that branch is pretty damaged, it should just be removed afterwards, but nevermind; I'll figure it out
<tseliot> pitti: ok
<hwilde> mpt,  so what is the difference?
<mpt> hwilde, that's what I'm asking y'all :-)
<pitti> tseliot: and I think I'll wait for mpt's verdict for merging the recommended support
<tseliot> mpt: which one do you suggest that we use? Bold, underline, etc. or what?
<mpt> tseliot, so the mundane answer to your question is, I don't understand what the bold or the underline by itself is supposed to mean
<tseliot> pitti: ok, no problem.
<mpt> I mean, you've told me that it means "Recommended", but I wouldn't have guessed that without you having told me.
<tseliot> mpt: shall we use "[Recommended]" then?
<hwilde> mpt, oh I am not much for semantics.   or guis for that matter.      or proprietary drivers :)
<mpt> That would be better than the other two, yes
<mpt> However, that would still leave me wondering why they were checkboxes and not radio buttons
<mpt> and also why the non-recommended options were offered at all.
<tseliot> mpt: you should ask pitti about the rest of the GUI
<mpt> If I need to make a choice, help me make an informed choice, otherwise don't bother. :-)
<tseliot> mpt: about the non-recommended options there is a reason.
<hwilde> how about a slider bar that goes between "proprietary" and "free" and the users just slide it where they feel comfortable  ;)
<totopalma> hi pitti :) can you take a look at bug #234754 please? :)
<ubottu> Launchpad bug 234754 in rhythmbox "Launcher icon is fuzzy" [Unknown,Confirmed] https://launchpad.net/bugs/234754
<tseliot> mpt: sometimes your cards are supported by one or more versions of the driver. We follow a certain criterion to determine which one you should install, however users might think differently
<pitti> totopalma: sorry, not right now, about to runout
<totopalma> pitti, ok
<pitti> totopalma: please subscribe me and ask the question in the bug
<pitti> tseliot: any chance we could call gobject.threads_init() in oslib.py?
<pitti> tseliot: that would be cleaner, I'll move it there
<mpt> tseliot, ok, what's the criterion?
<pitti> tseliot: hm, will take me a while to merge, I don't like "from foo import *" etc.
<tseliot> mpt: for example if you have 2 cards you might choose to select a driver which makes both of them work even though it's not the latest version which your new card supports. Sometimes you might want to ignore the old card and simply install the latest release of the driver because of its new features and make use of only you newer card
<tseliot> etc.
 * mpt admires his shiny new triple-boot startup menu
<tseliot> pitti: what's the problem with gobject.threads_init()? that should be called before you perform those operations
<pitti> tseliot: right, but not in backend.py, we only need it in the ubuntu branch for python-apt
<pitti> tseliot: i moved it to OSLib.__init__()
<tseliot> pitti: ok, but make sure that it works there ;)
<pitti> tseliot: yep, sure
<pitti> tseliot: do I actually need the TextFetchProgress stuff, or was that just for testing?
<mpt> tseliot, ok, so to be useful I think this list needs to give the benefit and drawback of each of the options
<pitti> tseliot: oh, "myobject", I see
<tseliot> mpt: right. This would make sense only when users have 2 cards plugged in, otherwise the latest version is recommended. What should I say in the latter case?
<mpt> tseliot, why would you want two graphic cards to work at the same time?
<tseliot> pitti: feel free to change the names, I had to pass an object in order to access the percentage from the outside
<ogra> mpt, for two monitors
<mpt> aha
<tseliot> ogra: right
<ogra> if you take two multihead cards even for four monitors .. though i doubt you find that wide mousepads :P
<pitti> tseliot: this fails the test suite, I'll track it down
<mpt> so for example, "Lets both your displays work, but does not allow Suspend."
<moquist_> ogra: nearly done (again) with moodle 1.9.1
<mpt> I guess there are all sorts of complicated reasons why you can't present a message like that
<ogra> moquist_, yay
<tseliot> mpt: if users have a problem with the recommended driver version, they will try another version. This is how it works (usually)
<tseliot> mpt: for example maybe the recommended driver has a regression and you install another version, etc.
 * mpt now has blue/black streaks all across his display :-/
<mpt> tseliot, so what's the procedure for trying them? Do you need to restart between each one?
<tseliot> mpt: yes, a restart is required (for common users...)
<Treenaks> Am I the only one who keeps clicking "Remove from panel" instead of "Empty trash" ?
<pitti> tseliot: hm, I don't understand why this needs a separate thread - the outer thread just sleeps anyway?
<tseliot> pitti: don't you need to run the while loop after you start the installation so that you can pass the "percent" with the progress_cb function?
<tseliot> until the process is complete
<pitti> tseliot: right, but wouldn't it be easier to pass the callback down to the FetchProgress/Installprogress objects, and their pulse/updateStatus methods call that directly?
<pitti> tseliot: ok, let me play around with this
<mpt> tseliot, so if at all possible, I suggest presenting a human-readable explanation of what the selected driver does, in a second pane underneath the first. Otherwise I don't think jockey will be useful to nearly as many people as it could be.
<tseliot> pitti: aah, calling that function directly from there. You would only have to pass that function instead of the object then
<mpt> Since it's presenting options without giving people the info they need to decide.
<pitti> tseliot: right, passing the callback down instead of the status up
<Adri2000> pitti: could you please move the the hardy amsn sru to -updates? (bug #243722)
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,Fix committed] https://launchpad.net/bugs/243722
<tseliot> pitti: yes, that would be possible
<pitti> tseliot: ok, playing more
<tseliot> mpt: ok, I'll think about it. Thanks for your help
<pitti> Adri2000: hardy and feisty are verified AFAICS, leaving gutsy and dapper
<mpt> tseliot, no problem, thanks for asking :-)
<Adri2000> pitti: feisty has one "works for me" (+ mine of course), is that enough?
<pitti> Adri2000: for me it is
<Adri2000> ok
<pitti> ok, I'm off for today
 * tseliot > dinner
<tkamppeter> pitti, hi
<tkamppeter> pitti, I have uploaded a new CUPS to SVN, this time with texttopdf
<tkamppeter> can you upload it to Derbian and Ubuntu. Thanks.
<ogra> tkamppeter, he just said goodnight ... it is probably better if you mail him to make sure he gets the request
<tkamppeter> ogra, the "pitti has quit" did not appear, he always closes hios client when he leaves.
<jpds> pitti: 'Tis a very nifty script indeed :)
<kirkland> bryce: ping
<bryce> heya kirkland
<kirkland> bryce: hey, thought i'd run something X11-ish by you....
<kirkland> bryce: Bug #257825, with patch
<ubottu> Launchpad bug 257825 in xorg "pair xorg.conf with particular hardware" [Wishlist,New] https://launchpad.net/bugs/257825
<BenC> pitti, mdz: Updated my findings on bug 255635
<ubottu> Launchpad bug 255635 in sysklogd "No messages in /proc/kmsg" [High,Triaged] https://launchpad.net/bugs/255635
<BenC> pitti, mdz: In short, it's not a kernel bug
<Kopfgeldjaeger> Does ufw output the iptable commands it uses anywhere?
<bryce> kirkland: mm, I think there may be a better solution than xorg.conf for this
<kirkland> bryce: i figured as much.... i'm all ears
<kirkland> bryce: basically, i want to be able to move my hard drive back and forth among multiple (ok, 2 for now) similar-but-not-the-same laptops, and have X just work (tm)
<bryce> kirkland: yeah
<bryce> kirkland: I think the right direction to go for this use case is the "no xorg.conf"
<kirkland> bryce: and i recognize this is perhaps a little hackish, especially with xorg.conf going away and all
<jcristau> kirkland: that already works, just not with nvidia?
<BenC> bryce: btw, the gem patch doesn't apply to 2.6.26 or 2.6.27...missing some other updates in drm subsystem...any idea what those updates are?
<kirkland> jcristau: then it doesn't work for me (or any of the other nvidia users out there)
<BenC> bryce: I'm guessing it's something in -mm, but I hate to guess on this
<bryce> BenC: no I don't, hmm
<bryce> BenC: want me to put you in touch with keithp?  I bet he's the one to go to about this.
<BenC> bryce: yeah, please
<bryce> kirkland: -nv or -nvidia ?
<kirkland> bryce: well, i'm still having better experience (resolution, 3d) with -nvidia, unfortunately
<kirkland> bryce: i try -nv once a week or so, just to check, though ;-)
<bryce> ok, so when you go xorg.conf-less, it comes up as -nv?
<jcristau> nv won't get better anytime soon
<bryce> agreed
<jcristau> seeing how it's maintained by the same people as nvidia, and they want you to use the blob
<kirkland> bryce: not sure....  gimme a minute to save all of my buffers and I'll restart X
<batsquid> the guided setup of ubuntu server 8.04 lts is great, but there's one place i always need help. partition disks. could more help be provided on each option here? Guided - use entire disk and set up LVM (Logical Volume Manager i presume, but i can't figure out if i want to do that). I have a 40GB disk and i want to use 1.5xRAM (768MB) for swap - or so i have been recommended. this screen is somewhat confusing
<emgent> hello people
<batsquid> or is swap taken care of under the hood by 8.04 ?
<bryce> BenC: email away
<warren> hey, did do you folks have any URL's with flash confirmed to cause Flash 10 to crash?
<warren> i'm trying to nail down a reproducer
<warren> I found one on sourceforge.net, but I need to reload until a random flash ad appears before it crashes.
<warren> so it isn't easy to reproduce there
<ogra> warren, asac might know if he's still around at that time of day
<bryce> kirkland: ok anyway in general (not considering proprietary vs. open) for such a case is to just make the xserver aware that it needs to use thus and such driver for thus and such hardware
<ion_> pitti: I already mentioned this to tkamppeter, but hereâs a diff for cups (against current svn) consisting of a couple of bugfixes, http://heh.fi/tmp/cups.debdiff
<bryce> kirkland: I suspect the issue is that if it boots with -nv and "basically" work, there's not really a strong enough reason to force it to default to -nvidia for every user of that hardware
<kirkland> bryce: okay, i'm booted xorg.conf-less
<BenC> bryce: thanks
<kirkland> bryce: the resolution is right, but the color depth isn't
<bryce> but I agree with jcristau that waiting for nv to get better is a watching-the-paint-dry exercise
<kirkland> bryce: how can I tell for sure what driver I'm using?  lsmod shows the nvidia driver loaded, but X isn't necessarily using that, right?
<bryce> look in /var/log/Xorg.0.log
<kirkland> bryce:         "Builtin Default nv Screen 0" for depth/fbbpp 24/32
<bryce> grep LoadModule should do it
<mtrudel> asac: I think I found a bug, presumably in network-manager-vpnc, in the version from the network-manager team PPA on Launchpad... the standard report a bug tool in Launchpad doesn't seem to me like the best of ways to report it, because I guess it would end up with the "normal" versions of NM in ubuntu? is there a better way to report what I've found?
<kirkland> bryce: (II) LoadModule: "nv", but it also loaded "vesa"
<kirkland> bryce: the rough color gradients make it look more like vesa
<asac> mtrudel: what is your problem?
<bryce> I think that's normal for xorg.conf-less boot
<asac> mtrudel: the vpnc plugin is known to still have issues with the authentication dialog. if you see that: i am working on getting a fix out as soon as possible
<mtrudel> ah, i see
<bryce> ok yep so loading "nv" by default as I thought
<asac> mtrudel: yes. most likely thats your issue
<mtrudel> that's precisely the problem I was having... looking a little bit at how to fix that, but given that I'm at work, the time I can put to this is limited :)
<kirkland> bryce: so perhaps maintain a list of hardware that prefers the nvidia module?
<kirkland> bryce: how can I force it to use nvidia?
<bryce> kirkland: we've got such a thing already, although I don't remember if it's set up for nvidia
<bryce> look in /usr/share/xserver-xorg/pci/
<asac> mtrudel: if you want to contribute to network-manager, feel free to jump in ... there are other things you could do - after your work :-P
<kirkland> bryce: k, i see nv.ids, but no nvidia.ids
<mtrudel> asac: already did some time ago, one patch even got in universe :)
<bryce> I think we need to talk with tseliot, as he was working on hooking in envy/jockey and the proprietary drivers to use either the same or an analogous setup
<asac> mtrudel: good.
<bryce> so possibly there's already a solution in place we can reuse
<kirkland> bryce: excellent, please point me the way
<kirkland> bryce: i'm happy to seed that nvidia database with my card info :-)
<mtrudel> i'm already pretty sure i've found something, but I'm struggling a bit with the patches
<bryce> kirkland: of course that also leaves the question of if we should prefer proprietary drivers in all cases where it works better, or only in cases where the hardware works no other way
<bryce> I suspect for Ubuntu the principle is the latter not the former
<kirkland> bryce: IMHO, when it works "better" ....
<kirkland> bryce: yes, for Ubuntu, I agree
<kirkland> bryce: it's both sad and frustrating to pay for hardware, and not be able to use it, when there is a way to do so
<bryce> yeah no kidding
<bryce> hmm
<kirkland> bryce: that question could be discussed, i suppose, on ubuntu-devel@, in case others have opinions
<bryce> kirkland: probably a good idea
<kirkland> bryce: but I hope we're in the majority ;-)
<bryce> kirkland: now, turning to your patch, I don't dislike it in principle.  It might be a good way to go.
<kirkland> bryce: it's a neat, opt-in hack
<bryce> the downsides are, that it's really solving a pretty specific use case (just -nvidia would need it I think)
<kirkland> bryce: as soon as you have your xorg.conf set up the way you want, you "sign" it with "/etc/init.d/x11-common hwsign"
<bryce> however, I could see it get expanded to cover other kinds of wonky hardware or stuff not well supported by X's normal hotplug stuff
<kirkland> bryce: and subsequent boots will always load that xorg.conf into place
<bryce> of course it could be argued that such cases should be handled by fixing the hotplug, not via a workaround.
<bryce> but it's a pretty clean workaround as far as workarounds go
<kirkland> bryce: true, the idea behind it could also solve some silly minor issues to do with me changing the networking hardware, etc. from underneath the installed OS
<kirkland> bryce: fortunately, i have the same eth/ath drivers in both laptops...  but in one machine, they're eth0/ath0, and in the other, they're eth1/ath1 :-)
<bryce> there's also a potential downside in that it could confuse users - like if they signed their xorg.conf, then used some other tool that updated their xorg.conf, then rebooted it restores the original signed one
<bryce> so I think if we go forward with it, we need to ensure it gets integrated or made compatible with X-kit, to detect and prevent such a situation
<kirkland> bryce: okay, i'm not familiar with X-kit....
<bryce> in fact maybe we should think a bit more generically about alternate xorg.conf's, such as backup versions
<kirkland> bryce: true...  I have 20+ xorg.conf's in my /etc/X11 :-P
<bryce> X-kit is a new python xorg.conf parser library tseliot is putting together, that we'll be using with envyng and other tools
<bryce> I wonder if we could stick them all in bzr ;-)
<bryce> anyway, could you post an email summarizing the situation to ubuntu-x@?
<kirkland> bryce: um, different that the description in the bug?
<bryce> the description is fine I think
<kirkland> bryce: okay, I'll write a one or two liner, and point to the bug
<bryce> maybe include our discussion above
<kirkland> bryce: sure, i'll summarize that
<bryce> cool.  and make sure to mention the need for making this work with envyng/jockey, since it involves -nvidia
<kirkland> bryce: right, it sounds like it's mostly a matter of insufficient support for nvidia kit
<bryce> x-kit is uploaded to universe if you want to check it out
<bryce> yep
<kirkland> bryce: will do
<bryce> I'll comment a bit on the bug too
<kirkland> okay.  i'm going to maintain an x11-common package with this patch in my ppa until we settle on something
<bryce> great
<cody-somerville> Is cjwatson on vacation or something?
<cody-somerville> Wait a tick, I can answer that question myself
<bryce> cody-somerville, yep
<bryce> cody-somerville, evand and slangasek are gone as well
<cody-somerville> All the people I wanted to talk to :/
<cody-somerville> They must have done this to me on purpose.
 * cody-somerville grumbles.
<superm1> bryce, how long they all gone for, you know?
<tseliot> kirkland: what happens when you change your graphics card? A new xorg.conf is generated?
<kirkland> tseliot: please clarify that question....
<bryce> superm1: cjwatson is gone for the week.  the others are at debconf iirc so will be back after that.
<kirkland> tseliot: what do you mean?
<tseliot> kirkland: let's assume that you have an xorg.conf and a geforce 7300. You sign the xorg.conf. Then you buy a new NVIDIA card. What would happen at this point?
<tseliot> kirkland: if what I write doesn't make any sense to you it might be because I'm quite tired ;)
<kirkland> tseliot: ;-) .....
<kirkland> tseliot: you boot your machine and it attempts to run with the old xorg.conf ... maybe it works, maybe it doesn't...  in any case, my suggested code hasn't taken any action yet
<kirkland> tseliot: either it "just works", or you hack around until you get to the point at which it "works"
<kirkland> tseliot: then you would consciously make the decision to "sign" this xorg.conf with hash of your current hw VGA configuration reported by lspci
<kirkland> tseliot: by running "/etc/init.d/x11-common hwsign"
<kirkland> tseliot: that copies the current xorg.conf, which you're "certifying", to a new xorg.conf appended with a md5sum of your hw configuration
<kirkland> tseliot: on subsequent boots, if a change in hardware (lspci | grep VGA) is detected....
<kirkland> tseliot: x11-common will look for a "signed" xorg.conf matching the md5sum
<kirkland> tseliot: and if found, that one is used
<kirkland> tseliot: otherwise, no additional action is taken
<kirkland> tseliot: so to answer your question, really, it's just the conscious step of "certifying" your working xorg.conf by running the "hwsign" init script action
<kirkland> tseliot: perhaps that could be more automatic with this x-kit thing?
<tseliot> kirkland: aah, I understand now. It's more or less what I suggested here: http://ubuntuforums.org/showpost.php?p=1368826&postcount=10
<tseliot> kirkland: of course your solution is a lot saner
<tseliot> kirkland: it depends on what you would like to do with X-Kit
<kirkland> tseliot: Yup :-)
<kirkland> tseliot: hashing it gives uglier filenames, but a virtually infinite space for avoiding collisions
<joaopinto> gnome-terminal is crashing when selecting a section is of text, is anyone aware of a record for this bug ?
<tseliot> kirkland: this trick wouldn't work if you wanted to switch between fglrx and nvidia and vice versa
<kirkland> tseliot: because of the gl libraries?
<jcristau> tseliot: or between fglrx or nvidia and anything else, really
<tseliot> kirkland: yes
<tseliot> jcristau: heh
<jcristau> what?
<kirkland> tseliot: well, i think it's better than nothing.  you lose 3d capability, but still get premium resolution and bit depth, i think
<tseliot> kirkland: yes, right. And signing the xorg.conf would be something which should be (deliberately) done by the user, therefore I don't see any problem with this approach
<tseliot> jcristau: never mind
<kirkland> tseliot: good, i'm in agreement with that point
<kirkland> tseliot: bryce had some good thoughts about better management of multiple xorg.conf's
<kirkland> tseliot: and extending this approach to other changing hw (wacom tablets, etc.)
<bryce> kewl, thought he would :-)
<tseliot> kirkland: yes, I read what bryce wrote before (in this chat session)
<kirkland> tseliot: ah, good
<tseliot> kirkland, bryce: if you need a hand, I'll be glad to help
<mkrufky> is anybody here going to the Linux Plumbers conference?
<kirkland> mkrufky: i've heard rtg talk about going
<mkrufky> cool
<superm1> tseliot, kirkland you know we could always register an alternatives system for libGL
<superm1> it would make for less ugly diversion magic
<mkrufky> im trying to justify why my boss should pay for me to attend
<kirkland> superm1: that's what I suggested!
<superm1> kirkland, haha, i just stepped in and saw the tail end of the convo
<kirkland> superm1: sorry, that was a couple of days ago
<superm1> kirkland, unfortunately at least in the fglrx case, there are more diverted libraries too
<superm1> libdri i believe is the main one
<superm1> i would understand resistance to registering libGL with the alternatives system though
<bryce> tseliot, kirkland: regarding the situation of plugging in new hardware, booting and failing, well we could also consider integrating the failsafe-x to be aware of this xorg.conf-alternates system, so it would popup a screen offering the option of trying any previously saved xorg.conf's in the system
<kirkland> superm1: Aug 08 02:43:22 *       kirkland wonders if it would be possible to make those libs update-alternatives savvy....
<bryce> tseliot, kirkland: as well as an option to regenerate a stock xorg.conf, and/or running with no xorg.conf.  And one day maybe something fancier ala displayconfig-gtk
<kirkland> superm1: Aug 08 02:43:42 <tjaalton>      uh no please, dpkg-divert is enough of a nightmare :)
<tjaalton> we could just apply the patch to prefer "nvidia" if it's installed
<tseliot> bryce: I really like this idea.
<tjaalton> and similar one for fgrlx
<tjaalton> -lrx
<superm1> tjaalton, you mean to prefer the nvidia or fglrx libGL's via a different name if installed?
<tseliot> tjaalton: a lot of people would complain about Aaron Plattner's patch
<tjaalton> superm1: no, let the xserver pick nvidia if it's installed
<tjaalton> tseliot: who would?
<tseliot> tjaalton: I wouldn't
<tjaalton> upstream said that it's a distro thing
<kirkland> bryce: sure, and you could sort those xorg.conf's by reversed-date (most recently used)
<superm1> that particular patch was just for choosing the modules if available and prevents the necessity of xorg.conf modifications in the first place, right?
<tjaalton> btw, is x-kit hal-aware? does it edit fdi-files for input drivers?
<tseliot> tjaalton: no, I haven't worked on that yet. Any links to how fdi files work?
<tjaalton> superm1: right, it would pick the blob even if you didn't have xorg.conf
<tjaalton> tseliot: hal documentation
<tseliot> tjaalton: I meant, Any links on how...
<tjaalton> tseliot: hehe, no :)
<bryce> tseliot: see http://wiki.ubuntu.com/X/Config
<tseliot> tjaalton: ok, I'll have a look at it
<bryce> I put some explanations of fdi files and examples there
<superm1> tjaalton, yeah if there is no opposition at the distro level, i think a patch like that would be welcomed for users
<tjaalton> superm1: that would also make a part of jockey/xkit obsolete
<superm1> tjaalton, indeed
<tseliot> bryce, tjaalton: so that's a simple xml file. It would be trivial to manipulate
<tjaalton> tbh I haven't looked at x-kit at all yet :)
<superm1> tjaalton, would a similar patch be possible to also check if you are loading fglrx/nvidia to use a different libGL so that no diversions or alternatives were necessary (maybe install it somewhere else instead)?
<tseliot> bryce, tjaalton: I can write a module for X-Kit to deal with fdi files
<tjaalton> superm1: I'm not sure..
<tjaalton> tseliot: cool
<bryce> tseliot: excellent
<jcristau> superm1: no matter how much you patch X you're not going to change where ld.so looks for libGL.so.1
<superm1> jcristau, yeah that's what i was thinking
<superm1> tjaalton, why do you think alternatives would be more complex than diversions?  It would at least allow you to have multiple things installed simultaneously.  eg if you wanted to try multiple different nvidia driver versions, or possibly switch back and forth between open and closed source without making package installation changes
<psyke83> hi, I packaged the latest flashplugin-nonfree release. This latest release has new dependencies (libcurl3, libnss3-1d and others) and works fine for 32bit users, but not 64bit, as it needs the 32bit version of these libraries. Do I really need to update the ia32-libs package with these new dependencies or can they be packaged separately (like lib32asound2)?
<tjaalton> superm1: maybe it could work.. it would be a surprise if no-one had thought about it before :)
<superm1> tjaalton, well at least it would prevent each driver from having to know about every other possible driver
<superm1> tjaalton, eg if there is an nvidia -180 release, don't have to update conflicts/replaces on the other 4
<tjaalton> superm1: hmm right
<tjaalton> superm1: you are welcome to demonstrate it in action ;)
<superm1> tjaalton, well lets see, when's feature freeze.
<tjaalton> handling diversions is ugly, it can't be worse :)
<tjaalton> two weeks from now?
<superm1> i'll see if i have time to mess with it on one of my -nvidia machines before then
<superm1> if not, then we can plan to try for ubuntu+1
<tseliot> superm1: let me know how it goes
<tseliot> superm1: if it goes... ;)
<tjaalton> by then we'll have 3D support for r6xx and nouveau released and... :)
<tjaalton> I'll get me coat ->
<superm1> tseliot, i'll have a handful of patches if it goes well :)  the worry with it though about generating packages for earlier ubuntu releases
<superm1> at least for the -fglrx case. i'll see though
<psyke83> superm1, the only practical problem with your idea is that the "nvidia-all" package would become quite bloated to hold the new/legacy/legacy-old packages, or else it could dynamically grab the upstream tarball like flashplugin-nonfree :)
<superm1> psyke83, nvidia-all package?  i didn't realize that such a package existed
<superm1> they are their own source packages now
<psyke83> superm1, well, I thought that if all the binaries were in the same package, it would cause bloat... but perhaps I misunderstood your idea about using the update-alternatives, sorry ;)
<slangasek> bryce: evand is on vacation, not at DebConf; I've just arrived home from DebConf today, it'll be at least a few hours before I'm fully spun up again though
<slangasek> cody-somerville: if you have a question, asking it may improve your place in the queue ;)
<cody-somerville> slangasek, https://pastebin.canonical.com/8177/
<bryce> slangasek: ah ok
<slangasek> cody-somerville: hmm; what's the question? :)
<cody-somerville> slangasek, would that sort of report between daily builds be useful for the distro team?
<cody-somerville> or just useful somehow
<mathiaz> kirkland: I've put up my comments for your update-motd package on REVU
<kirkland> mathiaz: awesome, thanks!
<LaserJock> who takes care of pidgin? desktop team?
<BenC> LaserJock: it certainly isn't the kernel team :)
<LaserJock> phew, good to know ;-)
<LaserJock> wouldn't want to have to deal with those crazies ;-p
<BenC> hehe
<warren> asac: ping
<asac> warren: yes?
<warren> asac: are you interested in joining a theoretical new mailing list to collaboratively discuss nspluginwrapper issues and development?  (I'm pretty fed up with the lack of an upstream list and everyone going through Gwenole, especially when he disappears for weeks at a time.)
<warren> asac: for example, I'm running into issues that are either nspluginwrapper, firefox or Flash 10 bugs.  I currently have nowhere to post my findings where others could possibly help isolate the cause of a problem.
<asac> warren: i sometimes wonder if nspluginwrapper could be be maintained by mozilla upstream
<warren> asac: Adobe is interested in joining
<nenolod> i would prefer for nspluginwrapper to be rewritten
<nenolod> ;p
<asac> warren: but yes. why not
<warren> asac: yes, my thought exactly, although I think creating a community around it is an intermediate step toward that goal.
<asac> warren: if adobe wants to contribute this might make sense
<pwnguin> adobe wants open source to deal with this STL guy they hired
<warren> STL?
<pwnguin> i cant remember his name. russian i think
<pwnguin> standard template library
<nenolod> also, matthew garrett is totally my hero :P
<pwnguin> heh
<pwnguin> well
<pwnguin> im not convinced that the third party didn't make up the logs to continue "teh lolz"
<pwnguin> (i didnt anticipate they'd fold, so I wrote their advertisers instead =/ )
<nenolod> that ryan guy is a total dumbass
<pwnguin> im surprised he knew and could use the bios decoding stuff
<nenolod> i must wonder how he managed to get slashdotted too
<nenolod> pwnguin, well, he didn't understand what he was seeing fully
<pwnguin> he got slashdotted becaus ubuntu forums is a conduit for stupid =(
<pwnguin> and slashdot decided they needed to jump on the stupid bandwagon and emulate digg
<nenolod> because flaming manufacturers is a GREAT way to get them to do what you want
<pwnguin> heh
<pwnguin> seems like it
<nenolod> it's all a HUGE conspiracy
<nenolod> the BIOS author couldn't be incompetent, no way
<nenolod> M$ writes every BIOS ever
<nenolod> i am being sarcastic if you didn't notice ;p
<pwnguin> at any rate, paying any more attention to this is counterproductive
<nenolod> i agree
<nenolod> it's not even funny lolz
<nenolod> it is just dumb
<pwnguin> it stopped being funny lolz a long time ago, and it certainly didnt get funny now that i have to convince CFO.com to unsubscribe me from 20 of their email alerts
<nenolod> you too? :P
 * LaserJock feels left out
<pwnguin> LaserJock: you were smart enough to  not give an email address on that guy's blog
<LaserJock> didn't particularly feel it was worth the effort, now I'm glad I didn't
<ion_> pwnguin: Why not forward those messages to some.appropriate.user@cfo.com instead?
<pwnguin> ion_: what you fail to realize is, that cfo is a drop in the bucket
<pwnguin> ion_: imagine you wrote a web spider, who's only job was to look for email subscription pages
<pwnguin> most of them have confirmation processes
<pwnguin> its easy enough to just ignore these, but a substantial fraction are configured... differently
<pwnguin> my favorites are the ones that set passwords
<pwnguin> to unsubscribe, just enter your email and password
<nenolod> pwnguin, for the record, iptables does well with the rest of them. it seems everyone who demonstrated to him otherwise on any medium where he could easily find e-mail addresses is being targeted :(
<mathiaz> kirkland: the sticky point will be how to handle motd
<mathiaz> kirkland: especially that you copy motd in the postinst
<mathiaz> kirkland: but motd is updated on every boot
<kirkland> mathiaz: by what?
<mathiaz> kirkland: /etc/init.d/bootmish.sh
<ogra> /etc/init.d/bootmisc.sh
<kirkland> mathiaz: i installed /etc/rc.*/update-motd at 90
<kirkland> mathiaz: bootmisc is at 55
<kirkland> ogra: thanks!  and welcome back, btw!!!
<ogra> :)
<mathiaz> kirkland: but you don't copy /var/run/motd to /var/run/motd.head from the init script
<mathiaz> kirkland: you just do that on postinst
<kirkland> mathiaz: right, I'll fix the init script ;-)
<kirkland> mathiaz: hmm, it is sticky, though, i see what you mean
<ion_> tkamppeter, pitti: Patch URLs changed: both are in http://heh.fi/tmp/cups/ now. 01-bugfixes contains bugfixes. 02-pdf implements the PDF filter chain for PostScript printers. Settings such as economy mode and DPI seem to work, even from OOo.
<ion_> tkamppeter, pitti: If you make changes to the svn before youâre ready to add one or both of those patches, feel free to ask me to rebase them to svn HEAD.
#ubuntu-devel 2008-08-15
<slangasek> cody-somerville: from where I sit, I'm not sure how an ongoing report like that would be useful to us; I'm sure it would be useful to look at if and when we're attempting to harmonize the two builds?
 * slangasek ponders the latest Hug Day announcement.  "This week's target is TARGET"?
<ion_> They must be using the $TEMPLATING_ENGINE templating engine.
<slangasek> That %unpleasant verb%
<LaserJock> slangasek: it looked to me like TARGET=casper, perhaps it was a bit hard to see
<slangasek> hum, ok
<LaserJock> if you go to the wiki page it says casper
<LaserJock> I'm guessing that's the correct one and not the previous one
<ScottK> It's a good $TARGET in any case.
<ScottK> ;-)
<superm1> kirkland, ping
<kirkland> superm1: hiya mario, what's up
<superm1> hey dustin.  i wanted to ask you about some recommends on mysql-server-5.0
<superm1> i noticed it has mailx as a recommend which is pulling in exim4
<kirkland> superm1: hmm, interesting, there should be viable alternatives to mailx
<superm1> wouldn't something like that be more sensible as a separate task for a mail server?
<lifeless> exim4 FTW
<kirkland> superm1: i think so...  what does it need it for?
<superm1> kirkland, well moreso that i'm sure not everyone who is installing mysql-server-5.0 will want something to be handling mail getting installed too
<kirkland> superm1: sorry, i'm way more familiar with postgresql in my own installations.....
<superm1> kirkland, well i bring this up because i'm looking at mythbuntu disks which gained about 200 megs by recommends
<kirkland> superm1: yikes, that's no good :-/
<superm1> and i'm trying to see where that space can be reclaimed, and what happened
<superm1> and this is one of them
<kirkland> superm1: i can take a look at it tomorrow, if you like
<superm1> kirkland, yeah if you can, that'd be great
<kirkland> superm1: i'll likely have to chat with zul and mathiaz
<kirkland> superm1: they work on mysql quite a bit too....
<superm1> kirkland, okay sounds good
<kirkland> superm1: would a smaller sql database be an option?
<superm1> kirkland, well there is no support in mythtv for anything but mysql at this point
<superm1> i wish postgresql was supported
<kirkland> superm1: oh, that's too bad...  there are some really trimmed down databases out there
<superm1> or even better if it had support for sqlite internally
<StevenK> superm1: Postgres support for Myth sounds good to me.
<superm1> kirkland, but exim4 & mailx are only contributing about 10 or the 200 meg increase from recommends, so still need to track down what else happened
<kirkland> superm1: how bad is Xubuntu over the limit at the moment?
<superm1> kirkland, not too sure, cody-somerville ?
<kirkland> superm1: and how many of the pluggins ship on the CD?
<kirkland> superm1: myth-*
<superm1> kirkland, normally all of them do
<superm1> they have for the last two releases
<kirkland> superm1: i know it's not ideal, but some of those could be left for internet download/installation
<kirkland> superm1: do you have any way of gauging which plugins are more popular?  popcon.ubuntu.com perhaps?
<superm1> kirkland, well the CDs aren't "oversize" persay yet for mythbuntu, just they have increased in size
<kirkland> superm1: personally, i only use MythVideo and MythWeb nowadays....  fwiw....
<superm1> i'm afraid this is just a lot of cruft though
<kirkland> superm1: ohhhhh, okay
<superm1> because the installs got along fine before and never got requests for adding other things in
<kirkland> superm1: that's a different story... I thought you were 200M over a 700M iso !
<superm1> kirkland, well we have some high res artwork coming around, so its very possible we will go over soon too
<ScottK> Personally, I don't think a mail server meets the definition for recommends for a database.
<ScottK> I'd drop it to suggests postfix|mail-transport-agent and be done with it.
<kirkland> superm1: fwiw, i've been messing with mdadm quite a bit lately...  it has mail-transport-agent as a Recommends, so that mdadm can mail you status information about degraded RAIDs
<superm1> kirkland, i'm not sure i agree with that for a recommends there either
<superm1> kirkland, but this should be up to your team to decide i suppose :)
<superm1> mostly because you still have to configure that mail application to use it, so its not entirely useful until you configure it
<superm1> if you are having  to go out of your way to configure it, why is it installed by default
<kirkland> superm1: right, i'll dig deeper tomorrow
<ScottK> kirkland: I'm not sure it makes sense there either, but I think the case is better for mdadm than for sql.
<kirkland> superm1: explicitly needing exim4 doesn't immediately make sense to me, at the moment
<kirkland> ScottK: my point is that recommending "mail-transport-agent" is more reasonable than explicitly requiring "mailx"
<ScottK> Yes, but it needs to be a specific one|mail-transport-agent.
<ScottK> If we're going to touch this stuff, may as well make it postfix|mail-transport-agent all the way around.
<kirkland> ScottK: I don't disagree with that
<lamont> make it default-mail-transport-agent|mail-transport-agent and have default-mail-transport-agent be a metapackage that Depends: postfix
<lamont> then we push all that back upstream to debian
<lamont> and they can make it exim4
<kirkland> and lamont's suggestion is an excellent one
<ScottK> soren has brought it up on debian-devel before and didn't really get anywhere.
<kirkland> except for the exim4 bit :-P
<ion_> kirkland: :-)
<ScottK> It pretty well devolved into a 'which MTA do we want for default' discussion.
<kirkland> but lamont's point is a good one...  a metapackage gives us that flexibility
<lamont> I'm happy to work with zugschlus on making it all pretty between the two of us
<kirkland> okay, i gotta call it a night
<lamont> for that matter, it doesn't actually have to be a real package, as long as only one MTA Provides it on each distro. :-)
<lamont> OTOH, that way lies madness
 * lamont realizes it's way past when he said he was going to bed as well
<lamont> g'night
<ScottK> Good night lamont who never looks at my scripts.
<ScottK> ;-)
<lamont> 2.5.4 kinda chewed up all of my brain last night
<lamont> very sleep deprived day today
<ScottK> Understand.
<ScottK> Just poking a little fun.
<ScottK> That was certainly more important.
<ScottK> lamont: Do we need postfix packages for dapper/feisty/gutsy/hardy?
<lamont> esp since I thought the announcement was friday until about 6 hours pre-release last night
<lamont> -security already has them, albeit maybe not unembargoed
<ScottK> OK.
 * lamont uploaded a total of 9 postfix packages between last night (embargoed) and this morning (post-announce to sid/experimental and a sync req)
<ScottK> Yahoo.
<lamont> including backporting the *&*^_ fix from 2.3 to 2.2 for dapper.  which required src/util/safe_basename.* or such
<lamont> and then that seems to have been compilcated by either kees' scripts, or by feisty/gutsy not liking an attribution in changelog when there's only one
<ScottK> I wondered about that since I say Upstream didn't do you the favor of a patch for 2.2
<lamont> the patch applies cleanly, it just calls a function that isn't in 2.2
<lamont> fortunately, src/util is _VERY_ modular and isolationist between files
<lamont> src/global less so
<ScottK> Kewl.  The best kind of patch.  Applies cleanly, but absolutely fails to work.
<lamont> FTBFS
<lamont> which is much nicer than builds-and-fails
<ScottK> Yeah.
<lamont> note that for the bug to be usable by an attacker, there needs to be a root-owned symlink to somewhere useful on the same filesystem as somewhere that postfix will naturally deliver to, in a directory where the attacker has write perms
<ScottK> Right.  There's a reason I didn't rush out and roll my own packages with the patch ...
<lamont> --> "oh.  we need to fix that." not "ZOMG SKY FALLING"
<ScottK> Yes.
<lamont> and 2937 is where we all laugh and  point at 1777 /var/mail machine
<lamont> s
<ScottK> Yeah.  All I had this morning was the opensuse email mentioning it, my phone for a web browser, and I was at the customer site.  I figured better safe the sorry and mailed you.
<lamont> heh
 * ScottK is off to bed.
<emgent> moin
<dholbach> good morning
<ion_> iÅ
<kirkland> dholbach: howdy :-)  you turned about 5 of my channels "red"
<dholbach> hi kirkland! :)
<dholbach> kirkland: I'm glad I didn't turn you red :)
<kirkland> dholbach: :-P
 * Hobbsee turns purple
 * ion_ turns rÃ¶ntgen
 * Mithrandir shakes the little purple alien.
<Hobbsee> eep!
 * Hobbsee turns orange
 * kirkland turns in for the night
<pitti> Good morning
<pitti> tkamppeter: I got your mail, will do
<dholbach> hi pitti
<ion_> pitti: Did you notice my message?
<pitti> ion_: /tmp/ is 403, and I cannot figure out the full URLS (without suffix, .patch, or .dpatch)
<pitti> ion_: yep, I was just looking at it
<ion_> pitti: The latest message. :-) I put the patches to http://heh.fi/tmp/cups/
<pitti> aah
<ion_> pitti: Patch 05 probably shouldnât go in just yet (iâm the only one who has tested that functionality so far), but the ones before it should be okay.
<TheMuso> Morning pitti.
<pitti> ion_: I usually keep track of where they got sent upstream in the patch header; do you have some STRs etc. for them?
<Hobbsee> pitti!
<pitti> ion_: hm, patching debian/local/ with patches?
<ion_> pitti: Those are debdiffs
<ion_> pitti: I havenât got around to posting anything to upstream yet.
<pitti> ion_: so I apply 1 to 4, and you'll discuss 05 with tkamppeter, and maybe he commits it when he's ok with it? (my last day today, I'll be on holiday from tomorrow on)
<ion_> pitti: Sounds good
<tkamppeter> Ion_, thanks for all the patches, but did you test whether OOo prints correctly, especially with options?
<ion_> tkamppeter: Yes, i did. It respected the options to my surprise.
<tkamppeter> Ion_ then OOo perhaps has changed with the time, great.
<tkamppeter> pitti. if I find CUPS bugs (or apply #5) during your vacation, should I simply upload a 1ununtu1 into Ubuntu and you resync afterwards?
<ion_> tkamppeter: Now that i look at cups/error_log, the print from OOo never used oopstops, the entire chain was pstopdf â pdftopdf â cpdftocps.
<pitti> tkamppeter: yes, please do that
<pitti> tkamppeter: but please don't commit the UNREELASED -> xubuntuy changelog changes to the svn
<ion_> tkamppeter: D [15/Aug/2008:08:43:49 +0300] [Job 236] argv[5]="Resolution=600x600dpi HPHalftone=Standard HPEconoMode InputSlot=Auto Smoothing=Off PageSize=Letter job-uuid=urn:uuid:3c87b758-557c-3db9-72c3-c82bf647a1b3"
<ion_> tkamppeter: OOo put the ppd options there correctly.
<pitti> tkamppeter: ttf-freefont should really be a Recommends:, will change that
<ion_> texttopdf probably doesnât work at all without it, unless iâm mistaken.
<pitti> right, but you don't need it very often?
<ion_> Yeah, most users probably wonât. Perhaps texttopdf should be changed to tell the user to install ttf-freefont if itâs not installed.
<pitti> ion_: erk, thanks; debian/filters/pstopdf is (was) a mess..
<ion_> Fixing it was a prerequisite for being able to get patch 05 to work. :-)
<pitti> tkamppeter, ion_: can one of you send ion_'s patches to the new filters to those Japanese gys?
<pitti> guys
<ion_> I didnât really edit any of the new filters from them, only changed their costs in #05. I wrote a new filter for the application/vnd.cups-pdf â application/vnd.cups-postscript conversion, though.
<pitti> the patch to change the font names, for example
<ion_> Ah, right
<emgent> moin
<pitti> ion_: ok, applied 1 to 4 to svn
<pitti> tkamppeter: ^
<pitti> ion_: thanks!
<ion_> Thanks
<tkamppeter> pitti, ttf-freefont is required by texttopdf, so we have to require it. But fortunately, also ubuntu-desktop requires it, which means that it is already on the CDs.
<ion_> Heh, i created patches to a svn repo with git, and pitti commits them to the repo with bzr. :-)
<pitti> tkamppeter: right, that's why it should be a recommends; texttopdf is not an absolutely critical part, thus people could uninstall ttf-freefont in embedded environments if they want
<tkamppeter> And I deal with upstream repos of all 4 RCSs (git, bzr, svn, cvs) and always use the client of trhe appropriate system.
<ion_> tkamppeter: Had i wanted to use the svn client, i couldnât have made the patches as separate commits anyway because of this bug known as âcommit accessâ. :-)
<tkamppeter> pitti, OK. As apt-get installs Recommends now, the usual desktop user will have the fonts. And so his right-click+Print of a text file in a file manager should work.
<pitti> tkamppeter: exactly
<pitti> ion_, tkamppeter: btw, dropping this silly svn repo and moving to bzr is on my short-term todo list
<pitti> especially for contributors like ion, for times when we have experimental/unstable/intrepid branches, etc.
<ion_> Nice
<pitti> svn sucks
<ion_> Amen, brother
<tkamppeter> pitti, is there a general planning of Debian to move to a modern RCS (bzr or git)?
<pitti> as a matter of fact, I have used bzrsvn with the cups branch so far :)
<ion_> Yes, i noticed.
<pitti> tkamppeter: that's up to indidivual maintainers
<tkamppeter> so Debian offers all the 4?
<pitti> all four pakcages are in debian, if you mean that
<tkamppeter> No, I mean the RCS server of Debian.
<pitti> DDs use all kinds of weird VCSs, some even still use tla/baz *cough*
<pitti> tkamppeter: alioth supports a lot, svn, cvs, bzr, at least (probably more)
<tkamppeter> tla/baz is older than CVS?
<pitti> but FSVO "support"
<pitti> you can store branches, but not browse them, etc.
<StevenK> tkamppeter: CVS has been around for decades.
<StevenK> tkamppeter: tla hasn't been around nearly as long, but quite a bit longer if you're Tom Lord.
<tkamppeter> StevenK, CVS is the first I used, when I started to get into free software, CVS was the only commonly used one.
<pitti> tkamppeter, ion_: cups uploaded to experimental and intrepid
<tkamppeter> pitti, thanks.
<pitti> tkamppeter: (without ion_'s patch 05)
<ion_> Patch 01 now. :-) I stgit-rebased the patch stack to the svn HEAD and re-exported the stack to the same web path.
<tkamppeter> ion_, you fifth patch is missing something: You are changing a conffile /etc/cups/mime.convs. dpkg will only install this change if the user did not modify the original by hand. If you want to impose this change to everyone, you have to do the same sed command also in the cups.postinst script, and tyhis only for the transition from the current CUPS package and older to your CUPS package.
<ion_> tkamppeter: It would be nice if /etc/cups/mime.convs were in /usr/share/cups in the first place. The file tells users to make local changes to local.convs anyway.
<ion_> tkamppeter: But yeah, iâll do that change.
 * pitti freaks out, sed? on conffiles?
<ion_> True. :-)
<pitti> nonononononono
<StevenK> sed on conffiles == bad
<StevenK> sed on conffiles == pitti beating you with a stick at UDS
<ion_> I better let the user handle it. dpkg will inform about the changed conffile anyway.
<ion_> If it only did a three-way merge. :-)
<liw> . o O (/etc/sed.conf)
<tkamppeter> Ion_, and CUPS 1.4 moves /etc/cups/mime.* even to /usr/share/cups/mime.
<ion_> tkamppeter: Nice
<tkamppeter> pitti, or should we move already all /etc/cups/*.{types|convs} files to /usr/share/cups/mime ?
<pitti> tkamppeter: with the old patch I had to move one back
<pitti> tkamppeter: but I don't know what's better, if upstream does it in 1.4, I'm fine with backporting that
<tkamppeter> pitti, the patch for /usr/share/cups/mime I have already replaced by the CUPS 1.4 version. So our CUPS is capable of having everything in /usr/share/cups/mime.
<pitti> right
<tkamppeter> ion_, I have found a bug in your cpdftocps filter: You are searching for CUPS options always with "<option name>=". Boolean options can also appear as "<option name>" or "no<option name>".
<ion_> tkamppeter: Ah, right. Will fix.
<ion_> tkamppeter: Is the ânoâ in no<foo> case-sensitive?
<tkamppeter> ion_, I think it is lowercase.
<tkamppeter> ion_, Duplex is not a CUPS option, it should not get filtered out.
<tkamppeter> ion_, have you also taken into account that application/cups-pdf can be PDF with JCL around it? If so, this JCL need to be saved by cpdftocps before it converts to PS and embeds the options and afterwards be merged with JCL added by pstops (or simply re-added in case pstops does not add extra JCL).
<tkamppeter> You should test whether pdftopdf applies the JCL options of the PPD. If it does so you can run pstops with the "emit-jcl=False" option. If pdftopdf does not apply JCL options of the PPD, you have to run pstops with "emit-jcl=True".
<tkamppeter> Any user or system-supplied "emit-jcl" you have to filter out in the cpdftocps filter.
<ion_> Ok, iâll do the JCL stuff later.
<dholbach> hi mvo
<mvo> hey dholbach!
<ion_> tkamppeter: Updated http://heh.fi/tmp/cups/01-pdf-filter-chain, still no JCL handling.
 * StevenK plots and schemes to get a Dapper server upgraded.
<ion_> tkamppeter: Anything to fix with the current option masking?
 * pitti blinks at the cups FTBFS and the various interesting "gcc OMG" errors and stares at doko
<tkamppeter> ion_, I am in doubt whethert it is such a good idea to replace Courier by FreeMono in texttopdf. For me texttopdf works without this change and the change would prevent using other fonts by means of the charsets/pdf.utf-8 file.
<tkamppeter> ion_, I think it is better to back that patch out.
<tkamppeter> Ion_, for me it looks like that fontconfig does the needed substitutions here.
<tkamppeter> pitti, I am currently replacing the texttopdf.c file by a bugfixed version from upstream.
<ion_> tkamppeter: I donât know really about anything else than that you added FreeFont to the packaging along with texttopdf, and texttopdf crashed because it tried to load Courier because it wasnât a TTF font, hence my patch. A better solution would be welcome, of course. :-)
<tkamppeter> Ion_, for me texttopdf did not crash when using the ttf-freemono fonts with the pdf.utf-8.simple file, without any patches on texttopdf.c or any other C file.
<tkamppeter> For me it creashed when used with pdf.utf-8.heavy, as that one contains fonts which are not in the distro (*.TTF).
<ion_> tkamppeter: Darn, perhaps i screwed up something with the charset files. Now that i think of it, i might have not had them installed while testing texttopdf for the first time and noticing the crash.
<tkamppeter> ion_, the important thing are also the links to the fonts files in /usr/share/cups/fonts/.
<ion_> tkamppeter: Perhaps defoma should be configured to maintain such links for all installed fonts?
<tkamppeter> ion_, I do not really know how defoma works and whether it would kick in here.
<tkamppeter> According to ldd texttopdf does not use libfontconfig.
<ion_> tkamppeter: See for instance /usr/share/defoma/scripts/gs.defoma and /var/lib/defoma/gs.d/dirs/fonts
<tkamppeter> ion_, if you can make texttopdf using defoma without modifying texttopdf by default, patches are welcome.
<tkamppeter> pitti, new upstream texttopdf.c with FreeMono patch backed out is on SVN now.
<pitti> tseliot: FYI, http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/revision/206 is what came out of the python-apt stuff; quite a bit smaller
<tkamppeter> ion_, please do not worry about the fonts for now, this works. Please sort out the JCL problem in the cpdftocps filter.
<ion_> tkamppeter: Yeah, iâll investigate the JCL thing after sleep.
<tkamppeter> ion_, what is the time for you now (where are you located)? When will you be back again?
<ion_> tkamppeter: Itâs 11:22 (AM), but i was awake during the night. :-) Iâll probably fall asleep soon. I assume iâll be back no later than ten hours from now.
<tkamppeter> ion_, OK
<tseliot> pitti: yes, it looks better now. Passing the function instead of the object is simpler and there's no need to subclass Cache.
<tseliot> pitti: which branch should I use to add the "recommended version" feature?
<tseliot> pitti: the changes in handlers and in the 2 GUIs won't affect other drivers in any way unless they support the "recommended" feature
<tseliot> pitti: maybe trunk for handlers and the guis while ubuntu for nvidia.py?
<mdz> pulseaudio certainly seems to wake up a lot
<mdz> hmm, only when my USB headset is connected
<lifeless> mdz: doing some power analysis?
<pitti> tseliot: right, the recommended feature should land in trunk
<tseliot> pitti: ok
<tkamppeter> pitti, I have found a solution for the JCL problem of cpdftocps which ion_ talked about:
<tkamppeter> pitti, pdftopdf adds JCL headers and footers according to the PPD file and to the options supplied on the command line (or the PPD defaults for not supplied options).
<tkamppeter> pitti. pstops does the same thing.
<tkamppeter> pitti, and pdftops does not care about JCL. It throughs the JCL away and makes PS out of the PDF part.
<tkamppeter> pitti, so we simply let the cpdftocps filter use the general setting of the emit-jcl option, not changing it, not masking it out and not adding it, so that pstops adds JCL the same way as pdftopdf did. So the JCL lost by pdftops gets re-added by pstops.
<pitti> I can't really follow, but if you understand the bug, and have a solution, great ;)
<tkamppeter> pitti, this means: No changes required on http://heh.fi/tmp/cups/01-pdf-filter-chain.
<ion_> Iâll add a comment about that to cpdf2ps and refresh the patch, a moment. (Didnât manage to fall asleep yet, thanks to the caffeine i drank a few hours ago.)
<mdz> lifeless: it's enough that I notice it in top
<lifeless> mdz: wheeee
<tkamppeter> pitti, so I will add the patch and commit it if it does not reveal new bugs.
<ion_> tkamppeter: Added some comments, http://heh.fi/tmp/cups/01-pdf-filter-chain
<tkamppeter> ion_, thanks
<tkamppeter> ion_, seems that you will not be able to sleep until the PDF workflow is ready.
<ion_> Heh
<tkamppeter> ion_, your last change are only comments in cpdftocps?
<ion_> tkamppeter: Yes
<tkamppeter> Ion_, small bug in cpdftocps: pdftops "$@" must be pdftops $@, otherwise you feed all the options into the queue name field.
<ion_> tjaalton: No, "$@" expands to "$1" "$2" "$3" etc.
<ion_> tjaalton: Sorry. tkamppeter
<tkamppeter> ion_, OK, reverting it.
<ion_> tkamppeter: On the other hand, "$*" expands to "$1$IFS$2$IFS$3" etc.
<ion_> tkamppeter: I noticed a typo in the comments: # â cpdftops (runs pdftops â pstops) (s/cpdftops/cpdftocps/)
<ion_> Shall i fix it and update the patch?
<ion_> Already did. :-)
<tkamppeter> ion_, you tell "$@" is correct, so there is nothing to fix.
<ion_> tkamppeter: The typo in the comment.
<ion_> % (set -- a b c d e; printf "|%s|" "$@"); printf '\n'
<ion_> |a||b||c||d||e|
<tkamppeter> ion_, there is another problem: CUPS defines an optional 6th command line argument for filters which is the input file name. cpdftocps does not support that.
<ion_> tkamppeter: It does. It goes to pdftops within "$@"
<ion_> tkamppeter: But intentionally not to pstops, of course.
<tkamppeter> ion_, yes, you are right.
<bigon> I'm the only one who cannot reboot/shutdonw using the shutdown dialog in gnome (intrepid) ?
<ion_> bigon: I only get a switch user/cancel/logout dialog.
<bigon> ion_, the dialog appears but when clicking shutdown nothing happends
<bigon> oh I get http://pastebin.be/13183
<seb128> bigon: no, that's a known issue
<seb128> bigon: #250506
<bigon> seb128, thx
<tkamppeter> ion, I have tried to print but have a problem: The Resolution option is set to 1200x1200dpi but the printout comes out with crappy 150dpi, perhaps broken down to that by the pstopdf filter in the beginning.
<tkamppeter> ion_, I have tested with the CUPS test page. It says 150x150dpi in the left box.
<ion_> tkamppeter: Hmm. The DPI setting worked for me. Whatâs the jobâs argv[5] in cups/error_log?
<tkamppeter> ion_, it comes from pstopdf, as when I do
<tkamppeter> /usr/lib/cups/filter/pstopdf 1 2 3 4 5 /usr/share/cups/data/testprint.ps > testprint.pdf
<tkamppeter> and then display testprint.pdf, it says 150x150dpi.
<ion_> Ah. Thatâs probably some default value because it doesnât read a PPD.
<ion_> Try PPD=/path/to/some/ppd /usr/lib/cups/filter/pstopdf ...
<tkamppeter> On real print jobs the 1200x1200dpi are not in the fifth command line argument, as I have set this value as PPD default.
<tkamppeter> ion_, probably this will not work, as I had the same observation with a real print job.
<tkamppeter> The filter is a script and it has hardcoded "-r150" in it. I will remove it and try again.
<ion_> Ah
<tkamppeter> Running the script manually it gives 720dpi now.
<ion_> I wonder how to make it grab the DPI value from the active PPD properly...
<ion_> I also wonder whether itâs relevant, i.e. whether it affects the actual PDF output. :-)
<ion_> Vector graphics wonât suffer for sure, but pstopdf could theoretically downscale embedded bitmaps.
<tkamppeter> The pstopdf conversion is OK when one looks at the page in acroread.
<tkamppeter> When I look at the printouts the only thing where it suffers is how the colors of the color wheel are rendered into bw.
<tkamppeter> ion_, there appears a coarse pattern and no grays.
<tkamppeter> ion_, the "-rXXX" in pstopdf has no influence on this.
<ion_> Hmm, ok...
<ion_> tkamppeter: I printed /usr/share/cups/data/testprint.ps using pstops and then pstopdfâpdftopdfâcpdftocps. I can see no difference at all in their quality.
<tkamppeter> ion_, sorry, I have tracked down the problem. It was the printer itself. I had to set it to Enhanced grayscale.
<tkamppeter> Now it works perfectly.
<ion_> Cool
<tkamppeter> ion_, but I will take the "-r150" out of the pstopdf filter anyway.
<ion_> Yeah
<ion_> Iâd guess the settingâs only relevant when using ghostscript to render postscript to a bitmap.
<tkamppeter> ion_, I think so, too. And as the filter does not do this, I have removed the option.
<pitti> mpt: I'd like to discuss some jockey UI changes with you, do yuo have some minutes?
<pitti> tkamppeter: FYI, cups failed to build, seems the new gcc doesn't like me or so
<tkamppeter> pitti, yesterday it still built and today it stopped?
<ion_> Worksformeâ¢
<ion_> I built it just a couple of hours ago.
<mpt> pitti, not at the moment sorry, I'm about to head out
<mpt> pitti, how about in 3 hours?
<pitti> mpt: works for me, thanks
<mpt> ok
<tkamppeter> ion_, then do not try "sudo apt-get update; sudo apt-get dist-upgrade", this will give you a bad gcc.
<ion_> Heh, alright :-)
<tkamppeter> pitti, ion_'s patch works correctly now for me. With some little corrections I have a perfectly working PDF workflow now. Should I commit it?
<asac> Ng: you have openvpn right?
<asac> Ng: can you test the latest packages from network-manager PPA?
<asac> (and remember to restart your system after upgrade)
<tkamppeter> pitti, please do not commit by yourself, as I have done several small corrections.
<ion_> Hm. After a print job, cups sets the RDYMSG as "READY", but IIRC it should be set as "" according to the PJL spec, so that the printer returns the display to its default view. Iâll make a patch.
<ion_> First iâll check the spec. :-)
<NCommander> seb128, morning
<Chipzz> NCommander: seb128 has a day off
<NCommander> wow, amazing concept :-P
<NCommander> I was just going to ask if he had any more packaging work for me
<ion_> tkamppeter: http://heh.fi/tmp/cups/02-pjl-messages (didnât test yet, still building)
<Ng> asac: sure can
<Ng> asac: do I really really need to restart? won't just restarting NM do the trick? :)
<ion_> tkamppeter: Ok, i tested the patch, it works.
<pitti> tkamppeter: sure, go ahead
<pitti> tkamppeter: cups is all your's in the next two weeks :)
<ScottK> Did I get fired and no one told me? "Your message to ubuntu-devel awaits moderator approval - Post by non-developer to moderated list."
<ScottK> I checked and the From address is the one that's subscribed.
<tkamppeter> ion_, thanks for the patch, please report all upstream CUPS bugs (for now this patch and also the path typo) at http://www.cups.org/str.php, with attached patches.
<ion_> tkamppeter: Yeah, iâll try to get around to reporting them.
<tkamppeter> pitti, I have committed all that. If you want to do a last synced Debian/Ubuntu upload before your vacation ...
<persia> ScottK: I got that today too.
<ScottK> Is this perhaps a question for #canonical-sysadmin then?
<ScottK> Other suggestions?
<persia> Do they manage the whitelist?  According to the information I saw, cjwatson managed the list.
<ScottK> I have no idea.
 * Hobbsee offers virtual gummy bears to whoever fixes listadmin
<Hobbsee> ah good, there's already a patch for it in debian.
<ion_> tkamppeter: Please see my private message. :-)
<asac> Ng: restarting the NetworkManager ... and restarting the nm-applet
<asac> Ng: should be ok
<asac> maybe reloading dbus config
 * NCommander sighs
<NCommander> morning Hobbsee
<Hobbsee> hey NCommander
<NCommander> Hobbsee, how goes your morning?
<Ng> asac: ok
<Hobbsee> my morning?  it's evening here, and i'm glad that work's over :P
<NCommander> Hobbsee, lucky, my morning began with one of my favorite ports being dropped from Debian
<NCommander> And the resulting flamewar on d-devel
<Hobbsee> awww
<NCommander> The worst part?
<NCommander> I'm a hurd/m68k porter :-P
<NCommander> I'm not sure the FD will approve me if those architectures get dropped -_-;
<mvo> I noticed that cups-pdf got demoted to universe in intrepid, out of curiosity, does cups itself provide this functionatliy now?
<seb128> hey NCommander
<NCommander> Morning seb128
 * NCommander is enjoying a nice hot cup of d-devel flamewar
<seb128> NCommander: want to look at getting the pygobject building?
<NCommander> why is it FTBFSing?
<NCommander> (usually an importing first question)
<seb128> NCommander: the debian and ubuntu packages are doing builds for multiple python versions
<seb128> NCommander: and the new version has a lib which doesn't play well with that
<seb128> NCommander: doko started doing changes to get the lib versionned by that doesn't build
 * NCommander twichs
<NCommander> Is it already packaged, and just FTFBS, or do I get the honour of packaging the new version ontop of everything else?
<doko> seb128: I thought you did finish that :)
<NCommander> morning doko
<seb128> doko: I've been too busy to look at it
<doko> ahh
<NCommander> seb128, well, I just finished repackaging glibc for m68k, so I can probably take a look at it
<NCommander> though my brain is fried
<seb128> NCommander: one sec
<seb128> NCommander: http://people.ubuntu.com/~seb128/pygobject/ the current version there
<mvo> tkamppeter: you probably know about cups-pdf, right? what is the status of this? it got demoted to universe, does that mean that there is something in stock cups now that provides this functionatliy?
<seb128> mvo: gtk does printing to pdf just fine no?
<seb128> mvo: if you select "print to file", you have the choice between ps and pdf usually
<tkamppeter> KDE 3.x apps all the time offered a "print to PDF" entry in their print dialog which opened a "Save as ..." for the PDF.
<mvo> seb128: aha, ok. and kde probably has something similar? it would just be useful for commandline users nowdays?
<tkamppeter> If this is not there any more in KDE 4, a simple "Print to file" should work as KDE apps send print jobs in PDF now.
<mvo> tkamppeter: ok, so the cups-pdf package is only useful for commandline users these days?
<tkamppeter> OOo has an "Export to PDF ..." entry in its "File" menu.
<doko> seb128: is this the one with my changes
<seb128> doko: 0ubuntu2 is your version yes
<seb128> I tried and it didn't build
<seb128> and I've been too busy to debug why
<tkamppeter> seb128, by the way, the PDF printing workflow (https://blueprints.edge.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format) is now completed on the server side and for KDE apps, as GTK apps can do "Print to file" with selectable PS or PDF, is there no simple possibility to let normal print jobs to be sent out in PDF?
<seb128> tkamppeter: I've no clue, as already said I don't know this code, you are welcome to look at the issue though
<pitti> tkamppeter: cups -4 FTBFSes on various architectures, e. g. sparc now, see debian bug 495220
<ubottu> Debian bug 495220 in cups "cups_1.3.8-4(sparc/experimental): FTBFS: unrecognized command line" [Serious,Open] http://bugs.debian.org/495220
<pitti> tkamppeter: that is a new CPPFLAG introduced in the local filters, and obvioously bogus for !i386
<pitti> tkamppeter: can you please fix that before I upload -5?
<pitti> tkamppeter: this affects a lot of Ubuntu arches, too
<pitti> tkamppeter: -Wall -g are not even appropriate CPPFLAGS (but CFLAGS), and -march even less so
<jcristau> pitti: err. -Wall -g in CPPFLAGS should be just fine.
<pitti> jcristau: but what for?
<jcristau> same as in CFLAGS, except for c++ instead of c
<pitti> that's CXX, not CPP
<pitti> CPP is preprocessor
<jcristau> ignore me
<jcristau> yeah, i know. but it seems 2 cups of coffee weren't enough
<pitti> tkamppeter: let me commit that myself
<pitti> jcristau: no number of coffee cups suffices to master cups
<jcristau> pitti: :)
<tkamppeter> pitti, done and committed
<pitti> tkamppeter: ah, you beat me to it, thanks
<tkamppeter> pitti, texttopdf contained a hardcoded -march=pentium
<tkamppeter> I have deleted it.
<pitti> tkamppeter: I'll add a changelog for it to close the bug and upload
<poningru> I had a quick question: https://help.ubuntu.com/community/LiveCDCustomization following that for live cd creation, but does the install get any changes I make as well?
<poningru> as in if I were to create a live cd changes with a different kernel and few gconf changes will the changes show up in the install as well?
<poningru> and where does one go for general downstream help?
<persia> poningru: If you've defined matching meta-packages, it should, and probably the Ubuntu derivatives team.
<persia> (or rather, a matching manifest, I believe, but I may be mistaken)
<pitti> tkamppeter: -5 uploaded to intrepid and experimental
<poningru> searching
<asac> Ng: did it work?
<ScottK> pitti: Would you have time to attend to a sync that's blocking a further upload?
<pitti> ScottK: sure, shoot
<ScottK> pitti: It's in Bug #258160
<ubottu> Launchpad bug 258160 in sip4-qt3 "Please sync sip4-qt3 4.7.7-1 from Debian Experimental (Main)" [Wishlist,Confirmed] https://launchpad.net/bugs/258160
<ScottK> Thanks.
<tkamppeter> pitti, great, thanks.
<pitti> ScottK: swoosh, there
<ScottK> Thanks.
<Ng> asac: I restarted NetworkManager and nm-applet, but it's segfaulting in nm-openvpn-auth and logging an error about not being able to get connection secrets (of which there should be none, the key is passwordless)
<Ng> asac: it's possible I've set it up wrong, the new config stuff is quite a lot more verbose than before, but I don't think so
<Ng> asac: http://pastebin.ubuntu.com/37730/
<tkamppeter> Anyone here is familiar with the GTK code?
<Ng> asac: interestingly, I get a similar thing if I try to export the settings for it :/
<asac> Ng: is there a way i can test  openvpn?
<asac> e.g. do we have a VPN?
<Ng> asac: not that I can quickly/easily hook you up with. It's not too bad to configure, and then you just need to make a CA and some keys, which they have some docs for
<asac> Ng: ok. ill try over weekend
<Ng> asac: http://openvpn.net/howto.html and http://openvpn.net/index.php/documentation/miscellaneous/rsa-key-management.html are pretty good, and I think I did it originally with something I dug out of google, but I don't seem to have a record of it unfortunately
<asac> Ng: ok. thanks. noted.
<asac> Ng: if i dont manage to set that up, ill come back with more debug instructions ;)
<Ng> unfortunately their Import thing doesn't seem to like importing native openvpn config files. It gets some of the values, but the connection editor segfaults when you start poking around ;)
<Ng> sure
<lamont> pitti: any chance you (or any $ARCHIVEGOD) could slap bug 257893 around for me?
<ubottu> Launchpad bug 257893 in postfix "Please sync postfix 2.5.4-1 (main) from Debian incoming/unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/257893
<pitti> lamont: slapped appropriately
<lamont> ta
<BenC> Is there any known bugs concerning IPP printing?
<BenC> I'm not sure if it's me or if ipp in cups is just broken
<BenC> (intrepid of course)
<pitti> BenC: can you try "sudo aa-disable cups", restart cups, and try again?
<BenC> pitti: ok
<BenC> pitti: I don't have a program called aa-disable on my system
<pitti> BenC: sorry, "aa-complain"
<pitti> BenC: "sudo rm -r /" should help as well
<BenC> pitti: I've heard that command works really well...I'll try it!
<pitti> let's check how many people actuall run my sudo commands over IRC without checking :-P
<pitti> "r"ead"m"ail -"r"eally"f"ast *
<BenC> at least we're not in #ubuntu
<pitti> BenC: insta-bugzap
<BenC> pitti: actually, I got a crash in applet.py...didn't match any other bug reports, so I let apport file it
<pitti> mvo: can I ask python-apt to just read one particular repository, not the entire sources.list{,.d/*.list} ?
<mvo> hey pitti
<BenC> pitti: KeyError 61 in update_job() in jobviewer.py
<mvo> pitti: not right now, what is your use-case for this?
<pitti> mvo: a driver db gives me a package repository and a package name in it
<pitti> mvo: just a strawman idea, nothing serious so far
<mvo> pitti: and you want to check if its from that repository? or you want to do a apt-get update that just updates  this repository (or both :) ?
<pitti> mvo: the latter, just to save some time
<mvo> pitti: I like the idea!
<pitti> mvo: apt.Cache() rightfully stumbles over a malformed deb line, but apt.Cache().update() doesn't fail on an invalid URL ("deb http://foo /"); shouldn't something detect that as well?
<mvo> pitti: you don't get a exception that some package could not be downloaded if you give it a non-existing repo?
<mvo> pitti: that sounds like a bug
<pitti> mvo: so far I just added that deb http://foo to /etc/apt/sources.list.d/jockey.list and did "c = apt.Cache(); c.update()"
<pitti> I didn't try to install anything yet
<pitti> I just expected c.update() to freak out on an invalid source
<pitti> but it might make sense that it doesn't, I don't know
<pitti> it's perhaps more like a warning kind of situation
<mvo> oh, right. I think this is a side effect of a change that we did not make apt more happy when no networks are available, network errors like "resolvefailure" are ignored by default
<mvo> hm, I guess it should do something about it, what would be best? a exception with the repos that didn't work?
 * pitti scratches head
<BenC>  def update_job (self, job, data):
<BenC>         store = self.store
<BenC>         iter = self.jobiters[job]
<BenC> pitti: it crashes on that last line
<pitti> BenC: what's that from?
<pitti> mvo: it just returns 1/0 so far, right? an exception might be too heavy
<BenC> pitti: jobviewer.py
<pitti> BenC: oh, that's from s-c-p; /me directs BenC to tkamppeter
<pitti> BenC: an apport crash report should be fine
<BenC> pitti: already done...but I need to be able to print :)
<BenC> tkamppeter: ping ^^
<pitti> BenC: the applet shouldn't stop you from it, it's just GUI sugar
<pitti> BenC: did the aa-complain help, btw?
<BenC> pitti: I'm not sure what I am looking for with that...dmesg didn't show anything weird
<BenC> pitti: and it still doesn't print
<pitti> BenC: ok, I thought because of the various apparmor violations cups spits out nowadays for various "funny" network protocols
<BenC> pitti: connecting to the ipp, I can directly print a test page, but cups isn't sending data
<pitti> BenC: anythign helpful in /var/log/cups/error_log? anyway, tkamppeter is the guru
<BenC> E [15/Aug/2008:11:19:11 -0400] cupsdAuthorize: Local authentication certificate not found!
<MacSlow> seb128, intrepid (GNOME) is not going to be using gnome-session 2.23.x or is it?
<BenC> just that
<seb128> MacSlow: not decided yet, why?
<BenC> E [15/Aug/2008:00:20:16 -0400] PID 19889 (/usr/lib/cups/backend/ipp) crashed on signal 9!
<BenC> oooh, there's a good one
<StevenK> Blink? What SIGKILL'd it?
<BenC> I wonder if that was me pausing/resuming the printer queue
<MacSlow> seb128, there's a nice simplification introduced in gdm upstream that would make part of my work a bit easier (namely the greeter to use is simply controled by a .desktop file in /usr/share/gdm/autostart/LoginWindow... before it was hardcoded and requires a considerable amount of boiler-plate code)
<MacSlow> seb128, if it's not decided yet... just take that as a pro-argument for using the new gnome-session :)
<seb128> MacSlow: that doesn't seem to be a gnome-session thing but a gdm one
<MacSlow> seb128, it's both sort of as the new change in gdm upstream uses the new gnome-session for session-managment
<seb128> MacSlow: the new gdm uses the autostart dir you mentionned for a while
<MacSlow> seb128, but not for the selection of the greeter to use... at least until yesterday it did not
<seb128> ok
<seb128> MacSlow: we are not likely to ship the new gdm anyway so it's not really revelant there
<MacSlow> on that regard you're right
<nxvl> MacSlow: when are we having the new gdm in intrepid?
<nxvl> MacSlow: or we need to wait one more release cycle?
<nxvl> i was the video, it look amazing
<nxvl> s/was/saw/
<MacSlow> nxvl, atm it looks like we're not going with the new gdm by default... nevertheless I'll keep working on the graphical-greeter
<nxvl> :(
<johanbr> MacSlow: is there any chance of having it as an optional package?
<MacSlow> johanbr, that's the plan
<johanbr> Excellent. Thanks.
<mpt> pitti, ready when you are
<pitti> mpt: hi
<pitti> mpt: so, you roughly know the current jockey main window, right?
<pitti> mpt: we will gradually add features to support "third-party driver databases"
<pitti> mpt: like printer drivers from openprinting.org, etc.
<mpt> ok
<pitti> or community people's PPAs, and whatnot, through some QAification process
<pitti> mpt: I would like to disable them by default and limit drivers to the ubuntu archive
<pitti> but I think there should be some discoverable way to enable them
<pitti> like a checkbox "Check for unsupported community drivers" or so
<mpt> This is sounding more and more like it should be part of the same interface as package management
<pitti> indeed it uses the package manager as its underpinnings, sure
<pitti> but it provides a per-hardware component centric view on it, and provides the driver db lookup, etc.
<mpt> I meant part of the same human interface
<pitti> like g-a-i?
<mpt> yes
<mpt> anyway, where would it look, precisely?
<mpt> I assume it wouldn't look through all the PPAs that exist on Launchpad :-)
<pitti> mpt: for now it can consult openprinting.org and fetch packaged PPD files and the like
<pitti> mpt: hell, no :)
<pitti> mpt: and ATM we are working on an "Ubuntu driver database" where we could add QA-blessed third-party repos to, but that's still in the design phase
<pitti> that is, the client side is done, but the server doesn't exist yet
<mpt> The client side is done?
<mpt> What does it look like?
<pitti> just the machinery
<mpt> oh
<pitti> no UI yet
<pitti> which is the bit I'm thinking about right now
<pitti> mpt: the UI doesn't look any different in the end
<mpt> How do you know if the machinery is done, if the HI isn't designed yet? :-)
<pitti> "dude, you plugged in hardware, you need that driver" *click* "ok"
<mpt> hm
<pitti> mpt: the code has all the bits to look up hardware, query the driver db (the protocol is finalized), create handlers for it, etc.
<mpt> Why would you not want to install drivers for hardware that you've just connected?
<pitti> so where your nvidia card appears today, in some months there could be your updated wifi driver from dell, or whatnot
<pitti> mpt: if these drivers are in the ubuntu repo, there should be no question, and that's what we do ATM
<pitti> mpt: but e. g. openprinting.org is not under our control, so we cannot say in advance that we can fully support it, or give guarantees whether they will actually work
<pitti> or community drivers
<mpt> hmmm, ok
<pitti> mpt: e. g. some weeks ago I packages an updated driver for DVB-T cards for hardy
<pitti> which is in my ppa
<pitti> it would be nice to make those available somehow to folks, but not by default
<mpt> I think we should avoid explicitly asking people to choose between unsafe drivers and their hardware not working at all
<mpt> so, no confirmation alerts hopefully
<pitti> mpt: maybe, instead of making a global choice, we could show these drivers in the list, but warn when enabling them?
<pitti> when someone clikcs on a driver he'll get the confirmation dialog with the detailled descrption and rationale, etc. anyway
<mpt> Then we should find some way that doesn't involve a confirmation dialog
<mpt> For example, yesterday I suggested having the description of the selected driver in a second pane, underneath the list of drivers
<pitti> mpt: you mean you want to get rid of the already existing one as well? (which shows the driver details)
<pitti> that would probably work, too
<mpt> If we did that, and had an "Apply Changes" button at the bottom, that would do the same job as a confirmation alert, without the annoyance of a confirmation alert
<pitti> there we can also have some fields/buttons for license and rationale
<mpt> Ok, so what information do we need to show?
<mpt> What kinds of license are there?
<pitti> for now, I have:
<pitti>  * license status: free/ not free (and in the latter case, a button or link to the full text)
<pitti>  * description and rationale
<pitti>  * support status: official Ubuntu driver or community
<mpt> Can you give an example of what you mean by "rationale"?
<pitti> e. g. for nvidia, "You need this driver to be able to use desktop effects and 3D applications"
<pitti> (the actual strings are a bit more wordy, but that's the idea)
<mpt> ok
<mpt> By "support status" do you mean whether Canonical maintains it (as in PackageMaintainednessPresentation), or something else?
<pitti> s/Canonical/Ubuntu/
<pitti> mostly "official Ubuntu driver" vs. "third-party contribution"
<mpt> so a driver that's in Universe is an "official Ubuntu driver"?
<pitti> we can further divide the status if we need
<pitti> we have gradually less control and QA over main >> universe >> third-party repo
<pitti> if the entire idea is bogus, please tell me, then we forget about the third-party repos and just include drivers which we QAed ourself
<mpt> It's probably not bogus, I'm just not sure what you mean by "we"
<pitti> but so far people use google and some crackful recipes to install whatever drivers they need, so anything that makes that a bit more structured and controlled is a win, IMHO
<pitti> mpt: 'we' in the sense of 'divide the status' -> mostly me, with your input
<ScottK> pitti: Probably the most important part of the idea is the qualification process for 3rd party repos.  Get that right, and I think it's good.  Get it wrong and it's possibly quite dangerous.
<pitti> ScottK: agreed
<mpt> pitti, sorry, I was unclear. I mean, who's "we" in "drivers we QAed ourself"?
<pitti> an indeed, the idea is not really that users should be scared about trying a driver
<pitti> but rather to tell them "if it doesn't work, Ubuntu cannot fix it, but it's someone else's fault"
<pitti> mpt: that's a little blurry indeed, and heavily depends on how we advertise it
<pitti> mpt: if we say "this thing Just Works(tm)", we need our hw certification and QA team
<pitti> if we just say "it doesn't break your system and is properly packaged", it could be ubuntu-motu
<pitti> so the certification "level" should map to the set of people allowed to add it to the driver db
<pitti> mpt: as I said, the only real DB right now which we have is opeprinting.org, which is mainly tkamppeter's work
<pitti> the rest is drawing board
<mpt> Do we currently have drivers in Universe at all?
<pitti> (and not at all something for intrepid)
<pitti> mpt: yes, e. g. the virtualbox kernel modules
<pitti> and since we have dkms now, non-kernel-packaged drivers actually started to make sense again, so I expect we'll have more in the future
<pitti> until now it was virtually useless to have a separately packaged kernel driver, due to our numerous ABI changes
<mpt> ok, so maybe something like:
<mpt> "This driver has been tested by Ubuntu core developers."
<mpt> "This driver has been tested by Ubuntu community developers."
<mpt> "This driver has not been tested by Ubuntu developers."
<mpt> There are probably half a dozen things wrong with that, tell me what they are. :-)
<pitti> that's actually pretty much what it comes down to
<ScottK> We also have the drivers for envy-ng in Multiverse
<pitti> right
<pitti> that would fit into the "Ubuntu community" class
<mpt> Have the openprinting.org drivers been tested by anyone?
<pitti> and I think envy-ng and jockey will merge some day
<pitti> mpt: by default, no; ATM I am trying to convince tkamppeter to provide packaged PPDs, which are relatively uncritical
<pitti> but there are also packages with real code in them, which are a bit more sensitive
<pitti> they are still much saner to the stuff printer manufacturers offer at their websites, though
<pitti> (anyone still remember the "printer driver set openoffice to setuid root" bug?)
<tkamppeter> pitti, and such driver packages we will not accept.
<pitti> hehe :)
<mpt> pitti, do you need anything more than that at the moment?
<pitti> mpt: I think I made up my mind, thanks a lot
<mpt> e.g. do you want a sketch of the two panes or whatever
<pitti> now I have 14 days of vacation to think about it :)
<mpt> ok
<mpt> enjoy it :-)
<pitti> mpt: I think I'll do a glade mockup and run it by you
<pitti> mpt: thanks
<tkamppeter> pitti, I was very much occupied with getting the PDF workflow into intrepid, the scripting for automatic generation of PPD file packages I will do in the beginning of September (it is not in Intrepid itself, so it does not need to meet the FF).
<pitti> tkamppeter: oh, cool! so in general you like the idea?
<pitti> tkamppeter: yes, it's not tied at all to Ubuntu releases
<pitti> so, I'm going to leave now, still have to do some preparation for tomorrow's wedding of my friend, and for our holiday trip
<pitti> have fun everyone, cu in two weeks!
<ScottK> Right, so I just missed pitti.
<ScottK> If there's an archive admin in the house, I'd appreciate them accepting the backports in Bug #258193 (source backports just uploaded) since it has a CVE fix in it.
<ubottu> Launchpad bug 258193 in gutsy-backports "Please backport postfix 2.5.4-1 to Gutsy/Feisty/Dapper" [Medium,In progress] https://launchpad.net/bugs/258193
<agy> I will be performing maintenance on wiki.ubuntu.com in 20 minutes. During this time the wiki will be placed in read-only mode. Please save your edits before this time. The maintenance is expected to last 15 minutes.
<zul> slangasek: ping any idea when samba 3.2.1 is going t be uploaded to unstable?
<slangasek> zul: approximately yesterday
<zul> slangasek: ah good :)
<zul> slangasek: I guess it will be kind of a monday morning kind of thing to do then
<ScottK> slangasek: Thanks for the postfix backport acceptances.
<slangasek> ScottK: n/p
 * ScottK would like to note for the record for those who wonder if *-backports gets security coverage or not, that this particular issue is fixed in *-backports before *-security.
<persia> ScottK: Does everything in -backports get that level of security support?
<ScottK> persia: No.
<ScottK> There seems to be a common assumption that "Not always"  == "Never" and that's not correct.
<persia> Ah, yes, that would not be correct.
<slangasek> nonnumquam
<persia> superm1: Unfortunately, there appears to be a real package named "gdm-themes".  Any ideas for a good name for a virtual package?
<superm1> persia, why not just gdm-theme?
<superm1> or default-gdm-theme
<agy> Maintenance on wiki.ubuntu.com has been successfully completed.
<persia> I don't like default-gdm-theme because it makes me thing someone would have to mess around with alternatives.
<persia> (or is that already being done?)
<superm1> well in order to use a different gdm theme you need to use  gdm-cdd.conf
<superm1> which is what mythbuntu does; not sure about xubuntu or studio
<persia> edubuntu has the issue as well.
<_MMA_> Studio uses ï»¿gdm-cdd.conf.
<persia> cody-somerville, ogra: what do you use?  Any thoughts on a virtual package name?
<cody-somerville> persia, whats the question?
<persia> cody-somerville: RIght now, gdm Recommends: a closed set of gdm themes.  I think it makes more sense to follow the practice of usplash, and recommend a virtual package so that any of the flavours that use gdm can have their own splash screen.
<persia> So, the question is whether the gdm-themes portion of xubuntu-default-settings uses gdm-cdd.conf to set the gdm theme.
<persia> s/splash screen/theme collection/
<_MMA_> cody-somerville: ï»¿Bug 258091
<ubottu> Launchpad bug 258091 in gdm "gdm should not recommend ubuntu-artwork" [Wishlist,Confirmed] https://launchpad.net/bugs/258091
<ogra> persia, ï»¿gdm-cdd.conf
<cody-somerville> Xubuntu just has a gdm.conf
<slangasek> kees: so have you talked to YokoZar about your sigsegv madness? :)
<persia> Right.  Based on that, I'll recommend xubuntu switch to using gdm-cdd.conf to match everyone else :)
<ogra> cody-somerville, oh ? since when ?
<ogra> i remeber jani and i worked out he gdm-cdd.conf setup
<cody-somerville> ogra, Lets take a step back.
<ogra> simply because we could set ut through alternatives if wanted then
<cody-somerville> Whats a gdm-cdd.conf? :]
<ogra> gdm.conf for a cdd (custom debian derivative)
<persia> (cdd is Debianese for flavour)
<ogra> right
<cody-somerville> Okay, we do have a cdd setup
<persia> OK.  So, is everyone happy with changing gdm to Recommend: ubuntu-gdm-themes | gdm-theme ?
<superm1> yeah that's fine with me
<seb128> persia: that's basically what it's doing now
<superm1> i'll have our theme provide that
 * cody-somerville nods.
<persia> This means theme providers will need to Provide: the package name.
<seb128> persia: just not using a provide but listing alternatives
<seb128> persia: that's going away in the new gdm anyway
<slangasek> kirkland: so kees didn't manage to get this grub stuff uploaded before alpha-4?  I saw him working oni t
<slangasek> on it
<kirkland> slangasek: pitti did the upload
<persia> seb128: Is it going away for intrepid?
<seb128> persia: not decided yet
<kirkland> slangasek: i think he chose to not put it in alpha-4
<slangasek> kirkland: I don't see that an upload has happened
<persia> seb128: Any objections to using the virtual package model for now, to br dropped later if it is decided?
<seb128> persia: I'm not convinced it's of any use but no
<seb128> since we list the known derivatives there already
<superm1> seb128, it will solve the problem for all of these derivatives that don't want any of  the ubuntu normal gdm themes (and future entrants too)
<seb128> and that's only a recommends
<seb128> superm1: that's only a recommends, don't install it?
<persia> seb128: Means mythbuntu and ubuntustudio don't pull ubuntu-artwork, and provides a cleaner model for ubuntume if they want to follow and we don't switch for intrepid.
<superm1> seb128, we have CDs that it gets installed by
<kirkland> slangasek: hmm, this is confusing....
<superm1> seb128, during the CD build process
<persia> seb128: recommends-by-default, no?
<kirkland> slangasek: basically, pitti and benc had uploaded directly to grub, bypassing the bzr tree
<kirkland> slangasek: i pinged pitti about it, and he fixed it, in retrospect
<seb128> persia: there was some discussions about being able to list recommends which should not be on the cd
<kirkland> slangasek: now, i'm trying to see where my code fell....
<seb128> but anyway having a provide should not hurt either
<slangasek> kirkland: right - he fixed the fact that things were not committed to bzr
<slangasek> kirkland: but there's not yet an upload of your new code
<persia> seb128: There's the possibility to blacklist stuff in the seeds, but it gets messy if someone later changes things.
<slangasek> kirkland: so, time for me to do a final review and upload? :)
<kirkland> slangasek: sure
<kirkland> slangasek: https://code.launchpad.net/~kirkland/grub/33649b
<_MMA_> ï»¿seb128: There's also the issue on upgrading.
<seb128> ok, enough noise, I'm no supposed to work today
<cody-somerville> So....
<cody-somerville> I'm going to upload xubuntu-default-settings now, mmkay?
<superm1> so he is implementing it or not?
<_MMA_> Looks like yes.
<kirkland> slangasek: hold on....
<kirkland> slangasek: https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu
<kirkland> slangasek: see rev 847
<slangasek> yes
<slangasek> been looking there already :)
<kirkland> slangasek: looks like it's in the branch, just didn't get pushed to the cd?
<slangasek> it has to be uploaded as a source package to get onto the CD, yes
<kirkland> slangasek: ah, or an upload of the source package
 * slangasek notes that this is what he meant when he referred to "upload" above :)
<kirkland> slangasek: gotcha.   bzr-based vcs control requires 1) push to the branch, then 2) upload of the source package...  is that the right vocabulary?
<kirkland> s/the branch/the main branch/
<seb128> persia: the recommend would be "gdm-themes" then? what about the gtk and icons theme?
<persia> seb128: Does gdm need those?  I thought it only needed the gdm-theme.
<seb128> there is a gtk theme specified in the gdm.conf too
<persia> ubuntu-desktop depends on ubuntu-artwork anyway, so I'm not worried in that case.
<persia> Hmm.
<persia> superm1: ?
<seb128> icon theme is probably not really required but it's nicer to have icons matching the theme used
<slangasek> kirkland: yes
<persia> seb128: I agree it ought look pretty: I'm just following comments in the bug.  On the other hand, do you imagine many cases where gdm is installed without any $(flavour)-desktop?
<kirkland> slangasek: cool.  are you still reviewing it?
<seb128> not really but technically the depends and recommends should get you something which doesn't complain that about the theme used in the config not being available
<kirkland> slangasek: also, how's the pam-config-tool thingy coming?
<slangasek> kirkland: still reviewing it; pam thingy coming late today, I believe
<persia> seb128: Hmm.  What do you think it should be then?  ubuntu-artwork | ?
<kirkland> slangasek: cool, thanks on both accounts.
<_MMA_> seb128: I'm unsure why it needs anything Ubuntu-specific? Just have the Ubuntu one work the way the other flavors do.
<persia> _MMA_: It needs a default when using a virtual package, and it makes sense to have the default be Ubuntu.
<_MMA_> If GDM just depended on the default GNOME themes this wouldnt be an issue.
<_MMA_> But the GDM package is changes to look for the Human theme. I dont see why it should.
<persia> Yes, but surely it's better for Ubuntu GDM to recommend the Ubuntu gdm theme as defaiult, no?
<_MMA_> Ubuntu GDM in what sense? The GDM package *in* Ubuntu? I think that ought to be flavor agnostic.
<_MMA_> persia: The flavors have to override the conf in the GDM package. To me, it shouldn't have to override Human, but Circles, or whatever.
<persia> _MMA_: Hmm.  Ubuntu Desktop isn't really set up with all the cdd stuff, so I'm not sure that would work, without rather more testing time than is available between now and FeatureFreeze.
<_MMA_> persia: Sure. Ideally, that's how I would like it as it would cause less headache in the end for the flavors. But I realize the time constraints.
<mvo> BenC: is bug #257162 releated to the new last-known-good kernel feature?
<ubottu> Launchpad bug 257162 in linux "error while upgrading to linux-image-2.6.24-19.34 " [Medium,Incomplete] https://launchpad.net/bugs/257162
<superm1> persia, seb128 i think that if other piece are needed to make a particular gdm theme work, they should be dependencies of the theme itself
<persia> superm1: Works for me, or perhaps recommendations, depending on the urgency of having them present.
<tkamppeter> seb128, I have good news!
<tkamppeter> seb128, I succeeded to patch GTK so that GTK apps output PDF instead of PostScript for print jobs. The patch is very simple.
<tkamppeter> gedit and gimp (standard print dialog, not the Gutenprint one) output PDF with the patch.
<YokoZar> slangasek: sigsegv?
<slangasek> YokoZar: kees has an alternative solution for wine 16-bit apps that doesn't involve reducing kernel security
<YokoZar> oooh
<slangasek> YokoZar: still a work in progress, and it's very evil, and it will make 16-bit apps somewhat slower; but ultimately it's a reliable solution that doesn't depend on fiddling with sysctl
<YokoZar> slangasek: I take it that it generalizes beyond Wine then
<slangasek> YokoZar: nothing beyond wine needs to mmap 0, AFAIK
<YokoZar> slangasek: I believe dosbox and something else have similar problems (see Dan Kegel's post in the Wine bug report)
<slangasek> it's not general, no - it's a sigsegv handler that would have to be added to any process that thinks it needs to access memory at address 0x0
<slangasek> right, so the same would need to be applied to dosbox
<emgent> evening
<psusi> packages.ubuntu.com is doing something screwwy... am I doing something wrong or is it broken?  When I look up the linux-image-2.6.24-19-generic package in hardy and click on the list of files link it tells me "No such package in this suite on this architecture"
<seb128> tkamppeter: can you open a bug and attach the patch there?
<seb128> superm1: that's not the theme which depends on the gtk theme but the gdm configuration
<superm1> seb128, then similar virtual package type things could be done i suppose, but I don't believe that gdm complains if it can't find the right gtk theme does it?  It just falls back to a known one
<seb128> superm1: probably not but it means that a sudo apt-get install gdm would not give what the user expect
<superm1> seb128, is that expectation actually pre-determined though?
<seb128> superm1: what do you mean? gdm has a configuration, the expectation is to have it working when gdm is installed
<seb128> the new gdm will make things easier since it uses gconf for its configuration
<_MMA_> seb128: I would expect that any user at a point where they're installing GDM would be happy with a default GNOME theme like circles.
<slangasek> tkamppeter: taking a look inside the fonts from gsfonts and ghostscript-fonts, the ones bundled in ghostscript-fonts are an earlier version of the URW fonts and should /not/ supersede the fonts from gsfonts
<slangasek> kirkland: grub 0.97-29ubuntu35 uploaded
<slangasek> kirkland: funny how the newer patch is simpler :)
<_MMA_> ï»¿seb128: The issue is that the default GDM package looks for Human. Not a GNOME default. This will be something I hope we can change for +1 as I know what time we have left and your workload.
<_MMA_> Or actually, this wont be an issue in +1 because of new GDM. :)
<seb128> _MMA_: Ubuntu users who install gdm expect to get the ubuntu theming and not the GNOME one
<seb128> _MMA_: but right having a way to change the configuration by installation an another package would be nice
<_MMA_> seb128: Ubuntu users that dont have GDM installed are advanced users usually installing over top of a CLI system. The can handle installing the Human theme.
<seb128> _MMA_: or users who installed some (*)ubuntu and decide to try GNOME
<_MMA_> Sure. Having the Human theme installed the way the flavors do would be best, but this all might be besides the point.
<_MMA_> SInce things change in the new GDM.
<seb128> the issue is that the current gdm config doesn't allow to set priorities for the configuration to use
<seb128> so we just do "if extra config installed use that other use the gdm one"
<_MMA_> All the other *buntu's use GDM besides Kubuntu and then GDM would conflict with KDM right?
<seb128> which doesn't allow do no (*)ubuntu > ubuntu > default
<seb128> so we have to change default
<seb128> if we had a gdm custom config for ubuntu that would conflict with derivatives configs
<_MMA_> But all still pointless discussing since we have a solution now and things will change yet again in the next release. :) Go enjoy your Friday evening.
<seb128> right
<seb128> thanks, you too ;-)
<slangasek> GDM should not need to conflict with KDM
<tkamppeter> seb128, will do so
<YokoZar> slangasek: would adding some sort of code to wineserver (which translates signals into Windows exceptions) be helpful here?
<slangasek> YokoZar: no
<tkamppeter> slangasek, should I replace the OR dependency by a simple dependency on gsfonts then?
<_MMA_> slangasek: Sure. I was just askin'. But wouldn't their be a issue there? What would handle logon?
<_MMA_> If both were installed that is.
<slangasek> tkamppeter: I'm not sure; I haven't established that all of the fonts in ghostscript-fonts are also present in gsfonts, or if some of them originate elsewhere
<slangasek> _MMA_: there's a long-existing mechanism for deciding which one should be used, which has a debconf interface and a "sensible" default
<_MMA_> Ahh..
<ion_> tkamppeter: echo foo >foo; cupsfilter -m application/vnd.cups-postscript foo >/dev/null fails for me: texttopdf (PID 9462) crashed on signal 11
<ion_> tkamppeter: I have the 1.3.8-5 debs installed from the archive.
<BenC> mvo: checking on that bug
<BenC> mvo: No, that bug looks like either corrupted fs, or his /boot is read-only
<mvo> BenC: ok, thanks.
<BenC> mvo: the error is from dpkg itself, plus it's a hardy only upgrade (nothing about intrepid in there, so no last-good-boot around)
<ion_> tkamppeter: http://heh.fi/tmp/cups/strace.texttopdf
<slangasek> tkamppeter: ok, the fonts that aren't present in gsfonts are Dingbats and StandardSymL; for all others, the gsfonts version should be used
<mvo> BenC: oh, I overlooked that, thanks for clarifying
<warren> Can anybody reproduce this on firefox-3.0.1 on Ubuntu with flash-plugin-10.0.0.569?  (no nspluinwrapper)
<warren> https://bugzilla.redhat.com/show_bug.cgi?id=459297
<ubottu> bugzilla.redhat.com bug 459297 in firefox "Firefox crash during Flash 10 teardown" [Medium,New]
<soreiser> hi there, i would like to know why "all_generic_ide" is not working with hardy. i really need it to make my old pc working. thanks
<soreiser> i mean the kernel string parameter
<soreiser> it was working with 7.10 (i tried xubuntu) but it is not with ubuntu-server/ubuntu 8.04 :-/
<soreiser> please can anyone help me out to solve this?
<LaserJock> soreiser: have you looked for open bugs about it?
<soreiser> LaserJock i've made a bug-report by myself but i'm not so expert so i was not sure it is a bug. is it really a bug, then?
<LaserJock> I really have no idea
<LaserJock> but in general it safer to report a bug than to not
<soreiser> is there anyone here could i ask for this?
<LaserJock> soreiser: you might also ask  #ubuntu-kernel
<soreiser> LaserJoke ok i go there and i try to ask
<soreiser> thanks for support, i didn't know about that channel :)
<kirkland> slangasek: saw the grub patch applied \o/  thanks!
<LaserJock> "LaserJoke" heh, that's a new one
<emgent> hahah
<emgent> heya kirkland !
<kirkland> emgent: hiya
<kirkland> emgent: cool video on Italy, btw, i enjoyed it
<emgent> I was in Genova this day
<emgent> italian police == mafia.
<kirkland> emgent: i suppose "enjoyed" isnt the right word
<kirkland> emgent: "informative"
<tkamppeter> ion_, bug forwarded to the upstream author, thanks for reporting.
#ubuntu-devel 2008-08-16
<NCommander> there is something awesome about ordering pizza via the internet
<Lightkey> are you high on WoW?
<realist> NCommander: there is something annoying about all pizza websites in the country requiring flash
<saivann> I just filed bug 258486 under jockey, but this might be issue with the LiveCD environment, can a ubuntu dev take a look at it?
<ubottu> Launchpad bug 258486 in jockey "X fall in failsafe mode after install if nvidia restricted drivers are installed during LiveCD session in intrepid" [Undecided,New] https://launchpad.net/bugs/258486
<ion_> tkamppeter: Should the CourierâFreeFont patch be applied until a fix for that exists?
<echo6> when I compile my own custom kernel /lib/firmware is not populated with the directory pertaining to the new kernel, what is the correct Ubuntu way to handle this?
<echo6> I'm using the old compile method, fakeroot make-kpkg --initrd --append-to-version=-some-string-here kernel-image kernel-headers
<cameronh> Why is there no libboost-system-dev package, only a libboost-system1.35-dev, whereas all the other modules have a libboost-{name}-dev package?
<petr4> Hello. Is it possible for bash script to detect if it is running on WUBI installed system?
<TheMuso> petr4: I wouldn't think it could be done reliably no, unless wubi was to leave some obvious signs on the host filesystem.
<petr4> TheMuso: what about output of "mount"?
<TheMuso> petr4: Anything can be mounted via ntfs-3g on /host, and happen to have a windows dir/filesystem layout.
<TheMuso> IMO thats not convincing enough.
<petr4> TheMuso: I thought that  / is mounted to file image in host filesystem
<TheMuso> petr4: Yes it is, but the host filesystem is mounted on /host.
<TheMuso> petr4: Anything can be image mounted, and claim to be named the same as a wubi image. I personally would never try to rely on the contents of mount or a filesystem layout.
<petr4> testing if /host is fat/ntfs and / is file image in /host sounds good enough to me
<petr4> TheMuso: the test is doomed to be approximate anyway
<TheMuso> petr4: Its up to you, but if the script is to be publically available/distributed, I don't personally think thats reliable enough.
<petr4> after all the question "is this WUBI" does not make sense. Question "does this system has feature XY?" would make sense, but unfortunately we do not know what feature XY is needed
<NCommander> hola persia
<hwilde> how come sometimes I try to join it says I am banned, sometimes it works ?
<nxvl> Hobbsee: around?
<nxvl> Hobbsee: i'm having some problems with buildd
<gui> hello all
<gui> not directly a development question, but i want to know where are stored X11 full configuration on ubuntu live-dvd ? (/etc/X11/xorg.conf doesn't contain all values)
<slangasek> gui: that is the full configuration; recent versions of X don't require explicit configuration for most settings.
<gui> slangasek: ok thanks
<IntuitiveNipple> Is there a quick way to update the po translations in a source package? The package has a template but the po files haven't been updated in several versions.
<doggymenz> Why does Ubuntu use its own custom usplash instead of bootsplash?
<sally_> I installed hardy over the network, but didn't select any of the desktops when it asked what I wanted to install besides the base system.  So I have just a base console system.  What package do I need to install so that I get everything that would have been installed if I had picked "Gnome Desktop" during the installation process?
<Mirv> sally_: ubuntu-desktop would be the package. please ask further questions on the plain #ubuntu channel, since this is for Ubuntu development
<sally_> Mirv: ok thanks, I asked in there first and no one knew
<emgent`> hello
#ubuntu-devel 2008-08-17
<ion_> tkamppeter: I finally got around to posting the CUPS patches to upstream: http://www.cups.org/str.php?L2908 and http://www.cups.org/str.php?L2909
<ubottu> CUPS bug 2908 in Core CUPS Software "cupsfilter PATH typo: filters do not have /bin in their PATH" [Priority moderate,New]
<emgent`> moin
 * emgent` hugs devfil_ 
<devfil_> hi emgent` :)
<echo6> /window1/window 2
<Sianis_> hi
<Sianis_> have somebody 8.10 and 2 minutes? :)
<Sianis_> I need a list from packages of Ubuntu
<Sianis_> only 4 command, can somebody help me?
<Hobbsee> Sianis_: this is not a support channel.
<Sianis_> this isn't support :) l10n and ddtp
<emgent> evening
<quadrispro> anyone's working on bug #257215?
<ubottu> Launchpad bug 257215 in fop "Please add dependency on ant-optional" [Undecided,Incomplete] https://launchpad.net/bugs/257215
<superm1> wha??? nixternal leaving us?
<superm1> was this some bad joke from planet?
<emgent> uhm?
<emgent> superm1: link ?
<superm1> whoops, that was meant for #ubuntu-chicago, but yeah let me grab a link
<superm1> http://admiralchicago.wordpress.com/2008/08/17/chicago-will-mourn/
<jpds> superm1: Talk about short-notice :p
<nixternal> superm1: that was a joke to try and get a couple of the Ubuntu Chicago guys out to barcamp...I didn't think he would blog about it
<nixternal> hahahahahaha
<genius> I want to learn programing I'm considering learning Python, I would like do develop apps for both Windows and Linux, would that be a good place to start??
<genius> does anyone have an opinion??
<pwnguin> well, this is more about the development *of* Ubuntu, but python is sufficiently cross platform
<genius> My question though is python a good place to start to learn programing or Maybe JAVA?
<cpufreak> you are asking your question in the wrong fora though. :)
<genius> And I do understand the topic but what better place to ask that question than here?
<genius> ok what forum should I ask it in?
<genius> ??
<pwnguin> (we dont have one =( )
<pwnguin> presumably -offtopic
<pwnguin> #ubuntu-offtopic
<genius> ok thanks
<genius> I will try there, have a great day
<fole> hi, can someone let me know what I should do after I uploaded a patch in launchpad?
<mouz> fole: https://wiki.ubuntu.com/SponsorshipProcess describes it
<fole> thanks
#ubuntu-devel 2009-08-10
<ebroder> Can somebody give me a hand triaging bug #330766? It should be marked as Fix Released for Karmic, but New for Jaunty
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<tripzeroooo> anyone have experience with getting pulseaudio to work from a debbootstrapped livecd?
<ebroder> Anybody around who could milestone bug #330766 for me? It should be marked as Fix Released in Karmic and Confirmed in Jaunty
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Undecided,Confirmed] https://launchpad.net/bugs/330766
<dtchen> no, it should be Triaged for Jaunty
<ebroder> Oh, right - sorry
<ebroder> I always get those mixed up for some reason
<maco> ebroder: id guess something to do with how some wiki pages said (say?) confirmed means enough data for a dev to start working
<ebroder> Yeah, I know what they mean, I just keep trying to mark bugs as Confirmed for some reason
<ebroder> Thanks, dtchen
<dholbach> good morning
<twb> packages.ubuntu.com:80 won't respond to me.  Is this a known issue, and if so is there an ETA on resolution?
 * wgrant wonders why people use packages.ubuntu.com rather than Launchpad.
<wgrant> Apart from file search.
<ebroder> wgrant: It's harder to get some forms of information directly from Launchpad
<twb> wgrant: because I hate launchpad.
<wgrant> ebroder: Like?
<ebroder> Especially if you don't know the source package off the top of your head
<wgrant> twb: Why?
<twb> Because it looks awful in w3m.
<ebroder> launchpad.net/ubuntu/+source/SOURCE is amazingly helpful, but there's no equivalent of that page if you only know a binary package name
<wgrant> ebroder: try the search box on /ubuntu.
<wgrant> That searches binary names./
<wgrant> See also launchpad.net/ubuntu/karmic/+package/BINARY
<ebroder> That's one more high-latency round-trip to get the information I want
<ebroder> I actually find launchpad.net/ubuntu/karmic/+package/BINARY to be even more useless, because it takes me 3-4 round-trips to get back the the actual useful source information page
<ebroder> Whereas if I was using packages.ubuntu.com, the information I care about shows up on the first page load
<twb> The other obvious problem is that it means I need to use a different workflow for Ubuntu to what I use for Debian.
<wgrant> Have you filed bugs?
<ScottK> p.u.c is a lot faster than an LP page.
<wgrant> All this is being redesigned right now.
<twb> Where they're the same, I only need to remember one workflow.
<ebroder> wgrant: I only have time to work through so many bugs. LP bugs tend to be low on my priority queue
<ebroder> Ugh. How did the fix for bug #251242 actually make it through SRU review? Did it ever occur that people might have /intentionally/ turned kexec on, /and you just forcibly turned it off/?
<ubottu> Launchpad bug 251242 in kexec-tools "Always kexecs on shutdown/reboot" [Medium,Fix released] https://launchpad.net/bugs/251242
<ojwb> it also works the same as packages.d.o
<ScottK> ojwb: It's the same code base.
<ScottK> ebroder: There's a process for reporting bad SRUs.  It involves writing the tech board.
<ojwb> ScottK: yeah, I realise that
<ScottK> OK.
<ebroder> ScottK: Ugh. That sounds time consuming. Although right now I might be ticked enough
<ScottK> ebroder: If no one complains, nothing gets fixed.
<ojwb> but if you work with packages in both, it's much simpler to have a common UI
<ojwb> that was my poiny
<ebroder> ScottK: Point taken. I was just going to rant on the bug
<ojwb> point
 * wgrant points out that LP works for Debian too.
<wgrant> Largely.
<ScottK> wgrant: So I can wait longer for Debian stuff too?
 * ScottK would like it if Ubuntu's rmadison service were as fast as Debian's.
<wgrant> ScottK: I find Launchpad's distribution source package view to be significantly more useful than packages.qa.d.o.
<wgrant> And I too find Ubuntu rmadison to be horrifyingly slow.
<ebroder> ScottK: Re-reading the SRU policy, I'm not actually sure there's a useful followup change to make, since the SRU scribbled over user settings
<ebroder> I may still write up a complaint, though
 * wgrant relocates.
<ScottK> I generally find p.qa.d.o to be within one click of whatever I want and to get there quickly.  While I agree there's more generally useful information on the LP page, it's harder to get to other stuff.
<ScottK> ebroder: If it scribbled over user settings you should.
<ebroder> Hmm...actually, I wonder if you can use the seen flag in debconf to recover...
<ScottK> ebroder: If if we can't directly fix it, the process needs the feedback.
<ebroder> Yeah, I agree. I'm filing a bug with my team that one of us should write it up "at some point"
<dholbach> wow... there's meeeellions of sponsoring items on here: http://people.canonical.com/~dholbach/sponsoring/
<dholbach> please let's all dive into it and reduce the number!
<LaserJock> dholbach: have you thought about separating out process bugs (mostly syncs and merges)
<dholbach> LaserJock: do you think that would help with anything? those bugs needs "sponsoring" too
<dholbach> also there's no reliable way to say if a bug is a sync or merge bug (AFAIK we don't require a tag or something, but rely on the bug title)
<LaserJock> dholbach: well, I thought maybe some people would focus on those to get rid of some low-hanging fruit
<LaserJock> bug title should be good enough, but it's not a big deal, it just struck me that they're sort of different classes of bugs
<dholbach> how would you like to see the "splitting out" on the page?
<dholbach> colours? different sections?
<LaserJock> sections I guess
<dholbach> I'll add it to my TODO list and see what I can do
<dholbach> but as I just got back and have thousands of emails in front of me, it might take a while :)
<LaserJock> like "Process Bugs" and something like "Code Bugs"
<LaserJock> of course, it'd be very much wishlist
<dholbach> you still have to review stuff and check if it works and take a look at the code
<dholbach> that's my only hesitation
<dholbach> I wouldn't want to give people the impression that they need to be less careful because it's not a "code bug"
<LaserJock> that is true
<dholbach> but organising it a bit differently on the page should probably be fine
<dholbach> I'll see what I can do
<LaserJock> seems like usually process bugs require less specific knowledge
<LaserJock> especially syncs
<ebroder> Any backporters who can ACK bug #216761?
<ubottu> Launchpad bug 216761 in xen-3.3 "[hardy-backports] errors in xendomains init script" [Undecided,Fix released] https://launchpad.net/bugs/216761
<nikolam> hi.
<nikolam> What could be done that packages.ubuntu.com don`t die that often?
<cjwatson> nikolam: it's not maintained by anyone here; try #canonical-sysadmin
<nikolam> 10x cjwatson :)
<liw> hrmph, synergy and kvm don't play well together
<soren> What's synergy?
<soren> Oh, it's like x2x.
<liw> possibly it's kvm and kvm not playing well together (one kvm is the software, one is the device for sharing keyboard and mouse between machines)
<liw> (and then synergy allows me to not use the hardware kvm all the time, just for bios)
<liw> the symptom is that the mouse in the kvm guest gets stuck in the lower right korner
<liw> (kvm host is jaunty)
<liw> is there a way to tell apt that a package should be marked as autoremove?
<soren> liw: apt-mark
<soren> liw: sudo apt-mark markauto <packagename>
<liw> soren, thanks
<liw> (synaptic seems to be able to do that, too)
<soren> :)
<soren> np
<ogra> seb128, since yesterdays upgrade my evo only shows a blank window, any idea whats up with that ?
<ogra> no UI elements at all
<ogra> but also not marked unresponsive by compiz
<seb128> ogra, no, there was an update yesterday? people were traveling, weird
<ogra> seb128, well, i didnt upgrade since wed. or so
<ogra> *i* upgraded yesterday :)
<seb128> dunno, works here and we got no bug about that
<seb128> maybe it's another of those cases were it rebuilds the index and takes a while
<seb128> ie let it 15 minutes and see if it comes back
<ogra> ok
<ogra> no disk activity though
<seb128> does anybody knows if "advocated" on REVU means "uploaded"?
<cjwatson> could somebody review partman-iscsi in source NEW for me please?
<cjwatson> I have an alpha-4 spec blocked on that
<seb128> cjwatson, looking
<cjwatson> thanks
<cjwatson> hmm, and I'd better start writing the MIR too :-/
<seb128> cjwatson, looks good, accepted
<ogra> seb128, i think advocated means only read to upload
<ogra> there is no actual indication for "uploaded" afaik
<seb128> ogra, who does upload?
<ogra> sponsors ?
<ogra> i usually do an upload for people that cant if i'm the last reviewer that advocates
<seb128> are those automatically listed on the sponsor queue?
<ogra> but afaik there is no rule that enforces it
<seb128> ok
<seb128> I just don't know the workflow there
<cjwatson> seb128: great, thanks!
<seb128> you're welcome
<ogra> seb128, will kill evo now, no change
<cjwatson> seb128: ... and binaries (partman-iscsi)
<ogra> ah, on restart it pops up a keyring question
<cjwatson> sorry, in a rush :)
<ogra> and UI is back
<ogra> was probably hung in accessing the keyring ... i'll keep an eye on that
<seb128> cjwatson, accepted
<seb128> ogra, ok
<cjwatson> seb128: cheers
<soren> Can anyone think of any ill effects caused by not having a hostname set before dhcp is run? It would be rather nice if EC2 instances accepted the hostname given to them by EC2, and the easiest way to do that is to not have an /etc/hostname in the image, which causes dhclient (actually dhclient-script) to set it to whatever the dhcp server suggests.
<soren> Alternatively, I can keep it set to the current "ubuntu" until the ec2-init thing runs and set it based on what's in the EC2 meta-data service.
<soren> So I guess the question is: Which will cause most headache: Not having a hostname set until dhcp runs, or having one set and then changing it half way through the boot process?
<liw> syslog wants to know the hostname, at least
<ogra> doesnt gethostbyname() peoperly return "(none)" if the file doesnt exists ?
<soren> ogra: Yes.
<ogra> liw, even with rsyslogd now ?
<liw> but syslog should work even if there is not hostname, or if it changes (not doing so is a bug, imho)
<ogra> i thought that should fix such probs
<liw> ogra, I'm talking about the abstract service, not the specific implementation
<cjwatson> soren: don't suppose you know this axis2 thing that eucalyptus uses?
<ogra> syslog used to use the ip if it couldnt find a hostname in the past
<soren> cjwatson: For some values of, yes.
<cjwatson> soren: I'm trying to figure out where to hook in to make it publish an avahi service on startup - is it axis2_svc_skel_EucalyptusCC_create or axis2_svc_skel_EucalyptusCC_init or somewhere else?
<soren> cjwatson: I've got an update for it pending. They fixed a whole bunch of the problems I had with it, but not all. Some of it, they just broke in new and interesting ways, so it's a bit tricky.
<cjwatson> I think I need to know the port number
<soren> cjwatson: Oh.
<soren> cjwatson: I don't know about that. I thought you were just going to use something like avahi-publish :)
<cjwatson> well, I could, but you're only supposed to publish the service for as long as the service is actually running
<cjwatson> so while avahi-publish is a viable fallback, it would be better to use the C avahi-client interface
<soren> Right. upstart would be helpful there.
<soren> Sure, sure.
<cjwatson> I was just going to add an --enable-avahi configure option so that it doesn't become a mandatory source dep
<mat_t> cjwatson: morning
<mat_t> cjwatson: are we currently planning (is it possible) to hide text messages that appear during shutdown/logout?
<cjwatson> which messages exactly?
<mat_t> cjwatson: the console messages that appear for brief moment
<directhex> mat_t, you mean before usplash is started?
<mat_t> directhex: precisely (in the shutdown/restart case)
<directhex> a bigger question is "does shutdown still take 2 minutes if you have a cifs mount in /etc/fstab?" - i meant to work on that at UDS, but other things got in the way
<cjwatson> mat_t: not sure, they're certainly bugs; some of the work to make boot smoother might help shutdown too as a side-effect
<ogra> can i get an archive admin to look at linux-fsl-imx51 in source NEW ?
<ogra> preferably someone who knoes what d-i expects from the naming scheme ?
<ogra> *knows
<mat_t> cjwatson: I see, so they should not appear when the bugs are fixed
<lool> cjwatson: This is the new control file http://paste.ubuntu.com/250765/
<lool> amitk: Any reason why the new linux-image are named -babbage instead of -mx51?
<lool> amitk: I was hoping for Lange 5.1/5.2 compat, and perhaps other devices
<ogra> lool, i guess lange will need extra binary packages
<lool> ogra: Which means multiple passes
<ogra> lool, i rather doubt the choice of -fsl- in the source
<lool> I raised this already; I don't really care about the source package name though
<ogra> you likely need multiple passes to apply the patches at buildtime
<lool> It's just weird to have it in half of the binary packages
<ogra> they might break babbage binaries
<lool> ogra: I don't see a good reason for maintaining two imx51 trees
<lool> Or linux-images
<ogra> well, all lange patches i saw yet apply on top of the babbage patches
<lool> Yes, that's my point
<ogra> but might change babbage drivers
<ogra> which would make them not work on babbage anymore
<lool> ogra: Might or do?
<ogra> might
<lool> That's very hypothetical because they dont so far
<lool> FSL is releasing a single linux binary for multiple mx51 boards; I think we should do the same
<ogra> right, but only fo babbage
<lool> No,for multiple boards
<ogra> fsl isnt releasing lange binaries to my knowledge
<lool> That is 3stack and babbage 1, 2, and 2.5
<ogra> right
<lool> I don't see why we wouldn't do the same for other mx51 hardware such as langes
<ogra> because of what i said above :)
<lool> It's not like the patch stack for lange was huge so far
<lool> ogra: This is hypothetical
<ogra> you dont know if the patches will touch driver code
<lool> And has no reason of happening
<ogra> heh, there is so much things that have no reason of happening :) but happen anyway .... imho it would be good to be prepared for them still
<ogra> though indeed an -imx51 binary could just grow a -imx51-lange suffix or something if thats actually needed
<lool> I still believe we want a single kernel image for everything mx51 and I'm also worried about jaunty upgrades
<ogra> upgrades only get painful if the meta packagename changes
<ogra> hmm, which it does apparently, looking at the config
<ogra> at least according to the description
<cjwatson> lool: that's technically OK for d-i
<lool> k thanks
<cjwatson> lool: though it's not clear from the control file alone what the udebs will look like
<lool> cjwatson: Not sure whether you're tempted to NEW that
<cjwatson> I'm assuming that they will follow the usual naming scheme since it'd take special effort for them not to
<damo22> can someone help me, i installed dbus and hal from a GIT repository and it broke my system, how do i force a reinstall the ubuntu dbus and hal?
<lool> I have some objections but nothing which we can't live with for A4
<lool> damo22: Look for reinstall in the apt-get man page; please move your questions to #ubutnu
<lool> #ubuntu sorry
<cjwatson> lool: the d-i part of it is fine; if you're happy with the rest of it then go ahead
<lool> cjwatson: I'm happy with the rest for A4
<lool> It's no good for upgrades and IMO we don't want per board spins but it can't be fixed for A4 and we want an image
<lool> cjwatson: thanks!
<amitk> lool: there is no guarantee that lange 5.x, 3stack and babbage will work from a single binary. Is there written evidence of that (guarantee) from freescale?
<sladen> cjwatson: mvo: what's the equivalent of apt-mark to *list* a packages autoremove status?
<sladen> cjwatson: apt-mark only appears to allow changing, not observing
<soren> I have an upstream project that consists of a bunch of python scripts. I'm using distutils to install it (it sets the scripts kwarg to a list of all the scripts). When I put this into a .deb, I want the .py extensions to be stripped (as the scripts will be in /usr/bin).
<soren> Is there a magic rune to pass to disutils to make it do that?
<soren> Or should I rename them post-install from debian/rules?
<sladen> grep -A1 packagename /var/lib/apt/extended_states...
<sladen> soren: post-install specifcally the binaries you want included in /usr/bin since then you keep control over what goes where
<soren> sladen: I want all of them in usr/bin. I happen to be upstream, so the project is (reasonably) well-behaved in the respect :)
<sladen> soren: or a find debian/tmp/usr/bin -name \*.py | awk ... | xargs mv
<lool> amitk: Do you have reasons to believe they wont?  FSL releasing a single image for all mx51 kernels is a good indication that it's possible for 3stack and babbage
<lool> amitk: I also asked FSL explicitely about this and while they couldn't commit for the Lange boards obviously, they did say they saw no reason it couldn't be done
<lool> s/all mx51 kernels/all FSL mx51 boards
<cjwatson> sladen: I know of no such interface, although apt-mark is just a python-apt script and it looks like it'd be trivial to add
<cjwatson> sladen: or /var/lib/apt/extended_states is pretty much human-readable and you could even use grep-dctrl
<cjwatson> $ grep-dctrl -nsAuto-Installed -PX libc6-dev /var/lib/apt/extended_states
<cjwatson> 1
<cjwatson> though no idea if the format is guaranteed
<sladen> yeah, just filed  bug #411369
<ubottu> Launchpad bug 411369 in apt "apt-mark should allow listing of autoremove status" [Undecided,New] https://launchpad.net/bugs/411369
<gp_will_be_back> can some body pl  tell me why ubuntu default theme is god damn ugly
<sladen> gp_will_be_back: Perhaps you could file a bug with some suggestions for improvements
<gp_will_be_back> on lauch pad ?
<sladen> gp_will_be_back: https://bugs.launchpad.net/ubuntu/+source/human-theme/+filebug
<liw> gp_will_be_back, it would, however, be more productive to be polite
<gp_will_be_back> oks
<gp_will_be_back> filed a bug report
<ogra> gp_will_be_back, you filed bug 411374 ? where are the suggestions for improvements ?
<ubottu> Launchpad bug 411374 in human-theme "Human theme is ugly , outaded , icons/theme sucks " [Undecided,New] https://launchpad.net/bugs/411374
<cjwatson> mat_t: FYI, I've managed to get grub to come up in graphics mode and transition smoothly to the kernel without a mode switch, but unfortunately there are some technical difficulties that mean that if anything goes wrong in early boot you'll just be left with a completely blank screen, so I don't plan to turn this on as yet. See https://lists.ubuntu.com/archives/kernel-team/2009-August/006773.html for the gory details
<gp_will_be_back> i am trying to build ubuntu based koisk based on xul runner  ....should boot less that 5 to 10 secs ...what wm i should use ... i need minimum enviorment where firefox can show full screen ?
<gp_will_be_back> bug 411374 ->> .please use better anti aliased fonts and icons .....please try to follow apple's HIG ...
<ubottu> Launchpad bug 411374 in human-theme "Human theme is ugly , outaded , icons/theme sucks " [Undecided,New] https://launchpad.net/bugs/411374
<sladen> gp_will_be_back: that's an interesting project, but sounds rather more like a question... please could you write it up at  https://answers.launchpad.net/ubuntu/+addquestion  with a few more details to help those who might answer it
<cjwatson> the existing bug could be converted to a question
<cjwatson> anything including "sucks" is unlikely to be a valid, fixable bug
<sladen> gp_will_be_back: (the second link is for your kiosk query)
<cjwatson> oh, right
<gp_will_be_back> thanks
<sladen> gp_will_be_back: but yes, for bug #411374, can you try to include some exact details.  For instance, here's a UI themeing issue I filed recently, including an annotated screenshot highlighting the issue  bug #404955
<ubottu> Launchpad bug 411374 in human-theme "Human theme is ugly , outaded , icons/theme sucks " [Undecided,New] https://launchpad.net/bugs/411374
<ubottu> Launchpad bug 404955 in firefox-3.0 "Search and URL box heights off-by-one" [Undecided,Incomplete] https://launchpad.net/bugs/404955
<sladen> gp_will_be_back: if you can include that level of detail, it should be easy to fix whatever has caught your eye
<amitk> lool: fsl might, their ODMs might not. And Lange code comes from the ODMs
<gp_will_be_back> sladen: its general suggestion , i cant say that current theme is bug .....................but its just a feedback .....and easy to fix by downlaoding a using a new theme
<sladen> gp_will_be_back: you should be able to select a different theme for your computer by System->Preferences->Appearance .  Or if you'd like more, by visiting http://art.gnome.org/themes .  If you find one that you think would benefit the millions of Ubuntu users, you should mention exactly which one, and why you like it and think it would be benefical
<mat_t> cjwatson: great, thanks!
<gp_will_be_back> sladen: i think best is conduct a pole among users (not developers ) so that they can  vote fav theme
<gp_will_be_back> btw i heard connaical hired some UI folks ...i think they should put hiim to work ;-)
<sladen> gp_will_be_back: then you should list (exactly) which themes should be on the pole, and where the poll would be held to attract the maximum feedback
<sladen> gp_will_be_back: I'd like world peace too, but it's a very general wish---and do get there I need to be more specific with my desires, and cut the problem up into tiny, describle pieces
<cjwatson> gp_will_be_back: if you want people to pay attention, my advice to you would be to avoid implying that they are lazy slackers
<cjwatson> I don't find that to be generally a productive attitude to take
 * ogra points out that there is no new artwork at all yet in karmic, https://wiki.ubuntu.com/KarmicReleaseSchedule will show that the first drop only lands on august 27th
<gp_will_be_back> sladen : can ubuntu copy look and feel from apple ? is it legal with few modication
<ogra> s/wil show/does show/
<gp_will_be_back> copy (inspired) and extend
<sladen> gp_will_be_back: the secret with Free Software is not just to copy;  but to fork, experiment, tweak, try things out;  and then if they work, to offer the changes back for the benefit of everyone
<sladen> gp_will_be_back: the Human theme has survived surprisingly well---it is non-intrustive when starring at it for 90 hours a week and uses natural colours that the eye is used to dealing with (eg. not in-your-face).  Attempts at changing the theme slightly get made before every release, and sometimes they get rolled back because they didn't provide the percieved benefit
<gp_will_be_back> yeah its forced choice on users
<sladen> gp_will_be_back: nothing is forced;  there are other themes shipped;  there are other distributions available, and---as you've noted---there are other operating systems available (although not all of them focus on Freedom)
<gp_will_be_back> yeah true only the default configurations can be forced if user wants he can tweak himself
<sladen> yup, and with a Free (as in Freedom) operating system, such as Ubuntu, you have the Freedom to tweak anything because you have all of the source code, and the permissions to modify it.  I would encourage you to try and help out by making and testing changes (patches) that you think would help improve Ubuntu
<ogra> sladen, though telling people that the work they did up to now "sucks" and is "ugly" wont help much to make you get heard
<gp_will_be_back> please feel free to ignore this feedback , but since ubuntu tries to focus working out the box even for novice users ...i thought this may be use full ...i will try to compile list of themes which be alternative default theme on karmic kola
<cjwatson> soren: so looking through avahi I think what I actually want to do is to udebify avahi-core, which is the stack designed for embedding - I think that'd probably be better than importing hand-written mDNS code from elsewhere
<soren> cjwatson: Oh, sure.
<cjwatson> soren: avahi-core doesn't depend on d-bus or glib or anything funky like that
<cjwatson> and more to the point perhaps doesn't require an avahi daemon to be running ...
 * sladen blinks at ogra
<soren> cjwatson: To be honest, I only really pointed out that other thing to demonstrate that in terms of space, adding service discovery to the installer didn't have to be a big deal.
<soren> cjwatson: I'm glad avahi provides the stuff we need.
<ogra> sladen, i was referring to the bugtitle
<sladen> ogra: yeah, we can work on that.
<cjwatson> soren: it occurred to me after saying that that of course we only need to bring avahi up after network configuration and so it can be after downloading installer components - doesn't have to be initrd bloat
<cjwatson> which was what I was really afraid of
<sladen> gp_will_be_back: ogra and cjwatson have a very valid point;  can you try to find a word that isn't subjective and change the bug title (you can click the tiny yellow dot after the title to edit the subject line)
<ojwb> point
 * ojwb blinks
<rtg> slangasek, can you process linux-fsl-imx51 ?
<ogra> rtg, i think cjwatson was taking a look
<cjwatson> lool already did, I thought
<cjwatson> I just nodded in the direction of the d-i bits
<rtg> cjwatson, I couldn't find any status on it in Launchpad, https://launchpad.net/ubuntu/+source/linux-fsl-imx51
<cjwatson> lool: hmm, did you get distracted midway through, or did we misunderstand each other about who was processing it?
<ogra> cjwatson, i think you did, lool is no archive admin and he mentioned in the mobile channel you would do a review
<cjwatson> oh, hah, I forgot that
<cjwatson> done
 * ogra thought there was some PM going on else i would have asked again :)
<cjwatson> BTW is linux-fsl-imx51-libc-dev really necessary? I wouldn't expect any userspace package to use that
<rtg> cjwatson, I don't know, but I figured since the kernel sources were substantially different that it wouldn't hurt.
<cjwatson> I processed it anyway, but I'm a bit worried people might use it ;-)
<rtg> cjwatson, shall I remove it for the next upload? I'm sure thare will be one :)
<rtg> there*
<cjwatson> rtg: I think it'd be best, though no rush
<rtg> I'd best take care of it now lest I forget.
<lool> cjwatson: Sorry, I probably said something which lead you to think I'd process it; I'm no archive admin (albeit a surprising number of people assumed this today   :)
<ogra> heh
<cjwatson> no worries
<lool> amitk: I can understand that it's heavy to bit various patch stacks for differing SoCs into sanity, but I have a harder time understanding why we'd come to a similar amount of work with various boards from the same soc
<lool> *beat doh
<lool> My brain's not there
<ogra> jetlag, eh ? :)
<lool> Yeah it's the terrible climatic difference
<ogra> is france so hot and himid as well ?
<ogra> *humid
<lool> Yeah
 * ogra felt like being struck by a hammer when leaving the plane
<Ng> --help
<slytherin> Can someone please give back nautilus-sendto on powerpc?
<seb128> slytherin, are the powerpc builds fixed now?
<ogra> ftbfs list looks like it
<slytherin> seb128: yes they are. And this one looks like a transitional error (-dev package present, but not the corresponding version of the library).
<seb128> right but no point to rebuild if that's going to fail on the libc errors
<cjwatson> libc was fixed
<seb128> tried a rebuild let's see if those are really fixed
<cjwatson> well, worked around
<slytherin> libc is fixed.
<Laney> how often do failed builds get automatically given back
<Laney> ?
<Laney> I don't fancy manually supervising ghc6 transition on ppc
<Laney> . o O ( edos-debcheck integration would make this super slick )
<superm1> cjwatson, ping. i notice in karmic we've got germinate 1.17, but for 1.3 in debian you submitted a patch to adjust the behavior of following recommends if an extra clause is added to a seed or structure.  since this is already in platform.karmic, what are the effects of running an older version of germinate that doesn't support it?
<Hobbsee> Laney: ftbfs ones?  every once in a blue moon
<Laney> Hobbsee: seems like the ppc ones are being done more often, from the mails i'm getting
<Hobbsee> Laney: sometimes a whole stack get given back on an arch, but it's from someone triggering it, rather than LP being automatic
<Hobbsee> Laney: unless it's chroot wait
<Laney> Then my question is whether this is going to continue to happen for ppc
<cjwatson> superm1: the effect will be that Recommends are silently skipped
<Hobbsee> i don't have the powers to do mass automated builds, and don't know
<tkamppeter> seb128, it is about Poppler 0.11.2
<cjwatson> Laney: is it just that the builds need to be retried in the right order or something?
<Laney> cjwatson: right
<seb128> tkamppeter, hi
<tkamppeter> You have uploaded it and you have removed an important fix which I have applied.
<cjwatson> Laney: will they misbuild if they happen in the wrong order?
<Laney> cjwatson: they should just fail
<Laney> due to uninstallable build-deps
<superm1> cjwatson, so the machine that normally runs the builds of the livefs, does it have an updated germinate already, or will it be getting one before karmic is released?
<cjwatson> superm1: karmic livefs images are built inside a karmic chroot
<cjwatson> i.e. the livefs itself is constructed as chroot-within-chroot
<cjwatson> superm1: IOW yes
<cjwatson> Laney: how many times would it require throwing them all against the wall until they stick, do you think? :)
<seb128> tkamppeter, which one?
<superm1> cjwatson, ah okay, just a matter of time until it's pulled in then from debian
<tkamppeter> seb128, I have done 0.11.0-0ubunu2, 0ubuntu3, and 0ubuntu4, the latter 2 are three patches which are accepted upstream, but 0ubuntu2 is a packaging fix which you have reverted with 0.11.2. I need it to build CUPS  ASAP for Alpha4.
<cjwatson> superm1: one of us is confused
<cjwatson> superm1: 1.3 was last year, it's been in the livefs build chroots for several release cycles
<superm1> cjwatson, oh... so what i'm mixing up is 1.17 > 1.3.  yeah i was reading that as 1.03, my mistake
<cjwatson> 1.17 > 1.03 too :-)
<seb128> tkamppeter, I'm looking at that now
<tkamppeter> seb128, your changelog looks like that you have based your 0.11.2 upload on your 0.11.0-0ubuntu1 upload and not on the newest version from the archives.
<cjwatson> yeah, Debian and Ubuntu have the same version of germinate; I usually just upload it to both for simplicity
<superm1> cjwatson, okay that makes much more sense
<seb128> tkamppeter, right I didn't notice that somebody did changes to poppler while I was working on it
<seb128> tkamppeter, fixing that now
<superm1> cjwatson, okay so then the next question is, how would i explicitly stop the recommends from coming in for only a particular set of packages?
<cjwatson> superm1: as far as germinate is concerned, you'd need to put them in a separate seed that doesn't have follow-recommends set
<cjwatson> superm1: BUT
<cjwatson> superm1: thinking about this in terms of seeds is wrong
<cjwatson> superm1: the reason I added this feature in germinate was purely and simply to track apt's behaviour
<cjwatson> superm1: and you can't make apt do different things for different seeds - it doesn't know about them
<cjwatson> superm1: you need to find a different approach, where the correct behaviour is actually in the packages
<cjwatson> superm1: while you might be able to make something work in seeds alone, it'll be fragile and you'll probably regret it later - it'll behave differently for different installation methods, etc.
<superm1> cjwatson, i see.  particularly because you would have a different result from a built livefs, versus an alternate image, versus installing a meta or task from a debootstrapped env
<cjwatson> right
<cjwatson> livefs builds don't set any apt options, so they'll follow recommends for everything outside debootstrap
<cjwatson> we do support " * Feature: no-follow-recommends" in seeds, but that's only supposed to be for the required seed, because debootstrap doesn't follow Recommends
<superm1> ah
<superm1> cjwatson, well then maybe you can advise what the best approach to fix the problem i'm hitting then.  mythbuntu-desktop is pulling in gdm, which recommends gnome-settings-daemon which recommends pulseaudio.  gdm recommends either gnome-settings-daemon or xfconf, but for some reason *both* gnome-settings-daemon and xfconf get pulled in
<cjwatson> have you already tried explicitly seeding xfconf?
<superm1> that's what i'm currently trying right now
<superm1> i just uploaded a new meta to the archive with that change
<cjwatson> that ought to work - if it doesn't, I think it's a germinate bug
<cjwatson> shouldn't even need a meta, just seeding it ought to be enough
<seb128> tkamppeter, uploaded a fixed version now
<cjwatson> germinate is supposed to scan everything that's explicitly seeded before trying to resolve dependencies
<superm1> well until bug 409578 gets released, i dont think i can fully trust results anyway though
<ubottu> Launchpad bug 409578 in soyuz "multiverse packages needed in task headers" [High,Fix committed] https://launchpad.net/bugs/409578
<superm1> (at least with the tasks)
<tkamppeter> seb128, thank you.
<cjwatson> mm, but xfconf isn't in multiverse; you should at least be able to test-run it
<seb128> tkamppeter, no problem, sorry for dropping your changes
<seb128> tkamppeter, do you have details on the poppler abi change btw?
<superm1> oh right it's not.
<superm1> then i'll give it a run with that change with it explicitly seeded and see if that's any better
<tkamppeter> No, only thing is that Koji Otani, author of pdftopdf, told me that a changeless rebuild of CUPS fixed bug 409962
<ubottu> Launchpad bug 409962 in cups "poppler 0.11.2 produces blank pages with cups" [High,Triaged] https://launchpad.net/bugs/409962
<tkamppeter> seb128: ^^^
<cjwatson> superm1: it's independently weird that both get pulled in, but perhaps there's some other dependency/recommendation on xfconf elsewhere
<cjwatson> superm1: germinate will normally just pick the first one, assuming that it's satisfiable
<seb128> tkamppeter, ok thanks
<cjwatson> so it probably goes "gdm needs gnome-settings-daemon or xfconf, ok, gnome-settings-daemon works so I'll use that. oh, xffoo needs xfconf, so I'll use that." it doesn't know how to backtrack and optimise
<Laney> cjwatson: (sorry, got a phone call). From http://cs.nott.ac.uk/~ial/graph.pdf (ignore the colours, they are about i386) it looks to be 7 or 8 rounds to get up to speed
<superm1> cjwatson, yeah i think that's the scenario
<Laney> but a lot of those are probably done
<superm1> cjwatson, since xfce4 does depend on xfconf
<superm1> what really throws me off is that xubuntu's builds work out fine without needing to explicitly seed xfconf
<cjwatson> Laney: hmm, that's useful. Do you have the input file for that graph? I could cross-reference it against the out-of-date list for powerpc
<cjwatson> superm1: I imagine that they happen to pull in xfconf somewhere before having to resolve gdm dependencies
<cjwatson> superm1: the germinate output log probably includes a note about it
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/mythbuntu.karmic/_germinate_output says "* Chose gnome-settings-daemon to satisfy gdm"
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.karmic/_germinate_output has no "... to satisfy gdm" line
<cjwatson> which implies that the alternative recommendation was already satisfied somewhere by the time that germinate got to it
<tkamppeter> seb128, you have uploaded the new Poppler as 0.11.2-0ubuntu2?
<seb128> tkamppeter, yes
<Laney> cjwatson: It's pretty much grep-dctrl -FDepends -r ghc6 (but generated by a hacky script instead)
<tkamppeter> seb128, it does not appear in Launchpad
<seb128> tkamppeter, be patient, I got the accepted email it should be there soon
<superm1> cjwatson, yeah from what it looks the xubuntu seed defines xfwm4 much higher, which pulls in a few things that get xfconf in the mix, and gdm is near the bottom
<cjwatson> Laney: mm, I was hoping for one with the graph arcs already set so I don't have to redo that :-)
<Laney> oh, right
<cjwatson> don't you need build-depends anyway?
<Laney> runtime depends is what we need to check for the transition
<cjwatson> la la la. ok
 * Laney generates the dot
<Laney> cjwatson: http://cs.nott.ac.uk/~ial/graph.txt - is this what you're after?
<Laney> excuse the node names...
<cjwatson> Laney: that looks like it should be OK with a bit of postprocessing
<Laney> I pipe it through tred | unflatten to get the output to be somewhat nice
<cjwatson> while x="$(grep '^[0-9-].*label=' haskell-graph | head -n1 | sed 's/ \[label="/ /; s/".*//')" && [ "$x" ]; do id="${x%% *}"; name="${x#* }"; sed -i "s/$id/$name/g" haskell-graph; done
<cjwatson> (you may vomit)
<superm1> cjwatson, it would appear that the combination of explicitly seeding xfconf and referring to it later in the seed has done the trick.  thanks :)
<superm1> (referring to gdm later in the seed that is)
<tkamppeter> seb128, I have uploaded a new CUPS package now, to fix bug 409962
<ubottu> Launchpad bug 409962 in cups "poppler 0.11.2 produces blank pages with cups" [Critical,In progress] https://launchpad.net/bugs/409962
<seb128> tkamppeter, thanks
<cjwatson> superm1: cool
<cjwatson> Laney: I've retried haskell-pcre-light as a first step although I'm not convinced that its build failure was due to prior powerpc breakage
<cjwatson> but I guess we'll find out
<Laney> cjwatson: The failure will be due to uninstallable deps if it's transition related
<cjwatson> so not that
<Laney> bah the build log is gone now
<Laney> I guess I'll get the failure mail if it ftbfs again
<cjwatson> mm, sorry
<Laney> no matter
<cjwatson> Laney: oh boy, what's the ghc6/ia64 build failure about? that causes some knock-on weirdness
<cjwatson> cabal-bin: ghc version >=6.4 is required but the version of
<cjwatson> /build/buildd/ghc6-6.10.4/ghc/stage2-inplace/ghc could not be determined.
<Laney> not sure, kaol is looking into that on the Debian side
<Laney> probably won't be fixed for 6.10.4 though
 * directhex argues with meebey for a whopping 200k saving
<directhex> our mono packages are anorexic, but that doesn't mean we can't slice off the occasional finger for the benefit of the weighing scales
<Laney> beauty is happiness
 * cjwatson nukes libghc6-harp-dev on everything but ia64 to tidy up the outdate report
<cjwatson> retrying haskell-regex-base
<cjwatson> (that's everything down to row 5 on the graph)
<evand> big hugs to whomever got pixma support in sane working.
<cjwatson> Laney: there are only 29 left out of that set you gave me. I'm just going to throw them at the wall.
<Laney> That approach has probably got the majority of them built thus far, so sounds sane
<ogra> heh, package pong :)
<cjwatson> Laney: done. FYI that retried ftphs gtk2hs haskell-alut haskell-cgi haskell-configfile haskell-curl haskell-hgl haskell-hsh haskell-http haskell-irc haskell-network haskell-parsec haskell-quickcheck haskell-regex-compat haskell-regex-posix haskell-tagsoup haskell-vty haskell-x11-xft hdbc-odbc hdbc-postgresql hdbc-sqlite3 highlighting-kate hslogger kaya missingh pandoc washngo xmonad xmonad-contrib
<Laney> excellent. Thanks very much
<Laney> cjwatson: While you're in a haskell mood, could you process the removal of haskell-edison? bug 408569
<ubottu> Launchpad bug 408569 in haskell-edison "Remove haskell-edison from karmic" [Wishlist,Confirmed] https://launchpad.net/bugs/408569
<Laney> also there is some stuff in binary NEW but that can wait more
<bankix> Hi. I need some help with building packages and not breaking dependencies.
<bankix> I've done some changes to casper to build an own live cd.
<bankix> I could create a new, derived package (let's say: casper-1.173bankix1) with my changes, but when casper 1.174 is released, my package would be overwritten. Which I of course don't want to happen.
<bankix> So I renamed casper to seppel, and inserted "Provides: casper" into the control file. This will create a seppel package, which provides casper.
<bankix> If I understood right, I should be able to remove casper now and install seppel instead.
<bankix> But when I force-removed casper (to avoid removing all depending packages) and installed seppel, lupin-casper keeps telling me he's depending on casper >= 0.98, allthough seppel 1.173 is installed and providing casper.
<bankix> Where's my big mistake?
<bankix> I'm working with Ubuntu 9.04 as base.
<cjwatson> Laney: are the same binary names going to return?
<Laney> actually I don't know
<Laney> let me check
<bankix> To cut it short: How do I create a derived package, containing a patched version, and avoid that it will be overwritten next time the original package is updated, and keep all the depending packages happy?
<cjwatson> bankix: Provides can't satisfy versioned dependencies (e.g. "casper (>= 0.98)"); this is an extremely long-standing deficiency in the packaging system
<cjwatson> bankix: you'll have to create your own version of lupin-casper too
<Laney> cjwatson: yes, and more
<cjwatson> Laney: would it be possible to upload the split packages first, then?
<Laney> if that's easier
<bankix> cjwatson: Uh.
<cjwatson> Laney: that would save them from having to go through binary NEW, breaking builds in the meantime, etc.
<Laney> it will have to binary NEW anyway
<cjwatson> well, OK, but it will still be simpler :)
<Laney> but I see what you mean
<cjwatson> if they're just syncs, can you point me to the bugs in question?
<Laney> haven't requested them yet
<Laney> but haskell-edison-core, haskell-edison-api
<bankix> cjwatson: Is there perhaps a different approach I could follow?
<cjwatson> bankix: you might want to reexamine your comment that your package would be overwritten
<cjwatson> bankix: when we branch Ubuntu packages from Debian, we just add "ubuntu1" etc., we don't feel we have to rename all the packages ...
<cjwatson> bankix: you could use apt pinning (see apt_preferences(5)) to force apt to prefer the version of casper in your repository, perhaps?
<cjwatson> bankix: that might be easier
<bankix> Interesting point with adding "ubuntu1".
<bankix> Will a "bankix1" prevent apt from installing casper-2.0?
<cjwatson> bankix: of course, Ubuntu has its own archive, which makes things a bit different; we don't point apt at the Debian archive at all
<cjwatson> bankix: if your archive is just an overlay over ours, then apt pinning is probably the only approach that doesn't involve renaming
<cjwatson> bankix: no, the only technical effect of "ubuntu1" in our case is that it's a hint to the tools we use to autosync stuff from Debian
<cjwatson> it doesn't affect apt
<bankix> Okay, then my investigations regarding the suffixes were right.
<bankix> I'm not too familiar with pinning, but would a "casper-2.0" in the ubuntu repository not overwrite the installed "casper-1.174-bankix1" although the version 1.174 is the latest in my repository?
<cjwatson> bankix: overriding that is sort of the point of pinning.
<bankix> Thanks.
<bankix> I'll keep this in mind as alternative.
<cjwatson> by default, yes, apt will behave as you describe if you have both archives present in sources.list with no additional configuration.
<bankix> But due lupin-casper seems not to be reverenced by other packages, I'll try renaming it as well.
<cjwatson> but it might be reasonable to use pinning to force it always to prefer versions in your overlay archive if available.
<cjwatson> certainly what I'd do if I weren't doing a full-archive snapshot
<bankix> BTW: How do I find out which packages have dependencies to let's say casper? Maybe I overlooked an option of dpkg-query.
<cjwatson> bankix: you probably want the tools in the dctrl-tools package
<cjwatson> dpkg-query can't do it
<bankix> I'll have a look, thanks.
<cjwatson> (apt-cache rdepends can do it, but its output is sometimes confusing. dctrl-tools is IME more useful in practice.)
<cjwatson> could an archive admin process the new avahi binaries in the queue?
<seb128> cjwatson, looking
<cjwatson> I added two udebs
<Riddell> cjwatson: are you able to tell me what I've done wrong with the kubuntu seeds?  I moved desktop/netbook common packages into a kubuntu-common seed but now germinate moans with http://paste.ubuntu.com/250920/
<seb128> cjwatson, binaries accepted to main now (I guess you need those for the installer)
<cjwatson> seb128: ultimately, yeah - thanks
<cjwatson> seb128: (it's for eucalyptus which isn't yet in main)
<ttx> slangasek: bug 385475 is now fixed, you can drop that from alpha4 release notes
<cjwatson> Riddell: you forgot to put a line beginning with "kubuntu-common: " in STRUCTURE
<ubottu> Launchpad bug 385475 in likewise-open5 "[Karmic] Likewise-Open 5 fails to authenticate users" [High,Fix released] https://launchpad.net/bugs/385475
<cjwatson> Riddell: I assume it ought to depend on desktop-common
<Riddell> cjwatson: let me try
<bankix> cjwatson: Thanks a lot, worked fine. I just had to repack lupin-casper as well, now the package database is clean again.
<sladen> cjwatson: -mozilla are interested in LZMA .orig source uploads;  are they still disallowed by policy (they were the last time I checked with you)
<ogra> eeek
 * ogra begs to not switch all the world to lzma
 * ScottK thinks they are dissallowed by not implemented in soyuz
<ogra> we have enough probs on armel with KDE already
<cjwatson> sladen: yes.
<maco> ogra: does lzma not work on arm?
<ogra> maco, its very slow
<maco> well it's very cpu intensive
 * ogra points maco to http://qa.ubuntuwire.com/ftbfs/
<ScottK> ogra: Do we need a longer timeout still then (qt4-x11 is still dead)
<ogra> ... scroll down to "k"
<ogra> ScottK, it is at 300 minutes already
<ScottK> ogra: I think most of it would build if we could get Qt fixed.
<ogra> yeah
<jono> is anyone else having laggy OO.o problems? https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/411542
<ubottu> Launchpad bug 411542 in openoffice.org "OpenOffice.org 3.1 Impress Very Slow" [Undecided,New]
<ogra> NCommander, was supposed to care for that
<bankix> Ah, before I forget: Is there some sort of list which packages contain the ubuntu logos? Due to the trademark policy, I think I should better replace them.
<ScottK> Someone should get out their stick and poke him.
<jono> bankix, you should ask the Tech Board for that
<ogra> he did tons of local buulds but didnt do anything to the package yet
<bankix> jono: Hm, where do I reach them?
<ogra> ro to the builders
<ogra> *or
<ogra> ScottK, if the pointy end of my stick would know where to point to in the world i would do that :P no idea wheer he is atm
<cjwatson> err, I'm not sure why the TB is the right body to ask for a list of packages
<jono> bankix, https://wiki.ubuntu.com/TechnicalBoardAgenda
<bankix> Thanks.
<ScottK> Smart of him.
<cjwatson> jono: this doesn't need the TB surely
<jono> cjwatson, I mean, I would think the TB should provide a list
<cjwatson> why?
<cjwatson> why should it be the TB *first*?
<jono> cjwatson, who would you suggest to do it?
<cjwatson> I'm all for one being provided, and I'm all for us doing more with the TB, but it was never a body of *first* resort!
<ogra> cjwatson, because then jono doesnt have to :)
<cjwatson> ask on ubuntu-devel?
<jono> I think that trademarks in Ubuntu is generally seen over by the TB, and it could be useful for the TB to maintain a list of packages based around Trademarks
<jono> cjwatson, fine, I don't either way who does it :)
 * ogra finds that a tricky statement, in the end the trademark is owned by canonical, not by the TB
<jono> ogra, good point
<jono> so maybe trademarks@ubuntu.com could be another option
<ogra> definately
<ogra> that should be the first address
<bankix> Hmmm, that adress was mentioned for questions obtaining a license or permission.
<Riddell> cjwatson: no, that doesn't work (with the seeds)
<cjwatson> trademarks@ will probably have no clue where it's being used in Ubuntu right now though. I suspect you're going to end up asking on ubuntu-devel for a volunteer to assemble a list anyway
<cjwatson> Riddell: I'm just about to finish for the day; send me a mail with a reproduction recipe?
<bankix> I see, I have to go through the files myself.
<ogra> right, but for a user who wants to do derivetive work its the right place to ask
<Riddell> cjwatson: ok
<ogra> *derivative
<ogra> (sigh, why do always i typo the long words)
<bankix> ogra: As I understood, I need permissions only if I want to include the original trademarks, and that I won't have any chance to get such a permission when I do changes to the kernel.
<bankix> Due I have a single line changed, I'm pretty sure not to get any permission at all.
<ogra> might be, what changes are that ?
<sladen> jono: if you were keeping up with the whole Ubuntu One naming incident, you may recall that of all the bodies named in relation to tradenames... it actually the CC
<bankix> So I take the safe action and try to remove the trademarks.
<ogra> if you add a module you might be able to rather add a dkms'ified package and not touch it at all for example
<bankix> ogra: The patch makes built-in harddrives inaccessible to the kernel.
<bankix> No, it's a patch to libata.
<ogra> another possibility would be to discuss your patch on the kernel ML and eventually get it included so you could switch it on as kernel cmdline option
<jono> sladen, ahhh yes, you are right
<bankix> ogra: No, I don't think there is general use for this patch. And it wouldn't help me for 9.04.
<ogra> indeed
<debfx> is the /usr/share/xserver-xorg/pci/*.ids video driver auto-detection disabled in karmic?
<tjaalton> debfx: yes
<debfx> tjaalton: is it going to stay that way / should I remove the .ids file from the virtualbox package?
<tjaalton> debfx: yes it is. does it autoload the correct driver without the .ids?
<tjaalton> doesn't look like it would
<debfx> tjaalton: no it doesn't load it with or without that file
<tjaalton> check how it's done in hw/xfree86/common/xf86AutoConfig.c and file a bug with a patch :)
<debfx> patch from fedora fixes that: http://cvs.fedoraproject.org/viewvc/F-11/xorg-x11-server/xserver-1.6.2-vboxvideo.patch?revision=1.1&view=markup
<tjaalton> ah, good
<tjaalton> file a bug against xorg-server and it'll be fixed before too long
<tjaalton> debfx: are you maintaining vbox?
<tjaalton> er, updating
<debfx> i'm collab maintaining it at debian and have done some sponsored uploads in ubuntu
<debfx> yeah i'm removing it with the v3.0.4 merge
<tjaalton> ok, there are some issues with it making x crash when the vbox driver is first installed, and triggering apport to file bugs
<tjaalton> maybe if you had a clue about those..
<debfx> tjaalton: is it possible to also trigger the virtualbox apport hook when the vboxvideo driver is used?
<tjaalton> debfx: I guess, don't know how that works
<seb128> is there any arch where uint are not 32bits?
<cjwatson> seb128: not in Ubuntu (or Debian), but the C standard certainly permits it
<seb128> ok, because pango upstream changed a guint32 to guint in a public structure
<seb128> I'm pondering whether that should be considered as an abi breakage
<seb128> they seem to know about it and have decided it should not be an issue
<cjwatson> not for us, at least
<seb128> ok thanks
<sebner> cjwatson: grub2 ftw! :)
<tkamppeter> superm1, hi
<superm1> hi tkamppeter
<tkamppeter> superm1: I have fixed a bug in Bluez, bug 411610
<ubottu> Launchpad bug 411610 in bluez "Device discovery of the "bluetooth" CUPS backend does not work" [Medium,New] https://launchpad.net/bugs/411610
<tkamppeter> Bluetooth printer setup did not work for years, I have fixed it now.
<superm1> tkamppeter, awesome :)  Would you mind submitting that patch to the core code to linux-bluetooth@vger.kernel.org, and once they ack it, i'll upload the debdiff?
<tkamppeter> Can you apply my debdiff and upload the package (I have now upload rights for bluez, I have only per-package upload rights for the printing stack).
<tkamppeter> superm1, it would be great if you upload it already, so Alpha 4 users will already have a great Bluetooth experience.
<superm1> tkamppeter, yeah it looks harmless enough I suppose.  can you at least submit it upstream in parallel then?
<tkamppeter> As it is 100% upstream problems (no packaging or so) I will submit it upstream in parallel.
<superm1> great thanks :)
<chrisccoulson> hey cjwatson - are you still experiencing bug 391559?
<ubottu> Launchpad bug 391559 in gnome-session "RequestReboot() causes dialog to appear briefly" [Low,Incomplete] https://launchpad.net/bugs/391559
<cjwatson> chrisccoulson: I don't know, it's not exactly something I encounter in my daily work - did you never manage to reproduce it using the recipe I gave?
<chrisccoulson> cjwatson - i didn't. were you using metacity or compiz though?
<chrisccoulson> if it's metacity, then i have a likely idea what's causing it
<cjwatson> chrisccoulson: metacity, IIRC
<cjwatson> chrisccoulson: simply installing from the live CD in a VM and watching closely towards the end ought to provoke it, although it takes a while
<cjwatson> I'm fairly sure I was just using kvm
<chrisccoulson> metacity pops up a dialog on shutdown in recent versions, notifying of any windows that don't properly support  session saving
<cjwatson> although I also tested it with just a terminal and python
<chrisccoulson> and it still appeared?
<cjwatson> chrisccoulson: yep
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 <- could some dev look @ this ? its kinda annoying bug
<ubottu> Launchpad bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,New]
<chrisccoulson> cjwatson - do you remember what terminal that was with (eg, gnome-terminal or xterm)? or if any other windows were open?
<cjwatson> chrisccoulson: gnome-terminal, nothing else open
<chrisccoulson> thanks - so it probably isn't the metacity issue i was thinking about, as gnome-terminal shouldn't be affected by that
<chrisccoulson> at least that is one thing ruled out now
<cjwatson> chrisccoulson: that's my memory, anyway. It was a while ago
<chrisccoulson> thats ok, thanks. i'll try and trigger it again sometime when i get the chance
<spotter> seb128, in popping into #poppler it seems they are against their dev versions being used in a distribution, they don't make any claims of compatibility/abi stability within a dev version
<seb128> spotter, thanks
<seb128> spotter, who commented about that and was that recently?
<spotter> this morning
<spotter> logs show pinotree
<seb128> ok thanks, morning is a fuzzy concept with timezones ;-)
<spotter> 7 hours ago or so?
<seb128> ok
<spotter> maybe 5-6?
<seb128> in any case cups got rebuilt
<seb128> which workaround the bug
<spotter> works around what bug?
<spotter> probably doesn't help my pdflatex bug?
<seb128> pdflatex is probably in the same case
<seb128> needs a rebuild because poppler changed soname
<spotter> though after today i wont care for a couple of weeks, just have a paper due today
<seb128> I would do it if latex was not takes ages to download
<spotter> :)
<seb128> or build
<spotter> I'm just using old version right now to build
<spotter> though can't print reliably (unsure why, even from acroread, generated ps files just fine)
<Lure> asac: firefox 3.5 again pulls lot's of gnome packages if installed on kubuntu - I thought this was fixed properly for 3.0, but somehow dropped for 3.5
<tkamppeter> superm1, thanks for the bluez upload.
<spotter> but can manage well enough to get paper submitted
<Lure> asac: --no-install-recommends is a workaround, but probably not perfect
<Ampelbein> spotter: seb128, maybe this is solved by sponsoring bug 410242
<ubottu> Launchpad bug 410242 in texlive-bin "pdftex/libpoppler crashed with SIGSEGV in strlen()" [Medium,Confirmed] https://launchpad.net/bugs/410242
<seb128> Ampelbein, could be but as stated before my bandwith suck and this pages takes ages to download
<seb128> so I will let somebody with fast internet do that
<Ampelbein> spotter: can you try texlive-bin version in https://edge.launchpad.net/~amoog/+archive/amoog-devel ?
<superm1> tjaalton, np
<spotter> Ampelbein, tomororw :)
<spotter> not messing w/ my tex w/ 3 hours to deadline
<Ampelbein> spotter: sure, no problem
<Ampelbein> ;-)
<spotter> though if you guys come to debconf10 you can see my research, as it appears we are hosting it
<spotter> though I will hopefully no longer be there
<spotter> anyways, back to work
<hdon> hi all. i am fighting audio latency in Jaunty. i have read a few experiences of people with similar problems, but the proposals for solutions, and the blame for the latency, are anything but clearer.
<hdon> i've noticed that sometimes my programs notify me on stdout/stderr of a buffer underrun. i'm thinking, alsa, or pulseaudio (i'm not really sure what the architecture is like, exactly) is increasing the buffer size automatically when an application doesn't fill the audio stream fast enough.
<hdon> does anyone have any experience to guide me on my quest for low audio latency?
 * cjwatson writes the necessary bits to be able to reduce *-meta/debian/rules to '%:\n\tdh --with germinate $@'
<cjwatson> hopefully will eliminate some sources for error - there was a bit of duplicate configuration required in *-meta/debian/rules until now
<Ampelbein> hey there. can some core-dev take a look at bug 410242? The rebuild is also needed to fix some FTBFS, notably octave3.2.
<ubottu> Launchpad bug 410242 in texlive-bin "pdftex/libpoppler crashed with SIGSEGV in strlen()" [Medium,Confirmed] https://launchpad.net/bugs/410242
 * TheMuso waves
 * chrisccoulson waves at TheMuso
<slangasek> rtg: looks like someone took care of linux-fsl-imx51 already, yes?
<slangasek> ttx: could you edit https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview to remove the reference to bug #385475 then, please?
<ubottu> Launchpad bug 385475 in likewise-open5 "[Karmic] Likewise-Open 5 fails to authenticate users" [High,Fix released] https://launchpad.net/bugs/385475
#ubuntu-devel 2009-08-11
<lamont> so ia32-libs is 560MB of so-called source, and we're ok with that beast?  I mean, I know it's "just temporary until multiarch is done in 2006" and all that, but really...couldn't we break it up even a little?
<TheMuso> lamont: I believe there is a plan to reduce it somewhat. I know for one that pulseaudio and its dependencies will probably have bi-arch packages in the coming months. Not elligant by any means, but better than nothing.
<lamont> TheMuso: it was more one of we could split it up into ia32-libs-XX for some value of XX
<TheMuso> lamont: right
<TheMuso> lamont: I think cjwatson was working on reducing ia32-libs somewhat, not sure what he has in mind though.
<cjwatson> it's certainly not worth splitting it up by any means other than creating individual biarch packages (which I haven't got round to yet, but may well do for pulseaudio). I don't know the current state but slangasek is pretty gung-ho about getting multiarch actually in place for 9.10
<lamont> yay!!!
<TheMuso> cjwatson: Well if user bug reports re audio/pulse are anything to go by, bi-arch packages for pulseaudio are the best bet if multi-arch doesn't happen.
<cjwatson> right, I just didn't get time for a4
<TheMuso> right thats fine.
<directhex> cjwatson, i think he's off his rocker given i've been watching zero happen on that front since 2004. but hey, let's see!
<cjwatson> directhex: there's a serious design that actually got widespread consensus at debconf (I nearly fell off my chair), and actual code being written
<directhex> blimey
<directhex> whatever next, HURD being usable?
<cjwatson> not to say it isn't still pretty challenging as a target, but it isn't quite the outer-space thing I thought it was going to be when he proposed it for karmic :)
<directhex> so when's alpha 4 ready? :p
<billybigrigger> ctrl-alt-bkspace works i guess
<TheMuso> cd ..
<TheMuso> woops
<ojwb> when preparing an upload for a PPA, is there an easy (ideally scriptable) way to tell if the orig source needs to be uploaded?
<ojwb> it seems I can just always upload it, but that seems a bit wasteful
<fabrice_sp> ojwb, for ppa's question, better ask in #launchpad
<ojwb> ta
<TheMuso> c
<dholbach> good morning
<gp_will_be_back> is the intel graphic driver issue in jaunty has been fixed ?
<gp_will_be_back> is the intel graphic driver issue in jaunty has been fixed ? -> is there a patch ?
<ogra> cjwatson, so it looks like rtg built the linux-fsl package with a full set of udebs (https://launchpad.net/ubuntu/+source/linux-fsl-imx51/2.6.31-0.2/+build/1157092) do you think i can save my energy and not hack around in debian-cd now ?
<ogra> (i guess it still requires d-i adjustments)
<cjwatson> ogra: sure, if they're about the right shape you shouldn't need further hacks
 * cjwatson pokes
<ogra> great, i'll only change livecd-rootfs then ... once i know for sure how they want to call the new metapackage
<cjwatson> you'll have to make d-i or debian-cd or whatever build from universe too, I'm not really comfortable with putting this in main just yet
<ogra> oh
<cjwatson> that shouldn't be difficult
<ogra> i guess that requires some tinkering in livecd-rootfs too
<cjwatson> hardly major
 * ogra goes to look
<cjwatson> binaries accepted
<geser> can a buildd admin please give back "bogl", "cheese" (both CHROOTWAIT) and "liblauncher" (Failed to upload). thanks
<ogra> thanks :)
<cjwatson> geser: doesn't need a buildd admin, any uploader can give stuff back
 * ogra wonders why he gets a Conflicting tags: 0.69 with bzr pull of livecd-rootfs
<geser> right
<StevenK> I'm not comfortable giving liblauncher back, I don't understand the error Soyuz is throwing
<cjwatson> cheese appears to be successfully built everywhere already
<cjwatson> I've retried bogl
<ogra> does that diff look ok for livecd-rootfs ? http://paste.ubuntu.com/251232/
<ogra> well, it wont break anything but my own images anyway ....
<geser> StevenK: liblauncher got promoted to main while the buildd tried to upload the debs, so for soyuz liblauncher was in both universe and main till the next publisher run (as far as I understand it)
 * ogra commits and uploads
<cjwatson> ogra: yes, except temporary -> temporarily
<ogra> whoops
<cjwatson> ogra: though surely multiverse is overkill ...
<ogra> i just copied the xubuntu line :)
 * ogra fixes
<ogra> pushed
<dholbach> warp10:
<dholbach>  _   _    _    ____  ______   __  ____ ___ ____ _____ _   _ ____    _ __   ___
<dholbach> | | | |  / \  |  _ \|  _ \ \ / / | __ )_ _|  _ \_   _| | | |  _ \  / \\ \ / / |
<dholbach> | |_| | / _ \ | |_) | |_) \ V /  |  _ \| || |_) || | | |_| | | | |/ _ \\ V /| |
<dholbach> |  _  |/ ___ \|  __/|  __/ | |   | |_) | ||  _ < | | |  _  | |_| / ___ \| | |_|
<dholbach> |_| |_/_/   \_\_|   |_|    |_|   |____/___|_| \_\|_| |_| |_|____/_/   \_\_| (_)
<dholbach>                                                                                
<hyperair> O_O
<wgrant> StevenK: "Duplicated ancestry" really means "I am terribly confused by the override that occurred while the build was doing its thing"
<warp10> dholbach: :D man, that's awesome! Thank you very much! :)
<seb128> for those who didn't notice, dholbach is back ;-)
<ogra> haha
<dholbach> :-D
<warp10> :D
<highvoltage> wb dholbach :)
<dholbach> hey highvoltage :)
<ogra> ugh, who did give back qt4-x11 on armel
<ogra> mcasadevall, ^^^ was that you ?
<ogra> oh, there was an actual upload, nevermind me then
<StevenK> wgrant: So a giveback will clear it?
<wgrant> StevenK: Yes.
<wgrant> In this case the override actually occurred just before the build started, but the key bit is that the publisher didn't run between the override and the build finishing.
<wgrant> The publisher has hopefully run in the past three days, so it should be fine now.
<YokoZar> Hey could someone with an ATI card on amd64 do me a quick favor and ldd /usr/lib32/libGL.so.1 (with ia32-libs installed) ?
<mdz> has anyone else seen bug 411889 happen?
<ubottu> Launchpad bug 411889 in desktopcouch "package python-desktopcouch (not installed) failed to install/upgrade: trying to overwrite `/usr/share/pyshared/desktopcouch/__init__.py', which is also in package python-desktopcouch-records" [Undecided,New] https://launchpad.net/bugs/411889
<sladen> not, but one should depend on the other if it's enhancing it
<sladen> (that __init__ file should only be present in python-desktopcouch, not python-desktopcouch-records aswell
<YokoZar> Who would be the right person to talk to about upload.ubuntu.com -- I want to use sftp rather than anonymous ftp (because dput keeps failing with ftp due to my internet provider, but sftp works) ?
<liw> YokoZar, is your dput configured to use "passive ftp"?
<damo22> how do i blacklist a udev module in ubuntu?
<damo22> i dont want ubuntu to claim my usb printer
<wgrant> YokoZar: upload.ubuntu.com is Launchpad. But SFTP is a completely different protocol from FTP, and LP uses a custom FTP server, so it's not at all easy to change.
<wgrant> But it is intended that the FTP upload mechanism will be replaced soonish, I believe.
<MacSlow> Does anybody know this sort of bug with VirtualBox 3.0.4 and recent Karmic -> http://people.canonical.com/~mmueller/VirtualBox-3.0.4_bug.png
<MacSlow> Initial install went fine
<MacSlow> Updating to Guest-Additions worked fine
<MacSlow> then updated to the latest packages I got this garbage once gdm starts
<MacSlow> it's with Karmic using kernel 2.6.31-5-generic
 * cjwatson debugs root-on-iSCSI into existence. Woo
<YokoZar> liw: dput is at default, the issue is my comcastic internet connection that likes to forge reset packets
<cjwatson> soren: do these tasks look plausible to you? http://paste.ubuntu.com/251338/
<cjwatson> soren: hmm, perhaps openssh-server on the node too
<soren> cjwatson: The node controller shouldn't need a dhcp server.
<soren> Err..
<soren> I must admit, though, that the current packaging seems to suggest otherwise.
<soren> Now I'm confused. :)
<soren> cjwatson: I'll check up on that. It looks odd. Other than that, it looks reaonable.
<Ng> I'm pretty sure dhcp3-server is unnecessary at best on a node controller
<cjwatson> soren: it doesn't actually seem to use it, so seems like a packaging bug
<soren> I wonder why a) it ended up there to begin with and b) why noone has complained :)
<cjwatson> soren: eucalyptus-cc needs it though, doesn't it?
<soren> cjwatson: I believe so.
<Ng> yes
<cjwatson> and it doesn't seem to be listed among its dependencies ...
<soren> No. That's why I'm wondering why noone complained.
<cjwatson> I'll bung it into the eucalyptus-simple-cluster task for now then
<Ng> hmm, you could argue it's not a hard dependency though, the default networking mode just needs a dhcp server to be present on your network
<soren> Ng: The default networking mode in Jaunty, yes.
<soren> Ng: Karmic will default to MANAGED.
<Ng> soren: bold :)
<cjwatson> how about I take it out of the task for now then since we don't have the new euca yet
<Laney> anyone fancy looking at the cdbs ftbfs? bug 409863
<ubottu> Launchpad bug 409863 in cdbs "FTBFS: FAIL: recursive.sh" [Undecided,New] https://launchpad.net/bugs/409863
<soren> cjwatson: Makes sense.
<soren> cjwatson: At least we're consistent in our buggy dependencies then :)
<Ng> soren: hrm, shouldn't -cc depend on bridge-utils too?
<soren> Ng: I would have thought so, yes.
<ScottK> cjwatson: I'm looking at updating kubuntu-meta and you've TIL.  It appears you updated it using the Sid deboostrap because I get "/usr/bin/germinate-update-metapackage: Installed debootstrap is older than in the previous version! (1.0.13 < 1.0.15)".  What's the best way to proceed from here?
<ScottK> Imagine I spelled debootstrap correctly in the last line please.
<cjwatson> ScottK: oh, bah, good catch. I don't want to sync that into Karmic right now for various reasons - how about you just manually edit the debootstrap-version file?
<ScottK> cjwatson: I can do that, just thought I should check with you first in case there was a reason  not to.
<ScottK> Thanks.
<cjwatson> no, it should be ok
<cjwatson> in this case anyway
<ScottK> It's running.  Thanks again.
<ogra> seb128, gah, you are to fast ... (/me wanted to ask if all of sbalneavs ubuntu fixed went into sabayon before that gets uploaded)
<ogra> (i didnt see his name mentioned in the changelog, but i know all edubuntu users use his ppa packages nowadays)
<seb128> not sure if his changes are in the new version I didn't know there was a ppa
<ogra> i know he did the xephyr transition and sent that upstream
<ogra> but i'm not sure all of his patches are in, i'll ask him to check if i see him around
<ogra> i only follow edu stuff with half an eye nowadays
<ogra> StevenK, poke, can i ask for de-NEWing linux-meta-fsl-imx51 ?
 * ogra assumes StevenK went to bed (which would be valid at nearly 2am :) ) 
<ogra> could any archive adimn take a look at linux-meta-fsl-imx51 and wave it through the NEW queue ?
<ogra> *admin
 * ogra jumps up and down waving his arms to get archive admin attention
<amitk> no #archive ?
<ogra> nope
<ogra> i know colin would help immediately if i pinged him directly, but i want the load being shared
<hyperair> didn't you just ping him directly?
<ogra> nope
<ogra> i doubt he highlights on his real name :)
<hyperair> ahaha
 * ogra starts to glow in rotating colors to get some more attention, jumping and waving doesnt seem to help ...
<Laney> so ping someone else directly?
<highvoltage> Not sure if you guys saw this yet:  http://lwn.net/Articles/346400/ (etch and feisty comparison in terms of common packages)
<ogra> 1079 Ubuntu has Vebian bersion with ubuntuXX patch
<ogra> ????
<ogra> funny typoing :)
<ScottK> Two of those updates only make sense if you update clamav to a newer version in Etch, which Debian won't do.
<ScottK> Oddly the analysis misses a bunch of the other clamav rdepends.
<ogra> ScottK, you dont feel like taking a look at linux-meta-fsl-imx51 ? (since you made the mistake to speak here *and* are archive admin :) )
<ScottK> ogra: There is specialness about kernel packages that the LP U/I can't handle.
<ScottK> Sorry.
<ogra> it will stay in universe and vanish after alpha
<ogra> oh, its only meta though
<ogra> seb128, you dont happen to have some spare minutes to let linux-meta-fsl-imx51 out of NEW ? (its only a metapackage)
<seb128> no
<seb128> we have a meeting starting right now
 * amitk is reminded of Scrat and his acorn from Ice Age when seeing ogra and his linux-meta-fsl-imx51 package :)
<ogra> heh
<ogra> amitk, well, if nothing helps i'll ping cjwatson but he does so much already that i wanted to put the load on someone else
<amitk> you just did :-p
<ogra> though a meta review is really trivial i think
<ogra> amitk, yes, deliberately :)
<ogra> since all the other archive admins are busy or not around
<slytherin> ogra: is it usually easy the bug the archive admin who is assigned for the day.
<kenvandine> slangasek, ping
<ogra> slytherin, meh, i forgot to look at the schedule on the wikipage, thanks for reminding
<ogra> Riddell, poke, can you unleash linux-meta-fsl-imx51 from NEW ?
<slangasek> kenvandine: hi
<kenvandine> slangasek, so can you get xsplash on the desktop seed?
<slangasek> kenvandine: working on some other critical-path stuff at the moment, but I'll have a look at it later this morning
<kenvandine> ok
<kenvandine> please do
<ogra> kenvandine, is there artwork already ?
<kenvandine> pitti had verbally approved it
<kenvandine> ogra, there is better temp artwork
<ogra> (if i install it do i get the shiny stuff ?)
<kenvandine> right now it is the default wallpaper
<kenvandine> :)
 * ogra would love to test it
<ogra> ah
<kenvandine> there are a couple of flickers and gdm needs to start sooner
<kenvandine> so it isn't the final experience of course
<kenvandine> but it is important that we get it on alpha4 :)
<ogra> yeah, i wasnt expecting anything final :)
<kenvandine> we really want bug reports, et
<kenvandine> +c
<slytherin> what is xsplash?
<james_w> ogra: I don't think there's a need for it to explain the history of linux in debian/copyright given that it's just a metapackage
<ccheney> so we still have a splash, no < 3s to gdm? :-\
<james_w> plus, Vcs-Git is invalid
<ogra> james_w, i'll tell rtg, the package will vanish after A4 again anyway
<ccheney> kenvandine: or is the < 3s to gdm still expected once it has moved?
<james_w> ogra: ok, thanks
<ogra> james_w, no, thanks to you for unleashing it :)
<kenvandine> ccheney, not sure how fast it will be
<ccheney> kenvandine: ok
<ccheney> iirc the plan was to not show splash if gdm came up in ~ 3s
<kenvandine> slytherin, the new boot experience stuff for karmic
<slytherin> ccheney: isn't 3s overly optmistic?
<ogra> ccheney, it is covering the black screen X had by default on startup
<kenvandine> ccheney, well you shouldn't see usplash
<kenvandine> but you should see xsplash
<slytherin> kenvandine: using kms?
 * ccheney wasn't at the sprint though so plans might have changed
<kenvandine> the idea is xsplash start with gdm and fades out when gdm is completely ready for you to login
<kenvandine> then when you login, xsplash raises again until the desktop is completely loaded and fades out
<kenvandine> so a nice smooth experience
<ccheney> kenvandine: ah ok, i think that was a change from uds, but sounds more realistic anyway :)
<kenvandine> it is a change
<slytherin> ahh ,good
<slytherin> i thought it was something like plymouth
<kenvandine> no... no point
<kenvandine> our boot will be so fast :)
<ogra> pfft
<ogra> my laptop still takes 25sec
<superm1> kenvandine, so usplash remains seeded/installed right?
<kenvandine> yes
<kenvandine> ogra, mine too... but people have great goals
<superm1> will it actually show up before xsplash takes over, or is the intention to not even run usplash when xsplash is available to be used?
<ogra> kenvandine, well, for me modprobe hangs in a 10sec loop, i doubt that will be fixed (hw doesnt respond) so i'll always have +10sec
<kenvandine> superm1, you shouldn't see usplash at all
<kenvandine> unless it fails to start X or something
<kenvandine> basically usplash should only be seen if something is wrong :)
<kenvandine> right now you will still see usplash
<superm1> kenvandine, ah okay
<kenvandine> until gdm gets moved to the beginning of the boot sequence
<kenvandine> that will happen post alpha4
<kenvandine> it is incremental :)
<kenvandine> we just want to get it out there now so we can get bug reports, etc
<ogra> james_w, can i get a binary NEW as well from you ? (yes it already built :) )
<james_w> ogra: for main?
<ogra> no, universe
<ogra> that package will never enter main
<ogra> it is only temporary for A4
<ogra> (we build the arm image from universe atm)
<ogra> the arm kernel naming is still being discussed, its likely to change right after A4
 * slytherin wonders if any archive admin can review jmeter (arch all).
<slangasek> ogra: eh, why are the kernel names changing again
<slangasek> ?
<ogra> slangasek, bug 411968
<ubottu> Launchpad bug 411968 in linux-fsl-imx51 "Please rename babbage to imx51, just like in jaunty" [Undecided,New] https://launchpad.net/bugs/411968
<ogra> slangasek, in our (mobile team) opinion the naming is wrong, but we postponed the discussion until after A4 to get the image out for now
<slangasek> I had already spoken to rtg about that last week, and he says the hardware that worked with the jaunty kernel doesn't work with the karmic kernel and vice versa
<slangasek> so there would be no reason to provide a direct upgrade path
<ogra> thats not true
<ogra> thats not true either
<slangasek> then I suppose you should make that clear to rtg in the bug
<ogra> the HW that worked in jaunty will go on working
<ogra> plus there will be two more iterations of the SoC that will work with it
<ogra> and we would like to have the ability to add two additional ones the oem team cares for later (karmic+1 probably)
<ogra> so the SoC name should be the name of the image/metapackage as it was in jaunty
<ogra> but we'll discuss that *after* A4 as i said
<crimsun> kklimonda: see my audio-fixes branch ubuntu-karmic.git branch if you want to test-compile
<crimsun> wow, completely screwed that one
<lool> slangasek: I noted that in the bug report
<lool> slangasek: IMO it's wrong to name the kernel flavour after the board instead of the soc because we might want to support multiple boards with the same kernel flavour; I also believe that Babbage 1 (supported in jaunty) will work in karmic albeit I don't think that's a hard requirement -- the bootloaders are incompatible though
<ogra> well, we already have one bootloader that clearly supports 2 boards ... so you never know :)
<ogra> (babbage 2.0 and 2.5)
<lool> ogra: But we know for sure b1 and b2.x bootloaders are incompatible just like lange versus babbage bootloaders
<ogra> yes
<lool> So I _do_ know
<lool> ;)
<ogra> but who knows, b3 might use the same as b2 and 2.5
<lool> Yeah but b1 wont
<ogra> indeed
<directhex>  f-spot (0.6.0.0-1) unstable; urgency=low
<seb128> directhex, right was uploaded to karmic before as a fake sync
<directhex> it was? :o
<sebner> directhex: f-spot (0.6.0.0-1~ubuntu1) karmic; urgency=low
<sebner> directhex: https://edge.launchpad.net/ubuntu/+source/f-spot ;)
<directhex> hax!
<seb128> directhex, I did sync the new mono too today
<sebner> seb128: still archive admin? then sync cli-common too please, directhex didn't need a main ACK, I got one :P
<seb128> sebner, bug number?
<sebner> seb128: 410744
<sebner> seb128: bug #410744
<ubottu> Launchpad bug 410744 in cli-common "Please sync cli-common 0.7 from Debian(Unstable)" [Wishlist,Confirmed] https://launchpad.net/bugs/410744
<seb128> sebner, done
<sebner> seb128: my hero \o/, thanks :)
<seb128> you're welcome
<directhex> yay for seb128
<directhex> seb128, barring bugs, i think that should be it for mono in karmic... although i'm leaning on meebey to make a small change which should save us 200k
<seb128> directhex, sebner: could one of you look if gnome-desktop-sharp2 can be synced?
<seb128> the diff seems to be non ubuntu specific
<seb128> ie could be fixed in debian now
<Jukada> hey
<Jukada> k
<slangasek> ogra: so why is arm being built from universe?  that's not a good thing, and I don't think we should be propagating that further by putting the kernels in the wrong place
<slangasek> kenvandine: should xsplash replace usplash in the platform desktop-common seed, or is there a reason this needs to be Ubuntu-only right now?
<kenvandine> slangasek, it doesn't replace
<slangasek> hmm?
<kenvandine> it is desktop specific though, needs X and gdm
<kenvandine> if all is good you won't see usplash
<kenvandine> but we want usplash to be there if something goes wrong
<slangasek> usplash is only in the desktop-common seed, that already implies X (but doesn't imply gdm in the case of kubuntu)
<slangasek> ok
<kenvandine> ok
<slangasek> alright, seeded & promoted
<kenvandine> woot
<kenvandine> thanks slangasek!
<slangasek> now I just need to get eglibc vetted, and we can start building us some ISOs
<ScottK> mcasadevall: Can you look at dbus on ia64?  Looks like a missing include to me, but I've got no way to test.
<mcasadevall> ScottK, *groan* that's a linker error
<mcasadevall> ScottK, I'll put it on my TODO list, but it probably won't get looked at until post-A4
<ScottK> mcasadevall: That's fine.
<mcasadevall> ScottK, anyway, its possible qt4-x11/lzma weirdness might be fixed
<ScottK> mcasadevall: Excellent.  With the one that's building right now perhaps?
<mcasadevall> ScottK, that's our test
<ScottK> err .... was last I looked.
<mcasadevall> ScottK, its still going
<mcasadevall> No idea if it will finish or not
<mcasadevall> ScottK, if it works, woo, if not, then common sense has been let go on this bug
<infinity> mcasadevall: qt4-x11 seems to have finished successfully, BTW.
<billisnice> I have a request?
<billisnice> When you are updating and it say to run  sudo dpkg --configure     Have the update manager run it automatically without telling you to...
<billisnice> sudo dpkg --configure -a
<docelic> Hey folks, any idea why "passwd/make-user= false" question during preseed would be ignored? It's delivered in the http preseed file, but the system still asks to create the user (name, username, password etc..)
<cjwatson> docelic: you'll have to create a root user; user-setup won't allow you to install with no user at all
<cjwatson> so 'd-i passwd/root-login boolean true' 'd-i passwd/root-password password blah' 'd-i passwd/root-password-again password blah'
<cjwatson> (or passwd/root-password-crypted. see the guide)
<docelic> ah! many thanks, root-login was the thing I missed
<docelic> also, the example-preseed.txt file (in the docs from 9.04) has a mistake in one field, let me tell you which one
<docelic> Question clock-setup/ntp-server
<docelic> the third field (type = string) is missing
* slangasek changed the topic of #ubuntu-devel to: Archive: main frozen for alpha-4, DebianImportFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> docelic: thanks; that was fixed a little while back in Debian and is fixed in Karmic, although unfortunately we overlooked the fix for 9.04
<crimsun> just as a sanity-check, karmic won't update to automake 1.11, will it?  pulseaudio git now requires 1.11.
<slangasek> didrocks: are there source changes needed to gir-repository to transition it to clutter-gtk 0.10?
<cjwatson> last I checked we were waiting for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512704 to be fixed
<ubottu> Debian bug 512704 in automake "automake: New upstream version available" [Wishlist,Open]
<cjwatson> rather than doing it ourselves
<mcasadevall> infinity, !\o/!
<crimsun> cjwatson: thanks
<slangasek> StevenK: gir-repository was recently MIRed, it build-depends on goocanvas which hasn't been; is that something that should be done, or is gir-repository sufficiently "temporary" that we should be getting rid of it, instead?
<tkamppeter> superm1: hi
<seb128> slangasek, gir-repository is not really "temporary" enough
<slangasek> alas
<seb128> ie it will not be solved this cycle
<slangasek> so there's a bunch of MIRs which would be needed for its build-deps, then
<seb128> that's a collection of things that each library should build
<slangasek> (clutter-cairo, goocanvas, ...)
<seb128> but since upstream didn't start on this move yet ...
<seb128> the whole gir-repository thing sucks
<slangasek> yes, I can tell by looking at it :)
<seb128> it's just a workaround to have gir working without doing thing properly
<seb128> ie it's fine for early testing etc but things should be move to proper libs
<StevenK> But should we promote goocanvas.
<StevenK> I guess promoting it for completeness would be nice, and if we need to actually rebuild/sync gir, but ...
<TheMuso> Could someone possibly get the latest binaries for linux-rt out of new? They've been there for a few days, and are needed for the next studio alpha.
<maxb> A mostly trivial merge of Subversion 1.6.3 (we currently have 1.6.1) from Debian is currently blocked owing to Debian's version now pulling in Serf as a builddep and hence requiring a new MIR. Serf is an optional builddep for Subversion which Debian just happened to enable now. There are important bugfixes in Subversion 1.6.3. Given the proximity of FeatureFreeze, would it be sensible for me to prepare an adjusted merge that drops the Serf
<maxb>  builddep?
<lifeless> maxb: 'yes'
<maxb> :-)
#ubuntu-devel 2009-08-12
<dhillon-v10> hi everyone, I need some help with launchpad
<Ampelbein> dhillon-v10: just ask, maybe someone knows the answer.
<dhillon-v10>  Ampelbein: alright I want to test some features in a laubchpad team (that I will create) so can I delete it if 'i don't need it
<hyperair> join #launchpad and poke them about it
<Ampelbein> dhillon-v10: use staging.launchpad.net for such tests, it's a testing environment that gets reset every night.
<Ampelbein> dhillon-v10: it doesn't send mails though so if you need that tested, do what hyperair says ;-)
<dhillon-v10> thanks guys
<Ampelbein> dhillon-v10: as far as i know, teams can only be deleted by asking a question on launchpad answers.
<dhillon-v10> Ampelbein: I am going to create a team of my own.. :)
<slangasek> StevenK: well currently gir-repository references the NBS libclutter-gtk-0.8, so it would be nice if /something/ were done here. :)
<StevenK> slangasek: Argh, it does?
<StevenK> slangasek: I'm about to upload casper since I suck, there's time for a UNR respin?
<slangasek> http://people.canonical.com/~ubuntu-archive/NBS/libclutter-gtk-0.8-dev
<slangasek> yes, there's time for a UNR respin
<StevenK> Yeah, the clutter-gtk NBS list was making me cry, so I closed it before I reached for something sharp
<StevenK> slangasek: The casper change is marking a working script as +x so UNR actually has the installer as a favourite.
<Ampelbein> hi there... I'm trying to get diagnostics built on karmic but get a FTBFS pointing to a "invalid conversion from 'int (*)(const void*, const void*)' to 'int (*)(const dirent**, const dirent**)'" (http://paste.ubuntu.com/251684/) The strange thing is: ace have not had code changes for some time and I can't really figure out why this suddenly fails. It did not fail about 3 weeks ago... could this be related to glibc -> eglibc transition?
<Ampelbein> full buildlog if anyone is interested: http://launchpadlibrarian.net/30197352/buildlog_ubuntu-karmic-i386.diagnostics_0.2.7-2ubuntu1_FAILEDTOBUILD.txt.gz
<Ampelbein> ojwb: i digged some more into this, in the specified file ( /usr/include/ace/OS_NS_dirent.h) there is http://paste.ubuntu.com/251687/ . So it seems to check at buildtime how to call those functions.
<Ampelbein> (i'm not a programmer, so forgive me if i make wrong assumptions)
<ojwb> ah, it is wrapping scandir() (for portability I assume)
<ojwb> it may be a change in g++
<ojwb> something that was only a warning being an error now
<Ampelbein> it doesn't show in the old buildlog (http://launchpadlibrarian.net/29636028/buildlog_ubuntu-karmic-i386.diagnostics_0.2.7-2_FAILEDTOBUILD.txt.gz) which failed because of wrong symbols file
<Ampelbein> could it be that ace simply needs a rebuilt to perhaps pick up a change in behavior? i'll try this.
<ojwb> well, warnings aren't turned on
<ojwb> it's worth trying a rebuild for ace I'd say
<Ampelbein> ojwb: thank you very much for your help.
<jtimberman> hello, is there a document on how to patch a debian/rules file in a package for karmic?
<Ampelbein> jtimberman: what do you want to do exactly? are you looking for the packaging guide?
<Ampelbein> !packaging
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - 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
<jtimberman> Ampelbein: I think I found it, Preparing patches section of: https://wiki.ubuntu.com/MOTU/Contributing
<StevenK> slangasek: It turns out the UNR daily hasn't built yet, I'll just wait for it
<slangasek> StevenK: good thing you've said that, otherwise I might've disabled the cronjobs before then :)
<jtimberman> and now there's a patch for the runit package, applicable to   Bug #406621
<ubottu> Launchpad bug 406621 in runit "package runit 2.0.0-1ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/406621
<StevenK> Argh, and the UNR livefs breaks thanks to nvidia-common
<StevenK> slangasek: &
<StevenK> Er
<StevenK> slangasek: ^ ; all livefses that pull in nvidia will fail, -185 is in source NEW, and nvidia-common wants it
<superm1> hi tkamppeter_
<Ushaib> Hi. Gedit is crashing everytime I'm opening a specific 800kb text file. There is no error message, it just closes immediately. How do I proceed if I want to alert the developers about this issue? What information should I gather, etc.
<Ushaib> err, just read the topic and the link to ubuntu-bugs. Sorry.
<Dyno> How do you sign packages? When I try to sign with my gpg, I keep getting "secret key not available
<ojwb> debsign <.changes files>
<StevenK> slangasek: The -180 -> -185 rename for nvidia looks gratatious to me, but I'm not sure how you want you to go in terms of cleaning up the mess
<YokoZar> hmm apparently build-essential isn't an implied package build dep ;)
<ScottK> slangasek: I have a proposed upload for konq-plugins that fixes a problem with file overwrites among packages within that source package.
<dholbach> good morning
<slangasek> StevenK: it's not a rename, the 180 package is still present?
<slangasek> ScottK: which -proposed?
<slangasek> oh, it is a rename; blah
<StevenK> slangasek: We can scorched earth nvidia-common back to -180?
<ScottK> slangasek: Proposed for karmic (not uploaded due to freeze, but I'd like to go ahead)
<slangasek> StevenK: I don't see that this is warranted (although packages that Replace: themselves are a bit odd)
<slangasek> ScottK: ah - go ahead, please
<ScottK> OK.  It'll be up in a moment.  Once again less foo.changes saves me from a typo in the changelog.
<slangasek> StevenK: hmm, I guess if I were to accept this -185 package, it would be just to get the milestone rolling, ignoring various packaging bugs; so yeah, let's revert -common
<slangasek> StevenK: will you take care of this?  Otherwise, I'll get it when I'm back from the store
<StevenK> slangasek: I'll start it now
<ScottK> slangasek: qt4-x11 built on armel ....
<emma> Hey I just wanted to tell you all that there is a meteor shower tonightin North America. If you are interested.
<ScottK> mcasadevall: ^^^^
<emma> It should be best around 2- 3 am local time no matter where you live.
<ScottK> Cloudy here unfortunately.
<mcasadevall> ScottK, yup, I'm aware
<mcasadevall> ScottK, take a look at the build queue now
<mcasadevall> def. an improvement, and once KDE builds, compiz can be built and make ubuntu-desktop installable on ARM
<emma> KDE with compiz?
<emma> I thought KDE had its own windows compositor
<hyperair> kwin4?
<ScottK> emma: It does, but compiz has a compiz-kde for people that just have to have compiz.
<ScottK> mcasadevall: Congratulations.
<ScottK> hyperair: Yes.  Kwin.
<emma> compiz would be pretty neat on kde.
<hyperair> compiz is neat. period
<emma> ScottK: im concerned about gnome-shell. It will be gnome 3 and it throws out (1) compiz, (2) gnome pannel, and (3) python.
<hyperair> it throws out python?
<emma> ScottK: it's hard to believe that ubuntu would even want to use gnome-shell. So maybe Ubuntu will switch to KDE as default?
<hyperair> i know it tosses 1 and 2, but 3 i've never heard of
<emma> hyperair: yes it's written in javascript!
<hyperair> ...what.
<mcasadevall> ScottK, thanks infinity; the issue was the buildds were using lenny as the base OS from when they were first installed in DC.
<mcasadevall> ScottK, reinstalling them to jaunty magically fixed things
<mcasadevall> (I don't want to know why)
<ScottK> mcasadevall: Lovely.  Glad it's resolved.
<hyperair> emma: where did you get that from?
<mcasadevall> ScottK, powerpc should also be (semi)fixed
<emma> hyperair: their website.
<ScottK> mcasadevall: Yes.  It's building fine.
<hyperair> you sure you didn't catch on a bad april fools joke?
<ScottK> emma: No idea about Gnome 3 myself.
<emma> hyperair: no it's certainly true, gnome-shell is written in javascript.
<hyperair> maybe gnome-shell, but definitely not the rest of gnome 3
<emma> I believe the grandidea behind the whole thing is that it's an interface that will work nice on mobile apps. But in my opinion the interface makes no sense on the desktop. So many menus just to do simple tasks!
<hyperair> i haven't taken a good look at gnome-shell's source code yet
<hyperair> i dunno, i can live with gnome do and compiz
<emma> How can they just throw out compiz! Compiz is one of the main things that draws people to linux. It's what people think of when they think of Ubuntu!
<hyperair> er no, you're exaggerating
<emma> Im talking about new people who get excited to try it out.
<hyperair> compiz isn't everything, but it sure as hell is something which has features i can't live without
<emma> They see that cube, they get excited, they want to know what that is, it's linux, so they get Ubuntu.
<hyperair> i know many new ubuntu converts who aren't excited by compiz
<hyperair> it's not so much of the cube, it's more of the virtual desktop
<hyperair> aka workspaces
<emma> Yeah
<hyperair> all window managers have them
<StevenK> slangasek: nvidia-common uploaded.
<slangasek> StevenK: cheesr
<StevenK> slangasek: So maybe we reject -185, and get Alberto to update -180 after Alpha 4. I'm not really fussed, but it does seem fairly gratuitous
<slangasek> StevenK: I agree
<dholbach> looking at http://people.canonical.com/~dholbach/sponsoring/ we should really make it the Ubuntu Sponsoring Week
<nellery> that sounds like a good idea
<tkamppeter> superm1, hi
<ttx> slangasek: did you get my message about bug 385475 being fixed and needing to be dropped for alpha4 release notes known issues ?
<ubottu> Launchpad bug 385475 in likewise-open5 "[Karmic] Likewise-Open 5 fails to authenticate users" [High,Fix released] https://launchpad.net/bugs/385475
<didrocks> slangasek: no transition needed from what I saw gir-repository is still intended to be "temporary"
<didrocks> slangasek: but well, it's a long "temporary" time, apparently :)
<sarts_> what's 'gir'
<directhex> my supybot on oftc!
<dholbach> sarts_: I guess 'r' and 't' are pretty close together on didrocks' keyboard :)
<didrocks> hey dholbach :)
<dholbach> heya didrocks
<dholbach> how's life in France?
<didrocks> no, gir-repository is a collection of gobject-introspection :)
<ogra> these french guys, tsk .... get better keyboards !
<didrocks> dholbach: great. I'm in the Alpes, near my parents on holidays :)
<ogra> ;)
<dholbach> ah nice
<didrocks> ogra: azerty keyboard for the win \o/
<ogra> haha
<sarts_> hehe
<sarts_> didrocks: I doubt it
<directhex> any time you need alt-gr to be useful, your layout sucks
<didrocks> directhex: that's unfortunately correct :/
<directhex> of course it is! /me knows all ;)
<sarts_> directhex: is there any layout that does not require the use of Alt-Gr while still supporting the â¬ sign?
<Ng> sarts_: anything with a compose key \o/
<directhex> sarts_, obviously â¬ sucks!
 * dholbach reminds everybody of http://people.ubuntu.com/~dholbach/sponsoring/ :-)
<sarts_> currently, $ and Â£ suck more ;-)
<slangasek> ttx: I guess that means you didn't see my request that you update the wiki page? :)
<slangasek> didrocks: right, long enough that we have to deal with it for a release cycle :/
<slangasek> asac: so, switching from bluez-gnome to gnome-bluetooth costs is half a MB on the CDs... does it bring half a MB of functionality?
<ttx> slangasek: no :) could you resend the url ?
<slangasek> ttx: https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview
<ogra> meh, amrel+imx51 doesnt build its livefs
<ttx> slangasek: ok, will do
<slangasek> ttx: thanks!
<didrocks> slangasek: the issue is that netbook-launcher and libclutk-0.2-0 depends on libclutter-gtk-0.10-0. If they still needs only 0.8, we can add an epoch to the source package, rebuild it to 0.8, and create clutter-gtk-0.10-0 source package in universe. Does this sound right?
<directhex> slangasek, if you want to ubuntu1 mono, i can get you 200k. i'm still trying to convince meebey to do it, but i don't see it happening in a4 timeline
<slangasek> directhex: I think we'll have to find the space elsewhere for alpha-4 (langpacks); I'm just poking at what looks like new bloat as it appears
<slangasek> didrocks: that doesn't make any sense at all to me - why would we not be trying to get rid of the 0.8 stuff entirely?
<directhex> slangasek, well if you become desperate, you know where to find me
<didrocks> slangasek: it was to avoid having to MIR gir-repository and all depends (only 0.10 depends on it IIRC, have to check this)
<seb128> slangasek, gnome-bluetooth is official part of GNOME now and maintained, will get frequent tarballs, new features, etc
<slangasek> seb128: but why is it 5x the size of bluez-gnome?  It certainly doesn't look more functional to me
<seb128> slangasek, 5x?
<slangasek> seb128: will gvfsd-backends be switching to obexd-client, btw, now that bluetooth-gnome depends on it?
<seb128> slangasek, I expect so
<slangasek> seb128: yes; gnome-bluetooth+libgnome-bluetooth7+modemmanager+obexd-client = 680K, vs. 161K for bluez-gnome (ok, 4x, not 5x)
<seb128> slangasek, to be fair in that you should not count modemmanager and obexd
<seb128> since bluez-gnome also has a obex server and doesn't cover what modemmanager do
<slangasek> if obex-data-server wasn't still on the CDs too, I wouldn't count obexd-client; but ok, that's still 3x. :)
<seb128> but yeah there is some sort of overlap now until we do proper cleaning
<StevenK> slangasek: I just did a build of UNR, I didn't step on your toes?
<slangasek> StevenK: ah, well, we'll get another build soon then
<slangasek> no big deal
 * StevenK nods
<directhex> according to my figures, f-spot/tomboy plus deps have shrunk by about 5 meg this cycle
<dholbach> who would like to give a packaging training session at 12:00 UTC tomorrow? (nothing huge, 15-20 minutes of content + some time for questions is fine)
<dholbach> james_w and I just had the idea to run a "on-call review" session instead of a "strict packaging training" session - who would like to participate as a reviewer?
<dholbach> hey mok0
<seb128> dholbach, "on-call"?
<mok0> heya dholbach
<dholbach> seb128: instead of a packaging training session, we wanted to be in #ubuntu-classroom and review stuff of people who show up there and explain problems, etc.
<dholbach> like an online review
<seb128> ah ok, I can be around I guess ;-)
 * ogra is desparate 
<ogra> seems my armel livefses dont build because gconf2 cant be found
<ogra> but gconf surely built
<cjwatson> dholbach: I can do that
<ogra> http://paste.ubuntu.com/251824/ is what i get trying a manual livefs.sh run on armel+imx51
<cjwatson> sometimes apt reports that package X is not installable when actually the problem is in one of X's dependencies
<cjwatson> I usually use chdist to investigate
<ogra> well, libgconf2-dev or gconf2-common replace gconf2
<ogra> and apt-get install gconf2-common is no prob at all in the chroot
<sebner> dholbach: aloha! Sry for the g-d-s sync. I accidently subscriped the archive admins too and the just know mono stuff is _not_ b0rken so they synced without leaving a note :)
<cjwatson> you need to test installing them all at once, not just one at a time
<cjwatson> the signs point to some kind of conflict
<cjwatson> and BTW that message totally does not say that gconf2 can't be found
<cjwatson> it says it's not installable, that's different
<cjwatson> ogra: which flavour is this?
<ogra> armel+imx51
<dholbach> seb128, cjwatson: that'd be sweet - you guys are rockstars!
<dholbach> I'll send out an announcement later today
<cjwatson> that's not a flavour, that's a subarchitecture
<cjwatson> kubuntu is a flavour, for example
<ogra> ubuntu-desktop, sorry
<cjwatson> ok, I get a different error when testing with chdist
<cjwatson>   evolution: Depends: evolution-common (= 2.27.5-0ubuntu1) but it is not going to be installed
<ogra> i'm just running livefs.sh -simx51 here
<cjwatson>              Recommends: evolution-documentation (= 2.27.5-0ubuntu1) or
<cjwatson>                          evolution-documentation-en (= 2.27.5-0ubuntu1) but it is not going to be installed
<ogra> ugh, i missed the equal sign
<ogra> sorry for the noise
<cjwatson> (though I don't have universe enabled)
<ogra> i do, but evo ftbfs
<cjwatson> that'll need to be fixed then ...
<ogra> yes, retrying it now
<cjwatson> what good will retrying it do?
<seb128> how did the build break?
<cjwatson> the problem is that gtkhtml3.14 failed to build
<ogra> it should fix it, normally the deps are delayed because openjdk or something builds
<cjwatson> ogra: gah. no. stop. think.
<cjwatson> gtkhtml3.14 failed to build because:;
<cjwatson>   gnome-icon-theme: Depends: libgtk2.0-bin but it is not going to be installed
<seb128> arch all any mismatch in gtk I guess
<cjwatson> so let's check http://people.canonical.com/~ubuntu-archive/testing-ports/karmic_probs.html
<seb128> ie the new version didn't build on the arch
<cjwatson> so that's no longer showing any problems in that area
<seb128> so retry gtkhtml?
<cjwatson> which indicates that it's probably safe to retry gtkhtml3.14
<cjwatson> wait for gtkhtml3.14 binaries to publish, *then* retry evolution
<ogra> ok, i just wasted buildd time then, i was to fast
<cjwatson> if people give-back without thinking then we may have to withdraw the ability for developers to retry builds
<cjwatson> especially on slow architectures
<seb128> slangasek, when would be a good time to upload a new gtk version?
<asac> slangasek: there is room for improvement how gnome-bluetooth is linked (e.g. he links libcommon.a in binaries and lib)
<asac> slangasek: modemmanager has nothing to do with the bluetooth thing. its factored out of NM rather
<Riddell> evand1: timezone page in ubiquity-frontend-kde broken, anything that's changed there recently? http://paste.ubuntu.com/251852/
<evand1> Riddell: yeah, mterry made changes to ubiquity to support translated timezones, and it looks like the kde timezone class hasn't been updated for those changes.  shtylman, can you take a look at this?
 * Keybuk fails to understand why he shouldn't push with uncommitted changes
 * ogra sighs about slowness of mirroring binaries to ports.u.c
<shtylman> evand1: will do
<evand1> shtylman: thanks, I appreciate it
<shtylman> no prob
<geser> soren: thanks for the new gnupg2 version, I can now play with my new shiny OpenPGP 2.0 card :)
<soren> geser: No problem. That was my goal, too, as I'm sure you've gathered by now :)
<cjwatson> Keybuk: '(echo "[ALIASES]"; echo "push = push --no-strict") >> ~/.bazaar/bazaar.conf' ? :-)
<chrisccoulson> directhex - do you know if libipoddevice is still maintained anywhere, or used (or going to be used) by anything?
<chrisccoulson> https://edge.launchpad.net/ubuntu/+source/libipoddevice
<cjwatson> err, or for that matter 'bzr alias push="push --no-strict"'
<ogra> The following packages have unmet dependencies:
<ogra>   usb-creator-common: Depends: syslinux but it is not installable
<ogra> mumble
<directhex> chrisccoulson, i don't know!
<chrisccoulson> the only reason i asked you is because the ~mono team is subscribed to the package ;)
<chrisccoulson> that's ok if you don't know though
 * YokoZar closed 10 ia32-libs bugs today
<YokoZar> Multiarch is still vaporware right?
<cjwatson> it's gradually congealing
<YokoZar> ia32-libs is a 500 meg source package now ;)
<chrisccoulson> urgh
<chrisccoulson> you have the bandwidth for that?
<YokoZar> chrisccoulson: sort of, dput kept stalling with 1 k left because of Comcast being horrible, so I had to sftp it to a datacenter server and then dput it from there
<chrisccoulson> yeah, i think my ISP would start throwing heavy objects at me if i was uploading things of that size frequently ;)
<directhex> chrisccoulson, perhaps libipoddevice was once an rdep for banshee?
<directhex> chrisccoulson, yep, in dapper
<Keybuk> cjwatson: I did that
<Keybuk> I just wondered why it was the default now
<chrisccoulson> directhex - that's what i'm thinking. the code doesn't seem to be hosted anywhere, and it currently depends on gnome-volume-manger, which i'm looking to have removed
<chrisccoulson> ah, ok. so libipoddevice is probably not worth keeping around now then?
<directhex> chrisccoulson, i would support its removal. who's maintainer in debian?
<cjwatson> Keybuk: yeah, I don't know, seems an odd decision to me
<chrisccoulson> directhex - not sure who maintains it in debian. i'll check this afternoon
<chrisccoulson> thanks :)
 * ogra ties seb128 to his chair and moves the chair 2m away from the keyboard
<seb128> ogra, what?
<ogra> i'm trying to get a working liveimage on armel ... you are uploading stuff all the time
<seb128> sorry I should be done now
<seb128> the thing is that if we don't get those now it will delay by 2 weeks at least
<seb128> I'm not there next week neither is pitti
<ogra> yeah, its fine as long as gtk doesnt take significantly longer than evo
<seb128> and I don't want to upload a gtk on friday before holidays
<ogra> right, but i'm also under pressure to have images, why isnt the qeue locked ?
<seb128> because we have soft freeze for alphas
<ogra> meh
<seb128> it's always like this
<ogra> at least the day we actually roll the images it would make sense, so people can upload and we are not affected with the images
<seb128> usually uploads don't break images
<seb128> gtk is a limit case I admit
<seb128> but as said it was now or in 3 weeks
<seb128> and the new version fixes annoying client side bugs
<ogra> yeah, should be fine i luckily retried evo right before you uploaded so it builds now
<Aks> is any1 home ?
<ogra> shriek !
<ogra> asac, why did the buttons get flipped on the "thats embarrassing" page in FF ???
 * ogra curses, just lost his whole session 
<seb128> ogra, what embarrassing page?
<hyperair> seb128: session recovery
<sarts_> seb128: http://1.bp.blogspot.com/_XITx9cKVWJU/SmpOfCSwHTI/AAAAAAAAABE/J-vCCXz3F-k/s1600-h/firefox_crash.jpg
<sarts_> (just googled for firefox embarrassing)
<hyperair> huh why is restore on the left O_o
<hyperair> wasn't it always on the right?
<seb128> restore should be on the right to follow GNOME
<ogra> seb128, but it was on the other side this morning ... i just clicked blindly
<seb128> seems a bug
<ogra> well, restore is on the right now
<ogra> it *was* on the left until we got the official package
<seb128> bug fixed then ;-)
<ogra> pfft
 * ogra steals seb128's session info to have at least *something* :P
<seb128> I don't use sessions
<ogra> you use tabs, dont you ?
<asac> ogra: which page?
<seb128> yes, I close tabs before closing firefox
<ogra> asac, the crash/session recovery
<seb128> but having crash recovering is useful
<asac> ogra: might be that they tried to be more gnome compliant ;)
<asac> the right one is the one people are expected to hit if they dont read
<asac> afaik
<ogra> asac, yes, they should add a <blink> around the button then :P
<asac> ogra: i think its a one time learning effect for folks like you that rely on it ;)
<seb128> yes, right is safe choice
<asac> you will probably not do it again ;)
<chrisccoulson> heh, i always keep tabs open between sessions. i only start closing them when FF is using about 800MB of RAM
<seb128> ie restore session should be there
<asac> yep
<asac> ogra: is that the case?
<ogra> i will *for sure* not do it again :P
<ogra> asac, yes, its the right button now
<ogra> used to be the left one until i upgraded today
<ogra> it would have been a perfect note to add to the "firefox restart required" window
<hile> ogra, I asked about this earlier, see preferences windows: to me all firefox internal buttons were in 'windows order', but print etc of course coming from gnome in 'correct' order
<asac> ogra: restart required window is going away
<ogra> meh, that would have been a good place to warn me
<asac> you should get a "start" thing in firefox
<asac> restart
<ogra> hile, well, i like that the buttons are in proper order now, i just dont like that i lost my session info with about 70 open tabs
<ogra> i kind of abuse FF tabs as todo list and keep stuff open until i cared for it
<hile> yes but if this still affects the internal preferences windowows (could not check) there are other windows now in wrong order for gnome
<hile> one of them was the dialog to choose if you want to open or save a download, cancel is rightmost button - but mybe this was fixed after I last saw a karmic machine
<hile> but, need to catch a train ->
<Laney> can someone reject haskell-edison-api from NEW please?
<Laney> alternatively, can I upload the same version again?
<james_w> yes, you can
<Laney> good news
<cjwatson> ogra: restore's been on the right for some time. If you haven't closed firefox again then your old session might still be around in your profile directory
<cjwatson> ogra: though you're not the first, mdz had the same problem at the sprint; I happened to be sitting beside him and walked him through the recovery
<evand> Updating my karmic desktop results in all windows include the panel disappearing immediately after I enter the keyring password.  So I just have the background and a cursor.  Curiously, alt tab works (even drawing the switcher window and window outlines) and I can enter text into windows, they just don't ever become visible.
<evand> Anyone else experiencing this?
<seb128> evand, xsplash bug
<seb128> evand, you can stop xsplash if you want
<seb128> evand, bratsche is on it I think
<evand> seb128: Awesome!  You're a lifesaver.
<evand> thanks
<seb128> that's a sideeffect of using the default background image
<seb128> it's not obvious the session is loaded with xsplash over it
<seb128> which is what you want when xsplash go away ;-)
<evand> heh
<seb128> cjwatson, slangasek:: I think that's an alpha4 blocker
<seb128> it happens to quite some people today
<seb128> the xsplash thing just discussed
<jdstrand> seb128: hi! so I hope to add an apparmor profile to evince this week (bug #382913). What is the best way to coordinate with you? just upload? debdiff in the bug? bzr branch?
<ubottu> Launchpad bug 382913 in evince "ship enforcing apparmor profile for evince" [Wishlist,In progress] https://launchpad.net/bugs/382913
<slangasek> seb128: ack; is there a bug open?
<seb128> jdstrand, feel free to upload if you don't need a review
<seb128> slangasek, bug #412455
<jdstrand> seb128: cool, thanks. it'll likely be Friday
<ubottu> Launchpad bug 412455 in xsplash "xsplash doesn't timeout to reveal the user session" [Undecided,New] https://launchpad.net/bugs/412455
<davmor2> slangasek: I just got hit by the same thing on unr too
<seb128> jdstrand, don't forget to push your changes to bzr though ;-)
<jdstrand> seb128: ack
<slangasek> seb128: new gtk version> tomorrow, I suppose
<seb128> slangasek, too late
<seb128> slangasek, it's in karmic for some hours now
<seb128> slangasek, sorry but I just uploaded since I wanted that before my holidays and didn't want to upload on friday to run away
<seb128> especially that pitti and mvo are not around either
<seb128> nor is robert_ancell
<seb128> ie that was now or after holidays
 * slangasek sighs
<mneptok> slangasek: too late for the pebbels to vote.
<mneptok> *pebbles
<seb128> slangasek, would now be a good time to upload a gdm fixing gdmsetup crashing on new configs?
<seb128> only change is to gdmsetup and that's not a lib so it should not confuse any cd build
<slangasek> seb128: it's not a good time, no; please wait until the milestone freeze is up
<seb128> ok
<seb128> slangasek, just curious but what sort of issue random app uploads can cause?
<slangasek> seb128: it screws up being able to see when we're done rerolling for critical issues because the set of packages on the ISO is constantly out of date, and if any package happens to get bigger on rebuild (which can happen from incidental toolchain changes, etc), then it may push an image oversized to where we'll have to respin it a second time
<seb128> slangasek, hum, ok
<ogra> cjwatson, hmm, i must have skipped a few upgrades then, i totally rely on update-manager nowadays, if it pops up i upgrade
<slangasek> cody-somerville: xubuntu ISOs are oversized for alpha-4; could you have a look at pruning?
 * cody-somerville nods.
<superm1> slangasek, 20090812.1, should those be what i should ask folks to test on mythbuntu, or is there any other planned re-rolls?
 * ogra sighs, so evo finished building 1h ago on armel ... still no trace of the binary on ports
 * ogra wishesfor a "sync now" button on ports so he can start building images
<slangasek> tkamppeter: we're in a milestone freeze.
<slangasek> superm1: currently I'm aware of no reason to need to reroll mythbuntu, yes; posting it to the tracker now
<superm1> slangasek, ok thx
<tkamppeter> slangasek: Sorry
<tkamppeter> superm1: The bluez changes are accepted upstream now.
<slangasek> tkamppeter: are you subscribed to ubuntu-devel-announce?  A mail is sent there when the freeze starts, and it's added to the channel topic here
<superm1> tkamppeter, great thanks.
<tkamppeter> superm1: So the patch can be dropped as soon as the upstream bluez version with the fix comes out.
<tkamppeter> superm1: The change in the debian/bluetooth.conf must stay as we replace the upstream file completely with ours.
<superm1> okay
<Riddell> mterry: you'll be able to fix the kde ubiquity frontend soon?
<mterry> Riddell, already in bzr
<mterry> Riddell, sorry man.  I only tested in non-English languages
<Riddell> gosh
<Riddell> mterry: rocking, works
<mterry> Riddell, sweet
<Riddell> evand: shall I upload?
<evand> Riddell: I'll sort it out.  I'm just fixing one more bug in the kde frontend
<evand> thanks though
<Riddell> great
<kenvandine> slangasek, can we upload a fix for that xsplash timeout fallback bug to main?
<slangasek> kenvandine: not clear what you're asking - are you asking whether it's ok to upload during the milestone freeze?
<kenvandine> yes... fixes that bug you tagged
<seb128> slangasek, he saks if it's ok to fix the alpha blocker fix now
<slangasek> kenvandine: yes, that's why it's tagged so that we get it fixed before the alpha. :)
<kenvandine> slangasek, figured.. .:)  just checking
<seb128> slangasek, well just asking if now is not the middle of a armel build or something which that would screw
<slangasek> seb128: when it's a milestone blocker, the sooner the better
<seb128> slangasek, ok thanks
<ogra> seb128, well, NCommander was clever and gave back a ton of KDE stuff, the armel buildds will be stuck for a while
<ogra> so upload whenever you want, we're screwed anyway
<ogra> (beyond that gtk will still take at least another 1.5h to show up on ports
<ogra> )
<ogra> the mirroring is very slow
<slangasek> ogra: have you talked to IS about this?  There's no reason, in principle, that ports mirroring should be any slower
<ogra> slangasek, no, will do so after A4
 * ogra makes note on TODO
<ogra> it usually takes 2h after the build finished until it shows up in the archive, whats the proposed time for non-ports ? 30min ?
<slangasek> ogra: oh, there's currently a problem that the publisher is running long (mentioned on #ubuntu-release)
<slangasek> so what's happening is that it takes an average of 2h after the build is done before the publisher finishes
<ogra> ah, so its not ports specific then
<chrisccoulson> slangasek - just looking at bug 412455
<ubottu> Launchpad bug 412455 in xsplash "xsplash doesn't timeout to reveal the user session" [High,Fix released] https://launchpad.net/bugs/412455
<slangasek> chrisccoulson: hi
<chrisccoulson> gnome-session already signals on the session bus when the session is running
<chrisccoulson> or at least that is the intention already ;)
<slangasek> oh?  then why have people been hitting the timeout?
<chrisccoulson> is it because xsplash doesn't listen to it?
<chrisccoulson> my understanding is it waits for nautilus and gnome-panel to signal that they're ready
<slangasek> chrisccoulson: ah
<slangasek> so perhaps this is still a xsplash bug
<slangasek> kenvandine: ^^ opinions?
<kenvandine> slangasek, need to talk to bratsche... i know they discussed that last week
<kenvandine> there was a reason they went with panel and nautilus
<chrisccoulson> slangasek - possibly. i don't know how much it changed over the last few days, but won't it fail if a user isn't using either gnome-panel or nautilus (or isn't using nautilus to draw the desktop)?
<kenvandine> chrisccoulson, it will timeout after 10s then
<kenvandine> at least for now
<kenvandine> they are trying to work out a better way
<chrisccoulson> kenvandine - i'm just about to send an idea to d-d-l which would handle this situation
<chrisccoulson> seeing as everybody took the e-mail from bratsche quite far off-topic
<kenvandine> chrisccoulson, with 0.4 anyway... it will go away after 10s, which is a hack
<kenvandine> yeah
<chrisccoulson> yes, i agree
<chrisccoulson> i've thought of a better long solution but i don't know what upstream will think about it yet
<kenvandine> talk to bratsche about it
<kenvandine> i am sure he would love to hear it
<chrisccoulson> will do. he'll see the e-mail shortly anyway
<chrisccoulson> my idea might be completely rubbish yet. i need to try and write it down though ;)
<seb128> chrisccoulson, topic for #ubuntu-desktop I guess
<seb128> bratsche is there
<chrisccoulson> seb128 - yeah :)
<chrisccoulson> i only came here because slangasek added the gnome-session task to the existing bug report, but i'm not sure there's anything that can be done there currently
<slangasek> seb128: why does the desktop have a separate channel, instead of the desktop developers participating in #ubuntu-devel?
<chrisccoulson> hibratsche
<seb128> slangasek, because you don't want us to flood this channel all day long to know who claims what update
<bratsche> Hi.
<chrisccoulson> hi bratsche even
<chrisccoulson> i should use my space bar ;)
<bratsche> :)
<slangasek> seb128: that's fair, but this is stuff it would be nice to have in the main channel :)
<seb128> right, I guess we hit ETOOMANYCHANS there
<seb128> is dxteam might not be interested so much by distro topics
<seb128> ie they hang out on #ubuntu-desktop and not there
<seb128> #ubuntu-desktop is quite chatty in fact
<seb128> but yeah such discussion should happen there
<slangasek> chrisccoulson, bratsche: in the near term, what do you think should be done with this bug?  Invalidate the gnome-session task and reopen the xsplash task?  Or move the gnome-session task to something else, if we want the signalling to come from "something else"?
<seb128> the issue is that gnome-session knows when apps are registered
<seb128> not when they are done rendering
<bratsche> Right.. I posted on desktop-devel-list to get suggestions on where to fix it, but that thread got derailed quickly.
<chrisccoulson> bratsche - i'm writing my response to the list now :)
<bratsche> Nice
<fta> bug 412631
<ubottu> Launchpad bug 412631 in upstart "Karmic alpha 3 can't boot if daemontools has been previously installed" [Undecided,New] https://launchpad.net/bugs/412631
<fta> Keybuk, ^^
<slangasek> solution: retroactively remove daemontools from the world ;)
<Keybuk> fta: don't do that, then
<fta> it's not mine
<fta> but it should not fail to boot anyway
<cody-somerville> cjwatson, You updated xubuntu-meta using a debootstrap version higher than whats available in Ubuntu.
<cody-somerville> I hope deleting debootstrap-version is safe
<jtimberman> slangasek: and use runit instead ;)
<ScottK> cody-somerville: Just edit it to what you have works too.
 * ScottK already pinged him on the topic.
<chrisccoulson> hey directhex - do you know the procedure for requesting package removals in debian? i looked up the maintainer of libipoddevice in debian, and it is pkg-mono
<slangasek> chrisccoulson: the maintainer should file a bug against the ftp.debian.org pseudopackage, requesting its removal
<chrisccoulson> slangasek - thanks. so i contact the maintainer to do that right?
<chrisccoulson> (that's a silly question actually) ;)
<directhex> mail debian-cli@lists iirc]
<chrisccoulson> directhex - thanks:)
<Mez> how are key revocations done in ubuntu?
<slangasek> key revocations are done at the PGP level
<slangasek> publish your revocation cert to the proper keyservers, and that should be enough
<slangasek> though you probably also want to drop the key from your LP profile
<Mez> slangasek: cheers :D
<slangasek> Mez: for completeness, you probably want to publish to keyserver.ubuntu.com, as I'm not sure how often (if at all) that one pulls from the public network
<Mez> slangasek: publishing to debian first :D
<elmo> slangasek: FTR, it's a part of the public network and so syncs  regularly
<slangasek> elmo: ah, excellent
<lemonade`> hey guys, why don't you have dev man pages installed by default?
<ion> The same reason we donât have a panorama creator or a MIDI sequencer installed by default.
<lemonade`> well the reason I ask is that new programmers have the compiler, but time and time again, they don't know to get the documentation. don't you think the program and the documentation for the program should both be installed, if one is installed by default?
<lemonade`> a lot of the time, they don't even know *to* get the documentation.
<mneptok> lemonade`: an Ubuntu developer that does not know about manpages-dev is in very bad shape
<mneptok> lemonade`: even more so if they don;t know how to find them
<lemonade`> mneptok: yes, they typically are in bad shape if they're just starting. and it's magnified by ubuntu being the go-to distro for people who want to try linux, and have it "just work". I'm thinking this should be included in the same spirit of usability.
<mneptok> lemonade`: you'll need to install build-essential to compile anything. at which point you know about package management.
<maco> does build-essential pull in manpages-dev?
<maco> maybe it should recommend or at least suggest?
<lemonade`> maco: I think a message to the user might help.
<maco> if its suggested, then when you install build-essential it'll mentioni t
<maco> mention but not pull. if its recommended itll be pulled in
<lemonade`> maybe hilight it, so people don't overlook it with the rest of the mostly irrelevant output.
<maco> suggests are listed right above "are you sure?"
<maco> itll say "the following are recommended and will be instaled: <list> the following are suggested but will NOT be installed: manpages-dev ... do you want to continue? [Y/n]"
<lemonade`> it's actually been a while since I used kubuntu... I'm not sure how the details are of apt-get, unfortunately.
<maco> but i dont believe build-essential suggests or recommends it ATM
<lemonade`> maco: yes, I think a prompt would be very effective.
<maco> well the prompt doesnt ask if you want to install manpages-dev, just tells you that its not gonna, but then at least you know it exists and has some relationship to development since youre getting build-essential
<maco> i found out about manpages-dev from a classmate
<lemonade`> maco: so you *wouldn't* be able to decide wether or not to install it at the time of prompting?
<geofft> oh, right, build-essential serves the role of being the set of packages you don't need to include in Dependencies, so you can't actually put it higher than Suggests, if at all
<maco> lemonade`: you could say "no" and add it to the list of what to install
<geofft> you can say +manpages-dev if you're using aptitude cli. (do you also want manpages-posix-dev?)
<lemonade`> maco: oh right, I remember how it worked. :)
<maco> so hit n or ctrl+c and then up and change it from "apt-get install build-essential" to "apt-get install build-essential manpages-dev"
<maco> geofft: cli or tui?
<geofft> I don't use the TUI often enough to remember
<maco> geofft: build-essential uses Depends for all its stuff. im wondering if Recommends or Suggests is better for manpages-dev
<maco> + sounds like the tui...
<maco> Recommends doesnt require it but pulls it if you use apt and its available. suggests just mentions it to the user
<maco> hi matt
<ScottK> maco: Recommends are installed by default
<dtchen> it would be a pretty bad idea to have build-essential recommend manpages-dev
<maco> ScottK: like i said "if its available"
<dtchen> please see http://www.debian.org/doc/debian-policy/ch-source.html#s-pkg-relations
<ScottK> OK
<maco> ScottK: its still not required...like you can use dpkg to install everything in Depends but not Recommends and itll be happy
<maco> looking at dtchen's link
<maco> oh...i see because then the buildd's will want it
<maco> so would Suggests be ok?
<dtchen> i wouldn't add it at all
<dtchen> as Policy states, it has nothing to do with building packages
<maco> does it have anything to do with ubuntu-dev-tools?
<dtchen> if anything, status quo is fine; aptitude install build-essential manpages-dev
<lemonade`> dtchen: but people don't know about it, that's the problem.
<maco> do the manpages-dev say anything that K&R doesnt?
<dtchen> maco: / lemonade`: you do realize that libc6-dev already suggests manpages-dev...
<dtchen> (it also suggests glibc-doc)
<maco> nope didnt know that. i dont do mental dependency resolution. im not apt ;)
<lemonade`> dtchen: no, I'm not aware of the structure of apt beneath the covers.
<maco> but now i do wonder...is manpages-dev more useful than the index of my copy of The C Programming Language?
<lemonade`> maco: I'd think so.
<lemonade`> at the least, it provides system-specific information.
<lemonade`> not to mention, some people don't have that book.
<maco> that is a book any C programmer would do well to invest in
<maco> its the bible
<lemonade`> I don't have that book.
<maco> well unless you dont speak english....in which case i dont think there are l10n manpages either anyway.....
<jtimberman> hah, thats the only C book I have :)
<lemonade`> I got kochan's book when I was starting C.
<maco> i got the o'reilly book first because i didnt know any better
<cjwatson> cody-somerville: yeah, I know, sorry - just nuke it. that wasn't an important bit of the update :)
<cjwatson> none of this should be in build-essential, it should be in a separate package
<cjwatson> as dtchen says, build-essential has one and only one purpose (policy-mandated) and this ain't it - though I do sort of agree it belongs somewhere
<cjwatson> there's an ancient bug about it which has never been fixed because nobody wants to be the guy who owns the development metapackage, which is certain to get flooded by requests for my-favourite-dev-package to be installed :)
<cjwatson> maybe if we named it appropriately ...
<ion> Letâs name it manpages-dev, because the user wants development manpages. Oh, wait.
<lemonade`> as I take it, build-essential is the minimal build environment for installing source packages?
<geofft> I think I'd really prefer a setting in apt or something to say, if I have installed foopackage, also install foopackage-dev and foopackage-doc
<geofft> or perhaps Dev-Recommends/Doc-Recommends, so gcc can Doc-Recommend manpages-dev, and I can configure my system to accept or reject those
<cjwatson> build-essential is defined in policy as follows:
<cjwatson>      It is not necessary to explicitly specify build-time relationships on
<cjwatson>      a minimal set of packages that are always needed to compile, link and
<cjwatson>      put in a Debian package a standard "Hello World!"  program written in
<cjwatson>      C or C++.  The required packages are called _build-essential_, and an
<cjwatson>      informational list can be found in
<cjwatson>      `/usr/share/doc/build-essential/list' (which is contained in the
<cjwatson>      `build-essential' package).[1]
<cjwatson> and yes, together with "Priority: required" packages and apt, it constitutes the minimal build environment installed on the build servers
<cjwatson> adding Recommends or Suggests wouldn't affect that, as it happens, but I still don't think it ought to be overloaded
<maco> ubuntu-dev-tools exists...does that count as the dev metapackage you mentioned above, cjwatson?
<lemonade`> cjwatson: ok thanks.
<maco> oooo shiny! theres a kubuntu-dev-tools too
<lool> cjwatson: Hey the armel image doesn't boot; /conf/uuid.conf has a normally long UUID but blkid and /dev/disk/by-uuid list a 8 chars UUID
<lool> cjwatson: Does that sound familiar?
<lool> Note that these are vfat
<lool> I'm not sure where that can come from; kernel configs perhaps or udev
<maco> maybe thats the vfat label?
<maco> those are limited char[8] iirc
<lool> the UUID I get is UUID="4A83-265C"
<lool> Hmm I get the same UUID on my system
<cjwatson> maco: mm. maybe. I'm not entirely convinced
<lool> Oh sorry I'm mixing apples and oranges
<cjwatson> but it could function as a grab-bag, I suppose
<lool> it's not looking at the actual UUID but at a file .disk/casper-uuid
<maco> cjwatson: kubuntu-dev-tools has a gui for bzr. i cant imagine this is less on-topic
<cjwatson> lool: right, that isn't a filesystem uuid, just a uuidgen one
<maco> (u-d-t just uses normal bzr)
<lool> cjwatson: Ah the UUID is named casper-uuid-babbage
<cjwatson> maco: I'm not really opposed, it's definitely a much better place than build-essential, though it might inspire a reverse gripe as it includes lots of stuff useful for developers of Ubuntu but not developers on Ubuntu
<lool> But the casper code only seems to check for $path/.disk/casper-uuid
<lool> Oh sorry, *
<lool> I'm blind
<cjwatson> ./scripts/casper:79:    for try_uuid_file in "$path/.disk/casper-uuid"*; do
<cjwatson> exactly
<maco> cjwatson: you mean itd get the "but what about my favourite lib's dev headers?!" thing you said above?
<cjwatson> why are you looking at the uuid-matching code in particular?
<lool> cjwatson: Just because the error was Unable to find a medium
<cjwatson> maco: no, reverse, it'd get "but this installs a big pile of stuff that's useful for people developing Ubuntu itself - I just want to write software on Ubuntu"
<cjwatson> but maybe I'm just being oversensitive
<cjwatson> there's probably no way to please everyoone
<cjwatson> -o
<seb128_> hum, can't go back from the partitioning screen on ubiquity
<lool> ogra: Didn't we set livemedia in the past?
<maco> cjwatson: oh hey it does... wow u-d-t has a lot more dependencies thatn k-d-t
<ogra> lool, i dont think so
<geofft> cjwatson, wouldn't adding support for pulling in -doc or -dev stuff when you install the corresponding package work?
<cjwatson> geofft: it's a heck of a lot harder
<cjwatson> geofft: with ten years of experience in Debian I have learned to prefer approaches that work now ;-)
<geofft> hah. good point
<cjwatson> it would require independent UI implementation in umpteen different package management frontends
<Quintasan> debuild -S -s -k$GPGKEY starts with clean and it fails because I didn't build it yet, how do I ommit clean?
<cjwatson> Quintasan: -nc
<cjwatson> Quintasan: but it's a bug in your package if clean fails there
<cjwatson> oh, -nc probably doesn't work with -S actually, so you just have to fix the bug
<lool> cjwatson: Ok; /lib/udev/path_id changed output with new drivers in .31
<lool> Insead of platform-mmc something it returns platform-mxsdhci something
<cjwatson> hah, lovely
<Quintasan> cjwatson: how should I do it then? building creates a build dir in each dir with source, I added find . -name build -exec rm -r {} \; to clean
<lool> Which is the name of the driver for MMC on FSL MXC
<cjwatson> Quintasan: rm -rf
<lool> cjwatson: I guess it's best to workaround it by passing livemedia in the cmdline than pushing casper at this point
<cjwatson> lool: depends on the status of other images, I don't know right now
<lool> Will poke slangasek
<lool> slangasek: ^
<cjwatson> Quintasan: though I can't see a case in which that command would actually fail, since it won't run rm if there are no such directories
<lool> Pushed the casper fix
<lool> to bzr
<cjwatson> Quintasan: does the debian/rules clean output clearly show that that's the command that's failing?
<slangasek> lool: the casper change only affects behavior or armel?
<cjwatson> pretty certain it wouldn't affect anything else
<lool> slangasek: It's in a common code path but I don't expect this match on any other arch
<lool> It's a very specific device name
<ogra> lool, ah, thats why editing /conf/uuid.conf doesnt work for me
<slangasek> lool: upload if you think it's needed, then
 * ogra just repackaed the initrd.lz
<ogra> but doesnt get it mounting either
<ogra> though i dont get why it doesnt work, casper only looks at /dev/disk/by-uuid, no ?
<lool> slangasek: Actually not sure if we need to bother
<lool> slangasek: Just get a nice oops in squashfs if I pass LIVEMEDIA on the kernel cmdline
<lool> hmm might be just a warning
<lool> I get input/output error though
<cjwatson> usually not a good sign
<ogra> well, stdin: error 0 isnt one either
<ogra> additionally the kernel has features that arent suposed to be there
<Quintasan> cjwatson: hmm, I made a simple mistake but I don't know how to fix it, archive untars to rbutil-1.2.2 but source is in rbutil-1.2.2/rbutil and rules try to compile it from rbutil-1.2.2. How do I specify the source tree?
<lool> cjwatson, ogra, slangasek: So I want push casper and consider the A4 image failed
<lool> Needs kernel fixes to boot
<ogra> needs kernel renaming too
<ogra> so we dont end up with -babbage and -imx51 in the same image
<lool> ?
<ogra> we get linux-headers-imx51 and whatnot indise the squashfs
<lool> this is a separate discussion which seems to be moving to a resolution post A4
<ogra> *inside
<cjwatson> Quintasan: $(MAKE) -C <directory> in your build target, usually
<lool> I don't know about linux-headers-imx51
<cjwatson> Quintasan: debian/rules does precisely what you program it to do :-)
<ogra> i told you hours ago in #mobile
<Quintasan> cjwatson: I thought there is a DEB_<something> variable :<
<slangasek> lool: and there's no kernel support for getting this fixed up in time for A4?
<cjwatson> Quintasan: if you're using cdbs, on your own head be it, it's hard to customise
<slangasek> s/kernel support/kernel team support/
<ogra> lool, i'm not sure what else can be affected by that
<ogra> slangasek, it would take half a day to build even if rtg managed to get a new package up
<cjwatson> Quintasan: if you really think it's a good idea to use a system that often requires grepping through make rules in order to figure out how to customise it, that's your call :)
<cjwatson> Quintasan: james_w gave a packaging training talk on debhelper 7 the other day, which is pretty much just as concise and much better-documented
<slangasek> ogra: well, the milestone freeze doesn't prevent someone working on this, in any case
<Quintasan> cjwatson: thanks, I will look into it
<ogra> slangasek, they did a lot of effort to get at least the one with the broken naming out, i'd personally prefer to have their energy focused on getting it right without being in a rush
<lool> slangasek: rtg is gone
<ogra> slangasek, rtg already agreed on the neaming
<cjwatson> Quintasan: as it happens I think DEB_BUILDDIR is the variable in question
<ogra> *naming
<slangasek> ogra: the naming isn't what's breaking alpha4
<lool> slangasek: bjf is bjf-afk
<cjwatson> in debhelper 7 you'd write an override_dh_auto_build: target
<lool> and amitk isn't on IRC
<slangasek> lool: ok then
<ogra> slangasek, the naming made us apply various werid hacks to a formely working system
<cjwatson> Quintasan: (BTW, this is just my opinion of cdbs, I realise other developers here have different opinions, but, hey, I'm the one who was answering ... ;-) )
<Quintasan> I'm not using cdbs :P
<cjwatson> cdbs is the thing that has DEB_* variables
<Quintasan> oh :<
<cjwatson> if you aren't using cdbs, there are no such variables
<cjwatson> override_dh_auto_build:
<cjwatson>         $(MAKE) -C src -f makefile_cptree TREE_TOP=$(CURDIR) \
<cjwatson>                 CC=$(CC) DEBUG="$(DEBUG)" CirclePack
<cjwatson> ^- example of this kind of thing in dh7
<maco> you still use dh_make to do dh7 stuff? dtchen mentioned there being a way to buid up only what you need instead of using dh_make then going through and deleting 2/3 of what it generates
<cjwatson> I don't see much point in dh_make with debhelper 7
<cjwatson> given that the rules file starts with /usr/share/doc/debhelper/examples/rules.tiny and it's probably best not to create other files until you need them ...
<Quintasan> urgh, I don't get most of the discussion -_- That's what you get from using cdbs and pkg-kde-tools all the time :S
<maco> hrm i think we need to poke dholbach into replacing his "how to make a package" video with a non-dh_make version
<cjwatson> the basic idea of dh7 is that standard packages that don't need to do anything surprising just have %: dh $@
<cjwatson> and each override target on top of that represents an unusual thing
<maco> in debian/rules?
<cjwatson> but it's very familiar for debhelper users, because every single thing you can override is "override_" plus a dh_* command name
<maco> is there a way to generate a skeleton debian/control without dh_make?
<cjwatson> so it's really easy to work out general rules for customising
<cjwatson> oh, don't know about that
<cjwatson> maybe somebody should do dh_make -7 :)
<cjwatson> I'm probably a bad example, I write debian/control by hand
<maco> that just means youve been doing this too long
<cjwatson> yes
<maco> i know theres a line about Depends and one about Build-Depends and umm....Maintainer...and a Description
<maco> and some other stuff
<maco> variously named, starting with a capital letter :P
<cjwatson> I was initially deeply sceptical about dh7 but am totally sold on it now, especially after discovering its plugin support
<cjwatson> I'm in the middle of converting lots of d-i over to 'dh --with d-i $@'
<ion> Yeah, dh7 and â--withâ ftw.
 * Quintasan got lot to learn
<cjwatson> well, debhelper's man pages are generally superb, you can follow it all through there
<kklimonda> cjwatson: is it "easier" than using cdbs?
<cjwatson> actually dh7 also has 'dh --sourcedirectory=build $@' and such, in very recent versions
<seb128_> cdbs for the win ;-)
<cjwatson> kklimonda: I certainly find it so
<maco> so if i wanted to say it uses quit id do "dh --with-quilt $@"?
<seb128_> is there somewhere in dh7 where we could add magic for langpacks etc?
<slangasek> kklimonda: shorter debian/rules for the general case, and for the exceptions there are useful manpages
<cjwatson> '--with quilt', but yes
<seb128_> as we do with the gnome.mk in cdbs
<cjwatson> seb128_: we could override its sequencing, in theory anyway
<maco> is there a list of addons? man dh just says "--with <addon>" but doesnt say what those addons are or where to find the list of them
<cjwatson> perhaps best to do it in a gnome plugin
<cjwatson> so you'd have --with gnome, and that'd deal with langpacks
<seb128_> we would have to get that plugin doing something in debian
<seb128_> and convince people to use it
<ion> maco: apt-file search /usr/share/perl5/Debian/Debhelper/Sequence
<cjwatson> maco: I think it's probably a bug that there isn't an easier way, but ls /usr/share/perl5/Debian/Debhelper/Sequence/
<seb128_> so we would just have to enhance the ubuntu version
<maco> cjwatson: or the bug is that the manpage doesnt say to ls that :P
<kklimonda> oh, it's written in perl - /me runs screaming like a girl.. ;)
<cjwatson> the other approach would be some kind of vendor detection in debhelper
<cjwatson> I talked with Joey very very briefly about that at DebConf, but haven't had a chance to follow through yet
<cjwatson> actually for the purpose of erasing our last delta against debhelper
<ion> /usr/share/doc/debhelper/PROGRAMMING.gz kind of points to that, and dh(1) points to PROGRAMMING. :-P
<cjwatson> the other approach would be a dh_langpack that's in the default sequence but I'm a bit scared of Joey shouting at me for changing the default sequence :)
<maco> little bit roundabout...
<cjwatson> I think again I'd probably want to get that into debhelper upstream with vendor detection
<cjwatson> dh_langpack would probably be useful anyway
<seb128_> would be nice
<cjwatson> BTW I don't know if people noticed amid the annoyance with my broken debootstrap version, but there's now a --with germinate to make generating metapackages from seeds trivial
<cjwatson> http://paste.ubuntu.com/252198/ was my first cut at merging our dh_installudev diff but I still need to do some polishing
<cjwatson> kklimonda: I generally find I only need to look into the internals when actually writing extensions; the documentation is normally very precise about what it does
#ubuntu-devel 2009-08-13
<TheMuso> slangasek: studio will have to be respun due to the new kernel not being out of the NEW queue when .1 was spun.
<slangasek> TheMuso: respinning now
<TheMuso> slangasek: thanks
<slangasek> TheMuso: posted to the tracker
<slangasek> hrm, hang on
<slangasek> just got a failure mail; so I guess the ones I posted are in fact the same ones as before
<slangasek> yeah, linux-image-rt still uninstallable
<TheMuso> hrm I'll check that out
<slangasek> still digging here
<slangasek> ah, it's 20090813 now, isn't it :)
<slangasek> ok, trying again
<slangasek> right, got past the breakage this time - must've been a transient connectivity problem with lp
<TheMuso> ah ok.
<TheMuso> I was going to say all looks ok here, the kernel has been p ublished, the dependencies look correct...
<slangasek> right, the packages were uninstallable because the isos didn't really get rebuilt
<TheMuso> ah ok
<slangasek> TheMuso: ok, really posted now
<TheMuso> slangasek: ok thanks.
 * TheMuso tries out zsync for the first time.
<ebroder> has anybody done any experimentation with running Ubuntu's debian-installer as a Xen domU?
<ebroder> (a la http://wiki.debian.org/DebianInstaller/Xen)
<dholbach> good morning
<\sh> moins
<AnAnt> could someone sponsor this merge request, it's been filed about 2 weeks ago: 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
 * Hobbsee looks at it
<AnAnt> thanks
<StevenK> irssi is in main, and main is frozen
<AnAnt> frozen since when ?
<AnAnt> isn't feature freeze near end of august ?
<soren> Alpha freeze. Since Tuesday.
<Hobbsee> no, alpha 4
 * Hobbsee will sanity-look, and upload it later
<soren> It'll be over some time today, probably.
<AnAnt> oh, it's still Thursday
<AnAnt> sorry, I thought it was friday
<\sh> Hobbsee: if you are in sponsor more ;) bug #412861 is needing love, too ;)
<AnAnt> Hobbsee: ok, thanks
<ubottu> Launchpad bug 412861 in libqt-perl "libqt-perl_3.008-4 FTBFS" [Undecided,New] https://launchpad.net/bugs/412861
<\sh> s/more/mode/
<Hobbsee> \sh: nah, not in sponsor mode.  and can't you sponsor?
<\sh> Hobbsee: not for main
<Hobbsee> oh
<\sh> s/oh/doh/ ;)
<maco> oh god too many slashes in too many directions
 * StevenK slashes maco 
<Hobbsee> AnAnt: that doesn't look right - I highly doubt 03firsttimer_text ever gets applied.
 * Hobbsee will fix it
<AnAnt> ok, thanks
<Hobbsee> eh, crap, tha'ts quilt
 * Hobbsee goes to look up how quilt applies patches
<AnAnt> I can work on it
<StevenK> Hobbsee: "Badly"
<Hobbsee> AnAnt: well, i've looked at it this far.  may as well do a full upload ;)
<spm> StevenK: is that a technical description or a personal observation? idly curious. :-)
<Hobbsee> StevenK: agreed ;)
<AnAnt> ok
<maco> oh oh i can get quilt import to work consistently now :D (this is new since UDS when some of you heard me whining about how hard quilt is)
<StevenK> spm: It's both, since I'm clever
<\sh> quilt and hard?
<StevenK> quilt isn't hard, it's just braindead
<spm> StevenK: apologies. I should have realised by now. :-P
<StevenK> spm: s/clever/bitter/ to taste
<AnAnt> StevenK: you prefer what simple-patchsys ?
<StevenK> AnAnt: Heck no, CDBS is a broken black-box
<AnAnt> StevenK: dpatch ?
<StevenK> debhelper 5 or 7 with dpatch
<AnAnt> ah
<maco> \sh: ive managed to bungle up quilt so thoroughly before that scottk couldnt undo it after a few hours of trying. running the commands in the wrong order tends todo that :P
<ScottK> Quilt is the Git of patching systems and I don't mean that in a good way.
<Hobbsee> simple-patchsys is nice, when it works
<StevenK> Bwaha
<Hobbsee> oh, go away postfix.
<maco> oh postfix...thats a mail thing right?
<maco> that means ScottK knows about it?
<ScottK> Only when it's working
<Hobbsee> yeah - installed when you install devscripts
<StevenK> Hobbsee: And when CDBS isn't obstreperous
<AnAnt> ScottK: ah, we really do differ !
<Hobbsee> hahahaha
<Hobbsee> StevenK: well, yeah
<StevenK> Which is well, all the time
<AnAnt> I prefer quilt & git
<AnAnt> over dpatch & bzr
<ScottK> AnAnt: I saw you took care of the blueman sync from Debian.  What would you think about dropping show-only-in-gnome from the .desktop files.  I tested it and it works better in KDE than kdebluetooth,
<AnAnt> I find them easier to deal with
<StevenK> I'm sorry, my brain just page faulted
<StevenK> You just said git and easier in one sentence
<ScottK> I'm sure I'd be fine with Git if I used it regularly enough to not have to relearn it every time I use it.
<AnAnt> StevenK: hehe
<AnAnt> ScottK: ok, I'll look at that
<\sh> maco: lol...well, it takes some time to get used to quilt
<AnAnt> ScottK: btw, can you mean this in the blueman thread ?
<Hobbsee> AnAnt: oh, it's right.
<AnAnt> ScottK: although I don't think that this would make a difference
<\sh> maco: but if you want to learn from the masters of patch systems, check the python source package dpatch system ;) that's one of my favorites how to use dpatch in a let's say "doko" way ;) it took my brain some time to understand the logic behind it..since then , doko is my patch system master :)
<AnAnt> ScottK: since upstream responsiveness is really important indeed
<ScottK> AnAnt: Not to make it default, but just to work.
<ScottK> kdebluetooth is pretty broken right now.
 * Hobbsee moves irssi to to_dput/ in the hope she remembers to upload it
<AnAnt> ScottK: erm, I'm not good at CDBS !
<ScottK> cdbs-edit-patch and edit the .desktops.
<StevenK> And then exit the subshell
<AnAnt> Hobbsee: I'll remind you tommorrow (I hope)
<Hobbsee> AnAnt: cool, OK
<\sh> now for some more interesting work...more puppet love
<AnAnt> ScottK: is there a bug filed about this ?
<StevenK> \sh: Now now
<Hobbsee> \sh: sponsor!  sponsor!
<ScottK> AnAnt: No
<Hobbsee> \sh: and grabbed your patch too
<lifeless> win 71
<AnAnt> ScottK: could you do so ?
<ScottK> Sure
<ScottK> AnAnt: I ended up just expanding on Bug #399129, but it's there now.
<ubottu> Launchpad bug 399129 in blueman "Blueman doesn't start in Xfce sessions" [Undecided,Confirmed] https://launchpad.net/bugs/399129
<\sh> Hobbsee: thx a lot :)
<Hobbsee> \sh: y/w
<AnAnt> ScottK: I should just attach a debdiff to that, right ?
<ScottK> AnAnt: Yes.  I'll sponsor it.
<Hobbsee> oh, screw you, launchpad
<Hobbsee> you have improved, but that bug is still here
<StevenK> Hah
<Hobbsee> search results -->  reorder == search terms lost.  Fail.
<AnAnt> ScottK: done, also submitted patch to debian
<ScottK> AnAnt: Thanks.  I'll look at it, but maybe not until tomorrow as it's very late here.
<AnAnt> ok, I gotta run too
<AnAnt> bye
<ScottK> Debian may have a different view as for KDE this is very much a workaround for broken kdebluetooth
<AnAnt> ScottK: well, a KDE/Xfce user on Debian might still like to have blueman
<ScottK> True, but if kdebluetooth was working great, having the Gnomish applet appear in a KDE session might be troubling.
<AnAnt> ah, ok
<ScottK> Still it's probably good to get them to think about it.
<AnAnt> ok
<AnAnt> so, I've got to leave now
<AnAnt> bye
<dholbach> Hobbsee, quadrispro: thanks for doing some sponsoring right now! :)
<Hobbsee> dholbach: consider it my yearly sponsoring quota ;)
<dholbach> more! more! more!
<quadrispro> lol
<quadrispro> dholbach: thanks for the add (on facebook)! :D
<StevenK> quadrispro: Now you'll get bugged about sponsorship on IRC and facebook
 * StevenK hides
<dholbach> StevenK: sponsoring!
<dholbach> StevenK: sponsoring!
<dholbach> StevenK: sponsoring!
 * quadrispro screaming: NOOoooo
<Hobbsee> dholbach: actually, make that 3 bugs.  That's gotta be the yearly sponsoring quota ;)
<dholbach> for your convenience: http://people.canonical.com/~dholbach/sponsoring/
<quadrispro> mmmh... I need a tester...
<maco> your fave link :P
<Hobbsee> ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/quassel/+bug/374802 is probably your fun
<ubottu> Launchpad bug 374802 in quassel "Consider building versions of quassel and quassel-client without KDE dependencies" [Wishlist,Confirmed]
<ScottK> Hobbsee: Last I saw the patch there it switched from using cdbs to dh and that's a problem as we have a lot of kde specific magic in cdbs we'd lose.
<Hobbsee> ScottK: then comment / reject it?
<Hobbsee> ScottK: in the spirit of killing easy things off that list
<ScottK> OK
<maxb> Where would I find devicekit-power gurus?
<seb128> maxb, bugs.freedesktop.org?
<maxb> fair enough. I was wondering if there was anywhere on IRC I couldd go for pointers in debugging why it doesn't like my battery
<maxb> lp 384304 ftr
<ubottu> Launchpad bug 384304 in devicekit-power "devicekit-power fails to realize I'm on battery" [Undecided,New] https://launchpad.net/bugs/384304
<seb128> not sure if they have an irc channel
<seb128> in ubuntu pitti is looking at devkit but he's on holidays
<maxb> ok, I'll try my luck in bugzilla then
<dupondje> https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/397776 <- this is a quite important bug that needs to be fixed imo :(
<ubottu> Launchpad bug 397776 in brasero "Unable to find any device" [Low,Confirmed]
<james_w> how can I find the I/O load of a machine without using any fancy tools?
<james_w> e.g. I know iotop, but it's not installed on this box
<Daviey> james_w: /proc/diskstats and awk :)
<james_w> thanks
<Daviey> james_w: http://erk.daviey.com/diskio.txt
<james_w> thanks
<bankix> Hi.
<bankix> I'm just about creating a live system basing heavily on ubuntu. Due there is no way in exchanging the kernel afterwards, but possible to install other new packages on a persistent filesystem (e.g. usb stick), I want apt to keep the kernel I delivered and do not install a newer one, which would only be a waste of space. I set linux-image-*-generic, linux-image-generic and linux-generic on hold, but an apt-get dist-upgrade still wants to install me a 
<amitk> wohoo, first nautilus crashed (apport pops up, I lose theming), then gnome-settings-daemon crashed (apport pops up), in the meanwhile firefox crashes while apport tried to file a bug and apport popped up
<slangasek> amitk: heh
<ogra> we call that apport *integration* ;)
<bankix> ..found the problem. I should do a "apt-get upgrade" and no "dist-upgrade". Thanks for listening.
<bankix> Bye...
<bankix> Sorry, I've got another question: When running "apt-get update" via chroot (while mounted dev, sys and proc via --bind so the chroot has access to them) it will (re-)start some services -- cron, udev, acpid, and some more. How can I suppress this?
<cjwatson> I think what you're supposed to do is write a /usr/sbin/policy-rc.d script that just does 'exit 101'
<cjwatson> /usr/share/doc/sysv-rc/README.policy-rc.d.gz
<cjwatson> it is possible that this is marginally overengineered ...
<bankix> Thanks!
<bankix> I'll give this a try.
<dholbach> Packaging Training Session "On-Call Review" with cjwatson, seb128, james_w and me in 12m in #ubuntu-classroom
<tkamppeter> ccheney: hi
<liw> cjwatson, it's so marverlously flexible nobody uses it, yes
<mdz> asac, https://bugs.staging.launchpad.net/ubuntu/+source/network-manager/+bug/412226 (notice the automatic driver-ndiswrapper tag)
<ubottu> Launchpad bug 412226 in kdebase "Dolphin icon mouseover indicators are very laggy with KDE 4.3.x and Karmic on AMD64" [Undecided,New]
<slangasek> liw: there's nothing quite like a hammer with a slinky for a handle
<liw> however, at least the "exit 101" solution for preventing any services from starting in a chroot is easy to implement
<mdz> asac, it also adds rfkill info, crda, etc.
<asac> nice
<mdz> and the overall source_network-manager.py is much shorter
<mdz> asac, I pushed those hanges to ubuntu.head, hope that's ok.  if you'd rather I send merge requests, I can do that
<tkamppeter> ccheney: I have a question about OpenOffice.org bug 94173
<ubottu> Launchpad bug 94173 in gnome-panel "does not fill screen" [Low,Invalid] https://launchpad.net/bugs/94173
<tkamppeter> ubottu, it must be http://www.openoffice.org/issues/show_bug.cgi?id=94173
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<ubottu> OpenOffice.org bug 94173 in gsl "Let OpenOffice.org send the data in PDF format to the printing system" [Enhancement,New: ]
<asac> mdz: thats ok. i can add you to NM team officially too (seems you can push everywhere?)
<asac> mdz: but please use a proper email in your commits ;)
<asac> https://code.edge.launchpad.net/~network-manager/network-manager/ubuntu.head
<asac> some email that is linked to a launchpad account
<mdz> asac, fixed my .bazaar.conf on this machine, sorry
<mdz> asac, I can uncommit and recommit to fix it
<asac> ok
<asac> that would beautify it ;)
<asac> mdz: oh. we also add the email to the [...] usually ... because in that way it also gets directly linked from the uploaded changelog
<asac> but i can do that when i next touch it for you too
<asac> (probably dch should be improved to do that)
<asac> thx for your work on this
<mdz> asac, ok, I made those changes. look ok now?
<asac> mdz: yeah. thanks. i will probably add a bunch of more drivers (if not all that i find)
<bankix> cjwatson: Thanks again, that's what I was looking for. Worked like a charm.
<asac> maybe that could be moved to the apport wifi hooks too at some point?
<mdz> asac, yes, that would be great, if you could agree with the kernel team on a standard set of tags
<mdz> Keybuk, can you give us a hint on what should replace the lshal code in source_network-manager.py ?
<bankix> Bye.
<asac> i thought about something like udevadmn info --query=all --attribute-walk --path=/sys/class/net/*
<asac> but that doesnt work. not sure if we can refer to "class" paths directly in --path ... or if we need to resolve the right sysfs path
<mdz> asac, this works, but produces a lot of data:
<mdz> for dev in /sys/class/net/*; do udevadm info --query=all --attribute-walk --path=$dev; done
<mdz> we probably want to parse that into some easier-to-read form
<asac> seems udevadm info --query=all --path=/class/net/eth2 --attribute-walk works
<mdz> (the lshal form was not that great either)
<asac> hmm i think its ok for now ... not so sure what type of info we will need, so better have more. the other question is how we can find a good subset of /class/tty/* things without requiring that the modem prober worked well (which adds a ID_NM label)
<asac> attaching all ttys doesnt sound like the right approach ;)
<Keybuk> mdz: what's source_network-manager.py ?
<asac> apport hook of NM
<asac> Keybuk: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu.head/annotate/head%3A/source_network-manager.py
<Keybuk> right that kind of udev query would work fine
<Keybuk> someone enterprising could do a python-udev, that would be fun ;)
<mdz> Keybuk, the apport hook for network-manager, which you'll have on your system in /usr/share/apport/package-hooks
<asac> ok so i would suggest to use the query above for net devices and then think a bit about the modem ttys
<asac> probably start with those already identified as NM_ modems
<asac> but i have to think about it. the udev output is particular useful to have for those modems not properly detected
<mdz> asac, https://wiki.ubuntu.com/DebuggingNetworkManager refers to /lib/udev/nm-modem-probe, but i don't have that on my system
<mdz> that seems like useful info to add to the hook
<asac> mdz: we dont have that anymore - since modemmanager landed
<asac> i will check with nm upstream what they think should be added for modems
<slangasek> plars: does bug #411091 happen on each suspend/resume?
<ubottu> Launchpad bug 411091 in netbook-launcher "netbook-launcher crashed with SIGSEGV in g_cclosure_marshal_VOID__OBJECT()" [High,Triaged] https://launchpad.net/bugs/411091
<mdz> asac, at the least I think we should add modemmanager to the syslog regex
<asac> yeah
<asac> wonder if there is anything we can do in apport so users get to know that modem related bugs should now get filed against modemmanager package
<seb128> asac, you can do interactive hooks or be smart
<asac> seb128: yeah. but i think we should need to check the title entered for words like "3g" and "modem"
<mdz> asac, I've added modem-manager to the regex in apport, will be in the next upload
<seb128> asac, why not just have a small interactive hook?
<seb128> asac, ask "is your issue a 3g modem one"
<mdz> asac, seb128++
<asac> i dont know about that feature ;)
<asac> would be great for sure
<mdz> asac, we could easily add a hook which asks the user "which connection are you having a problem with?"
<seb128> asac, ubuntu-bug -p totem
<asac> otherwise network-manager will become a "catch all" package similar to firefox
<mdz> then change the package, tags, debug info, etc. as appropriate for that
<asac> sounds good
<mdz> asac, could let them select either an NM connection profile, or a network interface
<asac> hmm. i think that would be great in the long run. but for now we could also ask for "what type of connection do you have a problem with: a) wired, b) wifi, c) modem/3g, d) VPN"
<seb128> asac, you have details in package-hooks.txt.gz
<seb128> on what questions you can ask, etc
<seb128> or you can look to totem or devicekit-disks for examples
<seb128> seems pitti didn't upload the devicekit one
<asac> thx will check that out ... and hoping for more contributions ;)
<afmacedo_> question: Is Ubuntu willing to make packagekit the default package-manager?
<afmacedo_> or that's gonna work for Kubuntu only?
<seb128> does it handle debconf questions, etc now
<ccm> seb128: finally got a full backtrace - interested before i post it?
<seb128> slangasek, when do you expect the freeze to be over?
<ScottK> afmacedo_: That presumes it actually works for Kubuntu.
<seb128> ccm, yes on pastebin
<ccm> seb128: yes, of course, wait a sec
<ccm> *giggle*
<ccm> 5988 segmentation fault (core dumped)  gedit gdb-firefox5.txt
<ccm> not my day
<afmacedo_> ScottK: To be honest, I don't remember having it updating a package which demands debconf interaction
<beuno> slangasek, bug 412925 is going to be... hard to address
<ubottu> Launchpad bug 412925 in launchpad "new ajax interface for changing bug statuses is too easy" [Undecided,New] https://launchpad.net/bugs/412925
<ScottK> afmacedo_: It's happened to me.  The lack of security concerns me the most.
<beuno> slangasek, it will require a lot of creativity at least
<ScottK> Also there's no equivalent of dist-upgrade in kpackagekit last I tried it.
<afmacedo_> I see...
<ScottK> fwiw, adept 3 had the same security issues (that are at least partially addressed now).
<james_w> that's being partially implemented now
<james_w> (dist-upgrade)
<ScottK> james_w: Which?  Security or dist-upgrade?
<ScottK> Ah.
<ScottK> Excellent.
<ccm> seb128: http://paste2.org/p/376339
<ccm> seb128: currently a lot of applications are crashing here
<ccm> seb128: looks like libpango
<cjwatson> afmacedo_: we've talked briefly about tunnelling debconf over d-bus or something so that packagekit can handle it properly, but to my knowledge nobody has done the work
<afmacedo_> ok... so if I got it right: kpackagekit handles debconf already AND dist-upgrade is partially implemented, is that correct?
<afmacedo_> cjwatson: got it
<cjwatson> how does kpackagekit handle debconf?
<seb128> ccm, dpkg -l libpango1.0-0
<james_w> cjwatson: it doesn't
<ScottK> afmacedo_: I don't think it does debconf
<cjwatson> that's what I thought
<afmacedo_> cjwatson: same here
<cjwatson> if anyone figures it out, as debconf co-maintainer I'd be happy to review patches
<ccm> seb128: ii  libpango1.0-0    1.25.2-0ubuntu2  Layout and rendering of internationalized text
<james_w> there's a further issue in that the idea of debconf conflicts with the model for user interaction in packagekit
<ScottK> beuno: At least have the ajax window open with the current status under the mouse so an accidental unclick doesn't change status.
<seb128> ccm, could you use pastebin.ubuntu.com ratheR?
<seb128> ccm, no way to copy from that weird pastebin you use
<ccm> seb128: i would, but the browser crashes
<seb128> or rather it changes formating
<seb128> hum ok
<ccm> seb128: so i used gnome-do as a work around
<ccm> seb128: i can mail you the file
<seb128> anyway wait for 1.15.3
<cjwatson> ccm: http://people.canonical.com/~cjwatson/ubuntu-paste
<beuno> ScottK, that can be tricky, as we would either need to move the mouse, or move the overlay. But yes, we should find a way to prevent accidental changes as much as we can
<seb128> ccm, some crashers are fixed that
<seb128> but it's blocked due to alpha freeze
<ccm> seb128: okay
<ccm> cjwatson: thank you!
<ccm> seb128: okay, there is the new paste http://paste.ubuntu.com/252531/
<ccm> cjwatson: works like a charm
<ccm> seb128: will wait for the update then
<cjwatson> wow, gdb output that's been sent into RTL is very very confusing to read
<dholbach> james_w, seb128, cjwatson: the log is up at https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-13 - thanks again
<dholbach> james_w, seb128, cjwatson: reading it again it doesn't strike me as too confusing - what do you think?
<seb128> dholbach, thanks
<seb128> dholbach, looks good to me too
<dholbach> seb128: I guess we should have those sessions more often - it was a lot of fun :)
<seb128> dholbach, yeah, twice a month or something
<seb128> dholbach, or maybe some one hour sponsoring, ftbfs etc sprint
<seb128> so some people work together to get things done
<dholbach> yeah, I'm not sure myself what the best format for it is
<dholbach> in the ideal world (as I imagine it), we'd have a 24/7 channel and always have a few people whose name is in the topic to indicate they're reviewing right now :)
<seb128> ;-)
<ccm> seb128: filed https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/413098 - just for tracking this down
<ubottu> Launchpad bug 413098 in pango1.0 "libpango1.0-0 on karmic crashes (e.g. Firefox)" [Undecided,New]
<seb128> ccm, thanks
<cjwatson> dholbach: actually I think that'd be brilliant
<seb128> dholbach, it seems it's difficult for some people to spend sponsoring time
<seb128> having a one hour slot with some people and getting some animation on IRC could be good
<seb128> we would rotate people, that would give some action and get some sponsoring done
<dholbach> even if it every now and then (on the WE for example) it says "current reviewer: -"
<dholbach> seb128: I'd hope those people very soon realised that should MAKE MORE TIME to do reviews :-)
<ccheney> tkamppeter: OOo bug tracker or lp?
<seb128> dholbach, well the think is that it's easy to forgot those
<ccheney> tkamppeter: ah i see it now
<seb128> or to put them low in your todolist
<cjwatson> dholbach: do we have #ubuntu-reviews already?
<seb128> when having a defined slot and some animation can motivated to be there
<tkamppeter> ccheney: OOo bug tracker, I have posted the link here.
<ccheney> tkamppeter: ok what about the bug, i read it
 * cjwatson shuffles his scheduled weekly sponsorship a few hours earlier so that it clashes less with TB meetings
<dholbach> cjwatson: not yet :)
<tkamppeter> ccheney: Seems that they want to know whether you already started writing a patch or whether they need to start from the beginning, so that they do not do work which you have already done.
<dholbach> or well... I'm there now
<cjwatson> dholbach: wanna?
<cjwatson> I realise it duplicates #ubuntu-motu a bit at the moment
<ccheney> tkamppeter: ok followed up and mentioned i have no patch
<tkamppeter> ccheney: Thanks.
<dholbach> cjwatson: I just brought it up with the packaging training coordinators, but I'd like to bring it up on ubuntu-devel@ for discussion too - somehow we need to get some kind of rotation going
<ccheney> tkamppeter: looks like it won't make 10.04 from what he said
<ccheney> tkamppeter: feature freeze for 3.2 (Ubuntu 10.04) is Sept 21
<tkamppeter> ccheney: What exactly means CWS?
<tkamppeter> ccheney: Is this a bigger effort, so that it will only go into 3.3 or 4.0?
<ccheney> tkamppeter: like a revision control branch for development work
<ccheney> tkamppeter: i think the only person even requesting it is you so you have to find someone to actually do the work i suppose?
<cody-somerville> superm1, ping
<superm1> cody-somerville, pong
<ccheney> tkamppeter: its often hard to get even bugs fixed in a timely manner in OOo via upstream
<tkamppeter> ccheney: I have a person who will perhaps soon work on OOo using the Common Printing Dialog, so he will probably do the PDF output in the same effort then.
<tkamppeter> ccheney: Then a new bug report with attached patch could be opened, perhaps the only form of bug report were they do anything.
<ScottK> tkamppeter: I recently had need to set up an HP printer on the network from Kubuntu and also from OS X.  I find if we want to 'match' the OS X user experience we will have to worsten printer setup considerably.
 * ScottK never did get OS X to work.
<ccheney> tkamppeter: yea probably so :-\
<tkamppeter> ScottK: So it means printer setup is much better in Ubuntu than in Mac OS X?
<ScottK> tkamppeter: Yes.
<tkamppeter> ScottK: And our goal is not to copy other OSes but to be better.
<ScottK> Agreed.
<ScottK> On Kubuntu it was just click, click, click until done.
<ScottK> On OS X it was the Windows like experience of no driver, hunt it down on the HP web site, download 100+MB file, install, and then have it still not work.
<tkamppeter> ScottK: Recently, one of the managers of the LF asked me why I do the high effort with OpenUsability for the Common Printing Dialog, the printer industry wants standard technologies and therefore I could simply copy a Mac or Windows dialog.
<ogra> well, we could cut out the clicking :)
<ScottK> tkamppeter: Heh.  Well they could copy us too.
<ccheney> Mac has about the same or less market share as linux, so just get open printing dialog done and have them switch instead ;-)
<GuyFromHell> Can anyone point me to the patch ubuntu is using on pidgin so you don't get ugly notify-osd notifications
<GuyFromHell> it doesn't seem to be in pidgin's .diff
<Laney> try patches.ubuntu.com
<GuyFromHell> Laney, wow shiny, never new that existed. i'll look through it
<seb128> slangasek, do you have any idea about when the freeze will lift?
<dholbach> bdrung, nixternal, james_w, bdmurray (and everybody else who's interest): would you guys have a few spare minutes to have an impromptu meeting to talk about Harvest UI in #harvest
<GuyFromHell> damnit, i found it. it's in a patch that also makes the thing require indicator applet >_>
<dholbach> to give a bit more background on the above: http://daniel.holba.ch/harvest was ported to Django already, but we want to explore how we want a future UI to look
<ScottK> GuyFromHell: There's a pidgin-libnotify (or something similar) package that if you remove you'll get no notifications.
<GuyFromHell> ScottK, Right, but I've compiled notify-osd and getting the ugly popups from pidgin. I've found the patch of pidgin-libnotify but the patch also makes pidgin-libnotify depend on indicator-applet, which my distro doesn't have
<ScottK> GuyFromHell: Oh.  Yes, well the presence of that is what stops the fallback dialogs, I think, but you would probably have more luck in #ayatana as they are upstream from this stuff
<GuyFromHell> Ah, that's probably what the maint was thinking. I didn't htink about it like that.
<slangasek> seb128: probably shortly after we know whether UNR should get a respin
<seb128> slangasek, any chance that will be today?
<slangasek> certainly
<seb128> cool
<slangasek> beuno-afk: 412925> less AJAX seems like a reasonable solution to me ;)
<jdstrand> slangasek: hi! re bug #305264, I think we need to get this straightened out because I've got gnutls updates that I need to prepare. my last comment in the bug:
<ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [High,Fix committed] https://launchpad.net/bugs/305264
<jdstrand> We need to push gnutls12 in Dapper and gnutls26 in Intrepid in -proposed to -security since these fix CVE-2009-2409. Dapper should not be a problem with openldap since openldap uses libssl0.9.8 on Dapper. For Intrepid, openldap will need to be copied as was done with Hardy.
<slangasek> jdstrand: so the status of that currently is that there are packages in -proposed that haven't cleared validation?
<jdstrand> slangasek: this bug is a mess... so let me try to recap
<jdstrand> slangasek: as you probably recall, gnutls made some changes that broke openldap
<jdstrand> slangasek: so we had to weigh the benefit of the security update with the brokeness
<jdstrand> slangasek: due to upstream having quite a few problems with regressions with one of the CVEs the -security updates were trying to fix, I uploaded them to -proposed for wider testing
<jdstrand> slangasek: this was ages ago
<jdstrand> slangasek: mathiaz prepared openldap packages to work with the new gnutls in -proposed
<jdstrand> (for hardy afaik)
<jdstrand> slangasek: gnutls was pocket copied to -security on hardy
<jdstrand> slangasek: I thought mathiaz' openldap2.3 went to hardy-updates too... (let me check, the bug still shows as Fix Committed)
<slangasek> openldap2.3 has a newer version in hardy-updates than hardy-proposed
<slangasek> er, than hardy-security
<jdstrand> slangasek: https://bugs.launchpad.net/ubuntu/+source/gnutls12/+bug/305264/comments/35 indicates that we had some intrepid testing (the reporter developed the patch upstream, but the 'Thanks' wasn't exactly clear on this point)
<ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [High,Fix committed]
<jdstrand> slangasek: yes, the hardy task for openldap should be closed
<jdstrand> slangasek: dapper can safely go to -security IMO, because it won't break openldap, which was the only thing broken by the gnutls updates, because it still uses libssl
<jdstrand> slangasek: which leaves intrepid
<jdstrand> slangasek: I've updated the hardy openldap task
<slangasek> ok
<jdstrand> slangasek: what is your opinion on dapper gnutls12? intrepid gnutls26 and openldap?
<slangasek> so we want gnutls26 and openldap copied from intrepid-proposed to intrepid-security && intrepid-updates?
<jdstrand> slangasek: yes
<jdstrand> slangasek: and really, openldap2.3 should be copied from hardy-updates to hardy-security, while you are at it
<slangasek> ok
<kees> jdstrand: is that safe?  i.e. it's not built with libs from -updates ?
<jdstrand> kees: gnutls26 all went through ubuntu-security-proposed
<jdstrand> kees: and was pocket copied to -proposed later
<slangasek> jdstrand: how quickly do you need this?  I need an hour or two to finish alpha4 publishing, otherwise if this needs done sooner I can give it my full attention now
<jdstrand> slangasek: if you'd like, I can take care of it all... I'm not in ubuntu-sru, so I wanted to talk to you
<slangasek> jdstrand: well, -security trumps -updates anyway, so if you're satisfied that these are ready to go to -security, then yeah, go for it
<jdstrand> slangasek: ok, thanks
<jdstrand> kees: though your point is taken on openldap-- I'll make sure it is ok for -security
<mynameisdeleted> latest ubuntu 9.04 and 9.10 totally suck over nfs+nis
<mynameisdeleted> mostely has to do with none of the sound-libraries workign I think
<mynameisdeleted> oss works but alsa-lib is messed up 100% along with anythign built on it such as pulse audio or port audio or audiolib or anything
<mynameisdeleted> does anyone know why this is?
<mynameisdeleted> I guess thats a #alsa question
<mynameisdeleted> is there a network file system for nis+shared home dirs taht is ubuntu friendly?
<mynameisdeleted> and keeps alsa apps working nicely?
<mynameisdeleted> maybe its no pipes or something
<slangasek> mynameisdeleted: I've not heard of any such problems, and NFS is supposed to give complete POSIX semantics as a filesystem.  I'd suggest opening a bug report against pulseaudio if that's what you're having problems with.
<mynameisdeleted> it fails on mplayer with -ao alsa
<mynameisdeleted> but not oss
<mynameisdeleted> same with the systemsettings
<mynameisdeleted> if I test an oss backend thats the only one that works
<mynameisdeleted> I have no_root_squash and rw
<mynameisdeleted> nto sure if async is useful or matters
<mynameisdeleted> I wonder if the same happens over samba
<mynameisdeleted> ... I know samba home dir is terrible
<mynameisdeleted> maybe afs is better
<mynameisdeleted> or pvfs
<mynameisdeleted> aroroa is mesed up by this,... as is firefox which opens a sound library
<mynameisdeleted> if it was just videogames and music players which haad yet to e switched to oss only mode I'd be happy
<mynameisdeleted> konqueror works great if I set to use the oss backend for kubuntu
<slangasek> mynameisdeleted: this isn't a help channel, and no, there's no reason this shouldn't work on NFS and therefore no reason to think another network filesystem would work better; as I said, you should file a bug report about your issue
<slangasek> seb128: unfrozen
<bryce> hrm, launchpadlibrarian.net isn't responding
<seb128> slangasek, thanks!
* slangasek changed the topic of #ubuntu-devel to: karmic alpha-4 released | Archive: open, DebianImportFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<kklimonda> kees: wrt django - would enabling test suite also make it possible to use point releases instead of backporting changes?
<kees> kklimonda: it is certainly a prerequisite, but it would take more than just that.  See: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<kees> kklimonda: so things like "sufficiently high", and "supports micro-version updates to stable releases".  an example of failing the latter is mysql which likes to change/add/remove features in their "micro" releases.
<kklimonda> I don't have a link right now but django developers are preparing micro releases that are api stable and contain only bug fixes
<kklimonda> kees: do you mind if I take a look at django to enable testsuite or would you rather reporter do it?
<kees> kklimonda: micro updates> cool; that sounds very much like a candidate then.
<kees> kklimonda: feel free to work on it, but add a comment to the bug report just so you guys can coordinate :)  thanks!
<slangasek> bah, why is firefox now making noise at me any time I reload a page that requires re-posting data
<maco> the bell, you mean?
<maco> or sometihng else?
<slangasek> maco: it sounds like the same sound gdm makes (made?) at a login failure
<maco> oh
<cjwatson> is it the noise about which I filed bug 399778?
<ubottu> Launchpad bug 399778 in ubuntu-sounds "dialog-warning.ogg sounds like a spring breaking and is too alarming" [Undecided,Confirmed] https://launchpad.net/bugs/399778
<cjwatson> (note I've been using firefox-3.5 since rather before it became the default)
<TheMuso> cjwatson: Yeah I would probably have to agree with you about that.
 * TheMuso just listened to it.
#ubuntu-devel 2009-08-14
<directhex> oh, alpha 4 released
<directhex> how's the cd size?
<TheMuso> directhex: If its oversized, a file should be present in the dir stating clearly that a disk is oversized.
<directhex> TheMuso, i meant from a "did any langpacks have to take a flying leap this time round" perspective
<TheMuso> oh
<TheMuso> Look at the seeds. :p
<TheMuso> Looks like it
<crimsun> TheMuso: pulse 1:0.9.16~test4-0ubuntu5~ppa3 from our ppa is good for main upload
<crimsun> i'll be fixing the segv and fpe bugs on the bus tomorrow and saturday
<crimsun> (well, minus the -jack stuff)
<TheMuso> crimsun: Just uploaded your most recent changes to the bzr repo.
<TheMuso> and to karmic
<crimsun> TheMuso: thanks
<TheMuso> np
<eddel> Can a package in universe have a Recommends: on a package in multiverse?  In Debian, main can't Recommend non-free. Can I here?
<lifeless> I"m not sure
<lifeless> it should be documented in the wiki
<eddel> I found the chapter and verse in the Debian Policy but this ain't Debian so ...   Pointers would be appreciated.
 * ojwb would think the same logic applies - recommends is quite a strong relationship, and something which depends that strongly on something non-free isn't really free itself
<jtimberman> eddel: there's an ubuntu policy manual too
<jtimberman> http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/
<crimsun> TheMuso: it's probably a really good idea to push 1:0.9.16~test4-0ubuntu6
<dEdd> jtimberman: Thanks, Section 2.2.3 is equivalent to what Debian has:  pkg in universe _must not_ require a pkg outsitde main + universe. That's what I needed.
<jtimberman> can you 'suggest' it though?
<ojwb> presumably, though it would be better to suggest a free alternative if there is one...
<TheMuso> crimsun: righto, will do that now.
<crimsun> TheMuso: many thanks!
<TheMuso> crimsun: np
<TheMuso> uploaded
<stoner> just out of interest do you think anyone would be interested in a command line media play that indexes your music collection
<stoner> only i've made on
<stoner> one *
<Dyno3421> in python, calling os.path.join('folder_name', image_name) keeps just returning folder_name/image_name. is this normal? I'm trying to load an image with pygame, but it's a no go since the path isn't valid
<StevenK> Dyno3421: Yes, it's normal, but this isn't the channel for questions like that.
<ebroder> When I have one package that can completely replace the functionality of another, is that when I use conflicts/provides/replaces?
<ebroder> I guess I know I want conflicts and provides, but I can never remember how replaces works
<ScottK> ebroder: If they can be co-installed, you probably just want provides.
<ebroder> ScottK: They can't be co-installed
<ebroder> I'm specifically shipping config files. One is the primary and default; the other is alternate versions of the same config files
<ScottK> ebroder: Then conflicts or use update-alternatives perhaps
<ebroder> But should it also Replace the other package?
<ScottK> Replaces allows it to over-write files provided by the other package.
<ebroder> Ok. That sounds like what I want
<dholbach> good morning
<TheMuso> Anyone having problems with bzr branches on launchpad? Looks like I am getting connection refused...
<TheMuso> hrm seems fine now.
<lifeless> some rollout issue
<lifeless> fixed now, but they will be trying again later
<TheMuso> ah ok
<mdke> could someone have a look at ubuntu-docs_8.10.3 and maybe let it into intrepid-proposed?
<cjwatson> ScottK,ebroder: FYI the "overwrite files provided by another package" meaning of Replaces does not apply in the presence of Conflicts; since two packages that conflict can't even be unpacked at the same time, it would be meaningless. The policy manual has explicit language about what Conflicts+Replaces together mean
<seb128> jdstrand, hey
<seb128> jdstrand, the evince apparmor profile create issues, I assigned the bug to you
<AnAnt> Hobbsee: Hello, please don't forget to upload irssi
<liw> hmm, something pops up a dialog every time I log into my desktop machine, telling me I have a broken hard disk -- while I appreciate the sentiment, I'd like a way to turn that off (unless that's been fixed in the past 48 hours?)
<amitk> liw: +1
<liw> (I've alread dealt with the bad sectors, and have nothing on the broken hard disk I am worried about)
<liw> hm, let's upgrade and reboot and see if it is fixed now
<liw> (fsck... *sigh*)
<liw> nope, still there
<liw> hm, no obvious process that's showing the dialog -- how do I figure that out?
<liw> er, never mind, the window title is explanatory
<chrisccoulson> liw - it's part of the gdu notifier. and i think there's already a bug report about the notification
<liw> chrisccoulson, there's #512152 which seems to be about the warning being triggered by mistake, at least originally
<chrisccoulson> liw - yeah. theres also one about the non-expiring notificaion, causing notify-osd to display it as an ugly fallback dialog
<liw> well, I think a dialog is appropriate, if my disk is actually failing
<liw> but I'd like to not be nagged about it on every login
<liw> (also, I'd like launchpad not to muck up my arrow/paging keys)
<cjwatson> liw: I think edge no longer does ...
<liw> cjwatson, good, then I'll get the fix too, eventually :)
<chrisccoulson> liw - the notificaion is currently only a dialog by accident, due it not using notify-osd correctly. but, yes, i agree that it should be a dialog anyway
<chrisccoulson> and it will be a more helpful dialog when it is fixed correctly
<liw> cool
<mjr> Hello hello; recent gnutls upgrade apparently broke md5-signed certificates. This is all fine and well, except, you know, when you happen to have one on disk that you kinda trust for putting it there yourself, and then ldap authentication breaks large system-wide.
<mjr> probably configuring to ignore that, but I thought I'd mention that the change is really potentially rather disruptive
<mjr> and therefore perchance not a thing to do in a minor update
<cjwatson> liw: bug 1072427
<cjwatson> err
<cjwatson> liw: bug 107247
<ubottu> Error: Launchpad bug 1072427 could not be found
<ubottu> Launchpad bug 107247 in malone "Launchpad bug pages trigger caret browsing in Firefox and other Gecko browsers" [High,Fix committed] https://launchpad.net/bugs/107247
<liw> cjwatson, *nod*
<mjr> (at least not inspiring much confidence in Ubuntu's stability around here in, oh, the birthplace of Linux)
<jdstrand> seb128: re evince/apparmor> ack. I'll have it fixed shortly
<seb128> jdstrand, thanks
<liw> mjr, I know nothing about gnutls, but... do you mean it dropped support for md5-signed certificates?
<seb128> doesn't seem there was any gnutls change in karmic
<jdstrand> mjr: this is likely bug #305264
<ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [High,Fix released] https://launchpad.net/bugs/305264
<phish3> hey I just updated a package for karmic and uploaded it to my ppa
<phish3> now I'd like to provide the same update for juanty
<phish3> how should i do that?
<liw> phish3, add a changelog entry to say you're uploading to jaunty, and upload the new source package?
<liw> (that's a guess)
<phish3> liw: I'll try
<liw> hal's going away; what's today's replacement for "gnome-mount --unmount -h /org/freedesktop/..."?
<seb128> liw, devkit-disks --unmount ...
<liw> indeed; thanks!
<seb128> you're welcome
<mjr> jdstrand, thanks
<dez> Hi all
<dez> Hi, I want to join the ubuntu development community. anyone could help me?
<iulian> dez: Please see /topic.
<dez> ok, thanks iulian
<mjr> jdstrand, except it happened today and we seem to be up-to-date with gnutls, 0.3 today probably broke it
<jdstrand> mjr: you are running intrepid?
<phish3> what's the best way to get build deps from a control file or where one would run debuild
<phish3> *get and install
<liw> phish3, "apt-get build-dep"?
<liw> else run dpkg-checkbuilddeps and parse output?
<jdstrand> mjr: 2.4.1-1ubuntu0.3 was only pushed yesterday
<jdstrand> mjr: https://bugs.launchpad.net/ubuntu/+source/gnutls12/+bug/305264/comments/70 explains the situation wrt md5. This is going to be discussed in an as yet to be published usn
<ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [High,Fix released]
<phish3> liw: that'd work if i had the package
<phish3> built already
<phish3> the deps changed though
<phish3> so now I need to go fetch new ones....
<liw> phish3, there might be something in the devscripts package
<mjr> jdstrand, oh yeah, true, intrepid, sorry, forgot to mention
<jdstrand> mjr: unfortunately our hands were rather tied wrt upstream's handling of the CVE that started that bug. In the end we needed to fix the security issue and that was the only way to do it. as I said, this is going to be discussed in the next security notice for gnutls (another update is pending)
<jdstrand> mjr: I apologize for the inconvenience
<s0u][ight> cjwatson ping
<phish3> liw: thanks for the tip, mk-build-deps btw
<s0u][ight> http://pastebin.com/m7ab3cd19 gnome-keybinding-properties crashes
<cjwatson> s0u][ight: yes?
<s0u][ight> cjwatson take a look at the link
<cjwatson> s0u][ight: I don't know anything about gnome-keybinding-properties; I don't know why you're asking me
<s0u][ight> :s it's a bug i discovered, i never submitted a bug before
<s0u][ight> btw thanks about easybcd helped me a lot
<s0u][ight> cjwatson seems to be fixed in git, sorry for bothering you
<soren> Can I somehow check for the existence of a function in posix shell?
<soren> Ah, "type" reveals it.
<mjr> jdstrand, well, we worked around it, will have to follow the situation then
<jdstrand> mjr: the situation should be over now-- people like yourself unfortunately need to workaround it/update the md5 certificates. also note that upgrading to 9.04 (or later) would have caused the same problem for you later even if the change did not occur in 8.10. but I know it is a pain
<AnAnt> Hobbsee: thanks
<AnAnt> Hello, is there a channel for notify-osd ?
<AnAnt> or is the guy working on notify OSD here ?
<Pici> AnAnt: #ayatana might be the place to ask
<phish3> can I specify multiple distributions in debian/changelog?
<phish3> ex: pulseaudio (1:0.9.16~test4-0jenewton2) jaunty; urgency=low -> pulseaudio (1:0.9.16~test4-0jenewton2) jaunty, karmic; urgency=low
<james_w> phish3: space separated, but it's not supported by the archive software
<phish3> james_w: best solution?
<james_w> upload twice?
<phish3> alrighty
<phish3> I'm still wrapping my head through it and making progress but ubuntu build system is a bit harder than opensuse's imo
<slangasek> ScottK: bug #339313 isn't marked as fix released, though; could you follow that up?
<ColdWind> any dev interested in latex can sponsor bug #409673 ? it's breaking major functionality on pdftex, pdflatex and programs based on these like kile (I guess a few more too)
<ubottu> Launchpad bug 339313 in ubuntu-release-notes "Kubuntu Jaunty: Cannot Connect To Wireless Network with WEP shared key" [Undecided,Fix released] https://launchpad.net/bugs/339313
<ubottu> Launchpad bug 409673 in poppler "latest poppler prevents pdftex/pdflatex from working correctly" [Low,Confirmed] https://launchpad.net/bugs/409673
<ScottK> slangasek: Doing the LP Foo now.  It's complicated due to package renames.
<slangasek> ScottK: ok
<ogra> ScottK, i guess you could use an xorg.conf with Driver fbdev
<ScottK> ogra: OK.  I'll try it.
<ogra> NCommander has the HW to do testing for you though and he cares for KDE usually in the mobile team
<james_w> if a package uses pycentral include-links then it seems hard to make it available for other python versions
<james_w> has anyone else seen this?
<james_w> I've installed python2.4 in a karmic chroot and can't get setuptools to be available under 2.4
<MacSlow> kenvandine, and idea what might be causing gconfd-2 eating up the CPU if one does "compiz --replace"?
<ogra> MacSlow, kill metacity
<ogra> it keeps running
 * ogra had the same prob, seb128 nicely educated me
<MacSlow> ogra, trying...
<MacSlow> how odd is that?!
<ogra> :)
<ogra> known bug though
<MacSlow> ogra, any clues why that's happening?
<ogra> no, but seb128 might have researched it, he pointed me directly to the workaround
<seb128> there is a bug open on launchpad
<seb128> chrisccoulson knows details
<ogra> ah
<ogra> MacSlow, ^^
<chrisccoulson> yes, its because metacity doesn't set the RestartStyleHint correctly when exiting
<chrisccoulson> so gnome-session just respawns it again
<cjwatson> james_w: XS-Python-Versions doesn't do it?
<cjwatson> james_w: I was wondering if lsb_release needs to be available for more than current
<james_w> XS-Python-Version: 2.5, 2.6
<james_w> so will it refuse to bcompile for 2.4?
<james_w> I guess it's set to that so it doesn't use 2.4 at build time, and so python2.4 can be demoted
<james_w> I can imagine some modules importing lsb_release, but I don't know of any, and I imagine lsb-release calls are far more common
<cjwatson> true
<cjwatson> james_w: is there any reason why you can't use include-links (to suppress some of the byte-compilation) *and* make some additional symlinks manually
<cjwatson> ?
<james_w> manually at build time, or manually after installation?
<james_w> hmm, seems no modules were set-up for python2.4
<james_w> I tried to do an rtinstall as well
<cjwatson> I meant build-time
<happyaron> can tor added in karmic
<happyaron> ?
<happyaron> it seems to be an mistake that it has been deleted from Jaunty, some one told me that's to delete 0.1.x but 0.2.x is deleted now
<james_w> cjwatson: yeah, you probably could
<happyaron> and here I've filed a bug, https://bugs.edge.launchpad.net/ubuntu/+bug/413657
<ubottu> Launchpad bug 413657 in ubuntu "Please sync tor 0.2.1.19-1 (universe) from Debian unstable (main)" [Undecided,New]
<kees> mterry: so... I *was* getting kernel messages, but when I did a restart of rsyslog, they stopped (but no errors that I can find...)
<mterry> kees: Oh, good...  :-/
<james_w> ah, you can't rtinstall 2.4 because it's not in "supported-versions"
<kees> mterry: the dd seems to be running, though
<mterry> kees: that's good.  how did you restart rsyslog?  reload/hup or restart?
<kees> mterry: stop/start
<kees> mterry: the dd is restarting as well.  *scratch head*
<mterry> kees: I'm not sure either...
<kees> mterry: if it shows up in "dmesg", I should expect to see it out of syslog, yes?
<mterry> kees: I don't think that's universally true.  I'm getting kernel messages, but not everything in dmesg
<mterry> kees: oh, maybe i am
<mterry> kees: the way i usually test kernel message is just tailing /var/log/syslog and unplugging usb
<kees> mterry: dd appears to be buffering?
<kees> read(0, "<6>[78582.176041] usb 4-1: USB disconnect, address 3\n<6>[78582.176197] gspca: disconnect complete\n", 512) = 98
<kees> write(1, "<6>[78495.781527] device br0 entered promiscuous mode\n<6>[78496.856514] device br0 left promiscuous mode\n<6>[78536.296047] usb 4-1: USB disconnect, address 2\n<6>[78536.296173] gspca: disconnect complete\n<6>[78543.456518] usb 4-1: new full speed USB device using uhci_hcd and address 3\n<6>[78543.643728] usb 4-1: configuration #1 chosen from 1 choice\n<6>[78543.646665] gspca: probing 046d:089d\n<6>[78543.646669] zc3xx: Sensor MC501CB\n
<kees> note the time offsets...
<kees> and I just got a huge hit of sutff into syslog
<kees> (which corresponded to the "write")
<mterry> kees: the latest version uses bs=1; i would think that wouldn't buffer
<kees> mterry: I have 4.2.0-1ubuntu2
<kees> it shows:
<kees>   start-stop-daemon --start --pidfile $KMSG_PIDFILE --exec /bin/dd -b -m -- if=/proc/kmsg of=$KMSG_PIPE
<mterry> kees: upgrade to 4.2.0-2ubuntu1!
<kees> mterry: ah-ha!  4 hours new.  :)
<mterry> kees: when I ported the dd stuff from sysklogd to rsyslog, I inexplicably dropped the bs=1 line.  not sure how, because I can't believe I retyped that line by hand
<kees> heh
<kees> mterry: okay, well, cool.  I'm sure that'll solve my issue.  thanks!
<mterry> kees: OK, well that's good then.  One mystery down
<mterry> kees: yeah  :)
<phish3> any idea on one can see what position in the queue one's ppa packages are for being built?
<phish3> *how
<bdrung_> dholbach: yesterday i was the complete day afmk
<jdstrand> asac: fyi, not sure if you saw it, but I requested a merge for my apparmor/firefox work. (see bug #382917)
<ubottu> Launchpad bug 382917 in firefox-3.5 "ship opt-in enforcing apparmor profile for firefox" [Wishlist,In progress] https://launchpad.net/bugs/382917
<jdstrand> asac: it is disabled by default and opt-in only (as the bug says), so risk of regression should be quite low
<cjwatson> Laney: I can't remember if I said, but I think the ghc6 stuff on powerpc is as far as I can get it with retries alone. haskelldb-dynamic highlighting-kate haskell-curl haskell-pcre-light remain
<dholbach> bdrung_: that's fine - no worries
 * dholbach heads out for the WE now - take care
<asac> jdstrand: great thanks for the update. I will let someone merge it.
 * asac out again
<jdstrand> lamont`: it would be great if we could get bug #412751 fixed. There is a debdiff in the bug. What do think? Shall I just upload? do you want a git commit? can you apply the debdiff to git? please advise
<ubottu> Launchpad bug 412751 in bind9 "bind9 should reload the named apparmor profile, not all of apparmor" [Medium,In progress] https://launchpad.net/bugs/412751
<lamont`> jdstrand: most cool.
<lamont`> I'll apply the debdiff and upload, prolly tonight if that works for you?
<jdstrand> lamont`: that would be fantastic. no huge rush. thanks!
<lamont`> there are a couple of other things already committed in the git tree to roll along with that, so upload is kinda pending these days
<jdstrand> I thought there might be, so wanted to ask :)
<Laney> cjwatson: Thanks, I'll catch up with it on Sunday
<Laney> I think I've gotten as far as I can without serious investigation on other arches too
<Laney> what remains are package that FTBFS for various reasons
<Laney> and one or two that are blocked on broken cdbs
<directhex> Laney, there's a different kind?
<norsetto> is there any plan to make automake1.10 available in karmic or we just forget about it?
<cjwatson> the Debian maintainer seems to think it's appropriate to supersede it entirely with 1.11, and only have one version
<cjwatson> this doesn't seem out of order to me
<omaha> hello all
<norsetto> cjwatson, ok, so we forget about it, thx
<cjwatson> if there are problems that can't be fixed with 1.11, it might be appropriate to reintroduce 1.10
<cjwatson> but I'd rather do that if need be rather than just 'cos we're paranoid
<omaha> is anyone familiar with the status of a touchscreen calibration util for evdev?
<omaha> i'm under the impression that some work was done: https://wiki.ubuntu.com/JauntyTouchscreenHandling
<omaha> or was at least intended....
<omaha> i'm about to write an app that would replace this utility, unless it already exists :)
<seb128> chrisccoulson, sorry I need to go for dinner now but maybe there is still some us guy there working who could sponsor
<seb128> slangasek, want to sponsor a nautilus fix for chrisccoulson?
<chrisccoulson> seb128 - that's ok. i'm still investigating it some more actually. there seems to be something confusing going on from GDU
<seb128> ok
<seb128> need to run
<chrisccoulson> so, nothing to sponsor just yet ;)
<seb128> bbl
<slangasek> seb128: can do
<slangasek> or not
<slangasek> :)
<sebner> slangasek: I'm wondering who has the next archive admin job (buglist is pretty long and growing) :P
<slangasek> sebner: the rotation is documented on https://wiki.ubuntu.com/ArchiveAdministration
<sebner> slangasek: ah, so I'm looking forward to monday seeing you in action ;-P
<ebroder> Does anybody have an example d-i preseed file that sets an empty root password?
<ebroder> I've tried setting user-setup/password-empty and user-setup/allow-password-empty both to true, but it doesn't seem to be enough
<slangasek> sebner: it's still Friday, perhaps jdstrand is doing some today
<cjwatson> there are some things d-i just won't let you do
<jdstrand> I do plan to work on it today, but a bit later
<cjwatson> if you want to do this, you'll have to set it to a dummy value and change the password directly from preseed/late_command
<sebner> jdstrand: do you really want to take away all the sync bugs for slangasek? :P
<ebroder> cjwatson: Ok. I kind of thought that was how I was reading the user-setup scripts; just wanted to be sure
<jdstrand> heh, well, I'd like to... but whether or not I'll be able to is another question entirely
<slangasek> mathiaz: so if you remove mysql-client-5.0 first, does the dist-upgrade work?
<mathiaz> slangasek: hm - that would remove mysql-server too
<slangasek> oh
<mathiaz> slangasek: let me try that
<slangasek> well if it's a dependency, I guess there's no hope for that
<slangasek> I mean, yeah it works, but it doesn't help us narrow down the problem any :)
<mathiaz> slangasek: right - and I think dist-upgrade should be supported
<slangasek> yeah
<slangasek> I was just wanting to isolate if it was a problem with the client vs. server packages, but if the server deps on the client, that doesn't help
<mathiaz> slangasek: considering that FF is around the corner would it make sense to upload the new package now and sort out the upgrade later?
<slangasek> I think that'd be ok
<mathiaz> slangasek: ok - so I'm going to upload mysql-dfsg-5.1 today
<mathiaz> and then I'd need some AA to do the override.
<mathiaz> s/override/promotion/
 * slangasek nods
<ccheney> er is copying files in gnome terminal supposed to qualify as inactive for the sake of power management putting the system to sleep?
<ccheney> it put one of my machines to sleep in the middle of a huge copy and now i get to do a long fsck :-\
<ebroder> If I'm using the Jaunty d-i to install an older release, do I need to set both mirror/suite and mirror/udeb/suite? How badly are things going to break if they're not the same?
<cjwatson> I'm not convinced that's even possible
<cjwatson> I wouldn't recommend setting mirror/udeb/suite - that's for bits of the installer itself
<cjwatson> the way to go about it would be to set only mirror/suite
<ebroder> But just setting mirror/suite should work?
<niktaris> why are there .deb files on the remix version ?
<niktaris> does it use d-i for installation or does it use the ubuquity ?
<cjwatson> ubiquity uses a small number of .debs too
<cjwatson> ebroder: it's worth a shot, but it is by no means guaranteed
<chrisccoulson> hey slangasek - still available to do some sponsoring? i'm just building and testing this brasero change to fix a nautilus crash that seb128 mentioned earlier
<chrisccoulson> i will push to bzr once i've tested it
<slangasek> chrisccoulson: yep
<chrisccoulson> thanks :) i'll let you know once i've pushed the change
<mdke> could someone have a look at ubuntu-docs_8.10.3 and maybe let it into intrepid-proposed?
<niktaris> cjwatson, hi, while trying to build a custom remix version I am curius as of how important these .deb files are.
<chrisccoulson> does anybody know what happens to CD drive entries listed in /etc/fstab on upgrade if the device node is different after the upgrade to karmic?
<cjwatson> niktaris: they're used for a variety of things which are conditionally installed; on your own head be it if you leave them out. :-)
<cjwatson> chrisccoulson: I think update-manager has a rune to try to adjust them ...
<chrisccoulson> cjwatson - thanks. i've spoken to some people who have stale entries in their fstab after upgrading. we just discovered it because it was a trigger for a nautilus crash i've just been looking at
<niktaris> cjwatson, I don't need to remove them I am just thinking if I should add mine too, even though they will be already installed in the .squashfs system :)
<cjwatson> niktaris: if they're in the squashfs, you don't need to include them separately too
<cjwatson> chrisccoulson: at most update-manager does it, so they may not have used that to upgrade
<chrisccoulson> cjwatson - yeah, that's possible. thanks
<cjwatson> chrisccoulson: I noticed today that mvo committed some code to upstream apt a little while back to add a more dynamic way to handle those, so we have some hope of making this go away eventually, although the upgrade problem remains
<chrisccoulson> that will mean the CD entries going away entirely won't it?
<ebroder> ...huh. So I set mirror/suite to hardy...and still got a Jaunty machine
<cjwatson> chrisccoulson: right
<cjwatson> ebroder: may just not work
<ebroder> I guess not. Oh well
<cjwatson> feel free to figure out why :)
<cjwatson> DEBCONF_DEBUG=developer may produce a more helpful (or at least verbose) syslog
<niktaris> cjwatson, thanks
<chrisccoulson> slangasek - i pushed the brasero change for sponsoring to lp:~ubuntu-desktop/brasero/ubuntu
<slangasek> chrisccoulson: grabbing
<chrisccoulson> thanks:)
<mdke> slangasek: do you think you might be able to have a look at poking the ubuntu-docs package in the intrepid-proposed queue through if you get a moment later?
<slangasek> mdke: yes, I have some time blocked this afternoon for SRU processing
<mdke> slangasek: awesome, thanks
<arand> slangasek: May I likewise plug the goffice package in ibex & jaunty queue?
<a|wen> mathiaz: regarding the mysql-server 5.1 upgrade ... running apt-get with debug-options on the package-resolver doesn't reveal anything to note; it seems that apt's resolver simply isn't smart enough (aptitude safe-upgrade works fine)
<jdstrand> slangasek, james_w: I couldn't get to archive work today. I'm gonna try to do some over the weekend though
<jdstrand> slangasek, james_w: fyi only...
<slangasek> jdstrand: ah, cheers
<slangasek> chrisccoulson: uploaded
<chrisccoulson> slangasek - thank you
<ccheney> grr i somehow broke my OOo build without even knowing wtf i did :-\
<ebroder> Does anybody still have a good writeup on how to do a fully unattended dapper install with a preseed URL (not file)?
<ebroder> I can't find any kernel command line arguments that will bypass the kbd-chooser/method prompt
#ubuntu-devel 2009-08-15
<lamont`> jdstrand: bind9 9.6.1.dfsg.P1-2 uploaded to sid
<ebroder> I'm guessing that nobody wants to touch pulseaudio, but is anyone from ubuntu-sru around who could look at bug #330766? It's causing problems for our site deployment for users who run out of quota
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<dtchen> ebroder: you'll have better luck asking on a weekday
 * ebroder nods
<dtchen> (and some of us "touch" PA quite frequently - for better or worse)
<dtchen> thank goodness we're using tdb now
<maco> tdb?
<TheMuso> dtchen: My concern with that fix is that it could break dir/file handling in .pulse
<TheMuso> maco: Tdb is a database library.
<maco> TheMuso: thanks
<jono> anyone around to test an Empathy audio call with?
<ccheney> jono: you can call me if you want if you want to just test your end of empathy
<jono> ccheney, what is your contact address?
 * ccheney heads off to bed, bbl
<ojwb> jono; if it's SIP, there's an echo test at sip:500@ekiga.net
<DigitalDarkness> Evening Everyone, I noticed today that OpenSuSE team is working on a "build-a-bear" distro thing on the web where you build and customize your own distro? Has there been any talks about ubuntu trying anything like this out?
<happyaron> hi, anyone can pay some attention about this latex-related bug: https://bugs.edge.launchpad.net/ubuntu/+source/texlive-bin/+bug/413964
<ubottu> Ubuntu bug 413964 in texlive-bin "got "invalid image dimensions" error" [Undecided,New]
<Ampelbein> happyaron: this is related to bug 410242, having the same root cause. A debdiff is attached there which fixes that and needs sponsoring by a core-developer
<ubottu> Launchpad bug 410242 in texlive-bin "pdftex/libpoppler crashed with SIGSEGV in strlen()" [Medium,Confirmed] https://launchpad.net/bugs/410242
<Ampelbein> happyaron: you can also test the package in the mentioned ppa, which should fix your issue, too.
<happyaron> Ampelbein: but I want 'tor' package to be added to karmic, without it be corrected, I cannot upload it, :(
<Ampelbein> happyaron: yeah, i'm waiting for it being sponsored, too.
<happyaron> Ampelbein: without a right pdfTex, the document of tor package cannot be fully included, other things about tor are done and tested and I decide to maintain it for ubuntu if possible
<happyaron> Ampelbein: when will it update to the new one?
<Ampelbein> cjwatson: hi there, do you happen to have time to review bug 410242?
<ubottu> Launchpad bug 410242 in texlive-bin "pdftex/libpoppler crashed with SIGSEGV in strlen()" [Medium,Confirmed] https://launchpad.net/bugs/410242
<cjwatson> Ampelbein: I'm on holiday until next week, so would prefer it be somebody else
<happyaron> cjwatson: i need that fix to build tor package in fact
 * ogra wonders why the armel queue isnt being processed .... buildds are idle but 67 builds in queue
<cjwatson> happyaron: right, and I need a break :-)
<cjwatson> lots of other core devs
<happyaron> cjwatson: any of core devs can help?
<ogra> cjwatson, go away from the kbd then, enjoy the sun !
<cjwatson> happyaron: yes
<happyaron> cjwatson: thanks, enjoy holidays!
<ogra> happyaron, did you subscribe ubuntu-main-sponsors to your bug ? if not, do that and someone will jump in
 * ogra points to https://wiki.ubuntu.com/SponsorshipProcess
<happyaron> ogra: not yet
<Ampelbein> happyaron: 410292 has the sponsors subscribed
<Ampelbein> err. 410242
<happyaron> oh
<Ampelbein> cjwatson: no problem, i'll find someone else. enjoy your holiday.
<happyaron> it was reported on Aug, 7th, but nobody fixed the package till now
<ogra> Ampelbein, looks good, uploaded
<Ampelbein> ogra: very cool, thanks.
<directhex> hm. what's the standard rate for bribery for the TB election?
<happyaron> ogra: when will it available?
<ScottK> directhex: Standard rate is to pay for voting for the other guy.
<asac> urgh. apt-get dist-upgrade crashes now for me :/ .. http://paste.ubuntu.com/253663/
<asac> i guess no updates till mvo is back ;)
<asac> hmm ubuntu-bug /var/crash.../ -> invalid problem report ... no such file or directory
<directhex> sladen, poke poke
<Ampelbein> asac: try aptitude?
<asac> Ampelbein: no. need to keep it this way
<asac> to debug
<asac> in case its a database state thing or something
<Ampelbein> ah, ok.
<directhex> sladen, can you take a look at taoframework from sid? it's about a year newer than what's in karmic, and you're the one who's ubuntu'd that package before
<andresmujica> themuso: hi, about the bug #409759 i've found several variations of it (muted after boot, changing output throu pavucontrol).  The most common one is the jack sensing not working. This is a pulseaudio problem and not a kernel one *in most cases*.  for example bug #410769 that's being workd by crimsun, I was planning to use as metabug the one you're working on for the muting variation and the other one for the pavucontrol route.  wh
<ubottu> Launchpad bug 409759 in pulseaudio "[Karmic] No sound with jack output now with PulseAudio 1:0.9.16~test4-0ubuntu1" [Undecided,Incomplete] https://launchpad.net/bugs/409759
<ubottu> Launchpad bug 410769 in linux "[karmic regression] jack sensing doesn't trigger toggle of Headphone/Speaker automatically upon insertion/removal 8086:284b Codec Analog Devices AD1984" [Medium,In progress] https://launchpad.net/bugs/410769
<ion> andresmujica: 1:0.9.16~test4-0ubuntu6 fixed the issue for me. The headphone output is now available in Sound Preferences.
<crimsun> the more adventurous types will likely want to track the ~ubuntu-audio-dev PPA anyhow.
<andresmujica> ion: but you're getting automatic audio routing? or you are selecting manually the output?
<ion> andresmujica: I have to switch it manually. I complained about that in the bug report. But at least i no longer have to enable the headphone output with alsamixer.
<andresmujica> ion: that's the point, the regression is the lack of jack autosensing.  It should be route automatically
<crimsun> be careful when you're triaging those, because you need two separate test cases
<crimsun> you need to be able to reproduce it without pulseaudio running (i outlined the procedure in #ubuntu-audio-help earlier)
<ion> Iâll upgrade to the PPA version. Letâs see what happens. :-)
<crimsun> ion: if you're being bitten by the analog devices/idt/sigmatel regression, i doubt the new PA version in our PPA will make any difference
<ion> crimsun: It would be nice if the Git commit-IDs in the changelog had the beginning of the commit message (whatever fits on the line) just after the ID.
<ion> 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
<crimsun> ion: test5 is imminent, so it won't be that useful, but sure, i can hack that in
<crimsun> ion: (/proc/asound/card*/codec*)
<jdstrand> crimsun: hi! is there anything more I need to do with bug #400682? I checked the new kernel changelog, and it wasn't immediately apparnt that the fix was in there
<ubottu> Launchpad bug 400682 in linux "[Karmic stac927x regression] No sound after upgrade from Jaunty to Karmic" [Undecided,Triaged] https://launchpad.net/bugs/400682
<ion> crimsun: http://pastebin.com/f50f9d481
<ion> crimsun: Ditto (with the commit-ID vs. the commit message) with the udev changelog entry. :-)
<crimsun> jdstrand: i don't know offhand if manoj make public any kernel debs with those fixes, but that's what you need. the linux sitting in NEW does not contain those fixes.
<jdstrand> :/
<jdstrand> crimsun: ok, thanks
<crimsun> ion: scott already rejected my proposal to backport the changeset; it's off my plate now
<crimsun> jdstrand: have i asked you to try the enable_msi=1 option for snd-hda-intel?
<jdstrand> crimsun: not that I recall
<jdstrand> crimsun: I can and will report back in the bug
<crimsun> jdstrand: thanks
<sebner> jdstrand: would you mind sponsoring an important sync-fix?
<jdstrand> sebner: what?
<sebner> jdstrand: bug #414072, fixes breakage with automake 1.11
<ubottu> Launchpad bug 414072 in gnome-common "Please sync gnome-common 2.26.0-2 from Debian(Unstable)" [High,New] https://launchpad.net/bugs/414072
<jdstrand> sebner: sure
<sebner> jdstrand: Thank you :)
<jdstrand> sebner: done
<sebner> jdstrand: great! Less breakage in the archive! :D
<jdstrand> :)
<sladen> directhex: if taoframework is a year old, I wonder why it didn't get synched for jaunty
<directhex> sladen, it's been ubuntu1'd for one thing
<sebner> sync! sync! sync! ... jdstrand will do it :P
<iulian> jdstrand: Yes, please sync 5.831-1 (libwww-perl).
<iulian> jdstrand: Please acknowledge it as well.  I'm not a member of core-dev.
<sladen> jdstrand: Please sync taoframework and drop Ubuntu patches  https://bugs.launchpad.net/ubuntu/+source/taoframework/+bug/414087
<ubottu> Ubuntu bug 414087 in taoframework "sync taoframework (2.1.svn20090801-1) from sid" [Undecided,Confirmed]
<sladen> directhex: okay, so Debian was at a FTPFS 2007 snapshot uploaded in 2008, and has now jumped straight to a 2009 snapshot uploaded in 2009 :)
<directhex> sladen, i.e. sam's come back from the dead & uploaded an update
<Laney> is there a key to get the grub menu to appear?
<Laney> ah, editing the config
<stennve> i cant get my soundcards to work with alsa but is there a supported devices list uner pulseaudio because neither cards are supported in the list of alsa?
<stennve> using a hp dv6 1105ee laptop
<cjwatson> Laney: escape
<cjwatson> Laney: (as posted to ubuntu-devel-announce)
<cjwatson> Laney: oh, whoops, apparently I didn't post that detail :)
<Laney> cjwatson: ;)
<cjwatson> Laney: it'll change anyway, Mark wants it to be a zero timeout but to let you get to the menu by holding shift as you come out of the bios
<Laney> yeah that sounds reasonable
<cjwatson> obviously only for people who aren't dual-booting
<Laney> is the text about tab completion going to go away?
<cjwatson> yeah
<cjwatson> well, either that or I get fired ;-)
<cjwatson> there are just some slight difficulties getting rid of it right now because the config file hasn't been read yet at that point
<cjwatson> so I have some reordering work to do
<Laney> good luck
<ScottK> ogra: Did you even find out why the armel buildd's are stalled?
<crimsun_> jdstrand: i'm spinning new kernels tonight, will ping you tomorrow
#ubuntu-devel 2009-08-16
<nsahoo> hi .. I accidentally marked some files under svn control to delete on next commit, how do I undo that?
<ebroder> nsahoo: #ubuntu-devel isn't a general support channel. For Ubuntu support, you should ask in #ubuntu. Although for help with subversion, you're better off asking in #svn
<nsahoo> thanks
<nsahoo> I asked in svn
<nsahoo> i was told in #ubuntu to ask here at first
<nsahoo> anyways resolved it
<ebroder> #ubuntu-devel is specifically for Ubuntu development, not development on Ubuntu in general
<ojwb> nsahoo: IIRC, svn revert <files>
<ojwb> oh, you resolved it anyway
<damo22> which package do i get if i want to compile my own kernel for ubuntu 8.04?
<damo22> linux-source-...
<damo22> ?
<superm1> could I get a give-back on mythplugins?
<cjwatson> superm1: you ought to be able to do that yourself?
<cjwatson> find the build page, hit the retry link
<udiio> Q: how do I easily touch the "Version" line of a deb control file from bash?
<mdke> what does dpkg-deb: subprocess paste killed by signal (Broken pipe)
<mdke> mean?
<mdke> is that the user interrupting an upgrade or could it be a crash?
<cjwatson> udiio: what do you mean by "touch"?
<cjwatson> mdke: it means that the parent dpkg-deb process exited, for some reason not explained by that error mesage
<cjwatson> message
<cjwatson> well, exited or otherwise closed the reading end of the pipe the subprocess was trying to write to, but exited is most likely
<mdke> hmm
<mdke> cjwatson: I'm looking at bug 414237 - there doesn't seem to be any explanation in the terminal log. Do you know if there is any way I can get the reporter to provide more info that might help?
<ubottu> Launchpad bug 414237 in ubuntu-docs "package ubuntu-docs 9.04.9 failed to install/upgrade: short read in buffer_copy (backend dpkg-deb during `./usr/share/gnome/help/about-ubuntu/ru/about-ubuntu.xml')" [Undecided,New] https://launchpad.net/bugs/414237
<cjwatson> mdke: you could try getting them to run 'sudo dpkg -i /var/cache/apt/archives/ubuntu-docs_9.04.10_all.deb' from a terminal and see what it does there
<cjwatson> we should probably filter out such apport reports, they're never package bugs ...
<mdke> but I guess it could be a bug of some kind, even if not in ubuntu-docs. I'll do as you've suggested
<mdke> thanks cjwatson
<YokoZar> Did sabdfl enable proportional representation for the technical board election?
<cjwatson> condorcet
<Laney> are there any platforms or such like available for the election?
<Laney> I feel like I'm voting a bit blind
<mdke> candidate wiki pages?
<YokoZar> cjwatson: Yes, but there are 5 winners.  You can either do this by picking the top 5 ranked or by using a condorcet method to pick the set of 5 that beats all other possible sets of 5
<YokoZar> (there's a link to the proportional representation explanation on their page, and whether or not it's on is a checkbox when you create the poll...but it's not clear on the actual ballot which method it uses)
<YokoZar> http://www.cs.cornell.edu/w8/~andru/civs/proportional.html  <-- their explanation of their PR method
 * YokoZar studied voting systems very heavily in college and is very pleased regardless
<Laney> mdke: have they been updated in general?
 * Laney could just look
<mdke> Laney: I'm not sure.
<Laney> seems not
<mdke> the thing taht confused me slightly about the voting process was whether one should try and make the ranking add up, so that if you have 2 people ranked at 1, the next person should be ranked 3
<cjwatson> YokoZar: oh, right, I don't know, sorry. I would hope that we're picking the top 5 ranked
<cjwatson> ask Mark :)
<YokoZar> mdke: it's smart enough to not care
<YokoZar> mdke: relative position is all that matters
<mdke> ah, good
<mdke> thanks
<LLStarks> how do i send something to the build farm?
<ogra> you upload a sourcepackage to the archive
<LLStarks> ogra, how do i do that?
<ogra> you become a developer, gain upload rights and upload your package is one way, you find a developer who has upload rights and convince him/her to sponsor your upload is the other
<LLStarks> well, how would i get this into the queue? https://bugs.launchpad.net/ubuntu/+source/libass/+bug/410112
<ubottu> Ubuntu bug 410112 in libass "libass 0.9.7 released" [Undecided,Confirmed]
<maxb> Get it into which queue?
<LLStarks> for the build farm.
<ogra> seems ubuntu-universe-sponsors is already subscribed
<LLStarks> well, i don't see the gears of progress turning.
<ogra> so it's a matter of being patient or asking someone in #ubuntu-motu to review and upload
<ogra> see https://wiki.ubuntu.com/SponsorshipProcess
<maxb> What is the usual time for a MIR to be reviewed and approved?
<maxb> I need an estimate of whether one which is currently pending is likely to be completed in time for FeatureFreeze
<maxb> lp 410624
<ubottu> Launchpad bug 410624 in serf "Promote serf from universe to main" [Undecided,New] https://launchpad.net/bugs/410624
<slytherin> Hi. Yesterday I upgraded my PC to karmic. I just added a DVD drive to the PC, but there is no /dev/dvd node created. To which package should I report the problem?
<ogra> kirkland, sorry that it took so log, qemu fix uploaded
<ogra> gah, pitty dropped my hal fix of the initscript without note
<ogra> heh, i should probably check for which release i build my chroots :P
<damo22> sorry to sound stupid, how do you reply to a message on a mailing list? i have subscribed and posted a message, but when i posted a reply to my own message back to the mailing list, it appeared as a new post.... i want to be able to post a reply and have it indented in the mailing list
<cjwatson> wow, get a less awful mail client :)
<cjwatson> the "reply to all" (or, if available, "reply to list") function in any non-hopeless mail client is sufficient
<damo22> cjwatson: yeah, im using gmail
<damo22> is it possible in gmail?
<cjwatson> no idea, sorry
<damo22> :(
<ion> gmail has worked just fine with mailing lists so far.
<damo22> but reply to all makes the mailing list as a CC
<damo22> and the primary address is the email of the person who posted
<damo22> is that correct?
<cjwatson> yes, and on some lists that is considered suboptimal, but that is not the question you originally assked ...
<cjwatson> the "reply to list" function, if available, tries to honour the Mail-Followup-To: header, which normally has the effect of putting the mailing list in To: if it can figure out how
<cjwatson> but either of those ought to preserve threading
<damo22> cjwatson: i dont want to post an email to the guy who posted, and then he gets a second email back from the list
<ogra> afaik you have to copy the CC address to the to field in gmail
<ogra> but the mail should end up in the proper thread then
<cjwatson> like I say, not the question you asked to start with - you were asking about threading!
<damo22> ogra: thankyou
<cjwatson> the "new post" bit
<cjwatson> if you want to be a really good citizen regarding list replies, you need a mail client that honours mail-followup-to
<ogra> (note that i dont use gmail, the above is only what i heard from gmail users)
<damo22> ogra: i will test it now
<cjwatson> and if that's something gmail doesn't provide, the right answer may be to ask google to add it, since presumably they are at least in part driven by demand from their users
<tikka> I'm curious about how to find out and when the latest kernel, with fixes for the null pointer deference, will be available for ubuntu?
<ogra> tikka, you probably want #ubuntu-security ... but to my knowledge only systems with vm mmap min addr set to 0 are actually vulnerable, note that ubuntu defaults to something a lot higher (i'm not in the security team though and might have misunderstood the issue)
<maco> ubuntu wasnt vulnerable, iirc
<tikka> thanks ogra, maco
<maco> i remember seeing someone comment on an article about it with the results of the proof of concept on ubuntu and fedora
<ebroder> tikka: If you want to be sure, you can `cat /proc/sys/vm/mmap_min_addr` to see what it's set to on your system
<ebroder> Should be 65536
<ebroder> If it is, you're not vulnerable
<tikka> 65536
<tikka> yep
<tikka> thanks ebroder
<ogra> grr ... Unsupported syscall: 242
 * ogra curses mono
<cumulus007> In which package is the "Add/Remove..." program packaged?
<mpontillo> cumulus007: gnome-app-install
<cumulus007> thanks :)
<cumulus007> "ImportError: libgailutil.so.18: can't open shared object file: no such file or directory"
<cumulus007> when I start it
<mpontillo> cumulus007: according to 'dpkg -S /usr/lib/libgailutil.*', that's provided by the "libgail18". do you have it installed?
<mpontillo> *the "libgail18" package, that is
<cumulus007> Nope, I'll install it
<cumulus007> it starts up now :)
<cumulus007> but it crashes after a few seconds
<mpontillo> possible bug in the gnome-app-install package then? I don't see a 'Depends' line.
<cumulus007> "glib.GError: Icon 'distributor-logo' not present in theme". I'm running Kubuntu with the Oxygen theme, could that be the problem?
<mpontillo> hmm that logo file is provided by the human-icon-theme package ;) tangled web this is
<mpontillo> and/or gnome-icon-theme, ubuntu-artwork, ... and a number of other theme packages. not certain how the themes work so if the oxygen theme has to provide it and isn't...?
<cumulus007> mpontillo: even when I change my icon theme to Human, it still crashes
<popey> anyone know what package I should file a bug against for the "shutdown/reboot/hibernate/suspend" screen in gnome?
<popey> gnome-session perhaps
<mpontillo> you could try could try hacking /usr/lib/python2.6/dist-packages/AppInstall/Menu.py to get it to work. see if replacing the line that does "item = Category(self, self.all_category_name, "distributor-logo")" to remove the last parameter helps, or if it just crashes on some other icon
<dupondje> is there a bugpage for upgrade bugs from Jaunty to Karmic ?
<dupondje> cause its a hell :s
<dtchen> jdstrand: bug updated with information regarding a current test kernel
#ubuntu-devel 2010-08-16
<Hobbsee> cody-somerville: yes
<Hobbsee> a few days late, i suspect
<superm1> yay contentless pings from 2 days ago
<Hobbsee> yup
<ajmitch> good to see that you're still alive though
 * Hobbsee quickly dies
<ajmitch> oh dear
<pitti> Good morning
<ajmitch> morning pitti
<ion> hi
<RAOF> 'Tis a pitti.  Hello!
<pitti> hey RAOF, how are you?
<pitti> is it just me, or is resuming very crashy in maverick these days?
<RAOF> Depending on what you mean by âveryâ, I think it might be just you.
<pitti> I either get kernel freezes or X crashes
<RAOF> I mean, resuming for me has failed once or twice over the last month, which is I think _slightly_ more frequently than in Lucid.
<RAOF> But it's difficult to tell at that frequency.
<pitti> ok, then I'll have a closer look next time
<pitti> slangasek: the upstart SRU has had lots of verification, and I haven't heard about regressions, so for the sake of 10.04.1 I'm fine with releasing it early
<slangasek> pitti: right; there seem to be a number of other SRUs that also need processing if we're to use the current ISOs for .1, I'm working on verifying the samba fix now
<pitti> slangasek: d-i is fine, I asked cjwatson to copy this (since it needs some manual fiddling)
<pitti> so that leaves scim, xorg-server, and casper AFAICS?
<pitti> slangasek: I'll test casper
<slangasek> pitti: ibus-anthy, libvirt?
<pitti> oh, we carry libvirt, too? ok
<slangasek> I don't know for sure; it's in main
<slangasek> far too much manual effort to check these things
<slangasek> yes, libvirt is on the server CD
<slangasek> erm, so is sane-backends, which is verification-failed?
<slangasek> not on the server CD, it's on alternate
<slangasek> and on desktop :(
<pitti> slangasek: right, we can't move sane, I'm afraid
<slangasek> which means we need to punt it and respin
<pitti> slangasek: we could remove it from -proposed and rebuild test CDs?
<slangasek> yes
 * pitti removes
<pitti> good time, 2 mins before publisher
<slangasek> pitti: hmm, sane-backends still in -proposed, an hour later
<pitti> slangasek: trying again, checking LP this time
<slangasek> pitti: saw your follow-up to 591207; what do you think we should do with casper?
<pitti> https://edge.launchpad.net/ubuntu/+source/sane-backends/+changelog
<pitti> slangasek: ^ this claims that it was removed already, hmm
<pitti> slangasek: ibus-anthy verified (moving to -updates now), casper causes some trouble
<pitti> slangasek: not sure why my dist-upgrade failed, but it gets a little further with the -proposed version
 * pitti checks hte USB stick whether initramfs was updated/untouched/destroyed
<pitti> -rw-r--r-- 1 martin martin   9837789 2010-08-16 07:47 initrd.lz
<pitti> -rw-r--r-- 1 martin martin    413696 2010-08-16 06:03 initrd.lz.new
<pitti> hmm
<pitti> slangasek: followed up
<slangasek> ok
<pitti> slangasek: so the net result of all this is that it's now writing an additional broken file to the USB stick :/
<pitti> slangasek: my gut feeling is that we should pull it from -proposed, since we have to respin anyway; this would avoid the new broken file
<pitti> slangasek: what do you think?
<pitti> slangasek: hm, I also removed ifupdown from -proposed (standard cleanup), and it's still published
 * pitti wonders whether there's something wrong with removals in general
<slangasek> pitti: the casper bug seems like a rather bad one to not have included in .1, but it wasn't milestoned, so yeah, I guess we should pull it
<slangasek> pitti: can I leave it to you to figure out why -proposed removals aren't working, and respin the world once you have that figured out?  I'll mark the images appropriately in the tracker
<pitti> slangasek: yes, that's fine (so that you can go to bed now :) )
<slangasek> either way, I need to get some sleep, yeah; so if you can't get to it today, I'll look at it myself in the morning
<pitti> slangasek: if it still doesn't get removed in 20 mins, I'll prod soyuz guys
<slangasek> ack, thanks
<pitti> slangasek: ah, got removed now
<dholbach> good morning
<ion> hi
<pitti> slangasek, cjwatson: I copy d-i to -updates, so that the alternates will be ok; we still need to copy the netboot bits, though
<pitti> kirkland: could you give the proposed .deb in bug 571093 some testing? we need to move it to -updates soon
<ubottu> Launchpad bug 571093 in multipath-tools (Ubuntu) "[SRU] multipath + libvirtd eats away more memory over time" [Medium,Triaged] https://launchpad.net/bugs/571093
<lanoxx> i have merged a bzr branch into my local working copy, how can i go back to the master branch?
<lanoxx> how can i switch branches in bzr?
<pitti> lanoxx: check it out separately, or overwrite your local copy with bzr pull lp:<mastername> --overwrite
<lanoxx> pitti, if i overwrite it, then i need to check out the other branch again right?
<pitti> lanoxx: if you need both branches, it's generally easier to just keep them checked out separately
<lanoxx> pitti, how do i check them out seperately
<lanoxx> pitti, sorry i have not much experience with bzr, im use to git
<RAOF> lanoxx: You *can* use âbzr switchâ in pretty much the same way as âgit checkoutâ, but it's probably not what you want to do.
<Hobbsee> ScottK: you around?
<lanoxx> RAOF, can i check out the master branch again and then switch between my current branch and the master branch?
<RAOF> lanoxx: The way I generally deal with it is to have one directory per branch.  So, you have your current tree, which is a branch of trunk with another branch merged in.  If you wanted to keep that branch, and also get a checkout of the master branch, you'd go up a directory and run âbzr branch lp:whateverâ
<lanoxx> RAOF, ah ok. i will do that
<RAOF> lanoxx: You can, with a little set up, make it so that you switch between branches in the same directory.  It's probably much less effort to just have one directory per branch :)
<RAOF> If you're going to do that, then âbzr init-repo .â in the directory containing your branches is a good performance optimisation to do.
<lifeless> --no-trees too
<RAOF> lifeless: I wasn't thinking of the bzr switch dance there :)
<lanoxx> does bzr have an option like format-patch?
<lanoxx> or should i just use bzr diff?
<RAOF> âbzr bundleâ does a similar thing to format-patch.
<RAOF> Man.  âbuffersâ is one of those words that just get more and more weird the longer you stare at them.
<lifeless> RAOF: bzr send please, not bundle
<RAOF> lifeless: Ah, sorry.  -EHAZY.  bzr send attaches a bundle, right?
<lifeless> yeah
<ogra> pitti, vala seems to have landed in universe (breaking a rebuild of libindicate on armel)
<pitti> ogra: hm, that was called vala-0.10
<pitti> and was in NEW
<ogra> http://ports.ubuntu.com/ubuntu-ports/pool/universe/v/vala/
<ogra> valac-0.10
<pitti> we now have two different vala versions as it seems; I asked Robert about it, but I'm not clear yet how the final result should look like
<ogra> hmm, k
<pitti> oh, the source is still vala?
 * pitti checks
<pitti> ogra: promoted
 * ogra hugs pitti
<ogra> now there is only zeitgeist that breaks image builds left :)
<pitti> ogra: already promoted this morning
<ogra> ah, cool
<pitti> hehe, did anybody look at a Debian bug today?
<pitti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582113
<ubottu> Debian bug 582113 in gsfonts "gsfonts: dropping defoma, introducing update-gsfontmap" [Wishlist,Fixed]
<pitti> 17 years birthday?
<ogra> cute
<seb128> why do people want every crack in the universe to go in Ubuntu
<seb128> shrug
<seb128> I will no reply on the list, seems there is already lot of noise in that discussion
<Laney> it is called universe ;-)
<pitti> TBH it's what we wanted to in warty, but I agree that we need to stop doing this
<seb128> well, that's one of the complain we get atm
<pitti> Laney: so it's a matter of definition, I guess
<pitti> universe == all stuff you can find, or universe == some sanity/maintenance involved
<seb128> quality is not egual and people misjudge ubuntu on some of the broken things they find
<seb128> we should lower the number of sources in the official archive and improve quality
<Laney> making this stuff more visible in s-c isn't going to cause people to think it's not part of Ubuntu though
<seb128> we should not aim at pushing every crack application nobody will keep working on 6 months later in universe
<seb128> well it's easy to message that this entry is not ubuntu
<seb128> and why people keep arguing to use backports
<seb128> that just doesn't work
<pitti> Laney: we certainly get some responsibility, but it's a matter of presentation IMHO
<pitti> people don't blame Apple or Google for every broken Android/iPhone app either
<seb128> backport require the source to be the same in the new distro
<seb128> ie you can't enable build using new gdbus or whatever
<pitti> well, maybe they do, but at this point we can't help it any more
<seb128> or you need to start tweaking your packaging to have different builds in backports
<seb128> that makes no sense
<Laney> anyway I think that maintaining stuff in universe is something we are terrible at too
<seb128> right
<Laney> not arguing for that
<seb128> I think we should clean universe
<pitti> well, terrible -> it's a manpower issue
<pitti> it's a helluva job
<Laney> sure, of course
<seb128> we are just lying when we pretend to be able to maintain that amonth of softwares
<seb128> we should aim for better quality
<Laney> luckily we don't have to actively maintain most of it
<seb128> I'm not sure why people want to turn universe to get as many crack non maintain as we can
<seb128> still there is lot unmaintained in debian as well
<seb128> or upstream
<Laney> I think there's a lot of scope for us to improve the automated QA
<Laney> people seem to work well when there's lists
<seb128> we should perhaps be agressive in clean things which rot
<seb128> or are buggy
<Laney> yes
<Laney> the binary removal thing which happened in Lucid was a good idea IMHO
<Laney> "fix this stuff or it won't be in the release"
<seb128> well why fighting the noise
<seb128> we could probably make a list of issues on all those packages nobody use
<seb128> but wouldn't we spend efforts in a better way trying to improve what users actually run
<Laney> apart from the 5 or 6 people that it's absolutely essential for
<seb128> rather than fixing un-used packages to be compliant with new policy or whatever
<seb128> or build softwares that didn't change for 3 years to build with a gtk update
<seb128> session restart brb
<diwic> Hi, I have some trouble trying to build a package with pbuilder (with arch=i386 on an AMD64 machine)
<diwic> the error message is "linux-headers-2.6.32-24-generic is a virtual package"
<directhex> diwic, is your pbuilder up to date?
<cjwatson> Laney: ubuntu-cli-mono-dev> yes, it should - done
<Laney> should?
<Laney> oh, ubuntu-dev, yeah âÂ­thanks!
<cjwatson> superm1: EFI> this thing called "holiday" ... I'm still tracking it, only reason it didn't land earlier was that I had problems getting 64-bit GRUB to boot my test machine, so I'll be getting back to that this week
<pitti> hey cjwatson, welcome back! had a nice holiday?
<cjwatson> pitti: I've copied d-i/lucid-proposed to -updates now (pending next publisher run); FWIW the procedure has been documented in https://wiki.ubuntu.com/ArchiveAdministration#Special%20case:%20debian-installer%20updates for a while
<pitti> cjwatson: ah, thank you!
<Riddell> pitti: are you the force behind the mysterious appearance of lucid .1 images?
<pitti> Riddell: yes; we need to respin due to some failed SRUs
<pitti> see discussion with slangasek here this morning
<cjwatson> pitti: yep, much less frazzled now :)
<cjwatson> pitti: FWIW am respinning lucid server now - it broke on a locking issue I hadn't previously thought of, now fixed in bzr
<diwic> directhex, hmm, interesting point, I should probably add lucid-updates and lucid-security to my pbuilder...
<pitti> cjwatson: ah, thanks
<cjwatson> very rare locking issue though - it only happened if two parallel builds completed at almost exactly the same time
<pitti> I'm respinning kubuntu desktop lucid, then the set should be complete again
<cjwatson> (so I haven't bothered rolling out the fix yet)
<pitti> cjwatson: marked server for rebuild in the tracker
<cjwatson> pitti: my respin was only based on the assumption that it was already rebuilding, and that somebody wanted the previous build this morning to succeed :)
<pitti> cjwatson: http://cdimage.ubuntu.com/ubuntu-server/lucid/daily/20100816.2/ looks like your respin?
<pitti> it has the reverted sane-backends, so it's good
<pitti> and reverted casper, too
<baptistemm> hi there
<cjwatson> pitti: yes
<pitti> cjwatson: added to tracker; I'll add kubuntu desktop once they finish, then "the world" is rebuilt
<geser> could a core-dev please give back: shotwell rrdtool. Both are in reality DEPWAITs and resolved now.
<pitti> doing
<geser> thanks
<baptistemm> heh, seb128 updated bluez for maverick previous week
<baptistemm> why didn't he merged from debian ?
<diwic> directhex, do you know how to add lucid-updates and lucid-security to the lucid chroot?
<directhex> set a pipe-delimited value for OTHERMIRROR in ~/.pbuilderrc, and run "pbuilder update --override-config"
<diwic> directhex, OTHERMIRROR="lucid|lucid-updates|lucid-security"? I mean, that's not exactly a mirror
<pitti> slangasek, cjwatson: all lucid CDs rebuilt and added to tracker; they picked up the failed SRU rollbacks
<directhex> diwic, no, that's not a mirror
<diwic> directhex, I'll read the manpage
<diwic> directhex, and come back if I still have a question :-)
<directhex> diwic, OTHERMIRROR="deb http://security.ubuntu.com/ubuntu lucid-security main restricted universe multiverse|deb http://mirror.ox.ac.uk/sites/archive.ubuntu.com/ubuntu/ lucid-updates main restricted universe multiverse" is more mirror-flavoured
<diwic> directhex, hey it seems to be working and you saved my day :-)
<directhex> diwic, the --override-config flag is needed for any changes to your mirror variables to actually be set
<diwic> directhex, I wrote it as OTHERMIRROR="deb $MIRRORSITE $DIST-security $COMPONENTS" though, out of lazyness :-)
<directhex> diwic, i could not guarantee that you had those vars defined
<diwic> directhex, anyway thanks for the help :-)
<ara> pitti, are Ubuntu 20100816.1 images ready to test? or are we waiting for .2 ?
<pitti> ara: all images ready to test and on the tracker
<ara> pitti, thanks
<pitti> ara: kubuntu desktop and server are .2, rest .1
<shadeslayer> dholbach: around?
<dholbach> shadeslayer: just about to head out for lunch - how can I help=
<dholbach> Ã
<dholbach> ?
<shadeslayer> dholbach: can you retry kdenetwork?
<shadeslayer> please :)
<shadeslayer> https://edge.launchpad.net/ubuntu/+source/kdenetwork
<dholbach> shadeslayer: almost anyone could have clicked that button for you! :)
<shadeslayer> the other builds failed because libsrtp wasnt in main, i64 builds because it was moved when it built
<shadeslayer> dholbach: i know, i dont know who else is allowed to push that button tho :P
<cjwatson> anyone who can upload a package can retry it
<dholbach> shadeslayer: done
<shadeslayer> dholbach: thanks :D
 * dholbach â late lunch
<shadeslayer> cjwatson: the package was sponsored :P
<pitti> shadeslayer: retried
<shadeslayer> lol.. :D
<pitti> shadeslayer: NB that ia64 and sparc will be removed soon anyway
<shadeslayer> pitti: thanks anyways :D
<shadeslayer> pitti: dont care about them ^_^
<pitti> someone beat me to it anyway
<shadeslayer> just noticed that i64 built
<pitti> ah, dholbach
<shadeslayer> yep
<shadeslayer> pitti: most packages on sparc are ftbfs anyways :/
<shadeslayer> they need special love
<StevenK> *sparc* needs special love
<cjwatson> shadeslayer: that doesn't change the accuracy of my statement ...
<shadeslayer> cjwatson: i can retry the build ? really?
<cjwatson> that means you can't retry.  but you said "I don't know who else is allowed to push that button", and I told you
<cjwatson> you can't upload the package yourself, so you can't retry it yourself
<shadeslayer> ohh
<cjwatson> but anyone who could have sponsored it for you could also have retried it
<shadeslayer> got it now .. anyone who can upload can retry
<superm1> cjwatson, ah okay, i was just a little worried it wasn't there at FF, i wasn't aware you were on holiday for a while.  cool, hope it was a good time off :)
<apw> is there an approved way to remove a PPA and un-upgrade all the packages?   i see xorg-edgers has a ppa-purge thingy that does it.  should something akin to that be available to mirror apt-add-respository ?
<pitti> apw: ppa-purge is in universe now
<apw> pitti, so it is, thats better than nothing
<ScottK> Hobbsee: Around now.
<ahasenack> hey guys, do you know when 10.04.1 is scheduled to be released? Is it tomorrow?
<pitti> ahasenack: if all goes well, yes
<ahasenack> pitti: thanks
<akgraner> mdz, do you have 5 mins right quick?
<mdz> akgraner, sure
<hallyn> general bug question - when i have a bug that's reported as affecting 3-5 projects, is it normal to change the priority/status for each project?  Or just one, bc that's enough info?
<hallyn> and also, is marking it invalid against a particular project considered ok (if it has nothing to do with that package)?
<bigon> do you think that gobject-introspection could be updated to the version in experimental? 0.6.15~git20100713-1 ?
<bigon> this version is needed for gnome-shell
<seb128> the gobject-introspection in maverick is newer than that
<seb128> it got 0.9
<asac> is anyone here who understands this gnome-sessio hack that uses X-Gettext-Domain or sometihng in .desktop file to select a specific gnome-session variant?
<asac> seb128: ?
<seb128> asac, the gettext domain is not for variants?
<seb128> asac, what do you call variants?
<asac> seb128: efl vs unity vs plain gnome
<asac> seb128: look at their desktop files. they all use "gnome-sessioN", but use a X-Gettext-Domain hack to choose which variant (e.g. xdg autostart dir)
 * sebner waves at asac :)
<seb128> asac, hum, it's a hack from didrocks I think but he's away 2 weeks
<asac> seb128: yeah i know thats why i wondered if anyone else knows about that. i wasnt able to spot the code that does that :((
<seb128> it's probably in gdm
<seb128> review the distro changes there
<asac> already did briefly ... let me look agian
<asac> wow we have a bunch of patches ;)
<ebroder> kaushal: Did you see someone already replied to your e-mail?
<asac> seb128: dont see it there using grep
<asac> lets look in gnome-session
<asac> not there either :/
<seb128> asac, let me check
<asac> it really feels like he is reusing some existing code ... otherwise he probably wouldnt have reused this awful Gettext thing ;)
<seb128> hum
<seb128> asac, 15_default_session.patch in gdm?
<seb128> asac, /etc/X11/Xsession.d/60xdg_path-on-session
<seb128> asac, I don't think X-Gettext-Domain is used for the default session
<seb128> asac, it's just the gettext domain for translations
<asac> hmm
<asac> seb128: so in /etc/X11/Xsession.d/60xdg_path-on-session there needs to be GDMSESSION set to "efl" somehow ... how is that working?
<asac> let me look at 15_default_session.patch
<seb128> asac, the etc change is changing the session parameter according to what you select in gdm
<seb128> asac, it's not what selects the session though
<seb128> asac, GDMSESSION has the value of the .desktop you select
<seb128> ie une.desktop will have GDMSESSION=une
<seb128> asac, those -une paths have special gconf keys and autostart etc
<asac> seb128: thats strange because the efl .desktop is called "une-efl.desktop", but the xdg path is: xdg-efl ... so where is the une- stripped ;)?
<asac> oh
<asac> wait
<asac> might be i am just looking at old (not cleaned up conffiles) here
<asac> seb128: kk ... all fine ;)
<asac> still feels hackish ;)
<seb128> ok
<asac> thanks
<seb128> np
 * asac has to think about this to understand what this means for his uxlaunch plans
<seb128> asac, /usr/share/gconf/une/mandatory/20_une-gconf-mandatory
<seb128> asac, see that for example
<asac> seb128: so to understand our efl session autostarts whatever is in /etc/xdg/autostart + /etc/xdg/xdg-une-efl/autostart ?
<seb128> asac, you might want to set the wm and the panel to what you want use
<asac> e.g. both?
 * asac checks that too
<asac> seb128: ok, but thos  /desktop/gnome/session/required_components/panel values etc are read by gnome-session, right?
<seb128> yes
<asac> e.g. if gnome-session starts with right XDG dirs all should be fine?
<asac> (given that all the gconf stuff is also there)
<seb128> asac, you don't use gnome-session?
<seb128>   XDG_CONFIG_DIRS="$DEFAULT_XDG_CONFIG_DIRS"/xdg-"$GDMSESSION":"$XDG_CONFIG_DIRS"
<seb128> asac, in the xsession.d
<asac> seb128: we use it. thats why i think i dont have to bother about /usr/share/gconf/une/mandatory/20_une-gconf-mandatory that much
<seb128> asac, ie it appends the path, so you get both yes
<asac> seb128: yeah. all fine. i will come back if i end up with issues
<seb128> asac, well what us uxlaunch?
<seb128> us -> is
<seb128> some sort of panel you want to run?
<asac> seb128: replacement for gdm
<seb128> oh ok
<asac> that doesnt have all the login stuff etc.
<asac> just a single user that auto logs in
<seb128> why do you want to use that?
<seb128> I guess you want to use lightdm next cycle
<asac> seb128: probably. we dont have requirement to select a different session in UI nor do we want to display any log-in on our images
<asac> and we want to be lightweight ;) ... might be we end up using gdm anyway. just wanted to try
<seb128> asac, just export GDMSESSION then in your script ;-)
<seb128> asac, we might switch to lightdm for ubuntu next cycle
<seb128> asac, but that's for next cycle...
<asac> yeah
<asac> seb128: is lightdm already in the archive?
<asac> i am happy to feature non-production-quality software in linaro images ;)
<seb128> hehe
<seb128> asac, no, but robert_ancell has a ppa
<seb128> not sure if he wanted to upload it to universe this cycle
<seb128> I think he does
<asac> seb128: robert is lagging on vacation right now?
<asac> or just timezone aka bed like weaknesses?
<seb128> he's still there for 2 or 3 weeks
<seb128> it's 2am for him
<asac> thanks
<asac> right. thats a weakness ;)
<seb128> so I guess he's sleeping
<asac> jk
<seb128> ;-)
<seb128> drop him an email maybe
<lfaraone> barry: re your message on
<lfaraone> barry: re your message on "Place for DDs and DMs to request syncs", you're talking about sort of a web interface to submittodebian?
<barry> lfaraone: hi!  yep
<barry> lfaraone: i don't know how feasible that is though
<lfaraone> barry: hm, that'd be interesting to write. would you know someone who'd want to design the UI for that?
<lfaraone> barry: well, we already have patches.ubuntu.com. We could pull from that and have a editor which would allow you to cherrypick from the diffs, with checkboxes or something, and generate a mail which LP sends to the BTS.
<barry> lfaraone: the launchpad folks have good designers for this kind of thing.  we should put it on lifeless's radar.  i don't know enough about submittodebian; would you be interested in submitting a lp bug report on this?
<lfaraone> barry: sure, I'll get on that.
<barry> lfaraone: that sounds pretty good
<barry> lfaraone: thanks!  send me the bug # and i'll ping lifeless (who's probably asleep right now :)
 * lfaraone 's just got a few things to finish up, but I'll get that done today.
<kenvandine> cjwatson, can you give ~ubuntu-desktop upload rights for libgwibber (currently in universe)?
<cjwatson> kenvandine: done
<kenvandine> cjwatson, thx!
<cnd> cjwatson, some of us in #ubuntu-touch are having issues with our radeon laptops
<penguin42> cnd: I'm curious what issues?
 * penguin42 runs a Radeon desktop
<cnd> we've found a workaround by setting GRUB_GFXPAYLOAD_LINUX=text
<cnd> penguin42, X never comes up
<penguin42> ah that one
<cnd> you might already know about it :)
<cnd> just thought I'd mention it
 * penguin42 tries to find the bug number
<penguin42> cnd: Bug 605614
<ubottu> Launchpad bug 605614 in linux (Ubuntu) "[ATI] GPU lockup with gfxpayload=keep" [Undecided,New] https://launchpad.net/bugs/605614
<penguin42> the failures you get from it can be a bit weird - mostly X not starting, but one boot it just failed all over with a random pile of apparmor errors and crud - I guess it's just a random corruption somewhere
<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.
<cnd> geser, how do I do so?
<cnd> and yes, utouch-gesturetest is the correct one
<geser> cnd: file a bug against gesturetest requesting its removal and subscribe ubuntu-archive
<cnd> ok, will do
<cnd> thanks!
<penguin42> Is there a right way to mark a bug that I think is a pretty serious regression in the current maverick alphas; I've done a nominated for maverick; it's bug 604087
<ubottu> Launchpad bug 604087 in iscsitarget (Ubuntu) "iscsitarget fails with can't create a target 2 0" [Undecided,Confirmed] https://launchpad.net/bugs/604087
<penguin42> using the (newer) debian package works, so in one way it's an easy fix
<jono> is anyone having problems with maverick upgrades
<jono> I get a tonne of dependency issues
<jono> it looks like gconf is causing many of them
<prefrontal> i'm creating 32/64 bit packages, each of which depends on two other packages that i created. the 32 bit packages are all working, but on 64 bit I get "Depends: * which is a virtual package"
<prefrontal> (aptitude gives that error output) it works fine on 32 bit, and i'm confused now..
<prefrontal> you can see the output here: http://pastey.net/139656
<prefrontal> on 32 bit `apt-cache depends emergent' shows libodeemergent and libquarter as real packages, but on 64 bit it shows them as virtual
<geser> jono: I updated my maverick just a few minutes ago without any problems
<geser> prefrontal: and you built the library as 64bit packages too?
<jono> geser, think I have it fixed now, thanks!
<cjwatson> cnd: please bring it up with the kernel team - grub is triggering it, but they're kernel issues that we need to have fixed
<prefrontal> geser, they are built in a 64 bit virtual machine
<cnd> cjwatson, ok, thanks
<cjwatson> cnd: (I'm willing to back out the grub change pre-release if need be, but I want to give the kernel team as much time as possible to fix things)
<cnd> cjwatson, whichever way is fine with me
<cnd> I just wanted to mention it in case you hadn't seen it before
<cjwatson> not with me, I'd much rather the kernel got fixed because then I can do shiny boot graphics
<cjwatson> cnd: oh, I've seen it LOTS
<cjwatson> had some long discussions with kernel folks at the sprint
<penguin42> cjwatson: I guess it's most Radeon users?
<cjwatson> penguin42: varies
<cjwatson> penguin42: I can't make any quantitative assertions with any accuracy, and I suspect neither can you. ;-)
<penguin42> cjwatson: Indeed
<geser> prefrontal: I guess you put your debs into a repository (as apt-cache works). Did you update it with your 64bit debs?
<prefrontal> geser, yes, i use this command, essentially the same as is used for 32 bit: cd /usr/local/ubuntu && dpkg-scanpackages dists/lucid/main/binary-amd64 /dev/null | grep -v -E 'Depends:[^a-z]$' > dists/lucid/main/binary-amd64/Packages && gzip dists/lucid/main/binary-amd64/Packages
<prefrontal> but, i appear to have fixed the problem ;-)
<prefrontal> somehow i passed -arch i686 to 64 bit for the last 4-5 major ubuntu releases, and my packages always worked.. switched it to -arch amd64 and it now works
<cjwatson> penguin42: iscsitarget> I'll deal with that
<penguin42> cjwatson: Thanks
<cjwatson> thanks for raising it
 * penguin42 has a nice little kvm iscsi server/client test setup - one kvm guest iscsi boots off another kvm guest running an iscsi server
 * penguin42 should think of something crueller to do to kvm
<cjwatson> penguin42: may take a little while, the 1.4.20.1 packaging is broken in some ways and 1.4.20.2 userspace doesn't work with 1.4.20.1 kernelspace
<cjwatson> penguin42: plus, 1.4.20.1 has a security vulnerability open against it anyway
<cjwatson> penguin42: so I think I'll ask the kernel team to bump to 1.4.20.2
<penguin42> cjwatson: There's also a bit of a mess in that we seem to have an iscsi kernel module in our kenrels, yet we still have an iscsitarget-source package
<cjwatson> penguin42: I'm OK with that, it's been the case in the past and I can imagine it being a useful get-out sometimes
<cjwatson> penguin42: having as much as possible provided in our stock kernel packaging is kind of deliberate
<penguin42> cjwatson: Yeh I'm ok with it being in the stock kernel, I'm not sure keeping the iscsitarget-source package is a good idea - I initially filed a bug complaining that it wouldn't build, but it's just not needed if it's in the kernel
<cjwatson> I'd prefer not to introduce extra divergence from Debian
<cjwatson> the less we diverge, the easier it is to merge
<penguin42> ok fair enough
<cjwatson> hallyn: re bug 606068, if you work on this, please be sure to do so against lp:ubuntu/iscsitarget in bzr, and note bug 604087 for why it can't be uploaded straight away
<ubottu> Launchpad bug 606068 in Ubuntu Server papercuts "[maverick] README.initiators missing" [Low,Confirmed] https://launchpad.net/bugs/606068
<ubottu> Launchpad bug 604087 in iscsitarget (Ubuntu Maverick) "iscsitarget fails with can't create a target 2 0" [Undecided,Confirmed] https://launchpad.net/bugs/604087
<hallyn> cjwatson: hm, ok, thanks
<penguin42> sorry, it was one of those days for a little flurry of bugs on the same package
<lool> lamont: Mind creating that build record for glib2.0/sparc?
<mathiaz> cjwatson: hi - where can I find the mkisofs command used to build the -server isos?
<mathiaz> cjwatson: I'd like to know which options are used
<lamont> lool: meh. ok
<cjwatson> mathiaz: you can extract it from lp:~ubuntu-cdimage/debian-cd/ubuntu, but it's tedious enough to extract it from the code that I just have it saved.  mkisofs -r -V 'Ubuntu 10.10 i386' -o foo.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /path/to/iso/tree
<mathiaz> cjwatson: great - thanks
<mathiaz> cjwatson: have the options changed over the releases?
<mathiaz> cjwatson: or they're quiet stable (since hardy+)?
<cjwatson> very little
<mathiaz> cjwatson: great - thanks again
<cjwatson> I don't think those have changed since something like dapper
<cjwatson> or maybe even earlier
<cjwatson> amd64 likewise; other architectures are different and less stable in places
<Jordan_U> I'd like to make a proposal for simplifying the process of recovering grub after installing windows. What's the best way to go about this? Create a wiki page, create a blueprint, send a message to a mailing list?
<sladen> robbiew: just for future reference, it might be better to _link_ to the IRC meeting log URL (rather than attaching 100kB of HTML)
<robbiew> it's only 100K...geez
 * sladen blinks
<robbiew> :)
<geser> robbiew: while we are at that topic: would it be possible to attach a plain text version instead of HTML?
<sladen> geser++
<sladen> perhaps a plain text attachment and a link to  http://irclogs.ubuntu.com/2010/08/16/%23ubuntu-meeting.html#t18:00  for the HTML would do it
<sladen> two birds with one stone
<jdong> fellow archive admins... bringing up sagemath again; is it possible to simply remove a package from jaunty and karmic?
<jdong> speaking with the Debian maintainer and upstream, the package was in an utterly broken state when it was auto-synced from Sid, and upstream has been getting quite irritated with users finding this package and concluding sagemath is broken
<jdong> I originally was thinking of doing a SRU, but the maintainer has no immediate plans to begin the undertaking of fixing the package
<cjwatson> afraid not - it would involve rewriting the Packages files in the release pocket which we try really really really hard not to do
<jdong> ah
<micahg> jdong: why not upload stub packages
<jdong> that's what I was going to ask next
<jdong> what's the next-most-preferred way of preventing users from installing the package?
<jdong> maybe better worded as "making upstream happier"
<cjwatson> I'm not sure, they all suck.  stub packages would be not entirely dreadful I suppose
<jdong> stubbed in what way, install it and nothing shows up?
<cjwatson> empty package with suitable descriptiveness
<jdong> yeah, I suppose that might be the next best compromise.
<ajmitch> so people had had sagemath installed would get it replaced with this empty package
<micahg> jdong: I just did empty packages for enigmail-locales (granted, I did a replaces on enigmail, but the emptiness is the same)
<ajmitch> assuming that's what you wanted
<jdong> mmm ok, I'll pass the word on to upstream and see if they want to proceed with that route
<ajmitch> it'd be nice if there was some way in the package to tell users about what happened, maybe with the notifier or NEWS file that gets shown
<jdong> right
<ebroder> What about having /usr/bin/sage or whatever be a 2-line shell script that echos "This package sucks. Please go actually get sage from http://[...]"
<jdong> haha
<jdong> can we replace /usr/bin/emacs with "this editor sucks, please go actually get vim....
<jdong> kidding!
<ebroder> Only if we replace /usr/bin/vim with "this editor sucks, please go actually get nano..." :-P
 * ajmitch lights up some torches & finds the pitchforks
<jdong> *groans* in other news, is there a "preferred" way of making an upstart job that starts as a non-root user?
<jdong> yes yes, insert rant about how the daemon should drop root itself
<ebroder> I think I filed a bug about that...
<jdong> doing a su hack is just simply ugly!
<ebroder> bug 586942
<ubottu> Launchpad bug 586942 in upstart "init: support dropping privileges" [Wishlist,Triaged] https://launchpad.net/bugs/586942
<jdong> cool
<jdong> I guess for an internal-user package I'll just su it :)
<jdong> while waiting for someone to do it correctly ;-)
<cjwatson> use start-stop-daemon
<cjwatson> you can just avoid using the features of s-s-d that are done better in upstart (like pidfiles)
<jdong> oh okay
<jdong> for some reason I thought start-stop-daemon was a sysvinit-ism
<cjwatson> nope, it's a dpkg tool to supplement init systems with what packages actually need
<jdong> ok gotcha, I'll use that then
#ubuntu-devel 2010-08-17
<superm1> jdong, be careful using su, it may open a console kit session, making an error popup whenever you try to shutdown using ck
<superm1> ran into that problem with mythbackend, and ended up patching in support to natively drop permissions in the app instead
<jdong> superm1: ouch. Fortunately this is just a topless server so I'
<jdong> err
<jdong> did I say that?
<jdong> I mean headless.
<jdong> same thing :)
<cjwatson> superm1: su is the wrong tool for nearly any job anyway, so I'm sure it's no great loss
<cjwatson> you certainly should never use it noninteractively, since it opens a PAM session
<cjwatson> and its argument parsing is awful
<cjwatson> man-db.postinst does a simple thing in perl; there are many options
<G> slangasek: FYI, I just updated 571093 (libvirt bug) looks like the SRU patch isn't the latest, the libvirt guys modified it slightly before pushing it and found a couple of other memory leaks
<slangasek> G: is the patch that's currently there free of regressions and an incremental improvement over the status quo?
<slangasek> (we're not going to have time for further fixes to libvirt before 10.04.1, so the question is whether we can commit to the current package in good conscience, or if I need to roll it back and respin candidate images)
<G> slangasek: I believe it is
<G> slangasek: let me just check one thing though
<G> slangasek: yep just double checked, I just noticed that we are in one case with the patch in proposed free'ing twice, but the function libvirt uses to free it, does check that it exists, so there shouldn't be a Null Pointer as a result
<G> slangasek: so I don't see any regressions in the code
<G> and the patch proposed, has been working for me for a while
<slangasek> G: great, will promote to -updates then - thanks!
<G> slangasek: no problem, it was a pain of a bug to try and reproduce :)
<penguin42> G: Are you using libvirt on a maverick install and if so do you find you have to disable the apparmor profiles for it?
<G> penguin42: ha, my maverick machine hasn't been updated for a while and I never got round to doing VM stuff on it, it's been on my TODO list for ages :)
<G> gotta work out the phantom reboots first, I think some are Kernel some PSU :(
<penguin42> G: OK, just wondered if it was just me; I have a pair of separte VM issues on maverick; apparmor and the SDL consoles broke a week or two
<penguin42> ago
<penguin42> hmm does 2.6.35 still have the alt-sysrq bug?
<G> (and I couldn't get kdump etc working to try and report the panics)
<penguin42> hmm no the forgetting about key up seems to have gone
<G> penguin42: is there a bug number for the libvirt/apparmor/SDL thing?
<penguin42> I've done the SDL one, not the apparmor one yet
<G> I might start to throw Maverick on my other box
<penguin42> G: bug 615077
<ubottu> Launchpad bug 615077 in qemu-kvm (Ubuntu) "[Maverick] SDL local window broken in last update" [Medium,New] https://launchpad.net/bugs/615077
<G> penguin42: I'll give it a go sometime :)
<penguin42> I'll try it again to see if it got fixed
<mathiaz> cjwatson: when netbooting d-i, is there a way to specify to install from the cdrom (ie take packages from the cdrom)?
<superm1> cjwatson, right, the reason the ck session was open was because of the pam.  so yeah good it's all sorted out now
<pitti> Good morning
<ajmitch> morning
<ion> hi
<rsalveti> pitti: do you know which process should be responsible for stopping ureadahead?
<rsalveti> it seems that nobody is stopping ureadhead, it's paused waiting for sigterm (stop)
<pitti> rsalveti: erm, I don't understand? it just exits by itself once it's done reading all the files
<pitti> rsalveti: oh, you mean the collector?
<ion> âstop on stopped rcâ
<rsalveti> pitti: yep, because it sets up the collector (debugfs) and then pause waiting for someone to stop it (send the sigterm)
<pitti> the collector is stopped by /etc/init/ureadahead.conf, "pre-stop exec sleep 45"
<rsalveti> then it'll generate the pack file
<rsalveti> but I don't know who is responsible for stopping it
<pitti> rsalveti: after those 45 secs, it gets stopped ("stopped rc" means all the rc*.d scripts ran)
<rsalveti> hm, so some other script is still running
<rsalveti> I just updated another machine to maverick and then I noticed this issue
<rsalveti> pitti: the weird thing is that rc is at "stop/waiting" but ureadahead is still "start/running"
<rsalveti> need to run upstart with debug to understand what's happening
<pitti> slangasek: AFAICS we now have everything in -updates for 10.04.1, right?
<slangasek> pitti: looks like it, though I see an openjdk security update was published to lucid-updates today
<pitti> slangasek: do you want to include that on new respins?
<pitti> there'll always be "that next update", after all
<pitti> I hear a kernel update is coming soon, too
<slangasek> pitti: no, I think we should go with it as-is; but I would have expected a freeze to be in effect on copies to lucid-updates at least until we took the point release snapshot
<slangasek> (which I'll go ahead and do now)
<pitti> oh, right
<pitti> slangasek: does that run automatically from cron these days?
<slangasek> the pocket copy?  I don't know
<slangasek> pitti: snapshot taken; I've also manually added the openjdk-6 sources to the snapshot, so we should be covered to proceed
<pitti> nice; so 10.04.1 is carved in stone now?
<pitti> slangasek: can you please ping me when you want to lift the -proposed freeze?
<slangasek> pitti: yes, I think 10.04.1 is locked in; everything is in -updates now that should be, if we do any further respins we can do them without -proposed, so please consider -proposed unfrozen
<pitti> ah, nice; time to process the large backlog then :)
<dholbach> good morning
<ion> hi
<bilalakhtar> 3
<bilalakhtar> sorry typed 3 by mistake
<ion> Thatâs unforgivable.
<bilalakhtar> ion: jokes are not forgiveable on this channel
<pitti> bilalakhtar: good bye, hello, good bye, hello again
<bilalakhtar> pitti: I cannot help. services takes a long time to assign me my cloak
<bilalakhtar> by that time irssi joins all the channels
<bilalakhtar> When is M-o-M supposed to be up again?
<bilalakhtar> manually merging until then
<dholbach> hola seb128
<seb128> hey dholbach
<StevenK> cjwatson: In regards to bug 582183, would you like initialise-from-parent to also copy the archive permissions?
<ubottu> Launchpad bug 582183 in Soyuz "initialize-from-parent should initialise package sets in new series" [Medium,Triaged] https://launchpad.net/bugs/582183
<pitti> StevenK: oh, it doesn't already? I. e. right now ACLs need to be set up again for each new release?
<ara> pitti, can I ask you a quick apport question?
<pitti> ara: sure
<ara> pitti, I am trying to add tags to a report (in an apport hook that I am writing)
<ara> if I put report['Tags'] = 'tag1 tag2', then 'maverick' and arch are not added
<pitti> ara: they are added before
<ara> but if I use report.setdefault, then tag1 and tag2 are not added
<pitti> ara: you need to use +=
<pitti> report['Tags'] += ' tag1 tag2'
<ara> pitti, ok, I tried that and debugging it (using python source_...) i got an exception, but I guess it works differently
<pitti> ara: ah, in that case they aren't added by apport of course
<bdrung> \o/ the sponsor request count for main is < 70
<pitti> ara: add this so that it works in both cases:
<pitti>     report.setdefault('Tags', '')
<pitti> bdrung: good work!
<dholbach> bdrung, woohoo!
<ara> pitti, OK, will try that
<ara> thanks a lot!
<bdrung> pitti, dholbach : thanks. i will be on vacation soon. hopefully the number won't be higher when i come back
<cjwatson> StevenK: yes please, would save me a deal of hassle
<cjwatson> slangasek: yes, copies from -security to -updates are cronned; I shouldn't think that matters because builds happen from -security as well anyway, in other words the thing that arguably should have been frozen was security publications rather than copies to updates
<ara> pitti, one more question, if the application crashes, and the package has an apport hook, will apport attach the information in the hook (apart from coredump)
<ara> ?
<pitti> ara: yes, that's the main point of those :)
<pitti> ara: you can test that locally by starting the app, and killall -SEGV appname
<pitti> then apport will come up, and you can click the "details" expander to see the repot
<pitti> report
<ara> pitti, thanks again, you rock :-)
<pitti> ara: you too! :0
<pitti> my shift key doesn't
<ara> :D
<wgrant> cjwatson: Do you want xz for 3.0 sources as well?
<cjwatson> wgrant: I figured one thing at a time; that should be a separate bug
<cjwatson> wgrant: I have a diff locally for data.tar.xz; was just looking for a *cough* pre-impl chat in #launchpad-reviews
<wgrant> Yes, they do often tend to be "pre"-imp...
<cjwatson> wgrant: though to give you a straight answer, .orig.tar.xz or whatever isn't an immediate priority for me; my motivation is in https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-spring-cleaning
<wgrant> Ah, so just killing off existing lzma stuff?
<cjwatson> right
<Riddell> dholbach: you can wipe ~dholbach/tmp/sponsoring-list, all done
<dholbach> Riddell, done, thanks a lot
<Riddell> dholbach: who should I subscribe to bug 617787 to get it approved?
<ubottu> Launchpad bug 617787 in Ubuntu "Sync request: 3depict" [Undecided,New] https://launchpad.net/bugs/617787
<\sh> hmm...did anybody setup a squeeze sbuild chroot with mk-sbuild in the last days? it stops with "finish: apt-get command not found"
<dholbach> Riddell, ubuntu-sponsors
<soren> Hm... I have a build that failed in lucid-proposed, but worked excellently in my PPA. A debdiff between the two source packages only shows the different versions I used in debian/changelog and a different timestamp. It's a bit of a mystery.
<soren> The build that works: https://edge.launchpad.net/~soren/+archive/nova/+build/1918475
<soren> The build that failed: https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058
<soren> Everything is pretty much identical up until the build starts (the lucid-proposed build apparantly has lucid-proposed enabled which my ppa does not. Only difference seems to be an unrelated change in libc6).
<soren> The build starts out running a "make oldconfig" on the kernel. The build log from the non-PPA buildd suggests that the kernel's build system thinks it's a 32-bit system, but it's not.
<soren> Does anyone have any clues?
 * soren is inclined to retry the build.
 * soren saves the build log and retries the build
<\sh> can someone approve lucid nomination for bug #533369 and eventually fix it ? :) thx
<ubottu> Launchpad bug 533369 in debootstrap (Ubuntu Karmic) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,New] https://launchpad.net/bugs/533369
<cjwatson> I've approved the nomination but have no time to do SRUs just now
<\sh> cjwatson: thx :)
<cnd> seb128, what do I need to do to start the ball rolling on MIRs for utouch stuff?
<cnd> https://wiki.ubuntu.com/MainInclusionProcess?
<seb128> cnd, write mir reports for those?
<cnd> ok, I assume it's documented there
<cnd> I asked before I google searched
<zul> did 10.04.1 go out?
 * cnd chastises himself
<cnd> thanks seb128
<seb128> cnd, right, that page describe what you need to do
<\sh> cjwatson: if it helps you, I'll prepared an debdiff for the SRU (needs uploading to lucid-proposed)
<Riddell> siretart: do you know what the status of bug 374900 is?  can it be closed?
<ubottu> Launchpad bug 374900 in faac (Ubuntu) "Libfaac not LGPL" [High,Triaged] https://launchpad.net/bugs/374900
<cjwatson> \sh: I thought you were a core-dev - can't you upload it directly?
<cjwatson> \sh: the debdiff isn't what takes the time for SRUs for me, it's the administration
<\sh> cjwatson: I'm not :)
<\sh> cjwatson: anymore :)
<cnd> I made a bug report against the upstream project in lp, how can I move that to the ubuntu package project?
<cnd> or is that possible?
<soren> cnd: Click the "also affects distribution" link.
<cnd> soren, ahh
<cnd> thanks!
<soren> cnd: Sure.
<\sh> micahg: ping
<cnd> seb128, does a packages build deps all need to be in main, or just binary package deps?
<seb128> build-depends as well
<siretart> Riddell: the TB has asked cjwatson to look into this. Collin, any news on that?
<chrisccoulson> hi persia - do you mind if i hijack bug 522645, or did you plan to do any work on that?
<ubottu> Launchpad bug 522645 in chromium-browser (Ubuntu) "[MIR] chromium-browser" [Undecided,Incomplete] https://launchpad.net/bugs/522645
<persia> chrisccoulson, I never intended to work on it: I filed it because there were discussions as to whether it would be in main, and I thought they should be tracked in a bug.  You aren't hijacking it (or I would have been assigned)
<chrisccoulson> persia - cool, thanks. i'll use your existing report then rather than starting a new one
<persia> chrisccoulson, That's why it's there :)  Good luck.
<cjwatson> siretart: none, sorry
<cjwatson> (P.S. "Colin")
<chrisccoulson> heh, thanks ;)
<tgardner> how can I figure out where a Linaro kernel package lives? linux-image-2.6.35-1001-omap_2.6.35-1001.5_armel.deb is not in http://archive.ubuntu.com/ubuntu/pool/{main,universe}/l/linux or http://ports.ubuntu.com/ubuntu-ports/pool/{main,universe}/l/linux
<ogra> linux-image-2.6.35-1001-omap_2.6.35-1001.5_armel.deb ?
<ogra> that would conflict with the existing omap image, no ?
<tgardner> ograthe ABI is different
<tgardner> ogra: ^^
<ogra> still very confusing
<dholbach> https://edge.launchpad.net/ubuntu/maverick/+queue?queue_state=3&queue_text=linux-image-2.6.35-1001-omap
<ogra> tgardner, cant you have a linaro in the name somewhere ?
<tgardner> ogra: thats what I'm working on
<ogra> ah
<ara> persia, hi!
<ogra> tgardner, is the package through the NEW qeueu already ?
<ogra> (else you wont find it in the archive)
<tgardner> dholbach, we pull the package from the archive to extract the ABI, so I need to know the URL
<persia> ara, The document I'm sure you want to ask me about has been getting better every couple days, but still doesn't quite make sense to the uninitiated.
<dholbach> tgardner, I'm afraid I don't know
<tgardner> ogra: I think so. checking...
<dholbach> tgardner, I just searched for it
<ogra> the meta is at http://ports.ubuntu.com/ubuntu-ports/pool/universe/l/linux-linaro-meta/ but i dont see the actual package
<ara> persia, OK, thanks for the update
<ara> persia, anything I can help with?
<dholbach> tgardner, does https://edge.launchpad.net/ubuntu/+source/linux-linaro help?
<JFo> persia! hope I didn't miss your ping in the recent past. I know you said you wanted to talk with me after Platform.
<persia> ara, Not right now, but I'll copy you on the next review round: I'm still processing notes from the last review (separation of policy & procedure, etc.)
<tgardner> dholbach, I can see it via Launchpad, but I'm not finding the binary in the archive
<persia> JFo, I think I didn't ping you, but I'll accept reverse pings :)
<JFo> heh
<dholbach> tgardner, ok
<ogra> tgardner, http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-linaro/
<ogra> there it is
<tgardner> ogra: wtf? why did it go there
<cjwatson> armel is all on ports
<ogra> tgardner, someone accepted it into main and its armel
<zyga> is anyone here using GMA500 on maverick?
<tgardner> cjwatson, its not ports that I'm questioning, it linux-linaro
<cjwatson> well that's just the source package name somebody gave it
<ogra> Changed-By: John Rigby <john.rigby@linaro.org>
<ogra> Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
<ogra> Signed-By: Tim Gardner <tim.gardner@canonical.com>
<ogra> tgardner, well, you apparently signed it :)
<tgardner> cjwatson, ok, I get it now. it follows the source package name. guess I should have figured that out.
<nigelb> bdrung: OMG, you're fast.
<nigelb> I just saw a debdiff uploaded within 45 minutes of posting.
<bdrung> nigelb: i am always fast :P
<nigelb> Even before I could catch up with the mail trail ;)
<nigelb> bdrung: Now I know :D
<bdrung> nigelb: your debdiff for karmic needs a refresh and sponsor-patch should not pull a version from -backports
<nigelb> bdrung: wait, It should \sh gave a new debdiff?
<nigelb> ah, that was for lucid.
<nigelb> ok, I'll try to get to it.
<highvoltage> sabdfl: hi! any chance on choosing a name for 11.04 soon? it's getting to that part in the release cycle where people are writing maverick+1 a lot :)
<\sh> nigelb: what?
<\sh> bdrung: thanks for sponsoring
<bdrung> \sh: yw
<kirkland> pitti: ping
<nigelb> \sh: um, sorry about the ping. It was about the debbootstrab bug for which you uploaded debdiff for sru.
<soren> I'm still wondering about my user-mode-linux ftbfs in lucid-proposed. An identical build in my ppa worked flawlessly. Is there any reason whatsoever why an amd64 buildd would report a 32 bit personality?
<cjwatson> *blink* cosmic rays?
<cjwatson> not that I can think of, maybe check with lamont
<soren> It did it twice.
<soren> The only way I can get it to fail in a similar way for on my local box is by prefixing dpkg-buildpackage with linux32.
<soren> lamont: Any clues at all?
<soren> https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058 <---- the build in question
<chrisccoulson> soren - it's funny you should mention that, as i've just started getting loads of weird build failures on amd64 for all of the mozilla daily builds
<soren> chrisccoulson: Fascinating.
<chrisccoulson> things like this - http://launchpadlibrarian.net/53843956/buildlog_ubuntu-maverick-amd64.firefox_3.6.9~hg20100817r34534%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
<soren> chrisccoulson: On all buildd's or just..
<lamont> soren: interesting as all get out
<chrisccoulson> soren - on everything, on all releases
<lamont> in fact, i386 builds are frequently done on amd64 kernels, with linux32 in front of things
<chrisccoulson> soren - https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages
<soren> lamont: This is an amd64 build.
<chrisccoulson> all todays builds failed :(
<soren> chrisccoulson: Even in the PPA?
<cjwatson> there was some chatter about repurposing some amd64 PPA buildds as i386; I smell a rat
<chrisccoulson> soren - yeah, these are all PPA builds
<soren> chrisccoulson: Ah, I see.
<lamont> sh: gcc: not found
<lamont> dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation)
<lamont> I  don't like that much
<cjwatson> that always happens, doesn't it?
<elmo> yes, it does
<soren> I thought so too. It didn't raise an eyebrow.
<cjwatson> I thought that was an artifact of something being run outside the chroo
<soren> Ok.
<cjwatson> t
<seb128> that's not new for sure
<lamont> true
<\sh> nigelb: I didn't do the karmic one...cause I didn't have a karmic sbuild right now
<lamont> the machine clearly thinks it's amd64...
<nigelb> \sh: I know.  bdrung has asked me to refresh it a bit :)
<soren> Kernel build from 10 hours ago worked fine. My initial build that failed was from 6-7 hours ago. Did anything change roughly in that timeframe?
<\sh> nigelb: cool...
 * soren does an experiment
<lamont> soren: I assume MCORE2 is 64-bit, yes?
<\sh> now gone from office
<bdrung> nigelb: i would have refreshed it, but sponsor-patch pulls the wrong version. i need to fix this first.
<soren> lamont: It supports both.
<chrisccoulson> cjwatson - checking target system type... i686-pc-linux-gnu
<chrisccoulson> checking build system type... x86_64-pc-linux-gnu
<chrisccoulson> :/
<soren> err.. obviously.
<nigelb> bdrung: heh, trying to fix one bug exposes another.  Normal :)
<bdrung> nigelb: it's unrelated. it's the first package i touch that had a backport
<soren> lamont: CONFIG_MCORE2 is set by the config. It chooses the config based on dpkg --print-architecture (which, incidentally perhaps, is unaffected by personality).
<nigelb> bdrung: Ah, cool :)
<lamont> well, and crested is amd64 with an amd64 chroot, so shouldn't matter
<bdrung> nigelb: do you have the bug number at hand?
<soren> lamont: Unless something accidentally runs it with linux32.
<lamont> soren: the last thing I'm aware of that has even a remote chance of having affected it happened on crested 20 hours ago
<soren> lamont: Can you bump the build score of this: https://edge.launchpad.net/~soren/+archive/ppa/+build/1922960 ?
<lamont> and everywhere else about the same time
<soren> lamont: It's a bit of an experiment.
<soren> lamont: And what would that be?
<lamont> Start in 1 minute (55555555)
<lamont> lp-buildd upgraded
<soren> Wow.
<soren> I feel so special.
<lamont> OTOH, changes were all elsewhere
<lamont> string of 5's is my "special" value.
<nigelb> bdrung: 533369
<nigelb> bdrung: bug 533369
<ubottu> Launchpad bug 533369 in debootstrap (Ubuntu Karmic) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,New] https://launchpad.net/bugs/533369
<bdrung> nigelb: thx
<soren> Aha!
<soren> Linux promethium 2.6.24-27-xen #1 SMP Wed Mar 24 12:56:18 UTC 2010 i686 GNU/Linux
<soren> from the amd64 build.
<soren> (output of uname -a)
<soren> lamont: ^
<soren> i686 == bad
<soren> :)
<chrisccoulson> so, that will be why all my builds fail then ;)
<soren> Indeed.
<chrisccoulson> phew :)
 * chrisccoulson wipes brow
<lamont> neat
<soren> Maybe the kernel got lucky, because it specifically passes an ARCH value.
<soren> user-mode-linux's ARCH setting is "um", the SUBARCH is detected from uname -m.
 * lamont yanks the rug out from under promethium, investigates
<slangasek> cjwatson: well, it's rather a long window to freeze all security updates, and in the past I thought we did handle this as freezing -updates publishing only since the relevant question is whether we have the source to reproduce the images?  or maybe I've not accurately understood the purpose of the archive snapshot
<cjwatson> slangasek: I may be wrong; I suspect there is room for process refinement ...
<soren> lamont: I doubt it's specific to promethium. If you're just picking a random one for investigation, that's cool, but I'm seeing the same on crested and chrisccoulson had it happen on a bunch of different ones.
<soren> lamont: just sayin'.
<lamont> yeah - just picking a random known place
<lamont> and I have my suspicion
<hallyn> so i've got a bzr branch that i had proposed for merge, and the relevant commits were in fact merged into lucid-proposed.  But the tree is still listed as pending merge.  Shoudl I cancel the merge request, or leave that until it gets from lucid-proposed into lucid-updates?
<soren> lamont: Lovely.
<soren> chrisccoulson: Thanks for chiming in. I would have stared at this for hours thinking it was local to this package.
<soren> chrisccoulson: Or days, even.
<lamont> soren: so...  I've put all of amd64 on manual for a little bit while I do somemore investigating.
<lamont> since all around, feh.
<chrisccoulson> soren - heh, you're welcome ;)
 * soren is stubborn with stuff like this
<chrisccoulson> i probably also would have spent a long time looking at it if cjwatson didn't suggest what the issue might be ;)
<soren> chrisccoulson: What? Cosmic rays? :D
<cjwatson> we might need to look into the possibility that there have been misbuilds
<lamont> cjwatson: verily
<hallyn> rephrase:  does a merge proposal need to stay open for commits to propagate from lucid-propsoed to lucid-updates?  Or will that happen (barring regressions/objections) regardless?
<cjwatson> the merge proposal doesn't need to stay open for that
<hallyn> cjwatson: thanks
<cjwatson> if it's been (effectively) merged into its target branch, you can mark it as merged
<hallyn> cjwatson: don't see how to do that in the lp bzr page (need some special privs?) but i've deleted the proposal, so hopefully all's good
<cjwatson> that should be fine
<hallyn> (though then it always lists as 'supserseded' for merge...  weird)
<mih1406> Hi, I am learning C++/Qt and want to switch to GTK
<mih1406> What are the packages that I need as a C++/GTK developer?
<SpamapS> hallyn: you can just change the status to "Merged", can't you?
<mih1406> I do not want GTK+, I want GTKmm. But I do not know which packages I need?
<cjwatson> mih1406: libgtkmm-2.4-dev is the primary one, and you'll probably want libgtkmm-2.4-doc too
<cjwatson> (apt-cache search gtkmm)
<hallyn> SpamapS: where?
<mih1406> Is there a documentation for GTKmm packaged?
<lamont> soren: version bump and re-upload your testpackage, give me the build record pls?
<lamont> assuming it built successfully rather than failing, that is
<soren> lamont: 2 seconds.
<soren> lamont: https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058
<soren> lamont: Just rebuild that one.
<cjwatson> mih1406: libgtkmm-2.4-doc
<lamont> sure
<soren> Heh. Launchpad has apparantly given up guessing when it'll build :)
<lamont> 0 builders
<soren> Ah, of course.
<soren> lamont: That's not a PPA build, by the way. Don't know if you noticed or it matters at all.
<mih1406> cjwatson: libgtkmm-2.4-dev requires many packages!!
<lamont> aborted all the currnetly-running amd64 builds
<mih1406> Are they important?
<lamont> soren: yeah, no worries
<mih1406> 57 packages!
<cjwatson> mih1406: yes, they're part of the interface
<cjwatson> mih1406: (how much time do you want to spend second-guessing dependencies, versus getting on with your work? :-) )
<mih1406> "second-guessing" ??
<soren> "questioning".
<soren> Sort of.
<mih1406> sorry for that
<lamont> mih1406: 100+ packages for build-depends is not a rare situation.  just fyi
<bilalakhtar> cjwatson: as for the meeting time problem, do you suggest earlier or later?
<mih1406> I want to develop in C++ and GTKmm what are good tools for that?
 * jdong would be tempted to suggest a waterproof laptop and large amounts of vodka
<cjwatson> bilalakhtar: I plan to suggest both and see what people like
<bilalakhtar> cjwatson: well, my opinion doesn;t count that much, but I would say, early
<cjwatson> bilalakhtar: it will have to be something that the board members can consistently make
<bilalakhtar> cjwatson: yup, it appears persia is in a very eastern time zone, so for persia it would also be 'early'
<soren> lamont: Perhaps I should come up with a quicker test case :)
<soren> lamont: There it goes.
<soren> lamont: It works.
<SpamapS> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel - "Open to all to subscribe, posting moderated for people who are not Ubuntu developers" ...
<soren> lamont: It wouldn't have made it this far if it still failed.
<SpamapS> Maybe its asking too much, but there seems to be no manpower behind said moderation.
<lamont> cjwatson: 13 suspect builds, 12 if you ignore soren's lum build
<SpamapS> Which, I know as an aspiring ubuntu developer, is fairly frustrating if you'd like to weigh in on anything. :-/
<cjwatson> bilalakhtar: OTOH push it much earlier and it's painful for USians
<cjwatson> or Americans in general
<cjwatson> always difficult
<bilalakhtar> cjwatson: yup
<cjwatson> SpamapS: I just did a partial moderation pass ...
<bilalakhtar> with a developer community that huge its difficult to find the right time
<cjwatson> SpamapS: I wouldn't object to more help, it's me + ev right now
<SpamapS> cjwatson: You've been amazing at moderation. But I think you have quite a few things that count as higher priority on your plate. :)
<cjwatson> though I do think moderators should be core-dev
<cjwatson> I don't think I can claim to be an amazing moderator, no
<SpamapS> I'm not saying I expect instant moderation. But the lag time for emails I've sent to ubuntu-devel has been 7-10 days since subscribing in June.
<lamont> soren: awesome.  time to go roll all the amd64 builders around
<soren> lamont: Care to share the gory details?
<cjwatson> bilalakhtar: we may just need to rotate or something
<bilalakhtar> cjwatson: yup
<bilalakhtar> bye, people
<soren> cjwatson: I'm sure I've mentioned it before, but 4 in the morning is a better time for me than the current one.
<SpamapS> cjwatson: I hate being a complainer when much of the work is in fact volunteer, so please feel free to tell me to stuff it and just concentrate on development. ;)
<cjwatson> no, complaints are good reminders
<lamont> soren: only under duress
<soren> lamont: :)
<soren> Oh, well, good times. It works now, I'm happy.
<soren> lamont: Thanks for looking into it so quickly.
<lamont> soren: at this point, the 12 affected builds (1) might not be completely accurate, and (2) all I have is build ids.. working on getting actual URLs/package/version/archive info for them
<soren> lamont: How do you determine whether they're affected?
<lamont> any amd64 build "first dispatched" since 20:00:00 UTC yesterday
<soren> There's only 12 of those? Wow.
<lamont> I think we looked at builds launched since then, and found that none had been not first dispatched since then, but started.
<lamont> soren: 13 with you.
<lamont> this is a happiness
<lamont> or at least a lesser sadness
<soren> Yeah, 12 builds are certainly a manageable set to have to rebuild.
<soren> Of course, this is only counting ubuntu proper, right? Not PPA's?
<lamont> all of lp, I believe
<micahg> I have 30 builds amd64 builds that FTBFS last night
<lamont> though I'm suspcious
<lamont> so make that "yeah, that doesn't include ppa", i fear
<cjwatson> micahg: we only really need to worry about the ones that succeeded
<soren> I have had 10 in the last 20 hours, I'm sure.
<cjwatson> the rest can be given back en masse
<micahg> cjwatson: ah, ok
<lamont> cjwatson: exactly.  the successes are the ones that worry me
<lamont> yellow fixed, and back in the game.  now for some ppa fun
<ari-tczew> cjwatson: ping for private message
<bdrung> nigelb: done
 * nigelb hugs bdrung :)
<bdrung> nigelb: you're welcome.
<bdrung> seb128: your glib 2.25.14-1ubuntu1 upload: "Resync on Debian". is it a sync or a merge?
<seb128> bdrung, it's a "grab the diff for the other upload listed in the change and apply that to ubuntu and upload"
<seb128> ie not bothering to merge again, just applying a debian revision
<seb128> bdrung, why?
<bdrung> seb128: sync means to me same version. then it's just a merge without stating the remaining changes
<seb128> bdrung, it's not a merge, it's backporting a debian change
<bdrung> looking at https://launchpad.net/ubuntu/+source/glib2.0/2.25.14-1ubuntu1/+build/1922843 - some package build will be broken for two days
<seb128> ?
<bdrung> seb128: aha, ok
<bdrung> seb128: "Start 2010-08-19"
<seb128> right, read backlog
<seb128> I think amd64 builders are under work
<bdrung> seb128: can you give me a time for the backlog?
<bdrung> s/time/start time/
<seb128> bdrung, 1:10 ago where lamont and soren and chrisccoulson were discussing
<lamont> seb128: interestingly, that build wasn't listed as one of the affected - had you given it back before I finished that bit?
<lamont> seb128: that is, more than 26 min ago?
<seb128> lamont, I didn't give it back but uploaded like 2 hours ago
<lamont> that would fit
<lamont> does it need a push?
<lamont> or just when it lands is fine?
<bdrung> lamont: the build blocks https://launchpad.net/ubuntu/+source/qemu-kvm/0.12.5+noroms-0ubuntu2 build on amd64
<pgraner> kirkland, ping
<kirkland> pgraner: yo
<pgraner> kirkland, getting weird screen error message after todays update on maverick
<pgraner> kirkland, using byobu for login
<kirkland> pgraner: what's the error message say?
<pgraner> pgraner@lenovo-T410:~$ ssh emerald.local
<pgraner> Cannot make directory '/var/run/screen': Permission denied
<pgraner> pgraner@emerald:~$
<kirkland> pgraner: maverick, or lucid on emerald?
<pgraner> kirkland, sorry emerald is lucid
<kirkland> pgraner: okay, right, there's a fix in lucid-proposed
<kirkland> pgraner: init race condition caused that problem for you
<pgraner> kirkland, ack
<kirkland> pgraner: you should be able to fix it in the mean time with "sudo service screen-cleanup start"
<pgraner> kirkland, ack, thanks
<pgraner> kirkland, just wanted to make sure you saw it
<kirkland> pgraner: yup, thanks, you want the existing bug number?
<pgraner> kirkland, nope, its in a proposed update I'm golden
<kirkland> pgraner: cool, yeah, thanks.
<djzn> when is 10.04.1 be out today, is it still some hope for today?
<djzn> cjwatson: does 10.04.1 get release today (ISOs)...?
<cjwatson> djzn: don't know yet
<sebner> Glib uploads are nasty, it seems it broke empathy :P
<sabdfl> highvoltage: http://www.markshuttleworth.com/archives/478
<smoser> pitti, i updated bug 582667. could you check it again for lucid-proposed ?
<ubottu> Launchpad bug 582667 in cloud-init (Ubuntu Lucid) "add support for set selections" [Undecided,Confirmed] https://launchpad.net/bugs/582667
<sebner> seb128: meh, GLib-GIO-ERROR **: Settings schema 'org.freedesktop.Telepathy.Logger' is not installed
<highvoltage> sabdfl: awesome :)
<bdrung> i get an oops when i retry to build eclipse on i386 (https://launchpad.net/ubuntu/+source/eclipse/3.5.2-5/+build/1844712/+retry)
<highvoltage> http://www.weebls-stuff.com/songs/Narwhals/
<tonyyarusso> narwhal...awesome.
<seb128> sebner, context?
<sebner> seb128: <sebner> Glib uploads are nasty, it seems it broke empathy :P
<seb128> lamont, sorry I was away, when it lands is fine
<micahg> bdrung: well, it's scheduled anyways
<seb128> sebner, works fine there
<sebner> seb128: do you have latest glib updates installed?
<seb128> sebner, yes, I tested it before uploading
<sebner> meh
<sebner> seb128: any advice what I can do?
<seb128> sebner, ls /usr/share/glib-2.0/schemas/
<sebner> seb128: uhh, http://pastebin.com/7JG8idba
<tonyyarusso> (Say, anyone know if 10.04.1 is still on track for today?)
<seb128> sebner, seems rather a bug in the telepathy-logger update then
<sebner> hmm
<sebner> ah, you where the uploader there too, fine
<tonyyarusso> On a related note, high five to robbiew for interim release managing, and Kate on the new job - I wasn't aware until just now that slangasek had left the position.
<sebner> seb128: it's not installed. needs a stronger dependency?!
<seb128> sebner, I'm checking now, I just synced this one on Debian
<tonyyarusso> (What's Kate's nick?  Is this someone I'll recognize?)
<robbiew> tonyyarusso: running into a wubi bug, but hopefully we can workaround it
<seb128> sebner, empathy recommends telepathy-logger weird
<seb128> sebner, I guess it should be a depends
<sebner> seb128: wasn't there some mail that recommends is not installed by default anymore? Btw, installing it fixes the problem
<tonyyarusso> robbiew: ah, okay.  If the list is down to one bug that's getting pretty darn close, so I'll take that.
 * tonyyarusso needs to wipe and reinstall a couple of systems, figured he might as well do it with a .1 image
<seb128> sebner, no, the email was from Keybuk and about recommends not being installed on the buildds
<sebner> ah Ic
<slangasek> tonyyarusso: candidate images are up, feel free to test them and give us feedback? :)
<seb128> sebner, empathy must have been working in a buggy way for you before without telepathy-logger
<seb128> sebner, ie you probably didn't have any logging on chat history
<sebner> seb128: I definately had
<tonyyarusso> slangasek: I could do that - where?
<tonyyarusso> just under dailies or something else?
<slangasek> tonyyarusso: http://cdimage.ubuntu.com/lucid/
<slangasek> tonyyarusso: or http://cdimage.ubuntu.com/ubuntu-server/lucid, or ../kubuntu/..
<tonyyarusso> right, 'k
<sebner> seb128: anyways, working now. thanks for you help :)
<seb128> sebner, your're welcome
<seb128> sebner, I will change the recommends to a depends
<sebner> fine
 * sebner hugs seb128 :)
<seb128> ;-)
<seb128> I'm still wondering why the recommends didn't work
<sebner> seb128: I'm even more wondering because in the morning it was still working, now the day is over, installed all updates and it didn't start
<sebner> and there was no empathy update
<seb128> well you should have got telepathy-logger installed way before
<seb128> you probably didn't have logging for all this time
<sebner> seb128: as I said, I definately had logging before since I use this feature from time to time, but yes, it seems telepathy-logger was never installed before on this system
<seb128> sebner, well logging was working until empathy stopped doing it in favor of telepathy-logger
<seb128> which has been done some weeks ago now
<sebner> seb128: telepathy-logger seems to be pretty new anyways, first upload was in june/july
<seb128> right
<lamont> cjwatson: it appears that there were no successful amd64/lpia builds during the period in question.
<lamont> cjwatson: or maybe I'm misparsing things
<seb128> lamont, should I be concerned about all the build failures on amd64?
<seb128> lamont, or will you retry those after the buildds issues are solved?
<lamont> buildd issues are solved.  it would help my current effort if you told me a couple of the builds in question, but didn't retry them yet.
<lamont> and I have an eye appt that I'll need to leave for in about 25 min
<lamont> seb128: ^^
<lamont> (and right now, I don't care if it's ppa or non-ppa examples of the issue, pass or fail)
<seb128>  * Build Log: https://launchpad.net/ubuntu/+source/gtksourceview2/2.10.4-1/+build/1922335/+files/buildlog_ubuntu-maverick-amd64.gtksourceview2_2.10.4-1_FAILEDTOBUILD.txt.gz
<seb128>  * Build Log: https://launchpad.net/ubuntu/+source/telepathy-logger/0.1.5-1/+build/1922341/+files/buildlog_ubuntu-maverick-amd64.telepathy-logger_0.1.5-1_FAILEDTOBUILD.txt.gz
<seb128>  * Build Log: https://launchpad.net/ubuntu/+source/libgnomekbd/2.31.5-0ubuntu2/+build/1922643/+files/buildlog_ubuntu-maverick-amd64.libgnomekbd_2.31.5-0ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> lamont, ^ some recent failures
<seb128> bah
<seb128> those are on glib installability issues sorry
<micahg> lamont: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/1921965/+files/buildlog_ubuntu-maverick-amd64.firefox_3.6.9%7Ehg20100817r34534%2Bnobinonly-0ubuntu1%7Eumd1_FAILEDTOBUILD.txt.gz
<lamont> yeah - I was going to say... they seem to predate the issue...
<lamont> micahg: ta
<micahg> lamont: there are 29 more in that PPA :)
<lamont> jsregexp.cpp:4730: Error: operand type mismatch for `call' <-- that seems a bonafide failure, no?
<lamont> also predates the rollout yesterday
<micahg> sorry, that must have been different, I know I saw some
<micahg> that's after 20:00 UTC yesterday
<micahg> lamont: here's one: http://launchpadlibrarian.net/53842834/buildlog_ubuntu-karmic-amd64.xulrunner-2.0_2.0~b4~hg20100817r50707%2Bnobinonly-0ubuntu1~umd1~karmic_FAILEDTOBUILD.txt.gz
<lamont> same ppa though?
<micahg> lamont: yeah
<lamont> micahg: I need the buildid, not the librarian URL
<micahg> oh, ok
<micahg> lamont: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/1921926
<lamont> thanks
<lamont> and most interesting.
<lamont> micahg: is it ok if we leave that PPA alone until I get done figuring things out?
<micahg> lamont: how long is that, a new round is scheduled for 4:30 UTC, but I can ask for it to be delayed
<lamont> oh, uploading new stuff doesn't matter
<lamont> I'm just asking that you specifically do not retry those builds
<micahg> lamont: k, but they'll probably be superceded tonight, that's why I ask
<micahg> at least some of them
<lamont> yeah - superseded is fine
<lamont> the new upload will get a new build record, so not my worry
<micahg> lamont: k, I'll not retry and tell the others :)
<lamont> thanks
<pandora> hi guys, is 10.04.1 being released today?
<kirkland> pgraner: you should be able upgrade that machine's screen to lucid-proposed now, if you like
<jdstrand> soren: hey, so I am pretty sure vmbuilder isn't going to play well with libvirt 0.8.3
<jdstrand> soren: libvirt now requires that you specify the disk format for disks. if none is specified, libvirt defaults to raw
<jdstrand> soren: which is fine for raw disks, but it looks like vmbuilder a) defaults to qcow2 and b) doesn't specify the disk format, so the domain won't start
<jdstrand> soren: basically, you need to add something like this:
<jdstrand>     <disk type='file' device='disk'>
<jdstrand>       <driver name='qemu' type='qcow2'/>
<jdstrand>         <source file='...
<jdstrand> err... that last 'source' didn't need to be indented
<jdstrand> soren: actually, it seems vmbuilder has more problems than that... I suggest giving it a thorough testing
<tonyyarusso> slangasek, robbiew: lucid candidate for i386 alternate installed and is up and running fine for me btw.
<robbiew> tonyyarusso: thnx...we have a few cornercase windows-related testcases left...wubi and migration assistant
<robbiew> figured a standard install would be fine ;)
<tonyyarusso> Well, it's actually not *entirely* standard - I have it running on VMware ESXi, and connecting to it via XDMCP with Xming.
<tonyyarusso> but yeah, no wubi nonsense here.
<soren> jdstrand: Yeah, it's in dire need of love. I'll apply some very soon. I actually have a good excuse to spend work time on it now, as it happens.
<jdstrand> \o/
<sladen> jdong: empty package which Conflicts with something essential like  base-files  ?
<ebroder> Hmm...is it normal to get the low-res, low-color plymouth splash when I have nvidia-current installed? Before when I was using the free drivers, I got a full-res splash
<ebroder> (I'm doing this on a live USB with a persistent store, though, so it's not exactly a typical setup)
<ion> Yes
<ebroder> Broken configuration in the initrd?
<ion> Broken driver
<ebroder> Got it
<ebroder> Does one of the other nvidia drivers work better?
<ion> That is, they have yet to bother to support KMS. None of the proprietary nvidia or fglrx drivers do.
<ebroder> Ah, got it
<jdong> A neat side effect also seems to be prolonged blinking black cursor while ureadahead does its thing, and then a blink of a logo then gdm :)
<ion> Thatâs intentional. Not that i like it. I proposed printing a simple line of text such as âLoading Ubuntuâ or just âUbuntuâ while waiting for ureadahead, but the powers that be said no. :-)
#ubuntu-devel 2010-08-18
<ebroder> Yeah, I saw that, too
<ion> Loading all the stuff needed for a graphical plymouth before ureadahead does its thing would defeat the purpose of ureadahead, but printing a line of text wouldnât.
<jdong> "Loading loading screen...."
<jdong> :)
<jdong> is that like Windows 7's "calculating time remaining"?
<ebroder> If I'm basically trying to create a livecd rootfs with the nvidia drivers baked in, what do I need to do? Install nvidia-current, drop in an xorg.conf, anything else?
<ion> Plymouthâs purpose is not a loading screen. Itâs multiplexing interaction between the user and startup programs.
<cjwatson> well, plymouth yes, plymouth-splash not necessarily
<cjwatson> I suspect we are in agreement from different directions, though
<jdong> ion: sure, but given that it also functions as a loading screen, it looks a little bit confusing
<jdong> ion: especially on machines with poor IO performance
<ion> Yes, a dozen seconds of black screen isnât optimal.
<lilmonsta> hello all , apolagies for asking but is the 10.04.1 release still due today?   would it be the daily iso listed as 16.1?
<ion> We should do what Windowsâ¢ does: drop the readahead stuff, generate (and keep updating) a model of disk usage patterns and use idle time to reorder disk blocks for optimal startup times. :-P
<jdong> ion: theirs also includes a readaheader
<ion> ok
<jdong> it does some interesting throttling stuff though to minimize the devastation if the readahead info is really wrong (tm)
<jdong> like for us, if you put 5000 random files in the readahead pack, your boot performance will really tank :)
<jdong> (on HDD)
<penguin42> (I was thinking Maverick is currently feeling slower at boot than lucid - but I haven't timed it)
<jdong> my two Maverick machines at work here are reiser4 and btrfs
<jdong> one doesn't support readahead, the other is slower than NFS to asia.
<ebroder> Oww. You must not like your data
<jdong> thanks to 2.6.35
<jdong> haha experimental setup :)
 * ajmitch thought all your setups were experimental
<jdong> it is kind of a shame that it takes 7 hours 30 minutes to install from the alternate CD on btrfs in Maverick
<jdong> wonder if we want to roll back that commit for ubuntu-maverick.git
<RAOF> It's more of a shame that installing 80 updates takes 2 hours on btrfs.
<jdong> (or cross our fingers and hope Oracle has a patch)
<jdong> RAOF: I got pissed enough to locally revert that
<ajmitch> RAOF: that sounds worse than my laptop :)
<jdong> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=5da9d01b66458b180a6bee0e637a1d0a3effc622
<jdong> that thing
<RAOF> jdong: I got pissed enough to take an image (as it seems by btrfs partition is interestingly broken) and reformat to ext4
<jdong> HAHAHA
<jdong> ok that works too!
<ion> Meh. Iâm counting days until Oracle drops the btrfs project and instantly starts suing everyone using/developing/distributing it for infringing on their Imaginary Property. :-P
<jdong> ion: well brtfs probably does violate the crap out of the ZFS patent portfolio
<RAOF> chrisccoulson: Isn't it a bit late for you to be joining #ubuntu-devel? :)
<chrisccoulson> RAOF, oh, i must have got disconnected for a bit ;)
<RAOF> Aaah, ext4.  < 10 minutes to download and install 300 packages.
<slangasek> wait, are you extolling ext4 because of how fast dpkg runs on it?
<jdong> haha.
<RAOF> slangasek: In comparison to how dpkg runs on *btrfs*, that's practically negative time :)
<slangasek> interesting
<RAOF> (at least in maverick)
<lifeless> RAOF: good or bad on btrsfs?
<RAOF> lifeless: Terrible on btrfs.
<lifeless> let me guess
<lifeless> fsync?
<RAOF> On the order of 2 hours to install 80 already downloaded updates
<RAOF> I'm not sure that it is fsync, actually, although my libeatmydata testing wasn't particularly rigourous.
<lifeless> ok
<lifeless> any ideas?
<lifeless> and does eatmydata take care of the fsync variants ?
<RAOF> jdong's already posted a link to the patch (series?) which causes a ~10x regression in write-heavy loads that's in Maverick
<lifeless> (sync, fsyncdir)
<RAOF> I think libeatmydata does, yes.
<RAOF> There's an LP bug about this, too.
<jdong> lifeless: and no, eatmydata doesn't take care of the btrfs thing. It has to do with delayed allocation not truly delaying allocation, forcing way more tree operations than needed
<lifeless> jdong: thanks
<jdong> Chris Mason had triaged the bug though and says he's working on a patch
<RAOF> bug #601299 , if you're interested.
<jdong> (two weeks ago)
<ubottu> Launchpad bug 601299 in linux (Ubuntu) "maverick btrfs slow install" [Undecided,Confirmed] https://launchpad.net/bugs/601299
<jdong> wow, 12 hours to set up on a SSD
<jdong> impressive!
<jdong> oh nvm it's an Asus SDHC-on-a-card "SSD"
<chrisccoulson> eatmydata is such a cool name. it almost makes me feel compelled to use it all the time
<jdong> oh just patch eglibc if you're gonna do that ;-)
<djzn> folks, 10.04.1 --- any hopes for tonight still ? or probably another 7 days...?
<skat_> djzn, looking likely.   #ubuntu-release is fairly active ;)
<djzn> so we don't get 10.04.1 tonight.....
<ScottK> djzn: I wouldn't assume that.
<ScottK> I guess it depends on when tonight ends for you.
<djzn> ScottK: it ends in 1:30 hour.... -3.00 GMT
<djzn> lol
<ScottK> You might yet then.
<djzn> ScottK: how can you be so sure... this has been postponed for a few days... yet, no sign of isos....
<ScottK> I'm somewhat involved in the effort.
<djzn> ScottK: I could notice that...
<djzn> ScottK: I feel a hint.... that everything is already done... ISOs are ready... the thing is... there are several types of ISOs and each of them had to be produced.. the netbook one, the alternate one, even the DVD had to be made....
<djzn> ScottK: But I am not sure... still a Fix Commited bug laying....
 * ScottK was going to tell him it's out.
<ajmitch> oh well, just a little late :)
 * ajmitch wonders when the NZ mirrors will have it
<ScottK> At least natty will be less typing than maverick.
<ajmitch> but getting people to spell narwhal properly will be fun
<ajmitch> At least it's not drapper :)
<ajmitch> great, looks like one of the nz mirrors just has a recursive symlink
 * huntz0r is away: I'm busy
<ion> Thanks for the information!
<huntz0r> bloody xchat...
<pitti> Good morning
<pitti> kirkland: pong
<pitti> smoser: yup, will do ASAP
<dholbach> good morning
 * mneptok looks left
 * mneptok looks right
 * mneptok junps up and down on dholbach 
<mneptok> MOIN!
<dholbach> hi mneptok
<mneptok> *tacklehug*
<ajmitch> that's a nice enthusiastic greeting
<TheMuso> Brutally so.
<TheMuso> :)
<dholbach> :-)
<Sarvatt> were the non-LTS ports archives before jaunty moved to another server or were they wiped out completely?
<tjaalton> Sarvatt: try http://old-releases.ubuntu.com
<Sarvatt> phew, thanks tjaalton!
<tjaalton> this is weird, mounting Maple14 cdrom doesn't work otherwise but manually
<tjaalton> both on lucid & maverick
<soren> tjaalton: The maple cdroms are rather special, irrc.
<soren> iirc, even.
<soren> tjaalton: I believe it will look different depending on whether you mount it from linux, windows or mac.
<soren> tjaalton: ...and it'll look different depending on whether you mount the iso like you normally would or if you look at it through one of the userspace tools to inspect iso's.
<soren> tjaalton: In short, I'm not surprised some things act up. They shouldn't, but I'm not surprised :)
<tjaalton> soren: ah, could be like that yes
<tjaalton> well, whatever tries to automount them should be fixed to support those I suppose :)
<tjaalton> soren: worked on jaunty though, so sounds like a regression to me ;)
<tjaalton> (just tested it)
<soren> tjaalton: I remember having problems in... err...
 * soren rewinds his brain a couple of years
<soren> err.. edgy, it must have been.
<tjaalton> soren: ok.. now it seems to be udev handling the mounts?
<soren> tjaalton: No idea.
<cjwatson> udev won't be mounting things itself.  perhaps udisks.
<tjaalton> right
<sivang> hi all
<sivang> What are the tools commonly used to allow participants not in physical presence to be part of a developer's summit? http://gobby.0x539.de/trac/ comes to mind, but what other tools have past summits used?
<bilalakhtar> bdrung: there?
<bdrung> bilalakhtar: yes
<bilalakhtar> bdrung: a main patch, ready?
<bilalakhtar> bdrung: patch has been accepted in MeeGo
<bilalakhtar> package: gnome-disj-utility
<bilalakhtar> K
<bdrung> bilalakhtar: i will put it on my list. i will have time for it in the evening
<bdrung> bilalakhtar: can you give me the lp?
<bilalakhtar> bdrung: Thanks a lot! https://code.edge.launchpad.net/~bilalakhtar/ubuntu/maverick/gnome-disk-utility/fix-414107/+merge/32966
<bilalakhtar> bug #414107 bdrung
<ubottu> Launchpad bug 414107 in gnome-disk-utility (Ubuntu) "Palimpsest GUI impossible to use on small screen" [Medium,In progress] https://launchpad.net/bugs/414107
<bilalakhtar> its a branch merge, hence bug is in-progress
<bdrung> bilalakhtar: if your branch is ready, unassign yourself
<bilalakhtar> bdrung: and, status of bug?
<bdrung> bilalakhtar: sponsor don't care about the status
<bdrung> bilalakhtar: i saw statuses of (new, confirmed, triaged, in progress, fix committed)
<bilalakhtar> huh?
<bilalakhtar> bdrung: what does that mean?
<bilalakhtar> bdrung: I don;t need to subscribe sponsors to the bug, right?
<bdrung> bilalakhtar: the merge request will appear on the sponsors list. so no need to subsrcribe the team.
<bilalakhtar> bdrung: what do you mean by 'I saw statuses of .....'
<bilalakhtar> ah well leave it. I know bdrung is busy. Bye!
<bdrung> bilalakhtar: the bugs that i sponsored had a status of one of the mentioned above. we have no rule which status the bug should have.
<bilalakhtar> aha bdrung thanks
<bdrung> bilalakhtar: it could be everything except a 'fixed' status or Incomplete
<bilalakhtar> thanks bdrung
<bilalakhtar> bdrung: I just ran update-maintainer over it, so if you have already downloaded the branch, please pul
<bilalakhtar> *pull
<bdrung> bilalakhtar: i haven't pulled it yet. sponsor-patch will run update-maintainer (and therefore catch those mistakes) ;)
<bilalakhtar> thanks bdrung :)
<ricotz> seb128, hello
<seb128> hi ricotz
<ricotz> seb128, looks like i have a working gtk+3 package :)
<seb128> ricotz, can you talk about it on #debian-gnome?
<ricotz> ok
<seb128> ricotz, ideally we would get it in debian, they started work there
<theclaw> hi
<theclaw> how do I have to mark config files so that when installing the package, I will get asked whether I want to overwrite the config?
<theclaw> I already tried putting the configs in 'conffiles'
<cjwatson> just install them somewhere under /etc, and use debhelper compat level 3 or above (usually 7 these days)
<cjwatson> with even remotely modern debhelper you don't need to fiddle with conffiles by hand
<cjwatson> it will only prompt you if there are some local changes versus the distributed copy
<theclaw> yes, I have local changes. Maybe I'm using an outdated debhelper
<cjwatson> astonishingly unlikely
<cjwatson> well, you might be using an outdated debhelper compat level
<theclaw> cjwatson: I have '5' in debian/compat, so this shouldn't be the problem?
<cjwatson> but debhelper 3 dates back to 2001
<cjwatson> then there is something else wrong and we would need detailed information (e.g. an example) to debug it
<seb128> hum, "vesamenu.c32: not a COM32R image"
<seb128> I wonder what went wrong with that lucid usb stick I just did
<cjwatson> the installed version of syslinux tends to need to match
<theclaw> cjwatson: I can't distribute anything of the package, sorry
<seb128> cjwatson, you mean I can't do a lucid usb key with maverick usb creator?
<theclaw> cjwatson: but thanks for the hints
<seb128> or on maverick rather
<cjwatson> seb128: only if you downgrade to lucid's syslinux
<cjwatson> (at the moment)
<seb128> cjwatson, ok thanks
<cjwatson> theclaw: can't help if you can't share
<seb128> I did the keys 3 times and rsync the iso again to be sure
<seb128> it's a non obvious issue ;-)
<cjwatson> there's an open bug for it
<cjwatson> ev and I have talked about it, but it's mostly been conference/holiday season since then
<seb128> ok, thanks
<seb128> at least I know what's going on now ;-)
<cjwatson> I'm not sure what the right answer is given that syslinux isn't actually on the CD, only isolinux
<bilalakhtar> bdrung: I actually need to get it SRUed into Lucid at the same time. How to do this with a branch? since lp:ubuntu/lucid-proposed/gnome-disk-utility does not exist.
<tumbleweed> bilalakhtar: propose merging into lucid instead of lucid-proposed?
<bilalakhtar> tumbleweed: is that acceptable?
<bilalakhtar> tumbleweed: ok, I will follow the good-old debdiff method
<tumbleweed> other people seem to do that, the problem is that the merge request will never be marked Merged automatically...
<tumbleweed> (and the reviewer can't mark it merged / WIP)
<bilalakhtar> tumbleweed: well, since it is my first SRU, I don;t want to experiment with it
<bilalakhtar> so I am debdiffing
<tumbleweed> bilalakhtar: :)
<bilalakhtar> tumbleweed: if you are free, bug #619738
<ubottu> Launchpad bug 619738 in amara (Ubuntu) "Sync amara 1.2a2-1.1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/619738
<bilalakhtar> tumbleweed: you were the one who got the ubuntu patches there
<tumbleweed> bilalakhtar: hah, sure
<geser> bilalakhtar: what's the benefit of syncing it now?
<bilalakhtar> geser: why?
<tumbleweed> bilalakhtar: that wasn't an ubuntu patch
<bilalakhtar> geser: so that in N release they get synced automatically
<bilalakhtar> tumbleweed: I know, but the reason is the same
<bilalakhtar> geser: people say: Drop the ubuntu changes whenever possible
<bilalakhtar> tumbleweed: the current ubuntu changes and the debian accepted changes are somewhat different, but they have the same goal: move away from python2.5
<geser> bilalakhtar: yes, but we are currently past FF and should start focusing towards release. That also excludes syncs which no benefit right now.
<bilalakhtar> geser: ok, I will take care about it next time onwards.
<geser> being able to autosync for N isn't IMHO a valid reason for syncing (at least if it's the only reason)
<bilalakhtar> geser: ah, ok, please allow this one, I will take care from the next time onwards
<geser> bilalakhtar: sure (it's up to your sponsors to ACK it or not) but please consider if syncing a package gains us anything for the release for next syncs/merges
<geser> we shouldn't sync/merge because we can
<bilalakhtar> ok, I will take care from the next time onwards, geser
<cjwatson> geser++
<sabdfl> seb128: did you get a chance to look into gnome-terminal tabs?
<seb128> sabdfl, not yet, still busy with feature freeze exception from dx and other teams
<sabdfl> okdokey
<sabdfl> i saw the version bump this morning and got all hopeful ;-)
<seb128> sabdfl, no, that was just standard GNOME 2.31 update ;-)
<pitti> slangasek, robbiew: \o/ 10.04.1
<ricotz> jcastro, hello
<pitti> robbiew: hm, https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/ChangeSummary/10.04.1 looks a bit thin?
<pitti> is there a non-boilerplate version of this?
<cjwatson> pitti: we were stuck on a silly UTF-8 decoding error in the script that generates it - I gave a fixed version to robbiew a couple of hours ago, so he should be able to fill that out once he's up
<cjwatson> the error was ultimately down to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593442, if you care ...
<ubottu> Debian bug 593442 in dpkg "dpkg-genchanges can produce broken UTF-8 in Description" [Normal,Open]
<pitti> cjwatson: oh nice, it's autogenerated now?
<cjwatson> pitti: more or less always was partially; it requires manual editing to do categorisation and get it into a consistent editorial voice
<\sh> cjwatson: I just stumbled upon a bug discussion for openssh + the ldap patch...do you still support your argument, or would it be a good idea to re-check the quality of the openssh LPK  patch (bts: #319244)
<cjwatson> I still support my argument - get it upstream first, I'm not going to carry it in a distro
<cjwatson> sorry
<cjwatson> I haven't made any argument either way about the quality of the patch, so that is a red herring
<\sh> cjwatson: I just trying to find now any reference from upstream about this issue...but looks like I'm too tired to read all google hits
<\sh> ah there
<pitti> hm, we recently started to pull in openjdk into the images, leading to massive oversizedness
<ahasenack> pitti: hi, is 10.04.1 out yet?
<pitti> ahasenack: yes
<ahasenack> pitti: cool, so -proposed is unfrozen?
<pitti> ahasenack: right; I'll get to SRUs ASAP
<ahasenack> pitti: thanks
<\sh> cjwatson: when you are interested in this topic: http://marc.info/?l=openssh-unix-dev&m=127607159208207&w=2 -> the whole thread :)
<jcastro> ricotz: hi
<ricotz> jcastro, hi, how is the progress with the gome3 (gnome-shell) ppa?
<jcastro> ricotz: I am not sure, I've been gone for a bit, seb128 might know
<ricotz> jcastro, there are still plans to provide a ppa with a gnome3 preview?
<ricotz> jcastro, ah, ok, then i am up2date
<seb128> ricotz, not really
<seb128> ricotz, we need to get gtk3 in with all those libraries changes first but everybody is busy
<ricotz> seb128, ok
<seb128> with GNOME3 delayed from one cycle and gtk3 delayed until end of year we almost have extra time
<ricotz> seb128, ok, but the goal is still to get gtk3 into maverick?
<seb128> would be nice to get it in universe yes
<ricotz> my package still has some file collisions with gtk2, i am not sure about the right way to solve them
<ricotz> but gnome-shell can be built again with it
<cjwatson> \sh: thanks.  they seem to be going about things the right way, at last; there is probably some hope
<robbiew> pitti: fyi, starting on the change summary now...assuming python holds up :)
<pitti_> ahasenack: I followed up to bug 610744, there's still some bug cleanup to do
<ubottu> Launchpad bug 610744 in landscape-client (Ubuntu Karmic) "Update jaunty, karmic, lucid and maverick to landscape-client 1.5.4" [Undecided,New] https://launchpad.net/bugs/610744
<seb128> ricotz, I would appreciate if you didn't have your own gtk3 version in a ppa
<seb128> ricotz, it has potential to create trouble for users who want to try it and don't know it might conflict with the official builds when we will have those
<ricotz> seb128, yes, that is why i want someone of you to review it
<ricotz> i still have it in my staging ppa which shouldnt be used
<free> pitti_: hey, didn't we agree on opening SRU tasks only for the main SRU bug (which references the other ones)? for sake of convenience
<pitti> free: we did? I can't remember
<free> pitti: also I think that internally we were marking bugs as "Fix released" only when the packages actually hit -updates
<pitti> free: but anyway, if the 1.5.4 changelog claims to fix a bug which is still open upstream and targetted at 1.5.5, there's something wrong?
<pitti> free: that's what the Ubuntu task should be for then
<pitti> free: but ok, I can accept the "fix committed" upstream state, even if it's slightly weird
<free> pitti: right, I'm fine whatever, I just didn't open tasks because of the above
<pitti> ok, I can't remember the discussion where we agreed to not add SRU tasks
<free> pitti: about the wrong milestone, sorry about that, the bug should have been marked "Fix committed" quite a bit ago, but we forgot, so it was automatically shifted to 1.5.5 by a script we use at the end of the milestone
<free> pitti: so do you prefer to have tasks for all bugs or only for the main one?
<ScottK> Is http://people.canonical.com/~ubuntu-archive/NBS/ updating correctly?  I uploaded most of the rebuild targets for http://people.canonical.com/~ubuntu-archive/NBS/libkrb5-25-heimdal last night and even the ones that built ~12 hours ago still show there.
<pitti> ScottK: hm, usually it does
<pitti> cronjob is working, anyway, but only every 8 hours
 * ScottK checks another one.
<ScottK> pitti: Probably just got caught in the window where we don't get a publisher run for a few hours + the 8 hour cron job cycle.
<ScottK> I'll check it again tonight then.
<ScottK> Thanks for looking.
<pitti> np; I have used it a few days ago, and it was working fine
<pitti> but please let me know if the next update (at 1900 UTC) is still bad
<ScottK> Will do.
<cjwatson> slangasek: could you review https://code.launchpad.net/~csurbhi/ubuntu/maverick/samba/samba-fix.276472/+merge/32753 ?
<slangasek> cjwatson: my review is not worth much there; it looks syntactically correct, but should be reviewed by somebody who understands the protocol better
<slangasek> (i.e., upstream)
<slangasek> cjwatson: (do you want me to follow up with an actual merge review saying this?)
<cjwatson> slangasek: sure, just looking for somebody to claim it really
<cnd> Hi all, are MIR reports processed on a set schedule?
<cnd> seb128, pitti ^^?
<pitti> cnd: not sure, asac is driving it these days
<pitti> but I expect not
<cnd> asac, in case you missed my question due to your ping timeout :), are MIR reports processed on a set schedule?
<bilalakhtar> Can anyone accept the nominations at bug #414107 ?
<ubottu> Launchpad bug 414107 in gnome-disk-utility (Ubuntu) "Palimpsest GUI impossible to use on small screen" [Medium,In progress] https://launchpad.net/bugs/414107
<achiang> slangasek: this bug has a patch and looks like Keybuk even reviewed it; any chance of taking a look? https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/537133
<ubottu> Launchpad bug 537133 in mountall (Ubuntu Lucid) "mountall issues with NFS root filesystem" [Medium,Confirmed]
<bilalakhtar> bdrung: about the bug I told you, there is an SRU also needed for it, so when you look at the maverick branch, could you please look at the debdiff attached to the bug report also (sponsors subscribed there)? That debdiff is for getting the package into lucid-proposed
<jibel> cjwatson, hello, bug 619135, do you think that's really a packaging issue or dpkg becoming suddenly overly verbose due to the changes in 1.15.8.4 ?
<ubottu> Launchpad bug 619135 in banshee (Ubuntu) "Warnings in '/var/lib/dpkg/updates/***' while installing banshee" [Undecided,New] https://launchpad.net/bugs/619135
<jibel> cjwatson, the relevant changelog entry "* Always print a massage on warning when parsing control files."
<akheron> I did do-release-upgrade on a karmic server today, everything was fine until libc-i686 was upgraded
<akheron> right after that everything started to fail, failing about missing version GLIBC_2.11
<akheron> *complaining
<akheron> what could be wrong?
<penguin42> akheron: Can you get an ldd /bin/ls out of it?
<akheron> I can reproduce this easily, as I have a backup disk image of the server
<akheron> penguin42: after the upgrade has failed?
<penguin42> akheron: Yeh depending just how failed it is
<akheron> I don't think so, as at least ls just segfaults
<sebner> JontheEchidna: hola :) , if you are bored you could update k3b and make another backport maybe? :)
<akheron> I cannot access the machine right now, and before trying again I would have to restore the backups
<djzn> ScottK: Just dropped by to say THANK YOU for the point release
<ScottK> djzn: It was very little to do with me, but you're welcome.  You left just slightly too soon last night.
<djzn> yeah, i had to sleep, but doesn't matter now, it's there...
<JontheEchidna> sebner: ooh, turns out I can merge from debian. :)
<highvoltage> JontheEchidna: nice :)
<SpamapS> pitti: Don't know if you noticed, but I proposed merging a change to the WI tracker that will allow you to stop regenerating all the html/burndown/json for closed out milestones.
<SpamapS> pitti: and currently looking at speeding up the select statements a lot
<mycae> Hello. I think I was asked in a bug to request an FFE for a  package sync (minor package that was new to debian), but I cannot seem to find any documentation on how one does this. In fact, i thought this was what I was doing. Does anyone know what I am supposed to do? (bug #617787)
<ubottu> Launchpad bug 617787 in Ubuntu "Sync request: 3depict" [Wishlist,Confirmed] https://launchpad.net/bugs/617787
<micahg> mycae: looks like you're fine on this
<micahg> archive admins are subscribed and FFe was approved
<mycae> ok. good. was not clear if I had to "get" an FFE from someone/where
<mycae> thankyou.
<maco> i just got an email from lp saying a package i uploaded failed to build on itanic but the FAILEDTOBUILD.txt.gz says "Built  successfully" partway down...
<maco> like, right at that end bit before the chroot cleans up and uninstalls all the stuff it installed as build deps
<maco> i am confused by this definition of fail
<SpamapS> maco: it detected that ia64 was a failure and noted it for you.
<SpamapS> they've added fuzzy logic now.. if processor_architecture.value == 0: send fail email
<SpamapS> ia: can you paste a link to the build?
<maco> http://launchpadlibrarian.net/53949323/buildlog_ubuntu-lucid-ia64.skyeye_1.2.5-2ubuntu1.10.04.1_FAILEDTOBUILD.txt.gz
<geser> maco: the failure is "Function `get_sym' implicitly converted to pointer at utils/main/skyeye.c:200
<geser> "
<geser> the source file is missing the prototype for the function
<maco> why is that so far after the "build successful" message?
<geser> the buildd scans the output for this and fails if it's found
<maco> and that's a bit odd
<geser> amd64 should fail the same way
<maco> since its a no-change rebuild
<maco> and the package it didnt change from /did/ build on ia64
<geser> but a lib might have changed between the time it got build last and now
<maco> well i dont know about ia64, but amd64 does not fail in pbuilder
<maco> ...and actually on lp it did complete on amd64
<maco> hmm ...
 * maco goes back to calling it itanic
<geser> yeah, hmm
<geser> perhaps a header which doesn't get included on ia64 for some reason
<maco> im glad amd64 won the 64bit market
<ScottK> maco: You can ignore ia64 anyway, it's about to be killed.
<ajmitch> the TB have spoken
<ScottK> Yep.
 * ScottK isn't sure why ia64 went along with sparc since it was still functional, but oh well.
<maco> which was still functional?
<ajmitch> I think it wa sfunctional but noone was caring for it
<ScottK> ia64
<ajmitch> but it at least booted afaik
 * ScottK saw ia64 specific bugs reported by users as recently as Karmic.
<ScottK> So I think it even has a non-zero number of users.
<maco> im surprised by that
<ScottK> But it's decided now anyway.
<maco> do they even sell itanium hardware anymore?
<maco> i saw it for like 6 months then people realised they couldnt use 32bit windows on it, then it went away
<achiang> hp sells quite a bit of ia64
<maco> is that servers?
<achiang> it only makes $10B / year for them
<ScottK> Yes
<maco> ah
<achiang> actually, that number seems wrong, please ignore it
 * ScottK has a server running Hardy that has a motherboard/CPU that dates from 1999.
<mdke> slangasek: around?
<ajmitch> perhaps the port can be revived if someone steps up to look after it
 * ScottK has another running Lucid from 2000.
<ScottK> Perhaps, but restarting a port is hard.  Ask lamont about restarting hppa.
 * maco would use debian if the year starts with a 1
<penguin42> there are probably quite a few Ia64 workstations/small servers that geeks have managed to hang on to when the places they work were about to throw them out
<ScottK> Since it's in Lucid, they'll be able to do it for another 3 - 5 years.
<penguin42> or actually after they through them out :-)
<ScottK> The last Sparc installer that worked was Gutsy.  The last working system was, I think, Jaunty.  So it's in a very different situation.
<ajmitch> maco: what's wrong with using debian? :)
<ajmitch> penguin42: especially if they have shares in power companies
<maco> ajmitch: it's more about what's wrong with using ubuntu
<penguin42> ajmitch: They make great heaters
<ajmitch> maco: if you have an ia64, the answer would be obvious :)
<maco> ajmitch: i was referring to ScottK's old machines
<maco> i tried feisty on a c1998 machine. that was...on the edge of bearable
<ajmitch> I had breezy on an old laptop with 128MB of RAM
<maco> i doubt it could boot lucid..if i could find it
<ajmitch> it was interesting
<maco> etch + e17 was the fanciest thing i could run on it and still have enough ram available to run 1 app at a time
<ScottK> Up through Hardy I have a laptop with 256MB of RAM I ran Kubuntu on (and even built packages)
<ScottK> have/had
 * ajmitch would just like little things like suspend/resume to work on hardware from last year, let alone having an ancient laptop boot
<maco> (er, ram+swap)
<maco> ajmitch: ancient things are more likely to work i think
<maco> nice old stable drivers
<ajmitch> rather than using things like fglrx
<maco> if it predates this wifi and bluetooth dohickeys, itll probably be happy :P
<maco> ScottK: did you have to install your own ethernet cards on those machines, or did they come with them?
<ScottK> One came with the other is home built, so I had to add it.
<ScottK> The laptop needed a PCMCIA ethernet card.
<ScottK> Err wifi card.
<ScottK> Ethernet was built in.
<maco> i think the WinME machine was the first we had that could do ethernet
<cjwatson> jibel: I think it might be dpkg breakage - I noticed it myself on different packages, but at the time put it down to the fact that I only restored this system from backup recently
<jdong> hmmmmm
<jdong> any way to debug when APT tells me "Hash Sum Mismatch" but I don't believe it?
<jdong> the Release file's md5sum and sha1sum listed for a Packages.bz2 matches what I get when I manually fetch the URL
<penguin42> jdong: I've seen that type of thing happen with dodgy ram or other faults
#ubuntu-devel 2010-08-19
<jdong> hmm the box is a Mac Pro with FB-DIMMs and reproduces on 3 different machines
<penguin42> ok ok, so it doesn't have to be a hardware bug!
<jdong> aptitude doesn't say anything
<jdong> but I still don't see the packages
<jpds> jdong: You have a HTTP cache between you and your mirror?
<jdong> actually....
<jdong> clearing /var/lib/apt/lists fixed it
<jdong> weird.
<jdong> oh.
<jdong> OH.
<jdong> stupid if-modified-since handling?
<jdong> the livecd was built using us.archive.u.c as a mirror, and then the final installed system chose mirrors.kernel.org
<jdong> I guess technically an older file hasn't been-modified-since the newer file
<jdong> *headdesk*
<mrmonday> Is this the right pace to ask about issues when trying to package apps for ubuntu, or is there a channel better suited to that?
<penguin42> mrmonday: There is also a #ubuntu-packaging (I think it's ing) and #ubuntu-motu where the stuff in the universe set of repos get done (I only hang out here occasionally)
<mrmonday> Thanks, I'm in there now :)
<bdrung> Riddelll: ping
<TheMuso> ScottK: Thanks, that was a quick decision. :)
<ScottK> TheMuso: I figure that's high on your list of packages not to leave broken.  Not much of a risk.
<TheMuso> ScottK: Yeah this is true, thanks again.
<TheMuso> c
<ipatrol> hello
<ipatrol> I was thinking about configuration GUIs
<hv> What happened to the gnome-terminal? Alt+Backspace does not delete a word anymore. (Alt is not being sent)
<ipatrol> open xev and see what happens when you press that keystroke
<hv> it's not from xev. xterm works fine. it is as if the gnome-terminal equivalent of "XTerm*metaSendsEscape: true" is no longer the case
<hv> do Alt+b, Alt+f, Alt+backspace, etc work for you in gnome-terminal?
<ipatrol> I'm not on a desktop computer
<hv> ipatrol: I see.
<ipatrol> If you gave me ssh or vnc access I could try :D
<hv> there was an upgrade (2.30.2 -> 2.31.90) on Aug 17.
<ion> Does esc-backspace work?
<hv> yes
 * micahg thinks there's a bug open already for that
<hv> umm, how can I search for bugs for package $PACKAGE in launchpad? PACKAGE name is what aptitude tells me.
<hv> there is "search in one project", but apparently project-name is not exactly the same as package-name
<StevenK> hv: First, you need the source package name, which you can find from aptitude (under Source: ), and then https://bugs.launchpad.net/ubuntu/+source/<source package name>
<hv> StevenK: "aptitude show" apparently does not have a section "Source". How can I get that automatically?
<StevenK> hv: If one isn't present, it's the same as what you searched for
<StevenK> hv: Actually, no, I'm wrong. aptitude show doesn't display it, but apt-cache show does
<ipatrol> yeah, apt-cache
<hv> StevenK: thanks.
<hv> function view-package-info () { if PKGSOURCELINE="$(apt-cache show "$1" | grep '^Source:')"; then PKGSOURCE=${PKGSOURCELINE/Source: /} ; else PKGSOURCE="$1" ; fi ; xdg-open "https://bugs.launchpad.net/ubuntu/+source/$PKGSOURCE"; }
<hv> :D
<geser> hv: see bug #619754 for the "Alt" key issue
<ubottu> Launchpad bug 619754 in vte (Ubuntu) "alt + backspace; alt+d etc. don't work anymore" [High,Fix released] https://launchpad.net/bugs/619754
<mdke> morning. Can someone tell me whether, if a source package builds more than one binary package, and a change is made so that a particular binary package is no longer built, does any additional act need to be taken to remove that binary package from the archive?
<geser> no, it will appear on in the NBS list and get removed by the archive admins if no reverse (build-)dependencies are left
<mdke> geser: excellent, thanks for the information
<mdke> is there an easy way to tell what dependencies exist?
<geser> apt-cache rdepends for dependencies but for build-dependencies you need use grep-dctrl on the Source file
<mdke> geser: thanks. I'm sure there aren't any build-dependencies in this case
<geser> or you simply check http://people.canonical.com/~ubuntu-archive/NBS/ once you dropped the package
<mdke> looks like no rdepends either :)
<mdke> geser: thanks again
<dholbach> good morning
<mdke> morning dholbach
<dholbach> hey mdke
<bilalakhtar> good morning dholbach
<dholbach> hey bilalakhtar
<pitti> Good morning
<pitti> erh, where did my control key go?
<pitti> seems it's acting like another windows key
<nigelb> heh
<nigelb> pitti: Nice way to start the morning.
<nigelb> Good morning :)
<mok0> What GNU autotools files do you guys include in your brz repo? Do you have all files at the "make dist" level, or do you not include the autogenerated files?
<mok0> Of course, you need "./configure" etc. for bzr-builddeb to work
<mok0> But that could be restricted to the package branch
<mok0> Do you consider the casual user, that might do a bzr branch lp:xxxx ; configure; make ?
<pitti> mok0: for upstream projects, definitively don't include autotools stuff; it's just noicse
<pitti> mok0: some packaging branches do that, when they import upstream tarballs instead of being a real branch from upstream trunk
<mok0> pitti, so, in your opinion, I should have the GNU autotools only in the "ubuntu" branch? (The one that includes debian/ )
<pitti> mok0: depends on the packaging style
<pitti> but upstream branches with autoconfiscation (or more generally, with anything that gets autogenerated) are pretty annoying
<geser> pitti: is it bug 619754 or a different issue?
<ubottu> Launchpad bug 619754 in vte (Ubuntu) "alt + backspace; alt+d etc. don't work anymore" [High,Fix released] https://launchpad.net/bugs/619754
<pitti> geser: ah, I did have a libvte upgrade yesterday afternoon indeed; trying
<mok0> pitti, unless you have configure and friends, bzr-builddeb doesn't work
<pitti> mok0: so your packgaging branch derives straight from trunk?
<mok0> pitti: yes
<mok0> pitti, it includes trunk, and adds debian/
<mok0> pitti, but I could also add m4/
<pitti> mok0: you could call autotools in debian/rules; if you use cdbs, you can just set the flags, otherwise call autoreconf before ./configure
<pitti> geser: hmm, no new vte in this morning's dist-upgrade
<mok0> pitti: yeah, that is a possibility...
<pitti> ah, vte failed to build on amd64
<mok0> pitti: thanks for your input
<pitti> robert_ancell: I'll give back vte on amd64 once glib has published (it just finished building on amd64
<robert_ancell> pitti, thanks
<mdke> I believe that the ubuntu-docs and gnome-user-docs packages both used to have a "XS-Vcs-Bzr" field, but they seem to have disappeared somehow. Are these still in use generally?
<pitti> mdke: it's now called Vcs-Bzr:
<pitti> ah, keyboard sanity! thanks geser
<mdke> pitti: thanks. That seems not to be there either, I'll readd it. No idea how it got lost
<kblin> hi folks
<kblin> I take it's too late to get driver support for a wifi dongle into 10.10?
<cjwatson> pitti: upstream autoconfiscation> disagree, just for the record.  (I'm not really trying to persuade you, but I want it to be on the record that not all upstreams act the same way.)
<pitti> cjwatson: hm, I've never seen one anyway
<cjwatson> anything I maintain for starters :)
<pitti> cjwatson: that makes upstream commits pretty noisy, though?
<cjwatson> Yes, exactly as noisy as I want them to be
<cjwatson> I want to be able to see what changes the autotools are making, and having the generated files in revision control is an excellent way to do that
<cjwatson> it's a good way to spot mistakes
<pitti> cjwatson: hmkay :) seems I just haven't stumbled over one of those upstream VCSes then
<cjwatson> man-db, ubiquity (OTTOMH)
<soren> cjwatson: That only really works for single-person projects, doesn't it?
<soren> cjwatson: Or do you just have a rule that only one person gets to change those things or do you mandate a very specifically versioned toolchain?
<cjwatson> soren: you do have to be reasonably close in autotools versions but that's often the case anyway.
<cjwatson> soren: this way, at least it's explicit what random set of stuff the principal maintainer was using.
<soren> cjwatson: True. I'm with pitti, though. I don't recall stumbling upon vcs with autogenerated stuff in it that wasn't a mistake.
<cjwatson> it's certainly popular to not include it, but I thought it worth mentioning that the practice is not universal
<soren> cjwatson: I acknowledge you do things differently, though, and I how it can be valuable.
<soren> right.
<soren> Good to know.
<chrismsnz> hey guys, do you know where i can find the people that run the xorg edgers ppa?
<cjwatson> in fact, if you do it very consistently, it avoids the need for a tarball branch sitting in between the upstream vcs and the packaging branch
<cjwatson> which can be convenient
<nigelb> chrismsnz: #ubuntu-x perhaps?
<chrismsnz> nigelb, ty
<jibel> pitti, hello, sru bug 595116, apache 2.2.14-5ubuntu8.1 failed to build in lucid, who should I warn ?
<ubottu> Launchpad bug 595116 in apache2 (Ubuntu Lucid) "ssl "error reading the headers"" [Undecided,Fix committed] https://launchpad.net/bugs/595116
<pitti> jibel: that already happened; the package was pulled from -proposed, and we asked zul to reupload
<jibel> pitti, okay thanks.
<doko> seb128: when is the next set of gnome updates expected, and when do you expect the archive be stable again after these are uploaded?
<doko> Riddell: when is the next set of kde updates expected, and when do you expect the archive be stable again after these are uploaded?
<seb128> doko, what is not stable and what do you try to figure?
<seb128> doko, is that for an archive rebuild? cd builds?
<doko> trying to figure out a good time to take a snapshot for a rebuilt test
<seb128> doko, next GNOME changes are august 30th
<ogra> doko, the archive is in its best condition right before a milestone
<seb128> doko, I don't expect GNOME to be unstable until then
<doko> seb128: ok, thanks
<bilalakhtar> okay, I need an FFe for a new upstream release, should I file 2 separate bugs (one for sponsorship, other for FFe) or merge 'em ?
<geser> merge them
<geser> it's easier to look at only one bug
<Riddell> doko: probably next big KDE update September 9th
<webczat> Hey.
<webczat> What usb-creator requires? i want to install it on gentoo and then create ubuntu liveusb pendrive
<webczat> version 0.2.22
<webczat> i'm extremely annoyed about that freeze!
<ricotz> seb128, hi
<webczat> :/
<seb128> ricotz, hey
<webczat> wrrrrrrr
<webczat> is that freeze something normal?
<webczat> hmm, 0.2.20 also does not work
 * webczat curses
<webczat> does anyone have a clue why usb-creator freezes?
<webczat> ?
<Pici> webczat: This isn't a support channel.  Please use #ubuntu for that.
<cnd_> seb128, I'm working on adding udebs to mtdev and utouch-grail
<cnd_> I've pushed packaging commits to enable udebs to lp
<cnd_> would you be able to review the changes?
<seb128> cnd_, sorry but I'm over busy atm, I've at least 5 changes in my queue and 3 person who pinged me
<seb128> cnd_, can you drop me an email with the references?
<seb128> cnd_, I might review that later otherwise it will be tomorrow
<cnd_> seb128, is there someone else you could recommend who could help?
<seb128> or maybe somebody else there can do reviews
<cnd_> I can also drop an email
<cnd_> I just don't want to overburden you :)
<seb128> well let's say that's the right channel
<seb128> but I suggest opening bugs with the change and subscribing sponsors
<cnd_> seb128, ok, I'll open bugs like you suggest
<cnd_> should I subscribe just yourself, or some team, or?
<dholbach> cnd: subscribe ubuntu-sponsors
<cnd_> dholbach, ok, thanks!
<cjwatson> cnd_: udebs> why?
<cnd_> cjwatson, mtdev and utouch-grail handle gesture recognition, and they siphon events from xserver-xorg-input-evdev in Maverick
<cnd_> (right now they siphon events off from a new *-gevdev package because we don't have udebs so we can't merge changes into the real *-evdev)
<cnd_> we want to just have a patch against evdev for Maverick, but if we do that right now, the evdev udeb will also depend on mtdev and utouch-grail
<cnd_> and the installer will burst into flames :)
<cnd_> cjwatson, I'm sure you're busy too, but would you have a moment to check my udeb changes?
<cnd_> np if you can't
<cjwatson> cnd_: what installer do you have in mind that uses evdev?
<cjwatson> cnd_: (noting that we don't actually use graphical d-i at the moment)
<cjwatson> cnd_: I don't object to adding the udebs, just surprised that it's a priority
<cjwatson> cnd_: happy to look at your changes
<robbiew> cjwatson: noticed bug 620293, bug 620302, and bug 620338 all created in the last 24hours....could there be a possible bug in initramfs-tools (Lucid)...or is this a common error message for multiple failures
<ubottu> Launchpad bug 620293 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 [modified: usr/sbin/update-initramfs] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/620293
<ubottu> Launchpad bug 620302 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/620302
<ubottu> Launchpad bug 620338 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 [modified: usr/sbin/update-initramfs] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/620338
<cjwatson> robbiew: I'll look, but it's a very common message
<cjwatson> and it's a "something broke" kind of thing
<robbiew> cjwatson: ack..then no worries
<robbiew> I thought it might be
<cjwatson> robbiew: two undebuggable problems with no useful information attached; one problem which is odd but isolated
<cjwatson> all different
<robbiew> cjwatson: cool...thnx
<robbiew> and sorry to take 5min of your life that you will never get back :P
<cnd_> cjwatson, sorry, didn't notice your messages
<cnd_> cjwatson, I was under the assumption that the graphical installer was running through X
<cnd_> if not, then this may all be a moot point :)
<cnd_> or perhaps you're meaning that the ubiquity installer image isn't built from udebs?
<cjwatson> cnd_: so, there are two graphical installers.  one (which we may use for something in the future, perhaps the server) uses udebs.  the other (which we use for the desktop today) does not.
<cjwatson> cnd_: don't let me stop you adding the udebs - we will probably want them eventually and we might as well add them while they're uppermost in our minds
<cjwatson> cnd_: it just won't affect ubiquity in any way
<cnd_> ok
<cnd_> at least it lowers the priority for now :)
<cnd_> cjwatson, you can review the changes at:
<cnd_> http://bazaar.launchpad.net/~chasedouglas/mtdev/packaging/revision/45
<cnd_> http://bazaar.launchpad.net/~chasedouglas/utouch-grail/packaging/revision/42
<cnd_> I suppose we should do the udebs anyways because we don't want to break anyone wishing to play with graphical d-i
<cjwatson> cnd_: you can drop debian/libmtdev1.shlibs
<cjwatson> right
<cnd_> cjwatson, what about the shlib deps checking though?
<cjwatson> and likewise you can drop debian/libutouch-grail.shlibs.  the rest is fine
<cnd_> the symbols file doesn't know anything about udebs
<cjwatson> cnd_: dh_makeshlibs will create that shlibs file all by itself
<cjwatson> keep the --add-udeb stuff
<cnd_> cjwatson, it didn't seem to do it for me...
<cjwatson> let me check
<cnd_> I'll check again
<cjwatson> certainly there is no need to hardcode the udeb: line in .shlibs
<cjwatson> the point of --add-udeb is to add that line
<cnd_> ok, I'll try without the line to see
<cjwatson> E: libmtdev1-udeb udeb: udeb-contains-documentation-file usr/share/doc/libmtdev1-udeb/
<cjwatson> E: libmtdev1-udeb udeb: udeb-contains-documentation-file usr/share/doc/libmtdev1-udeb/buildinfo.gz
<cjwatson> that's probably a dh_buildinfo bug
<cjwatson> works fine without the .shlibs file
<cjwatson> heh, how about I just purge dh-buildinfo here, since you don't build-depend on it :)
<cnd_> cjwatson, you're right
<cnd_> I think I was looking in the wrong place before
<cnd_> thanks for the review!
<cjwatson> yep, it's fine now that I've purged dh-buildinfo.  I'll go report that bug
<barry> james_w: ping
<james_w> hi barry
<barry> james_w: hi.  do you have a few minutes to walk through a udd scenario with me?
<james_w> of course
<barry> thanks!  okay, background: i'm trying to get subversion to build against py27.  it currently fails because of some test failures...
<barry> first i did: bzr init-repo svn; cd svn; bzr branch lp:ubuntu/subversion
<barry> then bzr branch subversion py27
<barry> cd into py27 and loomified that branch
<barry> bzr create-thread disable-tests
<barry> (note: the "fix" is currently to just disable a handful of failing tests)
<barry> hack, hack, hack, build, test, commit change, bzr record
<barry> push to lp
<barry> okay, so now i have a branch that builds, as a two-thread loom.  so far so good?
<james_w> yes
<barry> cool.  so, subversion uses quilt and now i want to turn that patch in a thread into a quilt patch.  i've tried a couple of things that haven't succeeded, but i guess let's start with what you'd recommend as the next step?
<james_w> something like "bzr diff -r thread: | quilt import disable_tests" would be my guess
<barry> james_w: should i do the import in the trunk thread?  in a pristine branch?  doesn't seem right to do it in the thread that contains the source change
<james_w> barry: is it quilt v3?
<james_w> or v1 + quilt?
<barry> james_w: 'what-patch' just says 'quilt'
<james_w> cat debian/source/format
<james_w> ENOENT means v1
<barry> 1.0
<james_w> barry: ok, so you could either do the import in a thread without your changes, or do the import in the same thread, and then back the changes out of the working tree
<james_w> I don't think it particularly matters, you will end up with the same tree state, so it just depends what you want in the history
<barry> james_w: i think i see what you mean.  thanks, let me try that...
<barry> james_w: this is interesting.  i tried creating a thread between trunk and disable-tests, called 'quilt'.  then i did a bzr diff -rthread:disable-tests -rthread:trunk and it returned an empty diff.  the same command returned the full diff only if i'm in the disabled-tests thread
<james_w> barry: I don't think two -r does what you would expect there
<james_w> try -r thread:trunk..thread:disable-tests
<barry> james_w: oh right.  so many diff command syntaxes ;)
<barry> james_w: that did the trick.  thanks, let's see if quilt will import the diff
<james_w> barry: you might need a --prefix=a/:b/ to get it at the natural -p level for quilt
<cjwatson> quilt has -p options itself
<barry> james_w: quilt import doesn't read from stdin, so i think i need to save it to a file first
<cjwatson> so you can use -p0
<cjwatson> also, quilt import -p0 /dev/stdin :-)
<james_w> barry: huh
<barry> cjwatson: yep, just saw that.  i think what tripped me up about trying to use edit-patch is that it *doesn't* take a -p argument, so edit-patch ends up rejecting the patch
<james_w> nice :-)
<barry> cjwatson, james_w: indeed... let's see!
<barry> ah, wait, i need to push all patches first before i import though, right?
<barry> cjwatson: that works, except that the patch file is called stdin.  probably not quite right :)
<cjwatson>            -P patch
<cjwatson>                Patch filename to use inside quilt. This option can only be used when importing a single patch.
<barry> cjwatson, james_w: very nice. i think i have a workflow now.  i'm going to write this up, and will send you a link.  thanks for your help!
 * barry might even try to automate this
<james_w> barry: I'd love a command in bzr-builddeb to turn revisions in to a patch
<barry> james_w: you and me both!  do you have a suggestion for a command name?
<james_w> like turning a bzr revisionspec for diff in to something for edit-patch
<james_w> import-deb-patch for a pretty poor first thought :-)
<barry> james_w: i probably have to hack edit-patch to take -p and -P
<barry> :)
<james_w> barry: it may be easier to get bzr to generate patches that don't need -p
<barry> james_w, cjwatson: oh, one other thing.  my thread included a debian/changelog entry.  i need to filter that out of my quilt patch
<barry> james_w: yeah, but -P is required i think if you don't use a tmp file
<james_w> ah, ok
<barry> this has been great, thanks guys
<SpamapS> Whats the feeling on a FFE for a package to sync changes from debian that only change the build process to run the automated testing suite? Otherwise the package is basically the same.
<cjwatson> SpamapS: what's the feature requiring an exception?
<cjwatson> syncing from Debian alone doesn't require an exception, it depends on whether it introduces new features
<Chipaca> is there something that would build up a changelog from bzr commit messages?
<Chipaca> not a changelog, I mean a changelog entry
<SpamapS> libdbi-drivers (in main), the Debian Maintainer and I did considerable work to run automated tests against mysql, pgsql, and sqlite.
<SpamapS> cjwatson: ^
<SpamapS> cjwatson: so the feature is running the tests.
<asac> jdstrand: are you awake?
<jdstrand> I am
<cjwatson> SpamapS: it's a feature in the build system I suppose, but I don't think it's a feature visible to users of the package (other than "less buggy")
<asac> jdstrand: what else besides the bug to track qt-qws code duplication did you want?
<cjwatson> SpamapS: so I don't think it needs an exception
<asac> seb128: ^^
<asac> here is the discussion now
<cjwatson> Chipaca: more usual to do it the other way round, write the changelog as you go and use that to generate commit messages (with debcommit)
<SpamapS> cjwatson: I'll just requestsync then. :) Thanks!
<jdstrand> asac: well, I'm not sure I am the gatekeeper of that bug. I just wanted to make sure that enough people were in agreement that that is the only thing we can do. someone from linaro saying they will maintain it for -security (since it is universe) and people more knowledgeable than I saying the technical issues can only be resolved with a copy copy
<Chipaca> cjwatson: right, i want to generate the package changelog based on the individual commits made on the project itself (also in bzr)
<jdstrand> s/copy copy/code copy/
<cjwatson> Chipaca: usually produces rubbish output, but as you like :)
<cjwatson> (don't know of anything; the kernel team does this with git)
<SpamapS> james_w: http://package-import.ubuntu.com/status/libdbi-drivers.html#2010-08-07 15:12:07.002397 ... did we mess up by importing 0.8.3-1 upstream without tagging the change ?
<james_w> SpamapS: possibly. Is that version number (0.8.3-1-0ubuntu1) intentional? Do upstream release 0.8.3-1?
<Riddell> asac: bug 618733
<ubottu> Launchpad bug 618733 in Ubuntu "package qt4-qws" [Undecided,New] https://launchpad.net/bugs/618733
<SpamapS> james_w: yes
<james_w> SpamapS: then it's probably a bug in bzr-builddeb
<SpamapS> james_w: though as of 0.9 they'll be moving to 0.9.0.0
<james_w> let me look
<SpamapS> james_w: let me know if I can help
<james_w> SpamapS: so yeah, it's caused by a bug in merge-upstream
<james_w> SpamapS: I can fix that branch, and then fix the bug as well
<SpamapS> james_w: well I'm glad to hear that we didn't screw it up.. but sorry to put more on your plate. ;)
<james_w> np, it's my fault for this stupid bug anyway
<james_w> SpamapS: if you run "bzr pull lp:ubuntu/libdbi-drivers" and try again it should now work
<james_w> SpamapS: let me know if that doesn't work
<james_w> I'll fix the bug so that it doesn't happen in future
<james_w> SpamapS: oh, if you are trying to merge a new upstream version of this package today then let me know and I'll help you workaround the bug.
<SpamapS> james_w: no, I just noticed that it had an error in package-import
<SpamapS> james_w: and it was uploaded to Debian today, so I wasn't sure if it was just out of sync w/ debian, or an error. Looks like both. ;)
<SpamapS> james_w: by it, I mean a new version of the same upstream.
<james_w> SpamapS: ok
<SpamapS> james_w: I'll keep an eye on it as the new release is imported into lp:debian, thanks for taking a look.
<james_w> np
<canesin> Hi all, I want to help maintain an package in ubuntu .. how can I do this ??
<johanbr> canesin, have a look at https://wiki.ubuntu.com/MOTU
<canesin> Thanks
<jcole> question about the livecd... i am providing remastered versions and would like to "force" encrypted home directories by default... what config would i modify to make that happen?
<seb128> kees, hey, could you review bug #609081?
<ubottu> Launchpad bug 609081 in libdmapsharing (Ubuntu) "[MIR] libdmapsharing" [Wishlist,New] https://launchpad.net/bugs/609081
<kees> seb128: sure, one sec
<seb128> kees, thanks
<soren> StevenK: Doing AA stuff today?
<lifeless> soren: @5am? :P
<soren> lifeless: Hmm.. point. :)
<pitti> isn't it funny how lifeless proves himself wrong? :-)
<dobey> is revu closed off now for maverick? or is it just confused at the moment?
<james_w> SpamapS: fixed, and will be uploaded soon. Next time you do a new upstream of a package like you shouldn't have a problem. Thanks for catching the issue.
#ubuntu-devel 2010-08-20
<TheMuso> 5~/c
<bdrung> bdmurray: have you played with sponsor-patch?
<bdrung> bdmurray: thanks for fixing one TODO. i have added two new TODOs. :)
<bdmurray> bdrung: I haven't played with it was looking at the patch / debdiff stuff like we'd talked about
<hamish> can anyone recommend an IDE for PostgreSQL on Ubuntu?
<hamish> can anyone recommend an IDE for PostgreSQL on Ubuntu?
<glick> hey excuse me is there any reason why lucid is using such an old version of mod_wsgi 2.8 when 3.3 is long out?
<micahg> glick: it might not have been packaged in time, maverick has 3.2-2
<glick> micahg, the maverick repos?
<micahg> glick: yes
<micahg> bzr diff
<micahg> oops
<nigelb> heh
<glick> is there a tutorial on how to add the maverick repos i did a goog search and cant see anything
<nigelb> you probably can't just add and use
<glick> oh
<glick> is it difficult to make a deb from the source?
<nigelb> not really.
<nigelb> Get the source and rebuild, I'm trying to figure out how to build it without pbuilder.
<nigelb> But it may fail horribly depending on the versions of the depends....
<glick> can i just install it via the install script?
<glick> do i have to use .deb?
<nigelb> you can install it via the script, but then uninstalling would be kinda tough.
<nigelb> I wish I had the docs handy here.
<pitti> Good morning
<\sh> pitti: good morning to you too :)
<dholbach> good morning
<pitti> hey \sh, how are you?
<pitti> dholbach: guten Morgen
<dholbach> hey pitti
<\sh> pitti: fine :) but fighting with some strange problems regarding glibc, passwd, crypt and ldap ;)
<\sh> moins dholbach
<dholbach> heya \sh
<siretart> einen wunderschoenen guten morgen zusammen! (or english: good morning) :-)
<\sh> hey siretart :)
<siretart> hi \sh
<micahg> hi \sh
<\sh> moins micahg :)
<\sh> guys, when someone has a solution to this problem I described on http://www.shermann.name/2010/08/openldap-passwd-and-crypt-passwords.html don't hesitate to come up with a solution ;)
<micahg> pitti: thanks for enigmail-locales, I almost forgot about it too
<bigon> slomo, any reason git file for libgee has been removed from debian? do you think you could put the same pkg as in maverick in experimental?
<bigon> s/git/gir
<\sh> directhex: the solution you mentioned doesn't work somehow, or I put the attributes in the wrong cn=config schema
<directhex> \sh, it's a global i think. should just go somewhere inoffensive in slapd.conf
<\sh> directhex: I don't have slapd.conf , using cn=config schema..which means the olcPasswordCryptSaltFormat goes into global cn=config and the olcPasswordHash goes to cn={-1}frontend,cn=config
<directhex> erk
<directhex> can't help with that kind of config, i'm afraid
<\sh> directhex: fixed...the ldap.conf on the client needs a setting in ldap.conf: pam_password exop
<\sh> then it works with the passwordhash and passwordcryptsaltsyntax
<directhex> \sh, oh, i didn't think about the client config
<directhex> \sh, glad you got it working, though
<\sh> directhex: me neither :) just had a quick chat with someone on #openldap
<\sh> I'll blog about the solution
<directhex> \sh, as long as their first response wasn't "you did WHAT? what idiot suggested that?"
<\sh> directhex: well...
<cjwatson> JFo: Following up on our discussion at the sprint, how did your collation of the kernel bugs associated with GRUB setting gfxpayload=keep go?  Is there a mailing list thread I can catch up on or anything?
<JFo> cjwatson, honestly I think I must have let that fall off my radar.
<JFo> let me catch up on it and get back with you.
<JFo> my sincere apologies for that
<JFo> cjwatson, was that on a blueprint somewhere? I found at least one that I was not subscribed to
<cjwatson> JFo: foundations-m-grub2-boot-framebuffer
<JFo> excellent
 * JFo pulls it up
<cjwatson> I think we may end up backing it out for beta
<JFo> I think so.
<cjwatson> but I'd really like to see the kernel side of it make progress anyway so that we can turn it on next release
<cjwatson> (and it's easy to flip the switch back and forward for testing)
<JFo> certainly
<JFo> I'll do some of the legwork now and get back with you so we can plan for UDS at least
<cjwatson> thanks
<JFo> my pleasure
<JFo> I apologize again
<penguin42> cjwatson: That 1.4.20.2-1ubuntu1 iscsitarget works great - thanks
<cjwatson> cool
<cnd> I've heard that dbgsym packages can be generated in ppas now
<cnd> if so, anyone know how to do that?
<chrisccoulson> cnd - build-depend on pkg-create-dbgsym?
<chrisccoulson> not sure how else to do it for PPAs, unless something changed
<cnd> chrisccoulson, oh ok
<cnd> is that documented somewhere?
<cjwatson> chrisccoulson: I have no straightforward way to test this, but do you think that something like http://paste.ubuntu.com/480968/ could fix bug 544139?
<ubottu> Launchpad bug 544139 in consolekit (Ubuntu Maverick) "Active VT tracking can fail at startup" [High,Triaged] https://launchpad.net/bugs/544139
<cjwatson> robbiew: perhaps bug 605042 should be regarded as a Linaro bug?
<ubottu> Launchpad bug 605042 in openjdk-6 (Ubuntu Maverick) "[armel] java fails to start with eglibc-2.12-0ubuntu4" [High,Confirmed] https://launchpad.net/bugs/605042
<cjwatson> doko_: is anything happening with bug 601030?
<ubottu> Launchpad bug 601030 in gcc-4.4 (Ubuntu Maverick) "broken configuration test with fortify source " [High,Confirmed] https://launchpad.net/bugs/601030
<cjwatson> slangasek: do you know what's happening with bug 553745?
<ubottu> Launchpad bug 553745 in plymouth (Ubuntu Maverick) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Triaged] https://launchpad.net/bugs/553745
<chrisccoulson> cjwatson - yeah, that would probably fix it
<cjwatson> chrisccoulson: I might stick it in a PPA or something and see what happens
<robbiew> cjwatson: aye
<robbiew> cjwatson: removed 605042 from the agenda
<cjwatson> ta
<pitti> smb: can you please make bug 614426 public? It's referenced by the lbm SRU
<ubottu> Bug 614426 on http://launchpad.net/bugs/614426 is private
<smb> pitti, Hm, I don't see much reason to keep it private, but I need to ask support guys
<ogra> seb128, would it be possibel to fix bug 607709
<ubottu> Launchpad bug 607709 in gst-plugins-good0.10 (Ubuntu) "Unused upstream files missing in the source package" [Low,New] https://launchpad.net/bugs/607709
<seb128> ogra: I don't even understand why things upstream let in the tarball is an issue, we probably have some of those in lot of sources
<seb128> ogra: oh sorry I was thinking to an another one
<seb128> ogra: well the tarball is the upstream one
<seb128> ogra: I've asked to report the bug to upstream, nobody did
<seb128> ogra: it will be fixed the day somebody cares enough to do what was suggested there
<ogra_cmpc> seb128, ok, i'll care for upstreaming
<ogra_cmpc> (oempa4 really needs these files in maverick)
<ogra_cmpc> *omap4
<seb128> ogra_cmpc, thanks
<seb128> ogra_cmpc, upstream might have a reason for not shipping those
<seb128> ogra_cmpc, I've also difficulties to understand why those are needed since it builds fine without them
<ogra_cmpc> might be, but wuld we be able to ship them in a patch if upstream doesnt make it in time ?
<ogra_cmpc> the subsequent omap4 modules and codecs make use of these files apparently
<seb128> ogra_cmpc, I'm fine adding those, I just want somebody to talk to upstream to know why they don't ship them
<seb128> could be legal reasons, could be an error, could be because the code is buggy
<ogra_cmpc> yeah
<seb128> ogra_cmpc, thanks for understanding ;-)
<ogra_cmpc> thanks for explaining :)
 * ogra_cmpc hugs seb128 
 * seb128 hugs ogra_cmpc
<smb> pitti, Seems we cannot make that bug public and I need to re-upload lbm with a new public bug number for it
<Riddell> dyfet: I don't suppose you've got anywhere with the kdebindings issue?
<dyfet> Riddell: I am discussing right now with NCommander.  It has become a python-qt4 build issue at the moment
<slangasek> cjwatson: 553745> no; my understanding was that although plymouth still has bugs there, the mountall change would render them inert
<robbiew> pitti: ping
<cjwatson> slangasek: the one that's already happened?  I would have thought it would mainly decrease the incidence
<slangasek> cjwatson: well - my expectation was that it decreased it to zero.  But if it's still happening, it should of course be a priority to fix
<asac> kees: you did the MIRs for touch stuff already?
<asac> that clearly would make my day ;)
<kees> asac: I did! at least the three mentioned yesterday
 * asac hugs kees
<cjwatson> slangasek: the assertion towards the end of the bug is that it's still happening occasionally, yes
<cjwatson> slangasek: but there's little detail, so I don't know whether it's the same thing
 * kees hugs asac back :)
<NCommander> Riddell: its not a python-qt4 issue. Its a cmake file issue. http://paste.ubuntu.com/480989/ - here's the patch that allows pykde4 to build. Smoke still FTBFS
<slangasek> cjwatson: <nod>
<pitti> robbiew: hello
<robbiew> pitti: hi :)
<robbiew> pitti: I had a ToDo from last week's release meeting
<robbiew> slangasek wanted to know if the SRU tracker could spit out a warning about significant size increases in packages in main
<pitti> robbiew: I wrote a script for comparing the package size deltas of two (alternate) isos
<pitti> robbiew: do we need that for LTS point releases? then it's already there
<robbiew> slangasek: ^?
<slangasek> pitti: what I think we want is a warning about size increases of packages *before* we start trying to turn them into ISOs
<slangasek> by the time we did that for this round, it was too late
<robbiew> how would we define "significant size increase"?
<pitti> it shouldn't be too hard to adopt the logics of iso-deb-size-compare to compare *-updates against final
<pitti> robbiew: iso-deb-size-compare lists added packages, removed packages, and size differences of > 100 kB
<pitti> well, size increases (we don't generally complain about decreases)
<slangasek> pitti: hmm, so you reinvented cd-size-analysis on antimony? :)
<pitti> but I guess for SRUs we shoudl actually list decreases as well, they are probably a bug
<pitti> slangasek: I couldn't get that to work for the life of it
<slangasek> pitti: regardless, as I said, this is something I think we need to be aware of in the SRU process, not just when we're to the point of creating ISOs
<pitti> right, understood
<pitti> it could become part of sru-report
<slangasek> robbiew: "significant size increase" - more than 5%, or more than 300k increase across the set of binary packages
<slangasek> maybe filtered by seed
<pitti> slangasek: I guess for all packages in *-proposed and *-updates should do for now; it's not that many usually
<pitti> but we could add the component indeed
<pitti> oh, "... in main"
<slangasek> robbiew: btw, I'm hesitant to approve this last message to ubuntu-announce...  I'm worried that we're no longer meeting the expectations of this being a "low volume" list
<robbiew> slangasek: hmm...fair enough...I'll copy ubuntu-devel
<smb> pitti, FWIW I am now done adding new stuff to the sru upload queue
<goldins> Hello, I hope this is not off-topic but I'm confused as to whether the issue I'm having with the new openssh (5.5) smartcard support is my fault or ubuntu's fault. The output says "dlopen pkcs11 failed: /usr/lib/pkcs11: cannot read file data: Is a directory" when I run ssh -I pkcs11
<goldins> (I'm running maverick)
<cjwatson> goldins: one moment
<goldins> cjwatson: it's cool, I can wait
<cjwatson> goldins: your -I option is certainly wrong - it's meant to be a path to a library
<cjwatson> goldins: does http://www.opensc-project.org/opensc/wiki/OpenSSH help?
<cjwatson> the syntax has changed from earlier unofficial patches against OpenSSH
<cjwatson> if you aren't using OpenSC, presumably you have some other PKCS#11 provider, in which case you need to provide the full path to its .sos
<cjwatson> er, .so
<goldins> cjwatson: it seems that if I move the directory out of the way and create a link instead to opencryptoki/libopencryptoki.so.0.0.0, I get a different error
<cjwatson> you shouldn't move files around there; you should provide a different argument to -I instead
<goldins> cjwatson: if that's the case, then ssh without arguments shouldn't say this: [-I pkcs11]  among other things
<cjwatson> pkcs11 is a substitution variable there
<goldins> I see
<cjwatson> just like -p port
<cjwatson> you aren't meant to literally type port there
<goldins> I suppose :-P
<cjwatson> the man page is more helpful
<cjwatson>      -I pkcs11
<cjwatson>              Specify the PKCS#11 shared library ssh should use to communicate
<cjwatson>              with a PKCS#11 token providing the user's private RSA key.
<goldins> also, /usr/lib/pkcs11/PKCS11_API.so is a dead link to ../opencryptoki/libopencryptoki.so but I think that's addressed in this bug:
<cjwatson> mm, I don't know anything about the specific implementations, only about the OpenSSH end of it
<goldins> https://bugs.launchpad.net/ubuntu/+source/opencryptoki/+bug/237392
<ubottu> Launchpad bug 237392 in opencryptoki (Ubuntu Hardy) "Missing symlinks for pkcs11_startup in /usr/lib/opencryptoki/stdll" [Low,Fix released]
<cjwatson> yeah, that's a bug, it will probably work if you install libopencryptoki-dev
<cjwatson> but in the meantime I guess you can just say 'ssh -I ./usr/lib/opencryptoki/libopencryptoki.so.0.0.0'
<cjwatson> er, 'ssh -I /usr/lib/opencryptoki/libopencryptoki.so.0.0.0', stray '.'
<cjwatson> and you can put the provider path in PKCS11Provider in ~/.ssh/config once it works
<goldins> cjwatson: it seems to work with /usr/lib/opensc-pkcs11.so thank you very much
<cjwatson> goldins: you're welcome
<SpamapS> ugh, why do I always seem to get changelog merging wrong? :-P
<slangasek> Riddell: re: qt4-qws - I had a good chat with svuorela yesterday on IRC; the ABI breakage isn't as bad as all that (it really is confined to the GUI components), I'm going to put together a proof-of-concept build that only rebuilds the really-truly-incompatible bits and see what that does for build time
<slangasek> SpamapS: because MoM is the only tool that actually helps with this? :)
<Riddell> slangasek: you want to talk to alf and asac mostly, it's their package
<slangasek> Riddell: well, if I prove that the build overhead is small and I'm arguing to put it in qt4-x11, that impacts *your* package :)
<SpamapS> slangasek: bzr needs a "changelog mode"
<SpamapS> that treats each block as its own immutable entity
<Riddell> slangasek: mm
<slangasek> SpamapS: recent bzr merge-package's that I've done seem to have totally mangled the debian/changelog... so maybe it already has one but it's not very good :)
<SpamapS> slangasek: we should probably go easy on james_w .. I think he's actually found a way to work 25 hours a day.
<james_w> slangasek: please file bugs
<james_w> it does indeed have one and we should improve it :-)
<slangasek> james_w: next time I reproduce it, I will :)
<james_w> thanks
<slangasek> james_w: rough description (from memory) of what I was seeing: all the changelog entries were reordered into strict version order, including those that were already present on both branches and listed in the order we wanted them.  Sound familiar at all?
<james_w> slangasek: sounds plausible
<slangasek> k
<tumbleweed> SpamapS: err, changelog merging? merge-changelog debian/changelog ../ubuntu/debian/changelog | sponge debian/changelog <- normally does the trick
<SpamapS> tumbleweed: whoa.. thats two commands I don't know anything about. merge-changelog and sponge... will do some reading
<tumbleweed> sponge is in moreutils (which is full of awesome), merge-changelog in ubuntu-dev-tools
<slangasek> hmm, why has merge-changelog not been submitted to devscripts?
<tumbleweed> SpamapS: if you are manually MoMing, I have a script that uses UDD (grab-udd-merge ubuntu-dev-tools branch)
<SpamapS> tumbleweed: in this case it was just a superceded version in a merge proposal.. but I've definitely fought with MoM'ing too.
<cjwatson> or dpkg-mergechangelogs
<cjwatson> would be better to improve that since that's about as central as we're going to get
<SpamapS> ah ok, so there is some help available.
<cjwatson> might be worth extending dpkg-mergechangelogs to be able to work without a base version
<slangasek> cjwatson: y'know, I knew dpkg-mergechangelogs was being created, but I kept failing to find it every time I looked for it... looks like it's finally made it into dpkg-dev, hurray :)
<Guest77779> Hallo. Mir ist unter Ubuntu 10 das Tray-Icon fÃ¼r die LautstÃ¤rkeregelung entschwunden. Ich schaffe es einfach nicht, dieses wieder dort auftauchen zu lassen. Was muss ich tun?
<sistpoty> Guest77779: Stelle Deine Frage bitte in #ubuntu-de, das hier ist der Channel fuer Ubuntu-Entwicklung
<Guest77779> Oh, entschuldigung. Dachte, ich befinde mich dort.
<Guest77779> Gute Nacht.
<sistpoty> kein Problem, gute Nacht
<bcurtiswx> Ok, maybe someone can help me here.  I'm trying to get fix a FTBFS in folks.  I get an error of Couldn't find include 'Gee-1.0.gir' (search path: ['.', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0'])
<bcurtiswx> which is here: https://edge.launchpad.net/ubuntu/+source/libgee/0.5.2-1ubuntu2
<bcurtiswx> in gir1.0-gee-1.0
<bcurtiswx> but, when adding that to build-dep in folks it says its a virtual package
<bcurtiswx> i already have libgee-dev as a dep, and still get that error
<eax> Hi there - Is it possible to try out the new Unity-shell somehow? Not sure if this is the right channel, if not; Sorry!
<directhex> eax-afk, try #ubuntu
<eax-afk> directhex: Will do, thanks :)
<mathiaz> jdstrand: hi!
<mathiaz> jdstrand: could you demote migrationtools and traceroute to universe?
<mathiaz> jdstrand: they already show up in component-mismatch.txt
<jdstrand> mathiaz: sure, but traceroute in universe seems odd...
<mathiaz> jdstrand: IIUC tracepath is a better alternative
<jdstrand> mathiaz: maybe, but I would never think to type 'tracepath'
<jdstrand> mathiaz: regardless of my thoughts, done
<mathiaz> jdstrand: thanks!
<SpamapS> mathiaz: well at least *something* got demoted. :)
<barry> james_w: you don't happen to still be online do you?
<james_w> barry: mais oui
<barry> james_w: so, i'm seeing something that i don't understand.  i'm working on python-numpy.  we have 1.3-mumble in maverick, squeeze has 1.4-mumble.  i go to a branch of lp:ubuntu/python-numpy and do 'bzr merge-package lp:debian/squeeze/python-numpy'.  the branch now contains numpy 1.4-mumble...
<barry> james_w: dch -i and add 1:1.4.1-4ubuntu1 (or ...4ubuntu1ppa0) and change from unstable to maverick.  the bzr bd -S
<barry> james_w: this produces both an orig.tar.gz and a debian.tar.gz, but only the debian.tar.gz gets dput'd to my ppa, and ppa rejects it because it can't find the orig.tar.gz.  what gives?
<james_w> barry: so, there is an optimisation in packaging that you don't have to provide the .orig.tar.gz if the target already has it
<james_w> barry: and there is a convention around version numbers that you start at -1 and work your way up from there
<james_w> barry: so dpkg-buildpackage has a heuristic that says "if the debian revision is greater than -1 then the target should already have it" and so omits the .orig.tar.gz
<james_w> barry: if you just have Debian then that works great
<barry> james_w: ;}
<james_w> barry: but once you introduce Ubuntu you hit the case you just have, and it falls down
<james_w> barry: so you have to tell dpkg-buildpackage that you want the .orig.tar.gz with -sa
<barry> james_w: so: bzr bd -S -- -sa ?
<james_w> barry: plus, as you are merging you should get it to include the Debian changes in the .changes, as they are new to Ubuntu.
<james_w> barry: to do that, find the last version number in Ubuntu, and pass -v<version> (no space)
<james_w> barry: and yes, that is how you would pass it
<barry> james_w: i understand all the above except the part about "Debian changes in the .changes"
<james_w> barry: ...at least it would be if I didn't anticipate your every need and upload just the other day a version of bzr-builddeb that can automate this
<james_w> barry: so it is now spelt "bzr bd -S --package-merge"
<james_w> barry: have a look at the source.changes you just uploaded that got rejected
<james_w> barry: in the middle there is an extract from the changelog with your "  * Merge from Debian squeeze [etc.]" lines
<james_w> barry: now build again with the --package-merge and look, and you will see your lines, but in addition below that lines that come from the Debian uploads that happened since we last merged.
<james_w> barry: these extra lines will get mailed around as the changes in this package, which is more correct than the changes in just your merge changelog entry
<james_w> make sense?
<tumbleweed> barry: the current version of python-numpy in ubuntu has no ubuntu delta. Can we not just sync?
<barry> james_w: it does, yes
<james_w> excellent
<barry> tumbleweed: yes, i think so.  there's an open bug on that, but doko hasn't approved it yet.  or let's say there's still some discussion about it
<tumbleweed> oh right, yes I saw that bug
<barry> james_w: one more question: after the debian merge, do i still need to bump the version number, i.e. dch -i?
<james_w> barry: yes, if I understand you correctly.
<tumbleweed> barry: yes
<james_w> you mean "after bzr merge-package lp:debian/..." run "dch -i" ?
<barry> james_w: yep
<james_w> then yes you do
<barry> it makes sense, i just needed some confirmation ;)
<james_w> we need a changelog entry different from the Debian ones
<james_w> barry: feel free to file a bug requesting an option to merge-package to do that for you
<barry> james_w: thanks again for the great info.  i'll make sure to update https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<james_w> thanks
<barry> james_w: will do, thanks again
<james_w> the "--package-merge" is new in maverick, so you might want to note that
<ScottK> jcastro: Since you've marked finding a place for DDs to ask for sync requests as done in the spec ....  What's the place?
<jcastro> ScottK: -archive, I updated the sync request wiki page too
<barry> james_w: nod
<jcastro> ScottK: with "If you do not have a Launchpad account you can mail the ubuntu archive mailing list."
<jcastro> with a link to the list
<ScottK> jcastro: My read of the discussion was some of the archive admins pushed back on that.
<ScottK> slangasek: ^^^
<jcastro> my read on that was "oh I guess we need to do a better job of telling people that"
<jcastro> ScottK: but whatever you guys decide is fine with me
<ScottK> jcastro: Unless someone is going to actively deal with sync requests sent to that list, it's going to be a point of frustration.
<nigelb> ScottK: Or a script.
<ScottK> IIRC my question about who would do that got no response.
<ScottK> nigelb: Someone would still have to run such a script.
<ScottK> (not to mention write it)
<james_w> do people realise that -archive is moderated, with non-subscribers being held for moderation?
<james_w> and that no-one would want to subscribe to the list?
<nigelb> ok, that's double pain.
<nigelb> somone has to moderate *and* process the queue
<ScottK> Since one can't assume all DD's keep track of where we are in freezes, they can't just be cargo culted, they have to be reviewed by someone who knows what they are doing.
<ScottK> jcastro: I don't think this one is solved.
<jcastro> yargh.
<jcastro> the lp sync requests end up going in there
<jcastro> why is the list moderated?
<jcastro> do the archive admins have regular meetings? It would be nice to just solve this
<ScottK> Nope.
<ScottK> List is moderated like pretty much all Ubuntu lists are moderated.
<nigelb> with only LP being white listed I think
<slangasek> jcastro: well, my position is that ubuntu-archive is not a list that I want to be subscribed to and would only subscribe to if it was made a policy for archive admins, which it has not yet :)
<ScottK> jcastro: I'd suggest any solution that ends up requiring more archive admin work to process these into syncs isn't the right answer.  Where they should land is in something like a sponsor queue.
<ScottK> slangasek: +1
<jcastro> would it be ok if I just say "hey, you guys are the archive admins, you figure it out, but please do it by X date"
<ScottK> jcastro: My response would be "They should file bugs and have them reviewed by sponsors.  Done."
<jcastro> right, but this is for people who don't have LP accounts
<ScottK> Right, I don't think that's the archive administrator's problem to solve.
<jcastro> from what lucas told me there were quite a few people he talked to in Debian that would like to be able to just mail a list
<ScottK> Yes.  I understand and agree with the goal.  I just don't think ubuntu-archive is the right list and I don't think the archive admins can/should be the ones to solve it.
<jcastro> ok, I think what I'll do is when I return from vacation if the matter isn't solved I'll POSTPONE the item and we can bring it up during the debian session at UDS.
<bcurtiswx> hey all, i've fixed a FTBFS with folks.  I've tested the fixes in pbuilder and it works.  What to do next to get the fixes into main?
<bcurtiswx> empathy's waiting on LP for this fix
<ScottK> jcastro: I don't think it needs to be in the Debian/Ubuntu session.  Ubuntu just needs to solve it.  Have a nice vacation.
<jcastro> I'll just shove you all in a room and lock the door until you solve it, heh
<sistpoty> bcurtiswx: create a debdiff, add it to a bug (file one if it's not there yet) and subscribe ubuntu-sponsors
<bcurtiswx> sistpoty: OK, brb
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/614039 => can somebody set priority on this ? seems like ALOT of people are having this issue
<ubottu> Launchpad bug 614039 in gnome-power-manager (Ubuntu) "gnome-power-manager crashed with signal 5 in _XError()" [Undecided,Confirmed]
<chrisccoulson> dupondje, somebody needs to ask for a proper backtrace (whilst running g-p-m with the --sync option). without that, it's prtty much useless
<chrisccoulson> and preferably run it through xtrace too
<dupondje> chrisccoulson: what you need exactly ? I have this issue, so can simulate this :)
<chrisccoulson> dupondje, please get a backtrace from g-p-m when running it with --sync :)
<dupondje> it says it made a coredump, but can't find it :s
<chrisccoulson> i suspect it hasn't made a coredump, because we set the core size to zero ;)
<dupondje> http://pastebin.ubuntu.com/481151/
<dupondje> ok ? :)
<chrisccoulson> dupondje, you don't have any debug symbols
<chrisccoulson> 1 second, just trying to work out which ones you need
<dupondje> libglib2.0-0-dbg ?
<chrisccoulson> gnome-power-manager-dbgsym libglib2.0-0-dbg libx11-6-dbg
<chrisccoulson> and
<dupondje> gnome-power-manager-dbgsym doesn't exist ... :)
<chrisccoulson> dupondje, https://wiki.ubuntu.com/DebuggingProgramCrash ;)
<chrisccoulson> you also need libxrandr2-dbg (or dbgsym)
<dupondje> its comming :D
<bcurtiswx> sistpoty: https://bugs.edge.launchpad.net/ubuntu/+source/folks/+bug/621423 done :D
<ubottu> Launchpad bug 621423 in folks (Ubuntu) "folks-0.1.14.1 FTBFS" [Undecided,New]
<dupondje> http://pastebin.ubuntu.com/481154/
<chrisccoulson> dupondje, which driver is this?
<dupondje> nouveau
<sistpoty> bcurtiswx: looks good from a glimpse, thanks!
<bcurtiswx> sistpoty: np, ty :)
<dupondje> chrisccoulson: http://pastebin.ubuntu.com/481159/
<dupondje> installed gdk2 dbg also :)
<dupondje> some additional info now
<chrisccoulson> dupondje, if you run gnome-power-manager --verbose, do you see "no XRANDR extension"
<chrisccoulson> ?
<dupondje> http://paste.ubuntu.com/481166/
<dupondje> seems not
<dupondje> oh yea
<dupondje> TI:00:01:53	TH:0x22950a0	FI:gpm-brightness.c	FN:gpm_brightness_init,928
<dupondje>  - no XRANDR extension
<chrisccoulson> ok, i can see whats going on
<dupondje> great :)
<chrisccoulson> not sure if i'll fix it tonight though, i'm in the middle of something else (and it's getting late here)
<dupondje> well as long it gets fixed :)
<dupondje> I hang around tomorrow, so if you need some more tests/info :)
<dupondje> going to sleep now
<dupondje> chrisccoulson: thanks for helping :) good to see it fixed in the near future :)
#ubuntu-devel 2010-08-21
<bcurtiswx> sistpoty: hey, i see it still FTBFS (folks).. I had that problem until libgee updated this afternoon
<bcurtiswx> but it works in pbuilder
<sistpoty> bcurtiswx: let me check my build log again (not too sure if I'm using a mirror, that would explain it)
<bcurtiswx> sistpoty: OK, thx
<sistpoty> bcurtiswx: yep, I've still got -1ubuntu1 draw in for the build... I'll recheck
<bcurtiswx> sistpoty: sounds good :)
<sistpoty> bcurtiswx: oh, just a small comment, please fix the bug in changelog (as in LP: #<bugnumber>). I can add that if it builds
<sistpoty> s/fix/close/
<bcurtiswx> sistpoty: ah ha, yeah since I created the bug after the fix I forgot to.  I will make sure to next time, ty.
<sistpoty> bcurtiswx: no worries, builds fine with the new libgee, looking at the binaries now :)
<bcurtiswx> sistpoty: :)
<sistpoty> bcurtiswx: thanks, uploaded
<bcurtiswx> sistpoty: you are welcome, have a great weekend
<sistpoty> thanks!
<ari-tczew> sistpoty: are you busy?
<sistpoty> ari-tczew: slightly, just reviewing libgda4 ffe, but feel free to ask any question,
<sistpoty> ari-tczew: now I'm all yours ;)
<sistpoty> tumbleweed: thanks for your thorough checks on sbackup (I admit that I didn't review the packaging at all, only the feasibilty of the new upstream version)
<ari-tczew> sistpoty: I have a patch for sponsor, but my pc has been hanged and now I have to retry build :(
<sistpoty> ari-tczew: oh, ok, I'll be around for maybe half an hour or an hour yet, but then I definitely need to go to bed
<tumbleweed> sistpoty: I've seen taht package before and so was a little extra-weary (mixed tabs and spaces in python is a recipe for disaster)
<sistpoty> heh, changing home directories contents in a postinst is certainly a blocker
<tumbleweed> yeah, most of the rest of it is just ugly. that is evil
<ari-tczew> sistpoty: my pbuilder has been crashed :(  -> Attempting to satisfy build-dependencies
<mathiaz> SpamapS: hey
<ari-tczew> sistpoty: okay, I did: sudo pbuilder-dist maverick clean and now it's building
<mathiaz> SpamapS: on the WI tracker would it be possible to put inprogress WI before done WI?
<mathiaz> SpamapS: actuall - inprogress WI should be listed first, then TODO, then done
<ari-tczew> sistpoty: bug 621497
<ubottu> Launchpad bug 621497 in gwget2 (Ubuntu) "gwget should depends on epiphany-extensions" [Undecided,New] https://launchpad.net/bugs/621497
<sistpoty> ari-tczew: I'm sorry, but I don't really understand the rationale for the change as I've almost no knowledge about the gnome stack (and try to avoid gnome packages where possible)
<ari-tczew> sistpoty: okay, so I'm leaving this one for other sponsor
<sistpoty> ari-tczew: yes, please
<ari-tczew> sistpoty: then unsubscribe from bug you could please :)
<sistpoty> ari-tczew: done, thanks
<ajeet> Hello All
<ajeet> I need some help regarding kernel releases  and Ubuntu
<ajeet> anyone out there?
<voobscout> who knows how to uupdate a source package from git repo? debian/watch is empty... aside from "We track StumpWM Git revisions, thus no need for a watch file."
<tumbleweed> voobscout: normal approach: add a get-orig-source rule in your debian/rules that does a git pull and creates a tarball
<voobscout> tumbleweed: thanks! gonna try it
<tumbleweed> voobscout: here's an example (package of mine, using hg not git): http://bzr.debian.org/loggerhead/collab-maint/re2/trunk/annotate/head:/debian/rules
<voobscout> tumbleweed: thank you!
<heyson-alice> Hi, there's a package named "teeworlds" which is out-of-date. Who should I contact if I want to upgrade it?
<voobscout> heyson-alice: you should probably do it yourself... or wait for the new release
<Laney> heyson-alice: probably #debian-games @ OFTC
<heyson-alice> I have updated it locally, but I want everyone to get the new upgrade.
<heyson-alice> Thanks, Laney.
<voobscout> heyson-alice: submit to PPA
<Laney> that won't get it in the distribution
<windydays> g@180.171.166.248) joined
<windydays> [22:50] *** fta quit (Ping timeout: 276 seconds)
<windydays> [22:50] *** fta_ changed nick to fta
<windydays> [22:52] *** schmidtm_ (~schmidtm@88.128.210.1
<windydays> I have a LAMP server run UBUNTU10.04. I think upstart is really nice. But I found that apache is not started by upstart,that is why?
<hv> in grub, how can I suppress generation of "load_video" and "set gfxpayload=keep" altogether?
<hv> It seems it is causing a lot of trouble with my graphics card
<penguin42> hv: Yeh I think you can edit /etc/default/grub
<geser> yes, I'm looking for the option right now
<penguin42> hv: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/605614/comments/11
<ubottu> Launchpad bug 605614 in linux (Ubuntu) "[ATI] GPU lockup with gfxpayload=keep" [Undecided,New]
<geser> yep, exactly that bug I was looking for :)
<hv> penguin42: thanks. btw, do you know how I can find out what are the options for that var (GRUB_GFXPAYLOAD_LINUX) ?
<penguin42> hv: No I don't; the ones I've seen are keep and text
<hv> thanks, I guess that workaround fixed it for me :)
<cjwatson> hv: 'info grub' documents them
<cjwatson> hv: the bit about unsetting the option is wrong, it should say to set it to 'text' - that'll be fixed with the next upload
<robertzaccour> I remember the customization customizing control I had in 9.04 Jaunty before it was taken away. Is it likely that we will get that back?
<hv> cjwatson: thanks, I should have read that. the info pages for grub seem well written.
<cjwatson> hv: thanks ;-)
<MTecknology> How hard is it to convert an init script to an upstart script?
<Ologn> I'm on Lucid Lynx and when I do
<Ologn> ps axu|grep dbus-daemon...system|grep -v grep|awk '{print $1}'
<Ologn> I get 102...but my /etc/passwd has messagebus as UID 102...I wonder why that happens
<Ologn> I wonder what other Lucid Lynx users get when they run
<Ologn> ps axu|grep dbus-daemon...system|grep -v grep|awk '{print $1}'
<cjwatson> what's wrong with that?
<penguin42> Ologn: It only displays names upto 8 characters
<cjwatson> oh, I see, that
<cjwatson> I thought you were wondering why it was running as messagebus
<Ologn> penguin42: Oh right, thanks
<Ologn> penguin42: I thought I might have misconfigured something, I forgot that
<penguin42> cjwatson: Can we add a pointer to the ati lockup with gfxmode=keep to the known issues on the alpha3 page - we get someone every hour or so on +1 and I'm guessing a lot more don't make ti that far
#ubuntu-devel 2010-08-22
<cjwatson> feel free, it's a wiki
<penguin42> oh, I hadn't realised the main release pages were
<penguin42> I meant http://www.ubuntu.com/testing/maverick/alpha3
<cjwatson> I can't change that either.  Just work on MaverickMeerkat/TechnicalOverview
<sistpoty> cjwatson: btw big thanks for the gparted update. While not having used the new version yet, I've experience amazing improvements after aligning my partitions to match my (cheap) hdd's 4096 sector size
<sistpoty> *experienced* even
<penguin42> sistpoty: Is that an internal drive?
<cjwatson> sistpoty: yeah, parted was updated last release, I hadn't realised until I saw the release notes that gparted needed a separate update
<sistpoty> penguin42: internal as in I mounted it inside my case... WD15EARS-00Z
<penguin42> sistpoty: interesting that the 4k drives are starting to appears
<cjwatson> they've been on their way for some time
<penguin42> nod
<penguin42> it'll be interesting to see how stuff works with >2T drives as well
<sistpoty> penguin42: actually I got that drive since january, and have only now found out that the sector size was causing huge problems (I first blamed my other hdd, being confused about my partitions, then my new mainboard)
<penguin42> sistpoty: I guess lots of people have the same problem but don't realise it
<sistpoty> penguin42: might be... I never thought that misalignment would have such negative net effects (e.g. firefox used to be unresponsive for about 20-30 seconds while updating its cache, I guess. That's completely gone now)
<penguin42> youch
<cjwatson> fresh lucid installs should generally be fine, but of course not if you tried to be clever and did the partitioning with gparted beforehand :)
<sistpoty> of course I have a developer system (wich is always weirds) and an installation that dates back to dapper, I guess (it'd be even earlier, but I reinstalled once I got amd64 hw)
<cjwatson> yeah, when I restored onto my SSD I took some care to create the partition table afresh rather than restoring it directly
<penguin42> does LVM do anything sensible on those drives?
<cjwatson> it's supposed to have alignment handling; no idea how well it works
<cjwatson> man pvcreate /alignment
<cjwatson> (hm, one of these days I should make that actually work when typed literally)
<sistpoty> penguin42: I've read that it automatically aligns to 4096 bytes, but I don't have a clue if it works (it's static data there in *my case*, problem with the 4096 sector size are writes FWIW)
<penguin42> sistpoty: Yeh - getting this all right in partition+LVM+fileystem+who knows what can probably be a nightmare; even with 512 byte drives making sure it all ligns up
<penguin42> lines even
<G> Hey guys, what should I do about a bug that I have provided a patch towards that has had no movement since May (when I posted the patch) (libvirt LP Bug #455832)
<ubottu> Launchpad bug 455832 in libvirt (Ubuntu Lucid) "segfault when attaching disk with same physical device" [High,Confirmed] https://launchpad.net/bugs/455832
<micahg> g: well, the ubuntu-reviews team is susbscribed, they'll get to it eventually, but you can ask someone in #ubuntu-reviews if they can look at it sooner
<G> micahg: righty'o thanks
<G> micahg: and I'm guessing the next thing to say is "We'd love help with reviewing other patches as well" right? :)
<micahg> g: that's up to you :)
<G> micahg: heh :)
<nigelb> G: have you tested the bug with lucid?
<nigelb> I have no clue how to test it :/
<nigelb> micahg: I'm writing that long pending email to you now :D
<micahg> nigelb: I'll work on it at our jam next weekend :)
 * nigelb hugs micahg :)
<G> nigelb: lucid yep
<nigelb> G: ok, and the patch fixes it?
<G> nigelb: all you need is a VM that you can't care about the data on
<nigelb> In that case our normal action is to forward it upstream
<G> nigelb: I'm yet to confirm if it's still present in latest upstream
<micahg> well, libvirt is much newer in maverick
<G> hmmm thats a good point
<G> haven't tried libvirt in Mav yet
<nigelb> you can forwarding upstream...
 * nigelb cannot make sense of it much.
<micahg> please see if maverick is still affected
<nigelb> G: aha, so you're the nigel jones :)
<G> micahg: just doing so now
<G> nigelb: yeah
<G> yeah, it doesn't apply to Maverick, it's fixed upstream, just lucid where it still happens
<G> micahg: nigelb: ^, can't see anything in the Debian changelog, just going to get upstream git to see if they did what I did
<nigelb> G: if you can isolate a patch, maybe we can backport it for lucid.
<G> upstream did the exact same thing, except used if (cgroup) instead of if (cgroup != NULL) which is basically the same http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=656a1e4a02c00ff6fb2ebc52ec3788d6d654f7f9;hb=92af69abad8b6531ea5d2dc16bfc36654c8f531f#l8313
<micahg> g: k, that's a good idea
<nigelb> G: aweesome, you can now go for sru since its fixed in maverick
<nigelb> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<micahg> G: great, if you can grab the commit and make a debdiff, that would be the next step
<G> micahg: so I should remake my patch to match what the libvirt guys did (assuming I can find the line where they did it)
<micahg> g: no, see if you can find the specific commit and an upstream bug that's mentioned
<G> ahhh right, I get ya
<G> will do so after coffee
<micahg> G; great :)
<G> micahg: found the original diff & ML Post reg bug
<nigelb> \o/
 * G hugs the '$VCS blame' command :)
<G> so with regard to SRU, I guess it qualifies based on the fact that it's a regression?
<micahg> G: well, it was already accepted for Lucid, so you're good to post the debdiff
<micahg> G: Make sure there's a good test case as well
<micahg> G: and follow the rest of the steps of the SRU
<G> micahg: if I was to review other libvirt bugs w/ patches would it be acceptable to bundle the patches (if I can verify them) into the same SRU?
<micahg> G: idk, we should ask the SRU team since now they approve in the queue
<micahg> jdong: around?
<kklimonda> G, micahg: https://wiki.ubuntu.com/StableReleaseUpdates#Fixing%20several%20bugs%20in%20one%20upload
<micahg> kklimonda: I know, but Idk if they thought about that with the new "review in upload queue" policy
<G> kklimonda: thanks
<G> in actual fact, there is just this bug that I'd be prepared to put forward
<ebroder> G, micahg: I'm pretty sure you can do that. If they NACK one of the fixes, you can just reupload, I'd assume
<kklimonda> micahg: I'd say that we should follow policy and if sru-team want to change it they should update documentation. at worst they will just reject it and we'll know that documentation is out of date ;)
 * micahg prefers to think tihngs out
<slangasek> G, micahg: as ebroder says, it's generally fine to bundle multiple fixes in a single SRU and upload to the queue; provided you're following the guidelines to begin with, the rate of SRU rejects out of queue is really going to be quite low
<G> okay
<micahg> slangasek: great thanks
<micahg> jdong: unping
<G> I think I'll just push this one, the others with patches I've not familiar with
<ebroder> So I'm starting to think about things like flights for UDS-N. I know robbiew said 10/25-10/29, but does that actually include weekends on either side?
<slangasek> ebroder: the developer summit is always M-F
<ebroder> Right, but should I plan on there being events on either end?
<slangasek> wrt UDS, no :)
<slangasek> you might not want a flight too early on Saturday morning since Friday night tends to be big for socializing
<maco> however there may happen to be other developers present with whom you want to spend time at a bar the sunday before
<slangasek> or that
<maco> or...ya know... DISNEY!
<ebroder> maco: I have absolutely no intentions of being in Orlando *without* going to Disneyworld. I don't understand what the point would be
 * maco pouts at the U1-4-KDE client
<slangasek> yes, what better epilogue to a free software conference than to pay tribute at the altar of perpetual copyright ;)
<ion> :-)
<ebroder> Ubuntu doesn't have awesome roller coasters :-P
<maco> slangasek: i was thinking go to disney first that way by being at uds you make amends
<maco> like penance, but fun
<slangasek> heh
<maco> well... funner than 10 hail mary's
<slangasek> I've been to Disney World, don't really need to go again :)
<ion> âWrite 100 lines of free code as a penanceâ
<slangasek> and I had the excuse that I was a child ;)
<ebroder> Eh. I don't care how old I am. I'm still a kid when it comes to theme parks
<maco> heh i was 8 when i went i think... but that was before they got all the themed areas and stuff... is the CA or FL one the one that has the new Hogwarts castle?
<slangasek> eh, haven't heard of that one
<ebroder> maco: That's Universal Studios Orlando
<maco> oh thats close!
<tjaalton> the next uds is in orlando?
<maco> yes
<tjaalton> sweet
<kblin> any pointers for debugging a partly working usb wifi dongle?
<kblin> I'm not 100% certain if I'm using the correct driver, but it's certainly a realtek chip
<kblin> can I update a package while I've got a submitrequest pending?
<lool> !regression-alert latest linux -security update in hardy breaks -xen flavour
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<lool> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<maco> lool: you're looking for the | key
<lool> maco: Thanks, will know for next time
<lool> LP #620994
<ubottu> Launchpad bug 620994 in linux (Ubuntu) "xen kernel bug: 'kernel BUG at /build/buildd/linux-2.6.24/debian/build/custom-source-xen/mm/memory.c:2704'" [Critical,Confirmed] https://launchpad.net/bugs/620994
<mdz> apw,  lag, ^^^
<lool> mdz: I've escalated to security@u.c, Cc:ing Stefan and Pete; do you think this requires further escalation (I think security@u.c is read quickly)?
<lool> mdz: I've pinged, but not phoned elmo
<mdz> lool, given it's a universe package, no, I don't think so
<persia> lool, You always have the alternative of uploading a reversion, if you feel strongly enough about it.
<lool> persia: Since it's a bunch of security updates, and all hardy users would get the updates, I'm not tempted to decide by myself, I'll leave it to security team who needs to approve the uploads anyway
<persia> OK.  Sometimes I find that on the weekend, if something bad happens, it can be better to just fix it (and let it get fixed right later), because some people aren't about.
<persia> But stable security updates end up being all sorts of special :)
<mdz> james_w, is it just me, or is lp:ubuntu/pm-utils out of date (it seems to contain 1.3.0, while maverick has 1.4.1-1)
<micahg> hmm, lp:ubuntu/flashplugin-nonfree is also out of date
<Laney> mdz and micahg: See http://package-import.ubuntu.com/status/
<micahg> Laney: does that include uploaded packages, I don't see anything for flashplugin-nonfree except for the Debian import failure
<Laney> I expect it's all part of the same thing
<geser> micahg: it might be because the Debian package didn't get imported the Ubuntu uploads don't get either anymore as this would break the history later
<micahg> geser: hmm...why?  aren't they different branches?
<geser> Ubuntu uploads are branched from the corresponding Debian revision
<wgrant> That's how merges work.
<micahg> hmm...well, this package is on the blacklist list
<persia> And trying to fix history later would be exceedingly painful, given how bzr tracks things.
<micahg> doe that mean I shoudl just use a debdiff
<micahg> instead of UDD
<wgrant> It's not really because of how bzr tracks things. But yes, all existing branches after that point would be broken.
<geser> micahg: the package importer probably doesn't know that we forked flashplugin-nonfree
<persia> Hrm?  I thought that recovering history was bad because of bzr's (current) inability to keep track of files by name and contents, rather than identity (and that this was a target to be fixed).  I agree it would be painful anyway, but this makes it more so.
 * micahg is just going to use a debdiff for branches that won't update
<wgrant> persia: Regardless of how files are tracked, you'd still have to rewrite every later revision (with a new rev ID) if you wanted to add a merge into the history.
<wgrant> Which then makes existing branches incompatible.
<persia> True
<persia> Well, incompatibility has to do with lack of understanding contents, but needing to update everything is annoying.
<wgrant> Somewhat.
<micahg> hmmm...weird, UDD just overwrote my 2 revisions (merge/release) that I used to update a package
<lifeless> had you done a mark-uploaded when you uploaded, and pushed that ?
<micahg> lifeless: no, I must have missed that step on the instructions
<micahg> ah, it's in the upload document, not the merge document...
<micahg> I'll remember for next time
<nisiop> ne one trued ubuntu lts???
<directhex> nisiop, that's not english
<nisiop> lol
<nisiop>  has anyone tryed ubuntu LTS eddition
<directhex> i'd guess quite a few people, given it's the current stable ubuntu release. but i'd also guess that your question isn't really an #ubuntu-devel question
<persia> Heaps and heaps of folk.  You may find some of them happy to answer questions about it in the support channel (#ubuntu).  At this point, most of the developers are focused on the next release.
<nisiop> man copers are cranky
<nisiop> coders*
<nisiop> ne one help me set up a domain useing bind?? does that count
 * nisiop finds another room
<directhex> i doubt i would have helped him even if it were #ubuntu, the inability to spell would send me into a flying rage within minutes
<wgrant> srsly???
<directhex> YA RLY
<shadeslayer> hehe :P
<debfx> could someone please retry https://edge.launchpad.net/ubuntu/+source/junit4/4.8.2-1 , it builds fine now
 * shadeslayer wants a sponsor too :P
<bilalakhtar> shadeslayer: bug #? I know I cannot sponsor, but will just have a loo
<bilalakhtar> s/loo/look
<shadeslayer> no bug :P
<bilalakhtar> shadeslayer: branch?
<shadeslayer> koffice 2.2
<shadeslayer> from : https://edge.launchpad.net/~rohangarg/+archive/experimental/+packages
<shadeslayer> they had a bug fix release
<bilalakhtar> ah, this is outside my scope
<shadeslayer> :)
<shadeslayer> i asked aplg but he doesnt have the bandwidth :P
<shadeslayer> if anyone has the time .. please :)
<bilalakhtar> shadeslayer: try asking on #kubuntu-devel
<shadeslayer> bilalakhtar: already did.. everyone is sleeping
<shadeslayer> im there most of the time anyway
<emacs_noob> anybody knows where does sudo source it's envronment vars from?
<jdstrand> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128, lool: I've commented in bug #620994
<ubottu> Launchpad bug 620994 in linux (Ubuntu Hardy) "linux 2.6.24-28.75 breaks xen flavours (xen kernel bug: 'kernel BUG at /build/buildd/linux-2.6.24/debian/build/custom-source-xen/mm/memory.c:2704')" [High,Confirmed] https://launchpad.net/bugs/620994
<jdstrand> in essence it is my opinion that we should not yank the patch as it would reintroduce a serious vulnerability with a known exploit (there is a paper on it) for all hardy users
<jdstrand> the kernel team should be online to look at this completely in 15 hours or so
<jdstrand> while unfortunate, I think pulling the patch would affect more people than leaving it in
<jdstrand> and xen users can always boot into their previous kernel
<MattJ> Sigh, I wonder if my internal TI card reader will ever work properly
<penguin42> MattJ: What does it do?
<MattJ> Aug 22 16:01:40 silver kernel: [ 7079.424137] tifm_sd0:1 : card failed to respond for a long period of time (12, 1)
 * penguin42 thinks the TI one in here generally works
<MattJ> and then gazillions of other syslog messages about IO errors
<MattJ> It's been a problem for me since, hmm, Dapper I think... but it's intermittent
<MattJ> Though it's puzzling, I think it started working (at least more reliably) in one release
<MattJ> and when searching for bug reports, it seems that's consistent
<penguin42> yeh PCIxx12 working on Maverick here - just tried
<MattJ> But now I'm having it again, so perhaps it's a regression... I can't find any recent reports of it
<penguin42> MattJ: My experience is they can be very touchy with regard to the particular card
<MattJ> I have: 07:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
<MattJ> I've used this card in here before
<MattJ> Hmm, actually maybe I didn't
<penguin42> MattJ: Same here, lspci -n shows it as 07:06.2 0180: 104c:803b
<MattJ> I could have given up and used my (slow) camera via USB
<MattJ> Oh well
<penguin42> yeh I've been tending to do that, my new machine doesn't have an SD card slot, and the external USB card reader doesn't seem to like the current 2GB card I have
<MattJ> Actually I think I'll borrow another laptop and network it, that'll save flattening my camera battery :)
<MattJ> Now the cards are bigger I just don't empty them until they're full :/
<penguin42> I do tend to like to copy any particularly nice stuff off before I have the chance to screw it up
<lool> jdstrand: thanks a lot for commenting
<nigelb> can someone take a look at bug 74065?
<ubottu> Launchpad bug 74065 in vmware-player (Ubuntu) "apt-get remove vmware-player doesn't remove vmware-player service" [Undecided,Confirmed] https://launchpad.net/bugs/74065
<penguin42> OLD bug
<nigelb> Yes, but it has a patch.
<nigelb> I'd like to know what they think about symlinks is the right.
<ebroder> nigelb: That's the wrong way to fix the bug, though. The right thing to do is for the init script to check if the package is still installed at the beginning
<tumbleweed> the normal solution to that is to check for the existance of the binary on startup
<ebroder> nigeld: Look at /etc/init.d/ssh; at the beginning it does "test -x /usr/sbin/sshd || exit 0"
<nigelb> Ah.  but symlinks getting removed only at --purge is normal?
<ebroder> Yes
<nigelb> Ok, thank you :)
<nigelb> cjwatson: do you have comments thoughts to add on bug 110144?
<ubottu> Launchpad bug 110144 in debootstrap (Ubuntu) "No lo interface after debootstrap install" [Wishlist,Triaged] https://launchpad.net/bugs/110144
<reaby> hi, just a question: will the 10.10 have onscreen keyboard preinstalled by default
<reaby> just wanted to point this out, since i ran into troubles one day using 10.04, i wasn't able to find it
<reaby> you can actually login to system with mouse, but can't use it after that, or atleast i didn't find onscreen keyboard anywhere
<penguin42> not sure, the accessibility stuff is normally in by default isn't it?
<reaby> well, i double checked this.. as the usercase with me was with a server that i installed a while ago
<reaby> i just installed 10.04 from scratch to virtualbox and i can't find onscreen keyboard in menus
<reaby> gdm has own onscreen keyboard, but gnome doesnt
<penguin42> that's a bit weird
<reaby> yes
<penguin42> Interestingly I've just checked, on here the only one I have is the KDE one under kvkbd
<penguin42> and character map isn't useable for that
<maco> onscreen keyboard used to be included by default
<maco> i wonder when it got removed?
<penguin42> not unless you primarily want weird symbols
<maco> visual system bell for deaf users was removed from gui in karmic, but i have a patch to add it back to mav
 * maco goes to say something in #ubuntu-accessibility
<reaby> well, i had to make compromize with the server machine i was working with, either mouse or keyboard with memoristick, apparently i wasn't able to get into system menus without mouse..
<penguin42> yeh that sucks, should be able to get to most stuff via keyboard
<maco> reaby: cant get into system menu without mouse?
<maco> what menus cant you open?
<reaby> well i didn't find a keyboard maping to applications menu
<maco> alt+f1
<reaby> ach
<reaby> lol
<reaby> :)
<maco> same in both gnome and kde
<reaby> ok, good to know
<maco> thats set in the "keyboard shortcuts" window as "show the panel's main menu"
<reaby> hmm.. you guys prolly don't like the idea for using now-a-days standard keyboard start-button for opening applications menu?
<mneptok> "standard?" the keyboard i am using does not have such a button.
<reaby> in terms of usability
<reaby> :/
<maco> not everyone has a pc105
<maco> also, the shortcuts dialog wont let you set <super> without another key
 * penguin42 hugs his Model M
<maco> modifier keys have to have a normal key with them
<mneptok> penguin42: ticka ticka ticka
<penguin42> although I have some sympathy for using super for some things, as long as I can switch away
<penguin42> mneptok: No, much much louder :-)
<maco> TICKA TICKA TICKA
<mneptok> penguin42: http://pckeyboards.stores.yahoo.net/linux101.html
<penguin42> mneptok: Nod, I've got 3 standard ModelM's (UK 102 key) - one here, one at work and a spare
<mneptok> penguin42: Unicomp is still making them. and labeling keys for Linux users. :)
<reaby> well sorry for mentioning :(
<penguin42> mneptok: Yeh
<maco> reaby: as far as i know, that key is only standard on windows anyway
<maco> reaby: when you hit the apple key on a mac, it does not open the menus
<mneptok> reaby: no need to apologize. but it's not safe to make assumptions about the hardware "most people" have.
<penguin42> reaby: No I have some sympathy with the use of the extra key; at some point I do have to acknowledge I'm a weird grey beard :-)
<maco> yuck i wouldnt use that
<maco> ctrl's in the same spot as those awful sun keyboards
<maco> now, if they made a *vi* keyboard... you know, with esc next to A...i'd be happy
<ion> What prevents you from mapping it there?
<maco> i do map it there
<maco> the key's just labeled wrong when anyone else tries to use my computer
<mneptok> maco: they tried. but the vi(m) community responded with "we make our own keyboards by specifying Chinese plastic fab factories in .vimrc. kthxbai."
<maco> they hit caps lock, and the window closes :P
<ion> I use it as ctrl, though. And yeah, iâm a vim user.
<penguin42> maco: Oh, HP used to do one like that, I used one at college - it had it just next to left shift
<penguin42> pity the rest of the layout was so weird
<reaby> but thanks for listening a random users note from this issue
<dupondje> chrisccoulson: had some time yet for the gnome-power-manager bug ? :)
<chrisccoulson> dupondje, i might look at it later, but it's still the weekend ;)
<chrisccoulson> i generally try to do as little work as possible at the weekend ;)
<reaby> bye
<dupondje> chrisccoulson: no problem :) you saw its also an issue with other drivers then nouveau? Or is it not nouvea-related ?
<chrisccoulson> dupondje, it affects any driver that doesn't support XBACKLIGHT
<dupondje> ok :)
<dupondje> seems like almost all drivers ?
<ari-tczew> Sarvatt: around?
#ubuntu-devel 2011-08-15
<diwic> Ctrl-Alt-T works again in oneiric! \o/
<dholbach> good morning
<bkerensa> Hi, Any packaging experts about?
<pitti> Good morning
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, now where the printer drivers are through the MIRs, can you seed them? 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> tkamppeter: yep, doing now
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, I have sent a message to the TB list and got a message that it needs moderator approval. Do I need to contact someone else to pass the message through?
<pitti> tkamppeter: I'll moderate it
<doko> Laney: ghc ping
<Laney> doko: yeah?
<cjwatson> SpamapS: yow, collectd is actually composed entirely of build failures
<doko> thunderbird and compiz is horrible broken
<doko> how do I get a screenshot from a MacBook keyboard?
<ev> doko: DISPLAY=:0 gnome-screenshot -d 10 &; chvt 7
<cjwatson> SpamapS: collectd fixed now
<directhex> Laney, were you satisfied with 2.10.4-2?
<Laney> directhex: yah. I requested the sync already
<directhex> cool
<Laney> I wonder why those upgrade bugs happen though
<doko> ev: you still build the camera binary from the "bad" source. is this intended?
<ev> doko: I'm halfway through sorting that now
<OdyX> tkamppeter: Ping (w.r.t rastertodag-gdi)
<debfx> cjwatson: may I bug you again about the kubuntu packageset? ;)
<debfx> I think these packages should be added: http://paste.ubuntu.com/666466/
<tkamppeter> OdyX, hi
<OdyX> tkamppeter: Hi. Did you get my mail wrt versioning ?
<cjwatson> debfx: could you mail me, please?
<tkamppeter> OdyX, I have seen your mail about the problem of the source tarball not having a version number.
<OdyX> tkamppeter: I noticed another problem too: the license is said to be "GPL", without versioning nor "or later" cause. This should really be clarified (with -2+ being preferred IMHO).
<debfx> sure
<tkamppeter> OdyX, I will contact the upstream author about that.
<OdyX> tkamppeter: other than that, nice (and easy) package, thanks !
<dobey> kees: hey. where did you leave ubuntuone-installer at?
<pitti> cjwatson: when building an image with "ubuntu-defaults-image --components main,restricted,universe --locale zh_CN" I now get the ubuntu syslinux/gfxboot bits (thanks!), but booting fails with "/casper/vmlinuz: file not found"; indeed there's only /casper/vmlinux-3.0.0-8-generic
<pitti> cjwatson: do you know whether something should create an appropriate symlink there, or should the syslinux configuration be changed to the versioned one?
<dobey> pitti: i guess kees isn't around yet. trying to figure out where
<dobey> https://bugs.launchpad.net/ubuntu/+bug/817133 is at, and what i need to do for it
<ubottu> Ubuntu bug 817133 in Ubuntu "[needspackaging] ubuntuone-installer needs packaged" [High,In progress]
<dobey> evil paste, pasted a 'RET' instead of my url :-/
<cjwatson> pitti: yeah, I know, on my queue to look at, I don't know the answer yet
<cjwatson> need to compare against the real images
<pitti> cjwatson: the real images actually have /casper/vmlinuz and /casper/initrd.lz, so I guess they should be renamed
<cjwatson> it would be best to match the real ones, yes.
<dobey> pitti, cjwatson: ^^ can either of you tell me where ubuntuone-installer is at, and/or what i need to do with it? i can't find it in the queue :-/
<ev> do we have a general practice for handling pipeline failures in dash scripts? I've tried something like http://paste.ubuntu.com/666566 , but it doesn't appear to be valid POSIX (works well enough in zsh).
<ev> err I copied that incorrectly
<ev> http://paste.ubuntu.com/666571
<cjwatson> ev: it's a pain, but the approach you've taken should be valid POSIX, I think.  What's the error message?
<broder> cjwatson: it looks like the ubuntu cds have EFI grub images on them. do you know where are those coming from? i don't see anything enlightening in ubuntu-cdimage or livecd-rootfs
<ev> cjwatson: syntax error: "}" unexpected (expecting ")")
<cjwatson> broder: debian-installer builds them
<cjwatson> ev: try (...) rather than {...; } then?
<cjwatson> it might not like { ...; } | ...
<cjwatson> actually I think I would take a marginally different tack anyway; let me construct it ...
<cjwatson> the 2>&1 is bad
<ev> cjwatson: for what it's woth, I did try a subshell
<ev> cjwatson: brilliant! Thanks for the spot
<cjwatson> s="$( ((grub-mkimage -O i386-pc ${prefix:+--prefix="$prefix"} -c "$tmp/wubildr-bootstrap.cfg" -m "$tmp/wubildr.tar" $modules; echo $? >&3) | cat /usr/lib/grub/i386-pc/lnxboot.img - > "$tmp/wubildr") 3>&1)"
<cjwatson> [ "$s" = 0 ]
<cjwatson> try that, I think it's a bit simpler and seems to work
<cjwatson> you might even get away without the outer subshell, not sure
<cjwatson> probably not
<doko> infinity: if you do a ocaml test rebuild, please could you use the one from  the ubuntu-toolchain PPA?
<infinity> doko: I was planning on just re-uploading all the ocaml bits to the archive to take advantage of the current fix... Do we need the linker changes from the PPA as well?
<ev> cjwatson: works perfectly, thanks a bunch!
<infinity> doko: And if so, why have them in a PPA?
<doko> infinity, well, then please merge it with the new version
<infinity> doko: Sure, happy to merge it with ocaml/jocaml before I re-transition armel.
<dobey> hrmm
<dobey> what would be the best thing to override with plain dh (%: dh $@), for running regression tests?
<cjwatson> dh_auto_test
<dobey> when does that get run?
<cjwatson> you can see the ordering if you read /usr/bin/dh and search for @bd
<cjwatson> it's immediately after dh_auto_build though, which generally corresponds to 'make' or './setup.py build' or that sort of thing
<dobey> ah, after build and before install, ok
<tkamppeter> OdyX, upstream of rastertosag-gdi is informed and I have renamed the upstream tarball to have the version number 0.1 as the Debian and Ubuntu packages. See http://forums.linux-foundation.org/read.php?30,13489,14202#msg-14202.
<cjwatson> dobey: or, 'dh --no-act binary' shows the complete sequence
<cjwatson> assuming a clean build tree
<infinity> doko: Is there a reason that patch drops --no-relax?
<doko> infinity, does it? and if yes, we don't care about alpha
<doko> infinity, join debian, they seem to care about alpha again ;p
<infinity> doko: Yeah, I suspect relax/no-relax are probably no-ops on most (all?) of our architectures anyway, but I was just curious if it was dropped intentionally.
<dobey> cjwatson: thanks
<OdyX> tkamppeter: great.
<OdyX> tkamppeter: on my side, I put some thoughts (and code) on a pkg-printing-tools package that would feature a dh_cupsppdupdate to externalize the big postinst redundancy + eventually a dh_pyppd that would feature automatisation around pyppd + automated depends.
<tkamppeter> OdyX, great, then this could all be reduced to a single line.
<OdyX> â¦ and reduced disk-space footprint, failure possibilities.
<infinity> doko: Oh, I was misreading the patch, didn't realise it was just passing no-relax on alpha.  Derp.  I'm only on my first coffee. ;)
<infinity> doko: Will merge, test, and upload today.
<jono> hi all
<jono> who is maintaining couchdb in Ubuntu?
<jono> well, specifically, desktopcouch?
<davmor2> jono the u1 team might be able to point you in the right direction
<beuno> jono talk to dobey, he'll probably be the person, or know the person
<Laney> all of the recent uploads are by chad miller
<jono> thanks beuno
<jono> dobey, hi!
<jono> :-)
<jono> dobey, have you seen https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/825280 ?
<tkamppeter> mterry, kees, the upstream of colord, Richard Hughes, has answered on bug 823185.
<ubottu> Ubuntu bug 825280 in thunderbird (Ubuntu) "Repeated Ubuntu One address book errors" [Undecided,New]
<ubottu> Launchpad bug 823185 in colord (Ubuntu) "[MIR] colord" [High,Incomplete] https://launchpad.net/bugs/823185
<SpamapS> cjwatson: Thank you! Yes.. collectd is a pretty ambitious union of just about every library that ever existed on servers... ;)
<RoAkSoAx> rsalveti: ping
<rsalveti> RoAkSoAx: pong
<RoAkSoAx> rsalveti: howdy!! I was wondering what's the status of PXE on pandaboards?
<rsalveti> RoAkSoAx: working nicely with the packages available at oneiric already ;-)
<Daviey> RoAkSoAx: did you follow the email i sent a few weeks ago?
<Daviey> (Hi btw)
<rsalveti> RoAkSoAx: http://rsalveti.wordpress.com/2011/07/11/net-booting-with-tftp-and-pxe-with-pandaboard/
<RoAkSoAx> rsalveti: awesome thne!! gonna try to pxe now!
<RoAkSoAx> Daviey: howdy!! what email?
<Daviey> RoAkSoAx: ^^ I emailed that link.
<Daviey> in response to zul's mail.
<RoAkSoAx> rsalveti: cool, yeah I saw your blogpost was just wondering if all made it to oneiric, which already did
<RoAkSoAx> Daviey: ah yes... I already saw that... but didn't have the required cables/power supply till last week and I was in Austin  :)
<RoAkSoAx> Daviey: how did things turn out in London btw?
<rsalveti> RoAkSoAx: mahmoh is our official u-boot pxe user on panda :-)
<mahmoh> RoAkSoAx: hi
<RoAkSoAx> rsalveti: k thanks ;)
<Daviey> RoAkSoAx: Pretty good.. i have a draft mail.
<rsalveti> he's being using it with the server image for quite a while
<rsalveti> RoAkSoAx: np, let me know if you find any weird bug ;-)
<mahmoh> so what's up?
<RoAkSoAx> mahmoh: howdy!! any recommendations? I'm gonna start playing with it to add the support to cobbler
 * mahmoh was hoping to talk about kernels
<mahmoh> RoAkSoAx: awesome.  There's a minor bugs in it now that require config caveats
<mahmoh> RoAkSoAx: what hardware are you using it with?
<RoAkSoAx> Daviey: cool!! I look forward to it.
<RoAkSoAx> mahmoh: as in SD card, or as in pandaboard?
<mahmoh> RoAkSoAx: sounds like pandaboard
<RoAkSoAx> mahmoh: heh yeah pandaboard
<mahmoh> RoAkSoAx: hm, I can give you a list of bugs I'm tracking that may affect you
<Daviey> mahmoh: Ooo, list of bugs most appreciated
<RoAkSoAx> mahmoh: sure, that would be helpful
<mahmoh> lp bugs: 820124, 808815, 820113,820116, 820121, 820122, 820124- these may affect you
<ubottu> Launchpad bug 808815 in u-boot-linaro (Ubuntu) "pxe missing kernel_ram and initrd_ram defaults" [Low,Fix released] https://launchpad.net/bugs/808815
<ubottu> Launchpad bug 820116 in u-boot-linaro (Ubuntu) "usb start in uEnv.txt fails with test - minimal test >>> like /bin/sh" [Undecided,Confirmed] https://launchpad.net/bugs/820116
<ubottu> Launchpad bug 820124 in u-boot-linaro (Ubuntu) "pxe boot ignores pxe config prompt and timeout value - fails to automatically boot" [Undecided,New] https://launchpad.net/bugs/820124
<ubottu> Launchpad bug 820113 in u-boot-linaro (Ubuntu) "uboot fails to automatically load uInitrd and boot hangs" [Undecided,New] https://launchpad.net/bugs/820113
<ubottu> Launchpad bug 820121 in u-boot-linaro (Ubuntu) "bootp via autoload fails to load uInitrd and continues on to fail with Bad image type" [Undecided,New] https://launchpad.net/bugs/820121
<mahmoh> bug 820122 and bug 820124 ? ubottu?
<ubottu> Launchpad bug 820122 in u-boot-linaro (Ubuntu) "running usb start twice hangs u-boot at ethernet discovery" [Undecided,Confirmed] https://launchpad.net/bugs/820122
<ubottu> Launchpad bug 820124 in u-boot-linaro (Ubuntu) "pxe boot ignores pxe config prompt and timeout value - fails to automatically boot" [Undecided,New] https://launchpad.net/bugs/820124
<mahmoh> I think I just found a bug in ubottu
<mahmoh> RoAkSoAx: ^^^^^
<RoAkSoAx> mahmoh: cool! thanks!
<mahmoh> RoAkSoAx: if you find any new problems feel free to add them in and ping me or GrueMaster
<RoAkSoAx> mahmoh: will do!1 thanks for the info!
<mahmoh> RoAkSoAx: speaking of which, is there a unit test or suite for puppet?  /me wonders if we should be using something like that soon to help regression testing
<RoAkSoAx> mahmoh: not that I know of
<mahmoh> RoAkSoAx: I'm usually on ubuntu-arm or ubuntu-server
<mahmoh> RoAkSoAx: well, if you want to collaborate on that at some point let me know, I'd have to take a look at the bugs that have sprung up over the years
<mahmoh> did I say puppet?  I meant cobbler.  I need to stop multitasking
<RoAkSoAx> mahmoh: cool ;)
<RoAkSoAx> mahmoh: and not there's no unit tests
<mahmoh> RoAkSoAx: as long as there's no bugs in it we're fine ;)
 * Daviey writes bug free softwares.
<mahmoh> RoAkSoAx: let me know if you have questions
<nigelb> Daviey: *cough* I have some of the code you wrote to prove that wrong :P
<mahmoh> bug free = feature rich
<Daviey> :D
<mahmoh> those were easter eggs for you to find
<Daviey> nigelb: show me the unit test proving otherwise.. kkthnx
<nigelb> Daviey: hah
<RoAkSoAx> rsalveti: mahmoh this might sound dumb, but do I still need to create a partition in the SD card and place the MLO and u-boot.bin or not anymore?
<mahmoh> RoAkSoAx: yes
<Daviey> RoAkSoAx: Are you asking when will there be native PXE support on ARM platforms?
<RoAkSoAx> mahmoh: cool, just double checking ;)
<mahmoh> RoAkSoAx: for that stock board you still need to boot MLO and u-boot off of the SD/MMC
<RoAkSoAx> Daviey: was just wondering :)
<RoAkSoAx> mahmoh: ok cool
<mahmoh> RoAkSoAx: from there you can pxe boot and/or install/boot from a usb-sata disk (powered is ideal)
<rsalveti> RoAkSoAx: that depends from board to board
<rsalveti> panda needs MLO and u-boot
<rsalveti> you can have that at your sd card or load it from usb, using omap4boot
<rsalveti> but then you'll need to do that on every reboot
<rsalveti> sd card should be a good start :-)
<RoAkSoAx> rsalveti: mahmoh awesome then! thanks
 * mahmoh forgot about omap4boot
<smoser> does this pastebin mean anything to anyone : http://paste.ubuntu.com/666645/
<smoser> i just uploaded a new euca2ools, with minimal changes, but when i try to install i get that
<smoser> python install error about /usr/share/pyshared/euca2ools-2.0.egg-info/PKG-INFO.dpkg-new
<cjwatson> smoser: possibly symlink changed to directory or vice versa; dpkg won't do that itself, you have to clean up the old one in a preinst
<cjwatson> this may have changed due to python helper changes
<smoser> thanks. i'll dig a bit. i'd think this would be larger than just euca2ools, though. i wouldn't think it is doing anything special here.
<dobey> jono: i have not. maybe rodrigo or chrisccoulson have?
<chrisccoulson> heh, it's not me ;)
<chrisccoulson> rodrigo is probably your best bet though
<cjwatson> smoser: yes, I recognised the problem because I've heard of it before, although I can't find a reference
<cjwatson> smoser: I don't know if there's a general solution beyond the (AIUI) small number of affected packages handling it explicitly
<smoser> cjwatson, ok.. it seems fairly new, though, as the last upload did not fail this way and occurred last thursday.
<cjwatson> you probably want barry for more than drive-by help
<smoser> yeah, barry ^ does that ring any bells ?
<dobey> can i get a couple of quick sponsorships to fix some FTBFS in oneiric?
<barry> smoser: it does ring a bell, but i can't place it.  there was another package that had a similar issue i think, but we decided not to worry about it because it only affected updates within oneiric alphas.
<jjardon> Hi, my Ubuntu session doesnt work anymore. Seems that compiz is crashing after login. Known bug?
<jjardon> Ubuntu 2D works without problems
<sladen> jjardon: the right people might not be around.  http://launchpad.net/ubuntu/+filebug
<jjardon> FYI, I'm using Oneiric
<jjardon> sladen: thanks
<jjardon> sladen: I know that link ;)
<dobey> mterry: i choose you!
<mterry> dobey, you have to catch me first
<dobey> mterry: https://code.launchpad.net/~dobey/ubuntu/oneiric/couchdb-glib/fix-824666/+merge/71592 and https://code.launchpad.net/~dobey/ubuntu/oneiric/evolution-couchdb/fix-824669/+merge/71593
<dobey> simple FTBFS fixes
<mterry> dobey, looking
<mterry> dobey, both pushed, thanks!
<dobey> thanks fore review
<dobey> now if i can figure out what happened to my other NEW upload
<ion> Yay, dmz-cursor-theme was added back.
<dobey> kees: ping?
<kees> dobey: hi!
<kees> dobey: I ran out time last week, sorry about that. :(
<dobey> kees: ok, what's the status on ubuntuone-installer, and what do i need to do?
<kees> dobey: hrm, now I can't find the bug for it.
<dobey> https://bugs.launchpad.net/ubuntu/+bug/817133
<ubottu> Ubuntu bug 817133 in Ubuntu "[needspackaging] ubuntuone-installer needs packaged" [High,In progress]
<kees> ah-ha, thanks.
<kees> dobey: okay, so, I'm not sure I understand one part -- __get_series() seems like it should at least return "oneiric" right now.
<kees> from there, I can upload it at least.
<dobey> do i need an FFE for it now though?
<kees> dobey: yes, though nothing depends on it, so it should be easy to do.
<kees> https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
<dobey> ok, thanks
<kenvandine> Ursinha, i took a pass at creating a package for unity-launcher-editor
<dobey> kees: ok, just attached new .dsc/.debian.tar.gz to https://bugs.launchpad.net/ubuntu/+bug/817133 and I also had to override dh_auto_install to use xvfb-run as well it seems. but there it is :)
<ubottu> Ubuntu bug 817133 in Ubuntu "[FFe] [needspackaging] ubuntuone-installer needs packaged" [High,In progress]
<ScottK> kees: I didn't flip 817133 back to incomplete to avoid a reversion war, but (see my comment in the bug) I definitely think it's premature to consider an FFe right now.
<kees> ScottK: fair enough, thanks.
<slangasek> ScottK: the new python-sip seems to break the build of python-qt4; there's a patch (debian/patches/siputils_debian_changes.diff) that short-circuits queries for the library names to link against, which means build-time tests attempt to compile programs without linking to Qt at all...
<ScottK> Hmmm.
<ScottK> That patch isn't new (IIRC).
<slangasek> yep - I guess the upstream behavior changed out from underneath the patch though
<ScottK> Also the API version didn't change so it's allegedly compatible.
<ScottK> Urgh.
<ScottK> The second hunk of the patch bypasses it entirely.
<ScottK> I think what's changed us --no-add-needed.
<ScottK> slangasek: I'm on a $WORK deadline this evening, so I can't promise when I can look at it.
<ScottK> Unfortunately Torsten Marek is not very active recently.
<slangasek> ScottK: it's not --no-add-needed - it's spitting out rules that attempt to compile without linking to *any* Qt libs (even -lQtCore for the first test)
<slangasek> $WORK deadline - understood; just wanted to bring it to your attention
<ScottK> OK.
<ScottK> debfx: ^^^ Maybe you can look?
<hallyn> SpamapS: around?
<SpamapS> hallyn: here now, sup?
<hallyn> SpamapS: i uploaded a libvirt to lucid-proposed earlier today,
<hallyn> but i want to mix in another triival sru
<hallyn> woudl you mind kicking the one that's there now and i'll re-upload?
<hallyn> (the other is a text comment added to /etc/default/libvirr-bin)
<SpamapS> hallyn: preparing to kick..
<SpamapS> hallyn: kicking..
<hallyn> thank you SIR may i have anOTHER
<SpamapS> hallyn: kicked!
 * infinity is mildly distubed by the above exchange.
<hallyn> dpamthnks!
<hallyn> uh.  hm
<hallyn> SpamapS: thanks!
<hallyn> new versions pushed
<hallyn> SpamapS: so regarding upstart jobs reading from /etc/default...
<hallyn> am i remembering right that we will want to stop that when override files are supported?
<hallyn> or is there something else it's waiting on?
<SpamapS> hallyn: Its waiting on me doing some tests to actually measure if it slows down the boot.
<hallyn> ok
<SpamapS> hallyn: override files have been available since the early alphas of 11.04
<hallyn> orly
<SpamapS> hallyn: I say if the original package used /etc/default, we're going to have to keep reading it anyway, so only worry about services that have never had a /etc/default file
<hallyn> hm, ok
<hallyn> i guess the really fast-booting netbooks wont' have libvirt anyway :)
#ubuntu-devel 2011-08-16
<slangasek> lamont: so I'm pretty sure that postfix used to copy sasl modules over into its chroot without my intervention; this seems to have broken with the convertion of cyrus-sasl2 to multiarch, but I can't find where in the code it would do the copy.  Can you cluebat me?
<slangasek> lamont: ah n/m, I've probably managed to break saslauthd
<slangasek> lamont: hmm, nope, saslauthd doesn't look like it was ever configured... so something else has gone wrong
<jbicha> does Feature Freeze mean that it's too late for new packages from Debian to get into Oneiric?
<micahg> jbicha: with a good reason, you can still get them in, just file for an exception
<jbicha> micahg: ok, thanks, I'll give it a try then
<micahg> *if you have a good reason :)
<jbicha> it'll just depend on if someone bothers to sponsor it in, otherwise it will happen automatically next cycle
<micahg> we'll still be going through the sponsorship queue regularly, the trick is only the FFe for new packages
<merlot> Hello, I have c++ program that I would like to put in a .deb package and make available for people. I'm not familiar with the build scripts anyone with a url?
<RAOF> merlot: https://wiki.ubuntu.com/PackagingGuide/Complete is the full packaging guide; depending on what you want to do it can be a bit of overkill.
<RAOF> merlot: If you just want something simple, there are tools being developed.  http://pkgme.net/ would be something to look into.
<merlot> RAOF: Do I need to read the automake manual first? I just have a single .cpp file.
<merlot> I've done make files before but not sure how to do this with automake
<RAOF> Ah.  Your program is even simpler than that :).
<RAOF> Automake would likely be overkill there.  I'm not sure how well pkgme handles plain makefile buildsystems.
<RAOF> On the other hand, it would also be fairly easy to whip up a source package by hand in that case.
<RAOF> https://wiki.ubuntu.com/PackagingGuide/Complete#Basic_Packaging isn't a bad guide there.
<pitti> Good morning
 * slangasek waves to pitti 
<pitti> hey slangasek
<slangasek> lamont: postfix figured out; patch pushed to oneiric
<dholbach> good morning
<pitti> doko_: I got a yelp merge proposal, OK to upload gnome-ish packages again?
<doko_> pitti: fine, as long as it doesn't leave some packages unbuildable. didn't start the rebuild yet
<pitti> no, shouldn't; no ABI change, and builds fine locally
<lamont> slangasek: a
<lamont> ta
<slangasek> doko_: anything blocking the rebuild from happening?
<doko_> slangasek, time \o/ ... will start it today
<slangasek> ok :)
<ev> @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: ev
<OdyX> tkamppeter: I changed my mind: http://bugs.debian.org/637978 I think it's a greatly better way to solve this.
<ubottu> Debian bug 637978 in cups "cups: Please add a dpkg trigger to update PPDs on driver upgrades" [Wishlist,Open]
<pitti> OdyX: dpkg trigger sounds a lot more elegant indeed, thanks for working on this!
<OdyX> pitti: thank tkamppeter for writing the postinst in the first place; it sounds almost easy now. :-)
<merlin371> hey guys would anyone be able to help me? I'm getting an error when I try and run sudo pbuilder create
<sladen> merlin371: probably more luck if you paste (pastebin) the error message :-)
<merlin371> :D
<merlin371> E: Failed getting release file http://ppa.launchpad.net/qbzr-dev/ppa/ubuntu/dists/natty/Release
<merlin371> E: debootstrap failed
<merlin371> that's what I get
<tkamppeter> OdyX, great. I like this. This perfectly overcomes the conflict between PPD updater and non-CUPS spooler support in Debian.
<tkamppeter> OdyX, thanks for working on this.
<OdyX> tkamppeter: actually, it's probably a damn simple patch as almost everything is already in CUPS's postinst.
<OdyX> (if we accept updating "all" queues' PPDs at any driver upgrade, but I think that this is sustainable (and safe))
<tkamppeter> OdyX, to check whether a driver package should trigger the update, the packages are all which contain *.ppd files under /usr/share/ppd and/or /usr/share/cups/model, files in /usr/share/cups/drv and/or files in /usr/lib/cups/driver. In addition it should be possible to manually mark a package as a printer driver package so that it triggers a PPD update.
<tkamppeter> OdyX, every update of any printer driver package should trigger a PPD update then.
<OdyX> tkamppeter: my strategy was just to trigger a CUPS "update all your queues' PPDs" whenever another package touches anythin under /usr/lib/cups/filter or /usr/lib/cups/driver
<RAOF> merlin371: Why is it trying to grab a PPA during debootstrap?
<RAOF> merlin371: Also know as: stop doing that :)
<sabdfl> our number
<sabdfl> erk
<merlin371> RAOF I really dont know :P
<RAOF> merlin371: How are you calling pbuilder?
<merlin371> sudo pbuilder create
<RAOF> merlin371: Pastebin your ~/.pbuilderrc?
<merlin371> it's just one line http://pastebin.com/Jf5h5TGR I added what was said on the tutorial :)
<RAOF> Hm.  And /etc/pbuilderrc?
<merlin371> http://pastebin.com/eCbKY025
<merlin371> I'm guessing that's the problem?
<merlin371> what mirrorsite should I use on it?
<tkamppeter> OdyX, you need change this strategy a little bit: The update should be triggered if anything under /usr/lib/cups/driver, /usr/share/cups/drv, /usr/share/ppd, /usr/share/cups/model, or /usr/share/foomatic is touched. All this influences PPD files.
<OdyX> tkamppeter: reasonably easy; I'll put my level-0 patch to the bugreport within the hour.
<tkamppeter> OdyX, it is also needed to mark binary packages manually as needing a PPD update after installation, as it can happen that the data on which the PPDs are based are in another binary package than the executable in /usr/lib/cups/driver.
<OdyX> tkamppeter: the trigger always happens at the end of the installation process, so that should be OKay.
<tkamppeter> OdyX, important is that one can mark packages manually when one creates them that they need the trigger.
<OdyX> tkamppeter: I don't understand why: if one package installs / upgrade a file under any of those directories, then the trigger will update all queues.
<RAOF> merlin371: Just remove the mirrorsite and it'll use archive.ubuntu.com
<tkamppeter> OdyX, imageing that package A installs an executable /usr/lib/cups/driver/A and this executable supplies PPDs to CUPS based on data in /usr/share/A. Now a printer driver package B puts data files into /usr/share/A in order to get its PPDs supplied via /usr/lib/cups/driver/A. Now let us have an update which only updates B and not A. This should also trigger the PPD update.
<merlin371> ya it's working now RAOF thanks :)
<OdyX> tkamppeter: if B puts a file into /usr/lib/cups/driver, it'll be OK.
<tkamppeter> OdyX, so we must tell to packagers that every printer driver package which needs a PPD update has to put a file into the said directories. If it does not need so for itself to work, it should simply put a zero-byte dummy file.
<OdyX> tkamppeter: wellâ¦ for a driver to be recognised (and used) by CUPS, doesn't it already have such a requirement ?
<tkamppeter> OdyX, principally yes and as AFAIK all current driver poackages have at least one file in the appropriate directories..
<OdyX> tkamppeter: I sent the patch to the bug, it "works here", but is certainly imperfect.
<OdyX> tkamppeter: what will be needed at "postinst removal" time on the driver packages is to add a versioned Breaks on cups, to ensure proper upgradeability.
<tkamppeter> pitti, OdyX is introducing an infrastructure to eliminate repeated code in the postinst files of printer drivers. Should this go into Oneiric or wait for P.
<pitti> tkamppeter: the patch should be rather easy, just re-run the configuration for a trigger
<pitti> this seems fine for me for oneiric
<pitti> all of the actual code is already happening after all
<OdyX> pitti: said patch is on the bug: http://bugs.debian.org/637978 .
<ubottu> Debian bug 637978 in cups "cups: Please add a dpkg trigger to update PPDs on driver upgrades" [Wishlist,Open]
<tkamppeter> pitti, OK, then if the appropriate CUPS is up, I will remove the code from the postinst files of the drivers.
<OdyX> tkamppeter: I'm available to coordinate this trough Debian unstable: I propose we do the updates on the Debian side and "just" sync to Ubuntu.
<pitti> OdyX: thanks, that looks fine
<pitti> 1.4.8 moved to testing, so I'm fine with uploading 1.5.0-2 to unstable now
<OdyX> pitti: I dislike the '.*' regex as it creates a 14'000 lines file in /tmp, but I couldn't find my way around it.
<tkamppeter> OdyX, why the '\' before the '.', does this not make the regexp matching only URIs beginning with any number of '.'s (which are all, as zero '.'s is included). Would it not be more intuitive to have the regexp empty or ".*"?
<OdyX> tkamppeter: shell escaping. Otherwise the ".*" gets transformed as ".gitrc .bashrc â¦"
<OdyX> (well at least here it was needed)
<tkamppeter> OdyX, another problem is that the drivers used individual regexps to assure that PPDs get only updated with PPDs of the same driver (and flavor of the driver like HPLIP and Gutenprint have IJS and CUPS Raster drivers). The regexps also overcome weird nickname changes between driver versions.
<tkamppeter> OdyX, so what we really need is that the drivers deliver their individual regexps but the code for the update is centralized.
<OdyX> tkamppeter: I thought about that, yeah. And feared it would be necessary.
<OdyX> tkamppeter: idea: cups triggers on any file in /usr/lib/cups/driver/regexes/ and drivers put their regex in those files: /usr/lib/cups/driver/regexes/${package}, which the trigger then reads.
<tkamppeter> OdyX, so the CUPS package could deliver the code in a script which takes two (optional) parameters (the regexps). But we must do all these script runs at the end of the installation, in the trigger stage, to assure that for a CUPS user CUPS is running.
<OdyX> tkamppeter: then use my "cupsppdupdate" (just a dump of the postinst): http://anonscm.debian.org/gitweb/?p=collab-maint/pkg-printing-tools.git;a=blob;f=cupsppdupdate/cupsppdupdate;h=dadc19a658904830122a72b54958f99f58118e99;hb=HEAD
<OdyX> it even has a manpage.
<tkamppeter> OdyX, OK, but let us use /usr/share/cups/regexps, as once the regexps are not executable programs (so they do not belong into /usr/lib) and second, /usr/lib/cups/driver/ should not get a subdirectory.
<OdyX> sure. I picked a random name.
<OdyX> make that "driver-regexps", to be fully clear.
<tkamppeter> OdyX, let us improve the name: /usr/share/cups/ppd-updaters
<OdyX> tkamppeter: As it's your code, are you going to implement it in cups or do you need me to provide patches ? (I can do it, it's just a matter of not doing things twice.)
<tkamppeter> OdyX, and note that there are two regexps, do not hardcode gennicknameregexp to empty.\
<OdyX> tkamppeter: I mostly copy-pasted this from rastertosag-gdi's, feel free to make it even better.
<tkamppeter> OdyX, as you are already on it, provide me the patch. Please base it on the current HEAD, which is 1.5.0 (probably in experimental).
<OdyX> tkamppeter: okay. Will prepare somethin.
<tkamppeter> OdyX, you can base the trigger on files in /usr/share/cups/ppd-updaters/ then. A PPD update without regexps does not make sense, as updating all queues easily leads to switches to an unwished driver.
<OdyX> tkamppeter: opinions on rleigh's answer on the bugreport ?
<fish_> hi
<fish_> just a question: is there something special on natty's libc related to getaddrinfo? (no, I don't want support but it looks like I've found a "bug" or feature or something forcing getaddrinfo to lookup dns instead of /etc/hosts
<Daviey> fish_: best thing to do would be to raise a bug, with a minimal code example - and output on natty, and maverick - showing the difference.
<fish_> Daviey: well, I don't have a maverick here right now.. but i'll open a bug with code example and output on natty vs debian/testing
<Daviey> fish_: That sounds great!
<tkamppeter> OdyX, I have answered Roger's question now.
<fish_> Daviey: ah damn... shame on me *facepalm*.. soo stupid typo.. hostname was 'apollo' but hosts entries apollon... ;)
<Daviey> fish_: heh.. at least you caught it :)
<fish_> yeah, but kind of frustrating to spend so much time on a so stupid typo ;)
<cjwatson> tseliot: could you please look at the fglrx-installer part of bug 827046?
<ubottu> Launchpad bug 827046 in fglrx-installer (Ubuntu) "package grub-gfxpayload-lists 0.2.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/827046
<tseliot> cjwatson: sure, I'll investigate the issue. Thanks for reporting
<cjwatson> uploading the workaround now
<cjwatson> thanks
<tseliot> thanks
<OdyX> tkamppeter: Too bad: dpkg-triggers only launches â¦/postinst triggered /usr/share/cups/ppd-updaters
<OdyX> tkamppeter: that means I don't know which package got updated.
<Daviey> smoser / cjwatson / stgraber : is bug #759545 likely to be addressed for Oneiric?  Thanks
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Oneiric) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<tkamppeter> OdyX, we must somehow do one run of the ppd-updater in the end of the installation process and if there are no traces of which packages got actually updated, we must do updates on all regexp files in /usr/share/cups/ppd-updaters. To make it not too slow we must run "lpinfo -m" once and use this output for all updates.
<tkamppeter> OdyX, perhaps we can determine by file change dates which packages got replaced with the current update and which not?
<OdyX> tkamppeter: that means maintaining states for those, I don't want that.
<OdyX> tkamppeter: "run lpinfo -m" once means having that not in a separate script, but all in the postinst (I can do that actually, not hard).
<cjwatson> Daviey: not from my side
<doko> Sweetshark, hi, any reason for not building lo in the libreoffice ppa?
<cjwatson> I'd take patches but it's a horrible rathole of a bug and IMO attempts to fix it have a very high propensity to go wrong
<Sweetshark> doko: -l10n needs translate-toolkit-1.9 and that seems to be a bit messy repository-wise on our side.
<doko> Sweetshark, what's the issue with translate-toolkit, if we do not import the translations, or do we?
<Daviey> cjwatson: it uses ucf, right?
<cjwatson> Daviey: sort of, it's a mix of ucf and manual handling
<cjwatson> which is why it's a pain
<Sweetshark> doko: I trying a build without translate-toolkit which would work hopefully, but I wanna see a successful local build first.
<doko> Sweetshark, comment out the export-gsi target
<Daviey> cjwatson: I'll see if smoser has any thoughts, it's really quite ugly at the moment.. but don't want to do more damage trying to fix it! :)
<OdyX> tkamppeter: okay, I'm done. Pushing the patch to the bug in secondsâ¦
<OdyX> tkamppeter: http://people.debian.org/~odyx/tmp/04dde8d6a3f412b3e6b1d3a36e8bae06/cups-triggers_1.5.0-1.1.debdiff fyi.
<tkamppeter> OdyX, great, thank you. I will look into it.
<doko> Processing 8 changed doc-base files...
<doko> Errors were encountered while processing:
<doko>  /var/cache/apt/archives/gstreamer0.10-camerabin_0.10.22-2ubuntu2_amd64.deb
<doko> Error in function:
<doko> SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)
<doko> ev: ^^^ there seems to be a replaces missing
<mvo> james_w: hello! do you have a advice for me? I'm trying to build a tree with a "flat" debian directory, i.e. instead of debian/changelog just changelog. it used to be possible to do this with bzr-buildpackage in --merge mode, but now its no longer. any hints for me how to make it work again?
<mvo> james_w: fwiw its lp:~vmbuilder-dev/vmbuilder/packaging
<ev> doko: okay, thanks
<mvo> hallyn: hi, I would like to do a new release of ubuntu-vm-builder but bzr-buildpackage is rather unhappy, do you have any preferences about how the package should be build? I would like to move it to a bzr-buildpackage configuration, it will require a working vcsversion.py, not sure yet how that is generated. or what method did you used in order to create the source package?
<hallyn> mvo: <thinking>
<mvo> hallyn: if you don't have any preferences, I would simply move the packaging into a new debian/ subdir
<hallyn> mvo: I guess i just stick the packaging dir in there by hand for each build
<mvo> hallyn: and generate the vcsversion.py via a bzr-buildpackage build hook
<hallyn> that is, lp:~vmbuilder-dev/vmbuilder/packaging under lp:vmbuilder
<Daviey> mvo: Hmm, what are you doing with it exactly>
<Daviey> ?
<hallyn> mvo: that's fine with me, though.  Please go ahead and document the new workflow somewhere.
<mvo> Daviey: fixing it enough so that it can generate oneiric images
<mvo> hallyn: sure, I will create a debian/README.source
<hallyn> mvo: thanks!
<Daviey> .. we were thinking of dropping it from the archive soon.. because nobody is maintaining it.
<mvo> hallyn: but the idea is that bzr-buildpackage will be enough, nothing else
<mvo> Daviey: I know and yet livebuild is not (yet) a replacement IMO, at least last I checked it was not at all trivial to build a vm image with it
<mvo> Daviey: and honestly I think we need to have something as simple as "whatever build kvm oneirc"
<hallyn> yeah, I'm rather using 'vm-new -t mini' as a replacement
<hallyn> mvo: bzr-buildpackage from vm:vmbuilder ?
<Daviey> hallyn: vm-new ?
<mvo> hallyn: from the packageing checkout
<mvo> hallyn: so what do I need to install to get vm-new :) and will it be able to genertate images for older distro releases as well (I assume so, right)?
<hallyn> Daviey: vm-tools - see https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment
<hallyn> mvo: yup, shoudl work for all releases.  That's a requirement for security team
<mvo> eh, if I have to do all the 5 steps and create this textfile in ~ I think we are not quite there yet
<hallyn> coudl be, but if there will be wider useage perhaps we cans mooth that out
<hallyn> s/cans mooth/can smooth/
<mdeslaur> mvo: would you like a python gui as well? :P
<mvo> I mean, no offense, but I'm really impatient and for me this is a tool
<mvo> mdeslaur: no, just "vm-new kvm oneiric" or whatever synatx after I installed it
<mvo> no exports, no textfiles
<Daviey> mvo: Yeah, it was just on my todo to raise an archive removal request this week. :)
<hallyn> Daviey: jinkeys.  i thought we were waiting for 12.04 to actually pull it
<mvo> I think that is too early, IMO we need at least document what replaces it
<mdeslaur> vm-new --mvo-mode kvm oneiric
<mdeslaur> :)
<mvo> mdeslaur: yeah vm-new --auto kvm oneiric ;)
<hallyn> Daviey: note that vm-builder should mainly still work!  We just don't want to be maintaining all the little corner cases that break.
<mvo> mdeslaur: no offense, I think this is all wonderful work, but this last bit for just works(tm) is missing ;)
<hallyn> mvo: mdeslaur: i'd like to find some time to smooth some of that out and maybe make a package of it
<Daviey> hallyn: I hit a corner case everytime i use it :)
<hallyn> Daviey: you *are* a corner case
<Daviey> thanks. :)
<hallyn> ok well then maybe i shoudl bump priority of productizing vm-tools?
<hallyn> note it's still not a full vmbuilder replacement as it requires running qemu/kvm...
<Daviey> well rather that than reinventing d-i :)
<mdeslaur> I'm not sure vm-tools is something that ought to be a package or a product
<mdeslaur> it's a 2000 line bash script full of workarounds and hacks
<Daviey> mdeslaur: Does it support foreign arches btw?  armel on amd64 host?
<mdeslaur> It's not a vmbuilder replacement...it's just some scripts that we use to help us create vms
 * Daviey makes a mential note that this really needs clarification at the next UDS with what we are doing.
<mvo> heh :) I will just go ahead and do my tiny tiny fix for vmbuilder to make it create oneiric VMs, I'm not attached to it in any way, but I need something like this that is so simply that even I can use it
<hallyn> mdeslaur: hm.  but don't you think that sort of thing always will necessarily be so?
<Daviey> echo mvo > vmbuilder-maintainers.list
<hallyn> mdeslaur: always have to deal with little per-distro/per-release special cases, as well as local mirroring/network context?
<hallyn> anyway, i'll wait then :)
<mdeslaur> hallyn: yes, but I don't think a 2000 line bash script is the way to handle it...package it if you want, but you'll be spending all your time SRUing fixes to it
<mdeslaur> updates break it, new releases break it, etc.
<mdeslaur> ironically, it's not a vmbuilder replacement...it used to be a wrapper _around_ vmbuilder :P
<Daviey> hallyn: /usr/bin/vm-tool could just be a wrapper to wget from http://people.ubuntu.com/~mdeslaur/vm-tool and exec as root. Seems clean enough to me :)
<hallyn> yes, but most bug reports for vmbuilder didn't come from vm-tools users :)
<hallyn> cause it had fewer options.
<mdeslaur> Daviey: there you go! +1
<mdeslaur> hallyn: right...so what we need then is a vmbuilder replacement that only uses command line opts, and then modify vm-new to use that replacement to add all our hacks and customizations
<hallyn> well, one coudl argue that we spend enough time maintaining an installer that requiring users to set up their own pre-seeded install isn't unreasonable
<hallyn> mdeslaur: let's have Daviey write it :)
<mdeslaur> hallyn: ah! sounds like a plan :)
<Daviey> Hmm.
<Daviey> I'll write it in go.
<mdeslaur> Daviey: there you go, and you'll win a prize :)
<hallyn> Daviey: \0/
<hallyn> (i'm an alien, i always have a big head)
<mdeslaur> maybe testdrive is the tool that should be used
<hallyn> it doesn't actually install
<Daviey> heh.. smoser and perhaps RoAkSoAx was quite keen for cobbler/koan to be considered for a replacement
<hallyn> do they have a prototype?
<Daviey> RoAkSoAx did show me how easy it could be with koan.
<mdeslaur> yes, I actually started to try and get koan working and packages
<mdeslaur> but I lost patience and added preseeding to vm-new instead
<mdeslaur> but koan would be a lot better at a package app than a 2000 line bash script
<hallyn> RoAkSoAx: ^ if you've been advocating it as a replacement, do you have something close to a package providing a cmd-line tool that can be tried out?
<hallyn> Daviey: uh, now, you're uploading gtk-vnc with sbeattie's fix right?
<Daviey> yes sir!
<hallyn> Daviey: thanks :)
<smoser> imo the right way to build vms is via network or cd boot
<smoser> which is waht koan does, but which can also be fairly easily done without cobbler requirement
<smoser> see my 'cobbler-devenv' and the way it builds a reproducible image
<smoser> the one nasty thing in it is that it ahas to extract the initramfs and gues at the command line parameters that would be set by syslinux
<smoser> imo the right way to fix *that* is to have the installer optionally read a seed file off a LABELed disk.
<smoser> then we'd just attach a second ISO or floppy disk that had a preseed in it it and a label named "PRESEED" on the filesystem.
<smoser> and boot the Cd
<hallyn> smoser: yes, that's how the new mini type for vm-new works
<hallyn> I nabbed that idea+code from yours :)
<hallyn> works very nicely
<smoser> and no root!
<smoser> but really, we need more cooperation from the installer
<smoser> parsing syslinux is no fun, and changes every release.
<Daviey> smoser: you and your care for non-root...
<hallyn> don't you run everything as root anyway?
 * hallyn loads up a flash website
<smoser> oh, i like root, and i like the fact that i have root on just about every machine Daviey touches.
<smoser> :)
<Daviey> heh
<mdeslaur> hallyn: btw, I still haven't merged your mini iso stuff in, I was trying to get virt-install to use a initrd without rebuilding the iso
<mdeslaur> hallyn: but haven't succeeded yet
<RoAkSoAx> hallyn: sudo apt-get install koan :)
<RoAkSoAx> hallyn: https://help.ubuntu.com/community/Cobbler/Deployment#Deploying via koan
<RoAkSoAx> hallyn: and yes smoser's cobbler devenv is also pretty cool
<RoAkSoAx> hallyn: btw.. SRU's version on changelog's are like (if changelog is ubuntu2 then SRU is ubuntu2.1)
<hallyn> RoAkSoAx: my understanding was that that's only needed if the next release has ubuntu3, but not if it switched to a whole new version
<hallyn> but in any case yeah i did notice i didn't do that in the other debdiff.
<hallyn> but since i've deleted that, you can all just STEP OFF!  :)
<hallyn> all right time to figure out wtf is going on with libvirt+cgroup-bin
<RoAkSoAx> hallyn: but I should proceed with the SRU's right?
<hallyn> RoAkSoAx: the ones i asked about yesterday?  yes please
<RoAkSoAx> hallyn: cool. Looking at them right now ;)
<dobey> pitti: ping https://bugs.launchpad.net/ubuntu/+bug/817133/comments/13 :)
<ubottu> Ubuntu bug 817133 in Ubuntu "[FFe] [needspackaging] ubuntuone-installer needs packaged" [High,New]
<RoAkSoAx> hallyn: uploded!
<hallyn> RoAkSoAx: thanks!
<hallyn> RoAkSoAx: i may have to submit another upload soon-ish :(  think we need a cgrulesengd policy for libvirt.  not sure yet
<RoAkSoAx> hallyn: ok, just let me know ;)
<hallyn> jbernard: hey, do you have a sec?
<hallyn> jbernard: i have a cgrules.conf entry:
<hallyn> root:libvirtd   *               libvirt/
<hallyn> but libvirt only ended up in cpu:libvirt, but is in devices:/sysdefault (and sysdefault for all the others)
<hallyn> just wanna make sure i'm not doing something wrong with the entry
<hallyn> well this must be a bug
<hallyn> meh.  perhaps we want the default libcgroup install to run cgrulesd but NOT cgred
<hallyn> smoser: ^
<hallyn> smoser: have you tried running '/usr/sbin/cgrulesengd -v -d'?  every task create causes that thing to work
<hallyn> maybe they should be split up into two packages
<hallyn> well, that's for later i guess.  fix the bug first
<smoser> hallyn, i think libvirt works fine
<smoser> its cgroups-bin that is the issue
<smoser> its not starting before libvirt and then libvirt has to be restarted and 'restart libvirt' doesn't funciton
<hallyn> smoser: no
<hallyn> smoser: yes cgroups-bin is the issue.  but just bc it reclassifies libvirt under /sysdefault
<hallyn> it *has* to start before libvirt.  we have upstart enforcing that
<hallyn> well, ok
<hallyn> what you point to is the better fix, but it's a fix in libvirtd!  it should be able to handle having its cgroup changed
<hallyn> i.e. it starts in '/', then cgred gets aroudn to reclassifying it
<mterry> Does anyone know why installing devscripts ends up asking a dpkg question about postfix setup?  (I understand the dependency tree, but I'm curious if there's a good reason we need to keep doing this...)
<mterry> cjwatson, seems like you would know ^^
<cjwatson> I do not
<cjwatson> try lamont
<mterry> cjwatson, thanks!  lamont, consider yourself asked  :)
<infinity> mterry: Are you asking why postfix asks debconf questions, or why devscripts is pulling it in?
<mterry> infinity, devscripts->bsd-mailx->default-mta->postfix  is the chain I think
<mterry> infinity, I guess why it should ask debconf questions
<infinity> Because an MTA that asks no questions ends up being nearly useless.
<infinity> When we shipped one by default, we used to go questionless, and people complained because it was neutered (it had to be to not have open ports).
<hallyn> smoser: (honestly, it doesn't quite make sense to me.  the code seems to do the right thing.  this shouldn't be happening)
<infinity> When we moved all the m-t-a deps to recommends, we un-neutered postfix.
<infinity> And I suppose then things went pear-shaped with install-recommends-by-default, where people now get asked questions sometimes, but... It beats typing "apt-get install postfix" and ending up with something that doesn't actually work as an MTA.
<mterry> infinity, I'm looking at making the fresh-to-Ubuntu-packaging experience easier, and the dpkg question seems to be a point of pain.  I'm trying to see what could be done to make that easier/go away
<infinity> --no-install-recommends will make it go away. :P
<tkamppeter> OdyX, I have tested your patch and added it to Debian's BZR repo of CUPS now.
<OdyX> tkamppeter: yay. Did you need to change stuff ?
<tkamppeter> pitti, can you upload the CUPS package to Debian and Ubuntu? Thanks.
<mterry> infinity, bsd-mailx is used for 'bts', 'mass-bug', and 'pts-subscribe' devscripts.  I assume those are all useful enough that we couldn't tweak them or move them to a suggested package or something?
<tkamppeter> OdyX, no, worked out of the box. I have tested by updating rastertosag-gdi appropriately.
<infinity> mterry: mailx itself is already suggested...
<infinity> mterry: But perhaps in a recommends chain from another recommends?
<Laney> mterry: install another mta explicitly such as nullmailer, then you won't get postfix at all
<infinity> That's an option, sure.
<mterry> Laney, hm
<mterry> infinity, bsd-mailx is in the recommends for devscripts, not suggests
<infinity> I dunno.  Call me crazy, but if people can't answer a debconf prompt, or figure out how to install another MTA to avoid a dependency, their packages will frighten me. ;)
<mterry> infinity, :) actually, I'm coming at this from the "quickly" side, where the tool is doing the packaging for the user
<mterry> infinity, so I'm targetting a pretty packaging-leery audience that doesn't want to see such questions
<infinity> Suggests: bsd-mailx | mailx
<infinity> mterry: Which version are you seeing that as a recommends?
<OdyX> tkamppeter: by re-reading the patch, I think we should put the lpinfo -m in a if [ "$1" = configure ] || [ "$1" = triggered ]; then â¦; endif to not launch it in other cases.
<Laney> infinity: appears to be recommends on natty
 * infinity is curious when that changed.
<Laney> git blaming now
<mterry> infinity, 2.10.69ubuntu2
<mterry> infinity, in oneiric
<Laney> grr, wrap-and-sort
<infinity> Anyhow, that's probably the "correct" solution for us, going forward.
<Laney> http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commit;h=563f6ae2376c852c22d5a960ff1a4547ac33973b
<infinity> Neutering postfix for the sake of an odd use-case of "devscripts being used by people who don't understand what devscripts is for" seems odd to me. :P
<jtaylor> barry: there is a minor problem with the m2crypto upload, it accidentally patches the removed file back in and one of the patches include to seperate fixes
<jtaylor> barry: the former is not really a problem, as the file was confirmed as free by the author, the latter would be nice for the future merge in P
<pitti> tkamppeter: ah, thanks for committing the patch
<barry> jtaylor: can you submit a bug report on it?
<jtaylor> should I fix it?
<jtaylor> no functional change so no exception necessary
<barry> jtaylor: that would be great; happy to sponsor it
<mterry> infinity, ok, I can look into why it is now a recommends instead of a suggest and maybe it's a revertable change...
<infinity> mterry: Err.  No, it's now a suggests.  It *was* a recommends.
<infinity> mterry: As in, this is fixed in unstable and oneiric.
<jtaylor> barry: not sure if I should remove the unintentional adding of the file, as there is an allowance by the author to distribute it, maybe just add a notice to the patch?
<barry> jtaylor: good question.  ScottK might have some input on that.  if there's some definitive reference for its free-ness, adding that to the patch and leaving the file included should be okay i think
<mterry> infinity, guh, I'm using two laptops, one oneiric and one natty
<mterry> infinity, looking at natty, but mentally thinking oneiric, because that's where my chat is
<mterry> infinity, ok, awesome
<infinity> Okay, this is really starting to irk me: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
<barry> bdmurray: ping
<barry> (might be too early for you tho)
<bdmurray> barry: not if I'm in London (which I am)
<barry> bdmurray: ah! cool. do you have a few minutes to talk about launchpad bugs?
<bdmurray> barry: yes
<barry> bdmurray: i'll go to pvtmsg
<pitti> tkamppeter: uploaded
<tkamppeter> pitti, thanks.
<OdyX> yay, thanks !
<pitti> OdyX: thanks muchly
<mdeslaur> cyphermox: any idea on how to get evolution to not segfault on startup now that I've updated to oneiric?
<OdyX> Now it's time to update all drivers to use that. Yay.
<seb128> mdeslaur, run it in gdb?
<seb128> (that does it for me)
<mdeslaur> seb128: nope, no dice :(
<cjwatson> Laney: ah, I missed the existence of syncpackage -d, thanks
<Laney> np
<tumbleweed> and I was just about to file a sync request for ubuntu-dev-tools... :)
<Laney> NEVER AGAIN!
<jamespage> doko: are you tagging Java on ARM related bugs in any way?
<kirkland> hallyn: Daviey: just read a little of the above conversation;  cobbler+koan is *very* slick for that
<doko> jamespage: jamvm
<doko> cjwatson: where can I find the usb images?
<cjwatson> doko: nowhere yet, I'm to sort them out this week
<doko> cjwatson: are these a subset of the dvd images, or is there something more installed?
<dobey> pitti: replied on bug. sorry for all the confusingness of it all. :)
<cjwatson> doko: they should end up being roughly a subset
<mdeslaur> cyphermox: hmm...I think doing dpkg -P evolution-webcal fixed it
<hallyn> kirkland: can it be reduced to a single command line tool to create any supported ubuntu release?
<mdeslaur> cyphermox: or one of these: dpkg -P libecal1.2-8 libebook1.2-10 libebackend1.2-0 libebook1.2-8 libedata-book1.2-8
<kirkland> hallyn: hmm, good question;  with the right preseed, yes, i don't see why not
<kirkland> hallyn: poke RoAkSoAx, as he's really deft at it
<hallyn> we have, i think it's on his brain :)
<hallyn> thanks
<Laney> cjwatson: do you mind if i sync mono or would you still like to reserve it to test?
<Ursinha> kenvandine: hey, now I understand what you said yesterday :)
<cjwatson> Laney: could I still reserve it just for a bit longer, I'd like to test that fix
<Laney> yep
<cjwatson> Laney: hm, I notice that BaseWrapper has a __call__ method that's return self._lpobject
<Laney> you could actually do the sync if you want, I've got to walk home now
<cjwatson> Laney: do you think that violates encap too?
<cjwatson> I sort of agree that at least the bare copyPackage method probably ought to be done in lpapicache, so that callers just see Archive wrapper objects, though
<Laney> I see why it can be pragmatically useful, but I'd prefer to keep stuff in ubuntutools as far as possible
<Laney> like I say, don't block on that though â we can do it later
<cjwatson> I'm doing it now anyway :)
<cjwatson> seems like a very odd use of __call__
<Laney> indeed
<Laney> I wonder if it's made use of anywhere
<cjwatson> hard to tell ...
<Laney> sadly
<Laney> silly dynamic languages :-)
<Laney> anyway, back later
<tkamppeter> kees, hi
<kees> tkamppeter: hello!
 * doko hides from the colord fight ...
<kenvandine> hey Ursinha
<tkamppeter> kees, I have seen your answer. So we must see whether Richard Hughes (or RAOF) can improve the situation, otherwise we need to skip the Blueprint over to P and give Richard six months to improve colord.
<tkamppeter> kees, the inserted media case is already covered by one of Richard's patches. RAOF could include it in the package.
<ahasenack> hi guys, are there some guidelines somewhere about using dh_python2 in ubuntu? Or should I just follow the debian guides?
<micahg> ahasenack: http://wiki.debian.org/Python/TransitionToDHPython2?action=show&redirect=Python%2FPythonSupportToDHPython2, conversion needs an FFe though
<ahasenack> micahg: FFe for what, oneiric?
<micahg> ahasenack: yeah, the change probably shouldn't happed for anything before
<micahg> *happen
<ahasenack> micahg: ok, thanks
<ahasenack> micahg: I'm playing with a ppa first, and this package isn't in ubuntu
<micahg> ah, ok, well have fun then :)
<ahasenack> nor debian
<ahasenack> micahg: is there a doc for starting from scratch with dh_python2? That one is about converting existing packages
<ahasenack> I guess man dh_python2
<ahasenack> or the instructions about packaging python apps, let me search for that
<slangasek> from scratch:  %:\n\tdh $@ --with=python2\n^D
<slangasek> by default, it should all DTRT
<ahasenack> I meant a debian/rules file, not /etc/sendmail.cf
<ahasenack> :D
<slangasek> hah
<slangasek> %:
<slangasek>    dh $@ --with-python2
<slangasek> :P
<ahasenack> much nicer :)
<ahasenack> ok, I will have to work a bit here, as this package has to build on hardy, lucid and all the rest that is still supported
<slangasek> ah
<slangasek> well, backporting dh_python2 for lucid is a todo for this cycle still
<ahasenack> I have lots of ifneq (,$(findstring $(dist_release),"hardy")) type of things in this rule file
<slangasek> but backporting it to hardy isn't in the cards; the python upstream support isn't there that far back
<ahasenack> and the other releases
<ahasenack> sure
<jtaylor> --with python no hyphen
<jtaylor> s/python/python2/
<dobey> ScottK: do the last few comments on bug #817133 help any? or you need more clarification?
<ubottu> Launchpad bug 817133 in Ubuntu "[FFe] [needspackaging] ubuntuone-installer needs packaged" [High,New] https://launchpad.net/bugs/817133
<slangasek> jtaylor: er, yes; I meant --with=python2, sorry
<slangasek> you know, I would swear flashplugin is eating less CPU now that I've removed ia32-libs
<micahg> slangasek: is flashplugin-installer using the multiarch libs now?
<slangasek> micahg: all the libs necessary to cross-install flashplugin-installer are multiarched
<slangasek> micahg: so you need only run 'apt-get install flashplugin-installer:i386'
<micahg> slangasek: can we switch the amd64 version to use the multiarch 32 bit libs?
<slangasek> micahg: no; what we can do is drop the amd64 package from the archiv
<slangasek> e
<micahg> slangasek: why wouldn't we want to have it displayed as an option to install for people? (or does flashplugin-installer:i386 show up in software center)?
<slangasek> micahg: i386 packages will show up just fine in software center
<slangasek> and "want to have it displayed" is not the issue - the issue is that we don't support specifying "this package of arch x depends on that package of arch y"
<slangasek> you can only say "arch needs to match" or "arch doesn't need to match" - so it has to be an i386 package to ensure the correct i386 libs are pulled in
<micahg> slangasek: also, don't we still need the nspluginwrapper depends for it?
<slangasek> I'm working on that part
<micahg> ok
<jbicha> Adobe just needs to hurry up and release Flash Player 11 for 64bit
<slangasek> they did that once before; it wasn't very good
<slangasek> well, not 11
<slangasek> other numbers
<jbicha> it was never an official release, just an unsupported beta right?
<slangasek> yes
<micahg> slangasek: does multiarch installation work against partner as well or just the main archive?
<jbicha> I'm using Flash 11 64 from sevenmachines' PPA
<slangasek> micahg: works fine with partner; I have skype:i386 installed right now, and have tested adobe-flashplugin:i386
<micahg> slangasek: very cool, so once you get the nspluginwrapper bits fixed, we can just drop flashplugin-installer entirely
<slangasek> hmm, really?
<slangasek> I didn't realize that was the only reason it was around
<micahg> yeah, flashplugin-installer is just a wrapper to handle the nspluginwrapper bits
<ricotz> slangasek, hello, could you get gnome-menus NEWed?
<slangasek> ricotz: there are an awful lot of packages in the NEW queue ahead of it; is there some particular reason gnome-menus is needed right now?
<ricotz> slangasek, hmm sorry, i would like to update the gnome-shell snapshot which already depends on it
<ricotz> slangasek, i was hoping pitti would get to it, but he called it a day already ;)
<slangasek> ricotz: I'll have a look at cutting down the NEW queue, but it's first come first serve :)
<ricotz> slangasek, no problem, thank you
<slangasek> bdmurray: is there a sensible way to write a bug pattern to trap the duplicates listed on https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bugs?field.searchtext=upgrade+134 ?  (The error code is not enough to identify them as duplicates, we should examine the backtrace in the term.log...)
<micahg> Laney: did you use th new script to sync mono?
<Laney> yap
<micahg> so, it's not doing the equivalent of -vUBUNTU_VERSION, I'm just wondering if this is a known issue
<Laney> just filed it
<slangasek> ScottK: still waiting for Debian feedback on bug #825689?
<ubottu> Launchpad bug 825689 in qt4-x11 (Ubuntu) "libqt4-dbus: contains an executable in /usr/bin, breaks multiarch, Policy 8.2" [Medium,New] https://launchpad.net/bugs/825689
<slangasek> ScottK: provided that no one can see a reason that qdbus is needed in the -dev package, I'm happy to JFDI
<cjwatson> Laney: I filed that too ...
<Laney> oops
<slangasek> mdeslaur: I've just uploaded a multiarchified nspluginwrapper; I have one outstanding doubt, which is that the internal protocol between npwrapper.so and npviewer.bin has changed since natty, which implies there should be a versioned dependency between the i386 and amd64 parts.  Do you have an opinion on what that versioned dep should be?  Should it just be kept in version lockstep?
<micahg> heh, glad I asked
<Laney> got a number so that I can dupe it?
<cjwatson> ha, adjacent bug numbers!  bug 827576 bug 827577
<ubottu> Launchpad bug 827576 in Launchpad itself "copyPackage only includes changes from upload being copied" [Undecided,New] https://launchpad.net/bugs/827576
<ubottu> Launchpad bug 827577 in Launchpad itself "native sync announcement mails don't show all changes since last version" [Undecided,New] https://launchpad.net/bugs/827577
<cjwatson> I guess yours wins
<Laney> :-)
<micahg> cjwatson: I filed a sponsored sync bug earlier, but yours is more verbose, so I duped mine to yours
<cjwatson> micahg: I had a sponsored sync bug?
<tumbleweed> it looks like "derivation" is the tag to use for copyPackage bugs
<cjwatson> it is
<cjwatson> per bigjools
<micahg> cjwatson: a bug about supporting sponsored syncs
<cjwatson> oh, ok
<mdeslaur> slangasek: multiarchified? oh, you split the package in half? I'm not quite sure I comprehend
<slangasek> mdeslaur: right; so 32-bit npviewer.bin is now in an i386 package, the 64-bit npwrapper.so is in an amd64 package, and the amd64 package depends on 'nspluginviewer' - of which there's only one in the archive, on i386, so the dep gets satisfied via multiarch
<cjwatson> micahg: thanks, I hadn't gone through the full list, on the assumption that since I was writing the client tool I'd be encountering most of the problems for the first time :-)
<slangasek> mdeslaur: so because they're now in two separate packages, there could be version skew unless we specify otherwise; so I'm wondering what to specify
<mdeslaur> slangasek: oh I see...yeah, I'd go with a version lockstep
<slangasek> ok
 * mdeslaur hugs slangasek for killing ia32-libs
<slangasek> trying to kill it
<slangasek> I think I've cut through the skin ;)
<mdeslaur> slangasek: so the ia32-libs package will be empty and will just have depends for whatever it's contents used to be?
<seb128> slangasek, you probable want gtk3 switched to multiarch
<seb128> having gtk2 converted is nice but that one is deprecated ;-)
<slangasek> YokoZar: hi, speaking of killing ia32-libs, I see that there hasn't been much progress on multiarching the stuff that was recently added for wine's benefit.  Do you think you'll have time to work on that sometime soon?  I'm inclined to kill ia32-libs from the archive as soon as p opens
<slangasek> seb128: yes, I would like that... I sighed when I saw it had been added in non-multiarch form :)
<slangasek> though I guess the packaging dates back to maverick, so that makes sense
<seb128> right ;-)
<YokoZar> slangasek: I'll need to see exactly what's missing still
<seb128> it's somewhat on my list but desktop world still has lot of things that need to be done for oneiric
<YokoZar> slangasek: and the state of how much today's wine depends on it
<seb128> so not sure when it will be done, it's rather low on the stack
<slangasek> seb128: yes, and it's probably too late to change that for oneiric; best to do the conversion when p opens
<slangasek> (it's not a blocker for ia32-libs reduction, anyway)
<tumbleweed> cjwatson: hrm I notice debversion isn't validated, and I can file a sync request for a package that launchpad hasn't imported from debian yet
<tumbleweed> ah bug 826850 will take care of that
<ubottu> Launchpad bug 826850 in Launchpad itself "package sync failures should send a rejection email" [High,In progress] https://launchpad.net/bugs/826850
<slangasek> mdeslaur: depends for its contents> nothing nearly so gentle; since we have no way for ia32-libs to say "Depends: libcups2:i386" right now, the plan is to simply cull the contents, and users will need to be sure to upgrade to the oneiric i386 version of the package in question
<slangasek> mdeslaur: so partial upgrades would be broken, and some local packages might be broken - users would have to track down the corresponding i386 package and install that
<slangasek> or resolve the library deps by hand
<mdeslaur> slangasek: I see...I'm just thinking of people downloading something like skype from their website
<slangasek> well
<mdeslaur> slangasek: where they have an amd64 package that pulls in ia32-libs because it actually contains i386 binaries
<slangasek> there's a skype package in partner
<mdeslaur> slangasek: but...meh...
<tkamppeter> I cannot start emacs, I get
<tkamppeter> emacs: symbol lookup error: /usr/lib/gio/modules/libgiozeitgeist.so: undefined symbol: g_desktop_app_info_launch_handler_get_type
<mdeslaur> slangasek: yes, exactly
<tkamppeter> Any workaround?
<slangasek> and since they're a *partner*, perhaps we can encourage them to drop the amd64 .deb
<slangasek> in general, I expect ISVs will be thrilled to not be providing amd64 .debs anymore :)
<slangasek> seb128: btw, I committed a small multiarch fix to gtk+2.0 bzr; should I upload that, or wait until there's another reason to upload?
<seb128> slangasek, if you want to upload feel free but I think doko was looking at starting a rebuilds test so maybe check with him if that's a right time to create instalability issues on some archs around gtk
<slangasek> seb128: does gtk out-of-dateness cause uninstallability?
<doko> well, I don't think so
<doko> today's toolchain builds are all in the archive for amd64/i386
<slangasek> all dependencies on libgtk2.0-common are unversioned, so it should be safe
<seb128> slangasek, it used to, I think it got fixed though
<seb128> slangasek, right, feel free to upload then ;-)
<slangasek> seb128: cool, going
<slangasek> doko: oh, another round of toolchain builds before the test rebuild?
<doko> slangasek: they're done
<slangasek> ok
<slangasek> still thinking to start the test rebuild today?
<Laney> interesting, the Debian uploader gets credited with syncs using the API
<doko> yes
<slangasek> cool... once there are some failure logs I can spend some time hammering on those
<bdmurray> slangasek: I'd think so
<jml> that is a lot of kept-back packages
<jml> upgrade made caps lock stop being a control key :(
<cjwatson> tumbleweed: wouldn't hurt to validate it anyway; I'll take care of that
<cjwatson> Laney: er, they do?  I thought that was fixed
<Laney> credited was probably a bit much, but nobody gets it on +uploaded-packages
<ion> jml: This? https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/740214
<ubottu> Ubuntu bug 740214 in console-setup (Ubuntu) "Keyboard settings reset to X defaults whenever keyboard-config is updated" [Undecided,New]
<cjwatson> Laney: do file a derivation bug then ...
<Laney> did
<cjwatson> ta
<SpamapS> hmm.. so gdal is building without finding libxerces .. despite having --with-xerces and libxcerces-28-dev as a build-dep..
<SpamapS> http://paste.ubuntu.com/667663/
<jml> ion: seems right
<SpamapS> There is the failure from config.log ...
<jml> ion: definitely same symptoms, but so much was upgraded I couldn't swear to same cause
<SpamapS> I notice that -lxerces-c is before conftest.cpp ...
<SpamapS> I've seent his problem before.. but not sure how to correct it
<SpamapS> if -lxerces-c is moved after conftest.cpp .. it works fine
<cjwatson> SpamapS: put -l arguments in LIBS not LDFLAGS during configure
<cjwatson> one of the standard failures with ld --as-needed
<SpamapS> :q
<SpamapS> Heh.. that was me :q'ing the wrong file.. to go try that. :)
<broder> haha, i assumed you screwed up the :p smiley
<SpamapS> double entendre, vim style
<cjwatson> there are pkg-config options that may help IIRC
<ion> jml: Look at the dpkg/apt log. Was keyboard-config updated?
<SpamapS> cjwatson: so it looks like a new m4 macro is in autoconf archive that does it "right" ..
<cjwatson> sounds plausible
<jml> ion: yes
<cjwatson> we're not the only distro using --as-needed after all
<SpamapS> but they changed the name from "with-xerces" to "with-xercesc" .. hrm.
<SpamapS>         saved_LDFLAGS="$LDFLAGS"
<SpamapS>         LDFLAGS="$LDFLAGS $xerces_lib_flags"
<SpamapS> so need to change that to LIBS
<cjwatson> yes
<cjwatson> if you're unlucky you may need to split them
<cjwatson> I did that recently in, er, was it collectd?
<SpamapS> yes
<SpamapS> this one was never found as it just silently moves on w/o xerces support
<cjwatson> nasty
<doko> slangasek: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+builds?build_text=&build_state=failed
<jml> ion: heh, I also can't seem to run the keyboard preferences app either. or logout :\
 * jml does it the old-fashioned way
<slangasek> doko: yay :)
<doko> slangasek: well, business as usual, we don't get any buildds :-(
<doko> I'll rescore ~300 builds before I get to bed
<slangasek> by hand? :/
<doko> script
<slangasek> ok
<doko> currently scoring down all the uninteresting builds
<slangasek> would really be nice to get the default queue balancing fixed
<ScottK> barry and jtaylor: I'd say that since the author confirmed the file was Free, there's no need to worry about it being there (my comments about removing it were from before that was known (at least to me)).
<barry> ScottK: +1
<ScottK> dobey: I think it's clear now.  Thanks.
<jtaylor> k then I'll add the patch to bzr with a comment?
<ScottK> slangasek: I think moving it there for the moment is fine.  I was hoping to get feedback from fabo first though.  Maybe you can ask him?  I don't mind JFDI if he doesn't reply soon.
<slangasek> ScottK: as long as it's just a question of where to move it or whether to drop it, it's easy enough to move it again if needed and I'm happy to do that; I'd just like to get the upload done since it blocks me taking an axe to ia32-libs ;)
<slangasek> anyway, have pinged fabo
<ScottK> slangasek: Let's not block axing ia32-libs.
<RAOF> slangasek: Thinking of ia32-libs - are you able to install libgl1-mesa-glx:i386?
<slangasek> RAOF: well, I appear to *have* it installed... I think libgl1-mesa-dri isn't coinstallable however, due to libdri2+libpciaccess
<slangasek> due to just libpciaccess, rather
<RAOF> slangasek: Yeah, for me it works fine once it's already installed.  But trying to install it fails.
<slangasek> hmm!
 * RAOF should prod #debian-x again on the libpciaccess multiarch branch.
<cjwatson> Laney: I happened to notice that that __call__ method is used in the implementation of Archive.getSourcePackage
<slangasek> RAOF: pastebin the failure?
<cjwatson>                 srcpkg = self.getPublishedSources(source_name=name,
<cjwatson>                                                   distro_series=series(),
<cjwatson> ...
<slangasek> oh, libpciaccess is debian-x, innit?  I should upload that then :P
<slangasek> well, no
<cjwatson> although that's in lpapicache itself so arguably doesn't count
<slangasek> I should fix the xorg copyright file so KiBi doesn't stab me for playing with multiarch ;)
<RAOF> slangasek: http://paste2.org/p/1590026
<cjwatson> Laney: TBH it would be nice for BaseWrapper objects to automatically JSON-serialise to the right thing so that passing them directly to LP API methods just works
<RAOF> slangasek: You're multiarching xorg?
<slangasek> RAOF: oh, that error, argh
<slangasek> RAOF: well, I have Debian XSF commit access, and have push most of the multiarch patches into unstable
<slangasek> RAOF: do you have an up-to-date version of libgl1-mesa-glx installed?
<RAOF> slangasek: Were I to guess, I'd guess that it's because libgl1-mesa-glx Provides/Conflicts/Replaces libgl1, and there's already libgl1-mesa-glx:amd64 providing that package.
<slangasek> RAOF: IME, that error happens because apt is doing something wrong when trying to calculate how to sort out the implicit conflict between $package:i386 $ver and $package !$ver
<RAOF> slangasek: Yes; I've got an up-to-date libgl1-mesa-glx:amd64 installed.
<slangasek> oh, interesting
<RAOF> slangasek: Ah. So you're not multiarching the Xserver, just all the libs and such.  Yeah.
<slangasek> right
<slangasek> I don't see the point in a multiarched X server
<RAOF> Indeed.
<ion> Can one switch an ia32 system to amd64 yet without reinstalling?
<slangasek> ion: only if you hack yourself up a multiarch libbz2 locally :)
<slangasek> cross-grading is not a goal for this cycle
<cjwatson> oh, bah, multiarch libbz2 didn't just happen for us?
<slangasek> not yet
<ion> Multiarch libbz2 is the *only* thing missing for that?
<slangasek> anibal has a few FTBFS bugs in unstable, I guess he's a bit inactive at the moment
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528143 poo
<ubottu> Debian bug 528143 in bzip2 "Add multiarch support" [Wishlist,Open]
<slangasek> ion: actually, we ironically have regressed a bit this cycle because libapt-pkg has been split out into a separate package.. and isn't multiarched :D
<slangasek> but libapt-pkg and libbz2 should be the only ones needed to switch your system's architecture view
<slangasek> once you have apt and dpkg switched, the rest is a simple matter of calculating the upgrade path
<cjwatson> and remember to switch the kernel first :)
<slangasek> hah, yes
<slangasek> well, that's easy enough, won't dpkg fail to configure itself if you don't? :)
<barry> slangasek: tell me there's no chance that setting up multiarch as per your email can break your desktop
<slangasek> barry: there's no chance :-)
<barry> slangasek: okay, back to the drawing board ;)
<slangasek> barry: slow down apt-get update and possibly cause extra warnings if you have any single-arch apt sources enabled, yes; but it shouldn't break the desktop :)
<barry> slangasek: yeah, i really think my desktop was broken by trying to install fglrx, not by enabling multiarch
<barry> slangasek: hopefully the desktop guys will be awake tomorrow, 'cause i'm at a dead end trying to get it working again
<RAOF> barry: Ah, you're here!
<slangasek> oh poo; libedit is FTBFS in the archive rebuild test, and it uses pmake, which is multiarched... which means I have to *un*multiarch libedit as part of the patch if I don't want to deal with the knock-on effects
<slangasek> barry: what's the symptom?
<barry> RAOF: yes!  been having system problems since i tried my little experiment
<barry> slangasek: no dock, no ubuntu menu, no indicators
<barry> slangasek: no app menus
<cjwatson> tumbleweed: I've added validation for the Debian version now
<barry> slangasek: both unity 3d and 2d are hosed
<RAOF> barry: /var/log/Xorg.0.log... and the output of glxinfo would be the price of entry on the debugging train.
<cjwatson> *cough* and really now
<hallyn> jdstrand: are you around by chance?
<hallyn> if so, since you reported it :) would you mind uploading the fix (from debdiff attached) for bug 827279 ?
<ubottu> Launchpad bug 827279 in libcgroup (Ubuntu) "Several problems in cgclear" [Medium,In progress] https://launchpad.net/bugs/827279
<hallyn> jbernard: ^ that bug should be present in debian and every previous release (and upstream) as well - races in cgclear
<hallyn> jbernard: let me know if you want me to file the debian bug
<micahg> hallyn: tab complete failure?
<micahg> oh, maybe not...
<micahg> hallyn: nevermind
<hallyn> micahg: heh, surprisingly no :)
<hallyn> jbernard: holy shnickities, near as I can tell src/api.c doesn't even pretend to parse '*' for controller, which it is supposed to :)
<hallyn> the code just ignores that possibility
<hallyn> bbl
<jono> hi folks
<jono> I just did an upgrade and my X won't start
<jono> is anyone getting this issue?
<jono> RAOF, are you aware of any uploads that break X?
<jono> I tried switching to gdm and gdm could not start either as it was missing a config file
<slangasek> barry: so, that sounds to me like the gnome-session issues I'd been seeing lately; I currently have gnome-session on hold, and assumed based on the widespread echoes I was hearing about the symptom that a bug had been filed and was probably in progress.. but I confess not to have checked.
<slangasek> barry, jono: do you also find that in the dm menu, the session selector is empty by default?
<jono> slangasek, I am not even a dm
<bryceh> jono, if X won't start it typically says something as to why in a log file
<jono> it looks like X isn't starting for me
<slangasek> jono: oh, ok
<jono> bryceh, I checked the syslog and dmesg
<jono> it doesn't say anything about X
<cjwatson> /var/log/Xorg.0.log
<bryceh> jono, in an X log ;-)
<jono> bryceh, which x log?
<jono> I didnt see anything in Xorg.0.log
<bryceh>  /var/log/Xorg.0.log* or /var/log/gdm/:0.log or /var/log/lightdm/* or /var/log/kdm/* or....
#ubuntu-devel 2011-08-17
<jono> bryceh, thanks
<jono> is there anything in specific I should be looking for?
<bryceh> jono, I would look for an error message or stack trace
<jono> looking throught he lightdm logs there are no errors
<jono> and I dont see errors in the Xorg.0.log* files
<jono> bryceh, it does say in the syslog that plymouth-stop terminated with status 1 and lightdm main process terminated with status 127
<jono> not sure what those statuses mean
<bryceh> that would be your culprit
<jono> bryceh, what do those statuses mean?
<bryceh> non-zero exit code generally means the program failed
<jcastro> I don't think it's lightdm
<jcastro> I can't plain startx at all
<jcastro> even if I remove lightdm from the equation
<bryceh> not that familiar with plymouth-stop, but sounds like maybe it was unable to terminate plymouth?  so then it never bothered to start X
<cjwatson> that wouldn't explain being unable to startx manually
<cjwatson> jono: it's often not possible to assign a specific meaning to exit codes
<jono> cjwatson, when I run startx as a user it says the user is not authorized to run the X server
<cjwatson> not from the exit code alone anyway
<bryceh> cjwatson, maybe, although if something went wrong with the gpu while plymouth was running, both startx and *dm-X would fail the same way
<slangasek> there's practically no reason that plymouth-stop should fail to stop plymouth unless something else (like a DM) has interfered with it; it's more likely that plymouth failed to start in the first place
<cjwatson> true, but that's a hell of a lot to infer from plymouth-stop exiting 1
<bryceh> jcastro, pastebin your output from running startx
<slangasek> jono: is there a plymouth process running?
<jono> slangasek, nope
<slangasek> 'plymouthd' rather
<broder> startx doesn't work as an unprivileged user
<broder> but that's separate
<jono> is there a way for my to try and boot without plymouth so I can see if that is causing the issue?
<jono> broder, I assume running startx as root would not work either?
<jcastro> Is plymouth used from the recovery entry on grub? because I tried that too
<cjwatson> booting without plymouth is impossible.  you can remove 'splash' from your boot parameters and plymouth will not try to display a splash screen, however
<jono> cjwatson, ahhh I see
<cjwatson> which would be sufficient to eliminate it from this question
<jono> was there a recent plymouth release over the last day?
<cjwatson> the recovery entry does not use 'splash', so if it exhibits the same problem, it's not plymouth's fault
<jcastro> I have the problem and I don't have "splash"
<bryceh> jono, your /var/log/dpkg.log should show what packages were updated since yesterday
<bryceh> was there a kernel update?
<jono> just checking now
<jcastro> I tried with an older kernel too. :-/
<bryceh> hmm
<cjwatson> plymouth hasn't changed for a month or so
<cjwatson> I think you can safely rule it out
<jono> there was mainly some gtk3 and initramfs updates
<jono> new libglib too
<bryceh> wonder what the initramfs change was
<slangasek> initramfs-tools itself hasn't been updated; the breakage could be caused by whatever triggered an update to your initramfs though
<jono> hmmm
<jono> not sure if this helps, but I tried to startx from root after I rebooted into recovery mode - it says /dev/fb0: No such file or directory
<RAOF> That's fbdev not being able to open the framebuffer device, which is entirely expected as recovery mode disables kms, leaving you without a framebuffer device :)
<jono> aha!
<jono> makes sense :-)
<jono> so any suggestions, folks?
<RAOF> Which, incidentally, means that intel and nouveau won't work from recovery mode, as they require kms.
<jono> anything else I can do to help track the issue down?
<bryceh> I'd suggest filing a bug report with ample logs in case there's something subtle in them a trained eye might catch
<jono> bryceh, will do
<bryceh> the /var/log/dpkg.log especially would be useful, since if it's a regression since yesterday it's likely going to be due to one of those updates
<jono> no worries
<slangasek> huh, has that always been the behavior of recovery mode?  I didn't remember 'nomodeset' being there before
<jono> slangasek, I just tried to run startx as root from a normal session and still no luck
<bryceh> theoretically downgrading the versions individually might reverse the error, although if slangasek's right that an initramfs update is involved, that may not help at all
<bryceh> jono, what printed out when you ran it?  "no luck" isn't a normal X error ;-)
<jono> bryceh, xinit: connection to X server lost
<Sarvatt> jono: ~/.xsession-errors
<RAOF> slangasek: It's new in oneiric, on the basis that one of the problems that people need to be able to recover from is when kms doesn't work :)
<jono> waiting for X server to shut down: ddxSigGiveUp: Closing log
<bryceh> the good news is if both jono and jcastro are seeing the same bug, it should be easy to reproduce
<slangasek> RAOF: I thought kms was always supposed to work ;p
<Sarvatt>  gnome-session: symbol lookup error: /usr/lib/gio/modules/libgiozeitgeist.so: undefined symbol: g_desktop_app_info_launch_handler_get_type
<RAOF> Well, at least we should have a useful Xorg.0.log :)
<jcastro> ooh, I get that same ddxgiveup thing
<slangasek> also, the tradeoff is that now recovery mode is less useful for debugging other failures that weren't kms-related
<slangasek> Sarvatt: should be non-fatal, just means gnome-session won't load zeitgeist integration?
<cjwatson> slangasek: bryceh and RAOF asked me to change that at UDS
<cjwatson> (adding nomodeset in recovery mode)
<cjwatson> of course one can edit the boot parameters and delete that if that's not the problem ...
 * slangasek nods
<jcastro> RAOF: there's nothing in the Xorg.0.log, it was the first place I looked.
<cjwatson> I feel no ownership of that boot parameter change, though - if the X team stops feeling it's appropriate, I'm happy to undo it
<jono> my .xsession-errors has a stack of Fatal IO error 11 (resource temp unavailable) on X server :0
<Sarvatt> X is fine, i've got X up with an xterm, its something gnome related from the looks of it
<RAOF> slangasek: It's really about what the purpose of recovery mode is, and mode which is guaranteed (as far as possible) to bring up a display of some kind is pretty useful.
<jono> I also see a stack of GLib-GObject-CRITICAL errors
<slangasek> RAOF: point
<jono> those errors seem to be in nautilus
<slangasek> jono: can you pipe your .xsession-errors through pastebinit?
<Sarvatt> startx is trying to start a session which is dying and quitting x
<jono> I also see an I/O warning about failing to load external entity /home/jono/.compiz/session/<long random number>
<jcastro> http://paste.ubuntu.com/667805/
<jcastro> there's mine
<slangasek> Sarvatt: I'm confused; are you experiencing other X problems, or are you reading over jono's shoulder? :)
<slangasek> s/X/desktop/
<Sarvatt> i reproduced it on a machine i upgraded this morning, rebooted and no desktop
<slangasek> aha
<Sarvatt> also the amd64 livecd from today doesnt start lightdm automatically
<slangasek> jcastro: I don't suppose there's anything interesting in *your* /var/log/Xorg.0.log?
<jcastro> nothing at all
<slangasek> jcastro: nothing except for the ddxGiveUp error?
<jcastro> yeah but that's only spit out to the console
<jcastro> not the log afaict
<slangasek> ah, when trying to run startx?
<RAOF> ddxGiveUp isn't (necessarily) an error; that's what the X server says during shutdown.
<jcastro> right
<RAOF> So if the X server is working fine, but the session you're trying to start up quits, the server will terminate and you'll get that message.
 * slangasek nods
<hallyn> jbernard: hm, scratch that (above), i see where it's supposed to do it
<jono> interestingly, if I switch my DM to gdm I see X repeatedly try to start
<bryceh> that's just gdm trying blindly to deal with the situation by trying to start X multiple times
<bryceh> in theory gdm should exit and drop into failsafe-x
<jono> right, ok, I am rebooting and then putting log files on a USB stick and will file a bug
<jcastro> ok so doing a "sudo startx" I get "No protocol specified" over and over on the first console
<Sarvatt> jono, jcastro, bryce: it's the glib2.0 update today
<Sarvatt> https://launchpad.net/ubuntu/+source/gnome-session/3.1.3-0ubuntu11/+build/2679219 works
<Sarvatt> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644910 for the amd64 packages, downgrading that makes everything work again
<Sarvatt> err sorry, didnt mean to link gnome-session in the first one
<jcastro> ok trying it
<Sarvatt> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912 for i386
<bryceh> Sarvatt, thanks
<jono> Sarvatt, how do I downgrade that package?
<bryceh> jono, jcastro, thanks; I've reproduced the bug on two machines.  Likely everyone who updates today will hit it
<jcastro> jono: grab the debs on that page and dpkg -i them
<bryceh> jono, download the .deb's and then do sudo dpkg -i *.deb
<bryceh> I still had the files in /var/cache/apt/archives
<jcastro> (I've installed them but need to wrestle with nvidia for a bit before I confirm they work for me)
<Sarvatt> libglib2.0-0 libglib2.0-data libglib2.0-bin should be what you need
<jono> thanks for all your help bryceh , Sarvatt , jcastro , cjwatson , RAOF
<jono> and of course slangasek
<bryceh> alright, I've reproduced both the bug and the workaround of downgrading glib using what is in /var/cache/apt/archives, and I have a functional desktop with unity
<micahg> slangasek: still around?
<slangasek> micahg: yep - what security update would you like me to break today? :)
<micahg> slangasek: heh, firefox, natty only, from ubuntu-mozilla-security to natty-security, please
<jono> Sarvatt, those are the AMD64 builds, where are the normal x86 builds?
<jcastro> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912
<Sarvatt> [9:17 PM] <Sarvatt> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912 for i386
<jono> ahhh
<jono> thanks
<jono> didnt see that
<slangasek> micahg: version 6.0+build1+nobinonly-0ubuntu0.11.04.1 ?
<micahg> slangasek: yes please
<slangasek> micahg: done
<micahg> slangasek: thanks!, by the end of my day, I should have a nice list of OOPSes to throw at the LP guys for this (not that it'll make them fix it any faster)
<slangasek> micahg: well, I understand they want us to not have to use the shell to administer the archive... and this counts :)
<jcastro> Sarvatt: bryceh: confirming the downgrade works here
<bryceh> jcastro, I gotta run but can you or jono file a bug against glib2.0 and make sure seb128 or one of the other gnome is aware of it?  I'll send a note to the mailing list.
<jono> thanks bryceh , will file it now
<jono> https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/827753
<ubottu> Ubuntu bug 827753 in glib2.0 (Ubuntu) "libglib 2.29.16-0ubuntu1 breaks desktop session - downgrade fixes" [Undecided,New]
<jono> biab
<slangasek> RAOF: installing libgl1-mesa-glx:i386 in a chroot works ok here
<slangasek> RAOF: however, bug #802901
<ubottu> Launchpad bug 802901 in apt (Ubuntu) ""E: Internal Error, Could not early remove linux-libc-dev" in multiarch chroot" [Undecided,Confirmed] https://launchpad.net/bugs/802901
<RAOF> That's an eerily familiar error messageâ¦ :)
<slangasek> oh, no, it doesn't work ok here at all, I simply forgot to let it get to the point of attempting the install :P
<RAOF> slangasek: Hah!
<RAOF> Yeah, I just tried it and it failed for me.
<RAOF> I was wondering whether you'd forgotten to install libgl1-mesa-glx:amd64 first :)
<RAOF> But, in case it's not obvious, the problem is symmetric - if you install libgl1-mesa-glx:i386 first, then libgl1-mesa-glx:amd64 will fail to install with that error.
<slangasek> linux-libc-dev also has a C/R/P - nice catch
<RAOF> jono, jcastro: Do you, perchance, have libzeitgeist-gio installed?
<jbicha> RAOF: that's not even available in my synaptic
<RAOF> jbicha: Yeah, I know.  It *was* in Maverick, though (see bug #724199), and so upgraders might hit this.
<ubottu> Launchpad bug 724199 in libzeitgeist "Remove libzeitgeist GIO module - zeitgeist-datahub does the same now" [Medium,Fix released] https://launchpad.net/bugs/724199
<RAOF> Whereas my freshly installed oneric is very happily running the latest stack.
 * jbicha tries rebooting also
 * TheMuso is upgrading now, will test as well.
<jbicha> yes I rebooted just fine
 * TheMuso is on a fresh install from a daily over the weekend so shouldn't have problems going by what you guys are saying.
<RAOF> Ok.  I think we should upload a new glib with an explicit Breaks: on libzeitgeist-gio, and leave seb or pitti to do a more thorough fix.  Dropping 71_gio_launch_handler.patch broke ABI; I'm not sure how they want to resolve this.
<TheMuso> Let me reboot to be 100% sure/.
<TheMuso> Ok all fine here.
<RAOF> Actually, I guess we've got two options: re-add 71_gio_launch_handler.patch, or add a Breaks: to libzeitgeist-gio
<TheMuso> I guess the question is whether the patch being dropped was accidental.
<RAOF> No, it was deliberate; there's new upstream API which does the same thing, but differently.
<TheMuso> Ah ok.
<RAOF> Re-adding the patch ensures that everyone's session should start up; if we just break: libzeitgeist-gio then there are potentially other failures that we don't yet know about.
<TheMuso> Right.
<RAOF> Hm.  There's another ABI change, but as I read it it's API that was introduced in 2.29.6, and hence is still unstable.  So hopefully nothing's using it.
<RAOF> Oh, wow.  It's 13:30.  That's why I'm hungry!
<TheMuso> heh
<RAOF> Hm.  glib's testsuite needs to be parallised.
<pitti> Good morning
<pitti> slangasek: (ah, ricotz offline) gnome-menus is blocking a whole lot of other gnome 3.1.5 packages; but as I uploaded it, I can't NEW it
<pitti> slangasek: but we have it in the ubutu-desktop PPA as well for staging, so it's not totally blocking everything
<pitti> RAOF: I don't actually know about 71_gio_launch_handler.patch; I guess I'll wait until seb128 is online, discuss it with him, and then we'll fix it today
<RAOF> pitti: Ah, ok.  My glib build re-adding that patch has finally finished the test-suite, so if you want that I can upload it now.  If not, I'll leave it to you.
<pitti> RAOF: please go ahead
<pitti> RAOF: so I guess the proper fix is to port libzeitgeist-io to the new upstream API?
<slangasek> pitti: ah, in that case allow me to expedite
<slangasek> pitti: actually, it looks like someone else may have already done so ;)
<RAOF> pitti: No; libzeitgeist-gio has been removed from the archive.
<RAOF> pitti: The problem was that it hasn't been removed on upgrade, and it blocks startup of anything glib-based, which means logging in is problematic :)
<pitti> slangasek: ah, splendid
<pitti> RAOF: oh, so a Breaks: actually sounds right?
<RAOF> pitti: I was deciding between re-adding the patch and just adding a Breaks: on libzeitgeist-gio, and decided to unbreak the ABI instead; I don't know how many other users of that ABI there are.
<pitti> RAOF: ok, please wait with the upload thhen
<RAOF> And preventing {lightdm,gdm} from starting is pretty obnoxious.
<slangasek> you want Conflicts:, not Breaks:
<slangasek> since Breaks doesn't guarantee removal, only deconfiguration
<pitti> I have the new version running since yesterday without any problems
<RAOF> Yeah, but that's a new install, right?
<pitti> it was introduced for wncksync
<pitti> RAOF: yes, but libzeitgeist-gio actually should be cleaned up on upgrade either way
<RAOF> I agree.
<pitti> RAOF: and it doesn't seem to break anything else
<pitti> it was originally introdoced for wncksync
<pitti> but bamf works fine with the new glib, so doesn't seem to need that any more either
<pitti> RAOF: so my gut feeling is that we should keep the upstream API now, and clean up the old cruft properly instead
<RAOF> I was rather thinking "as well" rather than "instead"; I just wanted to unbreak everyone's systems.  Then we could clean up later, and re-drop the patch once we were sure no one was using it.
<RAOF> You've touched glib much, much more than me, though, so now you're up I'm happy to hand off.
<pitti> RAOF: I'll triple-check bamf, as this seems to be the only other user
<RAOF> It'd be kinda nice for dpkg-symbols to have some sort of support for this - when you mark a symbol with an Ubuntu or Debian version it gets recorded in the dependency dataâ¦
<pitti> RAOF: ok, so want me to add the Conflicts:, or did you already?
<pitti> RAOF: and thanks for figuring out the cause of this!
<poolie> Daviey, hi?
<pitti> sorry, this didn't occur in seb128's or my testing, I guess as we both have an upgraded natty install
<RAOF> pitti: I haven't yet done that; I can, retest, then upload though.
<pitti> RAOF: I can take over if you want to call it a day
<pitti> just asking if you already did to avoid double work, but I don't see new commits in bzr yet
<RAOF> I'm not near EOD.
<RAOF> I've got a package with the patch re-added ready, but not one with just a conflicts.
<RAOF> That said, it'll be trivial to whip up one with the conflicts ;)
<pitti> RAOF: glib just built yesterday, I don't think it needs a full local run just to add a Conflicts:
<RAOF> Fair call.
<RAOF> Hm.  bzr doesn't seem to want to push; it's just sitting there.  I wonder what it's doing.
<RAOF> Heh.  Too impatient.  There it goes!
<RAOF> pitti: Done.
<pitti> RAOF: thanks
<pitti> slangasek: so I followed your announcement to enable multiarch, and apt-get update indeed did get all the i386 indexes
<pitti> so it's "sudo apt-get install flashplugin-installer:i386" now, right?
<pitti> that at least seems to pull in a lot of i386 dependencies
<StevenK> Can we purge ia32-libs now? :-)
<pitti> I suppose we should make the firefox plugin installer clever enough for this now
<ajmitch> StevenK: you seem eager to kill it :)
<pitti> StevenK: parner stuff still needs it
<pitti> ajmitch: who isn't?
<pitti> like this little package "skype"
<pitti> ia32-libs has been a thorn in our eyes forever
<micahg> pitti: apparently skype doesn't need it according to slangasek
<ajmitch> who doesn't love a large monolithic binary package that must give the security team headaches?
<pitti> slangasek: so, congratulations! that was a great piece of work
 * ajmitch feels sorry for whoever's had to touch it
<micahg> ajmitch: we're not talking about chromium right now :)
<pitti> lolo
<ajmitch> micahg: hah
<ajmitch> micahg: it still bundles half the world? :)
<micahg> yep
 * ajmitch is glad to see multiarch, thanks to those who've implemented it 
<pitti> hmm, now I just need to tell firefox somehow that the plugin is "on the other side of the arch fence"
<StevenK> pitti: Partner? Who uses that anyway? :-P
<ion> A major Finnish bank uses a really nasty Java thing for web banking access that only works with sun-java6-plugin. The partner repo is a decent way to get it.
<slangasek> pitti: yay :)  be careful though, you may need to purge the amd64 flashplugin-installer package before installing the i386 one... dpkg seems to get a bit confused when transitioning a non-multiarch-same package directly from one arch to another
<pitti> slangasek: that's what I did, and the install went cleanly; but if ffox is supposed to pick that up, I'll just try again, I suppose
<slangasek> oh - you still need nspluginwrapper installed
<slangasek> did you remove it?
<pitti> oh, indeed
<pitti> I thought flashplugin-installer would pull it in
<slangasek> (I still need to touch the flashplugin package to represent this in some sensible fashion)
<pitti> didn't help, though
<slangasek> yeah, the amd64 flashplugin-installer does, the i386 one doesn't - it may be simplest to just make it a dependency
<pitti> ooking for plugins in /var/lib/flashplugin-installer/
<slangasek> didn't help?
<pitti> Update plugin /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
<pitti>   wrapper ident matches and NPAPI plugin is unmodified, skipping
<pitti> perhaps I need to install the wrapper first, and then flashplugin-installer
<slangasek> hmm
<slangasek> I honestly don't know
<pitti> if it works for you, then I guess I just did something wrong, or have some cruft on my system
<slangasek> you could be right that nspluginwrapper needs to be installed before flashplugin-installer
<pitti> that didn't help either, thoug
<slangasek> hmm
<slangasek> restarted firefox after installing?
<pitti> yes, sure
<slangasek> shows up in about:plugins, or no?
<pitti> it doesn't
<pitti> sudo dpkg -P flashplugin-installer:i386 nspluginwrapper:i386
<pitti> and trying to reinstall both
<slangasek> oh, you need the amd64 version of nspluginwrapper :)
<pitti> should I clean up anythign else?
<pitti> ah!
<slangasek> nspluginwrapper is the bit that's the *plugin* for firefox :)
<slangasek> so has to match arch
<pitti> that's not installable on amd64
<slangasek> <cough> it's in NEW
<slangasek> :-)
 * pitti just feels the urge to do some archive admin
<micahg> in theory, we can solve the nspluginwrapper issue for firefox, but other things need nspluginwrapper
<slangasek> only in theory; the existing plugin-container doesn't do the job because it doesn't provide an interface for registering the foreign-arch plugin w/ firefox to begin with
<statim> general newb packaging question: would it be a really bad idea to have the build script download the original tar from somewhere, then extract, make, install? im not sure if that makes things more maintainable or not?
<infinity> statim: Our buildds have no access to the internet.
<infinity> statim: So, if that's destined for an archive, that's a huge "no".
<infinity> statim: (It's also quite possibly a license violation, if it's GPL or similar, since binaries and source need to be distributed together)
<RAOF> It's also generally a good idea for maintainability to have reproducible builds; downloading the tarball from the internet breaks that.
<statim> infinity:  cool thanks.  im actually just trying to figure this out to make my own packages for a few things, but i should do it the best way as you suggest.  im nowhere near understanding this enough to make packages that would make it into the official repos
<statim> i built something with pbuilder-dist, and now my ~/pbuilder/lucid_result/ has all these .deb files in it.  is there a special way to clean that out before i build something else, or just rm?  i already ran pbuilder-dist lucid clean, but that doesnt remove those deb files
<micahg> statik: no need to remove them
<micahg> statik: oops, tab complete failure :)
<micahg> statim: no need to remove them
<statim> micahg:  ok, so its just for my benefit to keep themâ¦ pbuilder doesnt care about them really, it just puts them there for me
<micahg> statim: yep, up to you, it's just a storage dir AFAIK
<statim> micahg: cool thanks
<dholbach> good morning
<Daviey> Good morning Mr Holbach!
<ion> morning
<dholbach> hey Daviey, hey ion
<pitti> happy birthday, Debian! 18 years, coming of age
<Quintasan> Good morning
<ogra_> pitti, finally at drinking age :)
<Laney> cjwatson: serialisation> yeah, that would be nice. TBH lpapicache has grown a lot since I was involved at its genesis (when it was genuinely just a caching wrapper) and I'm not sure of all of the moving parts at this moment in time.
<tumbleweed> slangasek: the multi-arch: same with differing files problem I mentioned in bug 802901 was in libfontconfig1's doc (I had symlinks, package didn't). But I have no idea where that came from, so I can't reproduce it it.
<ubottu> Launchpad bug 802901 in apt (Ubuntu Oneiric) ""E: Internal Error, Could not early remove linux-libc-dev" in multiarch chroot" [High,Confirmed] https://launchpad.net/bugs/802901
<jml> if gtk-window-decorator crashes, what's the least interfering way to get it back up?
<pitti> Alt+F2 gtk-window-decorator
<pitti> that worked for me
<RAOF> If gtk-window-decorator crashes, it's saving you from it's memory leak ;)
<jml> RAOF: hooray?
<jml> pitti: ta
<RAOF> jml: Indeed.
<doko_> soren, would it be possible to disable the ubuntu-server-qa repository for some days until the test rebuild is done?
<dholbach> barry, Riddell: can you answer https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/827925?
<ubottu> Ubuntu bug 827925 in Ubuntu Packaging Guide "How to handle a merge" [Undecided,New]
<ScottK> slangasek: It looks like we need to put qdbus back into some non-dev package (I'm guess it's own) and adjust dependencies.  I'll be offline most of today for $work, but can help with this in 10 or 12 hours.
<ev> would someone be so kind as to provide peer review on this move of camerabin from gst-plugins-bad to gst-plugins-good? http://paste.ubuntu.com/668124/ http://paste.ubuntu.com/668125/
<tseliot> cjwatson: would it be acceptable if I forced the removal of the old kernel hooks left in /etc by nvidia-common in, say, the preinst script of nvidia-common? (this should prevent the kernel installation from failing)
<cjwatson> tseliot: which exactly?
<tseliot> cjwatson: /etc/kernel/postinst.d/nvidia-common and  /etc/kernel/header_postinst.d/nvidia-common
<cjwatson> tseliot: sure, if a newer version removes them then I think cleaning them up in the preinst is the right thing to do
<tseliot> cjwatson: yes, this is exactly the case. Thanks
<soren> doko_: Sure. Hang on.
<soren> doko_: Done.
<doko_> thanks!
<RAOF> slangasek: You may be interested in bug #827950
<ubottu> Launchpad bug 827950 in dpkg (Ubuntu) "Multiarch: dpkg gets confused when installing new packages with the same version" [Undecided,New] https://launchpad.net/bugs/827950
<RAOF> slangasek: I hope that the description is clear enough; I found it difficult to describe.
<cjwatson> argh, I hate dpatch
<cjwatson> I always always always forget to add new patches to debian/patches/00list
<pitti> cjwatson++
<seb128> heh, I used to hate quilt for the same reason :p
<pitti> quilt does add stuff to series automatically
<seb128> if you use the right quilt commands
<seb128> I tend to cp the vcs diff in debian/patches
<cjwatson> if you use the natural quilt commands for creating new patches, yes :-)
<seb128> which "just work" with cdbs simple-patchsys
<cjwatson> as opposed to dpatch-edit-patch, which doesn't
 * cdbs simple-patchsys sucks when it comes to managing a gazillion patches
<mvo> edit-patch ftw!
<mvo> or add-patch for this matter
<cjwatson> yeah, I got fed up and de-simple-patchsysed grub2 at some point because the process of refreshing to a new upstream version was ridiculously tedious
<cjwatson> mvo: I probably ought to remember that, yes :)
<seb128> mvo, ;-
<seb128> mvo, ;-)
<mvo> I guess cdbs/dpatch should have a debian/00list, debian/patches: *AUTOMATIC-KTHXBYE* option to add there
<mvo> that would just use whatever is in the dir
<cjwatson> mvo: this particular package has patches in debian/patches/ that aren't applied :-/
<mvo> heh, there we go
<mdeslaur> ah, debian packaging, so much fun :)
<cdbs> compiz --replace
<cdbs> err whoops, gnome-terminal tab fail
<Laney> does anyone have a non-virtual ppa that they'd be willing to chuck a test build of mono's 2.10 branch at for me?
<Laney> seeing failures on buildds but not locally or on virtual builders
<OdyX> tkamppeter: Ping. I have a question about pyppd: does it hurt if, for all drivers, it is launched as "pyppd /usr/share/" (aka the path from there is in the pyppd-generated archive) ?
<OdyX> tkamppeter: That would make things way easier, and avoid having to parse and handle an option
<OdyX> (context being: dh_pyppd to be added to pyppd, in order to "just" put --with pyppd in the dh $@ line and be done with it.)
<mdeslaur> what package is Oneiric's battery indicator from?
<pitti> mdke: indicator-power
<pitti> sorry
<pitti> mdke: ignore me, wanted to respond to mdeslaur, tab failure
<Sweetshark> doko_: ping?
<Sweetshark> doko_: the "remove Matthias Klose who is no longer involved in this package" was not by me but by the upstream debian dev packaging 1.9.0-1 ....
<lool> stgraber: Is it ok to commit a pastebinit paste.linaro.org to collab-maint, or should I file a bug?
<lool> oh actually that's not upstream
 * jdstrand wonders why his /tmp directory isn't having its directories autocleaned on boot...
<mr_pouit> seems a few more sync mails leaked out from the test environment (debootstrap 1.0.35 and mono 2.10.4-2)
<cjwatson> mr_pouit: those were real
<debfx> slangasek: is it intentional that apt doesn't install recommends of foreign arch packages?
<mr_pouit> oh, indeed
<cjwatson> mr_pouit: I'll be announcing the new facility soonish, we're just finalising the client tool
<cjwatson> mterry: did my netbook-launcher-efl branch look plausible?
<mr_pouit> cjwatson: okay, nice. They have the same "incomplete" mail (without the .changes), that's why I thought they were the same ;-)
<mterry> cjwatson, ah, sorry. I bookmarked it to get back to it.  I can review now
<cjwatson> mr_pouit: ah, no, missing the changes is kind of inevitable for this mechanism
<directhex> of course, mono's breaking due to a random problem that only seems to happen on the real ubuntu buildds, not locally or in a ppa. woohoo
<cjwatson> mr_pouit: the thing that tipped me off about the aptitude one was that it was marked as signed-by somebody without Ubuntu upload privileges :-)
<cjwatson> mr_pouit: but if you look closely you can also see that it has a link to dogfood.launchpad.net
<cjwatson> mterry: cool, thanks
<mr_pouit> huhuhu, ok ;-)
<mterry> cjwatson, yeah, seems fine to me
<mterry> cjwatson, I'm putting the change in upstream trunk too
<cjwatson> mterry: great, thank you
 * cjwatson chips away at the EFL stack nightmare
<mterry> cjwatson, shall I merge to Ubuntu or will you?
<cjwatson> mterry: don't mind, I can if you like
<mterry> k
<cjwatson> done and uploaded
<tkamppeter> OdyX, no problem.
<OdyX> tkamppeter: okay, nice.
* doko_ changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
<bdmurray> ev: could you merge https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/bug-828037/+merge/71901
<ubottu> Ubuntu bug 71901 in Ubuntu "wrong order in /etc/rc2.d between kdm and nvidia-kernel" [Undecided,Fix released]
<ev> whoops, I still have that hat on
<ev> sure thing
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bdmurray> heh thanks
<ev> will do in about 5
<ryanakca> Is there somewhere I can find a history / archive of Sources.bz2 and binary-i386/Packages.bz2 for the past few years? Similar to http://snapshot.debian.org/archive/debian/YYYYMMDD/dists/sid/main/* , where YYYYMMDD is the day you're interested in?
<cjwatson> not as far as I know.  You can approach the problem from other angles since https://launchpad.net/ubuntu/+source/SOURCEPACKAGENAME/+publishinghistory has history for each source package
<debfx> slangasek: turns out that flashplugin-installer didn't pull in libasound2-plugins because I had libjack-jackd2-0 installed which isn't multiarch'ified yet
<ryanakca> cjwatson: Aye, I've been using launchpadlib to fetch source publishing histories for the past week and a half with no sign of it ending. Putting those back together and outputting Packages.bz2 and Sources.bz2 for Thursdays of every week isn't going to be very pleasant. Thanks :)
<cjwatson> ryanakca: sorry not to be able to help more
<ryanakca> cjwatson: No worries
<slangasek> debfx: oh, well, doh.  I have never understood why those two libraries conflict with each other the way they do
<tumbleweed> ryanakca: we have ubuntu upload history in a UDD table in Debian (if you have access to that. you can also download a dump). That should corrospond to source publishing history, but not binary
<tumbleweed> hrm, I suppose that won't give you removals
<cjwatson> tumbleweed,bdrung_vacation,Laney: any more thoughts on https://code.launchpad.net/~cjwatson/ubuntu-dev-tools/syncpackage-lp/+merge/71718 ?
<cjwatson> there were some moderately substantial changes in the last couple of commits, I realise
<tumbleweed> cjwatson: I'm happy with it
<slangasek> tumbleweed: libfontconfig1> hmm, very strange; if it's not reproducible though, guess there's no action to take
<tumbleweed> the symlinks were to ../libfontconfig1/$name, IIRC
<slangasek> ScottK: qdbus> yep, sounds like it; I'll try to get that fixed up this morning
<Laney> cjwatson: yeah, fine by me. We need to clean up the API in ubuntutools, but that's for another day
<cjwatson> I think the JSON serialisation could be handled by making BaseWrapper a subclass of whatever the lazr Resource class is
<cjwatson> but that seemed a bit intrusive to attempt in this branch
<tumbleweed> should we change requestsync to say "you can sync yourself if you want"?
<cjwatson> hm, yes, I can do that
<cjwatson> at least in the manual page
<Laney> it should Just Do It IMHO
<tumbleweed> it should only be necessary for sponsored syncs and FFe requests now
<Laney> or bail out with the commandline you need to run
<cjwatson> hm, I'm not ready to do that yet
<cjwatson> for a while, I'd prefer it to be opt-in
<tumbleweed> sounds good
<Laney> fair
<cjwatson> though I agree once this has bedded down a bit
<Laney> give a notice then
<tumbleweed> urgh, the changelogs really are ugly without newlines
<cjwatson> yeah, I know, sorry :-(
<cjwatson> the import's been fixed but can't do much about the existing data
<cjwatson> committed a change to requestsync(1)
<cjwatson> maybe I should have requestsync itself output a line
<tumbleweed> oh, I didn't realise those were from when the debian archive was imported
<cjwatson> yeah
<cjwatson> current imports are OK
<Laney> can't a query be run over the old data to fix it up?
<cjwatson> e.g. https://lists.ubuntu.com/archives/oneiric-changes/2011-August/006951.html came out OK
<cjwatson> Laney: I don't know, feel free to ask
<cjwatson> (well, OK apart from the spurious newline, I filed a bug about that)
<slangasek> RAOF: bug #827950 answered; sorry, it's not a /great/ answer though
<ubottu> Launchpad bug 827950 in dpkg (Ubuntu) "Multiarch: dpkg gets confused when installing new packages with the same version" [Undecided,Won't fix] https://launchpad.net/bugs/827950
<seb128> does it make sense to support static build for things like GNOME libraries nowadays? just asking because they switched some of their tarballs to default to not build the static libs
<seb128> so I'm pondering either updating the .install to drop the .a or adding a --enable-static to configure
<cjwatson> Laney: brief note added to requestsync
<ryanakca> tumbleweed: Thanks
<tumbleweed> ryanakca: don't know how helpful it'll be for what you want, though
<slangasek> seb128: I think the "nowadays" that people normally include in that question is something of a red herring; the use case for static linking has always been a narrow one and I don't know that it's diminished significantly over time
<seb128> slangasek, ok, worded differently "do we care about being able to do static builds on Ubuntu"
<slangasek> seb128: we could certainly argue that .a files are a waste of archive space; if we're going to drop them, though, I think we should be systematic about it
<seb128> right, archive space and build time
<seb128> I wouldn't mind to get ride of the extra build gtk is doing only for static
<stgraber> lool: patch upstream would be great. Then feel free to get that patched in Debian/Ubuntu as I don't expect a new upstream release very soon (next version will likely be a rewrite)
<flecha> Hello! Is the a way to set a hotkey to a menu bar applet?
<tumbleweed> cjwatson: it does concern me that +localpackagediffs lets non-archive-adimns so easily sync so many packages at once (or select the wrong package by mistake). I'd prefer individual sync buttons (or the use of the command line client). Mind you I assume it asks for confirmation?
<cjwatson> tumbleweed: that's why I'm encouraging Ubuntu people to use the API instead :-)
<dobey> pitti, ScottK: new release files attached to bug #817133
<ubottu> Launchpad bug 817133 in Ubuntu "[FFe] [needspackaging] ubuntuone-installer needs packaged" [High,Incomplete] https://launchpad.net/bugs/817133
<cjwatson> I really don't want people using that UI, but it's not within my power to do anything about it
<tumbleweed> right
<cjwatson> tumbleweed: I'm not sure what confirmation is involved; please do file bugs about UI concerns and tag them derivation ...
<tumbleweed> sure, I'll test it next time I do a sync
<cjwatson> IMO when we change the Ubuntu sync documentation it should just not mention that UI at all and pretend it doesn't exist
<cjwatson> I think it was written more for Linaro than for us ...
<tumbleweed> yeah
<cjwatson> also, it's not possible to apply Ubuntu-specific policy in the UI
<cjwatson> for example the specific requirement for confirmation if the version number contains 'ubuntu'
<Laney> It probably wouldn't be unreasonable for a distro to be able to set a header on that page, though
<Laney> like the bug reporting guidelines
<cjwatson> yeah, but workflow is harder and unlikely to happen
<cjwatson> I'd rather just direct people to good API tools
<cjwatson> unless the header was "do not use this page" I suppose :-)
<Laney> or you could ask for a policy knob to disable the UI
<Laney> or to limit it to a certain team, or â¦ :-)
<Quintasan> slangasek: ping
<Laney> or, well, see if it actually becomes a problem
<slangasek> Quintasan: hi
<Quintasan> slangasek: Oh hey there, I was wondering what's status of qdbus stuff
<slangasek> Quintasan: I'm looking to split out a qdbus binary package and have libqt4-dbus depend on it; currently test-building
<Quintasan> slangasek: That's the solution fabo proposed, right?
<slangasek> yes
<Quintasan> Okay, let me know if you need any help
 * Quintasan goes back to kwin opengles
<slangasek> Quintasan: where did you discuss this with fabo, OOI?
<Quintasan> OOI? What's that?
<slangasek> "out of interest" :)
<slangasek> just the comment on the bug (825689), or was there more out-of-band discussion?
<Quintasan> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/825689
<ubottu> Ubuntu bug 825689 in qt4-x11 (Ubuntu) "libqt4-dbus: contains an executable in /usr/bin, breaks multiarch, Policy 8.2" [Medium,Fix released]
 * slangasek nods
<Quintasan> and on OFTC I think but I didn't discuss it personally
<slangasek> just checking that there weren't any new bug reports I wasn't aware of
<Beret> I see that debdelta support was planned for Oneiric. Does anyone know if that's still on track to happen?
<jcastro> Beret: there's a blueprint somewhere with the status, it was discussed but not on the cards for oneiric
<Beret> yeah I found it at https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-debdelta
<Beret> it says "accepted for oneiric"
<Beret> what's the mean?
<slangasek> it means that the design was approved coming out of UDS; it doesn't guarantee that the work will land
<Beret> got it
<Beret> do we know if it's slated to land by 12.04 or will we find that out in Orlando?
<Beret> I have some work dependent on it which is why I'm asking
<Beret> just trying to get as much information as I can
<slangasek> I currently believe it's likely to land by 12.04, but it's contingent on having an appropriate server-side implementation
<Beret> ok
<Beret> thanks for the info
<Beret> that's what I was looking for
<Laney> siretart: are you looking at the libav nbs?
<chrisccoulson> hey jcastro, how are you?
<jcastro> chrisccoulson: hi
<chrisccoulson> hi jcastro, did you see my earlier ping?
<jcastro> chrisccoulson: nope, sorry, I've been in and out, what can I do for you?
<chrisccoulson> <chrisccoulson> jcastro, do you have any ideas for how we could engage more users and get them testing https://launchpad.net/~mozillateam/+archive/firefox-next (ie, the firefox beta channel)?
<chrisccoulson> (from #ubuntu-desktop)
<chrisccoulson> sorry if you're not the right person to ask ;)
<siretart> Laney: yeah, sort-of. I've worked on mplayer a few hours ago: http://packages.qa.debian.org/m/mplayer/news/20110817T173341Z.html - I guess we should sync that to oneiric
<slangasek> SpamapS: fwiw, slapd forking before listening should be fixed upstream and in oneiric now (following a horrible first at a patch landing in Debian and corrupting people's databases for a bit in squeeze)
<Laney> siretart: I just noticed that the nbs list is pretty large
<micahg> Laney: this might be a better guide: http://people.canonical.com/~ubuntu-archive/transitions/libav.html
<Laney> yep, still a reasonable size
<hallyn> slangasek: Hey - I assume bug #828262 is not possible (it's a new binary package in the lxc source package).  But since a great deal of users on natty/oneiric will want LTS in their containers, it would be awesome if it were
<ubottu> Launchpad bug 828262 in lxc (Ubuntu) "please backport lxcguest to lucid" [Critical,Confirmed] https://launchpad.net/bugs/828262
<hallyn> (so I asked him to submit that, pls yell at me not him :)
<hallyn> really all the stuff in lxcguest i should try and push into the other packages.  there'll be resistance, but...
<SpamapS> slangasek: OH
<SpamapS> slangasek: It didn't appear to be fixed in the latest one I pulled from oneiric
<siretart> Laney: well, yes. and I could really need help on it. most of the patches are IME rather easy, though
<tkamppeter> pitti, hi
<micahg> siretart: is there a guide similar to this one for libnotify from Fedora: http://lists.fedoraproject.org/pipermail/devel/2010-November/144914.html
<slangasek> SpamapS: patch not applied at unpack time, I suspect
<siretart> micahg: well, there is http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=doc/APIchanges, also installed into libavcodec53
<siretart> micahg: if you have a specific build failure, I'm happy to take a look
<SpamapS> slangasek: ahh right.. should have dug through that ;)
<SpamapS> slangasek: its been taken upstream though, right?
<slangasek> hallyn: 828262> that looks like a candidate for lucid-backports? https://bugs.launchpad.net/lucid-backports
<slangasek> SpamapS: the patch we currently carry originates upstream, yes
<SpamapS> woot, only 1515 lines in the mysql copyright file.. :-/
<hallyn> slangasek: ok, thx ( SpamapS had suggested same).  i've never felt (even reading the docs) i quite groked how backports flow, but i'll try that route.
<jbicha> slangasek: multiarch is a bit annoying in tools like Synaptic, USC does a decent job of hiding the extra data clutter
<jbicha> is multiarch something that we should have turned on by default for everything in Ubuntu or just certain libraries & programs?
<groundnuty> hey, is there some nice list of packages from which ubuntu (standard distrubuntion) is made of? preferably with some comments, this one do that, that one does something else. (I figgured it is best to ask here then on #ubuntu)
<slangasek> jbicha: it's not at all trivial to "turn it on" selectively
<jbicha> slangasek: ok, I was just thinking out loud
<slangasek> jbicha: it's a reasonable idea, but I think this needs to be fixed by the package managers getting smarter, not by trying to filter this on the server side
<dobey> groundnuty: list yes, descriptions in that list, no; there is a .manifest for each image on cdimage.ubuntu.com, iirc
<slangasek> because it's just too dynamic
<slangasek> groundnuty, dobey: you might be looking for the package seeds: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.oneiric/
<slangasek> (this is the source that decides what we put on the CDs)
<groundnuty> slangasek: thx, I was generally wondering from what that ubuntu is made of - I assume you you do not chose the packages (mostly 3rd party apps) randomly ;)
<dobey> we use darts, so there are actualy a lot of physics involved; not random at all. ;)
<slangasek> heh
<broder> what's the deal with the new ubuntu core thing i saw skaet mention in her interview? is it just sticking a pretty title on core+desktop-core?
<groundnuty> dobey: some derivations of montecarlo methods? ;P
<dobey> something like that
<groundnuty> dobey: anyway, there arent any discussions publicly aviable? Like: "lets pick that package because... no no! thats better" ;)
<groundnuty> I mean logs/forums
<dobey> groundnuty: well, there are discussions at UDS for big things usually
<slangasek> for instance, there are fairly regular discussions about which browser and groupware solution we should ship by default
<jbicha> groundnuty: you could poke around here: https://blueprints.launchpad.net/ubuntu/oneiric
<groundnuty> slangasek: I imagine :)
<slangasek> most other discussions tend to be about "can we make it fit on a CD?" or "how do we make this fit on the CD?" rather than about *which* app we're going to ship
<slangasek> since the Ubuntu desktop is 90% standard what ships with GNOME upstream
<groundnuty> I see. Btw why you still stick with cd-s? aren they kinda deprecated?
<slangasek> that is *also* a fairly regular discussion ;)
<groundnuty> :)
<slangasek> https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate
<groundnuty> imagine windows vista/7/8 shipped on the 700MB cd...
<groundnuty> I suppose they gave up long ago.
<groundnuty> anyway, thx for all the links I will make some tea and study them.
<slangasek> ScottK: qdbus should be a-sorted now
<slangasek> (with apologies to the ARM team)
<ScottK> slangasek: Thanks.
<bluefoxicy> I have a question
<bluefoxicy> Has anyone ever actually tried unchecking things to install in update-manager?
<bluefoxicy> Because it flat out doesn't work; the damn thing installs every single available update.
<bluefoxicy> 905k to download => downloaded 1% of 18MB
<slangasek> I do it all the time and it works as intended
<debfx> slangasek: could you have a look at my debdiff on bug #828360
<ubottu> Launchpad bug 828360 in gtk2-engines-oxygen (Ubuntu) "FFe: Build for multiarch" [Undecided,New] https://launchpad.net/bugs/828360
<bluefoxicy> hmm, odd.
<slangasek> debfx: does dh_makeshlibs not DTRT if you drop the override entirely?
<slangasek> hmm, it seems to set an SONAME, so I guess not
<bluefoxicy> http://img845.imageshack.us/img845/3158/screenshot4lv.png
<bluefoxicy> this is what I get.
<slangasek> debfx: all looks sane to me, but the proof is in the pudding :)
<debfx> slangasek: aha, I was wondering why it treated it as a public library even though it's not in a standard path
<statim> would anyone mind helping me with this? ive created a specific package of ruby for only my own purposes.  im trying to get the Depends, Conflicts, Replaces, Provides worked out so my own ruby package will take complete control over all things ruby.  ive tried adding all of these: ruby, ruby-dev, libruby, rdoc, ri, irb, rubygems in each form (null, 1.8, 1.9, 1.9.1) to each field of Conflicts, Replaces, Provides, but that doesnt seem to satisfy it.  any hel
<debfx> slangasek: I have tested it with the flash context menu :D
<slangasek> bluefoxicy: well, I unchecked a package twice today in update-manager to avoid upgrading it, so I know it works in general; file a bug?
<bluefoxicy> hmm.
<slangasek> statim: you cut off at the IRC line limit - but this channel is for development *of* Ubuntu, local packages that conflict with Ubuntu ones (and, quite frankly, are going to make a terrible mess of your system even if you solve your current challenge) are off topic
<statim> slangasek:  gotcha thanks.  where would i find this kind of help? just #ubuntu or are there other specialized places?
<slangasek> #ubuntu is the only place that comes to mind
<statim> slangasek: k thanks
<slangasek> but also, see above that you're going to make a mess of your system trying to do this :)
<ajmitch> bluefoxicy: you left firefox-gnome-support checked, which depends on the updated firefox. I think update-manager would try & satisfy all dependecies rather than skip that package
<ajmitch> still a bug if it's not making clear what it'll do
<statim> slangasek:  yes i know â¦ these boxes we use now adays are ephemeral though, and we have provisioning checks to make sure all our stuff worksâ¦ we dont keep them indefinitely and do updatesâ¦ i wouldnt recommend what im doing for everyday use haha
<slangasek> ajmitch: I wondered about that; historically, when you uncheck a package in u-m that has reverse dependencies, those revdeps will also be unchecked for you
 * Daviey wonders when we can finally throw dpatch on a fire.
 * ajmitch hasn't looked to see what its intended behaviour is
<bluefoxicy> ajmitch:  aha.
<OdyX> tkamppeter: c2esp and epson-inkjet-printer-escpr have been migrated to cups' new trigger + dh_pyppd.
<bluefoxicy> ajmitch:  I wasn't even looking :)
<cjwatson> Daviey: debian-devel, algernon says he's set himself a target to deprecate it by 2017 :)
<cjwatson> which actually is about the first realistic target I've seen this year
 * ajmitch wonders if cdbs will ever be deprecated
<cjwatson> now in that case nobody's convinced the maintainer yet ...
<ajmitch> it works well for a lot of simple things, so I doubt it'll die off
<Daviey> cjwatson: That is good news.
<slangasek> trying to convince the maintainer to deprecate it is not how I would go about it
<cjwatson> http://people.debian.org/~cjwatson/dhstats.png is a pretty clear pattern
<Daviey> cdbs still has a few targets that other patch systems hasn't yet addressed.
<cjwatson> a hard core of stuff sticking with it, almost no movement at all of the cdbs line up or down
<slangasek> maybe I should get active on debian-mentors again and refuse to sponsor anything that's not dh(1) :)
<cjwatson> there is no problem with dh(1) growing
<slangasek> yeah
<broder> cjwatson: what's debhelper 7 in that chart? is that just classic long-form debhelper with a >=7 compat level?
<cjwatson> broder: it's Build-Depends/Build-Depends-Indep implies debhelper (>= 7)
<broder> and the "debhelper" line is all-inclusive?
<cjwatson> that's BD/BDI implies debhelper
<cjwatson> and the dh(1) line is a grep of debian/rules for /^\s+dh\s+/
<cjwatson> (well, perl regex)
<cjwatson> probably not perfect but close enough
<slangasek> Daviey: what patch system targets do you have in mind?
<cjwatson> Daviey: YM build systems rather than patch systems?
<slangasek> eew, why is all of haskell using cdbs
<slangasek> looks like there's also a maven cdbs class, but no dh equivalent
<Daviey> slangasek: Well not strictly patching - but the cdbs gems, things like the maven support in cdbs
<Daviey> well, not patching at all.. but YKWIN
<ajmitch> the langpack stuff for cdbs, was that reimplemented for dh?
<slangasek> ajmitch: yes
<slangasek> Daviey: I think I could be persuaded to port maven.mk to dh
<Daviey> slangasek: you may or may not become jamespages best friend.
<slangasek> quite a bit of magic in here, tss
#ubuntu-devel 2011-08-18
<RAOF_> Hm.  That was apparently a bad time to update.  It seems that everything I start from gnome-terminal sits in D state in rtnl_lock
<slangasek> retinal lock?
<RAOF_> I don't know what crazy kernel internal bit that is :)
<RAOF_> Ah, no.  Maybe it's anything which hits some part of the networking stackâ¦
<RAOF_> Yeah, that's it.
<RAOF_> It's not been a good couple of days for oneiric :(
<slangasek> so this is after a post-upgrade reboot?
<RAOF_> slangasek: Yes.
<slangasek> well, doh
<RAOF_> (And that was xchat-gnome dying for no obvious reason) :)
<RAOF_> Hm.  And the previous kernel doesn't seem to help at all.
<RAOF> But preventing network-manager from loading works.
<cyphermox> RAOF: reading backlog, so NM issue or is it conclusively kernel? (or could it be libnl?)
<RAOF> cyphermox: Not conclusively kernel; switching to an older kernel doesn't change the issue.
<RAOF> cyphermox: Definitely related to NM in some way; disabling it (by killing /etc/init/network-manager.conf - running "stop network-manager" *also* hangs) and bringing up eth1 manually with dhclient works.
<RAOF> Might be related to libnl, or wireless.
<cyphermox> huh, stop NM hangs?
<cyphermox> that's probably not libnl or wireless :)
<cyphermox> just in case, have you tried downgrading n-m to 0.8.9997+git.20110721t045648.36db194-0ubuntu1?
<RAOF> I've not yet tried that.  I'll do so once my other stuff hits an appropriate checkpoint.
<cyphermox> ok... let's still check something though; but let's do this in #ubuntu-desktop
<pitti> Good morning
<pitti> tkamppeter: pong
<tkamppeter> pitti, hi
<tkamppeter> Can you upload CUPS to Debian and Ubuntu now? The first shot of PPD update centralization did not work (needed a small fix) and I have also found a bug which made some of the available PPDs not appea, rendering several hundreds of supported printers appearing unsupported.
<tkamppeter> pitti ^^
<jbicha> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-August/thread.html is a few days out of date
<pitti> tkamppeter: ah, sure
<pitti> tkamppeter: done
<dholbach> good morning
<tkamppeter> pitti, thanks.
<Sweetshark> hggdh: ping?
<nigelb> Sweetshark: I'm fairly sure he'd be asleep now
<pitti> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has a whole lot of eucalyptus and dependencies that want to go to universe
<pitti> Daviey: is that deliberate? switching to openstack now?
<pitti> (or whatever the name was)
<Sweetshark> doko: got the message about translate-toolkit?
<doko> Sweetshark, no nothing seen yet
<Daviey> pitti: yes, jamespage opened a bug to try and speed it up aswell
<Daviey> bug 816408
<ubottu> Launchpad bug 816408 in Ubuntu "Please demote eucalyptus to universe" [Undecided,Confirmed] https://launchpad.net/bugs/816408
<pitti> Daviey: oh, the demotion can happen any time, that's not a problem
<pitti> or time critical
<pitti> I just wondered whether it was deliberate
<Daviey> pitti: it is deliberate
<Sweetshark> doko: the "remove Matthias Klose who is no longer involved in this package" wasnt me, it was upstream debian doing that
<doko> bah
<Sweetshark> nigelb, brian-murray, jorge, leannogasawara, pvilllavi: anyone awake who can prevent me from expiring in ubuntu-bugcontrol?
<nigelb> Sweetshark: do you expire today?
<Sweetshark> nigelb: no, it will be a few more days.
<nigelb> if not, I'm sure, one of those pings will hit somone who'll do it tomorrow morning
 * Sweetshark checks ...
<nigelb> :)
<Daviey> Sweetshark: can you not renew yourself?  I thought it allowed self renewewl?
<nigelb> wait, you summoned pedro_  ;)
<nigelb> Daviey: No bugcontrol is not self renewal
<pedro_> hey nigelb ;-)
<Sweetshark> Daviey: ugh, where would I find that in launchpad? I am asking for the guys named above at those are the ones proposed to me in the nagmail.
<nigelb> pedro_: Sweetshark wants his bc membership renewed :)
<pedro_> Sweetshark, just $5000 dollars ;-)
<iulian> Wow.
<nigelb> lol
 * nigelb goes to blog about corruption in the community :P
<iulian> $1000 ought to do it though.
<iulian> pedro_: You just can't ask for that much.
<pedro_> Sweetshark, what's the lp id?
<Sweetshark> pedro_: wait a few more month, when the fed has printed enough, I might comply ;D
<pedro_> iulian, oh well, with the financial crisis and all that... we have to raise the price :-P
<Sweetshark> pedro_: bjoern-michaelsen
<nigelb> iulian: I think the trick is to start high and then negotiate to something like 0$ :P
<iulian> Heh.
<nigelb> pedro_: all of QA at the sprint?
<pedro_> Sweetshark, renewed ;-)
<Sweetshark> pedro_: thanks
<pedro_> nigelb, nope, just the defect analysts
<nigelb> pedro_: nice :)
 * ogra_ hugs pitti seeing the last u-meta upload .... does gnome-user-guide stay off the images permanently now ?
<pitti> ogra_: well, at least until the docs team switches back to having everything tehre :)
<ogra_> hrm
<pitti> but as we just switched back and forth, I guess it'll stay that way now, and it seems to make more sense
<ogra_> sad, i was hoping ...
<pitti> ogra_: I guess it's one of the packages which take a week to unpack?
<ogra_> it is the one package that makes SD card based rootfses scream
<ogra_> takes about 20min to unpack here
<ogra_> right :)
 * ogra_ types to slow today 
<bdmurray> Is there an archive admin channel anymore?
<infinity> Was there ever?
<bdmurray> I seem to recall there being one otherwise I wouldn't have asked. ;-)
<infinity> I don't recall ever having been in one, but I may have missed the memo. ;)
<bdmurray> Anyway I'm curious about how to get a package removed from the archive.
<infinity> File a bug, subscribe us.
<infinity> I'm willing to bet there might even be a cute helper tool for the bug filing, but not sure.
<bdmurray> I'd imagine just saying I think this package should be removed isn't quite enough though.  What type of content should I include?
<infinity> Whatever justification you have, really.
<infinity> "It was removed from Debian, and we have no interest in maintaining it in Ubuntu" is a good one.
<infinity> If it's Ubuntu-specific "we don't maintain it, and neither does MOTU" works.
<infinity> It it's still in Debian, but complete crack, then a longer justification would be needed, along with a reminder to blacklist it from syncs.
<bdmurray> Fails to start, has 1 star in software center and hasn't been updated since lucid and has lots of crash reports?
<infinity> All of that sounds like bug reports to me.  We could, y'know, fix it.
<infinity> One star doesn't mean much to me.
<infinity> We have tons of software no one would ever install from Software Centre.
<infinity> And "lots of crash reports" sounds like it's used.
<jbicha> but is it maintained?
<bdmurray> Right we could fix it but the bugs have been around forever bug 132636 and bug 703556
<ubottu> Launchpad bug 132636 in balazar (Ubuntu) "Balazar crashes with soya3d error: invalid GL_ENUM" [High,Triaged] https://launchpad.net/bugs/132636
<ubottu> Launchpad bug 703556 in balazar (Ubuntu) "Balazar fails to load soya, doesn't run on Natty " [High,New] https://launchpad.net/bugs/703556
<bdmurray> So we haven't gotten around to fixing it yet
<hrw> hi
<hrw> SyntaxError: ("'continue' not properly in loop", ('/usr/share/apport/package-hooks/source_ubiquity.py', 30, None, 'continue\n'))
<infinity> hrw: Already fixed.
<hrw> thx
<infinity> hrw: Upgrade with an up-to-date mirror. :)
<hrw> infinity: ok
<infinity> bdmurray: I'm just playing devil's advocate here, to be fair.  I suspect that the glaring bugs could be fixed pretty quickly if someone took the time.  And our maintainerless system does tend to let things fall through the cracks, which is a bit irksome.
<infinity> bdmurray: Also, given that I don't see those particular error in the Debian BTS, either the problem is Ubuntu-specific (quite likely), or more Ubuntu users use it than Debian ones.  Either way, it hasn't been updated in Debian because it's not RC buggy there.
<infinity> (Though I'm not sure it's hugely well-maintained in Debian either, from the looks of it)
<infinity> Meh.
<seb128> doko, did you mean to score your archive rebuilds over normal ppa builds?
<infinity> bdmurray: (It could just be that it needs to be rebuilt or something if it links against stuff that's been changing under its feet)
<doko> seb128, yes, in batches of 200
<seb128> :-(
<doko> until main is built
<seb128> doko, ok, pitti helped, but dx has been blocked since yesterday to get their compiz ffe update building to be able to test it
<seb128> that sucks
<seb128> that's blocking people to get real work done
<pitti> but at the same time the rebuild test isn't very useful if it's not getting through quickly
<doko> fixing build failures is real work. soyuz sucks
<pitti> and frankly, I consider the rebuild test more urgent than daily maverick chromium/firefox builds
<pitti> we can still manually score up the urgent ones
<seb128> pitti, why not? what difference does it make if it tests tomorrow's version of a source rather than yesterday's?
<doko> and there are 10 non-working machines, which are not given back currently
<pitti> seb128: because these builds are already queued, so you wouldn't test tomorrow's source
<infinity> bdmurray: Actually, looking more closely, the balazar issues on Ubuntu look to be in soya, not balazar.
<pitti> seb128: you'd get build failure reports which were already fixed in a newer version
<seb128> pitti, ok, fair enough, I guess I will just nag you today for dx when they have builds they need, I want that compiz ffe sorted
<seb128> just a bit annoyed that they wasted half a day waiting for builds
<pitti> seb128: sure
<seb128> pitti, danke ;-)
<doko> seb128, pick up your favourite build failures at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html ;p
<pitti> xvfb-run: error: Xvfb failed to start
<pitti> awesome
<pitti> that might hit a few test suites
<seb128> doko, do you want a list of the ones we (desktop) can look at?
<wgrant> seb128: There are package sets on that page now.
<wgrant> Which may be relevant.
<infinity> Don't we break xvfb-run every second release?
<doko> seb128, I assume that would be the ubuntu-desktop package set?
<seb128> wgrant, where?
<wgrant> seb128: Should be links at the top to lists down the bottom.
<seb128> oh, tooltip under the checkmark
<wgrant> Also that, yeah, but there are per-packageset lists down the bottom.
<wgrant> And FTBFS bugs are shown too, if present.
<seb128> doko, wgrant: ok, thanks
<seb128> we will look at the desktop ones
<doko> ScottK: same for the kubuntu ones
<doko> Daviey, and the server ones ...
<seb128> doko, pitti: seems mono is not installable on amd64, that will be leading to quite some builds issues as well
<seb128> it's because it failed to build on i386 and there is an arch all,any mismatch for the binaries
<pitti> yeah, see http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html
<doko> it doesn't seem to be all mono afaics
<seb128> not all, but a few are
<doko> as directhex, he did ask for the sync
<seb128> there is a least 5 of the desktop ones due to it
<seb128> Laney was looking at it I think
<wgrant> Laney and directhex mentioned it yesterday.
<wgrant> I think.
<Daviey> doko: I've already got it open :)
<directhex> it's maddening. it only fails on ubuntu's i386 builders. it's not reproducible on debian's builders or locally
<pitti> directhex: the buildds run on the lucid kernel, might that be related?
<pitti> directhex: was a rebuild already tried? i. e. not just gamma rays?
<directhex> pitti, yes. and it fails on two different buildds
<pitti> infinity: do the PPA builds "see" a different kernel due to the virtualization?
<pitti> i. e. in such cases, is it worth trying a build in a PPA to see whether it's any different?
<directhex> it builds in an oneiric ppa. i can fling it at a lucid ppa?
<wgrant> PPA kernels don't differ by series.
<pitti> directhex: that's what I meant
<pitti> directhex: an oneiric build in an oneiric PPA might actually use an oneiric kernel in the VM
<wgrant> It doesn't.
<pitti> directhex: while on the ubuntu builders it uses the lucid kernel
<pitti> wgrant: ah, these don't use kvm then?
<pitti> or xen?
<wgrant> I think all the VMs are Lucid kernels, but it's complicated due to Xen.
<wgrant> pitti: There is a Lucid VM, with a $series chroot.
<pitti> ah, right, with Xen client-side kernels are optional
<pitti> wgrant: I see
<pitti> thanks
<pitti> wgrant: so that pretty  much rules out a kernel issue then
<pitti> we had that problem with glib (failed on a too old kernel)
<wgrant> The PPA VMs may well be running a somewhat custom kernel, but who knows...
<wgrant> We've had issues with mono on Xen before.
<wgrant> But not, AFAICR, a situation where it worked on Xen but not on bare metal :)
<directhex> rothera and vernadsky have similar hardware?
<wgrant> They're both bases.
<wgrant> So within a year or so, probably.
<wgrant> Both should be i386 kernels.
<directhex> and the other three builders? which of them is significantly different?
<seb128> pitti, the glib issue was happening on ppa builds as well
<wgrant> directhex: roseapple and zirconium are very different.
 * pitti always chuckles when he sees DMI info in bug reports with "MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M."
<wgrant> directhex: roseapple may be an amd64 kernel.
<wgrant> directhex: zirconium was originally an lpia builder, so I don't know what it is.
<AnAnt> Hello, why doesn't Ubuntu sync the  openbios-*  packages from Debian ?
<Daviey> doko: I see last time you raised ftbfs bugs based on the rebuild, are you doing that again?
<doko> Daviey, later this week
<directhex> can we briefly disable vernadsky etc, and jab the rebuild button, so it goes on roseapple or zirconium?
<wgrant> Sure, I can do that. Which build?
<directhex> https://launchpad.net/ubuntu/+source/mono/2.10.4-2/+build/2687881
<doko> directhex, set to manual, please upload
<directhex> doko, i need to upload a 2build1?
<wgrant> No, it's queued now.
<Daviey> doko: Are you doing them manually, or scripted?
<pitti> no, we just need to retry
<wgrant> Should start in 5s or so.
<wgrant>  Currently building on roseapple
<directhex> okay, cool. let's see how this goes
<doko> scripted, but need to check the script first ...
<wgrant> (I manualled zirconium too, because I trust roseapple more)
<directhex> all my local test builds have been on an amd64 kernel. i think Laney was working on an i386 VM
<wgrant> Everything back to auto.
<directhex> i eagerly await the result :/
<pitti> directhex: don't watch the build log, lest it takes forever :)
<directhex> it was 40 minutes on vernadsky. i expect less time on faster tin
<AnAnt> https://launchpad.net/ubuntu/oneiric/+source/openbios-ppc  <- why aren't there binaries generated for openbios-* packages ?
<pitti> AnAnt: failed to build
<directhex> AnAnt, sounds like the old "can't build arch:all packages on non-i386" issue
<pitti> https://launchpadlibrarian.net/70891377/buildlog_ubuntu-oneiric-i386.openbios-ppc_1.0%2Bsvn1018-1_FAILEDTOBUILD.txt.gz
<pitti> "This package must be built on a PowerPC machine"
<AnAnt> aha
<Laney> the VM build succeeded
<AnAnt> pitti, directhex: thanks
<directhex> Laney, which kernel?
<Laney> O
<Laney> 3.0.0-7
<directhex> install an l kernel?
<Laney> -generic-pae
<Laney> yeah, said that yesterday
<infinity> pitti: Nearly all (or maybe all by now) of the PPA machines are amd64, while the i386 distro buildds are actually i386, that's probably the difference.
<pitti> ah, good to know
<wgrant> infinity: Even roseapple?
<wgrant> infinity: I thought it was amd64.
<wgrant> (it appeared while you were gone)
<infinity> wgrant: Oh, roseapple's new.  And almost certainly amd64 hardware.  No idea what kernel it's running, though.
<infinity> wgrant: rothera and vernadsky are both i386 for sure, though.
<wgrant> Yup.
<wgrant> IIRC palmer is a little nicer than them, but still i386.
<infinity> That said, "building on amd64 to make it work" is the wrong answer.  If we still ship and support i386, we should figure out why things don't work there.
<directhex> infinity, agreed - but how long do you want to hang around & wait, with a messed up archive?
<directhex> sigh, the only i386 tin in the house has a maverick kernel
<infinity> directhex: I'm not averse to workarounds, but I'm wary of workarounds that then lead to people forgetting about and not fixing bugs.
<directhex> et voila, it just got past the failure point
<jamespage> morning - please could someone with appropriate perms poke the package importer for the jenkins source package - it borked with a TooManyConcurrentRequests error.
<cjwatson> jamespage: if nobody appropriate responds here, file a bug on bugs.launchpad.net/udd
<jamespage> cjwatson: OK - thanks for the advice
<Daviey> jamespage: In other news, did you see that slangasek was looking at porting the cdbs maven support into dh?
<jamespage> Daviey: nope - missed that one
<jamespage> I know its on the list for the debian-java team
<jamespage> but I don't think anyone is working on it ATM
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<doko> jamespage, could you have a look at component mismatches, and confirm the demotion of all the java packages?
<pitti> doko: already discussed with Daviey, and demoted
<jamespage> doko: ack - I'll take a look now
<pitti> doko: it's due to the demotion of eucalyptus
<doko> ahh, ok
<pitti> bug 816408
<ubottu> Launchpad bug 816408 in Ubuntu "Please demote eucalyptus to universe" [Undecided,Fix released] https://launchpad.net/bugs/816408
<pitti> jamespage: ^
<jamespage> pitti: stopping looking now...
<dholbach> jamespage, is https://bugs.launchpad.net/ubuntu/+source/antlr3/+bug/814819 something the release team should have a look into? is it a bugfix release only?
<ubottu> Ubuntu bug 814819 in antlr3 (Ubuntu) "Update to antlr3 version 3.2" [Low,New]
<jamespage> dholbach: its not bugfix only - 3.0 -> 3.2 made quite a few changes
<jamespage> dholbach: just thinking about the best way to deal with this package
<dholbach> jamespage, is there anything that needs to be transitioned after the update?
<jamespage> dholbach: it only has a few reverse-build-depends
<jamespage> so it would be minimal
<directhex> Finished a moment ago (took 35 minutes, 16.5 seconds)
<directhex> infinity, wgrant ^
<directhex> also pitti i guess
<pitti> yay
<dholbach> jamespage, maybe it'd be good to list those reverse-build-deps and what needs to be done to them and add something like a NEWS file diff to the bug, so the release team can have a second look - I'm happy to deal with it from a sponsoring POV
<jamespage> dholbach: OK - I'll stick it on my list
 * dholbach hugs jamespage
<dholbach> I'll subscribe to it
<ev> what's the correct way to supersede a package? Is it the Provides, Conflicts, Replaces trifecta or is simply declaring Replaces sufficient?
<pitti> ev: for permanently obsoleting it, Conflicts:/Replaces:
<directhex> pitti, that should get the archive running again. we're scrambling to reproduce the issue locally, still
<pitti> ev: "Provides:" if it's a binary compatible drop-in replacement, or just a newer choice
<dholbach> thanks jamespage
<pitti> ev: just replaces: wouldn't cause package removal, just file overwriting
<directhex> provides: doesn't help for versioned depends though
<jamespage> dholbach: np
<directhex> iirc
<tjaalton> poolie: hey, which thinkpad model do you have?
<tjaalton> poolie: asking since I noticed that on 745112 you reported of a similar issue which is now reported as a regression on the kernel from natty-proposed, bug 814325
<ubottu> Launchpad bug 814325 in Linux "fuzzy and corrupted display with update in natty-proposed" [Medium,Confirmed] https://launchpad.net/bugs/814325
<ev> pitti: you're a star; thanks
<tjaalton> poolie: ah, X201 I guess? could you still read through that other bug and post your findings there, and if possible, test oneiric to see if you can reproduce the regression
<pitti> ugh, what's up with LP? It keeps logging me out, and fails to change bug states, add comments, etc.
<tjaalton> poolie: we've had a hard time getting it confirmed on any other hw, so it would be great to find another machine and then figure out what's common with those setups. thanks!
<soren> pitti: I'm seeing the same thing. Just raised it in #launchpad
<soren> pitti: Should be fixed now.
<soren> pitti: Poke henninge in #launchpad if that's not the case.
<pitti> thanks!
<soren> I'm just the messenger :)
<dholbach> cjwatson, hey Colin - how are you doing? how do you feel about merging debhelper 8.9.4 (https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/812120)? AFAICS it consists entirely of bug fixes
<ubottu> Ubuntu bug 812120 in debhelper (Ubuntu) "Please merge debhelper 8.9.4 from Debian unstable" [Undecided,Confirmed]
<cjwatson> I think it needs an FFE for safety's sake
<cjwatson> debhelper merges should not be just waved through at this point IMO
<dholbach> ok, no worries, I'll add some info and subscribe the release team and make sure that it's OK from a sponsoring POV
<cjwatson> the changes in 8.9.4 look subtle, especially the buildflags change, and personally I would rather defer it unless there is a clear reason
<cjwatson> Ahmed should be giving explicit justifications for merging debhelper at this point
<cjwatson> i.e. "it will fix these build problems over here"
<dholbach> ok, I'm happy to point this out
<cjwatson> thanks
 * cjwatson goes back to the NBS slog
<dholbach> unfortunately the consecutive merges have been overlooked for about a month, but still he should add some justification
<dholbach> although it seems he forgot so subscribe sponsors
<dholbach> thanks cjwatson
<cjwatson> argh, python-elementary, stop failing to build
<cjwatson> oh, chroot problem
<lamont> smacking buildds around a bit
<hrw> doko: alive?
<doko> hrw: ohh, do I get the arm biarch patch?
<hrw> doko: sorry, next week - I work remotely nto my main machine now ;(
<hrw> doko: I had an issue with cross binutils build but it was just missing deps on my side. sorry
<debfx> dholbach: could you have a look at bug #827489, it's a fix for a regression introduced in the last udev upload
<ubottu> Launchpad bug 827489 in udev (Ubuntu) "Bluetooth keyboards and mice stopped working in X server" [Undecided,New] https://launchpad.net/bugs/827489
<doko> seb128, directhex: which packages in the test rebuild archive should be given back now that mono did build?
<directhex> doko, is there a list?
<dholbach> debfx, sure
<doko> directhex, sure, see the topic
<Laney> gnome-sharp2 gtk-sharp2 libappindicator launchpad-integration linindicate libreoffice libubuntuone nunit
<Laney> banshee
<Laney> anything in main which reverse-build-depends on mono-devel
<doko> Laney, libreoffice ftbfs on i386 too
<doko> Sweetshark, ^^^
<Laney>  mono-devel : Depends: libmono-cil-dev (= 2.10.3-1) but it is not going to be installed
<Laney> sounds like skew
<doko> thanks! given back
<Sweetshark> doko, Laney: yes, mono-deps in LO are a mess.
<Laney> i'd like to see a build log
<Laney> but it's probably best to disable those bindings
<Sweetshark> Laney: already done
<Laney> not uploaded though?
<Sweetshark> Laney: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-oneirictest-20110718/+sourcepub/1859989/+listing-archive-extra
<doko> Sweetshark, why not test it in the distro?
<Laney> cool
<Sweetshark> Laney: nope, not uploaded. Needs a FFe (because I wasted so much time with mono :/), and I still need to get the LO-l10n to build ...
 * Sweetshark crosses fingers (145/152 modules done)
<directhex> last time i tried to test-build OOo to debug mono problems, it was just filled with fail in other places, so i gave up. couldn't rebuild it locally at all.
<Sweetshark> the mono stuff seems to be mixing mono1 headers and mono2 tooling, which is a path to doom anyway likely.
<Sweetshark> directhex: the official binary downloads on libreoffice.org do not have mono either, but debian does (and we did), so I tried to keep it alive.
<Laney> i suspect upstream no longer cares for that
<doko> lamont, if it's smacking time, please smack the builds on dubnium and hassium too so that I can downscore these
<directhex> Sweetshark, the bindings were part of go-oo, but not ooo upstream
<dholbach> cjwatson, I'll have a look at your meta-gnome2 update - seems we like had a mid-air collision, when I uploaded a merge from debian earlier
<lool> slangasek: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/828014 seems to hit some people switching to multiarch; on my system, /usr/share/doc/libfontconfig1/AUTHORS is a (looping) symlink to ../libfontconfig1/AUTHORS, but that's not what the .deb ship and I couldn't find any maintainer snippet creating these symlinks at install time, so I'm a bit puzzled; if I compare the .debs for i386 they both ship a real file, and the contentsmatch
<ubottu> Ubuntu bug 828014 in fontconfig (Ubuntu) "package libfontconfig1 2.8.0-3ubuntu1 failed to install/upgrade: './usr/share/doc/libfontconfig1/AUTHORS' is different from the same file on the system" [Undecided,Confirmed]
<Sweetshark> directhex: most of go-oo patches have been migrated to the main LO repos though -- but mono wasnt.
<directhex> Sweetshark, i think that's politics
<Sweetshark> directhex: it is ;)
<doko> Daviey, pitti: eucalyptus-commons-ext is still in main
<directhex> plus ca change
<cjwatson> dholbach: I think that merge dealt with a small part of it but that there's still more to go
 * Sweetshark is "member of the engineering steering commitee" for LO
<Sweetshark> directhex: I see enough politics
<dholbach> cjwatson, yep - will have a look
<cjwatson> dholbach: I saw the existing merge but decided that I was going to want somebody who knew GNOME to look at it anyway :-)
<pitti> doko, Daviey: demoting
<lool> slangasek: hmm this might be due to a temporary loss of the Debian diff
<directhex> Sweetshark, i find it particularly amusing when LO/OOo eat microsoft's lunch, and mono doesn't. which is the bigger "danger" to MS's bottom line? therefore which has a bigger target painted on its back?
<Daviey> doko / pitti: thanks!
<Sweetshark> directhex: well, but for the same reason other 800lb gorillas (*cough* IBM *cough*) still care about LO/OOo and might go nuclear in a patent shootout too. mono was always a novell only show -- nobody cared for it, as everyone else used java (either from sun, or their own impl.).
<directhex> true
<poolie> hi tjaalton, i've since upgraded my laptop to oneiric
<tjaalton> poolie: ah, ok. do you get the same regression though?
<OdyX> tkamppeter: Thanks for the fixes to my patch; it was needed indeed.
<Daviey> doko: The fixes you suggested for MIR of bug #
<OdyX> .oO(I spent 2 hours yesterday trying to fix those issues and ended seeing that you had committed that already. :-/ )
<poolie> tjaalton: actually i have been seeing that, i think even on oneiric
<Daviey> doko: bug 825110 have just been uploaded, would you mind ack'ing the MIR if you are happy please?
<poolie> on 3.0.0-7 or -8
<ubottu> Launchpad bug 825110 in prettytable (Ubuntu) "[MIR] prettytable" [Undecided,In progress] https://launchpad.net/bugs/825110
<poolie> i thought i filed another bug (which would be a dupe of this)
<poolie> ... but thinking back i actually i did not
<doko> Daviey, ok, will do
<tjaalton> poolie: ok, could you post your findings on the newer bug I mentioned, it would be valuable to find another machine with this issue..
<tjaalton> err, we found that, but would be nice for others to know about it too :)
<poolie> tjaalton: xchat crashed, that was exciting
<poolie> anyhow, i can reproduce some similar stuff
<tjaalton> poolie: ok, that might still be relevant to the bug
<Daviey> doko: thanks!
<tjaalton> 14:55 < tjaalton> poolie: ok, could you post your findings on the newer bug I mentioned, it would be valuable to find another machine with this issue..
<tjaalton> 14:55 < tjaalton> err, we found that, but would be nice for others to know about it too :)
<poolie> bug 814325?
<ubottu> Launchpad bug 814325 in Linux "fuzzy and corrupted display with update in natty-proposed" [Medium,Confirmed] https://launchpad.net/bugs/814325
<poolie> i'll boot it up and see if that's actually true
<tjaalton> poolie: yep
<tjaalton> there's a simple script to help in reproducing the issue
<mdeslaur> cyphermox: are you planning an evo upload soon? if not, I'll take care of bug 828693 later today
<ubottu> Launchpad bug 828693 in evolution (Ubuntu) "Uses wrong path for spamd binary" [Undecided,New] https://launchpad.net/bugs/828693
<poolie> ok
<poolie> 615MB of updates first
<poolie> (!)
<tjaalton> hehe
<doko> Daviey, package new'ed, will promote it in the next cycle
<hggdh> Sweetshark: pong
<Sweetshark> hggdh: thanks, already solved it was about my expiring bugcontrol membership.
<hggdh> Sweetshark: ah, OK.
<doko> directhex, Laney: nunit failed again
<Laney> i think that one awaits a sync
<Laney> doko: got a link to the build log, please?
<Laney> it's not on the index yet
<doko> Laney, https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+builds?build_text=&build_state=failed
<doko> seb128, pitti: fyi started the next batch of test rebuilds
<seb128> doko, ok
<Daviey> doko: thans
<Daviey> thanks*
<dholbach> can somebody please mark https://code.launchpad.net/~gal-fourier/ubuntu/natty/opencv/bug-756154/+merge/68171 as obsolete? it seems like all the related bugs are fixed in a newer version already
<ubottu> Ubuntu bug 68171 in tomboy "error in desktop file" [Medium,Fix released]
<StevenK> dholbach: You should be able to ?
<dholbach> StevenK, it's "natty" - so it looks like I can't
<StevenK> Hm, even I can't.
<dholbach> I guess only james_w or cjwatson can close https://code.launchpad.net/~gal-fourier/ubuntu/natty/opencv/bug-756154/+merge/68171
<ubottu> Ubuntu bug 68171 in tomboy "error in desktop file" [Medium,Fix released]
<james_w> dholbach, rejected
<dholbach> thanks james_w!
<smb> pitti, Just playing around with latest Oneiric and got a crash that pointed me to bug 827176. Funny thing is that I did not have language-selector installed (only language-selector-common and language-selector-gnome). Even with having run install ubuntu-desktop^ before...
<ubottu> Launchpad bug 827176 in language-selector (Ubuntu Oneiric) "fontconfig-voodoo crashed with DBusException in call_blocking(): org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist" [High,Fix released] https://launchpad.net/bugs/827176
<pitti> dholbach: hm, you didn't push the udev upload into the branch, can you please do?
<dholbach> :-( will do
<pitti> thanks!
<tkamppeter> OdyX, did you run into the ppds.dat mess, too?
<OdyX> tkamppeter: no.
 * smb wonders which package a bug about "the new iconify and de-fullsize buttons are the worst visual design I ever have barely seen" would be reported
<OdyX> tkamppeter: I'm currently migrating foomatic-db to the cups triggers and to dh_pyppd. It's fun.
<tkamppeter> OdyX, I see a lot of printer driver package uploads, are they all to make use of the centralized PPD update and the new Debian Helper for pyppd?
<dobey> smb: whatever theme they're in i guess
<OdyX> tkamppeter: yes, + new upstream release for foo2zjs
<smb> Would be the default then.. whatever that is called in Oneiric...
<tkamppeter> OdyX, the ppds.dat problem I only discovered with HPLIP when I migrated it to the centralized update (so it now only needs the pyppd change).
<OdyX> tkamppeter: so far, foomatic-db-engine, foo2zjs, c2esp and epson-inkjet-printer-driver have been migrated (the latter to multiarch too)
<pgraner> pitti, just hit https://bugs.launchpad.net/ubuntu/+source/apport/+bug/828010 which is marked fixed released and I'm fully updated
<ubottu> Ubuntu bug 828010 in apport (Ubuntu) "apport-gtk crashed with TypeError in function(): markup_escape_text() takes exactly 2 argument(s) (1 given)" [High,Fix released]
<pgraner> pitti, not sure how you wanted in the report
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<shadeslayer> hey, anyone around to correct a small problem on http://developer.ubuntu.com/packaging/html/packaging-from-scratch.html ?
<nigelb> dpm: ^
<Laney> there should probably be a footer showing how to file bugs
<Laney> shadeslayer: please file a bug https://bugs.launchpad.net/ubuntu-packaging-guide
<nigelb> oooh, that's our packaging guide!
<Laney> there's another one?
<nigelb> no, I think it just found its permanent home.
<dpm> thanks nigelb for the heads up. dholbach takes care of that bit of developer.ubuntu.com ^
<nigelb> instead of people.ubuntu.com/~dholbach
<Laney> uh
<dpm> yeah, that's correct
<Laney> that page doesn't mention workflow for getting it into the distro really
<dholbach> I put it on my TODO list to create a redirect
<nigelb> shadeslayer: branch, fix, and propose a merge! https://code.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk
<Laney> or going through Debian, which dholbach wrote a wiki page about recently
<nigelb> Laney: How long is this mono compliation going to take? (2-core machine)
<Laney> hour or so
<Laney> less if it fails :-)
<nigelb> heh
<dpm> Laney, there's a link at the bottom of the page that takes you to how to upload packages "See uploading for more information."
<Laney> dpm: there is a bit of a specific workflow for new packages
<dpm> Laney, ah, ok. I'm not involved in the guide, I was just pointing that bit out. dholbach should be able to tell you where to best discuss the structure and any missing content from the guide
 * shadeslayer shall fix on his own
<pitti> pgraner: what's the version in dpkg -l apport-gtk ?
<hrw> cyphermox: can you take a look at http://paste.ubuntu.com/669242/ diff? It has all changes which were needed to build network-manager-applet without indicator support. also had to disable -Werror
<hrw> cyphermox: changes are not usable for default ubuntu package anyway
<ScottK> slangasek: Does http://paste.debian.net/126597/ look like it might be related to the multi-arched qt4-x11?
<hallyn> If a package's x.install currently says "usr/lib/python2.6/dist-packages/", is changing that to "usr/lib/python*/dist-package/" ok?
<ScottK> hallyn: Generally, yes.
<dobey> morning ScottK
<ScottK> Hello dobey.
<hallyn> ScottK: thx
<ScottK> I find I'm a bit unclear what the U-one package you've got a pending FFe for is supposed to accomplish.
<dobey> hallyn: i also do *-packages, to deal with differences in python versions where site-packages might be used instead of dist-packages (if you care to support many versions from one debian/ dir)
<dobey> ScottK: it installs ubuntu one.
<ScottK> site-packages is only python < 2.5
<ScottK> dobey: So why is it needed?
<dobey> the reasons chipaca mentioned in his comment on the bug; it is a result of the discussion from https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-updates-for-network-clients at UDS
<ScottK> pitti: ^^^ This is exactly what I think the TB needs to approve.  It's not aligned with the current policy.
<ScottK> dobey: Thanks.
<pitti> but I thought that installer would specifically not enable a PPA, but just install the Ubuntu packages instead?
<pitti> ScottK: agreed
<pitti> but I'm confused since the bug report says it would not do taht
<dobey> what current policy?
<hallyn> not sure i'm quite following, but i'll do *-packages just in case, thanks :)
<pitti> just providing an aptdaemon shim to install u1 packages from ubuntu doesn't need TB approval, that's similar to our codec installer or what u1 already does right now (install desktopcouch when you want extra services, etc.)
<pitti> dobey: SRU
<ScottK> pitti: Agreed.
<pitti> so there seem to be two different claims in that bug: (1) provide a spec implementation, which entails PPAs, etc. (2) merely provide an installer
<pitti> dobey: ^ so which is it then?
<ScottK> I don't think that's what this is about though (although you might get that as a side benefit).
<ogra_> hmm, is anyone else seeing nm-applet leak memory ? i just killed it with 42MB reserved mem
<dobey> pitti: it is now currently only an installer
<ScottK> Of what?
<dobey> ubuntu one
<ScottK> From?
<dobey> whatever archives the user has installed at the time of running the installer
<dobey> s/installed/enabled/
<ScottK> And the functionality to enable additional repositories?
<dobey> isn't there
<dobey> user has to apt-add-repository now
<pitti> that seems fine to me
<dobey> well the code is there, but it doesn't get run now. we simply update the cache and do the installe
<ScottK> Not even a command line option?
<pitti> (FWIW, I'd even accept a pure CLI -- add-apt-repository is about as easy to use as any CLI from that new package, after all, and even has apturl support)
<dobey> ScottK: not currently there isn't no. there is a bug to add that though
<dobey> ScottK: but may or may not do that for Oneiric
<ScottK> pitti: Would you accept a scribus package with CLI option to add the scribus PPA?
<ScottK> We have, in the past, not allowed packages to add PPAs (I think for good reason).
<ScottK> I don't think we should change that.
<pitti> ScottK: ah, we didn't? ok
<ScottK> pitti: envy-ng was the first one I remember coming up.
<dobey> fwiw, there is no specific documentation in the Ubuntu Policy Manual about PPAs, afaict
<ScottK> It me it seems relatively obvious that if the user wants to reconfigure their system to allow third-party software it should be done via the package management system.
<ScottK> Allowing applications to bootstrap themselves outside the Ubuntu archive just doesn't seem a good idea.
<ogra_> software-center has a channel specification, we use it with the ti omap4 ppa for the
<pitti> eek - new LP now auto-sets bugs to "confirmed" on any response?
<pitti> bug 828751
<ubottu> Launchpad bug 828751 in pygobject (Ubuntu) "[FFE] update pygobject to 2.90.1" [Undecided,Confirmed] https://launchpad.net/bugs/828751
<ogra_> HW specific addon packages
<dobey> well it doesn't matter. we're past that. ubuntuone-installer doesn't add a PPA
<seb128> pitti, it should do it when somebody clients "it affects me as well"
 * pitti sets it back to New
<pitti> seb128: ah
<dobey> pitti: if it was New, and it gets a dup or someone clicks "affects me too" it does i think
<seb128> pitti, which seems to be the case there
<seb128> pitti, it does make sense since "confirmed" should be "somebody else confirm it's a valid bug"
<pitti> ok, so that just fails on exception requests then
<seb128> pitti, what does "confirmed" means for those?
<seb128> pitti, the process should perhaps be changed to use triaged or in progress?
<pitti> "approved"
<pitti> just like for sync requests, etc.
<seb128> we should change to use "Triaged" I guess
<pitti> yeah, perhaps; but so far "confirmed" seemed to grasp "approved" best
<dobey> pitti: not to interfere with your annoyance with LP, but back to me :)
<pitti> ScottK: do you have more questions to dobey about this?
<ScottK> pitti: No.  As long as it is just an installer and doesn't have the CLI (or other) option for adding PPAs, I think it's a release team decision.  I'm fine with whatever you decide.
<hrw> did someone got situation when linux see mouse (/dev/input/eventX created, evtest with it works) but x11 does not use this mouse?
<mdeslaur> cyphermox: hello?
<pitti> dobey: bug 817133 updated
<nigelb> Laney: sucess
<ubottu> Launchpad bug 817133 in Ubuntu "[FFe] [needspackaging] ubuntuone-installer needs packaged" [High,Confirmed] https://launchpad.net/bugs/817133
<nigelb> Laney: err, success.
<cyphermox> hrw: I don't get what you mean, you don't need todo that much work for it; just disable the patch that adds indicator support
<cyphermox> mdeslaur: yo
<mdeslaur> cyphermox: did you see my question earlier?
<nigelb> Laney: Rather, I think it was a success, I don't see failure anyway, and I see lots of deb references
<nigelb> tumbleweed: ^
<cyphermox> hrw: but then I don't see what you mean about not usable for the default package. nm-applet is meant to have indicator support, it just needs to be fixed for the cases where indicators fallback
<dobey> pitti: great, thanks. can you upload? :)
<cyphermox> mdeslaur: yes, finishing up on evo 3.1.5, which I was going to upload within minutes
<pitti> dobey: looking
<mdeslaur> cyphermox: ah, cool...that's what I wanted to know. thanks.
<hrw> cyphermox: sure, I could just disable indicator patch and do build. but I wanted to check will it build with this patch applied but functionality disabled
<hrw> cyphermox: it did not so I hacked sources a bit to get them built. waste of time anyway
<cyphermox> hrw: right, but disabling the patch will let it build just fine without indicator, so I'm not sure what you're trying to achieve
<hrw> cyphermox: if/when indicator.patch will get merged upstream then build will fail for those without indicator. merge my changes into indicator.patch and both worlds will be happy with indicator.patch merged
<cyphermox> not really
<cyphermox> not using --enable-indicator should do the same (not sure of the syntax, but it's build-time configurable
<pitti> dobey: uploaded
<dobey> pitti: thanks again!
<hrw> cyphermox: I did build without --enable-indicator and it failed when indicator.patch was applied
<pitti> dobey: you're welcome
<cyphermox> ok, then that's different, but the patch looks a little weird. that said, I haven't tried to apply it and build
<hrw> cyphermox: I suxx when it comes to gtk apps code so thats why patch is hacky
<cyphermox> heh, it comes with time, don't worry
<slangasek> lool: right, sounds like transient package breakage; do you think this was widespread enough that we should upload libfontconfig1 with a preinst to fix the symlink?
<cyphermox> I'm just pretty sure that wouldn't work for both "worlds"
<hrw> cyphermox: I am avoiding gtk code for ~7 years now
<slangasek> ScottK: yes, I think http://paste.debian.net/126597/ gets fixed with a no-change rebuild of akonadi
<ScottK> slangasek: Thanks.  I'll have a go at that.
<ScottK> slangasek: Also I just accepted qt4-x11 with qdbus.  Thanks for getting that fixed up.
<hrw> cyphermox: anyway - nm-applet built without indicator support works great here. finally have icon and menu
<Ursinha> jelmer_: hello! could you help me out with a couple of bugs? I'm doing some bug cleanup and bug 707563 might be a duplicate of bug 596064
<ubottu> Launchpad bug 707563 in samba (Ubuntu) "package samba 2:3.5.6~dfsg-4ubuntu2 failed to install/upgrade: le sous-processus script post-installation installÃ© a retournÃ© une erreur de sortie d'Ã©tat 1" [Undecided,Fix released] https://launchpad.net/bugs/707563
<ubottu> Launchpad bug 596064 in samba (Ubuntu Maverick) "nmbd fails to start on boot - problem with upstart " [Medium,Triaged] https://launchpad.net/bugs/596064
<slangasek> ScottK: sure
<ScottK> slangasek: Any idea if anything else needs rebuilding (or how I can tell)?
<slangasek> ScottK: no idea
<jelmer_> Ursinha: Hey! Sure, I'll have a look.
<cyphermox> hrw: cool. in any case, I'll fix the fallback so it works properly, but for now it appears to be broken. My guess is that some signalling between nm-applet and libappindicator/dbusmenu isn't quite working for that case
<Ursinha> jelmer_: thanks. :) If that happens to be true, so I'm afraid we have a lot of recent samba bugs that are dupes of the older bug as well
<hrw> cyphermox: ok - I can work as guinea pig for tests if needed
<cyphermox> hrw: ok. I'll try to get something out today
<hrw> cyphermox: hrw@canonical.com as I will end work in ~30 minues
<Laney> nigelb: oh, that's sad. cheers anyway
<cyphermox> sure sure
<doko> ev, camerabin now built from neither bad nor good?
<lool> slangasek: I wondered the same, there were only 3 people affected in the bug including me and 2 bug reports including mine, but I decided that it was easy enough to add a snippet and remove this post oneiric
<slangasek> lool: well, go for it :)
<lool> slangasek: Just uploaded a minute ago
<slangasek> yay
<ev> doko: it's built from good
<ev> UGH
<lool> slangasek: the only other ill effect I'm seeing so far is LP #828807, which seems to be an aptitude bug (albeit it might affect apt too?)
<ubottu> Launchpad bug 828807 in aptitude (Ubuntu) ""forget new packages" broken since multiarch is enabled" [Undecided,New] https://launchpad.net/bugs/828807
<ev> doko: actually, my range was a bit premature, camerabin is in -good
<hrw> pitti: can you check https://bugs.archlinux.org/task/25356 for udev? my BT mouse got ignored by X11 due to that
<slangasek> lool: ah, I'm unfamiliar with this aptitude feature
<hrw> pitti: bug 828814 at launchpad
<ubottu> Launchpad bug 828814 in udev (Ubuntu) "Bluetooth mouse is not working under X11" [Undecided,New] https://launchpad.net/bugs/828814
<pitti> hrw: could that be a dupe of bug 827489?
<ubottu> Launchpad bug 827489 in udev (Ubuntu) "Bluetooth keyboards and mice stopped working in X server" [Undecided,Fix released] https://launchpad.net/bugs/827489
<pitti> hrw: that got fixed in 173-0ubuntu2
<lool> slangasek: basically helps picking up new binary packages as they appear; only packages which were never seen are listed; pressing "forget" empties the list
<lool> acts a bit like a subscription to binary NEW  :-)
<hrw> pitti: again you people are faster then me ;)
<hrw> pitti: will check upgraded package
<pitti> hrw: thanks
<jelmer_> Ursinha, so, it seems like there are two related issues
<jelmer_> Ursinha: the fact that testparm is being called before the various directories in /var/ are created, and the problems with the net-device line
<tumbleweed> lool: aha!, you found the fontconfig symlink thing I ran into and got to the bottom of it, \o/
<slangasek> lool: yep... guess someone needs to poke aptitude for this, I don't think apt has any equivalent
<nigelb> Laney: wait, sad
<nigelb> ?
<Laney> we are trying to reproduce a failure
<nigelb> haha
<nigelb> oh
<nigelb> man, that was depressing. I had a successful build and I get "thats sad!"
<Laney> :P
<directhex> sorry, can't reproduce on any of our hardware. someone mail me vernadsky since that consistently fails
<hallyn> kees: hey, do you know of a way to make sbuild build in an existing session?
<kees> hallyn: I haven't tried, but I generally just use "debuild -uc -us" in those situations
<kees> hallyn: it's close, but not perfect
<hallyn> i wanted to verify that package versions listed in dependencies will be ok
<hallyn> debuild will do that though?  i'll do that, thx
<pgraner> pitti, ii  apport-gtk     1.21.3-0ubuntu
<kees> hallyn: oh, debuild won't do build-deps
<kees> hallyn: it'll verify them, but not fetch them
<pitti> pgraner: ah, of course it got cut off at the very point when it gets interesting
<pitti> pgraner: can you please try "dpkg -l apport-gtk | cat"?
<hallyn> kees: ok, verify is all i wanted.
<hallyn> kees: thanks
<pgraner> pitti, ii  apport-gtk                             1.21.3-0ubuntu4
<dhana013> Hi trying building with vim package using cdbs
<dhana013> I am trying with building with vim using cdbs.. I included these rules
<dhana013> root ~/test/vim-7.3.035+hg~8fdc12103333 # cat debian/rules
<dhana013> #!/usr/bin/make -f
<dhana013> include /usr/share/cdbs/1/rules/debhelper.mk
<dhana013> include /usr/share/cdbs/1/class/autotools.mk
<dhana013> include /usr/share/cdbs/1/class/gnome.mk
<dhana013> include /usr/share/cdbs/1/class/perlmodule.mk
<dhana013> I got error like this please guide me
<dhana013> dh_installinfo: cp README.txt.info Contents.info runtime/icons.info
<dhana013> runtime/macros/README.txt.info runtime/macros/hanoi/poster.info
<dhana013> runtime/macros/hanoi/click.me.info runtime/macros/urm/README.txt.info
<dhana013> runtime/macros/maze.info runtime/macros/urm.info
<dhana013> runtime/macros/life/click.me.info runtime/macros/hanoi.info
<dhana013> runtime/macros/maze/poster.info runtime/macros/maze/README.txt.info
<dhana013> runtime/macros/maze/maze_5.78.info runtime/tutor/README.txt.info
<dhana013> runtime/tutor/tutor.info runtime/tools.info runtime/doc/help.txt.info
<dhana013> runtime/doc/vim.man.info runtime/doc.info runtime/tutor.info
<dhana013> runtime/icons/README.txt.info runtime/icons/Vim_32Colors.info
<dhana013> runtime/icons/Vim_4ColorsLace.info runtime/icons/Vim_8ColorsLace.info
<dhana013> runtime/icons/Vim_8Colors.info runtime/macros.info vimdir.info
<dhana013> README_amibin.txt.info README_amisrc.txt.info README_ami.txt.info
<dhana013> src.info runtime.info Vim.info Xxd.info debian/vim/usr/share/info
<dhana013> returned exit code 1
<dhana013> make: *** [binary-install/vim] Error 2
<dhana013> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
<dhana013> debuild: fatal error at line 1340:
<dhana013> dpkg-buildpackage -rfakeroot -D -us -uc failed
<dhana013> please guide me
<hallyn> kees: I swear I used to be able to use '--chroot-setup-commands "dpkg -i xyz.deb"', but now it says i don't have privilege when i try that
<ScottK> slangasek: You put kscope on the sync blacklist due to being kde3.  It's now a Qt4 application (but with the same package name).  Would you pelase remove it from the sync blacklist so we get it back next cycle?
<slangasek> sure
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
<kees> hallyn: yes, that used to work; the patch regressed. I was actually going to fix that today.
<Ursinha> jelmer_: and is that detectable by the files attached to the bugs? or the comments?
<hallyn> kees: awesome!
<jelmer_> Ursinha, bug 596064 is the testparm issue, bug 750786 is the other issue
<ubottu> Launchpad bug 596064 in samba (Ubuntu Maverick) "nmbd fails to start on boot - problem with upstart " [Medium,Triaged] https://launchpad.net/bugs/596064
<ubottu> Launchpad bug 750786 in samba (Ubuntu) "nmbd job fails to start on boot" [Low,Incomplete] https://launchpad.net/bugs/750786
<jelmer_> Ursinha, The tracebacks seem to suggest bug 596064 is a dupe of 707563; the user that was encountering the other issue filed bug 750786
<ubottu> Launchpad bug 596064 in samba (Ubuntu Maverick) "nmbd fails to start on boot - problem with upstart " [Medium,Triaged] https://launchpad.net/bugs/596064
<ubottu> Launchpad bug 750786 in samba (Ubuntu) "nmbd job fails to start on boot" [Low,Incomplete] https://launchpad.net/bugs/750786
<kees> hallyn: okay, sbuild fix uploaded. thanks for the reminder. :)
<hallyn> kees: awesome, thanks :)
<SpamapS> oooo Chrome grew print preview
<cjwatson> cyphermox,jelmer: any chance of an evolution-mapi update?  it fails to build and it's built against old EDS libraries ...
<cyphermox> cjwatson: already on it :)
<cjwatson> excellent, ta
<cyphermox> jelmer had 3.1.4 ready; but we're uploading 3.1.5, so we'll get that in shortly
<cjwatson> lots of evolution stuff on http://people.canonical.com/~ubuntu-archive/nbs.html
<cjwatson> I know you only just changed soname
<cyphermox> yeah, and already been working to clean that up
<cyphermox> I'll get back to it once 3.1.5 is in
<cjwatson> ev: I've NBS-removed gstreamer0.10-camerabin since it looks like you just moved that into the gstreamer0.10-plugins-good package directly; hope that's OK
<ev> cjwatson: thanks!
<cjwatson> (... ubiquity upload soon then? :-) )
<ev> yes, I'll do that now
<doko> \o/
<infinity> Didn't that just move out of a plugins bundle package a few weeks ago? :)
<ev> ...yes...
<cjwatson> infinity: but -bad
<infinity> Yeah.
<cjwatson> no good for MIRage
<ev> silly, really
<infinity> Just curious about the middle step. :)
<cjwatson> it was a mistake I think
<infinity> I hope it enjoyed its brief freedom.
<ev> well I did it
<cjwatson> *shrug* rectified now
<infinity> It's like moving out of your parents' place, only to move in with your girlfriends' parents a month later.
<infinity> Poor thing.
<ev> but I mean, I think it's silly that I have to move a portion of a source tree from one place to another because we have this restriction in place
<slangasek> heh
<ev> rather than just saying "these files go into main"
<slangasek> it's the lesser evil
<slangasek> because we don't do MIR review for binary packages, which would be a much greater burden
<ScottK> doko: Can you retry packages from the rebuild?  I'd like to see if a bunch of KDE stuff builds now thanks to rebuilding akonadi.
<slangasek> ev: I think you need a bumped versioned Breaks/Replaces on gstreamer0.10-plugins-bad from gstreamer0.10-plugins-good
<doko> ScottK, sure, just make sure that it's already in the archive
<slangasek> ev: since camerabin was in -bad until 0.10.22-2ubuntu2, and the current Breaks/Replaces doesn't cover the version that was in natty
<slangasek> ev: er, no, it does cover that version... so it's only an issue for people who are running oneiric but upgrade infrequently
<ScottK> doko: Will do.  Turns out it's not there yet.
<seb128> ev, bug #828845 is yours
<ubottu> Launchpad bug 828845 in gst-plugins-good0.10 (Ubuntu) "package gstreamer0.10-plugins-good 0.10.30-1ubuntu4 failed to install/upgrade: trying to overwrite '/usr/lib/gstreamer-0.10/libgstcamerabin.so', which is also in package gstreamer0.10-plugins-bad 0.10.22-2ubuntu1" [Undecided,New] https://launchpad.net/bugs/828845
<slangasek> heh, yes
<kees> hggdh: hi! the ajaxterm patch looks good. do you need that uploaded, or do you have a sponsor for it already?
<hggdh> kees: no sponsor; Daviey would look at it, but he is busy as hell
<hggdh> kees: so, if I can impose on you...
<hggdh> kees: a question there -- we will now have a delta, is this an issue?
<kees> hggdh: it's not an issue, but it'd be nice to send the patch to Debian in the form of a bug report (see the "submittodebian" tool for more details)
<hggdh> kees: roger, will do
<ev> new ubiquity is up. I'll take care of the rest tomorrow
<seb128> ev, saw the bug I pointed before?
<SpamapS> hmm interesting situation
<SpamapS> http://people.canonical.com/~ubuntu-archive/nbs.html confirms it.. libdbi0-dev .. which was built by libdbi, but is not just a virtual package provided by libdbi-dev .. seems to be blocking the use of libdbi-dev for compiling..
<SpamapS> s/but is not/but is now/
<SpamapS> slangasek: I guess I need to complete that AA training so I can handle these things myself. :)
<slangasek> SpamapS: heh; libdbi0-dev nuked
<kees> hggdh: I made a few changes (Last-Update was july instead of august, filled in my name as reviewer, and clarified the description)
<kees> hggdh: if you're about to forward it to debian, I can wait to upload so that we can add the debian bug # to the ubuntu upload...
<hggdh> kees: thank you; I expected the reviewer to be filled...
<hggdh> kees yes, I am. Should I send the whole diff, or edit out the changes to control?
<kees> hggdh: I would leave out the maintainer changes when forwarding
<hggdh> kees: will do now
<kees> hggdh: okay, cool. I'll upload it when you get the bug # back from the debian tracker. :)
<cjwatson> SpamapS: yes, the NBS list does occasionally have incorrect cases in its dependency checking
<mdeslaur> micahg: looks like it has the translations in it now, since it got demoted to universe
<micahg> ah, didn't know it finally got demoted, ok, no issue then ,thanks
<mdeslaur> micahg: is this a problem?
<micahg> mdeslaur: no, it'll sort itself after the next translations update then
<mdeslaur> micahg: why did you notice that? did you have an issue with something?
<micahg> mdeslaur: a 4MB increase in install size for a wrapper fix seemed bad :)
<mdeslaur> micahg: how did you notice that? :)
<mdeslaur> micahg: you've got me curious now :)
<micahg> mdeslaur: aptitude FTW!
<seb128> doko, infinity, cjwatson: could somebody score up https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587
<seb128> ?
<seb128> it's the unity weekly update, I would like to get a ppa build for testing before uploading to the archive
<cjwatson> seb128: done
<seb128> cjwatson, thanks ;-)
<mdeslaur> micahg: hehehe
<doko> cjwatson > 10000
<doko> (done)
<cjwatson> 5000 said "1 minute"
<cjwatson> but OK
<seb128> hum
<seb128> failed again :-(
<seb128> https://launchpadlibrarian.net/77530994/buildlog_ubuntu-oneiric-i386.unity_4.8.2-0ubuntu1~build1_CHROOTWAIT.txt.gz
<seb128> "sudo: no valid sudoers sources found, quitting
<seb128> *** glibc detected *** sudo: double free or corruption (!prev): 0x0000000000629ff0 ***
<seb128> ======= Backtrace: =========
<seb128> /lib/libc.so.6[0x7f2598a970ea]"
<seb128> I got 3 broken i386 builds in a row due to that
<seb128> did we broke oneiric?
<seb128> or is that a buildds issue?
<doko> seb128, save the log and try again?
<seb128> doko, the one you scored was a retyr
<seb128> retry
<seb128> it failed the same way 15 minutes ago
<seb128> gobject-introspection from pitti in the same ppa failed the same way on i386
<seb128> I retried it but it's not going to try before some hours
<seb128> i.e that's 3 i386 builds that failed this way in a row
<seb128> doko, https://launchpad.net/builders/shipova/+history
<seb128> doko, could be the builder which is broken
<seb128> it's doing that on all builds it tries
<seb128> doko, I've retried the build if you could rescore it again
<seb128> https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587
<doko> seb128, done
<seb128> doko, thanks
<seb128> doko, I guess it's going to fail again, it picked the broken builder
<seb128> which I guess it's because all others are busy
<doko> seb128, shipova? I could disable this one
<seb128> doko, yes, see https://launchpad.net/builders/shipova/+history
<seb128> doko, that would be nice
<seb128> doko, ok, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587 to rescore once shipova is down
<seb128> thanks a lot, I appreciate the help on that ;-)
<hggdh> kees: debian bug 638332
<ubottu> Debian bug 638332 in ajaxterm "ajaxterm: updates required for Main inclusion on Ubuntu" [Normal,Open] http://bugs.debian.org/638332
<doko> seb128, done
<Daviey> kees: Are you taking hggdh's branch?
<kees> Daviey: yup, almost hav eit uploaded now
<Daviey> kees: That is great, thanks!
<kees> np! :)
<hggdh> kees: BTW, thank you very much, I really appreciate the help
<kees> hggdh: sure thing!
<seb128> doko, can you rescore https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587 as well?
<ScottK> doko: Can you retry kdepimlibs in the rebuild test?  It should work and then if that does, I'll have some others to try ...
<doko> seb128, ScottK: done
<seb128> doko, thanks
<tkamppeter> pitti, hi
<tkamppeter> Any multiarch lib package expert around? I get always an error like this if an i386 version of a multiarch lib gets installed:
<tkamppeter> Unpacking libcups2:i386 (from .../libcups2_1.5.0-3_i386.deb) ...
<tkamppeter> dpkg: error processing /var/cache/apt/archives/libcups2_1.5.0-3_i386.deb (--unpack):
<tkamppeter>  './usr/share/doc/libcups2/changelog.Debian.gz' is different from the same file on the system
<tkamppeter> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<tkamppeter> And this is not a problem of CUPS, I had it with another package before.
<infinity> I wonder if this is a product of our changelog mangling...  Though every binary should still have the same changelog.
<infinity> In theory.
<infinity> slangasek: ^-- You have better theories?
<micahg> tkamppeter: if you built that locally and installed w/out pkgbinarymangler running, you would probably get that result
<infinity> Oh, there's that, yes.
<infinity> tkamppeter: Local builds?
<micahg> ugh, that was unclear, if the local build didn't run pkgbinarymangler that would cause this
<infinity> micahg: It was clear to me. ;)
<slangasek> tkamppeter, infinity: two typical causes: 1) it's a library that you've done a local build of (perhaps because it was your upload and you tested it locally first), so your already-installed package doesn't match the one built in the archive due to things like changelog mangling and doc symlinking; 2) in some cases (such as the fontconfig issue mentioned in scrollback), a conversion between symlink and file may have gone wrong on your sys
<slangasek> ... past, resulting in a mismatch
<infinity> micahg: (But that was obvious from my questioning changelog mangling initially)
<micahg> infinity: indeed
<ScottK> doko: Thanks.
<slangasek> oh man - a user's biggest complaint about multiarch is the spurious warning messages from the gtk postinst. https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/646954/comments/18
<tkamppeter> slangasek, infinity, micahg, thanks, at least for the CUPS package this is the case. The current release of the CUPS package is done by me and on exactly this machine.
<ubottu> Ubuntu bug 646954 in ibus "failed to load 32bit ibus immodules (im-ibus.so)" [Undecided,Confirmed]
<slangasek> tkamppeter: so to fix this, I would do 'sudo apt-get install --reinstall libcups2' to get the version from the archive installed
<slangasek> (the same for any other affected packages)
<slangasek> if it still fails for you on any package, that would merit a bug report
<tkamppeter> slangasek, OK, done so.
<SpamapS> slangasek: thanks!
<doko> no evan ... libcheese1 still depends on gst-bad
<doko> ev: ^^^
<slangasek> doko: that's odd, why does the library depend on any of those?
<slangasek> doko: cheese fix uploaded
<pitti> ev: I thought ubiquity would drop the cheese b-dep, and just use gst directly?
<pitti> ubiquity is in depwait now, as cheese is in universe
<slangasek> from context, sounds like doko is reviewing an MIR for this already?
<slangasek> and it's per se correct for libcheese1 to drop the dep on -bad now
<pitti> that's right
<pitti> but the current cheese is quite heavy
<slangasek> well, but not libcheese1, which is only 60k
<pitti> it pulls in clutter (which we don't want on the CDs, and not in general because it has rather poor hw support), and also stuff like mx
<slangasek> although when speaking of cheese, 60k does sound like a lot
<slangasek> oh, indeed
<pitti> lol
<pitti> right, I meant heavy in terms of MIR dependencies, not CD space this time
<slangasek> right, that doesn't sound like a good thing
<seb128> slangasek, pitti: ev said the other day he would use gst directly and not cheese
<slangasek> ok
<slangasek> seems that's not what's been uploaded so far; I guess we need ev to comment
<pitti> slangasek: earlier, the cheese b-dep was just unused; perhaps he just forgot to drop it
<ScottK> doko: Would you please try kdepim/kdepim-runtime for the rebuild?
<kees> slangasek: I'm looking at the pam merge to get the syslog debug bug fix, but wanted to run some of the changes by you just to double-check: http://paste.ubuntu.com/669532/  (doesn't include the new ubuntu changelog entry for the merge yet)
<hallyn> doko: hi, for bug 823711, did you have a debdiff or something?  (the lp tree isn't showing me where the fix was localized.  Want to make sure i preserve it in a debian merge)
<ubottu> Launchpad bug 823711 in gcc-4.6 (Ubuntu Oneiric) "libvirt version 0.9.2-4ubuntu8 failed to build on armel" [High,Triaged] https://launchpad.net/bugs/823711
<hallyn> doko: ah, I see, there's a patch under debian/patches/.  thanks.
<slangasek> kees: hmm, what are the version bumps for?
<kees> slangasek: that was one of my questions. that's what in Debian's postinst/control. I figured moving it later wouldn't hurt
<kees> slangasek: (in the interest of reducing the ubuntu to debian delta)
<doko> ScottK, done
<doko> hallyn, wait for the next gcc-4.6 upload, and it won't be needed anymore
<doko> after a rebuild of libnl3
<slangasek> kees: ah, I guess those are the versions that first introduced multiarch in each of Debian/Ubuntu.  The control changes should be ok, apt can sort it out for natty->oneiric upgrades and for lucid->p it makes no difference
<slangasek> kees: I would shy away from bumping the versions in preinst/postinst just yet, because I still need to bugfix how we're doing the debconf prompts
<kees> slangasek: that was my thinking, but I wanted to be sure there wasn't anything fishy going on :)
<slangasek> (per UDS discussions)
<kees> slangasek: ah, okay, I can switch those back.
<hallyn> doko: when will that (gcc-4.6 upload) be?
<doko> don't know yet, sorry
<hallyn> doko: ok, thanks
<doko> slangasek, ev: now gnome-video-effects is a b-d of cheese, and still keeps gst-bad in main, afaics
<doko> anyway, afk now
<ScottK> slangasek: https://bugs.launchpad.net/bugs/828999 looks like more multu-arch fallout.
<ubottu> Ubuntu bug 828999 in wxwidgets2.8 (Ubuntu) "wxDisplay unexpectedly disabled" [Undecided,New]
<slangasek> ScottK: hmm, in natty even it seems :/
<ScottK> Yep.
<slangasek> cjwatson: when you do have openssl0.9.8 available, I'd like to know so I can update ia32-libs to include it
 * micahg thought openssl0.9.8 was going the way of the dodo in oneiric
<slangasek> <cjwatson> slangasek: partly because, even if we do manage to fix everything in the archive, libssl seems like the sort of thing people are not unlikely to have local binaries built against
<micahg> ah
<slangasek> FSVO "local binaries" that includes "acrobat reader", apparently :-)
 * micahg hugs slangasek for updating ia32-libs
<micahg> and behold, the source tarball fits on a CD again :P
<slangasek> just barely ;)
<micahg> you shaved almost 300MB off
<micahg> and the binary itself was reduced by ~50%
<slangasek> yeah, it was in need of some gardening
<cjwatson> ogra_: please push your livecd-rootfs changes to lp:livecd-rootfs
#ubuntu-devel 2011-08-19
 * ScottK shakes fist at slangasek.
<ScottK> Multi-arching qt4-x11 broke python-qt4 builds too.
<StevenK> ScottK: So you'd prefer qt4-x11 wasn't multi-arch? :-)
<ScottK> I'd prefer I'd understood what was going to happen better before I approved the FFe.
<ScottK> StevenK: Are you in the mood for some removals?
<StevenK> I'm *always* in the mood for some removals
<micahg> hehe
<ScottK> Excellent.
<StevenK> ScottK: I'm about to hit up lunch, so toss me a list and I'll look soon
<ScottK> StevenK: OK.
<ScottK> Bug #82914 (pgdesigner), then you can NBS gambas2-gb-qt-kde and gambas2-gb-qt-kde-html, then Bug #794513  gets rid of kdewebdev-kde3 and kdelibs.
<ubottu> Launchpad bug 82914 in Ubuntu "Huge noise in sound" [Undecided,Invalid] https://launchpad.net/bugs/82914
<ubottu> Launchpad bug 794513 in kdewebdev-kde3 (Ubuntu) "Please remove kdelibs and kdewebdev-kde3 from the archive" [High,Confirmed] https://launchpad.net/bugs/794513
<ScottK> StevenK: ^^^
<ScottK> Oops.
<ScottK> Bug #829149
<ubottu> Launchpad bug 829149 in pgdesigner (Ubuntu) "Please remove pgdesigner source and binary from onerici" [Medium,Confirmed] https://launchpad.net/bugs/829149
<ScottK> That one.
<StevenK> ScottK: Okay, I've made a note
<ScottK> Great.  Thanks.
<ScottK> StevenK: Never mind. slangasek beat you to it.
<ScottK> (sorry for the double request, I didn't realize he was around)
<micahg> StevenK: I've got a list in the ~ubuntu-archive queue if you're removal happy :)
<micahg> *feeling removal happy :)
<ScottK> As he says, that's his usual state.
<ScottK> slangasek: I filed Bug #829165 for your reading enjoyment (and hopefully you fix it).
<ubottu> Launchpad bug 829165 in python-qt4 (Ubuntu Oneiric) "FTBFS due to multi-arching of qt4-x11" [High,New] https://launchpad.net/bugs/829165
<micahg> and it's Friday for him, the perfect time :)
<slangasek> ScottK: heh; which would you like first, wxwidgets or python-qt4? :)
<ScottK> slangasek: python-qt4.
<slangasek> ok, queued
<ScottK> That's a package I actually care about as opposed to a package I happen to receive bugmail for ...
 * slangasek chuckles
<ScottK> StevenK: There's also Bug #829175 if you still want a removal.
<ubottu> Launchpad bug 829175 in kdegames (Ubuntu Oneiric) "Please remove kubrick and ksudoko binaries on armel only" [High,Confirmed] https://launchpad.net/bugs/829175
<micahg> slangasek: you around for another 10 minutes?
<slangasek> micahg: actually no... but StevenK is?
<micahg> slangasek: ok, no problem
<slangasek> ScottK: hmm, this is after sip4 is fixed or not?
<ScottK> slangasek: Not.  I didn't get a chance to look at sip yet.
<slangasek> ScottK: because python-qt4 is the package that led me to the sip4 regression... unrelated to multiarch ;)
<ScottK> Hmmm.
<ScottK> Except that particular build failure is due to a multiarch path.
<ScottK> I broke qscintilla2 in Debian and it got to Testing to that got pushed on the stack ahead of sip4.
<ScottK> to that/so that
<slangasek> ScottK: yeah, I dug into it thinking it might be multiarch, but it's definitely sip4
<ScottK> Crap.  OK.
<slangasek> built fine with the previous upstream version
<ScottK> Glad I didn't upload that sip4 to Debian yet then.
<ScottK> Grumble.  Please assign that one to me then.
<micahg> StevenK: would you happen to be back from lunch?
<StevenK> micahg: Mmmm?
<micahg> StevenK: can I get you to publish a security update for me from a PPA?
<StevenK> micahg: Which PPA?
<micahg> I got 3 out of 4 sources to work, but the last one has too many binaries
<micahg> StevenK: ubuntu-mozilla-security (public)
<StevenK> micahg: Firefox 6, I guess?
<micahg> StevenK: I need firefox 3.6.20+build1+nobinonly-0ubuntu0.10.04.1 to lucid-security
<micahg> StevenK: nah, slangasek too care of that for me on Tuesday
<micahg> *took
<StevenK> micahg: Done.
<micahg> StevenK: just that one, right?
<StevenK> micahg: Yes, just that one.
<micahg> StevenK: thanks!
<pitti> Good morning
<StevenK> ScottK: If you're still around, pgdesigner, gambas2-gb-qt-kde{,-html} and kubrick purged as requested.
<StevenK> ScottK: slangasek beat me to removing kdelibs, and I can't find ksudoko at all.
<infinity> StevenK: Can't "find" it?
<infinity>    ksudoku | 4:4.6.0-0ubuntu2 |         natty | armel
<infinity>    ksudoku | 4:4.6.0-0ubuntu2 |       oneiric | armel
<infinity>    ksudoku | 4:4.6.2-0ubuntu2 |         natty | amd64, i386, powerpc
<infinity>    ksudoku | 4:4.7.0-0ubuntu2 |       oneiric | amd64, i386, powerpc
<StevenK> Ah, ScottK can't spell
<infinity> And you don't autocorrect well, apparently. ;)
<StevenK> I don't play sudoku, so meh :-P
<micahg> that typo actually makes for a rather comical command :)
<infinity> And you've somehow missed millions of people referring to it for the last decade? :)
<infinity> micahg: I assume it's a KDE command for invoking toolchain builds?
<StevenK> infinity: Not missed; ignored.
<micahg> infinity: something to that effect ;)
<pitti> slangasek: it must have stung your heart to touch ia32-libs again
<infinity> pitti: ia32-libs has taken a piece of every every soul that's touched it over the years.
<pitti> slangasek: oh, BTW: flash working like a charm here now
<slangasek> pitti: nah, I got to take an axe to ia32-libs, that was fun ;)
<slangasek> my only regret is that I couldn't cut more out
<RAOF> There seem to be some dependency issues remaining; I didn't get libnss3:i386 or libcurl3:i386 installed automatically.  Once they _were_ installed, though, hurray!
<slangasek> hmm, how did you install?
<slangasek> libnss3 and libcurl3 are definitely in the dep list, so that's pretty odd
<kees> ia32-libs. the reverse horcrux.
<pitti> hah
<StevenK> kees: It just won't die?
<RAOF> slangasek: I just update-managered.
<RAOF> slangasek: I didn't do anything fancy to install.
<slangasek> RAOF: but then, wouldn't you still have had flashplugin-installer:amd64 installed?  I haven't nuked that yet...
<kees> StevenK: well, just going off what infinity said. if it steals a little of everyone's soul. maybe I should say 'super horcrux' instead.
<StevenK> Haha
<RAOF> slangasek: Yes, indeed I have got flashplugin-installer:amd64 installed.
<RAOF> slangasek: And it wants libnss3, which no longer appears to be in ia32-libs?
<slangasek> RAOF: right - switching to flashplugin-installer:i386 should have pulled in the libs for you (and allow ia32-libs to be removed)
<slangasek> yes, it's not in ia32-libs anymore because flashplugin-installer:amd64 is on its way out
<RAOF> Ah, ok.  It's just currently broken :)
<RAOF> Transitionally broken.
<slangasek> yep - I'll have it gone this week
<StevenK> slangasek: So ia32-libs will exist in oneiric release, a shadow of its former self, or utterly purged?
<micahg> slangasek: can packages depend on other arch versions of themselves?
<slangasek> StevenK: will still exist.  if you want to expedite its irrelevance for p, please provide multiarch patches for libxml2 and unixodbc in Debian :)
<slangasek> micahg: nope.  So maybe flashplugin-installer would want to become a transitional package?
<slangasek> there are a couple ways it could work, I mean to play to see which gives the best behavior
<slangasek> StevenK: also, libao
<micahg> slangasek: well, if you want to play with it, you could use the flashplugin-nonfree transitional package to depend on the i386 installer and have the flashplugin-installer:amd64 depend on it
<slangasek> micahg: by making flashplugin-nonfree an i386-only package? heh, twisted but it would work
<micahg> slangasek: well, you still need the amd64 package to depend on nspluginwrapper, still not sure how the dependency chain would work
<slangasek> that's assuming we don't just conclude nspluginwrapper should be pulled in on i386 too
<micahg> ah, right, you suggested that before and it sounded like a good idea
<slangasek> but yes, flashplugin-installer:amd64 Multi-Arch: same, depends: flashplugin-nonfree+nspluginwrapper; flashplugin-nonfree:i386 Multi-Arch: foreign Depends: flashplugin-installer; flashplugin-installer:i386 Multi-Arch: same would do the job
<slangasek> and make people go cross-eyed ;)
<micahg> slangasek: I thought you said you can't have the same package installed on 2 archs?
<micahg> s/on/from
<slangasek> you can if it's marked Multi-Arch: same
<micahg> ah, perfect then, that's what I was thinking :)
<slangasek> oh dear
<slangasek> Suggests: xfs (>= 1:1.0.1-5)
<micahg> slangasek: it's just a suggests, maybe drop it for now if there's no time...
<slangasek> micahg: the "oh dear" was that it suggests it at all, given that nothing uses xfs anymore :)
<micahg> ah
<mneptok> uhhhh .... XFS is one of the very popular choices among DBAs for data partitions
<slangasek> mneptok: apt-cache show xfs ;)
<mneptok> slangasek: oh, *package* XFS
<mneptok> slangasek: why are you not at LinuxCon? it's just up the road ...
<slangasek> mneptok: too much travel this summer already
 * mneptok went to dinner with Canonicalians on Monday. 'twas fun.
<slangasek> all travel and no work makes ia32-libs a something-something
<StevenK> "bloated piece of crap"
<mneptok> "still a scary solution?"
<slangasek> micahg: works as expected with dpkg; I'll check a bit later what happens with update-manager, before uploading
<micahg> slangasek: very cool, thanks
<slangasek> micahg: actually, just pushed to my multiarch ppa, so you're welcome to test too
<micahg> slangasek: maybe after I get this USN out :)
<doko_> pitti: according to the test rebuild, qdox requires jmock, which got demoted
<pitti> doko_: ah, qdox wants to go to universe as well, doing
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> I'll clean that up a bit
<pitti> ant-contrib, antlr3, etc.
<pitti> seems all obsolete
<doko_> ok, thanks
<pitti> oh, portmap wants to go to universe, too?
<pitti> ok, most stuff in "source main->universe" done, except for the ones which should be checked again
<doko_> pitti: hmm, there were some things there which I promoted ... so
<doko_> at least protobuf-c and x264
<pitti> ah, I can put them back then
<pitti> but I guess at some point an AA cleanup will demote them again until they get an rdepends
<doko_> icc-profiles-free
<doko_> tkamppeter__, ^^^
<pitti> I kept that one
<pitti> also icc
<doko_> and not sure if we should keep maven-ant-helper for now, there is a spec to go to maven3
<doko_> jamespage, ^^^
<pitti> we can promote it back when needed
<pitti> it was in main before, so that doesn't need any process
<pitti> once ubiquity drops its cheese b-dep, c-m should look a lot more useful again
<doko_> micahg, isn't there a reason that ssmtp has a `fakesync' in the version?
<micahg> doko_: I checked and apparently not...
<micahg> it was originally due to .bz2 issues, I think those have been fixed, but if not, I"ll upload manually
<tkamppeter__> pitti, icc-profiles needs perhaps a direct seed in ubuntu-desktop.
<doko_> err, that one is in multiverse
<jbicha> can gjs get pushed through the NEW queue?
<micahg> doko_: in theory, gpac could be dropped instead of MIRd depending on what siretart wanted to do with it
<doko_> micahg, well, let him sort it out
<micahg> doko_: right, that's why I filed the bug and subscribed him :), I guess I should've been clearer in the descrption there
<siretart> oh right, x264 drags gpac
<siretart> well, we'll loose quite important functionality with that
<siretart> I'll have to look at why gpac is in multiverse in the first place.
<micahg> siretart: it's in universe I thought
<siretart> ah, I misread the backlog
<siretart> hm. we have a package for debian more or less ready, I wonder why we haven't uploaded it yet: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/gpac.git
<micahg> siretart: what does it use xulrunner for?
<siretart> tbh: no idea
<micahg> siretart: ah, it seems to just need mozjs
<doko_> ScottK, please add the ftbfs tag to new build failure reports
<doko_> ScottK, will you do something with your teeworlds backport? still wants a newer bamf, and shows up on the buildds every hour or so
<pitti> tkamppeter: icc-profiles sounds like something that should be a dependency of something
<tkamppeter> pitti, then I suggest that colord or the color management part of g-c-c should depend on icc-profiles.
<tkamppeter> pitti, can you have a look at bug 829205? It is really annoying for developers.\
<ubottu> Launchpad bug 829205 in Ubuntu "multiarch environment makes testing of new package version for developers very awkward" [Critical,New] https://launchpad.net/bugs/829205
<pitti> tkamppeter: hm, icc-profiles is in multiverse, so actually we can't seed or depend on it
<tkamppeter> pitti, s/icc-profiles/icc-profiles-free/
<pitti> tkamppeter: I'm afraid that's a little outside of what I have time to do..
<pitti> tkamppeter: ah, right; i-p-free could be a recommends: of colord?
<pitti> or whichever package is actually using it
<pitti> we only seed top-level applications
<tkamppeter> pitti, yes that would be OK,.
<tkamppeter> RAOF, hi
<pitti> I'm off for an hour or so, have an appointment
<tkamppeter> pitti, which package for bug 829205?
<RAOF> tkamppeter: Hi.
<ubottu> Launchpad bug 829205 in Ubuntu "multiarch environment makes testing of new package version for developers very awkward" [Critical,New] https://launchpad.net/bugs/829205
<tkamppeter> RAOF, can you add a Recommends: icc-profiles-free to colord?
<pitti> tkamppeter: hm, dpkg probably
<tkamppeter> pitti, thanks.
<RAOF> tkamppeter, pitti: Way ahead of you.  Let me hunt down my bug for that :)
<RAOF> tkamppeter: Certainly.
<RAOF> tkamppeter: I'll finish looking into the run-as-system-user patch and such, too.
<RAOF> tkamppeter: Oooh, actually, that's not the bug I'm thinking of; it's subtly different.\
<RAOF> But the solution is to build i386 packages, too.
<RAOF> bug #827950 is the one I was thinking of (which you'll hit if you *do* build i386 and amd64 packges)
<ubottu> Launchpad bug 827950 in dpkg (Ubuntu) "Multiarch: dpkg gets confused when installing new packages with the same version" [Undecided,Won't fix] https://launchpad.net/bugs/827950
<tkamppeter> RAOF, so installation of an amd46 build environment (build-essential) should pull the i386 build environment and then every package should be actually built twice?
<RAOF> tkamppeter: Well, no.  But you'll need an i386 build chroot; either pbuilder or sbuild.  Perhaps they should have their defaults changed to automatically build both i386 and amd64, though.
<doko_> Subscribe somebody else ... ev ... Please enter at least three characters ... this is INSANE!
<tkamppeter> RAOF, or does this mean that I have to develop and test in an i386 environment?
<tkamppeter> slangasek, hi
<RAOF> tkamppeter: It means that, if the packages you are touching are multiarched, you will need to build both amd64 and i386 packages.  If you have the i386 package installed.
<micahg> doko_: that doesn't look like it's been filed yet
<RAOF> tkamppeter: So, either don't have the i386 package installed, or build both amd64 and i386 packages.
<doko_> micahg, what?
<tkamppeter> RAOF, can I remove the i386 stack from my amd64 system? And if so, how to proceed?
<RAOF> tkamppeter: apt-get remove $PACKAGE:i386
<micahg> doko_: against launchpad
<RAOF> tkamppeter: Unless you've got something critical (currently, the only possible candidate is flash) which depends on the i386 package, that'll work just fine.
<tkamppeter> RAOF, and this for 100s of libs one-byone?
<tkamppeter> RAOF, how do you do your package development and testing?
<RAOF> tkamppeter: The only multiarch package I touch is mesa and its dependencies.  I just build both i386 and amd64 packages and install them side-by-side.
<RAOF> tkamppeter: If you care about libcups2, either remove libcups2:i386 or build an i386 libcups2 binary.
<RAOF> (Obviously, as well as your amd64 binary)
<tkamppeter> RAOF, this means you have to do all test builds in a chroot, like pbuilder and always sttart the two builds in parallel and wait them to finish ...
<RAOF> tkamppeter: That's correct, although I do test builds (that I might possibly want to _install_ ) in a chroot anyway.
<RAOF> tkamppeter: Or, you can remove libcups2:i386; there's probably nothing interesting depending on it.
<dholbach> good morning
<tkamppeter> RAOF, correcting this by removing packages removes acroread and flash.
<RAOF> tkamppeter: Then you'll need to build i386 packages as well as amd64 packages.
<RAOF> tkamppeter: I agree that's a bit awkward.
<jamespage> pitti, doko: I think maven-ant-helper could be demoted for the time being - but please can antlr3 remain in main - see bug 814819 and bug 828816
<ubottu> Launchpad bug 814819 in antlr3 (Ubuntu) "[FFE]Update to antlr3 version 3.2" [Low,Confirmed] https://launchpad.net/bugs/814819
<ubottu> Launchpad bug 828816 in jython (Ubuntu) "Update to jython version 2.5.1" [Undecided,New] https://launchpad.net/bugs/828816
<slangasek> tkamppeter: hey there - has RAOF answered your question already?
<doko> jamespage, can you seed it, or else pitti will demote it again ;p
<doko> can't approve FFE's
<jamespage> doko: working on those bugs today
<pitti> jamespage: do we really need to seed it? seems like the kind of package that really ought to be a build dep, not a top-level app
<pitti> jamespage: we can re-promote it once something  pulls it in
<jamespage> pitti: jython will pull it back in once its upgraded so no it does not need seeding
<pitti> ah, good
<ev> doko_: has my username uncovered a bug in LP?
<ev> seb128: I did, tis what I meant by the other stuff I'd take care of in the morning.
<pitti> it's too short :)
<pitti> ev: good morning
<ev> good morning, pitti!
<seb128> ev: hey, ok
<ev> on it now
<seb128> thanks
<seb128> ev: well done on landing the ubiquity gtk3 version btw!
<ev> thanks, that was quite the battle
<ev> there's still a massive bug in the css handler
<ev> keeps segfaulting randomly
<ev> hope to get to the bottom of that today or monday
<pitti> ev: yeah, congrats! I'll try it with the new pygobject on today's live CD (assuming that it builds), and fix up remaining stuff if needed; but by code inspection it shoudn't cause trouble with the new version
<pitti> that might actually help, pygobject 2.90 turns a lot of these previous segfaults into proper exceptions
<ev> yay
<ev> pitti: that's grand news
<ev> do you know offhand if they fixed the exceptions being raised in a different context issue?
<ev> I checked the bug yesterday and it wasn't closed, but perhaps it was fixed with some other change
<pitti> I don't know about that, I'm afraid
<ev> no worries, I'll have a look
<pitti> ev: if you want to test with the new version, it's in https://launchpad.net/~ubuntu-desktop/+archive/ppa
<pitti> ev: but beware, there are some caveats (bug 828751)
<ubottu> Launchpad bug 828751 in pygobject (Ubuntu) "[FFE] update pygobject to 2.90.1" [Undecided,Confirmed] https://launchpad.net/bugs/828751
<doko> ev: I had to promote the timezone package, MIR was missing :-/
<pitti> ev: I made a task for myself in bug 829186 to check ubiquity with the new pygi, FYI
<ubottu> Launchpad bug 829186 in ubuntuone-control-panel (Ubuntu) "Mixes static and GI library bindings" [High,Triaged] https://launchpad.net/bugs/829186
<doko> ev: now I know why you don't get subscribed to any bug reports ;)
<Laney> hallyn: which version of lxc do you want backported? We have to support the upgrade paths so the backport will need to go to the intervening releases too.
<Laney> hallyn: So, what we need to approve the backport is you to state that it builds, installs and runs without further changes on those releases
<doko> ev: is cheese still required in main?
<ev> doko: nope!
<doko> ev: so I can demote it from supported-desktop-extra?
<ev> doko: please do
<slangasek> \o/
<slangasek> ev: nice work, glad that's finally landed :)
<ev> me too
<ev> and shouldn't you be sleeping?
<slangasek> that's debatable
<ev> :)
<doko> unseeded
<slangasek> ev: I had a session scheduled with my GSoC student actually; people in Ireland apparently keep nearly as funny hours as in London :)
<ev> heh, nice
<Daviey> doko: Ready to be super happy? https://launchpad.net/ubuntu/+source/psyco/1.6-2ubuntu1 <-- a Recommends of ajaxterm.
<Daviey> going to bump it down to suggests, due to being locked into python2.6
<cjwatson> ogra_: around?  if you could please push your livecd-rootfs changes to lp:livecd-rootfs, that'd be great - I want to work on livecd-rootfs a bit today
<ogra_> cjwatson, hmm, i thought i had
 * ogra_ checks
<ogra_> hmm, the branch is up to date
 * ogra_ wonders whats wrong here 
<cjwatson> what does 'bzr info' say?
<cjwatson> lp:livecd-rootfs here only has 2.26
<cjwatson> the archive has 2.27
<ogra_> yeah, got it ... one sec
<ogra_> there you go, sorry the branch was on a different machine
<cjwatson> ogra_: ah, right - thanks
<ogra_> (checking terminal prompts helps sometimes :) )
<doko> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<doko> Daviey: there seem to be some nova related MIRs missing
<pitti> much better
<doko> Sweetshark, ^^^ MIR's for translate-toolkit dependencies missing
<pitti> cjwatson: FYI, current CD buidl failure due to python-gmenu missing is being handled, just needs a s-c upload now
<Daviey> doko: the -carrot induced ones i'm holding out on, as there is work to get rid of carrot.
<doko> ScottK, ^^^ MIR for kdesvn missing?
<cjwatson> pitti: yeah, had already checked software-center bzr for that :)
<Daviey> doko: socat i raised an intial one, and asked zul to finish
<pitti> cjwatson: ah, way ahead of me :)
<Daviey> doko: and -psyco, see above.  I have someone sorting that out right now.
<Daviey> doko: The recommended demotion of powernap, i am investigating if we actually still have a reason to keep it in main.
 * Daviey notes that components-mismatch would be more useful if it linked to [MIR] bugs.
<doko> Daviey, no dependency
<Daviey> doko: uh?
<doko> Daviey, it appears in demotions, because it's not referenced in main
<doko> Daviey, I suppose cjwatson would accept a patch ;)
<Daviey> doko: Yes, i'm trying to find out if we need to make it a dep or seed it seperately, or let it fall through.
<Daviey> cjwatson: Where is the code which generates components-mismatch, it's not part of germinate iirc?
<cjwatson> Daviey: it's in ~lp_archive/dak/ on cocoplum, don't remember whether it's public
<cjwatson> I'm not sure how it would go about knowing where the MIR bugs were though ...
<Daviey> cjwatson: bugs with prefix title [MIR] or ubuntu-mir subscribed ?
<pitti> Daviey: I think all open bugs against the source package with ubuntu-mir subscribed is a very good approximation; there are seldomly more than one of those
<pitti> and if so, listing both of them wouldn't hurt
<Daviey> I'll take a sniff at doing that.
<soren> It could even just link to https://bugs.launchpad.net/ubuntu/+source/<package name>/+bugs?field.subscriber=ubuntu-mir
<Daviey> pitti: The problem is that some ~ubuntu-mir's work flow seems to involve un-subscribing if the MIR isn't ready, which would hide the inprogress report.
<pitti> Daviey: oh, is it? back then we just set them to incomplete
<Daviey> Laney: is that your workflow?
<Laney> I'm not on the MIR team
<soren> It's a long link, but you won't have to actually talk to launchpad to generate the list.
<Daviey> hmm, sorry - i'm getting confused between ubuntu-mir and ubuntu-release
<Laney> but unsubscribing sounds weird
<Daviey> soren: That is easier to implement, but doesn't give a quick reference if the url links to an empty set.
<soren> Daviey: Sure.
<soren> Daviey: ...which is roughly as useful/useless as a missing reference (which is what you'd get if you tried to find this info ahead of time with launchpadlib or whatnot), isn't it?
<Sweetshark> doko: I know, is on my list
<apw> cjwatson, i have noticed that the new live-build environment is not inluding the overlayfs.ko onto the casper initramfs.  I've tested adding that .ko is enought to successfully enable its use.  I am wondering what the process is for fixing live-build given its odd nature
<cjwatson> apw: I'd be surprised if it had anything to do with live-build
<cjwatson> surely it's up to the casper package to include what it wants
<cjwatson> lp:ubuntu/casper hooks/casper, add another manual_add_modules line somewhere there
<cjwatson> it already has them for unionfs/aufs/blah
 * apw checks, i thought there was a list in live-build too, but maybe i am mistaken which its using
<cjwatson> shouldn't be
<cjwatson> it's a few layers removed
<apw> cjwatson, cool then i must be mistaken, and i've lost the tmp dir which had my work... grrr
<cjwatson> well, OK, there's LB_UNION_FILESYSTEM in there, but all that does is pass a kernel parameter
<cjwatson> and that isn't used in our builds
<apw> cjwatson, ok cool, as simple as this it appears: lp:~apw/ubuntu/casper/oneiric/overlayfs-module
<cjwatson> apw: LGTM, thanks - merged and uploaded
<apw> cjwatson, thanks
<OdyX> tkamppeter: thanks for the continuous fixing of the ppd-updating patch. :-) Now I don't think your fixes on foomatic-db-engine were really necessary (but will fix in the next updates).
<njpatel> nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so
<njpatel> dpkg: error processing flashplugin-installer (--configure):
<njpatel>  subprocess installed post-installation script returned error exit status 1
<njpatel> is there anyway around that for amd64?
<ScottK> doko: AFAIK there's no intent to put kdesvn in Main.  I'll have to see what's up this time (this isn't the first time).
<ScottK> doko: re teeworlds and bamf it's an LP bug.
<ScottK> StevenK: Thanks.
<debfx> ScottK: kdesvn appearing in component-mismatch is caused by the kdesdk ftbfs on powerpc
<ScottK> Ah.
<ScottK> debfx: Thanks.
<apw> are we aware that PPA builds (at least) are dropping to CHROOTWAIT apparently due to a glibc detected memory corruption in sudo
<ScottK> unfortunately I've no access to hardware to work on that one.
<debfx> asac: could you please have a look at my patch for bug #750554?
<ubottu> Launchpad bug 750554 in ntrack (Ubuntu) "0.14: nl modules are not linked with libntrack even if they use symbols from it" [High,Confirmed] https://launchpad.net/bugs/750554
<cjwatson> apw: I asked #is about that just recently
<cjwatson> apw: have you seen any not on shipova?
<doko> seb128, is ubuntu-desktop writable for me?
<seb128> doko, yes
<seb128> it has subteams set to allow anyone who can upload to be able to commit as well
<kelemengabor> pitti: hi, do you have a few minutes to copy over the Natty langpack updates from -proposed to -updates: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
<pitti> kelemengabor: queueing; I'm sure I can get to it today, but probably only in two hours or so
<kelemengabor> okay, thanks!
<pitti> kelemengabor: thanks to you for organizing the testing!
<tkamppeter> pitti, seb128, I have done a fix on Poppler, I bzr-branched bzr: ERROR: No push location known or specified.
<tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch
<tkamppeter> branch/        branch-format  branch-lock/
<tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch/
<tkamppeter> branch.conf    format         last-revision  lock/          tags
<tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch/branch.conf
<tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ bzr push --remember http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/ and want to push my changes. To which URL do I have to push?
<StevenK> tkamppeter: You can't push to http URLs
<seb128> tkamppeter, lp:~ubuntu-desktop/poppler/ubuntu
<tkamppeter> StevenK, I getbzr push --remember http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/
<tkamppeter> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<StevenK> tkamppeter: Yes, because you can't push to http URLs
<seb128> tkamppeter, use lp:~ubuntu-desktop/poppler/ubuntu
<tkamppeter> seb128, thanks, but I get then:
<tkamppeter> bzr: ERROR: Cannot lock LockDir(lp-89119376:///~ubuntu-desktop/poppler/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport
<StevenK> You need to login
<StevenK> Run bzr lp-login
<pitti> seb128: oh, the package is missing a Vcs-Bzr: then
<seb128> pitti, seems so indeed :-(
<seb128> sorry about that
<tkamppeter> bzr lp-login returns my user name and then doing bzr push lp:~ubuntu-desktop/poppler/ubuntu again gives
<tkamppeter> bzr: ERROR: Cannot lock LockDir(lp-89229968:///~ubuntu-desktop/poppler/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport
<pitti> I was about to say "debcheckout -a poppler", but that wouldn't work here then
<StevenK> Argh! Where did View->Source go in Firefox 6?
<nigelb> StevenK: Tools -> Web Developer -> Page Source. also, ctrl + U
<StevenK> nigelb: Indeed, I just found that myself. Thanks!
<StevenK> What a silly change.
<nigelb> I just use firebug usually
<tkamppeter> seb128, any further tips to bet the bzr push working?
<seb128> tkamppeter, you maybe don't have access to that vcs
<seb128> tkamppeter, do a merge request?
<tkamppeter> seb128, is it perhaps core-dev-only?
<seb128> tkamppeter, it is
<tkamppeter_> seb128, my connection broke, here are the last messages again:
<tkamppeter_> seb128, is it perhaps core-dev-only?
<seb128> <seb128> tkamppeter, it is
<tkamppeter_> seb128, I have only per-package upload (icl. Poppler). The new poppler package I have successfully uploaded to the upload server.
<seb128> not sure how ppu works with vcs-es
<pitti> seb128: you can push to UDD branches, but not to ~ubuntu-desktop
<bigon> Rebuild upload doesn't require ffe I guess
<bigon> ?
<seb128> pitti, is there any way to "fix" that out of moving away from ~ubuntu-desktop?
<Laney> bigon: for a transition? no
<pitti> seb128: aside from using a MP or the UDD branch I don't see any
<seb128> tkamppeter_, pitti: feel free to use udd for poppler then
<seb128> it's small enough that it's ok
<tkamppeter> pitti, seb128, will someone move poppler's BZR then?
<NCommander> pitti: your a FFe machine. I went to go look at FFes this morning to find you've handled most of the queue :-P
<pitti> NCommander: comes with being pinged about them relentlessly :)
<pitti> NCommander: and also with cleaning mail in the morning
<NCommander> I need a way ot make mail that already been handled to to Archived
<tkamppeter> pitti, seb128, what needs to get into the Poppler branch is now the debdiff between 0.16.7-2ubuntu1 and 0.16.7-2ubuntu2.
<tkamppeter> http://launchpadlibrarian.net/77598473/poppler_0.16.7-2ubuntu1_0.16.7-2ubuntu2.diff.gz
<Gasseus> Is there any way to set the .profile for the guest?
<tkamppeter> pitti, do you remember when we discussed the problem with foomatic-db-compressed-ppds instead of foomatic-db getting installed on the buildds and we arrived at the conclusion to add Build-Conflicts: foomatic-db-compressed-ppds to the printer driver packages? buildds built the packages then, but now that all broke together and it seems that a completely different solution is needed: bug 829471, bug 829446.
<ubottu> Launchpad bug 829471 in gutenprint (Ubuntu Oneiric) "gutenprint version 5.2.7-2ubuntu3 failed to build in oneiric" [Undecided,Invalid] https://launchpad.net/bugs/829471
<ubottu> Launchpad bug 829446 in ptouch-driver (Ubuntu Oneiric) "ptouch-driver version 1.3-0ubuntu10 failed to build in oneiric" [High,Invalid] https://launchpad.net/bugs/829446
<tkamppeter> OdyX, ping
<OdyX> tkamppeter: pong
<tkamppeter> doko, ping
<tkamppeter> pitti, sorry, the problem with foomatic-db seems to be already solved.
<seb128> doko, "xvfb-run: error: Xvfb failed to start"
<seb128> doko, is that really a bug in random packages?
<seb128> or is xvfb broken?
<cjwatson> bdrung: are you OK with my syncpackage-lp branch now?
<tkamppeter> OdyX, I have seen your pyppd package in Debian, great. Are you currently migrating all printer driver packages in Debian?
<OdyX> tkamppeter: in the process of, yes.
<hallyn> Laney: I'll reply in the bug
<Laney> sure
<hallyn> Laney: thanks
<Laney> welcome
<bdrung> cjwatson: i still have to look at it.
<tkamppeter> OdyX, I saw your new foomatic-db and filed a sync request for pyppd, bug 829534.
<ubottu> Launchpad bug 829534 in pyppd (Ubuntu) "Please sync to pyppd 0.4.9-5 from Debian unstable" [High,New] https://launchpad.net/bugs/829534
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, can you have a look at bug 829534. OdyX has introduced a new debhelper for PPD compression. Is it OK for Oneiric? It only changes packaging, removing repeated code from  debian/rules in printer driver packages.
<ubottu> Launchpad bug 829534 in pyppd (Ubuntu) "Please sync to pyppd 0.4.9-5 from Debian unstable" [High,New] https://launchpad.net/bugs/829534
<tkamppeter> doko, hi
<pitti> tkamppeter: can you please subscribe u-release@? bit busy right now, will have a look later
<doko> seb128, I can
<doko> 't see this, how many o these are this?
<tkamppeter> pitti, done.
<doko> bryceh, could you have a look at xfvb?
<seb128> doko, no sure but the pygtk one is due to that
<doko> tkamppeter, now
<seb128> doko, I doubt it's a bug in pygtk, it didn't change for ages
<tkamppeter> doko, there were build failures of printer drivers, gutenprint, ptouch-driver, and m2300w.
<doko> tkamppeter, fix them =)
<tkamppeter> doko, they all built on buildds the first time when I uploaded them.
<tkamppeter> doko, what has changed on the buildds?
<doko> tkamppeter, software?
<doko> tkamppeter, look at the build logs
<tkamppeter> doko, and are gutenprint and ptouch-driver working again? You have marked them invalid without further comment.
<doko> tkamppeter, no, script error
<tkamppeter> doko, I had done Build-Conflicts against foomatic-db-compressed-ppds, and the buildds did it correctly, and now it has foomatic-db-compressed-ppds installed and blocks on it.
<tkamppeter> doko, OdyX, pitti, so the general question: Both binary packages foomatic-db and foomatic-db-compressed-ppds provide foomatic-db. Now I ned foomatic-db and NOT foomatic-db-compressed-ppds as build dependency. Earlier it was suggested to me to add Build-Conflicts: foomatic-db-compressed-ppds and that worked in the beginning. Now it broke. What do I have to do?
<pitti> tkamppeter: broke how?
<doko> tkamppeter, can't tell without looking. I filed ~100 reports today
<pitti> tkamppeter: you can use a versioned build dependency on foomatic-db if you want to ensure you get the real package
<pitti> if build conflicts don't work
<pitti> (haven't checked)
<tkamppeter> pitti, doko, OdyX, bug 829471, bug 829446, bug 829496.
<ubottu> Launchpad bug 829471 in gutenprint (Ubuntu Oneiric) "gutenprint version 5.2.7-2ubuntu3 failed to build in oneiric" [Undecided,Invalid] https://launchpad.net/bugs/829471
<ubottu> Launchpad bug 829446 in ptouch-driver (Ubuntu Oneiric) "ptouch-driver version 1.3-0ubuntu10 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/829446
<ubottu> Launchpad bug 829496 in m2300w (Ubuntu Oneiric) "m2300w version 0.51-0ubuntu13 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/829496
<pitti> tkamppeter: so apparenlty something else pulls in the compressed variant
<pitti> tkamppeter: try in a PPA with a versioned build dep?
<tkamppeter> pitti, strange is that as I introduced the build conflicts 2 or 3 weks ago, it worked.
<pitti> tkamppeter: yes, but your build dependencies may have changed, and grown a dependendcy to the compressed one?
<tkamppeter> pitti, why could a versioned build dep work?
<pitti> tkamppeter: Provides: are not versioned, so they don't satisfy a version requirement
<tkamppeter> pitti, the available foomatic-db-compressed-ppds and foomatic-db are always of the same version.
<tkamppeter> pitti, thanks.
<pitti> tkamppeter: yes, but if you do "b-dep: foo (>= 1)", this will only be satisfied by "foo", not by package "bar" which "Provides: foo"
<tkamppeter> pitti, and then the pulling of the versioned foomatic-db will uninstall foomatic-db-compressed-ppds?
<pitti> tkamppeter: the deeper question is of course which package pulls in -compressed in the first place
<pitti> tkamppeter: that depends on ^
<pitti> if the thing that pulls it in has a dep "-compressed | foomatic", then it shuold work
<pitti> if it has a dep "compressed" without alternative, then no
<pitti> then it's uninstallable
<tkamppeter> pitti, and if that package pulls "foomatic-db-compressed-ppds" explicitly, the build process will not be able to uninstall -compressed-ppds.
<dholbach> jamespage, I'll have a look at the antlr3 update
<pitti> tkamppeter: the builder never uninstalls a package
<jamespage> dholbach: hey - you where reading my mind
<ricotz> hrw, hello :), just wanted to mention the content of binutils-arm-linux-gnueabi_2.21.52.20110707-1ubuntu1cross1.71_amd64.deb seems a bit messed up
<dholbach> jamespage, I got the email, which helped a bit with that ;-)
<jamespage> dholbach: right - got an odd error from launchpad so assumed I'd failed to request a review from you :-)
<tkamppeter> pitti, so if -compressed-ppds gets already installed by the builder before the build-deps of the source package are read, then the package is generally unbuildable.
<tkamppeter> pitti, is there any way to do a general search on the buildds where this unwished dep originates?
<hallyn> stgraber: hey, late last week, when shutdown in a container wasn't working for you, what was the missing package again?
<pitti> tkamppeter: apt-cache rdepends
<pitti> tkamppeter: Package: foomatic-db-engine
<pitti> Recommends: foomatic-db-compressed-ppds | foomatic-db
<tkamppeter> pitti, so I should remove this altogether and perhaps only put a Suggests: foomatic-db.
<mr_pouit> seb128: the build failures with xfvb are caused by fakeroot 1.16 iirc
<pitti> tkamppeter: depends; does it make sense for foomatic-db-engine to pull in the PPDs?
<pitti> tkamppeter: as I said, you can still try with a versioned build dep
<pitti> if apt resolves them all in one go, it should pick the alternative
<stgraber> hallyn: it wasn't a missing package. It was the old lxcguest removing /var/run instead of removing its content (so removing the symlink from /var/run to /run)
<tkamppeter> pitti, will do so, first, foiomatic-db-engine to remove the recommends, then the drivers to pull versioned foomatic-db.
<pitti> tkamppeter: you shouldn't drop a valid recommends just to work around the ptouch-driver FTBFS
<pitti> also, you only need one, not both
<hallyn> stgraber: hm, i thought that there was a separate instance where a package was msising due to using minbase
<hallyn> ok, thanks
<Laney> I thought buildds didn't install recommends, only depends
<tkamppeter> pitti, this recommends is not so important, especially the presence of -compressed-ppds  does not improve the functionality of foomatic-db-engine.
<pitti> Laney: hmm, good point
<Laney> get a chroot, aptitude --without-recommends build-dep foo, aptitude why bar
<stgraber> hallyn: nope. the problem with using minbase was that we'd end up without ifconfig/file/... that are usually quite useful to have around
<pitti> Laney: well, it's definitively a b-dep, the log is quite clear there
<tkamppeter> pitti, for me it looks more that the buildds does something wrong. See
<tkamppeter> <tkamppeter> https://launchpadlibrarian.net/77487052/buildlog_ubuntu-oneiric-i386.m2300w_0.51-0ubuntu13_FAILEDTOBUILD.txt.gz
<tkamppeter> <tkamppeter> and search "compressed-ppds" in there.
<Laney> just saying that generally if I want to know "why did this package get installed?" I call upon aptitude why
<hallyn> stgraber: my newest lucid container, under oneiric, isn't shutting down.  drat.
<Laney> tkamppeter: that means that you've said -compressed- must not be installed, but another package says that it must
<Laney> two conflicting requirements
<stgraber> hallyn: can you try creating a symlink from /run to /var/run?
<tkamppeter> pitti, first mention is "Build-Conflicts: foomatic-db-compressed-ppds" meaning that it did not get installed before and now the system knows it is not desired.
<stgraber> hallyn: I'm wondering if lxc only monitors /run now
<pitti> tkamppeter: yes, but as you see in the build log it gets installed during installing build dependencies
<pitti> so perhaps the buildds have started installing recommends recently/
<pitti> ?
<pitti> infinity, lamont ^
<tkamppeter> pitti, second mention: foomatic-db-compressed-ppds: already deinstalled, system confirms that -compressed-ppds is correctly not present.
<tkamppeter> pitti, can it be that the buildds is installing recommended packages nowadays?
<pitti> tkamppeter: that's why I asked infinity/lamont about this
<Laney> you can see that recommended packages are not installed
<Laney> look for Recommended packages: and see that none of those get pulled in
<hallyn> stgraber: no that doesn'tn do it :(
<hallyn> (and /proc/10573/root/run/utmp and /proc/10573/root/var/run/utmp are the same file now)
<pitti> apt-cache rdepends foomatic-db-compressed-ppds only has some meta packages, and cups/foomatic-db-engine which only recommend it
<pitti> Laney: that "recommended packages" list isn't quite complete, though, apparently?
<Laney> I didn't get -compressed installed in my chroot, fwiw
<infinity> pitti: As Laney says, Recommends aren't being installed, but I missed what the actual problem is here?
<hrw> ricotz: report a bug please
<pitti> infinity: trying to figure out https://launchpadlibrarian.net/77487052/buildlog_ubuntu-oneiric-i386.m2300w_0.51-0ubuntu13_FAILEDTOBUILD.txt.gz
<Laney> I assume it's something to do with how the buildds resolve depends
<pitti> infinity: in particular, why foomatic-db-compressed-ppds gets pulled in
<pitti> (it's a build conflict)
<stgraber> hallyn: ok, so you're probably hitting something completely different then...
<hallyn> yeah, lxc-monitor doesn't report anything until i do 'lxc-stop' by hand
<infinity> pitti: Build-conflicts aren't magical.
<Laney> it must be being pulled in by the provides
<pitti> infinity: they shouldn't be
<pitti> infinity: but I checked apt-cache rdepends and can't find a package which pulls in foomatic-db-compressed-ppds as a depends
<infinity> It provides foomatic-db, which is a build-dep.
<pitti> infinity: my initial recommendation was to version the foomatic-db build dep
<pitti> to force taking the real package
<infinity> WHY does it provide fommatic-db?
<Laney> is the provides correct then, if it's not a genuine replacement?
<infinity> foo*
<tkamppeter> infinity, but foomatic-db can also be fulfilled by foomatic-db why does the buildds not go this way?
<pitti> tkamppeter: just try it with a versioned b-dep
<infinity> tkamppeter: Because it's perfectly valid to do so? :P
<pitti> well, arguably it's quite unexpected
<infinity> I need to toy with the idea of adding build-conflicts to the apt-get invocation as negatives.
<infinity> as in: apt-get install build-dep buil-dep build-dep build-conflict-
<pitti> if there's a real package, it should use that, especially when the virtual alternative is a conflict, but still, there's an easy workaround, so I don't think we should waste more time on that
<infinity> pitti: "If there's a real package, it should use that" is a non-starter.  Real and vitual are afforded the same level of citizenry.
<Laney> is there a custom resolver or do they use one provided by sbuild?
<infinity> pitti: It's why we usually don't have real and virtual overlapping in namespace, so we can then do things like "Depends: real | virtual" to get the desired behaviour.
<pitti> well, just said that this is my gut feeling :)
<infinity> Laney: sbuild's resolver to find the build-deps, apt's resolver to install.
<infinity> Uhm.
<infinity> pitti: Also, duh.
<Laney> I think rleigh did some tests recently with the aptitude resolver
<infinity> pitti: foomatic-db is in universe, this package is in main.
<infinity> pitti: (So, people might be oeverthinking this a lot)
<pitti> ah :)
<infinity> pitti: The ONLY foomatic-db in main is the one that's also a build-conflict.
<pitti> tkamppeter: ^
<pitti> kelemengabor: released
<infinity> Laney: Upstream sbuild has, like, 34 different resolver options.  On the other hand, we know the warts in Ubuntu's, and I like reproducibility.
<kelemengabor> pitti: thanks!
<infinity> Laney: (We also do things viciously different from Debian buildds intentionally in some ways...)
<infinity> Laney: It's also worth noting that 99% of the time people complain about sbuild's resolver (or other such things), it's usually pilot error (as above).
<infinity> Laney: Which somewhat inflates the percieved number of problems. :P
<Laney> I don't have a problem with it - the only time I use aptitude is when building for exp when apt won't find a solution. It seemed like that was one of the times when aptitude would have found a solution over apt, but happily it was likely a user problem
<mr_pouit> pitti: when you have some time later, could you look at bug #817792 please? (sorry if you're already aware of it) advpng is changing to mode 664 recompressed pngs
<ubottu> Launchpad bug 817792 in pkgbinarymangler (Ubuntu) "pkgstripfiles doesn't preserve permissions of png files" [Undecided,Confirmed] https://launchpad.net/bugs/817792
<pitti> mr_pouit: ah, probably fallout from the recent umask change
<pitti> mr_pouit: I'm wasn't aware, thanks for pointing out
<hallyn> stgraber: well the problem for me is that ssh only stops on runlevel S, but the container never goes to runlevel S, it goes from 2 to 0
<hallyn> when i change ssh's stop on to 'runlevel [0S]' the continer exits fine
<infinity> hallyn: Why would you expect it to go to S?
<cjwatson> I deliberately made ssh *not* stop on 0 (or 6) in line with https://wiki.ubuntu.com/Teardown
<hallyn> infinity: *I* don't.  ssh.conf shipped with openssh-server does
<stgraber> cjwatson, hallyn: did that change post-release?
<hallyn> cjwatson: yet another thing for lxcguest to tweak then
<infinity> Where are you seeing a stop on S?
<hallyn> cjwatson: I think the full problem is that it gets killed by sendsigs,
<hallyn> cjwatson: and then upstart restarts it
<infinity> I have stop on runlevel [!2345]
<hallyn> infinity: look at lucid's ssh.conf
<infinity> Oh, we're going back in time. :P
<hallyn> !2345 wouuld work for us
<ubottu> hallyn: I am only a bot, please don't think I'm intelligent :)
<infinity> Err, lucid's is as above too.
<hallyn> not on mine!
<hallyn> what on earth...?
<hallyn> oh, maybe bc the containers are debootstrapped without lucid-updates
<hallyn> checking
<cjwatson> stgraber: oh, wait, it indeed changed in maverick
<cjwatson> yeah, bug 603363
<ubottu> Launchpad bug 603363 in openssh (Ubuntu Lucid) "sshd never stops, prevents umount of /usr partition" [High,Fix released] https://launchpad.net/bugs/603363
<hallyn> (and lp:ubuntu/lucid-updates/openssh does not exist :( )
<tkamppeter> pitti, can you move foomatic-db into Main then. I t should always have been in Main as it is a build dependency.
<pitti> tkamppeter: done
<pitti> tkamppeter: that should solve the issue, so you can close the FTBFS bugs
<tkamppeter> pitti, is there something which automatically demotes binary packages to Universe if it does not find an evidence that it contributes to what is on the CDs?
<pitti> tkamppeter: s/CDs/main/
<pitti> tkamppeter: not automatically, but http://people.canonical.com/~ubuntu-archive/component-mismatches.txt will complain, so archive admins demote unneeded stuff
<tkamppeter> pitti, thanks for syncing pyppd.
<tkamppeter> pitti, should I switch to the versioned build-depends to secure foomatic-db in main?
<pitti> tkamppeter: let's see whether it complains; if it does, we need to do that
<tkamppeter> pitti, one package with versioned dependency is already on the way: m2300w.
<ScottK> slangasek: I fixed sip4 (uploaded), but then it turns out python-qt4 does have a mulit-arch related issue.  Please let me know when you can discuss so I can figure out the best way to fix it.
<tkamppeter> pitti, how long does it take for foomatic-db to arrive in Main?
<infinity> tkamppeter: A publisher cycle.
<infinity> tkamppeter: From the POV of the buildds, I assume it'll be fine in about 20 minutes, longer for mirrors.
<tkamppeter> infinity, thanks. m2300w started to build now.
<slangasek> ScottK: hi, happy to discuss python-qt4 now
<ScottK> slangasek: Hello.
<ScottK> Now that I fixed sip4 I have one file in python-qt4 (and the dbg) that gets multiarched:
<ScottK> usr/lib/i386-linux-gnu/qt4/plugins/designer/libpythonplugin.so
<slangasek> ok, yes, I saw that in my testing too
<slangasek> is that a problem?  It should transparently DTRT on the Qt side
<ScottK> python-qt4.install has usr/lib/qt4/*
<ScottK> So it finds nothing.
<ScottK> Bang.  FTBFS.
<ScottK> If I, for the sake of testing, change it to usr/lib/i386-linux-gnu/qt4/* then all is well.
<ScottK> Suggestions?
<slangasek> ScottK: I would (and did locally) edit the .install to usr/lib/*/qt4/*
<ScottK> slangasek: Fair enough.
<ScottK> Thanks.
<slangasek> sure!
<doko> ScottK, please keep the bug tasks in the ftbfs, create a new task, don't reassign please
<ScottK> doko: It was re-assigned once.  I was putting it back.
<ScottK> If there's special rules for these bugs they should be written down somewhere.
<doko> ScottK, send a patch to the svammel project
<ScottK> doko: I've no idea what you are talking about?
<slangasek> ScottK: lp:svammel is the mass-ftbfs-bug-filing tool; the trouble is that if the bug gets reassigned off of the package that fails to build, the next svammel run (depending on options passed) may wind up filing the bug again
<ScottK> Ah.  Well that would explain why another one got filed against python-qt4.
<slangasek> (though there's meant to be a capability of caching the list of already-filed-bugs locally to avoid dupes)
<xerosis> hi, I'm trying to bzr push a bug fix but it will let me push to .../natty/... but not .../oneric/... what am I doing wrong?
<slangasek> xerosis: do you want to give the full URIs of where you're trying to push to?  Otherwise we'd kinda be guessing blind :)
<xerosis> slangasek, sorry, I'm following https://wiki.ubuntu.com/Bugs/HowToFix and I'm trying to do the second to last command
<slangasek> xerosis: yes, please tell us the exact command line you're typing
<slangasek> oh, nevermind, I see the issue
<slangasek> you've misspelled "oneiric" :-)
<xerosis> slangasek, oh dear
<xerosis> slangasek, thank-you that was it, I'll be hiding in the corner now...
<slangasek> no worries
<slangasek> it's not an easy word to spell... considering it's not even in half the dictionaries I have to hand: )
<slangasek> YokoZar1: hey, what was the reasoning for pulling all of the gstreamer0.10-plugins-* packages, with dependencies, into ia32-libs last cycle?  Surely it's a diminishingly small set of plugins that are actually useful in the wine case, no?
<dupondje> Somebody knows if there is someone working on a new mutter version ?
<GTRsdk> I don't know if this is the right channel, but is there a package that provides xulrunner-dev?
<tkamppeter> OdyX, ping
<infinity> ScottK: Can I blame these failures on recent QT mangling? https://launchpad.net/ubuntu/+source/semantik/0.7.3-0ubuntu3
<slangasek> infinity: it's probably fallout from qt4 going multiarch, so I'll share the blame together with upstream's bad build system
<infinity> slangasek: Any interest in looking into it, or shall I poke it later?
<slangasek> infinity: no specific interest; there are a number of kubuntu packages in main I should probably look at first
<infinity> Fair enough.  It'll stall the ocaml re-transition for a bit, but that won't hurt my feelings if I don't fix it before the weekend. :)
<infinity> slangasek: I haven't looked, but I'm assuming you figure it's probably just a bad path lookup?
<infinity> slangasek: Shouldn't be rocket science for me to sort.
<infinity> s/bad/hardcoded/
<slangasek> infinity: yes, the only bugs we have that should be rocket science for us to sort are ones in altus metrum-provided packages
<sgnb> infinity: I think it doesn't affect anything else ocaml-ish...
<sgnb> and besides, this package doesn't seen to provide any *.cmx* file, so it didn't need recompilation
<infinity> sgnb: Ahh, well, it was on the transition page.   I'll admit to not being sure how that's generated. :P
<sgnb> the transition page lists everything (build-)depending on ocaml... it is not specially relevant to this transition
<infinity> sgnb: Either way, finding the build failure doesn't hurt my feelings. ;)
<infinity> sgnb: (But happy to fix it later, if you're sure it doesn't matter for the transition)
<sgnb> the actual condition is "installing some *.cmx* file"
<infinity> sgnb: Do you happen to have a list that meets your criteria for stages 3 through 6? ;)
<infinity> Or 8...
<infinity> sgnb: I was just going through the transition page and bouncing everything that appears to contain native-compiled code.  Which seems reasonable enough.
<infinity> (Though obviously less precise than your definition)
<cjwatson> siretart: do you have any recommendation for what to do with mplayer in oneiric?  At the moment it fails to build because libavformat isn't detected at configure time due to an API change (av_alloc_format_context).  The version in Debian experimental seems to have totally different stuff around there in configure.  My choices seem to be (a) just fix up the configure test with the new API, and anything else using the same ...
<cjwatson> ... functions, or (b) pull in the new snapshot from experimental, requiring an FFe and all the rest of it.  Neither of those options seems hugely appealing to me
<infinity> cjwatson: Changing the configure test sort of assumes that function isn't actually used in the code...
<sgnb> infinity: is there some file listing of .deb files of Ubuntu available somewhere?
<infinity> cjwatson: Oh, I see the "and anything else using the same".  Yes.  That sounds unfun.
<cjwatson> there actually isn't anything else using it
<infinity> sgnb: Contents files on the mirrors.
<cjwatson> the actual code in libmpdemux uses libavformat_alloc_context, which is the new API
<infinity> cjwatson: So, if you short the configure test and build, everything's groovy?  That seems to be the path of least resistance.
<slangasek> I'm always in favor of stabbing configure checks that test for things that aren't used by the software
<slangasek> like the wrong libssl check I patched for the other day
<cjwatson> infinity: I'm about to find out
<slangasek> every time I see the package phonon, I think of Bokonon
<infinity> sgnb: I need to run out for a late lunch appointment.  But I'll be back in an hour or less if you have more transition insight for me. :)
<cjwatson> ok, there are a couple of other API fixes needed, but don't look too major
<cjwatson> hmm
<cjwatson> upstream diff:
<cjwatson> -       for (fmt = first_oformat; fmt; fmt = fmt->next)
<cjwatson> +       for (fmt = av_oformat_next(NULL); fmt; fmt = av_oformat_next(fmt))
<cjwatson> compare with:
<cjwatson> -    for (fmt = first_iformat; fmt; fmt = fmt->next)
<cjwatson> +    for (fmt = av_iformat_next(NULL); fmt; av_iformat_next(fmt))
<slangasek> heh
<nigelb> is it python?
<cjwatson> err?
<nigelb> only place where whitespace probably matters :)
<cjwatson> no, it's the missing 'fmt = '
<nigelb> ah
<nigelb> gah, should learn to read before asking stupid questions :)
<Laney> looks good
<slangasek> all except that infinite loop part
<YokoZar1> slangasek: mostly it's the embedded movies in game intros and stuff -- things that in the bad old days would cause a crash even though the app worked
<slangasek> YokoZar1: yes, but what are the gstreamer plugins that are *actually* needed?
<YokoZar1> I don't fully know, I'll try to get a shorter list.  Are you considering splitting the packages further?
<slangasek> you pulled in roughly 250 plugins, with a similarly high number of library dependencies; I don't think all of these represent things actually used by Windows software in practice, and I'd like to cull some of the lesser-used plugins
<slangasek> either by removing them from ia32-libs entirely, or leaving the plugins in the package but ditching their specialized library dependencies
<YokoZar1> Yes, I did this because I wasn't entirely sure what was being useful and what was not (with a suspicion that the more esoteric plugins were precisely the sort of thing that would occur in weird windows programs)
<slangasek> well, I'd really like it if we had some hard data here on what plugins are actually needed; I would estimate we could reduce the size of ia32-libs (source+binary) another 30-40% from where it is right now if we had that
<slangasek> but if it's non-trivial to get that info, well, I'd rather you focused on converting the gstreamer deps to multiarch for P :)
<mdeslaur> so...glade in oneiric doesn't open gtk2 glade files anymore?
<YokoZar1> slangasek: I'll send an email to the guy who did the actual gstreamer implementation in Wine to see what he thinks.  I do suspect there's some 80/20 stuff going on here for sure though.
<slangasek> YokoZar1: cool, thanks :)
<YokoZar1> slangasek: the response is that -good and -base would probably be enough, which seems like the logical place to start anyway
<slangasek> YokoZar1: oh, if we could drop the others that would be most excellent - how strong of a "probably" is that?
#ubuntu-devel 2011-08-20
<cjwatson> ah.  damn it.  mplayer doesn't work if the header files in the source tree are from a different libav* ABI than the system libraries you're compiling against - it ends up with mismatched structure sizes and everything goes to pot
<cjwatson> that is very nasty
<cjwatson> siretart: so, the result of all that - never mind.  FFe sent requesting permission to sync from experimental.
<siretart> cjwatson: yes, the only other option would have been to link against the internal copy of libav*, but the package from experimental is IMO clearly the better option for oneiric
<cjwatson> siretart: yeah, I don't feel good about introducing more duplication
<dupondje> https://launchpad.net/ubuntu/+source/libdispatch/0~svn197-3
<dupondje> could somebody retry the build ?
<dupondje> should be fixed now (just tested in pbuilder)
<debfx> dupondje: done
<dupondje> thx
<dupondje> and it build :D
<dupondje> wtf, the armel build queue is 2 weeks ? :p
<ogra_> archive rebuild in progress
<dupondje> oh ok :)
<infinity> cjwatson: Acked your FFe, BTW.  As did ScottK.  You should be good to go to sync, unless you want another AA to do it.
<cjwatson> thanks.  that's OK, I'll take care of it
<sgnb> infinity: http://glondu.net/tmp/ocaml-arm-recompilation.txt
<infinity> sgnb: My hero.  I'll slam group 3 at the archive tomorrow, after I get some sleep. :)
<cjwatson> https://launchpad.net/ubuntu/+source/openscenegraph/3.0.0-2ubuntu1/+build/2636062 ugh, that kind of build result makes me sad
 * cjwatson is rather tempted to remove all the libav reverse-deps on armel that have GL porting problems
<cjwatson> on the basis that seriously who's using them anyway
<tumbleweed> there's a whole slew of science packages with that problem too
<ogra_> cjwatson, thhey would most likely need proting to GLES for hw accel, but there is meas for GL
<ogra_> *mesa
<cjwatson> yeah, but is anyone going to do it?
<cjwatson> or is there a porting guide?
<cjwatson> also if somebody really masochistic wants to fix salome (or declare that it should be removed), that'd be great
<cjwatson> have a look at its Debian bug page for great justice
<ogra_> well, thats linaro realm mostly, their multimedia teams work with upstreams to fix it usually
<cjwatson> ogra_: yeah, 16-hour builds that are going to involve serious effort and guesswork aren't high on my list to sort out
<cjwatson> but cleaning up NBS is
<bdrung> cjwatson: i found two bugs of the new syncpackage way. where should i report it?
<cjwatson> bdrung: are they bugs in the client or the server?
<ogra_> well, drop the dep and lest see about the fallout
<ogra_> its not like release is tomorrow ...
<bdrung> cjwatson: probably server. 1. wrong uploader: https://launchpad.net/ubuntu/+source/mozilla-devscripts/0.28 2. lp bug not closed: bug #829493
<cjwatson> I'd rather just remove the unbuildable binaries and have them continue to show up as build failures.  There is precedent for doing that around beta time
<ubottu> Launchpad bug 829493 in mozilla-devscripts (Ubuntu Oneiric) "mozilla-devscripts version 0.27 failed to build in oneiric" [High,Fix committed] https://launchpad.net/bugs/829493
<ogra_> if people scream about something missing we can still fix
<bdrung> cjwatson: 3. newlines seems to be wrong in changelog on https://launchpad.net/ubuntu/+source/mozilla-devscripts/0.28
<infinity> cjwatson: I'm happy with the old binary cruft being tossed.  If and when we get various ducks in a row about GL/GLES on ARM, people can fix it all.  If it doesn't happen before release, at least there's no cruft.
<cjwatson> bdrung: I think 1 may be deliberate to some extent, as it's copying the Debian publication record, although it'd be nice if the syncer were shown somewhere too.  It might be tied into bug 827608 and/or bug 827555
<ubottu> Launchpad bug 827608 in Launchpad itself "Sync requester isn't credited with upload" [High,Triaged] https://launchpad.net/bugs/827608
<ubottu> Launchpad bug 827555 in Launchpad itself "native syncs have no way to indicate sponsorship" [Low,Triaged] https://launchpad.net/bugs/827555
<cjwatson> bdrung: 2 is a client bug, syncpackage needs to close it; bug on ubuntu-dev-tools and assign to me, please?
<cjwatson> bdrung: 3 is bug 827528
<ubottu> Launchpad bug 827528 in Launchpad itself "native-synced changelogs have spurious extra newline" [High,Triaged] https://launchpad.net/bugs/827528
<cjwatson> bdrung: all the server-side bugs live at https://bugs.launchpad.net/launchpad/+bugs?field.tag=derivation
<tumbleweed> cjwatson: if syncpackage needs to close the bugs, that's another potential problem with people using +localepackagediffs
<cjwatson> bdrung: 2> (for now, just close it manually)
<cjwatson> tumbleweed: people need to not use +localpackagediffs for Ubuntu
<tumbleweed> indeed
<bdrung> cjwatson: couldn't be 2 done by LP?
<cjwatson> I'm simply not interested in making that work
<tumbleweed> let me write that bug I was going to, complaining about it
<Laney> syncpackage has -b xxxx that you could pass manually for now?
<cjwatson> bdrung: I don't think it would fit well into the API.  the API already has a way to close bugs, it doesn't make sense to bolt another one onto the side of the copy for the sake of Ubuntu process
<cjwatson> Laney: it doesn't honour that for the API copy case yet.  that's the bug
<infinity> cjwatson: To be fair, newlines are incorrect for non-sync uploads too, they're just differently incorrect. :P
<cjwatson> infinity: yeah, but they're wrong in the gina import in this case
<Laney> yeah, just saying that there's a non-completely-manual way to do it (and that this code could be wired together with the native sync stuff)
<cjwatson> you can see the same wrongness at https://launchpad.net/debian/+source/mozilla-devscripts/0.28
<cjwatson> Laney: you'll have to provide -b anyway - it probably can't magically figure out the right bug
<cjwatson> but yeah, need to fix that
<infinity> cjwatson: Yeah, I saw the extra newline there.  And yet, that still looks nicer than the missing newline on https://launchpad.net/ubuntu/+source/telepathy-glib/0.15.5-1ubuntu1 ;)
<tumbleweed> to close the bugs, we have to pull all the intermediate dscs (or a full source package to read debian/changelog) :/
<cjwatson> well, that's true
<cjwatson> hmm
<Laney> can you ask LP for the changes that were in the Debian changesfiles?
<cjwatson> I suppose that does kind of argue for an extra parameter to the API, although it won't help much until bug 827576 is fixed
<ubottu> Launchpad bug 827576 in Launchpad itself "copyPackage only includes changes from upload being copied" [High,Triaged] https://launchpad.net/bugs/827576
<cjwatson> I don't think it has changesfiles for Debian imports
 * cjwatson goes out
<tumbleweed> I suppose we could pull a changelog from PTS / changelogs.debian.net, but that's ugly (and potentially out of date)
<infinity> And not canonical, by any stretch.
<tumbleweed> or secure
<infinity> Though it does irk me that https://launchpad.net/ubuntu/+source/telepathy-glib/+changelog isn't actually a full changelog.
<Laney> yes, I said that on ^ bug
<tumbleweed> yeah it's a pain
<infinity> But rather a log of uploads that were published in soyuz.
<Laney> don't knwo if it will get completely fixed, the best you'll get is a concatenation of the changesfiles changes that went into debian I reckon
<Laney> which may still miss some
<tumbleweed> Laney: does launchpda get those changes files? I assumed it just looked for new versions when it mirrored
<Laney> maybe it does. I thought it got that data from the changesfiles, but perhaps not :-)
<Laney> anyway, it's not like people are as universally conscientious with using -v as they could be when they upload to ubuntu
<tumbleweed> sure, but tools should get it right
<infinity> Or make a valiant effot, anyway.
<infinity> Some of this stuff can never be right, just "slightly less wrong".
<Laney> indeed
<Laney> hence the bug, of course
<tumbleweed> yay, +localpackagediffs generated a diff for me and it only took half an hour to do so :/
 * infinity notices that it's 4am, and decides to sleep.
<htorque> maybe someone here can help me: i found a process that consumes more and more memory over time, how would i use valgrind to add something useful to a bug report? just call it once then close it or let it run for a while?
<kennydude> Hi, what do I do once a branch has been marked as "Needs Fixing"?
<tkamppeter> OdyX, ping
<ScottK> siretart: Do you have any time to help out with libav porting issues?  kd3b needs help (neither upstream, nor Debian have done the port).  If you add libqtwebkit-dev to build-depends and then try to build the current package you'll see the issues.
<ScottK> kd3b/k3b
<hyperair> can a core-dev please look into sponsoring bug #823937 please?
<ubottu> Launchpad bug 823937 in nautilus-share (Ubuntu) "Sync nautilus-share 0.7.3-1 (main) from Debian unstable (main)" [Critical,New] https://launchpad.net/bugs/823937
<shadeslayer> slangasek: multiarch ping
<slangasek> shadeslayer: pong
<shadeslayer> slangasek: hi!
<shadeslayer> one sec
<shadeslayer> slangasek: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2697477/+files/buildlog_ubuntu-oneiric-i386.kalzium_4%3A4.7.0-0ubuntu2_FAILEDTOBUILD.txt.gz >> t
<shadeslayer> we have : make[4]: *** No rule to make target `/usr/lib/libQtOpenGL.so', needed by `lib/libcompoundviewer.so.4.7.0'.  Stop.
<slangasek> right
<shadeslayer> because that file is now installed to /usr/lib/arch/
<shadeslayer> could you guide me as to how to fix this issue?
<slangasek> so the question is, what has hard-coded the path to /usr/lib/libQtOpenGL.so?  Looking at the build-deps, it might be kde-sc-dev-latest or kdelibs5-dev; or it could be in the kalzium source itself
<slangasek> I'm not an expert at cmake-based builds, so the most guidance I can offer is "use grep -r a lot"
<shadeslayer> its avogadro :)
<shadeslayer> more specifically /usr/lib/avogadro/1_0/AvogadroLibraryDeps.cmake
<slangasek> ok
<slangasek> try a no-change rebuild of avogadro, maybe that's enough to fix it?
<shadeslayer> alright, will try
<debfx> slangasek: that might be enough to fix it, but I'd rather not have to rebuild cmake-using libraries whenever some other library is converted for multiarch
<debfx> any idea how to properly fix this in cmake?
<slangasek> debfx: sure - then those cmake-violating libraries need to stop hard-coding paths in the first place, since this has never been guaranteed by the system.  If this is a general cmake feature, can cmake be changed to spit out -L$path -lQtOpenGL instead?
<slangasek> actually, in the shared library case it would be better if it would just not spit anything out at all
<slangasek> since with glibc, all it does is make the system more brittle
<debfx> slangasek: so it's "just" a question of how to implement that :)
<ScottK> doko: Are you going to sync trousers or should I edit the FTBFS bug to be a sync request?
<lamont> SpamapS: apport in postfix is annoyig
<lamont> SpamapS: since it forks the package (debian has no such beast)
<lamont> SpamapS: I would  welcome a solution to that situation
#ubuntu-devel 2011-08-21
<micahg> slangasek: BTW, aptitude seems to fail miserably at multiarch deps
<slangasek> micahg: oh?
<micahg> yeah
<micahg> oh, maybe not, I'm confused now...well, I have the old e-d-s-common installed
<micahg> before I installed all the i386 libs for flashplugin, it used to be able to resolve the dependencies, now it wants to remove a lot of stuff
<slangasek> hmm
<slangasek> how are you invoking aptitude? interactively, or commandline?
<micahg> interactive
<slangasek> well, I certainly get a lot of error output whenever I try to change the state of a package
<StevenK> slangasek: http://wedontsleep.org/~steven/libao_1.1.0-2.debdiff
<slangasek> StevenK: LGTM; mark libao4 Multi-Arch: same, and send it to Debian?
<StevenK> slangasek: But what about the -dev changes?
<slangasek> what about them?
<StevenK> I had to move where the .a files are and so on, is that a problem?
<StevenK> I'm also a little concern about the plugins
<slangasek> nope; already allowed for by policy, and the standard way to go about it - it does mean that it may break reverse-build-depends, though, so you shouldn't upload to oneiric without an FFe
<slangasek> what worries you about the plugins?
<StevenK> slangasek: That the path changed
<slangasek> well, I was assuming you had tested that the library still finds its plugins ;)
<StevenK> slangasek: I haven't yet, I wanted to check that you thought the diff was sensible first
<slangasek> yep
<StevenK> slangasek: Only libao4 gets Multi-Arch: , nothing else does?
<slangasek> well, libao-common should be made Multi-Arch: foreign (and probably also Architecture: all)
<slangasek> libao-dbg can probably be marked M-A: same
<StevenK> Yes, it's strange that -common isn't.
<slangasek> and libao-dev, it depends on whether there are architecture-dependent headers in there
<StevenK> It contains a conffile and a manual page only for pitys sake
<slangasek> looks like the headers are arch-neutral, so you can mark libao-dev M-A: same as well
<slangasek> that will make cross-building nicer :)
<slangasek> btw, as long as you're in here you might as well drop the .la files from the package
<slangasek> nothing in the archive uses them, and if something did, that something would be broken by them moving directory
<StevenK> Even though it installs usr/include/ao/ao.h and so on?
<slangasek> yep - as long as the files are the same across all archs, they get refcounted
<StevenK> Ahh, but dpkg won't complain like it usually does when two packages contains the same file
<slangasek> right, multiarch handles file overlapping differently
<slangasek> since /usr/share/doc/*/changelog.Debian.gz exists in every package, for example
<StevenK> slangasek: Good to know :-)
<StevenK> Now, how to test plugin loading ...
<irgendwer4711> hi, I have another problem with Bug #193507
<ubottu> Launchpad bug 193507 in linux (Ubuntu) "compile fails without BLK_DEV_INITRD" [Medium,Fix released] https://launchpad.net/bugs/193507
<irgendwer4711> I got this error with  BLK_DEV_INITRD enabled
<salvatore> hello everybody
<salvatore> anybody can help me
<salvatore> with lamp configuration?
<irgendwer4711> no developer active here now
<irgendwer4711> I am waiting too
<Hobbsee> support is in #ubuntu
<salvatore> ok thank u!
<irgendwer4711> for kernel problems too?
<salvatore> no
<irgendwer4711> okay
<irgendwer4711> then can you help me
<salvatore> i am tryng to install
<salvatore> mysql on dropbox
<salvatore> but i got a problem with phpmyadmin
 * Hobbsee has no idea on that kernel issue
<irgendwer4711> damn...
<salvatore> no sorry
<irgendwer4711> any kernel professional here?
<penguin42> irgendwer4711: There is a #ubuntu-kernel I think specifically for kernel issues - but always ask the question rather than asking if anyone is here!
<irgendwer4711> I asked already ;-)
<irgendwer4711> I have another problem with Bug #193507 ; this problem occures with BLK_DEV_INITRD enabled too
<ubottu> Launchpad bug 193507 in linux (Ubuntu) "compile fails without BLK_DEV_INITRD" [Medium,Fix released] https://launchpad.net/bugs/193507
<penguin42> hmm ancient bug
<irgendwer4711> I am using LTS ubuntu
<penguin42> irgendwer4711: Lucid or Hardy ?
<irgendwer4711> hardy
<penguin42> irgendwer4711: OK, so you're rebuilding your kernel just without BLK_DEV_INITRD and you get the same error?
<irgendwer4711> no with BLK_DEV_INITRD
<penguin42> ok, so what are you changing and what exactly is the error?
<irgendwer4711> (.init.text+0x82e): undefined reference to `early_populate_rootfs'
<penguin42> and which version source are you using exactly?
<irgendwer4711> 2.6.24.6 I think
<penguin42> can you check ? That fix in that bug went in 2.6.25-10.16
<irgendwer4711> wich file
<irgendwer4711> dpkg says "2.6.24.29.31"
<penguin42> irgendwer4711: sounds promising
<irgendwer4711> ok
<penguin42> can you pastebin your config?
<irgendwer4711> I try a diff to last working conf
<penguin42> yeh
<irgendwer4711> hm how to print only diffrent with diff ^^
<penguin42> diff oldfile newfile
<irgendwer4711> I mean with wide format
<penguin42> I think that's sdiff - but can't remember how to get it to just show changes
<irgendwer4711> done
<irgendwer4711> http://pastebin.com/2KYn6DR3
<irgendwer4711> I tried to activate some energy savings options und disabled unused drivers
<penguin42> irgendwer4711: Without having a dig in the source I'd suggest putting the CONFIG_ACPI_CUSTOM_DSDT_INITRD back the way it was?
<irgendwer4711> but I dont have a dsdt patch file
 * penguin42 doesn't know much about DSDT
<irgendwer4711> there is a file in initrd that patches the acpi tables
<irgendwer4711> but not for mine acpi
<irgendwer4711> but I can enable this an try
<penguin42> irgendwer4711: Yeh looking at the Ubuntu diff the early_populate_rootfs is ifdef'd on CONFIG_ACPI_CUSTOM_DSDT_INITRD but the ifdef in init/main.c is ifdef'd on CONFIG_BLK_DEV_INITRD
<penguin42> irgendwer4711: If you've not got the custom dsdt initrd just comment out the call in init/main.c somewhere around line 650
<irgendwer4711> I do a new kernel make now
<irgendwer4711> a missing dsdt patch file is not a problem, just a short message in dmesg
<penguin42> irgendwer4711: But yeh it does look like it's using the wrong ifdef - I don't know the history of the older version where bug 193507 was fixed whether the ifdef changed from there
<ubottu> Launchpad bug 193507 in linux (Ubuntu) "compile fails without BLK_DEV_INITRD" [Medium,Fix released] https://launchpad.net/bugs/193507
<irgendwer4711> wait to end of kernel make
<irgendwer4711> okay its donw
<irgendwer4711> no error now
<penguin42> good
<irgendwer4711> thank you
<irgendwer4711> bye
<penguin42> bah, I was going to tell him to open a new bug
<natschil> Hello. To prevent all packages from modifying /etc/example, do I do "dpkg-divert /etc/example --rename /dev/null" or is there some more elegant way?
<natschil> Alternatively, how can I prevent any package from writing to /etc/example
<sgnb> natschil: create a dummy package with a random name containing this file?
<natschil> what about dpkg-divert --divert /etc/example --rename /tmp/some_random_file_name ?
<cjwatson> natschil: 'chattr +i /etc/example' would cause any attempt to write to that file to file
<cjwatson> er, to fail
<cjwatson> personally I would be hesitant about trying to use dpkg-divert for that because at least historically it has had odd interactions with dpkg conffiles and it doesn't do anything useful for maintainer-script-managed configuration files
<cjwatson> ScottK: I may be able to help with k3b in the not too distant future, if somebody else can test the result; I'll queue it up
<natschil> cjwatson: let's say im installing something that wants to change /etc/example. Will that still fail?
<cjwatson> natschil: I'm not sure how to respond except by repeating what I said above
<natschil> cjwatson: ok thanks. I think I will use dpkg-divert instead and hope for the best :/
<cjwatson> well, I can repeat the fact that I do not recommend that
<cjwatson> chattr +i will cause *any* attempt to write to that file to fail
<cjwatson> dpkg-divert will arrange for a very limited subset of writes to be redirected elsewhere, which doesn't cover all the things packages do with files in /etc, and which I suspect will have crazy problems even if it does sometimes work
<cjwatson> the only advantage of dpkg-divert here is that it would arrange for the package to install successfully anyway
<cjwatson> (maybe)
<ScottK> cjwatson: I should be able to test it.
<ScottK> Help would be much appreciated.
<cjwatson> most of them aren't too hard once you get the patterns.  xvidcap is stubbornly segfaulting right now ...
<directhex> Laney found the mono commit which breaks on some (not all) i386 buildds
<SpamapS> lamont: [ -x /usr/bin/dh_apport ] maybe ?
<SpamapS> lamont: for the build-dep we can do an | to make it optional, right?
<broder> cjwatson: for what it's worth, i used diversions heavily when i was at mit, and i think we whined enough that we were able to get the bugs with diversions+conffiles ironed out
<cjwatson> broder: ah, that's something at least
<cjwatson> ScottK: give http://paste.ubuntu.com/671830/ a try?
<cjwatson> (please try not to laugh at my rusty C++)
<cjwatson> hmm, I wonder if my xvidcap crash is actually a libav bug
<cjwatson> looks like its MAP_ANON detection fell over in 0.7 or so
 * cjwatson tries to construct a test that isn't "build xvidcap with this dodgy patch"
#ubuntu-devel 2012-08-13
<Mikeulus> I found the information I was looking for in reset_unity_compiz_profile function.
<Mikeulus> thanks
<dholbach> good morning
<geser> good morning dholbach
<dholbach> hi geser
<mpt_> ev, I'm pretty sure the dip on the errors.ubuntu.com graph for the current day is because it's not dividing by the elapsed proportion of the day
<mpt_> ev, we weren't sure about that before because the dip didn't seem as big as it should be if that was the reason
<ev> mpt_: I thought we tried factoring that in and it swung wildly in the other direction?
<ev> I can't remember the numbers to back that up
<mpt_> But the dip isn't as big as it should be because of the wrong-denominator problem -- at the very start of the day it's 1
<mpt_> So our correction probably put it up to ~24 at the very start of the day, explaining the wild swing :-)
<mpt_> Once the denominator is right, the correction will work too.
<ev> well, it all goes away once we fix the denominator, as that calculation cannot be made in realtime. So the data will only go as far as the day past.
<ev> yup
<mpt_> oh, true
<mpt_> Well, it *could* be made in real time, it would just be a lot of work
<jamespage> any autoconf gurus around? struggling to see how 'if test "$HAVE_SYS_SOCKET_H"; then' in an acinclude.m4 would ever work
<cjwatson> jamespage: That does look wonky since $HAVE_SYS_SOCKET_H is 0 if you don't have the header, and test "anything_non_empty" is true.
<cjwatson> The usual version would be test "$HAVE_SYS_SOCKET_H" = 1
<jamespage> cjwatson, that is what is confusing me; the header is checked for using AC_CHECK_HEADERS
<jamespage> cjwatson, that is then used to wrap a call to AC_EGREP_HEADER to check for a feature
<jamespage> but it never gets executed :-(
<jamespage> cjwatson, I can't see $HAVE_SYS_SOCKET_H getting set at all (although the #define doe get set correctly)
<jamespage> hmm - I think I see the issue
<cjwatson> jamespage: Point me at the branch or something?  I don't know if I'm an autoconf guru, but I can probably play one on TV for the purposes
<cjwatson> OK :)
<jamespage> check should be looking for "$ac_cv_header_sys_socket_h"
<jamespage> so "$ac_cv_header_sys_socket_h" == yes works OK
<cjwatson> Ah yes.  Although that should be =
<cjwatson> (== is a bashism)
<pcarrier> hey!
<pcarrier> anybody would know why xulrunner isn't packaged in precise anymore?
<cjwatson> pcarrier: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance
<pcarrier> cjwatson: that doesn't really explain what the overall choice is. getting rid of xulrunner altogether?
<pcarrier> cjwatson: it's useful for projects like kiwix
<cjwatson> I wasn't involved and don't know any more.  Just providing you a reference.
<jamespage> cjwatson, bah - missed your last comment
 * jamespage makes a note to fix that later today
<xnox> pcarrier: while it is useful, it was a pain to depend on. My package would randomly start segfaulting after e.g. security update to xulrunner and my package had to be rebuild, bumping exact version mathing xulrunner stings each time.
<xnox> pcarrier: plus xulrunner is abandoned upstream and is no longer updated/released/supported/security-supported
<xnox> as a stand-alone / embedable product
<xnox> pcarrier: you should switch to webkit, as it is meant for embeding.
<pcarrier> xnox: sounds like a good answer, thanks :)
<pcarrier> xnox: well, it's not my project
<xnox> pcarrier: or you can become a firefox addon.
<pcarrier> xnox: but thanks
<pcarrier> xnox: that's very much not where those guys want to go, I'm afraid
<xnox> pcarrier: well then them and us go separate ways =) we have OS to support.
<pcarrier> xnox: I know that :) could be a universe package though :)
<pcarrier> xnox: not ranting
<xnox> pcarrier: there are expectations of packages to work in universe as well.
<pcarrier> xnox: I know that ;)
<xnox> if universe is broken it looks bad on the whole distro + all our derivatives + upstreams
<pcarrier> xnox: absolutely
<jamespage> @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: jamespage
<green7> can someone help me in fixing the bug #923932.
<ubottu> Launchpad bug 923932 in libreoffice (Ubuntu) "LibreOffice icons classic" [Undecided,Confirmed] https://launchpad.net/bugs/923932
<green7> can someone help me in fixing the bug #923932.
<ubottu> Launchpad bug 923932 in libreoffice (Ubuntu) "LibreOffice icons classic" [Undecided,In progress] https://launchpad.net/bugs/923932
<xnox> cjwatson: jodh: is sendsigs.omit.d honored in ubuntu (i.e. upstart)?
<xnox> nevermind, as long as /etc/init.d/sengsigs is till used it is honored, but if a script that uses it is converted to an upstart job, it should stop on correctly.
<green7> can someone help me in fixing the bug #923932.
<ubottu> Launchpad bug 923932 in libreoffice (Ubuntu) "LibreOffice icons classic" [Undecided,In progress] https://launchpad.net/bugs/923932
<mpt> ev, any ETA for the next rollout? Or are you still working on the 90-day actives?
<ev> mpt: one just happened, but I'm still working on the 90 days stuff
<ev> the greyed out lines are there though
<ev> let me know what you think
<ev> I need to get a better caching deployment done today too
<ev> as we're not paying any attention to etags from launchpad at the moment
<jodh> xnox: that logic assumes jobs specify an explicit 'stop on' condition; if they don't, they are in limbo land as sendsigs ignores them FWICS. Therefore sendsigs is making a potentially incorrect assumption (upstart_jobs() should parse 'initctl show-config' for each job and check if it does have a 'stop on' before omitting it).
<xnox> jodh: ah. ok. it's just mdmon should still be running after rootfs is unmounted, otherwise mdmon will not manage to stop the underlying RAID array
<xnox> which is hosting the rootfs for example.
<xnox> and mdmon is spawned/started automatically by mdadm, i.e. the udev rule. so it's ok if the pid is in the sendsigs and there is no upstart job.
<Riddell> tkamppeter: my printer doesn't get a driver auto-detected by s-c-p-udev but it works fine when I set it up manually, should I report?
<mpt> ev, whoo, y axis starting at zero. Oddly it seems to have brought the 12.04 line down with it.
<mpt> ev, at least the 12.04 values on the main graph are consistently 1.0 greater than those on the zoom graph.
<tkamppeter> Riddell, which printer do you have and how is it connected?
<Riddell> tkamppeter: USB, epson stylus SX130
<ev> mpt: https://bugs.launchpad.net/errors/+bug/1035866
<ubottu> Launchpad bug 1035866 in Errors "The y-axis ticks no longer map to the same values as the graph data" [Undecided,New]
<seb128> bdmurray, hey, your bot keeps commenting on bug #1035952 in loop for some reason
<ubottu> Launchpad bug 1035952 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon crashed with SIGSEGV in icon_name_hash()" [Undecided,New] https://launchpad.net/bugs/1035952
<bdmurray> seb128: thanks, looking
<dupondje> 19 UTC is within 4 hours right ? :)
<seb128> bdmurray, thank you
<seb128> dupondje, yes
<dupondje> so I don't come late for my MOTU application :)
<bdmurray> seb128: it is commenting on it because of the bug pattern for that "master" bug - http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/view/head:/bugpatterns.xml#L1777
<seb128> bdmurray, hum, the bug only has 1 comment, I wonder why I received 4 emails about it today
<seb128> they seems to be every second hour at :47
<bdmurray> seb128: oh, maybe the actually marking it as a duplicate failed
<seb128> bdmurray, seems likely
<seb128> hum
<seb128> wth, http://pastebin.ubuntu.com/1144977/
<seb128> "Rejected:
<seb128> dpkg-source failed for file-roller_3.5.4-0ubuntu3.dsc [return: 2]
<seb128> [dpkg-source output:   dpkg-source: info: extracting file-roller in file-roller-3.5.4"
<seb128> but I can dpkg-source -x that source file locally
<seb128> fine
<cjwatson> seb128: can you put the source package somewhere for me to look at?
<seb128> cjwatson, dget http://people.canonical.com/~seb128/file-roller_3.5.4-0ubuntu3.dsc and the orig is in quantal
<seb128> cjwatson, do you want the full reject email for launchpad as well?
<cjwatson> seb128: no, I can get that from production logs
<cjwatson> or near neough
<seb128> ok
<cjwatson> *enough
<seb128> there is no actual error in the email
<seb128> just blank lines
<jibel> bdmurray, about bug 1029046 I am not sure about the test case
<ubottu> Launchpad bug 1029046 in update-manager (Ubuntu Precise) "include system state from apt-clone in apport package hook" [High,Fix committed] https://launchpad.net/bugs/1029046
<jibel> bdmurray, shouldn't it be tested with an upgrade from Oneiric to Precise ?
<jibel> bdmurray, instead of Precise to Quantal
<jibel> because the version of the upgrader used during an upgrade is the version from the target release
<bdmurray> jibel: yes, you are correct
<bdmurray> jibel: do you want me to fix the description?
<jibel> bdmurray, that's fine. thanks, I'll do the verification
<seb128> cjwatson, do you want me to open a bug or something about the file-roller upload issue? I've an updated version (got an extra git commit), should I try to upload that one or do you want to keep the issue as a testcase?
<cjwatson> seb128: sorry for the delay, I'm in roaming mode this afternoon and I got locked out of library wifi
<cjwatson> I'll be back on it in a moment
<GrueMaster> So, with Unity-2d being dropped, what is the preffered solution for remote desktop usage?  Unity/Compiz currently fails, unless using VNC, which is a bandwidth hog.
<cjwatson> seb128: here's the actual error from dpkg-source:
<cjwatson> dpkg-source: error: expected [ +-] at start of line 11232 of diff `file-roller-3.5.4/debian/patches/git_src_update.patch'
<cjwatson> seb128: I suspect you'll find that dpkg-source -x would fail likewise in a lucid chroot
<cjwatson> yep, it does
<cjwatson> -</interface>
<cjwatson> \ Pas de fin de ligne Ã  la fin du fichier
<cjwatson> +</interface>
<cjwatson> so it objects to that - simplest fix might be to strip the trailing newline from that file and rediff (or just delete the \-prefixed line from that patch)
<cjwatson> kind of surprised we haven't encountered this before mind you
<cjwatson> it'll be fixed once LP moves to precise, since precise's dpkg-source doesn't object to this
<cjwatson> ah
<cjwatson> or you could regenerate that patch in LANG=C
<cjwatson> here's lucid's dpkg-source code:
<cjwatson>                 next if /^\\ No newline/;
<cjwatson> in precise it's just:
<cjwatson>                 next if /^\\ /;
<seb128> cjwatson, thanks
<xnox> Anyone has a spare intel matrix raid controller?
<tumbleweed> you get them as standalone controllers? I thought that was just a bios thing
<xnox> tumbleweed: well system which has an intel matrix raid controller, it's not stand alone but can be build into cpu/bios, bridge, intel sata controller cards as far as I understand it.
<xnox> tumbleweed: if you know how to *find* hw capable of intel matrix raid, i'd love my next laptop to have it =)
<stgraber> xnox: they usually appear as "00:1f.2 RAID bus controller: Intel Corporation 82801 SATA Controller [RAID mode] (rev 02)"
<xnox> stgraber: thanks!
<stgraber> xnox: pciid is 8086:2822 here. You might be able to find some matching hardware in the lab by looking for that on hexr.canonical.com, if you're lucky there's a server in the lab that you can get access to
<xnox> stgraber: sweet!
<barry> jdstrand: ping
<jdstrand> barry: hey
<barry> jdstrand: hi.  there's a bug in https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment
<jdstrand> barry: is this for quantal?
<barry> jdstrand: yep
<barry> jdstrand: script-get-ddebs can't source /etc/schroot/default/config because that file does not exist
<jdstrand> barry: may I direct you to tyhicks? he was looking at fixing those things
<barry> tyhicks`: ^^ (thanks jdstrand)
<tyhicks`> hey barry
<jdstrand> barry: I think tyhicks` is afk atm, but he'll be back in a bit
<barry> tyhicks`: just pointing out that /etc/schroot/default/config doesn't exist in quantal afaict
<tyhicks`> barry: You're right. The schroot configuration dir was shuffled around a bit.
<tyhicks`> barry: I have things working pretty well on my system now
<barry> tyhicks`: cool.  do you have an update for script-get-ddebs?
<tyhicks`> barry: Would it be ok if I got the wiki updated over the next 20 minutes or so and then pointed you at the updated page?
<tyhicks`> (I don't know how urgent you need things to be working again)
<barry> tyhicks`: whatever is easiest for you.  i was going to do a test build of a package i need to update (just updated my main box to quantal).  but i think the patch is good so i'll forgo the test build for now and just upload it :)
<barry> tyhicks`: can you ping me when the page is updated?  my email is temporarily down
<tyhicks`> barry: Will do
<barry> tyhicks`: thanks!
<tyhicks`> np
<shadeslayer> cjwatson: pingly
<shadeslayer> cjwatson: let's say I wanted to add a couple of 3rd party archives using live build, but some of the repos have a different component than the others, how can I accomplish that?
<shadeslayer> because using --archives foo --archive-areas bar for every repo makes it choose the last repo
<shadeslayer> and all other repos are overwritten
<shadeslayer> oh, hmm
<shadeslayer> there we go \o/
<shadeslayer> though I'm still certain that it'll fail since it won't find the main component on archive.canonical.com
<shadeslayer> or the partner component on the PPA's
<Peace-> byzanz-record is not in the repository
<Peace-> why?
<Peace-> there was
<Peace-> on 12.04 there is not
<Peace-> thre is a ppa that work for 12.10 too btw
<tyhicks> barry: Ok, finally got it finished: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Upgrading_to_Quantal_.2812.10.29
<tyhicks> barry: Please make a backup of everything and proceed with caution
<barry> tyhicks: thanks, trying...
<tyhicks> barry: You're the first one to follow my instructions on this, so you may hit some bumps :/
<barry> tyhicks: "guinea pig" is my middle name!
<tyhicks> barry: Exactly! :)  Let me know of any problems and we'll work through them
<barry> tyhicks: i've always stopped reading at "umt" :)
<tyhicks> barry: Hmm.. well do you need the whole script-get-ddebs magic? I assumed it was for umt.
<barry> tyhicks: maybe i don't and didn't know it
<barry> tyhicks: anyway, let me play around with it and see
<tyhicks> jdstrand: Do you know if /etc/schroot/script-get-ddebs is only for umt?
<tyhicks> barry: The core of the problem is that schroot deprecated the script-config option in schroot.conf, in favor of the profile option, and then /etc/schroot/ was shuffled around to match that
<tyhicks> barry: That's all you need to work around
<barry> tyhicks, jdstrand: maybe if i don't use umt, i don't need script-config at all and can just comment it out?
<tyhicks> barry: That's what I'm wondering, as well. I don't know the history of script-get-ddebs well enough to say for sure though :/
<jdstrand> tyhicks: ah sorry-- script-get-ddebs shouldn't strictly be needed even for umt
<tyhicks> jdstrand: Is it needed at all anymore?
<jdstrand> it is just there to snag the ddebs
<jdstrand> well, if you want ddebs it is needed
<tyhicks> Ok. I updated the wiki page to provide an equivalent setup to what was already described.
<barry> so perhaps that's just not needed for ordinary test builds
<tyhicks> barry: If you don't need access to the ddebs, then you should be fine just removing the script-config option from schroot.conf.
<barry> tyhicks: gotcha.  i'm going to just try that and see how it goes
<tyhicks> sounds good
<barry> tyhicks, jdstrand thanks!
<tyhicks> np
<robert_ancell> @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: robert_ancell, jamespage
<mdeslaur> barry: any idea how I can decode a hex string that works in both python 2 and python 3?
<barry> mdeslaur: string or bytes? ;)
<barry> mdeslaur: do you have an example?
<mdeslaur> it's a result from re.findall
<mdeslaur> ie: "4a4b4c"
<mdeslaur> I used to be able to do .decode("hex")
<mdeslaur> and now I can do bytes.fromhex("4a4b4c").decode('utf-8')
<mdeslaur> but, is there a way that works in both?
 * barry thinks
<mdeslaur> you can say no too :)
<barry> mdeslaur: off-hand i don't ;)
<mdeslaur> ok, thanks :)
<GrueMaster> mdeslaur: What are you trying to decode it to?  Can you use int('4a4b4c',16)?
<GrueMaster> I just tried it in both 2.7 & 3.2.  Seems to work for me.
<mdeslaur> GrueMaster: it's a text string that's hex encoded, so no, not an int
<GrueMaster> int converts text strings to integers.
<GrueMaster> >>> int('4a4b4c',16)
<GrueMaster> 4868940
<GrueMaster> Thisis what I get when I run this in "python -i".
<mdeslaur> GrueMaster: I don't want an integer, I want a string back
<mdeslaur> ie: '5468697320697320736f6d652074657874'.decode('hex')
<GrueMaster> Oh.  Give me a sec, I might have a solution.
#ubuntu-devel 2012-08-14
<GrueMaster> Sorry, got pulled away just after I typed that.
<GrueMaster> I'm not seeing anything in my notes.  THought I had.
<jono> hey all
<jono> which package should I file a gtk bug against?
<micahg> jono: which version of GTK?
<jono> ahh gir1.2-gtk-3.0
<jono> GTK3
<jono> thanks micahg
<silvio> hi. i have been running some automated scans checking that embedded libraries are being licensed correctly. which channel should i join to ask some license related questions for packages? (specifically, i have some questions about libjpeg8)
<micahg> silvio: if it's about in archive stuff, you can ask here
<silvio> ok. if package X depends on Y,Z and is just a dummy package to pull in those extra packages.. and Y,Z are BSD'ish licenses.. what license should X be?
<micahg> anything compatible...
<silvio> ok.. so libjpeg8 is licensed under GPL, but it's a dummy package to pull in permissively licensed jpeg code... and  libjpeg8 has packages dependant on it which are non GPL compatable
<silvio> err. libjpeg8 is LGPL
<silvio> i am wondering ig libjpeg8 is licensed incorrectly.
<micahg> we're not using libjpeg8, but libjpeg-turbo
<silvio> libjpeg8 is a dummy package that pulls in libjpeg-turbo
<silvio> as far as i can tell
<micahg> yes
<JontheEchidna> right, and the dummy package is not the original work
<JontheEchidna> since it is empty
<silvio> how should dummy packages be licensed?
<JontheEchidna> the packaging itself is licensed, using the license specified in debian/copyright of the source package
<slangasek> though honestly, if there's anything in the libjpeg8-empty source package that one can legitimately assert copyright over, I think they're doing it wrong. ;)
<JontheEchidna> right, and no derivative work would actually be linking against anything in there
<silvio> ok, that makes sense. i wasn't sure if that was the case or not. so not an issue. i have been running a scan checking embedded-code-copies.txt and making sure embedded libraries that are GPL are embedded in GPL compatable packages.
<silvio> i don't think i've seen anything else that presented as an issue so far.
<silvio> ok. thanks guys. cya
<robert_ancell_> @pilot out
<robert_ancell_> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<robert_ancell_> @pilot out
<robert_ancell> @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: jamespage
* kornbluth.freenode.net 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: robert_ancell, jamespage
<dholbach> good morning
<didrocks> hey dholbach
<dholbach> hey didrocks
<xnox> Guten Morgen ;-) =)
<ogra_> Riddell, if you want kubuntu on nvidia tegra arm to run, adding this patch to kwin would be good https://git.reviewboard.kde.org/users/griffais
<ogra_> s/this patch/these patches/
<Riddell> ogra_: those patches have been in kwin for 9 months now
<ogra_> Riddell, oh, ok, i didnt know someone just dropped tzhem on my lap right now :)
<tjaalton> infinity: I see that -omapfb is basically abandoned, and that -omap replaces it (uploaded a new upstream release to quantal-proposed). agreed?
<seb128> ev, hey
<seb128> ev, when do you think we will get the "month" view of e.u.c working again?
<ev> seb128: it was working fine again up until yesterday's deployment. It seems the Launchpad integration is causing some timeouts. I'm in the process of looking into it.
<seb128> ev, ok, thanks, it doesn't work here (or I got unlucky)
<dholbach> @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: robert_ancell, jamespage,
 * seb128 hugs dholbach
 * dholbach hugs seb128 back :)
<seb128> ;-)
<dholbach> can somebody please reject https://code.launchpad.net/~cldunlap1/ubuntu/quantal/ciderwebmail/typo-fix/+merge/119413 (typo fix already forwarded to Debian)
<dholbach> slomo, hey - how are you doing?
<dholbach> any idea what could be done with https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad0.10/+bug/973014?
<ubottu> Launchpad bug 973014 in gst-plugins-bad0.10 (Ubuntu) "gstreamer0.10-plugins-bad, (libgstvideoparsersbad.so), causes a failure to decode many common video files encoded as AVC 1 Baseline - L2.1, Baseline - L1.1 & others" [Undecided,Confirmed]
<melodie_> hi
<melodie_> I have a general question about develpment, but non-tech : where should I ask, please ?
<melodie_> s/develpment/development/
<dholbach> micahg, bdrung, regarding the ubuntu-branches timeout: it seems if we use the anonymous login we can get a list of open merge proposals from LP - I know it's a dirty workaround, but we could use a second LP login to get the list for now
<dholbach> if I have a bit of time later on, I'll look into it - otherwise feel free to go ahead with this :)
<dholbach> http://reqorts.qa.ubuntu.com/reports/sponsoring/ has merge proposals again! go wild!
<shadeslayer> ev: ping
<shadeslayer> ev: I'm trying to merge live-build from debian, and there's a ubuntu specific patch that adds a framebuffer to initramfs, is that patch still valid for quantal?
<shadeslayer> i.e. are wubi installs still supported?
<cjwatson> If you're merging live-build, keep all our custom patches.
<ev> shadeslayer: yes
<ev> yes they are
<shadeslayer> cjwatson: some of them have been applied upstream
<cjwatson> It's not worth dropping things in a merge only to discover that we needed them.
<cjwatson> Well, that's not dropping them then, is it :-)
<shadeslayer> ofcourse :P
<shadeslayer> cjwatson: btw, could you look into ubuntu-armhf-support.patch and ubuntu-kernel-img-conf.patch
<cjwatson> Not today or tomorrow.
<shadeslayer> for armhf, live build upstream does a special case ... but it's different from armel
<shadeslayer> oh ok
<shadeslayer> I'll disable it for now, since I'm not aiming at armhf
<cjwatson> Then your merge needs to not go to the Ubuntu archive.
<shadeslayer> ofcourse
<cjwatson> We have to keep armhf working.
<shadeslayer> I don't have upload rights anyway :P
<shadeslayer> plus, I wasn't planning on uploading to archive anyway
<cjwatson> Right, but you might have been planning to propose it for review.
<shadeslayer> nope
<shadeslayer> I wanted to consult you before even uploading for review
<shadeslayer> cjwatson: could you let me know when we can discuss this?
 * shadeslayer can plan accordingly
<cjwatson> Personally I'm afraid I find reviewing merges much harder than just doing them.
<shadeslayer> haha :D
<cjwatson> Because I generally have to basically do the merge in order to review it effectively.
<shadeslayer> I understand :)
<cjwatson> So I'd certainly be happy (well, more or less) to do the merge later this week - but I only have a couple of hours left today, and a funeral to attend tomorrow
<shadeslayer> cjwatson: I'll probably upload this to my ppa for now, and I'll give you the link :)
<seb128> tseliot, hey, what's the status of bug #1026518
<seb128> ?
<ubottu> Launchpad bug 1026518 in ubuntu-drivers-common (Ubuntu) "Add support for the Cedarview graphics driver" [High,Triaged] https://launchpad.net/bugs/1026518
<tseliot> seb128: that's a good question. The package still seems to live in precise-proposed
<seb128> tseliot, right, that's why I'm asking, can you verify it? it needs to be verified so it can go to updates or rejected at this point (.1 getting close)
<tseliot> seb128: sure
<seb128> tseliot, thanks
<melodie_> bye
<dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/quantal/openvswitch/debian-merge/+merge/118037 (based on the comment in the MP)
<stgraber> dholbach: done
<dholbach> @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: jamespage,, robert_ancell
<dholbach> thanks stgraber
<dholbach> stgraber, can you please reject https://code.launchpad.net/~cldunlap1/ubuntu/quantal/ciderwebmail/typo-fix/+merge/119413 (typo fix already forwarded to Debian) too?
<mdeslaur> ev: so, on my tablet, I have two cameras, a forward facing one, and a rear one...ubiquity selects the rear one by default...is there a bug open for that?
<ev> mdeslaur: not that I'm aware of, though I haven't kept track of the ubiquity bugs this cycle at all, what with the errors.ubuntu.com work
<mdeslaur> ev: ok, cool...wanted to see if you knew of one before opening a new one, thanks
<ev> sure thing
<ev> thanks for filing
<stgraber> dholbach: done
<dholbach> thanks stgraber
<micahg> dholbach: I think we specifically want an unprivileged account for the sponsorship queue, anonymous sounds better :)
<dholbach> micahg, we can't - to get information about who can upload what we need to be logged in
<dholbach> but if that wasn't the case, I'd totally agree
<micahg> dholbach: well, it still needs to be an unprivileged authenticated user then
<dholbach> yes, we need authentication for that bit at least
<micahg> tjaalton: /me is puzzled by an upload for a -dbg package, don't we have dbgsym packages automatically?
<infinity> micahg: We don't intentionally strip them out when the Debian packaging includes -dbg packages, it's a pointless delta.
<micahg> infinity: yes, but I thought we don't specifically add those to in archive packages since we have the ddebs
<infinity> micahg: I'm likely missing the upload where that happened.  But I would, generally, assume it was the result of a merge or other convergence with Debian...?
<micahg> infinity: https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/1.6.2-1ubuntu4
<infinity> micahg: Ahh, indeed.  Well, the Debian package will have a -dbg "soon", if 652992 is to be believed, so maybe it's pre-emptive convergence? ;)
<xnox> M-A: same; must be co-installable, must not install /usr/lib/libda.so, but should install /usr/lib/$(DEB_HOST_MULTIARCH)/libda.so
<xnox> in the -dev package that is for example
<xnox> ?
<xnox> or did I get it wrong...?
<infinity> xnox: I've never multiarched a -dev package but, yes, that seems like a reasonable interpretation of how one would do it.
<xnox> infinity: ok. reality check with infinity passed, I am on the right track then.
<xnox> infinity: i am merging lvm2 which is now multiarched. what possibly can go wrong? =)
 * stgraber makes a note not to update his quantal systems for another week or so ;)
 * xnox pinned all filesystem packages long time ago on all of my hosts/servers/friends etc.
<infinity> xnox: That's a serious vote of confidence in your own work...
<xnox> i did upload e2fsprogs today... upstream broke linking the whole package in a micro-point release =) was marvellous 20 minutes of fun
<xnox> I wish it used automake....
<xnox> infinity: oh It's pinned to quantal-proposed on all precise&quantal machines ;-)
<hyperair> hmm, how do i get apt-get dist-upgrade to follow an upgrade path that involves (on an amd64 machine) replacing foo (which depends on libc-i386) with foo:i386?
<hyperair> i've got a package bar which is arch:all that depends upon foo, but apt-get just marks that package under kept back, even with dist-upgrade
<hyperair> and foo is marked multi-arch: foreign
<green7> I've to download libreoffice source code to work on a bug. Is there any other method instead of bzr? bzr is horrendously slow.
<stokachu> jamespage: hi, do you have the ability to sponsor userspace?
<stokachu> i can't remember if you were the one that only did kernel
<ScottK> green7: apt-get source $packagename
<jamespage> stokachu, not me I'm afraid
<green7> ScottK: There'll be no problems while submitting the patch, right?
<stokachu> jamespage: sorry :) was that a not me to userspace?
<jamespage> stokachu, I don't do kernel - what do you want sponsored?
<stokachu> jamespage: https://code.launchpad.net/~louis-bouchard/ubuntu/precise/kexec-tools/lp988512-no-vmcoreinfo/+merge/112086
<stokachu> this merge proposal has been approved just needs to make it into proposed
<stokachu> its the userspace portion of kdump
<jamespage> stokachu, TBH thats a little outside my comfort zone; I'd prefer someone more knowledgeable review/sponsor
<stokachu> jamespage: any recommendations?
<xnox> green7: regular patches are excepted just fine. create a bug + attach a patch + subscribe ~ubuntu-sponsors team.
<stokachu> ooo xnox :D
<xnox> stokachu: Hola! =)
<stokachu> hey there!
<xnox> stokachu: it sounds like you want me to do something for you right?
<stokachu> lol you know me so well
<stokachu> xnox: https://code.launchpad.net/~louis-bouchard/ubuntu/precise/kexec-tools/lp988512-no-vmcoreinfo/+merge/112086 <-- is this something you dont mind reviewing?
<infinity> stokachu: The changelod mess doesn't give me a bunch of confidence that the rest of the patch is complete. :P
<infinity> Nor the changelog.
<infinity> Dear irony, go away.
<stokachu> yea he's pretty new at this, though oddly the revisions are clean its just that preview diff for some reason
<xnox> stokachu: revisions are clean ... against precise, not quantal changelog
<stokachu> ahh.. well there's the problem
<infinity> (This is, actually, one of the reasons why I prefer diffs to MPs)
<stokachu> ok so ill have him redo the diff against quantal
<stokachu> then backport to precise
<infinity> stokachu: Nah, I can sponsor to both and tidy up the changelog myself.  Just rap him on the nose with a newspaper.
<xnox> stokachu: it's fine, manually fix up the version string.
<stokachu> awesome thanks guys, ill make sure to have a writeup for the rest of the team
<xnox> stokachu: it's not his fault that from the time he proposed the merge and by the time we review it (i) precise got released (ii) a merge happened in quantal.
<stokachu> some "guidelines" in order to not lose limbs
<stokachu> xnox: ah gotcha
<xnox> stokachu: it looks fine, but i don't know what vmcoreinfo is/was
<stokachu> xnox: i think it was previously used by kdump when dumping the kernel's memory to a core
<stokachu> xnox: i think now it just uses vmlinux
<stokachu> or /proc/vmcore
<stokachu> xnox: https://bugs.launchpad.net/ubuntu/precise/+source/kexec-tools/+bug/988512/comments/19
<ubottu> Launchpad bug 988512 in kexec-tools (Ubuntu Quantal) "Missing /boot/vmcoreinfo-{version} file is breaking kdump" [Medium,In progress]
<stokachu> that explains the reasoning behind it
<barry> @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: jamespage,, robert_ancell,
* barry 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:
<barry> @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: barry
<barry> that's better
<barry> (are jamespage and robert_ancell actually piloting today?)
<ScottK> green7: Submissions can be done either as a patch or a bzr branch, so it should be fine.
<jamespage> barry, no - just forgot to pilot out yesterday
<barry> jamespage: np.  it looked like the bot was broken anyway
<jamespage> barry, ta - have fun...
<infinity> barry: Seems unlikely that Robert's piloting, since he's not even here. ;)
<barry> ;)
<stgraber> barry: I don't think the bot was really broken, looked like people forgeting to @pilot out and the topic overflowing (explaining why it only managed to append a , and not your name)
<stokachu> stgraber: its easier to blame the children though
<stokachu> :D
<tjaalton> micahg: right, it was merged from debian git. and ddebs are not that easy to use, unlike -dbg packages which are always available
<rsalveti> tjaalton: any idea when we'll be pushing the new xorg packages from proposed?
<rsalveti> tjaalton: I'm working no on checking and testing the omap x11 driver, to see if the support for sgx will still work fine with the latest xorg release
<rsalveti> seems upstream is still at xorg-server-1.12.99.904
<rsalveti> and I know feature freeze will happen during next week
<rsalveti> so just wanted to have an idea of when the new packages will actually land at quantal
<green7> how do I submit my patch without using bzr?
<slangasek> rsalveti: they're supposed to be getting pushed this week once we have a full set of driver packages built
<rsalveti> slangasek: great
<green7> can anyone help me out?
<green7> how do I submit my patch without using bzr?
<ScottK> green7: Make a debdiff or just a regular diff and attach the file to the bug. Then subscribe ubuntu-sponsors to the bug.
<stokachu> barry: do you mind reviewing https://code.launchpad.net/~adam-stokes/ubuntu/precise/tzdata/tzdata-2012d-1/+merge/119613
<green7> ScottK: I've added binary files
<ScottK> Needs to be source
<barry> stokachu: sure thing
<stokachu> thanks
<barry> c'mon diffy diff
<stokachu> ah still updating
<green7> what am i supposed to do?
<stokachu> barry: hmm i guess this is a good time to refill the coffee
<barry> stokachu: i'll come back to it
<stokachu> barry: ok no worries ill keep an eye on it and ping you when it shows up if thats cool
<barry> stokachu: np
<stokachu> thanks
<christoffer> Is there any cost for the UDS in Copenhagen?
<slangasek> christoffer: UDS is always free to attend
<christoffer> awesome =)
<christoffer> flight is booked
<stokachu> i hear copenhagen has great gluten free bakeries/restaurants
<stokachu> im excited
<barry> \o/
 * xnox is pondring sleeper train or flying
<slangasek> taxi on a ferry
<stokachu> may take you a year but what a trip!
<slangasek> nah, it's a much more direct route :)
<slangasek> (well, no, not really)
<stokachu> lol
<green7> should I attach both the binary files, and the patch?
<xnox> stokachu: 17 hours. Eurostar to brussels, train to Cologne & sleeper train to copenhagen =)
<slangasek> green7: what binary files are you attaching?
<green7> there were some icons missing, i added them
<stokachu> xnox: nice.. ill probaby be flying for 10 hours
<slangasek> ok.  So you can attach those separately from the patch, yes
<green7> in a tar.gz file?
<barry> stokachu: with how long a layover? ;)
<stokachu> barry: they haven't sent me the flight info yet :(
<stokachu> but from what i saw it ranged from 2-3 at LHR
<slangasek> green7: probably individually?
<barry> sigh, my email's been down for 2 days
<green7> all right
<xnox> stokachu: 1.5 hours to the airport, 2 hours in the airport, 2 hours flying, 1 hour arrivals, 1 hour ground transportation. 8.5h so couple of hours on the train + a sleeper sounds nice actually
<slangasek> green7: but I wonder why you're asking how to do this *without* using bzr, since bzr makes this case much easier
<stokachu> xnox: definately, i personally would take a train if possible
<stokachu> i have this thing about flying over large bodies of water for 90% of the trip
<green7> slangasek: I had to download the source. bzr was very slow, so I downloaded using apt-get source. By the way, I'm working on LibreOffice.
<slangasek> green7: oh... that's a good reason. ;)
<slangasek> stokachu: I do too... it means there's no in-flight Internet!
<green7> slangasek: thanks for the help.
<stokachu> slangasek: i know right! still makes me wonder how i survived the dialup/bbs days
<stgraber> stokachu: bah, just do like sladen did back in Orlando and spend a week on a boat ;)
<micahg> green7: did you chat with Sweetshark yet?
<green7> yes, once
<stokachu> stgraber: haha, i tried to see if disney cruises had a line there but i was let down
<xnox> stokachu: you survived... because you didn't know broadband!
<stokachu> xnox: lol kids dont know how good they have it these days
<xnox> stokachu: i always check the live jacket "under your seat" in case it's not ther
<stokachu> haha
<stokachu> i think all flights should come packaged with those paratroopere halo jump suits.
<stokachu> worse case scenario i could batwing it halfway there
<green7> micahg: Okay , I uploaded the patch. Now should I just wait? Or how can I send it for a review?
<micahg> @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: barry, micahg
<micahg> green7: subscribe ubuntu-sponsors or I can take a look at it
<slangasek> xnox: you mean you know how to find the life jacket?
<slangasek> I've tried and never succeeded in identifying the jacket :)
<green7> micahg: Here is the bug https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/923932
<ubottu> Launchpad bug 923932 in gnome-panel (Ubuntu) "[Classic session] LibreOffice icons are larger than other app's icons" [Undecided,Confirmed]
<green7> micahg: subscribing ubuntu-sponsors means subscribing to ubuntu-sponsors mailing list?
<xnox> slangasek: yes.
<micahg> green7: no, it means clicking subscribe someone else and adding ubuntu-sponsors
<slangasek> xnox: please tell me the secret :)
<green7> micahg: Oh, thank you
<xnox> slangasek: i once had a children jacket instead of adult one =/
<slangasek> heh
<micahg> green7: binary diffs don't work too well, I think this is something that should go upstream as I originally mentioned to you
<xnox> slangasek: if it's under the seat it has velcro fabric around it, take that off and it's there a bit deep than one would think it is.
<micahg> green7: what did Sweetshark say about upstreaming this?
<xnox> unless it's hidden in the 'overhead' compartment, which is meant to 'open automatically' =/
<green7> micahg: he said me to go on with it.
<micahg> Sweetshark: I'd like to chat with you about lp923932 if you're still around
<stokachu> barry: looks like the diff is there now
<micahg> barry: can I assume you're working on branches and I can safely work on debdiffs?
<barry> micahg: +1
<barry> stokachu: k, let me finish this current review
<stokachu> barry: cool man thanks
<barry> stokachu: i'll make you a deal.  i'll review this if you fix lp to only show me the debian/ directory on source branch diffs ;)
<stokachu> hahah
<stokachu> i mean.. sure ill see what i can do :)
<barry> stokachu: not that it isn't fun to review a 4023 line diff, mind you
<stokachu> lol my bad, however, the majority of it is translation
<slangasek> stokachu: kexec-tools uploaded
<stokachu> i think those should be ignored
<stokachu> slangasek: awesome thanks so much
<barry> stokachu: having my middle finger caress the scroll wheel as it points to the lp page does seem rather poignant
<slangasek> oh, but it didn't like my upload to precise-proposed, let's see
<stokachu> barry: lol i love the romantic spin you put on it
 * barry â¡ lp
<stokachu> barry: is it bad that it takes me a full 3 seconds to page up from the bottom of that MP :P
<barry> stokachu: probably not a *good* sign
<stokachu> lol
<xnox> barry: X can rotate screen 90 degrees... for a reason!
<barry> :)
<barry> stokachu: isn't tzdata is a special sru case?  i'm not exactly sure what the rules for it are
<xnox> stokachu: as in it's installer component, and we will need to refresh all of them before final image respin type of thing?
<ScottK> Also it's got a micro-release exception, IIRC.
<stokachu> barry: im under the impression tzdata policy is pretty relaxed
<stokachu> xnox: its probably a good idea to do that if its not to late
<barry> slangasek: do you know what the scoop is for tzdata sru?
<slangasek> barry: it's data, and if it's not up to date it's a bug by definition; so we take the full upstream bump as an SRU for all releases
<slangasek> not sure if this is documented anywhere, let me check and fix if not
<infinity> barry: With tzdata SRUs, we just take the upstream data, and do a bit of verfication that it (a) fixes specific bugs we wanted fixed and (b) doesn't horribly regress and make everyone appear to be in Tanzania.
<slangasek> https://wiki.ubuntu.com/StableReleaseUpdates#tzdata
<slangasek> yes, it's documented :)
<barry> slangasek: does it still go through -proposed?
<slangasek> barry: yes
<xnox> infinity: i bet it did once make everyone appear in Tanzania
<stokachu> haha
<dobey> anyone know how to get a -dbg package that's not empty, for a package using cmake to build a library?
 * barry appeared in tanzania once, but it was blamed on the kombucha mold
<barry> slangasek: so then stokachu needs to change his changelog entry to precise-proposed
<slangasek> barry: correct
<stokachu> ah ok
<barry> and i suppose also file an sru bug
<stokachu> so does my name appear on the changelog?
<barry> stokachu: and link the bug to your branch
<stokachu> so a normal sru process where i update the changelog and link related branch
<barry> stokachu: i think it would be fine to include the above url to the verification procedure
<barry> stokachu: i think so
<stokachu> barry: as the test case you mean?
<barry> right
<stokachu> ok gotcha
<stokachu> ill do that now
<barry> thanks
<stokachu> barry: do you mind accepting the series nomination for precise in the bug?
<stokachu> pad.lv/1031836
<barry> stokachu: done!
<stokachu> so for this since there was no ubuntu version im starting at 0.1? tzdata (2012d-1ubuntu0.1) precise-proposed; urgency=low
<stokachu> or just ubuntu1
<micahg> stokachu: it needs to go to all releases, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging for versioning suggestions
<stokachu> micahg: cool thanks that helps a lot
<barry> stokachu: and "dpkg --compare-versions" can help
<infinity> stokachu: Traditionally, we've gone with something like -0ubuntu0.11.10 -0ubuntu0.10.04, and such.
<infinity> stokachu: FTR, given that this is done by glibc maintainers in Debian, I don't mind if you pass this off to me for Ubuntu as well (I've done it in the past).
<slangasek> it's probably worth plucking a previous SRU bug out of the changelog and looking at how it's been done in the past
<infinity> Or looking at https://launchpad.net/ubuntu/+source/tzdata/+publishinghistory
<infinity> Which shows fairly consistent versioning.
<stokachu> i dont think there is one in the changelog
<infinity> (Except for hardy, which requires a repack...)
<stokachu> lol lp times out
<slangasek> infinity: I meant for a template for the SRU bug
<infinity> Ahh.
<slangasek> blah, are we still not done with hardy? :)
<infinity> Well, that would also aim him at those. ;)
<infinity> https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/881250
<infinity> For instance.
<ubottu> Launchpad bug 881250 in tzdata (Ubuntu Precise) "Clocks in Ukraine move back October 30, 2011" [High,Fix released]
<infinity> Or, the most recently-fixed:
<infinity> https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/948328
<ubottu> Launchpad bug 948328 in tzdata (Ubuntu Precise) "update database due to a change in Chilean timezone" [High,Fix released]
<stokachu> ah i see the version there
<stokachu> barry: ok i updated the MP, wrote the sru template, and linked the branch
<stokachu> though i followed the link micahg sent about the versioning and appended 0.1
<micahg> stokachu: hrm, that's not quite right...it has to go to all releases
<infinity> stokachu: Following what we've done with the packages in the past might be nice.
<micahg> I guess that doc doesn't make it clear in the uncommon case where you want to push a new upstream version to all releases
 * micahg fixes
<stokachu> yea i think im confused by what you mean on how to push to all releases
<stokachu> or the proper way
<barry> stokachu: also the 2012d-1 changelog entry looks weird (i did a bzr pull of your branch)
<infinity> stokachu: You looked at the publishing history, right?
<stokachu> infinity: ok i can do that, something like 0.12.04.1?
<stokachu> or leave off the .1
<infinity> stokachu: -0ubuntu0.12.04
<infinity> stokachu: And every other release.
<infinity> stokachu: It needs to go to all of them.
<infinity> stokachu: Plus, hardy needs a repack, as hardy's dpkg-dev can't deal with the source format in later releases.
<stokachu> i tried looking at the publishing history but lp was timing out with a oops
<infinity> stokachu: Right, so, the publishing history would show you that when $devel_release has 1.2.3-1, then we backport to older releases as 1.2.3-0ubuntu0.12.04, etc.
<infinity> stokachu: With the exception of hardy, which we can discuss after that bit's done. ;)
<infinity> stokachu: Cause tzdata in hardy is a bit icky.
<slangasek> stokachu: are you using this link?: https://launchpad.net/ubuntu/+source/tzdata/+publishinghistory
<slangasek> loads for me
<infinity> stokachu: And, as much as merge proposals are fun and all, I highly recommend you just backport quantal's package with nothing more than a changelog entry with the new version, and dump the sources somewhere for someone to verify and sign.
<stokachu> yea it just came up now
<infinity> stokachu: Cause, well.  A bazillion line MP is pointless.  Something I can diff against quantal and say "yeahp, that's identical except for the changelog", is easier.
<stokachu> infinity: ah, understood ill do that from now on
<micahg> infinity: umm, unless there were packaging changes to make it work, wouldn't it just be better to use the new upstream tarball + changelog entry?
<infinity> micahg: Actually, I may have uupdated with the new tarball (minus the hardy abomination) in the past.  Good point.
<infinity> micahg: Easy enough to verify that theory. :P
<infinity> micahg: Hrm.  Well, it's hard to say how I did my last update in 2011, but my diffs sure were readable. :P
 * infinity grabs the sources.
<micahg> infinity: seems that's what pitti did on the last update
<micahg> tarball + changelog
<stokachu> infinity: do you actually mind doing this one so i can see how it is done? that way i can get it right next time
<infinity> micahg: Yeah, looks like it was a straight uupdate.  That said, the end result was no different from what I outlined above, except that the changelog ends up a bit odd, and that debian/copyright is wrong. :P
<infinity> micahg: So, I'd argue that the "backport quantal's version" method is actually more correct.
<micahg> infinity: you have to be careful about that for earlier stable releases in case the packaging changed, but in the case of precise, sure, it works :)
<infinity> micahg: Diffing for packaging changes isn't rocket surgery.
<infinity> micahg: We know hardy breaks and needs special treatment, but that's true no matter how you approach it.
<micahg> infinity: sure, but once you say backport, not everyone will know to do that :)
<infinity> micahg: (Since the orig is a tar.xz, which don't work so smashingly well in hardy)
<infinity> micahg: Even if I don't say backport, people will screw that part up. :P
<infinity> micahg: Until they know why.
<micahg> yes, we got xz source support in lucid, just not xz binary support
<barry> infinity, stokachu maybe update that sru page #tzdata section with more details on the best way to handle the package?
<infinity> barry: Yeah, I'll continue my debate with micahg in my head, and then write up a slightly better bit in the docs.
<stokachu> that would be awesome
<barry> thanks!
<micahg> stokachu: and I've updated that wiki for versioning tips for a new upstream release
<infinity> It sort of goes both ways, of course.  "backport what's in $devel" means that if we change packaging in devel due tp upstream format changes, etc, it'll DTRT.  But it also, as micahg points out, has the chance that new packaging changes might blow up on old releases.
<stokachu> micahg: awesome, im reading that now
<infinity> So, there's a bit of common sense "diff against old release and make sure nothing weird  happened" in there.
<infinity> No matter which route you go, you need to "diff old release with $devel to see what changed in packaging, if anything".
<infinity> Thankfully, tzdata isn't wildly complex, and other than the orig format changing, the packaging hasn't really changed in eons for any meaningful reason.
<stokachu> micahg: so your example shows for new upstream release would be something like 2012d-1ubuntu0.12.04.1?
<infinity> stokachu: I'll update the tzdata bit on the wiki specifically.
<infinity> stokachu: And no, that version would be wrong, as it would be higher than quantal.
<micahg> stokachu: if you're basing it on the Debian package, yes, otherwise -0ubuntu0.12.04.1, but that has the unfortunate side effect of being higher than quantal, so you'd want to do 2012d-1~ubuntu12.04.1 if you're basing it on the quantal package
<stokachu> ah ok
<infinity> Ahh, dangit, we have different debconfiscation in older versions.  Yeah, uupdate is going to be the way to go.
<infinity> But I will update debian/copyright on this update, since it's wrong.
<stokachu> ah uupdate yet another tool i need to be familiar with
 * micahg added a note to the version page about it being for an upstream only update
<goddard> anyone know what the clock is called in the system tray?
<goddard> I wanna check out the code
<infinity> goddard: indicator-datetime
<goddard> ok thanks
<infinity> Hrm.  I wonder if we should update to 2012e while we're at it.
<micahg> if there's something useful in there, why not?
<infinity> Yeah, grabbing it to diff.
<infinity> A formatting change, a lot of updated comments, and one updated zone.
<infinity> May as well.
<barry> @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: micahg
<barry> micahg: the ship is all yours now
<infinity> stokachu: Still around?
<infinity> stokachu: Two things.  Can you tell me if https://wiki.ubuntu.com/StableReleaseUpdates#tzdata seems clear enough to you?
<infinity> stokachu: And, at http://lucifer.0c3.net/~adconrad/tz.tgz you'll find a tarball of what I just uploaded, so you can have a quick look at the final product and compare with the wiki instructions and see if the two seem to mesh and make sense.
<infinity> stokachu: To be fair, like I said, I don't mind owning tzdata anyway, but I always want to make sure that the "I'm on vacation being hit by several busses" instructions are sane, and that you've learned something from it all. :)
<micahg> infinity: for the hardy instructions, shouldn't the first copy be for an .orig.tar.xz?
<micahg> oh, hrm
 * micahg doesn't get why a repack is needed then...
<infinity> micahg: It used to do tarball-in-tarball, then switched to 3.0(quilt)
<infinity> micahg: It's not xz that's the problem, I was miremembering, it's dpkg-source 3.0
<micahg> infinity: why not just switch it to not use tarbal and tarball to skip the repacks?
<micahg> * tarball in tarball
<micahg> that's fine, as long as you're not updating the packaging, that should be irrelevant
<infinity> micahg: Did hardy do 3.0?
<micahg> no
<infinity> Well, then.  That's why...
<micahg> but who cares, it's an .orig.tar.gz
<ScottK> And tarball in tarball is awful.
<infinity> I mean, okay, someone could change the hardy packaging violently to neither match later releases nor previous, but who cares?
<micahg> ScottK: yes, chrisccoulson finally rid the Mozilla stuff of that (don't think it's hit stable yet though)
<micahg> infinity: well, make the change once and make future updates sane?
<micahg> infinity: I guess if we're not doing it every month, it doesn't matter much anymore with 8 months of support left
<infinity> There's nothing sane about it. :P
<BenC> Laney: are you babysitting the dep-waits and ftbfs on powerpc ghc updates?
<slangasek> anyone here seen problems with upgrading the latest libnspr4 SRU on precise?
<micahg> slangasek: worked for me when it hit proposed
<Laney> BenC: I'm not aware of any issues that require specific action beyond the normal transition stuff
<Laney> I've had some arm ftbfs but nothing for ppc yet
<infinity> Laney: What sorts of ARM FTBFS?
<BenC> Laney: ghc has a ton of ftbfs and depwaits for powerpc that aren't the same as i386 and x86_64 (which it should match up not that it has ghci)
<Laney> the compiler segfaults, haven't investigated
 * micahg had an armhf failure actually on something
<BenC> *now
<Laney> BenC: example?
<Laney> something that's already been uploaded?
<BenC> Laney: http://qa.ubuntuwire.org/ftbfs/
<Laney> infinity: try to rebuild e.g. haskell-cmdargs on armhf
<BenC> Scan down the powerpc column for haskell-*
<Laney> not sure that's anything that has been rebuilt for this round
<Laney> in other words I expect those to shake out
<infinity> Laney: And only broken on armhf?  FUN.
<Laney> some el too IIRC
<BenC> Laney: I had powerpc way down near i386 and x86_64, and now it's all a mess again :(
<infinity> BenC: Welcome to haskell.
<Laney> be calm, it's just the way these transitions go
<Laney> if you want to help then grind out some rebuilds: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<Laney> i'm not doing any tonight so you won't collide with me
<ajmitch> Laney: it's not helped by some rebuilds still mysteriously failing
<Laney> infinity: some armel too, same symptoms, see https://launchpadlibrarian.net/112621651/buildlog_ubuntu-quantal-armel.haskell-chell_0.3-1build1_FAILEDTOBUILD.txt.gz
<Laney> still way better than it has been
<ajmitch> I see haskell-cmdargs has been retried yet again, that's one that appear to be segfaulting during build
<infinity> Laney: I tossed one back to see if it's reproducible.
<infinity> ajmitch: That was me.
<ajmitch> aha
<Laney> it is, I built it on my panda (but nothing more)
<ajmitch> when I checked it an hour ago, it failed at the same place as yesterday
<Laney> built â reproduced the failure
<infinity> Bizarre that it would only sometimes hit armel, sometimes armhf, but reproducibly on the same code.
 * Laney sleeps
 * infinity removes ghc and its rdeps from the archive.
<xnox> infinity: why do you hate greek alphabet? =)
<ajmitch> infinity: I'm sure you'd make a few people happy if you did so
<infinity> ajmitch: I'd make myself happy, that's clearly all that matters.
<slangasek> xnox: Î²ÎµÎºÎ±ÏÎ¶ Î·Î¶ Î± ÎµÎ±Î¸ÎµÎ½
<infinity> slangasek: Ow.
<slangasek> apologies for the lack of breath marks, I seem to have misplaced them on my keyboard
<infinity> I'm convinced that lowercase zeta is a pictographic representation of an aneurysm.
<slangasek> á¼Î±Î¸ÎµÎ½
<slangasek> right, there are my breath marks
<slangasek> jcastro: http://askubuntu.com/questions/175722/unmet-dependencies-for-libnspr4/175920 corresponds to the top-reported failure on errors.ubuntu.com today, an issue that's been introduced by an SRU of libnspr4... that we can't reproduce.  is there anything you can do to help us get a useful bug report out of someone?
#ubuntu-devel 2012-08-15
<TheMuso> @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: TheMuso, micahg
<micahg> @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: TheMuso
<micahg> TheMuso: -v please when sponsoring merges, thanks :)
<TheMuso> micahg: oh whoops! Thanks, one tends to foget when working with bzr branches.
<TheMuso> forget
<TheMuso> And since I've been working with other packages, I get on a bit of a muscle memory role and its doubly forgotten.
<TheMuso> @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:
<dholbach> good morning
<diwic> If I'm preparing an SRU (for PulseAudio, a package in main) and want it to go into 12.04.1, what are my deadlines?
<RAOF> diwic: I think the answer might be âa week or so agoâ
<RAOF> diwic: You'll get a more authoritative answer in #ubuntu-release
<diwic> RAOF, ok, I'll just go with a regular SRU then and let it take the time it takes
<RAOF> Do ask in #ubuntu-release; I've been away for a couple of weeks, so might not be up to speed.
<diwic> it's not critical or anything, just figured that if there was a deadline around now, I could just as well adjust to it.
<RAOF> Fair enough.
<diwic> RAOF, looking at the release schedule for 12.04 you're probably right.
<christoffer> Does anyone know the reason for the upcoming UDS to finish on thursday instead of friday?
<diwic> christoffer, money, I would assume
<christoffer> yea probably, just wanted to make sure that it is not a typo.
<diwic> christoffer, i e, less days is cheaper, if we don't need the full week
<UndiFineD> christoffer, there is actually a 5th day planned , as you can see on the schedule of the location
<UndiFineD> but just not for ubuntu
<christoffer> Linaro has another day
<christoffer> UndiFineD, which schedule?
<UndiFineD> http://www.bellacenter.dk/da-DK/visitordk/Kalender/Event-2/Linaro-Connect-Europe-2012.aspx?Action=1&PID=57
<christoffer> UndiFineD, so I suppose you only stay an extra day (the friday) if you're interested in the Linaro discussions.
<xnox> UndiFineD: christoffer: it's linaro demo friday only-ish http://connect.linaro.org/events/event/lce12-copenhagen/#socializing
<christoffer> xnox, aha, thank you
<gotwig> hey there, where can I get help with packaging my app that I ported from python2 to python3 to get it ubuntu 12.10 ready?
<gotwig> got the channel...
<jamespage> doko, have you had a chance to look at openjdk-7 priorities/updates yet?
<jamespage> I'd quite like todo another rebuild test but want to ensure that java 7 always gets used...
<ev> mpt: we have a total. 1,664,679 unique users in the past 90 days.
<ev> *systems
<mpt> \o/
<seb128> ev, is that the total of users who reported an issue?
<mpt> The number of machines that sent an error report.
<seb128> mpt, great
<seb128> ev, mpt: does it mean we have updated stats on the number of issues reported by user as well?
<ev> seb128: not sure what you mean
<mpt> ev, that was the one-off calculation, right?
<ev> mpt, seb128: so using the formula suggested in that email thread, it would be 82118/166479 or 0.49326
<mpt> Next step is to do the calculation every day
<ev> where 82118 is the number of error reports received yesterday (since today isn't finished yet)
<ev> yes, that will be easy
<mpt> 0.49. Well, that's much better than 1.4, at least. :-)
<seb128> ev, so it means users who report issues report 0.49 ones a day?
<ev> seb128: as best we can approximate. Obviously we'd have a much better number if we were getting pings from systems that were not reporting issues.
<seb128> ev, that's not taking into account the 90% drop in report that happened in june though right?
<ev> 90% drop?
<seb128> ev, the curves all dropping to 10% of their value issue I pointed
<seb128> on 17/06/12? need to check the date
<ev> we've fairly consistently received about 80k errors per day. I know the issue you mention, but I don't yet think it's tied to the total number of errors we receive
<seb128> well 10% is an approximate
<seb128> well, what is tied to then?
<seb128> it seemed like we started receiving a lot less issues from one day to the next one
<ev> I'm not sure yet
<ev> not all the graphs have that form, mind
<seb128> that's still pretty disturbing to me, I'm not sure what to think about it
<seb128> not all, but from what I saw most do
<ev> sure - I'd like to get to the bottom of it
<ev> but there's no use speculating until we have sufficient data
<seb128> ev, right, at the same time I'm not sure the 0.49 number is to be trusted either
<dobey> what do the colors mean?
<seb128> dobey, what colors?
<ev> seb128: oh? why?
<dobey> seb128: the colors for the packages/vesrions/bugs on errors.u.c
<seb128> ev, because we don't know how much we miss by the "stop after 3 reports" and we don't know what that drop in numbers that happened at some point of time mean as well
<seb128> dobey, greyed lines are issues with a fix uploaded
<ev> dobey: red is a work in progress, but it's meant to indicate a possible regression
<seb128> dobey, red colored "last seen" are potential regressions or unfixed issues
<seb128> dobey, blue numbers are bugs you visited I think
<Laney> how do you get the graph to show you a different timeframe?
<Laney> to see this dip
<seb128> Laney, click on any report
<seb128> on the signature column
<dobey> hmm
<Laney> bah, it's painful to "back" through openid auth
<ev> Laney: I'm fixing that today
<seb128> yeah, middle click :p
<seb128> Laney, the jockey one in second is a typical example
<ev> Laney: most-way done through a branch that uses django-openid-auth instead of the apache module, so it will cache logins
<seb128> curve goes steadly increasing until 05/17/12 (increasing number of people installing the LTS)
<dobey> weird
<seb128> then it drops and flats
<seb128> there are lot of bugs with a similar graph
<Laney> well, could it be that clients only report the same problem once?
<Laney> so everyone got the bug, reported it and then didn't again
<seb128> Laney, well it means our rate of new users is stangely flat or linear then
<Laney> it could be skewed by the graph's y axis being so large
<Laney> anyway, that's just rank speculation that i should probably refrain from making :P
<dobey> it seems to also conflate the precise/quantal reports :(
<seb128> dobey, you can select the distro serie at the top of the page
<seb128> there is a combo
<seb128> dobey, or you mean individual reports?
<seb128> dobey, the individual reports have by version stats
<dobey> seb128: i mean, there are reports that only show up under 12.04 there, but the 'last seen' version is from quantal not precise
<seb128> dobey, click on the report, you have a table of instances by version
<dobey> seb128: well nice. it doesn't even list the 'last seen' version there :)
<seb128> Laney, well anyway the "stop reporting after n instance" would explain it was going up in a regular pace for a while then dropped and dropped on the same day for all the reports showing that shape
<seb128> dobey, well it lists all the versions in a table, the last seen is the most right
<dobey> seb128: yes but on the main page the version is 'last seen' column isn't list on the specific page at all
<seb128> dobey, well, you have the same info on the specific page, just in a expended version in a table
<dobey> seb128: so presumably there is a bug somewhere that's causing it to show quantal version on precise, perhaps due to someone running it during an upgrade or something?
<seb128> Laney, would->wouldn't
<dobey> seb128: https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction does not show "3.0.2-0ubuntu1" which is the "last seen" version on the main page
<seb128> dobey, I don't think 'Last seen' is a by serie info
<seb128> hum
<seb128> ev, ^ any idea about that? known bug?
<seb128> ev, if "3.0.2-0ubuntu1" is the last seen version should it be in the table with a count?
<dobey> in fact, of the 3 ubuntuone-installer reports there which list 3.0.2-0ubuntu1 as the last seen; only one of the specific report links shows it in the versions table
<ev> seb128, dobey: the code to create the tables landed after the Last seen stuff did. It's entirely possible that you've had a small number of users reporting with 3.0.2-0ubuntu1 when the error occurred on a previous version (this is fixed in apport, but I have to look into whether those reports are still getting sent to daisy.ubuntu.com).
<ev> for now just look for large numbers
<seb128> ok
<dobey> ok
 * dobey wonders if it's possible to get those fixes into 12.04 now; they still haven't been accepted into -proposed yet :(
<seb128> ev, btw still can't select a month view (sorry for being naggy about that)
<seb128> dobey, what fixes?
<ev> seb128: yeah, my initial suspicion turned out to be wrong on that one and I just haven't had time to dig into it further yet
<ev> I am aware of it though and will make it a priority
<seb128> ev, ok
<seb128> thanks
<dobey> seb128: the ubuntuone-installer and ubuntu-sso-client i uploaded to -proposed last week
<dobey> which should fix all those issues for them on errors.ubuntu.com
<seb128> dobey, didn't they ask you to reupload the ubuntuone-installer only with the selected fix?
<ev> (I had thought the timeouts were occurring from us taking extra time to talk to launchpad, as that change landed at basically the same time. But our addition of a cache hasn't fixed it, so the problem may lie somewhere else.)
<dobey> seb128: no; and i don't think u1 design will be happy about not having those fixes in as well
<seb128> dobey, re-reading the log from thurday on #ubuntu-release you wrote
<seb128> <dobey>        slangasek: understandable. and pretty much 100% of the other fixes are all non functional fixes anyway
<seb128> dobey, I though it meant you agree to reupload ubuntuone-installer only with the fix for bug 853060
<ubottu> Launchpad bug 853060 in ubuntuone-installer (Ubuntu Precise) "ubuntuone-installer crashed with GError in function(): Failed to execute child process "ubuntuone-control-panel-gtk" (No such file or directory)" [High,Triaged] https://launchpad.net/bugs/853060
<seb128> dobey, we are 2 weeks past .1 freeze, I'm not even sure they will accept that before .1 at this point though ... maybe we should just wait and get the updates in the queue in after .1
<dobey> seb128: i didn't read slangasek's comment as meaning to re-upload; but that he was simply expecting it to only fix the one issue (except that it wouldn't, as there at least 3 fixes in there to get rid of the errors.u.c reports)
<dobey> and i am not sure if they will apply cleanly without the other changes :-/
<dobey> seb128: but the sso upload is a single patch; so i wonder why it wasn't accepted into -proposed yet either? :(
<seb128> dobey, well, there was
<seb128> <stgraber>     dobey: as you know we're a week past the 12.04.1
<seb128>  upload deadline and your upload includes quite a bit more than just the fix we
<seb128> want for 12.04.1
<seb128> dobey, but I guess talk to stgraber about those
<dobey> well i guess it's too late now anyway :(
<seb128> dobey, because the upload freeze was august 3rd and you uploaded on august 10th
<seb128> dobey, so nothing uploaded after the 3 was considered if nobody asked to really get the upload in
<dobey> well, aug 4-8 i was on holiday, and iirc the comments asking for those uploads was after the freeze date as well
<dobey> and i've been swamped with quantal stuff too; and i wasn't really aware of the aug 3 date until this week basically :-/
<seb128> dobey, no blame, don't worry, if we get those in updates just before .1 that's fine too
<seb128> dobey, we are aiming at fixing the most common issues
<seb128> the fixes will not made it all on the .1 iso but we will have updates and a .2
<dobey> right. and the sso issue is #2 on the errors.u.c list right now
<dobey> should i poke skaet to get it in at least?
<Laney> I imagine processing will resume as usual after the final freeze tomorrow
<seb128> dobey, it would be good
<seb128> stgraber, ^
<stgraber> dobey: I'll look at the SSO one
<dobey> stgraber: thanks
<sveinse> I'm having problems compiling protobuf_2.4.1-1ubntu2 on amd64 from precise. It fails with "Makefile.am:84: Libtool library used but `LIBTOOL' is undefined", yet all build deps are installed. What could this be?
<slangasek> seb128, dobey: I wasn't asking for a reupload, I was in fact intending to review and accept... I just ran out of time on the review part, I'm afraid
<rmk_> can anyone help with getting the core rootfs image going on an ARM target?
<rmk_> I tried following the instructions at: https://wiki.ubuntu.com/Core and all I get is "init: Failed to create pty - disabling logging for job" and "init: Temporary process spawn error: No such file or directory"
<rmk_> as I'm using serial on ttyS0, I've tried adding a getty entry into etc/init/ttyS0.conf, but I never get that either
<rmk_> and var/log doesn't seem to contain anything useful
<xnox> rmk_:  join #ubuntu-arm experts channel =)
<xnox> failed to create pty is a known upstart bug
<rmk_> yep, found those bugs, seems to be treated as a low priority problem
<xnox> rmk_: not really low... there two engineers working on it. and there were 3 merges done for it.... but the bug would just not die....
<xnox> it's a nasty bug =(
<rmk_> how often does the core rootfs tarball get updated?
<smartboyhw> Excuse me, what version of AbiWord will be used for 12.04.1? We are talking about this in QA
<ogra_> rmk_, depends which one you use :)
<ogra_> there are plenty on cdimage.ubuntu.com ... where exactly did you download it from (url)
<rmk_> well, looking at the date on it... it doesn't get updated
<rmk_> as I said, I followed the isntructions at https://wiki.ubuntu.com/Core, which points me to http://cdimage.ubuntu.com/ubuntu-core/releases/12.04/release/
<rmk_> and that stuff is dated 23 April
<ogra_> right, that doesnt get updated
<smartboyhw> !Abiword
<ogra_> rmk_, there are daily images produced for the current development release though
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily/current has the latest
<smartboyhw> ogra_: Please help with my question a dozen lines above
<rmk_> ogra: looks like armel has been dropped
<ogra_> smartboyhw, check launchpad ;)
<ogra_> rmk_, yes
<smartboyhw> Uh
<ogra_> rmk_, in precise armel is gone (even though we still produce packages, there are no images produced for it)
<ogra_> err
<ogra_> s/precise/quantal/
<smartboyhw> ogra_: What?
<jodh> rmk_: the pty issue is fixed in quantal and scheduled for inclusion in 12.04.2.
 * ogra_ isnt sure if it was planned to rebuild -core for .1 or .2
<stgraber> I don't believe it's LTS so probably not
 * stgraber checks the manifest
<stgraber> oh, it's, for: amd64 i386 armhf
<stgraber> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
<ogra_> rmk_, in any case it shouldnt block you apart from spamming the console
<rmk_> ogra_: well, I've yet to get any kind of login on it
<ogra_> it should show a login prompt on the monitor
<ogra_> indeed you need to add a user or set a rootpw to be able to log in
<jodh> rmk_: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/702574/comments/7
<ubottu> Launchpad bug 702574 in upstart (Ubuntu) "getty should be started automatically on serial port when serial console is set on kernel command line" [Wishlist,In progress]
<rmk_> yea, well, I've created a /etc/init/ttyS0.conf to tell upstart to start a getty on there, but I get nothing
<ogra_> did you use the right device name for your hardware ?
<rmk_> and if I take the SD card out and mount it on a PC, then look in var/log, there's nothing in there either to suggest what it did
<rmk_> oh yes, it's definitely ttyS0
<ogra_> i.e. on omap its ttyO2
<rmk_> works in lucid
<jodh> rmk_: maybe there is an issue with your job? Try the version on the link above whilst booting with 'console=ttyS0' or similar.
<ogra_> rmk_, lucid used a different kernel
<rmk_> I'm using the same kernel (my own, 3.5.0-rc5+)
<rmk_> my etc/init.d/ttyS0.conf is:
<ogra_> well, as long as you are sure its the right devuce
<rmk_> start on stopped rc RUNNLEVEL=[12345]
<rmk_> stop on runlevel [!12345]
<rmk_> respawn
<rmk_> exec /sbin/getty -8 115200 ttyS0
<jodh> rmk_: typo - RUNNLEVEL
<ogra_> heh, yeah
<rmk_> that'll teach me to blindly copy instructions of a site
<jodh> rmk_: I'd appreciate it if you'd try the version on the link above as I'd like to be assured it works in all scenarios.
<rmk_> jodh: good catch, fixing that gives me a login at last :)
<rmk_> I'll try that script in a moment
<jodh> rmk_: thansk - much appreciated.
<jodh> rmk_: thanks even ;)
<rmk_> typo :)
<jodh> rmk_: touche ;)
<rmk_> anyone know where I can find the specs for what CPUs the armhf port supports?
<ogra_> rmk_, all ARMv7 and above
<rmk_> yes, but there's different VFP versions
<rmk_> I tripped over this in lucid's qt4 library package
<ogra_> we use vfpv3-d16 iirc
<rmk_> ok, that's fine then.
<rmk_> so, it sounds like I should switch to armhf rather than armel?
<ogra_> its unlikely that armel will be there after quantal was released, so yeah, that might be a clever move ;)
<rmk_> I think I'll put the armhf into a chroot, then update it first before trying to boot it
<rmk_> along with your tty-serial.conf script
<ogra_> what kind of HW do you have over there ?
<rmk_> it's one of these solid-run.com cubox things
<ogra_> ah, cubox should work just fine
<ogra_> we had some users around in #ubuntu-arm during precise development
<rmk_> well, I've been working on DRM support for this thing, mainly so that TVs can be properly hotplugged etc
<ogra_> sweet !
<rmk_> I have it working under lucid :)
<rmk_> or rather, the lucid which was supplied with the cubox
<seb128> cjwatson, ev, stgraber: do you know if https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1037001 is a known issue?
<ubottu> Launchpad bug 1037001 in ubiquity (Ubuntu) "[l10n][zh_CN] Indicator menus should be fully localized for installer" [High,New]
<seb128> seems like the ubiquity panel process (in ubiquity only mode) is not running under the right locale
<seb128> the translations are there and used in live session mode
<stgraber> seb128: I don't think it's a known issue but I can certainly see what's going on
<stgraber> seb128: the problem is that the installer always starts in the default locale (english)
<stgraber> then it changes to whatever the language is in the preseed or chosen in the dialog
<seb128> I guess it's too late to fix for .1 now?
<stgraber> ubiquity itself updates to use the right language, but the rest of the environment can't be updated
<stgraber> I think so, because I have no idea how to solve it
<seb128> stgraber, can you comment on the bug and maybe milestone for .2?
<rmk_> jodh: looks like the script didn't work - I tried increasing the runlevels to include 45 as well, still didn't work
<jodh> rmk_: could you possibly add a comment to bug 702574 with details of what you specified on the kernel command-line?
<ubottu> Launchpad bug 702574 in upstart (Ubuntu) "getty should be started automatically on serial port when serial console is set on kernel command line" [Wishlist,In progress] https://launchpad.net/bugs/702574
<ogra_>         PORT=${1#/dev/}
<ogra_>         DEVICE="/dev/$PORT"
<ogra_> jodh, that looks wrong
<ogra_> you dont need /dev/tty*** on the cmdline (though it wont do any harm if you set it)
<ogra_> i guess most people will just use console=ttyXYZ,115200n8 or some such
<rmk_> yes, that's the normal form of the console= argument to the kernel
<ogra_> well, iirc /dev/ttyXYZ would work too
<jodh> ogra_: I know you don't need it, but the current script requires you to specify that you want to enable an extra getty. We could have it auto-spawn based on udev of course.
<rmk_> ogra_: I don't think the kernel strips the /dev/ off before matching against the kernel console drivers
<ogra_> jodh, just dont match against /dev
<rmk_> so giving it console=/dev/ttyS0,115200n8 would probably result in no kernel messages on ttyS0
<ogra_> rmk_, oh, did you remove /etc/init/ttyS0.conf before testing the script ?
<rmk_> yes, it was tested on a brand new armhf rootfs
<stokachu> any patch pilots today?
<stokachu> bdmurray: is that you today?
<bdmurray> stokachu: yes, but I will probably postpone until tomorrow.  trying to sort out an issue with apport and errors
<stokachu> ok
<stokachu> ill see if another pilot is available
<bdmurray> stokachu: bryceh usually pilots around me too
<stokachu> i see adam gandelman and luke yelavich
<stokachu> looking up their nicks now
<stokachu> TheMuso, adam_g: any of you available for patch review today?
<rmk_> ogra_: just installing some other bits to make this rootfs a little more functional and then I'll debug that script
<ogra_> thx !
<rmk_> I'm still seeing:
<rmk_> init: Failed to create pty - disabling logging for job
<rmk_> when stuff is being started tho
<rmk_> and devpts is mounted
<jodh> rmk_: is this with precise?
<rmk_> yes, no initrd tho
<jodh> rmk_: the fix isn't available for precise yet. You can boot with '--no-log' to disable job logging (and make those messages go away) if you wish.
 * rmk_ gets vim installed so he doesn't have to use sed :)
<zul> mterry: ping
<mterry> zul, hi
<zul> mterry:  i dont think the python-django-appconf testsuite dont actually wory
<zul> work even
<mterry> I got an error about an env var
<mterry> zul, you think it's just a busted suite?
<zul> mterry: i think so
<mterry> zul, OK
<mterry> zul, then don't worry about it I guess
<zul> mterry: ok...i just uploaded a version to address all the issues that you raised other than the testsuite
<mterry> zul, cool, just marked the bug fix committed then
<zul> mterry: thanks
<rmk_> jodh: found the bug
<rmk_> you need:
<rmk_>       console=*)
<rmk_>         old_IFS="$IFS"
<rmk_>         IFS=','
<rmk_> ...
<rmk_>         FLOW="$4"
<rmk_>  
<rmk_>         IFS="$old_IFS"
<rmk_> so that IFS gets reset back to something sane before trying to call getty, otherwise the shell won't split the arguments
<rmk_> (it'll try to split them around , and not white space)
<stokachu> is anyone available to review http://pad.lv/932860
<ubottu> Launchpad bug 932860 in appmenu-gtk (Ubuntu Precise) "Broken (or missing) multiarch support" [High,Triaged]
<jcastro> slangasek: sorry I was afk, did you get the feedback from that question you wanted? it appears so
<stokachu> also could someone approve http://pad.lv/1013211 for precise series
<ubottu> Launchpad bug 1013211 in libgnomecanvas (Ubuntu) "Please transition libgnomecanvas to multi-arch" [Undecided,Confirmed]
<slangasek> jcastro: yeah, we've got an actual bug report with debug logs, thanks :)
<jcastro> nice to see the errors.u.c stuff come in so handy
<jcastro> slangasek: so like when things like that happen do bells and whistles go off somewhere?
<slangasek> jcastro: we don't yet have it wired to bells and whistles, it's still a manual poll of the errors.u.c frontpage
<slangasek> bells and whistles are round two :)
<jcastro> ah, I was so hoping like an alarm woke up infinity.
<slangasek> alarms don't wake infinity
<jocarter> I wish I could sleep like infinity :(
<infinity> jocarter: Alarms don't wake me because I'm generally never asleep; you don't want that.
<TJ-> whois TJ-
<stokachu> thats you!
<astraljava> Well, that's silly.
<jocarter> infinity: ah, indeed.
<slangasek> stokachu: libgnomecanvas> approved
<stokachu> slangasek: thanks
<stokachu> doing rdeps testing on it now
<stokachu> anyone available to do some multi-arch reviews?
<stokachu> ive got http://pad.lv/932860 and http://pad.lv/1013211 that needs some attention so i can SRU for precise
<ubottu> Launchpad bug 932860 in appmenu-gtk (Ubuntu Precise) "Broken (or missing) multiarch support" [High,Triaged]
<ubottu> Launchpad bug 1013211 in libgnomecanvas (Ubuntu Precise) "Please transition libgnomecanvas to multi-arch" [Medium,In progress]
#ubuntu-devel 2012-08-16
<dylan-m> Hey, does anyone know what became of patching libsoup to have a default SSL CA file?
<dylan-m> Looks like MVO sent a patch upstream from this bug: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/874242
<ubottu> Launchpad bug 874242 in software-center (Ubuntu) "Re: "Single sign on page doesn't look secure" --> well it isn't :>" [Critical,Fix released]
<dylan-m> And it was wontfixed, but reading the comment (though I could be misunderstanding)  it sounds like libsoup already has a similar compile flag
<dholbach> good morning
<dylan-m> Good morning!
<dylan-m> :o I'd better go to sleep
<lenios_> hey, just asking: i've reported a bug, someone wrote a patch and now it's pending for review. Who is responsible for review? package maintainer, reviewer team, me?
<geser> lenios_: do you have the bug number?
<jdrab> hi guys, is there something like ubuntu HIG or some sort of guidelines for developing applications in ubuntu/unity?
<Riddell> jcastro: uds sponsorship broken? http://summit.ubuntu.com/uds-r/sponsorship/
<Peace-> how sweet is this ? avconv doens't work to grab screen
<Peace-> and even the fake version of ffmpeg
<Peace-> 12.10 of course
<doko> apw: is CONFIG_X86_X32=y set for our kernel builds on amd64?
<apw> doko, nope not set anywhere currently
<apw> doko, something you need there ?
<apw>           You will need a recent binutils (2.22 or later) with
<apw>           elf32_x86_64 support enabled to compile a kernel with this
<apw>           option set.
<doko> apw: can you set it, afaik it should be possible to set it. well, it's not "needed", however to experiment with x32, it would be nice to have it set, if doesn't influence the amd64 build
<apw> doko, is our binutils new enough do you know ?
<doko> apw: it's 2.23 for quantal
<apw> doko, i don't see any issue having it set in quantal before release, security may whine if its on for release
<apw> doko, i'll go see if it turns on easy
<doko> let them whine =)
<infinity> apw: The master plan for this release was to flip it on for the kernel and get the toolchain bits vaguely ready enough for people to play with it.
<seb128> apw, hey, do you still plan to upload kmod? pitti said you were about to upload it before he left for holidays
<infinity> apw: That said, there are still commits every day to glibc upstream for x32, so it's clearly not "done" yet. :P
<cjwatson> seb128: robert_ancell did updated versions of libburn and libisofs recently; I don't suppose you know if he's planning to do a new libisoburn as well to go with them?
<cjwatson> if not, I might, as part of killing the amd64+mac images
<seb128> cjwatson, I doubt he is
<seb128> cjwatson, he's usually trying to tackle red lines on http://people.canonical.com/~platform/desktop/versions.html
<lenios_> geser, took a long time but #1025652
<lenios_> that's funny there's a new version of unity-greeter today, but the bug is still present
<geser> lenios_: in this case the patch is waiting on review by upstream (Unity Greeter devs), you don't need to do anything
<lenios_> ok thanks
<lenios_> i hope it will be fixed by the beta
<xnox> bug 1025652
<ubottu> Launchpad bug 1025652 in unity-greeter (Ubuntu) "greeter-show-manual-login is not correctly handled by lightdm" [Undecided,Confirmed] https://launchpad.net/bugs/1025652
<tjaalton> should dpkg in precise support handling xz tarballs?
<debfx> tjaalton: yes
<tjaalton> dpkg-buildpackage insists on creating a tar.gz even when there is a .xz available..
<tjaalton> ie. makes a native package
<Laney> you mean orig.tar.xz?
<tjaalton> yes
<Laney> is it correctly set to 3.0 (quilt)?
<tjaalton> 1.0 doesn't support it?
<siretart> tjaalton: no, you need 3.0 for xz AFAIR
<Laney> indeed
<tjaalton> oh gah..
<tjaalton> very well then
<siretart> yes, that's even documented in dpkg-source(1)
<tjaalton> ok
<tjaalton> 3.0 hates git
<Laney> what?
<tjaalton> trying to avoid it where possible
<tjaalton> and in this case looks like I need to do tricks in order to build from git
<tjaalton> dpkg-source: error: cannot represent change to wayland/spec/wayland-architecture.png: binary file contents changed
<tjaalton> etc..
<tjaalton> hmm something else going on, looks really weird
<siretart> tjaalton: seems that your tree content does not match the contents of the orig.tar.gz. check the version numbers in debian/changelog with the filename you try to use
<siretart> tjaalton: as a workaround, you can use 'dpkg-buildpackage -b' to avoid building a source package.
<tjaalton> siretart: I know where it came from. for some reason upstream git has files the tarballs don't, so in this case had to just remove them and live with it
<tjaalton> no ChangeLog then :)
<siretart> tjaalton: oh, yeah, I also have some upstreams that generate the tarballs with some scripts that causes the contents to be different to what is in git
<siretart> tjaalton: there are two approaches: import the upstream tarballs or screw them :-)
<siretart> (i mean the tarballs)
<tjaalton> yes, and pkg-xorg has the habit of doing 'git log <tag> > ChangeLog' every time a new version is merged, so the diff would normally have that
<siretart> that shouldn't cause issues with some random .png files, though...
<tjaalton> they're not in the tarballs -> nagging
<siretart> afaiui, missing files are not a problem at all, they just cause warning "file is missing". only files with different contents are problematic
<tjaalton> it ignores files that are deleted, ie. missing from the git branch (like autotool files)
<tjaalton> the other way around means problems
<cjwatson> tjaalton: there's always debian/source/include-binaries
<tjaalton> cjwatson: hmm, thanks
<mpt> "It's not just you! http://status.ubuntu.com looks down from here." http://www.downforeveryoneorjustme.com/status.ubuntu.com
<toggles> Is there a way to get a ppa to automatically build for the next version? Or do I need to change the changelog and submit it again?
<geser> if no rebuild is needed, then you can copy it forward otherwise (needs a rebuild) you need to reupload
<toggles> geser: thanks, what do you mean "copy it forward"?
<ev> mpt_:  whenever you have time for it, I think we'll need a small design for incorporating "problems my team is responsible for" on the most common problems table
<ev> vs "all problems"
<ev> the data coming from here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AhTVBLlLWapNdHRpM2QyRGQ5NGFzZmF3ODNpZ2E3d1E&authkey=CJzt1xo&authkey=CJzt1xo#gid=0
<geser> toggles: Launchpad has the feature to copy (source and binary packages) from one series to an other
<mpt_> ev, that's already on my list for <https://blueprints.launchpad.net/ubuntu/+spec/other-q-defects-dashboard>
<ev> oh, of course
<ev> excellent
<toggles> geser: thanks, I'll see if I can figure it out, much appreciated
<didrocks> ev: thanks for the openid change, I'm crossing my fingers :)
<ev> didrocks: sure thing
<ev> apologies it took so long - the correct solution required us pulling in postgres, which I wasn't particularly keen on. I had hoped we could find a decent way of bolting the django auth model to cassandra, but that looks quite difficult
<ev> and using a separate database just for login and session caching isn't really that bad an idea
<bdmurray> infinity: what were you saying about bug 1036794 yesterday regarding it being reported about update-manager and not the package?
<ubottu> Launchpad bug 1036794 in nspr (Ubuntu Precise) "unmet dependencies during update of nspr4: libnspr4 : Breaks: evolution-plugins (< 3.2.0-0ubuntu2) but 2.32.2-0ubuntu7 is to be installed" [High,Fix committed] https://launchpad.net/bugs/1036794
<ev> mpt_: I can't recall what the outcome was, but if you have thoughts on how we can do a better present the information in the most common errors table than by the current confusing colour system, do let me know.
<mpt_> ev, I think step 1 is to list the variables you're trying to present. Apparently regressed vs. fixed vs. never fixed, reported in latest version vs. not, what else?
<ev> mpt_: there's the 'last seen' version is not the most recent -> greyed out last seen, the linked bug is marked as complete -> greyed out line, the last seen version is the most recent version and the linked bug is marked as complete -> red last seen.
<ev> and of course, links you've clicked on are blue
<seb128> ev, I find it weird that errors.ubuntu.com has no error ever on gconf2 about gsettings-data-convert where we regularly have bugs in convert scripts and quite some reports on launchpad about those
<mpt_> ev, What does "complete" include?
<seb128> ev, do you know how we could figure out why that's so?
<ev> mpt_: whatever launchpad considers a complete bug. I believe that's Invalid, Wont Fix, and Fix Released
<ev> seb128: looking
<xnox> ev: Opinion?!
<ev> that too
<xnox> cjwatson: do you have the link to task for opening archive... again... me and micahg can't find it again =)
<xnox> found it
<xnox> micahg: https://wiki.ubuntu.com/NewReleaseCycleProcess
<micahg> xnox: thanks, bookmarked
<xnox> probably needs a new sections of "Things to do for Radiant Raccoon"
<Laney> you expect something special?
<xnox> Laney: yes we do =)
<Laney> sinister...
<cjwatson> xnox: Is this just misc changes we need to remember to make to various packages?
<xnox> cjwatson: aha
<shadeslayer> cjwatson: I wanted to add a custom task for my derivative, can I just edit /usr/share/tasksel/ubuntu-tasks.desc and go with that? or should I modify the tasksel package?
<shadeslayer> ( I've tried the former and it doesn't seem to work, probably I'm doing something wrong )
<cjwatson> shadeslayer: If you can modify tasksel in your derivative, you should
<shadeslayer> awesome
 * shadeslayer modifies tasksel
<cjwatson> shadeslayer: But you also need to arrange to have appropriate Task fields in your archive's Packages files
<shadeslayer> ah
<cjwatson> The usual arrangement is to use "extra overrides" in apt-ftparchive
<cjwatson> But it will depend a bit on your archive software
<shadeslayer> hmm .. I'm using reprepro
<shadeslayer> cjwatson: the files in indicies are exported by tasksel right?
<mterry> barry, hello!  I'm looking at pycurl right now and note it doesn't have a python3 port.  There are patches floating around, any objection to me applying one?
<infinity> bdmurray: I was saying that it would be nice if apport/errors didn't get it wrong. :P
<mterry> Er, not just one of them, but the one pointed at by the python3 spreadsheet
<bdmurray> infinity: right, and how I can help make it right?
<cjwatson> shadeslayer: no, they're generated by the archive machinery
<shadeslayer> hmm
<cjwatson> I'm afraid they're your problem to deal with - I can only support the Ubuntu archive here :)
<shadeslayer> then something is wrong with the way I've setup reprepro
<shadeslayer> cjwatson: yeah, I understand :)
<cjwatson> indices/ output isn't mandatory
<cjwatson> it's basically informational and to help people do matching apt-ftparchive runs and the like
<cjwatson> the important bits are the Task: fields in Packages
<shadeslayer> ah ok
<infinity> bdmurray: I dunno, do something programmy to it? ;)
<TJ-> When I "bzr push lp:~tj/gnome-control-center/fix-123456" to my LP, should it be sending the entire local repo or just the diff (originally got using bzr branch lp:ubuntu/precise-updates/gnome-control-center) ?
<infinity> bdmurray: The error in question, I think, was "clearly" an issue with either libnspr4 (or one of its dependencies) and, while it's not foolproof to do so, still seems like a regex to try to sort out to blame the package that can't be installed makes more sense than blaming the package manager.
<cjwatson> TJ-: Branches pushed to LP are generally "stacked", which saves pushing the whole thing.  However, what they're stacked on depends on where you push it.  In this case you're pushing it to an upstream-type location which will mean it'll stack on lp:gnome-control-center, whatever that may be, and very likely not having anything in common with your branch.
<cjwatson> TJ-: You should probably push to lp:~tj/ubuntu/precise-updates/gnome-control-center/fix-123456 instead.
<TJ-> cjwatson: Yeah, I tried "precise-updates" and got "Denied" which is why I asked. However, mgz in #bzr has sorted me out so I'm now just pushing the delta between 'precise' and my fix
<TJ-> cjwatson: My 'git' head still has trouble grok-ing bzr and launchpad integration. Thanks for the heads-up.
<killown> THANKS AGAIN by messing with ubuntu, now it's opengl things wine game screens doesn't work after the last update that bring mesa, compiz and opengl things, "THANKS AGAIN"
<killown> sudo apt-get upgrade it far more dangerous than rm -rf /
<mdeslaur> killown: how about filing a bug instead of coming here to rant?
<killown> every upgrade more bizarre bugs comes
<killown> I am tired from filling bugs, what about don't touch on what already is working?
<seb128> killown, what about you just stay on a stable version where thing don't change so often?
<killown> am I not on a stable distro?
<killown> 12.04
<killown> NO PPA's
<seb128> nothing brigs compiz and opengl in 12.04
<cjwatson> seb128: compiz had a new version in precise-updates 21 hours ago, according to LP
<seb128> cjwatson, it doesn't has any new requirement
<seb128> cjwatson, that new compiz doesn't bring any opengl over what the previous one did
<seb128> but maybe I misread the statement
<killown> brings a new bug
<seb128> what mdeslaur said then
<seb128> open a bug
<shadeslayer> cjwatson: ok, I'm trying to understand what ubuntu-seeds.pl does, but I'm a bit confused, it branches the seeds, and then ... what does it do?
<killown> while that I can't play my steam games, it's cool
<cjwatson> shadeslayer: I would be very surprised if it did anything that's appropriate for you ...
<shadeslayer> yeah .. I think using tasksel would be overkill
<seb128> killown, log into unity2d to play
<cjwatson> shadeslayer: no, that wasn't my point
<seb128> killown, or downgrade whatever you upgraded
<cjwatson> shadeslayer: ubuntu-seeds.pl generates the files in ubuntu-tasks/ based on the Ubuntu seeds
<shadeslayer> oh ok
<cjwatson> shadeslayer: but there's no reason you can't just edit those files directly as long as your changes aren't directed at the Ubuntu archive
<shadeslayer> right
<cjwatson> it's just to help us maintain them
<killown> seb128, even on kde disabling the effects doesn't fix this
<shadeslayer> makes sense, I'll skip using ubuntu-seeds.pl then
<seb128> killown, so it's not compiz
<seb128> KDE doesn't use compiz
<killown> seb128, its not
<killown> the upgrade list comes with alot opengl things and mesa
<killown> compiz is one of those
<seb128> well, try to downgrade until you figure which one created your issue?
<stgraber> mesa was indeed updated but unless you're using an i3 ivy bridge CPU, you won't get any difference
<stgraber> the only diff in mesa was reducing the number of threds on i3 ivy bridge GPUs to fix pretty bad screen corruptions
<shadeslayer> cjwatson: the other question I had was, I don't see anything remotely related to the Task field in the debian policy manual
<cjwatson> shadeslayer: I wouldn't expect you to
<shadeslayer> oh ...
<cjwatson> shadeslayer: the Packages format is extensible ...
<cjwatson> shadeslayer: it's not required for every field there to be specified in policy
<cjwatson> shadeslayer: only the ones that generally need to be assigned values by individual packages, which this doesn't
<cjwatson> even then, only the ones that need widespread cooperation
<cjwatson> the policy manual is basically there to document the things required of individual packages for interoperability, rather than a detailed guide to the entire system
<shadeslayer> alright ...
<shadeslayer> cjwatson: thanks for all the help so far, I hope I wasn't too annoying ;)
<cjwatson> that's ok
<killown> take a look http://i.imgur.com/aOzF5.jpg
<bryceh> @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: bryceh
<barry> mterry: go for it!  and thanks.
<mterry> barry, awesome
<killown> any developer needs downgrade the last packages updates, I tested with wine1.4, wine1.5 AND it's what I get http://i.imgur.com/aOzF5.jpg?  how I can filling a bug for that? this screen is all what I get, wine output doesn't tell where this opengl error is from
<killown> http://paste.ubuntu.com/1151115/
<cjwatson> there's no reason you can't file a bug with what you have so far - any change to a stable release would require a bug report anyway for tracking
<cjwatson> people aren't saying "file a bug" to get rid of you, but because that's how we track problems
<lborda> cjwatson, hi
<cjwatson> lborda: hello.  your previous comments in my direction were lost in the IRC client I closed down a while ago when shuffling network connections
<lborda> cjwatson, no problem... tks anyway... I am having some weird problems when preseeding 12.04 and using ONLY a local mirror... no internet access
<killown> cjwatson, but how can one distro be called stable with this kind of bug? this impede me from use wine, and more now  that valve is coming for linux this kind of thing can't happen with linux, this is a shame
<cjwatson> killown: I'm not going to engage with rants, I'm afraid - too much work to do
<cjwatson> lborda: ok, can you show me logs and the preseed file in question?
<lborda> cjwatson, yes here is the preseed: https://pastebin.canonical.com/72357/
 * rmk_ finds a bug in precise's vlc xv backend
<rmk_> it appears that it remembers the wrong fourcc code to pass back into PutImage
<rmk_> and with the additional check that xorg >= 1.9.99 does, it gets a BadMatch error back
<lborda> cjwatson, it follows the logs too: https://pastebin.canonical.com/72359/
<lborda> cjwatson, it looks like debian-installer is not able to fetch from the local mirror. there is no internet access on the environment...
<lborda> cjwatson, i am using 12.04.1 latest netboot files
<killown> ok, so now I fill a bug with that wait for a week without can use wine and last upgrade some new bugs that impede me from use other programs? ok enough, I am going to look for another distro, thanks you all.
<cjwatson> lborda: did you remember to include the debian-installer Packages files?
<cjwatson> lborda: in the local mirror, I mean
<cjwatson> lborda: i.e. dists/precise/main/debian-installer/binary-amd64/
<TJ-> Anyone familiar with gnome-control-center source? I have an FTBS issue that is confusing me
<lborda> cjwatson, haaaaaaaaaaaaa.... no i didn't...
<cjwatson> lborda: it's not ideal that the missing URLs aren't displayed in the logs; that's worth a bug report
<lborda> cjwatson, yeah ... i noticed that too...
<shadeslayer> cjwatson: weird, even after modifying tasksel ( added a custom task to ubuntu-tasks ), live build doesn't seem to pick it up
<lborda> cjwatson, , I will open up a bug on this one
<cjwatson> I think you're confused about what tasksel's for :)
<cjwatson> anyway, I'd need more detail on how it's not picking it up
<cjwatson> tasksel needs to be updated because otherwise tasksel won't show the right tasks.  but it has roughly nothing to do with live-build.
<shadeslayer> uh .... ok .... so something is wrong with my meta package then? ( it doesn't have a Task entry in the control file atm )
<cjwatson> typically live-build gets its notion of tasks from the Packages files.
<cjwatson> Task does not belong in debian/control.
<cjwatson> It is supposed to be autogenerated by the archive software.
<cjwatson> If this is all too hard then you should just tell live-build to use metapackages rather than tasks.
<shadeslayer> hm
<shadeslayer> cjwatson: the problem with that is that it's generating a huge poo
<shadeslayer> *pool
<cjwatson> being shouted at here.  cannot help you now.
<shadeslayer> uhh ... I'm not sure how I shouted at you 0.o
<Laney> I suspect the shouting is IRL
<shadeslayer> oh ... ok
<cjwatson> yes, I have children and it's dinnertime.
<cjwatson> anyway, I have no idea why using metapackages might be related to generating a huge pool; you're probably in the best position to dig into that
<cjwatson> when you're responsible for image building for a distribution you kind of get used to diagnosing this kind of thing :)
<cjwatson> but it's very hard to do without being in front of the failing build
<shadeslayer> cjwatson: understandable :)
<shadeslayer> anywho, still looking into it
<cjwatson> you could dig up the old cron.germinate from Launchpad from before it was converted to be a more native Launchpad script, I suppose, and wire that in to generate Task fields
<cjwatson> but if you aren't already familiar with it I suspect that would be a fair bit of work ...
<cjwatson> and it's not obvious it makes sense unless you're operating at an Ubuntu kind of scale
<shadeslayer> :)
<shadeslayer> afaictl, add_package pulls the meta package during the binary stage of the ISO build as well
<shadeslayer> so all the debs get downloaded again, and you get a huge pool of packages on the CD
<shadeslayer> right now, I've done a bit of hackery to check if that works
 * shadeslayer might switch to apt-ftparchive if he can't figure out what's wrong with reprepro
<lborda> cjwatson, where do I get the debian-installer packages files?
<lborda> cjohnston, I do have inside main this: ubuntu/dists/precise/main/binary-amd64/
<lborda> cjwatson, I do have inside main this: ubuntu/dists/precise/main/binary-amd64/
<TJ-> Anyone help with FTBS gnome-control-center: "error: âcc_shell_marshal_VOID__VOIDâ undeclared" ... there's a weird cc-shell-marshal.list containing "VOID:VOID" which seems related but I cannot find any way to build a header file from it using the debian/rules
<dobey> TJ-: there should be a cc-shell-marshal.[ch] which get built automatically during the build; glib-genmarshal gets run to generate them
<TJ-> dobey: Yeah, that's the problem. It's not compiling those afresh. The Makefile seems to show they should be included in the target gnome_control_center_SOURCES
<stokachu> hi, could i get someone to approve series nomination for http://pad.lv/1036834
<ubottu> Launchpad bug 1036834 in gdb (Ubuntu) "gdb should be marked "Multi-arch: allowed"" [Medium,In progress]
<stokachu> hi, could i get someone to approve series nomination for http://pad.lv/1036834 (sorry if double post, lagged out)
<ubottu> Launchpad bug 1036834 in gdb (Ubuntu) "gdb should be marked "Multi-arch: allowed"" [Medium,In progress]
<stokachu> bryceh: are you willing to review some multi-arch patches?
<dobey> TJ-: right, and it should also have a rule to build them
<micahg> stokachu: I don't know that :any is allowed in binary dependencies  in precise
<micahg> ISTR that being limited to a few packages as a build dependency only
<TJ-> dobey: I've followed the rules from the "cc-shell-marshal.c: cc-shell-marshal.list" > MARSHAL_FILES > gnome_control_center_SOURCES >  SOURCES | DIST_SOURCES > ID | TAGS | CTAGS ... got lost there!
<stokachu> slangasek: can you clarify micah's comment for precise?
<TJ-> dobey: strange. Working from the bzr branch. I had to "touch shell/cc-shell-marshal.list" to get it to rebuild
<TJ-> With gnome-control-center doing "bzr builddeb -S" results in "OSError: [Errno 2] No such file or directory: '<path>/INSTALL'". I'm trying to figure out why since that file isn't in the original bzr branch. However, it is listed in Makefile.am "MAINTAINERCLEANFILES="
<TJ-> Does this require a patch to Makefile.am too, in order to successfully build the source package ready for uploading?
<lborda> cjwatson, yes it works now! I am using apt-mirror for doing that! tks!
<bryceh> stokachu, I'm not the best to review multi-arch srus.  the few I've dealt with I've run by slangasek.
<stokachu> bryceh: ok np, thanks for the quick reply
<bryceh> stokachu, but I can definitely help with the sru mechanics if you get the multiarch bits squared with him
<stokachu> bryceh: ok sounds good ill talk with him to see when he has some free time
<stokachu> micahg: wouldn't allowed mean either or?
<micahg> stokachu: it's your premise that I had an issue with, not allowed per se, anyways, I have to go, but will check scrollback later
<stokachu> micahg: sorry i wasn't suggesting anything was just trying to understand
<trism> TJ-: your branch builds fine here, might just need a bzr revert to restore the deleted files
<TJ-> trism: Thanks, yes. I had my git head on and was trying to do "bzr checkout" to restore the working tree... what foxed me was "bzr log -n 0 INSTALL" wasn't showing any history for that file, which made me think it had never been in bzr
<TJ-> trism:  and a previous fakeroot debian/clean had invoked the maintainer_clean which had removed that file, grrr
<cjwatson> lborda: glad to hear it
<infinity> cjwatson: *nudge*
<cjwatson> infinity: you'll have to wait a bit ...
<infinity> cjwatson: S'all good.  elmo found himself a workaround.
<bryceh> @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:
#ubuntu-devel 2012-08-17
<kees> hrm, can't usb-creator-gtk use an ext4 for the main filesystem (since it boots syslinux?)
<kees> (or rather, can't we switch to extlinux?)
<slangasek> stokachu, micahg: hmm, TTBOMK :any is possible in precise; I can't think of any reason why it wouldn't be
<slangasek> stokachu, micahg: and in practice we're not talking about having any packages *in* precise depending on gdb:any
<Bluefoxicy> http://lists.gnu.org/archive/html/grub-devel/2009-04/msg00367.html
<Bluefoxicy> This should be standard reboot fare.  shutdown should kexec -e grub2whatever
<Bluefoxicy> (too bad it's unclear if this actually works yet)
<Bluefoxicy> that's interesting
<Bluefoxicy> you can't open an MTP device with a hell of a lot of stuff on it.  Nautilus complains DBUS timeout/failure
<Bluefoxicy> PTP it, remove a ton of images, swap back, it works again.
<Bluefoxicy> </google nexus>
<micahg> slangasek: ISTR some hoohah when wine wanted to depend on something :any, I think we were waiting for precise+1 so that there wasn't a problem with dpkg on upgrade
<micahg> in precise it was only used for build dependencies IIRC
<pp7> 12.04 why does my global menu stop working all of a sudden and go back to menu's per window?  How can i restart global menu?
<mvo> hm, whats up with the PPA builders? https://launchpad.net/~mvo/+archive/freeglut-multiarch tells me on amd64 the build will start next monday and i386 does not even tell me when it will try :/
<ScottK> mvo: data center move.
<lifeless> mvo: DC move.
<mvo> oh, of course!
<mvo> thanks
<shadeslayer> wheeee
<shadeslayer> cjwatson: image is unbootable xD
<shadeslayer> probably because of one of the patches I skipped
<shadeslayer> ( kvm says 'Booting from DVD/CD... )
<dholbach> good morning
<shadeslayer> morning dholbach
<didrocks> good morning Mr Holbach :)
<dholbach> hi shadeslayer, salut didrocks
 * shadeslayer ponders why the data center is being moved
<RAOF> Aligators.
<shadeslayer> what if the new place has worse animals?
<shadeslayer> like ... you know ... penguins and such :P
<RAOF> We'll import the alligators from the last place as a biological control.
<didrocks> they are moving it to australia, it's known to be a safe place with only friendly animals :)
<shadeslayer> ah .. animals and humans running a data center together, sounds like fun
<shadeslayer> "We got a bug in our system ... we'll patch it! ... no I meant literally a bug in the system!!"
<dholbach> shadeslayer, we'll have patch monkeys in there
<shadeslayer> :D
<rmk_> morning jodh
<jodh> rmk_: hi
<rmk_> just wondering if you saw my comments about your script?
<MCR1> haha
<rmk_> for tty-serial
<rmk_> specifically, IFS stuff
<jodh> rmk_: I was out yesterday, so no.
<rmk_> it was a few days ago
<rmk_> I found the problem
<rmk_> when you call getty you need to restore the IFS back otherwise you won't get the word splitting you expect
<jodh> rmk_: there are no new comments on bug 702574..?
<ubottu> Launchpad bug 702574 in upstart (Ubuntu) "getty should be started automatically on serial port when serial console is set on kernel command line" [Wishlist,In progress] https://launchpad.net/bugs/702574
<rmk_> because you leave it set to ',', getty gets "-8 115200 ttyS0" all as one argument
<jodh> rmk_: please could you just add your comments to that bug so they don't get lost? ;)
<rmk_> eventually... it seems not to be elinks compatible
<rmk_> iow,when I'm on the machine with firefox :)
<SpamapS> ok I'm going totally bonkers here
<SpamapS> I'm chrooted into a filesystem
<SpamapS> file has permissions for reading..
<SpamapS> no apparmor in effect
<SpamapS> but getting access denied
<SpamapS> but only when *sudo* tries to access (/etc/sudoers)
<SpamapS> hm or is it possible apparmor *is* doing something but not logging it properly?
<ev> mpt: am I remembering correctly that we're doing away with the Ubuntu logo in the error dialogs?
<mpt> ev, yes, I have an artwork request for a new icon. Do the error alerts show up in the Launcher? I forget.
<mpt> If so, the icon inside the alert should be the same as for the Launcher.
<ev> yes
<ev> one second
<ev> mpt: http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-08-17%20at%2010.31.43.png
<mpt> Oh, yeah, that thing
<xnox> =)))
<ev> mpt: I'm wondering if the spinner over the treeview is the best place for it, now that we can have multiple reports potentially loading at different times. Maybe a band that appears at the top of the treeview and says "Loading" with the spinner next to it?
<mpt> ev, how long apart are the sections likely to populate?
<ev> mpt: hard to say. That's entirely dependent on how frequent different crashes are occurring
<mpt> ev, and waiting for the last would be bad?
<ev> mpt: they can come in at any time. Lets say for argument's sake that you have the error report dialog up, with the show details pane expanded
<ev> another crash occurs
<ev> what should happen?
<mpt> ohhhh
<mpt> I was thinking just of the case where you already had all of them
<ev> ah
<mpt> you just hadn't analyzed them yet
<mpt> I'm tempted to say that showing the details pane should prevent aggregation of any later ones
<mpt> otherwise, even if you're concerned about exactly what the report contains, you may hit "Continue" just as a bunch of private stuff gets added to it.
<mpt> But that conflicts a bit with the idea of persisting expanded state of the details pane.
<mpt> (That could be prevented by making "Continue" insensitive for a few seconds after each problem, but in a diabolical case that might mean it never becomes sensitive.)
<ev> so it's possible to do that, but that would make determining which dialog to send subsequent error reports to difficult in the case where you've expanded the pane, a new report comes in and opens a new dialog, you collapse the pane and then a new report comes in.
<ev> unless the solution is to never aggregate to the existing dialog after the user has clicked show details, even if they then hit hide details
<xnox> as a point of interest / survey can I ask you to run:
<xnox> $ ls /boot/grub/unicode.pf2
<xnox> and tell me if you have it or not?
<geser> -rw-r--r-- 1 root root 2560080 Aug 10 11:41 /boot/grub/unicode.pf2
<xnox> geser: thanks.
 * ev headdesk
<ev> mpt: I'm glad I'm writing this state of the error tracker email
<ev> as it's getting me to think about some of these problems from a different angle
<ev> like how all the work I did on teaching crash-digger (the thing that links apport bug reports together) to use daisy.ubuntu.com for its brain so we could have just one mapping crash signatures to bug reports
<ev> this so we can have launchpad bugs on errors.ubuntu.com for the issues without them, and to lay the groundwork for crash signatures -> bugs -> uploaded source -> fixed binary packages stuff
<mpt> Standard therapist procedure: Communicating your problems helps solve them. :-)
<ev> I've realised that we can probably just leave crash-digger well alone, and just dup the crash-digger found bug against the daisy.ubuntu.com created one
<ev> mpt: I need a teddy bear
<cjwatson> pot plants work too
<ev> haha
<dholbach> tumbleweed, happy birthday! :)
<jocarter> happy birthday tumbleweed!
<xnox> ev: the 80cm Wenlocks are on sale
<ev> xnox: I have a rule. If I don't know what it *is*, I don't buy it in plush form.
<xnox> ev: it's a blob of metal =)
<ev> :)
<slangasek> micahg: ah right, lucid dpkg+apt would fail to parse that dep
<jdstrand> mterry: hey-- I don't remember the bug, but saw you were waiting on bin-deNEW of pycurl. it is done
<mterry> jdstrand, ah yes; awesome, thanks
<jdstrand> np
<barry> mterry, jdstrand \o/
<dholbach> anyone up for taking the last 1h slot on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable?
<tumbleweed> dholbach, jocarter: thanks
<dholbach> :)
<MacSlow> How do I best report this kernel-crash, which isn't picked up by ubuntu-bug/apport at all -> http://pastebin.ubuntu.com/1152750 (extracted manually from /var/log/syslog)
<smoser> stgraber, what is the "right" target of the symlink in /etc/resolv.conf ?
<stgraber> smoser: ../run/resolvconf/resolv.conf
<stgraber> it's relative to avoid problems when dealing with chroots
<smoser> stgraber, ok. good.
<smoser> for some reason my local system has absolute
<smoser> but i assume some result of me for that.
<smoser> the cloud images have relative, so i questioned the difference.
<stgraber> some early versions were creating an absolute symlink, so maybe you still have it from that time
<stgraber> I don't expect any problem on regular systems, the problem was mostly showing up with live-build/schroot/...
<BenC> infinity: Any idea what the 1 day backup is on the powerpc buildd's?
<stgraber> BenC: builders were moved between DCs yesterday, ppc only got back online an hour ago
<BenC> Ah, gotcha
<xnox> mpt: So no repeats on the alarms? =))) I'm guessing it's not a wake-up alarm then.
<xnox> mpt: should it boot the computer up as well?
<mpt> xnox, don't know if you went to the page or just read the diff, but the sketch shows "Repeat: (*) No  ( ) Daily"
<xnox> mpt: what I meant, is multiple alarms. I always set two alarms 7am & 7:30am
<xnox> cause I will snooze/ignore the first one
<mpt> xnox, if Ubuntu was smart enough to have timed startup and shutdown, I think it should first go in the Power settings. We could add it here later.
<xnox> mpt: Ok.
<mpt> xnox, baby steps. A single alarm for now. :-) Maybe a list of them later.
<xnox> mpt: the sketches look good =)
<xnox> mpt: there is a new installer design item similar with 'ubuntu one' integration, but landscape this time around =)
<mpt> joy
<mpt> cjwatson, hi, did bdmurray send you any of the statistics yet on how people edit their /etc/default/grub ?
<mpt> (for <https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-fix-grub-config-errors>)
<cjwatson> ah, I have an outstanding mail from him on that that I need to reply to
<ev> surely there's such a thing in gtk as a hseparator cell renderer
<ev> mpt: so to be clear on this before I go off writing custom cell renderers and come back with a beard and even more of a planet-sized hatred for GTK
<ev> individual report data with the expanders
<ev> separated by just a horizontal line
<ev> nothing fancier?
<mpt> nothing fancier
<cjwatson> Laney: looks like libpst could be synced?
<bdmurray> @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: bdmurray
<infinity> bdmurray: Didn't you just pilot a few days ago, or am I going insane?
<infinity> bdmurray: (The answer can be "both", FWIW)
<bdmurray> infinity: I was supposed to a few days ago but was working on an error tracker / apport thing
<infinity> Ahh.
<dpb___> Hi all -- is there is a policy on removing init scripts from a new version of a package?  Is an rm -f good policy, or is there something better?
<infinity> dpb___: Init scripts tend to be conffiles, so you might want rm_conffile
<infinity> dpb___: See the manpage for dpkg-maintscript-helper
<infinity> dpb___: Requires a pre-dep on dpkg (>= 1.15.7.2)
<shadeslayer> cjwatson: so I made everything work with the old lb build ( the on in the archives right now ), but it still doesn't boot 0.o
<shadeslayer> gives me a code 0003
<shadeslayer> maybe a bug in qemu
<mhall119> where can I get a list of packages in Precise's backports archive?
<tumbleweed> in the Packages list?
<mhall119> and where is that?
<mhall119> I don't see backports in http://archive.ubuntu.com/ubuntu/dists/precise/
<tumbleweed> precise-backports
<tumbleweed> e.g. http://archive.ubuntu.com/ubuntu/dists/precise-backports/main/binary-i386/Packages.bz2
<tumbleweed> mhall119: even easier: http://packages.ubuntu.com/precise-backports/allpackages
<mhall119> thanks tumbleweed
<tedg> slangasek, Hey, do you know of a good way to build unit tests for pam modules?  There seems to be ideas out there, but I don't see anything authoritative.
<slangasek> tedg: I'm not aware of one, sorry.  Linux-PAM upstream has an "xtest" framework, which requires root access to run
<tedg> slangasek, Hmm, okay.  This seems to be the best I've found: http://git.eyrie.org/?p=kerberos/pam-krb5.git;a=blob;f=tests/fakepam/README;h=b0f23abcc75fabcd85206bc1a3d8e3fede5e61d8;hb=HEAD
<slangasek> tedg: anything in pam-krb5 upstream is probably a good starting point
<bdmurray> tumbleweed: can you explain http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/view/head:/ubuntutools/sponsor_patch/sponsor_patch.py#L184 to me?
<bdmurray> tumbleweed: particularly line 205
<bdmurray> I'm at an ubuntu bug with 2 tasks, really 3 tasks, but just for different releases and sponsor-patch is assert'ing on me there
<tumbleweed> bdmurray: the assertion is because we need to find the single task that matches the branch
<tumbleweed> line 203 should pick the right release
<bdmurray> tumbleweed: right and this bug has 2 quantal tasks for the same source package
<bdmurray> ipdb> [t.get_series() for t in tasks]
<bdmurray> [u'quantal', u'quantal']
<tumbleweed> never seen that before
<tumbleweed> bug number?
<bdmurray> bug 959795
<ubottu> Launchpad bug 959795 in trousers (Ubuntu Quantal) "package trousers 0.3.7-2ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 137" [High,Triaged] https://launchpad.net/bugs/959795
<bdmurray> all 3 don't show up in the web interface but in the API and probably +text
<bdmurray> I believe it happens when you target a bug to the development release
<tumbleweed> that makes sense
<tumbleweed> how do we pick the right one?
<bdmurray> they seem to be the same series so does it matter?
<tumbleweed> actually, probably not. It only changes the state of tasks for old-style sync-acking
<tumbleweed> so, I'd be ok with asserting 0<x<2, with a comment explaining that oddity
<dpb___> infinity: thanks, will look
<tumbleweed> bdmurray: fix committed
<bdmurray> tumbleweed: ah, thanks!
<tumbleweed> bugtask was being too clever, and filling in quantal for the task that didn't have a series
<bdmurray> tumbleweed: well that makes sense if there are no series tasks
<tumbleweed> yeah
<bdmurray> @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:
<silverarrow> anyone clever with handeling packages here?
<silverarrow> anyone here at all=
<silverarrow> :-)
<micahg> silverarrow: if it's not related to stuff in the archive, you probably want #ubuntu-packaging
<silverarrow> it`s amazing what channel devision can conjure up these days
<silverarrow> micahg: can you take a look at this http://imagebin.org/224932
<micahg> silverarrow: will follow up in -packaging
<plasmasolutions>  Good evening guys...I've got a brand new intuos 5 under ubuntu here and need really your help. As far as I can see the pen /eraser is working properly but when I lay my finger at on of the left tablet buttons or move it in a straight row from top to bottom the pointer moves for a very short timespan to 0|0 (causing the exposee feature under gnome3 to happen)
<plasmasolutions> When I set the panel to left handed, the pointer moves to the lower right for a tiny period of time
<plasmasolutions>  I installed under my ubuntu 12.04 this package-archive: ppa:lekensteyn/wacom-tablet
<plasmasolutions> and the wacom-dkms package, it's this archive: https://launchpad.net/~lekensteyn/+archive/wacom-tablet
<plasmasolutions> Could someone lead me to the path where we can find if this is a bug or a misconfiguration? Didn't change anything by hand...
<plasmasolutions> no idea, anyone?
<failedassertion> I have a bug but I don't know where to file it. Using the "fsprotect" package in universe doesn't work on /var with samba installed, because samba starts writing to files in /var/log before fsprotect can move the rw-mounted /var out of the way. Is this a bug in fsprotect, or is it a packaging bug in Ubuntu?
<failedassertion> i.e. I think it's something specific to upstart trying to parallelize things
<cjwatson> I would be inclined to file that against the Ubuntu fsprotect package
<cjwatson> It probably needs to be converted to an Upstart job itself so that it can start at the appropriate time and block samba startup, or something
<cjwatson> Without having looked at the details or anything
<failedassertion> cjwatson: Alright. Sounds good. I'll write it up and file it. Thanks.
<slangasek> sounds non-trivial to fix in the general case however, since /var may or may not be a mount point
<cjwatson> Also samba may or may not be installed
<slangasek> and there's no consistent way to block everything that wants to start once the filesystem is up
<cjwatson> I'm not certain that fsprotect is the right place for the bug; it's just where I'd start with it
<cjwatson> It's possible fsprotect would need to be integrated into mountall to work properly
<failedassertion> i was afraid of that :-\
<cjwatson> There *might* be some hack involving starting on the various mounted events
<slangasek> actually, it seems like an upstart job that's 'start on mounted / instance MOUNTPOINT' would probably be what you want
<cjwatson> Yeah
<cjwatson> That would block local-filesystems until it's complete, which would block samba
<failedassertion> slangasek: cjwatson: that's a good thought... I've got basically no knowledge of upstart, but when I look at this tomorrow I'll dig a little deeper. I've gotta run now, but thanks again
#ubuntu-devel 2012-08-18
<hggdh> bah, my reportbug was set to 'print'
<blaggard> Hi! anyone in here?
#ubuntu-devel 2012-08-19
<codemaniac> j #ubuntuforums
<AL13N> does anyone know the mysql maintainer and is he on IRC?
<jml> jml@grace:~$ sudo do-release-upgrade -d
<jml> Checking for a new Ubuntu release
<jml> No new release found
<jml> never mind.
 * SpamapS \o/'s as uploads start flowing in to the archive again :)
 * SpamapS /o\'s as he realizes he hasn't showered yet today
<penguin42> then please put those armpits away
<jokerdino> hey guys. if i want to suggest a quicklist for gnote, how do i proceed?
<penguin42> jokerdino: it's probably best to ask upstream at gnote's bug tracker/forum
<jokerdino> right then. patches aren't prefered in ubuntu?
<penguin42> jokerdino: it's normally best to do stuff upstream unless it's fixing an ubuntu specific bug or integrating it in some ubuntu thing (like unity etc)
<jokerdino> well, quicklist is unity integration but i'll go with upstream.
<penguin42> oh hang on, then I didn't realise that - I'm not a unity user
<jokerdino> right. thanks
<penguin42> jokerdino: if it's a unityism then it might be best to be local - but ask a unity guy
<jokerdino> hm
<cjwatson> SpamapS: yeah, we tested the uploader and publisher on the new machine but (at least I) fell asleep before making sure that the cron jobs had actually been enabled :)
<SpamapS> cjwatson: "Is it plugged in? Is it turned on?" -- The two first questions of all I.T. responses. :)
<cjwatson> and it took a day or so before anyone complained anywhere I saw ...
<cjwatson> that's weekends for you I suppose
<Laney> well, people probably expected reduced service due to the move
<Laney> at least that's why I only complained quietly
<xnox> well, some package-importer branches are out of date, and it doesn't have them as pending/failed either
<cjwatson> that one's nothing I know of - try #launchpad-ops internal
<SpamapS> Yeah I did not complain because I figured it was part of the DC move
<penguin42> anyone else seeing problems with backtraces showing sprintf missing the buffer parameter?
<penguin42> wow - I've just found a Y2K bug - bit late, but hey....
<penguin42> TToTD struct tm's tm_year is 'number of years since 1900' so is currently 112, and if you print that into a buffer that only has 2 chars you get an overflow
<SpamapS> penguin42: y2k bugs are now y3k bugs ;)
<SpamapS> penguin42: or, optionally, y2100 bugs
<penguin42> SpamapS: No - this package has been broken for the last 12 years!
<penguin42> well, might have only been crashing since we turned stack smashing detection on
<micahg> penguin42: I think that's been on for about 2 years now
<penguin42> yeh, looks like it was fixed upstream a year or two ago
<penguin42> bug 771589
<ubottu> Launchpad bug 771589 in fbb (Ubuntu) "fbb buffer overflow" [Medium,Triaged] https://launchpad.net/bugs/771589
<penguin42> hmm food
<qdb> i want to read some info, explanation, about that update works other way in 12.04. sometimes it looks like it updates in background. it lock install process, several processes work, even if update manager is closed
<green7> does any one know how can I change keyboard mapping in ubuntu?
<micahg> green7: support for quantal in #ubuntu+1, any other release in #ubuntu
<penguin42> why is gcc-4.4 still in quantal?
<slangasek> tjaalton: it appears that the current mesa in quantal FTBFS with the current libdrm in same... are you aware of this?  Is this getting fixed soon?
<micahg> penguin42: it's still in Debian
<penguin42> micahg: Ah, I see - hmm, does anything still build depend on it?
<micahg> penguin42: yes
<penguin42> oh dear
<tjaalton> slangasek: no didn't know about it. a new mesa is being prepared though and should be ready before FF
#ubuntu-devel 2013-08-12
<fossterer> Hi ! I removed a patch applied earlier and receiving error as a result. Can smeone look into it?
<RAOF> lifeless: So that apt-btrfs-snapshot can work.
<lifeless> RAOF: I don't see the connection
<RAOF> lifeless: apt-btrfs-snapshot will take snapshots of your / on each apt transaction; you obviously don't want to roll back your /home as well if you decide to rollback
<lifeless> RAOF: there are lots of other things - /var comes to mind, which would be equally disasterous to rollback willynilly.
<lifeless> RAOF: mail spool, virtual machine files, LXC containers...
<RAOF> lifeless: But only bits of /var - it's a good bet that nothing under /home wants to be rolled back, whereas various bits of /var will.
<lifeless> RAOF: except for any daemon with a /home home, but sure thats less likely.
<RAOF> This could be rephrased as âpackage downgrades are hard, m'kay?â
<RAOF> What daemon(s) have a /home home?
<lifeless> sure, but the thing that got me was the *default* install makes a subvolume.
<lifeless> apt-btrfs-snapshot isn't installed by default
<lifeless> in fact, it's in universe.
<lifeless> RAOF: daemons with a /home home - I don't know, was a hypothetical, which is why I said 'less likely'
<RAOF> AFAIK it's harmless to make /home a subvolume, so you might as well make it one?
<lifeless> it's not harmless ;)
<lifeless> operations like rebalancing and so on that are per subvolume need to be repeated per subvolume; backups and copies etc with --one-filesystem likewise.
<lifeless> Folk *need to know* that this is being done. The partitioner shows what the partition table will be like - so that informs the person installing Ubuntu.
<lifeless> But there was zero notification of the subvolume behaviour, I found out when I had cause to review my fstab, and then found out my backup scripts hadn't been working properly for a year
<RAOF> Eeep.
<lifeless> Thats what I said.
<lifeless> Only my version wasn't printable.
<lifeless> I had a lot of good backups of everything but boot (expected) and home (unexpected)
<RAOF> Unicode has a *lot* of characters :)
<lifeless> :)
<ajmitch> 'small pile of poo' probably describes it
<RAOF> I expect that this is a bug in the partitioner, or at least will require changes there. I don't believe the partitioner understands subvolumes, so it'll need to be taught about them before it can display them.
<lifeless> So for clarity: I have no objection to the installer suggesting I might like a subvolume. I have a big objection to it just happening.
<lifeless> Of course, I may be horribly misremembering, in which case mea culpa.
<lifeless> if I get a little time I'll hand install a VM and see
<RAOF> lifeless: Oh, no. It definitely just happens.
<arand> lifeless: (randomly read the irclog) I'm not sure if you've read it already, but I've tried to put down the info about the ubuntu btrfs setup over at https://help.ubuntu.com/community/btrfs#Ubuntu-specific_subvolume_layout_in_11.04_and_later
<lifeless> arand: I saw that, thanks.
<lifeless> arand: it doesn't explain why it's like that, just that it is.
<arand> Indeed, though the home - / separation tends to be the most common one (except maybe boot), so I guess it makes a bit of sense.
<arand> lifeless: I think it was cjwatson who instated it in the installer, so I guess he's the one to ask ;)
<dholbach> good morning
<sil2100> Hi!
<sil2100> Does anyone know if there will be some patch pilot available today ;) ?
<Noskcaj> sil2100, there's meant to be three different ones today, dholbach might know actual times
<Noskcaj> Do you want me to check it?
<dholbach> https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&gsessionid=OK
<dholbach> (linked from https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews)
<Laney> a crack team
<mlankhorst> g'day
<mlankhorst> @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: mlankhorst
<dholbach> sil2100, ^ :)
<mlankhorst> keep in mind I probably can't upload anything, so you have to find your own sponsor :p
<sil2100> \o/
<sil2100> dholbach: thanks ;)
<sil2100> mlankhorst: I'll poke you about sponsoring something in a moment if you don't mind ;)
 * mlankhorst can only upload to xorg
<mwhudson> who do i have to bribe to get this kernel patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c5f927a6f62196226915f12194c9d0df4e2210d7
<mwhudson> backported to raring?
<dholbach> mwhudson, https://wiki.ubuntu.com/KernelTeam/KernelUpdates is what I could find quickly - maybe it's worth to ask in #ubuntu-kernel too
<mwhudson> dholbach: i guess it's getting to the point where "wait for saucy" becomes the easiest option :)
<didrocks> cjwatson: I know you are at debconf, but answer when you can: I saw that britney didn't block the Mir deps (unity-system-compositor) having a strict version dependency on Mir (latest Mir went in without the compatible u-s-c)
<didrocks> cjwatson: as upstream are breaking ABI daily, do you think there is a way for that case to be blocked? If not, if I try using a virtual package based on the upstream version, will that work?
<seb128> cjwatson, rewording what didrocks said, does britney handle a "provides: <something>" being dropped as "something" being dropped, e.g does it enforce rdepends of something to be fixed before allowing migration?
<geser> didrocks: both u-s-c and mir in saucy have the same timestamp in their version right now. so it's ok right now?
<didrocks> geser: it's ok right now, but it's released every 4 hours
<didrocks> I've block automated uploads during the week-end because of this
<geser> didrocks: should u-s-c have also an upper bound version check on libmirserver1 if it doesn't work with newer ones? (currently it's only >=)
<didrocks> hum, weird, it was = before
 * didrocks looks at who changed that
<didrocks> geser: oh I know, it's because of -V wasn't changed with ABI transition
<didrocks> ok, let's see with the fixed version that will now be available
<didrocks> and see if it will block mir without u-s-c
<sil2100> mlankhorst: hi!
<sil2100> mlankhorst: are you free for some sponsoring by any chance?
<sil2100> mlankhorst: there is this: https://bugs.launchpad.net/ubuntu/+source/lucene++/+bug/1211184
<ubottu> Launchpad bug 1211184 in lucene++ (Ubuntu) "lucene++ 3.0.4-0ubuntu2 needs releasing" [Undecided,New]
<mlankhorst> sil2100: as I said I can't sponsor uploads outside of xorg :-)
<seb128> sil2100, I can sponsor it
<seb128> @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: seb128, mlankhorst
<asac> hi... what was the magic to get a buglist like: https://bugs.launchpad.net/ubuntu-touch-preview/+bugs in plain/text ?
<asac> dholbach: am i right that you remember this? :)
<asac> bdmurray: ^^ thx
<sil2100> seb128: !
<sil2100> seb128: thanks :)
<seb128> asac, not sure you can...
<asac> seb128: i am 100% sure i did that in the past :)
<seb128> asac, you can add /+text to some pages, like bug reports
<asac> ah
<sil2100> mlankhorst: no problem, seems I have missed that message due to my disconnecting
<seb128> asac, but that doesn't work for the list view
<asac> yeah
<asac> lets wait for bdmurray or dholbach to waked up
<seb128> asac, you can do https://bugs.launchpad.net/ubuntu-touch-preview/+bugs -text
<seb128> ups
<seb128> asac, you can do https://bugs.launchpad.net/ubuntu-touch-preview/+bugs-text
<seb128> asac, but that gives you only the numberS...
<seb128> not very useful
<asac> interesting :)
<asac> i think i saw a more meaningful list
<asac> when we worked on this bug harvesting tool back in heno days :)
<asac> but lets see
<cjwatson> didrocks: if there's still a problem, I'd need to see the control files of the things that you think should have been blocked, bearing in mind I don't know the specific packages in question
<cjwatson> didrocks: from the sound of the discussion I read, using a virtual package that expresses the ABI would be a good idea; that's probably better than adding a << bound
<didrocks> cjwatson: yeah, now we have a fixed version of Mir/u-s-c in the release pocket. I'm trying to rebuild a new Mir and push to proposed to see if it was just due to the bad transition
<cjwatson> seb128: yes
<didrocks> cjwatson: right now, the deps are just:
<didrocks> unity-system-compositor Depends: mir (= <version>)
<cjwatson> Exact-version dependencies should be banned :-P
<cjwatson> They're almost never what people *actually* want, just a bad approximation
<didrocks> cjwatson: upstream not bumping soname should be banned as well
<didrocks> they are breaking ABI multiple times a day
<cjwatson> Yes, but that isn't an excuse for exact-version dependencies
<lifeless> didrocks: mir is ?
<didrocks> lifeless: right
<didrocks> cjwatson: and they don't want to maintain the ABI version by hand
<cjwatson> If I were in this situation I would look into automatically computing an ABI hash
<didrocks> so I have to do with the constraints that are imposed on me
<cjwatson> Many packages in the archive do this, although I admit I don't offhand know of a C++ example
<didrocks> cjwatson: that would be a nice thing I can investigate the day I don't have a ping every 2 minutes and 4 new compononents to push every day
<cjwatson> But if you used one of the tools to produce a reduced textual representation of the ABI, took a few characters from its hash, and stuck that in Provides and shlibdeps, that would do the job
<cjwatson> didrocks: Sorry, I can't help you then
<cjwatson> I have as much work as you do
<didrocks> I know :)
<cjwatson> Please don't blame me
<didrocks> cjwatson: I don't at all, but just understand why it's a strict dep for now :/
<cjwatson> If you don't have time to do any changes, you can't improve anything
<didrocks> I do changes to accomodate upstreams and try to get things flowing
<didrocks> cjwatson: so, back to my question, should the exact version dependency block britney?
<cjwatson> Yes
<didrocks> ok, thanks, I didn't catch they didn't bump the soname change it in debian/rules the other day, so this rebuild should proove it works
<didrocks> thanks cjwatson
<cjwatson> https://wiki.ubuntu.com/ProposedMigration for more on the migration semantics
<didrocks> cjwatson: ah, a good reading, will have a look, thanks again
<stokachu> rbasak: building and testing the mysql upgrade now should hopefully be ready in the next hour
<dholbach> asac, I was out for lunch
<dholbach> asac, https://bugs.launchpad.net/ubuntu-touch-preview/+bugs-text
<asac> dholbach: right. so no way to get the same stuff with titles etc.?'
<asac> i thought that existed as well at some poin
<dholbach> asac, no, AFAIK for that you have to use the API
<asac> kk thx dholbach
<didrocks> cjwatson: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html hum, Mir seems to be a valid candidate, but u-s-c Depends on libmirserver1 (= 0.0.9+13.10.20130812.1-0ubuntu1)
<didrocks> mir (0.0.9+13.10.20130812.1-0ubuntu1 to 0.0.9+13.10.20130812.2-0ubuntu1)
<Laney> didrocks: fails in update_output for that reason
<didrocks> Laney: ah, and that's not reflected in _excuse?
<Laney> no, that's just a first stage of checks
<Laney> https://wiki.ubuntu.com/ProposedMigration
<didrocks> Laney: well, I read:
<didrocks> The update excuses: list of all candidate package versions and the basic status of their propagation into the release pocket; this is somewhat shorter and nicer than
<didrocks> The update output: the complete, rather crude output of the proposed-migration scripts as they recurse through the candidates.
<didrocks> It doesn't say the first one is only a first stage :)
<didrocks> but anyway, it's excellent, so blocked as it was supposed to, great! :)
<didrocks> thanks Laney
<cjwatson> didrocks: this is working as it's supposed to, as Laney said.  I've clarified the wiki page
<didrocks> cjwatson: excellent! thanks a lot. /me ticks one less issue to deal with for now
<smartboyhw> kirkland, sure (on the email)
<kirkland> smartboyhw: great, thanks
<sergiusens> cjwatson: good day again! Question for you, is the cron for http://people.canonical.com/~ubuntu-archive/click_packages/ using ~sergiusens/click_ready/click_copy.py or a local copy?
<cjwatson> the former
<sergiusens> great, that works for me
<roaksoax> xnox: howdy!! you are one of the maintainers of python-flake8 in debian right?
<roaksoax> xnox: or am I crazy :)?
<roaksoax> i think i am
<roaksoax> nevermind :)
<stokachu> rbasak: i attempted to build mysql but it continually fails on a few unittests
<stokachu> and each build takes like 3 hours
<infinity> @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: mlankhorst, infinity, seb128
<infinity> mlankhorst: Still piloting, or forgot to bounce out?
<mlankhorst> @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: seb128, infinity
<mlankhorst> well was about to eod :P
<mdeslaur> mterry, mpt: this is cool: http://www.iphonehacks.com/2013/08/codescrambler-scrambles-numbers-on-passcode-screen.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+iphonehacks+%28iPhone+Hacks%29
<mdeslaur> (as a non-default alternative)
<mterry> cute
<mpt> cool
<dobey> anyone know anything about possible insanity of mixing qt4 and qt5 libraries together in the same binary?
<dobey> is it doable, or do you end up with same problems of gtk 2/3 mixing?
<dobey> n/m
<pete-woods> robru: good afternoon! when you get the chance, would you be able to enable the coverage and test hooks for the libqtdbustest and libqtdbusmock projects in the same way you have done for indicator-network-prompt?
<pete-woods> dobey: don't do it -> sedfault city
<pete-woods> *segfault
<pete-woods> they share the same namespaces
<dobey> right
<ScottK> dobey: http://perezmeyer.blogspot.com/2013/08/qt-in-debian-using-qt4-andor-qt5-in.html
 * pinky is away: Away
<xnox> roaksoax: nonetheless, what do you need/want with python-flake8 =) ?
<xnox> roaksoax: it's team maintained, so i have commit access...
<dobey> mardy: are you still around?
<dobey> guess not
<roaksoax> xnox: it is just that i want to sync it but the package in debian is broken as it depends on non-existant packages. but it seems that the svn repo has an updated packaging that has not yet been released
<xnox> roaksoax: ah, yeah. it's in flux at the moment.
<roaksoax> xnox: yeah! thought you were maintaining it but i guess i misread :)
<Noskcaj> kirkland, I was the only person who did anything at the testdrive hackfest. Do i still need to fix the changelog?
<Noskcaj> And your release script still didn't +1 the setup.py
<kirkland> Noskcaj: okay, I'll fix the release script
<kirkland> Noskcaj: you can put all of the changes under your own name/section, [ Jackson Doak ]
<kirkland> Noskcaj: but, yes, I do need you to write a list of bulleted changes
<kirkland> Noskcaj: look at debian/changelog and you'll see how I do those
<kirkland> Noskcaj: this is something you'll need to learn, if you want to help maintain TestDrive ;-)
<kirkland> Noskcaj: did Smartboyhw contribute to the hackfest?
<kirkland> Noskcaj: he emailed me asking me to add him to the testdrive team since he organized the hackfest;  I was curious what his contributions were to the day...
<Noskcaj> kirkland, nothing. danchapman was the only person who showed up, but his PC crashed the moment he realised testdrive was made with quickly.
<Noskcaj> btw, quickly is broken in 13.10
<stokachu> cjwatson: i was gonna merge keepalived is that cool with you?
<olli_> bregma, bdmurray is wondering what's a good ML to get autogenerated regression notifications for bamf in saucy
<bdmurray> olli_: actually raring
<olli_> bdmurray, alright, but not ubuntu-touch ;)
<bregma> I don;t think there is a mailing list for that
<olli_> bregma, it's currently going to ps-jenkins
<bdmurray> I'm using the email address of the uploader of the package which is ps-jenkins
<olli_> which I don't think is monitored for that reason
<bregma> so is everything else
<olli_> fginther, ^ do you have any input?
<sergiusens> olli_: everyone in QA has access to PS jenkins, it's a mailing list
<sergiusens> it's very high traffic though
<fginther> olli_, one moment
<olli_> sergiusens, it's not about access, but about looking out for such mails
<bdmurray> the subject of them is regularly formatted fwiw
<bregma> perhaps we need finer-grained status mails from the automated testers
<sergiusens> olli_: well I'm subscribed to that list and filter out what interests me
<bregma> I just check the results page online from time to time
<fginther> bdmurray, is this for the daily-release tests?
<bdmurray> fginther: no this is using the ubuntu error tracker to see if there are regressions detected in Stable Release Updates - http://www.murraytwins.com/blog/?p=127
<Noskcaj> kirkland, i've fixed the changelog. change you merge and possibly release?
<fginther> bdmurray, olli_, sergiusens' filtering is probably the best option. Monitoring packages already in the wild isn't something I normally do
<olli_> fginther, bdmurray wfm
<bdmurray> olli_: so the emails shall continue to go to the ps-jenkins list? is the current one awaiting moderation?
<olli_> bdmurray, that's how I understood fginther, I am not a moderator on that list (afaik)
<fginther> bdmurray, is something stuck?
<bdmurray> fginther: I don't know as I don't have access to the archive
<fginther> bdmurray, hmm, have you requested access to the ps-jenkins list? I'm not sure the moderator is still around, may need to engage IS
<seb128> @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: infinity
#ubuntu-devel 2013-08-13
<sergiusens> cjwatson: for testing purposes, I'm looking into adding extra data into the manifest under our CI, something like source: {vcs-bzr: 'lp:...', vcs-rev: '...'} ... technically it works and I can retrieve the autopilot tests from bzr. I'm just wondering if you had a better idea
<SpamapS> Hrm.. something wonky in Ubuntu 13.04 vs. 12.10 and earlier..
<SpamapS>     sed -i -e 's/\(^GRUB_CMDLINE_LINUX.*\)"$/\1 nomodeset vga=normal"/' /etc/default/grub
<SpamapS> used to ensure we'd get no graphical consoles
<mardy> dobey: pong :-)
<dholbach> good morning
<infinity> @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:
<mdeslaur> diwic: there is an apparmor API that pulseaudio can use to determine if a client is confined. Please ask tyhicks about it when he gets here
<diwic> mdeslaur, okay
<diwic> mdeslaur, so yet another build dependency for PulseAudio (apparmor) then?
<diwic> mdeslaur, do you think we should have a meeting about PulseAudio + touch + security?
<mdeslaur> diwic: we can do that...please invite me, tyhicks and jdstrand
<diwic> mdeslaur, btw, a quick question; I added rtkit to my test image, which PulseAudio talks to over system dBus. Is this prohibited on touch?
<mdeslaur> diwic: no, that's fine
<diwic> mdeslaur, if it's working just like on the desktop then it's something else, but I figured it was worth asking before digging deeper
<mdeslaur> I'm not aware of any reason that wouldn't work on touch
<diwic> ok
<mdeslaur> unless consolekit isn't working on touch or something
<diwic> mdeslaur, consolekit? I thought we switched to logind.
<mdeslaur> d'uh, yes, logind
<tumbleweed> doko: the bug I mentioned last night http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719485
<ubottu> Debian bug 719485 in src:inventor "[inventor] please explicitly link Decal.so against libc" [Wishlist,Open]
<tkamppeter> I have removed the binary package ghostscript-cups and have moved the contents into cups-filters, is it OK if cups-filters has breaks/conflicts/replaces: ghostscript-cups? Or do I need a ghostscript-cups transitional package (provided by which source package and what should it depend on?). How can I make an update uninstall the current ghostscript-cups when cups-filters 1.0.36 gets installed?
<tkamppeter> pitti: ^^
<sergiusens> cjwatson: hey, did you see my Q about click manifest entries for testing?
<tkamppeter> Anyone can help me with a packaging issue?
<pete-woods> fginther: good morning!
<pete-woods> fginther: would you be able to regenerate the libqtdbustest and libqtdbusmock jenkins jobs? they don't seem to have picked up the test and coverage reporting that is configured in the back-end configuration
<fginther> pete-woods-lunch, updating jobs now
<fginther> pete-woods-lunch, I've finished regenerating the jobs, please let me know if they need more love
<pete-woods> fginther: thanks! that seems to have fixed it!
<bdmurray> ev: bug 982082 has a couple of links to errors that no longer work (see comment #6).  Do you know what might have caused this?
<ubottu> bug 982082 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with IOError in init_proxy(): [Errno 5] Input/output error" [Medium,Incomplete] https://launchpad.net/bugs/982082
<ev> bdmurray: they're probably on the old database
<ev> they're not gone forever. We have a plan to merge the data back in, but it's going to take a couple of weeks
<nemo> http://m8y.org/images/temp.png (??) http://m8y.org/tmp/temp.txt (what I see on terminal)
<bdmurray> ev: but I should be able to find similar ones just with a lower count?
<jamespage> barry, hey - I was looking at setuptools/distribute merging upstream and someone pointed me at your mail to the debian-python ML
<jamespage> barry, are you planning any work in that area this cycle?
<stokachu> dholbach: i updated that keepalive merge with your suggested changes
<stokachu> dholbach: i dont think it qualifies as a full sync so i kept it as a merge
<barry> jamespage: i'd like to, but i'm pretty busy with phone stuff so i don't know if i'll get to it :(
<jamespage> barry, thats fine - I just wanted to check that I'm not stepping on your toes or anything if I do
<barry> jamespage: no, it would be fantastic if you take it on
<barry> jamespage: and i'd be happy to review/test/sponsor
<jamespage> barry, thanks
<mdeslaur> bdrung: any chance of a new version of ubuntu-dev-tools soon?
<ev> bdmurray: I don't follow your question
<ev> bdmurray: oh right. Yes :)
<bdmurray> ev: I could go to e.u.c/?package=ubuntu-release-upgrader and look for similar IOError crashes
<ev> bdmurray: you could look it up by the actual crash signature
<dholbach> stokachu, ok cool - will take a look in a bit
<stokachu> dholbach: no worries, thanks for the help
<pete-woods> fginther: so that change seems to have enabled coverage reporting, but I can't seem to autoland any more (with strange build errors)
<pete-woods> fginther: http://s-jenkins:8080/job/libqtdbustest-saucy-amd64-autolanding/4/console
<fginther> pete-woods, looking
<pete-woods> fginther: thanks :)
<fginther> gah!!!
<fginther> pete-woods, I found the problem, I've reapproved to retest and will monitor
<pete-woods> fginther: excellent, thanks!
<punter> I'm new: I have 3 packages I want to upload to launchpad, 1 is dependent on 2 and 2 on 3. Should I offer them through the same PPA or set up different PPAs given that some people might want to download just 3, or just 2+3 ?
<beuno> punter, I don't think you can depend on packages in other PPAs, so you would have to ship them all in the same one
<punter> Thanks beuno
<knocte> Cimi: ping
<achiang> punter: yeah, what beuno said. just put them all in the same PPA
<punter> thanks achiang
<bdrung> mdeslaur: i wanted to upload it to debian after you asked me, but it fails in an unstable pbuilder instance: https://paste.debian.net/24738/
<mdeslaur> bdrung: :(
<mdeslaur> lool: ^
<mdeslaur> bdrung: perhaps replace "name = name.decode(encoding)" with "name = name and name.decode(encoding)"
<bdrung> mdeslaur: name and name.decode(encoding)?
<mdeslaur> yeah, if name != None, it will do the decode
<mdeslaur> else it won't
<bdrung> okay. if name: name = ... is easier to read
<mdeslaur> sure, that works too
<bdrung> mdeslaur: will you commit that change?
<mdeslaur> uh, sure, one sec
<bdrung> thanks
<punter> I'm new: When I upload a source package to launchpad, does it automatically get built for every (recent) release of Ubuntu? If not, is there an automatic way to do it other than submit many times?
<mdeslaur> bdrung: done, thanks
<punter> someone? :(
<beuno> punter, so, this is not the right channel to ask for help with PPAs, this is specifically targetted to developing the core of Ubuntu
<beuno> punter, I'd suggest #launchpad
<punter> Ok, thanks!
<bdrung> mdeslaur: thanks & uploaded.
#ubuntu-devel 2013-08-14
<hallyn_> lifeless: i was going to push netcf to saucy so you could test the memory leak, but i seem to nto have upload perms again (was sure it had been added to server set last time...)  but you should be able to build your own from  http://people.canonical.com/~serge/netcf-saucy.debdiff
<lifeless> heh, I'm on raring anyhow; will have a poke
<hallyn_> lifeless: should be almost identical (but will pushd ebdiff for that in just a moment - of course that will need sru to get into the archive :)
<infinity> hallyn_: I can sponsor that for you.
<infinity> hallyn_: Or I can sponsor it to Debian and you can sync.
<hallyn_> infinity: thanks.  originally i was going to wait for ahs3 to sponsor to sid and sync from there, but then i was thinking it would be worth testing in saucy immediately.  so i can go either way.
<infinity> hallyn_: Your call.
<hallyn_> infinity: ok, pls do push to saucy
<hallyn_> meanwhile i should figure out why gnulib (under netcf/) wont' build on jessie
<infinity> hallyn_: Uploaded.  And where is this gnulib jessie build failure?
<infinity> hallyn_: You mean specifically jessie, but not sid?
<infinity> ... in which I discover that I still don't have jessie chroots, only squeeze, wheezy, sid, and experimental.  Oops.
<hallyn_> infinity: yeah, only jessie.  one sec, the failure is:
<hallyn_> http://paste.ubuntu.com/5983302/
<infinity> Erm, that really *only* fails on jessie?
<infinity> Now I need to create a chroot just to satisfy my curiosity. :P
<hallyn_> yeah wheezy and sid were both happy.
<hallyn_> so it's complaining that gets is undefined when it's being marked insecure?  weird.
<hallyn_> apparently cjwatson worked around a similar bug in grub2, commenting in changelog "Avoid assuming that gets is declared"
<hallyn_> (still waiting for devscripts to install so i can look more closely)
 * hallyn_ sees if he can just steal gnulib_gets.patch
<hallyn_> yup
<infinity> hallyn_: So, uhm, it builds on jessie for me.
<infinity> hallyn_: http://lucifer.0c3.net/~adconrad/netcf_0.2.3-3ubuntu1_amd64.build
<lifeless> hallyn_: builds fine on raring
<hallyn_> infinity: well that's whack.  i needed: http://people.canonical.com/~serge/netcf-jessie.debdiff
<infinity> hallyn_: That patch certainly won't hurt, but curious that it Works For Me. :P
<lifeless> hallyn_: running that build now, will see if it leaks overnight
<hallyn_> infinity: wait, that's the wrong version
<hallyn_> infinity: jessie has 1:0.2.0-5, you compiled netcf_0.2.3-3ubuntu1.dsc ?
<hallyn_> lifeless: great - thanks
<infinity> hallyn_: Oh, fair enough.  But who cares, then?  When 2.3-3 migrates, you're good.
<hallyn_> here's hoping
<infinity> hallyn_: I assume 2.3-3 has a newer gnulib that deals with glibc >= 2.16 correctly.
<hallyn_> infinity: heh, i admit i'm not clear on the package migration path ever since jessie was introduced
<infinity> hallyn_: jessie = testing.  How is that unclear? :)
<infinity> hallyn_: squeeze = oldstable, wheezy = stable, jessie = testing, packages migrate from sid to testing.
<hallyn_> what is it waiting on for the sid version to get to jesie?
<infinity> hallyn_: Looks like migrating it causes libvirt to become uninstallable.
<infinity> hallyn_: Perhaps just waiting for the two to migrate together, I didn't look.
<hallyn_> ok
<hallyn_> so is it more unorthodox to push fixes into jessie then rather than wait for them to get through sid?
<infinity> hallyn_: One generally doesn't upload to testing, except in a freeze.
<infinity> hallyn_: That would be equivalent to an Ubuntu developer uploading to saucy (which we just don't allow, we redirect everything to saucy-proposed, which is our own "unstable")
<infinity> hallyn_: That said, 74 days without migration is impressive, you might want to look at why it breaks libvirt. :P
<hallyn_> gotcha.  so a waste of time is what that was :)
<hallyn_> yeah
<hallyn_> noted for later thsi week
<hallyn_> all right on that note i'm heading to bed - \o
<lifeless> hallyn_: looks good to me
<hallyn_> lifeless: meaning memleak is gone?
<lifeless> yes
<hallyn_> \o/  thanks :)
<lifeless> no growth at all
<hallyn_> maybe i'll just start the sru right now then
<lifeless> hallyn_: actually, it may still be leaking
<lifeless> hallyn_: several hours got a 1M increase.
<lifeless> hallyn_: but massively better...
<dholbach> good morning
<dholbach> didrocks, good work1
<dholbach> !
<didrocks> dholbach: thanks dude ;)
<Cimi> knocte, pong
<knocte> Cimi: hello, I have a couple of bugs where I would love to get your feedback, do you mind looking when you have a chance? the bug numbers are..
<Cimi> bugs of what?
<knocte> Cimi: ubuntu-themes
<knocte> https://bugs.launchpad.net/light-themes/+bug/945430 and https://bugs.launchpad.net/bugs/1211831
<ubottu> Launchpad bug 945430 in ubuntu-themes (Ubuntu) "Lists lack zebra-striping" [Low,Triaged]
<ubottu> Launchpad bug 1211831 in ubuntu-themes (Ubuntu) "properties of state pseudo-classes are not applied successfully " [Undecided,New]
<Cimi> knocte, I'm no longer working on them atm...
<Cimi> that's why nothing changed in the last cycles..,
<knocte> Cimi: by "them" you mean the ubuntu themes? who should I ping then?
<Cimi> no idea, probably me :-)
<Cimi> I should really recruit someone from community to help approving branches
<knocte> Cimi: I see, well you can give me a nickname and I'll try to convince her/him :)
<Cimi> OK :-)
<didrocks> ev: hey, small question on whoopsie. How did you handle the fact that you propose the settings per user and the daemon is a system one? Do you have specific dbus call and it's the daemon writing the settings?
<ev> didrocks: there's a whoopsie-preferences dbus daemon
<didrocks> ah, so a separate dbus daemon
<ev> ja
<didrocks> then you just write to config files?
<ev> mostly
<ev> it will also start/stop whoopsie
<didrocks> interesting
<didrocks> ok, thanks ev
<ev> sure thing
<rbasak> stgraber, hallyn_: around? I can't install mysql-server-5.5 in an lxc container, because it tries to load an apparmor profile. I understand the reason (thanks to http://s3hh.wordpress.com/2012/05/03/lxc-in-precise-and-beyond/) but I wonder if we can make the apparmor profile load in the container a noop in this case?
<rbasak> stokachu: any news on bug 1121874 please? mysql-5.5 is stuck in saucy-proposed - I think because of a dep8 failure because of the same regression.
<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> It's be nice to get saucy unbroken too, which we can do either by fixing this properly, or by reverting your last upload.
<seb128> does anyone knowing how image build/tasks work exactly could help us to figure out what's the issue with cups-filters/ghostscript-cups
<hallyn_> rbasak: A few points,
<seb128> the first one is replacing the second and all rdepends got updated to depends on cups-filter (>= 1.0.36) | ghostscript-cups
<seb128> but that seems to make CD builds unhappy for some reasons
<hallyn_> rbasak: 1. stacked apparmor profiles should be coming soon, which will allow the apparmor profile load to work
<seb128> tkamppeter, ogra_: ^
<hallyn_> rbasak: 2. the solutionright now is supposed to be to run the container unconfined (lxc.aa_profile = unconfined), I guess
<hallyn_> rbasak: 3. it seems reasonable to me to have mysql postinst allow apparmor profile load to fail if it is in a container, but we'd have to ask security team how they felt about it...
<hallyn_> jjohansen: mdeslaur: ^
<jamespage> slangasek, hey - I started looking at merging samba from Debian but noticed the unreleased splits of the init scripts that you had done had been dropped in unstable - was that intentional?
<mdeslaur> jdstrand: ^
<hallyn_> lifeless: well, drat, but i'll run it under valgrind again in a few days and see what i can find
<tkamppeter> cjwatson, hi
<mdeslaur> jdstrand: don't we already have code to deal with packages loading in a container?
<siretart> infinity: I've uploaded libav9 to unstable yesterday, iow, the transition has started now in debian
<rbasak> hallyn_: thanks. I was thinking about something like having the apparmor package arrange for _all_ apparmor loads to fail if they are in containers.
<rbasak> I mean silently noop, not fail.
<rbasak> (or perhaps just a warning to stderr)
<rbasak> Given that we know that lxc security is currently still somewhat limited, I don't think that this would cause a surprise compromise in any real use case.
<hallyn_> rbasak: but also,
<hallyn_> rbasak: given that the host is already protected from mysql by the container profile, the mysql profile isn't as crucial.
<hallyn_> still, stacked profiles ftw :)
<rbasak> Right
<rbasak> Unless the user's expectation is that the inside of the container is protected by the mysql profile too.
<hallyn_> rbasak: that expectation would be wrong as per the server guide :)  They can also expect user namespace protection, that woudl be wrong too.  ("sadly" on both :( )
<hallyn_> lifeless: ok so 'lxc-create -B dir' on a btrfs DOES avoid the subvolume creation for me
<hallyn_> I'm loath to change default behavior, but at the same time we're nto at 1.0 yet, and I'm not sure where we would document this...
<pete-woods> fginther: hi again! I have another project for enabling CI on (https://launchpad.net/indicator-secret-agent) - it should have working support for test and coverage reporting already
<fginther> pete-woods, ack, I can get started on it in a few minutes
<pete-woods> fginther: awesome! :)
<ev> so scan-build is pretty cool
<lifeless> hallyn_: ok, so I'll follow your lead here.
<lifeless> hallyn_: the main feedback I can give you is that while its nice (if you want it) that it happens by default, its very surprising, given that the btrfs docs say subvolumes are == filesystems
<lifeless> hallyn_: you don't expect lxc-create to make a new filesystem by default, after all.
<hallyn_> lifeless: yeah maybe it shoudl be teh default with -B btrfs but not when -B is not set
<hallyn_> meaning, auto-detection of btrfs should perhaps be dropped
<hallyn_> but i'd have to get input from smoser on that at this ponit.  pretty sure last time he said he was ok with that,
<hallyn_> but i'm not sure if by now he's come to depend on it
 * hallyn_ has to go for a drive, bbl
<jdstrand> mdeslaur, hallyn_ , rbasak: /lib/init/apparmor-profile-load already has code to not load in a container
<jdstrand> rbasak: are you using /lib/init/apparmor-profile-load or are you using the new apparmor upstart stanza?
<jdstrand> s/apparmor upstart stanza/upstart apparmor stanza/
<tkamppeter> cjwatson, can you have a look at bug 1212239? It seems to be a problem of how the images get generated.
<ubottu> bug 1212239 in cups-filters (Ubuntu) "cups-filters is reported to have unmet dependencies with the latest saucy server installations" [Undecided,New] https://launchpad.net/bugs/1212239
<smoser> lifeless, other than your understanding of some bit of documentation in a man page for btrfs, do you have some reason as to why creating subvolumes is bad ?
<smoser> hallyn_, i think maybe we want something like '-B ANY', '-B NONE', '-B IF_POSSIBLE', '-B btrfs,lvm,none'
<rbasak> jdstrand: that's odd. The upstart script uses /lib/init/apparmor-profile-load, so I'm not sure why that isn't working. Thanks - I'll look in detail again later.
<jdstrand> rbasak: note that apparmor-profile-load does this:
<jdstrand> [ -x /bin/running-in-container ] && /bin/running-in-container >/dev/null 2>&1 && exit 0
<jdstrand> rbasak: so maybe running-in-container doesn't exist or isn't working right?
<rbasak> jdstrand: I'll check. Also, would dh-apparmor in debian/rules affect anything?
<jdstrand> rbasak: it will put in postinst something to load the profile into the kernel
<jmleddy> cjwatson: hi, we have some more information about the 4k/4k disk issue bug 1065281
<ubottu> bug 1065281 in OEM Priority Project quantal "Installer crashed when trying to partition 4k/4k sector hard disks" [High,In progress] https://launchpad.net/bugs/1065281
<jmleddy> we're finally able to get the machine into a state where it can boot
<rbasak> Wow. That's an impressive bug!
<hallyn_> smoser: -B btrfs,lvm,dir I'm ok with.  The others sound too magical.  (and '-B dir' is -B NONE IIUC)
<smoser> literal 'dir' ?
<hallyn_> yes
<hallyn_> dir for directory
<smoser> hallyn_, that would be fine then.
<smoser> the only thing  i dont like is that i dont want ot have to know a list of what is availalbe.
<smoser> thus 'ANY'
<hallyn_> smoser: if there were more possibilities that would make sense...  the thing about lvm and zfs is that there are more parameters
<smoser> ah. well then the comma delimited falls apart anyway
<hallyn_> we could simply assume that if a vg called lxc or zfs group called lxc exists,
<hallyn_> then it's "available".
<smoser> i would do that.
<hallyn_> anyway I'm goign to opena  bug where we can collect this info and make a decision
<hallyn_> smoser: thanks
<rbasak> jdstrand: turns out that there were two errors, and the postinst dh-apparmor warning fooled me into thinking that it was an apparmor problem.
<smoser> i sweare there was a feature in openstack now for termination protection
<rbasak> jdstrand: dh-apparmor does "apparmor_parser -r -T -W "$APP_PROFILE" || true" which fails with "apparmor_parser: Unable to replace "/usr/sbin/mysqld".  Permission denied; attempted to load a profile while confined?\nWarning failed to create cache: usr.sbin.mysqld" but of course doesn't cause the postinst to fail.
<rbasak> jdstrand: thanks for your help.
<jdstrand> rbasak: ah, good, glad I could help :)
<hallyn_> smoser: btw, not sure if lifeless has responded (doesn't look like it) - creating subvolumes can be bad because rsync -va --one-filesystem will not back up the subvolumes
<hallyn_> smoser: lifeless: bug 1212290 is to track this.
<ubottu> bug 1212290 in lxc (Ubuntu) "update backing store defaults at lxc-create" [Low,Triaged] https://launchpad.net/bugs/1212290
<smoser> hallyn_,
<smoser> it seems daily ppa doesnt have
<smoser> source-precise-amd64
<smoser> /usr/share/lxc/templates/lxc-ubuntu-cloud: line 388: /usr/share/lxc/hooks/ubuntu-cloud-p
<smoser> rep: No such file or directory
<smoser> lxc-create: container creation template for source-precise-amd64 failed
<hallyn_> oh, feh.
<hallyn_> stgraber: can you add that to lxc.install?
<hallyn_> (I figured it did the whole hooks directory)
<smoser> hallyn_, so did i.
<smoser> and i never bothered 'make install'
<smoser> :-(
<smoser> sorry
<hallyn_> hm, it does
<smoser> http://paste.ubuntu.com/5985238/
<hallyn_> smoser: your patch didn't add it to hooks/Makefile.am
<smoser> right
<hallyn_> lemme do that and runa  new build
<smoser> you said "i figured it did the whole hooks directory"
<smoser> i figured it did that by default too. but it has a manual list.
<smoser> our "it" was just different in this reguard.
<hallyn_> :)
<smoser> sorry to hvae been a pain hallyn_
<smoser> hallyn_, i could make that have sane behavior if you are interested.
<hallyn_> smoser: np :)  pushed to git, building pkg now... hopefully won't take too long
<smoser> ie, for hooks to install everything not named 'Makefile.*'
<hallyn_> smoser: the makefile?  sure
<smoser> or maybe everything executable
<hallyn_> that'd probably be best
<smoser> hallyn_, it seems non-obvious to me how i'd do it without a grep essentially
<smoser> wildcard in gnu make does not allow for exclude
<hallyn_> can you do some $(filter) crap?
<hallyn_> (just thinking however debian/rules often detects arch)
<hallyn_> smoser: eh, it's probably not worth it.  it's not something that will cause regressions
<smoser> hallyn_, fwiw, this works
<smoser> http://paste.ubuntu.com/5985282/
<smoser> but would include other stuff in that dir
<hallyn_> smoser: looks good to me.  more stuff shouldn't be added that isn't meant to be shipped, but if it is we can just make a $exclude variable including makefile*
<smoser> hallyn_, i'dm be more concerned about stuff in a local checkout
<smoser> getting installed accidently
<smoser> ie, foo.bk1
<hallyn_> heh, you're not supposed to do that, you're supposed to buidl a package :)
<hallyn_> ok, let's leave it as is
<pete-woods> didrocks: good afternoon! I have another project I'd like to do releases of (https://launchpad.net/indicator-secret-agent) - it already has jenkins autolanding activated
<didrocks> cyphermox: I think that one will be for you ^
<didrocks> (please add to the spreadsheet)
<didrocks> pete-woods: any integration tests?
<pete-woods> didrocks: it's not integrated with the shell yet (I'm waiting on the new system dialogue stuff) - but it does have 97% unit test coverage
<didrocks> great ;)
<pete-woods> didrocks: as soon as there is actually some integration happening, I'd be more than happy to write integration tests, however it is I'm supposed to do that (autopilot?)
<cyphermox> yeah
<cyphermox> alright
<infinity> smoser: Your cloud-init SRU has a patch in there (future_utils.patch) with no reference or explanation in the changelog.
<infinity> smoser: Rejecting on that basis, please either reference it so I know what it is, or drop it because it's cruft. :P
<smoser> boo.
<smoser> its just stuff from cloudinit/utils.py in newer versions of cloud-init.
<infinity> smoser: Added to make the azure backport easier, perhaps?
<smoser> yes.
<infinity> smoser: I don't like guessing. :P
<infinity> smoser: But okay, I can let that slide.
<infinity> smoser: It's at least more readable than the azure patch...
<smoser> i'm ok to re-upload if you'll look quickly
<smoser> i kind of a gree that the patch there should have a dep-3 header
<infinity> smoser: I'm looking at it all this afternoon/evening, after some of my walinuxagent concerns are addressed too.
<smoser> so you want to just NAK that and i'll re-upload ?
<infinity> smoser: Rejected.
<ogra_> infinity, did you notice the image build failures today ?
<infinity> ogra_: I'm off sick (can't you tell from my inactivity on IRC), so no. :P
<ogra_> seems we have an issue with the old "tasks resolve deps differently to metapackages" ....
<ogra_> haha, ok, i wont bother you
<ogra_> its a cjwatson thing anyway i think
<infinity> Erm, wait, which image(s) is this that you're talking about?
<infinity> ogra_: Oh, the cups thing?
<ogra_> infinity, yeah
<ogra_> bug 1212239
<ubottu> bug 1212239 in cups-filters (Ubuntu) "cups-filters is reported to have unmet dependencies with the latest saucy server installations" [Undecided,New] https://launchpad.net/bugs/1212239
<smoser> infinity, so i just upload again with same version, right?
<infinity> smoser: Yep.
<ogra_> seems the deps are fine, but the task resolves them backwards
<ogra_> (the "or" dep specifically)
<ogra_> i dont think we ever found a proper solution for that
<smoser> is 'dch -D some-thing --release' broken for anyone else?
<infinity> ogra_: It's because it recommends and conflicts.
<ogra_> oh
<infinity> ogra_: At least, that's my best guess.  And it's a bug either way.
<ogra_> yeah
 * infinity fixes.
<esing> hi
<esing> How do I install gummiboot on ubuntu
<infinity> ogra_: Uploaded.  Will test in a chroot to make sure this fixes it once it's built.
 * ogra_ hugs infinity 
<ogra_> (dont infect me though)
<smoser> infinity, i uploaded. http://paste.ubuntu.com/5986081/ is diff from last upload.
<infinity> smoser: Shiny, thanks.  Once I get utlemming's fixed walinuxthingee, I'll do them together.
<infinity> ogra_: Right, this should definitely fix it.  The problem was that cups-filters Recommending ghostscript-cups landed the ghostscript-cups package in the ubuntu-desktop task.  So, when you went to install the task, it exploded.
<infinity> ogra_: Can't test for sure until it's all migrated to the release pocket and gs-cups falls out of the task, but logically it makes sense.
<ogra_> yeah, it definitely does ...
<infinity> Bah, and same fix needs to be applied to cups itself.
<infinity> Aaaand, the cups testsuite fails now.  Awesome.
<infinity> tkamppeter: HALP.  CUPS sucks.
<ogra_> hahaha
<infinity> FAIL: 35 error messages, expected 33.
<infinity> So informative.
<tkamppeter> infinity, it worked for me last time, what did you change?
<infinity> tkamppeter: Nothing in the code.
<infinity> tkamppeter: https://launchpad.net/ubuntu/+source/cups/1.6.3-1ubuntu1
<tkamppeter> infinity, and why are you rebuilding CUPS?
<infinity> See above.
<infinity> tkamppeter: As it turns out, though, my motivation for uploading doesn't change whether or not the testsuite works. :P
<infinity> tkamppeter: Anyhow, image builds will continue to be broken until a cups that doesn't Recommend ghostscript-cups actually manages to build.  I leave the testsuite breakage to you, since I suspect you know it much better than I do.
<infinity> E [14/Aug/2013:13:50:34.039455 -0600] Filter "gstoraster" not found.
<infinity> E [14/Aug/2013:13:50:34.039476 -0600] Filter "gstoraster" not found.
<infinity> I'm assuming those are the lines to blame..
<tkamppeter> infinity, I see, CUPS needs to build-depend on cups-filters now where Ghostscript-cups has gone away ...
<infinity> tkamppeter: It does.
<infinity> tkamppeter: I have it installed here, make check still fails with that.
<infinity> tkamppeter: http://paste.ubuntu.com/5986315/
<infinity> tkamppeter: So, something more weird is going on...
<tkamppeter> infinity, the test suite of CUPS is really broken, it should not depend on cups-filters nor on ghostscript (which is needed by gstoraster which the test suite tries to call).
<infinity> tkamppeter: Sure, but both cups-filters and ghostscript *are* build-deps, and are installed.
<infinity> tkamppeter: And it's the server startup that's whining about gstoraster being missing.
<infinity> Well, "missing".  It's obviously there. :/
<tkamppeter> infinity, CUPS does a really bad thing, it links the filters contained in cups-filters one by one into the test filter directory, meaning that CUPS' test suite needs to be changed with every change of cups-filters making the "make check" of CUPS only work with a few versions of cups-filters.
<infinity> tkamppeter: Ah, I *just* got there myself and was about to upload a fix. :)
<tkamppeter> infinity, debian/patches/tests-use-cupsfilters.patch needs to get fixed, adding a link for gstoraster.
<infinity> tkamppeter: Already one it.
<infinity> s/one/on/
<infinity> tkamppeter: Test building, thanks for the extra set of eyes on that one.
<tkamppeter> infinity, did the package build for you now?
<infinity> tkamppeter: Oh, erk.  There's also the IPP compliance tests failing.  Fun.
<infinity> tkamppeter: http://lucifer.0c3.net/~adconrad/cups-str-1.6-2013-08-14-adconrad.html
<brendand> unity isn't showing even if i run it from a terminal
<brendand> what could be missing?
<infinity> tkamppeter: Yeah, those ipp failures have me a little bit stumped.  Possibly a race between creating fake jobs and looking for them?
<brendand> sorry to ask again, i had to reboot so may have missed a response. i've upgraded to saucy and unity won't seem to start. unity_support_test returns 0 though
<slangasek> jamespage: "dropped in unstable"> how do you mean, "dropped"?  It hasn't been landed yet at all - but that's something I'm working through this week at DebConf as part of the upstarting of the package
<slangasek> jamespage: "dropped in unstable"> how do you mean, "dropped"?  It hasn't been landed yet at all - but that's something I'm working through this week at DebConf as part of the upstarting of the package
<tkamppeter> infinity, I have done test builds of CUPS 1.6.3 and 1.7rc1 on my Saucy machine now and I get exactly the same IPP failures. Seems to be that something changed in Saucy which breaks the CUPS tests.
<infinity> tkamppeter: Alright, I'm uploading an ugly hack for now to ignore the IPP failures, so this can build and images can be buildable again, but obviously this needs looking into.
<tkamppeter> infinity, thank you very much, and sorry for the inconvenience. The test suite of CUPS is really a problem.
<blitzkrieg3> ay
#ubuntu-devel 2013-08-15
<dholbach> good morning
<xnox> rbasak: git-dpm - maintains patches as git commits, with rebasing/merging on to new versions.
<xnox> superm1: slangasek: this is interesting https://blueprints.launchpad.net/ubuntu/+spec/foundations-irst-support =)
<xnox> mpt: https://blueprints.launchpad.net/ubuntu/+spec/foundations-irst-support
<mpt> xnox, let me know when you need something for it. :-)
<xnox> mpt: i'll hunt down an SSD drive, cause my machine should be able to have this working. 13.10 will have the right kernel, but i'm not sure about the installer bits & user-space toggles. Something for 14.04 I think.
<jtaylor> why is skimage not showing up in jenkins? I though of the XS-... this time :(
<darkxst> I dropped the -dbg packages from webkit (on our ppa) but now the dbgsym's are broken http://paste.ubuntu.com/5988275/
<darkxst> anyone know about this stuff or do I need to wait for pitti to get back?
<rbasak> xnox: IIRC, it assumes that your branch is the Debian packaging branch though, rather than being able to import that bit :-/
<xnox> rbasak: well, you can start at any time. E.g. import a dsc.
<rbasak> xnox: right, but for Ubuntu you need to continuously rebase. I want to use tools like git-rerere to make that easier. Anyway, I do need to look into it more.
<rbasak> Also Ubuntu holds the archive as the pristine source for most packages, so any extra information would be lost.
<xnox> rbasak: that's how git-dpm works. it's git rebased based workflow.
<xnox> rbasak: all patches are commits, and those are rebased onto new releases.
<rbasak> I think it'll screw up if some other non-git-dpm-using Ubuntu developer does an intermediate upload.
<xnox> rbasak: =/ hm, yeah, i guess one would need to do imports.
<tkamppeter> I have uploaded ghostscript 9.06rc1 to saucy-proposed and it did not pass on to saucy. As I chose a bad version number (9.08~rc1~dfsg is considered newer than 9.08~dfsg) can this package get removed and I upload the final instead?
<henrix> @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: henrix
<mlankhorst> hm why is xorg-server still in proposed?
<tkamppeter> mlankhorst, I have installed the new package now and at least in standard X mode, without MIR (MIR not yet tested) it seems to work.
<tkamppeter> mlankhorst, now I am in MIR mode and it seems to work, too. Thank you very much.
<rbasak> stokachu: any news on bug 1121874 please? Or do you think we should just revert  5.5.32-0ubuntu2 in the meantime?
<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
<om26er> Who can I get  to review the packaging of a source to make it eligible for daily release ?
<henrix> @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:
* KevinJay 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:
<Laney> om26er: try Mirv
<stokachu> rbasak: for whatever reason the unittests wont pass when i attempt to build within sbuild
<stokachu> rbasak: might as well revert for now until i can get this built and run my tests for it
<rbasak> stokachu: thanks. Let me see if a reverted sbuild passes for me. No point uploading if that fails too.
<stokachu> rbasak: ok, not all tests fail just about 85 out of the million and 1 that gets run
<rbasak> Have we diverged on flash-kernel again? I thought the idea was to keep them synced this time?
<ogra_> with the panda gone in 14.04 you should be able to drop all changes
<ogra_> (apart from highbank i guess)
<mapreri> does someone know if pitti is on holiday or is simply afk (with the computer turned off)?
<twoface88> looking for mentor in ubuntu development. anyone needs help with their project ?
<ogra_> mapreri, he might be at debconf
<mapreri> ogra_: Uh, right! (what luck....)
<ogra_> (i'm not sure if he is actually there ... but many of us are this week and it seems likely)
<jono> is anyone else in Saucy constantly finding Firefox to hang for periods of time?
<ogra_> who uses firefox anyway ...
 * mdeslaur refrains from browser wars trolling
<ogra_> heh
 * mapreri loves browsers war!
<mdeslaur> is this "browser" thing an app I can install on my phone?
<ChogyDan> mdeslaur: only with 100 in game currency
<asac> jono: ffox is pretty stable as my default browser ... though, i dont use it for google services anymore as those seem to intentionally provide a sucky ffox experience while to market their chrome browser with a banner (old browser, why not use chrome)
<jono> asac, it is terrible for me right now
<asac> jono: didnt restart it for a few days... is that a very recent update?
<ogra_> FF is completely unusable on ARM
<ogra_> and since i spend most of my worktime on the chromebook ...
<jono> asac, been like this for a few weeks
<asac> jono: back in ffox maintainer days i would have asked you to check if disabling all your extensions will improve the situation as a first measure
<asac> jono: i assume you tried that?
<jono> asac, will try
<infinity> jono: If your browser's uptime is high, I'd also just try killing it, restarting, and restoring your session.
<jcastro> FF has been solid on saucy here
<infinity> jono: Plus, there was an update in saucy recently.  So, knowing that last week's browser was buggy isn't all that handy.
<jono> infinity, well this weeks browser is buggy too
<jono> :-)
<infinity> (I'm with jcastro though, it's been solid and performant for me)
<smoser> has 'nosetests' recently gotten a couple orders of magnitude slower for people?
<omer> hi, I'm trying to patch a package (first time), and when I run bzr builddeb, it fails with the error "Reversed (or previously applied) patch detected
<omer> for file debian/rules
<omer> which I changed
<omer> and then I get "fuzz is not allowed when applying patches"
<omer> any ideas why that could be?
<infinity> siretart: Are you ready to make the libav transition happen in Ubuntu?  FF is approaching quickly, and I'd rather not put it off another release cycle.
<om26er> mterry, are you online ?
<mterry> om26er, hi
<om26er> mterry, hey, would you be able to review ubuntu-keyboard packaging for it to be released daily ?
<mterry> om26er, sure.   is that the project name?
<om26er> mterry, yes https://launchpad.net/ubuntu-keyboard
<om26er> mterry, there is also: https://code.launchpad.net/~ubuntu-sdk-team/qtorganizer5-eds/trunk
<omer> If this is the wrong place to ask a question, should I post in the forums?
<sarnold> omer: you may need to include more details, here or elsewhere. which package? what packaging format? are you confident bzr builddeb is supposed to do anything useful wit hthe package in question? etc..
<omer> sarnold: I was just trying to follow the guide here: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<omer> I used edit-patch to create a patch
<omer> and then from what I understand I need to use bzr builddeb to create the dsc file
<omer> the package was libraw
<omer> I'm trying to compile it with some features enabled
<mterry> om26er, what is supposed to be in the tests package?  Doesn't look like anything gets installed into it
<mterry> (autopilot tests?)
<om26er> mterry, yes there will autopilot tests, they are not yet
<om26er> someone is working on it already
<mterry> om26er, k
<sarnold> omer: I think I'd try two things: (a) try "quilt push -a" before running 'edit-patch' (b) try "quilt push -a" after running edit-patch.  :)
<omer> okay, thanks!
<mterry> om26er, what about the various executables like word-candidates and language-layout-loading?  Are those meant to be installed (they are not currently)
<om26er> mterry, I am not sure about that, I think how it is, is fine :)
<mterry> om26er, OK
<janimo> stgraber, hi do you know  why lxc-create of a saucy armhf container on an amd64 host would fail while a raring one is created?
<janimo> stgraber, , I get Package iproute:amd64 is not available, but is referred to by another package
<sarnold> janimo: iproute was replaced by iproute2 somewhere along the way..
<janimo> sarnold, but is this something lxc-create/debootstrap needs to learn explicitly?
<sarnold> janimo: probably a bug should be filed against the package that refers to iproute in saucy, so it can be fixed
<stgraber> janimo: oops, yeah, we hardcode that in lxc, I'll have to fix this
<stgraber> janimo: please file a bug against lxc
<stgraber> janimo: you can easily fix it locally in /usr/share/lxc/templates/lxc-ubuntu
<janimo> stgraber, ok I will
<janimo> stgraber, but the fact that iproute was removed from saucy (apparently) is related though?
<janimo> https://launchpad.net/ubuntu/+source/iproute/+publishinghistory
<stgraber> janimo: yep, iproute2 is the new iproute
<janimo> stgraber, so all dependencies need to be changed or should that package Provide iproute?
<stgraber> janimo: I fixed all the rdepends before I demoted iproute to universe, so at least in main, everything now uses iproute2
<stgraber> I just missed lxc because it wasn't a depend but hardcoded in a script
<janimo> stgraber, thanks for the pointer it worked after changing the template
<janimo> stgraber, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1212820
<ubottu> Launchpad bug 1212820 in lxc (Ubuntu) "lxc-create of an armhf container fails in saucy" [Undecided,New]
<janimo> stgraber, I had to remove isc-dhcp-client as well from the template
#ubuntu-devel 2013-08-16
<ikepanhc> @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: ikepanhc
<dholbach> good morning
<Laney> jamespage: Can I ask you about golang in saucy? ;-)
<jamespage> Laney, yep
<Laney> jamespage: OK, one second...
<Laney> jamespage: Right then, compile and run this please: http://paste.ubuntu.com/5992017/
<Laney> it's broken on saucy but if I rebuild the Debian package without the Ubuntu changes then it works
<jamespage> Laney, oh - you'll love this one
<jamespage> Laney, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719611
<ubottu> Debian bug 719611 in golang "golang: os/user not usable without cgo" [Normal,Open]
<Laney> yes I found something like this while googling
<jamespage> and https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1211749
<ubottu> Launchpad bug 1211749 in golang (Ubuntu Saucy) "Packge os/users incorrectly built on amd64 arch" [Critical,Triaged]
<jamespage> Laney, when you build it locally I suspect you are building on amd64 right?
<Laney> so it's some buildd problem
<Laney> yes
<jamespage> Laney, this is due to the cross-compilation stuff that got introduced in saucy
<Laney> oh they're arch:all packages
<Laney> aaaaaaaaaaa
<jamespage> in launchpad the i386 build produces the amd64 cross compile package
<jamespage> but its broken because if can't cross compile the CGO bits
<jamespage> if you tried that on i386 it would work
<Laney> so I guess the debian maintainer built on amd64 hence it works there
<jamespage> Laney, maybe
<jamespage> Laney, its really awkward to fix without breaking the cross-compile feature as well
<jamespage> as you really want os/user built on the native arch build
<jamespage> but you might also want to use that for cross compile....
<jamespage> bah
<rbasak> stokachu: http://pastebin.ubuntu.com/5992058/ - is this what you're seeing, or do you see more test failures? I think it might be an artefact of the schroot, so I'll try again inside LXC instead.
<rbasak> ^^ was with http://pastebin.ubuntu.com/5992058/
<rbasak> err, 5.5.31-0ubuntu1. Wrong paste buffer.
<Laney> jamespage: yeah :/
<Noskcaj> jodh, Can you merge libnih? It's got no conflicts, just needs merging
<Laney> http://162.213.35.4:28080/search?weighted=1&q="Hello,+world"
<Laney> it's alive! (sort of)
<sil2100> ikepanhc: hi! Would you be able to sponsor a new package into universe for us? ;) https://bugs.launchpad.net/ubuntu/+bug/1212993
<ubottu> Launchpad bug 1212993 in Ubuntu "[needs-packaging] Mediascanner" [Undecided,New]
<sil2100> ikepanhc: it's something that will be used by a new unity scope and music app
<ikepanhc> sil2100: hmm, I am not MOTU. let me talk to someone and see if he can do that
<sil2100> ikepanhc: thanks ;)
<ikepanhc> no problem
<sil2100> ikepanhc: I already poked around for some people in #ubuntu-motu, but the usual people that do this for us are away today
<sil2100> ikepanhc: while we want to get things in as soon as possible since FF is near
<ikepanhc> yes, aug-29th
<brendand> why is it so hard to find decent documentation for debian rules files?
<rbasak> brendand: what are you after? Debian policy defines the targets, and then the documentation for the contents usually depends on the build system and/or helper you're using (eg. debhelper).
<brendand> rbasak, well it's a qt based project - so i guess it's supported by debhelper?
<rbasak> brendand: you're trying to write a new one?
<brendand> rbasak, what do you mean?
<rbasak> brendand: I don't understand what you're looking for.
<brendand> rbasak, i'm trying to write a rules file which builds my project
<ikepanhc> sil2100: freeflying told me if you have a package ready he can ack for you. please contact him at #ubuntu-motu
<brendand> rbasak, i guess i should read debhelper documentation
<rbasak> brendand: ah, OK. I'm not sure about qt specifically, but in general debhelper does the right thing automatically, so you might start off with a minimal debhelper-based rules file and see if that works. There might be some qt-specific runes you need, but they should be minimal. I'd look at an existing package to see.
<brendand> rbasak, i think the main issue is that my .pro file is not at the root of the source so i may need to override something
<rbasak> brendand: https://wiki.debian.org/IntroDebianPackaging#Step_3:_Add_the_Debian_packaging_files and scroll down a bit to see what a minimal debhelper rules file looks like.
<ikepanhc> @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:
<sil2100> ikepanhc: thanks! Will do :)
<ikepanhc> :D
<caribou> 5
<sil2100> tseliot: ah ha! Hi Alberto!
<sil2100> tseliot: can I 'use' you for some small task ;)?
<sil2100> tseliot: since you see, we need a core-dev to ACK packaging changes before we can daily-release it into Ubuntu, and we have one here
<sil2100> tseliot: it's a small packaging change but still, someone needs to say if the packaging changes aren't harmful or anything
<sil2100> tseliot: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/WebApps/job/cu2d-webapp-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-webapps-qml_0.1+13.10.20130816.1-0ubuntu1.diff <- there's not much here besides 2 lines
<sil2100> tseliot: (diff only shows packaging changes)
<ogra_> sil2100, no mention of the dependency change in the changelog ...
<ogra_> apart from that it looks fine
<sil2100> ogra_: yeah, sometimes those get missed, as the changelog is being updated automatically - is that a blocker, or can we publish anyway?
<ogra_> sil2100, well, can you make sure this happens in the future ... if someone greps the changelog for such stuff when debugging he should be able to find anything
<ogra_> beyond that, happy upload
<sil2100> ogra_: we'll let upstreams know that they should include info about such things in the commit messages so that it happens less frequently :)
<mdeslaur> @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: mdeslaur
<ogra_> sil2100, great
<tseliot> sil2100: +1 from me too
<sil2100> tseliot, ogra_: thanks guys
<ogra_> np
<caribou> mdeslaur: I need your patchpilot attention on a couple of SRU (one that you've already looked at)
<mdeslaur> caribou: sure, which ones?
<caribou> mdeslaur: LP: #1005901 is the one you commented on
<ubottu> Launchpad bug 1005901 in duplicity (Ubuntu Precise) "cannot change temp dir" [Undecided,In progress] https://launchpad.net/bugs/1005901
<mdeslaur> caribou: I just uploaded that one literally 30 seconds ago :)
<caribou> mdeslaur: :D
<caribou> mdeslaur: the other one is LP: #816153
<ubottu> Launchpad bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,In progress] https://launchpad.net/bugs/816153
<caribou> infinity and cjwatson have both helped me with this one a while ago
<mdeslaur> caribou: ok, let me take a look
<caribou> mdeslaur: for this last one, the proper way would have been to change configure.ac, but the debian packaging is badly broken
<caribou> mdeslaur: so I followed cjwatson's advice
<sil2100> Can any core-dev give us a green light for a daily-release packaging change?
<sil2100> https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.0.11+13.10.20130816.2-0ubuntu1.diff <-
<sil2100> We need to release this ASAP
<sil2100> Thanks in advance!
<sil2100> mdeslaur: maybe you could help? :)
<sil2100> Scratch that, ogra_ performed the ACK
<mdeslaur> sil2100: cool
<mdeslaur> caribou: do you have a few minutes to fix a few small details in your dante debdiffs?
<caribou> mdeslaur: sure
<roaksoax> xnox: howdy!! so I've been trying to re-enable clvm (for corosync only) against the newer dlm (which is still in universe), however, it FTBFS. The funny thing is that If I configure it locally, it does not fail: http://paste.ubuntu.com/5992776/ http://pastebin.ubuntu.com/5992774/
<mdeslaur> caribou: ok, commented in bug
<caribou> mdeslaur: ok looking
<caribou> mdeslaur: about point  #4, I had noticed the case on my system as well, but concluded that it would not be an issue in a build environment
<mdeslaur> caribou: ok, can you please add a not to that effect in the patch header?
<mdeslaur> note
<caribou> mdeslaur: ok, will do. I'll fix the other minor issues
<mdeslaur> caribou: cool, let me know when you're done, and I'll upload them
<arges> is there a 'best-practice' way to use something like a control.in file to generate a control file?  I've seen many packages just use sed, but am wondering if there is a better way. thanks
<jtaylor> having a control.in is not considered best practice, why do you need it?
<jtaylor> cdbs provides some tools to use it I think
<caribou> mdeslaur: just uploaded new debdiffs to the dante bug
<mdeslaur> caribou: thanks
<caribou> mdeslaur: as discussed, I didn't change the logic for point #4 but added a note to the patch header
<mdeslaur> caribou: ok
<stokachu> rbasak: thats exactly what i saw
<stokachu> rbasak: re mysql build
<tseliot> slangasek: are you around?
<mdeslaur> caribou: uploaded dante to saucy and proposed. thanks!
<caribou> mdeslaur: saucy & precise ? np
<caribou> mdeslaur: thank you
<mdeslaur> whoops, yes, precise
<smoser> slangasek, ping.
<smoser> jodh, maybe.
<smoser> lxc has clone via overlayfs now (example at https://gist.github.com/smoser/6199772).
<smoser> thats *really* nice. except for the whole inotify/reload-configuration thing.
<smoser> for upstart in > saucy, its sufficient to write a job and then run 'initctl reload-configuration'. that sucks, but oh well.
<smoser> but in precise, with overlayfs below the container, 'apt-get install some-service' results in 'some-service' not running by default as you'd expect (because it puts the job in /etc/init, runs 'start job', but upstart says "what job?")
<smoser> i'm looking for a generic way to solve the 'apt-get install' path.
<jodh> smoser: I'd rather not put hacks into Upstart to work around kernel bugs. However, maybe an option is to tweak invoke-rc.d to detect if /etc/init is on overlayfs and force a reload.
<smoser> jodh, right. thats the kind of thing i was thinking.
<smoser> diverting 'start' and doing it there might also be an option.
<hallyn_> jodh: is un-implemented inotify in an fs really a "kernel bug" though?
<smoser> kernel , upstart, FIGHT!
<hallyn_> i'd deposit a quarter to see that
<jodh> hallyn_: I thought the problem was that it (partially?) claims to support inotify but actually lies?
<hallyn_> jodh: oh, if so then that's a bug :)  how does it claim that though?  inotify syscalls succeeding?
<smoser> jodh, does upstart do anything if it was told the truth and there was no support ?
<smoser> hallyn_, its possible that the intofiy *does* work.
<smoser> and goes through to someone monitoring the underlay
<smoser> i dont know.
<sil2100> kenvandine: ping!
<hallyn_> smoser: me neither :)
<hallyn_> and in either case i wouldn't want hacks saying "if this is overlayfs" in upstart - rather just "if /etc doesn't support inotify"
<kenvandine> sil2100, pong
<sil2100> kenvandine: do you know if maybe you could upload my new package to the archive ;) ?
<sil2100> kenvandine: since dholbach seems to be AFK
<sil2100> kenvandine: https://bugs.launchpad.net/ubuntu/+bug/1212993
<ubottu> Launchpad bug 1212993 in Ubuntu "[needs-packaging] Mediascanner" [Undecided,New]
<kenvandine> sure
<mdeslaur> @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:
<sil2100> kenvandine: thank you! :D
<sil2100> kenvandine: I was trying to release it for like 7 hours now :D
<sil2100> dholbach found some small issues we fixed, there's also some hardening question there, but upstream will deal with that in next versions if there indeed is a problem
<kenvandine> sil2100, uploaded
<sil2100> kenvandine: WOHA
<sil2100> :D
<sil2100> kenvandine: I think I owe you another beer!
<kenvandine> :)
 * kenvandine likes beer!
<rickspencer3> e
<asomething> anyone around that might be able to help me figure out why a package isn't migrating?
<asomething> update_excuses says the autopkgtest for bzr is marked failing, but the most recent run on jenkins is successful
<asomething> ^^ maybe cjwatson ?
<infinity> asomething: The root of the problem needs looking at, but I've nudged bzr to migrate.
<asomething> infinity, thanks. I just wasn't sure if I was missing something. update_output.txt didn't mention bzr at all
<infinity> asomething: Right, it won't be in output if it fails in the excuses stage.
#ubuntu-devel 2013-08-17
<ffio> are there any guide reagrding ubuntu packaging guide or some source that will be helpful to start from ?
<sladen> ffio: http://developer.ubuntu.com/publish/my-apps-packages/  Ubuntu uses the Debian packaging standards
<sladen> ffio: http://developer.ubuntu.com/2012/02/how-to-prepare-a-compiled-application-for-ubuntu-software-center/
<sladen> ffio: -> #ubuntu-motu is a good place to ask
<ffio> sladen: thanks you so much :)
#ubuntu-devel 2013-08-18
<Riddell> cor ubuntu on bbc news front page, well done
<JackYu> great! http://www.bbc.co.uk/news/business-23402994
<xnox> smoser: hallyn_: it does make sense for upstart-file-bridge to ship a job that watches "/" and if "/etc" is created execute initctl reload-configuration. As that job will never be triggered on normal machines, but will be triggered on "overlayfs is bodging inode under our feet"
<xnox> or hint, you can drop one yourself in the image =)
<xnox> but you should do that on the base-dir, not in the overlay dif.
<xnox> s/dif/dir/
<robert_ancell> mterry, around?
<mterry> robert_ancell, yeah, hi
<robert_ancell> mterry, hey, reading bug 1212408. I don't think it can be done without what you proposed in http://lists.freedesktop.org/archives/xdg/2011-July/012004.html
<ubottu> bug 1212408 in lightdm (Ubuntu) "lightdm needs to set $XDG_CURRENT_DESKTOP" [Undecided,New] https://launchpad.net/bugs/1212408
<robert_ancell> Do you know about the bug / did your proposal go anywhere?
<mterry> robert_ancell, never went anywhere.  I recall particular resistance from GNOME people.  I got the impression they weren't concerned with the problem space
<mterry> robert_ancell, I think historically we've patched gnome-session and its .desktop files to add a new key to specify the desktop
<mterry> robert_ancell, I think the request is to move this up the stack into lightdm, rather than gnome-session
<mterry> or down the stack anyway
<mterry> robert_ancell, because now user-upstart is parallel to gnome-session I guess
<robert_ancell> mterry, ah, I didn't see them in the xsession files, right it would have to be inside gnome-session
<robert_ancell> yes
<robert_ancell> request makes sense, just LightDM can't work out the names (http://standards.freedesktop.org/menu-spec/latest/apb.html) unless they're in the xsession file
<mterry> robert_ancell, yeah, I think that's still a sensible place for them.  But for now, we'd maybe want to prefix X-Ubuntu- or something
<robert_ancell> yep, agreed
<robert_ancell> X-LightDM for now I guess
<mterry> robert_ancell, hey, are you still interested in unity8-greeter-on-the-desktop?  I dropped that for now (thought you wanted it for some demo purpose), but I wanted to double check
<robert_ancell> mterry, not for demo purposes, though I'd like to check it works for phone purposes
<robert_ancell> thanks
<mterry> robert_ancell, I have branches to get most of the way on the phone, but got blocked by u-s-c not really being able to switch between greeter/user-sessions.  Seems like Mir doesn't register them as sessions (racarr suggested that the lack of the whole nested Mir feature was the problem)
<robert_ancell> mterry, right, they can't be mir servers, but we can test the greeter as a mir client with a u7 session
<mterry> robert_ancell, oh I see.  You're saying you wanted it on the desktop, as proof of concept for phone?
<robert_ancell> I was hoping we could test on desktop as that might be easier. But it seem the dependencies make too many phone assumptions.
<robert_ancell> yes
<mterry> robert_ancell, yeah, it seems that the unity8 engine that drives unity8-greeter needs qtubuntu stuff that isn't fully there for the desktop
<robert_ancell> right. That was my conclusion too
<robert_ancell> mterry, though I talked to ricmm and he said he should be unblocked to land qtubuntu mir stuff into the archive now
<robert_ancell> mterry, would you be able to review the MP when I add the XDG_CURRENT_DESKTOP support? Shouldn't be too complex
<mterry> robert_ancell, OK.  Just wanted to make sure you weren't waiting on a deliverable from me
<mterry> I mean, you'd still like it, but it's not blocking you
<mterry> robert_ancell, OK
<robert_ancell> mterry, not blocked
<robert_ancell> mterry, do I have anything specific blocking you?
<mterry> robert_ancell, no...?  let me review
<robert_ancell> there's no need to review ;)
<mterry> robert_ancell, naw
<robert_ancell> mterry, you're in boston right?
<mterry> robert_ancell, yeah
<robert_ancell> mterry, we're (Mir team+QA) in town (Lexington) the week of the 16th Sept - should catch up!
<mterry> robert_ancell, oh nice!
<mterry> robert_ancell, yeah
#ubuntu-devel 2014-08-11
<asac> stgraber: cjwatson: i dont think i asked for two layers of feeding to stable. lets chat tomorrow about it; if you still have quotes from back then, it might help me rememeber what i thought/meant that got interpreted like this :)
<stgraber> asac: the two layers is what you asked to setup for the current implementation (utopic-proposed gets manually copied to utopic which then gets manually copied to stable) as you wanted more control as to what gets into stable than just have stable be a straight alias for utopic or whatever our stable series is
<asac> stgraber: ok, i sense there might be confusion again as i am thinking about devel and stable only... and not really utopicetc.
<asac> stgraber: with rtm feeding into stable-proposed soon, i guess that part of straight alias is void anyway ?
<asac> e.g. utopic feeds to devel-proposed/devel and ubuntu-rtm/utopic feeds into stable-proposed/stable?
 * asac thinks it would be easier to refer to uptopic as our current devel archive series (which kind of already exists as an alias for upload and apt, no?)
<asac> and ubnutu-rtm/utopic referring to our "stable" archive series for touch in that senes
<asac> assuming we have branched ubuntu-rtm i would think that ubuntu/utopic -> devel-proposed ... and ubuntu-rtm/utopic -> stable-proposed
<asac> anyway, lets sync tomorrow when colin is awake too
 * asac waves; be back in a few hours
<constantine> Hey guys. I was just curious: do Canonical use -flto option to compile packages? It looks like good optimization, but looks like nobody uses it for unknown reasons.
<constantine> Probably nobody uses it cuz -flto option(stands for "link time optimization") relatively fresh. If this is the reason, then I hope I give good hint, how to make Ubuntu a bit faster ;)
<dholbach> good morning
<dholbach> Noskcaj, any luck with 1346056?
<LocutusOfBorg1> ScottK, you there?
<LocutusOfBorg1> sorry but I didn't like too much your upload https://launchpad.net/ubuntu/+source/wxpython3.0/3.0.0.0+dfsg-2ubuntu1
<LocutusOfBorg1> you fixed a bug in the _wrong_ place
<LocutusOfBorg1> the build failure is a fault in wxwidgets, and it has been spotted because ubuntu has a _bad_ cairo version
<LocutusOfBorg1> so the right fix is:
<LocutusOfBorg1> fix 1353362
<LocutusOfBorg1> wait for wxwidgets3.0 to be uploaded in debian (hint: the fix is there http://anonscm.debian.org/cgit/freewx/wx.git/commit/?h=wx3.0-debian&id=7bbc39c4018cee0fa2e021e58ea79bd5de241785 )
<LocutusOfBorg1> and then rebuild wxpython.
<tvoss> seb128, good morning. Not sure you are the right person to ask, but I was looking at the dbus spec and stumbled across GetConnectionCredentials, which would be super useful to have. However, it's only supported from ver 1.7 onwards. Do you know if we have plans to update to that version?
<LocutusOfBorg1> this is a bug in _every_ package using wxwidgets, not just wxpython, so please next time fix it properly ;) many thanks
<seb128> tvoss, see https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1320422
<ubottu> Launchpad bug 1320422 in dbus (Ubuntu) "Please merge dbus 1.8.2-1 (main) from Debian testing (main)" [Low,Incomplete]
<seb128> tvoss, tyhicks is/was working on it
<tvoss> seb128, ack and thx, will follow up with him then
<seb128> thanks
<Noskcaj> dholbach, Just got back into town then. I made a crappy patch to remove turbogears2, but i'm waiting for a responce from the debian zope team about transaction before i do anything
<dholbach> Noskcaj, ok cool - maybe you can follow up on the bug report to just mention where things stand
<Noskcaj> ok
<cjwatson> asac: the series in the ubuntu-rtm distribution is called 14.09 rather than utopic - since RTM isn't tied to the Ubuntu release cycle I didn't think it made sense to tie it to Ubuntu release codenames
<cjwatson> asac: stgraber set it up for me on Friday as ubuntu-touch/ubuntu-rtm/14.09-proposed and ubuntu-touch/ubuntu-rtm/14.09, on the system-image side; I think that makes sense provided that we also have a stable alias (and maybe a stable-proposed alias, I don't care much).  The utility of that is that in a few months' time we can potentially keep working on updates to 14.09 while also preparing for a switch to 14.12 or whatever
<doko_> Noskcaj, the best thing is to package it yourself, and then point the team to it
<Noskcaj> doko, I wanted to check if there was a reason for no updates other than "maintainer MIA"
<doko> Noskcaj, you didn't write that in your email
<Noskcaj> no, i should have
 * Noskcaj leaves to get food
<doko> mlankhorst, mesa ping
<asac> cjwatson: ok thanks! devel{-proposed} points to ubuntu-touch/ubuntu/utopic{-proposed} accordingly i guess?
<cjwatson> asac: Just ubuntu-touch/utopic-proposed but yes
<cjwatson> I think
<asac> ack
<cjwatson> Not totally sure how that works, as it's not in the config file
<cjwatson> Oh, well, it's in http://system-image.ubuntu.com/channels.json
 * asac reads
<cjwatson> Some of those have "alias" entries
<asac> yeah see it
<asac> think makes sense as it is now
<jamespage> cjwatson, morning
<jamespage> cjwatson, do you have any ideas as to why a block device might have a first partition which is identifying as a character device?
<jamespage> (context - https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1343199)
<ubottu> Launchpad bug 1343199 in ceph-osd (Juju Charms Collection) "Ceph charms die horribly when the device behaves badly" [High,Triaged]
<cjwatson> jamespage: err doubleyou tee eff
<cjwatson> jamespage: get a udev trace maybe?
<jamespage> cjwatson,  that was my reaction as well
<jamespage> cjwatson, will try to
<cjwatson> jamespage: that really should be impossible regardless of the structure of the partition table, so while looking into the partition table might illuminate the problem somehow, the fix shouldn't be there
<jamespage> cjwatson, ack
<cjwatson> I don't even know how you'd do that in a udev rule if you wanted to.  Doesn't that come from the kernel?
<cjwatson> udev_device_new_from_devnum is probably the starting point for tracking it down within udev
<jamespage> cjwatson, I've asked that one of the reporters debug when it happens again
<doko> xnox, did you finish your work on creduce?
<ScottK> LocutusOfBorg1: Changing package depends won't provide a missing build-depend, so your change is orthogonal to mine.  In any case, once there's a version in Debian that will build on Ubuntu too, mine should definitely by sync'ed over.  Additionally, I find your approach very aggressive and unwelcome.  Calm down.
<Mirv> a packaging ack for unity8 desktop file moves + removal of an upstart job would be appreciated: https://ci-train.ubuntu.com/job/landing-006-2-publish/50/artifact/packaging_changes_unity8-desktop-session_1.0.12+14.10.20140811-0ubuntu1.diff
<jamespage> doko, apologies its taken me so long to get to the libcommons-logging-java/tomcat8 unpicking
<jamespage> but I've hopefully fixed that now so comp mismatches might be a little more usable shortly
<doko> jamespage, \o/
<arrrghhh> infinity, bdmurray was there some specific bug that needed squashing before updating the meta-release-lts page?
<bdmurray> arrrghhh: coincidentally, I just did that
<arrrghhh> ohai look at that
<arrrghhh> thank you :)
<infinity> arrrghhh: There were bugs we fixed last week.  The only bug over the weekend was that it was a weekend.
<arrrghhh> works for me.  thanks so much!
<rbasak> bdmurray: nack on bug 1252843. AIUI, the exact same problem will occur on V->W upgrade when V is installed on an HWE stack.
<ubottu> bug 1252843 in update-manager (nUbuntu) "Permits upgrade from an LTS system on an HWE stack to a broken system" [Undecided,New] https://launchpad.net/bugs/1252843
<infinity> slangasek: I uploaded a new shim-signed to unblock your shim in proposed (and now my d-i and the kernel), but what I didn't check is if you need/want to mirror your fallback stuff in -signed as well somehow.
<infinity> slangasek: (My upload was just a straight rebuild to fix deps)
<slangasek> infinity: um!
<bdmurray> rbasak: okay
<rbasak> bdmurray: correction. U->V when on a V HWE stack.
<slangasek> infinity: can you remove this from the queue or is it too late?
<slangasek> infinity: shim is SUPPOSED to block in -proposed until the binary signing is done
<infinity> slangasek: My upload WOULD have been a straight rebuilt to fix deps, if it hadn't FTBFS. :P
<slangasek> infinity: yeah, please don't touch this
<infinity> slangasek: Err, oh.  Well, it's blocking everything else. :/
<slangasek> why are things blocking on it?
<rbasak> bdmurray: I think this bug affected a large number of people. I saw many complaints about a blank screen on boot, and this was both reproducible and sounded like a reasonably common use case.
<infinity> slangasek: Oh, shim-signed CONTAINS the blob.  Right.  I was thinking it was like grub/linux.  Derp.
<rbasak> bdmurray: agree that there's no point fixing HWE stack upgrades on P for this bug, but we should do something about it for T HWE.
<infinity> slangasek: It's blocking because shim-signed has a versioned dep on shim, which causes d-i to FTBFS, which blocks the kernel.
<slangasek> blahhh
<infinity> slangasek: Perhaps this should be staged in a PPA, if the turnaround time it on the order of weeks instead of hours.
<slangasek> infinity: so in the future, I guess that means we should upload shim to a distro ppa instead of directly to -proposed, yeah
<slangasek> any way that we can route around this for d-i in the present instance?
<infinity> slangasek: Can I delete shim/shim-signed from -proposed so d-i is happy, and then we can sort out what to do?
<slangasek> infinity: only if you can recover it
<infinity> slangasek: I can delete and copy it back in, sure.
<slangasek> this binary has been submitted to Microsoft, it needs to not get lost :)
<infinity> slangasek: Deletion isn't particularly fatal.
<slangasek> where do you stash it to make sure it doesn't disappear?
<infinity> slangasek: The librarian.
<infinity> slangasek: We can just copy it back in over itself, like nothing happened.
<slangasek> ok
<slangasek> then yes, as long as we're sure it'll find its way back safely when it needs to, go ahead
<infinity> slangasek: So, a landing that takes this long is a poor fit for a CI silo, perhaps we should just give you a devirt of your own (or a foundations one, so it's not a bus issue), and use that for shim exclusively.
<cjwatson> foundations devirt sounds good for this
<slangasek> agreed
<infinity> slangasek: Want to create a "Shim Staging" PPA under ~canonical-foundations and I'll do the magic to make sure it's distro-sane, and copy these binaries there, so we don't lose them?
<infinity> s/lose/forget about/
<slangasek> infinity: de-virt me? https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim
<infinity> slangasek: Fixing it up now.
<slangasek> and copy done, I think: https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim/+packages
<infinity> Oh, I was just doing that.
<infinity> Looks good.
 * infinity cancels his.
<LocutusOfBorg1> ScottK, sorry if I seemed aggressive, wasn't in my mind to be ;)
<LocutusOfBorg1> this is why I ended my question with the ";)"
<LocutusOfBorg1> sorry again
<LocutusOfBorg1> and anyway, sorry but I didn't understand your answer :D
<LocutusOfBorg1> wxpython3.0 depends on wxwidgets3.0 and the build failure was in wx code
<LocutusOfBorg1> so the fix should be done in wxwidgets3.0, rather than in wxpython
<LocutusOfBorg1> because a program that uses libwxgtk3.0-dev should automatically drag in the mesa-common-dev package, rather than adding it manually
<LocutusOfBorg1> (please correct me if I'm saying something wrong, and sorry again for being unpolite, it wasn't in my intentions)
<psivaa> cjwatson: infinity: i'm investigating an issue with the i386 desktop VM installations
<psivaa> the installation with the preseed http://paste.ubuntu.com/8018805/ succeeds but the host machine is not able to ssh to the client VM
<cjwatson> can you tell whether the client VM's network is up?
<psivaa> purging openssh-server and reinstalling in the VM fixes the issue. i.e. being able to ssh from the host machine
<psivaa> cjwatson: i think the network is up since i am able to apt-get update from it (after logging in to the Virt machine manager UI)
<cjwatson> psivaa: was openssh-server definitely installed beforehand?  I don't think pkgsel/include is honoured by ubiquity (in general it doesn't have much in the way of package selection)
<cjwatson> psivaa: or are you handling that in a late_command hook instead?
<psivaa> cjwatson: yes, i think utah deals with it
<psivaa> cjwatson: and i confirmed that openssh-server was installed and sshd was running
<cjwatson> psivaa: ok, could you take a backup copy of /etc/ssh/ before purging openssh-server and compare it with what's there afterwards?
<psivaa> but sshd_config was empty
<cjwatson> empty?  blink
<cjwatson> psivaa: can you point me at the utah code here?
<cjwatson> psivaa: also any installer logs you have
<psivaa> http://d-jenkins.ubuntu-ci:8080/job/psivaa-utopic-desktop-i386-smoke-default/6/artifact/log/utah-72-boot.log has the openssh-server installation details and let me point to the utah code for it
<cjwatson> jibel: Any guesses as to why I might be getting this kind of result from adt-run with adt-virt-qemu?  http://paste.ubuntu.com/8018927/
<cjwatson> I just added the ls -lR / whoami there to rule out obvious permission issues
<cjwatson> psivaa: The only reason I can see in openssh-server.postinst why this could happen is if something had touched /etc/ssh/sshd_config before openssh-server was installed
<ScottK> LocutusOfBorg1: OK.  I don't claim it was the best solution, just that it worked.
<psivaa> cjwatson: http://bazaar.launchpad.net/~utah/utah/dev/view/head:/utah/provisioning/provisioning.py#L741 and http://bazaar.launchpad.net/~utah/utah/dev/view/head:/utah/provisioning/provisioning.py#L798 would be relevant
<cjwatson> psivaa: If that file exists, the postinst just modifies it rather than writing a fresh one.  I guess I could change it to test for empty-or-zero-size, but this seems like it must be a bug somewhere else
<cjwatson> No mention of sshd_config in utah though
<psivaa> cjwatson: i dont think we are touching the file before installing and on amd64 installs this is not an issue. the sshd_config comes with the entries needed
<cjwatson> Definitely no idea why it might be arch-specific
<cjwatson> psivaa: So, literally empty /etc/ssh/sshd_config, i.e. zero-bytes?
<psivaa> cjwatson: it was empty.. dint check if it was with zero-bytes
<psivaa> I'll run another test to check
<LocutusOfBorg1> thanks ScottK , I hope I can ask you to sync as soon as we fix it in debian :) have a good day
<ScottK> LocutusOfBorg1: Yes, I'd much prefer it sync'ed from Debian, just let me know.
<LocutusOfBorg1> +1 I love fixing debian bugs and syncing ubuntu ;)
<LocutusOfBorg1> hint: cairo needs merging, it will fix the "bug" at the actual debian style
<LocutusOfBorg1> (cairo is the reason why nobody noticed the bug in debian)
<LocutusOfBorg1> bug 1353362
<ubottu> bug 1353362 in cairo (Ubuntu) "cairo needs merge from debian" [Undecided,New] https://launchpad.net/bugs/1353362
<LocutusOfBorg1> (leaving sorry)
<ScottK> zul: Your upload of ironic has been sitting in proposed for a month.  Fancy fixing it?
<psivaa> cjwatson: http://pastebin.ubuntu.com/8019255/ is the /etc/ssh/ listing
<psivaa> cjwatson: and /var/log/apt/history.log does not contain any reference to openssh-server
<psivaa> neither does dpkg.log
<jdstrand> @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: jdstrand
<cjwatson> psivaa: That's incredibly confusing.  My guess is filesystem corruption - try forcing the installation to sync harder (er, in some way) before shutting down?
<jibel> cjwatson, from the paste, I've no idea. Are you on trusty (the version string suggests so)? Is the package available somewhere? I'll have a look.
<Lysian> Hi, in Precise Release Notes https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes, is a dead link to changes of 12.04.5 https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.5
<jtaylor> doko: do you have a hint where to look to add -Wl,--no-as-needed before the sanaitizer links in the gcc commandline, some spec file maybe?
<jtaylor> it is done for -lc -lgcc but I can't figure out where
<jtaylor> mh I guess I found it in gcc.c
<ScottK> Would someone please requeue the libkdegames test for i386.
<xnox> doko: creduce.... no, doesn't ring a bell.
<sarnold> hey xnox :)
<xnox> sarnold: hola =)
<doko> xnox, fixed it
 * xnox this is a public service announcement: "nobody likes thinkpad's nipple. it's just that touchpad has horrible tap/drag/scroll sensitivity, awful touchpad button and feels like sandpaper rather than a good quality touchpad"
<kklimonda> hmm, i really like x240 touchpad
<kklimonda> and yeah, im not using the trackpoint at all now
<xnox> i have x230 and it doesn't compare to e.g. macbook from 2006
<ogra_> xnox, that totally contradicts what i always hear from thinkpadders who are buying them because they are nipple fans
<kklimonda> mhm, they have revamped it in x240 again
<xnox> ogra_: a thinkpad nipple is forced upon me =) taking my microsoft sculpt keyboard and mouse combo with me tomorrow
<kklimonda> ogra_: i'm starting to think that people are just in an abusive relationship with their trackpoints ;)
<ogra_> i find thinkpad nipples pretty awful ... though not as bad as the toshiba copy that i had to use once with a company laptop
<kklimonda> i find thw nipple in x240 pretty bad, and now im left wondering if it has always been that way, or did they break it at some point
<ogra_> i think they call them "accupoint" or some such
<jdstrand> @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:
<bdmurray> rbasak: Did you try the debian patch for bug 1257186? it looks a bit different than the debdiff you posted.
<ubottu> bug 1257186 in samba (Ubuntu Trusty) "memory leakage messages " [High,Triaged] https://launchpad.net/bugs/1257186
#ubuntu-devel 2014-08-12
<dholbach> good morning
<dholbach> salut jibel, comment Ã§a va?
<jibel> guten Morgen dholbach, es geht mir gut, und dir?
<dholbach> jibel, bien aussi :)
<dholbach> jibel, do you know who could help nik90 and myself with https://code.launchpad.net/~dholbach/ubuntu-clock-app/reboot-packaging/+merge/229173 (it's the rewrite of the clock) to make all the test execution work in an expected way?
<dholbach> jibel, I took the upstream source, added packaging to it and tried to do what I could, but I'm stuck
<dholbach> jibel, there is a placeholder for unit tests, there are some autopilot tests, and I'm not sure if autopkgtest is the way to go, or the added -autopilot package
<dholbach> AFAICS everything is a little bit broken, so it'd be good if somebody who knows what they're doing could help :)
<jibel> dholbach, probably balloons can help. I think now autopkgtest is the preferred way to run the tests but before adding that layer tests must run without it. There are other click app that use autopilot and can be use as example.
<jibel> dholbach, really balloons is well aware of all this
<zyga> hey
<zyga> is it just me or is all-canonical infrastructure down somehow?
<zyga> chinstrap, irc, archive, etc
<doko> same here
<dholbach> zyga, I'm having trouble as well
<zyga> yeah
<psivaa> cjwatson: we are force shutting  down the VM soon after we get 'ubiquity reboot' message in the install log. so filesystem corruption could be possible. i had to add a sleep before the shutdown for server installs which saw a similar issue before but not doing that for desktop now. will try and add a sleep before the shutdown and try if it improves.
<zyga> thanks for confirming, so it's not anything on my end then
<dholbach> zyga, it seems to work though from another machine I have access to
<zyga> dholbach: can you ssh to chinstrap or get a hold of IS?
<zyga> dholbach: I cannot even find the IS emergency phone number now
<dholbach> zyga, #canonical-sysadmin
<dholbach> jibel, the bugs we are looking at right now are 1354377 and 1355145 - it'd be good if we had a bit better idea what the general process is
<dholbach> jibel, but yeah... maybe I should have a closer look at some other packages
<jibel> dholbach, I can have a look later today if it can wait a couple of hours
 * dholbach hugs jibel
<dholbach> merci beaucoup!
<jibel> dholbach, it seems classic problems with uninitialized dbus session an stuff like that. I'll have a look.
<dholbach> jibel, at this point I had no idea what I was doing :)
<xmj> good morning
<xmj> does ubuntu provide a mirror for america's army as listed here - https://help.ubuntu.com/community/AmericasArmy ?
<xmj> i'm working on updating the freebsd port of it, and noticed that they took all 11(!) mirrors down.
<rbasak> bdmurray: re: bug 1257186, I did try a more recent patch from that bug (from upstream, actually) but samba FTBFS for other reasons, and I didn't get through figuring that all out.
<ubottu> Error: Could not gather data from Launchpad for bug #1257186 (https://launchpad.net/bugs/1257186). The error has been logged
<rbasak> I'll update the bug, but it's open for testing and fixing atm.
<mapreri> pitti offline from 3 days?? what the hell is going on? :o
<seb128> mapreri, he's on holidays this week
<cjwatson> psivaa: A sync seems more likely to help than a sleep, but maybe ...
<psivaa> cjwatson: ok, i'll need to figure out how to integrate that to utah :)
<mapreri> seb128: ouch, I'd rather say pitti never goes on holiday :)
<seb128> lol
<cjwatson> psivaa: Should be no harder than sleep?  Just another command
<psivaa> cjwatson: ohh?, i'll use it then. thank you
<cjwatson> psivaa: May have to experiment a bit; actually forcing everything out to disk can be a bit of a black art sometimes
<doko> xnox, do you know why you did add the Breaks: clang (<< 1:3.5) in clang-3.5?
<xnox> doko: such that we can change clang metapackage to default to 3.5 without need to rebuild 3.5 toolchain.
<xnox> doko: i believe it's committed in debian packaging VCS as well (reported to debian developer via private email)
<xnox> doko: otherwise clang defaulting to 3.5, was depending on clang-3.5 yet not coinstallable.
<doko> xnox, https://launchpad.net/ubuntu/+source/creduce/2.2~pre3-2
<xnox> doko: multiple clang toolchains are not coinstallable. You are trying to install both clang-3.4 and clang-3.5 but they conflict with each other.
<xnox> doko: drop "clang" build-dep, and use "clang-3.5"
<doko> xnox, are you serious?
<xnox> as all clang-3.x packages provide /usr/bin/clang. We are working on making them co-installable gcc style.
<xnox> doko: yes. I no joke.
<doko> argh, that's silly
<doko> xnox, https://buildd.debian.org/status/package.php?p=creduce&suite=unstable works in debian
<xnox> doko: well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736057 is closed now, so clang is co-installable in debian now.
<ubottu> Debian bug 736057 in clang "clang: Co installable clang versions" [Wishlist,Fixed]
<xnox> doko: hm, maybe my breaks is wrong now.
<michagogo> whois arges arges
<michagogo> erm
<michagogo> Does anyone know if the 7-day thing for SRU is just on the 7th day or later, or if it has to be at least 168 hours?
<cjwatson> michagogo: It's implemented by sru-report in lp:ubuntu-archive-tools.
<cjwatson> michagogo: You can see the current reported age on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<cjwatson> That's in practice what we look at.
<michagogo> Ah, okay
<michagogo> So 168 hours, then?
<cjwatson> I would be surprised if it were otherwise.
<michagogo> okay
<michagogo> cjwatson: thanks
<cjwatson> Basically it's whenever an SRU admin happens to look at that page and notice something >= 7 days.
<michagogo> Ah, cool
<michagogo> So sometime in the next day or two, probably?
<cjwatson> No idea what package you're talking about, so can't say.
<michagogo> (IIRC it was accepted a week minus ~6 hours ago)
<michagogo> bitcoin
<cjwatson> michagogo: It's at 6 days, but has one unverified bug.  See the page linked above.
<michagogo> cjwatson: yeah, I have no idea what that bug is
<cjwatson> We won't normally look at packages where all the bugs at the right aren't highlighted green.
<michagogo> It's completely irrelevant, as the SRU is removing the package
<michagogo> Looks like that bug was an older SRU that didn't get verification and got rejected
<michagogo> "This SRU has remained unverified after 175 days in the -proposed queue. I've removed it now from quantal-proposed and am marking the task 'wontfix'. The package has already been removed from precise-proposed for the same reason.:
<michagogo> s/:/"/
<cjwatson> I guess somebody will have to look at that and check that it's irrelevant.
<michagogo> What makes that bug show up there, btw?
<cjwatson> Haven't investigated.
<cjwatson> It's probably walking through the versions between current -updates and current -proposed or something.
<cjwatson> You can read sru-report if you fancy working it out
<michagogo> cjwatson: ah, I think I found it
<michagogo> https://www.irccloud.com/pastebin/TcMjGLhv
<michagogo> er
<michagogo> In the changelog:
<michagogo> https://www.irccloud.com/pastebin/oQ4h6TiW
<cjwatson> We can ignore it if it's genuinely not a problem
<michagogo> It's not.
<cjwatson> But I'll wait for the aging period to expire since that involves much less thinking
<michagogo> Not a problem...
<michagogo> I think I first started looking into how to get the package removed back in October, what's another 5-6 hours? :-)
<michagogo> anyone know how often pending-sru.html updates?
<cjwatson> michagogo: 10,40 * * * *
<michagogo> What format is that in?
<cjwatson> crontab
 * michagogo googles
<cjwatson> man 5 crontab
<cjwatson> I don't remember whether it always runs inside its window - the job is quite slow - so I guess it might be less frequent than stated
<michagogo> Ah, so it's on minute 10 and 40 of every hour of every day of every month, every day of the week?
<cjwatson> Yes
<michagogo> Also, the timestamp on there is 10:35:54 UTC, so...
<cjwatson> Implying it takes ~25 minutes.  Might get quicker soon as I just released the big batch of KDE stuff
<michagogo> 25? or perhaps 55?
<cjwatson> michagogo: Don't know, not going to look.  It doesn't matter that much.
<michagogo> yeah, that's true
<doko> jamespage, zul: any idea why python-wsme uses nosetests for 2.7, and setuptools for 3.4? and any idea why that fails (trying to download WebOb)?
<psivaa> Saviq: regarding your test.xml archiving for http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/, in fact *test*.xml and *Test*.xml are already archived. so I'm not sure why you dont see the results that you're expecting
<Saviq> psivaa, that's a good question, could the job collect the .xml files in artifacts?
<psivaa> Saviq: that could be done
<zul> doko:  i dont but im on holiday this wek
<doko> everbody seems to be =)
<jamespage> doko, ah the joy of august
<cjwatson> Laney: Hmm, do you think you could be persuaded to merge gst-plugins-bad1.0?  I'm touched-it-last due to an attempted rebuild for http://people.canonical.com/~ubuntu-archive/transitions/libass.html, but it fails to build due to a strict opencv version constraint, I don't really know the package, and it looks as though it ought to be caught up with the rest of gstreamer1.0 anyway
<doko> jamespage, found it ... bad barry ... https://launchpad.net/ubuntu/+source/python-webob/1.4-1ubuntu1
<jamespage> doko, awesome - thanks!
<psivaa> cjwatson:  adding a 5 second sleep just before shutting down the VM fixes the issue of openssh-server installation issue for i386 desktop
<psivaa> tried using sync too, but it dint help a lot. so without rocking utah too much, i'm going to use the sleep for now :)
<psivaa> cjwatson: thanks for your input
<psivaa> jibel: so the i386 desktop smoke tests are running after  a long time and the image has been promoted to current today
<Mirv> hmm, is there a process for updating release notes?
<Mirv> in 10.04 LTS /etc/resolv.conf was a real file, and an upgrade to 12.04 LTS did not change it to the new default of a symlink. this did not hurt in 12.04 LTS, but upgrading to 14.04 LTS apparently yields non-working name resolving.
<Mirv> my previous trusty fix fixed the case where /etc/resolv.conf was removed by user (or live CD customizer...), but it does not improve the situation when /etc/resolv.conf is there and is a normal file, like it was in 10.04 LTS
<Mirv> well, there's the ubuntu-release-notes project, I'll use that instead of editing directly
<jibel> psivaa, thanks for the update
<Mirv> so, filed bug #1355868
<ubottu> bug 1355868 in Release Notes for Ubuntu "Ubuntu 10.04 LTS upgraded to 14.04 LTS via 12.04 LTS does not have proper name resolution" [Undecided,New] https://launchpad.net/bugs/1355868
<zyga> xnox: hey
<zyga> xnox: do you have a moment to talk about python3.4 and libpython3.4?
<zyga> doko: so, about libpython3.4 not being a dependency of python3.4 executable
<doko> zyga, yes, it doesn't depend on it
<zyga> doko: if it would use dynamic linking everything would be prohibitetively slower?
<doko> zyga, as I did say, 10-15%
<zyga> doko: the problem is that anything that links to python3 now needs to *ship* python3, with all the security issues around that (on the phablet)
<doko> especially on register starved architectures like armhf and i386
<zyga> doko: I'm trying to find a way to either get the .so file back on the image
<zyga> doko: or figure out something else that could prevent us from having python inside our click package while we still have it in the os
<doko> zyga, no, libpython3.4 depends on libpython3.4-stdlib, not on python3.4
<zyga> doko: right, stdlib is there, this whole discussion is about the .so file
<zyga> doko: if I'd like to get it as a part of touch images
<zyga> doko: do you know who I should be talking to?
<doko> zyga, sorry, no. why isn't that pulled in by a dependency?
<doko> maybe ask Mirv, ogra_ tvoss?
<zyga> doko: because nothing depends on libpython3.4 anymore, apparently
<zyga> doko: python3 doesn't, all of the apps just use it as an interpreter
<ogra_> doko, recommends vs deps perhaps ? touch doesnt install recommends
<zyga> doko: pyotherside does but that's different and apparently I cannot convince anyone to include it in the image
<zyga> we can ship pyotherside
<zyga> but shipping python3.4m.so starts to be fishy
<zyga> (security)
<jdstrand> zyga: I think you want lool and pmcgowan_
<zyga> and it's all just silly, we have python there anyway, just not the way (our) particular app needs it
<zyga> ok, thanks
<zyga> lool: hey
<ogra_> right, and as i said., we are 600MB to big in the install already
<zyga> ogra_: how do you plan to cut 600MB?
<zyga> ogra_: that feels unrealistic
<xnox> zyga: we do not ship python on touch
<ogra_> there must be some really serioous reason to add anything now
<xnox> zyga: and will not.
<zyga> xnox: we ship python3 today, has that changed?
<xnox> zyga: please do not rely on it being there.
<zyga> xnox: will all the deps be migrated away?
<xnox> zyga: well, system-image is in python3 so, yeah that is there.
<ogra_> zyga, long term by droping all the autopilot bits etc ...
<xnox> zyga: and will stay
<zyga> xnox: so we will ship python3.4 on the image
<xnox> zyga: but it's not an app framework one is allowed to use.
<zyga> xnox: I'm trying to find a RTM-ready solution
<zyga> xnox: for our (hw/cert) tools
<xnox> zyga: it's not part of the sdk
<zyga> xnox: sure, it's not but we're special
<ogra_> so shop what you need in your package
<xnox> zyga: and can be removed at whimp, or like blocked from accessing with apparmor.
<zyga> xnox: we don't care, we cannot rewrite our tools and we wont, we took that higher already, we need _a_ solution
<ogra_> *ship
<ogra_> this is what you have to do long term anyway
<zyga> ogra_: long term we might just do that
<xnox> zyga: we seeded a bunch of packages because "something rather as a click needs it"
<ogra_> the image will massively shrink still
<zyga> ogra_: but we need something for now that doesn't pull the carpet from under us
<zyga> ogra_: so will python be on the RTM image?
<xnox> zyga: but generally it's an exception, it's best to make your click building procedure to bundle things and/or statically link. You can't statically link python, but you should be able (at build time) to ship it into the ldpreloaded path and it will just work.
<ogra_> thats why i'm suggesting a method that works now and wil work later :)
<xnox> zyga: what are you after, and what is missign?
<xnox> zyga: given that python3 is on the image and is usable.....
<ogra_> zyga, perhaps
<zyga> xnox: python3.4 is but libpython3.4m.so isn't (and that's what we actually need)
<ogra_> basic python will always be there for system-image
<xnox> zyga: are you building compiled extensions?
<ogra_> abd currently whatever autopilot still pulls ion is there
<zyga> xnox: yes and no, we depend on pyotherside, everything we have is pure python
<zyga> xnox: pyotherside is pulled in from the archive as-is
<xnox> zyga: then you will at compile time, will also need to copy libpython3.4m as you'd need to rebuild that everytime python shared library is.
<zyga> xnox: and it links to libpyton3.4
<xnox> zyga: so pull libpython3.4m at the same time as pyotherside and ship into lib/$multiarch-tripplet inside your click, which is a set ldpreload path by ubuntu-app-launch.
<zyga> xnox: that doesn't work, somehow, I just tried that
<xnox> zyga: and you'd need to pull in all shared deps that are not in the sdk but are deps of the pyotherside like that.
<zyga> xnox: but it's also a security issue which we wanted to avoid (shipping pyotherside, fine, shipping a part of python itself, less fine)
<xnox> zyga: why is that a problem? well - did you use the correct path? check ubuntu-app-launch code to see the environment variables it sets.
<zyga> xnox: we have no other deps if that matters :/
<zyga> xnox: I'll check it out but I still don't think that's the right way
<zyga> xnox: we're kind of system-ish as well
<xnox> zyga: we are not going to pull in libpython3.4 just for your optional component, as we will not ship qa/cert tool on the image itself.
<zyga> xnox: but we get the app-level treatment
<zyga> xnox: that's not entirely decided yet though
 * zyga mutters something about some special modes for testing and engineering 
 * zyga looks at ubuntu-app-launch
<xnox> zyga: use qml and compile c++ =))))
<xnox> zyga: that's standard sdk these days.
<zyga> xnox: that's fun but we have existing tools and we cannot and won't change that
<zyga> xnox: and waving magic wand won't rewrite our code
<zyga> xnox: so just lib/$triplet doesn't work for what I see, the qml plugin is found but loading libpython still fails (cannot find the .so file)
<zyga> xnox: ok, so LD_LIBRARY_PATH is set, hmmm,
<zyga> xnox: how can I use u-a-l on the device interactively?
<zyga> xnox: what's tha app id? is that the click package id?
<xnox> zyga: tedg can help you more =)
<zyga> xnox: thanks
<zyga> tedg: ^^
<tedg> zyga, So what's the issue?
<zyga> tedg: I'd like to understand how ubuntu-app-launch works to debug how it sets LD_LIBRARY_PATH and how my app fails to find some .so files it needs
<zyga> tedg: how do I use u-a-l? what is tha app id?
<tedg> zyga, It's a combination of three things, the package name, the app name and the version number.
<tedg> zyga, Probably the easiest way to discover it is to use ubuntu-app-triplet $pkgname
<zyga> tedg: so if that's a click package how does that look like in practice?
<zyga> $pkgname is click package name?
<tedg> For instance calculator is: com.ubuntu.calculator_calculator_1.3.307
<tedg> zyga, Correct
<zyga> ok
<zyga> oh
<zyga> xnox: fun, so it works when I install the package, fails from SDK "run" button
<zyga> odd?
<xnox> zyga: not really. sdk run button doesn't create full click, nor run it fully, i believe it just pushes the files and executes them without a full click/install cycle.
<zyga> xnox: ah, that would explain it then
<zyga> xnox: thanks, we got some bits moving
<xnox> zyga: which imho is an sdk bug or feature. Discuss that with bzoltan
<zyga> who should probably be here in this channel :)
<doko> mlankhorst, we need a llvm-toolchain-3.4 merge ... for clang be co-installable with clang-3.4. do you volunteer? ;p
<xnox> =)))))
<xnox> doko: i did leave a pile of unmerged stuff didn't i?! =)
<xnox> doko: i can probably do it late in the evening tonight.
<xnox> doko: don't have gpg nor ssh access to my compile box at the moment.
<slangasek> xnox: leave it?  goodness no, you're still TIL
<xnox> slangasek: lolz =) ok. then.
<xnox> slangasek: may I join ~ubuntu-release?
<slangasek> uh
<slangasek> in theory you could join the team and then be added to the group? :)
<xnox> slangasek: in practice, how does that happen?
<slangasek> xnox: by consensus of the existing team
<xnox> slangasek: ack.
<slangasek> xnox: so you should start schmoozing infinity
<slangasek> (who, incidentally, is a team admin, where I am not :)
<xnox> slangasek: i'll write an email to ubuntu-release mailing list as a start.
<Laney> cjwatson: I did, it FTBFS due to bug #1358074
<ubottu> Error: Launchpad bug 1358074 could not be found
<Laney> bug #1350874
<ubottu> bug 1350874 in platform-api (Ubuntu) "/usr/include/ubuntu/application/ui/input/event_deprecated.h:79:24: error: redefinition of âstruct PointerCoordinateâ" [Undecided,Confirmed] https://launchpad.net/bugs/1350874
<cjwatson> Urgh.  Well hopefully somebody will sort it out and finish the transition before I get back from vac :)
<Laney> I've poked a couple of times already
<mlankhorst> doko: erm would prefer not, I'll look tomorrow
#ubuntu-devel 2014-08-13
<saiarcot895> Can someone nominate bug 1284190 for Trusty?
<ubottu> bug 1284190 in openscenegraph (Ubuntu) "openscenegraph 3.2.0~rc1 doesn't build on ARM (armhf), but builds fine in Debian" [Undecided,Fix released] https://launchpad.net/bugs/1284190
<dholbach> good morning
<sil2100> Morning o/
<sil2100> didrocks: hello! Are you busyish right now? :) I'm looking for a volunteer that would do some operations on snakefruit for me ;)
<didrocks> sil2100: hey! if it's just for a few minutes, I can handle that
<sil2100> didrocks: ok! What I would need is, first: a bzr pull on the cu2d directory on snakefruit to pull in my missing change for copy2distro
<didrocks> sil2100: no need for a review?
<sil2100> didrocks: it's part of a bigger change, and it's just a tweak now for the new stuff to work wit the old stuff as well
<didrocks> sil2100: ok
<sil2100> didrocks: because of my lack of this one thing to support back-compatibility (which got removed by accident when all the bazillion workarounds were cleaned), it also caused some packages to be rejected, and I would like their rsync files copied to ./incoming again once the bzr pull is done :)
 * sil2100 will give a list
<didrocks> sil2100: really man, that's why I offered my help for all the reviewsâ¦ seems you don't want them and things are breaking
<sil2100> It's like almost the finish line! Publishing to ubuntu-rtm works, it would be the same for ubuntu if we would switch to production already, so this got only broken because we have a mix of prod and preprod publishings made
<didrocks> sil2100: doesn't answer why you didn't want to get any review from the start, but oh well ;)
<sil2100> didrocks: I blame it on being ashamed of my python skills!
<sil2100> didrocks: if anything, the missing rsync files ;) paste.ubuntu.com/8033978/
<didrocks> you shouldn't! reviews is what enable everyone to get more skills :)
 * didrocks grabs
<sil2100> I know, it's a bit of like shooting in one's own knee sadly ;/
<didrocks> sil2100: ok, trunk pulled and all rsync files in incoming/
<didrocks> running a manual sync
<didrocks> done, no error message
<sil2100> |o|
<sil2100> That's... unexpected!
<sil2100> didrocks: thanks!
<didrocks> yw ;)
<didrocks> seems some are already on -changes
<didrocks> (ubuntu-keyboard)
<halfie__> hey, why doesn't the openldap / slapd in trusty have support for {SSHA512} hashing scheme?
<tjaalton> it's too old?
<tjaalton> hm no, looks like the module is under contrib tho
<tjaalton> halfie__: slapd-sha2 isn't included, see debian bug #746727
<ubottu> Debian bug 746727 in slapd "slapd: Please include slapd-sha2 contrib module" [Wishlist,Open] http://bugs.debian.org/746727
<halfie__> tjaalton, cool, thanks, taking a look now.
<seb128> doko, hey, are you aware of any issue with the llvm update?
<seb128> some autopkgtests started failing yesterday due to it
<seb128> e.g http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/149/
<seb128> on i386
<seb128> "LLVM ERROR: Do not know how to split the result of this operator!"
<seb128> seems to be the issue
<sil2100> @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: sil2100
* hobana.freenode.net 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:
<doko> seb128, mlankhorst: do you know how to debug this, get a reproducer?
<mlankhorst> do you have a public url?
<seb128> doko, no idea how to debug, reproducer is "run autopkgtest for ubuntu-system-settings-online-accounts on utopic"
<seb128> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/148/ARCH=i386,label=adt/
<mlankhorst> ok
<seb128> is a public url
<seb128> it's easy to reproduce locally, Laney and I confirmed
<mlankhorst> seb128: we have moved to llvm-3.5 on doko's request, when did it start failing?
<seb128> yesterday
<Laney> downgrading mesa and getting libllvm3-4 back fixes it
<mlankhorst> ok
<mlankhorst> I'll try with reverting just llvm first since that seems to be the obvious step here
<Laney> ta
<doko> mlankhorst, well we know how to work around it, but do we know how to debug this?
<mlankhorst> doko: I want to rule out it being the  upgrade to 10.2.5 first i also uploaded that
<mlankhorst> hm what ppa has online-accounts-ui?
<Laney> ubuntu-system-settings-online-accounts in the archive
<mlankhorst> ok I don't have a i386 utopic chroot atm, give me a bit..
<Laney> I ran it like this http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<mlankhorst> the log has enough info
<mlankhorst> 06:24:26.845 INFO _launcher:431 - Launching process: ['/usr/bin/online-accounts-ui', '-testability', '--desktop_file_hint=/usr/share/applications/online-accounts-ui.desktop']
<prorus> Hello there, little help needed http://askubuntu.com/questions/510706/live-build-lb-config-help-needed
<prorus> In short I need to specify in ld config kernel version
<prorus> no idea how to do it even google won't help
<doko> jamespage, zul: fixed your autopkg test regression in swift
<mlankhorst> hm test works for me on real hardware
<doko> mlankhorst, does llvm have some means to "downgrade" the cpu it compiles for?
<sil2100> hm, it seems I disappeared from the patch pilot list
<sil2100> @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: sil2100
<mlankhorst> doko: dno, I can run in qemu..
<mlankhorst> oh nm the warning happens
<mlankhorst> doko: doing a google search.. https://github.com/llvm-mirror/llvm/commit/636a9bece43b3f10c27fb1260467fdc3cf989ea1 ?
<mlankhorst> from https://github.com/JuliaLang/julia/issues/7911
<mlankhorst> I'll give it a shot
<mlankhorst> hm weird, should be applied
<mlankhorst> doko: can I crank up the verbosity on llvm?
<Laney> tyhicks: hiya, do you think you're going to be able to get to the dbus merge again soon? Having 1.8 would be nice if we can manage it.
<Laney> selfishly, I want the dbus-run-session script :-)
<doko> mlankhorst, probably, but it's a long time I did some work with llvm
<mlankhorst> ok
<sil2100> Lunch break :)
<sil2100> @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:
<doko> jtaylor, python-scipy autopkg test failing on i386
<doko> this test test_roots (test_interpolate.TestPPoly) fails during the build too, but test results are ignored :-/ but not for the autopkg test
<saiarcot895> Can someone nominate bug 1284190 for a Trusty SRU?
<ubottu> bug 1284190 in openscenegraph (Ubuntu) "openscenegraph 3.2.0~rc1 doesn't build on ARM (armhf), but builds fine in Debian" [Undecided,Fix released] https://launchpad.net/bugs/1284190
<sil2100> @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: sil2100
<pete-woods> jdstrand: hi! I'd like a quick chat about settings for scopes
<pete-woods> (when you have a few minutes to talk about it)
<jdstrand> pete-woods: hi! now is as good a time as any :)
<pete-woods> jdstrand: so as I understand it...
<pete-woods> scope settings are (currently) being written to $HOME/.local/share/$SCOPE_ID/settings.db
<pete-woods> this is (intentionally) somewhere that the scope cannot read directly
<pete-woods> I had (incorrectly) thought that an unconfined part of the scope machinery was going to read these settings
<pete-woods> and hand them over the the scope when it was queried
<pete-woods> however it seems that the scope really needs to read them in-process
<pete-woods> i.e. have filesystem level read-only access to them
<pete-woods> jdstrand: so should we move them somewhere else? or is it reasonable to add that path to the confinement profile with read-only access?
<jdstrand> pete-woods: this is a global settings db for scopes?
<jdstrand> ie, all scopes are using the same settings db?
<jdstrand> s/db/file/
<pete-woods> jdstrand: nope, it's one file per-scope
<pete-woods> jdstrand: literally this path $HOME/.local/share/$SCOPE_ID/settings.db
<jdstrand> pete-woods: ok, good!
<jdstrand> :)
<jdstrand> let me check the policy
<jdstrand> pete-woods: does SCOPE_ID contain the version?
<pete-woods> jdstrand: no, I really mean the short id
 * pete-woods checks
<pete-woods> yeah, e.g. com.ubuntu.youtube_youtube/
 * jdstrand is thinking
<jdstrand> pete-woods: is there any reason why it can't be in the existing directory we have allocated for scopes:
<jdstrand> @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}
<udevbot> Error: "{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}" is not a valid command.
<Laney> @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: sil2100, Laney
 * dholbach hugs Laney
 * Laney hugs dholbach ;-)
 * Laney hasn't opened the list yet... brace for impact
<Laney> 59, could be worse
<dholbach> takes you what? half an hour?
<Laney> dude
<Laney> I've always been a super slow sponsor :P
<dholbach> come on everyone, the man needs a challenge
<mlankhorst> hm
<mlankhorst> 10.3 + git seems to work
<pete-woods> jdstrand: we don't want the scope to be able to write to the settings itself
<Laney> git what?
<pete-woods> as that is where the setting for, e.g. should the scope get location data, is stored
<jdstrand> pete-woods: ah, so no writes
<mlankhorst> Laney: git mesa :-)
<Laney> ah
<Laney> bisect time
<mlankhorst> well git log anything first
<mlankhorst> reverse bisects are awful
<pete-woods> jdstrand: that's the idea, yes
<jdstrand> pete-woods: I can add read-only access to 'owner @{HOME}/.local/share/@{APP_PKGNAME}_@{APP_APPNAME}/settings.db* rk,'
<jdstrand> pete-woods: I wonder if it would be more uniform to do this instead: @{HOME}/.local/share/unity-scopes/@{APP_PKGNAME}_@{APP_APPNAME}/settings.db*
<jdstrand> (ie, insert 'unity-scopes' in there)
<pete-woods> jdstrand: okay, that would mean that confined scopes would use the same paths as unconfined ones, right?
<jdstrand> pete-woods: yes, there is no 'leaf-net' or anything embedded in the path
<pete-woods> jdstrand: to be honest, I'm happy with any path you think makes the most sense
<pete-woods> I just need everything to tie up
<pete-woods> and for confined scopes not to be able to write to it
<jdstrand> pete-woods: I like having unity-scopes in there since without it, the path sorta looks like the path apps use, but not quite
<pete-woods> okay, sure, that works for me
<jdstrand> pete-woods: actually, would it be better served in ~/.config?
<pete-woods> jdstrand: probably makes more sense, too
<pete-woods> given it's, er, config!
<jdstrand> pete-woods: ok, so I will add this to apparmor-easyprof-ubuntu 1.2.18: @{HOME}/.config/unity-scopes/@{APP_PKGNAME}_@{APP_APPNAME}/settings.db* rk
<jdstrand> pete-woods: I'm assuming this is sqlite? (perhaps I shouldn't)
<pete-woods> jdstrand: fantastic stuff
<pete-woods> it's u1db, but underneath sqlite, yes
<pete-woods> the next step is making sure u1db doesn't get upset for a RO database
<jdstrand> ok, good. that's why I used 'settings.db* rk' (account for sqlite journal and lock files)
<pete-woods> :)
<jdstrand> pete-woods: not sure about u1db, but sqlite can definitely do it. talk to mardy if you need help (he is using ro on an sqlite db for online accounts)
<jdstrand> pete-woods: if you need help with u1db specifically, talk to kalikiana
<pete-woods> jdstrand: thanks, will see how this goes first :)
<mara__> please help. I have a Java Swing project in Netbeans. I need him to create the Debian Source package. Can someone help me. thanks
<saiarcot895> Can someone nominate bug 1284190 for a Trusty SRU?
<ubottu> bug 1284190 in openscenegraph (Ubuntu) "openscenegraph 3.2.0~rc1 doesn't build on ARM (armhf), but builds fine in Debian" [Undecided,Fix released] https://launchpad.net/bugs/1284190
<hallyn> sigh, was going to merge slof from debian, but the cross compiler appears to be crashing when i test-build locally
<darkxst> Laney, let me make that 60 for you then ;) bug 1076232
<ubottu> bug 1076232 in nautilus (Ubuntu) "Build with tracker support" [Wishlist,Confirmed] https://launchpad.net/bugs/1076232
<mara__> please help. I have a Java Swing project in Netbeans. I need him to create the Debian Source package. Can someone help me. thanks
<Laney> darkxst: got a bzr branch?
<darkxst> Laney, no, but can make one if you prefer
<Laney> darkxst: marginally easier because I have to push it there after uploading
<Laney> but as you prefer
<sil2100> @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: Laney
<mlankhorst> oh nm some error in how I build things
<mlankhorst> 10.3 git is affected after all if I run it in a qemu img
<darkxst> Laney, ok, will push something up in a few minutes
<darkxst> Laney, nautilus branch is missing  1:3.10.1-0ubuntu12
<Laney> who uploaded that?
<Laney> me
 * Laney RUNS!
<darkxst> Laney, yep!
<Laney> one second
<Laney> darkxst: try now
<darkxst> Laney, yeh that is better ;)
<darkxst> Laney, lp:~darkxst/ubuntu/utopic/nautilus/tracker
<Laney> cheers
<hallyn> jamespage: so it turned out i was even dumber than we thought yesterday - there was an existing bug with a debdiff attached for ipxe in debian.  just noone has merged it.
<hallyn> (bastian blank awol i guess)
<hallyn> wonder if this is a candidate for NMU
<jelly> hallyn: (fwiw, waldi, that's his nickname, has been active here on freenode recently)
<jdstrand> pete-woods: hey, can you look at the denials in https://bugs.launchpad.net/barajas/+bug/1355061/comments/1 ?
<ubottu> Error: launchpad bug 1355061 not found
<jdstrand> pete-woods: the youtube denials that is
<jdstrand> pete-woods: there are a number of issues. disregard the libaccounts denial (they need the accounts policy group)
<pete-woods> jdstrand: hmm, that's a bit worrying that the scopes API thinks that youtube is unconfined
<jdstrand> pete-woods: well, notice the denial
<jdstrand> unconfined/com.ubuntu.scopes.youtube_youtube
<pete-woods> yes, that's what I mean
<jdstrand> then another for leaf-net/com.ubuntu.scopes.youtube_youtube
<jdstrand> there are two things:
<jdstrand> a) unconfined was tried first
<jdstrand> b) these are appending _youtube, but the policy doesn't allow that
<jdstrand> the policy was adjusted recently for the end points to use @{APP_PKGNAME}_@{APP_APPNAME}
<pete-woods> jdstrand: ah, this is because that's how the scopes API determines if something is confined
<jdstrand> but the files in the leaf-net directory have thus far intentinally used only @{APP_PKGNAME}
<pete-woods> yep
<jdstrand> pete-woods: ok, that was my first question-- I can silence that denial
<jdstrand> (the unconfined one)
<pete-woods> I think this stuff is pretty messed up, though
<pete-woods> as you say, it's putting stuff in the wrong directory
<jdstrand> but, seems the scope is in error to use @{APP_PKGNAME}_@{APP_APPNAME}?
<pete-woods> this has come about because that's the actual scope ID
<jdstrand> maybe that is a problem in the scope libraries, not sure
<pete-woods> yeah, I think it is
<jdstrand> that is what I was afraid of. now, I can change the policy to be more specific, but I want to make sure that is intentional, and if intentional, I want to mention that it means multiple scopes shipped via a single click can't share data, which they could before
<pete-woods> it's the actual scope runtime that is doing this
<hallyn> jelly: cool, thanks
<mlankhorst> Laney: can i run that program stand-alone?
<Laney> if you pass --shell to adt-run you can ssh in and then run the script
<pete-woods> jdstrand: FYI https://bugs.launchpad.net/unity-scopes-api/+bug/1356409
<ubottu> Launchpad bug 1356409 in unity-scopes-api "Confined scopes are using the wrong path for the writable directory" [High,Confirmed]
<mlankhorst> Laney: I want to run online-accounts-ui stand-alone
<Laney> don't know
<Laney> look at what the autopilot test runs
<mterry> jodh, hello!  I'm looking at a bug in our Touch image.  Where sometimes (seems racy) an upstart job is failing over and over again.  The  crash files from it aborting (seemingly) due to a missing environment variable show that procEnviron for it is basically empty.  But querying the job's environment via initctl shows the right stuff.  What might cause a difference there?
<jodh> mterry: so you are using 'initctl set-env' and a job isn't seeing the variable right?
<mterry> jodh, it's not about the use of set-env.  get-env shows full normal environment.  But procEnviron in the .crash file shows an environ with like 5 basic variables in it
<jodh> mterry: does the job start with the correct environment?
<mterry> jodh, I believe so.  The job is respawning regularly.  And doing a get-env on one of its instances prints the right env
<mterry> jodh, I'm not saying it's an upstart bug necessarily.  I'm just curious if you've seen this sort of thing before or if it seems likely that upstart could not pass on the right env
<jodh> mterry: could it be corrupting it's own environ pointer?
<jodh> mterry: we have pretty extensive tests in this area so I'd be surprised if it's an upstart bug tbh.
<jodh> mterry: can you point me at a crash file?
<mterry> jodh, the process?  Could do.  It'd have to be pretty early in the sequence, but maybe.
<mterry> jodh, yeah I feel like we would have seen this before if it was upstart
<mterry> jodh, https://errors.ubuntu.com/oops/c2b19e56-22f2-11e4-9d72-fa163e373683
<mterry> jodh, that's a specific version of the general crash problem
<jodh> mterry: wait a sec - ProcEnviron is only a subset of the env vars; apport doesn't show the complete set for security reasons.
<mterry> jodh, oh really?  I was under the impression it was full.  But that makes some sense...  OK.  So that may be a complete red-herring
<mterry> I thought that was why we restricted errors.u.c to ubuntu members and whatnot
<jodh> mterry: also, note that 'initctl {get,list}-env' shows the "global" job environment table (ie not job-specific), unless called directly from a job.
<jodh> mterry: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L484
<jodh> mterry: so you'll have to look at environ in the core file, but it may be that the crash is unrelated to env vars.
<mterry> jodh, ok thanks so much for the help.  sigh
<mterry> jodh, my sigh was at the problem, not you!  :)
<jdstrand> pete-woods: ah, thanks!
<jodh> mterry: could you maybe change the job to run 'exec strace -o ... unity8-dash' ?
<mterry> jodh, maybe...  It's a bit racy, and I haven't even been able to reproduce myself yet
<doko> infinity, can we start building glibc with gcc-4.9?
<infinity> doko: Does that magically fix the ppc64el failure we don't know the cause of? :P
<infinity> doko: I'll throw a test build at my PPA for my next merge and see how it looks on all arches.
<infinity> doko: I assume gcc-4.8 will stick around for jessie, and there's no rush to switch in Debian?
<doko> infinity, no, already checked, but didn't cause any additional test failures
<doko> infinity, well, I would like to get rid off it
<infinity> doko: Alright, I'll see what I can do on the Debian side too.  That'll take a bit more testing to be sure.
<doko> infinity, ahh, and I would need the cross-toolchain-base package working again for multilib builds ...
 * doko hides
<infinity> doko: Yes, I was going to take ownership of fixing that mess.
<infinity> doko: It's about to get worse before it gets better, so I'll fix as we go.
<tjaalton> should systemd-sysv be installable now, without removing unity?
<seb128> speaking of systemd, who is working on that transition, out of pitti?
<seb128> I've upgraded to utopic and my system stopped shutting down or rebooting, it hangs on the plymouth logo forever, I need to sit on the power button to get ouf of the situation
<seb128> is that a known issue/where that should be reported?
<seb128> oh, also "hibernate" is back as an option in the UI, didn't we turn that out on purpose, is that a bug?
<seb128> slangasek, ^ you might know? ;-)
<slangasek> seb128: the UI is not my department ;)
<seb128> slangasek, what about the hang on plymouth? ;-)
<slangasek> seb128: but as of the last TB discussion, there were unsolved issues that were considered blockers for re-adding 'hibernate' to the menu
<seb128> slangasek, I guess hibernate is a question for pitti, when he's back next week
<slangasek> seb128: well, I'm on vacation, so yes but no.  Maybe jodh can help?
<seb128> slangasek, thanks for pointing somebody, I was unsure who to ask, usually I would grab pitti but he's on vac as well
<seb128> slangasek, enjoy your days off work ;-)
<seb128> jodh, hey, can you help debugging the issue I described a bit earlier?
<jodh> seb128: hmm, just checked and my systemd vm is suffering similarly. looking... can you raise a bug meantime?
<seb128> jodh, sure, against what component?
<seb128> upstart?
<seb128> not sure what init system I'm using, I didn't do anything special, is systemd default yet in utopic?
<jodh> seb128: are you talking about a system booting with systemd here?
<infinity> Shouldn't be.
<jodh> seb128: no.
<jodh> seb128: ps -p1
<seb128> jodh, dunno, how do I tell what is booting? that's my laptop, I did no hacking around, just upgraded from trusty to utopic
<seb128>     1 ?        00:00:02 init
<jodh> seb128: that's upstart. I'm not seeing that issue then. Please raise an upstart bug for now then thanks.
<seb128> jodh, do you have any debug hints?
<seb128> I feel like that a bug report without details is not going to be useful, if you don't see the issue to be able to debug it
<jodh> seb128: get rid of 'quiet' and 'splash' to see if that fixes the problem. If not, it might show what is going on. If that doesn't help, you could maybe apply lp:~jamesodhunt/ubuntu/trusty/sysvinit/log-open-files-on-shutdown that never quit made it into the archive.
<seb128> k
<seb128> thanks
<arges> hallyn: hey. I noticed that kvm_stat wasn't packaged up in qemu. I created a patch to add it to qemu-utils. Any objections or comments? I can point you at a bug/patch soon if you'd like
<hallyn> arges: would you mind dropping by oftc#debian-qemu and dropping your debdiff there?  we may be syncing (at least at an svn level :) the debian+ubuntu qemu trees so may as well let him know asap
<arges> hallyn: would it be easier to submit a patch to debian? then post there?
<hallyn> arges: might be.  i mean if you want it asap i can always push it in and let it work its way up,
<arges> i'll submit the patch to debian and track it in ubuntu launchpad/debian bugs
<Laney> @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:
<arges> hallyn: so mjt is saying that kvm_stat is part of the qemu-kvm package, but in Ubuntu we don't install this. Is that the solution to just install qemu-kvm? or is that package deprecated?
<arges> the old qemu-kvm packages
<hallyn> arges: i don't see kvm_stat in qemu-kvm pkg.
<arges> hallyn: the older version of it apparently. Anyway I'm replying to the debian bug
<arges> s/apparently//
<arges> hallyn: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758042 fyi
<ubottu> Debian bug 758042 in qemu "qemu-kvm: add kvm_stat to qemu-utils package" [Wishlist,Open]
<hallyn> yeah i got the opening email, haven't re-fetched to ge tthe rest of the thread yet
<hallyn> oh, i think he means it's aprt of the qemu-kvm *source* pkg
<hallyn> in wheezy/squeeze
<hallyn> arges: ^ all is fine, he's right, debian will need a replaces in qemu to do it right, he's going to do it
<smoser> i've a question about /vmlinu? and /initrd.img.
<smoser> what is the expected behavior of those symlinks.
<smoser> do they point to the latest installed kernel or the newest (version compare-wise) kernel.
<dobey> now that gcc-4.9 is default, how do i "update" my sbuild utopic-amd64-armhf chroot to be able to cross compile again?
<hallyn> smoser: context?
<smoser> well, just what is it supposed to point to
<smoser> it points to *something*
<smoser> but i'm not sure what htat something is supposed to be.
<sarnold> whichever kernel the sysadmin wants to boot next, right?
<smoser> http://www.tin.org/bin/man.cgi?section=5&topic=kernel-img.conf
<smoser> i *think* says "latest installed". b
<israel_> Hi does anyone know of a library to convert X11 colornames to hexidecimal, or rgb?
<sladen> israel_: grep MistyRose /usr/share/X11/rgb.txt
<sladen> israel_: grep MistyRose /usr/share/X11/rgb.txt | awk '{printf("%02x%02x%02x\n",$1,$2,$3);}'
<israel_> sladen: Thanks, I am wondering if there is a library for C++... sorry I forgot to mention that, I had been asking on a different channel.
<asac> xnox: hey ho. wonder, whats the plan about https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot? are we still trying to get that out of proposed/
<asac> ?
<israel_> I can also use awk to get each column... but I really want something where I can feed in an x11 colorname and get out a hexcolor (or rgb...)
<asac> infinity: hey, i see https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot failed to upload on i386
<asac> do we need to give that back? can you do?
<asac> thanks
<sladen> israel_: XLookupColor(), returns *exact_def which are the RGB colours
<sladen> israel_: XLookupColor(), returns *exact_def which are the RGB colour values
<israel_> sladen: thanks So do I pass in something like  const char* color = "white"  and get out something like 255255255
<israel_> where can I find the documentation?
<infinity> asac: No.,
<infinity> asac: It failed to upload for good reason, retrying won't fix it.
<asac> infinity: ok, what's up there?
<infinity> asac: Looks like most of its binaries were replaced by llvm-toolchain-3.5
<infinity> asac: The upload log makes that fairly clear.
<asac> infinity: any suggested way forward?
<infinity> asac: Remove llvm-toolchain-snapshot?
<asac> infinity: yeah. guess so. thanks for finding the -3.5 thing
<infinity> asac: I assume you're not actually waiting on it for anything, since the bianries you probably care about are built from another source.
<asac> we have a regression during test build and it didnt make sense as that -snapshot thing was uploaded ages ago
<asac> but now i see the -3.5
<asac> was pushed yesterday by doko
<asac> https://launchpad.net/ubuntu/+source/llvm-toolchain-3.5
<asac> 1: Test timeout computed to be: 9.99988e+06
<asac> 1: LLVM ERROR: Do not know how to split the result of this operator!
<asac> https://launchpadlibrarian.net/182181736/buildlog_ubuntu-utopic-i386.messaging-app_0.1%2B14.10.20140813-0ubuntu1_FAILEDTOBUILD.txt.gz
<infinity> We're actually building with llvm?
<infinity> Are we masochists?
<asac> infinity: its used for graphics tests
<asac> infinity: not for building... we use a xvfb setup to do strong testing during build it seems
<asac> tvoss knows more
<infinity> Ahh, llvmpipe fun, not the compiler.
<asac> guess so (/me kind of detached from smart things :))
<doko> asac, mlankhorst identified a patch for 3.5 to fix i386. I don't know the current state
<asac> mlankhorst: ^
<doko> and synced the snapshot
<asac> doko: the -snapshot is in proposed since jul 25 ... guess thats not what he synced?
<asac> (thanks for coming back btw)
<tvoss> infinity, yup, likely llvm-pipe
<infinity> tvoss: Right, that's what I assumed when I actually read the log.
<infinity> tvoss: Which was slightly less scary than the idea that we're using llvm to compile things. :P
<tvoss> infinity, yup, I initially thought about something qml-ish or a shader-compilation in the qml engine, but xvfb is a strong hint towards llvmpipe
<infinity> Apologies to the Apple fanboys who are now silently frothing with rage.
<tvoss> infinity, yup
<asac> doko: any suggestion we could do to unblock landings of our UI software while we wait for mlankhorst ?
<infinity> asac: Your only three viable options are probably to find someone else to debug and fix llvm, wait for mlankhorst, or temporarily disable the testsuite with big red flashing warnings to turn it back on Very Soon.
<asac> infinity: yeah. thanks for confirming what i thought. any idea who knows enough about llvm that it might worst trying option 1. ?
<infinity> asac: I know some llvm, but llvmpipe is a complete black box to me.  My ramp up time would be far too long for your quick landing goal.  I imagine that's true of most of us.
<asac> infinity: general proposed question. i know that proposed runs reverse dependency autopkgtest one level up, right?
<asac> infinity: does it also do build testing?
<asac> one level up?
<infinity> asac: As in, rebuild all rdeps?  No.
<asac> infinity: kk thanks
<asac> thought so, just wanted to get confirm
<mlankhorst> infinity: I can't get that autopkgtest to run in a debugger, does autopilot3 have some debugger support for it?
<infinity> mlankhorst: Hrm?  The failing test is a build-time testsuite, not an autopkgtest.
<mlankhorst> yeah but it's triggered with autopkgtest too
<mlankhorst> autopilot3 run online_accounts_ui iirc
<infinity> Ahh, different test.
<mlankhorst> oh which one is failing?
<infinity> mlankhorst: This one might be easier for you to reproduce: https://launchpadlibrarian.net/182181736/buildlog_ubuntu-utopic-i386.messaging-app_0.1%2B14.10.20140813-0ubuntu1_FAILEDTOBUILD.txt.gz
<infinity> mlankhorst: Looks like a very clear xvfb call.
<mlankhorst> yeah more sane
<mlankhorst> seems more tests are failing atm then
<asac> could we somehow be sneaky and depend on llvm 3.4 thingy to make that build pass while we fix things?
<asac> mlankhorst: infinity: ?
<asac> (and thanks for coming back mlankhorst)
<saiarcot895> Wait, there's a plan to use the LLVM compiler for Ubuntu?
<infinity> saiarcot895: No.
<asac> depends on the defintion of plan and use i am sure :)
<infinity> I'm sticking with "no".
<asac> hehe
 * asac checks secret roadmap
<asac> infinity: mlankhorst: in case there is a build-depend trick for these packages to still build and land without disabling tests, please let pmcgowan; otherwise lets check tomorrow where we are
<asac> thanks
 * asac break
<mlankhorst> doko: mind if I revert to llvm 3.4 for now?
<sladen> israel_: https://gist.github.com/sladen/833d4d23d89aa12e9dc8
<doko> mlankhorst, sure, but please make sure that we do the switch for 14.10
<mlankhorst> doko: yeah this will make my 14.04.2 a lot easier for me too
<israel_> sladen: you are amazing!! thank you!!
<mlankhorst> but that will fail for that other arch right?
<mlankhorst> oh well hope it gets forced through..
<israel_> sladen: this is great, I can totally adapt this for my uses, and I will give you credit in the appropriate places :)
<mlankhorst> ok revert uploaded, mesa should be back to 3.4 soon-ish
<jtaylor> someone have an upstream gcc without ubuntu patches handy?
<xnox> asac: no, we llvm-toolchain-snapshot should not migrate at the moment. llvm-toolchain-3.5 superseeds all packages build by llvm-toolchain-snapshot.
<xnox> asac: once 3.6 snapshot is packaged, and synced it will migrate.
<xnox> asac: i see 3.6 snapshot in proposed now, so it should migrate.
<infinity> xnox: Backscroll contained all that info. ;)
<xnox> infinity: heh, fair enough =)
<xnox> infinity: just had enough time to read highlights alone...
<asac> xnox: ack. thx
#ubuntu-devel 2014-08-14
<mwhudson> argh
<mwhudson> is there some way i can easily hack about in a revision controlled dir (bzr or git i don't mind) and turn my local commits into patches in debian/patches?
<mwhudson> (only the parts of my local commits that don't touch debian/ obv.)
<sarnold> mwhudson: it's not what you asked for, but 'quilt shell' may come close to giving you something that works
<mwhudson> erm
<mwhudson> i guess so
<darkxst> mwhudson, you can use gbp-pq to create a branch with all debian patches applied as commits
<hallyn> sarnold: are you by chance an apport guru?
<jakesyl> hey guys i've been looking to help out with ubuntu dev and already know a considerable amount of python, but what other languages should i learn? x86?
<RAOF> jakesyl: If by âx86â you meanÂ âx86 assemblerâ, then that's a pretty low-return investment of learning :)
<RAOF> jakesyl: The answer, as with everything open-source is: what do you want to do? âº
<jakesyl> i learn for the sake of learning, and of course applying my learning to a worthy cause, so what can i learn to be of most assistance RAOF
<RAOF> Because that will determine what you'll need to know. Want to hack on GNOME Do? You'll need to know (or learn) C#. Lots of the Ubuntu tools are written in Python, so you could help there already; Ubuntu Touch uses QML / Qt, for which a dialect of C++ can be useful.
<RAOF> It's sort of like going up to a science department and saying âI'd like to help in science; what can I learn to be most usefulâ :)
<StevenK> RAOF: Install a power-mad AI and get her to do the science, obviously.
<RAOF> Generally the best way to help is to find something that doesn't work the way you want, or is broken in some way, and fix it :)
<jakesyl> eh RAOF, hypothetically if i wanted to build an ubuntu like os from scratch, what would i need to know
<rww> StevenK: I vaguely recall popular culture telling me that this ends badly with cake and lies and such.
<StevenK> rww: :-)
<jakesyl> big hypothetical
<RAOF> jakesyl: Depends on what you mean by both âfrom scratchâ and âUbuntu-like OSâ.
<jakesyl> RAOF, i mean completely from scratch, as in an ubuntu iso
<jakesyl> and general linux
<RAOF> Well, we've got tools to do that :)
<RAOF> But from the raw upstream source you'd need to know a whole bunch of system administration, because you're going to be running a build farm.
<jakesyl> what languages?
<RAOF> That's kindof the wrong question :)
<jakesyl> hmm why?
<RAOF> But you'll be dealing with everything from raw assembly of whichever architectures you're interested in to compilers for the same, to C, C++, python, ruby, perl, C#, Java...
<jakesyl> RAOF, perhaps a little context, i'm 15 i've been writing perl since i was 8 finally decided it was a dead language, i still wrote python wrappers in perl, and i'm just now realizing i should move on
<RAOF> jakesyl: The most useful way to learn is to find a (coding) project that needs help (which is basically everything!) and work on it. Which project you help determines what you need to learn.
<RAOF> (Although the chances of needing to learn x86 assembler are very low âº)
<jakesyl> so what would i need x86 for
<RAOF> Work on compilers or runtimes, mainly.
<jakesyl> RAOF, the reason i ask is ever mentor i've ever had brags about memorizing hex tables
<jakesyl> hmm RAOF, if i wanted to do a ui/ux overhaul and just make it look cleaner, what would i need to learn?
<RAOF> Those sound like some sucky mentors :(
<RAOF> So, choices!
<jakesyl> well either that or a universal package manager
<RAOF> If you want to work on the actual UI toolkits - that'd be Qt and GTK - you'll be wanting C++ and C(ish)/Vala, respectively.
<RAOF> To work on applications, you get to pick an application and find out what it uses :)
<jakesyl> but there's no uni package manager is there?
<rww> there are too many universal package managers. someone is going to end up making a universal universal package manager
<jakesyl> rww, i've never seen a seamless one tho, now i'm not an apple fanboy, i'm on ubuntu, but the seamless integration is what i want, click on the package it opens, is there anything like that?
<RAOF> Yes; gdebi
<RAOF> Or do you not want to install things?
<jakesyl> why doesn't it come pre installed?
<RAOF> It does.
<RAOF> (I think?)
<jakesyl> so how come when i click an application it doesnt just open
<rww> RAOF: it's in universe, so I assume not
<RAOF> Oh, of course. Software Centre does that now.
<RAOF> jakesyl: What do you mean by âan applicationâ? :)
<Mirv> if a core dev is around, unity8 CI Train release would need a packaging ack for their debian/ changes https://ci-train.ubuntu.com/job/landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity8_8.00+14.10.20140814.1-0ubuntu1.diff
<RAOF> We *don't* have application bundles ala OS X, but that's not a technical problem.
<geofft> I think the click-packages stuff is also relevant here?
 * RAOF looks at that packaging diff
<jakesyl> metasploit is a great example, i download metasploit i hit the package it should auto install and i understand how to do it but it should be seamless should it not?
<RAOF> If you download an Ubuntu package and double click on it it *will* install (or, rather, it'll come up in the Software Centre asking if you want to install it)
<jakesyl> okay so i guess i'll focus on ux
<RAOF> Mirv: That looks fine.
<Mirv> RAOF: thanks!
<sarnold> hallyn: sorry, I don't know much about apport
<dholbach> good morning
<dholbach> does anyone of the Canonical folks know if there's an arm64 porter box?
<slangasek> dholbach: there is not; there's an open RT for one
<dholbach> all right, thanks
<slangasek> (there are physical boxes but they're not yet provisioned as a porter box)
<LocutusOfBorg1> hi dholbach, were you looking for the arm64 porter because of wxwidgets3.0?
<LocutusOfBorg1> (the build has been successful)
<LocutusOfBorg1> thanks ;)
<dholbach> LocutusOfBorg1, indeed I was - in the end I trusted your build log and knew I could find you if things exploded :)
<LocutusOfBorg1> oh yes ;)
<LocutusOfBorg1> feel free to mail me, or to find me there, and the fix was quite trivial anyway (disable the precompiled headers), fortunately the bug has been fixed in gcc
<dholbach> cool
<LocutusOfBorg1> BTW I never been able to reproduce in pbuilder/arm64 so I guess the old buildd lp system was just buggy, again a great thanks to cjwatson :D
<tjaalton> is there a way to force dch to not append the ubuntu version?
<tjaalton> in a conffile
<LocutusOfBorg1> tjaalton, the man says probably DEBCHANGE_VENDOR
<LocutusOfBorg1> "dch --vendor debian"
<tjaalton> hm indeed
<tjaalton> just need an alias then
<LocutusOfBorg1> I think so and I think I'll need it too ;)
<LocutusOfBorg1> it is annoying sometimes :)
<tjaalton> especially when you later notice that debcommit pushed it to $vcs.. to a debian branch
<LocutusOfBorg1> argh
<LocutusOfBorg1> dholbach, I opened two bugs for you ;) sorry
<dholbach> LocutusOfBorg1, not necessarily just for me, right? :)
<LocutusOfBorg1> no dholbach :) but you rock in merging/syncing lol
<dholbach> haha
<dholbach> I need to take care of a few other things first - if nobody beats me to it, I might have a look later on
<LocutusOfBorg1> wonderful!!!
<LocutusOfBorg1> I really would like to fix the wx2.8 and wxpython3.0 stuff
<doko> dobey, ubuntu-sso-client finally \o/
<Laney> doko: any objection to taking pcre3 8.35?
<doko> Laney, not at all
<Laney> cool
<Laney> infinity: your merge, can I steal it?
<infinity> Laney: My merge of what?
<infinity> Laney: Oh, pcre3?  Go nuts.
<Laney> Tah
<rbasak> xnox: bug 1355992 claims the last samba merge inadvertently dropped an upstream cherry-pick. Please could you take a look?
<ubottu> bug 1355992 in samba (Ubuntu) " pam_winbind krb5_ccache_type=FILE stopped working after 14.10 upgrade" [Undecided,New] https://launchpad.net/bugs/1355992
<halfie> sudo aa-genprof /usr/bin/vim results in "TypeError: 'bool' object does not support item assignment"
<halfie> the AppArmor user space seems to be in a terrible state
<rbasak> I think the genprof issue is known about
<rbasak> AIUI, it's limited to genprof.
<rbasak> jjohansen: ^^
<halfie> I thought that AppArmor was like a bullet-proof production ready thing ;(
<halfie> I guess I will have to go with SELinux (on Ubuntu!)
<lullis> Hi, all. I have a few questions regarding (I think) lightdm customization. Basically, I am working on a system that needs to provide remote authentication. And to do that, the user needs to be able to (1) set up the network connection and (2) be able to also "register" directly on the greeter screen.
<lullis> My questions would be: regarding (1), can I add the NM applet to top bar of any the (gtk/unity) greeters?
<lullis> regarding (1) and (2), I have a python/GTK application that handles the setting up a new account on the remote server. How hard would it be to change the C greeters to add a handler that starts my python code?
<doko> jpds, strongswan ftbfs on armhf and powerpc. any reason not to use libgcrypt20?
<lullis> And also, is any better place to ask these questions?
<rbasak> halfie: AppArmor is production ready, and has been used in production for many years. I wasn't aware you were talking of a production release. No idea about that, but genprof is a helper and not a production piece.
<rbasak> halfie: try #ubuntu-hardened for apparmor discussion. The security folks listen in in there.
<jpds> doko: Upstream still has to figure it out: https://wiki.strongswan.org/issues/674
<doko> jpds, please can you try building with -O2 on ppc64el?
<jpds> doko: Ah, upstream just pinged me and we were doing a git bisect on a porter box.
<doko> jpds, but up to now, all test failures seen with -O3 did point to invalid source code ...
<jpds> doko: Upstream says -O2 is the default in the configure script.
<doko> jpds, and?
<doko> ppc64el is built with -O3 as the default
<halfie> hi, I am trying to download all utopic package and the debug information packages for some offline analysis. how do I go about it? Currently I am using debmirror.
<rbasak> halfie: debug packages are at ddebs.ubuntu.com. The rest is as your sources.list says for utopic.
<halfie> rbasak, ah, I see. is there a way to mirror the debug packages for utopic only? I guess I could try using debmirror for it?
<rbasak> halfie: just mirror ddebs.ubuntu.com I guess?
<halfie> rbasak, it will be too large :)
<rbasak> halfie: well, the rest is up to your mirroring tool. debmirror can filter as needed.
<halfie> ok, giving it a shot now
<tedg> ev, Would you be opposed to us not filtering fields on recoverable errors in Whoopsie?
<lamont`> has anyone run into grub_isprint not found (and the subsequent bail into grub rescue) on a machine upgraded from saucy to trusty? (did this last night, not so wonderfull)
<lamont`> didn't find anything in launchpad on the subject
<lamont`> nm.
<ev> tedg: very much opposed, given that people shove entire log files into these fields and cassandra does not do blob storage
<ev> what's the motivation?
<tedg> ev, Well for instance I have UAL have a recoverable error for "bad AppID" and then it has a custom field with the appid that was bad. Not getting that custom field.
<tedg> ev, https://errors.ubuntu.com/bucket/?id=ubuntu-app-launch-invalid-appid
<tedg> ev, Can we switch to Mongo? I hear it has all the features.
<tedg> ev, Seems like we could filter by size instead of a white list?
<ev> suggest mongo again and I'll come find you
<ev> tedg: sometimes we have big fields we want to carefully split
<ev> like Stacktrace :)
<tedg> ev, Sure, so let the whitelist be to avoid the size limits not to be in/out.
<tedg> ev, So, < 1KB or in whitelist
<ev> so any field below a certain size plus these big ones we care about?
<ev> yeah
<ev> works for me
<ev> I'll +1 that MP
<ev> but remind me I said this :)
<tedg> ev, K, I'll work on that MP
<tedg> ev, I'll remind you daily :-)
<ev> lol
<tedg> ev, I don't know cassandra, is 1KB reasonable?
<ev> yeah, I think the barrier (for Thrift) is 16 MB, but the other thing I'm trying to avoid is quickly growing the database when the IS team responsible for getting us out of the ENOSPC hole has been moved onto other top secret projects
<ev> so we can start at 1K and increase from there
<ev> tedg: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Increasing-thrift-framed-transport-size-in-mb-td6825655.html
<tedg> ev, Oooh, secret projects. 1KB I think works for my usecases.
<ev> note that we're on cassandra 1.0.lulz, so anything you read about 1.2, 2.0 or whatever is a pipe dream at this point
 * tedg wonders what else would break if an appid was 1KB in length
<dpm> hi sarnold, would you mind doing a final review to the File Manager security checks MP? We've got the AP tests working now, and Arto did a couple of tweaks to the code. You gave your +1 already, but it'd be good to have a final sanity check after the last few changes
<dpm> https://code.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/require-screenlock-password/+merge/230058
<tjaalton> shouldn't sbuild/schroot clean up stuff from /tmp too after exiting the chroot?
<Unit193> cjwatson: Hello!  Not sure if you're back from VAC, but just a bump on tasksel refresh?
<mdeslaur> doko: mind if I merge subversion?
<doko> mdeslaur, not at all. can you apply the patch from 1353142 and revert to -O3?
<mdeslaur> doko: sure
<jtaylor> doko: mind if I do numpy?
<doko> jtaylor, sure. did you see may scipy workaround?
<jtaylor> no?
<jtaylor> I wanted to check that out this weekend
<jtaylor> also needs another fix for statsmodels
<doko> are you at debconf?
<jtaylor> no
<doko> http://launchpadlibrarian.net/182175661/python-scipy_0.14.0-1_0.14.0-1ubuntu1.diff.gz
<jtaylor> I wonder why that is failing, I did test i386 for the 0.14 upload
<jtaylor> also seems to work in debian
<jtaylor> maybe gcc-4.9?
<jtaylor> I'll look at it later
<doko> yep, but it's i386, and I didn't care too much, therefore the ignore
<jtaylor> yes i386 fails numeric tests all the time
<jtaylor> doko: I filed a bug about gcc dropping -ltsan https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62105
<ubottu> gcc bug 62105 in driver "sanitizer libraries in wrong command line position in link spec file" [Normal,Unconfirmed]
<jtaylor> not much useful information yet but possibly we have to add --no-as-needed in the ubuntu package
<doko> jtaylor, maybe, but since today we can use --push-state and --pop-state
<doko> see the ld docs
<jtaylor> uh thats neat
<jtaylor> doko: in case you want to sponsor, bug 1357044
<ubottu> bug 1357044 in python-numpy (Ubuntu) "merge numy 1.8.2-1 from debian unstable" [Undecided,New] https://launchpad.net/bugs/1357044
<mwhudson> darkxst: hm, thanks
<mwhudson> i found gbp completely confusing last time i looked at it, but gbp pq seems sensible on a very quick look...
<doko> jtaylor, merged
<jtaylor> thx
<hallyn> so, i have /usr/share/apport/package-hooks/source_qemu.py , but it doesn't get called when qemu-system-x86 crashes (that is, i kill it manually with kill -11).  Am I supposed to do something else?  Register it somehow?
#ubuntu-devel 2014-08-15
<asac> cyphermox_: how can i mount nexus 4 storage properly?
<asac> cyphermox_: like not the face nautilus stuff so i can use cd etc.
<asac> cyphermox_: guess first i have to prevent nautilus to not deal with this?
<asac> guess on -touch better
<dholbach> good morning
<Tribaal> hi dholbach
<dholbach> hi Tribaal
<doko_> jtaylor, matplotlib tests start failing: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-matplotlib/lastBuild
<Tribaal> hi all - I need my package to create a /var/log/mypackage directory - what's the recommended way to do it? postinst?
<Tribaal> I feel there should certainly be a "better" way to do it since it seems like such a common thing to do...
<Tribaal> or should I use a debian/mypackage.dirs file?
 * Tribaal is confused
<seb128> Tribaal, that works yes
<Tribaal> seb128: what's the recommended way to do it then?
<seb128> Tribaal, not sure there is only "one recommended" way
<seb128> you could make the make install from your software create it, create it from the rules, from a .dirs, etc
<Tribaal> seb128: so either is fine? Nice. I'll go for the mypackage.dirs option then, seems easy enough
<Tribaal> ok
<Tribaal> less work = win
<jtaylor> doko_: seems wxversion is 3.0 but it the rest 2.8
<jtaylor> which I do not understand, there is no wxversion 3.0
<jtaylor> has it been removed from proposed?
<doko_> jtaylor, no, there is a new version in proposed
<jtaylor> not of 3.0
<jtaylor> oh its from another source pacakge
<jtaylor> ScottK: what are your plans with the wxpy 3 transition now that you changed wxversion to 3.0?=
<jtaylor> rebuild everything against 3.0?
<Mirv> anyone else noticing PPA uploads going to /dev/null and no e-mail about acceptance/rejection?
<Mirv> from some other uploads it's just me, hmm hmm
<Mirv> unless that I'm uploading for trusty series instead of utopic matters
<sveinse> Hi. There is no more firmware-libertas in trusty and I cannot find the firmware binary files in any other package either. Anyone can recollect why this has happened?
 * Mirv found the reason, finally. using a wrong GPG key apparently results in silence.
<Mirv> sveinse: maybe they were collected to the linux-firmware package? dpkg -L linux-firmware | grep libertas lists a lot for me
<sveinse> Mirv, I am looking for sd8686.bin, but unless this has been renamed to something else, it is not found in the linux-firmware package IFAICS
<Mirv> sveinse: I see sd8686_v9.bin and v8 at least (although I'm on 14.10)
<directhex> i see sd8688.bin
<directhex> sd8686_v8.bin and sd8686_v9.bin too
<sveinse> Mirv, directhex: ah, there it is. Thanks
<rbasak> xnox: bug 1355992 claims the last samba merge inadvertently dropped an upstream cherry-pick. Please could you take a look?
<ubottu> bug 1355992 in samba (Ubuntu) " pam_winbind krb5_ccache_type=FILE stopped working after 14.10 upgrade" [Undecided,New] https://launchpad.net/bugs/1355992
<ScottK> jtaylor: I don't have a plan, I just fixed an FTBFS.
<ScottK> Mirv: I can confirm using the wrong GPG key gets silence.  I've done it before.
<infinity> jodh: You around?
<infinity> jodh: LP: #901038 is a much nastier bug than the severity implies.
<ubottu> Launchpad bug 901038 in upstart (Ubuntu) "packages fail to install: Failed to connect to socket /com/ubuntu/upstart: Connection refused" [High,Confirmed] https://launchpad.net/bugs/901038
<infinity> jodh: Pretty much anything that does a 'telinit u' on upgrade just explodes very unintuitively, and it takes a Very Long Time to get back to a sane enough state that retrying the upgrade fixes it.
<infinity> jodh: Like, well over a minute on the machines I'm doing this on right now.
<infinity> jodh: So, I think having 'telinit u' block until completion is correct, but it would also be good to sort out WHY this takes so long.  I'd expect it to be seconds (or less than a second), not minutes.
<infinity> Riddell: Ahh, good ol' ppc54el. :P
<Riddell> by the ubuntu7 upload my typing is showing my frustration!
<infinity> :)
<asac> however, i tested multiple times yesterday and dont know why, but i never 99had the big time lag in the indicator/infographics screen
<asac> but sure its still there
<asac> oops
<asac> :)
<doko> asac, Mirv, whoever: unity-scope-click autopkg tests fail. is this being worked on? blocks gcc-4.9
<doko> tvoss, ^^^
<ogra_> doko, talk to the lander (marked on the landing spreadsheet)
<infinity> ogra_: "The lander" is a pretty opaque thing to people working on the distro.
<asac> truish
<ogra_> infinity, well, it is the name that is in the column named "lander"
<ogra_> :P
<asac> hehe
<asac> ogra_: where is the landing log again?
<ogra_> you mean the spreadsheet URL ?
<infinity> ogra_: Yeah, I'll reiterate the above.  That column doesn't exist to someone working on the distro. :P
<ogra_> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&pli=1#gid=0
<ogra_> now it does :P
<infinity> ogra_: And encouraging people to look things up on a spreadsheet at a magic URL won't help it go away or get fixed properly.
 * infinity shrugs.
<infinity> Anyhow, this one has nothing to do with "the lander", it looks like a dep of unity-scope-click stopped linking pthread, and it needs to explicitly link it itself.
<infinity> So, anyone upstream would do.
<ogra_> infinity, so who else would you expect to look up the name of the person you want to talk to ?
<infinity> ogra_: I'd expect the uploader recorded in LP to not be a bot, but I've beaten this horse a few thousand times.
<ogra_> ther is a person that is responsible for getting this package into the archive ... the name of that person is noted down in the spreadsheet
<asac> changelog suggests Michal Hruby
<asac> Alejandro J. Cura (alecu)
<dobey> hrmm?
<infinity> dobey: Is your perking up you volunteering to take ownership of unity-scope-click sucking at linking? :)
<dobey> infinity: it's a "what is the problem exactly?" :)
<infinity> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/artifact/results/log
<asac> ogra_: where? i dont see the list of component owners in there anymore
<infinity> dobey: Missing a -pthread or -lpthread
<infinity> dobey: Which it was likely always missing, but a transitive dep probably pulled it in and recently stopped doing so.
<ogra_> asac, the first column ?
<dobey> weird
<asac> ogra_: well, that requires you to be lucky and find a landing of this component
<ogra_> asac, so you want package names ?
<asac> ogra_: searching unity-click yields nothing on pending nor archive for me :)
<ogra_> ask sil2100 :)
<infinity> ogra_: No, more info on the spreadsheet isn't helpful, we need to fix this so we can actually track from LP/changes.
<asac> infinity: doko: check with your teammate... we also have a landing commitlog that has the info: http://people.canonical.com/~lzemczak/landing-team/
<infinity> Having a spreadsheet that grows infinitely so I can do an upload blame for a package from 8 months ago isn't sane.
<ogra_> asac, thats post landing
<asac> think having a concatenated log that has all landings would be nice for these things until better solution arises
<infinity> ogra_: This is all post-landing.
<asac> ah in proposed its still in pending?
<ogra_> the package in question hangs before entering the archive
<infinity> ogra_: The package is in the archive.
<ogra_> wint show up in that changelog
<dobey> infinity: hmm, what triggered this autopkgtest?
<infinity> dobey: gcc-4.9 upload.
<lullis> Hello, all. I have a few questions regarding (I think) lightdm. I am looking for a way to allow users to authenticate remotely, but first of all they need to get a connection to a OpenVPN Server.
<ogra_> infinity, yu mean it is in the release pocketalready ?
<doko> but the test doesn't compile anything afaics
<infinity> ogra_: Yes.
<ogra_> oh, i thought it is stuck in autopkgtests
<infinity> doko: It... Compiles lots of things?
<dobey> infinity: weird
<lullis> I was looking at the docs for lightdm, but it does not provide anything related to network connections, so my guess is that any of current greeters won't be able to have a "network applet". Is that correct?
<infinity> ogra_: No, it's an autopkgtest regression, probably due to dep churn.
<dobey> infinity: the same package passed under the glibc upload.
<infinity> dobey: The glibc upload that's older than the package?
<dobey> according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html anyway
<ogra_> infinity, ok
<dobey> 2.19-4ubuntu2
<infinity> dobey: Yeah, I'm not sure what you're driving at.
<infinity> dobey: That glibc upload was in July.
<infinity> dobey: This new autopkgtest triggered today.
<doko> yep, but once it fails, and once it suceeds. it references the very same autpkg run
<dobey> infinity: i mean, the only thing i see that changed is gcc-4.9. i'd like to understand why it had the -pthread before and now it doesn't
<infinity> doko: The reference is just bad UI.
<infinity> doko: It succeeded when it ran in July, the link just links to the latest.
<infinity> (so it becomes a stale lie)
<doko> dobey, ahh, that's a fix. where do you see this?
<infinity> It never had -pthread...
<infinity> It may have been pulling it in silently via a dep.
<doko> dobey, where do you see the problem?
<infinity> doko: In the test log?
<infinity> doko: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/artifact/results/log
<dobey> doko: in the test log
<dobey> infinity: and why wouldn't it still be doing that though, if the dep hasn't changed as well?
<infinity> doko: It's clearly missing a -pthread, but the latest build in the archive also doesn't have one there, so...
<infinity> doko: So, your assertion is that in the last 4 days, none of the 293 build deps changed?
<dobey> infinity: well, if the build-deps of unity-scope-click had changed, it would have caused an autopkgtest run, and it would have failed then, no?
<doko> infinity, dobey: so the change is that when using thread from libstdc++ it now always emits a reference to pthread_create, which it didn't before. meaning that problems are now catched at link time, and not at run time
<dobey> doko: ok, so libstdc++ change is the cause? that's what i wanted to know
<infinity> doko: Ahh, so this is an intentional change in g++/libstdc++ ... Kay.
<doko> dobey, not ok if you use this information to blame me ;-P  do you see where things are missing the -pthread?
<infinity> doko: That seems like something we might want to comb a rebuild test for once this is in.
<dobey> doko: i'm not blaming you. i'm just trying to understand why it worked before, and now it doesn't
<doko> infinity, https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01366.html
<ubottu> gcc bug 2014 in c++ "error in print_rtl_and_abort, at flow.c:6592" [Critical,Resolved: fixed]
<doko> dumb bot
<infinity> doko: And maybe a short note to -devel telling people that they might start seeing "undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'" in their C++ projects, and what that means.
<lullis> No one? Maybe someone could point me where to go to ask lightdm-specific questions?
<dholbach> lullis, you could try #ubuntu-desktop
<infinity> doko: The upstream change looks entirely sane and reasonable to me, just a bit unintuitive (as the last 5 minutes demonstrate), so a heads-up to -devel and a grep of the next rebuild test would both be good, IMO.
<infinity> dobey: Are you going to own hunting down which component actually needs the -pthread (unity-scope-click, or one of its deps, or both), and getting it fixed?
<infinity> dobey: Or delegate same to someone else. ;)
<lullis> dholbach, I imagine there it would be about dealing with configuration of existing greeters. What I am looking is to possibly understand how I would go around writing my own (adding an openvpn connection setup applet)
<lullis> I will try, though.
<dobey> infinity: i don't have much choice really. damn national holidays in europe and south america :)
<dholbach> lullis, the folks who wrote lightdm should be hanging out there
<doko> infinity, wanted to wait with the test rebuild until you had a chance to address https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1352836  afaiu this is pending upstream, I have the gcc backport done
<ubottu> Launchpad bug 1352836 in gcc-4.9 (Ubuntu) "link failure when package is built with -O3 (14.10)" [High,Confirmed]
<doko> jtaylor, ScottK: did you come to any conclusion about the missing wx.py?
<jtaylor> doko: I filed an RC bug in debian
<jtaylor> lets see what debian does
<jtaylor> debian bug 758209
<ubottu> Debian bug 758209 in wxpython3.0 "wxpython3.0: cannot import 2.8 anymore" [Serious,Open] http://bugs.debian.org/758209
<jtaylor> can we force numpy into utopic? the matplotlib failure has nothing to do with it
<dobey> doko, infinity: https://code.launchpad.net/~dobey/unity-scope-click/explicit-pthread/+merge/230973 looks correct?
<infinity> dobey: Except for the unnecessary whitespace change, sure.
<infinity> dobey: Assuming it works.
<doko> dobey, well, usually you build with -pthread in both CFLAGS and LDFLAGS
<infinity> -lpthread should work fine.
<doko> sure
<infinity> And it's used other places in the same codebase.
<infinity> So, meh.
<infinity> dobey: Might be prettier with some CMakey macro.
<doko> jtaylor, we can blame dholbach for sponsoring these packages ;-P
<infinity> dobey: The tests use "${CMAKE_THREAD_LIBS_INIT}", not sure how that expands, or what exactly it does.
<dobey> oh
<infinity> dobey: But the tests do seem to be built with -lpthread, while the failing bit isn't.
<infinity> dobey: So, that might be the "right" CMakey way to do it.  I dunno.
<dobey> changed it to that
<jtaylor> I guess we could change matplotlib to wx 3.0
<jtaylor> though I would prefer todo that for all packages at once to avoid tcl/tk like issues
<infinity> dobey: I'd still nitpick the whitespace change, but otherwise looks alright.  Going to test build to make sure.
<doko> jtaylor, it even fails when pyhton-wxgtk3.0 is installed
<jtaylor> oh I didn't try that
<dobey> infinity: well, i was tempted to fix all the other weird whitespace in that file too, but only did this since i was changing the target_link_libraries call :)
<jtaylor> doko: hm in unstable the import works
<infinity> dobey: Sure, I'm just from the anal-retentive world where whitespace fixes and bugfixes shouldn't be the same commit.
<jtaylor> maybe one has to do a --reinstall python-wxversion you had to do these things when having 2.6 and 2.8 installed
<infinity> (So, ie: it's obvious that the 1-liner that fixed the bug is just one line)
<dobey> infinity: so am i, but more lenient for very small changes.
<pete-woods> jdstrand: hi. are you able to get the easyprof release you made yesterday into RTM?
<jodh> infinity: As the bug shhows, we can't actually have telinit block - would have to poll indefinitely attempting to reconnect (ugh).
<jodh> infinity: I don't understand why you are seeing stateful re-exec take so long - even on a system with hundreds of running jobs it should be almost instantaneous.
<infinity> jodh: arm64, though I can't see why that should make a difference.
<infinity> jodh: Nothing running except a few idle daemons.
<jodh> infinity: if you can recreate (I can't - tried a few times), can you add some further details to the bug?
<infinity> jodh: I can reproduce on a whim, yeah.  What details are you looking for?
<infinity> jodh: and what do you mean we can't have telinit block?  That's the only sensible thing for it to do.
<jodh> infinity: can you try running http://people.canonical.com/~jhunt/upstart/scripts/get_state.sh and seeing how long that takes to run?
<jodh> infinity: telinit connects to upstart via dbus and asks it to re-exec. On re-exec, upstart severs all dbus clients connections (of which telinit is one :-)
<jodh> infinity: it's all on the bug dude
<jodh> infinity: I wonder if for some reason the performance of libjson on arm64 is poor?
<infinity> jodh: The bug implies what I'm asking for, though.
<infinity> "a better solution to modifying initctl would probably be to modify telinit such that it runs fully synchronous when a restart is requested"
<doko> jtaylor, I don't understand that alternatives business, because: $ cat /usr/lib/python2.7/dist-packages/wx.pth
<doko> wx-3.0-gtk2
<doko> this is hard coded in python-wxversion
<jtaylor> I never understood it either, I was very happy when 2.6 disappeared and the problem was gone
<jtaylor> now its back :(
<jodh> infinity: yes, well the telinit command would certainly block whilst we poll, waiting for the re-exec to finish.
<infinity> jodh: Right, which is what we want.
<jodh> infinity: Yes, it's not ideal, but until dbus allows a connection to be serialised I think it's the best we can do (tm)
<jodh> infinity: I'm tempted to throw in a magic variable that if set disables the blocking op as a 'get out of jail card'
<infinity> Oh, FFS, now 'telinit u' works instantly.
<infinity> I bet it's because I rebooted all these machines after the upgrades. :(
<jodh> infinity: I've tried 4 upgrades and all worked flawlessly. sorry :)
<jodh> infinity: upstart just hates you
<infinity> Ah-ha, I left one of them not rebooted.
<infinity> It still has the slow re-exec.
<infinity> We win.
<infinity> jodh: So, this could point to a leak or something, if a fresh boot is happy, but an older system isn't.
<jodh> infinity: ah - a thought occurs. Do any of the jobs use the 'debug' stanza?
<infinity> jodh: Not that I see.
<infinity> dobey: That still fails the same way, FWIW.  So, maybe that Cmake thing doesn't do what we thought, and the explicit link would work better?
<doko> great packaging ...
<doko> cd thirdparty; tar xzf desktop-0.4.2.tar.gz --strip-components=1 -C ../taskcoachlib/thirdparty desktop-0.4.2/desktop
<doko> cp /usr/share/pyshared/lockfile.py taskcoachlib/thirdparty
<doko> cp: cannot stat '/usr/share/pyshared/lockfile.py': No such file or directory
<doko> Makefile:181: recipe for target 'thirdpartymodules' failed
<doko> make[3]: *** [thirdpartymodules] Error 1
<dobey> infinity: weird
<dobey> infinity: so the tests aren't getting -pthread/-lpthread either?
<infinity> jodh: Oh dear, get_state is a lot of vomit. :P
<infinity> dobey: No, the tests do...
<infinity> dobey: As the build logs show.
<jodh> infinity: get_state.sh | json_pp > /tmp/upstart.state
<jodh> infinity: if you can send me that file along with a get_state.sh run for an amd64 system unaffected that would be useful.
<infinity> jodh: Adding json_pp to that pipe makes it take a lot longer, could definitely back up your arm64 json performance assertion.
<dobey> wtf
<dobey> infinity: ah, needs the find_package() in there too
<jodh> infinity: I'll send you a json test prog to check performance...
<infinity> jodh: Getting you your outputs.
<jodh> infinity: ta
<infinity> The filesize differences are shocking. :P
<dobey> infinity: so i just pushed the addition of the find_package(), so it should work now
<infinity> jodh: http://lucifer.0c3.net/~adconrad/upstart/
<infinity> jodh: good returns in under a second, bad takes well over a minute.
<jodh> infinity: wow. thanks.
<tedg> jodh, I'm kinda curious if bug 1357252 is the same cgroup error Chipaca was talking about yesterday.
<ubottu> bug 1357252 in Ubuntu Application Launcher ""Application failed to start." during autopilot tests after the newest ubuntu-app-launch landing" [Undecided,New] https://launchpad.net/bugs/1357252
<infinity> jodh: Both hosts run exactly the same things, the only difference is that one was just rebooted, the other's been up 53 days and lived through some re-execs.
<tedg> jodh, When do you expect the better error reporting there to land?
<hallyn> hm, what does
<hallyn> W: qemu source: virtual-package-depends-without-real-package-depends build-depends: gnutls-dev
<hallyn> mean.   apt-cache seems to disaree
<infinity> dobey: Testing that.
<jodh> infinity: hmm - I don't think it's the performance of the json parser per se - look at the file size difference!
<infinity> jodh: Right, it's huge.
<infinity> jodh: And all 5 of these hosts were in, I presume, the same state, until 4 were rebooted.
<infinity> (The fifth is 14h into a webkit build, hence why I didn't reboot yet)
<jodh> infinity: running json_pp on upstart_vomit.bad is taking almost an entire cpu on my system (been running for 20 odd seconds so far)...
<hallyn> 'sudo apt-get install gnutls-dev' does do th right thing...  so i guess i can ignore that
<infinity> jodh: Anyhow, clearly two very unrelated bugs here, but this highlights why telinit blocking needs to happen.
<infinity> jodh: But it would also be smashing to sort out why my state grew so large and make that not happen again. :P
<infinity> jodh: Being buildds (constantly tearing down and setting up chroots) might relate, though I'd have assumed my last-minute --disable-sessions default swap would have made that a non-issue.
<jodh> infinity: ack. looking at the bad file, you seem to have 591,355 lines of job definition whereas my system has ~1000 lines :)
 * jodh goes to get a strong cup of tea...
<infinity> jodh: Would it be helpful if I keep the sad system in its sad state, in case you need more info, or can I reboot it at my leisure?
<infinity> dobey: That fixes it.
<infinity> dobey: Commented on the MP.
<dobey> thanks
<rbasak> slangasek: please could you review bug 1357003 wearing your ~ubuntu-sru hat? This would be a violation of the micro-release exception, so upstream have asked in advance and I've filed at as a regular SRU-type bug. Upstream would like to know Ubuntu's position to help make a decision.
<ubottu> bug 1357003 in mysql-5.5 (Ubuntu Trusty) ""SET GLOBAL sql_log_bin" causes data loss" [Medium,Triaged] https://launchpad.net/bugs/1357003
<dobey> now to get it landed
<jdstrand> pete-woods: I'll see what I can do (/me needs to review the procedures still)
<pete-woods> jdstrand: thanks :)
<jodh> infinity: would be useful if you could keep it for a while if not too inconvenient.
<jodh> infinity: how many chroots have you got on the bad system?
<rbasak> I'm ready to land mysql-5.6 in Utopic, to replace mysql-5.5 completely. This involves switching some binary packages over from being built from 5.5 to being built from the 5.6 source package.
<rbasak> The upgrade path works easiest when the mysql-5.5 packages all disappear at the same time as 5.6 appears. Otherwise apt-get seems to want to remove the mysql-server metapackage.
<rbasak> (rather than remove mysql-server-5.5).
<rbasak> So, please could I have a hand from an archive admin so that we can maybe remove mysql-5.5 binaries in the same publisher run that 5.6 appears?
<rbasak> Or should I handle this in some other way?
<dobey> infinity: it's building in a silo now
<tedg> jodh, any ideas on bug 1357252
<ubottu> bug 1357252 in Ubuntu Application Launcher ""Application failed to start." during autopilot tests after the newest ubuntu-app-launch landing" [Critical,Triaged] https://launchpad.net/bugs/1357252
<jodh> tedg: just updated the bug - we need more debug :)
<rbasak> stgraber: around? I'm still waiting on https://lists.ubuntu.com/archives/devel-permissions/2014-August/000711.html. Seems like an unnecessary addition to the sponsorship queue.
<tedg> jodh, Were you able to try locally? It might be easier to reproduce there.
<slangasek> rbasak: replied on the bug (+1 from me)
<rbasak> slangasek: thank you!
<jodh> tedg: can you give me an example cmdline to trigger the prob?
<tedg> jodh, Let me find it, I'm pretty sure there's a wiki page with info.
<tedg> jodh, https://wiki.ubuntu.com/Touch/Testing/ phablet-test-run -p ubuntu-ui-toolkit-autopilot ubuntuuitoolkit
<jodh> tedg: thanks
<stgraber> rbasak: this is an auto-generated packageset, we don't do manual additions to it.
<stgraber> Laney: can you run the script see if that adds what rbasak needs? ^
<rbasak> stgraber: yes you do. There have been many instances in the past.
<Laney> rbasak: I just ran the script right now
<stgraber> rbasak: we did in the past because the script was broken for like a year :)
<Laney> you need to add an exception for this if you want to
<stgraber> rbasak: now any manual change I do will get reverted when we run the script. We have a list of exceptions in the script itself, though that shouldn't be needed for seeded packages since that's precisely what the script is meant to base the packageset on :)
<Laney> or seed it somewhere
<Laney> like platform/supported-server
<rbasak> Hmm, OK. I still can't upload, but I'll see if I can in a few minutes.
<Laney> It didn't get added
<rbasak> It's seeded in http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.utopic/supported under "Extra server bits"
<stgraber> ok, that's not a server seed so that explains why it's not pulled into your set
<stgraber> Laney: can you add an exception for nginx?
<Laney> why not platform/supported-misc-servers?
<Laney> then it should get into https://bazaar.launchpad.net/~developer-membership-board/+junk/packageset/view/head:/packageset-report#L59
<stgraber> that'd actually sort of make sense
<rbasak> Laney: I'm not sure I understand the distinction
<rbasak> (between "Extra server bits" and supported-misc-servers)
<rbasak> Apart from reporting and this script, of course.
<rbasak> Why does "Extra server bits" exist in the first place?
<stgraber> rbasak: one is a server seed, the other one isn't
<stgraber> no idea, possibly someone who didn't know to look into the platform.* seeds too :)
<stgraber> and then people just keeping adding stuff there :)
<rbasak> I have never understood the difference between platform.* and ubuntu.*. Is this documented anywhere?
<stgraber> supported seeds are pretty much used for 3 things, get suff in main, include things in the support declaration, package sets
<stgraber> so the main distinction I can think of in the past for ubuntu.*/supported vs platform.*/server-supported was that the former was supported for 3 years during LTS and the latter for 5 years during LTS, but none of that matters now since we don't do the different support length stuff anymore
<rbasak> infinity: ^^ you seeded nginx, I think, in bug 1262710? Do we want this in ubuntu.utopic/supported or in platform.utopic/supported-misc-servers?
<ubottu> bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Fix released] https://launchpad.net/bugs/1262710
<rbasak> Or shall we just move everything in that section across to platform.utopic/supported-misc-servers now that we have an actual reason to want it there?
<rbasak> stgraber: ah, that makes sense, thanks
<rbasak> So are we moving the seed or putting an exception in the script?
<dobey> infinity: so unity-scope-click is built in the silo now, and marked as tests passing, so will hopefully be published very soon.
<dobey> and i'm off to lunch
<stgraber> I'd prefer we move that chunk to the right seed
<rbasak> stgraber: would you mind committing that change, please? I can't.
<stgraber> that way further additions will likely be done at the right place too and we won't have to add even more exceptions to the script :)
<rbasak> Sounds good to me :)
<stgraber> done
<rbasak> Thank you!
<rbasak> Does that need the script re-running now?
<stgraber> yeah
<stgraber> Laney: can you re-run the script?
<Laney> Maybe, if --bzr works
<Laney> Otherwise it needs to wait for LP
<stgraber> Laney: oh, we're only using the tasks for that?
<Laney> germinate looks at people.c.c
<stgraber> ah, I can refresh people.c.c
<Laney> oh wait, already did
<Laney> nice
<stgraber> Laney: gah, "more than 25 entries", I need to get queuebot to pastebin the output in those cases :)
<stgraber> rbasak: can you try again now?
<rbasak> stgraber: "ubuntu-upload-permission" still says no.
<Laney> that was a previous run
<Laney> call it an amusing coincidence
<stgraber> yeah, interesting timing :)
<infinity> jodh: Only ever one chroot at a time, but they're constantly unpacked, set up, torn down, and deleted.  For every build.
<Laney>  actually I was trying to address that request
<Laney> you beat me to it by minutes :)
<jodh> infinity: could you do another get_state.sh run after a chroot has been spun up and down again? Also, does 'ls -al /proc/1/fd' look sane?
<infinity> jodh: It's 16h into a build, there won't be any new chroots until that's done.
<jodh> infinity: ok.
<infinity> jodh: Your ls shows the usual stdin/stdout/etc, and about 100ish inotify.
<infinity> jodh: I'm not sure what qualifies as sane. :)
<jodh> infinity: can you pb it?
<infinity> jodh: http://paste.ubuntu.com/8054640/
<jodh> infinity: confirmed - that's most definitely not sane :)
<jodh> infinity: my theory is that you'll get 2 more anon_inode:inotify post chroot tear-down.
<infinity> jodh: That machine's done far more than 50 builds since the last reboot.
<jodh> infinity: ok. can you 'telinit u' at your leisure and see if that bumps the anon_inode:inotify count by 2?
<infinity> jodh: Sure.
 * infinity waits a few minutes for that to take.
<Laney> rbasak: there
<infinity> jodh: Stayed at 125 before and after a telinit u
<rbasak> Laney: ubuntu-upload-permission agrees. Thank you, and to stgraber.
<infinity> jodh: How many should there generally be?  My laptop has two, one of these recently-rebooted machines has 4.
<Laney> yw - enjoy
<jodh> infinity: you should only ever have 2.
<jodh> infinity: having paused for thought, I've realised that what you're seeing is bug 1338637. This is fixed in 1.13, so I'm afraid you'll have to suffer the slow re-exec's to get to that version :)
<ubottu> bug 1338637 in upstart "continuous re-exec can result in a build-up of inotify fds" [High,Fix released] https://launchpad.net/bugs/1338637
<infinity> jodh: And when will it get fixed in trusty?
<infinity> jodh: We're not upgrading production machines to utopic. :P
<infinity> jodh: I think both the telinit-should-block bug and this one should be fixed in trusty before too many more people suffer my pain.
<dobey> doko, infinity: ok, fixed unity-scope-click is in archive now
<doko> slangasek, ping
<infinity> dobey: Thanks.
<jodh> infinity: It's a cherry-pick. I'll take a look at this early next week unless another upstart dev wants to jump in.
<hallyn> hm, has it always been the case that launchpad told me "newer version available" for a package when newer version was only available in -proposed?
<infinity> hallyn: If it didn't, it was a bug, the current behavious is correct.
<infinity> hallyn: I assume you mean when a PPA lists a newer version in the distro, yes?
<hallyn> right
<hallyn> ok, thanks.  just checking.
<xnox> rbasak: =( ok.
<roadmr> hello folks! I found a couple of problems with the 12.04.5 images, what's a good place to report them/file bugs? (place as in, launchpad project or package)
<xnox> roadmr: depends what type of problems.
<roadmr> first, if booted on a VM (tested on kvm and virtualbox), I don't get a console
<xnox> roadmr: can you describe in short them?
<roadmr> no way to access any of the vttys with ctrl+Fx, I have to reset the VM and use recovery mode to get a root prompt
<xnox> roadmr: boot what specifically? desktop iso / live cd; server iso / d-i installer; installed system?
<roadmr> xnox: right :) sorry, this is 12.04.5 server amd64 image. The install completes correctly, but when trying to use the installed system I get that issue and another one...
<xnox> roadmr: I'd say $ ubuntu-bug console-setup - from installed system itself, if you can.
<roadmr> xnox: the second issue is that the apt lists seem somehow corrupted: if on this freshly installed system I try apt-get update, I get a lot of checksum mismatch errors and apt-get exits with errors
<roadmr> xnox: sure, I can do that (console-setup). I don't mean to give detailed descriptions here, I can provide good steps to reproduce but wanted to know where to file them
<xnox> roadmr: that can happen naturally, if e.g. network connection / dns setup is wrong. Can you confirm by changing all sources to use just "archive.ubuntu.com" (no coutry prefix) and see if errors persist?
<roadmr> xnox: also, the install/no-console problem was verified by someone else on qemu/kvm, and the apt-get problem verified by the same person on a bare metal installation
<xnox> roadmr: if mirror bug -> file against ubuntu-mirrors project. If other checksum error -> file against $ ubuntu-bug apt; and it would be inspected / reassigned from there.
<roadmr> xnox: they have no country prefix now :D just archive.ubuntu.com (I told it I was in the US)
<roadmr> xnox: ok, I'll start with apt. FWIW, I've reproduced this from Canada, the UK and US west coast, and at different times (yesterday + today) so it doesn't seem like a network issue
<roadmr> xnox: thanks for your help (as usual, much appreciated), I'll file them now
<arayaq> Hi! I'm getting an error trying to compile the template project for a QML Extension library with a tabbed UI (CMake) on 14.04
<arayaq> Nvm, the problem is that you can't have a dash in your project name
<arayaq> No idea if it is a bug
<dobey> anyone know why the symbols checker would complain about 2 symbols not being in the .symbols file, even though i added them?
<infinity> dobey: build log?
<infinity> dobey: And symbols file.
<infinity> dobey: My guess is the answer is "it wouldn't", but...
<dobey> infinity: http://pastebin.ubuntu.com/8057237/
<dobey> ironically, in the diff from gensymbols you can see 2 lines above the + that the ::updated() is already there...
<xnox> wgrant_: ./copy-package -s utopic --from ubuntu --to ~xnox/ubuntu/scratch hello is very nice.
<xnox> wgrant_: apart from having to quote "~xnox/ubuntu/scratch" as otherwise it ends up with error message - AssertionError: No such archive: /home/xnox/ubuntu/scratch
<geofft> is anyone working on updating gnome-settings-daemon to a newer upstream version in Utopic?
<geofft> slash, is that wanted or is there something that requires it being held at 3.8.x?
<Bluefoxicy> bah
<Bluefoxicy> lightdm and gdm should have a setting to add priority to the DE
<Bluefoxicy> that way X11 can run at -2, lightdm at 0, Gnome-Shell or Unity or XFCE at 1.  Then the DE should have a configuration to spawn all user applications at additional priority i.e. +2 or +5.
<Bluefoxicy> then maybe stuff will work when chrome misbehaves
<Bluefoxicy> and if not, I can just ^+F1 and log in on a priority-0 terminal, running at higher priority than Chromium at 3.
#ubuntu-devel 2014-08-16
<wgrant_> xnox: Or --to=~whatever/blah/blah
<ScottK> or \~whatever/blah/blah
<Mirv> if someone can rerun autopkgtests, there's unity8 stuck in proposed by something that's probably a false alarm and a rerun (or investigation of that i386 machine that failed) would be nice
<Mirv> well it's certainly false alarm regarding the unity8 since it isn't installed during that particular autopkgtest, but something else might have broken something
<halfie> hi, http://ddebs.ubuntu.com/pool/main/j/john/ does not seems to have .ddeb package for john 1.8.x. why is that?
<halfie> http://archive.ubuntu.com/ubuntu/pool/main/j/john/ contains john 1.8.x
<Saviq> hi, is anyone with archive upload rights available to help me with reverting the last qtmir upload
<Saviq> that's the only thing I can think of that changed between https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/3524/ and https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/3526/
<Saviq> it's the same branch, just two commits more, and between those runs unity8 started deadlocking in ap test runs (not reproducible locally, hence the drastic measure of reverting)
<Saviq> the result can easily be seen in the ap runner jobs https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/ ...
<Saviq> rsalveti, I'm sorry to be pinging you over this on a Saturday... if you're around, could you help with reverting qtmir (read up on reasons)
<rsalveti> Saviq: hey
<rsalveti> Saviq: just qtmir & qtmir-gles?
<Saviq> rsalveti, yeah
<rsalveti> Saviq: ok
<Saviq> rsalveti, thanks a lot
<Saviq> rsalveti, I really hope that's it, it's a bit of a witch hunt, but from the dpkg logs that's the only thing that makes sense (and from the commit, maybe, too) http://paste.ubuntu.com/8065468/
<rsalveti> Saviq: yeah, let me revert it (the change seems to be quite small)
<rsalveti> then we can validate the whole thing again
<Saviq> accounsservice is just a no-change rebuild, scope-scopes is just a stoopid visual change https://code.launchpad.net/~saviq/unity-scope-scopes/fix-overview-search-mapping/+merge/230966
<Saviq> and the rest of the diff is a build from unity8 trunk + a branch
<rsalveti> yeah
<Saviq> and I can actually imagine the qtmir change getting into a deadlock waiting for a new frame from an app that doesn't want to give it up
<rsalveti> Saviq: http://paste.ubuntu.com/8065516/
<rsalveti> Saviq: ack?
<Saviq> rsalveti, yeah, convention seems to be to say .is.$version in the changelog if you could
<rsalveti> right, thought about reverting it from trunk
<rsalveti> Saviq: or do you only want to revert the packaging?
<Saviq> rsalveti, that I'll take care of
<Saviq> rsalveti, just upload a package reverting it
<rsalveti> alright
<Saviq> rsalveti, and thanks for remembering -gles, I'd have forgotten it
<rsalveti> Saviq: do you want another image once it gets published?
<Saviq> rsalveti, I'll do a test run in a branch to verify (having bumped the required qtmir version)
<rsalveti> Saviq: ok
<Saviq> rsalveti, and I'll let you know if it's worth an image (does it not build automagically?)
<rsalveti> Saviq: yup, but only in 5:30h
<Saviq> rsalveti, or well... you could just kick one when this publishes, we'll get better coverage
<rsalveti> great
<Saviq> rsalveti, thanks a bunch
<rsalveti> np
<Saviq> rsalveti, it's published btw
<rsalveti> Saviq: rmadison still can't see it
<rsalveti> should probably take another 10/20min
<Noskcaj> Can someone please retry gecko-mediaplayer on ppc64el? The alt-depend on firefox should be working now
<jtaylor> done
<Noskcaj> thanks
#ubuntu-devel 2014-08-17
<Sven_vB> hi :)
<Sven_vB> i managed to fix a crash in update-manager (missing error handling in ubuntu-support-status) on Ubuntu 12.04.5 LTS, which is still present in the development branch, so usually i'd open a pull request but they use bzr. is there any chance i can use my git skills to submit it in an easy-to-integrate format? (easier than having to manually apply my patch file)
<kurain> hello all
<kurain> how to use autopilot for calling slots of qt class?
<kurain> I have read the documentation of autopilot, but there is no docs for this topic
<tsimpson> Sven_vB: push your branch to launchpad and propose it for merging into the source branch
<Sven_vB> trying... i'm still waiting for the original branch to finish downloading
<Sven_vB> at least i found a PPA for git-bzr-ng in the meantime
<Sven_vB> should be here in about 2 hours =) maybe i should just make a traditional patch file already
<Sven_vB> noes it ran out of disk space D:
<mitya57> Sven_vB: I usually use `bzr branch --stacked lp:somebranch` for "big" branches.
<mitya57> This way it takes less time to clone, but commands like diff and commit will need internet & more time.
<Sven_vB> thanks, i'll try that later
<mitya57> Also, "traditional patch files" are also welcome
<kurain> join #ubuntu-autopilot
#ubuntu-devel 2015-08-10
<pitti> Good morning
<veebers> Morning pitti :-)
<pitti> cjwatson, lamont, infinity: most of the virt builders are "cleaning", looks like they're stuck?
<pitti> wgrant: ^ or maybe you know
<wgrant> pitti: Let me see.
<wgrant> That is rather broken indeed.
<pitti> I'm going to put another big chunk of work on the buildds soon /me sighs at g++
<wgrant> pitti: Ah, no, it's fine.
<wgrant> Just lots of small kubuntu-ci builds.
<pitti> and they don't manifest as an actual build, but as "cleaning"?
<wgrant> (ubuntu-archive-tools' "manage-builders -v" is informative here; it whines when things are stuck for more than a few minutes)
<wgrant> kubuntu-ci has a lot of small builds starting at the same time.
<wgrant> So they all finish quickly, and leave a lot of builders cleaning at the same time, so they queue a bit.
<pitti> wgrant: ah, ok; thanks for checking!
<pitti> cjwatson, lamont, infinity: unping then ^
<wgrant> https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20150810/20150811/ <- suddenly a queue from nowhere.
<wgrant> We can possibly increase the reset concurrency a bit now, but it's very rarely a problem like this.
<wgrant> And this'll resolve itself in maybe 10 minutes.
<dholbach> good morning
<darkxst> jdstrand, thoughts on https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1466290/comments/13? core GNOME is pretty blocked on this and feature freeze is fast approaching
<ubottu> Launchpad bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New]
<doko> pitti, do you care about http://autopkgtest.ubuntu.com/packages/a/apport/wily/amd64/
<pitti> doko: yes, I do; I just fixed one regression, looking at the other right now
<pitti> doko: related to the first one -- is it really intended to have /usr/bin/gcc-5 instead of /usr/bin/gcc-5.2 ?
<pitti> doko: (it's one of the issues that hold up binutils and gcc-5)
<pitti> lintian also ought to be fixed now
<pitti> (didn't run yet)
<doko> pitti, yes, next major release will be 6.x
<highvoltage> win 26
<doko> Laney, pitti: could you work on more "binNMU's" today?
<pitti> doko: I could; I'm currently working on finishing some transitions that we started in Ubuntu, resolving FTBFS etc.
<pitti> not sure what is more urgent
<Laney> going to look at the state soon
<doko> good as well
<Laney> I'm working on a deduplication script for the tracker atm
<doko> looks like slangasek wants to force gcc-5 and gcc-defaults to -release tonight to see what else migrates
<pitti> ah, my merged lintian passes again \o/, that should unblock another 4 packages
<pitti> doko: doing a final test run of apport, then uploading this; should unblock binutils and gdb
 * pitti runs for some errands while this runs
<pitti> doko: right, this should flush quite some things, e. g. gcc5 -> mozjs24 -> {gjs,cjs} (and presumably much more)
<pitti> from a quick look, all teh regressions in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 also appear somewhere else (where they are better to track)
<doko> pitti, I'm working with kubuntu to get the kde related things done. however there are four others: ruby-re2 libwx-scintilla-perl gprbuild freecad
<doko> now afk, going back home with the train
<ricotz> pitti, hey :), some likely important packages which aren't on that list: scribus, vlc
<pitti> doko: I'm already looking on freecad
<pitti> doko: ruby-re2 needs transition of re2, I can NMU to Debian/sync/re-build in Ubuntu
<pitti> please use the pad -- tracking on IRC is too hard
<pitti> doko: adding re2 for me
<pitti> ricotz: scribus and vlc don't have autopkgtests; doko's list was regressions from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 which aren't KDE-ish
<Mirv> seeing libcolumbus1v5 rename brigs me the memory that no-one has really combed the libraries that are actually deprecated and not in use anymore... there's cruft from earlier phone efforts in the archives
<pitti> Mirv: please do let us know which ones we can just remove
<Mirv> yeah, worth doing so
<Mirv> let me think a bit and see if I come up with any that I can verify
<Mirv> pitti: ok I've some 15 source packages now collected.. made a pad for it: http://pad.ubuntu.com/drop-obsolete-phone-packages
<Mirv> sil2100: can you check the above too? ^ and say if something seems not to be removed from archives in wily
<Mirv> pete-woods: are libcolumbus, unity-voice and libdbusmenu-qt to be continued to be used on 16.04 LTS unity 7 desktop?
<pete-woods> Mirv: unity-voice technically isn't used any more
<pete-woods> but the others are
<pitti> Mirv: thanks! will process once sil2100 signs off
<pete-woods> unity-voice has a dependency, though
<pete-woods> so would need to remove that from HUD first
<pete-woods> then you will also get space savings from the voice definition files
<Mirv> pete-woods: yes, I noticed I've unity-voice installed on my desktop
<pete-woods> Mirv: it's not used, because there is no UI to invoke the voice recognition any more
<pete-woods> after HUD was pulled from the phone
<Mirv> pete-woods: thanks for the explanation! so some benefit could be had by at least dropping the dependency. I filed bug #1483210 now.
<ubottu> bug 1483210 in hud (Ubuntu) "drop unity-voice dependency from HUD, remove unity-voice from archives" [Undecided,New] https://launchpad.net/bugs/1483210
<pete-woods> Mirv: thanks
 * sil2100 looks
<Laney> can anyone see why https://launchpad.net/ubuntu/+source/open-vm-tools/2:9.10.2-2822639-1ubuntu2/+build/7763199 happens?
<pitti> Laney: hm, seems to work in my amd64 -proposed chroot
<pitti> "apt-get build-dep open-vm-tools", I mean
<Laney> right, I tried sbuilding it
<cjwatson> Laney: open-vm-tools is in main, the mentioned build-deps are in universe
<cjwatson> ... and with that, holiday
<Laney> huh
<Laney> Oh, there was a new upstream release waiting in proposed already
<Laney> I had subconsiously discounted that due to it only being a no-change rebuild
<Laney> utlemming: ^^^ any chance you could take a look at that?
<apw> xack
<pitti> infinity: why is fisher03 on manual?
<pitti> (asking because we could really use some more ppc64el horsepower)
<pitti> I just retried to revive denneed04, let's see how it goes
<pitti> apw: cheers
<pitti> apw: want to do another one?
<pitti> Mirv: does this happen to tell anything to you? http://paste.ubuntu.com/12048072/
<pitti> Mirv: I just added a change to add -fPIC to the CXXFLAGS, which apparently was respected (as it appears in the c++ line now), but I'm still getting that error
<apw> pitti, damn, so much of this is pending for lack of build resources, gah
<pitti> Mirv: ah, it seems this error message is utterly confusing; it rather objects to being built with -fPIE it seems
<pitti>     (!defined(__PIC__) || (defined(__PIE__) && defined(Q_CC_GNU) && Q_CC_GNU >= 500))
<pitti> so Qt does not want to be built with -fPIE on gcc > 5
<pitti> apw: that too; it's annoying to see updates on the trackers and when waiting for retrying/uploading followup transitions, but so far there's still enough first-level stuff to do :/
<Mirv> pitti: ..yes, so I think this is the last change that went into 5.4.2 we luckily had before the GCC5 transition began: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=3eca75de67b3fd2c890715b30c7899cebc096fe9
<pitti> Mirv: hm, that commit description is equally wrong/confusing then
<pitti> or maybe it *is* the intention, then the code is wrong?
<pitti> Mirv: so should I drop -fPIE from gnuplot5?
<Mirv> pitti: yes it seems they do want to ban the usage of -fPIE
<pitti> too bad, it's quite nice for ASLR
<Mirv> on x86 only, to be exact, since reduce relocations (-Bsymbolic) is only used on x86 with Qt
<pitti> Mirv: oh right, it actually does build on any !x86 arch: https://launchpad.net/ubuntu/+source/gnuplot5/5.0.1+dfsg1-2build1
<pitti> Mirv: but it's impractical to drop this by-arch, as a package like gnuplot can't know on which arches we enabled -Bsymbolic
 * pitti tries to drop it from all arches then
<Mirv> pitti: yes, and the upstream might change to enable it for other archs too but there's a binutils bug on armhf that was thought to be fixed but isn't so it's currently as it is
<Mirv> https://bugreports.qt.io/browse/QTBUG-47350
<Mirv> we did have -reduce-relocation explicitly set at one point but with Qt 5.4 upgrade it caused Unity 8 to show black screen on arm because of this buggy behavior, so now we accept what upstream defaults to
<pitti> Mirv: ack, thanks for the pointers!
<Mirv> pitti: you're welcome! I'm happy I battled with Qt 5.4.2 in June without anyone specifically asking for it, since now this problem was largely resolved before GCC5 transition began. GCC5's painful enough as it currently stands.
<pitti> wah, wah, wah, still doesn't build
<pitti> and why on earth is it so utterly hard to actually find the error message in a build log
<pitti> Mirv: hm, I patched out the addition of -fPIE in configure.in and configure, but it still creeps in; might that come from some pkg-config stuff from Qt itself?
<pitti> "grep -r fPIE" is empty now
<pitti> (and so is "fpie")
<Mirv> pitti: hardening flags? see https://launchpad.net/ubuntu/+source/poppler/+changelog
<pitti> Mirv: ah!
<pitti> Mirv: ok, one step further, but it's *still* there
<pitti> actually, it's not
<pitti> Mirv: oh! so I *do* need to use -fPIC, but must not use -fPIE
<Mirv> pitti: yes!
<pitti> but that is wrong
<pitti> PIC isn't for executables
<pitti> that's PIE
<Mirv> I thought PIC was superset of PIE, but I'm not really knowledgeable at that level
<pitti> I thought PIC -> shlibs, PIE -> exes
<pitti> finally!
<pitti> thanks Mirv, builds at last
<Mirv> no problem
<davmor2> pitti: ofcourse PIE is not for executable PIE is for eating hmmmmm PIE!!!!
<pitti> davmor2: it's summer! "pie" is spelt "ice cream" now.
<tdaitx> pitti, you might have seen these already, but I found a couple link that might help: http://code.qt.io/cgit/qt/qtbase.git/plain/dist/changes-5.4.2 https://bugreports.qt.io/browse/QTBUG-45755 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
<ubottu> gcc.gnu.org bug 65886 in target "[5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic" [Normal,New]
<davmor2> pitti: Baked Alaska is still PIE
<pitti> tdaitx: thanks; the "changes" is quite useful (it's what the git commit Mirv pointed to did)
<tdaitx> hmm... right, I missed that one
<tdaitx> although the Changelog itself does add that "Applications using qmake or cmake >= 2.8.12 as their build system will adapt automatically. Applications using an older release of cmake in combination with GCC 5.x need to change their CMakeLists.txt to add Qt5Core_EXECUTABLE_COMPILE_FLAGS to CMAKE_CXX_FLAGS. In particular, applications using cmake >= 2.8.9 and < 2.8.11 will continue to build with the -fPIE option and invoke the special compatibility mode
<tdaitx> if using GCC 4.x."
<infinity> pitti: Because I forgot I was working on it.  D'oh.  Fixing.
<tdaitx> pitti, btw, thanks for the fixing the Changelog of the 2 ftbfs fixes I made the other week... one question: what is the right procedure to add those links when creating the debdiff? at added the debdiff at the time I created the LP bug and used submittodebian to create the bug at debian... seems like I should first create the bugs and only then attach the patches, right?
<pitti> tdaitx: you can do that, but adding the bug refs as a sponsor isn't a big deal
<pitti> tdaitx: creating an LP bug is instant, so doing that, and re-doing the debdiff is simple
<pitti> tdaitx: the Debian BTS is a much worse beast and there are some delays involved
<tdaitx> indeed
<infinity> The only real delay is greylisting.
<infinity> Use the BTS often enough, and it's delay-free.
<infinity> So, obviously, file more bugs!
<tdaitx> sweet
<tdaitx> =)
<Riddell> ricotz: ping, you rebuild openconnect?
<Riddell> I need it rebuilt for plasma-nm, do you know the status of that in the ubuntu archive?
<ricotz> Riddell, how do you mean? the -proposed pocket doesnt provide a rebuild yet, feel free push one
<Odd_Bloke> arges: I mistakenly "fixed" https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1381776 in trusty when it actually only appears in precise.
<ubottu> Launchpad bug 1381776 in cloud-init (Ubuntu) "cloud init depends on python-serial but does not declare it" [Medium,Confirmed]
<Odd_Bloke> arges: But there isn't actually an impact on the installed package, so can we let that through and fix the needlessly added dependency in the next SRU?
<Odd_Bloke> arges: (As in, the package is determined as a dependency by debhelper's Python stuff, so the requirements of the package haven't changed, just the Build-Depends)
<arges> Odd_Bloke: so if it isn't needed in trusty why not just fail the -proposed version and then when the next upload comes along we just overwrite it
<Odd_Bloke> arges: Would we be able to expedite getting that in to the archive and out of -proposed?  We've got another SRU that we want to do that is fairly time-critical.
<Odd_Bloke> arges: (But contains big enough changes that trying to verify everything all at once would have been painful)
<arges> Odd_Bloke: we can overwrite the current version in proposed. Does it just contain that one fix?
<Odd_Bloke> arges: The version in -proposed fixes three bugs; the only change needed to that package would be to fix this problem.
<Odd_Bloke> (Well, fixes 2 bugs and this non-bug)
<arges> Odd_Bloke: ok in that case verifying #1464253 and then 'verifying' 1381776 would help (perhaps comment on how its a non-bug fix and what your plan is in the next upload)
<Odd_Bloke> arges: Ack, thanks.  Both of those bugs are now verified.
<arges> Odd_Bloke: another helpful thing would be to ensure all development tasks are marked either 'invalid' or 'fix released'
<arges> at least for bug 1381776
<ubottu> bug 1381776 in cloud-init (Ubuntu) "cloud init depends on python-serial but does not declare it" [Medium,Confirmed] https://launchpad.net/bugs/1381776
<Odd_Bloke> arges: So that should reflect the status in the development release (i.e. not a problem)?
<arges> Odd_Bloke: yea so if its not a bug in development its probably 'invalid' or if its already fixed 'fix released'
<Odd_Bloke> arges: Ack, will make sure I do that in future.
<arges> Odd_Bloke: np
<arges> Odd_Bloke: ok so just to confirm cloud-init in precise/trusty/vivid can be released, then you'll upload a new one here soon for the next update
<Odd_Bloke> arges: Yep, they are all ready for release.
<arges> ok
<Odd_Bloke> And I will start preparing the new SRU tomorrow morning.
<Odd_Bloke> (As I'm about to EOD)
<arges> ok
<israeldahl> Hi, is there anyway to make PowerPC debs in a PPA?  I don't think I am allowed to manually upload them.
<teward> not an expert but i don't think so...?
<maxb> That's more a question for #launchpad, but there are no virtualized PPC builders, so you'd need a PPA enabled to use non-virtual builders, which I *think* is only an option for people employed by Canonical for security reasons
<israeldahl> thanks guys...
<israeldahl> is the other option to create a repository then?
<infinity> mterry: Hah, nice clash on the lxd MIR. :)
<infinity> mterry: I guess now it's REALLY assigned to ubuntu-security.
<infinity> Twice!
<mterry> infinity, hah  :)
<doko> hmm, after today's updates, my mouse cursor on the wily-proposed desktop disappears after some time
<doko> Laney, seb128: ^^^ any idea?
<seb128> not really no, sorry
<tjaalton> doko: try a VT switch and back, or suspend/resume cycle
<doko> tjaalton, vt switch didn't help. will try suspend/resume next time
<doko> jamespage, smoser: mongodb ping ... you last updated the package in 2014 ...
<smoser> doko, you're pinging because its ftbfs ?
<doko> smoser, yes
<doko> smoser, and we need it for the transition
<smoser> i'll poke and see if we cant get someone to look at it.
<doko> smoser, ok, I'll upload a workaround to not build with -Werror
<smoser> ok. and then we'll try to drop taht in another upload.
<doko> smoser, juju-mongodb needs attention too
<smoser> ok. thanks.
<doko> smoser, open-vm-tools too
<doko> smoser, and ceph
<smoser> you have a comprehensive list ?
<doko> smoser, see slangasek's email to ubuntu-devel (and there are the various ruby packages in dep-wait status which need resolving)
<smoser> k
<Logan> could someone please help me figure out what's going wrong with this build? https://launchpad.net/ubuntu/+source/aqsis/1.8.2-1ubuntu1 I can't find a specific error message in the log...
<Logan> the same upload built perfectly fine in my PPA: https://launchpad.net/~logan/+archive/ubuntu/ubuntu-tweak/+build/7778391
<Logan> oh right, it's the parse error again
<doko> smoser, LP: #1482777 needs bug subscribers, and filed LP: #1483400 for mongodb. the ceph ftbfs is LP: #1483403
<ubottu> Launchpad bug 1482777 in xml-security-c (Ubuntu) "[MIR] open-vm-tools 9.10.2 build dependencies: xml-security-c and xerces-c" [Critical,New] https://launchpad.net/bugs/1482777
<ubottu> Launchpad bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400
<ubottu> Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483403
<smoser> thank you
<smoser> anyone want to guess what would do this ?
<smoser> please
<smoser> http://paste.ubuntu.com/12051576/
<smoser> for some reason the while loop there just does not read the second line.
<slangasek> smoser: any chance that 'sudo cat /proc/net/route' gives different results? :)
<doko> smoser, configured open-vm-tools without xmlsecurity and xerces support, seems to build
<sarnold> smoser: how repeatable is that? it looks fine, runs fine on my system..
<smoser> slangasek, no different
<smoser> http://paste.ubuntu.com/12051601/
<smoser> well, this system keeps repeating it.
<doko> barry, 3.5 related: https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1483410
<ubottu> Launchpad bug 1483410 in checkbox-support (Ubuntu) "checkbox-support FTBFS in wily" [High,Confirmed]
<barry> doko: ack
<smoser> http://paste.ubuntu.com/12051630/
<smoser> slangasek, take a look at that.. .very odd. they're the same contetns. but behave differnetly.
<slangasek> smoser: what are you meaning to show with that pastebin? you seem to be showing everything *except* the output of 'sudo cat /proc/net/route'
<smoser> slangasek, ? cat /proc/net/route at the bottom
<smoser> everything there is done as non-root
<smoser> so it took the root suggestion out of the picture, but it didnt matter anyway.
<slangasek> smoser: oh, because you see the same misbehavior even when running as non-root, check
<slangasek> smoser: so it's gotta be either a kernel bug or a dash bug.  What does strace look like?
<barry> slangasek: how terrible will it be to MIR libgeos-dev?  i'm more or less stuck between three not so great options for getting django buildable in wily.  libgeos-dev to main seems like the least painful option.  otherwise it's try to try to backport a huge diff from upstream (not sure it will apply and build to our version), or pull in django 1.8.3 from experimental, but i'm really not sure i want to start a django transition right now
<barry> too :/  thoughts?
<slangasek> barry: it seems like a reasonably self-contained library dep, shouldn't be too horrible IMHO?  But you probably want the MIR team's input
<barry> maybe doko can weigh in?
<doko> barry, but it doesn't build python bindings?
<barry> doko: no, django's test suite uses it via ctypes
<barry> the problem is, test discovery works differently on py2 and py3, and the latter picks up gis tests that py2 doesn't pick up.  but you can't just add some test skips because its during discovery that modules get imported which hit libgeos-dev
<doko> Changes in 3.4.2
<doko> 2013-08-25
<doko> seems to be dead upstream
<doko> https://github.com/libgeos/libgeos
<barry> looks like they've got some recent-ish changes there
<doko> but some activity at https://github.com/libgeos/libgeos/commits/svn-trunk
<doko> yeah, no release. well, look at the other criteria for a MIR ...
<barry> cross pocket b-ds bite again :/
<barry> well, if mir of libgeos-dev is unlikely, we might just be stuck with a broken django stack for now
<barry> i guess another option is to just ignore test failures for django
<sarnold> just how bad is pulling in 1.8.3? iirc django is important to maas, openstack, probably elsewhere, and breaking those doesn't sound fun
<infinity> smoser: Is that weird /proc behaviour in a namespace (ie: a container) by any chance?
<infinity> smoser: Oh, no.  I can reproduce it here in my base system on my laptop.
<infinity> WTF.
<sarnold> I wondered if it might have anything to do with read block sizes, so I tried dd with different bs, but the 14 or 15 tests I ran all gave identical results on my computer
<sarnold> for i in 1 2 4 8 16 32 64 128 256 512 1024 4096 8192 ; do dd if=/proc/net/route of=$i bs=$i ; done
<infinity> I don't see any fishy non-printable chars in the file, which was my first guess.
<infinity> Well, my second guess.  My first guess is the kernel just flat out not giving you that line in a pipe.  Which seems like the only plausible answer right now.
<infinity> sarnold: You say it doesn't break for you?
<infinity> sarnold: Do you have a default gateway on the machine you're trying on (that seems to be the line both smoser and I are missing)
<sarnold> infinity: yeah, I do have a default gateway
<sarnold> interesting...
<sarnold> 3.13.0-57-generic here
<infinity> 4.1.whatever here.
<infinity> 4.1.0-3-generic
<cyphermox> you're missing a default gateway?!
<infinity> cyphermox: No.
<infinity> cyphermox: Only when reading proc with a pipe.
<cyphermox> ok
<cyphermox> well, obviously, since you're online :P
<infinity> cyphermox: Compare:
<infinity> sh -c 'while read line; do echo line: $line; done' < /proc/net/route
<infinity> cat /proc/net/route
<infinity> And witness the bizarre missing line.
<cyphermox> ah, interesting
<sarnold> cyphermox: you too?
<cyphermox> yeah
<sarnold> o_O
<cyphermox> http://paste.ubuntu.com/12052232/
<cyphermox> 4.1.0-2-generic
<infinity> Yep, same missing line.
<infinity> It's always either the first route or the default.  Hard to say, since they're the first route on all the test systems.
<cyphermox> it's also the one you're most likely to care about :)
<infinity> smoser: Have you seen this on a stable kernel, or just on wily?
 * infinity tests 4.2.
<sarnold> how about "cat < /proc/net/route" ?
<cyphermox> correct
<infinity> sarnold: That's fine.
<sarnold> gah. that hurts my head.
<infinity> Same issue on 4.2, *and* confirmation that it's the default route.
<infinity> Cause my machine came up with two defaults (on eth0 and wlan0), and both are removed from the piped list.
<infinity> Weeeeeird.
<infinity> http://paste.ubuntu.com/12052314/
<infinity> apw: WTF is wrong with your kernel? :)
<doko> tjaalton, no, suspend/restore doesn't help either
<infinity> Bah.  Literally identical set of packages installed, still no failure.  Not we're in the realm of the bizarre.
<infinity> Err, wrong window.
<smoser> infinity, i have only ever seen that today
<smoser> running on 4.1.0-2-generic
<smoser> linux-image-4.1.0-2-generic
 * smoser reboots taht system to -3 to see if it goes away
<infinity> smoser: It's still broken in 4.1-3 and 4.2
<infinity> smoser: Was curious if it was alright under 3.19 and earlier.
<infinity> (sarnold says it's fine on 3.13)
<infinity> Though, he also has different userspace, which is less helpful.
<smoser> yeah, mine is not user namespace
<infinity> No, neither was mine.  I got past that theory. :)
 * smoser files a bug
#ubuntu-devel 2015-08-11
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1483440
<ubottu> Launchpad bug 1483440 in linux (Ubuntu) "odd behavior with /proc/net/route reading via sh 'read'" [Undecided,New]
<smoser> infinity, is your /proc/net/route exactly 512 bytes like mine is
<smoser> did i just really luck into the fencepost ?
<infinity> smoser: No, mine is 768.  Though, still a curiously round number in binary land, so I assume the lines are a padded length.
<infinity> And, indeed, they are.
<sarnold> heh, mine's 77 * 128 bytes long
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1483440
<ubottu> Launchpad bug 1483440 in linux (Ubuntu) "odd behavior with /proc/net/route reading via sh 'read'" [Undecided,Confirmed]
<sarnold> this reminds me so much of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381005 -- but that looks to be tty specific
<ubottu> Launchpad bug 1381005 in linux (Ubuntu Vivid) "Long stdin from terminal can result in code execution" [High,In progress]
<smoser> walking through powers of two for byte size, i get error right at 512, which is exactly mine.
<pitti> Good morning
<pitti> slangasek: I heard you want to force gcc-5 into wily-release, so that at least some of the transitions can land?
<sarnold> hey pitti, this seems especially early..
<pitti> that would at least help a bit to untangle the mess
<pitti> sarnold: yeah, can't sleep any more :/
<sarnold> oh :( sorry
<tjaalton> seems to be the trend..
<pitti> tjaalton: morning :)
<pitti> The early bird can bite me
<tjaalton> hehe
<tjaalton> yeah or the cat, woke me up 1+ hrs ago
<mwhudson> blargh
<mwhudson> i can't install packages in the wily chroot on the ppc64el porter box
<mwhudson> SystemError: E:Unable to correct problems, you have held broken packages.
<mwhudson> how can this be unpicked?
<mwhudson> i don't know how to use rapt very well
<pitti> mwhudson: if apt-get -f install doesn't help, then you need an RT I'm afraid
<pitti> unfortunately the schroots on our porter boxes are quite useless
<mwhudson> ERROR: only install/update/upgrade/dist-upgrade supported as argument
<mwhudson> rt time!
<mwhudson> also eod time so that's ok i guess
<pitti> mwhudson: perhaps while you are at it you can ask for re-setting them up properly
<pitti> i. e. with session overlays instead of "everyone uses and breaks one single schroot"
<mwhudson> pitti: heh uh, i don't think putting that literal text into the rt would be productive
<pitti> I thought I did that years ago already
<pitti> but it seems nobody got around to it yet
<pitti> mwhudson: asking for session overlays? but that's the right thing to do, and constructive?
<pitti> nobody except IS should ever be able to access the "real" (source) schroot
<pitti> one should be able to start a session, hack in that, end it, and it's all gone
<mwhudson> i can see how that would be useful
<mwhudson> but i'm not sure i'm going to fight that fight today
<pitti> what makes me wonder is how IS set this up in the first place, given that sessions are schroot's default mode of operation
<pitti> you actually have to go through great lenghts of effort to set them up the way they are right now :)
<slangasek> pitti: if by "force" you mean "review the remaining autopkgtest blockers and make judicious decisions about whether to override them", yes
<pitti> slangasek: oh, please don't force-badtest those; all the KDE failures also appear in more proper excuses where they *should* hold back stuff until the transitions get completed
<pitti> slangasek: I thought you were going to force-skiptest gcc-5 itself only?
<slangasek> pitti: I was not suggesting a force-badtest at all
<pitti> (after reviewing the remaining failures, yes)
<slangasek> pitti: there should be some information on the pad; I know robru confirmed that some of the regressions started only after gcc-defaults landed so are not related, but I think there are some remaining failures that need looked at
<robru> pitti: yeah i put those at the very bottom of the pad
<pitti> but that's misleading
<pitti> well, it can be argued that gcc-5 broke all those, but shouldn't they rather be tacked to the kde lib renames instead of gcc-5 itself?
<robru> pitti: how can that be argued? There's a handful of cases where tests passed after gcc5 was uploaded.
<pitti> either way, for gcc itself it doesn't matter much whether it promotes; we effectively can't "hold back" gcc, as we build everything from -proposed
<pitti> I thought we wanted to do this to unblock some unrelated transitions
<slangasek> I wouldn't say unrelated
<pitti> e. g. scim, snappy, schroot, etc.
<slangasek> so, unrelated to kde but not unrelated to gcc, sure
<slangasek> pitti: fyi gr-* failed because gnuradio has a wrong dependency on libuhd
<pitti> slangasek: yeah, just looked at it
<pitti> slangasek: want me to fix, or are you on it?
<pitti> (yay for not using proper shlibs..)
<slangasek> pitti: I'm just letting you know since you triggered the builds; I'm off to bed now
<pitti> slangasek: right, the previous FTBFS was due to non-current gnuradio, so it looked worth a retry
<pitti> slangasek: ack, will fix
<pitti> slangasek: are you the blue editor on the pad?
<pitti> (I don't see any names except robru's and mine)
<slangasek> pitti: yep
<pitti> ah, thanks
<slangasek> and going to bed for real now ;)
<pitti> slangasek: sleep well!
<pitti> Logan: hmm, aqsis still fails, did that work locally for you for some weird reason?
<darkxst> jdstrand, can you look again at bug 1466290?, remaining core GNOME is blocked on that
<ubottu> bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New] https://launchpad.net/bugs/1466290
<dholbach> good morning
<shine_> I have a situation that I feel is a but in the ubuntu o/s (unity?) and I'm having a hell of a time finding a way to just submit a bug in my own words. Been to https://bugs.launchpad.net/ubuntu ... click "report a bug" and get a howto document (not a place to submit a bug). In my particular case, there is no system information that would be useful. it will effect every 14.04 system (no matter the hardware) because it's a design
<shine_> choice I'm pointing out.
<ikonia> this isn't really a "bug" channel
<shine_> Been on #ubuntu and not getting anywhere in an economic amount of time. What can I do?
<ikonia> (check the topic)
<shine_> well perhaps the requirement is too much to ask (time wise) for something as simple as this. Shame if suffering result because the failure to report somethgin important
<shine_> Suppse, at this point, ubuntu doesn't want you to report bugs
<ikonia> you know it does want you to report bugs, this was explained in #ubuntu
<ikonia> so hitting other channels and repeating won't help
<ikonia> getting the bug logged, will, which if you rejoin #ubuntu people will work through with you
<shine_> I just don't feel it's fair to require someone to do research before they can report what seems like a problem to them. Person should be able to spend 5 or 10 minutes total, make a couple clicks, write in some text, click "submit" and be done with it.
<ikonia> this isn't the channel for this discussion
<shine_> Suppse, at this point, ubuntu doesn't want you to report bugs
<shine_> but hey - who cares - right?
<ikonia> this self pity stuff doesn't help
<pitti> doko: bug 1483400> why is dropping -Werror not an option? IMHO -Werror is just plain wrong in "production" builds (specific errors are okay and good of course)
<ubottu> bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400
<pitti> -Werror is only ever a thing for local developer builds
<infinity> pitti: I used to think that way too, but I've come to love gcc warnings more and more over the years.
<pitti> sure, they are good
<infinity> pitti: And a lot of them really, really do point to real bugs that will affect runtime.
<pitti> infinity: not in my experience then
<pitti> I used to see tons of FTBFS due to deprecation warnings wiht e. g. new glib which turned into FTBFS
<infinity> Oh, well, that's glib. :P
<infinity> I'm talking gcc warnings, not people abusing #warning.
<pitti> and building a package with a new compiler which has new warnings doesn't suddenly break your software
<infinity> No, it means it was already broken, often.
<pitti> the developer of that software should build with it, but never packages
<infinity> I still kinda want to know.
<pitti> yes, but no-change rebuilds are the wrong place for that
<infinity> See, I still disagree.
<infinity> "It was always broken" is no excuse for not fixing it.
<infinity> And when we discover it is a good time to fix it.
<pitti> well, I was mostly interested in why doko said "not an option" -- just out of general principle, or whether he reviewed the warnings and they are actual errors
<infinity> I have a slight bias here after putting in years to get glibc to build warning-free. :P
<infinity> But the number of real bugs we found in the process was pretty shocking.
<pitti> infinity: yes, and that's the very "developer build" use case
<infinity> pitti: We build it with -Werror in Debian and Ubuntu too!
<infinity> (And Fedora and Gentoo, and...)
<pitti> I'm not going to fix all the warnings in juju-mongodb
<pitti> and while I do agree that warnings are important, they are not *more* important to me as a random "do this transition" packager than to upstream
<pitti> (or the package maintainer)
<infinity> pitti: So, the answer for things you don't care about fixing is to see what *new* warning are affecting it, decide they don't matter, and build with -Wno-error=$warning
<pitti> and I yet have to see a C++ package rebuild that doesn't have warnings :)
<infinity> Cause a new warning might be a nasty bug.  But maybe the warning of the day isn't.
<pitti> infinity: right, that was kind of the point of my question to doko
<infinity> Effectively, when you drop -Werror entirely, you're making a future decision that you can't support because you have limited info (you don't know if future warnings will catch awesome bugs or code style issues or cows in your comment blocks)
<RAOF> In my experience with Mir, we've had a bunch of new warnings appear as compilers advance. These have *all* been stylistic.
<doko> pitti, at least -Werror is not good enough to fix the ftbfs
<pitti> well, it's a question of who can and will do something about it
<RAOF> But we're doing more fun things than the average package, and are aggressive with enabling warnings, and CI requires the build to succeed with -Wall -Werror before it lands, so...
<pitti> upstream and a package's maintainer should
<infinity> pitti: Anyhow, mongo may well be a lost cause, and maybe the answer is to turn off -Werror, and purists like doko and I should shut up.
<infinity> pitti: I definitely get where you're coming from too.
<infinity> pitti: But if it's just a few warnings on repeat, -Wno makes more sense.
<infinity> IMO.
<pitti> infinity: yes, agreed
<doko> pitti, if you work on this, please update to the current upstream of the 2.6 series ...
<pitti> currently working on luabind and libcrypto++ FTBFSes (I spotted the above when reviewing the list)
<pitti> doko: noted
<pitti> infinity: "[-Werror=unused-variable]" -> that definitively sounds like a case of -Wno-error :)
<infinity> pitti: Yeah, unused-variable probably should be in extra, not all.
<infinity> (or is mongo building with -Wextra?)
<pitti> I'll look at mongodb/juju-mongodb, and update the former to 2.6.10
<infinity> unused-variable is in -Wall.  That seems perhaps wrong.
<Mirv> hmh, why does apt continuously give me hash mismatch on http://archive.ubuntu.com/ubuntu/dists/wily-proposed/main/i18n/Translation-en
<Mirv> good to complain, the continuity stopped
<darkxst> Mirv, I get that often, but usually on mirrors
<darkxst> usually clears up after 5mins or so
<Mirv> darkxst: this was on main. I do tend to see that every now and then, but usually it's immediately that the next apt update works. this was maybe that 5min or such
<zyga> doko: looking at https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1483410 -- when I test-build the package from debain in a wily sbuild I get python 3.4 and it builds okay, what am I missing?
<ubottu> Launchpad bug 1483410 in checkbox-support (Ubuntu) "checkbox-support FTBFS in wily" [High,In progress]
<zyga> doko: is that built using something (proposed?) that has 3.5 as default?
<doko> zyga,  come out of your comfort zone and enable -proposed as the buildds?
<zyga> doko: ack, thanks
<zyga> :-)
<zyga> I'm getting hash sum mismatch on wily-proposed, is that something common/expected?
<zyga> odd, now it works
<pitti> that's the case fairly often indeed
<pitti> sil2100: did you have a chance to review http://pad.ubuntu.com/drop-obsolete-phone-packages already?
<sil2100> pitti: no, on it right now, I had a few firefights yesterday :)
<pitti> sil2100: cool, thanks; not that urgent, I was just wondering
<sil2100> pitti: ok, had a look at those
<sil2100> pitti: so libdbusmenu-qt is required and can't be removed, but I'm not sure about libcolumbus
<sil2100> pitti: the rest looks fine to get rid of
<sil2100> I remember hud was using libcolumbus on the desktop as well some time ago, so I suppose it's still using it
<sil2100> And since we have hud still in unity7 desktops, I wouldn't remove it
<zyga> doko: fixed, should I just request a new version in Debian (which might take a while, I cannot upload yet) or do you want to get the patch in ubuntu faster?
<doko> zyga, ubuntu then. and pretty please watch these packages, if you sync them, and they ftbfs
<zyga> doko: I just realized this is not in my inbox, how can I ensure we are subscribed?
<zyga> doko: I didn't explicitly sync them they just got auto synced
<zyga> doko: I'm watching debian bugs carefuly now but bugs on source packages in ubuntu still seme not to be subscribed
<rbasak> doko: in bug 1483400, you say "just building without -Werror is not an option". Why?
<ubottu> bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400
<tseliot> pitti: hi. Did you get any more reports of that symbols problem with fglrx? I'm asking as my 15.04 installation works well here
<doko> rbasak, because it fails later on boost1.58 (please talk with pitti)
<pitti> tseliot: yes, the u-d-c test still fails
<pitti> rbasak: I'm currently test-building a potential fix for both
<pitti> argh, one failed with more followup errors, the other with "out of space"
<tseliot> pitti: can you point me to the link again, please?
<rbasak> pitti: thanks! Please let me know if you need anything.
<pitti> tseliot: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/u/ubuntu-drivers-common/20150804_151050@/log.gz
<pitti> tseliot: from http://autopkgtest.ubuntu.com/packages/u/ubuntu-drivers-common/wily/amd64/
<pitti> sil2100: cheers! I'll go through them with reverse-depends again and clean up
<sil2100> pitti: thanks a lot :)
<tseliot> pitti: I'm not sure if you saw my last few messages. I was saying that it seems to me that you're testing fglrx instead of fglrx-core (which is what builds the module)
<pitti> tseliot: yes, it installs fglrx indeed
<pitti> tseliot: ah, did the module recently move from fglrx to fglrx-core?
<pitti> tseliot: then I suppose we just need to adjust the test?
<tseliot> pitti: yes, that's what I was trying to say
<pitti> tseliot: how is it called for fglrx-updates? there's no f-core-updates
<pitti> ah, fglrx-updates-core
<tseliot> yep
<pitti> tseliot: I'll try that once my computer becomes usable again (building two mongodbs ATM)
<pitti> tseliot: thanks!
<tseliot> pitti: thanks to you
<zyga> doko: how do you want me to send the patch (I never uploaded directly to ubuntu before), a debdiff attached to the bug?
<doko> zyga, do you have upload rights?
<zyga> doko: no
<doko> pff
<zyga> doko: (though I'd like to work on gettin that)
<zyga> after all those years ...
<doko> apply for it
<zyga> per package upload or UD?
<doko> dholbach, ^^^ here's your next victim
<zyga> :D
<zyga> dholbach: with pleasure :)
<doko> zyga, send me the patch, or file a bug report
<zyga> allright
<zyga> dholbach: and please tell me what to do to apply for upload rights
<zyga> doko: sent
<zyga> __hmm__
<zyga> doko: looking, I just built it like 12s of times
<zyga> oh, I see... somehow the python3-gi dependency is not in the debdiff, sorry, my bad
<doko> that's all?
<zyga> doko: yes
<zyga> doko: it's in debian, I must have d'd it by accident before running debdiff
<zyga> doko: it's a build-dependency
<zyga> doko: sorry :/
<zyga> doko: I just checked that it's not in the debdiff
<zyga> doko: do you want -1ubuntu2 or will you do that yourself?
<doko> https://launchpad.net/ubuntu/+source/checkbox-support/0.20-1ubuntu2
<pitti> rbasak: juju-mongodb now fails in that "smoke" test during build: http://paste.ubuntu.com/12054846/
<pitti> rbasak: any idea what's wrong with the pymongo module?
<zyga> doko: thank you
<pitti> rbasak: AFAICS there is no "Connection" in dir(pymongo)
<rbasak> pitti: I know no more than you on this, sorry. If the server team needs to take this on I can add it to our list.
 * pitti retries mongodb, take IV
<zyga> doko: built fine! I'll subscribe to all the source package bugs not to miss that next time
<pitti> rbasak: I'm adding my preliminary patch with the above output to bug 1483400
<ubottu> bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400
<rbasak> Thanks!
<rbasak> pitti: are you still working on the bug or are you handing it over to us?
<pitti> rbasak: I'm trying something
<rbasak> OK, np
<pitti> I found http://api.mongodb.org/python/current/tutorial.html, I hope it's just a simple renaming
<pitti> I see the test suite now, looking good
<pitti> dpkg-deb: building package 'juju-mongodb' in '../juju-mongodb_2.4.10-0ubuntu4_amd64.deb'.
<pitti> \o/
<pitti> rbasak: ^
<rbasak> \o/
<rbasak> Thank you!
<dholbach> zyga, sure... which packages do you want to upload? which did you upload in the past?
<zyga> dholbach: I never uploaded packages directly to ubuntu before, it would be fantastic if we could (the checkbox development team in general but probably me in particular for now), upload plainbox, checkbox-ng, checkbox-support, plainbox-provider-checkbox, plainbox-provider-resource-generic and perhaps one or two misc packages that I also maintain in debian, python-guacamole, python-morris, python-padme
<zyga> dholbach: we also want to land a whole new checkbox to wily and that will include two new packages (not in debian), checkbox-converged and qchartjs (a qml module)
<dholbach> nice, that should be possible
<zyga> dholbach: excellent, what do I need to do?
<dholbach> zyga, https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess explains the application process
<zyga> dholbach: allright
<dholbach> zyga, it's a lot like the membership process - so set up a wiki page, explain what you're after, get a few endorsements and attend a meeting
<zyga> dholbach: one question, should I apply for per-package uploader or for something more generic?
<dholbach> zyga, as you like it... for something more generic, you might have to demonstrate a more diverse interest or prior work on other packages
<zyga> dholbach: ok, let me read the precise difference between them and see what to do next
<dholbach> zyga, the process is very much the same
<dholbach> zyga, you might have to explain what your interests are and what you worked on in the past
<pitti> Mirv, sil2100, seb128: I processed most of http://pad.ubuntu.com/drop-obsolete-phone-packages but qml-friends and friends (and thus libfriends) are still seeded on ubuntu-touch adn ubuntu-desktop-next; should these be dropped?
<pitti> see "reverse-depends src:libfriends"
<pitti> and "reverse-depends src:friends"
<pitti> * ubuntu-desktop-next [amd64 armhf i386]  (for friends-twitter)
<pitti> * ubuntu-desktop-next [amd64 armhf i386]  (for friends-facebook)
<pitti> * ubuntu-touch [amd64 armhf i386]  (for friends-facebook)
<pitti> * ubuntu-touch [amd64 armhf i386]  (for friends-twitter)
<pitti> * unity-lens-friends            (for friends)
<zyga> dholbach: for what we are after (creation of ubuntu-specific new packages) core dev might be better as it includes "specify, develop and deploy new features for the default installation of Ubuntu" but I lack the required "hitory of substantial direct contributions to the distribution"
<zyga> history*
<dholbach> zyga, maybe start with a checkbox package set first?
<dholbach> get it created for you, and team mates can apply for that later on as well
<zyga> dholbach: yes, I think that is appropriate
<dholbach> cool
<dholbach> let me know if I can help with anything
<zyga> dholbach: so package sets are only briefly mentioned there
<zyga> dholbach: how does one create a new set?
<zyga> dholbach: is that the delegated team concept?
<dholbach> no
<dholbach> just mention which packages you need upload rights for
<zyga> ok
<dholbach> and mention that A, B and C should be made a package set
<zyga> ok
<dholbach> later on you can still go and get packages added and removed
<zyga> makes sense, thanks!
<dholbach> cool :)
<Mirv> pitti: wow, that's true
<sil2100> pitti: I'm pretty sure we don't use that anymore
<sil2100> But hm
<sil2100> Let's double-confirm with robru
<Mirv> sil2100: yeah, and in general even though we don't use the Friends anymore on the images, robru can weigh in if it'd be nice to keep it in archives still
<Mirv> sil2100: anyway, created https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_remove_friends/+merge/267648
<Mirv> it is/was a nice program from user point of view
<Mirv> but maybe it could rather live on as a click package rather than in archives, if somewhere
<seb128> pitti, unsure about friends, to be checked with kenvandine
<sil2100> Mirv: thanks!
<pitti> tseliot: that's not it -- fglrx Depends: fglrx-core
<pitti> tseliot: it actually fails to build in -proposed; I'll file a bug with the details
<pitti> make[1]: gcc-4.9: Command not found
<pitti> heh, that would do it :)
<pitti> tseliot: filed as bug 1483695
<ubottu> bug 1483695 in fglrx-installer-updates (Ubuntu Wily) "fails to build module in wily-proposed: gcc-4.9: Command not found" [High,New] https://launchpad.net/bugs/1483695
<pitti> tseliot: what I'm not sure about is where the gcc-4.9 comes from -- I can't find anything in fglrx about it
<pitti> then again, nvidia* build fine, and I don't see it in dkms itself either
<mterry> bdmurray, FYI team mapping update: ~checkbox-dev has agreed to look after xlsxwriter in main
<tseliot> pitti: maybe something's pulled in as a result of the depending on these: lib32gcc1 [amd64], libc6-i386 [amd64], dkms, make, linux-libc-dev
<pitti> tseliot: I didn't find anything that would set CC -- do you know where that gcc-4.9 might come from?
<TJ-> pitti: I believe the gcc-4.9 comes from the kernel due to parsing /proc/version in lib/modules/fglrx/build_mod/make.sh
<pitti> ah, so it tries to invoke the same compiler that the kernel was built with?
<pitti> that would explain it indeed (and why it doesn't affect nvidia or other DKMS mods)
<tseliot> oh
<tseliot> pitti, TJ-: yes, the set_GCC_version function in make.sh http://paste.ubuntu.com/12055486/
<pitti> tseliot: ah, that's it; so we either need to patch that out (preferred), or add a gcc-4.9 dep?
<tseliot> pitti: yes, a patch would be easier
<pitti> I mean "better" -> so that users don't end up with a second compiler just for this
<pitti> hm, LP keeps timing out on me, I wanted to add that info to the bug
<tseliot> pitti: I agree, I don't want to hardcode the gcc-$ver dependency
<mterry> sarnold, on bug 1455644, is it ACK to be approved *now* or did you want a release with the fixes you've discussed in wily first?
<ubottu> bug 1455644 in ippusbxd (Ubuntu) "[MIR] ippusbxd" [High,In progress] https://launchpad.net/bugs/1455644
<mterry> bdmurray, FYI team mapping update: ~ubuntu-printing has agreed to look after ippusbxd in main
<ricotz> doko, hi, maybe you are able to confirm this? this is running aptitude from wily-proposed -- http://people.ubuntu.com/~ricotz/ubuntu/aptitude-gcc5.png
<pitti> Riddell: as per http://pad.ubuntu.com/gcc-5-transition there are several KDE libs that need to be renamed to v5 and rdepends rebuilt: okular, libkdegames, marble, okteta
<pitti> Riddell: for coordination: do you plan to upload them anytime soon? is there a new upstream version for those for 5.13 which changes SONAME anyway?
<pitti> Riddell: if not, want me to upload renames?
<pitti> (and rebuilds)
<pitti> doko: ^ (FYI)
<Riddell> pitti: we're onto it
<pitti> Riddell: cool, thanks (FYI, just uploaded cantor, but that was just a no-change rebuild)
<Riddell> pitti: it's KDE Applications 15.07.90 (the third large release from KDE along with Frameworks and Plasma)
<Riddell> pitti: it'll take us a couple more days because it's got stuff ported to frameworks5/qt5 as well as the gcc transitions but I can start uploading stuff sooner
<pitti> Riddell: that's ok, I just don't want to step on your feet, thus asking who's on what
<Riddell> pitti: along with doko we're still poking the frameworks and plasma packages to compiling happyness
<pitti> these four don't block gcc-5 any more, just the konsole FTBFS
<pitti> "undefined reference to `Konsole::HistoryScroll::hasScroll()'"
<pitti> doko: oh, you didn't rename the openvdb libs? because no rdepends?
<Riddell> pitti: ok I'll look at the new version of konsole
<doko> pitti, no cxx11 symbols
<doko> ricotz, I don't use aptitude
<ricotz> doko, hmm, ok
<tdaitx> pitti, doko, infinity, slangasek: notmuch is now FTBFS on ppc64le, how can I get a ppa that has ppc64le? I need to add one debug flag to the build to see what is going on. I created LP: #1483760
<ubottu> Launchpad bug 1483760 in notmuch (Ubuntu) "notmuch FTBFS on PPC64LE" [Undecided,New] https://launchpad.net/bugs/1483760
<pitti> tdaitx: we have porter boxes (with incredibly brittle schroots)
<pitti> tdaitx: porter-ppc64el.canonical.com
<pitti> tdaitx: however, note that this isn't a blocker -- notmuch never built on ppc64el, so britney won't block it on that
<tdaitx> right, anyway, those are the only failures, that test runs gdb, I bet it is related to it
<tdaitx> pitti, err... what am I supposed to do with porter-ppc64el.canonical.com? is it offline? I can ping it, but there is no response for either http or ssh
<pitti> tdaitx: hm, I can ssh to it; maybe you aren't on the company VPN?
<tdaitx> indeed, vpn is down
<hallyn> pitti: hey, i have some systemd ignorance i'm hopng you can help with
<hallyn> when you have a minute
<pitti> hey hallyn -- better just ask, mostly left for the day already
<hallyn> pitti: trying to write systemd jobs for libvirt.  i've got the libvirt-bin one working, trying to write the one which would shut down vms cleanly before machined kills them at shutdown
<hallyn> but i've not been able to get it to run in time.
<hallyn> i'm trying to figure out what it is that does tha tkilling.  is it machined.service?  having my job run before or after that doesn't seem to work
<hallyn> debian uses a job from upstream that is supposed to suspend vms at shutdown adn restart them at startup, but that doesn't seem to be working either
<hallyn> well i guess let me take another stab at that one
<slangasek> pitti: it seems http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html hasn't updated for 10 hours
<pitti> slangasek: right, just noticed 10 mins ago (sorry), I'm at it
<pitti> slangasek: I went over the gcc-5 test regressions today and cleared out some things, pad updated
<pitti> some test fixes, some FTBFS fixes etc.
<pitti> britney should be back in the next run
<pitti> hallyn: machined doesn't really cause any peer service to get shut down; I assume you are talking about libvirt on the host, not in the guest?
<pitti> hallyn: shutting down will cause all services to get stopped; if they specify an ExecStop= then by running that, otherwise by TERM and eventually KILL
<pitti> hallyn: and with Before=/After= you can influence the shutdown order (note that it has an inverse meaning on shutdown)
<pitti> hallyn: e. g. After=network.target will ensure that a service gets stopped before anything which brings the network down, like stopping ifupdown, NM, or networkd
<hallyn> pitti: in one attempt, my service was WantedBy shutdown.target and Before=shutdown.target.  but it didn't run until later
<hallyn> in another, it is simply wantedby=multi-level.target and after=libvirt-bin.service, with execstart=/bin/true and remainafterexit=true,
<hallyn> but then the execstop seems to run as soon as /bin/true exits
<hallyn> ideally th eformer would work,
<hallyn> i.e. like a 'stop scrip' in upstart
<pitti> hallyn: with ExecStart=/bin/true it needs to be Type=oneshot, is it?
<hallyn> yes it is
<hallyn> pitti: here's the one i was really hping toulw work: http://paste.ubuntu.com/12056134/
<pitti> hallyn: looks good at first sight; so this is running too early or too late, or what goes wrong?
<hallyn> pitti: too late.  lemme get that one installed again and show the log output,
<hallyn> pitti: http://paste.ubuntu.com/12056205/ and /var/log/libvirt/shutdownlog.log .
<hallyn> maybe if i add After=libvirt-bin...
<pitti> hallyn: http://paste.ubuntu.com/12056205/ is very short, and doesn't contain "libvirt" at all -- wrong log?
<hallyn> pitti: http://paste.ubuntu.com/12056205/ is syslog output, from where i 'virsh start cdboot' until after some things have shutdown due to shutdown
<hallyn> the other is the /var/log/libvirt/shutdownlog which is written to by the script called at ExecStop
<hallyn> is there a way to get 'journalctl' to show me the last boot's journal?
 * hallyn sees --list-boots
<pitti> hallyn: yes -- enable persistant journal (/usr/share/doc/systemd/README.Debian
<pitti> hallyn: then sudo journalctl -b -1
<hallyn> sigh
<hallyn> how come that's not auto-enabled? :)
<hallyn> thanks, that's very helpful
<pitti> hallyn: because we install rsyslog by default, and I don't want every log be written to disk twice
<pitti> /var/log/syslog should also contain most things
<hallyn> pitti: http://paste.ubuntu.com/12056255/  full boot log showing the ordering
<hallyn> pitti: sadly no syslog misses a lot of systemd ordering info
 * pitti really needs to run now, o/
<hallyn> pitti: thanks \o
<doko> jibel, please could you have a look at the autopilot autopkg test failure? somehow urgent
<jibel> doko, sure
<flexiondotorg> I'm migrating some Ubuntu MATE application to python3 because I see that is an objective for 16.04.
<flexiondotorg> Should I reference python3 in the shebang or just rely on the packaging to install the correct versions?
<flexiondotorg> Just interested to know what others are doing in this regard.
<flexiondotorg> The code will run on Python 2.6+ and Python3.3+ now.
<doko> barry, ^^^
<jibel> doko, it's an unreliable test apparently and nothing to do with gcc. Can you force it? I'll ask veebers to fix it.
<doko> slangasek, ^^^ can't do this myself
<slangasek> doko: context? what test?
<slangasek> doko: if you can document it on the pad, that's the best way to track at the moment
<slangasek> (I guess autopilot-gtk)
<doko> slangasek, done
<doko> barry, https://launchpad.net/ubuntu/+source/pytables/3.1.1-3build2
<jibel> doko, slangasek filed a bug and added details to the pad.
<juliank> doko: We're trying to get current APT git building on travis-ci.org again, for continuous integration. But it  keeps failing with internal compiler errors in most cases, with both gcc 4.9 and 5.1 from https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test - idea?
<juliank> dobey: travis-ci runs precise, BTW.
<doko> juliank, check wily-proposed, not interested in anything else
<dobey> uhm, ok
<doko> seb128, Laney: norwegian is dep-wait, please file a MIR or drop the additional requirements
<jdstrand> darkxst: I responded in the bug (sorry, I was on vacation last week)
<doko> seb128, Laney: gnome-online-accounts is dep-wait, please file a MIR or drop the additional requirements (just one more webkit copy)
<seb128> doko, there is a mir for webkit2gtk
<doko> seb128, without dropping anything? I can assure you that jdstrand will reject that
<seb128> doko, see https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1466290
<ubottu> Launchpad bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New]
<seb128> which jdstrand was just mentioning
<jdstrand> that was actually what I just responded to, above
<doko> smoser, https://bugs.launchpad.net/ubuntu/+source/acpica-unix/+bug/1483836
<ubottu> Launchpad bug 1483836 in acpica-unix (Ubuntu) "acpica-unix ftbfs on powerpc" [High,Confirmed]
<hallyn> pitti: ok, i think i've figured out my problem.  slice dependencies were messing with me
<hallyn> eureka
<dragos> guys i have an cool idea
<dragos> for ubuntu
<doko> seb128, Laney: ibus-chewing is dep-wait, please file a MIR or drop the additional requirements (cmake-fedora)
<boldfilter1> Ping IdleOne
<doko> mterry, welcome to the gcc 5 madness
<mterry> doko, :)
<mterry> doko, figured I'd help out
<doko> is clementine your next one?
<doko> looks similar
<mterry> doko, oh is it?  where are you seeing that?  I can take it
<doko> ahh, no, already fixed
<mterry> \o/
<ari-tczew> does anybody know a workaround for long taking time pbuilder while "I: Obtaining the cached apt archive contents" ?
<ari-tczew> I think more than 15 minutes is not a normal
<doko> zyga, https://launchpad.net/ubuntu/+source/plainbox/0.22.2-1/+build/7738741
<slangasek> mterry: are you working on the freecad build failure?  this should be the same fix as for other qt4+boost1.58 bugs
<slangasek> mterry: oh, Debian bug says you have :)
<mterry> slangasek, yeah I was, and uploaded a patch
<mterry> slangasek, but now I'm hitting something unexpected and am looking into it
<slangasek> ok
<ochosi> hey everyone, anybody else apart from Sweet5hark taking care of libreoffice packaging?
<hallyn> sigh.  is it too late to delete https://launchpad.net/ubuntu/+source/libvirt/1.2.16-2ubuntu6 ?
<hallyn> it's still Pending, so i'm kinda hoping not
<hallyn> maybe my testing is bogus anyway.
<infinity> hallyn: I can delete it.
<infinity> hallyn: But ask quickly.
<infinity> hallyn: You could also add the "block-proposed" tag to your bug there, so it never migrates.
 * infinity does that for you.
<hallyn> infinity: i dunno, i had one vm where upgrading upset systemd.  but a new one is fine.  my worry is - I'm switching from the syvsinit job to a systemd job.  but the first vm mustve had something else funky i think
<hallyn> there's not supposed to be anything for me to do manually in preinst-postinst right?  dh_installinit + dh_systemd should do it for me...
<hallyn> yeah upgrade went fine here.  what the hell happened in the other place
<infinity> hallyn: That's the general theory.  That said, a new systemd service that didn't exist before and autostarts in postinst might exhibit curious behaviour if the daemon is already running.
<hallyn> however that job is --restart-after-upgrade, so it must get stopped from sysvinit and then started from systemd right?
<infinity> hallyn: Anyhow, you missed your chance to delete before it's published, it's on disk now.  But that bug has block-proposed on it still, so when you're happy with things, remove that.
<hallyn> otherwise it would get very screwed :)
<hallyn> infinity: thanks
<infinity> hallyn: restart-after does the restart all in postinst, so there'd be no way of knowing to stop the sysv job, unless the systemd unit is smart enough to find the orphaned not-a-systemd-service version of the daemon and eat it first.
<infinity> hallyn: There's also a stop on prerm, start on postinst semantic, but you can't go back in time and make the old package do that. :)
<infinity> hallyn: Why did you write libvirt-stop-guests twice? :P
<infinity> hallyn: Surely, the init script can call it instead of embedding a copy.
<hallyn> so the q is whether i need to add a stop to pre-inst
<hallyn> infinity: ?
<hallyn> init script can call what?
<infinity> /usr/lib/libvirt/libvirt-stop-guests
<hallyn> oh.  yeah.
<infinity> Ditto if there's a copy of the same logic already in the upstart job.
<hallyn> i'd done the inline version first before i realized there was no way to do it from sysvinit
<infinity> "No way to do it from sysv" seems fatalistic.
<infinity> And probably not true...
<hallyn> yeah will clean that up if i have to push a new version
<hallyn> no - libvirt defines VMs with systemd-machined, which then hard-kills them at shutdown.  you can't get a sysvinit job to block that hard-kill
<infinity> Ugh, another systemd-rules-the-world thing?
<infinity> When did that happen?
<hallyn> took me two days to find where tha twas done - the systemd service name you have to define is hardcoced in libvirt
<infinity> Still, there must be a way to order that differently.
<hallyn> years ago actually, but when we used upstart we could ignore it
<hallyn> "it's opt-in"
<hallyn> well we could compile libirt to nto use systemd-machined
<hallyn> s/compile/patch/
<infinity> I mean ordering of the shutdown.
<hallyn> the other code is still there as a backup if systemd isn't running
<infinity> Or is it because services are all acted on before sysv, because sysv is a second class citizen?
<infinity> Except, no.  It should be the inverse on shutdown.
<infinity> sysv first, then systemd services.
<infinity> So, one should be able to stop things gracefully from sysv before systemd goes nutty on it.
<infinity> If it's not inverted on shutdown, that's a bug in our systemd sysv emulation, IMO.
<hallyn> i don't think so.  libvirt tells systemd "create this slice for the vm, and it is Before=libvirt-guests which will shut it down orsuspend it"
<hallyn> not sure about before, but at least in parallel
<infinity> hallyn: Also, minor nitpick, that "Suggests: systemd" is pointless.  It's pretty much a no-op.
<hallyn> i don't know the systemd code enough to know how systemd-machined-defined slices relate
<hallyn> ok i'm removing the duplicate libvirt-sotp-guests from libvirt-bin.init, but removing it from the upstart job worries me bc users may be depending on changes they made to variables in /etc/defualt/libvirt-bin
<hallyn> infinity: ok, yeah, systemd doesn't know what to do with libvirt afte rthe upgrade.  so i guess in pre-inst from older versions i'll stop libvirtd by hand
<infinity> hallyn: If the upstart version uses bits sourced from /etc/defualt/libvirt-bin, then the new script should source it too, no?
<bluesabre> hi doko, ochosi tells me that you might be able to help with a libreoffice packaging request
<bluesabre> bug 1483914
<ubottu> bug 1483914 in libreoffice (Ubuntu) "libreoffice-style-elementary as alternate to libreoffice-style-human" [Undecided,New] https://launchpad.net/bugs/1483914
<hallyn> infinity: i dunno.  sounds reasonable....  i was just going by the "systemd jobs don't like /etc/default" mantra
<infinity> hallyn: Pfft.
<bluesabre> The Xubuntu team is shipping libreoffice, libreoffice-gtk, and libreoffice-style-elementary this cycle
<infinity> hallyn: If it was tunable before, upgrading shouldn't break that.
<hallyn> so yeah i'll do that and yank it from hte upstart job
<infinity> hallyn: So, /usr/lib/thing should be a cargo-cult of the upstart logic, including sourcing the defaults file, then tear it out of upstart/systemd/sysv and replace with refernce to script.
<infinity> hallyn: The upshot of that sort of thing is that it makes maintaining all three inits super simple too, which is nice.
<infinity> hallyn: You get to be a fence-sitting commitment-free developer with near zero effort.
<hallyn> infinity: one bugaboo being that upstart wanted libvirtd -d, systemd does not.  so /etc/default/libvirt could cause problems.  but it shouldn't in the libvirt-stop-guests script
<infinity> hallyn: What's "-d"?  Daemonize?
<infinity> hallyn: If so, you were using upstart wrong.
<infinity> hallyn: Using "-d" and then "expect daemon" is just obtuse.  upstart's default mode, without the "expect" is to want foreground processes, same as systemd.
<infinity> hallyn: (sysv, OTOH, probably wants "-d" to be sane)
<hallyn> yes
<hallyn> luckily i can point to the author field and say i didn't do it :)
<infinity> Heh.
<ochosi> doko: just fyi, i'm the maintainer of that icon theme. as mentioned in the bugreport, we're trying to get this upstream too, but that might take a bit and we'd like to ship it by default in xubuntu 15.10
<infinity> hallyn: Well, no point changing that bit now, if it works, it works.
<infinity> hallyn: But if we had a time machine, I'd tell past Dustin he was wrong. :P
<sarnold> ochosi: btw, it's nice to prefix every line with the other person's nickname, so they can read it all with /lastlog -hilight -- otherwise picking out the bits of conversation ten hours later is difficult
<hallyn> ok those changes are made, but i still need to test the pre-inst bit.
<ochosi> sarnold: i thought that was what i did?
<hallyn> infinity: any harm in my waiting for morning to upload the new version?
<ochosi> sarnold: oh, i guess you're referring to bluesabre not doing that before
<sarnold> ochosi: ah, I'm sorry, I didn't notice the different nick between bluesabre and ochosi. /me hangs his head in shame.
<ochosi> heh, no worries ;)
<bluesabre> woops
<infinity> hallyn: Not unless your users run wily-proposed.
<infinity> hallyn: Which no one should.
<bluesabre> doko: bug 1483914
<ubottu> bug 1483914 in libreoffice (Ubuntu) "libreoffice-style-elementary as alternate to libreoffice-style-human" [Undecided,New] https://launchpad.net/bugs/1483914
<bluesabre> doko: The Xubuntu team is shipping libreoffice, libreoffice-gtk, and libreoffice-style-elementary this cycle
#ubuntu-devel 2015-08-12
<hallyn> infinity: http://paste.ubuntu.com/12059133/  seems to be working, and i think incorporates your suggestions
<infinity> hallyn: ITYM "after 16.04".
<infinity> hallyn: The unnecessary whitespace change in the init script is gross (tabs versus spaces) if that introduces a delta with Debian.
<infinity> hallyn: Well, it's gross either way, but worse if it's a delta. :)
<hallyn> infinity: do I?  I thought that so long as 16.04 existed people might be upgrading from something older
<infinity> hallyn: I think one of us might be confused about the meaning of the word "after"?
<infinity> hallyn: 16.04 needs to have the upgrade code.  16.10 doesn't.  16.10 is after 16.04.
<infinity> hallyn: Similar whitespace changes in postinst too.  You're good at that.
<infinity> Or your editor hates your freedom?
<hallyn> yes when i edit a block i try to make it tab/space-consistent
<hallyn> maybe i shouldn't, it does complicate the diff
<infinity> Well, it's particularly bad if this is shared code with Debian.
<infinity> If it's all your code, meh.
<hallyn> re debian delta, we're not syncing from debian at all right now.  considering trying to merge in next few months, but it's been years since we'v edone that
<infinity> hallyn: What does "service libvirt-bin stop" do?  Is that going to kill everyone's VMs during the upgrade?
<infinity> Kinda looks like it will...
<infinity> Oh, but it won't because the init script was missing that bit before. :)
<infinity> And the upstart job guards against running stop outside the stop runlevels.
<infinity> hallyn: Okay, so that seems reasonable.  The same runlevel guard might be nice for the sysv implementation, but we'll never use it anyway (but if you intend to push this to Debian...)
<infinity> hallyn: The only remaining question is are the the systemd services similarly guarded somehow, or will stopping the systemd service stop all guests?
<hallyn> infinity: with the systemd jobs, the libvirt-stop-guests is only run right before machined would kill them anyway
<hallyn> i.e. libvirt-bin stop by itself does not call kill the vms
<hallyn> but now that you mention it i'm not sure that the sysvinit variant is doing the right thing there...
<hallyn> so i think i'll just drop that delta - meaning the bug won't be fixed for anyone who's insisting on running sysvinit
<hallyn> bc i don't know offhand how to tell in sysvinit jobs what runlevel we're in
<infinity> hallyn: You can ask it.
<infinity> hallyn: /sbin/runlevel echoes "X X" for previous and current runlevel.
<infinity> hallyn: ie "N 2" or whatever.
<hallyn> meh
<hallyn> one more thing to break if i do it :)
<hallyn> all right all righ ti'll do it
<hallyn> thanks :)
<pitti> Good morning
<pitti> hallyn: good!
<pitti> slangasek: gcc-5 promotion -> \o/
<hallyn> infinity: ah, but apparently /sbin/runlevel still says 'N 5' during reboot :)  guess it's transitioning *to* 6, but not yet there :)
<infinity> pitti: Does it seem sane that apt is waiting on autopkgtests for a version of python-apt that has no binaries?
<pitti> infinity: that's a change from yesterday, see ubuntu-release@
<pitti> infinity: it's always a compromise one way or the other :/
<infinity> pitti: Yeah, hrm.
<infinity> Oh well, guess I need to merge the newer apt.
<pitti> infinity: slangasek responded on the list, I'll respond again
<pitti> we might be able to fine-tune this a bit
<pitti> infinity: but this illustrates it rather well: at this point we don't know whether the new apt breaks the new python-apt, or whether python-apt is broken in its own right
<pitti> doko: oh, http://launchpadlibrarian.net/214180176/okular_4%3A15.04.2-0ubuntu2_4%3A15.04.2-0ubuntu3.diff.gz was not an ABI change? I had it noted down as "needs rename/transition" in the pad
<slangasek> pitti: hey, what is the 'Removal candidates' list on http://pad.ubuntu.com/gcc-5-transition for? are these things you are proposing to remove, things you know have been identified as removal candidates in Debian?
<pitti> slangasek: I think that's Laney's
<slangasek> ah
<slangasek> you're right, it's his color not yours :-)
<pitti> slangasek: but I read it as "gpid-cpp" is RC buggy and removed in Debian, so we could think about removing it in Ubuntu instead of fixing it
<pitti> or bumping to -proposed
<slangasek> ok; I think that's better handled by flagging down an archive admin rather than putting it in the pad
<pitti> we could do the same with bombono-dvd
<pitti> slangasek: I'm still working on FTBFS, and finishing up transitions; is there anything else/more important you want me to look into?
<slangasek> no objection to removing bombono-dvd; at the moment I'm just trying to clean up the pad a bit for readability
<pitti> yeah, I went over it and removed the finished items
<slangasek> pitti: FTBFS+transitions> I think that will probably keep you busy for at least another day
<pitti> slangasek: for sure :) I'll need half a day for that systemd bug fix with "systemctl link" and to prep my debconf talks, but I'll continue with the gcc bits
<pitti> slangasek: FAOD, http://people.canonical.com/~ubuntu-archive/transitions/html/html/icu.html can be moved to "finished", right?
<pitti> boost1.55 is itself obsolete, and cg3 is just NBS (new version built fine)
<infinity> Why the *(&*%! is gcc-5 so huge?
<infinity> My chroots just doubled in size when I refreshed them.
<pitti> they might not have purged gcc-4.9 along?
<infinity> pitti: I did.
<infinity> pitti: And that really wouldn't account for it anyway.  They literally doubled.
<infinity> armhf went from 118M to 223M.
<infinity> Okay, not quite, but basically double.
<infinity> Installed-Size for gcc-5 is 125MB all on its own.
<infinity> doko: ^-- Is that intentional or a horrible bug?
<infinity> And 135MB for g++-5
<ricotz> leftover debug symbols?
<pitti> vs. 18 MB for gcc-4.9
<infinity> And 30ish for g++-4.9
<infinity> So, yeah.  A bit of growth there. :P
<infinity> Oh well.  I'll upload these chroots to take pressure off queues, and we can fix this later.
<pitti> -rwxr-xr-x 1 root root 124324976 Aug  9 15:14 /usr/lib/gcc/x86_64-linux-gnu/5/lto1
<pitti> "not stripped"
<infinity> Hah.
<infinity> That would certainly do it.
<infinity> Similar failure for g++?
<pitti> $ cp /usr/lib/gcc/x86_64-linux-gnu/5/lto1 /tmp/; strip /tmp/lto1; ls -lh /tmp/lto1
<pitti> -rwxr-xr-x 1 martin martin 18M Aug 12 07:50 /tmp/lto1
<pitti> much nicer :)
<pitti> -rwxr-xr-x 1 root root 131M Aug  9 15:14 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus
<pitti> yes, seems so
<pitti> reduces to 20 MB after stripping
<infinity> pitti: Can you point those two out to doko when he wakes up so they don't get lost in backscroll?
<pitti> infinity: ack
<infinity> pitti: And I'm updating chroots anyway, so no pressure to fix it ASAP (as that'll invalidate the chroots...)
 * pitti moves 11 more transitions to "finished", yay
<infinity> THough, it'll take a good half hour to upload these chubby chroots.
<infinity> La la la.
<Bluefoxicy> Hey, here's an idea
<Bluefoxicy> how about every 6 months automatically backporting the entire standard release repository into the LTS as a point release, and automatically updating anyone who runs apt into the new 6 month release, with no support (or security updates) for the old versions of all the software
<Bluefoxicy> We could call it "Red Hat Enterprise Linux"
<darkxst> Bluefoxicy, you would have to call it Fedora, RHEL don't backport new versions, just security fixes
<Bluefoxicy> darkxst:  I'm just venting.
<Bluefoxicy> RHEL point releases "carry major architectural changes, so you should read the release notes carefully"
<Bluefoxicy> as a result,  when you have RHEL 6, you have... something.
<Bluefoxicy> They claim RHEL 6 is a stable software distribution--like, say, Ubuntu 12.04 LTS
<Bluefoxicy> but at every point release--say, 6.3, 6.4, 6.7--they do major version upgrades of software, in a similar way from moving from 12.04 to 12.10 to 13.04
<Bluefoxicy> This of course means all support for the prior point release effectively ends
<Bluefoxicy> so it's like if Ubuntu ran a 6 month cycle and automatically updated the same existing repository (instead of making a new release), dropping all support for prior versions immediately when a new version came out.
<Bluefoxicy> which, when you get right down to it, with RHEL claiming 20 years support of a stable distribution, is what's colloquially known as talking out both sides of your mouth.
<Bluefoxicy> They asked me at work if we should switch from CentOS to RHEL to get some sort of real support contracts, even though we're aware RHEL support is functionally useless.  I told them the pragmatic option--and thus the ethical and responsible one--is to switch from something Redhat-based to Ubuntu LTS :|
<Bluefoxicy> They pay me to do my job well, not to cover my ass with useless but bureaucratically-placating support contracts.
<Bluefoxicy> /rant
<Bluefoxicy> Also, if anyone ever suggests rewriting support policy to favor more major changes on LTS point releases, stab them in the face.
<dholbach> good morning
<darkxst> Bluefoxicy, I thought once upon a time, RHEL point releases were opt-in, not automatic
<Bluefoxicy> darkxst:  in so much as running yum update is opt-in, the problem with that being you're opting out by no longer running updates.
<Bluefoxicy> let's say you didn't run updates for a month.  Well, unless you want to select each update--each security patch and bug fix--prior to the latest point release by hand, specifying the exact version to install, you can't patch up to the latest on current.
<Bluefoxicy> The guy who did this a week before point release is in the same boat, but closer.
<Bluefoxicy> it's as if you just took the Trusty repositories and shoved the Utopic packages into them.
<Bluefoxicy> darkxst:  btw, if you have a support contract, and you tell them you haven't run yum update to the latest patch, they will refuse to support you until you do so.  :P
<Bluefoxicy> It's like how you have the option to surrender to the police.  It's not mandatory; you could just let the police shoot you in the back of the head while you run away.
<darkxst> Bluefoxicy, go find a red hat channel perhaps!
<Bluefoxicy> ha.
<Bluefoxicy> YEah I've vented more than I cared to tbh.
<zyga> doko: ack, thanks
<zyga> hmmm, is it just me or is debian unstable/sid archive gone?
<zyga> ah
<zyga> yeah, I should get a coffee before trying to fix bugs
<zyga> doko: do you know when debian plans to switch to python 3.5 as default?
<pitti> Laney: I'm currently going through http://people.canonical.com/~ubuntu-archive/transitions/html/
<pitti> Laney: i. e. cleaning up finished transitions, uploading missing rebuilds, noting FTBFSes, and such; pad is up to date
<Laney> pitti: nice
<Laney> I'll check up on some others shortly
<pitti> Laney: I retried some of your FTBFS, but I might have missed smoe
<Laney> some kind soul retried bpp stuff
<Laney> \o/
<pitti> Laney: yeah, that was part of "going through transitions and try to fix" :)
<pitti> but only 40% through so far
<pitti> touch-core: * libtinyxml2-2               # camera/gallery
<pitti> WTF?
<pitti> why are we seeding libraries in touch?
<pitti> sdk-libs: * libjsoncpp0v5
<pitti> touch-core: * libzen0
<infinity> pitti: Because someone doesn't understand how dependencies work?
<pitti> my friends, this is wrong
<infinity> pitti: The sdk-libs thing, unfortunately, has an excuse.  All it *is* is a collection of runtime libraries.  Though, auto-generating it from the deps of sdk-libs-dev might be clever.
<pitti> yes, granted; but in touch-core?
<infinity> pitti: The touch-core thing is almost certainly someone doing something wrong.
<pitti> is that because we are working around our own click specification?
<pitti> i. e. "click packages don't have deb dependencies"?
<infinity> pitti: Possibly?
<infinity> (also, ew?)
<seb128> pitti, that doesn't have much to do with clicks I think
<seb128> rather it's up to define what libs we support as part of the base image
<seb128> which is othogonal to click depends
<pitti> seb128: that should be in sdk-libs, but nowhere else
<seb128> right
<seb128> just commenting about workarounding clicks
<pitti> and it says "camera/gallery" which sounds like a really bad workaround
<seb128> workaround to what?
<pitti> it's been there forever apparently
<seb128> clicks are not part of the OS
<seb128> they can't be what brings a lib in
<pitti> seb128: to what> well, I don't know -- some broken dependency somewhere, or maybe it's obsolete?
<pitti> seb128: yes, that's what I mean -- clicks can only depend on platform-api, so if they have an implicit dependency to a packaged lib they are broken
<pitti> that what I mean with "working around our own click spec"
<seb128> right
<seb128> but that doesn't have to do with the spec
<seb128> either the lib should be part of the base image
<seb128> or they shouldn't use it
<seb128> or they should have their own copy
<pitti> right
<mwhudson> er is there some way i can see if a package is still tied up in the gcc5 transition?
<infinity> mwhudson: You might need to expand on that a bit.
<infinity> mwhudson: A package in proposed?  A package you want to upload and you don't know if it'll get stuck?
<mwhudson> it was a bit gnomic wasn't it
<mwhudson> this build blew up https://launchpadlibrarian.net/214259852/buildlog_ubuntu-wily-amd64.unity-scope-snappy_0.1.0%2B15.10.20150721-0ubuntu1_BUILDING.txt.gz
<mwhudson> with things like src/launchpad.net/unity-scope-snappy/internal/launchpad.net/go-unityscopes/v2/activationresponse.cpp:25: undefined reference to `unity::scopes::Variant::deserialize_json(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
<mwhudson> which certainly tickes my c++ abi break spider sense
<mwhudson> and now i see from https://launchpad.net/ubuntu/+source/unity-scopes-api that there is a package in proposed
<mwhudson> heh i wonder if i'd get more or less brokeness if i enabled proposed as a dep
<infinity> mwhudson: PPAs that aim to test things for the archive should generally build against proposed anyway.
<infinity> mwhudson: On the flip side, if things can't build in the release pocket, that's a pretty serious issue.
<mwhudson> yes i guess that makes sense
<mwhudson> well the latter point should be easy enough to check
<mwhudson> oh and blargh i guess i should have copied from the release pocket too
<mwhudson> no
<mwhudson> proposed
<mwhudson> infinity: do you ever sleep?
<infinity> mwhudson: Sort of.
<flexiondotorg> seb128, I saw your post on the ML about testing BLuez5. Do you want me to build Blueman2 in a PPA, linked to the Bluez5 trasition PPA, or will you be able to build Blueman2 in the transition PPA?
<pitti> Laney: ah, I noticed that several of our demotions (bombono-dvd, crystalspace) went back into wily; for bombono-dvd I went with removal and reupload
<pitti> Laney: do you know a better trick for that?
<pitti> Laney: a FTBFS bug with "block-proposed" should do
 * pitti demotes again
<Laney> pitti: ah, if their deps are still satisfiable then I have blocked in the past
<pitti> Laney: ok, will do that from now on
<pitti> Laney: yeah, they only will stop being satisfiable once the transitinos land
<Laney> meh, we're racing on these
<seb128> flexiondotorg, I'm looking at it, but your sync request doesn't state why the delta is not needed anymore
<dholbach> can somebody moderate my mail on u-d-a?
<pitti> looking
<dholbach> <3
<pitti> gern :)
<pitti> Laney: I stop firing transition uploads for now, going back to sifting through the resulting FTBFS; so it's all your's :)
 * Laney is test building before uploading so doing both simultaneously :)
<pitti> I got through maybe 60% of the transitions, so please check for existing rebuilds before you fire mass-rebuilds
<Laney> I tried to use the pad to lock transitions but that wasn't really working
<pitti> ah, I don't have enough horsepower for that
<pitti> Laney: yeah, I added them this morning, but removed them again as it's too unwieldy
<pitti> Laney: I usually just click through the package names on a transition page, and ignore the ones which already have rebuilds
<Laney> the rebuild-fix-sign-upload cycle adds some delays here :P
<mwhudson> ah so it's you guys who are stopping my arm64 ppa builds from ever happening
 * mwhudson goes to bed and will resume when all the europeans have gone away
<Laney> we are children of doko
<pitti> Laney: I started with test-building, but after I ran into the fourth package with a 3 h build time I gave up
<doko> mwhudson, which one?
<pitti> mwhudson: trust me, we have the same feeling :)
<mwhudson> doko: https://launchpad.net/~mwhudson/+archive/ubuntu/go15-rc-tests/+packages
<doko> ci-train is eating all the time, it's not me
<pitti> mwhudson: this morning 4 out of 5 builders were building PPA stuff
<mwhudson> yeah, i'm mostly just being silly
<pitti> anyway, no need for a blame game, we just need to wait
<mwhudson> and really should go to bed
<doko> mwhudson, ahh, not just one package. sorry, has to wait
<pitti> mwhudson: no worries, we all like to joke about it :) good night!
<mwhudson> obviously builds for the archive trump ppa builds :)
<doko> bumped golang
<mwhudson> doko: ah thanks
 * pitti cancels all queued arm64 builds which are going to FTBFS anyway, to help a bit
<Laney> vtk has a broken shlibs file
<Laney> that'll probably be why all http://people.canonical.com/~ubuntu-archive/transitions/html/vtk-g++5.html failed
<Laney> at least initially
<alkisg> Hi, I'm trying to troubleshoot a regression where wily has CHARMAP="ISO-8859-15" instead of CHARMAP="UTF-8" in /etc/default/console-setup, any clues on how to pinpoint that change?
<alkisg> (it breaks non-ascii output in VTs)
<pitti> apw: please ignore bombono-dvd, I demoted it to -proposed
<doko> Laney, are you currently looking at vtk?
<Laney> doko: rebuilding it
<Laney> locally
<Laney> will check it can rebuild stuff before uploading
<Laney> takes a while so don't want to waste buildd time :)
<pitti> we've got plenty of x86 and even armhf power :) (I just tend to cancel builds of ppc64el and arm64, as these are the scarce ones)
<Laney> I can build it faster than they can anyway
<Laney> and then I can also iterate
<Laney> and instantly try r-deps instead of waiting for publisher
<Laney> etc :)
<alkisg> Is there a bzr branch of console-setup in launchpad that I can branch and find the commit that caused the regression?
<alkisg> It's Ubuntu-specific, it's not there e.g. in Debian
<Laney> apt-cache showsrc console-setup | grep Vcs # or just debcheckout console-setup
<alkisg> Thanks
<tseliot> Laney: hi, I've just updated my code for this review (QA tested it). If you're ok with it, I'll push the same changes for 14.04: https://code.launchpad.net/~albertomilone/unity-settings-daemon/non-blocking-touch-mapping-wily/+merge/266248
<Laney> tseliot: ok, will look soon
<tseliot> thanks
<Laney> thanks!
 * pitti moves another 4 transitions to "done" -- this evening after arm64 catches up, http://people.canonical.com/~ubuntu-archive/transitions/html/ ought to fit on one page :)
<Laney> pitti: are you tracking the accidental migrations?
<Laney> (/me noticed feel++)
<pitti> Laney: no, hard to track; thanks, will demote and file an RC bug (after lunch)
<apw> pitti, i think i have actually fixed bonbono-dvd if we care
<pitti> apw: oh, even better :)
<Laney> upload it
<Laney> britney will sort it out
<alkisg> Meh. Purging and reinstalling console-setup fixes the issue
<alkisg> So the problem is not in the packaging, it's probably in the code that generates the .isos
<alkisg> That code is closed-source, isn't it?
<alkisg> Where would I file a bug report against it?
<ogra_> alkisg, https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup not closed source :)
<alkisg> Thanks Oli, checking...
<ogra_> alkisg, you also want to take a look at livecd-rootfs (that assembles the rootfses)
<ogra_> (the nusakan branches have equivalents on launchpad)
<ogra_> (the private/production branch only carrries lists or mail addresses nowadays afaik)
<ogra_> (nothing relevant for building)
<alkisg> Ah wait it looks like I was wrong, LANG=C apt-get install console-setup ==> broken CHARMAP, LANG=C.UTF-8 apt-get install console-setup ==> UTF-8 CHARMAP
<alkisg> So a wrong LANG setting at installation (iso generation) time can cause this...
<alkisg> I think that's best solved in console-setup, to ignore the LANG setting at postinst
<alkisg> Thanks, I'll file a bug report against it
<alkisg> (I still don't know at what point the regression started, it's there in 15.04 as well)
<seb128> doko, could you comment on the change mentioned on https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1448548? "Only install the openjdk-java.desktop file when using cautious-launcher." ... it makes .java files have no handler in e.g nautilus
<ubottu> Launchpad bug 1448548 in openjdk-8 (Ubuntu) "OpenJDK 7/8 don't generate .desktop needed by nautilus" [High,Confirmed]
<doko> seb128, I'd like to defer that to jdstrand, mdeslaur, sbeattie. made on their request
<seb128> doko, k
<seb128> jdstrand, mdeslaur, sbeattie ^
<pitti> mwhudson: actually, CI train service trumps the archive at least for universe packages (what we are largely dealing with) -- 4010 vs. 3270
<pitti> (build score)
<shadeslayer> is there a way for deferred package removal?
<shadeslayer> so that I can mark a package to be removed later on
<pitti> shadeslayer: what should that be?
<pitti> a bug report? :-)
<shadeslayer> pitti: it's a alternate installer to ubiquity, that needs to remove itself, kind of like how ubiquity-oem marks itself for removal perhaps
<pitti> ah, I thought "remove from the archive"
<shadeslayer> ah no, from the system
<shadeslayer> problem is that the installer is operating in a OEM like mode
<pitti> I suppose you could mark it as "automatically installeD", so that apt-get autoremove will clean it up?
<pitti> (man apt-mark)
<pitti> but IIRC ubiquity has an explicit list of packages that it purges after install
<shadeslayer> pitti: the problem is that it loads a plugin to show the "finished" page, that plugin is removed after the package removal step is run, which is before the finished page
<alkisg> ogra_: how can I file a bug report against ubuntu-cdimage?
<alkisg> I've filed https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1484101 against console-setup, but I think it should also be solved in the .iso generating code as well
<ubottu> Launchpad bug 1484101 in console-setup (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,New]
<alkisg> I.e. when installing packages, it shouldn't be using LANG=C but e.g. C.UTF-8
<ogra_> alkisg, https://bugs.launchpad.net/ubuntu-cdimage/+filebug ?
<alkisg> No items matched "ubuntu-cdimage".
<ogra_> alkisg, but ubuntu-cdimage doesnt install any packages, it only rolls bootable images out of existing components
<alkisg> (I'm clicking "also affects project/distribution")
<ogra_> for the rootfs you want to file against livecd-rootfs ...
<alkisg> Thanks, searching...
<alkisg> Yup it does have LANG=C at the top of the BuildLiveCD script
<ogra_> thats fine
<ogra_> but the LANG=C in live-build/auto/build is probably not
<ogra_> BuildLiveCD only sets up the outer-most chroot ... there are multiple chroots in an onion model ... the actual rootfs chroot setup lives in live-build/auto/build
<alkisg> Done, thank you, fortunately LTS live CDs were not affected
<seb128> StevenK, hey, seems like there are no admin atm on the ~bluetooth can you give me access? we would like to re-activate it to maintain bluez&co
<seb128> morphis, ^
<juliank> jodh_: I am currently closing segfault bugs for APT, and https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1016040 is assigned to you. Can I close that, it's probably working in recent versions.
<ubottu> Launchpad bug 1016040 in apt (Ubuntu) "apt_check.py crashed with SIGSEGV in FileName()" [Medium,Confirmed]
<StevenK> seb128: I've added you, and promoted you to admin and owner.
<doko> pitti, Laney: could you proof-read this draft for u-d-a? http://paste.ubuntu.com/12061573/
<seb128> StevenK, thanks!
<pitti> doko: "The majority of the packages" .. actually we rebuilt more than half of them already (but nitpicking)
<Laney> doko: erm, I wouldn't recommend that use wily-proposed
<Laney> why do you want to do that?
<pitti> doko: "brake" -> "break"
<pitti> doko: and what Laney said
<pitti> we should never ever recommend enabling devel-proposed
<pitti> just in schroots
<Laney> maybe we should target transitions that touch the desktop though?
<doko> pitti, the majority compared to those already migrated
<Laney> I didn't look at the situation there
<pitti> doko: maybe add "Relevant FTBFS are tracked on http://pad.ubuntu.com/gcc-5-transition -- help with those is greatly appreciated to unblock library transitions." ?
<pitti> http://qa.ubuntuwire.com/ftbfs/ is rather intractable for getting the g++ transitions done IMHO
<doko> Laney, I'm running a wily-proposed desktop, so at least there are no more transitions
<Laney> doko: all transitions that touch packages in the desktop need to be finished to get it all to migrate
<Laney> that could be a good priority list
<doko> Laney, do you have a list?
<Laney> nope
<Laney> there's some terrifying thing going on with unity/libsigc++-2.0
<doko> ?
<doko> Laney, pointers?
<Laney> doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt search for libsigc++-2.0
<Laney> it's probably "just" entanglement
<doko> yes, "just" ;)
 * pitti moves 9 more transitions to /finished \o/
<pitti> doko: did you see backscroll about gcc-5 and g++-5 being ginormous due to unstripped binaries?
<pitti> /usr/lib/gcc/x86_64-linux-gnu/5/lto1 and /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus are both unstripped
<pitti> doko: want a bug report for that?
<doko> pitti, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783876
<ubottu> Debian bug 783876 in gcc-5 "gcc-5: consider stripping lto1 / cc1 / cc1plus" [Wishlist,Open]
<pitti> infinity: ^ FYI
<pitti> doko: ah, thanks; seems quite a regression from -4.9
<doko> no, intended
<doko> at least for now
<pitti> hm, I don't get the talk about plugins etc. not working; we've never had these unstripped so far, are "plugins" a new feature of gcc-5?
<pitti> anyway, known, thanks for the pointer
<doko> plugins are not the reason, but the backtraces
<Laney> need to at least get libxml2 ready to migrate, and I think boost1.58 too
<doko> Laney, pitti: update at http://paste.ubuntu.com/12061747/
<doko> boost1.58 and icu already are
<Laney> (for unity)
<Laney> how did that go in without the transition?
<doko> we forced icu; new soname. and then boost1.58 migrated on its own, as expected
<pitti> doko: LGTM now, thanks!
<Laney> because boost1.55 still exists, I see
<Laney> I can't drill this list down to the qt package which is causing the problem
 * Laney needs food, bbiab
<AkrogAmes> Hi all
<AkrogAmes> I search to create and use virtual GPIO for my simulation program
<AkrogAmes> What is the best way for create virtual gpio device ?  Have you another ideas for that ?
<doko> pitti, Laney: could one of you merge debhelper again?
<pitti> sure
<hallyn> infinity: will push http://paste.ubuntu.com/12061910/ for libvirt in a bit
<pitti>  debhelper depends on dpkg-dev (>= 1.18.2~); however:
<pitti>   Version of dpkg-dev on system is 1.18.1ubuntu1.
<pitti> doko: ^ hm, I prepared the merge, but seems we need dpkg first?
<pitti> the diff looks simple enough, but I'd at least wait for infinity's "no, I'm doing it" or "it's fine, go ahead"
<doko>   * Move the implicit build-essential:native Build-Depends from
<doko>     dpkg-checkbuilddeps to a new vendor hook, as it is Debian-specific.
<doko>  
<doko> pitti, infinity: does this need extra attention?
<pitti> Laney: just to confirm, are you tracking https://launchpadlibrarian.net/214278525/buildlog_ubuntu-wily-amd64.postbooks-updater_2.2.5-9build1_BUILDING.txt.gz and friends?
<pitti> doko: ah sorry, I meant diff == "the ubuntu delta", not the substantial diff of dpkg 1.18.1 -> .2
<pitti> doko: can't say, I'm afraid; cjwatson/infinity would know better
<infinity> pitti: I'm doing dpkg today.
<pitti> infinity: ah, great; I'll test/upload debhelper tmw morning then
<infinity> doko: It needs attention, sort of.  We can ignore it (the dep was "new" a year ago or so anyway), or we can follow suit for Ubuntu.  Haven't decided yet which is less pain.
<kirkland> infinity: you don't have a time machine and yet you always tell Dustin he's wrong
<infinity> kirkland: But if I had a time machine, I could do it *more*, and at more appropriate times.
<infinity> kirkland: Like, at birth.
<infinity> kirkland: And every day after.
<infinity> kirkland: This conversation might be a massive CoC violation.
<Laney> pitti: yeah
<ogra_> infinity, did you see bug 1484101 ?
<ubottu> bug 1484101 in livecd-rootfs (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,Confirmed] https://launchpad.net/bugs/1484101
<ogra_> export LC_ALL=C in live-build/auto/build doesnt sound so clever
<ogra_> (if we actually want C.UTF-8)
<Laney> pitti: could you please score up https://launchpad.net/ubuntu/+source/vtk/5.8.0-17.5ubuntu4/+build/7790378 so that I can do some retries?
<pitti> Laney: nudged
<Laney> cheers!
<pitti> Laney: that's generally a good idea (building dependencies first) to speed up arm64, so please keep pinging
<infinity> ogra_: We've done that forever, it's an installer bug if we don't fix console-setup's setup.
<infinity> ogra_: That said, I had planned to go all-UTF-8 this cycle if I find the time.
<ogra_> well, one for cyphermox then :)
<infinity> ogra_: Also, I note that bug mentions that touch uses en_US.UTF-8 as a default.  Why?
<ogra_> touch ?
<infinity> ./live-build/ubuntu-touch/includes.chroot/etc/default/locale:LANG="en_US.UTF-8"
<infinity> ./live-build/ubuntu-touch/hooks/48-setup-env.chroot:LANG=en_US.UTF-8
<ogra_> infinity, oh, thats legacy crap that someone from the phone team needs to clean up
<ogra_> neither of it should be needed ... that stems from the weird OEM builds the phone image originates from
<tjaalton> what updates resolv.conf?
<cyphermox> infinity: what's broken in console-setup?
<tjaalton> it's getting rewritten here, with an empty one
<ogra_> cyphermox, bug 1484101
<ubottu> bug 1484101 in livecd-rootfs (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,Confirmed] https://launchpad.net/bugs/1484101
<ogra_> cyphermox, alkisg just reported it
<pitti> tjaalton: resolvconf updates /run/resolvconf/resolv.conf and /etc/resolv.conf sohudl be a symlink to that
<pitti> tjaalton: and resolvconf is called from /etc/dhcp/dhclient-enter-hooks.d/resolvconf
<pitti> tjaalton: and from /etc/network/if-up.d/000resolvconf too (for ifupdown)
<tjaalton> pitti: yeah, ifup br0 is sets it up fine, then a few minutes later it's rewritten
<pitti> tjaalton: by openvpn possibly?
<cyphermox> infinity: ah, I see
<Laney> pitti: maybe https://launchpad.net/ubuntu/+source/postbooks/4.7.0-3build1/+build/7790500 too then
<Laney> thanks
<tjaalton> pitti: when I use it yes, but not on this machine
<pitti> Laney: got it a 1st class build ticket too :)
<cyphermox> where do we default to C though? the installer should mostly get you things right unless you go out of your way to pick or preseed C
<cyphermox> (IIRC)
<tjaalton> pitti: anyway, I'll keep poking at it, must be something transient
<infinity> cyphermox: We default to C when building the rootfs, and the installer doesn't fix console-setup's setup to match the locale being installed for.
<ogra_> cyphermox, well, the build defaults to C ... but the installer should reconfigure
<cyphermox> ok
<cyphermox> maybe I can find the time to fix for ubuntu and debian next week :)
<infinity> cyphermox: So, two bugs there (maybe three).  1) livecd-rootfs should probably have a saner default for people building raw rootfses that don't use installers (like snappy), 2) real installers (d-i, ubiquity, etc) should dpkg-reconfigure console-setup (or similar) under the right locale to get the right setup, and (maybe) 3) console-setup's postinst might be dumb.
<cyphermox> yeah, a bit of 2 and 3
<cyphermox> 1 is up to you :)
<infinity> cyphermox: Yeah, (1) will be part of my blanket s/C/C.UTF-8/ across the world of buildds, d-i, base system, etc.
<cyphermox> ok
<cyphermox> fwiw I just installed a trusty ppc64el vm with the mini iso and I got UTF-8 ;)
<cyphermox> that was explicitly without a rootfs though
<ogra_> well, thats plain d-i
<cyphermox> right
<ogra_> not using the rootfs from livecd-rootfs
<cyphermox> now for servers and desktop we mostly copy a rootfs
<cyphermox> correct
<ogra_> and d-i most likely sets C.UTF-8 which makes console-setup DTRT from the start
<alkisg> cyphermox: trusty didn't have this issue because the older console-setup version didn't care about LANG
<alkisg> Now I think it's trying to be more clever, and ends up to ISO-8859-15 because livecd-rootfs sets LANG=C
<ogra_> not clever enough ;)
<cyphermox> alkisg: I'm pretty sure a straight d-i install with mini.iso would do the same on later releases too
<cyphermox> hell, let me try the fix right now :)
<ogra_> heh
<alkisg> cyphermox: the .iso contents of all releases after 14.04 that I saw, had ISO-8859-15 in filesystem.squashfs
<ogra_> thats finne
<alkisg> I don't know if mini.iso has console-setup preinstalled
<ogra_> what isnt fine is that the installer doesnt recobfigure it
<alkisg> ogra_: it's not fine, we can't use the VTs in the live CDs
<ogra_> and mini.iso installs package per package ...
<cyphermox> alkisg: it doesn't ship a squashfs at all; so things get installed separately
<ogra_> and likely hardcodes C.UTF-8
<cyphermox> ogra_: nah, you get to pick which you want
<ogra_> alkisg, you use the raw rootfs without installation ?
<alkisg> cyphermox: then it depends on the LANG setting when `apt-get install console-setup` is executed
 * cyphermox zsyncs latest server image
<ogra_> cyphermox, is plain "C" even in the list ?
<cyphermox> ogra_: yeah, I think it is
<alkisg> ogra_: you mean that casper should reconfigure it on boot? But why should it be broken in the first place?
<cyphermox> somewhere out of the way though
<ogra_> alkisg, the point is that it doesnt matter whats in the rootfs ... the installer *must* reconfigure it properly
<alkisg> E.g. suppose that I want an initramfs shell, why should it be broken there, and fixed later on on boot...
<ogra_> the rootfs part is mostly cosmetic
<ogra_> (we should indeed clean the rootfs side too ... but the bug is in the installer)
<cyphermox> ogra_: well, the bug is in both. console-setup shouldn't necessarily have to go back and reconfigure itself just to be extra sure things are correct
<ogra_> cyphermox, well, it should ... since the installer allows you to select a language it has to
<alkisg> I don't know why anyone wouldn't use UTF-8 in the console
<alkisg> (as the CHARMAP, not as the CODESET)
<ogra_> yeah, the ISO charsets should just be wiped from the face of the earth
<cyphermox> ogra_: it already does some amounts of magic to get you the correct /etc/default/keyboard
<ogra_> yep
<infinity> alkisg: So, we're slowly converging on a world where most people think UTF-8 is basically okay, but you're wrong in assuming it's right for EVERYONE.
<infinity> A proper installer will check the locale the user asked for and reconfigure anything that needs reconfiguring.
<seb128> @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: seb128
<infinity> If that includes a boot menu locale selection leading to reconfiguring early terminals, so be it, though that sounds scary hard to get right.
<alkisg> infinity: setupcon has been broken in ubuntu for about 6 years now
<Laney> Can I tell apt to use some random Packages file that I give it as its brain state?
 * dholbach hugs seb128
<seb128> dholbach, :-)
<alkisg> It's not called at boot, it doesn't apply the fonts unless someone calls it manually
<Laney> I want to write something to come up with the state that britney is trying to mutate the archive to that I can then give to apt in order to get some intelligible output
<alkisg> UTF-8 was hardcoded in console-setup.postinst afaik
<infinity> Laney: You can reconfigure the Etc root.
<alkisg> Sure advanced menus are fine, but I think the basics should be taken cared of first ...
<infinity> alkisg: No one's arguing with you that defaults could and should be better.
<cyphermox> alkisg: did you file bugs for each of these particular issues? that way I (or someone else) can get to them and fix them
<infinity> alkisg: But sometimes bugs lead to these things called "discussions", where we do this thing called "exploring possible solutions".  Don't take it as a personal insult about the validity of your bug, or a prompt for you to keep arguing the point.
<cyphermox> I'm looking into reconfiguring console-setup right now
<alkisg> cyphermox: about setupcon, I think I've filed 2 bugs, 6 and 4 years ago...
<ogra_> cyphermox, only the one i pointed to you
<ogra_> lol
<cyphermox> alkisg: ok, if you tell me which ones those are, I'll look when I have a bit of time
<ogra_> alkisg, none in bugzilla ?
<alkisg> ogra_, in launchpad
<ogra_> (that we used before launchpad :) )
<alkisg> Haha
<ogra_> :)
<alkisg> I think they'll be closed now, EOL etc
<arges> cyphermox: the upload for bug 1481780 looks a little messed up. i see two patches unaccounted for can you confirm and I'll reject
<ubottu> bug 1481780 in ipmitool (Ubuntu Vivid) "ipmitool 1.8.13 needs 2 patches for OpenPower systems" [High,In progress] https://launchpad.net/bugs/1481780
<Laney> infinity: Yeah. Maybe I can just make a sources.list that points to this or something.
<alkisg> cyphermox: here's one: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/133072 comments #20 - #24 are mine
<ubottu> Launchpad bug 133072 in console-setup (Ubuntu) "tty console doen't show characters with accent" [Medium,Fix released]
<alkisg> Someone marked it fix released but it's still broken
<cyphermox> arges: yes, please reject I screwed up
<arges> cyphermox: ack
<pitti> Laney, infinity: FYI: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration
<infinity> pitti: Does some useful group (like ubuntu-archive) have access to wendigo, or are those commands just there in case we need to ask a GSA to drive?
<pitti> rod-ues-proposed-migration:x:2997:pitti,adconrad,vorlon,stgraber,laney
<pitti> infinity: it's the Canonical persons in ~ubuntu-release (by intent, I hope it's reasonably correct)
<infinity> pitti: Mmkay.
<Laney> good old rod
<pitti> infinity: retrying tests requires snakefruit ubuntu-archive access, that's a larger group
<infinity> pitti: ubuntu-archive should be a smaller group, the largeness of it is a bug. :P
<infinity> A bug we should fix.
<pitti> Laney: oh, now I get it
<infinity> ASAFP.
<pitti> it's of course "p"rod
<Laney> :)
<infinity> Because people in that UNIX group have way more power than they should.
<Laney> Don't fix it
<Laney> You'll fix me out of it
<pitti> ubuntu_archive:x:2552:cjwatson,seb128,doko,pitti,adconrad,vorlon,didrocks,stgraber,laney
<infinity> Yeah, actually, it's not as bad as I remember.
<infinity> Though it does suspiciously have that one person who isn't an AA. :)
<infinity> Laney: Should we do formal AA training and make you part of the team some day, so you're not bypassing community governance with your Canonical machine creds?
<Laney> infinity: That'd be nice
<infinity> Laney: Cause you have literally carte blanche in the archive from that UNIX account, which makes me uneasy as a community member.
<pitti> Laney: I retried the vtk rebuilds, but many of them still fail due to uninstallability :/
<pitti> I just moved three more transitions to /finished
<pitti> $ bzr diff -r 278..|grep 'renamed'|wc -l47
<pitti> 47 transitions done, not bad for a day!
<pitti> and with that, good night everyone!
<Laney> infinity: Let's do it when we're free
<Laney> Shame no Debconf eh
<Laney> see you pitti!
<infinity> Laney: Yeah, conflicted with Plumbers.  Someone didn't plan that out well.
<infinity> pitti: 'Night!
<Laney> man
<Laney> writing that script was a good use of time
<slangasek> pitti: are you beige on http://pad.ubuntu.com/gcc-5-transition ?
<slangasek> pitti: someone wrote that asterisk blocks the jack transition; there is no jack transition
<Laney> So looks like strigi qtdeclarative-opensource-src kde-runtime would be good to get passing excuses
<Laney> that's from analysing a few packages broken by trying to migrate the big libsigc++-2.0 block
<Laney> (which contains unity)
<slangasek> Laney: I hadn't triggered rebuilds for strigi because the list of library dependencies was long and hairy, and also because I started to second-guess myself because KDE
<slangasek> I'd love to have confirmation that this is actually an ABI change for strigi and we should push ahead
<Laney> Ah, I didn't look if they were themselves transitions
<Laney> but: https://packages.qa.debian.org/s/strigi/news/20150808T100114Z.html looks good
<slangasek> pitti: I see you did rebuilds for voms (libvomsapi1) but you seem to have missed lcmaps-plugins-voms, not sure if you're using a script that you're debugging
<slangasek> Laney: check
<slangasek> triggering rebuilds now for strigi
<infinity> slangasek: How closely do you watch build times on some of your uploads?
<infinity> slangasek: Curious if you've noticed things that appear to be mutex-heavy being crazy slow on arm64?
<slangasek> infinity: not very, why?
<Laney> I'll make my dear-update-output-what-are-you-really-telling-me script usable by others tomorrow
<slangasek> infinity: I've noticed arm64 being the long pole, that's all
 * infinity is trying to decide if tbb is a flaming heap or if there's a nasty toolchain/glibc/kernel bug at play here.
<slangasek> infinity: ah.  I haven't in general noticed arm64 being orders of magnitude slower than others if that's what you mean, just delayed
<infinity> slangasek: Sure, arm64 lags just for resource reasons.  Slower CPU than PPC, fewer builders than everyone else, very slow I/O.
<infinity> slangasek: But, yeah, check tbb, the build times are insanely bad on arm64.  And it's all in those mutex tests.
<infinity> It almost made me go hunting for glibc bugs at 5am, but I figured I'd wasted enough of my life on two packages.
<slangasek> infinity: robru had noted yesterday that the previous successful build on arm64 (before the buildd timeout) was also long, ~4x the other archs IIRC
<slangasek> there may be an underlying bug, but tbb is the only thing I've heard affected
<infinity> slangasek: Yeah.  Tres weird.  Maybe I'll revive my carefactor later and throw a debugger or profiler at it.  For now, I'll chalk it up to tbb being crap.
<infinity> slangasek: At least it's fixed on PPC. :P
 * infinity goes to find more caffeine to keep his caffeine company.
<slangasek> Laney: kdegraphics-mobipocket ftbfs (strigi)
<seb128> @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:
<ochosi> doko: hi!
<ochosi> doko: just quickly wanted to check whether we pinged the right person last night and whether the libreoffice patch would be generally acceptable
 * hallyn ponders where he might find some caffeine
 * ochosi guesses a cafÃ© might be the place to go to
<doko> ochosi, sorry, please ask SweetShark. seb128 might be able to help as well
<hallyn> none near here.  maybe the snackshop
<ochosi> doko: thanks will do!
<ochosi> doko: sorry if we pinged the wrong person, just saw you're on the LO packaging team ;)
<doko> for historical reasons, yes
<ochosi> okeydokey!
<ochosi> thanks for the heads up
<robru> infinity: oh you got tbb working? can you show me the final diff on that for educational purposes?
<doko> robru, you can see that diff in lp ...
<doko> not showing myself for educational purposes ;-P
<robru> heh
<robru> not awake yet
<seb128> ochosi, Bjoern is on holidays, but ask on #ubuntu-desktop tomorrow on european working on hours (or try now but I'm about to call it a day and I'm unsure who is still around)
<doko> robru, https://launchpad.net/ubuntu/+source/<source package>
<robru> doko: thanks
<infinity> robru: The tbb and openvdb diffs should both be more or less self-explanatory, I hope.
<infinity> robru: Though I note that I didn't mention dropping the crap patch in debian/changelog.  So, do as I say, not as I do in that case. :P
<doko> pitti, http://autopkgtest.ubuntu.com/packages/k/kservice/wily/i386/ is this an installation error?
<robru> infinity: well, it's the sort of thing that makes sense when I read it, but I have no idea how you got there from where I left it off
<infinity> robru: Making sense when you read it is a good first step.  I don't know how you best learn, but for me, it's by watching "smarter" people be smart until I absorb it.
<infinity> robru: When I first decided I wanted to transition from a Debian user to a Debian contributor, I subscribed to debian-bugs-dist (I don't recommend this) and just watched people argue about bugs and iterate on fixes until patterns emerged and I realised most of this isn't really hard, it's just about seeing the same damned bug 700 times in a row.
<ubottu> bug 700 in boa-constructor (Ubuntu) "After installing Boa Constructor, no menu items in Gnome" [Medium,Fix released] https://launchpad.net/bugs/700
<infinity> ubottu: Thanks, that was super helpful.
<ubottu> infinity: I am only a bot, please don't think I'm intelligent :)
<robru> lol
<robru> infinity: that seems a reasonable approach, I'm more of a learn-by-doer, it's best if somebody stands over my shoulder and tells me what to do until I get the hang of it
<infinity> robru: Are you inviting me to come visit and loom over you while you type?
<infinity> robru: You're in Vancouver, right?  I could use a vacation on the coast.
<robru> infinity: I wouldn't say no
<robru> infinity: even better: Victoria!
<infinity> FSVO "better"...
<infinity> I guess you're only a ferry away from a real city.
<robru> infinity: more actual ocean & mountains, less obnoxious big city noise
<infinity> robru: I live for city noise. :)
<robru> infinity: I'll have you know I only live in capital cities. First Edmonton, then Winnipeg, now Victoria. Vancouver never had a chance!
<infinity> Can't sleep without the soothing sounds of dumpsters being emptied at 4am.
<robru> yeah...
<infinity> (I'm not actually joking, I've lived in CBDs so long that life without that background noise is unsettling)
<robru> CBDs?
<mterry> doko, poke about some gccxml/gcc5 issues that I'm looking at, if you have time
<mterry> doko, I will explain here and you can get back to me when you have time
<infinity> robru: Central Business District.  Generally known in most of North America as "downtown", despite that only making sense in Manhattan.
<doko> mterry, this is now replaced by castxml
<mterry> doko, yup, and that's causing some problems for me
<doko> ouch
<robru> ah
<mterry> doko, I'm trying to build activiz.net.  Which calls gccxml, which now calls castxml.  Then uses cableswig to consume the xml.
<mterry> doko, unfortunately, castxml seems to be writing slightly different xml than gccxml (namely, it's leaving off some 'name=' attributes).  cableswig errors out if certain types of elements don't have name= attributes
<mterry> doko, having castxml always write out a name attribute, even if just name="" seems to get activiz.net building...
<mterry> doko, but I'm not sure if that's really the best thing  :)
<mterry> doko, maybe alternative would be making cableswig less strict?  But I don't know if breaking that assumption would mess other things up, or maybe that's actually a valid level of strictness and castxml is in the wrong
<mterry> This is not my area of expertise
<doko> mterry, debian-med packages aren't my expertise either ... can we just demote that to -proposed ?
<mterry> doko, you mean take it out of the release pocket?  So it wouldn't block migrations?
<doko> yes
<mterry> The chain I know about is activiz.net -> gdcm -> insighttoolkit4 -> plastimatch.  Maybe there are other packages.  But *I* don't care about those being in release pocket.  But I'm not familiar with how important they might be
<doko> argh
<mterry> I take it from your argh that those are packages we want to remain in release?
<doko> hmm, no. but all these packages are marked for autoremoval in testing
<doko> and the maintainer apparently at debcamp uploading again new packages instead of fixing his existing ones
<mterry> doko, yeah, looks like a sizeable bubble of packages, but all in that debian-med universe.  Seemingly not terrible to demote.  so what's the process for demoting?
<mterry> doko, alternatively, I could land a patch to castxml that inserts empty name attributes instead of leaving them off...
<mterry> Seems hacky though
<doko> mterry, file a bug, add tasks for all involved packages, make sure there are no other rdeps, and add th block-proposed tag. then wait for an archive admin
<mterry> doko, paperwork!  :)  OK, will chase exact list of rdeps
<doko> the bug needs to be there, or else the package will migrate again
<mterry> doko, yeah makes sense
<mterry> doko, subscribing archive team is enough to get their notice in this case?
<mterry> doko, also...  is there a fancy way to get all recursive rdeps, besides using reverse-depends a bunch?
 * mterry writes a tiny script
<doko> mterry, everse-depends src:activiz.net and everse-depends -b src:activiz.net
<mterry> yeah, but then I have to recurse
<doko> ahh
<doko> no, don't know one
<mterry> (also, it would be nice to not have to run twice, to say -b and -normal)
<slangasek> who's copying packages from wily to wily-proposed? pitti?
<slangasek> (crystalspace)
<slangasek> pitti: would you please leave the FTBFS package in wily-proposed and delete the package from wily instead?
<slangasek> the current approach leaves the packages in -proposed on the tracker, and makes it harder to script an upload (since 'build1' is already taken)
<doko> slangasek, hmm, I assume the same would hapen when use demote-to-proposed?
<slangasek> oh, there's a script for that?  maybe that's the problem yes
<slangasek> but if the package is already *in* proposed, we should remove-package -s wily, not remove-package -s wily-proposed + demote-to-proposed
<infinity> slangasek, doko: demote-to-proposed does no version checking, it just copies from release to proposed, and deletes from release.  There's no conscious "deleting from proposed" going on here, just copying over it.
<infinity> slangasek, doko: Arguably a bug in the script that it doesn't at least warn and prompt when you're about to downgrade (patches welcome), but currently the onus is on the user to know what they're doing.
<slangasek> ok
<slangasek> I would say that demote-to-proposed is not the right tool in this circumstance then
<infinity> No, if there's a higher version in proposed already, the correct tool is remove-package.
<infinity> demotion only makes sense if the release version is broken and there's no proposed version.
<infinity> One could turn demote-to-proposed into the catch-all tool for this by adding a version check with a "would you like to just delete the release version, then?" prompt.
<mterry> doko, ok filed bug 1484258.  Think it's right
<ubottu> bug 1484258 in vtk-dicom (Ubuntu) "Demote activiz.net and friends to proposed (from release)" [Undecided,New] https://launchpad.net/bugs/1484258
<mterry> infinity, ^ is that right process?  new to demoting/removing-from-release
<infinity> mterry: Do any of those exist in -proposed at higher versions?
<slangasek> tyhicks: I'm looking to merge new audit, and I see that you have a delta to drop the build-dep on libwrap.  Is that really needed, given that libwrap is in main?
<slangasek> tyhicks: (seems to be a no-op change, so I'd rather reduce the delta)
<tyhicks> slangasek: we build our audit differently due to not wanting auditd to have networking capabilities
<tyhicks> slangasek: it has been long enough since I brough audit into main that I've forgotten if libwrap was part of that
 * tyhicks takes a quick look
<slangasek> tyhicks: ok.  I checked and libwrap is in main, so it's just an inert build-dep
<tyhicks> slangasek: ok, then you can add the --with-libwrap and corresponding Build-Depends back in but the --disable-listener delta needs to stay
<infinity> No need for libwrap if you're disabling TCP connections.
<tyhicks> right
<tyhicks> which is why I removed it
<mterry> infinity, yes.  Some have rebuilds, some have imported new versions from debian
<infinity> mterry: Okay, so, as we just discussed up there, for all of those, the correct action isn't "demote to proposed", but rather just "delete from the release pocket".
<infinity> mterry: Enumerating which is which would be helpful.
<slangasek> tyhicks, infinity: right - no need for it but also no need for a delta.  adding it back, but of course leaving --disable-listener there
<mterry> infinity, ok, I will make two lists
<infinity> mterry: Ta.  I'm running out of steam here, probably going to crash after I verify and release tzdata SRUs, so slangasek will likely be actioning your lists.  He'll appreciate them not being wrong. ;)
<slangasek> haha
<mterry> infinity, unlike you?  :)
<infinity> mterry: I'm endlessly tolerant, everyone knows that.
 * infinity wonders if he just ruined any keyboards.
<mterry> :)
<mterry> slangasek, infinity: posted lists to bug 1484258.  (no rush)  Thanks!
<ubottu> bug 1484258 in vtk-dicom (Ubuntu) "Demote activiz.net and friends to proposed (from release)" [Undecided,New] https://launchpad.net/bugs/1484258
<slangasek> mterry: you appear to have missed invesalius as a reverse-dep (but not reverse-build-dep) of gdcm; can you check if there's more hiding there?
<slangasek> mterry: nope nevermind I see it in the "demoted" list sorry
<slangasek> mterry: all packages demoted; I'm leaving it to you to close out the bug tasks...
<doko> slangasek, will the packages stay in proposed with closed bugs?
<slangasek> doko: yes, half of them have no binaries and the other half depend on binaries that don't exist
<mterry> slangasek, thanks!  will close
<mwhudson> did we get a new gccgo with the gcc 5 transition?
<doko> no, already was at 5
<mwhudson> hm
<doko> mwhudson, what's the problem?
<mwhudson> doko: docker.io failed to build on ppc64el
<mwhudson> in my ppa with go 1.5, but docker still built with gccgo this time
<mwhudson> doko: https://launchpadlibrarian.net/214275071/buildlog_ubuntu-wily-ppc64el.docker.io_1.6.2~dfsg1-1ubuntu3_BUILDING.txt.gz
<doko> mwhudson, can you retry with -O2?
<mwhudson> doko: i don't think that's the problem
<mwhudson> maybe some dep got updated, i haven't really looked at this at all yet
<doko> don't see any recent checkins for this
<mwhudson> yeah, it's pretty odd
 * mwhudson is wdiffing the build environments
<mwhudson> cooooooooouuuuuuuuuuld be some cgo change maybe?
<mwhudson> oh god
<mwhudson> it's the type of syscall.RawSockaddr.Data or something like that
<mwhudson> i think this did get changed on ppc64el
<mwhudson> doko: it's this https://go.googlesource.com/gofrontend/+/a850225433a66a58613c22185c3b09626f5545eb%5E%21/
<sarnold> http://codesearch.debian.net/results/ifrDataByte/page_0
<mwhudson> doko: so it's terrible but not our fault i guess
 * mwhudson thinks
<mwhudson> no real idea how to fix this :(
<mwhudson> i can at least complain at people
<doko> mwhudson, please open a bug report for golang *and* gcc upstream
<mwhudson> doko: as in bugzilla?
<mwhudson> sure
<doko> yes
<doko> and mark it as a regression, if it worked before (or subscribe me)
<mwhudson> doko: step 1 https://github.com/golang/go/issues/12124
<mwhudson> doko: how do i mark it as a regression?
<doko> prefix with [5/6 Regression]
<mwhudson> doko: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198
<ubottu> gcc.gnu.org bug 67198 in go "[5/6 Regression] change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs" [Normal,Unconfirmed]
<doko> ta
#ubuntu-devel 2015-08-13
<pitti> Good morning
<pitti> slangasek: yes, I'm beige; "jack" was already there (wondered about that myself), I just appended another transition; thanks for cleaning up
<pitti> slangasek: I'm using the ben pages, and it indeed has lcmaps-plugins-voms; not sure how it got dropped, probably just mouse copy&paste error
<pitti> doko: http://autopkgtest.ubuntu.com/packages/k/kservice/wily/i386/ WDYM install error? KSycocaThreadTest fails
<pitti> slangasek: crystalspace> ack, can do; that's what I did with bombono-dvd, that works better I guess
<pitti> Laney: ^ FYI, as you also did some
<pitti> slangasek: yes, I removed the broken rebuild from wily-proposed and used demote-to-proposed, but then realized that this doesn't work well as it goes back to -release immediately
<pitti> so just removing from wily sounds easier and better
<slangasek> pitti: ah yes, demotion with binaries also has that problem :)
 * pitti marks petsc++ as finished, feel++  is in -proposed
<pitti> oh, where did sflphone go on the pad?
<pitti> ah, slangasek demoted to -proposed; anyway, I have a fix now
<slangasek> pitti: no objection to it being fixed of course, but it didn't look to me like something that should be allowed to continue blocking
<pitti> slangasek: fully agreed, I just wondered for a second where the pad entry had gone
<pitti> (it was rightfully removed -- just a bit of confusion there)
<pitti> slangasek: "unbuilt/uninstallable" is holding up too much stuff, I'm dialing this back in britney now
<pitti> as per u-r@ discussion
<ricotz> good morning
<ricotz> pitti, hi, small fix regarding the icu transition http://paste.debian.net/plain/291826
<pitti> ricotz: ah thanks; could this just be committed to http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qt4-x11.git ?
<pitti> an entire upload for (an essentially useless) Suggests: seems a bit exaggerated
<ricotz> pitti, I see, and yeah should be fixed there too
<ricotz> mitya57, hi, could you take a look at this ^
<pitti> slangasek: sorry, uploaded duplicate rebuild of bisonc++ and ccbuild
<slangasek> pitti: if that's a duplicate of something I did, don't worry, I'd rather have you be TIL than me ;)
<pitti> slangasek: yes, you uploaded http://people.canonical.com/~ubuntu-archive/transitions/html/html/bobcat-g++5.html recently and I missed that
<slangasek> pitti: "recently" as in within the past half hour, I think
<pitti> I ^Ced my transition uploads after I realized the unexpected build2
<pitti> slangasek: right; not much harm, just in case you wonder
<slangasek> I'm mostly just spamming the 'mass-rebuild' button here
<pitti> I earn the FTBFSes then :)
<pitti> yeah, me too; was going over the remaining ones
<slangasek> which at least turns up FTBFSes somewhere that people can see them without having to hunt - e.g. I think most of the bobcat revdeps FTBFS, judging by my inbox
<slangasek> oh perhaps it's not as bad as all that
<slangasek> guncat
<slangasek> with pthreads fail
<didrocks> stupid question but git-buildpackage in wily doesn't have the buildpackage command anymore? (it only has the bash completion) and it seems no other package has it, known?
<pitti> didrocks: sure, "gbp buildpackage"
<pitti> didrocks: the old aliases were removed in wily indeed
<pitti> didrocks: it's now "gbp <verb>", no gbp-verb or git-verb any more
<didrocks> pitti: ok, didn't know the other alias was deprecated, thanks!
<dholbach> good morning
<mitya57> ricotz: Will commit later today, thanksa
<mitya57> The last 'a' should have been '!'
<ricotz> mitya57, thanks
<infinity> Sarvatt: Was your verification of LP: #1471213 on vivid or trusty+lts-vivid?
<ubottu> Launchpad bug 1471213 in mesa (Ubuntu Vivid) "[SKL] noise in unity dash, torcs" [Undecided,Fix committed] https://launchpad.net/bugs/1471213
<mitya57> ricotz, here you go: http://anonscm.debian.org/cgit/pkg-kde/qt/qt4-x11.git/commit/
<seb128> @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: seb128
<infinity> seb128: Hey, since you're being community-oriented today, can you chase up the verification-failed on the SRU you uploaded for LP: #1440157 ?
<ubottu> Launchpad bug 1440157 in One Hundred Papercuts "WARNING **: Could not connect to geoname lookup server: Operation was cancelled" [Low,Confirmed] https://launchpad.net/bugs/1440157
<infinity> seb128: Probably user error, but would be nice to confirm.
<seb128> infinity, shrug, it was verification-done, can't we just ignore that user? ;-)
<infinity> seb128: Possibly.
<seb128> infinity, I've asked for some details
<ttx> wgrant, cjwatson: Hi! Any idea why launchpadlib 1.10.3 was not uploaded to https://pypi.python.org/pypi/launchpadlib ? Just an oversight ?
<wgrant> ttx: The only significant change was some pretty broken Python 3 support. We'll be releasing 1.10.4 soonish.
<wgrant> I can't recommend using the Python 3 support in 1.10.3
<ttx> wgrant: ah ok, makes sense.
<ttx> wgrant: I'll wait for that before turning my py3 test jobs on
<Odd_Bloke> If the bzr packaging branches for a package haven't been updated after an upload, what can I do to refresh them?
<wgrant> Odd_Bloke: Which package?
<Odd_Bloke> wgrant: cloud-init
<wgrant> Hah
<Odd_Bloke> (vivid, trusty, precise)
<Odd_Bloke> Well, and maybe wily, but I'm doing backports so I don't care. :p
<wgrant> Odd_Bloke: Any particular reason you're still using UDD?
<wgrant> It basically only works for a given package once.
<wgrant> We strongly discourage its continued use. It is barely on life support.
<wgrant> We intend to replace it with something git-based in the relatively near term.
<Odd_Bloke> wgrant: I really want version control so backporting multiple fixes is less painful.
<Odd_Bloke> (Of the "dget ...; OH GOD ITS ALL GONE" variety)
<wgrant> Odd_Bloke: You're probably better off maintaining your own branches in that case. The Bazaar implementation of UDD has some pretty fundamental flaws that prevent it from being reliably usable.
<wgrant> Lessons that will be learnt from in any future replacement.
<Odd_Bloke> OK, cool.
<Odd_Bloke> My sponsor normally takes debdiffs anyway, so we probably aren't using it fully. :p
<wgrant> Yeah
<wgrant> cloud-init in particular has been broken since 2013.
<wgrant> It's not unfixable, but it will unfix itself pretty quickly if I fix it.
<seb128> bdmurray, seems like you maintain ubuntu-release-upgrader, could you update it to work the new pep8 in wily? it fails some tests because the new version is stricter, which is blocking webkitgtk or pyqt5 in wily-proposed
<Odd_Bloke> Well, I'm more than happy to use my own git branches to track stuff. :)
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/u/ubuntu-release-upgrader/20150813_000449@/log.gz
<doko> wait, arm64 buildds almost idle? did we finish?
<pitti> doko: heh, not quite yet :) http://people.canonical.com/~ubuntu-archive/transitions/
<pitti> doko: I just had to stop pegging them for some hours do catch up with some other stuff
<pitti> and we are getting into the "fewer rebuilds, more manual fixing work" zone
 * Laney is fixing some K things to shrink the pending stuff that's blocking unity
<doko> pitti, new dpkg arrived, could merge debhelper now?
<pitti> doko: yes, currently looking at the dpkg test regressions
<pitti> doko: running some package builds with new debhelper now, then I'll upload
<pitti> doko: uploaded
<Laney> ICE ICE baby
<pitti> Laney: you booked a German hi-speed train? :-)
<Laney> think of a worse kind of ICE :P
<Laney> although I will be getting one of those soon!
<pitti> Laney: they have enough of Internal Climate_control Errors, trust me :)
<pitti> although I've been lucky this summer apparently
<davmor2> https://www.youtube.com/watch?v=rog8ou-ZepE
<pitti> davmor2: oh the sound of our youth :)
<pitti> I think this came out when I was 10
<davmor2> pitti: that's not the sound of my youth this is the sound of my youth https://www.youtube.com/watch?v=TLV4_xaYynY
<mdeslaur> seb128, doko: I've looked at bug 1448548 , the openjdk rules file is broken
<ubottu> bug 1448548 in openjdk-8 (Ubuntu) "OpenJDK 7/8 don't generate .desktop needed by nautilus" [High,Confirmed] https://launchpad.net/bugs/1448548
<mdeslaur> or, maybe I'm reading that wrong
 * mdeslaur looks again
<seb128> mdeslaur, hey, well, I don't understand the intend
<seb128> so I can't tell if it's right
<seb128> there is a limited list of ubuntu series for some reasons
<seb128> which are all unsupported ones
<mdeslaur> yeah, I read it backwards, it's _not_ enabling cautious-launcher for those old releases which didn't have it
<mdeslaur> the issue is ifeq ($(java_launcher),cautious-launcher)
<mdeslaur> it's not equal as it's missing the parameters
<mdeslaur> or maybe not....perhaps I should actually drink my morning coffee before saying a bunch of stupid things
<seb128> lol
<doko> Laney, do you look at the remaining kde autopkg test failures? might want to coordinate with Riddell
<Laney> doko: mmm, hi Riddell!
<doko> mdeslaur, ifneq (,$(findstring cautious-launcher, $(java_launcher)))
<doko> fixed it
<mdeslaur> doko: yeah, I was just compiling with exactly that change to test
<mdeslaur> doko: can you push that to your trees for the next security update?
<doko> mdeslaur, yes
<mdeslaur> doko: cool, thanks
<dragos> hi
<dragos_> hi
<dragos_> how r u
<dragos> good
<dragos_> 2 xchat on  pc running at the same time
<dragos> cool
<dragos_> ya ik
<dragos_> dragos and dragos_ is the same user
<dragos_> dragos_
<dragos_> dragos
<dragos_> dragos
<dragos_> dragos
<dragos_> dragos
<dragos_> soory
<Laney> dude
<pitti> barry: are you tracking the "Illegal instruction (core dumped)
<pitti> barry: in http://autopkgtest.ubuntu.com/packages/p/pytables/wily/amd64/ ?
<barry> pitti: thanks for the pointer; hadn't seen that yet
<seb128> cyphermox, hey, why did you subscribe sponsors to https://code.launchpad.net/~mathieu-tl/ubuntu/wily/grub2/lp1097570/+merge/260228 ? you can upload grub yourself right?
<cyphermox> seb128: I'm not sure why it got in the list, I think it's just because I filed the merge at all
<seb128> cyphermox, are you waiting for specific reviewers?
<cyphermox> no, not really. let me get that off the list
<seb128> thanks
<seb128> @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> Mirv, remember the libllvm v5 changes when you backport new llvm versions. for 3.5 and 3.6 you have to drop these changes, for 3.7 you have to *add* something else, e.g. v4. and change the wily version to replace/conflict these
<Mirv> doko: do you mean tjaalton?
<Mirv> too many Timo:s
<doko> yeah, sorry
<doko> tjaalton, ^^^
<tjaalton> doko: whaat?
<tjaalton> maybe mlankhorst did the previous ones, i can't remember doing those :)
<tjaalton> doko: 3.7 will be useful for newer mesa and amdgpu driver though
<tjaalton> you mean backports to trusty?
<doko> tjaalton, yes, you must not use the same library name as used in wily-proposed
<pitti> doko: does that then mean that we need to add another Conflicts:/Replaces: to the wily version?
<tjaalton> doko: mesa in proposed?
<tjaalton> i'm just confused :)
<doko> pitti, for libllvm3.7? maybe
<tjaalton> doko: so is there something I need to do right now?
<doko> tjaalton, no, just remember when you backport. I'll add the Conflicts/Replaces for libllvm3.7 (libllvm3.7v4), so you should use exactly that name for your backports
<tjaalton> doko: ah, ok
<pitti> apw: ah, kicad is running into the same boost error; so waiting on your fix
<apw> pitti, yeah waiting on some test builds in my boost PPA, seems feel is very large
<mdeslaur> cjwatson: I am going to steal your net-snmp merge
<mterry> doko, arg, you were working on pinba-engine-mysql at the same time I was.  put your name on it  :)
<mterry> doko, but awesome, good work  :)
<doko> mterry, sorry, and now looking at qwt
<doko> this pad is always timing out ...
<mterry> doko, I know, right
<barry> pitti: i can't get pytables to core dump locally :/  all dep-8 tests pass just fine here
<doko> seb128, was it intended to build gnome-bluetooth without the new bluez?
<seb128> doko, you mean? bluez was uploaded
<seb128> doko, or you mean build order? in which case yes, gnome-bluetooth doesn't build-depends on bluez, it uses its dbus api, so it's runtime depends
<doko> ok
<doko> zyga, still there?
<zyga> doko: yes
<zyga> doko: want to know about the plainbox FTBFS issue?
<doko> zyga, not to know, just a fix =)
<zyga> doko: a quick fix is to disable tess, I tracked that down to about a dozen silent test failures on earlier pythons, I started fixing them but I'll need one more day
<doko> ok, then I'll leave that
<mterry> doko, I'm looking at kdegraphics-mobipocket, which is now missing one of its symbols and dpkg-gensymbols errors out during build.  I see for okular, you just uploaded a new version with a symbols file that had the #MISSING lines in it.  How do I test whether any rdeps were using the specific symbol that is missing in my kdegraphics case before uploading it with an updated symbols file?
 * doko hides (already uploaded)
<doko> mterry, these are destructor symbols, which GCC 5 doesn't emit anymore. In general, you can ignore these (that's what the kde symbols tool is doing).
<mterry> doko, OK great.  Will upload with modified symbols file then
<doko> mterry, I already did :-/
<mterry> doko, oh I see, that's why you hid  ;)
<mterry> doko, thanks  :)
<mterry> doko, you monster
 * mterry goes on lunch break, after successfully fixing two gcc5 failures  ;)
<Laney> Riddell: ScottK: Do you know if opengtl & libqtgtl are still relevant?
<Laney> FTBFS, seem to have been removed from fedora saying they are obsolete
<Riddell> hmm, krita isn't it?  let me look
<Laney> don't see any rdeps
<Laney> if you confirm then would you please remove them from wily+wily-proposed? :)
<Riddell> Laney: you could be right, asking upstream
<doko> Laney, Riddell: https://bugs.launchpad.net/ubuntu/+source/opengtl/+bug/1483000
<ubottu> Launchpad bug 1483000 in opengtl (Ubuntu) "please remove opengtl and libqtgtl from 14.10" [Undecided,New]
<Laney> thx
<Laney> we're so four days behind
<Riddell> doko: that should say 15.10?
<doko> yeah
<seb128> kirkland, hey, is there any chance you could review https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940?  there is a patch waiting for review since january 1st...
<ubottu> Launchpad bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New]
<kirkland> seb128: sure, looking now...
<kirkland> seb128: ugh, backslashes in user names?
<seb128> kirkland, thanks
<seb128> that's how AD works apparently
<seb128> don't ask me, I know little about that ;-)
<kirkland> seb128: hmm, I'd be curious to have pitti's and slangasek's take on the pam parts of this patch
<seb128> slangasek, pitti, ^ (https://launchpadlibrarian.net/193837670/45_44.diff)
<kirkland> pitti: slangasek: there's a patch posted on Launchpad for ecryptfs, on this bug: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940?
<ubottu> Launchpad bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New]
<kirkland> pitti: slangasek: which adds support to ecryptfs, to allow for backslashes and dollar signs in user names
<kirkland> pitti: slangasek: for active directory and samba support
<kirkland> pitti: slangasek: that sounds scary to me
<kirkland> seb128: okay, marked triaged/low, asked for comments from slangasek, pitti, and tyhicks
<kirkland> seb128: my initial inclination is pretty hesitant
<kirkland> seb128: I also have no environment (active directory) where I could test this
 * jdstrand notes tyler is on holiday until tuesday
<kirkland> jdstrand: thanks
<seb128> kirkland, ok, thanks, at least the submitter has some activity (we should maybe also unsubscribe sponsors if that's too technical for ubuntu sponsoring and should be let to the ecryptfs team or something
<kirkland> seb128: ack
<kirkland> seb128: yes, agreed, that's not something that a general ubuntu sponsor should upload, as there are potentially serious security implications
<barry> slangasek: i'm confused.  http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4-5.html has gcc-python-plugin failing for all archs, but if you look at the build logs, everything is built just fine.  it's not the page being out of date, so what's going on?
<barry> ditto python-aoihttp
<Laney> barry: Do they match the 'bad' line?
<barry> Laney: hmm.  i think it doesn't bug i'm not positive i'm reading the bad line correctly
<Laney> laney@nightingale> apt-cache show python3-aiohttp | grep Depends                                                                                                                                ~/temp
<Laney> Depends: python3 (<< 3.5), python3 (>= 3.4~), python3-chardet, libc6 (>= 2.4)
<Laney> seems to match bad
<barry> Laney: hmm, i guess so.  okay, thanks, probably a no-change rebuild would fix that
<Laney> that's usually what the transition tracker is telling you to do
<Laney> in the best case, anyway. :P
<barry> ;)
<barry> Laney: thanks
<slangasek> barry: wasn't python-aiohttp on the list of ftbfs packages?
<barry> slangasek: i think i was just misinterpreting the page.  i'll investigate
<slangasek> barry: confirmed; python-aiohttp was ftbfs in your ppa
<barry> yep
<slangasek> kirkland, seb128: backslashes and dollarsigns are certainly valid in usernames... but why is that bundled with a new pam config?  that doesn't look to me like something we should add to the package, there are already separate modules for dynamically creating home directories and his auto-enable-ecryptfs script encodes a lot of policy
<kirkland> slangasek: thanks, agreed;  can you add a comment to that effect to the bug?
<slangasek> yes
<slangasek> kirkland: also they have a setup script that's passing the user's password on the commandline...
<jdstrand> pitti: hey, I'm trying to run unmodified click-apparmor autopkgtests in a wily chroot using only packages from the archive (on a vivid host)
<jdstrand> pitti: and I am seeing this: http://paste.ubuntu.com/12072798/
<jdstrand> pitti: the autopkgtest is creating a click file and trying to install it, but that is failing with a sandbox failure
<jdstrand> pitti: have you seen that before? if not, how would I go about resolving this?
<jdstrand> jibel: ^
<jdstrand> pitti, jibel: ginore me for the moment-- this might be a symptom of a bad chroot
<jdstrand> hmm, no
 * jdstrand scratches head
<doko> Laney, slangasek: why is http://people.canonical.com/~ubuntu-archive/transitions/html/proj.html  zygrib still shown there, when it's not in the release pocket?
<slangasek> doko: because the tracker doesn't care about -proposed vs. release, it cares about "newest binary".
<doko> ahh, ok
<slangasek> doko: this does tie into the discussion from last night, that if we're removing a package from wily we should leave it source-only in wily-proposed instead of leaving stale binaries there; I'll delete these now since they date back to an earlier transition failure
<jdstrand> pitti, jibel: yes, at a loss. I'm still poking, but I could use some help with: Sandbox failure: 'click install' not permitted to write-open '/dev/pts/25'
<slangasek> doko: removed the old package; this at least takes zygrib off the "urgent fixme" list in favor of the "we need to clean up -proposed" list
<doko> apw, are you still looking at kicad?
<apw> doko, i am looking at feel, which nearly built before the netowkr outage bust the builds ... pitti tells me kicad has the same issue, if so i'll confirm that in my boost ppa
<doko> ta
 * doko welcomes slangasek to the club of empty library package uploaders ;p
<infinity> doko: But, was it libgcc?
<infinity> doko: Cause I think the only person who could top that would be me shipping a libc6 with no libc.
<slangasek> doko: was it d-shlibs?
<slangasek> cuz d-shlibs
<jdstrand> pitti, jibel: I filed bug #1484661
<ubottu> bug 1484661 in autopkgtest (Ubuntu) "'click install' within an adt-virt-schroot fails with "Sandbox failure: 'click install' not permitted to write-open '/dev/pts/8'"" [Undecided,New] https://launchpad.net/bugs/1484661
<doko> slangasek, just saw mterry's changelog about bobcat
<mterry> it's easy to do  :)
<slangasek> doko, mterry: ah, lovely.  yes, the batch script didn't catch that case I'm afraid
<slangasek> er though it should have
<slangasek> sed -i -e"s/\([ |,=/]\)$oldpkg\([ |,:]\|$\)/\1$newpkg\2/g" debian/rules
<slangasek> must've been an upload from an early revision of the script
<slangasek> oh of course it was because alphabet
<slangasek> sorry :/
<bdmurray> seb128: I sorted out the ubuntu-release-upgrader pep8 issues, thanks
<doko> which -dev package could have dropped dependencies on some multimedia packages such that asterisk ftbfs?
<seb128> bdmurray, thanks!
<doko> barry, https://bugs.launchpad.net/ubuntu/+source/ubuntu-sso-client/+bug/1484680   not sure if others will pick that up
<ubottu> Launchpad bug 1484680 in ubuntu-sso-client (Ubuntu) "ubunu-sso-client autopkg tests fail in wily" [High,Confirmed]
<barry> doko: ack.  looks shallow from first glance
<doko> found the first ICE after changing the default ...
<seb128> could somebody overwrite/retry the buggy bootest that makes the bluez update not considered?
<doko> mterry, there seems to be a new boost.m4 somewhere which fixes this. didn't find the master source yet
<mterry> doko, oh yeah?  thanks for fixing that in another package, I would never have figured that out on my own  :)
<doko> d-shlibs should die
<mterry> doko, I'd never seen it before.  Took me a bit to figure out why I had an empty package
<mterry> doko, reading debdiffs for idle fun?  :)
<doko> mterry, no, it was the -P in the changelog which spotted my interest =)
<mterry> doko, beyond reading the man page for cpp, I wasn't entirely clear why boost suddenly started dying without -P
<mterry> obviously linemarkers bugged it out
<mterry> Just a weird change to happen
<infinity> seb128: It's failing its own autopkgtest as well, that seems more dire?
<seb128> infinity, hum, right, i'm going to look at that tomorrw, thanks for pointing it out ;-)
<mterry> Can I get a NEW for libmems's v5 transition?
 * mterry wants to push button on progressivemauve's rebuild before heading out
<mterry> infinity, ^ ?
<doko> slangasek, does your script fixes this now? http://launchpadlibrarian.net/214411099/libmsn_4.2.1-0ubuntu3_4.2.1-0ubuntu4.diff.gz
<infinity> mterry: Still building on armhf, patience. :P
<mterry> infinity, but I want it now!!!
<mterry> infinity, fair enough, I have to jet though, will have to settle for pushing button in the morning  :)
<infinity> mterry: Packaging looks good though, and so do the built binaries, will accept as soon as it's built.
<slangasek> doko: no; and also your patch does not fix it...
<doko> ?
<slangasek> doko: you have the right package but the wrong -V argument ;)
<doko> slangasek, hmm, at least kopete builds now
<infinity> doko: You just made packages depend on the wrong package, unless you have a versioned provides.
<doko> ahh, I see
<infinity> And a versioned provides would completely break the point of renaming the library package, so I hope you don't have one.
<doko> killing the kopete builds
<doko> still wondering why the command succeeds with an unknown package
<infinity> doko: The string you pass to -V isn't (and shouldn't be) validated, as you can have a package-foo-alt whose shlibs declares a dep on package-foo, or whatever.
<infinity> doko: It's one of those 'enough rope' sort of interfaces.
<doko> no, but slangasek's original upload called with -p <package not in control file>
<infinity> Oh.  That one should have broken, depending on how debhelper stuff was called, yeah. ;)
* infinity changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise - vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* infinity changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> doko: yes, the original upload (from my original script) was buggy, the new upload was also buggy, but it seems we're converging now.  The latest version of my script still wouldn't DTRT here but the Debian release team have enough hints in that thread that they can fix it up for their own usage to address these bugs - I'm not futzing with it in Ubuntu anymore because the damage is done and anythin
<slangasek> g that's broken is going to need manual attention now
<doko> slangasek, which thread?
<slangasek> doko: debian-devel
<doko> which... don't ;-P
<slangasek> so who keeps blindly retrying asterisk builds on amd64 and generating mail for me? :)
<doko> slangasek, me. see my question on -devel/-release. anyway, afk now
<doko> and finished the coinutils-g++5 transition by "blindly retrying"
<slangasek> doko: I'm not seeing any question on any devel fwiw
<doko> slangasek, hmm, maybe not sent. I was asking if some -dev package dropped dependencies on other -dev packages
#ubuntu-devel 2015-08-14
<doko> three more transitions finished. libgenome, libmsn, coinutils. good night
<pitti> barry: hmm, and the last runs indeed succeed again -- http://autopkgtest.ubuntu.com/packages/p/pytables/
<pitti> barry: so, nevermind
<pitti> good .. almost morning
<pitti> jdstrand: I haven't seen it before; isn't that test running as root? seems weird to not have permisisons
<pitti> jdstrand: or is that some click --user mode?
<pitti> jdstrand: ack, will look at the bug; not sure there's much that I can do on the autopkgtest side, but it seems for now we don't yet understand enough what happened
<doko> pitti, kicad ... tried to update the stable branch, but this apparently must relate to the current trunk. can't find any reference to this flag
<pitti> doko: http://pkgs.fedoraproject.org/cgit/kicad.git/tree/kicad.spec#n232 uses it as well, and it was recommended on the upstream bug
<pitti> doko: err, Debian bug
<pitti> doko: anyway, as noted in the pad this is waiting on apw's boost fix
<pitti> then it can be retried
<dholbach> good morning
<kako> Hi, I'm wondering why I can't find the libt1-dev package for 15.04. Was the name changed? Is there an alternative? On a 14.04 I can find it by "dpkg -S /usr/include/t1lib.h" => libt1-dev, but on 15.04 I get no result. Is there no "libt1.(a|so)" for vivid?
<infinity> kako: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744881
<ubottu> Debian bug 744881 in ftp.debian.org "RM: t1lib -- RoQA; obsolete" [Normal,Open]
<kako> infinity: thanks, this is a answer... but now I must find out how to compile php without t1 :-(
<infinity> kako: The same way it's configured in the distro?
<infinity> kako: --without-t1lib
<guest42315> dpkg: error processing archive /var/cache/apt/archives/unity-control-center_15.04.0+15.10.20150813-0ubuntu1_amd64.deb (--unpack):
<guest42315>  trying to overwrite '/usr/share/man/man1/bluetooth-wizard.1.gz', which is also in package gnome-bluetooth 3.8.2.1-0ubuntu12
<guest42315> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<guest42315> on wily :/
<mitya57> guest42315, it's 1484658, will be fixed soon
<mitya57> bug 1484658
<ubottu> bug 1484658 in unity-control-center (Ubuntu) "package unity-control-center 15.04.0+15.10.20150805-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/bluetooth-wizard.1.gz', which is also in package gnome-bluetooth 3.8.2.1-0ubuntu12" [High,Confirmed] https://launchpad.net/bugs/1484658
<seb128> mitya57, do you handle the landing or should I?
<mitya57> Just wanted to ask the same :)
<mitya57> I can do it.
<seb128> thanks
<guest42315> mitya57, oh thanks :D
<guest42315> \o/
<mitya57> building in landing-023 now
<mitya57> 2015-08-14 09:32:28,962 ERROR unity-control-center 15.04.0+15.10.20150813-0ubuntu1 is missing from the changelog, which has up to 15.04.0+15.10.20150805-0ubuntu1. Please sync destination version back to trunk.
<mitya57> seb128, can I tell citrain to forcefully merge your upload to trunk?
<seb128> yes
<seb128> want me to do it?
<seb128> seems you did, thanks
<mitya57> Yes I did it.
<tsdgeos> doko: is https://code.launchpad.net/~aacid/unity8/dropgcc49more/+merge/268047 correct? i think i've seen some other projects do this too
<mitya57> Oh wait, why did it commit the indicator-bluetooth change to 15.04 branch?
<doko> tsdgeos, yes
<seb128> shrug
<tsdgeos> doko: tx
<seb128> mitya57, because works was from previous cycle and we didn't retarget :-/
<mitya57> :(
<mitya57> At least the branches aren't diverged so it's possible to push that commit to trunk.
<seb128> right
<mitya57> seb128, I'm not a member of ~indicator-applet-dev, can you do that?
<seb128> k
<mitya57> branch & push
<seb128> mitya57, there, you go, https://code.launchpad.net/indicator-bluetooth
<seb128> 15.04 back on r87
<seb128> and trunk on 89
<mitya57> seb128, thanks a lot
<seb128> yw!
<kako> infinity: yes, of course ;-). But what If I need the type 1 font functionality?
<guest42315> No tool chain set from kit "Ubuntu Device (GCC armhf-ubuntu-sdk-15.04-vivid)".
<guest42315> No tool chain set from kit "UbuntuSDK for i386 (GCC ubuntu-sdk-14.10-utopic)".
<guest42315> ubuntu-sdk on wily
<guest42315> Failed to parse '/usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/plugins.qmltypes'.
<guest42315> Error: /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/plugins.qmltypes:1106:39: Meta object revision without matching export.
<guest42315> /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/plugins.qmltypes:1125:39: Meta object revision without matching export.
<sil2100> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1484882 <- :)
<ubottu> Launchpad bug 1484882 in langpack-o-matic "Set automatic language-pack creation an upload for overlay-ppa" [Undecided,New]
<sil2100> pitti: hey!
<sil2100> pitti: I'll also request a manual langpack-o-matic run later today if that's not a problem - will you have a moment for that?
<mterry> infinity, thanks for the NEW and presumably the rebuild presses on progressivemauve  :)
<mterry> pitti, oh interesting about --v5 not being in Debian, thanks for the warning.  I am not very familiar with d-shlibmove
<infinity> mterry: No rebuild presses, but if it was dep-wait, that clear automatically.
<mterry> infinity, hrm, they were failures.  Some kind soul pressed some buttons
<flexiondotorg> seb128, Regarding Blueman2. You mentioned a merge should be done. Do you mean a merge proposal for the just the debian packaging?
<seb128> flexiondotorg, no, a merge
<seb128> flexiondotorg, https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<flexiondotorg> seb128, Thanks for the docs.
<seb128> yw
 * flexiondotorg goes to have a read.
<seb128> basically there are ubuntu changes to that package
<seb128> so you can't drop them
<seb128> you need to reapply them on top of the debian version
<flexiondotorg> seb128, I understand that bit :-)
<seb128> k, that's what a merge is
<flexiondotorg> seb128, I need to learn the mechanics of merging.
<seb128> take the debian version and reapply the ubuntu changes
<seb128> your sync request was basically copying the debian version discarding ubuntu work
<flexiondotorg> seb128, Understood.
<infinity> flexiondotorg: The simplest mechanic is "debdiff debian_ver ubuntu_ver > ubuntu.diff" and then apply that diff to the new Debian.
<infinity> Which takes some wiggling in the changelog.
<infinity> Or, if it's a simple merge, MoM may have done it for you and you just need to check it.
<flexiondotorg> infinity, seb128 Thanks for the info.
<infinity> https://merges.ubuntu.com/b/blueman/
<flexiondotorg> My concern is I am on Jury service right now. Very limited time on a computer. I don't know if I will have the oppotunity to do this work before next weeks feature freeze :-(
<infinity> So, wasn't simple enough for MoM to get it right.
<infinity> But the conflicts are likely easy to resolve by a human.
<jdstrand> pitti: I spent about 5 hours digging into that bug yesterday and I'm quite puzzled-- it only happens under adt-run. there are steps to reproduce in the bug and how it doesn't reproduce in a schroot
<pitti> sil2100: hey! (spotty now, in train)
<jdstrand> are you able to reproduce? I can help speed up trying to reproduce if needed
<pitti> mterry: d-shlibs> heh, nobody is :) it was my first encounter too
<pitti> sil2100: I can do a manual run, for what?
<pitti> jdstrand: hey! adt-run captures stdout and stderr into pipes, maybe that's related? /dev/pts sounds like that could be related
<jdstrand> pitti: hello :)
<jdstrand> well, it's weird
<pitti> jdstrand: just a straw of bandwidth right now, and I spent the morning on g++ again, sorry
<jdstrand> that's ok
<pitti> jdstrand: I have the bug report now as a reminder
<jdstrand> pitti: how easy is it to kick off an autopkgtest in jenkins for click-apparmor in wily?
<jdstrand> pitti: basically, the severity will be somewhat less if it is only on a local schroot
<jdstrand> pitti: but if jenkins can't run it, that is more important
<pitti> jdstrand: rather hard, as we don't run Jenkins any more :)
<pitti> jdstrand: more seriously, it's rather easy
<pitti> jdstrand: requested
<pitti> jdstrand: are you still an archive admin? then you can do it yourself too (https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration)
<pitti> err, or I would have requested it if my ssh command hadn't failed, /me kicks VPN
<jdstrand> pitti: I am (though not active in the traditional sense-- have the powers still for shuffling MIRs and security updates)
<pitti> ok, done for realz
<jdstrand> thank you
<jdstrand> and haha on the jenkins bit :)
<pitti> jdstrand: not "haha", it's a great relief :)
<jdstrand> hehe
<jdstrand> I just meant I actually laughed at your joke :)
<pitti> jdstrand: (no worries - TGIF!)
<jdstrand> pitti: fyi, not that it matters much, but I don't have access wo wendigo
<jdstrand> s/wo/to/
<pitti> jdstrand: right, you just need access to snakefruit for requesting tests (the britney host)
<jdstrand> ok. I was running the command to see if it was running
<jdstrand> np
<pitti> jdstrand: btw, result will take a bit, the queues are rather long
<pitti> (~ 110 tests waiting)
<pitti> will appear on http://autopkgtest.ubuntu.com/packages/c/click-apparmor/wily/amd64/
<pitti> (and /i386 of course)
<jdstrand> is https://jenkins.qa.ubuntu.com/view/wily/view/All/job/wily-adt-click-apparmor/ no longer used? (I see jenkins in the url)
<pitti> jdstrand: no, it's not; I sent u-devel-annouce@ about that two weeks ago or so
<pitti> jdstrand: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-August/001145.html FYI
<jdstrand> I thought I remembered there was something on that. ok, thanks
<jdstrand> pitti: curious, is the queue expressed anywhere in http://autopkgtest.ubuntu.com/?
<pitti> jdstrand: no, not yet; it's an open wishlist item
 * jdstrand nods
<jdstrand> pitti: the site looks good. nice job :)
<pitti> jdstrand: most of it isn't my job (I just did a few fixes), but thanks
<pitti> jdstrand: it's "debci", aka. http://ci.debian.net
<hallyn> infinity: could you unblock libvirt (as of 1.2.16-2ubuntu8)
<sil2100> pitti: hey! I wanted that manual langpack creation since 1) wanted to check if all is working 2) get out our first updated base of translations for the overlay with no manual hacks involved
<sil2100> pitti: anyway, still waiting for the base export to happen
<sil2100> pitti: I asked wgrant for it, but it'll probably take a while until it finishes
<infinity> hallyn: You have the power to do that.
<hallyn> oh?  /me checks
<Laney> (Close the bug)
<infinity> Or remove the block-proposed tag.
<infinity> Which is more appropriate than closing the bug.
<cyphermox> morphis: I was told you were preparing a packaging branch for bluez in ~bluetooth?
<infinity> Since the bug isn't closed until the package migrates.
<infinity> hallyn: ^
<morphis> cyphermox: yeah
<cyphermox> morphis: is that lp:~bluetooth/bluez/ubuntu and were you done?
<morphis> yeah
<cyphermox> morphis: I wonder if we shouldn't keep history
<morphis> would be fine for me
<hallyn> i see - i thought it was a package property, not bug
<hallyn> infinity: thx
<infinity> hallyn: Excuses has a link to the bug that's blocking it and everything. :)
<cyphermox> morphis: finally, I'm curious, is it set up as a merge-mode branch on purpose, ie. for CI train landings or something?
<morphis> cyphermox: no, just for manual uploads atm
<morphis> but would be good to have that
<cyphermox> ok
<cyphermox> morphis: I'll see if I can prepare a bluez branch too then I'll show you how it works / what I've done, we can see if that would work
<morphis> that would be nice
<morphis> still struggeling a bit with all this stuff :)
<seb128> cyphermox, basically my fault for suggesting that workflow
<seb128> but I don't know of a workflow working well for upstream projects
<cyphermox> well, it's what I would have used too
<seb128> CI train works fine for thing smaintained in launchpad
<cyphermox> but I've thought that now maybe git would work
<seb128> yeah, I think that too
<seb128> I just have no clue about what workflow would be nice
<seb128> and how to set it up
<cyphermox> I wanted to make that for NM given that we already force NM to go through the train
<seb128> and I didn't want to block starting a vcs on me figuring out those details
<cyphermox> seb128: I'll play with it this week, get to a conclusion and let you know
<seb128> thanks
<cyphermox> to seed it I just need to download a few hundred .dscs :)
<infinity> cyphermox: Thus proving that source packages *are* a VCS.
<infinity> If you keep all of them...
<cyphermox> yeah
<cyphermox> but it's not so much for the history that I was looking into this
<cyphermox> it's more for the ease of pulling in new upstream releases or cherry-picking patches from some git tree, which is what Tony wants to do in NM
<infinity> flexiondotorg: Or maybe you're paying attention in this channel? :)
<pitti> utlemming: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=3676d8c7b FYI
<pitti> infinity: ^ I think he discussed that with you
<infinity> pitti: Yeah.  To be fair, his rule only applied to CPUs, but I can't immediately think of how allowing the memory rule under Xen would be a bad thing.
<infinity> pitti: (It's probably a no-op entirely, since Xen memory management isn't done that way)
<pitti> infinity: yes, I just didn't want to make the rule even more complicated; apparnetly hyper-v needs the memory rule too
<infinity> pitti: THat said, all it would take is one more LABEL to make it do exactly what his rule did.
<utlemming> pitti: I think your match won't work: ATTR{[dmi/id]sys_vendor}=="Xen", Machine"
<infinity> pitti: Inset a vm_cpu_hotadd_apply LABEL in between the two, and make Xen jump to that one.
<pitti> well, what should *really* be done is to stop working around kernel defaults in userspace and just activate hotplugged CPUs
<infinity> pitti: Yes, no argument on that.
<pitti> it's stupid to always override kernel defaults with constant values from userspace
<infinity> pitti: utlemming also has a point WRT your typo. ;)
<infinity> Or copy-pasto.
<barry> pitti: ping.  i'm confused.  when you look at dh-python for wily/{amd64,i386} on autopkgtest.ubuntu.com, you see a thumbs-down-fail, but if you chase the link to the test logs, it looks to me like they're passing.  am i looking at the wrong thing?
<infinity> barry: Search for '- - - re'
<infinity> Makefile:16: recipe for target 'test201' failed
<infinity> make: *** [test201] Error 2
<infinity> adt-run [09:19:05]: test dh-python: -----------------------]
<infinity> adt-run [09:19:05]: test dh-python:  - - - - - - - - - - results - - - - - - - - - -
<infinity> dh-python            FAIL non-zero exit status 2
<infinity> For example.
<barry> ah.  okay, i need to file a bug on autopkgtest.  it's too hard to find the results in a big log file :(
<seb128> could somebody overwrite the boottest for bluez again?
<seb128> it's buggy
<seb128> Laney overwrote it earlier, but that doesn't stick and cyphermox did an upload since
<cyphermox> yes, please :)
<tjaalton> doko: looks like the switch to gcc5 broke mesa build on debian & ubuntu
<tjaalton> http://pastebin.com/VgJX9ghz etc
<tjaalton> doko: Sarvatt pointed me to https://llvm.org/bugs/show_bug.cgi?id=22593
<ubottu> llvm.org bug 22593 in System Library "lib/libLLVMRuntimeDyld.so build failure with gcc-5" [Normal,Resolved: fixed]
<LocutusOfBorg1> Unit193, can I upload virtualbox-ext-pack on unstable?
<seb128> slangasek, can you override buggy boottests?
<seb128> cf backlog, somebody to skip the bluez one would be nice
<slangasek> seb128: it is possible to do, but why do you believe the boot test is buggy?
<seb128> slangasek, because pitti said this morning that it always failed on bluez and that he keeps skipping it
<seb128> slangasek, http://irclogs.ubuntu.com/2015/08/14/%23ubuntu-desktop.html#t07:57
<seb128> if you want reference
<seb128> we should sort that out one day, but atm the bluez transition had an issue and half migrated
<seb128> which is breaking iso builds
<slangasek> pitti: what is broken about the bluez boottest?
<seb128> so would be nice to unblock it without waiting on the boottest situation to be sorted out
<slangasek> seb128: and what is the impact of this new bluez on the phone stack - which is what boottests are supposed to tell us?
<seb128> slangasek, basically making bluetooth not working on touch
<seb128> which was an approved decision before landing
<slangasek> ok
<seb128> the phone team is working on enabled bluez5 but they don't plan any product on wily and the image is already in a not so good state
<seb128> so they said it's ok to unblock desktop and make bluetooth buggy on touch for a while
<slangasek> but it's not expected to make the phone unbootable, for instance; this is probably just an error with the boot tests being broken? (trying to install packages on a running system with apt instead of offline)
<seb128> right
<slangasek> ok, will override as soon as I find the syntax
<seb128> thanks
<slangasek> though maybe it's just (force-skip)
<slangasek> seb128: done
<seb128> slangasek, thanks
<doko> tjaalton, I don't understand, the last successful build is https://launchpad.net/ubuntu/+source/mesa/10.6.3-1ubuntu1 ?
<tjaalton> doko: it was built with old gcc
<tjaalton> now llvm needs to be rebuilt with gcc5 and only then would mesa build again
<doko> tjaalton, on Aug 11?
<tjaalton> hm sorry
<tjaalton> well it fails on my sbuild
<doko> no, I already rebuilt 3.5 and 3.6
<tjaalton> hmm
<tjaalton> then I need to check my chroots
<tjaalton> ..next week
<doko> tjaalton, you sure to have -proposed enabled?
<tjaalton> but debian fails too
<tjaalton> no
<doko> then do
<tjaalton> failure on debian is expected then?
<doko> and I'm pestering Sylvestre to rebuild it in Debian
<tjaalton> sid
<tjaalton> ahh ok
<doko> yes
<tjaalton> then I'll revisit it next week :)
<tjaalton> thanks
<mitya57> Mirv, hi, is there any reason why qtcreator is not built with system qbs (like in Debian)?
<mitya57> Mirv, also, in Qt 5.5 there are duplicate headers in /usr/include/x86_64-linux-gnu/qt5/QtQmlDevTools/ and /usr/include/x86_64-linux-gnu/qt5/QtQml/,
<mitya57> do you know if we really need the former? and if we need, can we symlink them?
<LocutusOfBorg1> ginggs, congrats!
<ejat> hi ..
<ejat> can someone help me know why need to remove gnome-bluetooth ?
<ejat> http://paste.ubuntu.com/12084015/
#ubuntu-devel 2015-08-15
<hallyn> looking at some other changelogs, now i'm wondering - are we still doing the "oldrelease-proposed" thing, or did thta go away when we switched to devel-proposed and now I should just use 'trusty' instead of 'trusty-proposed'?
<hallyn> well i guess it doesn't break anything at least to keep using it, even if it appears not to break things when not used
<stgraber> hallyn: we've been redirecting <series> to <series>-proposed for a couple of years now I think, but either works fine
<ginggs> LocutusOfBorg: thanks! are you attending debconf this year?
<mitya57> cyphermox: https://launchpadlibrarian.net/214485915/bluez_5.33-0ubuntu2_5.33-0ubuntu3.diff.gz looks like you did *not* update d/control
#ubuntu-devel 2015-08-16
<Mirv> mitya57: the qbs is just an omission, I'm meaning to fix it. I just gave some time for release pocket migration to happen but it seems it'll need some release team hinting to get both botan and muparser transitions in at the same time (if I understood correctly)
<Mirv> mitya57: hmm, no I'm not aware whether the QtQmlDevTools is really needed, maybe it should be just removed and seen if everything continues to work fine
<mitya57> Mirv: I already checked yesterday and the headers can't be easily removed (qttools need that), but can be symlinked (will do that in next Debian upload).
<mitya57> Thanks for looking at qtcreator!
<pitti> slangasek: I don't know, I don't have any insight into the boottests; just that some packages have never worked
<pitti> jdstrand: so click-autopkgtest continues being happy, seems it's specific to a schroot
<pitti> jdstrand: presumably because most chroots have the host's /dev/pts bind-mounted; I don't know why it fails precisely, but VM tests don't have such a shared /dev
<happyaron> slangasek: protobuf broken for builds in wily?
<slangasek> happyaron: see doko's mail to ubuntu-devel-announce.  If you want to build C++ code in wily right now, you need to do it with wily-proposed enabled (like the autobuilders do)
<happyaron> ok
<happyaron> thx
<slangasek> freyes: we have failing puppet autopkgtests in wily that started happening at the time ruby-passenger was uploaded for the g++5 ABI transition.  Is this something that you would be able to look into?  I'm planning to bypass the ruby autopkgtest failure as necessary to un-wedge the large transition, which means puppet may be left broken in wily until someone can look at it (http://autopkgtest.ubuntu
<slangasek> .com/packages/p/puppet/wily/amd64/ ...
<slangasek> ... http://autopkgtest.ubuntu.com/packages/p/puppet/wily/i386/)
<slangasek> happyaron: sorry, I should have mentioned this part earlier as well as you were working on something building with C++ - please note that the main g++5 transition is currently in progress, so uploads of any affected packages (including protobuf) slows down the transition; please avoid uploading these until tomorrow
<slangasek> happyaron: (I've just removed the old uim-mozc binaries from wily-proposed, so mozc should now make it in without problems)
<happyaron> slangasek: ty! I really need that package to land before feature freeze, and sorry for that
<happyaron> slangasek: after striping down uim support, we cleared the way of using mozc as default for Japanese users.
<slangasek> happyaron: lots of devs need lots of things to land before feature freeze, but landing them when we're trying to land the transition slows down everyone else's landings :)  but hopefully we'll be able to push this through within just the next couple of hours
<happyaron> ic
<maqbool> hello guys i am newbie to open source world i want to contribute how can i get started
<maqbool> ?
<ari-tczew> maqbool: hi. do you want to contribute to open source in general, or stricte to Ubuntu?
<maqbool> open source but related to ubuntu
<maqbool> I am University undergraduate
<ari-tczew> maqbool: well, there is an useful link in the topic, but you might be interested in reading this one https://wiki.ubuntu.com/MOTU/GettingStarted
<maqbool> thanks
<ari-tczew> maqbool: you don't need to have Bachelor/Master graduated :)
<ari-tczew> cyphermox: anyway, would be nice if you could process NM 1.0 till 20th :)
<cyphermox> yeah, I'm fixing up a git branch to do this on
<ari-tczew> cyphermox: cool
#ubuntu-devel 2016-08-15
<wemeetagain> is there any documentation/information about how ubuntu is handling the transiion to the c++11 abi?
<wemeetagain> are packages in 16.04 being compiled with dual abi/ c++11 abi support?
<RAOF> wemeetagain: Nope; it's all new ABI.
<xnox> PHLin, new launchpadlib should be in yakkety now - could you please test if that's all good now?
<PHLin> xnox, ok let me try
<PHLin> xnox, hey there, launchpadlib tested with Yakkety dailylive image, and it works, thanks!
<xnox> PHLin, whoop whoop.
<xnox> PHLin, I see that in your repository you have a port to python3 for this helper lptk library or some such. It's packaged in the distribution as well, are you planning to upload python3 version of it into Yakkety too?
<cjwatson> xnox: Maybe you should wait for review ... your launchpadlib r152 will crash if you pass unicode to that method on Python 2
<cjwatson> oh, wait, will it
<cjwatson> Yeah, it will if it's unicode and contains non-ASCII characters
<PHLin> xnox, need to ask bjf, that port exists before I took part in this :D
<cjwatson> xnox: why not "if isinstance(query_string, bytes)"?
<xnox> bah, at the moment it bail on me in different way now.
<xnox> http://paste.ubuntu.com/23057847/ -> even in python3
 * xnox thinks i've screwed up multiple times
<cjwatson> no, that one is my fault, will fix
<cjwatson> fixed in r153, was a regression in r146
<xnox> cjwatson, ack. I rolled back to 145, applied my credentials file fix, and it works correctly.
<xnox> cjwatson, as far as understand in python2 the query_string is unicode object, not string.
<xnox> no that's wrong.
<cjwatson> Don't care what it is; my point is that you can't necessarily decode a unicode object.
<xnox> true.
<cjwatson> >>> sys.version
<cjwatson> '2.7.12 (default, Jul  1 2016, 15:12:24) \n[GCC 5.4.0 20160609]'
<cjwatson> >>> u'Ã©'.decode('utf-8')
<cjwatson> ...
<cjwatson> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: ordinal not in range(128)
<xnox> but i only need to decode in python3. And "if isinstance(query_string, bytes)" breaks in python2 for this case
<cjwatson> Why does it break?
<xnox> as str & bytes are the same in python, and decoding code path is triggered.
 * xnox checks my previous py3 macros in that file
<cjwatson> And why does that break?
<cjwatson> In one of my previous comments I noted that it should work fine with unicode on Python 2.
<xnox> in other places we do
<xnox> 153        if not isinstance(value, unicode_type):
<xnox> 154            value = value.decode('utf-8')
<xnox> which is correct, as we correctly set unicode_type to be the right thing for python2 and python3.
<cjwatson> I think either your approach or mine would work.
<xnox> horum yes.
<xnox> $ python2 -c "if isinstance('string', bytes): 'string'.decode('utf-8')"
<xnox> does not explode.
<xnox> cjwatson, changed to use "if isinstance(query_string, binary_type)" which is actually the same as "if isinstance(query_string, bytes)" given the macros at the start of the file.
<xnox> and i guess i'll need both of these commits uploaded now.
<cjwatson> what?
<cjwatson> if you mean "if isinstance(query_string, bytes)" then just write that.
<cjwatson> no reason to use binary_type.
<cjwatson> in fact binary_type should not exist; it's only for compatibility with pre-2.6 and we don't care about that any more.
<cjwatson> xnox: ^-
<xnox> what was special about pre-2.6 that warranted that. I'm pretty sure binary-type was cargo-culted from six / write py2&3 compatible code guides.
<cjwatson> xnox: pre-2.6 didn't have "bytes"
<xnox> oh
<xnox> quite, don't care about that.
<cjwatson> six was designed to support quite old versions of Python, but launchpadlib has no good reason to care
<cjwatson> even six probably doesn't particularly any more, but inertia
<xnox> yeap.
<cjwatson> now, my approach does mean that AccessToken will be constructed with unicode attributes
<cjwatson> so actually perhaps "if not isinstance(value, unicode_type)" is safer
<xnox> cjwatson, python3 -c "from launchpadlib import launchpad as lp; lp.Launchpad.login_with('foobar', credentials_file='foobar.txt')" still explodes in both python2 & 3.
<xnox> in a different spot now.
<xnox> cjwatson, http://paste.ubuntu.com/23058020/
<xnox> correct because i shall not copy & paste bad things
<cjwatson> your code is broken :)
<cjwatson> so yeah, s/content/query_string/g in that bit and may as well make it the slightly more conservative not unicode_type test while you're there.
<xnox> yeah credentials is conservative like that: if unicode_type to serialise; if not unicode_type to decode.
<RAOF> Hm. What's the way we get new CI'd projects into the archive?
<ginggs> doko: libixion and liborcus need updated symbols for the gcc6/boost1.61 transition, do they need a soname bump as well?
<sitter> juliank: hey. any thoughts on the os-release mess? I am thinking only using it for is_like right now as to preserve capitalization from lsb_release, but long-term this really needs an API behavior break and coerce the Distribution attributes id, codename and release to lower case so we have normalized expectations both internally and externally
<juliank> I don't think anyone is relying on the casing of the distro names?
<sitter> juliank: I am always wary of breaking behavior, regardless of whether I know it is used :)
<juliank> But I'm probably wrong.
<juliank> s/'m probably/might be/
<Riddell> bdmurray: ping?
<Odd_Bloke> infinity: Where are we on getting sagari's kernel upgraded to something that can handle metadata_csum?
<dobey> hmm
<dobey> how do seeds handle conditional dependencies when building the ISOs for example?
<doko> ginggs, libixion is in NEW
<zul> can someone please promote python-ws4py please https://bugs.launchpad.net/ubuntu/+source/python-ws4py/+bug/1590425
<ubottu> Launchpad bug 1590425 in python-ws4py (Ubuntu) "[MIR] python-ws4py" [Undecided,Fix committed]
<ogra_> dobey, depends on the flavour ... some use tasks and some use metapackages ... both resolve slightly different
<dobey> ogra_: right, but say i need to support both snaps and clicks, and so i want to have "snapd | click" as a dependency, what happens?
<ogra_> well, you seed both or one ... and hope for the best :P
<ginggs> doko: yup i see 0.12 experimental there, i uploaded 0.11 with updated symbols in the meantime
<cjwatson> dobey: seeds don't have conditional dependencies; you have to pick one
<cjwatson> dobey: they exist to be opinionated
<cjwatson> dobey: but are you in fact talking about what happens if something that is seeded itself has alternative dependencies?
<cjwatson> dobey: rather than trying to put alternatives in the seeds themselves?
<dobey> cjwatson: yes
<dobey> cjwatson: so if my package, which is seeded, has a conditional dep, and both are in main, does first get picked?
<cjwatson> dobey: in most cases yes, though it's a little bit more complicated than that.  the algorithm is as follows: (1) are any of the alternatives explicitly (i.e. not just via deps) listed in this seed?  if so, pick the first.  (2) is the first alternative explicitly listed in a seed that inherits from this seed?  if so pick that.  (3) are any of the other alternatives explicitly listed in a "close-by" s
<cjwatson> eed (i.e. one that generates the same ...
<cjwatson> ... task, as defined by Task-Seeds headers)?  if so, pick the first.  (4) pick the first of the alternatives that exists.
<cjwatson> dobey: the point of all this palaver is to make it possible for flavours to pick different versions of things by explicitly seeding them, but to use sensible defaults.
<cjwatson> dobey: it is not relevant whether any of the dependencies are in main; seeds are used to define what's in main, so we don't circularly use what's in main to define how seeds expand.
<dobey> hmm, ok
<wemeetagain> RAOF: are packages built with the --std=c++11 option set as well?
<wemeetagain> RAOF: from https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html , it appears that the ABI can be set independently of the --std option
<mterry> bdmurray: so about unity-api-bugs vs -team...  Does the -bugs team even seem useful if it's just two people?
<mterry> bdmurray: the -team team is already subscribed to most of their packages, it doesn't seem like they are looking to avoid bugmail
<bdmurray> mterry: The number of the people related to the team doesn't really matter. The team is just an entity for scripts which create reports like http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-y-tracking-bug-tasks.html. I'm fine with switching the team though, iirc I just created teams in some cases as the quickest way to get the reports up and running.
<mterry> bdmurray: but I thought one point was that somewhere someone was reading the bugmail
<bdmurray> mterry: yes, for new MIRs that's true.
<mterry> bdmurray: if you don't care, I'd just as soon use the LP team that the actual maintainers are using
<bdmurray> mterry: That makes sense to me
#ubuntu-devel 2016-08-16
<sarnold> tedg: "##SELECTION_END##"?
<tedg> sarnold: ?
<sarnold> tedg: your comment on https://bugs.launchpad.net/bugs/1613420
<ubottu> Launchpad bug 1613420 in Snappy "no way to run daemons on user session " [Undecided,New]
<tedg> Huh, wonder what happened there.
<sarnold> tedg: are you using evolution? https://codesearch.debian.net/search?q=%23%23SELECTION_END%23%23 -- evo's the only hit in debian's archive..
<tedg> sarnold: Interesting, it is in the plain text copy of the e-mail, but not the html version.
<tedg> sarnold: Yeah, evolution
<pitti> Good morning! /me resurfaces from summer holidays
<tsimonq2> hey pitti! how are you? :)
<pitti> tsimonq2: I'm great, thanks! well-relaxed after vacations
<pitti> infinity: hey Adam, how are you? I fixed some tests and hints from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glibc yesterday, but there's some remaining ones which might be actual issues
<pitti> infinity: cjs, linux-raspi2, log4cxx, umbrello in particular, although some of them might also be due to a new compiler; the others are unrelated and can be hinted once these four get investigated
<seb128> tseliot, pitti, could you make ubuntu-drivers-common stop build-depending on python3-aptdaemon.pkcompat in yakkety? it's a nbs binary now
<infinity> seb128: I'm updating all the metas after mangling the seeds, so you can ignore those r-recommends.
<seb128> infinity, was not going to bother about the recommends but thanks!
<seb128> I'm looking at fixing the real depends though
<Odd_Bloke> infinity: We're seeing yakkety build failures because of sagari's old kernel.  Do I need to re-upload our hack-around for that to our build PPA, or might you be able to upgrade that kernel soonish?
<infinity> Odd_Bloke: Is trusty's new enough?
<Odd_Bloke> infinity: I _think_ so.
<infinity> Odd_Bloke: I'll file a ticket.
<Odd_Bloke> Yeah, https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums suggests it landed in 3.6.
<infinity> Oh, but we didn't do LTS backports on all arches in precise.  That started in trusty.  Grr.
 * infinity doesn't file the ticket.
<infinity> Odd_Bloke: Unfortunately, the solution is going to be to either upgrade sagari entirely or pull it out of rotation.  Less fun.
<Odd_Bloke> Oh, that sucks. :(
<infinity> Odd_Bloke: I'll pull it out of rotation for now, but no guarantees it'll stay that way if the queues get deep.
<Odd_Bloke> infinity: OK, thanks.  We can cope with it being in rotation if there's a queue, because we're less likely to get scheduled on it. :p
<infinity> Odd_Bloke: Heh.  I'll throw some hours later at parallelising my current builders a bit more to make it a non-issue.
<Odd_Bloke> infinity: Thanks. <3
<pitti> seb128: this would break installation of graphics/wifi drivers, so this needs to be entirely rewritten (it doesn't work with packagekit as that doesn't support plugins and thus WhatProvides())
<seb128> urg
<seb128> Laney, cyphermox, ^
<seb128> pitti, well, we went ahead with the packagekit1.0 transition and cyphermox deleted pkgcompat from aptdaemon
<seb128> unsure how that migrated if it breaks ubuntu-drivers-common though
<seb128> oh, it's only a Suggests
<pitti> seb128: language-selector as well; dist-upgrade now wants to remove these two and  ubuntu-desktop
<seb128> shrug
<seb128> how did that migrate
<seb128> and why is language-selector not on http://people.canonical.com/~ubuntu-archive/nbs.html ?
<seb128> oh, I misread
<seb128> it depends on python3-aptdaemon.widgets
<seb128> not on the compat one
<pitti> ah, right; so that one is still okay?
<seb128> yes
<seb128> it's only the packagekit compat layer that got removed
<seb128> in favor of using packagekit directly
<pitti> I need to check what software-properties uses, the PackageKit what-provides API or the UbuntuDrivers module directly
<seb128> since the apt backend there is judged better maintained
<pitti> in the former case this needs to be ported
<seb128> k
<seb128> pitti, thanks
<seb128> pitti, why is dist-upgrading wanting to remove language-selector?
<seb128> it should
<seb128> ubuntu-drivers-common only suggests the compat binary
 * pitti boots VM again, hang on
<pitti> seb128: I get http://paste.ubuntu.com/23060985/
<seb128> pitti, what happens if you "apt-get install sessioninstaller system-config-printer-gnome ubuntu-desktop"?
<pitti> "already the newest version" of course, but with aptdaemon I get
<pitti> aptdaemon: depends p3-aptdaemon, breaks: p3-aptdaemon.pkcompat
<seb128> oh, right
<seb128> add p3-aptdaemon ?
<pitti> oh, that's better
<pitti> http://paste.ubuntu.com/23060994/
<pitti> so it seems apt rather wants to remove l-s & co than install packagekit
<seb128> right, the "right" solution is not scored enough :-/
<pitti> I guess we need to move the aptdaemon dependencies to packagekit?
<seb128> could be
<pitti> seb128: what's the plan now, is aptdaemon obsolete entirely in favor of PK, or just the pkcompat bits?
<pitti> i. e. will sessioninstaller & co move to PK directly?
<seb128> I can do that, it's an alternative depends atm but we should just remove the first option
<seb128> no plan afaik, nobody is really working on that stack
<Laney> :/
<seb128> but we wanted to unblock packagekit1.0 because we were on an old unmaintained version
 * pitti rips out the PK plugin from u-d-common
<seb128> ideally things would use packagekit directly and we remove aptdaemon
<pitti> ok
<seb128> but it doesn't hurt to keep using it until somebody has cycles to work on that
<seb128> which doesn't seem to be the case atm
<pitti> well, the what-provides plugins of l-s and u-d only work with aptdaemon's pkcompat plugins, so they can go
<pitti> aptcc doesn't have plugin support
<pitti> the apt PK backend used to, but AFAIK it's gone
<pitti> a shame really, the plugin concept of PK is really nice and the whole point of using the PK abstraction in the first place
<seb128> yeah :-/
<seb128> are we going to see a feature regression in l-s and u-d?
<pitti> u-d itself is fine, need to check software-properties which has the actual UI for driver installation
<pitti> but if so, it woudl already be broken
<seb128> k
<seb128> need to go for some errands and lunch, bbiab
<pitti> wow, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-drivers-common is 77 days old
<pitti> I now have a package that builds again, running autopkgtests
<tseliot> pitti: great, so that I can finally add a few changes that I was planning to make to u-d-c :)
<pitti> seb128, tseliot: uploaded
<tseliot> :)
<pitti> tseliot: including teh xenial SRU, I guess :)
<pitti> seb128: are you going to unseed it?
<tseliot> pitti: yes, I might revert that change, and go with a lighter approach (which might give us the same results)
<pitti> tseliot: which change?
<tseliot> pitti: the fix for the performance issue in gpu-manager
<tseliot> I need to check if the alternative solution I have in mind is as good though
<pitti> seb128: software-properties doesn't use the PK interface, thus should be fine
<yanku> Hi,when root partition is full, and i delete some files,but it is the same,is there some people met the same ?
<Odd_Bloke> yanku: This channel is for the development of Ubuntu itself (e.g. discussing packaging).  Your question is more suited to #ubuntu (if you're on a desktop) or #ubuntu-server (if you're on a server). :)
<sitter> juliank: Heya, I changed the patch to now only take is_like from os_release, the other values come from lsb_release https://github.com/apachelogger/python-apt/commits/aptsources-distro-os-release so it should be fully backwards compatible. I did add a TODO note about the need for behavior change though
<Mirv> oh pitti is back, welcome!
<pitti> hey Mirv, thanks!
<infinity> pitti: Can debian/tests/control take [arch] specifiers in Depends:?
<Odd_Bloke> xnox: o/ Any plans to backport https://bugs.launchpad.net/launchpadlib/+bug/1471927 to xenial?
<ubottu> Launchpad bug 1471927 in launchpadlib "AccessToken.from_string() crashes on python3" [Undecided,Fix committed]
<pitti> infinity: yes, anything that apt can parse
<infinity> pitti: Kay.  Just adding gcc/binutils/linux-libc-dev [linux-any] to the glibc deps, so they land in Test-Triggers.
<infinity> pitti: Though, irksome that I need gcc-6, since gcc isn't from gcc. :/
<infinity> One more place to update.  Maybe I can generate that.
<xnox> Odd_Bloke, once i upload the fix ups, i guess i could.
<xnox> Odd_Bloke, do you want SRU, or would you be happy with a xenial-backports upload?
 * xnox .o( pip3 install lp:launchpadlib )
<infinity> xnox: Why wouldn't you SRU?
<xnox> good point
<Odd_Bloke> :)
<Odd_Bloke> xnox: I've had problems (the specific nature of which I cannot recall) installing launchpadlib with pip previously; is it expected to work (and currently working)?
<xnox> at the moment trunk > packages > pip, in terms of # of fixes.
<Odd_Bloke> Ah, I guess I was installing from PyPI with pip, rather than trunk.
<cjwatson> It was out of date on PyPI for a while, but I uploaded a less archaic version there recently.
<juliank> sitter: Great, I'll take a look later
<sakrecoer> greetings pitti ! i just wanted to poke you about the status of the systemd upstart thing for ubuntustudio.. i don't have a lot of technical knowledge about it tbh. so i wonder about how it will affect the audio apps and such. i guess my question is: how is the timeframe looking?
<pitti> sakrecoer: sorry, what does "systemd upstart thing" mean?
<pitti> oh, you mean running the ubuntustudio session under systemd?
<pitti> that shouldn't affect audio apps at all, just a question of getting more robust services with better logging
<sakrecoer> pitti: sorry, yes that is what i ment.
<sakrecoer> ok. sounds fair :)
<sakrecoer> thank you, pitti
<pitti> time frame> I'm working on netplan ATM which is higher prio, so I might have a look in September
<pitti> sakrecoer: but there shouln't be any breakage with current ubuntustudio yakkety, is there?
<pitti> (or regression)
<sakrecoer> pitti: september sounds great. i don't know if there are any breakages, that is why i was hopeing we would get some time before release to try everything :)
<sakrecoer> thank you pitti for your answer and time! bye for now :) o/
<infinity> pitti: http://paste.ubuntu.com/23061299/
<infinity> pitti: That seem like a reasonable approach?
<pitti> infinity: nice!
<pitti> infinity: oh, do we use gcc-6 now? that might explain some of the new glibc regressions
<pitti> ah, so we do
<infinity> pitti: We do.  It explains the linux-raspi2 one, for sure.
<infinity> pitti: Lots of new warnings, and that's building with -Werror.
<infinity> I like the misleading-indentation warning.
<pitti> oh yes, that's awesome
<jbicha> what are we doing with python3-aptdaemon.pkcompat as seen on https://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> xml/domtestcase.cpp:193:117: error: narrowing conversion of â194â from âintâ to âlog4cxx::logchar {aka char}â inside { } [-Wnarrowing]
<pitti> infinity: ^ this (log4cxx) also looks  gcc related then, not libc
<infinity> jbicha: Unwinding the rdeps and then nuking it.
<pitti> infinity: and umbrello is also a C++ incompatibility, not glibc
<pitti> infinity: thus I don't see any real glibc regressions; time for force-skiptest?
<pitti> infinity: or do you want to let it bake longer?
<jbicha> infinity: so I can/should just drop it from ubuntu-gnome's seed?
<pitti> it blocks a fair bunch of other packages in -proposed
<infinity> pitti: I don't think baking will do much good, if the tests look reasonable.
<infinity> jbicha: Already done.
<pitti> infinity: agreed; ok, hinting
<infinity> jbicha: And uploaded meta.
<infinity> pitti: Besides, I will be doing another upload and resetting all the tests to zero. :P
<pitti> ubuntu-drivers just landed too (wrt. pkcompat removal)
<jbicha> infinity: cool, thanks
<pitti> infinity: my minions will be pleased!
<pitti> infinity: btw, britney doesn't look at Testsuite-Triggers: yet, but that's reasonably high on my list
<jbicha> Laney: when is a good time for me to do the evolution 3.22 transition since I believe it collides with the qt transition? bug 1613291
<ubottu> bug 1613291 in evolution-data-server (Ubuntu) "Update evolution stack to 3.22" [Wishlist,In progress] https://launchpad.net/bugs/1613291
<infinity> pitti: Yeah, I figured it didn't yet, but never hurts to be prepared. :)
<infinity> pitti: I'm kinda hoping we can do something approximating The Right Thing with this to fix the kernel testing mess.  Or make it less messy, anyway.
<pitti> infinity: indeed not, and with this I can take out some hardcoded triggers
<Laney> jbicha: When it migrates, just the kernel left AFAICT
<seb128> pitti, unseed the pkgcompat binary? infinity did(is doing?) that
<Laney> jbicha: I pinged #ubuntu-kernel earlier but no reply yet
<jbicha> Laney: thanks
<infinity> Laney: The kernel is tied up in the Qt transition?
<infinity> Laney: How or why would that be?
<infinity> linux-tools.  Hrm.
<infinity> Laney: linux-tools doesn't depend on Qt, what else got pulled into this mess?
<Laney> binutils
<infinity> Well, isn't that lovely.
<Laney> It's zooper dooper
<infinity> FWIW, I see a couple more non-kernel packages there.
<infinity> perf-tools-unstable, qbittorrent, btfs
<shemgp> Anyone knows which app I need to run to have the com.canonical.AppMenu.Registrar dbus service?
<infinity> Oh, p-t-u just depends on linux-tools
<Laney> I don't see qbittorrent and btfs those in the autohint I'm looking at
<Laney> There's one which includes it in the hint
<seb128> shemgp, it doesn't work like that, what are you trying to do?
<infinity> Ahh, I missed the bigger block.
<Laney> nod
<seb128> shemgp, on unity it's unity-panel-service which owns the name
<infinity> apw: Are you back from vacation yet?
<Laney> Who needs a kernel anyway
<Laney> let's just remove it
<infinity> *smirk*
<infinity> If libbfd actually had sane versioning, this wouldn't be an issue.
<infinity> Friggin' binutils.
<Odd_Bloke> If we removed the kernel, we'd also be able to close out pretty much all other bugs as unreproducible.
<Odd_Bloke> So that's another positive.
<shemgp> seb128: I'm tinking of creating a global menu widget for gnome 3. Do I need to run my own dbus service then?
<infinity> Laney: FWIW, this is the major metric the kernel team will use to decide if we can let it in: http://people.canonical.com/~kernel/status/adt-matrix/yakkety-linux-meta.html
<infinity> Laney: Feel free to examine missing or regressions and figure out why. :P
<Laney> infinity: Is the baseline usually good?
<infinity> Laney: Well, you can compare to previous versions there.
<Laney> Oh right, the columns, derpy
<Laney> is this meant to correlate to excuses?
<seb128> shemgp, try talking to tedg when he's online (should be in the next hour or so) but you you can probably build an extension around indicator-appmenu
<Laney> because it's saying some things are regressions that excuses calls always failed
<infinity> Laney: Excuses lies, that's why this exists.
<infinity> Laney: Due to hacks involved for moving triggers around from linux to linux-meta, britney doesn't keep history correcly for those tests currently.
<infinity> tseliot: Any idea why nvidia-304 hates kernel 4.6, and if that can be fixed in a jiffy?
<shemgp> seb128, okay. Thanks for the pointers.
<tseliot> infinity: I thought I had already fixed that. What's the error this time?
<seb128> shemgp, yw!
<infinity> tseliot: Unsure, the autopkgtest just says it didn't install.
<infinity> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/n/nvidia-graphics-drivers-304-updates/20160813_022829@/log.gz
<infinity> tseliot: Oh wait, that's 304-updates, not 304.
<infinity> tseliot: You just need to bump updates to match, it looks like.
<tseliot> infinity: I thought had an admin remove 304-updates from the archive
<tseliot> *tjalton had
<infinity> tseliot: The archive disagrees.
<tseliot> infinity: I can make transitional packages in 304 for -updates, and get rid of the problem
<infinity> tseliot: Sure, that works too.
 * infinity was never quite sure what the updates packages were for anyway...
<tseliot> infinity: they're all going away :)
<infinity> Is that just insurance, so users can roll back?
<tseliot> it was but not any more
 * infinity nods.
<infinity> Good riddance to them, then.
<tseliot> yep
<infinity> So, we can ignore that test failure, if you're killing 304-updates.
<shemgp> tedg, I'm trying to add global menus to gnome 3.  I already run  unity-panel-service so that I can get the using menus from gdbus but not all apps are showing their menus returned.  What am I doing wrong?
<infinity> Laney: I've got Tim looking at iscsitarget, and rerunning all the missing tests.
<infinity> Laney: Odds are, we'll be good to go later today.
<Laney> infinity: 'k, thanks
<infinity> tseliot: Oh, and there's some urgency on that 304-updates think, so if revving it to match 304 is the faster solution before you EOD (I imagine that's trivial), just do that, and kill *-updates later.
<Laney> Let's hope nobody uploads anything that ruins it all in the meantime
 * Laney deactivates everyone's upload rights
<infinity> tseliot: Cause I don't want people using -updates to suddenly be broken when the kernel migrates.
<infinity> pitti: The libnih test on s390x seems well and truly hung.  You might want to hit it with a bat.
<pitti> infinity: I blacklisted it yesterday as it keeps on running forever; for some reason this manages to circumvent the timeout (on all arches)
<infinity> pitti: As if I needed more motivation to remove scottware from the archive.
<infinity> pitti: Death to nih and upstart.
<pitti> infinity: i. e. this is a case of "needs reproducing locally and investigating", just not at the  top of my list
<pitti> hm, what's holding back glibc
<pitti> skipped: glibc (517, 64, 7)
<pitti>     got: 167+0: a-54:a-14:a-16:i-16:p-19:p-15:s-33
<infinity> Oh.  It needs some migration.  I'll do that.
<pitti>     * amd64: apitrace, apitrace-gui, apitrace-tracers, bro, broctl, dante-client, libdsocksd0, libnss-db, libsocksd0, libsocksd0-dev, unscd
<infinity> Yeah.  I'll fix those.
<infinity> They use private symbols, need a rebuild on major version bumps.
<pitti> do we have some libc6 (<= something) deps? I don't see any on e. g. apitrace
<infinity> I usually wait until output.txt reminds me of the list. :P
<infinity> pitti: apitrace-tracers
<pitti> oh, apitrace-tracers
<infinity> Every once in a while, I do a "why are you using private symbols, you fools" pass, but the current list looks mostly like they have valid excuses.
<infinity> Anyhow, will upload rebuilds for all of those after I get back with my coffee. :P
<infinity> s/upload/test and then upload/
<pitti> thanks
<shemgp> tedg, I guess my query now is: How do I make, for example, the menu of gnome-terminal hide so that when I show the menu in the global menu it's not duplicated? Thanks.
<tseliot> infinity: sure
<infinity> pitti: Actually, looks like doko beat me to the rebuilds, so something else to unwind here...
<infinity> pitti: Hahaha.  And that makes glibc end up in the Qt block. :)
<pitti> oh gawd
<infinity> pitti: So, back to "need to get the kernel moving".
<pitti> has that still not landed
<infinity> pitti: The kernel is the last bit.
<infinity> Working on it.
<pitti> wow, how did we intertwine Qt with the kernel?
<doko> pitti, binutils upper version deps
<infinity> Yeah, that.
<infinity> doko: My kingdom for properly-versioned binutils shared libs.
<pitti> infinity: remember, only ever give away half of your kingdom
<infinity> I find it entertaining that binutils, of all things, is the project that can't sort that out.
<pitti> so that you can do it arbitrarily often instead of just once :)
<infinity> pitti: http://www.smbc-comics.com/comic/2011-02-10
<pitti> haha
<infinity> pitti: Yes, that one's a bit of a sad "haha" for me, given how true it rings.
<infinity> pitti: Oh, on the upstart-removal front, is cgmanager still a useful thing in our systemd world?  And, if so, is the libnih dep part of the design, or a side-effect of upstart support?
<pitti> infinity: the main thing that still uses it is ubuntu-app-launch, which tedg will port
<pitti> and qtmir build-depends on it, not sure what it does with that as it doesn't binary-depend on it
<infinity> pitti: Yeah, I was just talking to him on #-release, where you seem to be missing.
 * pitti blames proxy restart after holidays
<infinity> pitti: And he seems less convinced about it being a near-term goal.
<pitti> lxc-android-config also depends on it, also unsure why
<tedg> I don't think we can drop Upstart from U8 until we drop vivid.
<infinity> tedg: Dropping vivid would be LOVELY.
<pitti> +1000
<infinity> tedg: But even without doing so, I don't find "we're triple-landing, so the code can't fork" to be a compelling argument.
<infinity> tedg: yakkety can't be hamstrung by vivid.
<dobey> preacher, choir
<pitti> if we are triple-landing anyway, why doesn't xenial work as a basis for touch again?
<dobey> pitti: gcc5 broke things
<pitti> just  because of the changed C++ ABI? (as solving that would be much easier than what we do now)
<pitti> dobey: really, we are dragging along vivid *just* because of that?
<pitti> wouldn't it be so much easier to upload a gcc-defaults to the xenial  overlay that switches back to g++ 4.9 and rebuild the 20-odd packages that are part of the app ABI?
<dobey> no
<tedg> infinity: I don't think you're gonna find a lot of disagreement from engineers on those points, and I'm hoping management is moving on them as well. But today, in practice, we are hamstrung by vivid.
<dobey> much of it is not only used on the phone, and the issue wouldn't be limited to just "things supported by the SDK"
<dobey> tedg: well, some things could be made optional during build/runtime
<tedg> Sure, but we'd be effectively increasing the QA surface area then. Which isn't really a win.
<infinity> I suspect xenial upgrades would just need to be a flag day with forced app updates to match.  Isn't this exactly what versioned frameworks are for?
<tedg> We could also have different branches for each release to land into. Also a PITA.
<infinity> tedg: I have different branches for all my packages.
<infinity> tedg: I'm not sure why we decided that was unhip for a certain section of the archive.
<pitti> dobey: you mean there are apps which link to C++ libraries outside of the SDK? I thought click apps mustn't do that
<pitti> (I know that we break our own rules, but I thought that was just for us, not for third-party apps)
<infinity> (But if you'd like me to keep landing new upstream versions of glibc to precise and trusty, sure)
<tedg> infinity: It's hard to maintain when you're landing features in all of them. If some are bug fix and one is features that's not too bad.
<dobey> pitti: i mean, not everything is a click app, and the SDK is not self-contained.
<pitti> dobey: right, but the others are ubuntu debs which are already rebuilt against the new API and have proper binary dependencies
<pitti> err,  ABI
<dobey> pitti: right, but to do what you suggested, we'd need to pull a lot more stuff into the overlay PPA, and rebuild everything against 4.9, but then that breaks the plan of moving to snaps, which will all be built with gcc5 ABI, too
<infinity> I don't think reverting gcc is remotely sane, no.
<infinity> But I still can't grasp why framework versions don't cover this.
<pitti> well, that's what we effectively do, just with dragging along a whole release in addition
<pitti> with triple landing, the overlay just turns into vivid with g++4.9 over time..
<pitti> err, "into yakkety"
<dobey> infinity: well, they sort of do. it just means we wouldn't have any framework versions on 16.04, and so no apps will be installable from the store
<seb128> pitti, reverting the ABi in a xenial ppa doesn't solve the problem though, it just move it to the next upgrade and make us get more clicks built against an abi we are trying to move away from
<dobey> it basically forces all developers to repackage their apps at that point
<dobey> if frameworks were chroots that provide ABI or something, sure, but that's not how they are
<pitti> it seems easier to me to maintain gcc-4.9 in x/y than the whole of vivid, but *shrug*
<pitti> I guess the root problem is indeed the lack of an upgrade path for apps
<dobey> pitti: for values of the phone images, those two statements are roughly equivalent
<dobey> and there are no plans to build phone images off yakkety at all, ever, afaik
<pitti> right, and they shouldn't be -- but xenial for sure
<seb128> pitti, right, but xenial might move to arm64 or new android and they want to do one transition in that case and not do one for gcc and then another for a new arch
<dobey> pitti: but "maintain xenial for the phone" and "maintain vivid for the phone" are pretty much equivalent, if we're rebuilding all the bits of xenial with 4.9 ABI in the PPA; probably worse because then we have to deal with conflicts against the gcc5 versions in the upstream archive
<pitti> dobey: ask tedg about fun with too old cmake :) and we have to keep a whole lot of infra running for it too, like ddebs or autopkgtests
<infinity> dobey: Sure, I get that it would force an app update, but our store isn't that amazingly populous, is it?  Can we not reach out and JFDI?
<dobey> pitti: yes, it sucks. but it is what it is, and we have to deal with it
<dobey> infinity: i don't recall the numbers, and i'm not important enough to make such decisions anyway. i'm sure there's more to it than just the gcc5 break, but the gcc5 break is certainly a big thing.
<tedg> shemgp: Hey, so for GNOME3 you'd probably be better off chatting with desrt. Apparently not in this channel :-) Try #ubuntu-desktop
<shemgp> tedg, thanks.
<infinity> tseliot: Still around?
<infinity> tseliot: I've made an executive decision that, to unblock this kernel, I'll just upload 304-updates with the 4.6 patch.  You can worry about getting rid of *-updates and such in a more stately and well thought-out fashion instead of under pressure.  Deal?
<tseliot> infinity: yes, it's not EOD yet
<tseliot> infinity: as you prefer, I was working on it
<infinity> tseliot: Heh.  S'ok, I'd rather not rush you to do all the removals and transitionals and such.  Take your time.
<infinity> tseliot: I'm uploading the synced 304-updates now. :)
<tseliot> infinity: ok, good
<xnox> is anybody else's sbuild started to fail?
<xnox> gpg: Warning: not using 'Sbuild Signer' as default key: No secret key
<xnox> hence it fails to sign dummy archive Release file =(
<infinity> xnox: In yakkety?
<xnox> infinity, not quite. I think we want to backport http://metadata.ftp-master.debian.org/changelogs//main/s/sbuild/sbuild_0.70.0-1_changelog to xenial
<xnox> because thanks to gpg now gpg2, the sbuild-keys no worky anymore with "xenial host -> yakkety/unstable chroots"
<xnox> unless the ascii armored keys are used as in 0.70
 * xnox upgrades quickly.
<cjwatson> I just moved the contents of /var/lib/sbuild/apt-keys/ out of the way and then all was well
<xnox> ha
<infinity> Oh, and I need to change all my overlays to overlay from overlayfs...
<infinity> La la la.
<pitti> infinity: can we mark wily as obsolete in LP now?
<infinity> pitti: Almost.  Sorry, I keep getting distracted from my kernel cleaning script writing.
<cjwatson> some LP builders are still on wily
<infinity> cjwatson: I don't see why that should matter, LP builders already pull from a PPA.
<infinity> cjwatson: We won't remove it from ftpmaster/archive, just close it.
<cjwatson> if you think we can realistically get kernel security updates in there ...
<infinity> cjwatson: We're not getting kernel security updates regardless of the state of the archive.
<infinity> cjwatson: The kernel team stopped when they were meant to.
<cjwatson> Ah, OK
<infinity> cjwatson: As for the hypothetical "what if we need to update the kernel", PPA should be fine, since we don't boot signed kernels on those instances.
<cjwatson> yeah, this is true
<cjwatson> I really hope somebody figures out why xenial makes those systems very sad though
<infinity> cjwatson: Things seem to be getting worse instead of better.
<infinity> cjwatson: 4.2 was kinda unstable, 4.4 is really vile, 4.6 doesn't boot.
<infinity> cjwatson: So, I assume 4.8 will take your dog out back and shoot it.
<cjwatson> and I don't even have a dog
<infinity> cjwatson: I know, but I couldn't bring myself to s/dog/cat/ in that sentence.
<slangasek> infinity, kees: TB meeting?
<infinity> slangasek: If you insist.
<zequence> infinity: Thanks for updating ubuntustudio-meta. Was actually just about to do it myself.
<infinity> zequence: I did some seed changes to many flavours, and decided to just respin all the metas and see what fell out. :P
<zequence> infinity: Oh, ok. Well, thanks anyway :)
<infinity> zequence: NP.
<sarnold> tedg: ah an explanation :) https://mail.gnome.org/archives/commits-list/2016-May/msg06756.html
<mterry> bdmurray: maliit-framework has ~phablet-team as a bug subscriber.  A team that might make sense for further MIR'd packages too.  Might be worth adding to the package-subscribers script?  Doesn't seem to be a comparable team there, covering Touch in general
<mterry> Or at least the upper levels of touch (there is a phonedations team)
<gb_mks> Hi, IÂ´m looking for some help to fix this bug in Ubuntu 14.04. https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1398569   is this the right place for it?
<ubottu> Launchpad bug 1398569 in schroot (Ubuntu) "overlayfs: handle v3.18 overlay union type" [Medium,Fix released]
<bdmurray> tinoco: Why is bug 1570678 verification-done when there is not testing info re: xenial?
<ubottu> bug 1570678 in percona-cluster (Juju Charms Collection) "mysqld got signal 11 during setting up root password on package installation on ppc64el" [High,Confirmed] https://launchpad.net/bugs/1570678
<tinoco> bdmurray: checking
<tinoco> bdmurray: i've asked final user to verify xenial but he made a comment that he verified - again - trusty..
<tinoco> that is why i got confused, my bad
<tinoco> i'll seek for verification again, no ppc machines for me to test unfortunately
<bdmurray> tinoco: no problem, I wanted to make sure I wasn't missing something
<bdmurray> coreycb: openstack-trove in xenial-proposed still needs bug 1516471 verified fwiw
<ubottu> bug 1516471 in openstack-trove (Ubuntu Wily) "systemd init scripts not setting correct conf file" [High,Triaged] https://launchpad.net/bugs/1516471
<coreycb> bdmurray, ok I'll take a look, thanks
<mterry> Mirv: qtbase5-dev-tools seems to have dropped qdoc in yakkety-proposed.  Is that intentional?
<mterry> Ah, it's now in qttools5-dev-tools
<mwhudson> ups, i guess i need to MIR golang-github-coreos-pkg
<mwhudson> slangasek: can you upload nplan 0.7 for xenial to the snappy-dev ppa?
<mwhudson> slangasek: would it make it any easier for you if i uploaded it to some ppa first? (all i'm doing is dch -D xenial -r 'rebuild for Xenial')
<slangasek> mwhudson: please go ahead and upload it to the ubuntu-image ppa, then I'll just copy-package it
<mwhudson> slangasek: ok, done
<slangasek> mwhudson: and copied
<mwhudson> slangasek: thanks
<jbicha> Laney: what am I supposed to do with this? aptdaemon stuff http://paste.debian.net/789960/
<infinity> jbicha: Hrm, would be nice is packagekit was being pulled in there by apt. :/
<infinity> s/is/if/
<jbicha> infinity: ok, I'll add pk to ubuntu-gnome-desktop for today
<infinity> jbicha: It's already in the task.  But maybe it needs to be an explicit dep of the meta to smooth the transition, indeed.
<infinity> If so, gnome won't be the only one with that problem.
<infinity> And maybe it belongs in desktop-common.
<jbicha> or I can let you take care of it :)
<infinity> Heh.
<infinity> Yeah.
<infinity> Lemme double check that it's in all desktops (I think it is now), and then add it to desktop-common and respin all the metas *again*.
<infinity> Whee.
<jbicha> that's the problem, you speak up and try to be helpful and then you end up with *more* work to do
<infinity> That's my life in a nutshell, yep.
<infinity> In this case, though, it's almost zero effort for me, just CPU time.
<infinity> The loop to update all the metas is still in my bash history. :P
#ubuntu-devel 2016-08-17
<kulyzu> $ cat -         # what does it mean
<Mirv> mterry: yes, moved tp qttools
<pitti> Good morning
<pitti> infinity, doko: hmm, seems the rebuilds of apitrace & friends didn't help, still on update_output.txt?
<pitti> installing them does work in a -proposed schroot, so not sure what britney complains about
<pitti> doko: python3-talloc{,-dev} is NBS, and python3-ldb has no reverse dependencies; would it be ok to drop the p3-ldb packages again?
<infinity> pitti: Erm, "didn't help" how?
<pitti> infinity: glibc is still held back by these exact packages in output.txt
<infinity> pitti: I told you yesterday that glibc is caught up in the Qt/binutils mess, I'm fixing the kernel to push that through.
<infinity> pitti: You're reading the wrong block.
<pitti> I looked at "trying: glibc"
<infinity> pitti: Yeah, look further. :)
<pitti> oh, in 'Trying easy from autohinter'?
<infinity> pitti: It gets autohinted with apitrace, etc.  And Qt.  And binutils.  And a bazillion other things.  And linux-tools is the only thing holding it back.
<infinity> Which I'm fixing.
<pitti> ah, ok; sorry about that then
<pitti> there seem to be about five people in the world who can correctly deciver output.txt, and apparently I'm not yet one of them :)
<infinity> Turns out that specifying the default compiler for the *entire* kernel source tree (including tools) is a total cluster*^#%, so it's taken a bit longer than expected to fix a thing here. ;)
<infinity> I think I have it, though.
<infinity> Just one more test.
<infinity> Then an upload.
<infinity> Then profit.
<pitti> indeed; building against a newer linux-libc-dev is fair enough, but that oughtn't result in changed binary deps?
<infinity> Then maybe some upstream fixes. >:(
<infinity> pitti: No, no.  perf depends on binutils for libbfd.  That's not what I'm "fixing".
<infinity> What I'm fixing is making linux-4.4 buildable in yakkety, so I can delete 4.6, insert a 4.4 rebuilt against binutils 2.27, migrate the mess, then copy 4.6 back into proposed.
<infinity> Because we can't migrate 4.6, as hard as I tried, due to it being unbootable on arm64.
<infinity> Grr.
<infinity> And, it turns out, that while you'd think that setting "CC=gcc-5" would do a useful thing (and it mostly does), it completely breaks a few makefiles.
<infinity> Which I see upstream patches for in my future.
<infinity> Because eff that.
<infinity> And that concludes today's lecture on why Adam hates all upstreams.
 * pitti knocks on the bench
<Odd_Bloke> semiosis: o/ Do you have time to work on https://bugs.launchpad.net/cloud-images/+bug/1605795?  (Specifically, we need to generate a debdiff for the changes needed to xenial and attach it to the bug. :)
<ubottu> Launchpad bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,Confirmed]
<infinity> Odd_Bloke: Ahh, crap, I was going to do some backporting of all of that.
<infinity> Odd_Bloke: We really should pull more fixes to xenial than just that one.
<Odd_Bloke> infinity: Aha, so there _was_ a reason I thought I could get gaughen to bug slangasek about that bug. :p
<tseliot> pitti: hey, can you push your last changes to u-d-c, please? I still see the package as unreleased in git
 * tseliot -> lunch
<pitti> tseliot: whoops, sorry; done
<kdub> pitti, have some automated tests that have been running for quite a long time here https://requests.ci-train.ubuntu.com/static/britney/ticket-1654/landing-036-xenial/excuses.html, but they arent listed as running on http://autopkgtest.ubuntu.com/running.shtml, any ideas?
<pitti> kdub: kicked those
<kdub> thanks pitti
<tseliot> pitti: thanks!
<coreycb> bdmurray, I've verified bug 1516471
<ubottu> bug 1516471 in openstack-trove (Ubuntu Wily) "systemd init scripts not setting correct conf file" [High,Triaged] https://launchpad.net/bugs/1516471
<kdub> pitti, do you think it would worthwhile to re-kick the yakkety builds? they seem to have that 'testbed out of date' problem. (last time that happened, I had to just forward the silo to QA testing)
<kdub> https://requests.ci-train.ubuntu.com/static/britney/ticket-1654/landing-036-yakkety/excuses.html
<kdub> the xenial tests passed after the re-kicking there
<pitti> kdub: they are uninstallable; presumably they need to run against all of -proposed, there's a horrible amount of stuff stuck in -proposed right now
<pitti> kdub: done
<kdub> pitti, yeah, chatted with jibel and got it bumped to the qa queue, so hopefully in the clear
<kdub> thanks again for the help
 * xnox 's head is spinning with not declared in this scope, only a friend here </3 c++
<pitti> mdeslaur: last week during my holidays there were two postgresql CVEs; are these already in the pipeline, or need me to prep updates?
<mdeslaur> pitti: oh! didn't notice...could you prepare them?
<pitti> mdeslaur: ack
<mdeslaur> pitti: thanks! :)
<pitti> mdeslaur: I'm creating tracking bug 1614113 (still need to clean up tasks)
<ubottu> bug 1614113 in postgresql-9.5 (Ubuntu Yakkety) "New upstream microreleases 9.1.23, 9.3.14, 9.5.4" [Undecided,New] https://launchpad.net/bugs/1614113
<flexiondotorg> Laney, I need to submit a few MATE package for rebuilds for GTK 3.20.
<flexiondotorg> Some MATE packages have build time rules for 3.20 and all MATE packages in the archive were built against 3.18.
<flexiondotorg> What is the correct version suffix for a rebuild, with no other changes?
<jbicha> flexiondotorg: run dch -R
<flexiondotorg> jbicha, ty
<infinity> flexiondotorg: (The rule is "append buildN starting at N=1 for versions without an ubuntuN suffix, else increment ubuntu suffix, but as jbicha points out, dch -R gets it right)
<flexiondotorg> infinity, Thanks. Understood. Rebuilds uploading.
<pitti> mdeslaur: all done
<mdeslaur> thanks pitti! much appreciated
<infinity> pitti: Okay, kernel mess finally on its way into proposed.  Hopefully the perfect transition state isn't perturbed in the next hour or so. :P
<pitti> ok, everybody hands off the archive!
<pitti> infinity: thanks muchly!
<infinity> pitti: I'm going to check enough autopkgtests to make sure a reboot smoketest is fine, and then let it in, based on the lack of code changes.
<pitti> infinity: agreed, was just going to propose that
<pitti> infinity: I would then flush the glibc requests from the queues after a few dozen tests
<infinity> s/glibc/linux-meta/ ?
<pitti> infinity: oh, I thought glibc; there  aren't that many linux tests
<infinity> Nope.
<infinity> THough its own self test takes forever, and I won't be waiting on that.
<pitti> the three expensive ones are glibc, binutils, and linux itself; the dkms ones are laughable
<infinity> Just going to look at some of the fast ones and make sure they indeed install and reboot into the new kernel.
<pitti> infinity: shouldn't take *that* long really -- linux doesn't rebuild itself for testing itself
<infinity> The qrt suite takes ages.
<pitti> but then again linux' tests have been broken for months, so they'll fail anyway
<pitti> I wish they would get fixed at some point -- not learning about kernel regressions although we could is a bit of a bummer
<infinity> They get examined by hand on a more granular level.
<pitti> anyway, nothing for me to steer manually for linux
<infinity> But a green baseline would make that waste of time unnecessary.
<infinity> And everyone knows it.
<semiosis> Odd_Bloke: yes i'll work on it today
<Odd_Bloke> semiosis: infinity said he might also look at it, so check with him.
<semiosis> Odd_Bloke: to be clear, the goal is to take the xenial branch of livecd-rootfs, apply the needed changes, then generate a diff (debdiff) to attach to bug 1605795
<ubottu> bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,Confirmed] https://launchpad.net/bugs/1605795
<semiosis> Odd_Bloke: infinity: let me know how I can help.  i'll hold off until you confirm if you need anything from me.
 * xnox qpid-receive.cpp:135:27: error: no match for 'operator<<' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'std::ostringstream {aka std::__cxx11::basic_ostringstream<char>}')
<nacc_> rbasak: around? not urgent
<gaughen> semiosis, I wouldn't hold off. I'd do the backport and get it already for SRU. I don't want to block on infinity as he's a busy guy and I'd like to get the change sin.
<mterry> bdmurray: i just filed https://code.launchpad.net/~mterry/ubuntu-archive-tools/phablet-teams/+merge/303163 based on recent MIR feedback from teams
<gaughen> semiosis, so have at it!
<nacc> arges: if not all the upstream bits (re: LP: #1490611) apply to the 16.04 source, is it sufficient to just note that? That's why there is a difference in the qem2 changes backported.
<ubottu> Launchpad bug 1490611 in qemu (Ubuntu Xenial) "Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid" [Medium,In progress] https://launchpad.net/bugs/1490611
<arges> nacc: ok good to know. Yea that's useful info to put into the patch description
<nacc> arges: ack, updating now, thanks for noticing that!
<arges> so the next person who looks at this and wonders why it doesn't match the upstream commit can see why
<nacc> barry: thanks for the wiki updates!
<nacc> barry: fyi, i did see one i wanted to ask about -- the -d option should work with an appropriate directory (i use it to pick up a failed import, e.g., and to continue after fixing the importer). I think I should add some defensive checks that the specified directory is of the format I expect (or empty).
<barry> nacc: hey! hi!  yw.  i was going to ping you to discuss a few other things i ran into, but i saved it in an ephemeral file and lost my notes ;)
<barry> nacc: yes, i think that would help.  relative paths should also be allowed i think (unless there are specific technical reasons why it can't)
<nacc> barry: yep, probably just oversite on my part, or using the wrong API
<nacc> err, oversight
<nacc> barry: could you file a bug for that? https://bugs.launchpad.net/usd-importer
<barry> nacc: the other thing is that the job of deconstructing and reconstructing the patches is rather complex and does involve some esoteric git knowledge.  that's okay, since the tool does assume up front that you know a fair bit about git, but i also feel like for drive-by mergers, the steps involved won't be committed to muscle memory.  that means (maybe) a quick cheat sheet would be helpful in addition to the detailed docs on the wiki
<barry> page
<barry> nacc: +1
<nacc> barry: yep, that is on my todo
<barry> nacc: but overall, it made my merge of claws-mail much nicer than mom (which i've used every time before now).  otoh, claws-mail only has a fairly simple delta over debian.  still, win!  thanks for all the great work on this tool
<barry> nacc: LP: #1614189
<ubottu> Launchpad bug 1614189 in usd-importer "-d directory improvements" [Undecided,New] https://launchpad.net/bugs/1614189
<nacc> barry: thanks!
<rbasak> nacc: o/
<rbasak> nacc: also, I started importing claws-mail for barry
<barry> rbasak: thanks!
<nacc> rbasak: heya, just wanted to touch base with you re: https://answers.launchpad.net/launchpad/+question/326278
<nacc> rbasak: basically, it seems like we shouldn't rely on a version only being published once in a given series (meaning we need to be able to distinguish by more than series/pocket/version :/
<nacc> rbasak: also, i think i mentioned this to you briefly before i was on vac, but i think we want to remove the hardstop in the importer on versions going backward and just trust the publication history? basically http://paste.ubuntu.com/23065299/
<rbasak> nacc: the tree should still be identical though, right?
<nacc> rbasak: the tree is identical, but it's history is not
<nacc> rbasak: the publishing history, that is
<rbasak> nacc: if, in the case of this happening, we make an empty commit with the correct tree, would that cause problems?
<nacc> rbasak: well, the tricky part right now is detecting that it is happening :)
<rbasak> nacc: isn't it the same case that (import|upload)/<version> exists?
<nacc> rbasak: do you have time for a hangout? sorry, i know it's late there
<rbasak> Let me check.
<nacc> rbasak: sorry, just hard to type fast enough to explain what i ran into :)
<nacc> rbasak: we can also chat tmrw AM
<rbasak> nacc: dinner will be ready in five minutes. Maybe afterwards?
<rbasak> I'll ping you.
<nacc> rbasak: sure, like i said, we can also talk tomorrow, don't want to interfere with your evening
<rbasak> After Denver my body hasn't yet understood what evening means again :-)
<nacc> rbasak: ah i can only imagine :)
<tgm4883> Can someone take a look at this? https://bugs.launchpad.net/ubuntu/+source/mythbuntu-default-settings/+bug/1613122 I've got a package in proposed waiting on this and not sure what happens with packages in proposed after feature freeze
<jbicha> tgm4883: don't worry, if it's in -proposed, it's considered "in" before feature freeze
<tgm4883> jbicha: ah cool. Thanks
<ubottu> Launchpad bug 1613122 in mythbuntu-default-settings (Ubuntu) "Move ubuntu-bare into multiverse" [Undecided,New]
#ubuntu-devel 2016-08-18
<nacc> rbasak: i think i got ubuntu/devel working :)
<rbasak> \o/
<nacc> rbasak: will talk w/ you in the am on it, i think i got barry's bug fixed too, as well as the isc-dhcp import
<rbasak> Great!
<pitti> Good morning
<infinity> pitti: Morning.
<infinity> pitti: Kernel attempt number 2 in progress.  Turns out that changing CC in the top level Makefile blows up dksm. :/
<infinity> dkms, too.
<infinity> Qt will migrate today if I have to jam it in with a fork.
 * pitti hands infinity some lube too
<sarnold> don't force it, get a bigger hammer
<infinity> pitti: Witness the horror: http://paste.ubuntu.com/23066399/
<infinity> export SHELL=env PATH=$(PWD)/debian/compiler:$(PATH) /bin/bash -e
 * infinity shudders.
<pitti> that's a curious ABI bump
<pitti> 9034 â 9134?
<infinity> pitti: 34.53 matches the xenial source.
<pitti> using gcc 6 instead of 5 changes ABI?
<infinity> pitti: 90/91 was me making the ABI not clash with xenial.
<pitti> ln -s /usr/bin/gcc-5 debian/compiler/gcc
<pitti> elegant! *cough*
<infinity> pitti: No, not actually an ABI change, but ABI == package name, they have to be unique these days for other reasons (signed modules, for one)
<infinity> The days of ABI tracking are dead.  Unless we move to using a central signing key for modules.
<infinity> But for now, because of the baked in ephemeral key, every kernel needs to be a unique "abi".
<infinity> pitti: And yes, "elegant". :P
<infinity> pitti: Though, I might clean it up and propose something similar but more robust for compiler switching.  Specifying CC breaks some of upstream's Makefiles (a joyous bug I won't bother hunting down), and changing CC in the top level Makefile breaks installed kbuild (ie: dkms), so...
<pitti> sergiusens: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapcraftÂ test fails
<Unit193> pitti: BTW, with upstart user sessions, dbus-launh would launch an application in a new session or something such that the new application was unaware of other applications.  With the new systemd/dbus-user-session, that and unsetting DBUS_SESSION_BUS_ADDRESS no longer work.  Do you know how I can do this?
<pitti> Unit193: that's not the same -- dbus-launch starts a new (local) bus and sets D_S_B_A to *that* address; that should continue to work as before
<pitti> Unit193: *unsetting* D_S_B_A will just make applications use the builtin $XDG_RUNTIME_DIR/bus default
<Unit193> Hrm, neither are working now as a workaround.
<pitti> neither of this is a function of how you start the session -- most probably this changed with installing dbus-user-session
<Unit193> I figured it was from dbus-user-session, aye.  But clearly I don't know dbus magic. :)
<pitti> what are you tryign to do?
<Unit193> There's a workaround to get dropbox to show up correctly, but it's to force it out of indicator-application and use its trayicon, otherwise you get an IMAGENOTFOUND icon and a non-functioning menu.
<pitti> Unit193: and "DBUS_SESSION_BUS_ADDRESS=invalid dropbox" doesn't work? I tried "dbus-launch --exit-with-session d-feet" and that runs in its own private session bus world as expected
<Unit193> pitti: Correct.
<pitti> I figure actually launching a new bus is moot as dropbox then can't communicate with anything else anyway -- so just using an invalid address is simpler
<Unit193> pitti: Eh, I'll just nuke XDG_RUNTIME_DIR for now instead I guess.
<pitti> Unit193: that's much worse, but if you know what you are doing, sure :)
<Unit193> pitti: Dropbox is entirely weird, it has /usr/bin/dropbox, which launches ~/.dropbox-dist/dropboxd, which launches another script, which finally launches the actual process.  If I set the env in the uppermost script, I should still get a functional dropbox without breaking too much, I'd think.
<pitti> cjwatson: FYI, I just committed http://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/revision/171 to ignore wily as a supported release; this should hopefully stop the cron spam
<pitti> (not sure why it can't be marked as obsolete yet, but I suppose there are reasons)
<infinity> pitti: There's a reason, it's just my TODO list being too long, and some things I need to clean up before I disable it.
<infinity> pitti: Sorry it was causing backscatter.
<pitti> infinity: no problem, it's an easy enough workaround
<pitti> cjwatson, infinity: is there some way to find out what pulls p3-lp into standard now? http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
<pitti> this will affect containers as well, and might not be intended
<pitti> oh, I think update-manager-core (in standard seed) â python3-update-manager â python3-launchpadlib
<pitti> but python-launchpadlib has been optional forever, even in xenial
<pitti> ok, that came from http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz
<pitti> "Attempt to retrieve Changelogs from PPA sources"
<tsdgeos> is libreoffice-writer crashing in yakkety for anyone else?
<jibel> doko, hey, could you help with bug 1613602 to understand where the problem is, if it's libc or something else?
<ubottu> bug 1613602 in Canonical System Image "repowerd crashes on xenial/arm64" [Critical,New] https://launchpad.net/bugs/1613602
<jibel> doko, alf and vicamo can provide more info if needed
<mwhudson> how do i see the default gcc flags? (i.e. the place where pie got turned on for s390x in 16.04)
<juliank> I feel like the arm64 build is going weird, it's printing "INFO: pkgstripfiles: waiting for lock (apt-transport-https) ..."  since a minute or so https://launchpad.net/ubuntu/+source/apt/1.3~rc2ubuntu1/+build/10631459
<brendand> has anyone been using the nose-subunit plugin successfully recently? my attempts to install it have been underwhelming
<juliank> I guess I'll restart the build and hope for more luck this time
<juliank> Hmm, now it's cancelling stuff since a minute or so
<juliank> well, seems to have been cancelled. retrying now. let's hope it works better this time ...
<doko> jibel: glibc should be infinity's expertise. but I can have a look tomorrow
<doko> mwhudson, compile and link a helloworld.c with -v and look for the flags
<xnox> mwhudson, PIE is on by default in the toolchain for s390x in 16.04, in 16.10 it's also on for amd64 and ppc64el.
<doko> ahh, yes, we even have a wiki page documenting these ...
<mwhudson> xnox, doko: context is https://github.com/golang/go/issues/16780
<mwhudson> which i think roughly speaking means "-fdebug-prefix-map doesn't work"
<mwhudson> but only on s390x!
<mwhudson> which makes no sense
<jibel> infinity, any insight on bug 1613602?
<ubottu> bug 1613602 in Canonical System Image "repowerd crashes on xenial/arm64" [Critical,New] https://launchpad.net/bugs/1613602
<infinity> jibel: Nothing immediately leaps to mind.
<infinity> jibel: I can look more $later, but not sure precisely when $later will be.
<infinity> Laney: The default gedit colour scheme has a transparent background.  That can't be right. :P
<jibel> infinity, that's fine as long as later != infinity
<infinity> jibel: infinity would be an awful result indeed.  The last thing I want to do is examine the same bug at every point in time.
<infinity> Maybe that's what hell is.
<Laney> infinity: Not seen that, will check on an iso or something later
<infinity> Laney: I thought it might be a bad local mapping of old setting or something, but if you go to preferences, colours, and click the schemes/themes (which I would expect would reset any bad settings I have?), they all seem to work fine, but the top one has a transparent window.
<infinity> And the top is, I assume, also the default.  It is here anyway.
<infinity> Laney: Also an entertaining menu re-rendering bug (which I'm guessing is the theme's fault?) where hilighting a menu item makes the menu grow in size slightly...
<Laney> It looks right on a live session :(
<Laney> Yes, that one is known
<infinity> Laney: Hrm.  The gedit thing is fine in live?  Great.  I'll try a fresh profile at some point, but if it's an upgrade bug, that's icky.
<Laney> https://trello.com/c/EXpA6lKW/8-look-into-gtk-3-20
<Laney> Those are my known issues
<infinity> Laney: Handy.  I'll keep that card open and only bug you when something is either not there or listed fixed and clearly not. :)
<Laney> Try gedit in a guest session
<Laney> Maybe something's held back pre-3.20 or whatever
<infinity> Laney: Guest session is fine.
<infinity> Laney: Which implies an upgrade bug.  But I haven't exactly customized gedit or anything.  I only use it for quick throwaway notes.
<Laney> infinity: Meh, keep the bug around and let me see it when we're next in the same place
<xnox> Mirv, i'm getting QT_QT_INCLUDE_DIR set to NOTFOUND building against Qt4 in calligra
<xnox> never mind, i have qt5 installed as well.
<Mirv> ok
<Mirv> calligra is removed from Debian it seems
<xnox> it's not.
<xnox> it's in unstable.
<xnox> but yeah, it is not in a nice state at the moment.
<Mirv> correct, just looking regarding release. it seems there's some 2.9 packaging in there but not finished or touched since 2015.
<Mirv> (I was mostly curious there is still some software using Qt 4 which should be on its way out)
<xnox> ubuntu is on 2.9 series
<xnox> i wonder what happened. I guess libreoffice got better kde/qt integration and people gave up on calligra?
<xnox> it is ex-KOffice, right?
<Mirv> I think Calligra was funded by Nokia until... not anymore, maybe it's been searching for itself a bit and with less resources
<xnox> ah, did not know about nokia funding
<Mirv> so calligra was also more mobile oriented and was running on Nokia N9 as the document viewer
<Mirv> but indeed LO is starting to cover all those corners now
<xnox> anyway, i have an umbigious reference between "half" and "Eigen::half_impl::half" to fix. Silly OpenEXR not using a namespace.
<mdeslaur> slangasek: I'm going to need some help from someone to figure out why libgcrypt20 isn't building on armhf anymore in xenial: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/10628823
<mdeslaur> slangasek: unfortunately, it's an urgent update
<mdeslaur> slangasek: could you please tell me who I can ask?
<ogra_> does anyone else see apparmor hangs in 16.04 upgrades today ?
<ogra_> i see a kernel oops during the apparmor package postinst on two 16.04 machines i upgraded today
<ogra_> involving an uncloseable update-manager too
<ogra_> bug 1614459
<ubottu> bug 1614459 in apparmor (Ubuntu) "daily upgrade on 16.04 hangs" [Undecided,New] https://launchpad.net/bugs/1614459
<infinity> cjwatson: What conclusion did we draw the last time we talked about alignment on armhf on arm64 kernels?
<infinity> cjwatson: Looks like mdeslaur is seeing SIGBUSes in libgcrypt that (presumably) were being fixed up or ignored before. :/
<mdeslaur> infinity: fixed up by what?
<infinity> mdeslaur: Anyhow, short story, gcrypt has alignment bugs.  Long story, it seems our armv7 kernels were fixing those up instead of throwing bus errors, and our arm64 kernels aren't (or can't).
<mdeslaur> oh, huh
<ogra_> SRU team ... see above bug please (havent heard of anyone else who can reproduce it yet, but i have seen it on two machines now)
<jibel> tyhicks, hey, can you have a look at the bug ogra pasted earlier? 1614459 it's a regression in xenial
<infinity> mdeslaur: I'll note that yakkety doesn't seem to have said problem, so finding the commit(s) that fixed the alignment bug(s) might not be too hard.
<mdeslaur> yeah, possibly http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=a6158a01a4d81a5d862e1e0a60bfd6063443311d and http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=1111d311fd6452abd4080d1072c75ddb1b5a3dd1
<mdeslaur> I'll try backporting those
<Mirv> Laney: both http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-ui-toolkit and the -gles would be there now for the --all-proposed run of unity8
<Laney> huh, I thought I did it
<Laney> lemme see
<infinity> mdeslaur: It was probably a mistake for us to ever have kernels that fixed up alignment errors on ARM in the first place, but now here we are.
<infinity> Those traps are super expensive, we were just hurting ourselves by not catching the bugs.
<Laney> Mirv: there we go
<mdeslaur> infinity: thanks for the hint
<Mirv> thanks
<Laney> huh
<Laney> it's disappeared
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/u/unity8/20160818_121007@/log.gz
<cjwatson> infinity: https://bugs.launchpad.net/launchpad-buildd/+bug/1516331
<ubottu> Launchpad bug 1516331 in launchpad-buildd "please set /proc/cpu/alignment=4 on Launchpad ARM buildd kernels" [Undecided,New]
<Mirv> Laney: indeed I still don't see them at http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8
<cjwatson> infinity: Steve explicitly wanted us there to do more raising of SIGBUS, which at the time seemed to be not a thing on arm64 kernels, but maybe that is in fact a thing now, in which case "yay" as far as that bug is concerned
<Laney> Mirv: Some kernel uninstallability, looks like things are publishing out
<infinity> cjwatson: Well, mdeslaur was sigbusing all over the place, so it definitely seems to be a thing.
<infinity> cjwatson: I think what's not a thing is the config that does alignment fixups.  I think.
<infinity> cjwatson: Although, that indeed contradicts the bug comments.  Hrm.
<infinity> cjwatson: Oh!  But your test was an armv8 binary.  mdeslaur's sigbussery was armv7 on arm64.
<infinity> cjwatson: From this, I would conclude that armv8 allows and fixes unaligned access, but v7-on-64 raises a sigbus.  Maybe.
<infinity> Ish.
<cjwatson> Ah, could be.  Either way it's apparently what we wanted for more reliable behaviour with phones.
<infinity> cjwatson: If you can prove the truth of my conclusion, I think you can close Steve's bug as Fix Released By Accident.
<xnox> Mirv, is qml working correctly on powerpc - a harmless test fails to work https://launchpad.net/ubuntu/+source/biometryd/0.0.1+16.10.20160628-0ubuntu3
<caribou> infinity: mdeslaur: I'm working on building statically linked pam-winbind & libnss-winbind as suggested for LP: #1584485
<ubottu> Launchpad bug 1584485 in samba (Ubuntu) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
<caribou> infinity: building them statically brings a bunch of crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' that seems to be fixed by using -static-libgcc
<caribou> infinity: should I just iteratively identify each one that fails & add the flag or there is a more direct approach ?
<Mirv> xnox: no, 32-bit powerpc has problems that are tagged with powerpc https://is.gd/9FnqIR
<infinity> caribou: I'm not sure I have much advice, I don't tend to do much static linking.
<caribou> infinity: well, I'll keep on the iterative approach if the number of modification is small (not many so far)
<infinity> caribou: If you've got the time, I'd recommend trying to do it in a suitably upstreamable way, so the build can just be done with --static-winbind or some such.  We may be the first to notice the problem, but it really should bite anyone.
<infinity> (In fact, I'd suggest that --static-winbind be the default, for that reason)
<caribou> infinity: ok, will keep that in mind once I get something building
<infinity> caribou: Not critical for the SRU or anything, but would be nice to push something upstream so we don't have to maintain a delta, that's all.
<caribou> infinity: should be feasible with some waf hacking
<infinity> caribou: It might be enough to extend the NONSHARED bit in buildtools/wafsamba/samba_deps.py to allow type BINARY and type LIBRARY, and then tweak it a bit, then one can do --nonshared-binary=nss_winbind or some such.
<infinity> caribou: But that's my naive poke ater 5 minutes of grepping. :)
<caribou> infinity: ok will look at that too
<infinity> caribou: How did this end up in your lap? :P
<caribou> infinity: took it over from a colleague
<mdeslaur> caribou: did he quit? I'd consider quitting too if that was on my lap :)
<caribou> mdeslaur: :D
<caribou> mdeslaur: that's how one builds experience in build weirdiness I suppose
<xnox> Mirv, ack. Do you want a bug open about it + upload that skips that one test on powerpc?
<xnox> (fro biometryd)
<infinity> xnox: Looks like they're tacking "skip tests on ppc" bugs on to that master bug as tasks.
 * xnox looks again
<infinity> A one-stop shop to reopen them all after the Qt bug is fixed, I guess.
<tyhicks> ogra_, jibel: the apparmor oops was a known bug that only affected a handlful of people
<tyhicks> ogra_, jibel: unfortunately, the apparmor package SRU is causing it to happen to a lot more people now because the update process triggers a profile reload :/
<tyhicks> ogra_, jibel: I've duped your bug to bug #1579135 - jjohansen has a proposed fix and any testing of the kernel mentioned in comment #27 would be appreciated
<jibel> tyhicks, so what is the plan of action?
<ubottu> bug 1579135 in apparmor (Ubuntu) "AppArmor profile reloading causes an intermittent kernel BUG" [Critical,Incomplete] https://launchpad.net/bugs/1579135
<jibel> tyhicks, okay, thanks
<coreycb> arges, mind rejecting cinder and aodh from the xenial queue? I forgot the bug #.
<arges> coreycb: rejected! *slams basketball*
<coreycb> arges, lol, thanks
<pitti> arges: he'll get the rebound, I'm sure :)
<seb128> happyaron, cyphermox, looks like the network-manager-applet (1.2.0-0ubuntu2) and ubuntu3 uploads didn't get commited to git which made the 1.2.2-0ubuntu1 update revert them/drop them, we really need to sort out the nm vcses and standardize on using them...
<cyphermox> word
<cyphermox> just use git; that's what we agreed on
<cyphermox> for the record, I haven't done an upload of NM in weeks
<seb128> cyphermox, yeah, those you did in may
<seb128> still there are missing from the vcs
<seb128> which makes happyaron's update he handed me for sponsoring today buggy
<seb128> happyaron, can you please fix the vcs tomorrow then I can have another look at uploading it for you
<cyphermox> seb128: the git tree was up to date, I'm not sure what happened for stuff to be missing
<seb128> k
<seb128> let's see with Aron tomorrow
<seb128> cyphermox, thanks
<seb128> I'm sure what happened is "git"
<seb128> :p
<seb128> the best tool to get things screwed up it seems :-/
<cyphermox> no
<cyphermox> tbh it has happened a couple of times that people forget to commit or whatever
<seb128> yeah, but you said that it was uptodate
<seb128> so it means somebody rewrote the commit history or something
<cyphermox> I think it's counter-productive to try to figure out who did what and where
<cyphermox> aron will fix the git tree, things will be good
<seb128> yeah, that was mostly joking
<seb128> I just wanted to make sure everybody was syncing up on using the same vcs
<cyphermox> yes
<seb128> seems you guys are
<seb128> so it's good
<seb128> cyphermox, thanks
<cyphermox> np
<Mirv> Laney: rerunning autopkgtests with --all-proposed still broken?
<Laney> Mirv: nope
<Laney> i386 done, amd64 nearly
 * Mirv finds the correct entry on the running page
<Mirv> i386 was a pass, and seems amd64 too (qmluitests pass just visible on the running page)
<Laney> Mirv: can you find out why the disabling didn't work and fix it please?
<Mirv> Laney: yes, robru should be online now
<Laney> â¥
<juliank> How can I check what translation stuff was exported during the apt build? A tarball is generated, but it's not accessible; and the translation import queue does not have it either.
 * juliank is wondering if launchpad exporting/importing of apt translation domains now works
<nacc> powersj: nice find on LP: #1613982, I just reviewed and rejected it :)
<ubottu> Launchpad bug 1613982 in php-defaults (Ubuntu) "Date parsing has been fixed in 14.04, but broken in 16.04 again" [Undecided,Invalid] https://launchpad.net/bugs/1613982
<powersj> nacc, thanks :)
<Unit193> nacc: BTW, I think it's very cool that you're an active developer that keeps an eye out in #ubuntu too.  Thanks.
<nacc> Unit193: thanks! i try to be -- always hard with time constraints, though :)
<nacc> luckily i'm mostly working on release stuff, so people's complaints tend to be relevant :)
#ubuntu-devel 2016-08-19
<pitti> Good morning
<pitti> Laney, infinity: I just installed firefox from -proposed and scrollbars are back, thanks!
<zzarr> hello! I'm trying to play a mp3 file in a project built with Qt 5.7 but it says that it's missing a plugin for gstreamer
<zzarr> I'm on Ubuntu 16.04
<Mirv> zzarr: you'll most likely indeed lack a plugin, as mp3 is patent encumbered format. for example gstreamer1.0-fluendo-mp3 package has a licensed decoder.
<zzarr> thanks Mirv
<zzarr> Mirv it's already the latest
<Mirv> hmm then I don't know
<xnox> something odd is going on. packages that just build in local yakkety sbuild fail on launchpad.
 * xnox rebuilds my chroots
<happyaron> seb128: need to work on that on Monday, hands were full today...
<Mirv> does anyone else have hanging builds in LP? https://launchpad.net/~canonical-qt5-edgers/+archive/ubuntu/qt5-beta2/+build/10632384 at the end of the build
<Mirv> I've had one since yesterday, and still happens
<cjwatson> can happen if you leave test processes hanging around
<cjwatson> just cancel it
<Mirv> ok
<seb128> happyaron, shrug, ok, always a reason to delay those :-/
<happyaron> seb128: hey, appears most fixes were included for the 1.2.2 version, but the wwan icon patch has something not upstreamed, thus not picked...
<happyaron> cyphermox: ^
<jbicha> mdeslaur: are you planning to use gnupg1 soon instead of gnupg like Debian did?
<jbicha> because I saw you merged gnupg 1.4.20-6 but not gnupg1 1.4.20-7
<mdeslaur> jbicha: huh, wasn't aware of that
<jbicha> mdeslaur: https://debian-administration.org/users/dkg/weblog/116
<mdeslaur> gnupg1 is in yakkety already
<jbicha> yes but it's in universe and the gnupg source package should probably be removed if we're going to follow Debian's example for yakkety
<mdeslaur> yeah, someone who cares can do that
<mdeslaur> doesn't look like they've actually replaces gnupg though
<mdeslaur> (yet)
<jbicha> well except for providing transitional packages and removing the old source I think they have https://anonscm.debian.org/git/pkg-gnupg/gnupg1.git/tree/debian/control
<xnox> mdeslaur, well it needs gnupg2 merge
<xnox> and on debian it is claimed to break things (the RC bug report)
<xnox> i would want to for this to happen, but I am biased.
<xnox> Laney, shall we try to squeeze in gnupg2 by default?
<xnox> and see how much stuff breaks?
<xnox> i think the rest of stuff is merged / working by now......
<jbicha> well a transitional package would help with some of the breakage
<pitti> oh, please let's move to gpg2, this is overdue
<Laney> xnox: abstain
<ricotz> pitti, +1
<xnox> i shall file FFe request
<xnox> https://bugs.launchpad.net/ubuntu/+source/gnupg1/+bug/1615039
<ubottu> Launchpad bug 1615039 in gnupg2 (Ubuntu) "[FFe] /usr/bin/gnupg --version should be 2.1" [Undecided,New]
* Laney changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | 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:
<mdeslaur> xnox, jbicha: I don't mind helping a bit with the gpg transition, but I don't have time to properly take care of it
<mdeslaur> xnox: thanks for volunteering :)
<mdeslaur> xnox: let me know if there's something you'd like me to do
<jbicha> mdeslaur: I thought *you* volunteered by touching gnupg last!
<mdeslaur> see, the problem with that is the security team touches everything last :)
<mdeslaur> xnox: I can merge our stuff into the gnupg1 package if you'd like
<xnox> mdeslaur, i'm punting this till next week. cause i do want to make it happen, but it needs to be done right. And i can't just toss it over the wall on friday evening =)
<xnox> i'm sure some things will break and/or need testing - e.g. user session gpg-agent and the like.
<mdeslaur> xnox: ok, just let me know
<jbicha> yeah, maybe after Beta
<rbasak> barry: you might be interested in bug 1613880. We can't be sure, but it sounds like he changed /usr/bin/python to point to python3.5. I wonder if there's a way for apport to tell us for sure, so we can explain and Invalidate these bugs immediately?
<ubottu> bug 1613880 in six (Ubuntu) "package python-six 1.10.0-3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1613880
<pitti> rbasak: Dependencies: should tell, but that field is empty (!?)
<barry> rbasak: looking
<rbasak> Not urgent at all - just pondering the bigger picture. Maybe these are rare.
<pitti> i. e. apport mentions modified files in packages, i. e. it should have told us that python-minimal has a modified /usr/bin/python
<barry> rbasak: changing /usr/bin/python is definitely not a supported option on ubuntu (or debian) so we should detect that and exit
<rbasak> barry: would you like a bug for that somewhere?
<barry> rbasak: i think it should be rare, and it's something that someone would have to go out of their way to do.  or i suppose they could have installed python3.5 from source into /usr/local/bin and made that first on their $PATH?  in any case, i think we can just handle this on a case-by-case basis.  pitti what do you think?
<pitti> barry: yeah, WFM; I'm mostly interested in why this bug has an empty Dependencies: field
<barry> pitti: yeah ;)
<pitti> barry: oh -- apport is python too, it wouldn't surprise me if that was broken by that change
<barry> patient: "dr. it hurts when i do this".  doctor: "don't do that!"
<pitti> well, Friday evening, debugging a weird regression, and that ^ isn't a "want to think about it" problem right now, sorry
<barry> not likely to change over a nice weekend :)
<rbasak> I just thought it was interesting that 1) someone did that and then reported a bug; but also 2) apport didn't tell me why. But that he broke apport itself by doing that is interesting. Also ironic that he reported it against python-six!
<ahoneybun> anyone know if we can expect a startup sound change?
#ubuntu-devel 2016-08-21
<joefox> Hi. Can someone tell me how /etc/ files are generated during ubuntu installation? I want to know if I want to change some seetings for a live-cd for example, how would I do that?
<brendand> anyone know what this usually means?:
<brendand> adt-virt-qemu: DBG:  +>?
<brendand> tar: Unexpected EOF in archive
<brendand> tar: Unexpected EOF in archive
<brendand> in autopkgtest
#ubuntu-devel 2017-08-14
<xnox> LocutusOfBorg, well you say sad installing udev, but i am failing to reproduce that sad.
<xnox> where do you see it?
<LocutusOfBorg> xnox, grep on excuses page for "unknown: armhf: Regression"
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/k/kdelibs4support/20170814_043223_736a3@/log.gz
<LocutusOfBorg> retrying them over and over again usually works
<LocutusOfBorg> addgroup: The group `input' already exists as a system group. Exiting.
<LocutusOfBorg> Job for systemd-udevd.service failed because the control process exited with error code.
<LocutusOfBorg> See "systemctl  status systemd-udevd.service" and "journalctl  -xe" for details.
<LocutusOfBorg> dpkg: error processing package udev (--configure):
<LocutusOfBorg> the issue should be "Aug 14 07:32:34 autopkgtest-lxd-dstsak systemd-udevd[1380]: inotify_init failed: Too many open files
<LocutusOfBorg> "
<xnox> i think this means the host is hosed =/
<xnox> Laney, what is the inotify max_user_instances limit on armhf hosts? https://github.com/moby/moby/issues/1044
<xnox> and can the sysctl be bumped? e.g. sysctl -w fs.inotify.max_user_instances=8192 via a drop-in or some such
<xnox> hm... but lxd has it bumped.
<xnox> https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1602192
<ubottu> Launchpad bug 1602192 in lxd (Ubuntu) "when starting many LXD containers, they start failing to boot with "Too many open files"" [Undecided,Fix released]
<LocutusOfBorg> is it fixed for zesty but we need the fix in xenial? which lxd version are using autopkgtests servers?
<acheronuk> ah. was just going to ask about that dbus issue on armhf tests. thx
<ejat> what is the best way to remove unity from 17.10 ?
<ejat> http://paste.ubuntu.com/25311633/
<mitya57> Most qtbase autopkgtests are fixed now, thanks LocutusOfBorg, acheronuk or whoever took care of them :)
<LocutusOfBorg> thanks acheronuk I did mostly nothing :)
<mitya57> Now we âjustâ need to remove ubuntu-ui-toolkit.
<acheronuk> np :)
<mitya57> (or fix it, if someone still cares about it)
<LocutusOfBorg> sad me the new qtwebengine or whatever breaks geary :(
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/geary/0.12~20170613-0ubuntu5
<mitya57> That looks like GTK's webkit, not Qt's webengine :)
<LocutusOfBorg> you right thanks
<LocutusOfBorg> jbicha, I blame you then for the libwebkit2gtk-4.0-37 bad library :)
<LocutusOfBorg> ricotz, can you please  merge the geary patch upstream?
<ricotz> LocutusOfBorg, which patch, although I am not geary upstream
<LocutusOfBorg> this patch fixes the build https://git.gnome.org/browse/geary/commit/?id=1d0aac1dfe461bf731b022381f179c0f48923834
<LocutusOfBorg> hurray!
<ricotz> LocutusOfBorg, haha
<LocutusOfBorg> ricotz, this patch http://launchpadlibrarian.net/332741065/geary_0.12~20170613-0ubuntu3_0.12~20170613-0ubuntu4.diff.gz
<LocutusOfBorg> I'm going to upload a new snapshot then
<ricotz> LocutusOfBorg, this only happens on s390x?
<LocutusOfBorg> yes, not sure why
<LocutusOfBorg> :(
<LocutusOfBorg> this is the failure https://launchpad.net/ubuntu/+source/geary/0.12~20170613-0ubuntu3
<ricotz> LocutusOfBorg, did you compare the webkit girs with e.g. amd64?
<LocutusOfBorg> (BTW I don't know about this patch)
<LocutusOfBorg> ricotz, I did zero debug, I don't know such things
<ricotz> I see
<ricotz> likely a gobject-introspection problem
<LocutusOfBorg> fwiw it now builds, and I'm happy with gmime transition going to an end, sorry for not being too helpful, I just found you as author of the commit fixing the issue :p
<ricotz> LocutusOfBorg, I see
<ricotz> LocutusOfBorg, your s390x build fix looks wrong and might result in a double-free
<ricotz> LocutusOfBorg, could you try to drop your patch and disable debhelpers parallel building?
<Laney> xnox: can you remind me on wednesday please?
<jdstrand> tyhicks, sbeattie: fyi, I'll take bug #1710487. I need to check snapd for that anyway
<ubottu> bug 1710487 in apparmor (Ubuntu) "evince silently crashes with apparmor error on artful" [High,Confirmed] https://launchpad.net/bugs/1710487
<tyhicks> thanks jdstrand
<sbeattie> jdstrand: thanks
<tsimonq2> rbasak: Hey there! Could I get a bump on looking at bug 1133477? :)
<ubottu> bug 1133477 in gvfs (Ubuntu Xenial) "[SRU] cut-n-paste move files got stuck forever" [Critical,Fix committed] https://launchpad.net/bugs/1133477
<jbicha> LocutusOfBorg: I'd like to remove (old) webkitgtk from Ubuntu soon, maybe before 17.10's release
<jbicha> current status (except for boinc) at LP: #1710318
<ubottu> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
<rbasak> tsimonq2: I appreciate the ping. I'm not sure I'm going to get time to hit it this week though :-/
<rbasak> tsimonq2: I'd be happy for someone else to take over if someone else is available.
<rbasak> tsimonq2: otherwise I will try and do it - I'm just trying to be realistic.
<tsimonq2> rbasak: Sure, I just don't know who else to ping :P
<rbasak> tsimonq2: anyone in ~ubuntu-sru
<rbasak> tsimonq2: RAOF is in rotation today, though I don't see him online right now.
<tsimonq2> rbasak: Ok. Yeah, I think he's in Australia, I'll catch him this evening maybe.
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<rbasak> !dmb-ping
<acheronuk> even the bot doesn't want to do it!
<tsimonq2> oh snap :P
<mwhudson> does anyone know what's going on with http://autopkgtest.ubuntu.com/running#pkg-ubuntu-make
<mwhudson> it says it's been running for an hour but i'm preeeety sure it said that 8 hours ago
#ubuntu-devel 2017-08-15
<mwhudson> having chided people about forgetting to use mere-buildpackage etc i have of course forgotten to use it myself today
<karstensrage> if i have my own package that im working on, can i put it in the list so another library can find it during autoconf ./configure
<LocutusOfBorg> jbicha, I don't think boinc will be able to switch to something different :/
<LocutusOfBorg> at least not now
<blaze> hello. package libsidplay2v5 was replaced by libsidplay2 but there are still some packages depenging on the 2v5
<acheronuk> chrisccoulson: hi. not a moan in the slightest, but a few forum and other places are asking why no Firefox 55 stable updates have been pushed yet. is there a reason I can give?
<acheronuk> oh, there was a 55.0.1 update. that probably delays things a bit
<chrisccoulson> acheronuk, yes, it's because there was a 55.0.1 update, and we don't do updates on fridays generally
<chrisccoulson> and then I found a crash that needed a rebuild
<acheronuk> chrisccoulson: makes sense. thanks :)
<ahasenack> apw: hey, around?
<ahasenack> sru-related
<apw> ahasenack, possibly
<ahasenack> apw: I got an automated email (looks like) about "[zesty/samba] Increase in crash rate"
<ahasenack> link is https://errors.ubuntu.com/?release=Ubuntu%2017.04&package=samba&version=2%3A4.5.8%2Bdfsg-0ubuntu0.17.04.5
<ahasenack> I believe this is not related to the sru
<ahasenack> that crash is old, has a bug already, even an upstream one
<apw> so you would like it re-thingged
<ahasenack> "Further phasing of this update has been stopped until the errors have either been fixed or determined to not be a result of this Stable Release Update." <-- that :)
<ahasenack> dpb1: what about getting rid of "check" entirely? Would also have to change .travis.yml
<ahasenack> is that what you didn't want?
<dpb1> ahasenack: changed travis and pushed a new copy
<ahasenack> dpb1: dpkg-buildpackage calls which one?
<ahasenack> "make", or "make test"? Do you know?
<dpb1> 'make' I think
<ahasenack> dpb1: change DEFAULT_GOAL to test, and get rid of check?
<dpb1> k
<dpb1> ugh
<dpb1> I don't like setting env vars
<ahasenack> that's a magic make var
<dpb1> keeping the rules file clean feels better
<ahasenack> what do you mean, no change is needed in d/rules
<dpb1> oh, you mean putting that in the makefile
<dpb1> I like that even less.
<ahasenack> the makefile has that already
<ahasenack> .DEFAULT_GOAL := check
<dpb1> hah
<apw> ahasenack, ok re-phased
<dpb1> that's so unecessary!
<dpb1> make by default runs first target
<dpb1> OK ahasenack wait for next
<ahasenack> I said so
<ahasenack> but ack
<ahasenack> maybe he found a makefilecheck script somewhere
<dpb1> just testing
<dpb1> ahasenack: ok, next rev is pushed
<dpb1> better?
<jbicha> LocutusOfBorg: and is dropping boinc from 17.10 going to be a problem?
<ahasenack> yep
<ahasenack> let's wait for travis to finish
<ahasenack> dpb1: make a d/changelog entry for version 6
<dpb1> really?
<ahasenack> yes, previous one is 5 right?
<dpb1> ok, you want a new changelog with every commit?
<dpb1> it's fine, I'm just checking
<ahasenack> I think there are two big changes worth mentioning: the updated manpage ("add exit status to manpage") and
<ahasenack> well, maybe this shellcheck thing isn't worth it
<ahasenack> let me check if there was something else
<slangasek> kees, mdeslaur, infinity, stgraber: TB 5 minute warning
<dpb1> ahasenack: ya, let's just land this, then I'll let you do a changelog after
<mdeslaur> ack
<ahasenack> dpb1: ok
<dpb1> ahasenack: could use an ubuntu-advantage status
<dpb1> :)
<ahasenack> we sure could
<ahasenack> for all?
<dpb1> ahasenack: ya, I'll put in a gh issue.  I think a summary status and each one with an individual status
<dpb1> ahasenack: put a few issues in
<dpb1> ahasenack: looks nice
<dpb1> manpage++
<LocutusOfBorg> jbicha, I presume it might be a big problem :)
<dpb1> ahasenack: I'd say get the non-status issues resolved and it would be worth another SRU
<ahasenack> dpb1: I had highlighted that problem with trying to enable esm on non-precise during the sru testing
<dpb1> ahasenack: ya, I saw that
<dpb1> you think a whitelist is good?
<ahasenack> hm
<ahasenack> the way it is now, if esm is enabled in non-precise, we don't have to do anything
<ahasenack> it will just work
<ahasenack> if we have a list, then we need another sru
<ahasenack> maybe something smarter could be done
<Pharaoh_Atem> nacc: you should look at fedpkg for inspiration :)
<Pharaoh_Atem> (in re "git ubuntu clone" discussion on ML)
<Pharaoh_Atem> fedpkg is the Fedora Swiss Army Knife of awesome for package maint management
<nacc> Pharaoh_Atem: does it do historical imports?
<Pharaoh_Atem> https://www.mankier.com/1/fedpkg
<Pharaoh_Atem> what do you mean by historical imports?
<nacc> Pharaoh_Atem: so, no.
<nacc> Pharaoh_Atem: meaning the source of a package going back to the beginning of fedora (or as close as possible)
<nacc> Pharaoh_Atem: that's why we have so many tags
<nacc> but I will look at that as a reference for subcommands, etc.
<Pharaoh_Atem> yes, everything is there
<Pharaoh_Atem> keep in mind, we're a top-level distribution
<Pharaoh_Atem> as opposed to Ubuntu, which deals with both Ubuntu and Debian stuff
<nacc> Pharaoh_Atem: right, but I think because someone does their work in fedpkg? or because some runs `fedpkg import <path to srpm`
<nacc> for each srpm in fedora
<Pharaoh_Atem> fedpkg import is only for the initial import into Fedora
<Pharaoh_Atem> everything else after is direct git things
<nacc> right
<Pharaoh_Atem> or rather, using all the other fedpkg subcommands
<Unit193> nacc: Do you use sbuild or pbuilder?
<nacc> that sounds like a 'do things this way'
<nacc> Pharaoh_Atem: we're trying to avoid that :)
<nacc> (at least for now)
<Pharaoh_Atem> well, you *can* use fedpkg import every time
<nacc> Unit193: sbuild
<Pharaoh_Atem> nothing technically *stops* you
<Pharaoh_Atem> it works, it's just people don't do that anymore :)
<Unit193> nacc: Have you run into issues since the 10th with creating i386 build chroots?
<Pharaoh_Atem> it was more common back when we used CVS for Dist-VCS rather than Git
<nacc> Pharaoh_Atem: sure
<nacc> Pharaoh_Atem: i think we have slight different goals, in any case
<Pharaoh_Atem> well, you're starting at the beginning
<Pharaoh_Atem> fedpkg was nowhere near as powerful in the beginning times :)
<nacc> Unit193: i've not tried, I can tomorrow to see
<Unit193> nacc: I'm working with zesty as a host, but just to be sure I bumped debootstrap up too.
<Pharaoh_Atem> the original fedpkg was more or less a thin wrapper to make it more manageable to deal with dist-git
<Unit193> nacc: Thanks.
<Pharaoh_Atem> now it does a lot of other things since the initial problem was solved
<nacc> Unit193: ok, i'm on artful, I'lll try first thing
<nacc> Unit193: and let you know
<nacc> Pharaoh_Atem: thank you for the pointer, though
<Pharaoh_Atem> np
<Pharaoh_Atem> zyga raves about the awesomeness of fedpkg :)
<Pharaoh_Atem> I figure if you're going to do a tool like it, base it on something made of awesome
<nacc> well, i think fedpkg is doing a lot
<nacc> a lot that we are not planning on doing
<Pharaoh_Atem> sure, not right now
<nacc> we are not writing an archive management tool
<Pharaoh_Atem> trust me when I say that your tool will become that
#ubuntu-devel 2017-08-16
<Unit193> nacc: If it helps, I pasted the log from pbuilder a few days ago, and unstable chroots work.
<nacc> Unit193: ok, good to know
<cpaelzer> still trying to wrap my head around this bug did we cahnge the default pic/pie behaviour with a recent (maybe gcc) update?
<cpaelzer> I see some fallout due to "-fPIE -pie" being dropped and replaced by "-specs=/usr/share/dpkg/no-pie-compile.specs"
<cpaelzer> at least that is how it seems so far, still debugging
<cpaelzer> or any changes to what hardening=+all does maybe
<cpaelzer> I thought that the move was still towards pie
<cpaelzer> maybe this package drives dpkg/debhelper nuts t generate the wrong options
<cpaelzer> ok down to two things "DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS" really looses -fPIE
<cpaelzer> maybe assumed to be default without stated now?
<cpaelzer> the other thing seems package specific and more debuggin
<cpaelzer> g
<infinity> cpaelzer: Yes, -fPIE is default on all arches.  It's not "losing" PIE.
<cpaelzer> thought so
<cpaelzer> only the explicit arg is lost which was a red herring for a bit
<cpaelzer> I found the issue deeper down due to no-pie-compile.specs now generated by hardening=+all,-pie
<cpaelzer> in my case package A (net-snmp) sets -pie and pakage B (nut) collects the build options of A for plugin builds
<cpaelzer> but they fail as they pass CFLAGs to all builds, but LDFLAGs only to some
<infinity> cpaelzer: Ahh, yes.  CFLAGS and LDFLAGS both need to be pulled from dpkg-buildflags if you're doing one.
<cpaelzer> leading to binaries with no-pie-compile.specs but subsequent links without "no-pie-link.specs"
<infinity> cpaelzer: Mismatching them will lead to a very bad time.
<cpaelzer> exactly that I'm in
<cpaelzer> need to fix the package as it is deep in the auto-generated makefiles, not broken on our side really - we are only the trigger by behaving slightly different
<cpaelzer> IMHO it was "wrong" all the time just not breaking anything yet
<cpaelzer> infinity: you'll love this quote "In any case, CFLAGS are only -I options, so there is no harm"
<cpaelzer> from the broken makefile :-)
<infinity> cpaelzer: Well, other option is to just explictly state "CFLAGS=$(dpkg-buildflags --get CFLAGS -fno-pie -no-pie)" and similar for LDFLAGS, if that's then being embedded in some pkgconfig file later or something.
<infinity> cpaelzer: And yes, I've run into similarly broken makesfiles (both from upstreams, and broken debian/rules).  I guess, to be fair, pie and pic are on a very short list of options where compiler and linker have to agree.
<infinity> cpaelzer: So I don't mind educating people when they mess it up.  The real annoyance is when they argue. :P
<ginggs> tsimonq2: f.y.i. nodejs 6.11.2 is now in debian unstable and can be merged
<tsimonq2> ginggs: ack
<tsimonq2> ginggs: I'll have a patch for you as soon as I can, I need a sponsor ;)
<ginggs> tsimonq2: i tested a merge of 6.10.2 some weeks ago in my PPA, if it helps - i'll happy to sponsor!
<tsimonq2> ginggs: Ok :D
<tsimonq2> ginggs: Let's see how the build goes: https://launchpad.net/~tsimonq2/+archive/ubuntu/universe-upload-testing/+packages
<cpaelzer> can building with gcc7 affect the c++ symbols exported?
<cpaelzer> I guess so
<cpaelzer> but they are so unreadable ...
<tsimonq2> cpaelzer: Yep, sometimes there's optional templinst symbols that either appear or go "MISSING"
<tsimonq2> cpaelzer: Also, c++filt ftw
<cpaelzer> yeah it already has a few templinst
<cpaelzer> might just be more now or some not yet tracked
<cpaelzer> OTOH what broufht me to look were the missing symbols as it broke the check
<cpaelzer> and reading/checking if that might be an issue is next to impossible with the names they have
<cpaelzer> newer came by c++filt
<cpaelzer> need to take a look
<cpaelzer> ah yeah looks good
<cpaelzer> thanks tsimonq2
<tsimonq2> cpaelzer: You're welcome, let me know if you need any assistance with symbols mangling (I've learned quite a bit from Qt packaging) :)
<cpaelzer> tsimonq2: to me it appears they are rather trimmed than mangled-names - what do you think? http://paste.ubuntu.com/25324531/
<cpaelzer> at the same shlibs diff there are two new templates showing up - I'd almost think gcc7 outputs them slightly different so that they are now more "readable"
<cpaelzer> but I'd loke to prove
<tsimonq2> cpaelzer: Could you get a paste of the new ones?
<cpaelzer> already preparing
<cpaelzer> http://paste.ubuntu.com/25324539/
<cpaelzer> those can at least be demangled - let me try the tool you recommended
<cpaelzer> oh yeah
<cpaelzer> that seems to match
<cpaelzer> need to this more than with eyes on console now
<cpaelzer> please let me know what you think tsimonq2 if that seems odd to you
<tsimonq2> cpaelzer: Yeah it does seem to match pretty well
<cpaelzer> well then let me fix that and make them replace the old ones in-place
<cpaelzer> thanks for your hint on c++filt
<cpaelzer> that serves well as "prove" on the reason of the change
<tsimonq2> cpaelzer: I have this bookmarked and it might help in general with symbols :) https://pkg-kde.alioth.debian.org/symbolfiles.html
<cpaelzer> I think I read that in the past when I had fun in dpdk with that
<cpaelzer> thx
<tsimonq2> yw :)
<cpaelzer> slangasek: I saw your collectd upload broke on something around dpdk - let this be my problem, I'll ping you with a solution
<ginggs> tsimonq2: for nodejs i think you might need debian/patches/fix_sslv3_test.patch from my PPA
<LocutusOfBorg> acheronuk, do you plan to have a look at qtwebkit-opensource-src on i386/armhf?
<LocutusOfBorg> some symbols sadness
<LocutusOfBorg> I can do it, but I think I'll just make things worse, since I don't know how to deal with them :)
<acheronuk> KDE stuff I am ok with. The qt packaging, I have only touched briefly on, and have not had much to do with this time. so tsimonq2 or mitya57 are the people I think
<LocutusOfBorg> tsimonq2, is asleep :)
<LocutusOfBorg> I see they are ~10 symbols changed, I think I can do it, but I don't know which tool they use to do the magick, I can do it manually but I'm not sure it is error-prone
<acheronuk> bah. so much for his 'sleep is for the weak' :P
<acheronuk> I guess still this? https://pkg-kde.alioth.debian.org/symbolfiles.html
<acheronuk> 26 MB build log is killing my browser!
<LocutusOfBorg> acheronuk, you can wget and tail -n 200 after gunzip
<LocutusOfBorg> or I can give you the two patches
<LocutusOfBorg> I'm trying the command right now
<LocutusOfBorg> lets see
<acheronuk> I'd rather not touch it myself and wait a few hrs
<acheronuk> but if you think your result looks sane, then fair enough
<LocutusOfBorg> pkgkde-symbolshelper patch -p libqt5webkit5 -v 5.9.1 < ../buildlog_ubuntu-artful-armhf.qtwebkit-opensource-src_5.9.1+dfsg-2_BUILDING.txt
<LocutusOfBorg> this fails
<LocutusOfBorg> fails in applying patches
<acheronuk> I normally grab all the logs, even the passes and they help
<LocutusOfBorg> I'll try the old fashioned manual way instead
<acheronuk> then do 'pkgkde-symbolshelper batchpatch -v 5.9.1 ../buildlog_ubuntu-artful*'
<LocutusOfBorg> ah ok
<acheronuk> which compares and confirms, and makes exceptions etc on some arches, based on what happened overall
<acheronuk> but think I only tried with Qt once ever
<acheronuk> which has some extra stuff for marking private symbols at the least
 * acheronuk is away for now
<LocutusOfBorg> tsimonq2, please do it, I'm lost
<LocutusOfBorg> :)
<cpaelzer> slangasek: I have a working fix complete, will report upstream and provide you with a debdiff so you can upload this fix to artful
<cpaelzer> slangasek: I don't want to mess with your "potential" uploads you have in queue for that but I don't know of
<cpaelzer> slangasek: just need to report and polish the patch headers to be correct
<cpaelzer> slangasek: bug 1711120 is ready for you to pick the debdiff from if you agree with the solution
<ubottu> bug 1711120 in collectd (Ubuntu) "dpdk subset fails to configure correctly on i386" [High,Triaged] https://launchpad.net/bugs/1711120
<xnox> bdmurray, do you remember where "incomplete language support" code lives? and which packages it installs, etc? i think i need to fix cjk languages to install qt4-fcaitx for us to drop qt4 from main.
<xnox> bdmurray, or e.g. i could go easier route and make qt4 gui or some such pull in fcaitx as a recomends.
<bdmurray> xnox: I think language-selector-gnome puts a file somewhere so update-notifier notifies you about the incomplete support
<powersj> rbasak: nacc: when I run `apt show <package>` should the "Supported" field on an LTS always say 5y?
<powersj> clear
<powersj> woops lol
<nacc> powersj: LP: #1574670
<ubottu> Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [High,Confirmed] https://launchpad.net/bugs/1574670
<nacc> powersj: for context, if i had to guess
<nacc> slangasek: --^ is someone from foundations working that?
<powersj> nacc: yeah someone filed LP: #1710721 looks to be similar
<ubottu> Launchpad bug 1710721 in libsdl1.2 (Ubuntu) "This packages have the wrong timeframe set for the xenial LTS release" [Undecided,New] https://launchpad.net/bugs/1710721
<nacc> powersj: yeah, i'd dupe it
<rharper> slangasek: hi,  was looking at the artful cloud server images at the locales present, and I see both C.UTF-8 and en_US.UTF-8 present (http://paste.ubuntu.com/25326237/) ; if we already have the en_US.UTF-8 generated, is there a need for the C.UTF-8 as well?  also, other than the directory presence (/usr/lib/locale/C.UTF8) is there a way to know if C.UTF8 is available?  I  though that localedef --list might show it, bu
<rharper> t it doesn't
<xnox> bdmurray, ack! thanks.
<slangasek> cpaelzer: cool, thanks, the dpdk i386 failure was the last thing I hadn't figured out.  I'll upload that straightaway!  You've forwarded this to upstream?  (Debian upstream or upstream upstream?)
<slangasek> nacc: ubuntu-support-status returns inaccurate information because the metadata in the archive is incorrect; this is on infinity to solve
<cpaelzer> slangasek: yes collectd upstream
<cpaelzer> slangasek: the issue is in the branch
<cpaelzer> linked
<slangasek> rharper: C.UTF-8 is always available on Ubuntu and we should be using that intsead of en_US.UTF-8, and we should DROP en_US.UTF-8 as a default locale in artful and forward
<cpaelzer> I'll make a note to check build and migration in a-p tomorrow
<rharper> slangasek: yes, and shouldn't /etc/default/locale  have LANG=C.UTF-8 or is that not the right thing to do ?
<rharper> I do see that locale -a shows C.UTF-8 ; so we can always check for that;
<slangasek> rharper: we do need to somewhere select C.UTF-8 as the runtime locale, yes
<slangasek> rharper: /etc/default/locale is an appropriate place for it
<rharper> IIUC, the locale-gen tooling would never generate a C.UTF-8 (it's part of glibc , i think) ?
<nacc> slangasek: ok, are you ok if i put that comment in the bug?
<slangasek> nacc: I'm certainly ok with it, it's not me you're pointing the finger at ;)
<nacc> infinity: --^ :)
<nacc> slangasek: ack
<ricotz> hello, is there any chance to force firefox to the artful release pocket? https://launchpad.net/ubuntu/+source/firefox/54.0+build3-0ubuntu1
<nacc> ricotz: well, it failed to build on a few archs, it seems like?
<nacc> chrisccoulson: --^ I assume is looking into it
<ricotz> nacc, I know, and no, he is not looking into it
<nacc> ricotz: i see
<nacc> ricotz: is it a rustc issue?
<ricotz> nacc, no
<ricotz> several buildsystem and (smaller) source issues
<ricotz> I am hoping firefox 56 will be in a better shape
<chrisccoulson> it's the armhf failure that stops it from migrating. The other architectures aren't blocking it
<nacc> chrisccoulson: ah ok
<nacc> chrisccoulson: ah yes, i see that now
<ricotz> chrisccoulson, is this already a webrtc failure there?
<chrisccoulson> It's blocked on arm because it just crashes at startup, which causes the startup cache compilation to fail
<nacc> heh, that message isn't too helpful
<nacc> mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation
<chrisccoulson> Firefox 55 doesn't build a startup cache, so it builds ok now. But it still crashes at startup
<ricotz> chrisccoulson, still force it into release
<ricotz> I guess having 50.1.0 on the iso is quite something
<seb128> ricotz, try arguing with infinity that having firefox outdated is a bigger issue than not having it working on armhf
<seb128> I tried that before
<seb128> he seems to disagree, so somebody needs to eventually fix firefox
<ricotz> we can deal with those failures again with 55 / 56
<seb128> as I said I'm not the one to convince
<ricotz> seb128, you pinged him already ;)
<seb128> ricotz, right, and you think that's going to be enough to convince him? ;-)
<ricotz> at least to read
<seb128> yeah, let's see
 * rbalint looking for sponsor for LP: #1709726
<ubottu> Launchpad bug 1709726 in akonadi (Ubuntu) "Breaks reverse build-dependencies by embedding build-time std exception header path" [Undecided,Confirmed] https://launchpad.net/bugs/1709726
<LocutusOfBorg> rbalint, thanks!
<cpaelzer> slangasek: collectd complete, thanks for the upload
<cpaelzer> slangasek: and on your Deb question - my co-maintainer on dpdk is watching the PR
<cpaelzer> slangasek: since he has no FF ahead he can be more relaxed to pick the final fix without the extra hop including the suggestedone we did for now
<slangasek> cpaelzer: excellent
<rharper> slangasek: one follow-up;  locale-gen --lang C.UTF-8 returns an Error, 'C.UTF-8' is not a supported language or locale;  is that expected?  and if someone in cloud-init passes us a locale: C.UTF-8 , currently we just call locale-gen ; so we'll need to fix that up if that's expected behavior of locale-gen
 * tsimonq2 stretches
<tsimonq2> LocutusOfBorg: ack, will do
<slangasek> rharper: ah, I thought cloud-init was being fixed to not regenerate already-present locales?
<slangasek> rharper: locale-gen doesn't support generating C.UTF-8 because it's always shipped in the glibc package
<rharper> slangasek: is it possible to get those tools (locale-gen and update-locale) to not barf on it (even if it doesn't have to regenerate it) ?
<rharper> slangasek: cloud-init currently reads the value (if present) in /etc/default/locale, checks if the value in the file matches what it's been told to configure (defaults currently to en_US.UTF-8, we're looking to change to C.UTF-8)  and then we call update-locale to update the file;
<slangasek> rharper: bug report on glibc?  but again, I understood from dpb that cloud-init was being changed to avoid regenerating locales when it doesn't need to, which you know categorically you never need to regenerate C.UTF-8, so why are you trying
<rharper> slangasek: C.UTF-8 stuff is new to me at least, we initially implemented not regenerating the default of en_US.UTF-8 if it was present in the /etc/default/locale file;  that value is unset in images today, despite en_US.UTF-8 locale being generated and in the locale-archive file
<slangasek> rharper: fwiw there was a mail thread about this back end of May that you were cc:ed on where I said C.UTF-8 was the right default for future releases
<rharper> so, one fix is to have the image set LANG="en_US.UTF-8" in /etc/default/locale; that'll work with cloud-init trunk in artful;  if we want to switch to defaulting to C.UTF-8 (which sounds fine to me); I wanted to know how to generate C.UTF-8 (turns out you dont' need to);  We can make further changes to cloud-init to not call locale-gen/update-locale if we;ure using C.UTF-8;  but was worried that if someone at runtime
<rharper> were to run either of those tools with LANG=C.UTF-8 in /etc/default/locale; if that would complain
<slangasek> rharper: so we need an image change to set up /etc/default/locale to a correct default
<slangasek> is the behavior sane when the locale-gen and update-locale commands are absent?  (minimal images)
<rharper> behavior of what? cloud-init?  currently none of the images set a value in /etc/default/locale; and cloud-init still defaults to en_US.UTF-8 (as of today, I'm working on a C.UTF-8 branch now)
<rharper> if the images switch to setting C.UTF-8 in /etc/default/locale, and I land the C.UTF-8 cloud-init branch, it will skip calling locale-gen/update-locale
<rharper> and it sounds like, in our path where we'd want to regenerate, we'd never attempt to call locale-regen/update-locale if the LANG value was C.UTF-8, since it's not something that can be regenerated
<slangasek> rharper: behavior of cloud-init.  Minimal images won't have the locales package installed; they don't currently set LANG=C.UTF-8 in /etc/default/locale but they should; if we do those things (including for minimal images on xenial), will cloud-init behave sanely?
<rharper> slangasek: we'll need the current branch I'm working on to land for C.UTF-8 support;
<rharper> I should have that up today as I now understand more about C.UTF-8 w.r.t regeneration (or the lack of a need to do so)
<rharper> slangasek: it does seem odd though that, I cant say 'update-local --locale-file=/etc/default/local LANG=C.UTF-8'  ; is there a reason why that shouldn't work ?
<slangasek> rharper: this is literally the first time I have ever heard of the update-locale command
<rharper> hehe, me too
<rharper> I guess we can pass --no-checks
<rharper> that seems reasonable; though I still feel like if it's a valid LANG setting, the tool's check should accept it
<rharper> slangasek: is that worth a bug ?
<slangasek> rharper: yes, I think so
<rharper> ok
<rharper> thanks for the help
<ahasenack> acheronuk: hi, around?
<ahasenack> LocutusOfBorg: hi,
<ahasenack> LocutusOfBorg: I caught wind of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868473
<ubottu> Debian bug 868473 in dh-acc "dh-acc: Incorrect usage of doit (Dh_Lib)" [Serious,Open]
<ahasenack> LocutusOfBorg: there is a dep8 test in qca2 that uses dh_acc, and which fails now because of the warning that dh_acc is sending to stderr
<ahasenack> LocutusOfBorg: http://pastebin.ubuntu.com/25327602/
<ahasenack> LocutusOfBorg: you seem to have a patch, is it landing soon?
<ahasenack> the trail is that my cyrus-sasl2 upload to artful is blocked on that qca2 test failure, and on a kdepim-runtime build failure
<ahasenack> hm, looks like a new abi-compliance-checker that is in proposed fixes it
<ahasenack> "test in progress"
 * ahasenack checks again tomorrow
<tsimonq2> rbasak: Ping, I don't know if you're in a US or UK timezone ;)
<ahasenack> uk
<tsimonq2> ack
<LocutusOfBorg> ahasenack, exaactly, proposed is the fix
<ahasenack> nice, thanks
<nacc> ahasenack: i can rerun your dep8 test with the appropriate srcpkg(s) from -proposed
<nacc> ahasenack: if you tell me which ones
<acheronuk> LocutusOfBorg: well, unless someone ignore those libkf5eventviews/4:16.12.3-0ubuntu1 and libkf5calendarsupport/4:16.12.3-0ubuntu1, then it will never get our of -proposed
<acheronuk> those tests should never run. it's only a bug or glitch in britney that they are
<acheronuk> ok. those are overridden now. if the armhf tests will just complete, might have a chance of fixed abi-compliance-checker making it to -release
<Unit193> nacc: Hiya!
<nacc> Unit193: hey, let me spin a chroot as promised :)
<Unit193> No rush, but just wondered.  Danke.
<nacc> Unit193: what error do you get?
<Unit193> http://paste.openstack.org/show/cGj8uRFD3nm0PKN3D9T8/
<nacc> Unit193: what was the cmdline for that?
<Unit193> Basically: debootstrap --arch=i386 --include=apt --arch i386 --variant=buildd --force-check-gpg --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg artful /var/cache/pbuilder/build/6390
<Unit193> nacc: I'm not sure if I should be annoyed or happy, it appears to be working now...
<Unit193> Thanks for fixing it!
<nacc> heh
<Unit193> I'm sorry for wasting your time.
<sarnold> it felt a bit like something that 'waiting' would fix, but i'm surprised it fixed so quickly :)
<nacc> yeah, i wonder if it was just the gcc-7 transition/mirror latency/etc.
<Unit193> sarnold: I thought so too, but hit it sometime before Aug 13.
<nacc> glad it works now, regardless
#ubuntu-devel 2017-08-17
<sarnold> Unit193: oh hrm. I'd expect that kind of error to persist for about four to six hours ath the most, just a wild guess..
<nacc> sarnold: true
<nacc> Unit193: had to remember my mk-sbuild commandline for cross-building, but it seems to be working fine with sbuild as well now
<Unit193> nacc: Technically the command is  `sudo DIST=artful pbuilder create`, but that tells you nothing and the debootstrap command does (since that hit the error.)  What was even weirder, I created a chroot (without --variant=buildd), arch-chroot'ed in, installed build-essential (which I think failed), then ran apt-get install -f and it passed.
 * Unit193 shrugs.
<Unit193> Still, sorry for wasting time.
<nacc> Unit193: nothing to worry about
<Unit193> Thanks for trying, nacc!
<tsimonq2> ginggs: http://people.ubuntu.com/~tsimonq2/packages/nodejs_6.11.2~dfsg-2ubuntu1.dsc :)
#ubuntu-devel 2017-08-18
<acheronuk> ahasenack: abi-compliance-checker finally got all it's tests passed and migrated
<mwhudson> are livefs builds hard coded to only look at main, or can i influence that somehow?
<Unit193> Eg, the iso builds?  Xubuntu is mainly in universe.
<mwhudson> Unit193: yeah
<mwhudson> it's probably a livecd-rootfs thing
<mwhudson> and how do i turn https://launchpad.net/~canonical-foundations/+livefs/ubuntu/artful/test/+build/107309 into something i can boot? :)
<tsimonq2> mwhudson: Hidden in ubuntu-cdimage somewhere is the tooling that powers something like this: http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/artful/daily-live-20170817.log
 * tsimonq2 doesn't know where it's hidden :P
<mwhudson> ubuntu-cdimage, right
<mwhudson> i can never keep these things straight in my head
<tsimonq2> mwhudson: Once you find where it's hidden, please share :)
<mwhudson> oh lol this hook is missing set -e
<cpaelzer> hmm private bugs are annoying, do we in a changelog list the bug number when an upload closes them?
<cpaelzer> and LP can hide (or not) the content depending who looks at them?
<cpaelzer> or do we omit them in the changelog completely and manually close?
<stgraber> if it's not going to be made public at the same time as the package hits the archive, then I'd say manually close
<cpaelzer> stgraber: both changes are in the upstream projects pblicly available
<cpaelzer> which is why I wonder if I could (I prefer) add them to the changelog
<cpaelzer> anyway I hear you saying "to not get in trouble you might manually close"
<stgraber> on top of the social problem of having a private bug linked to a public upload, we have tools that parse changelogs for LP entries and those don't like private bugs very much either
<cpaelzer> oh yeah because without creds they can't read them
<cpaelzer> ok reason enough, not listing in changelog
<cpaelzer> thanks stgraber
<Unit193> cpaelzer: Even more annoying?  "Public" bugs filed by the automatic bot on behalf of errors.ubuntu.com...
<cpaelzer> Unit193: what is the annoying part on them?
<cpaelzer> other than causing work and usually being hard to debug?
<Unit193> cpaelzer: Most information you get out of 'em is in the title, doesn't have any other info. :P
<cpaelzer> yeah like "failed to install/upgrade: subprocess installed post-installation script returned error exit" without extra files attached and a comment of "I don't know"
<cpaelzer> well, in that case me neither :-)
<Unit193> (Eg, 1697506)
<ahasenack> acheronuk: yep, my cyrus-sasl2 migration passed :)
<ahasenack> thx
<ahasenack> hi, in the ubuntu or debian bag of tricks, is there some sort of copyright file parser?
<rbasak> ahasenack: I think it's standard "control file" format. So stuff like grep-dctrl will probably work against it. I know lintian does some checks in it so presumably it has a parser. What are you trying to do?
<ahasenack> I need to generate a list  with package name, version, and license
<ahasenack> lawyers
<ahasenack> some copyright files are machine readable
<ahasenack> others not
<ahasenack> by "machine readable" I mean they have well identified fields, but still plaintext
<ahasenack> like the control file you mentioned
<rbasak> https://spdx.org/ might be relevant
<mdeslaur> ahasenack: https://wiki.debian.org/CopyrightReviewTools lists a few perhaps
<ahasenack> $ licensecheck /usr/share/doc/binutils
<ahasenack> might work
<ahasenack>  /usr/share/doc/binutils/copyright: GPL (v3 or later)
<ahasenack> gets a bit confused with libc6
<ahasenack> who doesn't
<mdeslaur> heh
<mdeslaur> I think it's meant to parse the license in source files, not in the copyright file itself
<rbasak> licensecheck is mainly intended for scanning code rather than copyright files AIUI. But since it searches regexs, it may work.
<ahasenack> $ licensecheck -l 10000 /usr/share/doc/libc6/copyright
<ahasenack>  /usr/share/doc/libc6/copyright: BSD (3 clause) ISC GPL (v2) GPL (v2) LGPL (v2)
<ahasenack> still misses a lot
<mdeslaur> ahasenack: is grep "^License:" /usr/share/doc/libc6/copyright not enough?
<ahasenack> mdeslaur: not all have that field
<ahasenack> and some times it's a different license for the debian/* stuff
<rbasak> That particular file is free form text
<ahasenack> there is a DEP for that
<mdeslaur> oh heh, I of course used the example that doesn't respect the DEP
<rbasak> IMHO, there basically isn't the data that can give you conclusive results. You have to do it manually.
<rbasak> Any automation may give you results for most things but they also be wrong so you can't rely on those results.
<ahasenack> I have a list of 279 packages
<ahasenack> names, that is
<rbasak> And of course this depends on debian/copyright being correct. I reckon you'll find errors across 279 packages.
 * mdeslaur estimates in about 276 packages
<rbasak> Depending on the required accuracy of your answer your task is non-trivial.
<ahasenack> it's to be done in 2h, that defines it as trivial
<ahasenack> I could as well just dump the whole copyright file
<ahasenack> instead of a simple abbreviation
<rbasak> Yeah I'd just extract all copyright files and provide those.
<rbasak> That's all that's really achievable in 2h.
<ricotz> hi, is something holding back rustc from transiting out of proposed? https://launchpad.net/ubuntu/+source/rustc/1.18.0+dfsg1-4ubuntu1
<cpaelzer> hiho, what is the usual duration from a package in Debian going to "installed" state until "has not been picked up by LP yet. Please try again later." on syncpackage goes away?
<cpaelzer> I expected a 30m or 1h job, but it is 2h now and still not finiding it - so it might be better to ask what to expect
<ahasenack> given a package I downloaded via apt-get, how can I figure out its download url?
<ahasenack> apt-cache doesn't print that out explicitly
<ahasenack> "apt-cache show" shows "Filename", maybe I can use that
<mdeslaur> ahasenack: apt-cache policy
<mdeslaur> you'll need to mangle that a bit
<mdeslaur> oh, apt-cache show too
<juliank> cpaelzer: Usuually takes a few hours (well, more like 6?) in my experience
<juliank> ahasenack: The correct way to figure out download urls for packages generally is apt download --print-uris <package name>[=<version>]
<cpaelzer> thanks juliank, that is a target I can wait for and retry
<ahasenack> juliank: nice trick
<ahasenack> juliank: hm, apt download --printuris doesn't seem to work for packages from ppas
<ahasenack> it just prints nothing
<SpamapS> doko: FYI, https://bugs.launchpad.net/ubuntu/+source/python3.6/+bug/1711724 <-- I just uploaded a xenial SRU of python3.5
<ubottu> Launchpad bug 1711724 in python3.5 (Ubuntu Xenial) "Segfaults with dict" [High,In progress]
<slangasek> rharper: replied to your comment on the livecd-rootfs mp; let me know if we need to discuss
<rharper> thanks, will read
<rharper> slangasek: yes; hrm;  I was hoping to avoid exec'ing locale -a or localedef --list to see what's available;  I assumed a 1:1 mapping between the /etc/default/lang and what's in /usr/lib/locale/ ;  otherwise, if they're not the same, we're including additional locales which won't be used by default (making the image larger)?
<slangasek> rharper: ok, from my pov that's an awkward assumption for cloud-init to be hard-coding; let me think on it
<rharper> slangasek: I'm not sure it's the *right* thing; we previously have always generated en_US.UTF-8 (unless told a different locale);  we could now check (locale -a and/or localedef --list); and if the default/or requested lang is already available, avoid calling locale-gen;
<rharper> the debian cloud-image, for example doesn't contain a locale-archive file, but has 135MB of locale dirs in /usr/lib/locale/  (one can see the list via locale -a) ;
<Unit193> LocutusOfBorg: Oh dang, now you are active.  Oh well, already filed Bug 1711748.
<ubottu> bug 1711748 in chef (Ubuntu) "Sync chef 12.14.60-3 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1711748
<LocutusOfBorg> done, leaving now! cheers
<jackpot51> What's going on with launchpad?
<dasjoe> Works for me
<jackpot51> I uploaded packages almost 6 hours ago and they haven't started building
<jackpot51> The predicted time has been 30 minutes for several hours
<Unit193> Did someone upload KDE/Qt again?
#ubuntu-devel 2017-08-19
<mitya57> Unit193, there are new KDE applications 17.04.3, and some Qt modules could have been autosynced from Debian.
<juliank> grr, apt autopkgtests are horribly broken on non-amd64
<juliank> on ppc64el there is still the regression from the gcc 7 upgrade
<juliank> probably because that compiles with -O3 (IIRC)
<ktosiek[m]> Hi! What are the tools for working on a debian package? I've had to mock a bit with network-manager today (basically backport a patch to a backported patch :-)), and neither doing a full rebuild with dpkg-buildpackage nor generating patches for said tool to apply was nice
<ktosiek[m]> I've started with `apt-get source`, copied the source dir, edited one of them, did a diff, added patch to series, and waited for full dpkg-buildpackage
<JanC> ktosiek[m]: did you see http://packaging.ubuntu.com/html/ ?
<ktosiek[m]> JanC: not yet, thank you!
<JanC> and maybe also https://www.debian.org/doc/manuals/maint-guide/ if it's not in there
<ktosiek[m]> I was just doing the things the way I've remembered, it was probably never a good one :-)
<JanC> there is Debian-specific stuff in the latter that might not apply to Ubuntu, but OTOH it might have details that the Ubuntu one doesn't have
<JanC> it's probably best to use a "clean" build environment like pbuilder (which uses a chroot) or similar
#ubuntu-devel 2017-08-20
<mwhudson> mornin
<Unit193> Howdy, mwhudson.
<mwhudson> so uh the artifacts from livefs builds expire really quickly?
<Unit193> mwhudson: ...After doing the favor of fixing, I suppose I shouldn't ask if you're going to forward the golang-github-jacobsa-crypto-dev fix to upstream should I?
<mwhudson> Unit193: the mistake was in the debian delta wasn't it?
<mwhudson> but i suppose some delta against upstream is still required yeah
<mwhudson> Unit193: i can send it along if you don't want to for some reason...
<Unit193> https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-jacobsa-crypto.git/tree/debian/patches/0001-Add-xorBlock-compile-support-for-deb-archs.patch?h=debian
<Unit193> mwhudson: I don't know golang, nor have a GH account. :3
<mwhudson> Unit193: heh ok
<Unit193> Did file a Debian bug on the other package, no response yet.
 * mwhudson tries to understand how to invoke debian-cd
<Unit193> mwhudson: I've missed what you're specifically trying to do?
<mwhudson> Unit193: turn https://launchpad.net/~canonical-foundations/+livefs/ubuntu/artful/test/+build/107525 into a bootable iso
<mwhudson> Unit193: it's for subiquity, building a live image with some custom installer bits
<Unit193> mwhudson: Ah, sounds like fun.  subiquity could be interesting, perhaps.
#ubuntu-devel 2018-08-13
<GunnarHj> sil2100: Thanks for the bionic upload for bug #1778041. Want to mention that it resulted in much fewer binaries than is present in bionic-release. Is that a problem? (I hope not.)
<ubottu> bug 1778041 in freshplayerplugin (Ubuntu Xenial) "browser-plugin-freshplayer-pepperflash broken" [High,In progress] https://launchpad.net/bugs/1778041
<sil2100> GunnarHj: I don't think so, sometimes microreleases just drop binary packages so yeah, but I must say I didn't have experience with such cases before - accepted it as it seemed the logical way to go
<sil2100> Since it's either that or leaving it busted
<GunnarHj> sil2100: That's what I thought/hoped. There is an additional aspect with the xenial one - there is already stuff the old way in bionic-updates.
<GunnarHj> sil2100: s/bionic-updates/xenial-updates/
<abeato> sil2100, is it a good time for a review of https://github.com/CanonicalLtd/ubuntu-image/pull/155 ?
<g40> Greetings. Can anyone help? Trying to update a chroot'd 18.04 base image on an 18.04 host. `Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [107 kB] Err:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease   Couldn't create temporary file /tmp/apt.conf.vN6blL for passing config to apt-key`
<g40> filesystem is writable. `ls -als /tmp total 12 4 drwxr-xr-x  2 root root 4096 Aug 13 12:55 . 4 drwxr-xr-x 22 root root 4096 Aug 13 12:38 .. 4 -rw-r--r--  1 root root    6 Aug 13 12:57 x`
<ahasenack> g40: shouldn't /tmp be 1777?
<g40> @ahasenack boom! great catch, thank you.
<udevbot> Error: "ahasenack" is not a valid command.
<scientes> mvo, any questions about command-not-found?
<mvo> scientes: in a meeting right now, sorry. but excited about your C implementaton, I think its pretty cool to have that
<scientes> hit me up
<scientes> (later)
<mvo> scientes: now :) so I think the C implementation is great, low latency/overhead and all that. the update-alternatives problem could be solved by making it a server side problem. I had this idea that we would store the commands in a new apt indexfile that is automatically downloaded by apt when c-n-f is installed. the apt snippet is super simple:https://paste.ubuntu.com/p/TW4gR7KnmF/  and here is an example what it would look like http://peop
<mvo> le.canonical.com/~mvo/c-n-f/dists/bionic/main/cnf/
<mvo> scientes: this would then be parsed by c-n-f into whatever format it wants
<mvo> scientes: the server side extractor is also easyhttps://git.launchpad.net/~mvo/command-not-found-extractor/tree/
<mvo> scientes: (unfortuantely I have some trouble getting the server side deployed but that is a different matter)
<mvo> scientes: what do you think about this?
<mvo> scientes: ideally this would be same for debian/ubuntu too, the format is pretty simple
<scientes> yeah that is great
<scientes> I'll code that up in the C version
<mvo> scientes: thanks, lets coordinate with the proposal of the ideas to debian and please keep naging me about getting the extractor to the server side, it needs some admin work mostly I think
<ahasenack> is gcc-8 the default one in cosmic?
<scientes> ahasenack, $ ls -al /usr/bin/gcc
<scientes> lrwxrwxrwx 1 root root 5 Jul 21 00:14 /usr/bin/gcc -> gcc-8
<ahasenack> trying to figure out this error in a ppc64el build: cc1plus: error: unrecognized command line option â-Wno-deprecated-registerâ [-Werror]
<ahasenack> same package builds in the other arches
<ahasenack> well, is still building. so far amd64, s390x and i386 passed
<ahasenack> thanks scientes
<tomreyn> is it known and expected that changing the upgrade-manager release-upgrade prompt to 'normal' enables starting an upgrade from 16.04 to 18.04 without -d ? (and apparently that fails?
<scientes> that should always work even without -d
<tomreyn> scientes: 16.04 -> 18.04 LTS upgrade is not enabled, yet, no.
<scientes> oh my bad
<slashd> seb128, based on our last week discussion, dgadomski_ did the MP for both LPs (dgadomski and tseliot) : https://code.launchpad.net/~dgadomski/ubuntu/+source/gdm3/+git/lp1782152/+merge/352976, it is set to "Need review". According to your process, should I wait for that MP to be approved/merged before uploading ?
<slashd> seb128, basically what are the desktop team expectations according to your process before tseliot or I can upload gdm3 for Bionic (both LPs) which has a MP "Needs review" and Xenial (dariusz bug only)
<ahasenack> hi, on a ppc64el lxd container (haven't tried elsewhere), dpkg-buildflags in cosmic returns -O3, instead of -O2
<ahasenack> I'm trying to track down where that is coming from
<ahasenack>  /etc/dpkg/* has nothing
<ahasenack> any other ideas?
<ahasenack> dpkg-buildflags --status output: https://pastebin.ubuntu.com/p/WXPwsbT5H9/
<ahasenack> in a lxd container in my laptop, amd64, I get -O2 in cosmic
<ahasenack> ah
<ahasenack>  /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm
<ahasenack> if arch ppc64el, set -O3
<ahasenack> amazing
<ahasenack> rbasak: ^ FYI
<ahasenack> "-g -O3" actually
<cjwatson> Yes, it was a specific requirement from the port's sponsor AIUI
<ahasenack> hi guys, any idea why adding -O3 would enable -Werror=format=truncation?
<ahasenack> https://gist.github.com/panlinux/4716e167c2e06612b28be4b9f8f2b52b scroll all the way to the right, the only difference between the two g++ command lines is the last -On I added
<ahasenack> -O3 fails, -O2 works
<ahasenack> (it was easier than editing -O2/-O3 inside the long command line, but has the same result)
<seb128> slashd, no, it's fine, go ahead with the upload and I'm going to review/merge it
<cjwatson> ahasenack: the GCC manual says that -Wformat-truncation sometimes estimates the number of bytes that will be written based on optimisation-level-dependent heuristics
<cjwatson> "While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives."
<ahasenack> hm
<cjwatson> You'll need to analyse the error manually and see whether it's a true overflow
<ahasenack> I could try -O2 *with* -Wformat-truncation
<cjwatson> If it's a false positive, then sometimes carefully-chosen assert() calls are enough to hint the compiler into what's going on
<ahasenack> if that triggers again, then it's not the optimize, right
<cjwatson> No, you misunderstand
<cjwatson> -Wformat-truncation is enabled by default, but behaves differently depending on the optimisation level, because that influences the heuristics that it uses to analyse how many bytes will be written
<cjwatson> Before going any further, you should analyse the code path that the compiler is complaining about and see whether it's actually a potential overflow
<cjwatson> If it is, then fix it; if it isn't, then maybe there's an assert you can add to help the compiler prove that it isn't
<rbasak> ahasenack: I'm not sure what the specific issue is that you're working on, but it might be acceptable to override it down to -O2 for the time being and leave a bug open if you're trying to land something.
<ahasenack> rbasak: it's the squid build I mentioned in the standup
<ahasenack> that it only failed in ppc64, and at that time I saw that -O3 was used, and I thought it was something new in cosmic, not that it was ppc64 exclusive
<rbasak> Does it fail with -O3 on amd64?
<ahasenack> it should, let me check
<sarnold> -O3 ppc64el reminds me of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905868  (probably just coincidence)
<ahasenack> cjwatson: as far as I can see, the truncation can indeed happen. Target buffer is 64 bytes, source string can be up to 3*256+10
<ubottu> Debian bug 905868 in gcc-8 "gcc-8: miscompiles vec_sl at -O3 with -fwrapv on ppc64el" [Normal,Open]
<ahasenack> upstream seems aware: http://squid-web-proxy-cache.1019090.n4.nabble.com/compiler-Error-tp4686058p4686065.html
<ahasenack> this error is a bit down in that page
<ahasenack> I also got the first one, but that one was easy to fix
<ahasenack> heh, look at what I found: https://bugs.squid-cache.org/show_bug.cgi?id=4875
<ahasenack> with a pr and a work-in-progress patch
<ahasenack> goo
<ahasenack> d
<tsimonq2> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<tsimonq2> 40 mins, but I'd really be happy to have quorum. ;)
<slashd> tsimonq2, I'll be there
<tsimonq2> Thanks!
<tsimonq2> !dmb-ping For real this time
<ubottu> tsimonq2: I am only a bot, please don't think I'm intelligent :)
<tsimonq2> darnit
<tsimonq2> !dmb-ping | For real this time
<ubottu> For real this time: cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<tsimonq2> I hate how ubottu is inconsistent in what it wants you to pipe and what it doesn't.
<Unit193> It isn't, you pipe !info as well as factoids.
<tsimonq2> Unit193: Oh?
<tsimonq2> Hmm.
<tsimonq2> infinity: So, I'm now a Core Developer: https://lists.ubuntu.com/archives/ubuntu-devel/2018-August/040436.html
<tsimonq2> infinity: I think you said you wanted to push a Core Developer-only DMB policy at one point, after I became a Core Developer.
<tsimonq2> infinity: So, there you go. :)
<infinity> tsimonq2: \o/
<infinity> tsimonq2: Congrats.
<tsimonq2> infinity: Thanks!
#ubuntu-devel 2018-08-14
<sil2100> abeato: hey! I'll try to review  your PR today :)
<abeato> sil2100, cool, thanks :)
<doko> tsimonq2: https://launchpad.net/ubuntu/+source/metview/5.1.1-1/+build/15233178  version mismatch with Debian?
<doko> jamespage, coreycb: openstack related MIRs needed: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<jamespage> doko: ta - on those this week
<doko> xnox: finalrd: why do we need to handle lib64?
<doko> FAIL: misc/tst-preadvwritev2
<doko> FAIL: misc/tst-preadvwritev64v2
<doko> infinity: ^^^ glibc autopkg test failures triggered by binutils branch update. could you have a look?
<ricotz> doko, regarding "gdb 8.1-0ubuntu6" there seems to be source packages which build-dep on gdb, but build-conflict with gdb-minimal
<ricotz> juliank, hi, https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1762384
<ubottu> Launchpad bug 1762384 in gpgme1.0 (Ubuntu) "libgpgme-dev installs libgpgme-pthread.so in /usr/lib/${DEB_HOST_MULTIARCH}, literally" [Undecided,Confirmed]
<juliank> ricotz: ack
<juliank> maybe MoM stripped an x bit or something
<juliank> ricotz: hmm, libgmpg11.links is executable for me
<juliank> so I wonder why it's not working
<ricotz> juliank, this effects bionic too
<ricotz> juliank, thanks for looking
<juliank> Ah no
<juliank> I looked at the wrong file
<juliank> libgpgme-dev.links is missing the executable bit
<ricotz> juliank, is this link actually needed?
<juliank> If something passes -lgpgme-pthread
<ricotz> while this is suppose to fix some kde build failures? this wouldn't worked so far?
<juliank> I don't know if it fixes anything or not
<juliank> I fixed cosmic now
<juliank> will do bionic shortly
<ricotz> thanks
<juliank> ricotz: this unfortunately does not show up in debdiffs :(
<juliank> need to enhance debdiff!
<doko> ricotz: ?
<ricotz> doko, meaning while gdb provides gdb-minimal, such source packages will fail to build and will require an ubuntu-delta
<ricotz> just ran in to debian's rustc which does have those gdb build-deps/conflicts
<doko> then file a bug report against rustc
<ricotz> afaics a real empty arch-all package would not cause such an issue
<doko> there's no reason for that conflict
<ricotz> rustc won't be synced, jfyi that this might cause problems
<doko> chrisccoulson: ^^^ please fix rustc
<juliank> ricotz: unfortunately ftbfs /bin/bash: line 1: /usr/bin/python3.7: No such file or directory
<juliank> it only has a python3-dev dep, but needs python3-all-dev ugh
<tsimonq2> doko: ack, will fix later unless you want to JFDI.
<psusi> sil2100: I thought you were going to simply change grub-install to switch to grub-pc instead of grub-efi in the case of no ESPs, but instead, if I am reading this correctly, you made the installer simply refuse to offer to do a side-by-side install with a bios mode install but booted in EFI mode?
<psusi> if so that seems like bad ux; they should be able to do a side by side install and simply have it work.
<sil2100> psusi: where did you read that?
<psusi> ohh, right... re-use means re-use the existing partition with no partition table changes and replace the existing OS there
<psusi> as opposed to side-by-side... I think I see now.. bug @1766945
<sil2100> psusi: yes, that's the only case that's not being offered as it would require doing partition changes in an option which, by definition, shouldn't do any partition changes
<psusi> wait... this still doesn't sound right... side-by-side creates an ESP, causing the computer to switch to booting in EFI mode, then that break's the existing bios booting install
<sil2100> As re-use partition means: 'use the very exact partition and install ubuntu on it', as it would result in no ESP and not being able to boot into the system in the current mode
<sil2100> It shouldn't break BIOS booting, the ESP partition is simply appended to the partition table
<psusi> and of course, creating an ESP on an MBR disk that also already has an existing OS in it is going to be a twisted mess what with the 4 primary partition limit
<psusi> yes, but if grub-efi takes over the boot process, you can not chainload the existing bios mode OS
<sil2100> Did you you just reproduce such an issue?
<psusi> no
<juliank> Isn't grub capable of chainloading bios files in EFI as long as the compat thingy is enabled in EFI
<juliank> ?
<psusi> I don't think son
<psusi> once the computer starts in EFI mode, there is no BIOS
<psusi> or at least... you can't count on it being there... maybe current implementations don't bother getting rid of it?
<psusi> but I'm pretty sure the last time I looked at the grub code, grub-efi's chainload command is expecting to load a .efi program
<juliank> ok
<psusi> sil2100: did you test a side by side install with freedos or Windows?  Because I'm pretty sure those will fail... with another bios mode install of Ubuntu it is fine because grub-efi doesn't chainload grub-pc; grub-efi just imports the menu entries to load the other install's kernel
<sil2100> psusi: I personally didn't test that case, but I think jibel did as part of some point-release related testing
<sil2100> jibel: ^
<psusi> I'm not sure if Windows still puts its EFI loader on the disk when installed in bios mode ( what release of Windows even supported EFI?  Windows 7?  I guess XP is too old to worry about )... but I'll bet dollars to doughnuts that you won't be able to boot FreeDOS after doing this
<psusi> though I suppose that may be a small enough of a concern to not worry about too... who really uses freedos?
<sil2100> If that's the case then it's certainly a bug worth filling in
<psusi> where is the windows efi boot loader?  isn't it c:\BCD\something?
<psusi> ahh, here we go... EFI/MICROSOFT/BOOT/bootmgfw.efi
<psusi> so yea, looks like it is on the ESP, which you don;'t have if installed in bios mode, so a side-by-side mode install with windows already in bios mode will break it
<psusi> ohh, look at that... I just searched this bios mode windows system and it has a copy under C:\Windows\Boot\EFI... so maybe you could chainload that and get it to boot, but I don't think that's where grub-probe currently looks for it
<teward> anyone know whether there's a way to delay a systemd unit from starting until after both IPv4 and IPv6 networking are 'up' and 'configured' on a system?  got an nginx bug that looks like a race condition between nginx starting and network being 'up', and it's being problematic as a result...
<teward> so i'm trying to see if there's a way to alter the systemd service/unit to wait until v4 and v6 are up
<teward> (even if it's just local/link-only v6)
<cyphermox> psusi: side-by-side install would create a new ESP, but only if the system was previously booting in BIOS and now booted EFI -- that's already a tiny minority of cases. Furthermore, grub will still run os-prober and detect the other Linux installs, and should be able to boot them still, up until we enforce that kernels are signed
<cyphermox> as for Windows, any recent windows will already have an EFI bootloader
<cyphermox> old Windows do chainload fine
<cyphermox> and the new Windows would, too
<psusi> cyphermox: it is not a tiny minority of cases.. we get hundreds of apport crash reports every month of people doing just that.  You can not chain load bios booting OS from EFI grub
<cyphermox> (windows already gets chainloaded by grub using bootmgfw.efi, and that validates because the right keys are in firmware)
<psusi> only if bootmgfw.efi is found on the ESP... if it was a bios mode install of Windows, it won't be
<cyphermox> you can't chain load, but you absolutely can load the kernels for linux installs, up until we disable fallback to unsigned.
<psusi> yes.. linux installs.. but not freedos or windows
<cyphermox> and the issue you're refering to for Windows is an os-prober bug
<cyphermox> there's nothing stopping os-prober from detecting bootmgfw.efi from elsewhere than /EFI/Microsoft/whatever
<psusi> yea, if os-prober was smart enough it probably could find the copy of the windows EFI boot loader and chainload it even if there is no ESP and that *probably* will work
<cyphermox> freedos would chainload just as fine.
<psusi> no it won't... you can not chainload a bios OS from grub-efi
<cyphermox> psusi: you're free to disable Secure Boot.
<psusi> I'm not even talking about secure boot
<cyphermox> psusi: of course unsigned things don't load if you expect Secure Boot to be enforced, but chainloading is chainloading
<cyphermox> maybe there's a bug, I don't know
<psusi> no... chainloading in grub-efi means load and execute another PE EFI image in EFI mode
<psusi> grub-efi can not chainload a bios MBR
<cyphermox> psusi: there's no way around the fact that it's possible for some things to break if people are changing their firmwares
<psusi> they don't *want* to change their firmware... they don't even know the difference
<JanC> I wonder: is that a GRUB limitation or a UEFI limitation?
<psusi> they just have a working bios mode install and accidentally booted the ubuntu installer in EFI mode
<cyphermox> psusi: how do you accidentally boot the ubuntu installer in EFI mode?
<psusi> JanC: UEFI... if you boot in UEFI mode, there is no bios, you can't switch back to real mode and make interrupt calls
<psusi> cyphermox: because they don't know the difference?  they just hit whatever it takes to get the cd to boot
<psusi> and in most firmwares, it is not clear which mode yuo are booting in
<cyphermox> psusi: to qualify this; how do you do so and then be completely unable to boot back in BIOS?
<psusi> unless you know the subtle little difference to look for... like the fact that it actually calls it "ubnuntu" in efi mode, isntead of just "boot from usb"
<cyphermox> yes. you'll get varying things in a boot menu. that means you'll still be able to boot your device in "legacy" mode should you choose to.
<psusi> they could figure out how to force the machine to boot in bios mode maybe, but by default, we will configure it to boot in EFI mode, and it will do so.. and once grub-efi is booted, it can no longer chainload back into bios mode
<cyphermox> but we should also take care to help users transition from legacy to UEFI, which is what sil2100's changes are doing.
<psusi> except that the transition doesn't really work for them unless we can manage to have a working grub menu entry that still boots their old os
<cyphermox> psusi: my point is, if you accidentally booting in UEFI; you can also accidentally boot in legacy mode, and grub installs both to a MBR and to ESP; if one fails they will try another one
<psusi> you can't really accidentally boot in MBR mode from your hard disk... once the EFI variables are in place to boot in EFI mode, that's what the system is going to do.. it's only when people are trying to boot from install media that they can get the mode wrong
<psusi> then if we install in efi mode they won't get a grub entry to boot windows any more
<psusi> and will have to figure out how to go into their firmware and demand that it boot in legacy mode to get into windows
<psusi> heck, if we also install grub to the MBR even that won't work
<psusi> since our grub.cfg won't have a chainloader +1 stanza because that is only generated if os-prober is run not in EFI mode
<cyphermox> psusi: you're missing the fact that if they managed to have both the legacy and UEFI options, their firmware is UEFI pretending to be BIOS. There's only so much we can do; being able to install to MBR and ESP simultaneously is about as much as you can do, and then deal with those who don't understand, did it wrong, and tell them how to switch back to legacy (if necessary)
<psusi> well as things stand now the only thing they will be able to do to get back into their windows is to boot the windows install cd ( if they even have one ), and run FIXMBR to dig grub out of the MBR and put the MS loader back
<cyphermox> we're not actively trying to break anyone's computer; mistakes happen, but most things already understand EFI, and some will in fact insist on it (hello Windows)
<cyphermox> psusi: I suggest you file a bug, and possibly include a patch to let os-prober detect the Microsoft bootloader from its alternate location?
<cyphermox> that would at least deal with that BCD copy for Windows 10.
<psusi> yea... but the only way to deal with freedos is to not force the machine to efi mode and just install grub-pc
<cyphermox> tough luck for freedos I guess, for one thing there's nothing really stopping them from supporting EFI
<psusi> sure there is... it's DOS..
<psusi> it kind of runs in real mode with bios by definition
<cyphermox> and their kernel can't emulate interrupts?
<psusi> well now you are talking about just running dosemu under linux with freedos installed in the emulator
<psusi> of course one of the reasons people use freedos on bare metal is to be able to run bios update utilities that many vendors still only support from dos
<psusi> at least they did the last time I looked
<psusi> maybe they have finally all gotten with the times, I dunno...
<cyphermox> not all manufacturers have, but some never will, that doesn't mean freedos can't ever do its thing by booting in EFI and say, remaining in BootServices.
<psusi> it would have to actually run in protected mode then use v86 mode to emulate bios to run the applications
<cyphermox> in any case, you can still boot with CSM to load legacy things.
<psusi> yea, but if we also installed grub-pc, then you still get grub with no windows menu entry
<cyphermox> we install grub-pc, if people manage to start grub-pc, then they will get grub-pc, and a windows with no EFI loader will work.
<psusi> their grub.cfg won't have a windows option in it
<psusi> unless they boot ubuntu in bios mode and run update-grub
<psusi> so I guess that's a way out... force firmware to boot in legacy mode... load ubuntu, run update-grub, then you can reboot and get into either
<psusi> but why are we making them go through all of that instead of just sticking with grub-pc only?
<cyphermox> because the installer booted in UEFI, and you can't know whether it's an error or intended, so we install both bootloaders, and users will decide via what way they boot the devices
<cyphermox> if it so happens that they boot everything with CSM enabled, but somehow their firmware can only do UEFI for USB keys or CDROM, then things will keep working.
<cyphermox> we don't need to actively break the installer, fail the install, or write a cryptic message telling the user that "this might not work". They're installing Ubuntu, we're doing our best to give them an installation of Ubuntu that works, and doing our best to keep all the other things working too.
<psusi> of course not... that message needed to go... but we should just assume that they don't want us to change their boot mode and stick with grub-pc
<psusi> since you know that will boot both operating systems correctly
<cyphermox> no, it does not. It's actively going against people who genuinely decide to boot in UEFI and install in UEFI.
<psusi> anyone who actually wants to switch should format the drive and do a clean install of Windows *before* installing Ubuntu
<psusi> not install Ubuntu and then no longer be able to boot their Windows
<slangasek> infinity: hi, are you running the TB meeting?
<sarnold> Unit193: congratulations on getting privileges I assumed you already had :D
<Unit193> sarnold: Hah, thank you very much!
<Unit193> sarnold: FYI, I'm not a DD (yet) either. :>
<sarnold> Unit193: that's is *also* a surprise :)
<Unit193> In process of, though.
<sarnold> even though I think I've been told both of these things before
<sarnold> also did you realize it's august?
<Unit193> My sister's birthday was the 1st, I did realize.  Not sure what context I'm supposed to realize it in though. >_>
<rbasak> Is your sister Unit192 or Unit194? :-P
<Unit193> Paha.
<Unit193> Arguably 192, but I usually claim to have superseded prior versions.
<sarnold> well I meant  in the general "things that surprise me but don't surprise other people" sense :)
<sarnold> but good on you for re3mmebering your sister's birthday :D
<Unit193> (I don't know when the other's is.)  Ah!  Well I nearly missed the DMB meeting, only saw it because of the factoid use here.  I was busy dealing with spam. :P
<sarnold> :(
#ubuntu-devel 2018-08-15
<superm1_> infinity, ping.  I wanted to talk to you about what's happening with signed EFI packages in cosmic (Eg https://launchpad.net/ubuntu/+source/fwupdate-signed/1.20)
<superm1_> since debian started making signed packages it looks like they're also autosynced into the wrong pocket (https://launchpad.net/ubuntu/+source/fwupdate-amd64-signed) but that causes ubuntu signed packages to fail
<superm1_> also their signing service isn't running on every upload, so it's even out of sync now too
<superm1_> so I think unless Ubuntu intends to move to the same signing solution as Debian some time in $future using those template packages, those autosynced packages need to get blacklisted to prevent this problem
<doko> coreycb, jamespage: rejected zvmcloudconnector, incomplete copyright. also do you really need all the alternatives, does it matter which Python version is used for these binaries?
<doko> coreyb, jamespage: rejected vaultlocker, incomplete copyright again
<doko> tjaalton: rejected jboss-annotations-1.2-api, incomplete copyright
<tjaalton> doko: incomplete how?
<doko> tjaalton: Oracle not listed
<tjaalton>            2011, Oracle and/or its affiliates
<tjaalton> sure is
<doko> oops
<doko> tjaalton: and dogtag-pki autopkg tests are failing
<tjaalton> alright
<jamespage> doko: working those both now
<jamespage> doko: vaultlocker re-uploaded with complete copyright
<jamespage> doko: re zvmcloudconnector - the d/copyright looks to have an extra copyright holder not in the upstream source which I have dropped
<jamespage> doko: anything else I have missed
<jamespage> doko: re py2 package - right now we do still need that as this is a depends for nova
<jamespage> doko: python-future is needed for the latest python-pysaml2 - its been in main before so can we re-promote that one?
<jamespage> I subbed ubuntu-openstack for bugs
<seb128> doko, hey, could you have another look to https://bugs.launchpad.net/ubuntu/+source/cpdb-backend-cups/+bug/1747760 and https://bugs.launchpad.net/ubuntu/+source/cpdb-libs/+bug/1747759 to see if Till's fixes are enough for you?
<ubottu> Launchpad bug 1747760 in cpdb-backend-cups (Ubuntu) "[MIR] cpdb-backend-cups" [High,In progress]
<ubottu> Launchpad bug 1747759 in cpdb-libs (Ubuntu) "[MIR] cpdb-libs" [High,In progress]
<seb128> doko, what are the chances https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1770877 get reviewed before ff?
<ubottu> Launchpad bug 1770877 in tracker-miners (Ubuntu) "[MIR] tracker-miners" [Undecided,New]
<rbasak> Could an AA-type please review bug 1778041? For binary package disappearances in an SRU. I'm not sure what needs to be done, if anything.
<ubottu> bug 1778041 in freshplayerplugin (Ubuntu Xenial) "browser-plugin-freshplayer-pepperflash broken" [High,In progress] https://launchpad.net/bugs/1778041
<doko> seb128: I'm just back for two days ...
<doko> jamespage: vaultlocker accepted and built
<seb128> doko, wb, I hope you had nice holidays :)
<seb128> doko, and yeah, sorry to ping you, the MIR team is understaffed and things are just sitting there unsure to get them unblocked :/
<doko> coreycb, cpaelzer, nacc: is php 7.3 as the default planned for cosmic?
<cpaelzer> ahasenack: rbasak: ^^
<cpaelzer> maybe to discuss on the standup
<rbasak> I'm reluctant
<cpaelzer> me as well
<rbasak> php-defaults is still in excuses for ?7.2
<rbasak> That part isn't FF-critical I don't think.
<cpaelzer> lacking nacc this was a bit orphaned most of this cycle with resolution planned next cycle
<rbasak> Yeah
<cpaelzer> I msut admit at least I haven't looked for php at all recently
<rbasak> That part isn't FF-critical I don't think -> but going for 7.3 seems like too much of a stretch to me without nacc. I'm not familiar enough with it all yet.
<rbasak> Though php-defaults is in sync now, so it'll autosync if Debian do it. Seems unlikely before our FF though.
<jamespage> doko: ta
<psusi> bug #1683105 has had a patch waiting for someone to apply since last december... could someone please apply it?
<ubottu> bug 1683105 in dmraid (Ubuntu) "Installation of DMRaid should automatically add necessary modules to /etc/initramfs-tools/modules" [Medium,Triaged] https://launchpad.net/bugs/1683105
<nacc> doko: cpaelzer: rbasak: i really apologize about that. The hard part right now is we had to add a bunch of delta to universe packages for phpunit in 18.04
<nacc> and many of those packages are still not updated in debian, when i last looked
<nacc> and since debian, last i checked as well, still wasn't gating their CI, it will fail in our system; so they will need merges
<nacc> fairly trivial merges, but merges nonetheless
<nacc> i just haven't had the time this cycle :(
<GunnarHj> rbasak: Thinking of bug #1778041. If I hadn't SRU'ed the fix, people with one of the dropped packages installed might upgrade to 18.10 and then keep having the old package installed. So we don't usually have a model to make sure that packages which are dropped from archive are uninstalled, do we?
<ubottu> bug 1778041 in freshplayerplugin (Ubuntu Xenial) "browser-plugin-freshplayer-pepperflash broken" [High,In progress] https://launchpad.net/bugs/1778041
<rbasak> GunnarHj: I think do-release-upgrade might take care of that. I'm not sure exactly.
<rbasak> GunnarHj: if nobody else chimes in, how do you feel about shipping the binary packages but empty? I think that'd be the least harmful, even if it turns out later to be overkill, since it leaves thd door open to anything later without having made it difficult, IYSWIM.
<rbasak> afk now, but back later.
<GunnarHj> rbasak: I thought that do-release-upgrade only takes care of packages no longer needed as dependencies - like 'apt autoremove'. But I'm not sure either.
<GunnarHj> rbasak: Sure, I can add empty packages for the two dropped binaries, if you think it's motivated.
<nacc> it would be nice if it did something more, if it doesn't know, based upon, perhaps ubuntu-support-status output, etc.
<nacc> *if it doesn't now
<GunnarHj> rbasak: But before doing so, please also consider that the remaining binary browser-plugin-freshplayer-pepperflash is - unlike before - only built on amd64 and i386. (See comment #4 in the bug report for the reason.) I suppose that can't be handled through empty packages.
<GunnarHj> nacc: Would make sense. But can you confirm that no such thing is in place currently?
<nacc> GunnarHj: i can try :)
<GunnarHj> nacc: Don't spend too much effort on it. It's merely a side discussion when discussing a special SRU case.
<nacc> yep, understood
<rbasak> GunnarHj: that's a good point.
<rbasak> sil2100 accepted the Bionic package so I'd like his opinion but he's not here right now.
<rbasak> I'm also reluctant to dictate anything on this one, since I'm not certain of any right answer here, and others will know more. But I also don't want to block you :-/
<Unit193> https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-1000544.html Debian 902720 was fixed in Debian, so cosmic is covered at least! :D
<ubottu> Debian bug 902720 in ruby-zip "CVE-2018-1000544" [Grave,Fixed] http://bugs.debian.org/902720
<ubottu> rubyzip gem rubyzip version 1.2.1 and earlier contains a Directory Traversal vulnerability in Zip::File component that can result in write arbitrary files to the filesystem. This attack appear to be exploitable via If a site allows uploading of .zip files , an attacker can upload a malicious file that contains symlinks or files with absolute pathnames "../" to write arbitrary f... (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000544)
<Unit193> https://launchpadlibrarian.net/383593876/ruby-zip_1.2.1-1_1.2.1-1.1.diff.gz interesting diff though.
<sarnold> uhhhh
#ubuntu-devel 2018-08-16
<Unit193> https://salsa.debian.org/ruby-team/ruby-zip/commit/c2b41627b94269940c2cd4aa40f48c0b47c865a2 looks just as odd.
<Unit193> new file mode 100644
<Unit193> index 0000000..e74ee19
<Unit193> --- /dev/null
<Unit193> +++ b/test/data/symlink.zip
<GunnarHj> rbasak: A day or two extra is no big deal. Would be good if you could consult with sil2100 soon.
<lovepopsickle> why is booting on ubuntu 18.04 slower than 16.04
<mwhudson> entropy
<mwhudson> oh wait, sorry i though i was in a different channel :)
<mwhudson> lovepopsickle: systemd-analyze blame?
<lovepopsickle> mwhudson, not sure
<lovepopsickle> mwhudson, its not a huge difference about 15 seconds added time
<mwhudson> lovepopsickle: miiight be something to do with waiting for ipv6 ras?
<mwhudson> lovepopsickle: but with the info you've provided we really can't say
<lovepopsickle> i think i have ipv6 disabled
<mwhudson> lovepopsickle: if you pastebin the output of systemd-analyze blame for both systems, at least that's something to start with
<lovepopsickle> mwhudson, https://zerobin.net/?f842c3137adfb4a3#XVRu0obOxXb9e11nj6jU2HFtlucVFkLtRsMxzXA5ptE=
<lovepopsickle> mwhudson, https://askubuntu.com/questions/1029050/long-boot-times-on-18-04
<lovepopsickle> https://askubuntu.com/questions/1038368/slow-boot-on-ubuntu-18-04
<lovepopsickle> https://www.reddit.com/r/Ubuntu/comments/8dws67/can_we_talk_about_the_boot_time_on_ubuntu_1804/
<lovepopsickle> https://www.quora.com/Why-did-Ubuntu-18-04-slow-down-on-booting-How-do-I-solve-it?share=1
<lovepopsickle> looks like there is a bug going on
<lovepopsickle> plymouth-quit-wait.service looks like the major cause
<lovepopsickle> bug report: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1742063
<ubottu> Launchpad bug 1742063 in systemd (Ubuntu) "Systemd taking long time to boot into desktop 18.04" [Undecided,Confirmed]
<lovepopsickle> mwhudson, did you see the blame link?
<mwhudson> lovepopsickle: i did but it didn't mean very much to me i'm afraid
<lovepopsickle> i mean its basically the same issue as those other links
<mwhudson> i'm not sure that's true
<mwhudson> there's no wait-online on there for example
<lovepopsickle> not sure what you mean. What I was saying is that plymouth-quit-wait.service seems to be taking about 30 secs and there is a bug report on it
<lovepopsickle> your saying i should have had a wait-online?
<lovepopsickle> its the plymouth-quit-wait that seems to be the common theme
<lovepopsickle> or is that the total seconds?
<lovepopsickle> well its not a huge deal and maybe it will get fixed later. Those links did not see to have any good solutions maybe it will get worked out later
<lovepopsickle> it doesnt take that long but it was noticeable from before.
<jamespage> doko: re zvmcloudconnector I've re-uploaded with a tidied d/copyright - I could not find any missing copyright information, but there did appear to be a surplus copyright holder in d/copyright
<seb128> juliank, hey, you previously merged wpa, could you do it again for the current revision? it fixes a CVE so would be nice to get into cosmic
<seb128> https://packages.qa.debian.org/w/wpa/news/20180808T210425Z.html
<juliank> seb128: ack
<seb128> thx
<juliank> I should really do some more merges
<Unit193> Merges are nice, dropping delta is even better. :>
<juliank> true
<juliank> very true
<jamespage> doko: ta ;)
<jamespage> on the assumption it was you
<psusi> so I'm investigating reports of grub postinst failures and it looks like set -e is terminating the script on this line:
<psusi> device_map="$(grub-mkdevicemap -m - | grep -v '^(fd[0-9]\+)' || true)"
<psusi> shouldn't that || true catch any errors and keep the entire pipeline from failing and so it should not be possible to terminate the script here?
<cjwatson> You'd have thought.  I'd suggest trying to construct smaller test cases
<cjwatson> set -e has a few weird edge cases
<cjwatson> And they're likely highly shell-dependent, so check what /bin/sh is
<psusi> cjwatson: grub-pc.postinst's shbang calls for /bin/bash
<cjwatson> so it does
<psusi> replacing either side with false doesn't seem to bail out of the script....
<psusi> hrm... what if the child is terminated with a signal?
<psusi> nope... script still continues....
<psusi> how could that grep be the last thing that is run before the postinst errors out?  weird...
* Laney changed the topic of #ubuntu-devel to: Archive: open (Cosmic Cuttlefish), auto-sync disabled temporarily | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first
<jbicha> Laney: something is wrong with the armhf autopkgtests (excuses says Test in Progress for all of them), I retried the ones from today, but there is more from yesterday
<Laney> jbicha: Please additionally ping slangasek, sil2100 (although not here atm), juliank
<Laney> this is not a one person show any more
<Laney> thankfully, because I can't really look atm
<jbicha> ok, good :)
 * juliank has meeting now
<Laney> an example of one that you accuse of going missing would be helpful for $person to look in the logs
<Laney> ah, what the hell, I just restarted everything, looks like the machine got a reboot :(
<jbicha> thanks
<bdmurray> roaksoax: It looks like there may be a regression with the maas SRU. https://errors.ubuntu.com/problem/243e461131f7d9c36fd09fee3e90d74a01401d5c
<ahasenack> rbasak: hi, can you click the lander signoff one more time please? :) https://bileto.ubuntu.com/#/ticket/3351
<rbasak> ahasenack: done
<ahasenack> rbasak: thanks
<ahasenack> sil2100 isn't here, I wanted to ask him why I can't do that step
<rbasak> Perhaps it's restricted to uploaders but bileto doesn't know about packagesets and things?
<ahasenack> it's probably related yes
<ahasenack> but that restriction should apply to the "publish" button
<ahasenack> I can do that step with krb5, which I can upload
<ahasenack> squid (not squid3) is NEW
<roaksoax> bdmurray: howdy, yes I saw that email. That said, who maintains the registration form ?
<bdmurray> roaksoax: I do
<roaksoax> bdmurray: ok, its not a regression. The same happens in older versions of MAAS
<bdmurray> roaksoax: Could you show the error with previous versions?
<howard> Hi!
<howard> I'm looking for a breakdown of the standard options of the /etc/lsb_release file as I'm trying to modify it to describe a custom release
<howard> Are there any options beyond the DISTRIB_ID, RELEASE, CODENAME, and DESCRIPTION fields?
<rbasak> howard: see the lsb_release manpage. I believe the standard interface is the command, and the /etc/lsb_release file is an implementation detail.
<rbasak> If you want to parse a file, then you might find https://www.freedesktop.org/software/systemd/man/os-release.html more useful.
<rbasak> (/etc/lsb_release file is an implementation detail which you cannot rely on to be stable)
<howard> I felt more okay with relying on it because I'm going to be writing the file. It's not a user lib trying to read OS information
<howard> rbasak: like, I guess I mean I'm trying to edit the implementation detail
#ubuntu-devel 2018-08-17
<tsimonq2> Would anyone (cjwatson?) happen to know how lp:ubuntu-sponsoring is deployed?
<tsimonq2> I'd like to convert it to Git.
<cjwatson> tsimonq2: Haven't the foggiest
<tsimonq2> cjwatson: Do you know where I can find who knows? :P
<cjwatson> tsimonq2: Nope
<tsimonq2> cjwatson: Mkay, thanks anyway.
<Unit193> Achievement unlocked: Found something cjwatson doesn't know.
<tsimonq2> ^
<cjwatson> Heh
<cjwatson> I'd start by asking people who've committed to that branch
<cjwatson> (and who are still around)
<tsimonq2> If Laney or bdmurray don't know, I *think* I still have a way to contact dholbach, if he remembers.
<tsimonq2> Otherwise I just about cut the sponsoring queue in half, and I plan on going further tomorrowish, but I want to eventually (but slowly, ELITTLETIME) work on refining the queue in general.
<Mirv> smoser: wow, huge thanks for pdftk snap, and thanks to command-not-found patchers who have added snap support :D
<wxl> whoa pdftk snap. cool.
<Mirv> I was like "nooo, gone in bionic"
<Mirv> but snap saved
<Mirv> apparently it doesn't build with GCC 7
<Mirv> but in my use case I have a note that eg pdfjoin tool breaks hyperlinks, pdftk does what I want
<Laney> tsimonq2: Well done on your work there. It's probably a cron script on some machine. I could find out if necessary - but is it that important to switch it?
<tsimonq2> Laney: bzr is painfully slow, even with a wrapper.
<tsimonq2> And thanks.
<Laney> what is painfully slow about it?
<tsimonq2> Pushing/pulling.
<Laney> You plan to do a lot of that on the sponsoring queue?
<tsimonq2> I plan on working on it a bit, yeah.
<Laney> And pushing it *that* often?
<tsimonq2> We're talking five seconds vs 30.
<tsimonq2> I push frequently enough to make it annoying.
<Laney> But even at a 25 second deficit, how often are you planning to push the spnosor queue's branch?
<Laney> It's probably pulled from trunk with each run, so you should only be pushing things you actually want to deploy ...
<tsimonq2> I don't know if I can give you a quantitative value.
<tsimonq2> And that's yet another advantage of Git, multiple branches.
<Laney> I understand the differences between the two.
<Laney> I'm challenging the benefit gained by someone having to go find out how this is deployed and update that to work with git, when the project is not active at all.
<tsimonq2> I guess I personally see the ROI for someone taking maybe 5 minutes to reclone a repo and sed a crontab.
<tsimonq2> It costs more overhead to continue using Bazaar than to switch it.
<rbasak> It does make it easier for others to contribute to
<rbasak> It's much more of a pain trying to remember how to do things with bzr at least. And then there are all the things that you can't do easily (eg. squash)
<Unit193> But rbasak!  Brz is cool.
<Unit193> !info brz
<ubottu> brz (source: breezy): easy to use distributed version control system. In component universe, is optional. Version 3.0.0~bzr6852-1 (bionic), package size 36 kB, installed size 72 kB
<Unit193> There is one feature I like in bzr, lp-propose.  Though it is known to have unexpected results.
<rbasak> IIRC sparkiegeek (not here) has a git replacement equivalent for LP for that?
<Unit193> That sounds shiny.
<cjwatson> rbasak: snap info gitlptools
<rbasak> Thanks!
<rbasak> Unit193: ^
<Unit193> Is there a source for that?
<rbasak> https://launchpad.net/gitlptools it loos like
<Unit193> Hmm, no tags..
<Unit193> tsimonq2: Looks like something you might want to know about, and package.
<smoser> Mirv: thanks for sharing.  Would you upvote https://askubuntu.com/questions/1028522/how-can-i-install-pdftk-in-ubuntu-18-04-bionic ?
<smoser> unless you honestly think that shell-script-blob (currently the top aswer) is a better way of distributing software :)
<Mirv> smoser: upvoted the snap one, yes I think it should be on the top...
<bdmurray> tsimonq2: What was the original question?
<bdmurray> rbasak: Are you familiar with postgresql or is there somebody else on the server team I should ping?
<ahasenack> bdmurray: what's up? Maybe I can help, rbasak and cpaelzer are eod
<ahasenack> cpaelzer prepared the recent postgresql sru
<bdmurray> ahasenack: its about postgresql and release upgrades. postgresql is in the release upgrader blacklist b/c of bug 871893 and I wonder if its still relevant.
<ubottu> bug 871893 in update-manager (Ubuntu Oneiric) "After upgrading postgresql-databases are not accessible any more" [Critical,Fix released] https://launchpad.net/bugs/871893
<bdmurray> see also bug 1787349
<ubottu> bug 1787349 in ubuntu-release-upgrader (Ubuntu) "postgresql-plperl-9.5 blocks do-release-upgrade from 16.04 to 18.04" [Undecided,New] https://launchpad.net/bugs/1787349
<ahasenack> that's from 2011
<ahasenack> I have no idea
<bdmurray> Okay, I'll email ubuntu-devel
<jbicha> slangasek: https://autopkgtest.ubuntu.com/running is outdated, I triggered those cmake/gnutls runs last night
<cpaelzer> bdmurray: I neither hae background on this postgres thing
<cpaelzer> this was all in the time pitti cared for it
<cpaelzer> bdmurray: you should set him to CC on this mail
<cpaelzer> maybe he can shed some light
<Unit193> sbeattie: Thanks for the sponsorship.
<sbeattie> Unit193: you're welcome, thanks for preparing the update!
<tsimonq2> bdmurray: Where's lp:ubuntu-sponsoring deployed?
<bdmurray> tsimonq2: you mean the name of the server?
<tsimonq2> bdmurray: Right; that, and how it's deployed. I'd like to convert it to Git.
<tsimonq2> bdmurray: I can do the conversion, I just need someone with access to button push.
<bdmurray> tsimonq2: Its on cranberry and laney and I, and some others, have access.
<rbasak> Are you sure it's on cranberry?
<rbasak> Not rootstock?
<tsimonq2> There, it's converted: https://git.launchpad.net/ubuntu-sponsoring
<bdmurray> rbasak: yes
<rbasak> Oh. OK
<rbasak> bdmurray: what does it run as, OOI?
<rbasak> Ah
<rbasak> ubuntureports
<rbasak> I see it. Nice to know, thanks.
<bdmurray> rbasak: Yeah, I guess you have access too.
<rbasak> Yes
<rbasak> Though I won't push any buttons without others telling me that's OK :)
<rbasak> (since my access is only incidental to other stuff)
<tsimonq2> I guess not being a Canonical employee there's no way for me to have access, correct?
<rbasak> Though I was left with co-adminship of ~ubuntu-sponsors at one point
<bdmurray> I haven't looked at it in so long as it is...
<rbasak> tsimonq2: I assume so, since it's shell access on some Canonical infrastructure.
<rbasak> Though presumably all the actual code that's running is in the public repo
<tsimonq2> I would even argue that https://launchpad.net/ubuntu-sponsoring should be "maintained" by ~ubuntu-sponsors, not ~ubuntu-dev, because anyone from ~ubuntu-dev can join ~ubuntu-sponsors, and I'd argue that you should be sponsoring things to get commit access to the associated infra.
<tsimonq2> bdmurray, rbasak: If you both agree, it's a flip of a switch. Otherwise I can ask for more wider feedback on e.g. ubuntu-devel.
<tsimonq2> rbasak: Canonical infra> ack.
<rbasak> tsimonq2: I have no objection. Though I think peer review might be a good idea (or at least the opportunity; if nobody objects after a while then we shouldn't cause policy to enforce blocking progress)
<tsimonq2> rbasak: Peer review on the policy change or code changes in general?
<rbasak> On code changes in general
<tsimonq2> Sure.
<tsimonq2> I know dholbach drove that for a while, but I've just been making commits that seem useful.
<tsimonq2> With Git, this will become much easier to just put commits in feature branches. :)
#ubuntu-devel 2018-08-18
<tomreyn> what's the package implementing the recovery menu on 18.04 ? i'd like to file a bug.
<tomreyn> oh that's "friendly-recovery"
#ubuntu-devel 2018-08-19
<teward> has a draft for the release notes for Cosmic been created yet?
<mwhudson> https://launchpad.net/~pythoneers/+archive/ubuntu/py37-rebuilds/+build/15269010 <- somehow stuck in building for 3 days?
#ubuntu-devel 2019-08-12
<anon^_^> gpg --keyserver hkps://keyserver.ubuntu.com:443 --recv-keys 7EF33F027E9E4869F46F77E34E72F77D7D158F33
<anon^_^> gpg: key 4E72F77D7D158F33: public key "Launchpad PPA for Micah Lee" imported
<anon^_^> gpg: Total number processed: 1
<anon^_^> gpg:               imported: 1
<anon^_^> however, apt-key fails
<anon^_^> sudo add-apt-repository ppa:micahflee/ppa
<anon^_^> .
<anon^_^> Executing: /tmp/apt-key-gpghome.XNiyRBLgEY/gpg.1.sh --keyserver hkps://keyserver.ubuntu.com:443 --recv-keys 7EF33F027E9E4869F46F77E34E72F77D7D158F33
<anon^_^> gpg: WARNING: Tor is not properly configured
<anon^_^> gpg: keyserver receive failed: Permission denied
<rbasak> anon^_^: please stop spamming the channel. You said you had a question. Please just ask it. We don't need a bug report spammed into the channel - we have the bug tracker to record a bug if that's what you want to do.
<anon^_^> it's a critical bug, i don't have launchpad account
<rbasak> It doesn't sound like it meets our definition of "Critical": https://wiki.ubuntu.com/Bugs/Importance
<rbasak> You can create a Launchpad account.
<Unit193> I have 18.04, I have tor, gpg --refresh-keys works as expected.
<anon^_^> Unit193, yes gpg --refresh-keys works, but add-apt-repository is broken
<rbalint> hi, how do i resolve circular build dependencies in Ubuntu? Should I just upload a "stage1" source package then, after rdeps are rebuilt, the good one or there are extra steps?
<rbalint> (i could not find the wiki page for that)
<rbalint> i'm looking at the loop including golang-google-cloud-compute-metadata-dev
<cjwatson> rbalint: (at least some) archive admins can inject build-deps to resolve loops
<cjwatson> but will need clear instructions on the sequence
<rbasak> mapreri: "Default to checking signatures while pulling a .dsc" -> regresses download of some Ubuntu packages. I'm not sure why.
<rbasak> mapreri: some examples: hoel lyricue net-snmp orthanc-mysql pam-mysql proftpd-dfsg rsyslog
<rbasak> mapreri: failure example: https://pastebin.ubuntu.com/p/vYH7xNm6Zq/
<mapreri> rbasak: because it makes a lot of sense in debian, but doesn't in ubuntu, which doesn't have an equivalent to debian's debian-keyring.
<mapreri> some other canonical employee mailed me the other day about it
<mapreri> so I expect the verification to fail for anything that is not signed by a key in the debian-keyring, which pretty much means ~everything with a direct upload to ubuntu
<rbasak> I see
<mapreri> rbasak: so I'm thinking of https://paste.debian.net/1095441/ - which should keep the validation enabled on debian only (since it subclasses SourcePackage and overrides the pull_dsc() method with a verify_signature=True)
<rbasak> mapreri: sounds good
<Odd_Bloke> Ohh, _that_ explains why I've been seeing those failures a lot recently.  I thought I'd screwed up my GPG keyring or something.
<rbasak> mapreri: can we upload a fix fairly quickly please?
<Odd_Bloke> (Luckily my strategy of ignoring the problem in the hopes it would go away has paid dividends.)
<mapreri> rbasak: I wanted to finally enable autopktest for ubuntu-dev-tools in the next upload, I was waiting on finding enough tuits to do that
<rbasak> mapreri: I don't think a fix for this issue should wait for any other changes.
<rbasak> It's breaking the majority of people who use the package, no?
<mapreri> well, those tools that download source packages, at most.
<rbasak> So most (all?) Ubuntu developers then!
<mapreri> which are arguably the most important of them all
<mapreri> let me see if I can do that all nowâ¦
<rbasak> Thanks!
<rbasak> mapreri: arguably the behaviour is wrong on Debian too - what if someone retires, their key is removed from the keyring, but their last upload remains?
<mapreri> rbasak: well, you proposed that change in the first place
<mapreri> and added a --no-verify-signature to pull-debian-source to override thatâ¦
<mapreri> this was a little more than a month ago, already forgotten? :)
<mapreri> just, your change broke the testsuite, but I noticed only after merging.  my change "Default to checking signatures while pulling a .dsc" was a way to fix the testsuite after that
<rbasak> I noticed --no-verify-signature is attributed to me but I don't remember the detail!
<mapreri> https://code.launchpad.net/~racb/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/326608
<mapreri> oh
<mapreri> that was 2017!
<mapreri> sorry, I looked at month and day without year :3
<rbasak> Perhaps I had hit the Debian verification failure case already?
<rbasak> I'm not sure it was my intention to add additional checking!
<rbasak> mapreri: looks like it needs SourcePackage.pull() adjusting, not pull_dsc().
<rbasak> Otherwise the default of True gets passed through.
<mapreri> good point.  the original report I had was from `backportpackage`, which only uses pull_dsc().
<mapreri> rbasak: could you please confirm that https://paste.debian.net/1095443/ works for you?
<rbasak> Looking
<Odd_Bloke> Do we have any policy about what level of logging should be written to the journal (vs. a package-specific file in /var/log)?
<rbasak> mapreri: confirmed. Reproduced in a fresh eoan container, and I patched /usr/lib/python2.7/dist-packages/ubuntutools/archive.py directly with your patch, and pull-lp-source started working on a problem package.
<rbasak> Incidentally it looks like pull-lp-source is still on Python 2, but I would leave that for now.
<mapreri> most of ubuntu-dev-tools is still py2
<mapreri> it's not a difficult task to migrate it, but requires someone to do it
<mapreri> on that regard, I hoped ddstreet merged his fork that did over a year ago beforeâ¦
<mapreri> rbasak: uploaded, let's see how this goes.
<rbasak> mapreri: thank you for looking at it so quickly!
<rbasak> And sorry for the fallout. I'm not trying to punish you for looking at my MP, honest :-/
<mapreri> don't worry for that bit :)
<hallyn> hm, 'pull-lp-source qemu' on eoan fails on checking the signature
<hallyn> cpaelzer: ^
<rbasak> hallyn: see above!
<hallyn> oh? sorry :)
<hallyn> (finally reading the backlog) zomg
<cpaelzer> oh
 * cpaelzer read the backlog as well now ... oO
<hallyn> it seems to imply that .dsc's didn't use to be verified before?  that surprises me
<hallyn> cpaelzer: so, actually, i was wanting to lok through the source to see - should virtio-blk storage be enabled ?
<hallyn> i'm not finding it in the manpage, at any rate, maybe it's just not there
<cpaelzer> hallyn: I think it is enabled by default, IIRC we have no delta
<mapreri> hallyn: it doesn't really make sense to verify a signature on a ubuntu's .dsc, because ubuntu developres can just change their gpg key whenever they want.
<cpaelzer> let me check
<mapreri> and they are not collected on a keyring either
<hallyn> mapreri: well, but they do keep them on launchpad no?
<mapreri> there is no trust path to them, etc
<hallyn> "it's better than nothing"
<mapreri> we still have no keyring to give to gpg
<hallyn> hm
<hallyn> i wonder how big it would get if we were to just rsync a tree of all the ubuntu developer's pubkeys from lp :)
<hallyn> (as a sidestep to apt-get update if you have ubuntu-dev-tools installed)
<cpaelzer> hallyn: yeah I see virtio-blk.o build and linked - so default-on/no-delta is correct
<cpaelzer> maybe we miss a new manpage since you expect that one?
<hallyn> cpaelzer: great, thanks!  i'll do some more testing
<hallyn> i just thought checking the source would be easier
<hallyn> but, it wasn't :)
<hallyn> i dunno - upstream might just not stick every blockdev type in the manpage.  i just thoght they used to
<cpaelzer> ok, let me know if you find something missing
<hallyn> will do, thx.  (it'll be later this afternoon, unfortunately)
<cpaelzer> as long as you give me a highlight I can collect it the other day then
<hallyn> what i'm looking for is, having an lvm thinpool, i want to be able to dd if=/dev/zero of=/xxx bs=1G count-2;  rm /xxx, fstrim -v /, and then have the backing store be trimmed.
<cpaelzer> so you look for discard being passed on?
<cpaelzer> there is one discard option at -blockdev and more depending on the format (e.g. qcow2 has more)
<hallyn> cpaelzer: well, no - apparently (according to the interwebz) virtio-blk only supports discard with linux 5.0, which I'm not using yet;  and is obsoleted  virtio-scsi does support it.
<hallyn> but when i did 'man qemu-system-x86_64' i didn't find any reference to it. but then virtio-blk also doesn 'tshow up, so i guess it's just not ther.e  it's probably fine :)
<cpaelzer> yeah virtio-scsi is what rharper recommended to jamespage recently for discard as well
<rbasak> hallyn: the problem with best effort for signature is that you can't rely on that for scripting. Otherwise something will inevitably fail.
<rbasak> It could be written to validate against the apt repository signature in the common case that the source package version being downloaded is available in an apt repository I suppose.
<rbasak> But that would need implementing, and it'd have to be a different code path from the general path of being able to grab any version published ever.
<rbalint> cjwatson, thanks! and is injecting ppa-built build deps preferred over doing the loop breaking in -proposed?
<cjwatson> rbalint: I think so
<rbalint> cjwatson, ack, will go that way then
<rbasak> Subject: [proposed-migration] mysql-8.0 8.0.16-0ubuntu2 stuck in eoan-proposed for 13 days.
<rbasak> I know. Please stop spamming me.
<rbasak> Five today so far :-/
<xnox> force-skip-test uploader/rbasak/all
<rbasak> ?
<Laney> rbasak: Can't immediately see from code inspection why that's happening, so I'll add a bit of debugging...
<rbasak> Thanks!
<Laney> this is https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney2/policies/email.py#n176 if you want to play along at home
<Laney> I forgot about that exciting calculation we have there
<Laney> At 13 days age the threshold should be 11 days, and that's what is in the cache
 * Laney blames computers
<Laney> it's not every run either
<GunnarHj> Hi rbasak, do you possibly have time to consider this:
<GunnarHj> https://lists.ubuntu.com/archives/devel-permissions/2019-August/001391.html
<rbasak> GunnarHj: I suppose I should, as a Bangla speaker!
<rbasak> It sounds perfectly fine to me, but I need to check if it needs one DMB member or a quorate number to approve.
<rbasak> IIRC it should be PPU though, rather than personal-* packageset entry
<GunnarHj> rbasak: Had no idea that you speak Bangla. :) I mentioned this to Åukasz when he sponsored the addition of the package, and he thought that the packageset would be fine.
<rbasak> He doesn't seem to be online right now
<GunnarHj> rbasak: Right.
<rbasak> If you're curious, https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Personal_packagesets_and_glob_expansions is our documentation on that.
<rbasak> But this is something we should be able to sort out ourselves and tell you technically how we're achieving it.
<rbasak> Oh
<rbasak> "This is defined as the set that the DMB has agreed that Gunnar may upload, which includes individual packages to which he has PPU, as well as glob expansions."
<rbasak> OK, I'm wrong.
<rbasak> I think we need to treat it as a PPU application though
<GunnarHj> rbasak: With a voting round then?
<rbasak> IIRC, yes, but I'm just trying to find documentation to confirm.
 * rbasak prefers to be consistent about these things
<rbasak> I don't see it being a problem to add you though - makes perfect sense to me.
<rbasak> And nor do I want to make you write up a tedious application or anything.
<rbasak> GunnarHj: I can't find any documentation on an exception so I think a vote is required. Let me add this to our meeting agenda.
<rbasak> GunnarHj: IMHO think your email request is sufficient.
<GunnarHj> rbasak: Ok, that works for me. It means that I'll need to bother my sponsor an extra time, but that's how it is.
<GunnarHj> rbasak: Since you are a Bangla speaker, it would be nice it you could install the package and let me know how useful you think it is.
<rbasak> GunnarHj: I'd be happy to give it a try, but my literacy skills are quite poor and rusty. My spelling is atrocious :-/
<rbasak> I did say speaker, not writer or reader :-P
<GunnarHj> rbasak: Your view would be much more valuable than mine, anyway. I can type à¦¬à¦¾à¦à¦²à¦¾, but that's about it. :)
<rbasak> :)
<rbasak> (incidentally the Ubuntu Mono font completely screws that up)
<GunnarHj> rbasak: Yeah, even I realize that it doesn't look right.
<rbasak> There's a complexity that some Indian writing systems have (Bengali, Devanagari, maybe some more) that vowels appear around consonants. It was never obvious to me which way round Unicode expects them to be encoded for all cases, and it's really common to see rendering get all confused.
<GunnarHj> rbasak: I have seen some Ask Ubuntu questions about problems with such languages in e.g. gnome-terminal. Sometimes I point them to konsole, which seems to handle it better.
<Locutusofborg> hello, do we have some sort of way to know all the delta one particular developer introduced in Ubuntu wrt Debian?
<Locutusofborg> I would like to know how many gcc-9 fixes I did, since now they should go in Debian (including wl-asneeded ones)
<Locutusofborg> and do some NMUs there
<rbasak> The changelog?
<rbasak> Clearly that's not the answer you're looking for, but I'm not sure what I'm missing.
<rbasak> Oh, you mean across all packages?
<rbasak> The sponsorship miner perhaps?
<rbasak> Also grep-merges might be helpful.
<Locutusofborg> rbasak, grep-merges shows only outdated stuff?
<rbasak> There's also https://launchpad.net/~/+uploaded-packages
<rbasak> Locutusofborg: yes, good point
<Locutusofborg> rbasak, problem, is that I keep my merges up-to-date :p
<Locutusofborg> but yeah, I can look for gcc-9 bugs in Debian and compare with rmadison the Ubuntu version
<Locutusofborg> starting from there maybe
<Locutusofborg> https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=doko@debian.org
<rbasak> Or grep your mailbox for queue accepts?
<Locutusofborg> cat page |grep "ftbfs with GCC-9" |cut -f 2 -d ":" |cut -f 1 -d "]" > list
<Locutusofborg> this might work
<Locutusofborg> rbasak, doesn't help in general
<Locutusofborg> I'm not the only one who did fix ld-asneeded stuff
<rbasak> I'm not sure I understand the general specification for your request
<Locutusofborg> I want to start from *my* packages, but it is a good time to send all this kind of delta we have
<Unit193> Is X-GNOME-Gettext-Domain a thing?
<Unit193> (codesearch didn't really pick up anything.)
<Unit193> https://launchpad.net/builders/lgw01-amd64-046 and a couple others seem a bit stuck.  I could build that package on an old P4 in about two minutes. :3
#ubuntu-devel 2019-08-13
<RikMills> rbasak: hi, is there any progress on fixing systemd -> udisk2 post install failure in armhf lxd autopkgtest runners? now seeing this impact tests on latest KDE framewworks
<RikMills> rbalint ^^^ I mean!
<rbalint> RikMills, i'm bisecting the regressions and will upload a package in much better shape today/tomorrow
<RikMills> rbalint: thank you
<ricotz> doko, hi, are there built gcc-7 packages which are working on there own? it seems packages from ubuntu-toolchain-r/test are relying on later uploads
<ricotz> ah sorry, for 16.04/Xenial
<doko> ricotz: no, but you edit debian/rules.defs and regenerate the control file
<ricotz> doko, I assume with_common_libs and with_common_pkgs are the important vars in this case?
<doko> yes
<doko> ricotz: but why would you need that?
<ricotz> doko, I am trying to build libreoffice (6.3 requires gcc 7) on xenial
<ricotz> and avoid interferences with newer commons libs
<ricotz> or is there still a chance that xenial will receive such a toolchain update?
<ricotz> like bionic getting gcc-8
<doko> no, bionic was already released with gcc-8
<ricotz> hmm I see
<GunnarHj> Hi mapreri, did you see my latest mail last night?
<mapreri> GunnarHj: I did, but I'm caught up in something else today
<mapreri> so it's there, in my inbox
<GunnarHj> mapreri: Ok, good. Let's talk when you have a minute.
<mapreri> I have a minute right now, but not much more
<mapreri> GunnarHj: i.e., bring your query ;)
<GunnarHj> mapreri: Not much of a query, really. Just hoping that you'll find the time to upload the backports based on current eoan. The reasoning is in the mail.
<mapreri> GunnarHj: aye, I think I will.  Maybe tonight or tomorrow.
<GunnarHj> mapreri: Sounds great! See ya.
<mapreri> o/
<juliank> Laney: That black thing looks really interesting, I'm about to run it on python-apt
<juliank> It's a shame there's no git-black which only formats the hunks you are changing
<juliank> (Like clang-format does for C(++); what we use in apt to progressively fix formatting)
<Laney> juliank: why you highlight me?
<Laney> but thanks for pointing me to it, TIL :P
<juliank> Laney: Wasn't it you who pointed me to it?
<Laney> nope
<juliank> then it was ahasenack?
 * juliank is confused
<ahasenack> what did I break?
 * ahasenack reads
<Laney> haha
<juliank> _someone_ mentioned black to me at debconf in hacklab
<doko> tsimonq2: please could you change all the kde-l10n-* packages to b-d on python3 instead of python?
<juliank> but who?
<connor_k> I tidied up a package's debian/patches/ directory and added a few other patches to resolve build issues. However, creating a debdiff from the *.dsc files that resulted from `debuild -S -d` is only creating a debdiff that sees my changes to the changelog, but none of my other patches. The only notable difference from my usual workflow that produces "correct" debdiffs is that I renamed some of the patches in debian/patches
<connor_k> and updated the series file accordingly. Does anyone have a suggestion for where I could begin troubleshooting this?
<rbasak> connor_k: did you make sure that quilt was fully popped before changing the patches in debian/patches/ and the series file?
<rbasak> I'm not quite sure how not doing so would give you exactly the behaviour you describe, but if you didn't do that then you'd certainly end up in trouble.
<connor_k> rbasak, aha! Thank you! I "started over" after backing up my changelog and debian/patches directory, did a quilt pop -a, and copied in my backed up changes and the debdiff certainly looks more correct
<connor_k> thank you very much :-)
<rbasak> connor_k: you're welcome!
<bdmurray> rafaeldtinoco: Could you answer rbasak in bug 1810857?
<ubottu> bug 1810857 in cloud-utils (Ubuntu Disco) "Typo in cloud-guest-utils: "reserveration-id"" [Low,In progress] https://launchpad.net/bugs/1810857
<rafaeldtinoco> bdmurray: sure
<vorlon> infinity, stgraber, kees: TB meeting?
<mapreri> GunnarHj: looks like I also had to add -backports to the package, I didn't realize u.U
<GunnarHj> mapreri: Do you mean the first line in d/changelog? In that case I follow you.
<GunnarHj> mapreri: Ok, I see that it's in both the -proposed and -backports new queues. Then we have spread our bets, so to say. ;)
<GunnarHj> mapreri: Anyway, thanks! That will be easy to sort out.
<GunnarHj> bdmurray: Do you have time to remove a couple of uploads which ended up in the wrong pocket?
<bdmurray> GunnarHj: Depending on what you mean, I'm not an AA.
<GunnarHj> bdmurray: Ah, I thought you were. It's ibus-avro, which was just uploaded to the xenial/bionic/disco new queues. It's intended for the -backports pocket, but was first uploaded by mistake to -proposed too. So if you have the necessary access, it would be great if you could delete them from -proposed.
<seb128> GunnarHj, I can do that
<GunnarHj> seb128: Ah, nice!
<seb128> GunnarHj, mapreri, bdmurray, done
<GunnarHj> seb128: Thanks!
<mapreri> seb128: well, you rejected everything :D
<mapreri> guess I'll re-upload the -bpo ones
<GunnarHj> I think seb128 needs some sleep. :)
<mapreri> alright, back afk! o/
<seb128> GunnarHj, mapreri, sorry, I didn't know backport was in the same queue, I though those were 2 buggy uploads
<seb128> I see it's reupload so we should be good :)
<GunnarHj> seb128, mapreri: Right, now all is as it should be. Thanks!4
<tsimonq2> doko: Don't quote me on this, but those are KDE 4 and should be nuked anyway.
 * sarnold runs to wikiquote
<Unit193> sarnold: Why there when you can just remove them with 'tsimonq2 says these can be removed'?
<sarnold> Unit193: so it can be mirrored everywhere!
<tsimonq2> XD
<Unit193> Might as well send something to ubuntu-devel-discuss while we're at it.
<tsimonq2> My personal opinion is that we should have nuked all of Qt 4 anyway cycles ago.
<Unit193> But that kills so much stuff!
<Unit193> Like...Uh...Synergy?
<tsimonq2> Bah. :P
<Unit193> I'm kidding, barrier is a good replacement.
#ubuntu-devel 2019-08-14
<doko> tsimonq2: well, how to make progress?
<tsimonq2> doko: Is kde-l10n-* the last blocker for something, out of curiosity?
<Unit193> Perhaps a qt4-rm transition tracker could help?
<tsimonq2> That's a good idea.
<doko> tsimonq2: just saw that as a big delta compared to debian unstable
<tsimonq2> doko: I doubt that's from Kubuntuers of our time.
<doko> tsimonq2: well, then file removal bugs
<tsimonq2> RikMills: ^ are you okay with this?
<RAOF> tjaalton: Hm. Is there any reason to migrate bug #1825940 to -updates? Its only changes are to ICL support, right, and it doesn't actually work?
<ubottu> bug 1825940 in mesa (Ubuntu Bionic) "[graphics] Enable ICL" [Undecided,Fix committed] https://launchpad.net/bugs/1825940
<RAOF> (As in, it will need another mesa upload before it will work?)
<RAOF> That sounds more like a âplease remove from -proposedâ than âit's good to release into -updatesâ ð¸
<RAOF> Ah, no, it also includes the 19.0.8 stable release.
<tjaalton> RAOF: needs to move to updates, I'd then stage the next upload in proposed which would stay there until the kernel is released
<tjaalton> the stablw update fixed some bugs that I probably duped to the tracker bug
<rbasak> vorlon: please could you binNEW review src:poco for the MySQL transition? It's not on the critical path yet but will be soon.
<rbasak> The binNEW is unrelated to the transition AFAICT.
<rbasak> Skuggen, cpaelzer, rafaeldtinoco, bryce, ahasenack: I highlighted in red on the worksheet the packages on the critical path.
<rbasak> Please grab when you can, adding yourself to the "Driver" column.
<rafaeldtinoco> rbasak: alright
<rafaeldtinoco> adding myself
<Skuggen> rbasak: Will do
<lag> cyphermox: sil2100: waveform: Are you guys aware of this 'critical' Grub2 bug?
<lag> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1839317
<ubottu> Launchpad bug 1839317 in grub2 (Ubuntu) "Grub fails to chainload the Windows Boot Manager" [Critical,Confirmed]
<cyphermox> lag: as I recall that had been fixed in the past
<cyphermox> however, not on aarch64; and I'm not certain how well that's been working before either
<cyphermox> lag: are you able to reproduce that yourself?
<lag> cyphermox: It worked great before - this is a regression
<lag> cyphermox: Yes
<cyphermox> ok
<cyphermox> lag: how does the failure present? would you be able to add a video of it to the bug, just to make sure it's crystal clear for me what the failure looks like?
<cyphermox> I think I know what piece of code is the culprit, but still it would help ;)
<lag> cyphermox: The failure is 0.25s of black screen - then back to the menu
<cyphermox> lag: ok
<cyphermox> then, if I may ask for something else
<lag> Nope
<lag> ;)
<lag> Of course
<lag> cyphermox: ?
<cyphermox> could you modify the grub entry to include: set debug="chain,secureboot,dl"
<cyphermox> then run it again, and video (if possible)
<cyphermox> there would be debug text shown on screen very briefly
<vorlon> rbasak: poco done
<rbasak> Ta!
<juliank> Hmm, is there like a weird scheduler bug in 5.2.0-10-generic or something?
<juliank> I'm having applications randomly lock up on me
<juliank> for short period of times
<juliank> well, sometimes the entire desktop locks up for like 10 seconds or so
<juliank> and suspend does not really work
<juliank> but no issues reported in dmesg
<juliank> I guess it could also be a bug in gnome-shell where it just prevents the window from rerendering or stuff
<juliank> df -h just took 4 seconds to execute
<juliank> I feel like I/O is blocking somehow (it's an NVME SSD -> LUKS -> LVM -> btrfs or xfs)
<juliank> maybe btrfs is going crazy somehow
<juliank> yes, it seems to be the case
<juliank> time to move away from it I guess
<rbasak> cpaelzer, bryce, ahasenack: I think tdbcmysql is now false positive in the transition tracker because the old libmysqlclient20 dependency did not go away. But it does now have libmysqlclient21 as an alternative, so it should be fine. I suppose the transition tracker isn't well suited to this type of package that does everything manually and therefore more readily supports multiple ABIs at once.
<seb128> juliank, aptdaemon/arm64 autopkgtest seems unhappy, is that something you are looking at?
<juliank> seb128: Well, not really looking at it. I think we should go back to ignoring them
<juliank> There's a weird race or sth that only triggers on arm64
<seb128> we ignored them before?
<juliank> they were always-failed
<juliank> now they passed once
<seb128> hum, right
<juliank> armhf is similar, but succeeds a lot more often
<seb128> seems like a real bug in the test worth fixing though?
<cpaelzer> rbasak: yes this is why I added it as alternative
<cpaelzer> rbasak: it might be off that list if we add it in front, but that is not worth it IMHO
<juliank> seb128: optimally yes
<juliank> seb128: but it's a bit unclear whether it's really worth allocating time for
<seb128> juliank, if not can you at least get the skip rule added?
<juliank> like all the code is arch-independent, so ...
<juliank> yeah
<seb128> thx
<nacc> xnox: not sure if you'd be the relevant point of contact or not, but we're able to reproduce LP: #974454 at will on Bionic. The Debian patch does resolve it in our testing. Would you be opposed to a debdiff to apply it to 19.10 and backport to 18.04? I can do the bug work/SRU template
<ubottu> Launchpad bug 974454 in netcfg (Ubuntu Bionic) "resolv.conf loses search directive with domain during pxe boot" [Undecided,Confirmed] https://launchpad.net/bugs/974454
<tomreyn> there's someone in -arm trying to make contact in terms of what looks like a commercial partnership. logs  https://irclogs.ubuntu.com/2019/08/14/%23ubuntu-arm.html
 * tomreyn afk
#ubuntu-devel 2019-08-15
<The_LoudSpeaker> Where can I download 19.10 ? To test?
<tjaalton> The_LoudSpeaker: http://cdimages.ubuntu.com/daily-live/current/
<The_LoudSpeaker> tjaalton: Thanks!
<seb128> cpaelzer, hey. Would you have some slot for a (hopefully) not too complicated MIR review? https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271 is something we are trying to land for ff still (so in the next week)
<ubottu> Launchpad bug 1839271 in zsys (Ubuntu) "[MIR] zsys" [Undecided,New]
<cpaelzer> seb128: in a bit I have ~20 packages building and can take a look
<seb128> cpaelzer, excellent, thx!
<cpaelzer> never say "not too complicated" that makes extra suspicious
<seb128> haha
<seb128> that's why I added the (hopefully) :)
<cpaelzer> the last "not too complicated" was triple denied (precheck, MIR check and by security)
<seb128> but I expect that's going to need a security team review as well, Will pinged them about that before his holidays
<cpaelzer> seb128: its getting lat and I still haven't started zsys :-/
<cpaelzer> I'll keep it open for tomorrow hoping for a day with hupefully much less other breakage
<seb128> cpaelzer, no worry, thx for keeping it in mind, if it's not tomorrow it's next week don't worry
<seb128> we are likely going to end up asking for a ffe but it's our fault for getting things uploaded late
<The_LoudSpeaker> Hey! Can anyone tell me whom should I contact to know the procedure to set up an ubuntu mirror in my university?
<The_LoudSpeaker> The University will be more than happy to help.
<gQuigs> The_LoudSpeaker: https://wiki.ubuntu.com/Mirrors
<The_LoudSpeaker> Thanks! I will have a look.
<gQuigs> :)
<roaksoax> bet/win 2
<doko> coreycb, jamespage: http://launchpadlibrarian.net/437485398/python-cinderclient_1%3A4.2.1-0ubuntu1_1%3A4.2.1-0ubuntu2.diff.gz  when do you plan to drop the py2 stuff?
<coreycb> doko: well we had a discussion about that bit in that change. it's not entirely necessary, it's just easier for UCA backports. other than those few BDs we have dropped py2 across the board. we just need to sort out the proposed migration issues.
<coreycb> we meaning james sahid and i. if we need to drop those BDs soon as in this release, we can. it's just busy work across a lot of packages.
<mwhudson> Locutusofborg: go 1.12.9 already! ffs
#ubuntu-devel 2019-08-16
<robert_ancell> FourDollars, I'm still confused by https://code.launchpad.net/~fourdollars/ubuntu/+source/systemd/+git/systemd/+merge/370808 - nothing in that merge shows any changes to that revert patch, so either the revert hasn't been done or the changelog entry shouldn't be there.
<FourDollars> retoaded: Because it just removed the patch file under debian/patches/debian.
<FourDollars> retoaded: Oops. Sorry.
<FourDollars> robert_ancell: Because it just removed the patch file under debian/patches/debian.
<FourDollars> robert_ancell: You may need to checkout lp:~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-bionic and lp:~fourdollars/ubuntu/+source/systemd:ubuntu-bionic to see what is going on.
<robert_ancell> FourDollars, yeah, is LP showing the wrong thing? Because those changes aren't showing the diff there.
<FourDollars> robert_ancell: LP doesn't show the wrong thing. It is because 237-3ubuntu10.25 is not in lp:~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-bionic but there is another commit of https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=832a06123f7b060b67394fe270123d80c8d7e37b in the git repo.
<sarnold> is that a patch in debian/patches/ that's modifying another patch in debian/patches/ ?
<FourDollars> robert_ancell: drop Revert-udev-network-device-renaming-immediately-give.patch has existed in  lp:~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-bionic but not released yet.
<FourDollars> sarnold: No
<FourDollars> robert_ancell: So you won't see it in my merge proposal.
<robert_ancell> FourDollars, so it should still be in the history though. Perhaps we need to merge in the changes for 237-3ubuntu10.25 first to make this less confusing.
<robert_ancell> If that change has never been released, then why would there be a commit message saying it was removed later!?
<FourDollars> robert_ancell: Which commit are you talking about?
<FourDollars> robert_ancell: 237-3ubuntu10.25 is not in lp:~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-bionic so I imported it manually in my merge proposal although it has been released.
<robert_ancell> FourDollars, 2357ccb mentions Revert-udev-network-device-renaming-immediately-give.patch, which is not in the commit history and not added or removed in that change.
<FourDollars> robert_ancell: It is a Debian package release commit so its content is from debian/changelog.
<FourDollars> robert_ancell: "Releasing package systemd version 237-3ubuntu10.26".
<robert_ancell> FourDollars, If I look at lp:~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-bionic the "Revert-udev-..." patch is not there, if I look in the uncommited changes in https://launchpadlibrarian.net/434785026/systemd_237-3ubuntu10.24_237-3ubuntu10.25.diff.gz it is not there, and it's not there in https://code.launchpad.net/~fourdollars/ubuntu/+source/systemd/+git/systemd/+merge/370808 that I can see.
<robert_ancell> So it seems the patch never existed, so there shouldn't be a changelog entry mentioning it being removed.
<FourDollars> robert_ancell: Not really. It existed before. It is because https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=832a06123f7b060b67394fe270123d80c8d7e37b removed it so you won't see it in lp:~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-bionic.
<FourDollars> robert_ancell: You need to check 237-3ubuntu10.24 and you will see it.
<robert_ancell> FourDollars, I'm looking at 832a06123f7b060b67394fe270123d80c8d7e37b which is the ubuntu-bionic branch and it's not showing.
<FourDollars> robert_ancell: Checkout f81ac1953e6b2fa1c7b5d044d707646f480e2afa
<robert_ancell> FourDollars, oh wait, now I see. So the change was in 237-3ubuntu10.24, just no-one updated the changelog?
<robert_ancell> or was it released in 237-3ubuntu10.25?
<FourDollars> robert_ancell: It is from Debian upstream.
<FourDollars> robert_ancell: Check 0650aebb9791da1bdeae1ca89b8eef70c631612d
<robert_ancell> FourDollars, ok, I think I now understand - 237-3ubuntu10.25 was released with the patch in, but the git branch wasn't updated. 237-3ubuntu10.26 will remove it, but the merge proposal as shown is confusing as it shows it being removed before the 237-3ubuntu10.25 release.
<FourDollars> robert_ancell: You probably need to check my merge proposal by gitk or something alike to see what is going on.
<FourDollars> robert_ancell: LP can not show the diagram like gitk.
<robert_ancell> FourDollars, super confusing. I can see it in gitk.
<FourDollars> robert_ancell: haha
<robert_ancell> :)
<FourDollars> robert_ancell: I was also very confusing before.
<FourDollars> Why 237-3ubuntu10.25 doesn't exist in lp:~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-bionic when it has been released. XD
<FourDollars> Why there is another commit just after 237-3ubuntu10.24, but it is not included in 237-3ubuntu10.25.
<robert_ancell> FourDollars, right, and that extra commit should have had an entry in the changelog set to UNRELEASED.
<FourDollars> robert_ancell: Yup
<FourDollars> robert_ancell: Would you push the package into the SRU queue?
<robert_ancell> FourDollars, have you heard from xnox about it?
<FourDollars> robert_ancell: No
<FourDollars> robert_ancell: Heard what from xnox?
<robert_ancell> FourDollars, just wondering if he was planning on reviewing, as he's listed as one.
<FourDollars> robert_ancell: I just saw he mentioned https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700/comments/5 recently. Nothing else.
<ubottu> Launchpad bug 1837700 in OEM Priority Project "Dell system takes a long time to connect network with external dock" [Critical,In progress]
<robert_ancell> FourDollars, uploaded.
<FourDollars> robert_ancell++ Thx a lot.
<vorlon> xnox: wasn't something fixed to prevent such broken packages? https://launchpad.net/ubuntu/+source/rust-regex/1.2.1-2/+build/17418647
<gQuigs> (also pinged in internal/#security) - anyone around to confirm this possible nginx regression - https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1840404
<ubottu> Launchpad bug 1840404 in nginx (Ubuntu) "[regression] 1.14.0-0ubuntu1.4 security update enables TLS1.3 without a choice" [Undecided,New]
<Locutusofborg> mwhudson, we need a golang-1.12-race-detector-runtime package, or to remove that dependency
<Locutusofborg> opinion?
<cpaelzer> Locutusofborg: I ahve a fix for the ufw dep8 test fail that stopped iptables
<cpaelzer> do you want to be on the MP as reviewer?
<Locutusofborg> thanks cpaelzer :) if it works, please upload!
<Locutusofborg> I also think we should open a bug in Debian for all the Ubuntu delta...
<Laney> bah, polkit-1 in proposed is now uninstallable since systemd got removed
<Laney> guess I could revert that particular change
<teward> this will sound like a dumb question I should know the answer to, but is it possible to write autopkgtests that are Python driven?
<teward> so that I can write the autopkgtest for the given 'test' in a language I'm fluent in heh?
<mdeslaur> sure
<ogra> we only allow spanish or esperanto python though
<mdeslaur> wait, when did we drop french python?
<ogra> ah, i forgot about that one ... indeed there is french pyton too but you have to wrap it in crÃ©pes
<Odd_Bloke> mdeslaur: The problem with French Python is that the scripts have to be 3 times bigger than the English Python equivalent if we're shipping packages to Quebec. ;)
<mdeslaur> hehe
<vorlon> Unit193: hi, at one point you had done an upload of assaultcube pulling from "Debian unreleased VCS", and there's been a new Debian upload by a new maintainer that doesn't seem to derive from that; do you have interest in reconciling this?
<ahasenack> hi, the ufw test (http://autopkgtest.ubuntu.com/running#pkg-ufw) has been running for 20h at least
<ahasenack> almost 21h actually
<ahasenack> maybe someone should kill it?
<ahasenack> same for iptables?
<Unit193> vorlon: I've already looked into it, and it's most certainly weird to say the least.  The version that's in Debian now doesn't actually exist, the watchfile is pointed to his "mirror" on Gitlab where he's got a number of his own commits on top of upstream.  All in all I find it weird and think nothing is gained at this time by merging/sync'ing, but may as well for the next upstream or whatnot.
<Unit193> It's not easy to track changes because he's got "import Debian changes for version 1.2.0.2" as the commit for everything...
<jdstrand> cpaelzer: fyi, ufw did pass with 1.8 in the past (ie, on buster). is this a 1.8.*3* change?
<jdstrand> cpaelzer: also, based on what ahasenack said, it sounds like the upload is causing autopkgtests to hang
<jdstrand> cpaelzer: (the iptables upload)
<vorlon> Unit193: ack
#ubuntu-devel 2019-08-17
<mwhudson> Locutusofborg: yep all done now i think?
<mwhudson> oh https://launchpad.net/ubuntu/+source/golang-1.12-race-detector-runtime needs promotion
<mwhudson> has anyone written a thing to get git to do intelligent merging of debian/patches/series?
<Locutusofborg> mwhudson, why not call it golang-race-detector-runtime ?
<Locutusofborg> vorlon, can we sync glibc-doc-reference, or should we really keep such delta?
<Locutusofborg> cpaelzer, didn't work the ufw patch?
#ubuntu-devel 2019-08-18
<mwhudson> Locutusofborg: in general it's built from a different version of the compiler-rt source for each go version
<mitya57> Looks like autopkgtest.ubuntu.com is down
#ubuntu-devel 2020-08-10
<Laney> dear BTS, please give bug numbers faster
<Unit193> 3
<cpaelzer> sil2100: (for +1 maint) xnox (for boost in general): is one of you on src:mrs which is a FTFBS blocking boost1.71 (and thereby ICU as well)
<cpaelzer> seems it was ignroed and removed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957567
<ubottu> Debian bug 957567 in src:mrs "mrs: ftbfs with GCC-10" [Serious,Open]
<cpaelzer> I was wondering if anyone looks already into that - and if not what you'd think for Ubuntu (removal as well, or trying to fix) would be the better approach
<cpaelzer> I can give it some time to fix FTFBS and if it seems to complex file a removal  (as part of +1 duty), but wanted to avoid that this is already being worked on
<cpaelzer> different question - I know if we have a source in Ubuntu the only way to prevent auto-sync from Debian is giving it a ubuntuX suffix. But if we don't have the src:package is there a way somewhere to block a given package from syncing?
<cpaelzer> I'd want to check for a particular package if it is blocked there as well (and hopefully find a comment about the reasons)
<cjwatson> cpaelzer: Are you thinking of https://code.launchpad.net/~ubuntu-archive/+junk/sync-blacklist ?
<cpaelzer> sounds about right cjwatson - thanks
<cpaelzer> I'll take a look there
<cpaelzer> thanks that was it
<cpaelzer> I knew such a thing existed, I even see changes in there by me - but I forgot the right paths to look at
<xnox> cpaelzer:  what do you mean "blocking boost1.71"?
<xnox> cpaelzer:  there is no boost transitions in progress.
<seb128> xnox, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#boost1.71 ?
<slyon> Hey core-devs! Could somebody please review/sponsor my fix for bug #1889138 (debdiff attached) â so I can move forward with getting sbuild/dpkg migrated from -proposed?
<ubottu> bug 1889138 in procenv (Ubuntu Groovy) "procenv is FTBFS in Groovy" [Undecided,New] https://launchpad.net/bugs/1889138
<xnox> seb128:  but that's not a transition, it is simply part of icu transition.
<seb128> xnox, sorry I don't have the start of the discussion, but that's boost in proposed blocked by some items
<seb128> so 'blocking' seems to apply
<xnox> ok
<juliank> Laney: I guess we can't teach britney to always add a grub2-signed trigger when it has a grub2 trigger (and vice versa)
<seb128> xnox, reading irclog nobody said 'transition', I think saying boost is blocked in proposed due to mrs (and dart) was factual?
<cpaelzer> xnox: yes what seb128 referenced is what I meant
<cpaelzer> not a boost transition itself
<cpaelzer> xnox: and the bug - as written in the description - is intentionally not (yet) an RM bug
<cpaelzer> giving it a chance to be fixed and only then it becomes an RM
<xnox> ok
<xnox> cpaelzer:  i have separate questions about libvirt/virsh. I'm trying to write a restart tool. And when doing `systemctl restart libvirtd.service` it only restarts the main daemon, not any other processes it spawned due to KillMode=process"
<xnox> cpaelzer:  so i'm working, is it safe to kill/restart the dnsmasq agents that are running under virsh? is there something like virsh net-restart command?
<xnox> not working => so i'm wondering
<xnox> or if restarting dnsmasq is not safe.
<cpaelzer> xnox: no net-restart
<cpaelzer> xnox: not that I know of
<cpaelzer> xnox: you'd need to destroy + start
<cpaelzer> xnox: if that is safe depends on the complexity of the network that you defined
<cpaelzer> most of the time it is not safe (with guests up=
<cpaelzer> xnox: the default net for example includes the definition of virbr0 - if you remove/start that guests likely will have connection issues
<cpaelzer> xnox: but other configurations e.g. for existing bridges might have no issue at all
<cpaelzer> xnox: this was discussed upstream a while ago btw https://bugzilla.redhat.com/show_bug.cgi?id=1597326
<ubottu> bugzilla.redhat.com bug 1597326 in libvirt "Restarting libvirtd does not restart dnsmasq" [Medium,Closed: notabug]
<Laney> juliank: feels possible, would be best if we can do it in an upstreamable way
<cpaelzer> xnox: how about "virsh net-update" - does that give you waht you need
<cpaelzer> xnox: https://wiki.libvirt.org/page/Networking#Applying_modifications_to_the_network
<xnox> cpaelzer:  it would, if it allowd "empty" updates. It tries to force me to actual make a change.
<xnox> i.e. sudo virsh net-update --help
<xnox> sudo virsh net-update --network vlan --command modify --xml '' --section ''
<xnox> is not ok, because section & xml cannot be empty
<xnox> =(
<xnox> i kind of want to "just reexec dnsmasq" please
<ahasenack> hi vorlon, about my question from friday about the corner case of user removing /etc/default/motd-news before upgrading to the new packages (which would reinstall that config file), did you get a change to think about it?
<ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388835/comments/1022886
<ahasenack> apologies if you did and my  irc proxy bot was offline
<realtime-neil> Does launchpad support the kind of pipeline that will host source, build source, and publish the resulting debian package(s)? If so, where can I learn more about this?
<tumbleweed> realtime-neil: https://help.launchpad.net/Packaging/SourceBuilds
<realtime-neil> tumbleweed: much thanks
<rbasak> Anyone else with an XPS 9360 getting wifi lockups after suspend/resume, requiring reboot? I found a newer firmware than in linux-firmware. Trying that now.
<realtime-neil> tumbleweed: is there a way to get launchpad to build things git-hosted elsewhere?
<ahasenack> for recipes, the git repo needs to reside in lp afaik
<ahasenack> you can setup a mirror, though
<realtime-neil> ahasenack: how do I set up a mirror?
<ahasenack> you have to create a project, then in the "code" tab you can setup a mirror I believe
<realtime-neil> I tried to mirror https://github.com/torvalds/linux.git and got "This foreign branch URL is already specified for the imported repository ~lopin/linux/+git/linux."
<ahasenack> are you lopin?
<realtime-neil> I am not
<ahasenack> then I don't know, sorry
<realtime-neil> okay, thanks anyway
<tumbleweed> looks like that import is timing out
<tumbleweed> You can talk to the launchpad people about that, but I'm guessing the repo is simply too big
<cjwatson> Kernel packaging tends to be rather too complicated to work well with fully-automated recipes anyway.
<ricotz> rbalint, hi, is systemd 246-2ubuntu1 in groovy-proposed going to transition as it is?
<ricotz> I upgraded to it last week and my system nearly dead-locked due to some high cpu usage in the upgrade itself and on the following restart, which rendered the system unusable
<ricotz> downgraded to 245.7-1ubuntu1 again
<ottok> Hi! I am a Debian developer trying to learn how to backport packages in Ubuntu. I followed docs and filed https://bugs.launchpad.net/bionic-backports/+bug/1873597 a month ago but there was no response. What shall I do next?
<ubottu> Launchpad bug 1873597 in Bionic Backports "Please approve backport of galera-4 26.4.3-4 (universe) from focal" [Undecided,Confirmed]
<rbasak> ottok: unfortunately the backports process is mostly dead and there's no longer an active backports review team. Some background here: https://lists.ubuntu.com/archives/ubuntu-devel/2019-January/040575.html
<rbasak> And continuation here
<rbasak> https://lists.ubuntu.com/archives/ubuntu-devel/2019-February/040587.html
<rbasak> I am in favour of its resurrection, FWIW. But it needs a committed team to drive process and resume reviews I think.
<rbasak> teward: FYI ^
<ottok> Thanks, skimmed through those emails, but it left it hanging in the air on what should be done now. Shall I send email to ubuntu-backports@ or just give up?
<sarnold> rbasak: is there a way to give ottok backports priviliges "soon"? ie at the next dmb meeting or something? this is the most effort / activity I've seen put towards backports in ages, and ottok's surely demonstrated an ability and commitment
<rbasak> sarnold: I'm in favour but it's not up to the DMB currently - the DMB isn't delegated management of the backports team currently
<sarnold> rbasak: oh :( :( :(
<rbasak> But separately, IMHO we need a reviewer for ottok's work as well as ottok himself contributing the upload
<sil2100> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<rbasak> I think requiring backports _reviewers_ to be core dev or MOTU is probably appropriate
<rbasak> And we need volunteers for that
<rbasak> teward was such a volunteer in the past, but I'm not sure that he's still available
<rbasak> Unfortunately review work is generally tedious and thankless, so few people volunteer
<rbasak> ottok: maybe reply to the ubuntu-devel@ thread pointing out that you are volunteering a backport but have no reviewer? I think that'd be the most useful place to direct an email.
<sarnold> rbasak: yeah, reviewers would definitely be nice -- and full ack on it being all work no play
<teward> rbasak: sarnold: Laney and I Had also written up restrictions that it needs someone dedicated to maintain the backport
<teward> sort of how you need a DM or be a Sponsored Maintainer in debian to upload for a given package
<sarnold> teward: I can appreciate the sentiment but that's more than universe packages get now ..
<teward> but chaos happened with COVID and everything so I haven't pursuded it much
<teward> sarnold: well 'exceptions' exist :P
<teward> but the problem with backports is "anyone can request"
<sarnold> hah, yes, but no one actually bothers doing them -- until today, anyway ;)
<teward> if we restrict that to devs are teh only ones who can file the request that solves that, the problem is backports is overwlelmed with crap
<teward> and things that aren't good candidates, aren't tested, etc.
<teward> but i'm currently recovering in the hospital
<teward> so E:NOACTION from me for a few days
<teward> appendicitis ia a pain
<teward> but we caught it early now I'm just needing to relax and recover for a couple days
<teward> sarnold: what's on the radar about the backport?
<teward> s/about the/for/
<teward> in this case
<sarnold> teward: oh ugh :/ I hope you're back home soon :)
<teward> sarnold: also backports requires coredev/MOTU I THINK to upload to -backports directly without sponsoring
<sarnold> teward: in this case, ottok's trying to get this going https://bugs.launchpad.net/bionic-backports/+bug/1873597
<ubottu> Launchpad bug 1873597 in Bionic Backports "Please approve backport of galera-4 26.4.3-4 (universe) from focal" [Undecided,Confirmed]
<teward> I can upload to -backports for example
<teward> for Universe or Main or {ANY} because coredev
<teward> but it needs approved/released regardless
<teward> C D and E are dead righgt?
<teward> C D E series*
<teward> ottok: yeah, so
<teward> backports process in terms of review is heavily stalled
<teward> if not dead
<teward> Laney's the only one who does backport reviews and has wanted things backported only that make sense
<teward> what's your justification for needing it backported?  (just curious)
<teward> rbasak: what's the status of mariadb in Xenial
<teward> or is it nonexistent?
<teward> they say in their backport bug that: Ubuntu Bionic has currently only galera-3 available. The new version galera-4 is required to run MariaDB 10.4 or newer.
<teward> and unless people are using MariaDB 10.4+ on Xenial i'm *real* hesitant to do the second part of the backport which is a Xenial request
<rbasak> teward: I would need to look. ottok will be more familiar with all that
<teward> ok
<teward> ottok: ^ same questions
<teward> i assume they went AFK/AWOL
<teward> rbasak: maraiadb 10.0 is in Xenial
<teward> so the jump from 10.0 to 10.4 i'm not entirely sure why is needed/substantial
<teward> if it's "just so we can use newer MariaDB" i'm... not entirely willing to review/sponsor for Xenial.
<ottok> I noticed that there is also a user request to backport a package I maintain in Debian and already maintain backport in PPA: https://bugs.launchpad.net/bionic-backports/+bug/1876599
<ubottu> Launchpad bug 1876599 in Bionic Backports "Please backport rdiff-backup 2.0.0-1 (universe) from focal" [Undecided,New]
<ottok> I promise to make the review very easy, since the backports are all no-changes backports and live along identical ones in Debian backports.
<ottok> And I have a track record of maintaining my packages in both Debian and Ubuntu (unless an idividual package/pocket had some special case going on)
<sarnold> teward: ^^
<ottok> teward: I replied to your "review questions" on Launchpad in context.
<ottok> teward: https://bugs.launchpad.net/bionic-backports/+bug/1873597
<ubottu> Launchpad bug 1873597 in Bionic Backports "Please approve backport of galera-4 26.4.3-4 (universe) from focal" [Undecided,Confirmed]
<teward> ottok: i assume galera-3 and galera-4 are coinstallable then?
<teward> or do they conflict?
<teward> ottok: also: > Using the Ubuntu backported Galera 4 package would assure a good quality of packaging instead of using any alternative option,
<teward> if and only if you also backport mariadb 10.4+ into the repos as well
<teward> because mariadb isn't backported - so unless someone picks up MariaDB 10.4+ and backports it, adding the dependent library doesn't really seem like a necessary/useful step, *especially* since backports it not default-installable unless you specify it during apt calls or are installing things from -backports
<teward> because any 'third party repository', PPA Upstream or Otherwise, would require (1) backports to be enabled, and (2) still be third party so vetting the mariadb code is still 'hard' (as sarnold and others on the sec team can admit to from experience)
<teward> ottok: do you or someone else have the intent to also backport MariaDB 10.4+ into Bionic Backports as well?
<teward> (posted to the bug as followup as well as my REJECT review for Xenial - xenial dies in the next year and MOST people are probably upgraded except for legacy applications, and I don't have any viable tests of whether MariaDB newer can actually *run* on Xenial so I have no basis for accept.
<teward> Laney: if I get up off my lazy butt and backport NGINX, would you be willing to back me up on that backport to Bionic of the stable in focal-updates?
<realtime-neil> How do I tell my launchpad recipe to checkout a git tag and not a git branch?
<cjwatson> realtime-neil: What does your recipe look like at the moment?
<realtime-neil> ```
<realtime-neil> # git-build-recipe format 0.4 deb-version {debupstream}-0~{revtime}
<realtime-neil> lp:test9001 v4.16
<cjwatson> That ought to work, except that the lp:test9001 code import failed
<cjwatson> And https://launchpadlibrarian.net/492765364/realtime-neil-test9001-+git-linux.log is somewhat unclear
<cjwatson> Miiiiiight be helped by https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/373732 but I'm really not sure
<realtime-neil> cjwatson: I feel like you're suggesting something but I'm too ignorant to understand.
<cjwatson> I'm suggesting that this is broken right now
<cjwatson> And it's not completely clear how to fix it
<cjwatson> Your recipe syntax is correct in and of itself, but that doesn't help when https://code.launchpad.net/~realtime-robotics/test9001/+git/linux contains no branches
<cjwatson> (or tags)
<realtime-neil> cjwatson: if I have a fresh source repository that might still be syncing from an upstream source, would that explain the lack of branches and tags?
<cjwatson> What fresh source repository exactly are you talking about?
<cjwatson> (URL)
<realtime-neil> cjwatson: I have a fork of github.com/torvalds/linux here: https://gitlab.com/realtime-robotics/linux
<cjwatson> Whether that gitlab repository is still syncing from upstream is immaterial
<cjwatson> This is a bug in Launchpad code imports that affects a small number of very large repositories
<cjwatson> Probably the same as the tail-end of https://bugs.launchpad.net/launchpad/+bug/1642699
<ubottu> Launchpad bug 1642699 in Launchpad itself "git-to-git import from gerrit with many changes "fails"" [High,In progress]
<cjwatson> Need to get one of my colleagues to review my merge proposal above so we can see if it helps
<realtime-neil> ah, okay; you're theorizing that, since this repository is so big, I might be hitting the bug you mentioned
<cjwatson> It may not be precisely the same thing, but it's something along those sorts of lines
<cjwatson> You can see the code import failure in the log above
<cjwatson> The problem is that it spends five minutes without producing any output at all, which causes the code import monitor to assume it's got stuck and kill it
<cjwatson> (I think it's five minutes anyway)
<realtime-neil> cjwatson: okay, understood; how would you suggest I proceed? Smaller repository? Maybe try this with just a shallow copy of what I care about most?
<cjwatson> The purpose of my branch above is to crank up the progress output so that we get some kind of output every so often to pacify the watchdog, but to throttle it so it doesn't produce an absurd amount of noise in the log
<cjwatson> You could try a smaller repository, or you could try pushing it manually to Launchpad rather than using a code import
<realtime-neil> lemme try the latter
<cjwatson> "Smaller" may possibly be mainly "fewer refs"
#ubuntu-devel 2020-08-11
<ottok> teward: replied to your questions here in context at https://bugs.launchpad.net/bionic-backports/+bug/1873597
<ubottu> Launchpad bug 1873597 in Bionic Backports "Please approve backport of galera-4 26.4.3-4 (universe) from focal" [Undecided,Confirmed]
<cpaelzer> mwhudson: (has seen this on +1 duty) sil2100: (+1 duty atm)  xnox: (triggerd the rebuild for ICU): wgrant (for riscv): hi I wanted to ask about "dee" https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1/+build/19646792
<cpaelzer> it seems it built on all but riscv64 two weeks ago - but ~14h ago someone seems to have restarted the build
<cpaelzer> it hangs in the after-build stage for several hours by now
<cpaelzer> mwhudson: said in his mail "dee's tests are timing out on riscv64 :(" but this seems to be after (build time) tests
<cpaelzer> is someone looking into that actively (after all there must be someone who restarted the build some hours ago) ?
<cpaelzer> FYI dee (see question ~2h ago) still hangs at that stage https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1/+build/19646792
<cpaelzer> is there any extended debug we cuold/should do on the job while still running?
<cjwatson> Let me see if I can get into it
<seb128> cpaelzer, right, previous tries did take more than a day to fail the build
<cjwatson> Zombie schroot process
<cjwatson> Looks like there's a dbus-daemon process still running in the background of the build that the build didn't clean up properly
<cjwatson> buildd    481987  0.0  0.0   5244  2780 ?        S    Aug10   0:00 dbus-daemon --config-file /usr/share/dbus-test-runner/session.conf --print-address
<cjwatson> # ls -l /proc/481987/cwd
<cjwatson> lrwxrwxrwx 1 buildd buildd 0 Aug 11 10:08 /proc/481987/cwd -> /home/buildd/build-PACKAGEBUILD-19646792/chroot-autobuild/build/dee-1HAMJl/dee-1.2.7+17.10.20170616/tests
<cjwatson> cpaelzer: Is that enough for you to debug this or do you need more?
<cpaelzer> thank you a lto cjwatson, that is enough to give it a start
<cpaelzer> I can at least try to hard-clearn after the tests (or skip) and try that in PPAs
<cpaelzer> All I need it a paper-trail and you have provided one - thanks!
<cjwatson> I would prefer to cancel this build because otherwise we might end up with a build that succeeds in the primary archive but nobody knows why because it took manual intervention
<cjwatson> Sound reasonable
<cjwatson> ?
<cpaelzer> I have only started to look at it this morning and all past builds have failed AFAIK
<cpaelzer> while I'd expect it to fail again, I see no reason to wait another 10h for it to do so
<cpaelzer> yes, we should abort it for now unitl we know more
<cpaelzer> let us hope the hang reproduces in PPA builds
<cjwatson> OK, cancelling
<cjwatson> I expect it will
<cjwatson> That's cancelled now
<cpaelzer> thank you
<cpaelzer> cjwatson: could you enable riscv64 on https://launchpad.net/~paelzer/+archive/ubuntu/dee-groovy-hang for me - otherwise I'd need to use a bileto PPA which builds on all architectures (uselss builds are a waste of build resources IMHO) ?
<cjwatson> I mean negligible
<cjwatson> But done
<cpaelzer> thank you
<cjwatson> cpaelzer: If you could delete that archive when you're finished testing then that would be good
<cpaelzer> I clean up my PPAs about every 6 months
<cpaelzer> if in this case it is more urgent I can surely do that
<LocutusOfBorg> niedbalski, hello, I confirm your patch of LP: #1872118 works on my focal servers as primary and slave dhcpd services... can I upload to unapproved queue? and fix also for groovy?
<ubottu> Launchpad bug 1872118 in isc-dhcp (Ubuntu Groovy) "DHCP Cluster crashes after a few hours" [Undecided,Confirmed] https://launchpad.net/bugs/1872118
<narakrish> Hello all.I've developed an application using Qt5.12.7 on Ubuntu 16.04.06 system. I'm facing flickering issue when the application starts. I was able to fix the flickering by installing the following package from ubuntu repository : sudo apt-get install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04. I would like to understand
<narakrish> is there any link between Qt 5.12.7 and those packages ?
<xnox> slyon:  seb128: network-manager autopkgtest wpa-dhclient started to fail on ppc64el and i cannot work out what has changed, or even reproduce the failure the same way. For me, even bringing up wlan0/wlan1 fails and I can't even start dnsmasq on the AP which is like part of individual test case setup.
<xnox> i am slightly concerned, but also not sure if we care abput wifi on ppc64el =(
<Laney> We have definitely had cases before where ppc64el was just noticing bugs/races that exist everywhere
<Laney> So IMO to discard it on that basis we should have a determination that it is actually arch specific and not just something we happen to see there for $reasons
<cpaelzer> and someone started the dee build again  https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1/+build/19646792 :-/
<cpaelzer> The assumption for now is that this is a real issue and not a "retry until it works" case
<cpaelzer> see https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1891158 and let me know if you look or looked into it already
<ubottu> Launchpad bug 1891158 in dee (Ubuntu) "riscv64 build issue hang at the end of the build (groovy)" [Medium,Confirmed]
<juliank> new apt landing, please stay attentive and ping me immediately if you see download errors https://launchpad.net/ubuntu/+source/apt/2.1.10
<rbasak> Laney: which series(es) do you need canonical-oem-metapackages defined for?
<rbasak> Never mind I'll just request $(distro-info --supported)
<LocutusOfBorg> cpaelzer, my fault, I won't retry it
<LocutusOfBorg> thanks juliank :)
<LocutusOfBorg> niedbalski, will you forward upstream the fix?
<rbasak> Thanks Marc!
<LocutusOfBorg> @rafaeldtinoco, ^^ I got trapped by the isc-dhcp bug, do you need help/sponsorships? I can upload to groovy and focal if needed
<udevbot> Error: "rafaeldtinoco," is not a valid command.
<LocutusOfBorg> rafaeldtinoco, ^^
<rafaeldtinoco> LocutusOfBorg: I was waiting niedbalski to give a go
<rafaeldtinoco> sent an email cc'ing him from yesterday triage
<rafaeldtinoco> if he is +1 and you're into it, feel free to sponsor it
<rafaeldtinoco> niedbalski: ^
<LocutusOfBorg> btw the problem looks in bind9-libs
<LocutusOfBorg> no need to no-change rebuild isc-dhcp at all
<LocutusOfBorg> +-                      else
<LocutusOfBorg> ++                      else if (!sock->pending_send)
<LocutusOfBorg> this change is ABI-safe
<rafaeldtinoco> seems so, haven't looked into details
<rafaeldtinoco> triage queue was ... interesting yesterday =)
<rafaeldtinoco> 35 bugs.. many with big updates
<LocutusOfBorg> well, I suspect niedbalski should open a bug against bind9-libs?
<rafaeldtinoco> yep, I think he wasn't finished yet with the bug
<LocutusOfBorg> I can't reproduce the crash with updated bind9-libs and normal isc packages
<rafaeldtinoco> thats why I didn't take a move
<niedbalski> LocutusOfBorg: rafaeldtinoco sure, i'll add the bind9-libs and propose the SRU(s)
<LocutusOfBorg> niedbalski, don't forget to offer a debdiff for groovy, and to open a debian bug with patches
<LocutusOfBorg> so the package goes in sync again
<niedbalski> LocutusOfBorg: okay
<LocutusOfBorg> rbasak, ?? how do you feel about adding the patch directly to the Debian package and wait for the sync?
<rbasak> Was that for me?
<ahasenack> hi devel team, I have a failing test on armhf for samba in groovy, and turns out that the host is not running the groovy kernel
<ahasenack> I know armhf tests are run on lxd/armhf images, but I was expecting the host to have the same kernel as the target ubuntu release at least
<ahasenack> looks like the host is bionic
<ahasenack> just checking if this is expected, and that I should guard my test to check for the kernel version
<rbasak> That was discussed recently as it happens: https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041109.html
<ahasenack> fwiw, it's a test using kernel's uring support, which became available in kernel 5.1 and later
<rbasak> Based on that you can never make that assumption about the build host kernel
<ahasenack> yeah, for vms it doesn't matter, for armhf is the special guy
<ahasenack> ok, I'll adapt the test and have it skip if the kernel is too old
<rbasak> I was under the impression that armhf builds happen on arm64 nowadays?
<ahasenack> it's an armhf lxd image on an arm64 host
<rbasak> Right
<ahasenack> well, at least it shows my test works
<rafaeldtinoco> and there is yet another problem.. the arm64 kernel with armhf userladn
<ahasenack> in the sense that it fails if uring support isn't there :)
<rafaeldtinoco> but thats another story =)
<rafaeldtinoco> (the syscall execution paths are diff, bugs may rise from there)
<ahasenack> so uring was really being exercised
<LocutusOfBorg> rbasak, bind9-libs needs a patch, also in Debian, to fix a crash
<LocutusOfBorg> the patch is trivial
<LocutusOfBorg> rbasak, http://debomatic-amd64.debian.net/distribution#unstable/bind9-libs/9.11.19+dfsg-2/buildlog
<LocutusOfBorg> this is the "fix"
<rbasak> LocutusOfBorg: wrong URL?
<rbasak> LocutusOfBorg: I don't follow why you're asking me
<rbasak> Which of my hats are you talking to?
<rbalint> ricotz, please open a but then, unless it is LP: #1890913
<ubottu> Launchpad bug 1890913 in linux (Ubuntu) "init is using 100% of processor " [Undecided,Invalid] https://launchpad.net/bugs/1890913
<rbalint> ricotz, (re: systemd 246)
<LocutusOfBorg> rbasak, aren't you the maintainer of bind9-libs?
<ricotz> rbalint, this looks like the symptom I saw, running an i7 2600K, no i915 though
<rbalint> ricotz, 5.8 kernel?
<ricotz> rbalint, yes
<ricotz> 5.8.0-13-generic
<rbasak> LocutusOfBorg: ah. I wasn't aware. I guess that got copied across from find9
<rbasak> bind9
<rbasak> LocutusOfBorg: probably best file a BTS patch?
<ricotz> rbasak, more precise 5.8.0-13.14-generic 5.8.0
<rbasak> I've not been active there for a while
<rbalint> ricotz, i think new systemd would work fine with old kernel
<ricotz> rbalint, ok, but 5.8.0-12.13 is in groovy-proposed
<ricotz> you have tested it with 5.4.0-* only?
<rbalint> ricotz, yes, not breaking release pocket is sufficient for migration
<cpaelzer> seb128: I see you hav retried sbuild/dpkg in regard to procenv
<rbalint> i think kernel 5.8 made intel driver's fastboot the default and this breaks old cpus
<ricotz> rbalint, alright, might be good if you give the proposed kernel a try
<cpaelzer> seb128: due to the way that gets the procenv source the combined trigger wasn't getting what you wanted
<cpaelzer> seb128: but now procenv is released to groovy (thanks slyon)
<cpaelzer> seb128: I have retriggered again and now it should work (or find a different failure)
<seb128> cpaelzer, ah, sorry for screwing those triggers set ... what was missing exactly?
<seb128> ah
<seb128> that wouldn't respect the trigger version, ignore that
<seb128> cpaelzer, thanks for the headsup!
<slyon> cpaelzer: seb128: sbuild should work now, I verified that locally. dpkg needs sbuild to migrate first
<seb128> slyon, ack
<seb128> doko, could you trigger a refresh of https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html ?
<cpaelzer> slyon: seb128: I have issued the new trigger - and now it should work
<cpaelzer> slyon: if not I'll let you know and we can debug what new issue it is now
<seb128> cpaelzer, thanks!
<slyon> thanks!
<rbalint> ricotz, so you have not modified kernel cmd line manually, right?
<ricotz> rbalint, no
<rafaeldtinoco> sergiodj: did you open a bug for the rabbitmq-server merge ?
<rafaeldtinoco> just asking cause I can "sponsor" that sync bug
<sergiodj> rafaeldtinoco: nope, but I can do that now.  I thought the MP was enough :)
<sergiodj> let me run requestsync here
<rafaeldtinoco> sergiodj: nah
<rafaeldtinoco> sergiodj: no need
<sergiodj> rafaeldtinoco: ah, ok
<sergiodj> thanks :)
<rafaeldtinoco> sure!
<rafaeldtinoco> sergiodj: could u pls check migration for rabbitmq-server upload ?
<rafaeldtinoco> hopefully it migrates with no issue s=)
<sergiodj> rafaeldtinoco: absolutely, thanks
<cpaelzer> slyon: seb128: all sbuild/dpkg turned green
<cpaelzer> just one systemd test left that has a retry in the queue already
<slyon> cpaelzer: thanks a lot for your support with this!
<rbalint> vorlon, vim blocks libguestfs -> systemd , i'd like to disable vim tests on riscv64 to unblock them
<rbalint> vorlon, or we can unblock tests on riscv64 for all packages which i would not oppose
<xnox_m> <rbalint "vorlon, vim blocks libguestfs ->"> please go ahead with vim upload to skip riscv64 test.
<vorlon> rbalint: yes, please do
<rbalint> vorlon, i guess the former for now :-)
<vorlon> but also, where did we get to with the discussion about disabling tests at build-time for all riscv64
<rbalint> vorlon, it stalled after my last email asking for it
<xnox> rbalint:  vorlon: i tend to agree with wgrant that in general, most of them run, and most of them pass, and are ok. And we should be free to upload disabling them on case by case basis, and like opening a bug report to revisit them. Or like revisit that after next merge from debian.
 * xnox_m is still not sure if matrix client or weechat are better
<vorlon> xnox: no, the problem is the cost on package build time to run tests whose results we don't care about
<vorlon> it's *not* about test reliability
<xnox> vorlon:  so PPA builds on riscv64 of snapd are the only place where riscv64 tests are executed today..... so it's used as a ci.
<xnox> vorlon:  if we do disable tests by default, it should be possible to re-opt-into them.
<vorlon> which it would be
<vorlon> just unset the environment variable that would be set by dpkg-dev
<vorlon> DEB_BUILD_OPTIONS=notnocheck
<xnox> i don't see how to make that policy compliant.
<vorlon> what aspect of policy?
<xnox> is notnocheck a thing?
<rbalint> xnox, which policy?
<xnox> that packages should honor DEB_BUILD_OPTIONS and not modify / ignore it.
<xnox> debian policy
<vorlon> xnox: no, I was being facetious re: notnocheck
<rbalint> well, we are ok with having packages which are not fully policy compliant
<xnox> there is nocheck profile right? vs DEB_BUILD_OPTIONS?
<vorlon> profiles are not supported anywhere in launchpad
<xnox> i'd be more happy with "default profile set to nocheck on riscv64 in dpkg" unless any other profile is specified.
<xnox> it does not need to be supported by launchpad
<vorlon> I don't see anything in policy saying that packages are not allowed to change the contents of DEB_BUILD_OPTIONS
<xnox> also one cannot pass arbitrary DEB_BUILD_OPTIONS via launchpad either.
<vorlon> hmm
<vorlon> profiles aren't mentioned in policy at all ;P
<xnox> ah it's optional
<xnox> "Supporting the standardized environment variable DEB_BUILD_OPTIONS is recommended."
<vorlon> yes, and in any case "supporting" doesn't mean "not allowed to override"
<xnox> vorlon:  doko wanted to patch dpkg and/or debhelper, to do "nocheck by default on riscv64" because well, anything else is mad.
<vorlon> does setting a nocheck profile automatically set DEB_BUILD_OPTIONS?  Because most packages honor the latter and not the former
<rbalint> xnox, i'd go with patching dpkg as well
<xnox> ie. local sbuild stops matching what launchpad does, if we hide deb_build_options/profiles in launchpad-buildd
<vorlon> agreed, it should be a dpkg patch
<xnox> rbalint:  but please upload vim first =)
<vorlon> quite
<rbalint> vorlon, ok, but i got so enthusiastic i already pulled dpkg, too ... :-)
<xnox> vorlon:  so i'm currntly doing cross-building and something set all the things for me like "nocheck cross" build profiles and like "DEB_BUILD_OPTIONS" too
 * xnox sensed disturbance in the forse
<vorlon> xnox: sure - but the DEB_BUILD_OPTIONS bit is what's actually functional, so I don't see the point in messing with profiles instead of just build options directly
<xnox> sure
<xnox> vorlon:  it would be neat to eventually wire up profiles/deb-build-options into launchpad archive settings, such that i.e. we could create archive rebuild with|without nocheck, and create cross-building archive, etc.
 * vorlon nods
<vorlon> ahasenack: hi, managing to reply before you drop off IRC for the day; I think the corner case in question is acceptable to not address, but needs to be called out in the SRU
<vorlon> (as "regression potential")
<ahasenack> I see
<ahasenack> I was just implementing cpaelzer's suggestion
<ahasenack> creating a file in postinst of one package, checking for it in the postinst of another
<vorlon> ok, I have no well-formed opinion on this at the moment :)
<ahasenack> it worked in the case of ubuntu-server being installed, but when it's not installed, that touched file used for "inter-maintainerscript-communication" was left around (/etc/default/motd-news.wasremoved)
<ahasenack> vorlon: this was/is the logic: https://pastebin.ubuntu.com/p/fhg6pHmMMH/
<ahasenack> (postinst snippets at the bottom)
<ahasenack> should I continue with that, or remove this corner case, any opinion?
<ahasenack> I feel a bit dirty manipulating maintainerscripts like that
<vorlon> ahasenack: sorry, can't look right now; I'll try to give an opinion in ~1h
<ahasenack> vorlon: thanks
<vorlon> ahasenack: yeah, so I'm vaguely inclined to leave this corner case unfixed but called out in the SRU, rather than add additional complicated maintscript handling; but I wouldn't block the SRU if you do add the maintscript stuff
<ahasenack> yeah, I fear I might introduce bugs of my own with that complicated handling
<ahasenack> thanks vorlon
<ahasenack> teward: hi, around? Would you like us to merge nginx from debian again, or would you prefer to work on this one?
<bdmurray> bryyce: Do you have an example of the nodejs timeout on arm64?
<bryyce> bdmurray, just the build log, but I can give you a link
<bryyce> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/n/node-redis/20200811_140200_cbf2b@/log.gz
<bryyce> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/n/node-immutable-tuple/20200811_110654_f3a78@/log.gz
<bryyce> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/n/node-address/20200811_110131_4b017@/log.gz
<bryyce> bdmurray, ^^
<bdmurray> bryyce: Have you tried it with a longer timeout?
<bdmurray> I'm trying it with timeout-test=20000
<bryyce> bdmurray, no I hadn't; is that set in the package itself?
<bdmurray> bryyce: no when you call autopkgtest "--timeout-test" which defaults to 10000
#ubuntu-devel 2020-08-12
<seb128> rbalint, hey, https://launchpad.net/ubuntu/+source/vim/2:8.2.0716-3ubuntu2 ... why is it a good idea disabling test? would be nice to have some description stating if that's a forever delta or wjat's the reason, also do you plan to try to get that change to Debian?
<rbasak> vorlon: sergiodj asked me to review https://code.launchpad.net/~sergiodj/britney/hints-ubuntu-xenial/+merge/388495 but I've never really understood what you want wrt. these cases. SRU to fix the autopkgtest? badtest the version only? badtest all versions?
<rbasak> AIUI a fix to the test case in Xenial is available.
<rbasak> And this failure "blocks" the rpcbind SRU from being released
<rbasak> Any chance of some documentation for when a badtest is acceptable to you please?
<xnox> seb128:  it builds fine in debian, maybe with the next merge it will "just work"
 * xnox ponders when matrix channel will finally send a message, or maybe that would be never.
<seb128> xnox, hey, what are you talking about?
<seb128> xnox, was it my comment about vim?
<seb128> xnox, basically I was saying that adding undocumented and unforwarded delta just creates debt and increase our workload for futur cycles
<xnox> seb128:  please see discussion about vim on riscv64 across all the previous weeks here, on #ubuntu-meeting and ~RISCV =)
<xnox> seb128:  this change was not done lightly.
<xnox> rbalint:  i did say, you should also open a bug report documenting that tests were disabled for riscv64 and need to be investigated.... and expected for that bug to be referenced in the changelog. such that there are breadcrumbs for others to follow ^
<Laney> the changelog could be more verbose, I think that's a fair comment to make
<xnox> Laney:  yeap.
<cpaelzer> slyon: all dpkg tests are green now
<cpaelzer> should migrate on the next run
<seb128> xnox, I didn't say that it was done lightly, just that the rational was undocumented in the changelog and that there was no bug reference or forwarding ... but seems you agree so no reason to keep that discussion going :-)
<slyon> cpaelzer: great!
<rbasak> TIL: lddtree
<rbasak> Thanks Christian :)
<cpaelzer> yw rbasak
<cpaelzer> you sometimes want -a on it
<cpaelzer> Hi https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4192/+build/19813392 is hanging and it will soon timeout-die
<cpaelzer> This is due to bug 1891158
<ubottu> bug 1891158 in dee (Ubuntu) "riscv64 build - hang at the end of the build (groovy)" [Medium,Confirmed] https://launchpad.net/bugs/1891158
<cpaelzer> I've added some debug to this build, but even hitting an exit 1 in override_dh_auto_test  will suffer from the hanging process keeping the chroot up
<cpaelzer> I'm afraid once it died I won't be able to get the full log
<cpaelzer> can anyone "log into" that builder and get the build log as generated so far?
<cpaelzer> cjwatson: ^^ since you gave me the initial traces to follow when debugging this - maybe you can do that?
<cjwatson> cpaelzer: I'm pretty sure if you cancel it you'll get the full log.
<cjwatson> cpaelzer: And even if you don't, this is a devirt builder so I can always log in after the fact and get the full log.
<cjwatson> cpaelzer: So please try an ordinary cancel first.
<cpaelzer> thanks cjwatson - I wanted to make sure I ask before I throw away the chance to get to the log - aborting now ...
<cpaelzer> cjwatson: cancel complete, no buildlog there
<cpaelzer> cjwatson: could you log in and throw me the full log somewhere?
<Laney> cpaelzer: what are you seeing - stray dbus-daemon or something?
<cpaelzer> Laney: yes seems like that
<Laney> mmm
<cpaelzer> I see some timeouts on the test and then it never dies until 24h timeout
<Laney> so https://bazaar.launchpad.net/~indicator-applet-developers/dbus-test-runner/trunk.16.10/view/head:/libdbustest/service.c#L181 failed I guess
<cpaelzer> https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1891158 is what I know about it so far
<ubottu> Launchpad bug 1891158 in dee (Ubuntu) "riscv64 build - hang at the end of the build (groovy)" [Medium,Confirmed]
<Laney> because you see that g_print() but then the daemon is still there
<Laney> so that kill must have not worked?
<cpaelzer> yes I see the g_print
<cpaelzer> but the builder still isn't returning
<cpaelzer> I was adding some debug in the build to look for active processes and open cwds
<cpaelzer> that is the build I'd like the log from
<cpaelzer> just in case it helps to understand the case
<Laney> It's probably waiting for all of the build's processes to exit, namely that dbus-daemon
<Laney> I'm just pointing you at dbus-test-runner because it might be a good place to add some more verbosity
<cpaelzer> I'd have a mitigation skipping the tests on riscv64, but only would go that route after giving up on understanding what goes on
<Laney> like -> here's the PID of the dbus-daemon I spawned, here's the PID of the thing I tried to kill
<Laney> then you can match those up an dsee if that's the stray one
<cpaelzer> for now getting that full build log of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4192/+build/19813392 woud be a good next step
<cpaelzer> but thanks on the hint for dbus-test-runner - I could throw one wit hmore debug into the PPA as well
<cpaelzer> just that I have to ask for full logs is a bit inhibiting :-)
<cpaelzer> as "alone" I can only see the snippet the build shows while running
 * cpaelzer off a bit for lunch
<Laney> I wonder if you lowered the timeout on your local system if it would happen to
<Laney> too*
<Laney> like, make it 1 second or 0.1 seconds or something, might trigger the same bug
<cjwatson> cpaelzer: will do after meeting
<cpaelzer> back again, and thanks in advance
<cpaelzer> Laney: it can't be a fraction but -m 1 is already building
<cpaelzer> and vice versa "just" bumping the timeout could be a fix for riscv builds for now
<Laney> right, even if you manage to fix the test runner to fail properly it's still an FTBFS :-)
<cpaelzer> Laney: ha - timeout = 1 on x86 triggers the same warnings/erorrs, but NOT the hang of the builder
<cpaelzer> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4200/+build/19818311 is an example
<Laney> interesting
<Laney> perhaps riscv64 does process reaping differently
<wgrant> Laney, cpaelzer: dbus-test-runner is what generally gets stuck, I haven't worked out why.
<wgrant> But there are a couple of packages that were consistently hanging because it didn't die for a while. But they seemed to eventually fix themselves by around maybe September.
<cpaelzer> wgrant: https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1891158 seems to be a new occasion for this then
<ubottu> Launchpad bug 1891158 in dee (Ubuntu) "riscv64 build - hang at the end of the build (groovy)" [Medium,Confirmed]
<seb128> wooot, sbuild migrated :)
<cpaelzer> Right now I'm testing if for riscv I need to bump the timeout or skip the test entirely
<cpaelzer> seb128: yes I did some trigger magic
<seb128> thanks slyon and cpaelzer for the work unblocking it!
<cpaelzer> together with dpkg
<cpaelzer> wgrant: was there a bug for dbus-test-runner back then?
<cpaelzer> wgrant: or should I add a task that we keep open to my bug (for documentation purposes) ?
<wgrant> cpaelzer: Has anyone tried to reproduce it?
<cpaelzer> I tried to trigger the same on other arches with no luck
<wgrant> For something like dee I'd probably just skip the test suite, since it tends to bitrot fairly aggressively.
<cpaelzer> I can make it happen more likely on riscv64 thou, by reducing the timeout
<wgrant> But someone probably should dig into dbus-test-runner at some point.
<wgrant> Yep
<cpaelzer> I'll add a dbus-test-runner task to my bug then
<cpaelzer> and try in a riscv64 qemu a bit
<cpaelzer> wgrant: since I have you here - ever seen https://github.com/dartsim/dart/issues/1482 before?
<ahasenack> teward: hi, around? Would you like us to merge nginx from debian again, or were you planning on doing that?
<rbasak> rbalint: o/ I'm reviewing this glibc SRU. In bug 1889190, what's the user story that's broken please? And shouldn't it be fixed in Groovy first?
<ubottu> bug 1889190 in glibc (Ubuntu Focal) "ldconfig is still deferred in libc6.preinst " [Undecided,New] https://launchpad.net/bugs/1889190
<rbasak> rafaeldtinoco: o/ couple of quick queries on your bcache-tools SRU for Xenial please
<rafaeldtinoco> xenial ?
<rbasak> Oh Bionic sorry
<rbasak> I have Xenial in my head
<rafaeldtinoco> ah =)
<rafaeldtinoco> sure
<rbasak> Because the version number in your upload would clash with a Xenial SRU should that be required
<rbasak> Can you see if you agree please?
<rbasak> Second question - I note this was already accepted into Focal, but I'm puzzled by the dependency on gawk
<rafaeldtinoco> oh
<rafaeldtinoco> rbasak: I missed that, yes
<rafaeldtinoco> just saw it
<rbasak> The code being added calls "awk" by name, which would be subject to update-alternatives
<rbasak> If gawk is specifically required, then I'd expect gawk to be called by name explicitly, as well as the depependency
<rafaeldtinoco> rbasak: so I had an issue with awk (mawk vs gawk recently)
<rafaeldtinoco> you prefer us to call a specific one ?
<rbasak> If you need a specific one, then I'd expect that
<rbasak> If you don't need a specific one, then I'm not sure you need the dependency?
<rafaeldtinoco> I dont think for this case a specific one is needed
<rafaeldtinoco> rbasak: I thought I had a dep for it
<rafaeldtinoco> it was part of paelzers review
<rafaeldtinoco> one of his requests iirc
<rafaeldtinoco> unless Im confusing with other revirew
<rafaeldtinoco> let me check
<rbasak> It's not marked Essential so maybe you do need a dependency
<rafaeldtinoco> rbasak: im thinking because of groovy & focal
<rafaeldtinoco> -Depends: ${misc:Depends}, ${shlibs:Depends}
<rafaeldtinoco> +Depends: ${misc:Depends}, ${shlibs:Depends}, gawk
<rafaeldtinoco> for groovy
<rafaeldtinoco> focal also has it
<rafaeldtinoco> rbasak: ok all 3 have the same change
<rafaeldtinoco> to debian/control (Depends)
<rafaeldtinoco> isn't that enough ?
<rbasak> I would have used "mawk | awk" or something
<rafaeldtinoco> oh
<rbasak> What you have isn't incorrect, but it would cause gawk to get pulled in to an SRU if the user doesn't have it installed I think
<rafaeldtinoco> I see what you mean
<rbasak> Although
<rafaeldtinoco> makes sense
<rbasak> lsb-core depends on it
<rbasak> As does byobu
<cpaelzer> we have alinged to some common packages already depending on it that way, but we didn't check which ones
<rbasak> mawk is in the minimal seed
<rbasak> So we can always expect that
<cpaelzer> rbasak: is there a single bug for "please get mysql5.7 into debian (testing)" ?
<rbasak> cpaelzer: you mean 8.0?
<cpaelzer> yeah
<rbasak> There isn't, but also it would only be unstable, not testing
<rafaeldtinoco> rbasak: with those dependencies and an already done SRU for focal with gawk, should we stick to gawk for bionic just so things are the same ? And I recently had a regression in +1maint because of mawk vs gawk syntax (autopkgtest dependencies though).. I thought the same about alternatives / mawk being the default fort minimum
<rbasak> rafaeldtinoco: I accepted that Focal is done that way. But if it introduces something undesirable, then we have an opportunity to not do that to users for Bionic here.
<rbasak> OK
<rbasak> Leave it as it is.
<rafaeldtinoco> rbasak: I can change, no complains
<rafaeldtinoco> I thought about uniformity vs fixing it =)
<rbasak> I'll leave it to you then. I'll accept either way.
<rafaeldtinoco> rbasak: just to confirm
<rbasak> It does mean more work for you if one of them turns out to be wrong.
<rafaeldtinoco> having mawk would be better
<rafaeldtinoco> right ?
<rafaeldtinoco> because its already part of min installation
<rbasak> IMHO, using mawk would be better since that's guaranteed to be present on Ubuntu, and wouldn't pull in a dependency - especially in adding that in an SRU.
<rbasak> Right
<rbasak> It's fine to know about a shortcoming and depend on gawk, but in that case gawk needs to be used explicitly rather than assuming which way the update-alternative points
<rafaeldtinoco> yep
<rafaeldtinoco> one thing Im afraid now Robie
<rafaeldtinoco> Im pretty sure I have tested everything with gawk
<rbasak> Right
<rbasak> That's why I'll accept gawk for Bionic :)
<rafaeldtinoco> but I can call it directly
<rafaeldtinoco> rbasak: should I change a direct call s/awk/gawk and repush ?
<rafaeldtinoco> to be 100% ?
<rbasak> Sure if you want to do that
<rbasak> Remember to fix the version string please
<rafaeldtinoco> alright, ill fix both and ping u back
<rafaeldtinoco> thanks!
<rafaeldtinoco> rbasak: should I use 1.0.8-2ubuntu1 or 1.0.8-2ubuntu1.0 ?
<rafaeldtinoco> xenial could have a 1.0.8-2ubuntu0.1
<rbasak> 1.0.8-2ubuntu0.18.04.1?
<rbasak> That would leave 1.0.8-2ubuntu0.16.04.1 for Xenial, etc
<rafaeldtinoco> perfect
<cjwatson> cpaelzer: https://paste.ubuntu.com/p/RhFWhJHW2Z/
<rafaeldtinoco> rbasak: as I had uploaded 1.0.8-2ubuntu0.1
<rafaeldtinoco> this will also solve that correct ?
<rafaeldtinoco> just checking
<rafaeldtinoco> (I assume I have to overseed the previous upload to -proposed)
<rafaeldtinoco> (and should I force push to git-ubuntu pkg also ? the new upload tag ?)
<rbasak> rafaeldtinoco: yes I will reject the old upload so it will be as if that didn't happen. You can push the new upload tag and delete the old one
<rafaeldtinoco> perfect. thanks
<cpaelzer> thanks cjwatson
<rafaeldtinoco> rbasak: taking a few to test it against the test case again
<rafaeldtinoco> just to make sure =)
<rbasak> Sure
<cpaelzer> seb128: Laney: in proposed are all kind of things around *compiz* 2:0.8.18 most of them blocked on missing build dep (one epoch away).  I come from a +1 POV, is Desktop handling these and I can go on without looking into it?
 * cpaelzer reads old +1 report mails if something was mentioned
<cpaelzer> "all kind" may be too much
<cpaelzer> looking a bit deeper it is down to two things
<cpaelzer> https://launchpad.net/ubuntu/+source/compiz-plugins-experimental/2:0.8.18-1
<cpaelzer> https://launchpad.net/ubuntu/+source/compizconfig-python/2:0.8.16-2
<seb128> cpaelzer, I don't think anyone in desktop has been working or interested by those
<seb128> mitya57 might know better the status
<cpaelzer> seb128: I'm clearing out packages like these - if I could get a clear "we don't need and are not interestd in those" that woudl be enough
<cpaelzer> mitya57: let me know once you read that
<mitya57> cpaelzer: Debian decided to use a fork of Compiz 0.8. We are using 0.9 where all code is in a single source, so all those source packages should be deleted/blacklisted.
<cpaelzer> thank you
<cpaelzer> will let that happen then
<seb128> mitya57, thanks
<cpaelzer> essentially is a re-occurance of 1844626 - I'll try to ensure it stays non-synced this time
<rbalint> rbasak, thanks for reviewing glibc, yes the fix is planned to land in groovy next weeks with the other fixes in the upload
<rbalint> rbasak, with do-release-upgrade the bug did not cause problems in my testing, but it is still reproducible the way listed in the bug
<rafaeldtinoco> rbasak: upload/1.0.8-2ubuntu0.18.04.1 (uploaded) sources file pushed
<bdmurray> bryyce: node-redis has passed for me multiple times. do you want to add it to long_tests or shall I?
<bryyce> bdmurray, that's great to hear.  I haven't marked long tests before but would love to learn how.
<bdmurray> bryyce: I tried to write enough down here if its inadequate let me know and I'll give you a hand. https://wiki.ubuntu.com/ProposedMigration#autopkgtests
<bryyce> thanks
<seb128> rbalint, hey, did you get anywhere with systemd vs plymouth?
<cpaelzer> rbalint: I was checking the systemd autopkgtests which were flaky retries and which were real issues
<cpaelzer> rbalint: and it seems all were flaky (most resolved now and src:audit in the queue to be tested)
<cpaelzer> rbalint: but one remained - plymouth - that seemed to be a genuine issue and I found https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1886886/comments/2
<ubottu> Launchpad bug 1886886 in plymouth (Ubuntu) "Plymouth 0.9.5 release" [Wishlist,Fix committed]
<cpaelzer> I wanted to ask what became of this and if you could update the bug if something was e.g. added to systemd/245.7-1ubuntu1 for it
<seb128> vorlon, hey, could you have a look to the speech-dispatcher-contrib i386 build failure? it seems a fallout from your change you upstreamed to Debian but unsure why it didn't bite us previous cycle?
<LocutusOfBorg> niedbalski, debian bug opened, and uploaded in Ubuntu groovy
<niedbalski> LocutusOfBorg: great, thank you.
<LocutusOfBorg> please send upstream your patch
<LocutusOfBorg> <BTS> Opened #968298 in src:bind9-libs 1:9.11.19+dfsg-1 by Gianfranco Costamagna (locutusofborg) Â«bind9-libs: SEGFAULT on redundant dhcp server configurationÂ». https://bugs.debian.org/968298
<ubottu> Debian bug 968298 in src:bind9-libs "bind9-libs: SEGFAULT on redundant dhcp server configuration" [Important,Open]
<niedbalski> LocutusOfBorg: iiuc, it would be difficult to land that patch in upstream, only affects stable branches and the code around socket event handling was entirely refactored in most recent releases.
<LocutusOfBorg> so, it isn't a problem in the last version?
<niedbalski> LocutusOfBorg: it is in the version that ubuntu has 9.11.19+dfsg-1, but we are far behind upstream releases in libisc-export, i'd have to check if it is reproducible with current master, but a quick glance at the code, shows a huge delta of changes / complete refactor in that area.
<ahasenack> LocutusOfBorg: niedbalski: keep in mind we have two sources for bind9 in focal+. bind9-libs builds just the libraries for legacy apps like isc-dhcp who don't work with the latest upstream (9.16.x), isc-dhcp being one
<ahasenack> then we have bind9, which is 9.16.x (upstream's latest LTS track), which builds the server and the libraries used by that server, but NOT by isc-dhcp
<niedbalski> LocutusOfBorg: ahasenack: okay, thanks. the patch is only required for isc-dhcp (afaik) in focal+, therefore the change in bind9-libs shouldn't affect bind9 itself.
<ahasenack> correct
<ahasenack> we had to keep this legacy bind9 code around because of isc-dhcp, debian installer, and bind-dyndb-ldap iirc
<ahasenack> but mostly isc-dhcp
<niedbalski> ahasenack: understood
<ahasenack> great work fixing that, btw
<niedbalski> LocutusOfBorg: the debdiff for focal is also attached to the bug, unsure if you'll use that or merge back from groovy
<niedbalski> ahasenack: thank you a lot for the clarification, somebody was suggesting to verify bind9, but giving this, that won't be required
<ahasenack> right, it won't affect bind9
<rbalint> cpaelzer, seb128 i plan adding a fix to next systemd upload, will update  the bug, too
<rafaeldtinoco> waveform: ping (on open-iscsi)
<rafaeldtinoco> are you uploading gcc-10 patch anytime ? cause I'm merging it to 2.1.1 today, and I think it already contains the fix.
<rafaeldtinoco> just wanted to sync
<seb128> rbalint, thanks
<vorlon> rbasak: what I /want/ is baseline retesting so that we don't have to add manual hints ;) but in the meantime, the 'force-reset-test' hint, with a version number, is the most semantically correct
<vorlon> rbasak: where would you want this documented?
<waveform> rafaeldtinoco, ah - nice - I'll close the bug and wait for the merge, thanks!
<rafaeldtinoco> waveform: tku!
<vorlon> seb128: hmm I don't see what these build failures related to speech-dispatcher-kali have to do with my patch to omit speech-dispatcher-festival from the i386 build
<xnox> mwhudson: hm rustc has been building for 21h now. Yet in Debian it built in 11h. Do you know what is normal amount of time for rust to build on riscv64?
<cjwatson> xnox: That doesn't seem like much of an apples-to-apples comparison, since our builders are emulated but that 11h time is from a native build
<xnox> cjwatson: oh, they have native builders?! Where? How? What? I want that!
<cjwatson> https://people.debian.org/~mafm/posts/2019/20191211_debian-gnulinux-riscv64-port-sponsors-and-build-machines/
<cjwatson> A number of Debian's riscv64 buildds are still emulated, but rv-rr44-01 is one of the native ones
<cjwatson> The remark about "frequent lock-ups" there doesn't make me enthusiastic about operating them, but maybe that comment is dated ...
<xnox> thanks, and yeah it's just the hifive-unleashed boards not quite datacentre hardware / servergrade.
<cjwatson> Yeah.  I mean more power to them giving it a go
<cjwatson> But I'm not volunteering to be managing those things :)
<seb128> vorlon, are we looking at the same thing? https://launchpad.net/ubuntu/+source/speech-dispatcher-contrib/0.10.1-1/+build/19789421
<seb128> vorlon, dh_gencontrol: error: Requested unknown package speech-dispatcher-festival via -N/--no-package, expected one of: speech-dispatcher-pico speech-dispatcher-baratinoo speech-dispatcher-kali speech-dispatcher-ibmtts
<seb128> is the error from what I see
<seb128> vorlon, I think that's because the same source is used to build speech-dsipatch and -contrib
<seb128> but the binary doesn't exist so the rule should probably be limited to the first one?
<vorlon> seb128: ah I was looking at the dpkg-shlibdeps warnings, sorry.  Uh so the -N option is still there but the package is no longer built from this source?
<vorlon> seb128: yeah so the debian/rules special case should just be dropped because speech-dispatcher-festival is commented out in debian/control...
<LocutusOfBorg>  niedbalski the diff you provided is already in unapproved queue
<seb128> vorlon, ups, my IRC disconnected but I didn't notice ...checking again I think the same content is used to generate speech-dispatcher and speech-dispatcher-contrib sources, there is some debian/rules sed lines to generate one or the other
<seb128> vorlon, so your fix works for speech-dispatcher but broke -contrib (which you didn't seem to have update/uploaded at the time)
<vorlon> seb128: ah I see, so the problem is my patch is applied to a source package I didn't submit it to ;)
<vorlon> so a more complete fix would be to check for the package in the output of dh_listpackages before setting the -N option
<seb128> right, sort of
<seb128> of have a 'if source' condition in addition of the ubuntu/i386 ones
<vorlon> I don't know a sensible interface for checking source package name from within debian/rules; dh_listpackages is easy
<tumbleweed> dpkg-parsechangelog, probably
<seb128> vorlon, k
<vorlon> tumbleweed: yeah - which is a hassle :)
<vorlon> not a "sensible interface" :)
<tumbleweed> :)
<seb128> ifneq (,$(filter speech-dispatcher-festival,$(shell dh_listpackages)))
<seb128> ?
<seb128> vorlon, do you want to fix/upload or should I try that ^ ?
<mwhudson> xnox: hm the one in focal built in 15h https://launchpad.net/ubuntu/+source/rustc/1.41.0+dfsg1+llvm-0ubuntu2/+build/19157331
<vorlon> seb128: please go ahead
<ddstreet> vorlon i'm stumped on software-properties migration from groovy-proposed, it complains about unsatisfiable deps for i386 and riscv64, but there are no new binary deps, just python3-launchpadlib, so i'm not sure how any previous versions got promoted...?
<ddstreet> not sure if i'm missing something in the process, or if it was just manually approved before
<seb128> vorlon, k
<seb128> ddstreet, where do you see that?
<seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has
<seb128> Will attempt migration (Any information below is purely informational)
<seb128> "software-properties-common/i386 has unsatisfiable dependency, but it is already uninstallable in the target suite so never mind. "
<seb128> ddstreet, seems like it's going to migrate on the next publisher?
<ddstreet> is that what it means?
<ddstreet> ok i misread it then :)
<seb128> 'so never mind'
<seb128> also 'is purely informational'
<ddstreet> lol, well never mind i will do then :)
<ddstreet> thanks!
<seb128> np!
<mwhudson> i kind of love the britney "xx yy zz problem but never mind" messages
<mwhudson> although they are a bit confusing
<mwhudson> i can totally imagine the coding process that leads to them
#ubuntu-devel 2020-08-13
<cpaelzer> wgrant: I was unable to get the dbus-test-runner hang to occur in a local qemu based riscv build of dee
<cpaelzer> wgrant: I have thrown the bit of info that I found into 1891158
<cpaelzer> and unblocked (for now) src:dee by skipping the tests on riscv64 - bumping up the timeout didn't help
<cpaelzer> so far just FYI in case you want to subscribe to the bug and/or put it on your "sometime I should get to this" List of things that we all have :-)
<seb128> vorlon, firebird3.0 unsatisfiable Build-Depends(-Arch) on i386: recode
<seb128> do you know what's going on there? recode seems to be build on i386?
<xnox> mwhudson:  1 day and 9h later hopefully rustc on riscv64 is now publishing https://launchpad.net/ubuntu/groovy/riscv64/rustc
<wgrant> xnox: Nicely done
<xnox> wgrant:  well launchpad publication history looks very odd, if i'm doing this again for focal, i think i will do "no change rebuild" such that things all arches are built in the same bileto ppa (which happens to have bootstrap compiler for riscv64 available as a build-dep)
<xnox> hopefully, it will publish fine.
<wgrant> xnox: What's weird about it?
<xnox> wgrant:  at https://launchpad.net/ubuntu/+source/rustc/1.43.0+dfsg1+llvm-1~exp1ubuntu2 buildlog is not yet visible, and riscv64 points at the in-archive build, instead of the copy from bileto.
<xnox> (and the build in bileto)
<xnox> wgrant:  i think i should upload no-change rebuild after this publishes.
<wgrant> xnox: Both builds are there
<xnox> https://launchpad.net/ubuntu/groovy/riscv64/rustc/1.43.0+dfsg1+llvm-1~exp1ubuntu2 => i can click under Downloadable files on to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4195/+build/19815578
<wgrant> Which is a bit weird, but it happens.
<xnox> i found a UI way to find it, so i am good.
<xnox> seb128:  rbalint: retriggered systemd tests with plymouth isc-dhcp triggers to hopefully have them pass and everything migrate.
<seb128> xnox, thanks
<xnox> mwhudson:  "rustc unsatisfiable Build-Depends-Indep on amd64: wasi-libc (<= 0.0~git20200114.1fad338++)"
<mwhudson> xnox: is that in focal?
<xnox> mwhudson:  groovy
<mwhudson> xnox: oh
<mwhudson> it's fairly easy to hack out the wasm stuff
<xnox> mwhudson:  i guess we need to keep up bootstrapping rustc up? cause debian is at 46 now, and we are now at 43
<mwhudson> xnox: i guess so
<xnox> and one can only jump by one?
<mwhudson> so apparently jumping by more than one "usually" works
<mwhudson> but officially ye
<xnox> mwhudson:  i guess i'll throw 44 build into my bileto PPA, to then throw 45 build into it, to finish with 46?
<mwhudson> s
<xnox> let me check the contol file restrictions
<mwhudson> rustc updates are usually fairly simple, it's cargo ones that are a headache
<mwhudson> oh but if we're just merging from debian, that's usually fine
<xnox> somehow our cargo is ahead of debian
<xnox> but behind upstream
<xnox> we are at 44 cargo, upstream is at 46 and debian is at 43
<mwhudson> how does debian have rustc 1.46 but not the corresponding cargo?
<xnox> oh 46 is in experimental
<xnox> debian is at 45 rustc in sid
<xnox> with cargo at 43 in sid
<xnox> dunno
<mwhudson> yeah was going to say, is 1.46 even out yet?
<mwhudson> i only update rustc when osomon asks me to :)
<xnox> hahhahahahha
<xnox> well it can't migrate now, so either new rust, or rebuild with "nowasm"
<xnox> but i think we want new rust, no?
<mwhudson> let me find the wasm disabling thing
<mwhudson> yeah rolling forward probably makes sense
<mwhudson> but might be nice to make it migratable before we get there, dunno
<mwhudson> xnox: https://git.launchpad.net/~canonical-foundations/ubuntu/+source/rustc/commit/?h=focal-1.43&id=1439259a505ca4053c2a81d726e821213f0c34e9
<xnox> mwhudson:  why do we even build it if nothing uses it? =)
<mwhudson> xnox: /me points at debian
<mwhudson> xnox: although i'm not sure quite what you're asking?
<xnox> oh
<xnox> but rustc is, well urgh.
<xnox> your merge is large.
<xnox> i don't want to merge it =)
<xnox> i'd like rather rollback wasi-lib or cherrypick things for new one.
<xnox> i think we should drop building wasi-lib for now, I don't see the point of it.
<xnox> mwhudson:  hm, based on https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox we will need rust 45 soon.
<mwhudson> xnox: better get cracking then i guess
<xnox> so i'll create bileto ppas that build a sync of 44 & 45.
<xnox> which we then will be able to use for the build of rustc which is "merged" properly.
<rbasak> What version would be suitable for chromium-browser in Groovy then? 1:0?
<rbasak> 1:0ubuntu1 maybe?
<rbasak> Looks like it's currently a non-native package
<seb128> rbalint, sorry I missed the backlog, what's the issue?
<seb128> rbalint, it's a native package, just including an ubuntu revision in the version number?
<seb128> ups
<rbasak> :)
<rbasak> I mean https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041127.html
<seb128> rbalint, sorry, that was for rbasak
<seb128> I just saw that
<seb128> Olivier is out this week, let's wait monday for him to be back?
<rbasak> I thought it might be wise to decide now to save round tripping if I'm unsure when Olivier uploads
<rbasak> Ah I didn't realise. Sure, thanks.
<seb128> maybe accept that round of SRU meanwhile
<rbasak> Can do if you think it's important to land it now?
<seb128> to avoid having a concrete upgrade issue after the next security round
<seb128> well if a security update in bionic become higher than focal than upgraders from bionic to focal aren't going to get the snap
<rbasak> OK sure
 * rbasak looks
<seb128> that's already the case it seems?
<seb128> bionic has 84.0.4147.105-0ubuntu0.18.04.1
<seb128> and focal proposed 84.0.4147.89-0ubuntu0.20.04.1
<rbasak> Yep so I'll accept this one in the Focal queue, right? That'll bring it up to 84.0.4147.105-0ubuntu0.20.04.1
<seb128> yes, that fix the immediate problem
<seb128> then we can sort out the epoch use when Olivier is back
<seb128> rbasak, thanks!
<rbasak> Done - though that's only in proposed
<seb128> that's a first step
<seb128> we can maybe discuss lowering the testing to less than a week, that's only a version bump
<rbasak> I agree that should be fine.
<rbasak> Probably best for someone to check the binary transitional package is as expected after it's built though
<rbasak> Just to try to detect any human error
<seb128> right, I will do that
<rbasak> Oh and if possible, today would be better than tomorrow to release - because Friday
<rbasak> Thanks!
<seb128> np, thank you for the review!
<rbasak> vorlon: so you want force-reset-test over SRUing a fixed test? This is a case where the broken test is affecting the SRU of a different package.
<rbasak> vorlon: documentation in https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions please? I think what's there is out of date then?
<rbasak> vorlon: I'd like a table mapping "situation" to "action expected".
<rbasak> Where "action expected" might be "fix the autopkgtest in an SRU", "add a hint (specifying the type of hint)" and so on.
<rbasak> Right now I'm not clear on what you intend for those things.
<ahasenack> good morning
<seb128> ddstreet, so yeah, I was wrong yesterday, software-properties isn't migrating, it's blocked now because it makes livecd-rootfs uninstallable on i386, I expect it's due to the new depends on python3-launchpadlib
<ddstreet> seb128 i'm not sure why that is though, python3-launchpadlib is 'all' arch
<seb128> that's probably not installable on i386 currently?
<Laney> correct
<ddstreet> why isn't it installable on i386 if it's 'all' arch?
<seb128> ddstreet, yeah, unsure, maybe that's not it, I guess you need to set up an i386 env to try...
<ddstreet> ack, i'll look into it, it's confusing though
<seb128> indeed, I wish it was easier to locally try those i386 problems :/
<Laney> arch:all packages can depend on arch-specific ones
<ddstreet> Laney right i get that, and in fact software-properties-common does (and python3-softwareproperties depends on it, and livecd-rootfs depends on that...so not sure how any of this 'worked' already)
<ddstreet> ah, ok i see python3-software-properties doesn't dep on any of the other pkgs
<Laney> ddstreet: It's probably going to turn out to be that some packages need 'bringing back' on i386 to make it installable again, first step would be to investigate in a chroot to find out what they are
<ddstreet> at least python3-cryptography and python3-simplejson
<ddstreet> unfortunately the 'livepatch' additions to python3-software-properties didn't actually update the pkg deps, as the new addition of softwareproperties.LivepatchService actually imports softwareproperties.gtk without declaring the dep on software-properties-gtk
<ddstreet> i dont want to get into pulling the -gtk deps into i386...
<ddstreet> rcj if i'm reading livecd-rootfs right, the only thing it needs python3-software-properties for is to print out a ppa signing_key_fingerprint?
<ddstreet> if that's all, i can totally redo that for the livecd-rootfs pkg so we can drop the python3-software-properties dep
<ddstreet> (or we could stop building livecd-rootfs for i386...)
<cjwatson> Stopping building livecd-rootfs for i386 is not very possible, as it's required as part of having LP builds for i386 at all
<cjwatson> (At least in the present configuration.  Other configurations are conceptually possible but would be a good deal of work)
<cjwatson> I don't think the software-properties bits are needed to make buildd chroots work though
<xnox> mwhudson:  rustc ubuntu archive build record kicked in now. I think you will get weird emails about it failing to upload, but we shall see.
<xnox> and 44 build in bileto from debian ftbfs on i386, because llvm9 is gone. So yeah, to bootstrap 44 we will need ubuntu style merge of rustc.
<xnox> not sure i want to do that.
<xnox> horay
<xnox> rbasak:  systemd + isc-dhcp are migrating now
<rbasak> Was that for me?
<Odd_Bloke> xnox: vorlon: I'd appreciate your thoughts on https://github.com/canonical/cloud-init/pull/514/files#r469464608
<rafaeldtinoco> FTR: on-going open-iscsi merge (https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/389234)
<rafaeldtinoco> vorlon: ^ keeping your delta (the ones I did not merge in debian yet), will cleanup iscsi-root support (and merge things in debian as accepted) as a next step
<rafaeldtinoco> im also keeping history as split git-ubuntu merges to keep history to server team when 1.1.1-1 from debian gets imported into usd-importer
<rbalint> xnox, \o/
<slingamn> i submitted a draft review for a change to software-properties, but i seem to have mistakenly pinged the entire "Ubuntu Core Development Team"
<slingamn> any suggestions for  an individual reviewer for a software-properties change?
<vorlon> ddstreet: I think we're nearly there on python3-launchpadlib; looks like it should only be 3 python packages that need added to the set (python-cryptography, simplejson, python-cffi)
<ddstreet> vorlon awesome, and you want to use the alternate MR, to change livecd-rootfs to use python3-launchpadlib directly?
<vorlon> ddstreet: I haven't seen the MP, can you link me to it?
<ddstreet> https://code.launchpad.net/~ddstreet/livecd-rootfs/+git/livecd-rootfs/+merge/389260
<vorlon> thanks, I'll have a look
<vorlon> xnox: why did you copy recode from groovy to groovy-proposed?
<vorlon> xnox: ... because you were trying to make firebird3.0 build on i386, I guess... should've used --force-same-destination and copied it back to groovy instead
<vorlon> seb128: recode restored in groovy release, so firebird3.0 should be migratable shortly
<seb128> vorlon, thanks
<vorlon> rbasak: from what I see, https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions already documents this, aside from the s/force-badtest/force-reset-test/ optimization?
<vorlon> ddstreet: and python-cryptography is built now on i386 so I believe as soon as we get a publishing run + britney run, software-properties should be good to migrate; if not, feel free to yell
<realtime-neil> what's a good and proper way for an _unprivileged_ user to change his/her own locale, console keymap, x11-keymap-{layout,model,variant} --- and have that choice persist across login/reboots ?
<vorlon> realtime-neil: an unprivileged user doesn't get to change the console keymap, the console is privileged
<realtime-neil> vorlon: understood. what about the other items?
<vorlon> realtime-neil: if you're using the Ubuntu Desktop and the necessary locale packages are installed, you should be able to configure everything through Settings -> Region and Language
<realtime-neil> What if the "Region & Language" is missing from gnome-control-center?
<realtime-neil> vorlon: related question: How does one restore the "Region & Language" tab to the gnome-control-center?
<vorlon> realtime-neil: I have no idea how you would have managed to do that; and this is not a user support channel, maybe ask in #ubuntu?
<realtime-neil> will do
<smoser> anyone else seen this: https://paste.ubuntu.com/p/Hdxt9hMgwG/
<smoser> INFO: pkgstripfiles: waiting for lock (cloud-initramfs-rooturl) ...
<smoser> keeps repeating
<seb128> software-properties did migrate, thanks vorlon!
#ubuntu-devel 2020-08-14
<cpaelzer> hi wgrant, is gdb on (emulated) riscv64 fully functional?
<wgrant> cpaelzer: it's worked fine in my experience
<cpaelzer> I was trying to debug a crash and can't see a backtrace at all - which might be part of the problem I try to analyze OR it might be that gdb support isn't complete on that platform
<cpaelzer> ah ok, then I'll assume ti is part of the problem that I search
<cpaelzer> thanks wgrant
<cpaelzer> I wanted to make sure I won't go red herring fishing ...
<wgrant> cpaelzer: Ah, I wouldn't be *that* sure it was reliable.
<cpaelzer> hehe
<cpaelzer> it is fine, hearing that it was seen working is what I wanted to hear
<cpaelzer> but e.g. I get (so far) no backtraces at all
<cpaelzer> so I got wondering if it might be a platform issue
<cpaelzer> got a bt now
<cpaelzer> need to find where it break, but that is problem-specific not riscv64 specific
<Laney> seb128: https://launchpad.net/~laney/+archive/ubuntu/lo-test1/+build/19822873 indeed the no-change rebuild of 6.4.5 crashed the compiler cc vorlon - hopefully 6.4.4 doesn't have this problem ...
<seb128> 'fun'
<seb128> (not)
<cpaelzer> Laney: seb128: there have been armhf gcc crashes since gcc-10
<cpaelzer> is this one reproducible at least - the othere ones were not
<Laney> yeah it seems to be
<cpaelzer> bug 1890435 and bug 1887557 (the latter being fixed)
<ubottu> bug 1890435 in gcc-10 (Ubuntu) "gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation fault" [Undecided,New] https://launchpad.net/bugs/1890435
<ubottu> bug 1887557 in gcc "GCC 10 is crashing with an internal compiler error when compiling Mesa" [Medium,Fix released] https://launchpad.net/bugs/1887557
<Whoopie> Hi, do we have support for wireguard in 20.04's VPN panel? Which package does provide it?
<Laney> I don't think we got a successful armhf libreoffice build with gcc-10 yet
<Laney> at least not afaik
<cpaelzer> ok, so on the good side yours at least can be tracked and debugged - on the bad side thou how to compile until then :-/
<Laney> not sure if it's always the same object though
<Laney> 24 hour turnaround time!
<cpaelzer> outch
<cpaelzer> yeah it might be just compiling so much that it fails at some random point each time
<seb128> to add even more fun, that is in the way of the icu transition
<Unit193> Whoopie: Sounds like something you may wish to ask in #ubuntu.
<Whoopie> Unit193: ok
<Laney> cpaelzer: I'll file it separately in case there are two bugs here, can be merged if needed later
<cpaelzer> yep
<Laney> ricotz: did you see a successful armhf build of LO with gcc-10 yet? can you point me to some fail logs pls?
<Laney> how come it works @ Debian?
<ricotz> Laney, is debian using gcc 10 by default yet?
<Laney> ah
<Laney> true, I didn't check that!
<ricotz> https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-prereleases/+build/19818811
<ricotz> sorry, it isn't there yet
<Unit193> ricotz: Yes.
<Laney> https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=1%3A7.0.1%7Erc1-1&stamp=1597356576&raw=0 yeah it did use 10
<Laney> ricotz: have you got a build of that versin 7.0.1~rc1?
<ricotz> Laney, the links points to a 7.0.1.1 ppa build
<Laney> cool
<Laney> keep an eye on that one then
<Laney> ... in 12 hours Â¬_Â¬
<ricotz> as expected the focal armhf build is happy
<ricotz> with gcc 9
<Laney> yeah
<ricotz> so yeah, using gcc 9 this specific build would be an option
<Laney> I just kicked off builds of 6.4.4/6.4.5 with gcc-9 (for all arches though) in two silos
<ricotz> ok
<Laney> in case this autopkgtest problem is some other 6.4.5 regression
<ricotz> my 6.4.6~rc2 builds were happy on focal
<Laney> did you try the autopkgtest on armhf?
<ricotz> https://launchpad.net/~libreoffice/+archive/ubuntu/ppa/+sourcepub/11525210/+listing-archive-extra
<Laney> that's what we were seeing sadness with on groovy lately
<ricotz> no, I don't an environment for that
<Laney> ah yeah, this is where you need upload rights ;-)
<Laney> or a raspberry pi :p
<seb128> Laney, http://autopkgtest.ubuntu.com/packages/libreoffice/focal/armhf has an happy 6.4.5/armhf/focal result
<Laney> ok cool
<Laney> didn't notice it got SRUed there
<seb128> I mentioned it the other day when we talked about new version regression, but that probably got lost in the middle of the discussion
<Laney> likely
<Laney> too many versions of different things going on
<seb128> I hope we get enough clarity to find a way forward with one of the options
<seb128> probably for monday at this point though
<doko> ricotz, Laney: LO successfully built using gcc-10 in the test rebuild
<Laney> k!
<xnox> vorlon:  yes, and i didn't know about force-same-destination. Also not sure if i can copy things to groovy, i think as a core-dev i can only upload things to proposed.
<Laney> I think that's true
<ahasenack> vorlon: hi, just found an issue with motd-news-config, looks like it inherited "Priority: required" from src:base-files https://launchpad.net/ubuntu/groovy/amd64/motd-news-config/11ubuntu11
<ahasenack> is that something I can override in d/control for it? What should the new value be, optional?
 * ahasenack sets optional
<vorlon> ahasenack: right, though the archive also has priority overrides which take precedence, so I'll also override it now.
<ahasenack> thanks
<ahasenack> vorlon: for all releases, i suppose?
<vorlon> ahasenack: yes
<ahasenack> I found this testing a release upgade from a focal desktop to groovy
<ahasenack> ok, thanks
<vorlon> I mean, I can only override it for series where the binary is already published
<ahasenack> so it will have to be a reminder in the sru?
<vorlon> if you set the priority in debian/control before SRUing, I *think* that will DTRT, but it would be good to have the reminder as well in the SRU bug
<vorlon> best to make it part of the test case
<ahasenack> ok, I will add it
<ahasenack> I ahve 9 tests cases already, what is another one :)
#ubuntu-devel 2020-08-15
<LocutusOfBorg> mitya57, hello, llvm-toolchain-11 and llvm-toolchain-snapshot FTBFS due to new sphinx... any idea?
#ubuntu-devel 2020-08-16
<mitya57> LocutusOfBorg: looks like recommonmark needs to be updated from 0.4 to â¥ 0.5
 * mitya57 will do it
<mitya57> LocutusOfBorg: oh well, it's complicated. Debian currently has only old commonmark-bkrs packages. However new recommonmark needs new commonmark which is incompatible with -bkrs so needs to be a new source package.
<mitya57> See also https://salsa.debian.org/python-team/modules/commonmark-bkrs/-/blob/master/debian/README.Debian
<mitya57> LocutusOfBorg: I don't have much time now, maybe you can package new commonmark? And then we will need to wait until it passes NEW queue.
<LocutusOfBorg> mitya57, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962721
<ubottu> Debian bug 962721 in wnpp "ITP: commonmark -- Python parser for the CommonMark Markdown spec" [Wishlist,Open]
<LocutusOfBorg> is this what you are referring to?
<LocutusOfBorg> and its already in new queue, I asked to process it
<mitya57> LocutusOfBorg: ah, wonderful. Thanks for asking. I will update recommonmark once that is processed.
<LocutusOfBorg> thanks
<LocutusOfBorg> so I presume at the end llvm-* will start building without any further change
<mwhudson> icu is migrating?
<mwhudson> that was an easy +1 shift
 * mwhudson goes back to bed
<mwhudson> hmmm it's not migrating though
