#ubuntu-devel 2004-12-06
<seb128> ok ok
<enrico> elmo: around?
<seb128> so go with the compatibility stuff
* jdub attempts to fix the NDEBUG assert b0rk
(lamont/#ubuntu-devel) hrm... gonna have to reboot
(lamont/#ubuntu-devel) changing IP's will do that to you...
<enrico> wiki login has been fixed
* enrico cheers elmo
<pitti> mdz: ping
<seb128> 'night
<jdub> night seb128 
<pitti> night seb128 
<jdub> elmo: did you see my paste above?
<__daniel> bye seb128
<pitti> elmo: one last upload from chinstrap, because the mysql package was already there anyway. Sorry... 
<elmo> jdub: err, yes, why is that a surprise?
<elmo> your key isn't in the debian keyring?
<elmo> pitti: why doesn't ftp work for you?  is it just with this server or in general?
<pitti> elmo: it's a general problem with my ISP
<pitti> elmo: it works, but it is sloooooooooow
<pitti> elmo: that's why I scp it onto another host and ftp from there
<pitti> elmo: if chinstrap is to be avoided, I can also route it through my own server
<elmo> pitti: ok - I just want to encourage people to test out the new upload daemon - if ftp is fux0red for you, you can use chinstrap
<jdub> elmo: boh
<pitti> elmo: tomorrow I have some smaller packages to fix, I will test it then
<jdub> i thought putting those in DEFAULTS would default to ubuntu
<jdub> bong
* jdub uses the other setting
<pitti> night
<doko> night
<lamont> maybe re-iping things wasn't the best timed act of the day... :-(
<lamont> grumble.  bounced mail.  only about 60 messages though. :-(
<lucas_> hi
<lucas_> somebody with some debian-cd knowledge ?
<lucas_> I need to build iso with software from (uni|multi)verse
<lucas_> it isn't supported, right ?
<lucas_> am I right when I think that the easiest way to fix this is to grep for "restricted" and see what was changed to add "restricted" support ?
<lamont> lucas_: I started with a copy of the CD, added files, replaced the Packages/Sources/Release files, and reburned the CD
<lamont> the rune to make the ISO is "mkisofs -r -V 'Ubuntu 4.10 i386 Bin-1' -o warty-install-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table wherever-your-new-tree-is"
<lamont> understanding what that means is left as an exercise.
* lamont built a warty install-dvd
<lupus_> is discover only called on install of ubuntu?
<lupus_> or each boot
<jdub> only on install
<jdub> during install
<lupus_> why only durring install?
<lamont> lupus_: because warty doesn't use discover.
<lamont> well, mostly
<elmo> hotplug is better, basically and we're migrating to it
<elmo> +even in the installer
<lupus_> ah so hotplug is not used in the installer at the moment
<lupus_> only discover
<elmo> yeah
<elmo> tho, that's already changed in hoary
<lupus_> so /etc/hotplug is for coldplugging and /etc/hotplug.d to have hotplugging? sorry I'm trying to understand how hardware is detected and configured
<lupus_> nm I'm wrong :)
<jdub> http://mail.nl.linux.org/humorix/2004-11/msg00002.html
* sladen chuckles
* ironwolf giggles
* lamont sleeps
<lamont> jdub: heh
<jdub> the final live cd looks brill
(sladen/#ubuntu-devel) "final" ?
<ironwolf> warty? yeah, it's pretty.
<jdub> sladen: the release version, on the pretty printed cds :)
<jdub> i didn't have the b/w to pull many live cd releases
<lamont> ironwolf: did your order show up yet, btw?
<ironwolf> lamont: no, only 3 days left too...
<ironwolf> lamont: although I have had lots more local interest in them when they arrive.
<eruin> blah, I can't rightclick files and create an archive anymore
<jdub> vino + damage == rock!
<lamont> well, night
<jdub> later lamont
<ironwolf> night lamont
* netjoined: irc.freenode.net -> tolkien.freenode.net
<ironwolf> lamont around?
<fabbione> morning guys
<fabbione> lamont: ping
<pitti> Hi all
<jdub> doko: woo!
<lifeless> jdub: what were you pinging about before ?
<jdub> don't remember :)
<jdub> oh
<jdub> here's something though
<jdub> baz register-archive -> do you ever register anything other than an archive?
<lifeless> oh, ui names ?
<lifeless> ie baz register ?
<jdub> yeah
<lifeless> sounds good, chuck it in the mockup UI :)
<pitti> ping lamont
<jdub> lifeless: also, what do you think about splitting that page up a bit? it's getting unwieldy
<jdub> lifeless: happy to take an initial stab at it
<lifeless> please do
<pitti> elmo: here?
<jdub> doko: ping?
<seb128> morning
<seb128> jdub: #4092 is WONTFIX, right ?
<jdub> yeah, atm
<pitti> Hi seb128 
<seb128> hey pitti 
<Kamion> I really must actually upload our modified debian-cd to hoary for this release
<fabbione> hey Kamion 
<fabbione> Kamion: kernel-wedge doesn't like symlinks :(
<fabbione> things need to be copied in proper places for it to work
<Kamion> can you elaborate?
<Kamion> oh, make-links and clean
<fabbione> sure...
<Kamion> yeah, but dpkg-source doesn't much like symlinks in diffs either
<Kamion> at best they'll get expanded into real files
<fabbione> remeber we agreed on the dir structure of debian/d-i/<arch> ?
<Kamion> so you might as well copy
<Kamion> yes
<fabbione> perfect.. to generate debian/control from control.stub, kernel-wedge accesses a bunch of files like modules/<arch>/
<fabbione> the original idea was to symlink those from the top level directory
<fabbione> but kernel-wedge just delete the symlinks
<fabbione> so they need to be copied and removed
<fabbione> in order to keep the top level dir clean
<fabbione> perhaps it would be nice for kernel-wedge to understand symlinks
<Kamion> right, but all the modules/<arch> directories are separate anyway
<Kamion> you might as well just copy them
<fabbione> no big deal.. just some extra cp rm work
<fabbione> Kamion: yes.. i agree. i don't want to clutter the top level dir.
<fabbione> since it is the top level of the kernel
<fabbione> and still other files need to be copied per arch
<fabbione> and this will also keep the merging easier
<mdz> pitti: pong
<pitti> mdz: Hi!
<pitti> mdz: can you please take a look at the mysql USN?
<pitti> mdz: I try to reach lamont or elmo to investigate the missing build from ppc, but as soon as this is sorted out, I can publish it
<mdz> pitti: ok
<mdz> pitti: you can reproduce the problem, right?  it is not just me?
<pitti> mdz: "the problem" ==?
<mdz> I straced it and it is not calling mlock(2)
<mdz> pitti: gpg
<pitti> mdz: ah
<pitti> mdz: I followed up the bug report
<pitti> mdz: it's a buildd problem
<mdz> yes, very strange
<pitti> mdz: it works fine when I build it on my machine and I investigated the cause of the problem
<pitti> mdz: luckily the warty version was built correctly
<mdz> I saw
<mdz> pitti: what do you want me to look at for mysql?
<pitti> mdz: just the USN text
<mdz> I sent email to the list regarding the diffs
<mdz> ok
<fabbione> i think some buildd chroots are having problems
<pitti> mdz: https://chinstrap.warthogs.hbd.com/~pitti/usn-mysql.txt
<fabbione> like having too many apt entries
<pitti> fabbione: so far I only had problems with amd64, it's my first ppc failure
<mdz> pitti: it should note explicitly that -0837 and -0956 require an authenticated mysql user in order to exploit
<fabbione> pitti: i noticed gdb has been built
<fabbione> but using universe packages
<fabbione> that means that some stuff might be actually building for mistake
<fabbione> (talking about hoary)
<lucas_> Hi
<lucas_> I've always been confused by "warty-updates" vs "warty" dists on the mirror
<lucas_> from what I understand, some updates go in "warty", but not all of them ?
<lucas_> or is "warty" totally frozen ?
<daniels> warty's totally frozen
<lucas_> ok
<pitti> mdz: fixed
<seb128> lucas_: changes in warty are mainly security fixes
<lucas_> those go in warty-security right ?
<seb128> yes
<seb128> why ?
<mdz> lucas_: as described on the website, stable releases receive only security fixes and other critical bug fixes
<mdz> pitti: the advisory text needs a few more changes, I will send you an updated version
<pitti> mdz: okay, thanks
<lucas_> yup, my question was about building warty CDs that include the security/bug fixes
<lucas_> but I need to read more debian-cd code
<Kamion> (I'm only limited help here because I've never actually tried doing that ...)
<lucas_> ok, I think I'll start by building CDs based on released warty packages, ignoring updates
<Kamion> that will certainly be easier
<lucas_> no plans to release ubuntu 4.10r(0..n) ?
<Kamion> don't believe so
<lucas_> ok
<smurfix> lucas_: not much point, with a 6-month release schedule. This isn't Debian. ;)
<lucas_> yeah I know, I was just asking because it would have helped me a lot ;)
<Kamion> you could investigate update-cd I guess, but that's *really* never been tested with Ubuntu
<lucas_> ok
<lucas_> the easiest would probably be to write a tool that would merge warty-update and warty-security inside warty
<lucas_> so there's no need to hack debian-cd
<lucas_> (merge in the local mirror)
<seb128> lucas_: do you really need the security updates on the CD ?
<lucas_> it's not high priority, but it would be better
<lucas_> some of my "customers" don't have broadband
<Kamion> lucas_: that's a bit scary; debian-cd *is* capable of reading multiple Packages files in general so it shouldn't be necessary
<lucas_> don't forget grenoble != la doua ;)
<lucas_> ok
<seb128> lucas_:  people who have a network connection just have to download these updates, what's the security issue with people who don't have a network connection ?
<lucas_> the problem is for people who have a network connection but not broadband
<seb128> lucas_: bah, just wondering if a student with no connection really needs the security updates
<seb128> lucas_: security updates already are that big ?
<lucas_> not sure
<lucas_> depends on what is updated ;)
<mdz> lucas_: we have talked about producing CDs containing only security updates
<Kamion> seb128: yes, often
<seb128> ok
<mdz> seb128: xfree86 has been updated, e.g.
<seb128> right
<mdz> lucas_: that is what I recommend that you do, if you are interested in pursuing this
<jdub> doko: around?
<lucas_> mdz: it might be difficult regarding my user base
<__daniel> hai
<lucas_> well, that's not high priority anyway
<lucas_> bbl
<Kamion> mdz: lucas_ is doing a single CD with a number of other modifications anyway
<Kamion> mdz: it makes little sense for him to waste time creating a separate security update CD
<mdz> Kamion: except that the work would be reusable
<Kamion> sure, but it's not what his userbase wants
<Kamion> see ubuntu-devel@
<Kamion> there's no point trying to get reusable work out of somebody when it's not usable for them
<Kamion> mdz: oh, if you didn't notice, I moved mozilla-browser/mozilla-psm from ship to supported yesterday
<Kamion> there seemed to be reasonable consensus for at least that step
<mdz> that's fine by me
<elmo> % linda *.changes
<elmo> Happy birthday to me!
<elmo> I'm 3 today!
<elmo> oh dear
<mdz> Kamion: his userbase will eventually need to download security updates; creating an updated CD doesn't solve that problem at all
<mdz> the security update CD approach has the clear advantage of actually working on an ongoing basis
<Kamion> it'll be no worse than for our own CDs though
<Kamion> I don't think he has a problem either with his userbase having to download some updates or with updating his CD every so often
<Kamion> elmo: linda scares me
<mdz> ok, I guess I don't understand the use case then
<pitti> elmo: can you please look why the mysql security update did not built on ppc?
<elmo> err, it looks like lamont disabled warty-security on the powerpc buildds by mistake 
<pitti> elmo: can you fix that or shall I wait for lamont?
<elmo> I'll have a quick look in a bit
<pitti> thank
<pitti> s
<Kamion> mdz: he's lending CDs to other students in his student union who aren't very computer-knowledgeable; he needs to remove/add some packages to provide for the students' special needs, and he needs to make some changes to the installer too
<Kamion> mdz: the ones that can't download security updates are the ones who don't have an internet connection, so that's not such a big deal
<Kamion> mdz: I think his rationale for updating the CD with security updates is just that he might as well, it's a nice-to-have
<mdz> in that case, I don't see the point of bothering with security updates at all
<mdz> ok
<Kamion> I can certainly see the rationale; if you're going to build a CD now, it might as well be current
<pitti> mdz: oh, have a happy holiday! :-)
<mdz> thanks
<pitti> mdz: thanksgiving is another opportunity to stuff one's stomach with far too much food, right?
<mdz> correct
<pitti> mdz: enjoy :-))
<fabbione> hehehe
<elmo> # list of distributions that buildd should take packages from
<elmo> @take_from_dists = qw(stable frozen unstable);
<elmo> *boggle*
<Kamion> hooray for buildd
<daniels> elmo: looks like someone installed a new w-b, heh
<Kamion> yeesh, pciutils still has no DH_COMPAT or debian/compat? bleh
<daniels> elmo: do you have access to the ia64 thingies?
<elmo> daniels: blink - of course?
<daniels> elmo: do you care to spin a build around them, or should I harass lamont when he wakes?
<elmo> harass lamont to get debootstrap working, then I can create a hoary chroot on the port box
<daniels> elmo: k, cheers
<daniels> lamont: harass, harass, p.u.c/~daniels/xorg, etc
<elmo> pitti: ok, should be fixed now
<pitti> elmo: thanks
<elmo> (or at least the powerpc buildds will start building things now)
<pitti> elmo: it will automatically arrive at rookery now?
<pitti> elmo: or must there be a trigger of some kind?
<mdz> night, all
<pitti> night mdz 
<seb128> 'night mdz 
<Kamion> sleep well
<elmo> pitti: err, jackass you mean? yes
<daniels> mdz: night
<pitti> elmo: yes, of course. jackass
<Mithrandir> why doesn't nautilus allow one to open a folder multiple times on multiple desktops?
<seb128> bug ?
<jdub> Mithrandir: you can in browse mode; spatial is spatial.
<seb128> oh, doesn't
<seb128> I misread
<jdub> Mithrandir: the window *is* the folder.
<Mithrandir> jdub: but the window is on another desktop.
<Mithrandir> jdub: it means I have to race xpdf to make it open on the right desktop.
<seb128> ?
<seb128> what are you trying to open/start, and how ?
<jdub> Mithrandir: you're saying that the window is open, and you try to open it again, but it does nothing (because it's already open on the other desktop)?
<Mithrandir> jdub: no, it moves me to the other desktop.
<Mithrandir> which is totally surprising.
<seb128> it should move the window on the current one
<Mithrandir> seb128: agreed.
<seb128> it does here
<Mithrandir> not here, but I'm using openbox.
<seb128> oh, so probably an openbox bug
<jdub> it does here too
<pitti> elmo: $ ps aux|grep ntpd
<pitti> ntp       2052  0.0  0.4  3516 3516 ?        SLs  12:16   0:00 ./ntpd
<pitti> elmo: :-)
<elmo> pitti: sweet thanks
<gicmo> hi
<pitti> elmo: well, it needs some tweaks (to work also on non-cap kernels and such), but it works in principle
<daniels> elmo: so is davis fully set up to be abused?
<elmo> pitti: next I need you to fix... ssh, cron, klogd, sylogd, postfix and getty.. kthxbye
<elmo> ;-)
<elmo> daniels: AFAIK, yeah
<pitti> elmo: ssh? easy, it just could lack a _little_ functionality...
* pitti grins
<Kamion> *ahem*
<pitti> elmo: btw, syslogd?
<pitti> elmo: I fixed that yesterday
<elmo> pitti: both syslogd and klogd?
<pitti> elmo: no, it's impossible for klogd
<pitti> elmo: klogd needs CAP_SYS_ADMIN, which is equivalent to root
<pitti> elmo: the odd thing is, you cannot open /proc/kmsg as root and read from the descriptor as user
<pitti> elmo: this works for normal files, but not for /proc/kmsg
<pitti> elmo: with the current kernel there's nothing I can do
<elmo> oh well.. nice for syslogd anyways
<elmo> s/for/to get/
<daniels> elmo: cool
<Kamion> -rw-rw-r--    1 cjwatson cdimage  636405760 Nov 24 08:49 20041124/hoary-install-powerpc.iso
<Kamion> -rw-rw-r--    1 cjwatson cdimage  625797120 Nov 25 08:49 20041125/hoary-install-powerpc.iso
<Kamion> \o/
<daniels> Kamion: congrats :)
<daniels> Kamion: how did you shave that much off?
<Kamion> mozilla-browser
<daniels> ahr
<daniels> elmo: btw, would it be possible to get access to an ia64 port box once lamont makes chroots work and stuff?
<elmo> sure
<elmo> I just need working debootstrap
<Kamion> yeah, waiting on gcc-3.4
<daniels> elmo: awesome, thanks
<elmo> oh, ok, thought Lamont had bodged that
<Kamion> think it's the last thing left to do
<elmo> and why on earth do.. oh libgcc
<Kamion> at least, it was last time I heard
<Kamion> elmo: yeah
<Kamion> I'm kind of refusing to do debootstrap until I can do it automatically from germinate output :-/
<Kamion> lamont has a hacked script though I believe, if you want to ask him for it
<elmo> no, that's fair enough
<Kamion> anyone object to me adding pciutils-udeb to the installer seed?
<daniels> Kamion: seems eminently sensible
<elmo> daniels: btw, don't forget to add that fd candy to the appopriate seed
<elmo> seb128: you too for gnome-python-extras
<elmo> doko: and you too for zope
<seb128> ok
<daniels> elmo: good catch
<Keybuk> jdub: btw. I've mailed the hotplug-ng and udevsend/udevd guys to see what they think the future should be
<jdub> elmo, daniels: do we actually want the fd candy in any of the seeds?
<jdub> Keybuk: rad
<daniels> jdub: i put fdclock/xcompmgr/transset in supported
<daniels> jdub: fdclock might be sorta kinda neat, but the compmgr is really just too slow
<jdub> daniels: i don't think there's any reason to support them
<Keybuk> jdub: I also sent them grepmap as a "here's the C modules.*map parser for you" :)
<daniels> jdub: oh?
<daniels> jdub: i think enough people will want to use them to support them
<daniels> jdub: but not enough, and it's not general-purpose enough, to ship them per default
<daniels> jdub: but, your call
<elmo> yes, sorry, please remember when I say "add to the appropriate seed" there's a hidden subtext of "and get sign off for it, if you need to" :-P
<jdub> yeah, these things should be added to the seed proposals page
<jdub> daniels: they're not useful to support though, surely they're fine for universe
<daniels> jdub: done
<jdub> daniels: please put them on the proposals page though, we may come back to it
<daniels> jdub: k
<jdub> anyone mind if i patch out the openoffice.org kde stuff, so we can get a build?
* jdub hasn't got pong from doko
<daniels> oh frig, this means I need to edit the wiki
<elmo> god I would KILL for sysklogd to use fricking logrotate
<jdub> far out
<jdub> 171MB
<rburton> daniels: i hear you are off to see mallum on monday
<daniels> rburton: i hear you are too!
<rburton> daniels: indeed. want to meet at victoria?
<daniels> rburton: rockin'
<daniels> rburton: easy to get to from south ken?
<rburton> yeah, along on the circle for a bit
<rburton> or the district. yellow or green.
<daniels> swoit
<daniels> ahr, right
<daniels> yeah
<daniels> which means it's easy from earl's court also -- phat
<rburton> daniels: what time were you planning on going?
<daniels> rburton: *shrug*, whenever
<haggai> jdub: sure.  I was thinking we're gonna have problems sometime with OOo needing GTK and KDE libs to build
<daniels> haggai: availability isn't a huge problem, it's just that that would drag kde into main
<haggai> jdub: I want to split some of the -dev sort of headers out and make an installable .deb from them but like everything with OOo it takes ages & ages to do
<haggai> daniels: but that would suit KDE users ;)
<Kamion> we could imaginably end up stripping out the KDE build-dep for Ubuntu; it wouldn't be the first package we've done that for ...
<jdub> yeah, that's the main issue
<fabbione> elmo: (wishlist) any eta for sparc.u.c =
<Kamion> life will be easier once we have community maintenance for KDE
<jdub> atm we can't build it because kdelibs4-dev isn't in universe
<fabbione> s/=/?
<jdub> Kamion: but that doesn't necessarily mean kde in main :)
<haggai> is there any way we can tell if we're building for Ubuntu?  We have a lot of optional stuff in the pkgs controlled by DEB_BUILD_OPTIONS and it would be handy if we could do the same with the KDE bits too
<_rene_> yeah, good idea
<Kamion> haggai: nope, we just upload a *ubuntuN version
<daniels> Kamion: is it worth setting a default DEB_BUILD_OPTIONS="ubuntu"?
<Kamion> although having our changes integrated that way could make life easier
<Kamion> daniels: users rebuilding our source packages won't set that
<haggai> daniels: yeah, might be a good idea
<daniels> Kamion: like, within dpkg-buildpackage, or /etc/environment, or something
<elmo> fabbione: I'm trying to ping sabdfl about sparc boxes - I'd really like to know if we're going to do that first
<Kamion> that's always the problem with DEB_BUILD_OPTIONS and similar; they can only be used for optional features, not what the buildd needs
<Kamion> daniels: EWWW
<daniels> Kamion: (sorry)
<Kamion> daniels: (what if somebody wants to build the Debian source package on Ubuntu?)
<daniels> Kamion: (good question)
<jdub> (stop whispering)
<Kamion> source packages pretty much have to be self-contained, unfortunately
<daniels> Kamion: (of course, dpkg-buildpackage could only set D_B_O if the source version contained 'ubuntu' ...)
<haggai> so what about adding some sort of DEB_BUILD_OPTIONS+=ubuntu in debian/rules?
<haggai> (as an ubuntu-only patch)
<Kamion> haggai: if our diff were just that one line, that'd rock
<haggai> Kamion: that's my idea
<rburton> daniels: meet at victoria train station, around platforms 1-8, about 11:30-40? there is a train at 11:53
<daniels> Kamion: to every package?
<daniels> rburton: sounds awesome
<Kamion> not sure DEB_BUILD_OPTIONS is *quite* the right place, but anyway
<jdub> haggai: what would the kde package have in it, if we did that?
<_rene_> jdub: we could just disable it
<Kamion> I think I'd prefer DEB_DISTRIBUTION or something
<haggai> the advantage of DEB_BUILD_OPTIONS+= means you can build the ubuntu variant on Debian.. :)
<_rene_> jdub: -Nopenoffice.org-kde etc
<rburton> daniels: sweet. mail me your mobile so i can find you when you are lost ;)
<daniels> rburton: heh :)
<Kamion> yeah, just trying to avoid overloading DEB_BUILD_OPTIONS itself
<fabbione> elmo: didn't we agree that i was going to offer "main" in an unofficial archive and that if the port will take off, we were going to buy buildd?
<_rene_> jdub: so we could make -lde not even built
<daniels> rburton: sent
<Kamion> _rene_: or generate the control file
<elmo> oh, maybe we did. blah, my brain sucks
<Kamion> so that -kde isn't in the .dsc either
<fabbione> elmo: because i am already building the "golden debs" for main at this stage...
<jdub> _rene_: ahr :)
<jdub> _rene_: handy
<fabbione> elmo: and when they will finish i can add universe & co.
<_rene_> jdub: we actually do that now like this with the java/nonjava flag
<daniels> thom: kaping
<haggai> Kamion: we actually generate the control file anyway so yeah we could take it out but I think just using -Nopenoffice.org-kde, like we do for the optional -java pkg, should be enough
<elmo> fabbione: okay, I'll try and have a look at doing s.u.c in the next couple of days - it has to be below a few other things in my todo list tho
<fabbione> elmo: sure... that will be more than perfect
<_rene_> hmm. that still leaves the builddep, though ;-)
<fabbione> elmo: when you will be ready to test the setup i will send you the gpg key for the buildd
<fabbione> elmo: if you don't mind i want to keep them separate
<haggai> _rene_: oh, yeah good point
<haggai> _rene_: we can always do our trick of depending on something in the distro :)
<haggai> _rene_: like the woody bp
<elmo> fabbione: of course - tho, if we go ahead with the port, I think one of the things we do when we get our buildds, is rebuild the world on them ?
<_rene_> ah, yeah
<haggai> Build-depends: kdelibs | ubuntu-somthing
<rburton> daniels: where did you send the mail? it's not here yet
<_rene_> kdelibs4-dev | some-ubuntu-stuff
<daniels> rburton: rburton@d.o?
<jdub> haggai: oof. :)
<rburton> daniels: ross@
<daniels> ... which just bounced, rock on
<_rene_> jdub: works, we did that already with woody and dpkg-dev ;-)
<haggai> jdub: you haven't seen all our hacky^W neat stuff for our woody backport from the same OOo source? :)
<fabbione> elmo: we can still use my "golden debs" to start with
<jdub> haggai: i saw the 171MB download and turned back :)
<daniels> rburton: try that
<fabbione> elmo: there is no point in starting from scratch again
<_rene_> jdub: heh
<fabbione> elmo: i can already bootstrap ubuntu sparc chroots
<haggai> jdub: ok, you failed the real h4ck3r test then
<jdub> heh
<fabbione> elmo: and with a bit of love we might be able to install ubuntu on them directly ;)
<jdub> .au has lots of real hackers :)
<jdub> we just don't ahve a lot of real bandwidth :)
<fabbione> jdub: s/real/fake/
<fabbione> ;)
<daniels> we don't have much fake bandwidth, either
<fabbione> daniels: well it was for the hackers
<fabbione> daniels: mtools is another FTBFS from xlibs split :( i uploaded the fix.. mind to keep an eye on it?
<daniels> fabbione: sure
<fabbione> daniels: where is xorg crack? :P
<daniels> fabbione: concordia has finished (like 20min ago), davis has just started -dbg, and catsby (my laptop) is meandering through
<fabbione> davis ?
<fabbione> ia64?
<elmo> davis is adare
<daniels> nope, new powerpc port box
<elmo> er
<fabbione> ah ok
<daniels> adare's motd told me to use davis for chroot builds, so I did
<elmo> davis is powerpc, it replaces adare
<elmo> halley is the ia64 port box, but it doesn't have a hoary chroot yet
<Kamion> haggai: something in the distro> that's really sick and twisted ;)
<fabbione> ok
<fabbione> thanks
<_rene_> Kamion: you haven't seen the foo | dpkg-dev (<< something) builddeps, have you? ;-)
<lupus_> libgnome2-common_2.8.0-5ubuntu1_all.deb the 5=debian release? and the 1=ubuntu release? or how does the versioning system work?
<jdub> night all
<bob2> 'night jdub 
<daniels> jdub: 'nacht
<daniels> _rene_: oh man, that's hideous
<_rene_> daniels: hackish, but works
<Kamion> _rene_: I think I noticed them once and RAN AWAY SCREAMING
<Kamion> lupus_: first Ubuntu revision on top of 2.8.0-5
* fabbione sighs
<_rene_> Kamion: :)
<fabbione> Kamion: we need to do a really hackish thing to merge the udeb creation :(
<Kamion> fabbione: oh?
<fabbione> Kamion: because the install target doesn't actually install in debian/<pkgname> (that i was hoping for)
<daniels> fabbione: what's mtools doing with libxau?!?
<fabbione> Kamion: and later binary-arch calls make-kpkg to create the debs, that are than moved to the right place
<Kamion> fabbione: which install target?
<fabbione> daniels: you ask me?
<fabbione> Kamion: then one in the top level debian/rules
<fabbione> daniels: it FTBFS without
<Kamion> fabbione: oh, you clearly have to run kernel-wedge after most of binary-arch is finished
<daniels> fabbione: oh man
<fabbione> Kamion: yep
<fabbione> daniels:
<fabbione> floppyd.c:28:23: X11/Xauth.h: No such file or directory
<fabbione> floppyd.c: In function `do_auth':
* Kamion tries to find a solution to his network device detection problem that doesn't involve diverting modprobe
<seb128> herzi: your testcase doesn't work and I think than bastien doesn't want to debug it 
<herzi> well, it works on my machines, maybe it's locale-dependent?
<seb128> $ ./compile.sh
<seb128> gcc: -E required when input is from standard input
<seb128> here
<seb128> BTW don't bother to fix it, I've added a tarball to the BR
<herzi> i saw that
<herzi> it's good for non-english people to have this fixed
<seb128> yeah
<seb128> elmo: eog sync please
<elmo> seb128: done
<seb128> thanks
<fabbione> Kamion: regarding the kernel-versions file
<fabbione> Kamion: the last entry is the build-dep field, that we don't need anymore, since we build everything from the same source
<fabbione> Kamion: problem is: if i leave a build-dep in there it finishes into debian/control
<fabbione> Kamion: if i remove it kernel-wedge install-files will fail a sanity check
<fabbione> Kamion: and i have 2 options to fix it:
<fabbione> Kamion: a) patch kernel-wedge to be less anal in that sanity check
<daniels> fabbione: if you want to give ubuntu4 a test run around sparc (p.u.c/~daniels/xorg), that would be cool
<fabbione> Kamion: b) insert a fake build-dep in kernel-versions
<fabbione> Kamion: fake as in writing for ex. tar
<fabbione> Kamion: or something like that
<fabbione> daniels: it would take hours to build and don't worry about sparc until there is a need for it :-)
<fabbione> Kamion: what would you prefer?
<fabbione> Kamion: the change in kernel-wedge would be limited to commands/install-files
<fabbione> Kamion: the var is not even used.. just checked for len > 0
<daniels> fabbione: heh, ok
<daniels> fabbione: waiting on lamont for an ia64 test build anyway
<Kamion> fabbione: uh, wait a sec, I want to look at this carefully
<fabbione> Kamion: sure
<Kamion> fabbione: we must not break kernel-wedge in such a way that you can't build Debian's installer on Ubuntu any more
<fabbione> Kamion: removing the sanity check shouldn't break
<Kamion> yeah, but it sucks
<fabbione> otherwise we need to patch gen-control
<fabbione> or create a gen-control-ubuntu
<Kamion> noooo
<Kamion> this is why I said "wait a sec"
<fabbione> eheh
<Kamion> let's not do random things just to hack it into working; this should be done properly
<fabbione> i agree.. that's why i am discussing it with you :-)
<Kamion> ok
<Kamion> I don't see this sanity check?
<fabbione>             ! length $builddep ) {
<fabbione> in commands/install-files
<Kamion> ah
<Kamion> why not just not call gen-control?
<Kamion> oh, no, you need it
<fabbione> Kamion: because we need the control? ;)
<fabbione> kernel-wedge is correct assuming that there must be a build-dep
<fabbione> it's our merge that goes against it
<Kamion> hmmm
<fabbione> actually...
<fabbione> i think the best approach would be to change gen-control
<Kamion> I don't think I'd object to changing install-files, actually
<Kamion> that seems the most compatible approach
<fabbione> or create an ubuntu copy of it
<Kamion> no
<Kamion> no copies
<fabbione> hmm why not?
<fabbione> it would make merge very simple
<Kamion> have you heard the term "clone-and-hack"?
<fabbione> hmmm no
<Kamion> if we copy, we do not get the benefit of bug fixes
<Kamion> it's not a complimentary term
<fabbione> Kamion: let me see one thing
<Kamion> what gen-control change were you thinking of?
<fabbione> Kamion: well on our system should not add the entry in the Build-Dep field
<fabbione> Kamion: otherwise you will get a source that build-dep on itseld
<fabbione> itself binaries
<Kamion> I don't like that, I'd much rather remove the check from install-files
<Kamion> that seems fairly harmless, looking at it
<fabbione> Kamion: otherwise how would you feel in NOT touching the code at all
<Kamion> especially since gen-control does not perform that sanity check
<fabbione> and just add a fake build-dep ?
<Kamion> nah, let's remove the check, that's better
<fabbione> ok.. do you want to do it, or should i?
<Kamion> no point adding fake cruft to lots of kernel-versions files
<fabbione> hmm no
<fabbione> it's only on one line
<Kamion> I've got the change here, will upload
<fabbione> the Build-Dep 
<fabbione> ok thanks
<Kamion> per-arch, remember
<fabbione> not in this case
<fabbione> it will add it to linux-source
<fabbione> but ok...
<fabbione> the change to the code is ok with me :-)
<Kamion> um, you still have multiple kernel-versions files surely?
<Kamion> I mean, you have to
<fabbione> yes, but the gen-control changes only the Build-Dep to add the ones listed in kernel-versions
<fabbione> anyway it's ok the change to the code :-)
<Kamion> right, but if you were adding a fake build-dep you'd have to do that on every kernel-versions line; that's where the check was being applied
<fabbione> oh yes
<fabbione> i misunderstood you before :-)
<Kamion> I'll talk to joeyh next time I remember, see if this can go upstream
<fabbione> good idea
<Kamion> uploaded, thanks
<fabbione> thanks to you :-)
<fabbione> i think i can give you the first -17 -> -18 interdiff tomorrow to create debs...
<fabbione> tho there is still the versioning problem that i need evaluate
<fabbione> if we are going to create newer or older udebs
<Kamion> cooooooool
<Kamion> udebs don't have an upgrade problem technically, but katie may hate you
<fabbione> Kamion: i am taking my time to be as less intrusive as possible
<fabbione> even if i don't fully understand the reason of this merge :-)))
<Kamion> wouldn't it be a much newer version by default?
<fabbione> imho it will make user's life more complicate with a bunch of extra kernel updates, only to change udebs
<fabbione> Kamion: i didn't check.. i just had the flash while talking with you 3 seconds ago
<Kamion> it's basically so that a kernel upgrade doesn't involve "build linux-source-2.6.8.1, wait, get Kamion to build linux-kernel-di-* so that the changes propagate to the installer"
<fabbione> Kamion: yes.. i grok that :-)
<Kamion> which can be important when we're doing stuff in a hurry, and mdz wants it for security uploads
<fabbione> but on the other side
<fabbione> "hey another kernel upgrade to fix the usb udev" ;)
<Kamion> yep; I kind of regard that as "unlucky for running a development release"
<Kamion> it'll be easier once our kernel package is in arch
<fabbione> oh yeah...
<fabbione> ehhehe
<Kamion> then I can commit as I do stuff rather than uploading for every change
<fabbione> linux-source-2.6.8.1-2.6.8.1$ kernel-wedge install-files
<fabbione>         kernel-wedge copy-modules 2.6.8.1-3 386 2.6.8.1-3-386
<fabbione>         kernel-wedge copy-firmware 2.6.8.1-3 386 2.6.8.1-3-386
<fabbione>         kernel-wedge find-dups 2.6.8.1-3-386
<fabbione> fabbione@gordian:/usr/src/wartydevel/kernel/linux-source-2.6.8.1-2.6.8.1$ 
<fabbione> sweet :-)
<Kamion> bonus :)
<fabbione> let see what it did :-)
<fabbione> impressing
<fabbione> it's working :-)
<fabbione> Kamion: probably later this evening...
<fabbione> i was expecting more problems
<Kamion> nifty, nice work
<fabbione> xfs-modules-2.6.8.1-3-386-di_2.6.8.1-18_i386.udeb
<fabbione> it almost work :-)
<Kamion> that looks ok ...
<fabbione> Kamion: yes.. all the udebs are ok...
<fabbione> the debs aren't
<fabbione> but it should be easy to do it nice and clean
<zul> gday
<pitti> die, evil ntp root privileges, die!
<tseng> mmm, openntpd
<tseng> privelage seperation + no listening by default
<pitti> tseng: I just uploaded a new ntp package which lets ntpd run as normal user
<tseng> mm, nice.
<elmo> by day, pitti is just another programmer - but by night he turns into the DEROOTER - a shadowy figure fighting the wars others fear to wage, rooting out (har har) evildoers who retain priviledges they don't deserve
* pitti hides the "slash root" axe
<pitti> tseng: the funny thing is that it took me about half an hour to fix the code, and about one and a half to fix the broken init script handling
<tseng> ew
<smurfix> pitti: *sigh* yet more work for me.
<tseng> so it now starts as root and drops?
<fabbione> lol
<pitti> smurfix: why, are you the Debian NTP team?
<pitti> tseng: yes, it drops to ntp:ntp and only keeps CAP_SYS_TIME
<smurfix> not quite "the", bu close.
<fabbione> pitti: yes he is
<tseng> great.
<fabbione> smurfix: btw.. that mail about evdev
<pitti> tseng: the code already kind of supported that, it just needed some tweaking
<fabbione> smurfix: please discuss it either in ubuntu-devel or debian-x
<pitti> tseng: the hard part was to get a smooth transition on package upgrading
<fabbione> smurfix: i don't maintain X in ubuntu anymore :-D
<smurfix> fabbione: OK
<fabbione> smurfix: can't you see the difference yet?
<fabbione> no caps lock..
<fabbione> no irritation to my skin
<sivang> fabbione : who is ?
<sivang> :)
<fabbione> i don't wake up yelling at the elfloader
<fabbione> sivang: daniel the kid
<smurfix> fabbione: the relevant changhelog entry was yours, though, so I thought maybe you'd feel responsible. ;-)
<fabbione> smurfix: i did only one change to make it more flexible for certain corner cases
<fabbione> smurfix: not as default protocol
<fabbione> but you can discuss it
<fabbione> with enough arguments you can convince daniels
* smurfix needs to fix dasher so nobody needs to see more of his broken one-handed typing
<pitti> smurfix: I sent the patch as a wishlist bug. Have fun with it :-)
<smurfix> pitti: thanks. I guess. ;-)
<Kamion> smurfix: one-handed typing> I don't want to know
<smurfix> Kamion: read my blog... (or not)
* daniels returns from spasming on the ground at the mention of 'elfloader'.
<daniels> smurfix: so!  evdev as default, eh?  sell me.
<smurfix> daniels: (a) I like the ability to actually use the multiple buttons on mine.
<daniels> smurfix: er, most people have working multi-button mice without evdev (by 'most people', I mean 'everyone not running Apple hardware')
<smurfix> multi := >3
<Kamion> smurfix: ouch :(
<smurfix> my lowly Explorer has five and I didn't even have to configure $BROWSER to use the additional ones as back+forward
<smurfix> Kamion: my thoughts exactly.
<smurfix> Kamion: I thought you didn't want to know :-/
<daniels> smurfix: so change to ExplorerPS/2
<fabbione> daniels: evdev seems to autodetect that
<fabbione> [debian-ntp]  Bug#282941: ntp-server: Please run ntpd as non-root
<smurfix> daniels: why ask the poor user what mouse protocol he should use on his USB bus?
<fabbione> tsk :-)
<daniels> smurfix: yeah, I dunno whether it's safe for standard ImPS/2 or not; if it is, I'll make it the default
<daniels> smurfix: unfortunately all I have here is my laptop, but if you want to do some research, it would be hugely appreciated (feel free to open a bug in Bugzilla, assigned to daniel.stone@canonical.com, status NEEDINFO)
<daniels> smurfix: and yeah, I agree that asking a question like that is tremendously shit
<smurfix> daniels: OK, will do.
<daniels> cheers
<smurfix> daniels: #4106
<daniels> smurfix: thanks
<fabbione> Kamion: testing a full build now :-)
<fabbione> ccache orgy :-)
<daniels> http://gstreamer.freedesktop.org/releases/gst-plugins/0.8.6.html <- polypaudio support
<seb128> they have finally release 0.8.6 ?
<daniels> yahuh
<daniels> to be fair, they were blocked for about four or five days on fd.o
<lifeless> rock
<elmo> have polypaudio's problems been resolved?
<daniels> elmo: not sure, but I would assume lack of a GStreamer sink would be one of them ...
<daniels> fabbione: eh papa
<fabbione> daniels: yes kid?
<daniels> fabbione: wanna test the new nvidia packages?
<daniels> fabbione: actually, wait until I merge the AGP patch -- nevermind
<azeem> daniels: polypaudio can be transparently used as esound sink, no?
<fabbione> daniels: not right now.. i am building a kernel package
<azeem> now, a GStreamer source is something different, but AFAIK polypaudio handles that somehow as well
<fabbione> UltraSPARC IV <- this is not supported by linux
<fabbione> ops
<daniels> azeem: unsure
<daniels> fabbione: k
<lamont> daniels: that died quickly yesterday...
<fabbione> hey lamont 
<lamont> (xort that is)
<fabbione> lamont: the chroots that are building hoary/main are broken
<fabbione> lamont: they manage to build gdb that build-dep on type-handling
<fabbione> that is in universe
<fabbione> lamont: btw.. good morning :-p
<lamont> fabbione: is this a new gdb upload?
<elmo> drow used type-handling?!
<fabbione> lamont: it's a sync from debian
<fabbione> E: Couldn't find package type-handling
<elmo> dear god, what is the world coming to
<daniels> lamont: yeah, there's a new one up there today
<daniels> lamont: i told you you had to delete 000_stolen_from_fedora.diff :)
<lamont> fabbione: gdb 6.3-4 predates the fix
<lamont> daniels: missed that.  I can just regrab?
<daniels> elmo: what does type-handling even do?
<daniels> lamont: yah, same source version, lasted through clean builds on i386/powerpc/amd64
<daniels> (in reverse order of speed to compltee)
<fabbione> lamont: ok
<fabbione> lamont: thanks for checking
<lamont> daniels: build running
<daniels> lamont: thanks dude
<lamont> fabbione: there was a bug in the ogre-model implementation.  damn perl.
<lamont> (fixed 23 nov)
<fabbione> lamont: ogre-model?
* fabbione scratches his head
<Kamion> fabbione: seen Shrek?
<fabbione> yes
<Kamion> onions
<fabbione> but i have seen it in italians
<fabbione> ah ok
<fabbione> so ogre-models is like onions and orks.. they have layers :P
<lamont> fabbione: that, and it's smelly
<fabbione> ehhe
<daniels> elmo: could I please get linux-restricted-modules build-deps on concordia?
<elmo> daniels: done
<daniels> elmo: cheers
<daniels> shitting hell, the l-r-m build goes into an infinite loop if it fails
<thom>  "From: psychoelmo <psychoelmo@gmail.com>" *giggle*
<thom> elmo: is that your pseudonym these days?
<daniels> heh
<lamont> Applying patch
<lamont> +debian/patches/024_ati_r128_and_radeon_enable_build_without_vgahw.diff ...
<lamont> +failed! (check
<lamont> +stampdir/log/patches/024_ati_r128_and_radeon_enable_build_without_vgahw.diff
<lamont> +for reason)
<fabbione> why am i not surprised?
<fabbione> daniels: let me guess
<zul> its ati...go figure
<fabbione> you renamed 020 to 025
<fabbione> and not done a patch-audit
<daniels> fabbione: dude, ease off it, will you?
<fabbione> daniels: tell me if i am right or not..
<fabbione> ;)
<lamont> 8 out of 12 hunks FAILED -- saving rejects to file xc/programs/Xserver/hw/xfree8
<lamont> 6/drivers/ati/radeon_driver.c.rej
* daniels boggles.
<lamont> elmo: elilo-installer/ia64 needs some unknown-love.
<daniels> that's exactly what I copied to concordia and davis
<daniels> fabbione: actually, you're wrong
<fabbione> daniels: good :-)
<fabbione> daniels: if what you have around is the same as what is in baz, here they all apply ok
<daniels> fabbione: yeah, that one had to be updated because benh's patch lets you configure vgahw or not at runtime also
<daniels> fabbione: so presumably after I did it, I copied to concordia and davis, but not rookery
<fabbione> daniels: can you give the changelog some love before uploading please?
<eruin> what's herbert xu's nick?
<daniels> eruin: he doesn't IRC
<thom> he doesn't use irc afaik
<fabbione> eruin: afaik he doesn't irc
<daniels> fabbione: it's not final, more stuff will change before then
<eruin> crap, and I wanted to whine about nvidia6629 ;)
<daniels> apparently 6629 is known broken
<daniels> (says the man who doesn't own any nvidia hardware)
<eruin> hmm, gotta google that.. they work fine here
<fabbione> eruin: the problem seems to affect certain AGP busses
<daniels> eruin: there's a patch on some forums somewhere supplied by an nvidia dude that I'm testing
<fabbione> in specific conditions
<fabbione> eruin: that makes it no no for us
<daniels> 'testing' -> 'beating at until the package builds with it, then releasing to suck^Wtesters'
<eruin> :D
<lamont> hrm.. thumb cuffs for $6.99...
<eruin> owell, as long as I have these alienified ooo1.9 debs installed 'm happy
<_rene_> erm, you don't need to installl alienated debs when there are "normal" debs...
<eruin> of 1.9?
<_rene_> yes
<eruin> and where might those be?
<daniels> lamont: ...
<_rene_> eruin: read debian-openoffice
* lamont adds the 26" retractable steel baton to his "when I can write it off" list.
<lamont> it's a fun catalog, you see..
<_rene_> eruin: http://lists.debian.org/debian-openoffice/2004/11/msg00216.html
<shaya> how is one supposed to use smbmount if it cant be suid root?
<shaya> used to always just smbmount as a regular user
<eruin> _rene_: ah, yeah, I'm using those.. synaptic dupes them "alienated"
<_rene_> ah. probably because you installed them with dpkg -i etc
<eruin> what's the diff between java and nonjava?
<haggai> eruin: the nonjava is a build without java support
<_rene_> the java one ist built with java support, the other one is without ;-)
<eruin> okay, I was foolishly thinking gtk
<rburton> has oo.o 1.9 got anything really cool?
<eruin> somehow the ooo1.9 I have on my fedora partition blend in with the rest of my gnome desktop, whereas these don't
<eruin> well, .oot support
<eruin> :)
<rburton> .oot?
<_rene_> the new file format :)
<eruin> the new default format
<rburton> ah
<haggai> eruin: that's because I didn't enable the gtk or kde plugins yet
<tseng> 1.1.3 is being built for hoary now
<tseng> which has some of the visual improvements
<eruin> all my old docs from my windows days are in .oot, that's why I need it :)
<eruin> tseng: no oot support I suppose?
<_rene_> err? this must be a different oot?
<tseng> not afaik
<haggai> what is oot?
<_rene_> the new OASIS format
* tseng points up
<haggai> ah, yeah
<eruin> _rene_: nah, I used an ooo1.9 release there too
<_rene_> ah
<_rene_> ok
<haggai> eruin: oot format is scheduled for 1.1.5 I believe
<azeem> "old docs from my windows days" <- IT landscape is moving fast these days, huh?
<_rene_> tseng: there are rumours 1.1.5 will have backported support for OASIS
* haggai senses an echo
<eruin> what does ooo use anyway? for the interface I mean
<tseng> it has its own toolkit
<_rene_> an own toolkit
<tseng> its just being modified recently to emulate native toolkits
<eruin> yeah, .56 milestone seemed to do that, while the one I'm running, .62 looks butt-ugly ;)
<_rene_> you have to enable it during configure
<_rene_> and the resulting stuff then of course is linked against gtk and kde/qt...
<eruin> damn me for using those debs then
<_rene_> tose debs in  no way have the usual quality. they are just made from a stock upstream build ;)
<eruin> time to lobby the maintainer ;>
<_rene_> erm? you are talking with them atm...
<eruin> eek
<eruin> you do the ones at ~halls/ ?
<_rene_> haggai does
<eruin> oooh haggaaii?
* shaya hacks samba so smbmount works again for regular users
<shaya> cant let security get in my way
<haggai> eruin: as I said in the mail, it was a first cut and there's lots to improve on
<haggai> eruin: I was just happy to have any .debs at all.. and many people asked for them so I put them up as they were
* lamont wanders off for a bit
<haggai> eruin: I'll turn on the gtk & kde interfaces for my next build, ok?
<shaya> haggai: debs of what?
<eruin> haggai: that'd be great! :)
<haggai> shaya: openoffice 1.9.62
<shaya> open office
<shaya> aren't there gtk/kde interfaces in debian already?
<eruin> for 1.1
<haggai> shaya: we're talking about 1.9.x
<_rene_> shaya: if you count experimental.. ;)
<daniels> pitti: ah, dude!  want to test out a new radeon_drv?
<daniels> thom: what sort of machine is your radeon in?
<pitti> daniels: sure
<thom> daniels: amd64
<pitti> daniels: can you please mail it to me?
<daniels> pitti: jah
<pitti> daniels: I'm in a hurry, gotta go soon
<daniels> pitti: sure thing
<daniels> thom: dvi, yeah?  did it Just Work beforehand?
<pitti> daniels: fixed the vga out?
<daniels> pitti: hopefully!
<daniels> thom: if you wouldn't mind giving http://people.ubuntu.com/~daniels/xorg/amd64-radeon_drv.o a spin, that'd be rad
<tseng> daniels: whats different about it?
<tseng> daniels: ill give it a try.
<tseng> oh sorry.. missed the 64.
<daniels> tseng: lots of fixups from benh
<daniels> tseng: http://people.ubuntu.com/~daniels/xorg/i386-radeon_drv.o
<daniels> basically, with a bare-bones (i.e. no special options) config file, every single configuration should be detected
<shaya> daniels: what's in there?
<tseng> mm, nice.
<daniels> shaya: basically, you shouldn't ever need to specify any wacky options
<daniels> every display you have connected should just come up and work
<shaya> daniels: faster/slower or just options?
<tseng> ill test on laptop w/ crt
<daniels> shaya: just options, no optimisations iirc
<tseng> and no layout options
<shaya> oh well
<daniels> http://people.ubuntu.com/~daniels/xorg/xorg_6.8.1-1ubuntu4_source.changes <- changelog
* thom plugs in second monitor and tries 
<daniels> it's the 'break benh's radeon_drv challenge'
<thom> brb, hopefully
<tseng> daniels: works for me
<tseng> w/o monitor_layout
<daniels> tseng: :D
<tseng> before it would mess up the top edge of the screen on the CRT
<daniels> rooooooockin
<tseng> unrelated X question
<tseng> when i do something with direct rendering, like playing a dvd
<tseng> it doesnt show up on the crt
<tseng> can i config-fu something?
<daniels> right, you need to set the overlay to the other crtc
<daniels> hold on a sec
<daniels> try Option "MergedFB"
<tseng> i tried that once and got crap
<daniels> is it any better now? ;)
<tseng> funny rainbow colors and no X
* tseng tries
<daniels> heh
<smurfix> daniels: I'll try the thing too, I need to reboot anyway
<tseng> Option "MergedFB"   "true"
<tseng> no hung X, but no video on crt either
<daniels> so you just get a colourkey, or blank?
<tseng> black square in totem
<thom> daniels: close, but no cigar
<daniels> thom: oh?
<daniels> tseng: hm
<thom> oh, hrm
<fabbione> Kamion. IT WORKS ! IT WORKS!.. at least.. it builds fine...
<thom> maybe i should specify some options for the second head
* fabbione prepares a patch for Kamion to test on ppc
<thom> like res and xinerama?
<daniels> tseng: i suspect the only way you'll get it is with Xinerama + MergedFB, and moving the video on the second head
<daniels> tseng: of course, we could write a tiny utility to just set OV0_CRTC_SEL
<tseng> hm
<daniels> thom: probably, if they're different resolutions
<daniels> thom: if you select a res which both heads are capable of, it should work tho
<daniels> thom: mergedfb may be a plus here
<Kamion> fabbione: hooray
<fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/linux-source-2.6.8.1_2.6.8.1-18_i386.changes
<fabbione> i just need to add one entry in the changelog
<fabbione> and you to test on ppc
<Kamion> guess I can kiss goodbye to my CPU time for a time
<Kamion> a bit
<fabbione> i386 is easy because it has only one kernel image used for d-i
<fabbione> Kamion: run it at night
<Kamion> fabbione: do I get the source as well as the .changes? :)
<elmo> kamion: you can't reconstruct the .diff.gz from the md5sum?? lamer
<Kamion> oh yeah, I forgot I could trivially crack any md5sum-signing scheme, silly me
<fabbione> Kamion: yeah hold on :-)) i am preparing an interdiff
<fabbione> start getting -17
<fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/17_to_18.diff
<fabbione> the patch is big due to importing all the d-i stuff
<fabbione> but the changes to the relevant files are contained
<Kamion> fabbione: is ignoring errors from kernel-wedge check a good idea?
<Kamion> I'd rather the build failed if that breaks
* fabbione feels Kamion's heartbeat slowing down....
<fabbione> Kamion: it breaks on unrelated packages like linux-headers
<fabbione> because they are sometimes empty
<fabbione> and kernel-wedge bitches about it
<Kamion> heartbeat?
<Kamion> hm, should just fix kernel-wedge for that
<Kamion> but ok, later stage
<fabbione> Kamion: yeah... reading the patch... driving you crazy... dieing slowly in front of your pc :P
<Kamion> heh
<Kamion> fabbione: I'm not sure shipping debian/control in its current condition is a good plan
<Kamion> lots of i386-specific generated stuff in it
<fabbione> Kamion: debian/control is regenerated everytime from control.stub
<fabbione> if you were building it from amd64 or ppc would have been the otherway around
<Kamion> yeah, I know that
<Kamion> I think it might be better to save the ungenerated version
<Kamion> and restore it in clean
<Kamion> anyway, building
<fabbione> i did use the same way as -di- but yes it can be done
<fabbione> that's also why i call debian/control also in clean
<fabbione> so it gets updated immediatly
<fabbione> Kamion: have fun :-)
<fabbione> i am off for today
<smurfix> daniels: the radeonfb from ~daniels/xorg/i386-radeon_drv.o still kills my monitor
<daniels> smurfix: hmmmmm
<daniels> smurfix: what setup are you running?
<smurfix> daniels: radeon 9600, one TFT display on its digital output.
<smurfix> Putting it on analog gets me a "you exceed my timing parameters, go away" display instead of a "I'm told to shut down so I'll go away" message on the TFT.
<smurfix> lspci -n:
<smurfix> 0000:01:00.0 0300: 1002:4150
<smurfix> 0000:01:00.1 0380: 1002:4170
<daniels> smurfix: so plugging it into your VGA port breaks, but plugging it into your DVI port works?
<smurfix> No, both break
<smurfix> just differently.
<daniels> does commenting out your HorizSync/VertRefresh lines, and commenting out the Option "DPMS" line, in the Monitor section, have any effect?
<smurfix> daniels: I'll try ...
<Mitario> hullo everyone
<eruin> would any of you have a script to recursively print md5sums of a directory to a text file
<daniels> eruin: touch foo && for i in $(find ./ -type f); do md5sum $i >> foo; done
<eruin> thankyou :)
<Keybuk> daniels: find . -type f | xargs md5sum > foo
<daniels> Keybuk: meh
<eruin> man I need to man find
* lamont really walks out the door
<eruin> daniels: can I ask you for another one? the find pattern to match all *~ files ? :P
<tseng> -iname *~ ?
<smurfix> daniels: nope
<smurfix> daniels: same result. I can send you the xorg.log if that'd help.
<eruin> tseng: cheers ;)
<Kamion> fabbione: yeah, linux-kernel-di-* is different because it's only one architecture per source package
<Kamion> tseng: just -name will do there
<tseng> ya
<tseng> i always use -iname out of habit
<daniels> fabbione: have you got a link to the agp problems?
<daniels> smurfix: er yeah, thanks
<spotter> is there a good reason why pgp4pine is in multiverse, but pine isn't?
<smurfix> daniels: daniel.stone@canonical ?
<daniels> smurfix: yah
<smurfix> daniels: sent.
<daniels> ta
<daniels> smurfix: try removing the HorizSync and VertRefresh lines
<daniels> if that fails, remove the DPMS line
<daniels> (all Section "Monitor")
<smurfix> daniels: you're looking at the wrong Monitors section
<smurfix> daniels: you want the one named "Test"
<smurfix> daniels: iow, they already are commented off
<daniels> smurfix: bah
<daniels> what about if you take out all the custom modelines?
<RubenV> is there an ubuntu specific anacron maintainer?
<smurfix> I can do that. They did work a few months ago, so I kinda doubt that'll change anything. But I'll try.
<bob2> RubenV: no
<RubenV> i've just made a quick patch to add lsb functions to the init script
<daniels> smurfix: so was it working right before you upgraded radeon_drv?
<bob2> RubenV: send it to debian's bts
<Kamion> bob2: no, don't
<Kamion> RubenV: lsb functions are Ubuntu-specific, please file them in our BTS
<RubenV> bob2: do they accept those?
<RubenV> thought so
<RubenV> ok, coming up
<RubenV> it's just a quick fix though
<bob2> oh, oops, the lsb pretty printing thing
<smurfix> I was working up until ~three months ago, with the xfree that's no longer in Sarge either.
<eruin> find relies on having an uptodate db
<smurfix> daniels: s/I/It
<eruin> ?
<daniels> smurfix: with XFree86 4.2.1?
<RubenV> hmmm
<RubenV> no anacron module?
<RubenV> i'll just put it under cron then
<smurfix> daniels: probably. I didn't actually reboot for a long time and then was way too busy to reboot the system all the time to narrow the problem down. :-/
<daniels> smurfix: could you please email the log from a working setup (preferably one with CRT, one with TFT) to benh@kernel.crashing.org, complete with your config and a quick description of the problem, and mention that it's broken both with 6.8.1's radeon_drv, and the patch that he sent me last night?  cc me as well please
<daniels> smurfix: heh
<daniels> smurfix: well, if you could get an email off, that would be great
<smurfix> daniels: yeah, I'll have to dig up an older xfree from Snapshots and all that, but apparently there's no fucking way around doing the work. :-/
<smurfix> (so what else is new)
<daniels> smurfix: yeah
<daniels> smurfix: oh, for the email, he doesn't need a working log -- just a broken one should be sufficient
<RubenV> https://bugzilla.ubuntu.com/show_bug.cgi?id=4118
<RubenV> gonna be cleaning up some more init scripts
<RubenV> just to contribute something
<smurfix> daniels: OK, that does limit the effort somewhat ;-)
<Kamion> RubenV: don't put it under cron please
<Kamion> RubenV: if there's no appropriate package, use UNKNOWN
<smurfix> galeon is broken in hoary. It's linked to nautilus.so.2 which the latest update renamed to nautilus-private. :-/
<RubenV> Kamion: aw, sry, too late :s
<smurfix> s/nautilus/libnautilus/g
<Kamion> RubenV: reassigned
<RubenV> doing the alsa script now
<RubenV> that does have a pkg :)
<RubenV> voila, no more ugly starting ALSA
<RubenV> and now it's time for some studying
<__daniel> hai
<Mithrandir> thom: I think I found a bug in apache.  wrt multiviews.
<azeem> in theory, I could go an sell Ubuntu-CDs via the web, right?
<tseng> sure
<RubenV> as long as you obey the gpl
<RubenV> i think :)
<zul> he isnt modifying or removing the license
<bob2> yes, but he is distributing gpl code
<zul> oh yeah..duh
<tseng> ew @ openoffice 1.1.3
<RubenV> ?
<tseng> fails on missing kdelibs4-dev
<_rene_> hehe
<_rene_> we had that discussion this afternoon
<__daniel> OOo depends on kdelibs?
<_rene_> openoffice.org-kde does
<_rene_> and so the source build-deps on kdelibs4-dev
* __daniel gets the collywobbles
<Md> I'm trying to understand how udev-udeb is being used. I see no init script in the package and no postinst to create the rules. who knows more?
<Md> I can't remember Colin Watson's nick
<Kamion> Md: that's me
<Kamion> Md: it's all still in development and wildly unsuitable for sarge, which is why I haven't sent the patches back yet
<Kamion> Md: rootskel does all the init work
<Md> Kamion: I started merging some parts of it, feel free to send any kind of patches or comments
<Kamion> ok, fair enough, but I think it would be a good idea to keep it out of sarge; I'm scared what would happen if udev-udeb showed up in the debian-installer Packages file
<Astharot> hi Md :)
<Kamion> something might decide to install it :)
<Md> BTW, you don't need -pudev for dh_link because it's the default and you don't need -a for dh_installdirs because all debian/*.dirs files are always processed anyway
<Kamion> Md: rootskel pretty much has to have control of the early init process in d-i - it's too custom
<Kamion> Md: yeah, that's true
<Kamion> I think I thought the former was clearer despite the default
<Md> Kamion: yes, I'm just adding some code to debian/rules but the package will not be generated by default
<Kamion> ok, cool
<Kamion> at some point soon I'll be mailing debian-boot and all the affected maintainers with the work I've done
<Md> do you have an URL for the rootskel file which deals with the rest?
<Kamion> but I don't want to distract too much from sarge with shiny things
<amu> do we have a kernel with benh's sleep-support for a G4 ? 
<Kamion> amu: afraid not
<Kamion> Md:    libiw27 |       27-1 |       testing | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
<Kamion> oopd
<Kamion> Md: http://archive.ubuntu.com/ubuntu/pool/main/r/rootskel/rootskel_1.09ubuntu3.dsc
<Kamion> I put it next to the existing devfs code
<amu> Kamion: stupid question, why not?  
<Kamion> amu: no kernel maintainer for hoary right now
<Md> Kamion: /.dev is definitely not necessary for d-i
<daniels> amu: that's an update to 2.6.9 + the patch
<Kamion> Md: noted, will fix
<amu> ubuntu-ppc without sleep, is like you go undressed to bed :( 
<Kamion> I wasn't sure
<amu> daniels: no prob with it, just woundert is there something like this atm
<Kamion> Md: is it likely to be possible to use udev without having hotplug at all? it would be nice to be able to switch Debian over one step at a time rather than all at once
<Md> Kamion: you need at least /sbin/hotplug. what's wrong with the rest of the program, anyway?
<lucas_> hi
<Kamion> switching d-i to hotplug is non-trivial; it requires an overhaul of the hardware detection architecture
<Kamion> I'm working on it but it's not the work of five minutes
<Md> Kamion: oh, you mean coldplugging. it's not mandatory, look at the init script to see how to disable it
<Kamion> we could certainly install some kind of dummy /sbin/hotplug in the meantime
<Md> Kamion: /sbin/hotplug does nothing by itself, look at it
<Kamion> I know, I've been looking at it and friends for much of today :)
<Kamion> it can't be called /sbin/hotplug in d-i incidentally, for annoying reasons
<Md> like?
<Kamion> we have to activate it only after pivot_root
<Kamion> if you call it /sbin/hotplug then udevd gets started up in the first initrd and prevents it being unmounted
<Kamion> I ran into that straight away
<Kamion> so I just call it /sbin/hotplug.real instead and echo that into /proc/sys/kernel/hotplug shortly after pivot_rooting
<Md> so don't put it in the first initrd... what am I missing? or make it just exit if everything it needs is not there
<Kamion> you have to put it in the first initrd, or you don't get it until after the first round of hardware detection
<Kamion> d-i has no way to install additional udebs until then
<lucas_> Kamion: how big is a full ubuntu mirror ? debmirror is broken, so I need to get everything. but I'm not sure if it will fit on my disk.
<Md> then I think it should be patched to exit until the environment is OK, it looks simpler
<Kamion> how should it tell?
<Kamion> there is no significant difference in the filesystem between before pivot_root and after, apart from /dev being populated
<Md> [ -e /some/file ]  || exit 0
<Md> at worst you will have to create a flag file
<Kamion> the first initrd is copied wholesale to the ramdisk
<Kamion> I think I prefer the current approach TBH, it's easier to understand and doesn't seem fragile
<Md> I find easier to understand *my* approach :-)
<Kamion> if I patch /sbin/hotplug then that patch needs to be on the real system as well - I don't want the code to differ between deb and udeb
<Kamion> so a flag file doesn't sound like an option ...
<Md> that's OK, I maintain hotplug and can do this :-)
<Kamion> oh, I thought that was ukai
<Md> I'm the co-maintainer
<Kamion> ah
<lucas_> ***lucas@ubuntu2:/space/ubuntu-mirror/pool$ ls -l universe/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb
<lucas_> lrwxrwxrwx    1 lucas    lucas          72 Nov 25 13:55 universe/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb -> ../../../../pool/multiverse/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb
<Kamion> hm, speaking of, a hook in hotplug to allow feeding back module names to whatever's calling the rc scripts would be really nice ... :-)
<Kamion> but, looking at the code, it seems very non-trivial to add such a hook
<lucas_> there are symlinks looping to themselves on the archive :/
<Md> Kamion: what?
<Kamion> lucas_: I believe something on the wiki tells you
<Kamion> Md: look at how hw-detect interacts with discover and you'll understand
<Kamion> Md: especially the bit that allows the user to enter module parameters for each module that's going to be loaded
<Md> the major problem with hotplug is that it should be completely rewritten to remove all compatibility code for 2.2 and 2.4 kernels...
<Kamion> lucas_: my warty+hoary mirror for amd64+i386+powerpc is just over 10GB
<mdz> Md: also the udev race conditions seem to need hotplug changes to be fixed
<Md> Kamion: module parameters are managed by modprobe, not hotplug
<Md> mdz: which race?
<Kamion> Md: there is no way for d-i to know in advance what modules are going to be loaded so that it can ask
<lucas_> Kamion: ok, thanks
<mdz> Md: between the completion of the modprobe process and the creation of the device node
<mdz> so that modprobe <module> && work with /dev/foo works as expected
<Md> mdz: it will never be fixed, there is no easy way to do it and the maintainer says to use dev.d
<Kamion> Md: I would like to be able to know when each module is going to be loaded so that I can ask the user if they want to supply any options to it, basically
<Kamion> Md: we can do this with discover because it just gives back a list of module names it wants rather than loading them itself
<Md> Kamion: I see your point, but if users know that some modules need options they probably know their names as well
<Kamion> Md: there's nowhere for d-i to ask that though
<Kamion> Md: people could drop to a terminal and do it, but that's hardly acceptable UI
<Md> Kamion: I think this could be added to hotplug without too much work, BTW
<mdz> Md: that works for some cases, but not others
<Md> Kamion: there is no reason to use a terminal
<mdz> pppd, for example, doesn't make sense as a dev.d script
<Kamion> how should people add options in the context of d-i then?
<Md> Kamion: you present users with a dialog with input fields for a module name and its options
<Kamion> Md: in debconf? good luck
<Md> mdz: OTOH in this case you already know the device name
<Kamion> mdz: /lib/debian-installer-startup.d/S40framebuffer-module-linux-x86 is another example
<Kamion> I've had several cases recently where /dev/fb/0 simply never appeared
<Kamion> it's as if the event vanished somewhere between hotplug and udev
<mdz> Md: true, but polling waiting for the device node to appear is such a hack
<Kamion> but I haven't been able to reproduce it reliably enough to debug it; it seemed to go away when I started poking at it
<Md> mdz: agreed. but I'm not going to fight this anymore, you people should subscribe to the linux-hotplug mailing list
<mdz> Md: I wish I could follow the mailing lists for every project that I work with, but unfortunately it is too much
<Kamion> the problem with using /etc/dev.d for the framebuffer stuff is that checking to see whether /dev/fb/0 has appeared seems to be about the only reliable way to tell whether the framebuffer module loaded properly or not
<Kamion> particularly with vesafb and vga16fb; they can load and then not work
<Kamion> so /etc/dev.d doesn't really work; you still have to say "we're going to wait for a while to see if this worked, otherwise give up" :-(
<Md> BTW, you should use "sleep 0.1" instead of "sleep 1"
<Kamion> is that implemented in busybox?
<Md> if it works in busybox
<Kamion> it doesn't seem to be
<Kamion> it just uses sleep(3)
<Kamion> I would certainly prefer finer granularity
<Kamion> then again, it seems to take as long as five or six seconds for the device to appear on my test laptop
<Kamion> I'd love to know what the system is doing for that time
<Md> me too. in this case I find hard to blame fb brokeness on udev :-)
<Kamion> oh, I'm not blaming udev exclusively, but it does make things harder to follow that's all :-/
<Kamion> still, getting rid of devfs *was* nice
<Md> it was a bad idea from the start to use devfs for hardware detection, but nobody listened...
<Kamion> nothing else was available at the time
<Kamion> for d-i, that is
<Md> it was a bad idea to not target 2.6 kernels from the start as well :-)
<Kamion> you do realise d-i development started four years ago right?
<Md> yes
<Kamion> it's not good strategy to develop for a kernel you can't run yet :)
<Md> maybe not from the start, but one year ago
<doko> elmo: please sync openoffice.org-debian-files, when openoffice.org 1.1.3 enters hoary
<Kamion> could be; we've been gradually moving over
<Kamion> my experience so far certainly tends to support my opinion that moving to udev/hotplug in a hurry would not have been a good idea from a stability/permanent-releasability point of view
<smurfix> Md: even half a year ago I wouldn't have depended on 2.6 exclusively.
<Kamion> I'm somewhat worried for hoary actually; I'd much prefer if we were getting the massive attention that d-i changes in Debian get, for a change this sweeping
<Kamion> but we're committed to it
<Kamion> mdz: oh, do you mind if I add pciutils-udeb, usbutils-udeb, and libusb-0.1-udeb? I need pci.ids and usb.ids now that discover1-data is no longer around to provide the names of network interfaces for netcfg's UI
<Kamion> mdz: which I had totally not thought about in advance
<azeem> Kamion: joeyh said you will open up the d-i branch for etch soon, so if you merge it early, you'll get enough testing there as well, hopefully
<azeem> you == the d-i guys
<Kamion> mdz: and getting lspci and lsusb will probably be a bonus for debugging purposes, too
<Kamion> azeem: yeah, I'm very much hoping so
<Kamion> azeem: I have a number of other changes I want to merge, but which are too untried for sarge
<azeem> sweet
<fabbione> Kamion: how is the build going?
* fabbione is curious as hell
<Kamion> make[1] : Entering directory `/home/cjwatson/src/ubuntu/linux-source-2.6.8.1/linux-source-2.6.8.1-2.6.8.1/debian/build/build-power4-smp'
<Kamion> The changelog says we are creating 2.6.8.1, but I thought the version is 2.6.8.1-3-power4-smp
<Kamion> make[1] : *** [stamp-debian]  Error 1
<Kamion> oh, damnit, I probably need Ubuntu's kernel-package
<fabbione> argh.. yes
<Md> ROTFL! I just noticed that the new udev makefile prints init-style green "[OK] " labels instead of the whole command line
<fabbione> Md: green? it's white here
<fabbione> ahh
<fabbione> never miind
<Kamion> fabbione: trying again, off to the pub now
<fabbione> Kamion: have fun :-)
<elmo> doko: nothing to sync?
<doko> elmo: ahh, ok, from experimental, or should this be directly uploaded?
<Mithrandir> fabbione: pong?
<fabbione> ehehe
<fabbione> Mithrandir: #debian-women
<fabbione> i was trying to convice your gf to build a kernel for me :-P
<Mithrandir> hehe :)
<Mithrandir> what arch?
<fabbione> amd64
<Mithrandir> I don't think she has an account on any amd64 box
<fabbione> we need to fix this, don't we? ;)
<fabbione> well it's easy
<Mithrandir> she just doesn't have any account on my home box, is that so weird? :)
<fabbione> just grab linux-source-2.6.8.1<whatever>-17.d*
<fabbione> Mithrandir: apply this: http://people.ubuntulinux.org/~fabbione/17_to_18.diff
<fabbione> and build
<fabbione> it needs to be done in hoary
<fabbione> even if you tell me in 2 days or tomorrow late evening if it works, it will be more than fine
<Mithrandir> applied against what kernel source?
<fabbione> Mithrandir: we have only one
<fabbione> that applied to the entire package
* Mithrandir runs apt-get source
<fabbione> linux-source-2.6.8.1-2.6.8.1
<Mithrandir> yeah, but my DSL is only at about 260KB/sec atm.
<fabbione> yeah don't worry...
<fabbione> even tomorrow is fine
<fabbione> brb
<jdub> doko: can we remove the kde depends/packages from OOo in the mean time, before haggai and _rene_ add their optional foo?
<doko> jdub: I'll have a look, but maybe let's wait for the first problem reports before the next upload.
<jdub> doko: if it depends on kdelibs4-dev, it won't build.
<jdub> doko: OOo is sitting there happily not building.
<jdub> doko: so i have a problem report and a solution for you ;-)
<seb128> jdub: how is flumotion package going ? thomasvs was asking about it
<jdub> seb128: haven't spent time on it since the initial packaging - have to upgrade and upload.
<elmo> doko: synced
<jdub> seb128: will probably do it over the weekend, can't today.
<seb128> jdub: ok
<_rene_> we probably could do it fairly quick... I just need a package which reliably is in ubuntu but not in debian ;-)
<_rene_> the DEB_BUILD_OPTIONS logic is already written...
<Matt|> hoary: anyone got totem working?
<doko> jdub: ok, will do another one ...
<_rene_> ok, if anyone wants to tell me that package, mail me ;-)
<Matt|> hey guys is totem working ok in hoary? just crashes on startup here
<thom> Mithrandir: oh?
<jdub> doko: i was going to do a quick revision here, but 171MB... OWCH :)
<jdub> Matt|: load it with a file
<Matt|> jdub, ok i'll try
<Matt|> jdub, yeah that works ok
<jdub> known bug, hopefully there'll be a new release soon
<Matt|> upstream bug?
<jdub> yes
<Matt|> ok thanks v much
<Mithrandir> thom: go to http://err.no/personal/wishlist/ 
<Matt|> it is a recent thing
<doko> jdub: yes, that's why I didn't upload it with my 16kB upstream ...
<Mithrandir> thom: but I'm off to bed now.  Talk to you in the morning
<jdub> doko: i'm tempted to do it on chinstrap or something
<jdub> doko: man, my upstream is fatter than that - if you don't want to do it, let me know
<doko> it's on adare for now, I just didn't want to upload the binaries.
<jdub> you only need to upload the diff
<elmo> you only CAN upload the diff
<doko> yes, working on it ...
<jdub> elmo: so, the mp3 stuff in debian - what led to it being acceptable?
<elmo> jdub: *shrug* decoding's never not been accepted - at the time, the consensus was it was as valid as the lzw decompress patent, i.e. not
<elmo> oh, and infact, I think Thompson explicitly said free decoders were okay or something too
<jdub> ?!
<jdub> well, lzw stuff led to libgd-nonfree and friends
<pitti> mdz: nice de-rootification hints, thanks for them
<seb128> jdub: please comment on #4092 :)
<elmo> jdub: only for encode
<elmo> jdub: decode was always accepted
<elmo> that's why we had web browsers in main...
<elmo> or image viewers or...
<elmo> and why libungif existed
<jdub> seb128: that's the ffmpeg thing?
<seb128> jdub: yes
<jdub> seb128: oddly, this is related ;)
<seb128> :)
<jdub> elmo: so the 'debian stance' is that the patents cover encoding, not decoding, so let's get on with it?
<elmo> okay, I may have made up the point about Thompson not going after decoders at one stage - I only vaguely recall reading that, and can't find a reference
<elmo> jdub: err, no - the consensus at the time, as I remember it was that the mp3 decode patent wouldn't stand up
<jdub> and i can't remember them ever saying anything positive about non-thomson Free implementations
<jdub> elmo: whoa, okay
<jdub> elmo: so, ffmpeg stuff.
<elmo> remember, that's partially based on lzw precedent - unisys claimed decode on that too, and we (and gzip upstream who did a lot of research into it) thought that was bogus too
<elmo> but Debian really isn't a good example, we do a lot of legal stuff that's dubious basically through lethargy.. e.g. it took us years to start enforcing GPL vs. SSL conflicts
<elmo> jdub: what's that do?
<jdub> so if debian thinks a patent is bogus, you'll ship until there's judgement or injunction
<jdub> ?
<jdub> ffmpeg viciously violates every mpeg related patent known to man
<elmo> jdub: *shrug* I'm really not comfortable answering questions about "what debian does" - I can't speak for them , but historically we have yes
<seb128> ffmpeg is staying in NEW for months :p
<elmo> jdub: more so than the existing stuff we have?
<elmo> e.g. xine, SDL's plaympeg etc.?
<jdub> doesn't debian's xine disable its ffmpeg stuff?
* jdub checks
<jdub> ffmpeg is copy'n'pasted in lots of things
<jdub> so it's a hard one
<jdub> seb128: 'longtemps' in french?
<seb128> yes
<seb128> you start with the big "everybody speaks french" plan ? :)
<jdub> heh, what does it mean? :)
<seb128> oh
<seb128> a long time
<jdub> haha
<seb128> I thought you were reaction to my <seb128> ffmpeg is staying in NEW for months :p
<jdub> yeah ;)
<jdub> but no
<jdub> my french is not that good
<jdub> i just saw it on vuntz's jabber status :)
<seb128> oh ok
<jdub> 'parti pour longtemps' -> fun :)
<seb128> he he
<jdub> i think xine uses a limited ffmpeg
<seb128> jdub: about ffmpeg, dunno what sam did exactly with the package waiting in NEW, but usually he does really good work
<elmo> sam is usually very careful with patents
<seb128> yes
<jdub> seb128: is that gst-ffmpeg or ffmpeg itself?
<seb128> ffmpeg
<jdub> oh no, it has libavcodec in it too
<elmo> the main question is if the ffmpeg in NEW does encode - we have decoders in main (-> precedent), we don't, AFAIK, have any encoders
<seb128> taaz is waiting on ffmpeg to upload gst-ffmpeg ... that's not needed, but since no decision is taken about ffmpeg ...
<mirak> erf
<jdub> so it's sitting in NEW purely because it's controversial?
<mirak> j'ai cr un fichier   "-f2" par megarde
<mirak> je ne parviens pas a le virer
<mirak> avec tm
<mirak> rm
<mirak> bon je l'ai vir avec konqueror
<mirak> mais j'ai pas trouv comment faire avec rm
<mirak> il croit en effet que je lui passe une option
<seb128> mirak: ECHAN imho
<mirak> ?
<_rene_> mirak: and if not ECHAN, ELANG anyway
<seb128> mirak: that's #ubuntu-devel ...
<_rene_> mirak: this is an english-speaking channel...
<mirak> damn
<mirak> sorry
<mirak> lol
<mirak> I am tired
<mirak> my bad
<smurfix> mirak: so go to sleep
<jdub> i can't understand what you are talking about, but i would defend to the death your right to say... whatever it is.
#ubuntu-devel 2004-12-07
<pasc> mirak: stick a ./ in front of the file name
<mirak> mmm
<seb128> yes, that works too :p
<pitti> elmo: still here?
<_rene_> pitti: besides the fact that 1.1.3-2 is b0rked, 1.1.2dfsg1-3 and 1.1.3-2 have the l10n-* changes
<elmo> pitti: yeah
<pitti> _rene_: heh, nice
<pitti> elmo: klogd     5192  0.1  0.2  2560 1472 ?        Ss   00:12   0:00 /sbin/klogd -P /var/run/klogd/kmsg
<pitti> elmo: ^^^^^   another item gone from your list :-)
* pitti grins
<elmo> I thought you couldn't do that ?
<pitti> elmo: it's night, remember?
<pitti> the DEROOTIFICATOR strikes back
<pitti> elmo: no, of course I had to cheat
<pitti> elmo: klogd is now run as unprivileged user right from the start
<jdub> azeem: your new multisync has Depends: evolution (<< 1.5) on the evo plugin
<pitti> elmo: I added an option to read an alternative /proc/kmsg location (a pipe /var/run/klogd/kmsg)
<jdub> pitti: man, you are rocking on the derootification
<pitti> elmo: and have a root process (a mere 'dd') which pipes /proc/kmsg to /var/run/klogd/kmsg
<pitti> elmo: I know it's an evil hack, but it works great
<pitti> elmo: and so we separated the root task from all the parsing stuff which is now done purely as user
<pitti> jdub: thanks :-)
<elmo> pitti: rock on
<pitti> well, bedtime now
<pitti> I do some further cleanups and tests and upload tomorr
<pitti> ow
<fabbione> YEAH
<fabbione> applying patch sparc64-syslog-register to ./ ... ok.
<fabbione> the kernel starts to take shape
<fabbione> MUHA MUHA MUHA
<pitti> fabbione: how far is the porting effort?
<fabbione> pitti: i am building the "golden debs"
<pitti> fabbione: btw, will we all get a free sparc64 when you are done?
<pitti> :-)
<fabbione> basically ubuntu on top of ubuntu
<pitti> fabbione: "golden"?
<pitti> ah
* pitti has never seen a Color: attribute in debian/control
<fabbione> and i am hacking around the kernel now
<pitti> fabbione: wait, tomorrow the kernel will run as normal user :-)
<pitti> fabbione: btw, the platform supported by Debian is "only" sparc32?
<pitti> fabbione: I had woody on a sparc64 once; you are now building the whole userland for 64 bit?
<fabbione> pitti: ETOOMANYQUESTIONS
<fabbione> pitti: oh yeah.. kernel as user ehhehe
<fabbione> pitti: it depends from the kernel.
<fabbione> but the userland is always 99.9% 32bit
<fabbione> it's just faster
<sjoerd> fabbione: btw. alsa is now working on my U5, you might want too look at the patches for that (as your doing kernel stuff)
<fabbione> sjoerd: sure.. right now i need to get the packages to compile
<sjoerd> :)
<fabbione> and give some love to the config
<fabbione> sjoerd: do you have idea why sparc have nsdiwrapper support?
<fabbione> isn't that a i386/m$ thingy?
<pitti> Solaris drivers for Linux/sparc?
<sjoerd> fabbione: huh ?
<Md> NDIS is a windows technology, I can't see how solaris enters the picture
<pitti> Md: just guesssing :-)
* fabbione wonders why i was prompted for it
<elmo> because our kernel patch isn't very ipcky
<fabbione> elmo: ok thanks
<Md> does ubuntu have some modem autodetection script? I'm pondering about what to do with /dev/modem
<fabbione> Md: nope...
<Md> I suppose it's possible to send ATIwhatever to all serial ports and check if something comes back, but doing this at every boot could take too much time. and I do not even want to think about what happens if something which is not a modem is connected to the port...
<elmo> anyone here use apt-move ?
<fabbione> good night guys
<fabbione> cya in 5/6 hours
<pitti> night fabbione 
<_rene_> Md: wvdialconf does something like that...
<_rene_> Md: (just used it some time ago)
<pitti> good night everybody!
<lamont> evening
<eruin> any of you have an idea as to what might be causing either a very long wait time after failing to insert pciehp/shpchp (operation not permitted) or a complete system halt (on boot)?
<eruin> I see rp_filter. after it the times it doesn't actually halt my system (which is about 1/2 of the time), then setting up network
<eruin> I've got one connected eth and one not connected, and I'm thinking this is more an issue with that fact than hotplug after reading bug #1869
<haggai> eruin: long waits are often caused by unreachable dns servers.  Did you try commenting out all nameservers in /etc/resolv.conf?
<eruin> no, but I will do
<__daniel> good night
<zul> evening
<lamont> if someone rolled isdnutils forward from libstool 1.4, then we could move it to universe...
<lamont> (it's ftbfs on amd64)
<sladen> pitti: sweet klogdness!
<jdub> doko: woo! :)
<doko> :) morning, did the build start?
<fabbione> morning guys
<jdub> doko: i don't think i get to see running logs
<fabbione> hey jdub
<jdub> yo fab :)
<fabbione> jdub: i think soon you will be able to run hoary on sparc
<jdub> rad :)
<jdub> how's kernel stuff?
<fabbione> building now
<fabbione> it still needs love, i am only checking the patches right now
<fabbione> there is a few things that needs to be added properly
<fabbione> the major blocker atm is silo
<fabbione> because it build-dep on gcc-2.95
<fabbione> it compiles fine with other gcc's
<fabbione> but apparently it doesn't always work
<fabbione> so someone will have to test it for me
<fabbione> (because i only have ONE sparc that it is actually building)
<fabbione> jdub: do you feel brave enough to give it a shot?
<jdub> yeah, maybe on my U5
<fabbione> jdub: cool
<jdub> then on the 220R :)
<fabbione> jdub: just grab silo from there
<fabbione> don't use the other debs, because they are not all of them yet
<jdub> i should try silo with a sarge install?
<jdub> or...?
<fabbione> jdub: it doesn't matter on which distro
<fabbione> it's just recompiled with gcc-3.3 instead of 2.95
<jdub> oh right
<fabbione> there are no package or code changes
<jdub> oh, sorry, missed your "only one sparc" bit :)
<fabbione> ehehe
<jdub> i'm tempted to put my sata disks in the sparc now...
<jdub> no idea if it'll boot off them though. i suppose it wouldn't.
<fabbione> nope
<fabbione> obp is pretty anal
<fabbione> either IDE or SCSI
<jdub> doko: http://people.ubuntulinux.org/~lamont/buildLogs/o/openoffice.org/1.1.3-2.3ubuntu2/openoffice.org_1.1.3-2.3ubuntu2_20041126-0708-i386-failed
<jdub> doko: hrm
* HcE m tisse
<HcE> ops :$ wrong #
<fabbione> ehehhe
<fabbione> HcE: go and take your piss :P
<HcE> :P
<HcE> norwegian should be a far off language only I understood
<HcE> and of course the persone I was supposed to talk to
<fabbione> HcE: i only understand a bit of danish/swedish/norvegian
<fabbione> but that "bit" is pretty common
<fabbione> to all of them
<HcE> your not dannish?
<fabbione> nope
<fabbione> i am italian
<fabbione> i live in dk
<HcE> only live in .dk?
<HcE> ah
<fabbione> yeah
<HcE> can't go to the toilett before I've check new packages from Debian
<HcE> the days big highlight
<fabbione> haha
<HcE> happy to see wxWidget 2.5.3 as a .deb finally
<pitti> Morning
<fabbione> morning pitti
* sid77 ciao
<mdz> pitti: here?
<fabbione> morning mdz
<mdz> morning
* fabbione starts the really boring part of udebs integration
<Mithrandir> fabbione: I ran out of disk space last night, redoing build now.
<fabbione> Mithrandir: ah cool
<fabbione> thanks
<fabbione> Mithrandir: 8012 -rw-r--r--   1 sparcbuildd sparcbuildd  8191682 Nov 26 08:04 linux-image-2.6.8.1-3-sparc64_2.6.8.1-17.1_sparc.deb
<fabbione> ;)
<Mithrandir> yay
<jdub> woo :)
<fabbione> Mithrandir: we might have problems with silo
<fabbione> as i explained to jdub
<fabbione> it needs testing :(
<fabbione> otherwise we will have to pull in gcc-2.95 for sparc in main
<seb128> morning
<fabbione> hey seb
<Mithrandir> ew, ok.
<fabbione> ouch
<fabbione> something is not properly working...
<fabbione> the merge doesn't create kernel-image udebs
* sid77 re
<pitti> Hi mvo_, hi daniels!
<pitti> daniels: btw, I can test the new radeon_drv if you want
<daniels> pitti: hey dude
<daniels> pitti: ah rad -- http://people.ubuntu.com/~daniels/xorg/powerpc-radeon_drv.o
<pitti> daniels: anything I should test in particular?
<pitti> daniels: shall I change anythign in Xorg.conf?
<fabbione> daniels: hey kid
<fabbione> daniels: libao needs to build-dep on libxau-dev, can you take care of it?
<mdz> night all
<fabbione> night mdz
<pitti> Night mdz!
<daniels> fabbione: k
<daniels> mdz: night dude
<daniels> pitti: ditch Option "UseFWPLL", that's about it
<fabbione> daniels: thanks
<mvo_> night mdz 
<pitti> daniels: I already tried the new driver
<pitti> daniels: still with the PLL option
<daniels> pitti: still works?
<pitti> daniels: it behaves exactly like the very old one
<daniels> pitti: because I threw away the usefwpll patch
<daniels> pitti: rockin!
<pitti> daniels: external works, internal one flickers
<pitti> daniels: so, "no"
<daniels> pitti: oh, right
<daniels> hold on, there's an option for that
<pitti> daniels: the last one you sent me worked fine
<pitti> daniels: "very old one" == the version shipped in 6.8.1-0.2
<daniels> pitti: does 'Option "LVDSProbePLL"' help?
<daniels> pitti: if not, does 'Option "NoLVDSProbePLL"' help?
<pitti> daniels: first I try to remove UseFWPLL
<pitti> daniels: then the other two
<pitti> daniels: brb, I have to disconnect my monitor
<daniels> pitti: usefwpll should have no effect with the new radeon_drv (the one I put up last night)
<daniels> k
<pitti> daniels: oh, then the option should not make any difference?
<daniels> right
<pitti> indeed, no difference, still flicker. Let's try the other one
<azeem> jdub: euh
<pitti> daniels: no, neither option makes it work
<daniels> pitti: and it worked with my patch and UseFWPLL?
<pitti> daniels: yes
<daniels> heh
<pitti> daniels: it worked with the 2.3 MB driver you sent me 
<pitti> daniels: md5sum 2b44a78a...
<pitti> daniels: 2327838 bytes
<pitti> daniels: ^^ this certainly included debugging symbols?
<daniels> could you please email benh@kernel.crashing.org, CCing daniel.stone@canonical.com, send him your logs from both with LVDSProbePLL and with NoLVDSProbePLL, tell him it worked with my patch that pulls the PLL values from the registers, and just quickly describe your problem?
<daniels> pitti: yeah, it's only ~100kB stripped
<pitti> daniels: 230 kB for me
<pitti> daniels: anyway, do you want any logs?
<pitti> daniels: shall I set any value for above option?
<pitti> "true" or so?
<bob2> hrm, my laptop doesn't wake up from sleep
<bob2> shockingly
<daniels> pitti: if you could just throw them all (with LVDSProbePLL and with NoLVDSProbePLL) in the email to myself and benh, that'd be great, thanks
<daniels> pitti: nope, just Option "LVDSProbePLL" or Option "NoLVDSProbePLL"
<pitti> daniels: benh.get_email() == ?
<bob2> tommorow I'd guess
<daniels> pitti: benh@kernel.crashing.org
<daniels> pitti: see the line just above 'yeah, it's only ~100kB stripped'
<pitti> oh, missed that one
<pitti> I'll do
<pitti> daniels: how I shall refer to this driver I just downloaded?
<pitti> daniels: is it from any official version?
<fabbione> this is SOOOO evil!
<fabbione> one of the (2000) Makefiles clean targets remove without any check all files called kernel-image!
<fabbione> that of course.. disable the generation of the kernel-image*_udeb
<daniels> pitti: tell him it's with his patch backported to the 6.8.x branch
<lupus_> The following packages have been kept back:
<lupus_>   openoffice.org-debian-files
<lupus_> what does it misses?
<lupus_> I did dist-upgrade
<azeem> lupus_: do apt-get install openoffice.org-debian-files and see
<mvo_> lupus_: it looks like not all of openoffice has hit the archive yet
<lupus_> so those 2 packages aren't available yet?
<mvo_> it appears so
<mvo_> openoffice.org is still 1.1.2 
<haggai> doko asked elmo to sync -debian-files once openoffice.org was ready, looks like he perhaps did it early
<azeem> jdub: fixed now
<azeem> (hopefully)
<fabbione> lupus_: these kind of questions are more appropriate for #ubuntu
<lupus_> k sorry
<lupus_> but I thought hoary = devel so :)
<lupus_> but I missed the point of this channel I guess :)
<azeem> lupus_: yeah, but 'apt-get dist-upgrade does not work' is not a good error report
<azeem> in any case, stuff will break occasionally and people will be aware usually. If it is broken for a longer time, reporting it is fine I guess
<jdub> thom: GUS RELEASE!
<daniels> jdub: ... gravis ultrasound?
* jdub ITPs
<jdub> daniels: gnome-user-share
<Keybuk> jdub: what does that do?
<daniels> jdub: NICE!
<daniels> Keybuk: http://cvs.gnome.org/viewcvs/gnome-user-share/README?rev=1.2&view=auto
<daniels> i so need to prise my mouldavia rewrite off trinity
<jdub> Keybuk: user-policy sharing with apache+webdav :)
<Keybuk> ah, cool
<fabbione> jdub: apache1.3 or 2?
<fabbione> or it doesn't care?
<jdub> fabbione: 2 man, 2 :)
<jdub> it's *rad*
<fabbione> cool
<fabbione> less bugs from lusers for me :P
<daniels> jdub: mouldavia was still cooler
<fabbione> daniels: please libao :-)
<daniels> fabbione: yes
* sid77 goddbye, all!
<daniels> fabbione: wtf, dude, are you sure?
<daniels> daniels@catsby:~/canonical/libao/libao-0.8.5% egrep -r '#include.*X' *
<daniels> configure:#include <X11/Intrinsic.h>
<daniels> configure:#include <X11/Intrinsic.h>
<fabbione> daniels: apt-get --purge remove libxau-dev
<fabbione> and build it
<fabbione> it will fail building one of the libraries
<fabbione> the makefile is retarted and doesn't notice
<fabbione> until it starts creating the deb
<fabbione> where it will fail becuase ls .libs will return empty
<fabbione> there.. logs are on the way
<fabbione> repeatable on i386
<daniels> what the hell?  i can't see that this package uses Xau at all
<fabbione> checking for XauFileName in -lXau... no
<daniels> yes
<fabbione> and it FTBFS without :-)
<fabbione> checking for X... libraries /usr/X11R6/lib, headers 
<daniels> the only place XauFileName is referred to is in autoconf files
<fabbione> this line will change once you install Xau
<daniels> i know that.
<daniels> but it's not actually using any X headers or functions AFAICT
<fabbione> ah crap! first 2 spam mail via @canonical.com
<smurfix> can't escape them :-(
<jvw> who do I mail for inquiries re sponsoring (the upcoming conference)? Mako? some role account?
<daniels> jvw: mako@canonical
<jvw> ok, tnx
<daniels> Kamion: ping
<_rene_> Kamion, jdub: http://cvs.debian.org/oo-deb/debian/rules.diff?r1=1.231.2.26&r2=1.231.2.27&diff_format=h&cvsroot=debian-openoffice
<lucas_> hi
<lucas_> Kamion: you there ? I'm now successfully generating iso images. I'd like to be able to replace some packages with my own now
<fabbione> Mithrandir: how is going the build?
<lucas_> I'd like to use the LOCALDEBS way
<Mithrandir> fabbione: it built.
<fabbione> Mithrandir: cool.. what about the udebs?
<lucas_> but I don't understand which directory structure debian-cd expects in the local repository
<Mithrandir> fabbione: there are udebs with non-zero size. :)
<fabbione> Mithrandir: that sounds cool
<fabbione> it build.. it works :-)
<fabbione> i just need to wait for Kamion to confirm ppc
<fabbione> even if the version you built has 2 bugs
<fabbione> i fixed them locally
<Mithrandir> ok
<fabbione> it doesn't generate kernel*.udeb
<fabbione> and as a consequence it miscalculate the dependencies
<Mithrandir> oh, ok.
<fabbione> but they look good here
<Mithrandir> we want kernel*udeb?
<fabbione> debdiff is happy
<fabbione> Mithrandir: it's a missing $(touch modules/${arch}/kernel-image
<fabbione> )
<Mithrandir> heh
<fabbione> but the missing file is related to something else
<fabbione> it must be one of the clean target that wipes it away
<fabbione> because it always disappear
<Kamion> fabbione: damnit, I ran out of disk space :-(
<fabbione> Kamion: shit
<Kamion> fabbione: can you use a porting box in the lan or something?
<Kamion> daniels: pong
<fabbione> sorry
<fabbione> Kamion: than wait before you start
<fabbione> Kamion: i will give you another diff on top of 17
<fabbione> Kamion: i fixed a couple of problems
<fabbione> (see above)
<Kamion> _rene_: dunno - you'd have to ask elmo/lamont whether lsb-release is installed on the buildds
<Kamion> lucas_: mmkay, that's a little complex, let me see
<_rene_> well, we build-dep on it, so ;-)
<_rene_> that's the control.in part ;)
<Kamion> _rene_: ah
<Kamion> lucas_: LOCALDEBS is probably what you want, certainly
<lucas_> Kamion: yes
<Kamion> lucas_: do you have tla installed?
<lucas_> Kamion: I tried to use apt-ftparchive to generate the packages and all
<fabbione> Kamion:
<fabbione> The following lines in the control files differ (wdiff output format):
<fabbione> ----------------------------------------------------------------------
<fabbione> Version: [-2.6.8.1-18-]  {+0.67ubuntu3+}
<fabbione> Section: [-devel-]  {+debian-installer+}
<fabbione> Maintainer: Debian [-kernel team <debian-kernel@lists.debian.org>-]  {+Install System Team <debian-boot@lists.debian.org>+}
<lucas_> Kamion: yes
<fabbione> Source: [-linux-source-2.6.8.1-]  {+linux-kernel-di-i386-2.6+}
<_rene_>   * debian/control.in:
<_rene_>     - add Builddep on lsb-release [RE] 
<_rene_>     - change kdelibs4-dev builddep to kdelibs4-dev | ubuntu-artwork to
<_rene_>       disable it for Ubuntu [RE] 
<_rene_>   * debian/rules:
<_rene_>     - use lsb_release -is to differentiate whether we build for Debian or
<fabbione> [ new ]  { old }
<_rene_>       Ubuntu and disable the KDE stuff when building on Ubuntu, thanks
<_rene_>       Matthias Klose for the lsb_release hint. Honour
<_rene_>       DEB_BUILD_OPTIONS=withkde to enable build with KDE on Ubuntu [RE] 
<_rene_> is the changelog entries
<Kamion> fabbione: you do need Section: debian-installer
<Kamion> fabbione: may have to change kernel-wedge to ensure that
<fabbione> Kamion: yes.. 
<fabbione> i was looking into it
<Kamion> fabbione: just add '$pkg{Section}'="debian-installer";' on line 154
<Kamion> fabbione: of commands/gen-control
<fabbione> ehhee
<Kamion> lucas_: tla register-archive http://people.ubuntulinux.org/~cjwatson/archives/colin.watson@canonical.com--2004
<fabbione> i was doing the same :-)
<jdub> _rene_: cool :)
<Kamion> lucas_: tla get colin.watson@canonical.com--2004/cdimage--mainline--0
<Kamion> lucas_: bin/update-local-indices may help you
<jdub> i have just uploaded the coolest 2.9 feature EVER
<jdub> gnome-user-share
<lucas_> Kamion: cool thanks a lot :)
<jdub> it makes me very horny
<Kamion> lucas_: except you'll need an apt-ftparchive.conf, hmm
<jdub> that is all
<lucas_> Kamion: I wrote one, but I'm not sure about it
<seb128> jdub: rock !
<fabbione> Kamion: do you want to upload kernel-wedge with it?
<daniels> FRIGGING HELL LIBAO
<Kamion> lucas_: http://cdimage.ubuntulinux.org/code/apt-ftparchive.conf is what I use
<jdub> seb128: it's *really* cool
<Kamion> lucas_: (I think the content-type's broken for that file, sorry)
<lucas_> it's ok
<Mithrandir> Kamion: text/plain is fine for that file?
<daniels> calc: libao is broken to hell, dude
<Kamion> fabbione: doing
<Kamion> Mithrandir: hm, strange, the last time I looked at it in w3m the line-wrap was broken, but now it's fine
* Kamion blames the mad w3m coders
<Mithrandir> Kamion: wget claims it's text/plain at least.
<lucas_> Kamion: btw, I'm documenting what I'm doing. no problem with the tla archive going public ?
<Kamion> lucas_: not at all
<Kamion> lucas_: I'm not sure what the licence ought to be on my code there; TBH there probably isn't an awful lot that's copyrightable anyway
<Kamion> but I'd have to check with Mark if you're creating derived works of it
<lucas_> ok
<lucas_> well I hope I won't have to modify it too much ; I'm not that interested in hacking debian-cd ;)
<Kamion> fabbione: 0.25ubuntu5 uploaded
<fabbione> Kamion: cool!
<Kamion> (and change committed to d-i svn)
<lamont> _rene_: Kamion: chroot build/chroot-hoary dpkg -l lsb-release
<lamont> No packages found matching lsb-release.
<lamont> it's not build-essential
<_rene_> but we build-depend on it anyway, so no problem ;-)
<jdub> elmo: ping
<elmo> jdub: ?
* lamont bbl
<jdub> elmo: can you kill g-u-s in NEW? i'm going to upload another one
<jdub> then could you let it through? :)
<fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/17_to_18.diff <- NEW with bug fixes
<fabbione> including the debian/control thing you mentioned yesterday
<elmo> rejected
<Kamion> fabbione: I'm still not going to have disk space to build it though ;)
<fabbione> Kamion: i guess i will have to simulate a multi kernel thingy here than
<fabbione> i need to verify that the archs with more than one kernel d-i set works
<Kamion> fabbione: like I suggested earlier, can you get an account on a box in the LAN to do this?
<Kamion> we must have a powerpc porting system
<jdub> $ dput ubuntu gnome-user-share_0.3-1_source.changes
<jdub> Already uploaded to upload.ubuntu.com
<jdub> Doing nothing for gnome-user-share_0.3-1_source.changes
<jdub> ^ wtf?
<elmo> rm g-u-s*.upload
<fabbione> Kamion: oh yeah... i didn't read the scrollback
* jdub growls at stupid stupids
<fabbione> Kamion: but i can simulate it locally
<jdub> elmo: thanks
<fabbione> no big deal ;)
<fabbione> on the other side.. i want to be 200% sure
<fabbione> elmo: what is the new ppc porting box?
<daniels> fabbione: davis
<fabbione> daniels: ok
<fabbione> elmo: can i get linux-source build-dep + kernel-wedge ?
<lupus_> jdub, wouldn't it be better if you open websites that they are openend in a new tab by default?
<fabbione> (version -4 is ok)
<fabbione> for kenrel-wedge
<jdub> lupus_: i think that's a good option for advanced users to enable
<lupus_> why advanced users?
<lupus_> if you give the new tab autofocus
<jdub> because they'll know their page opened in the other window in a tab, instead of popping up straight in front of them (as reasonably expected)
<elmo> fabbione: done
<fabbione> elmo: thanks!
<lupus_> if firefox is already open the current website is just changed, firefox doesn't get caption
<lupus_> and as I user I would wonder why my other page went
<jdub> not with the current default settings
<jdub> a new window is opened
<jdub> (unless we've had a reversion of those settings in hoary)
<jdub> (which is not unlikely)
<lupus_> ic sorry I have maybe some old settings lying around :p
<fabbione> Kamion: how much did you diverge linux-kernel-di from debian kernel-di ?
<Mithrandir> fabbione: how far from being debootstrappable is sparc?
<fabbione> Mithrandir: it will take a while still
<fabbione> Mithrandir: because i am building ubuntu on top of ubuntu
<fabbione> Mithrandir: but sparc64 kernels are ready
<fabbione> Mithrandir: i am going to drop sparc32 on the floor for now
<fabbione> if someone wants it, he will provide patches
<fabbione> theoretically i could upload the kernel in hoary
<fabbione> but since i have like 3 branches at the moment
<fabbione> i would prefer to go for one at a time
<fabbione> first udeb integration
<fabbione> 2.6.9
<fabbione> sparc integration
<fabbione> Mithrandir: i would say that i should be able to give you all the debs in a week or so
<fabbione> it's only question of time basically
<Mithrandir> fabbione: goodie.
<fabbione> + i am catching a bunch of FTBFS due to the xlibs split that we didn't notice in the first run
<fabbione> so that's even better
<Kamion> fabbione: debdiff, man :)
<fabbione> daniels: 4132
<Kamion> fabbione: a bit
<fabbione> Kamion: ?
<Kamion> fabbione: firmware, extra modules, etc.
<Kamion> fabbione: Debian uses linux-kernel-di-*, not kernel-di-*; using debdiff to see the differences is trivial
<fabbione> AHHH
<fabbione> ok
<fabbione> sure
<daniels> fabbione: eh?
<fabbione> daniels: #4132 <-
<daniels> yeah
<daniels> any specific reaosn why I won it?  or do you need it urgently or something?
<fabbione> daniels: because it's a FTBFS?
<elmo> whee, expect is FUBAR in hoary
<Kamion> pitti: isn't the LSB init stuff in lsb-base, not lsb-release?
<Kamion> pitti: (re your anacron changelog)
<lucas_> Kamion: tools/scanpackages generates errors when running apt-ftparchive :
<lucas_> E: Could not open file /space/ubuntu-custom/scratch/tmp/warty-i386/CD1/dists/warty/local/binary-i386/Packages.gz.new - open (2 No such file or directory)
<pitti> Kamion: indeed
<lucas_> E: Could not open file /space/ubuntu-custom/scratch/tmp/warty-i386/CD1/dists/warty/local/binary-i386/Packages.new - open (2 No such file or directory)
<lucas_> E: Error Processing directory dists/warty/local/binary-i386/
<pitti> Kamion: I copied that from another package
<pitti> Kamion: so there is at least one other faulty package
<Kamion> lucas_: might need to create those directories by hand
<pitti> Kamion: I'll fix it
<Kamion> pitti: ta
<Kamion> lucas_: er, not the directories under CD1, though
<lucas_> mmh
<Kamion> lucas_: actually FWIW I get the same error in the official builds, it's harmless as far as I know
<lucas_> ok
<lucas_> :-)
<Kamion> I should probably investigate it at some point
<lucas_> the script responsible for copying the Packages to CD1/ should create the dir
<lucas_> or they should be created before
<Kamion> well, not sure; local is weird in a few places
<Kamion> do you actually have anything in your local tree yet? the official builds (obviously) don't
<lucas_> I do
<lucas_> I rebuilt base-config
<Kamion> hm, ok, it used to work fine for us though
<lucas_> but debian-cd doesn't pick my local version
<Kamion> did you increase the version of base-config?
<lucas_> yup
<jdub> fabbione: do you recommend doing "libx11-dev | xlibs-dev, libice-dev | xlibs-dev" and so on, or just depending on xlibs-dev?
<fabbione> jdub: nothing should Build-Dep on xlibs-dev
<daniels> jdub: the former
<fabbione> you need to just use the real Build-Dep
<daniels> fabbione: makes backports hard oh shit 0% battery
<fabbione> libx11-dev, libice-dev, libdanielscrack-dev
<Kamion> lucas_: try 'tools/apt-selection cache show base-config'
* jdub is doing a debian-compatible deb :)
<fabbione> jdub: still...
<lucas_> correct version
<lucas_> but I think I understand
<Kamion> lucas_: your modified version?
<lucas_> I mkdir -p /space/ubuntu-custom/scratch/tmp/warty-i386/CD1/dists/warty/local/binary-i386/
<lucas_> then apt-ftparchive is able to generate the Packages on CD1
<daniels> jdub: you only want xlibs-dev if you want to be compatible with pre-4.3
<lucas_> so I just need to add the creation of this dir swhere in scanpackages
<Kamion> lucas_: the issue is that nothing post-install expects local to be there
<jdub> daniels: oh
<jdub> bugger that, then
<daniels> yes!
<lucas_> Kamion: it doesn't really matter for me
<Kamion> lucas_: so you can generate a CD that way, but base-config probably won't get installed
* fabbione would really like to see xlibs-dev vanishing
<Kamion> lucas_: yes, it does :-)
<lucas_> oh
<daniels> fabbione: and -static-dev, and -static-pic
<lucas_> so the best solution would be not to use local at all
<fabbione> daniels: these are a bit more hard to kill.. but yes
<Kamion> lucas_: you might find that easier
<Kamion> I guess I should try using local for something again to make sure it still works the way I remember
<lucas_> when apt-ftparchive finds 2 packages with the same name but different versions
<lucas_> I expect it only writes the newer one in Packages ?
<Kamion> lucas_: but really the only reason we have LOCAL turned on at all is that in the early days of Ubuntu development the archive wasn't quite usable for building installable CDs, but I had a few local hacks that made it more or less work so I used those temporarily
<Kamion> lucas_: right, should do
* lucas_ thinking...
<lucas_> ok, it should do the trick
<Kamion> I've just turned LOCAL off for our builds
<Kamion> let's see if it keeps working
<lucas_> it probably will
<lucas_> it WFM before I enabled LOCAL
<Kamion> fabbione: probably has to wait for a full Debian release cycle though; that's a *lot* of source packages to change
<Kamion> fabbione: xlibs-dev is really handy too
<Kamion> for users
<daniels> Kamion: i dislike the entire idea of xlibs*
<pitti> Kamion: stupid me...
<daniels> Kamion: (not a rhetorical question, largely because I don't know the answer) do we have a gnome-dev?
<pitti> Kamion: anacron does depend on lsb-base, I just made the error in the changelog
<fabbione> Kamion: yes i know.. :( but i plan to kill it in etch if Branden will allow me
<bob2> daniels: gnome-devel
<fabbione> Kamion: more than users.. we are talking about lazy maintainers
<fabbione> ;)
<daniels> hm
<Kamion> daniels: gnome-devel and gnome-core-devel, yeah
<daniels> well, yeah
<daniels> maybe we should keep xlibs-dev and make it illegal to b-d on them (make dpkg-source break)
<Kamion> fabbione: users are more important in the long run though
<daniels> either that or just rename it to x-libraries-devel
<daniels> -> users keep the metapackage to install, b-ds on xlibs-dev break and I get to go fix them all
<Kamion> I dislike the idea of creating a billion serious bugs just because you don't like a particular package
<Kamion> that's SO not fun
<fabbione> Kamion: it's not like it will happen in sarge
<Kamion> fabbione: so?
<fabbione> there is an entire release cycle to fix that
<Kamion> fabbione: I don't want everything to go to shit after sarge either
<Kamion> modifying that many packages is HARD
<Kamion> we did it for /usr/share/doc, and it truly sucked
<Kamion> it took two release cycles to get all the packages changed
<fabbione> Kamion: yes i understand that...
<Kamion> and it sucked up huge amounts of developer effort that was just a total waste of time
<Kamion> you're basically proposing deliberately wasting developer time
<jdub> fabbione: yeah man, stop punching me in the face!
<fabbione> not really.. i am proposing to kill a meta package that is there because maintainers are lazy to figure out their build-dep
<fabbione> i know it's not "nice"
<fabbione> but imho it's cleaner to know on what you really depend on
<fabbione> instead of just pulling a gazillion of libs for nothing
<Kamion> $ grep-dctrl -nsPackage -FBuild-Depends,Build-Depends-Indep xlibs-dev /var/lib/apt/lists/riva_debian_dists_unstable_main_source_Sources | wc -l
<Kamion> 795
<Kamion> I'm sorry but I don't think that's acceptable
<Kamion> you must have a transition plan
<smurfix> fabbione: the shlibdeps already tell that. Maybe we can use them to automate the transition.
<Kamion> and removing xlibs-dev and fixing everything up afterwards isn't one
<daniels> Kamion: fixing everything up before?
<fabbione> Kamion: xlibs-dev is already a transition to avoid breakage from X < 4.3
<Kamion> daniels: that would be less bad
<fabbione> so i think it will be time with X > 6.8 to shake the dust away
<elmo> I have to agree with kamion here - you're imposing a massive transition for aesthetics, not technical reasons and then trying to justify by blaming maintainers for being lazy
<Kamion> fabbione: it's obviously not a completed transition, because it's still being used
<Kamion> fabbione: realise that maintainers aren't AWARE that you think xlibs-dev is a lazy thing to use
<daniels> i think 'lazy' isn't the right justification
<daniels> having properly articulated b-ds is a win
<elmo> daniels: how?
<fabbione> Description: X Window System client library development files transitional package
<Kamion> although it is oldlibs - but I don't think it's been particularly widely announced, e.g. wishlist bugs on everything that b-ds on it
<fabbione> This transitional package is
<fabbione>  only depended upon by packages that haven't yet corrected their dependencies to
<fabbione>  reflect the new library arrangement.
<elmo> and how does this win counter-balance the massive transition effort involved?
<Kamion> fabbione: how about you go file the wishlists to move away from it now?
<elmo> fabbione: dude, I have packages that depend on X and have done for years - what makes you think I would have read that description since it changed?
<daniels> elmo: eh, I'd rather like people to know what they actually use
<elmo> daniels: how is that a technical win, dude
<fabbione> Kamion: it will make more sense immediatly after sarge and do it properly, once, with Xorg split
<Kamion> browser-history, certainly, I haven't uploaded that for ages
<elmo> don't hand wave.  give me cold, hard, technical benefits that don't involve aesthetics
<daniels> rather than just a rough sledgehammer 'oh right, so I'll install everything from the base authentication through to four toolkits'
<jdub> elmo: with the Big X Split coming up, it will matter more
<daniels> elmo: not dragging in 200MB of crap you don't need
<daniels> and yes
<elmo> jdub: why?
<jdub> elmo: (i'm not taking sides here, but that is a valid point)
<elmo> AFAIK xlibs-dev could still exist in a X split world, AFAICS
<daniels> yes, it could
<jdub> elmo: because those libs will be released separately
<Kamion> fabbione: and for all of this we have to figure out how to get the changes into testing, which takes a lot of time in the real world
<daniels> but it's just a craptastic idea imo
<fabbione> elmo: don't get me wrong.. i understand why xlibs-dev exists...
<daniels> elmo: your packages don't depend on X, BTW
<elmo> daniels: bzzt
<daniels> elmo: they likely depend on the general client-side X library, which is up for replacement
<Kamion> there's also random bits of documentation out there that say "to get X libraries on Debian, install xlibs-dev"; that documentation doesn't just go away
<elmo> I maintain a KDE-based package - I think that's likely to depend on X
<jdub> if you have to depend on a specific version, you'd have to switch or add a specific depends anyway
<daniels> elmo: 'depend on X' is handwavey random crap
<jdub> daniels: i don't get why gtk-dev doesn't have the right x dev depends
<daniels> jdub: it doesn't?
<jdub> no
<jdub> that just bit me with GUS
<fabbione> Kamion: X usually moves in one shot in testing..
<elmo> daniels: you know what I mean
<daniels> jdub: then it needs updating
<Kamion> fabbione: I'm not talking about X
<elmo> so basically, the only technical reason you guys have is "so we install less as build-depends" .. mmk
<daniels> elmo: yes, I assume you depend on the general X11 client-side library, which is up for replacement (thus chaining through to the X authorisation library), and you probably depend on the library that provides a few extensions
<Kamion> fabbione: I'm talking about nearly 800 other source packages, many of which will have fun interdependencies
<fabbione> Kamion: but i see the complexity.. i am just saying that xlibs-dev was is already a transitional package and that can be killed doing thing properly
<daniels> elmo: possibly the I Can't Believe It's Not IPC library
<fabbione> Kamion: yes.. i grok that
<jdub> elmo: when the big X split happens, the difference between the libs will matter
<daniels> elmo: but probably not all of four toolkits
<daniels> elmo: and whatever random crap was in 'xlibs'
<Kamion> fabbione: if the transition had been done properly I wouldn't be seeing nearly 800 build-deps in unstable right now
<jdub> elmo: you will be depending on different versions
<Kamion> (and that's only main)
<Kamion> jdub: surely if the versions are being allowed to get wildly out of sync you lose anyway
<jdub> elmo: up til now, it's always been one great big galumphing monolithic release
<jdub> Kamion: with x, no, because it's been api/abi stable for years anyway
<Kamion> jdub: if xlibs-dev depends on say x-dev and libx11-dev, how does it make any difference if you write out the build-dependencies separately?
<Kamion> jdub: metapackages and writing out build-deps separately are semantically identical
<jdub> Kamion: because you may need libx11-dev 56 and libice-dev 23
<daniels> elmo: this is what you are build-depping on --
<jdub> Kamion: and which package owns xlibs-dev in future? and which versions does it depend on?
<Kamion> jdub: uh-huh, so if you do you can say so
<fabbione> Kamion: i don't have enough historical backgroud to tell what was done to inform developers that xlibs-dev is a transitional package, so i cannot comment on it. On the otherside this doesn't not mean that things can be still done
<daniels> daniels@catsby:~/canonical/xorg/arch/source/xorg-6.8.1/build-tree/xc/lib% ls -ld * | wc -l && du -sh . | tail -1
<daniels> 64
<daniels> 701M    .
<Kamion> fabbione: right, but it means that dropping xlibs-dev for etch is a highly ambitious goal
<jdub> Kamion: so you end up switching anyway :)
<daniels> elmo: if you're unable to further articulate your build-deps, then I'm sorry, but that's just crap
<elmo> daniels: dude, grow the fuck up
<Kamion> jdub: sure, in the unlikely event that say browser-history needs to
<elmo> I'm not unable to articulate anything
<daniels> elmo: i understand that this is a change
<daniels> elmo: and that previously there was just xlibs
<jdub> daniels: the "you are lazy" reasoning doesn't help your case
<daniels> elmo: but what I'm trying to say here is that was *wrong*
<fabbione> Kamion: i never said it was going to be easy, did I? ;)
<daniels> agh
<daniels> elmo: not meant to imply that this is your fault or that you're lazy or whatever
<daniels> a non-specific, hand-wavey 'you'
<daniels> Kamion: (x-dev is an aberration anyway)
<elmo> daniels: sorry, but it doesn't matter whether you're accusing me or the n hundred maintains of being "lazy or whatever", all it's doing is convincing me you have only religious reasons for this
<Kamion> daniels: so ... what am I supposed to do to get X11/Xos.h and X11/Xatom.h?
<daniels> Kamion: the selection of files for x-dev is ... odd
<Kamion> daniels: this isn't particularly helping your case either you know :)
<daniels> Kamion: sort of randomly picked from whichever files didn't neatly fit into whichever categories were picked as a first glance
<daniels> Kamion: i know
<daniels> i'm just saying, that if I were designing it from the ground up right now, I know how I'd package it (largely because I already have packaged it, from the ground up)
<Kamion> if maintainers get the impression that X is going to randomly move files around between development packages, they're fully entitled to say "screw it, I'll just b-d on the metapackage and that'll work no matter what they rearrange"
<daniels> and that is not bundling 64 libraries with a 701MB build-tree into a single package
<daniels> and that the result is rather a horror and I'd like it to go away
<daniels> Kamion: understood.  that's why I would rather like to reorganise it sooner rather than later, and then come out with a transition document (or, hell, even a semi-automated 'this is what you probably need to do for package <foo>' generator) describing it
<Kamion> on the scale of 11 years of Debian development, and by comparison to say libc6-dev, X *does* randomly move files around, and expecting every maintainer to keep up with it when it's not clearly documented for them is a bit much
<fabbione> Kamion: usually it happens only on major releases
<fabbione> Kamion: but that's also an upstream decision
<smurfix> Kamion: so now's the chance, with the X split, to actually document it (and, dare I say, freeze the stuff...)
<fabbione> Kamion: like the last library split. it was not our decision
<daniels> Kamion: right now, it's so utterly random because at the time we were doing the split, neither Branden nor I had an idea of what most of them did or belonged
<Kamion> sure
<fabbione> Kamion: upstream changed a bunch of libs from static to shared...
<daniels> Kamion: i did part of the xlibs split, so I'm thus partially to blame for the current craptastic situation
<Kamion> I'm just saying that preserving build-dep compatibility *is* important
<Kamion> even (or especially) if it's your (collective) mistake
<daniels> Kamion: the xlibs-static-* stuff was upstream realising that saying the Xinerama API was 'too fluid for a shared library' was arse
<daniels> Kamion: understood
<daniels> Kamion: i'm just saying, i will be happy when no packages b-d on xlibs-dev
<fabbione> Kamion: i don't disagree.. but if some changes might require other maintainers to do some work, i am not going to ask the buildd to pull 200 libs because people can't change a line in debian/control
<fabbione> ^^missing: well.. they can move their butt and do it
<elmo> ARGH
<elmo> the buildd couldn't CARE LESS
<elmo> it has the 200 packages cached
<Kamion> I'm just wondering in what way you expect the release team to accept this
<elmo> the time-to-install is noise on the big scale
<elmo> please do not use that as an argument, it's total BS
<Kamion> it's entirely possible that britney might in the future decide to hold X out of testing until it stops breaking build-deps
<daniels> Kamion: neither of us are arguing to break B-Ds at the moment
<Kamion> since having britney enforce that sort of thing is high on the wishlist for post-sarge
<fabbione> elmo: i am not talking only about install time...
<elmo> so what else is left?
<elmo> removal time?
<elmo> as I said, on any Debian buildd, the 200  packages will be cached locally
<fabbione> elmo: space (s390), bw 
<elmo> s390 needs it's space fixed for other reasons - that's not an argument
<elmo> it's all virtual disks anyway
<Kamion> (like kde)
<daniels> elmo: should we merge x back into a single package, then?
<daniels> i just fundamentally fail to see how arbitrarily connecting a bunch of disconnected libraries can be a good thing
<elmo> daniels: nothing I said suggested that
<elmo> but it's a nice strawman
<daniels> xlibs-dev as a concept is fundamentally dead anyway
<fabbione> elmo: as soon as we reupload X and the packages needs to be refreshed.. you are starting from the beginning, but yeah.. we have resources
<daniels> given that no libraries added after 4.2.x have been added to xlibs-dev, it is no longer 'the clientside X libraries'
<daniels> given that two toolkits are in there, where the distinction was drawn in the first place is a mystery, anyway
<Kamion> fabbione: it amortises
<daniels> so right now it's just an arbitrary grouping of packages that is kept alive because of inertia
<Kamion> fabbione: as soon as one package fetches some set of libraries it's free for all the others
<fabbione> Kamion: yes.. i agree on that..
<fabbione> Kamion: but right now you pull 200 libs each time you ask fro xlibs-dev (and yes they get cached)
<daniels> the other point is that the X packaging is still horrifically broken
<Kamion> (I'm fixing most of my packages now; can't fix groff at the moment though)
<fabbione> Kamion: perhaps with a proper b-d there will be less than 10
<daniels> and the damage was only barely just started to be unravelled in 4.3.0, and mistakes were made along the way
<fabbione> Kamion: clearly these are just fake numbers
<fabbione> Kamion: but there is still a benefit, even if minimal
<Kamion> source: xfree86 only generates 26 -dev packages ;)
<fabbione> Kamion: check x.org
<fabbione> there must be a bunch more
<Kamion> fabbione: still not 200
<fabbione> <fabbione> Kamion: clearly these are just fake numbers
<Kamion> daniels: X is certainly allowed to unravel its mistakes, and that's a good thing
<fabbione> 200 was to give the idea
<Kamion> daniels: the point is that the rest of the distribution has to be allowed to catch up gradually, not in a flag day
<daniels> Kamion: absolutely, I agree with you here
<Kamion> daniels: if you guys agree on that, then we seem to be in agreement, except perhaps about what "gradually" means. :)
<daniels> Kamion: (also, bear in mind that my ideal world has ~70 library source packages)
<daniels> Kamion: rather violent agreement, it seems
<fabbione> Kamion: but none of us ever wrote "from one day to another"
<fabbione> at least.. if my short memory doesn't betrade me
<Kamion> fabbione: removing xlibs-dev before all its b-ds are fixed counts as a flag day
<daniels> Kamion: agreed
<fabbione> Kamion: neither i wrote to do it that way
<fabbione> i just expressed the whish to kill xlibs-dev
<fabbione> wish even
<fabbione>  fabbione would really like to see xlibs-dev vanishing
<Kamion> ok
<fabbione> that was all i wrote
<fabbione> in terms of future plans
<Kamion> I understood the stuff about etch to be "come hell or high water" :)
<fabbione> i didn't say to do it now or how
<Kamion> alright, sorry then :)
<fabbione> well clearly i would like to do it asap, but asap has a very large relative terms in debian
<daniels> Kamion: basically, I know how I would like X to be packaged, and that doesn't involve xlibs*
<fabbione> Kamion: don't be sorry.. i love to discuss
<fabbione> Kamion: and i like to hear different opinions on stuff
<fabbione> Kamion: other than daniels' one that we know are crap :P
<Kamion> still, has the bonus that I have a bunch of my packages to fix, some of which haven't seen an upload in two years
<fabbione> it's a good opportunity to refresh the timestime on the inodes :)
<fabbione> timestamps
* fabbione uploads another batch of sparc packages
<zul> morning
<elmo> I did a madison patch once that showed you the last upload time - I should resurrect it
<elmo> almost everyone I showed the output to for their packages went "oh, yeah, I forgot about <foo>"
<fabbione> libcaca <- i wonder who invented this name
<fabbione> literaly translated from italian is: libtakeashit
<Kamion> elmo: cool
<smurfix> elmo: sometimes that's actually a good thing ;-)
<smurfix> fabbione: what does it do?
<fabbione> smurfix: no idea
<smurfix> fabbione: hopefully something unrelated to its name ...
<daniels> oh wow, I still maintain dbtcp
<elmo> ^-- like that :P
<fabbione>  libcaca is the Colour AsCii Art library.
<stratus> fabbione, hah it doesn't sound good in portuguese too.
<daniels> elmo: hey, I don't have any bugs to my name in debian
<infinity> daniels : Only because you sneak around co-maintaining things, so the bugs accumulate on other addresses. :)
<infinity> (adconrad@debian.org doesn't have any open bugs either!)
<daniels> infinity: i don't see *you* fixing apache2 :P
<infinity> daniels : Yeah, yeah.  I'll get another upload in before I go on vacation.
<infinity> Maybe throw something in to shut up all the "I'm too stupid to set up SSL without handholding" whiners.
<infinity> I dunno.
<daniels> heh
<thom> heh
<daniels> 'morning thom
<fabbione> ihih
<elmo> if apache's SSL handling wasn't so insanely fragile it might garner less whiners :-P
<fabbione> hey thom
<fabbione> thoom: still jetlagging?
<daniels> elmo: dude, you should give 2.0.16 a shot
<daniels> elmo: those were they days where they sent out a different 100kB 'this might work, hey actually it bombs out on compile' SSL patch
<elmo> "WAH WAH, you omitted one section of the config file - I'm not going to tell you about it, I'm going to just break silently, hahaha, good luck.  p.s. don't try loglevel debug, it won't help, kthxbye"
<thom> elmo: well, i think they reasonably assume that someone wanting ssl on should have a cert attached to that vhost
<elmo> thom: I'm not arguing it shouldn't break, I'm arguing it should break BETTER
<thom> agreed
<infinity> More spectacularly, even.
<infinity> A lot of apache could do with being more verbose.
<infinity> Or differently verbose.
<infinity> Some of the error messages are a bit... Odd.
<fabbione> infinity: we can still add a "poweroff" if apache fails to start
<thom> some of them are just genius
<thom> but they've gotten better
<infinity> I love watching my requests randomly disappear into the ether too.
<thom> fabbione: and yes, my timezones are broken
<thom> infinity: did you ever play with that "dav eats my files" bug?
<infinity> thom : I looked atit a bit when it came in, but not since.
<infinity> thom : I was going to look at it again before the next upload.
<infinity> thom : The logic in there seems... Broken.
<jdub> thom: btw, what do you think about checking the "lock screen after X minutes" setting before locking on lid down?
<infinity> thom : If you follow it, it's definitely wrong.  I'm just undecided as to what the RIGHT behaviour is.
<thom> jdub: i think it should lock instantly
<infinity> thom : (Right now, if a move fails, it seems to want to cover its tracks by deleting... both copies..)
<thom> infinity: yes, that is very broken indeed
<jdub> thom: i'm thinking if you have that turned off, it shouldn't lock
<daniels> ah, the log stuff is shit
<seb128> jdub: what should we do about #3043 ?
<thom> jdub: bleah, maybe
<elmo> jdub: eww, please don't do that
<daniels> 'the directory you specified for one of your logs doesn't exist, so I'm going to bail now, and not even print a \n, because I'm such a hateful bastard'
<elmo> I want my laptop locked on resume
<daniels> infinity: !
<elmo> please at least me allow to specify that easily
<jdub> elmo: ideally, this would be power-management-user-policy stuff
<jdub> but for now, perhaps we should hook it to that preference
<infinity> jdub : A certain other OS that shall remain nameless makes a clear separation between "locking the screen" (ie: screensaver settings) and "lock on resume).
<thom> yeah, if that's turned off in xscreensaver settings, it makes sense
<jdub> elmo: it would work that way by default even with this change
<jdub> infinity: that's the ideal, yes.
<thom> daniels: yes, that's an RoUS special
<jdub> seb128: oh
<jdub> seb128: i think i have a viable bounty hunter/team for that
<daniels> thom: WOO!
<seb128> jdub: should I reassign it to you so ?
<jdub> seb128: yeah, thanks
<seb128> np, thank you :)
* infinity wanders off to bed after an evening of cleaning up kullervo.
<thom> g'night mate
<infinity> thom : G'night.
<daniels> infinity: night dude
<elmo> gar
<elmo> tcl 8.4.6-1 works, tcl 8.4.7-1 breaks
* fabbione sighs at ppc
<fabbione> still 2 and 1/2 kernels to build :(
<elmo> you should do amd64 instead
<elmo> still mutliple variants, but it'll build a bucket load faster
<fabbione> elmo: not for the udebs part
<Kamion> elmo: powerpc has the three sets of udebs
<fabbione> amd64 creates only one set of udebs
<elmo> ah I see
<fabbione> at this speed i will have time to integrate sparc too :-)
<fabbione> elmo: i have the kernels btw
<fabbione> i am doing another round of build to be 100% sure
<Matt|> daniels, there's a guy in ubuntu-it who has a problem with his touchpad and xfree, have you got a few minutes for him?
<daniels> Matt|: yeah, sure
<jdub> ok
<jdub> who's running hoary and i386 and wants to try some SEXY new gnome love?
<tseng> jdub: pick me, pick me!
<smurfix> jdub: ?
<Matt|> jdub, are you appealing for regular users?
<jdub> hell yeah
<tseng> hah.
<jdub> this is maximum SASS
<stratus> jdub, i! :)
<stratus> break my hoary!
<jdub> http://people.ubuntulinux.org/~jdub/gnome-user-share_0.3-2_i386.deb
<jdub> install that
<Matt|> daniels, thanks a lot, I've asked him to pm ya
<jdub> and run gnome-file-share-properties
<stratus> doing..
<Matt|> jdub, i'm running 686 kernel it is cool?
<jdub> then look in Computer > Network :-)
<daniels> Matt|: thanks
<Matt|> daniels, thank YOU
<jdub> Matt|: hrm?
<daniels> jdub: how come it's not in the archive?
<tseng> its going that way
<stratus> jdub: wait, it needs libhowl0, installing...
<jdub> daniels: g-u-s?
<stratus> *sigh*, apache2 and mdnsresponder?
<stratus> it needs to be really cool
<jdub> it is
<daniels> jdub: yeah
<daniels> jdub: you should upload it, dude
<jdub> daniels: you're fixing why it doesn't build right now, aren't you? :)
<zul> jdub, what is it?
<Matt|> jdub, too many dependencies for me
<stratus> still installing...
<jdub> Matt|: it's not...
<daniels> jdub: yeah :)
<Matt|> jdub, apache2?
<jdub> zul: user level zeroconf/webdav file sharing for gnome
<jdub> Matt|: just update-rc.d -f apache2 remove after you've installed it
<stratus> hey jdub
<stratus> is libhowl0 >= 0.9.8-1 around?
<jdub> in hoary, yes
<jdub> this is a hoary package
<jdub> for testing and so on
<stratus> updating packages now...
<zul> jdub, its installed
<smurfix> jdub: Syntax error on line 39 of /usr/share/gnome-user-share/dav_user.conf: Invalid command 'MinSpareServers', perhaps mis-spelled [...] 
<jdub> smurfix: aha, which mpm do you have installed?
<smurfix> jdub: sh
<tseng> works for me
<tseng> except, we still dont have howl in gnome-vfs?
<smurfix> jdub: should grey out the password when it's "never" too
<jdub> smurfix: yeah
<jdub> tseng: yeah, we do
<smurfix> jdub: the wrong one ;-)  -- apache2-mpm-worker
<tseng> jdub: i dont see myself in network
<thom> um, worker is the default? :-)
<jdub> it should work with worker
<pitti> Kamion: I'm currently merging the new udev 0.046, we need it for several reasons
<jdub> hrm, i have prefork
<pitti> Kamion: I merged all changes but some details of the udeb creation
<smurfix> jdub: should, but apparently doesn't
* jdub checks
<stratus> I see the same error message about dav_user.conf
<pitti> Kamion: the new udev Debian package already has provisions for building the udeb, however, some files are missing that you ship with 0.042
<jdub> smurfix: yeah
<jdub> okay dudes, install apache2-mpm-prefork
<pitti> Kamion: could you take a look at it and finish the merge?
<jdub> i'll figure out how to get it working with the other ones
<daniels> libapache2-mod-dav, innit?
<stratus> jdub, ok
<jdub> daniels: a) it's not separate anymore, b) to run apache, you need an apache server :)
<smurfix> jdub: I saw that error after running gnome-file-share-properties -- it should have appeared at install time too
<jdub> smurfix: nah, it shouldn't have
<stratus> smurfix, the same here.
<daniels> jdub: well, yeah, heh
<tseng> jdub: works!
<jdub> alternatively, you can comment the two *Spare* lines in dav_user.conf
<fabbione> gordian:/var/lib/dpkg/info# for i in `ls *-dev.*`; do grep ldconfig $i; done
<fabbione> gordian:/var/lib/dpkg/info# 
* daniels chortles.
<fabbione> daniels: nobody calls ldconfig in -dev
<daniels> why not just grep ldconfig *-dev.* ?
<jdub> tseng: got computer > network love?
<fabbione> grep ldconfig *-dev.*
<fabbione> gordian:/var/lib/dpkg/info# 
<tseng> jdub: indeed.
<fabbione> daniels: better now?
<jdub> sexy, huh? :)
<tseng> jdub: using perfork
<tseng> hot as hell
<tseng> and not buggly like eppitance
<jdub> heh
<daniels> fabbione: i wasn't saying the results were wrong, just a wasteful method
<mvo_> jdub: what is the future for gamin (the fam replacement)? will it stay or is that a dependencies that gnome would like to drop long-term?
<jdub> hooray for reusing code from leading free software projects :)
<daniels> anyway, I do not see how what we have can even possibly work
<jdub> mvo_: it'll stay
<daniels> elmo: would really love your input on this, please
<mvo_> so I can safly use it in the update notifier tray icon?
<jdub> yes, that's a great idea
<jdub> mvo_: gamin is binary compat with a subset of fam, so it should work with either
<stratus> jdub, but huh what's up with that default password?
<mvo_> jdub: great, thanks :)
<daniels> Any package installing shared libraries in one of the default library directories of the dynamic linker (which are currently /usr/lib and /lib) or a directory that is listed in /etc/ld.so.conf[42]  must use ldconfig to update the shared library system.
<jdub> stratus: there is no default password, is there?
<tseng> ya there is.
<Kamion> pitti: sure, Md and I were talking about that
<stratus> jdub, i see four asterisk when running 'gnome-file-share-properties' at password field
<stratus> smurfix, don't you?
<pitti> Kamion: http://people.ubuntu.com/~pitti/udev/
<smurfix> stratus: same here
<stratus> jdub, :)
<pitti> Kamion: it contains the current status of the merge and the Ubuntu diffs that I did not yet merge (udeb-relevant)
<jdub> stratus: you'll always see four asterisks
<jdub> stratus: however long your password is
<elmo> daniels: say what?
<jdub> stratus: determine the length of the password as stored in ~/.gnome2/user-share/passwd
<stratus> jdub, but i didn't write nothing i just started g-f-s-p
<daniels> elmo: ok, so here's the scenario
<daniels> libx11-6 installed, along with libX11.so.6 and libX11.so.6.2
<daniels> calls ldconfig in postinst
<jdub> stratus: even if the passwd is zero length, you will see four asterisks
<daniels> -> libX11.so.6 registered with ld
<daniels> --later--
<daniels> libx11-dev installed, with libX11.so
<daniels> ldconfig not called in postinst
<stratus> jdub, oh my failure.
<daniels> would ldconfig need to be called there, to register libX11.so?  or is there something I'm missing?
<elmo> daniels: you're breaking my mind.  you mean ld.so right?
<elmo> ld(1) is very different
<daniels> elmo: never mind me
<daniels> elmo: i blame keybuk
<Kamion> pitti: the first two hunks can be dropped
<pitti> Kamion: indeed, these work fine
<pitti> Kamion: however, the Debian udeb does not ship many files the Ubuntu one does
<Kamion> pitti: yeah, I know, I'm looking at those
<fabbione> elmo: dpkg-deb: building package `linux-image-2.6.8.1-3-sparc64-smp' in `../linux-image-2.6.8.1-3-sparc64-smp_2.6.8.1-17.1_sparc.deb'.
<fabbione> that's all for you :P
<pitti> Kamion: I don't think we need all of the remaining files, that's why I did not just take the Ubuntu version
<thom> fabbione: my sparc wouldn't boot 2.6 last i tried :/
<fabbione> thom: we will see later 2.4 support
<fabbione> thom: right now i had to drop sparc32 too
<thom> ahr
<fabbione> because i really don't have one to test on
<fabbione> and kernel needs love on sparc32
<fabbione> sparc64 gets enough
<fabbione> thom: don't you have an u30?
<Kamion> pitti: indeed
<thom> u10
<Kamion> pitti: could you add links.conf to /etc/udev? I'm not absolutely sure about it but I'm not comfortable with leaving it out yet
<fabbione> thom: did you try debian kernels or custom kernels?
<jdub> tseng: at the bottom of your dav_user.conf, put:
<pitti> Kamion: sure
<jdub> <IfModule prefork.c>
<jdub> MinSpareServers 1
<jdub> MaxSpareServers 1
<jdub> MaxClients 3
<jdub> </IfModule>
<jdub> 
<jdub> :-)
* jdub is doing that in the next release
<Kamion> pitti: can you drop that udev.startup thing from debian/rules too? I'll talk to Md about that; rootskel must be able to control d-i's startup, and /lib/debian-installer-startup.d is not a published interface for random packages to use
<tseng> ok.
<jdub> now it should build too
<Kamion> pitti: (at least, not yet)
<jdub> /bin/dd if /proc/kmsg of /var/run/klogd/kmsg <- fear ;)
<thom> fabbione: debian
<Kamion> pitti: other than that I *think* it's ok
<pitti> jdub: I know, it's a hack, but it works :-)
<Kamion> pitti: actually, hmm
<Kamion> pitti: yes, never mind me, should be fine, might have to change rootskel slightly
<pitti> Kamion: so the important things are only links.conf and the dropping of udev.startup?
<Kamion> pitti: in fact, I misread the diff, links.conf is still there
<jdub> lamont: please kick gus :)
<smurfix> jdub: Hmmm, so what do I (or anyone else for that matter) need to get Nautilus to show the public folders? I'll freely admit that I've not played with zeroconf stuff before.
<Kamion> pitti: so just drop /lib/debian-installer-startup.d/S02udev, please, rest should be fine
<pitti> Kamion: okay thanks
<jdub> smurfix: nautilus uses gnome-vfs's howl stuff
<pitti> Kamion: pure curiosity, has d-i a something similar like /etc/init.d/?
<jdub> smurfix: so it should just appear in Computer > Network
<pitti> Kamion: this symlink looks like sysvinit-style
<jdub> smurfix: you've run gnome-file-share-properties, and verified that gnome-user-share (and apache) are running?
<Kamion> pitti: kinda sorta
<elmo> I wish there was a way to do opportunistic gdb-ing or strace-ing, i.e. say "next time something called 'expect' starts, attach to it"
<jdub> elmo: obviously you want dtrace.
<Kamion> pitti: in fact, Md's startup script will break d-i because he didn't know how it worked ... whoopsie
<pitti> Kamion: so this _is_ relevant for Debian, too
<pitti> Kamion: well, the Debian version currently disables it anyway
<jdub> smurfix: not working?
<Kamion> pitti: ... actually maybe not, he installs it executable so it'll get executed not sourced
<smurfix> jdub: not so fast :-/
<Kamion> pitti: I'm still uncomfortable with /lib/debian-installer-startup.d not being entirely controlled by rootskel
<Kamion> pitti: doesn't matter for Debian yet because Debian won't be using udev for a little while yet
<smurfix> I'm typing with one hand
<jdub> TMI
<pitti> Kamion: if I understood that correctly, witht the current version udev would be started twice?
<pitti> Kamion: once by rootskel, another time by this S02udev?
<smurfix> jdub: it's temporary ...
<eruin> what's been happening to gdesklets recently? it's more broken than what I'd be after a 90kph car-to-brick-wall-crash
<Kamion> pitti: no ... rootskel already ships S02udev, so they'd clash and have to be resolved somehow anyway
<pitti> eek
<pitti> Kamion: okay, thanks for your help!
<smurfix> jdub: Not seeing it on the desktop (which is the one publishing), or from the MacOS-X laptop. My ubuntu laptop's busy updating to Hoary at the moment.
<Kamion> pitti: as it happens udev's would win because the initrd udebs get unpacked in alphabetical order
<jdub> smurfix: install howl-utils to do some testing for me :)
<pitti> Kamion: "r"ootskel > "u"dev ???
<pitti> not in my alphabet...
<pitti> Kamion: anyway, I removed it
<smurfix> jdub: done
<jdub> smurfix: type this:
<jdub> mDNSBrowse _webdav._tcp
<Kamion> pitti: udev's would win; it gets unpacked second and therefore overwrites
<smurfix> jdub: sitting there, not doing much
<pitti> Kamion: ah, I see. I thought it would be similar to dpkg where it just refuses to overwrite something
<jdub> smurfix: hrm
<smurfix> (mDNSBrowse, not me)
<jdub> smurfix: and mdnsresponder is running?
<Kamion> pitti: we use 'dpkg -x'
<smurfix> jdub: 20205 ?        Ssl    0:00 /usr/sbin/mDNSResponder -f /etc/mdnsresponder/mDNSResponder.conf
<smurfix> strace shows that it did respond to the browser's first packet
<Kamion> pitti: actually, no, we don't, we use dpkg --unpack, but we also use --force-overwrite
<pitti> ah
<pitti> Kamion: why overwrite? Did this already occur on several other udebs?
<Kamion> pitti: yes
<Kamion> pitti: busybox-cvs-udeb and module-init-tools-udeb for a start
<pitti> ugh, sounds like gambling
<Kamion> sure, but there are some battles not worth fighting
<pitti> I removed the script and the directory, I upload now. Let it break... :-)
<Kamion> ok, I'll upload rootskel to match
<Kamion> thanks
<pitti> thanks to you too
<pitti> Kamion: this version fixes several important errors, that's why I'm eager to get it :-)
<smurfix> jdub: I just restarted the mdnsresponder with -d; mdnsbrowse now reports ...
<smurfix> jdub: browse reply: Add Service 0x2 smurf's public files _webdav._tcp. local.
<Kamion> Keybuk: are targets like 'install-libLTLIBRARIES' considered internal? i.e. can I use them from debian/rules?
<smurfix> jdub: resolve reply: 0x2 smurf's public files _webdav._tcp. local. 192.109.102.35 53848
<smurfix> jdub: ... but still doesn't return.
<smurfix> ah, restarting Nautilus worked.
<smurfix> jdub: that shouldn't be necessary.
<thom> jdub: worth thinking about adding a "Branding" keyword to bugzilla?
<smurfix> jdub: now I'd please like to rename that shared folder.  ;-)
<jdub> "no." :)
<smurfix> jdub: "Duh, I'll keep using MacOS then, it works there."  :-)
<thom> jdub: um, to which :P
<jdub> thom: not you - on phone
<thom> ahr
<smurfix> jdub: Interestingly the webdav share can be seen but not mounted from OSX. Not sure yet why.
<jdub> knownish bug :)
<smurfix> jdub: I take that to mean that you don't yet know why ..?
<Keybuk> Kamion: very internal
<Kamion> Keybuk: guess I just have to install and then remove everything but the library, then ...
<RubenV> patched laptop-mode for LSB
<RubenV> patch is in bugzilla
<RubenV> my boot is now almost clean :)
<thom> can you attach the patch to #1580
<thom> since that's the canonical bug
<RubenV> ah, great :)
<RubenV> didn't knew that one
<RubenV> there's also an alsa one from me somewhere
<RubenV> i'll put it in 1580 too
<thom> great
<RubenV> voila
<jdub> ok, back
<jdub> thom: branding would be handy for me, yeah
<jdub> thom: or you can just reassign viciously :)
<jdub> smurfix: no, not known why
<jdub> http://people.ubuntulinux.org/~lamont/buildLogs/g/gnome-user-share/0.3-3/
<jdub> hoo-ray
<smurfix> jdub: Apparently the stupid thing produces neither network traffic nor log file entries when it does that. :-(
<stratus> humm news about gnome-user-share?
<smurfix> stratus: it worked here after I restarted nautilus.
<stratus> smurfix, it worked here before my lunch but i was asking about others mpm.
<jdub> stratus: the updated packge should be in hoary by now
<stratus> jdub, thanks i was lunching sorry for the noise.
<smurfix> stratus: then you should ask more specific questions. ;-)
<jdub> smurfix: which 'stupid thing'?
<smurfix> jdub: The MacOS laptop. "It doesn't work" error messages are sub-standard.
<smurfix> It seems that Apple does its own zeroconf file sharing with AFP, not WebDAV. I don't feel any particular urge sto start hacking netatalk.
<zul> no?
<zul> :)
<smurfix> zul: The day has only so many weeks. :-/
<zul> heh...i wouldnt either :)
<smurfix> Is there a way to mount a WebDAV file system?
<jdub> with hacky stuff like FUSE
<smurfix> Well, that does seem to be on its way into the official kernel.
<smurfix> It's just differently hacky than something that exists only in gnome.' 
<daniels> not really
<daniels> gnome has its own vfs stuff
<daniels> fuse is kinda handwavey there-is-no-standard-file-interface-because-I-just-replaced-it
<daniels> these are entirely separate ideas
<smurfix> daniels: I know they're separate ideas, that's kind of my point.
<smurfix> File system contents should be visible to all programs, not just those which happen to have a gnome GUI.
<daniels> mmmmm
<daniels> try this:
<jdub> s/have a gnome GUI/use gnome-vfs/
<smurfix> right
<daniels> write a WebDAV server which sends 'Connection: keep-alive' unconditionally (because you wrote a buggy test)
<daniels> sorry, Connection: close, unconditionally
<daniels> then have it assume it's doing keep-alive, and keep the connection open forever
<daniels> mount any volume from this WebDAV server on a Mac OS X machine
<daniels> double-click on the volume, and watch Finder lock up solid
<daniels> drag it over to the Dock to eject it, and watch the Dock lock up solid
<daniels> watch anything that attempts to do file IO lock up solid
<daniels> swear and reset your machine
<daniels> i assure you, there are some *serious* issues with moving stuff like WebDAV down into the kernel
<smurfix> daniels: FUSE isn't exactly doing WebDAV in the kernel.
<daniels> understood, but the problem space isn't quite as simple as you make it out to be
<daniels> i know, because I spent three or so days in a mount/reset cycle on the OS X machine
<daniels> (afaik, the problem still isn't fixed)
<smurfix> never said it was, it's just a *different* problem space, one I personally prefer.  ;-)
<smurfix> Anyway, Apple certainly could do a lot better in that area. They still can't keep NFS mounts over wireless networks stable. If the IP address doesn't change, that's not supposed to be difficult to do.
<elmo> seb128: ping WRT libzvt?
<seb128> elmo: oh yes, I've forgotten this one. We don't need it in main
<elmo> seb128: thanks
<seb128> np
<chrisa> jesus
<chrisa> I was so confused when the postwoman handed me a box of packages
<chrisa> Turns out they're all Ubuntu cds
<bob2> haha
<daniels> ordering lots of CDs tends to have that effect, yeah
<Matt|> *laughs*
<smurfix> chrisa: so how many did you order?
<chrisa> smurfix: 200 for the oss group / lug
<chrisa> and to also throw in random places on campus
* smurfix doesn't quite know whether 'order' is the right word when they're free
<Matt|> where are the cd's shipping from?
<smurfix> cool
<chrisa> No return address on the envelopes, no idea
<Kamion> I use "request"
<smurfix> Kamion: thanks, that's better
<fabbione> Kamion: good that we did the ppc and that i integrated sparc :-)
<fabbione> Kamion: i spotted 2 errors in one line :-)
<chrisa> Neat, these have a live cd and install cd, as well as directions on them
<Kamion> fabbione: heh
<fabbione> Kamion: -18 will have sparc + udebs for i386/ppc/amd64/sparc
<fabbione> Kamion: rocking :-)
<fabbione> lamont: do you have anything from ia64? (kernel wise)
<lamont> fabbione: not personally, no.
<fabbione> lamont: what about t-bone?
<fabbione>         install -D -m 644 debian/d-i-powerpc/boot/vmlinux-2.6.8.1-3-powerpc debian/kernel-image-2.6.8.1-3-powerpc-di/boot/vmlinux
<fabbione>         install -D -m 644 debian/d-i-powerpc/boot/vmlinux-2.6.8.1-3-power3 debian/kernel-image-2.6.8.1-3-power3-di/boot/vmlinux
<fabbione>         install -D -m 644 debian/d-i-powerpc/boot/vmlinux-2.6.8.1-3-power4 debian/kernel-image-2.6.8.1-3-power4-di/boot/vmlinux
<fabbione> Kamion: i guess we are rocking :-)
<lamont> fabbione: t-bone would be the one to ask
<lamont> and/or dannf, but that's probably a monday thing
<fabbione> lamont: ok.. i guess ia64 can wait :-)
<fabbione> yeah
<fabbione> Kamion: if you want to login on davis and take a look in my home...
<fabbione> Kamion: you are more used than me watching ppc udebs (at least in terms of numbers/names)
* fabbione goes to get some dinner
<fabbione> later
<Kamion> fabbione: don't think I have an account
<fabbione> Kamion: afaik everybody does
<fabbione> on porting machines
<fabbione> and daves is one of them
<fabbione> anyway.. food
<Kamion> my ssh key doesn't seem to work, and the password I think I remember doesn't work either
<Kamion> elmo: ?
<daniels> er, IIRC it's a specific thing
<daniels> i didn't have access to the port boxes until I asked
<daniels> Kamion: if you want me to pull specific things out, let me know
<elmo> yes, port stuff is on request
<daniels> or, even better, just ask elmo
<elmo> Kamion: do you need an account or just the files?
<zopi> hi
<zopi> where I can find kernel-headers for unbuntu ?
<tseng> apt-cache search kernel-headers
<zopi> there is linux-kernel-headers but nothing in /usr/src
<zopi> already done
<zopi> there is none matching the kernel
<zopi> 2.6.8.1-3 
<zopi> even using universe repository
<Matt|> zopi, are you talking about linux-headers?
<thom> #ubuntu for support questions, please. (you want linux-headers)
<zopi> no
<lamont>  /bin/sh: ps: command not found
<lamont> hehe
<zopi> kernel-headers
<Matt|> zopi, #ubuntu
<zopi> ok
<zopi> sorry so
<zopi> Does it plan to add rescue mode on CD for the next release ? 
<lamont> zopi: #ubuntu is the right place for that.  this is the right place to discuss your patch that implements it
<Matt|> *laughs*
<zopi> ok :)
<zopi> lol
<Kamion> elmo: just the files is fine
* lamont gags on isdnutils build log
<Kamion> zopi: rescue mode> maybe; I'd like it to exist but there is absolutely no code for that available for our installer as far as I know, so it'd be an interesting development project for somebody
<zopi> just to boot
<zopi> just like this rescue root=/dev/hd**
<Kamion> yes, I know what you're referring to
<zopi> ok :)
<zopi> Kamion : and the code from Debian Woody ?
<elmo> Kamion: rookery:~james/davis
<Kamion> the trick is managing to make that work without requiring a big monolithic kernel
<lamont> Kamion: I thought that's what alt-f2 was for... :-)
<Kamion> zopi: code from woody is inapplicable because we totally rewrote the installer for sarge (and hence warty)
<Kamion> elmo: thanks
<zopi> Kamion : ah ok
* lamont wonders if maybe debian-policy should move into main...
<zul> why?
<Kamion> zul: our own packaging policies are likely to be pretty similar
<Kamion> fabbione: I haven't looked through all the udebs, but those look OK to me
<zul> i c..so why not rename it to ubuntu-policy?
<lamont> Kamion: in fact, if ubuntu-policy does differ from debian-policy, it'd be nice if it was just a list of changes from debian policy, since it shouldn't vary _that_ much
<Kamion> fabbione: with the exception of Section: devel => debian-installer, but I think you were using the previous version of kernel-wedge?
<Kamion> zul: varies; we haven't renamed debian-installer for instance (and I'd be against doing so - the upstream name is "debian-installer", renaming it arrogates too much credit to ourselves)
<seb128> daniels: here ?
<Kamion> zul: ubuntu-policy might be a different case, I suppose; it might depend on how much we changed or whether we just took d-p verbatim
<zul> Kamion, truebut at what point would that be
<Kamion> not sure
<zul> you might need 2 debs...not sure either
<lamont> but speaking of policy... what's the official way to add a service to /etc/services?
<lamont> because this sure isn't it (in Makefile...):
<lamont>                 @(grep isdnlog $(SERVICEFILE) >/dev/null) || \
<lamont>                 (echo "";echo "";echo "Add a line to the file $(SERVICEFILE)" ;echo "";echo ""; \
<lamont>                 echo "isdnlog $(SERV_PORT)/tcp        isdnlog" >> $(SERVICEFILE))
<daniels> seb128: sup
<Kamion> lamont: you get the netbase maintainer to add it
<Kamion> lamont: that code's so wrong it's not true
<Kamion> lamont: isdnlog's already in netbase's copy of /etc/services though
<Kamion> http://people.ubuntulinux.org/~lamont/buildLogs/d/debian-installer/20041118ubuntu4/debian-installer_20041118ubuntu4_20041126-1806-i386-failed - crap
<seb128> daniels: do you if this is supposed to work ? "echo "Xcursor.size: 20" | xrdb -merge -"
<seb128> +know
<daniels> seb128: should do, but I don't know if you have to do specific known sizes like 32/64
<daniels> seb128: also, you might need to do it before you start everything -- dunno that you can change it on the fly, but worth a shot
<seb128> daniels: ok, because GNOME do this (with known size) to change between small/medium/big cursors and that doesn't work here
<lamont> Kamion: doesn't seem to be in the hoary chroot's services, thouhg
<lamont> Kamion: that'd be because /etc/services isn't there
<Kamion> lamont: ah, no netbase
<lamont> yeah, adding that too.
<Kamion> I guess b-ding on netbase would be wrong? :)
<lamont> don't see why not.
<Kamion> lamont: netbase's postinst runs /etc/init.d/networking though ...?
<lamont> ah, yes. that might be bad...
<lamont> install phase finished...
<lamont> Kamion: so how do I get those perl bitches about locale to go away without installing locales in the chroot, and leaving the locale in place outside the chroot???
<lamont> is it as simple as stuffing LANG=C somewhere?
<elmo> lamont: empty /etc/environment
<seb128> daniels: ok, changing the cursor theme works but the size (12/24/36) doesn't
<Kamion> or LANG=C before sbuild
<elmo> the machines don't have locales installed - /etc/environment should be updated to match
<Kamion> true
<Kamion> keep forgetting you mean /etc/environment outside the chroots
<lamont> elmo: doesn't work for me.
<Kamion> lamont: you'd have to restart the buildd, it'll already have LANG=whatever surely?
<lamont> or you mean outside the chroot?
<elmo> lamont: on which machine?
<lamont> my machine
<elmo> yes, in base
<elmo> and restart the buildd
<lamont> doesn't that break me using a locale?
<Kamion> lamont: on your own machine, just LC_ALL=C before building
<elmo> oh, well, if it's not your machines, go with what kamion said
<elmo> s/not//
<Kamion> (LC_ALL in case you've set LC_FOO by hand)
<lamont> elmo: any objection to sbuid just forcing LANG=C into the environment?
<lamont> LANG= seemed to work...
<Kamion> if you're going to use something as an override it should be LC_ALL=C
<elmo> lamont: no, I suppose not
<lamont> I'm more inclined to teach buildd to inject something into the environment from buildd.conf
<Kamion> I. HATE. MKLIBS.
<lamont> Kamion: LC_ALL doesn't change LANG... is that gonna bite me?
<Kamion> no
<Kamion> type 'LC_ALL=C locale'
<Kamion> oh, true, that shows LANG=en_GB.UTF-8 for me; but nothing checks that
<lamont> ah, ok
* lamont bemoans his lack of perl literacy...
<lamont> given %ENV and %ENVOVERRIDES, how do I get all of %ENVOVERRIDES into %ENV?
<Kamion> lamont: perl (and pretty much everything else that cares about this kind of stuff) does setlocale(LC_ALL, "")
<lamont> perl: warning: Falling back to the standard locale ("C").
<Kamion> lamont: $ENVOVERRIDES{$_} = $ENV{$_} for keys %ENV;
<lamont> actually, looks like 'C'
<Kamion> #ifdef LC_ALL
<Kamion>     if (! setlocale(LC_ALL, ""))
<Kamion>         setlocale_failure = TRUE;
<Kamion> #endif /* LC_ALL */
<lamont> Kamion: actually the other way around, yes?
<Kamion> lamont: oh, yeah, right
<Kamion> $ENV{$_} = $ENVOVERRIDES{$_} for keys %ENV;
<Kamion> bah, keys %ENVOVERRIDES
<lamont> yeah - that falls so trippingly off the fingers, doesn't it...
<fabbione> seb128: you around?
<lamont> Kamion: it doesn't like me... dammit
<lamont> env changes aren't making it into child processes
<Kamion> %ENV is definitely exported (in shell terminology) by perl
<lamont> yeah, well...
<Kamion> I suspect a child process is resetting it
<lamont> to what it was _outside_ the chroot?
<Kamion> check exactly what %ENV looks like, too
<Kamion> perl -d rocks
<Kamion> is there an /etc/environment inside the chroot?
<lamont> emtpy
<lamont> but present
<mdz> morning
<Kamion> hi mdz
<fabbione> hey mdz
<zul> hey mdz
<lamont> Kamion: that assuems that one knows what to do wiht perl -d.....
<lamont> morning mdz
<Kamion> lamont: type 'n' or 's' gdb-style at it until one gets to the line one's interested in, then 'x %ENV'
* mdz watches the number of user processes running as root fall under pitti's axe
<mdz> anyone seen amu lately?
<Kamion> yeah, he was around on #canonical just an hour or two ago
<zul> is anyone working on selinux support?
<Kamion> not among Canonical folks, dunno about anyone else
<zul> i wouldnt mind taking a shot at it though
<fabbione> mdz: http://people.ubuntulinux.org/~fabbione/changelog
<fabbione> mdz: doing the last test now
<fabbione> mdz: but that's basically what i would like to go for -18
* lamont gets dragged off to family stuff
<mdz> zul: consensus is that rather than disrupt mainline development, it should be done in a derivative branch, and then merged in when it's reasonably stable
<Kamion> lamont: please make debian-installer dep-wait on pciutils-udeb (>= 2.1.11-15ubuntu3)
<Kamion> lamont: that is, assuming you can dep-wait on udebs (can you?); if not, the corresponding source
<lamont> which source?
<Kamion> pciutils
<zul> mdz: sure no problem..once i have something i can put patches into the bugzilla cant i?
<lamont> Kamion: d-i is PaS'ed on ia64?  or is the ia64 box just slow I wonder... Anyway, the 3 architectures you care about are d-w./
<zul> mdz: nm...im not thinking
<mdz> zul: certainly.  also, we'll be doing a lot of work to make it easier to work on derivatives, which we'll talk about in Spain
<Kamion> lamont: ta
<Kamion> lamont: won't work yet on ia64 anyway ...
<Kamion> lamont: (lack of kernels)
<lamont> right
<zul> mdz: heh...i wish i could go to spain :)
* lamont really really really runs
<lamont> bbl
<fabbione> hmmmm
<fabbione> pool/universe/x/xcompmgr/xcompmgr_1.1.1+cvs.20041109-0ubuntu2_i386.deb
* fabbione scratches his head
<fabbione> mdz: do you know why it has been moved to universe?
<fabbione> or anybody?
<mdz> fabbione: moved? was it in main previously?
<fabbione> yes
<mdz> the two things which control that are seeds and dependencies
<mdz> if it's not in a seed, and isn't depended on by anything in main, it'll go into universe
<fabbione> they are xclients.. so nothing depends on it
<fabbione> (together with fdclock and transset
<fabbione> )
<fabbione> ok
<fabbione> we might want to add them to a seed than
<fabbione> but i will give daniels a remider 
<fabbione> brb
<Kamion> mdz: which reminds me; did you see my question about pciutils-udeb and usbutils-udeb?
<elmo> fabbione: daniels and jdub discussed it yesterday
<Kamion> 2004-11-25 11:53:03 GMT Daniel Stone <daniel.stone@canonical.com>       patch-31
<Kamion>     Summary:
<Kamion>       fdclock/xcompmgr/transset -> universe, per jdub
<Kamion> mdz: I've created all the udebs now, just need to seed them and add the necessary support to hw-detect
<mdz> Kamion: no, I don't think I did
<mdz> my cablemodem shat itself for about 12 hours yesterday while i was out, so I didn't have scrollback
<Kamion> 20:48 < Kamion> mdz: oh, do you mind if I add pciutils-udeb, usbutils-udeb, and libusb-0.1-udeb? I need pci.ids and usb.ids now that discover1-data is no longer around to provide the names of network
<Kamion>                 interfaces for netcfg's UI
<Kamion> 20:48 < Kamion> mdz: which I had totally not thought about in advance
<Kamion> 20:49 < Kamion> mdz: and getting lspci and lsusb will probably be a bonus for debugging purposes, too
<Kamion> ah
<mdz> sounds fine
<mdz> in general, it's fine with me if you add things to the installer seed at your own discretion
<Kamion> ok, thanks
<mdz> it doesn't have the same associated issues as adding things to base, desktop or ship which require that those be discussed first
<Kamion> haven't quite decided yet whether I want to include usbutils-udeb in any of the initrds
<Kamion> I suspect not; it's a fair size and we degrade relatively gracefully
<seb128> fabbione: pong
<Kamion> ooh, I have a cunning plan: I can use Enhances for a technical purpose!
* mdz gasps!
<Kamion> anna is one of the very few tools anywhere in Debian that actually pays attention to and uses Enhances
<fabbione> seb128: control-center is a FTBFS due to type-handling :(
<seb128> fabbione: what's wrong with type-handling ? it works on my box
<fabbione> elmo, Kamion: DOH!
<fabbione> seb128: it's from universe
<seb128> depends from a main should go automatically in main, right ?
<seb128> +package
<fabbione> elmo, Kamion: do daniels and jdub realize that we did all this X.org sprint to get the new extensions in, like composite, ad we are taking away the only ONE available manager?
<fabbione> seb128: yes, but we don't want type-handling in main :-)
<Kamion> fabbione: no idea
* fabbione nods
<seb128> fabbione: arg, any reason for that ?
<seb128> what's the problem with it ?
<elmo> seb128: not for type-handling - we've been trying to avoid bring that in, and have already removed it from several packages' build-depends
<fabbione> seb128: i remember that we were told to remove it from everywhere
<Kamion> seb128: ECRACK basically
<seb128> ok
<seb128> it has been added in some GNOME package because some BSD guys submitted patches IIRC
<fabbione> yeah! another 2 and a half kernels to go
<seb128> should I slay it on the debian side too ? :)
<Kamion> seb128: I'll take a guess that that was the author of type-handling
<fabbione> guys.. my apologizes if i was bitching on X compilation time
<fabbione> i really really feel sorry for that
<fabbione> the kernel is MUCH worst
<fabbione> specially when you compile it in 200 flavours
<fabbione> including the choccolate cake one with coffe.ko
<seb128> Kamion: yep, just checked (ie: #272722)
<Kamion> night all
<fabbione> cya Kamion 
<mdz> seb128: type-handling is fairly crackful
<jdub> mdz: tried gnome-user-share?
<mdz> nope
<jdub> mdz: it will most likely be in gnome 2.9, and depends on apache2 and mdnsresponder. :-)
<mdz> "easy user-level file sharing" is defiintely a gap that needs filling
<mdz> it is not, however, something that warrants open ports by default :-)
<seb128> mdz: ok, I've not played with it so I didn't know :)
<jdub> :-)
<Mithrandir> mdz: sounds crackful.
<jdub> by default, it's not on
<mdz> jdub: no problem, then?
<jdub> but there's a black cloud hanging over mdnsresponder
<jdub> which will be very un-zeroconf if it doesn't listen by default
<mdz> mdnsresponder just needs some smarts so that it is only enabled if the user has asked for it
<mdz> this is something where I think we are justified in being bull-headed
<jdub> yeah
<mdz> I need to read up on how it works so that I can understand the security model
<mdz> but I'm ostensibly off today and will be heading out soon
<mdz> if you have some pointers to resources on that subject, please send them to me
<jdub> it's the kind of thing that could be run by the library when required, but unfortunately, it listens on :5353 udp
<jdub> and there must only be one daemon because of that
<seb128> jdub: GNOME used to have a preview of the mouse cursors, right ? 
<jdub> seb128: not a proper one, no
<jdub> seb128: it had a "small" and "large" picture, but it wasn't of the actual cursor
<seb128> jdub: I swear I can remember a screen with cursor pictures
<seb128> oh, perhaps that's it so
<jdub> yeah, it was in the old mouse properties dialogue
<jdub> we haven't had anything that handles cursor themes though
<seb128> how old is the dialog ? I don't find the change in the ChangeLog
<jdub> hrm, that probably disappeared in 2.4
<seb128> ok
<seb128> I'm doing some bug triage in the control-center's bugzilla, not always easy to understand the bug without the old capplet to compare :)
<jdub> oh yeah, it's turkey day
<fabbione> jdub: want to take a look at http://people.ubuntulinux.org/~fabbione/changelog before i upload?
<jdub> fabbione: cool
<jdub> exciting :)
<Mithrandir> jdub: have you done any fun stuff on libuser?
<jdub> Mithrandir: haven't had time :|
* fabbione uploads
<jdub> Mithrandir: perhaps we should beg lifeless to import it asap :)
<jdub> fabbione: so i guess i should bring on the U5 :-)
<Mithrandir> jdub: I guess so, so we havething to work off.. I hope I
<Mithrandir> 'm able to do something next week, but exam on Monday, so..
<fabbione> jdub: if it can boot 2.6
<fabbione> thom claims his u10 can't
<jdub> duck
<jdub> er
<jdub> suck
<fabbione> accepted
* jdub wonders which OS this machine runs
<jdub> ah
<jdub> solaris 9
<sjoerd> an U10 is just an U5 in another box right ?
<jdub> i think so
<fabbione> get ready for -19
<fabbione> there was an error in debian/control
<jdub> U5 is surprisingly noisy
<sjoerd> the front fan is noisy 
<sjoerd> my U5 runs 2.6.9 just fine so..
<jdub> fabbione: so you reckon a sarge install and piecemeal upgrades to your packages is the best bet?
<fabbione> no
<fabbione> there is a much better way
<fabbione> install sarge in the future swap
<jdub> aha
<jdub> and debootstrap into the / ?
<fabbione> install debootstrap from ubuntu and patch it with debootstrap.diff from the website
<fabbione> and than debootstrap it
<jdub> nice
<fabbione> you need to find a way to make the _all.deb available to your machine
<fabbione> my archive is only _sparc.deb
<fabbione> ok.. _19 is going up
* lamont decides that ia64 is committed enough to just file bugs about it... :-)
<lamont> albeit as normal, not serious
<chrisa> hrm, I like the idea of putting windows versions of apps on the ubuntu live cd
<fabbione> yeah.. but you can't symlink
<lamont> jdub around?
<fabbione> argh
<lamont> seb128: you around?
<fabbione> lamont: mind to babysit the kernel build?
<seb128> lamont: yes
<lamont> seb128: libglademm2.0 is yours, yes?
<lamont> fabbione: bouncing around, but I can check on it, yets.
<lamont> yes.
<fabbione> lamont: it would be enough for me to know if it started the real build
<fabbione> (compiling)
<lamont> heh
<lamont> any particular architecture?
<fabbione> all of them? :)
<lamont> i386:  CC [M]   fs/reiserfs/tail_conversion.o
<lamont>   CC [M]   fs/reiserfs/journal.o
<lamont>   CC [M]   fs/reiserfs/resize.o
<lamont> ditto amd64 and ppc.
<lamont> ia64 I just marked failed.
<seb128> lamont: not really but I can work on it
<fabbione> cool
<seb128> lamont: I don't maintain the *mm
<fabbione> lamont: well.. ia64 isn't supported yet
<lamont> fabbione: true 'nuf
<lamont> seb128: ah, ok
<lamont> fwiw - i didn't assign you the bug.  if it's assigned, bz thinks you own it...
<seb128> lamont: what's needed ? I can work on libglademm2.0
<lamont> amd64? ftbfs
<seb128> ok
<lamont> 4144
<lamont> and bz didn't give it to you.  istr the "please use 2.4" was assigned to you though...
<seb128> "please use 2.4" ?
<seb128> BTW I'm not official maintainer for gnome-mm stuff but all the "*gnome*" stuff seems to get assigned to me :)
<lamont> seb128: your lucky then. :-)
<seb128> sort of :p
<lamont> 3621 is the one assigned to you "Please update to ver 2.4"
<lamont> in the lamont-needs-to-file-a-bug camp: binutils, linux86, svgalib, zsh
<lamont> I'm fixing zsh tonight if noone beats me to it, elmo knows about binutils
<lamont> specifically "[Something went b0rken with tcl/expect in hoary in i386] "
<lamont> or some such, iirc
<seb128> hum, yes, 3621 has been assigned by Matt, not bz :)
<lamont> right
<lamont> knew that when I saw that 4144 hadn't been autoassigned
* lamont files the svgalib bug
<lamont> $conf::should_build_msgs ||= 1;
<lamont> if $conf::should_build_msgs is 0 before that, what does that statement do?  (trying to figure out how it becomes 1...)
<lamont> doh
* lamont hates perl
* lamont honey-do's
<Mithrandir> lamont: howso?
<BradB> lamont: It does what it looks like it does.
<BradB> lamont: e.g. what does x += 1 do in Python? :)
#ubuntu-devel 2004-12-08
<jdub> what was the command to sleep if you can't use your sleep button?
<azeem> echo 3 > /proc/acpi/sleep or similar
<jdub> ah, /etc/acpi/sleep.sh
<jdub> nah, that doesn't work
<jdub> now rmmod button is in D state
<jdub> gar
* jdub just turns off :)
<azeem> don't you love it when hardware just works[tm] ? :)
<lamont> Mithrandir: perl's love of terse punctuation and uninitialized variables means that it does unexpected things unless you really dig into the language.
<lamont> I genenerally find that I have to use perl just often enough to have a learning curve every time.
<lamont> BradB: every other use in that file is setting variables that are not set.
* lamont giggles at #283049
<azeem> heh
<azeem> ugh
<lamont> jdub about?
<magnon> ew. Xorg just went unkillable @ 100% cpu and wouldn't let me get rid of it without rebooting.
<mako> the ubuntu talk at GLUEV just went *really* well
<magnon> mako: feeds?
<mako> people *literally* fought over the last cds :)
<magnon> :D
<mako> they nearly tore one of them in half!
<mako> the box, not the cd :)
<mako> and i did something you're never supposed to do
<mako> during the question time, i did an ubuntu install onto a compuer i'd never used before
<mako> just someone who anted to install ubuntu
<mako> and it worked prefectly :)
<magnon> let me guess, it got seamlessly installed
<magnon> :)
<mako> i thought that doing something untested in fromt of 600 peopple is guarentted to make it breka :)
<mako> wow.. that was mangled
<jdub> lamont: pong
<magnon> mako: are there video feeds?
<mako> magnon: there will be.. i don't know if they are yet
<magnon> ok
<mako> i have pretty extensive notes and slides online though
<magnon> mako: where?
<azeem> tonight, two guys from the BSP here gave a talk about d-i and they decided to try out LVM for the first time...
<mako> azeem: where they as lucky as me?
<azeem> they used the whole partition and then failed to install lilo
<jdub> mako: i heard GULEV was rad
<mako> jdub: it's really really cool
<lamont> jdub: feeling kind enough to add ia64 to bugzilla's list of architectures?
<mako> there were only 3 non-spanish talks
<lamont> or is that a 'discuss this more first' thing?
<jdub> lamont: hrm
<lamont> jdub: exactly
* lamont decided to pretend and just file bugs against ia64, you see...
<lamont> so they're all 'Other' right now.
<mako> jdub: it's totally the kind of conference we want to be at
<mako> the only thing i have to complain about is the headache i get from all  the tequila :)
<lamont> mako: after 4 you're supposed to be unconcious....
<lamont> s/nc/nsc/
<mako> lamont: didn't work that way last night 
<mako> lamont: might have beeter if it had
<mako> last talk now.. rms is talking now :)
<jdub> did you bring vegetables?
<mako> jdub: i think its prudent to forget them. he likes us remember? :)
<azeem> that was before multiverse
<mako> azeem: richard doesn't know about multiverse :)
<jdub> mako: i only bring him up just to tear him down
<mako> jdub: that man is very depressed.
<mako> you would feel sorry for him but he is VERY annoying about it
<mako> azeem: but we also allow GFDL documentation
<lamont> even with multiverse, we're simply allowing end users to run whatever they feel they need on their machine... dammit, it's more freedom for the end user.
<mako> azeem: that ought to get on his good side
<jdub> lamont: um, i'm not sure i know how.
<lamont> and the main/restricted universe/multiverse split helps make it clear what you're doing...
<jdub> how on earth did i get lumped with bugzilla maintenance, anyway?
<mako> richared ends up supporting distributions that are unknowingly distribuint free software
<thom> jdub: no-one else wanted it?
<jdub> thom: stfu!
<lamont> jdub: have to edit the list of platforms in the localconfig file, then run checksetup.pl to copy it to the database
<azeem> lamont: hey, I'm not judging you, just pointing out his possible line of reasoning
<lamont> azeem: yeah
<jdub> lamont: seriously? i can't do that
<lamont> no shell access there?
<lamont> oh thom bot... :-)
<jdub> HA HA HA
<mako> rather than supporting distributions that make it clear when you are using non-free and letting people make adult decisions.. and making freedom the default
<thom> mail me
<thom> i'm going to bed now
<lamont> jdub: you wanna mail him, or want I should just cc you on the mail...
<lamont> ?
<mako> dude, the main organizer for this conference had a baby LAST WEEK
<mako> that guy is A SUPERMAN
<lamont> mako: or was it his wife?
<mako> well, his wife gave birth i suppose
<mako> lamont: that's my best guess at least
<mako> i didn't ask
<mako> :)
<lamont> heh
<mako> probably a pretty safe assumption :)
<lamont> Mithrandir: you still around?
<lamont> ncc -Ml -ansi -s  -o elksemu elks.o elks_sys.o elks_signal.o minix.o
<lamont> WARNING: Native a.out generation not included, sorry
<lamont> ...
<lamont> strip: /build/buildd/linux86-0.16.14/debian/tmp/lib/elksemu: File format not recognized
<lamont> that'd be linux86 on amd64.
<lamont> which amusingly enough is #260647.  sihg
* lamont goes back to sleep
<mako> my back is hurting and my mail is synced.. i'm off unless the wireless gets fixed
<magnon>  /me goes to sleep as well
<lamont> oh. that reminds me.  how many access points should I bring?
<magnon> night
<lamont> to mataro
<mako> lamont: lots :)
<lamont> mako: only have 3...
<mako> lamont: one HUGE one? :)
<lamont> btw, anyone in EU have a netgear box with a US adapter that wants to trade me for my EU adapter?
* mako goes for real
<lamont> will have at least one 1W beast
* lamont must do more honey-do list, or find a new place to sleep.
<lamont> bbl
<azeem> did somebody point out 'Multiverse' to Erich Schubert? java-package is in there
<thom> and the custom install target, for that matter
<bob2> haha
<KeyserSoze> hey fellas is there a netinstall for amd64?
<mjg59> ARGH NO NO NO
<mjg59> If anyone ever suggests putting swsusp2 in the Ubuntu kernel, kill them
<thom> rofl
<Mithrandir> lamont: pong?
<lamont> Mithrandir: trying to remember what the amd64 error I was going to poke you with was...
<mjg59> thom: Seriously, people keep suggesting it
<lamont> Mithrandir: ah, was linux86, but the bug is already in debbugs
<Mithrandir> lamont: yes, I've seen it.  I need to be more drunk than sober, but less drunk that I'm now to tackle it.
<elmo> looks like our amd64 boxes are happy smp now, btw - which is nice
<Mithrandir> elmo: yay, that is good.  Any real change that happended to them?
<mjg59> Any sign of a kernel maintainer yet?
<elmo> Mithrandir: reinstalled as real amd64, and using (self-compiled) warty kernel source
<KeyserSoze> anyone that can tell my why the enlightenment package says "not available" on hoary amd64
<jdub> elmo: how big is a mirror of warty main?
<jdub> elmo: also, can someone mirror warty-security on its own?
<elmo> jdub: err, I _think_ main is about 6Gb for one distro
<elmo> you can only mirror one distro with a script like debmirror
* lamont does a partial mirror by munging Packages/Sources files.
<lamont> ugly but mostly works.
<lamont> KeyserSoze: d-w libfnlib-dev
<lamont> which is d-w libtool1.4, which won't be fixed.
<lamont> so...  create a patch for fnlib that moves it to libtool instead of libtool1.4, and I'll upload it, and we'll quite possibly be enlightened...
<jdub> elmo: one distro meaning 'warty' or 'hoary'?
<elmo> jdub: yeah
<elmo> pool/main == 13Gb, which matches my memory of warty being 6Gb last time I had a local mirror of it
<lamont> warty main+source fits on a dvd
<jdub> cool
<lamont> with room to spare.
* lamont will bring his warty install dvd to mataro with him
<elmo> jdub: yeah, bear in mind that 6Gb is for 3 arches +source
<lamont> er, warty i386/main + source fits on a dvd - thanks elmo
<jdub> nice
<jdub> it's pretty small
<lamont> jdub: dvd has i386+source main/restricted, bits of universe/multiverse, and theopencd
<jdub> heh
<jdub> and the livecd tacked on? ;)
<lamont> elmo: btw, libtool1.4 can move to universe.
<lamont> 'k thanks bye
<lamont> yeah
<lamont> oh. no livecd
<jdub> that'd be cool
<lamont> didn't want to make it dual boot you see...
<jdub> ;)
<lamont> and I had to shave stuff to fit on the dvd as it was
<lamont> was very sad.
<lamont> 4.7GB == 4700000 bytes
<jdub> no good having a stubbly dvd
<lamont> which truely sucks
<elmo> jdub: gnome-user-share in a seed or should it be in universe?
<jdub> elmo: universe until it's proposed and accepted
<jdub> thanks
<lamont> elmo: actually, if libtool1.4 isn't seeded, then it'll automagically move to universe, yes?
<elmo> if you ignore the muppet behind the curtain, yeah
<lamont> KeyserSoze: actually, fnlib no longer b-d's libtool1.4...
<lamont> which is to say that enlightenment may be there in about 45 minutes
<lamont> elmo: lol
<lamont> elmo: shame we don't allow previously uncompiled universe packages to enter warty as I free up build-deps. :-(
<jdub> hrm
<jdub> dh_python does not love me
<elmo> lamont: you can upload to warty-updates if you want
* lamont continues to be reminded that --pretend-avail propogates back to warty.
<lamont> elmo: I'd have to care
<lamont> jdub: did you remember to b-d: python?
<elmo> that propagation shit is fucking satanic
<jdub> lamont: yeah
<lamont> elmo: yeah
<elmo> there's a screenshot of it in action next to "WHEN DWIM GOES WRONG" entry in a dictionary somewhere
<jdub> (well, it's a depend of a depend, and i'm doing the build locally)
<lamont> I type in the w-b command, see it say 'propogating', and then get the reject mail shortly thereafter...
<lamont> elmo: lol
<elmo> jdub: hmm, is something actually going to happen about the chunk of seed proposals at some stage?
<jdub> i was hoping to do an initial pass at them next week
<jdub> to cut it down before the conference
<elmo> ok, cool - I wasn't sure if I was meant to be more activiely fighting for my proposals
<elmo> tho I think I need to redo most of them
<jdub> fight when i say something stupid :)
<lamont> jdub: how do I get firefox to show me text/plain in a simple window?
<jdub> lamont: it normally does
<elmo> jdub: always, dude ;-)
<jdub> perhaps the server is giving you a funny mime type
<lamont> jdub: mine asks me whether to save it to disk or display it with less
<jdub> elmo: so then you should also back me up when baby jesus is crying :-)
<jdub> lamont: bong
<lamont> jdub: bugs.debian.org/283174, click on the byacc.diff attachement (which says text/plain), and that's where I go.
<jdub> because it's a DIFF file
<jdub> weird
<lamont> jdub: like I said.  annoying
<elmo> how the heck do we not ship with python-elisp
<jdub> elmo: you around for a bit to process some NEWage?
<elmo> jdub: yeah, only half an hour or so tho
* jdub races against the clock
<elmo> will people laugh at me if I propose lavaps?
<elmo> or does anyone know something else to do what it does well, i.e. get a visual representation of process CPU & memory usage which makes it super easy to find the problem process(es)
<jdub> elmo: flumotion in NEW :)
<elmo> done
<jdub> thanks
<elmo> does synaptic have deborphan style functionality?
<lamont> elmo: ISTR being told it did
<lamont> hrm.. byacc NMU'ed.
<GotD0t> does anybody know why 3D accelerated games crash my X in hoary?
<lamont> so how do I allow gpg to plock?
<GotD0t> lamont: i couldn't get it to lock when it was installed through apt-get... i had to remove it and compile it from source then lock it
<lamont> GotD0t: it is intentionally not setuid-root from install, because there's a better way to do the same thing... I just can't remember how...
<lamont> ENOPITTI
<lamont> :-)
<GotD0t> lamont: i know... you're supposed to be able to do chmod u+s but i still got the insecure memory warning
<KeyserSoze> anyone that can tell me why the enlightenment package isn't available?
<KeyserSoze> in hoary
<KeyserSoze> dunno about i386 but it doesn't work in amd64
<KeyserSoze> Package enlightenment is not available,
<KeyserSoze> I see
<lamont> KeyserSoze: let me check again
<KeyserSoze> there is no amd64 package for it
<KeyserSoze> thats why
<lamont> although this is really a #ubuntu question...
<KeyserSoze> I know
<KeyserSoze> but I've been asking there for a while
<KeyserSoze> the reason is that there is no amd64 in the pool/universe/e/enlightenment dir
<KeyserSoze> just i386,ia64 and powerpc
<GotD0t> lamont: where would i find log files that might tell me why X crashed after running a 3d Accelerated game?
<KeyserSoze> in /var/log/Xorg.0.log
<KeyserSoze> or in your home dir .xsession-errors
<lamont> KeyserSoze: )&%*%^&*(^*(_ wanna-build propogation
<lamont> that, and the fact that fnlib hasn't changed since warty froze
<KeyserSoze> yeah I just tried to apt-get source and saw that fnlib was missing too
<lamont> KeyserSoze: yeah - pb was that what I did earlier caused fnlib to build for _WARTY_ not hoary (and get rejected, etc.)
<KeyserSoze> ok
<lamont> upload for hoary just happened, will be in the archive in 30 minutes, and enlightenment should hit just over an hour from now
<KeyserSoze> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
<KeyserSoze> trying to compile fnlib
<KeyserSoze> ohh well
<KeyserSoze> I'll wait
<lamont> KeyserSoze: that was bulding fnlib or enlightenment?
<KeyserSoze> fnlin
<KeyserSoze> fnlib
<lamont> because, mind you, I don't _know_ that enlightenment will build... just know that fnlib does
<KeyserSoze> ok
<KeyserSoze> weird why I got that error
<lamont> dpkg-buildpackage?
<KeyserSoze> apt-get -b source
<KeyserSoze> same thing really just that it applies the diff for me
<lamont> right
<lamont> KeyserSoze: this is just sbuild building in a hoary chroot
<KeyserSoze> this is on a newly installed amd64 hoary
<KeyserSoze> no wonder
<KeyserSoze> I didn't have g++ installed
<lamont> KeyserSoze: fwiw, I missed the window by about 20 seconds, hence the 30 minute wait. :-(
<KeyserSoze> just built fnlib
<KeyserSoze> let me try enlight
<KeyserSoze> wth is /usr/bin/ld: cannot find -lXtst
<KeyserSoze> whats -lXtst?
<KeyserSoze> Xtest?
<KeyserSoze> wtf?
<KeyserSoze> its there
<KeyserSoze>  /usr/X11R6/lib/libXtst.so.6
<lamont> and is there -L/usr/X11R6/lib in the command line?
<KeyserSoze> configure:14115: cc -o conftest -g -Wall -O2   -L/usr/lib  -lImlib conftest.c -lXxf86vm  -L/usr/X11R6/lib -lXtst
<KeyserSoze>  /usr/bin/ld: cannot find -lXxf86vm
<lamont> well, that'd mean that the -L needs to come before that one, too. :-)
<KeyserSoze> this is all busted
<lamont> xorg broke up all the xlibs, and this causes some amount of pain for packages...
<KeyserSoze> how are you getting this to build without manual changes
<lamont> haven't yet.
<KeyserSoze> hehe
<lamont> all I did was coax the buildd into building fnlib/hoary/amd64
<lamont> and in about 10 minutes, that'll show up in the repository, and free everything that's d-w libfnlib-dev, to build or fail as it sees fit...
<lamont> KeyserSoze: yep.  ftbfs
<lamont> patches welcome
<KeyserSoze> hehe
<KeyserSoze> I'm too lazy ;)
<lamont> KeyserSoze: then I guess we'll both have to wait for someone who cares.
<KeyserSoze> its a simple change if you want to make it
<KeyserSoze> to the "configure"
<lamont> night all
<lamont> really?
<KeyserSoze> yeah
<KeyserSoze> I just compiled enlight
<lamont> so unpack it, save that directory, make the change, say 'diff -ur old new' and send me that output...
<lamont> then I can credit you with the patch. :-)
<KeyserSoze> line 13316
<KeyserSoze> LDFLAGS="$LDFLAGS -L$prefix/lib  -L$prefix/X11R6/lib"
<lamont> by adding the last token, I expect.
<KeyserSoze> yeah
<lamont> seriously - send me an email.  I'm going to go crawl into bed, and universe stuff falls through the cracks when I do that.
<lamont> lamont@canonical.com
<KeyserSoze> but I'm too lazy to make a diff and stuff ;)
<lamont> even that much and I'll eventually deal with it.
<lamont> but it certainly is backburner.
<lamont> and I'm off to bed.  night all.
<KeyserSoze> ok
<KeyserSoze> night
<fabbione> morning guys
<smurfix> Should this line in various /etc/init.d/* files be considered a bug?
<smurfix>         log_success_msg "Usage: /etc/init.d/apache2 start|stop|restart|reload|force-reload"
<smurfix> (occurs with and without redir to stderr)
<smurfix> IMHO that should be turned back to "echo".
<smurfix> Hmmm, everybody asleep at this time...
<ironwolf> smurfix: not everyone.
<smurfix> Everyone who'd disagree, then.
* Kamion had a cunning idea for a d-i rescue mode over the weekend
<Kamion> er, overnight, I mean
* Kamion is not time-travelling
<mdz> a replacement for "proceed until you get to the partitioning step and swich VCS"?
<Kamion> yes
<Kamion> basically one udeb that checks a debconf question and does 'anna-install rescue-mode' if set, and another udeb that runs just before the partitioner, mounts and invokes a shell, and then reboots
<Kamion> very very simple
<fabbione> that sounds cool
<fabbione> mdz: udebs are in the kernel :-)
<fabbione> and i am off 
<mdz> fabbione: great
<fabbione> have a nice we
<mdz> built for all architectures?
<fabbione> mdz: yes, including sparc
<fabbione> :)
<mdz> sweet
<fabbione> we will need a special setup to build sparc kernels on the buildd
<fabbione> but that's not ubuntu problem
<fabbione> it's a buildd setup issue
<fabbione> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/
<fabbione> ^^mdz enjoy :-)
* fabbione &
<Kamion> might have rescue-check do db_set debconf/priority critical or display some helpful message or something; we do actually need to go through language/country/keyboard selection and hardware detection anyway
<mdz> sounds useful
<mdz> linux-source-2.6.8.1 produces _even more_ binary packages than before
<Kamion> one miiiiiiiiiiiiiiiiiiiiillion binaries
<Kamion> at some point remind me to jump up and down on benh's head until he makes power3 and power4 go away
<smurfix> In diesem Schritt kompiere ich auf einen Kunden. Von dort wird auf einen anderen Dienst kopiert und der dann wieder auf alle Kunden.
<smurfix> *sigh*
<smurfix> I'll be turning that off now.
<Kamion> hm, I am missing too much vocabulary to be able to translate that
<Kamion> Schritt and kompieren, for a start
<azeem> kompieren was a typo
<azeem> kopieren
<smurfix> It's a comment in a slightly convoluted test script. azeem: I noticed. Kamion: Schritt=step
<smurfix> azeem: It's not exactly a typo -- with dasher, one doesn't type. ;-)
<azeem> ah
<elmo> woah
<elmo> a build log somehow managed to infect the title bar of my screen process
<elmo> that's scary wrong
<daniels> to be fair, screen's title handling is pretty horrendous
<elmo> err, I meant status line actually, meh
<elmo> [I made that mistake in my head, corrected it, and still typed it wrong] 
<daniels> status line?!?
<daniels> that's pretty impressive
<elmo> sigh, ia64 kernel images are 88Mb a shot
<zopy> Hi
<zopy> is it plan to add Gartoon icon by default or you want to make your own ?
<zopy> http://zeus.qballcow.nl/icons.php
<azeem> zopy: the problem with such iconsets is that only a few icons would like that, all the others are regular
<azeem> which looks bad
<zopy> arf
* RubenV prefers gnome-icon-theme
<RubenV> jakub and the rest are doing great work
<azeem> RubenV: ack
<_rene_>  /gw 13
<_rene_> grmbl
<jdub> fabbione: there?
<fabbione> yeah now
<fabbione> jdub: ?
<jdub> fabbione: so i need the debootstrap from hoary;
<jdub> fabbione: where was the patch?
<fabbione> jdub: same place where the debs are
<fabbione> i am not sure 100% you can bootstrap.. the base debs should be there already
<jdub> fabbione: oh, your debs?
<fabbione> jdub: in the middle of my debs there is a .diff :-)
<fabbione> debootstrap.diff
<fabbione> remember that you need to find a way to make the _all.deb available to your debootstrap
<fabbione> it's not extremely simple yet
<jdub> how do you mean?
<fabbione> that in the sparc dir there are only the _sparc.deb
<jdub> oh, so _all has to come from archive.ubuntu.com or wherever?
<fabbione> you need to make the _all.deb available to debootstrap somehow
<fabbione> jdub: yes... and that makes it complex
<jdub> oh, i have to rebuild debootstrap on sparc?
<fabbione> no
<fabbione> debootstrap is arch _all
<fabbione> you just need that patch to /usr/lib/debootstrap/scripts/hoary
<jdub> http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/
<jdub> ?
<fabbione> yes
<fabbione> + debootstrap is very anal in checking the pool/dists tree
<Kamion> debootstrap isn't arch all
<Kamion> it's got pkgdetails.c
<fabbione> true
<fabbione> jdub: well just wait.. it's better
<fabbione> atm it is just pure crack to mix the archive properly and make debootstrap happy
<Kamion> so can I start running germinate against your archive + archive.ubuntu.com to generate debootstrap/sparc?
<fabbione> Kamion: i would wait a bit still
<fabbione> but if you want you are welcome to start
<fabbione> it's not a complete main yet
<Kamion> if it's got all of base it should work fine
<fabbione> Kamion: i think it does...
<Kamion> yeah, I only need base for debootstrap though
<Kamion> where's the archive?
<fabbione> people/~fabbione/sparc
<fabbione> Kamion: the debootstrap.diff is almost mandary
<fabbione> mandatory
<fabbione> it works around 2 things atm
<fabbione> ltrace is not for sparc
<Kamion> yuh-huh, but I refuse to maintain that manually :)
<fabbione> -> moved to the different $archs
<Kamion> I can generate all this stuff automatically; I've been doing so for amd64/i386/powerpc for six months
<fabbione> oh sure
<Kamion> that's what required-base.py does
<fabbione> it was just to show you how it should look after germinate output
<fabbione> lvm2 and strace are FTBFS on sparc atm
<fabbione> and libreadline5 is required to install a bunch of base
<Kamion> that sounds like a bug, we got rid of it from hoary
<fabbione> lvm2 needs to deal with a big 32/64 api/abi problem
<Kamion> after a bunch of syncs from Debian
<fabbione> Kamion: probably it will disappear after i finish to rebuild ubuntu on ubuntu
<Kamion> should do
<fabbione> but if i did build libreadline5 it means that it was in main at some point
<Kamion> yes, it was
<fabbione> well.. than some of my pkgs have used it
<fabbione> and probably still are
<Kamion> the build-deps should be tighter now
<Kamion> we had to change them for sarge
<fabbione> ok
<fabbione> i will be back in 20 minutes
<fabbione> gf is calling
<fabbione> :(
<Mithrandir> poor fabbione :)
<jdub> fabbione: so you reckon i should wait a bit for hot ubuntu-on-sparc action?
<fabbione> jdub: if you like to mess around no.. just do it
<fabbione> but it's not trivial without mixing things around
<fabbione> anyway.. i need to go and done some works in the house
<jdub> might leave it a bit
<jdub> :)
<fabbione> yeah.. once they will enter the archive it will be very easy
* Kamion heads off to the bug-squashing
<daniels> Kamion: seeya there
<Matt|> the version of evolution in hoary is beyond a joke - It's totally unusable. is there any chance of reverting to an older version?
<azeem> Matt|: uhm, hoary is the development branch, right?
<Matt|> yes
<Matt|> but this version of evolution cannot be tested - it crashes so randomly that no profit is had by using it
<Matt|> and i assume the problems are all upstream
<lemsx1> Matt|, you are right about that... 2.1 is very unstable
<carlos> Matt|: it works here
<lemsx1> Matt|, and all upstream
<carlos> 2.1.0
<lemsx1> carlos, you don't use imap to access your mail right?
<carlos> no, pops
<Matt|> carlos, you don't get random crashing?
<lemsx1> carlos, that's part of why it works for you... but does it crash at all?
<Matt|> i use pop only and it's always crashing when I open messages and click on windows and all sorts
<carlos> no, I got 0 crashes
<carlos> and I'm using it since long ago
<Matt|> well i don't know why mine is crashing then
<Matt|> but i've seen all the problems in bugzilla
<Matt|> and they all say "UPST"
<Matt|> 3928 is a classic
<Matt|> 3839, 3310, 3634
<Matt|> i don't think this app should even be in the devel branch it's too rubbish
<azeem> Matt|: evo is an important part of the desktop, so there is no use in just dodging problems
<Matt|> but they are upstream problems. Could a previous version of evo not be used?
<tseng> you are in the devel branch
<tseng> it tracks devel versions of key components
<tseng> it would suck to be at the end of hoarys 6 month cycle and just start adding this stuff
<tseng> thats now how it works.
<Matt|> you are right
<tseng> if you want stable versions, see warty.
<tseng> if you want to test the latest, keep tracking bugzilla :)
<Matt|> tseng, i don't have the expertise to understand the complete randomness with which evolution crashes upon clicking on various parts of the window
<Matt|> but i take your point
<tseng> also, remember that evolution used to be developed by Ximian internally
<tseng> they are still adjusting to the gnome proper way of things
<tseng> like.. always stable devel branches :)
<Matt|> yeah guess so
<Matt|> they should have kept it separate ;)
<tseng> no, it will be better someday
<tseng> for everyone.
<Matt|> here's hoping
<tseng> :P
<Matt|> if they integrate it too much into gnome they'll have to call it outlook express tho
<tseng> not true
<Matt|> well obviously not literally
<tseng> it has a seperate backend for data storage that apps are integrating with
<tseng> mostly not directly with the evolution client
<Matt|> tseng, do you use #ubuntu?
<Matt|> i want to ask you some questions about evolution but they are not really appropriate for this chan
<tseng> sure.
* Kamion finishes a preliminary version of d-i rescue mode and checks it into d-i svn
<elmo> cool
<Matt|> does anyone know if anything is happening on bug 2711?
<Nafallo> hi all! any drawbacks by mixing debian woody and ubuntu warty? I don't want my server without security updates.
<Kamion> Ubuntu warty has security updates
<Kamion> it also entirely supersedes woody by about two years; I wouldn't recommend mixing the two
<Nafallo> Kamion: so do woody. that's why I run both of them on my current server :-).
<azeem> you'd have to violate APT a lot to actually get those two to mix, I bet
<Kamion> you probably *can*, but there's little point, since nearly every package in woody will be replaced by much newer versions in warty
<Nafallo> azeem: in what way? :-)
<azeem> what Kamion said
<Nafallo> Kamion: nope, I couldn't find the jabber server for example :-/.
<elmo> it's in universe
<Nafallo> elmo: and that repo hasn't got security updates :-).
<Kamion> well, it would depend on whether woody's jabber actually works with woody ...
<Kamion> er, with warty
<Nafallo> Kamion: it does :-)
<Nafallo> Kamion: everything I got currently running does :-).
<Kamion> then that should be ok
<Nafallo> oki. I'll run mixed system a while longer then :-).
<GotD0t> have there been any reports of nano not closing when it should?
<eruin> new udev = camera broken ;o
<eruin> what info would I need to submit for a bug report on my (supported by gphoto2) camera suddenly not working after the last udev upgrade?
<eruin> not even familiar with which packages are involved in this sort of thing
<azeem> eruin: is the camera displayed by hal-device-manager?
<eruin> azeem: yep
<eruin> via tech. vt82x -> dx4330 -> usb ptp interface
<azeem> best info in that case would be the kernel log, probably
<azeem> and perhaps gnome-volume-manager output if you start it from the console (if there is any)
<eruin> kill it and restart in console?
<azeem> worth a try I guess
<eruin> kernel log hasnt got anything since last boot though
<azeem> and /var/log/messages
<azeem> ?
<eruin> Nov 27 17:41:31 localhost usb.agent[4900] :      libgphoto2: loaded successfully
<Matt|> kernel panic when booting after last hoary upgrade
<Matt|> i think it is just a grub error
<azeem> eruin: anything about USB and devices?
<eruin> azeem: gnome-volume-manager had some interesting output
<eruin> I'll get a pastebin
<eruin> http://pastebin.com/123940
<eruin> the errors output when pressing import
<azeem> looks informative for a bug report, possibly with some more HAL/udev /var/log/messages log output
<azeem> pitti is the guy who knows about this, but he's not around
<eruin> I'll keep the info saved in a text file for now
<eruin> what's pittis timezone?
<eruin> the only relevant thing I can find in var/log/messages is that libgphoto was loaded successfully though
<sjoerd> eruin: GMT+1 or GMT+2
<eruin> oh, same as me
<azeem> well, it's weekend :(
<azeem> eh, :(
<eruin> hehe yeah
<azeem> eh, :)
<sjoerd> eruin: what's going wrong ? gthumb doesn't pop up ?
<eruin> gthumb pops up, but hal screams about no property info.capabilites on the device after gphoto pops us
<eruin> up*
<eruin> well thanks for help gathering info azeem :)
<sjoerd> that's normal, the endpoints don't have capabilities
<azeem> eruin: sjoerd is the guy as well
<sjoerd> eruin: but if gthumb pops up what's wrong ? 
<eruin> it says there are no images ont he device
<eruin> and "no cameras found" is in the left pane
<eruin> err scratch that
<eruin> gthumb says cannot import pictures - no cameras found
<sjoerd> ah
<eruin> it did however work fine just a few days ago ;)
<sjoerd> check in /proc/bus/usb what the permissions for the camera endpoints are ?
<sjoerd> there should be some of root.plugdev or root.camera
<eruin> if hal-device-manager lists the camera as the first device on controller #4, that means /proc/usb/004/001 ?
<eruin> 007 in there was modified recently
<eruin> and says root.plugdev
<eruin> -rw-rw----
<eruin> yeah thats definately it
<eruin> should I try changing those?
<sjoerd> no that's the way it should be
<eruin> crap ;)
<smurfix> Hmm. Do this:
<smurfix> strace gphoto2 -n 2>&1 | grep EPERM
<eruin> done
<smurfix> that should display the usb device it has a permission problem with
<sjoerd> eruin: oh and check your in the plugdev group (just to be sure)
<smurfix> assuming that's the problem, that is
<eruin> I'm not
<smurfix> ah
<smurfix> you should be
<azeem> eruin: how did you install ubuntu?
<eruin> minimal warty -> sources to hoary -> hoary
<azeem> warty final?
<azeem> when was plugdev introduced?
<sjoerd> dunno
<sjoerd> eruin: is your user on the system the user which was made during install or did you add it later
<Nafallo> warty final
<eruin> azeem: yeah, the cds canonical shipped
<lamont> moo
<Nafallo> atleast my system has it ;-)
<eruin> sjoerd: made during install
<azeem> eruin: what groups are you in?
<eruin> only thing I've done to it manually is adding it to the src group
<eruin> eruin adm dialout cdrom floppy audio src
<Nafallo> odd
<eruin> I'll logout/login and see if adding myself to plugdev solved it
<eruin> brb
<Nafallo>  video plugdev lpadmin scanner <-- those are also added on warty final :-).
<eruin> yup, adding to plugdev did the trick ;)
<azeem> 18:09 < Nafallo>  video plugdev lpadmin scanner <-- those are also added on warty final :-).
<eruin> hmmm
<eruin> well, I ordered the cds about two months ago
<eruin> version 4.10 is all they state
<Nafallo> eruin: I'm running 4.10 (warty) amd64, and those got added when base-config set my account up :-).
<eruin> that's odd
<Nafallo> hmm, I'll check my girlfriends puter. she's running i386, and not a laptop either...
<Nafallo> she got those groups to.
<eruin> meh!
<eruin> what could I have done to get them removed?
<eruin> and why did the camera suddenly stop working now as opposed to a couple of days ago? :)
<Nafallo> eruin: don't look at me. I haven't touched them ;-P
<eruin> I'll test a fresh install on another partition tomorrow
<lamont> make[1] : Entering directory `/build/buildd/syck-0.42'
<lamont> /usr/local/bin/bash ./config.status --recheck
<lamont> make[1] : /usr/local/bin/bash: Command not found
<lamont> hehe
<daniels> ssssssssssvvvvvvvvvvvveeeeeeeeeeeeeeennnnnnnnnnnnnnnnn!
<daniels> elmo: could you please install l-r-m b-d's (rpm, sed, sharutils, bzip2, module-init-tools, linux-headers-2.6.8.1-3-*) on davis?
<elmo> done
<daniels> thanks
<daniels> could you please take l-r-m-2.6.8.1 out of it's p-a-s or n-f-u, also?
<elmo> it'll build?
<elmo> err, never mind
<daniels> it will with 2.6.8.1.4-1, yes
<daniels> amd64 gains madwifi, powerpc gains madwifi, ia64 gains nvidia (and nvidia/fglrx/madwifi all get new versions)
<elmo> it's not p-a-s'ed, it's n-f-u... when the source hits jackass, I'll force g-b
<elmo> [I think buildds infect people with acronymitis... hmm.] 
<Nafallo> hmm, kewl encryption ;-)
<daniels> cheers
<daniels> s/it
<daniels> s/it's/its/
<daniels> elmo: you're running pychecker on katie??
<elmo> I always run pychecker
<elmo> katie's not exactly pychecker clean, but I run it
<daniels> ahr
<daniels> heh :)
<Ferry> hi anyone else having probs with samba support in nautilus with hoary. It sees the machines but i cant connect the password window never pops up
<Ferry> sorry wrong chan
<sivang> anybody has an idea of the D-LINK DWL-650 will be good enough for mataro? considering it has 100m limit inside buildings..
<sivang> ?
<sjoerd> pitti: morning 
<pitti> Hi sjoerd
<sjoerd> hal 0.4.1-2 uploaded :) (yeah, finally)
<pitti> sjoerd: by now I just saw a reject message
<sjoerd> ?
<pitti> sjoerd: but I did not yet came to the debian folder in my crowded mailbox
<pitti> sjoerd: ah, here it is
<pitti> sjoerd: congrats!
<pitti> sjoerd: I will package it for Ubuntu at Monday
<sjoerd> cool
<pitti> sjoerd: I put udev 0.046 into Ubuntu yesterday, works great
<sjoerd> nice.. >= 0.046-2 is also working nicely here
<jdub> Md doesn't sound too happy about not getting our patches straight away
<pitti> jdub: what do you mean?
<sjoerd> in his blog you mean ?
<jdub> yeah
<pitti> jdub: I synced the udev package yesterday, it has everything we patched (but the LSB'ified init script)
<pitti> sjoerd: can you please look at #283216?
<sjoerd> that's a ubuntu or a debian but ?
<sjoerd> uh bug
<pitti> sjoerd: if you took something similar to the Ubuntu storage policy, this should be fixed with the new hal
<pitti> sjoerd: Debian
<sjoerd> oh diggers but
<sjoerd> (i asked him to put that in the bts)
<sjoerd> i talked about that to davidz, but apparently it's an fhs violation
<sjoerd> bah i'm blinkd
<sjoerd> and i can't type
* sjoerd looked at the wrong bug
<pitti> sjoerd: ??? I'm confused
<sjoerd> pitti: ignore what i said, i was looking at the wrong bug :)
<sjoerd> 283216 should be indeed fixed now
<pitti> night, guys
<winkle> Is there a diff between debian and ubuntu dh-make?
<winkle> i'm guessing no
<daniels> doubt it
<daniels> elmo: linux-headers-2.6.8.1-3-power{3,4,pc}{,-smp}
<daniels> elmo: (davis, pls)
<elmo> done
<daniels> include/asm/setup.h:8:28: asm-m68k/setup.h: No such file or directory
<daniels> WHAT
#ubuntu-devel 2004-12-09
<daniels> errrrrrr ...
* daniels lies in a corner, whimpering.
<daniels> (hoary-chroot)daniels@davis:~/kernel/linux-restricted-modules-2.6.8.1-2.6.8.1.4 $ grep '#include' /usr/include/asm/setup.h
<daniels> #include <asm-m68k/setup.h>
<daniels> powerpc is screwed!
<daniels> (hoary-chroot)daniels@davis:~/kernel/linux-restricted-modules-2.6.8.1-2.6.8.1.4 $ zgrep 'setup.h' Contents-powerpc.gz | grep asm
<daniels> usr/include/asm/setup.h                                     devel/linux-kernel-headers
<daniels> usr/src/linux-headers-2.6.8.1-3/include/asm-ppc/setup.h     devel/linux-headers-2.6.8.1-3
<sivang> anybody know if GNOME samba gui interface borked?
<sivang> it seems to not be able to find me workgroup anymore
<seb128> which app ?
<sivang> seb128 : when doing network://
<seb128> which version of samba and libgnomevfs2-0 ?
<sivang> seb128 : will tell you in a sec.
<sivang> seb128 : libgnomevfs2-0 :  2.8.3-5ubuntu1 
<mdz> daniels: there's a bug in bugzilla about that, iirc
<sivang> seb128 : ii  samba          3.0.7-1ubuntu6 a LanManager-like file and printer server fo
<sivang> ii  samba-common   3.0.7-1ubuntu6 Samba common files used by both the server a
<sivang> seb128 : I am using samba from warty, hoary one borked completly on me..
<seb128> sivang: do you have a /usr/lib/gnome-vfs-2.0/modules/libsmb.so ?
<mdz> daniels: https://bugzilla.ubuntu.com/show_bug.cgi?id=2728
<sivang> seb128 : -rw-r--r--  1 root root 23700 2004-11-25 15:09 /usr/lib/gnome-vfs-2.0/modules/libsmb.so
<seb128> sivang: ok, that's ok (gnomevfs was bugged due to samba some time ago)
<seb128> sivang: so dunno
<daniels> mdz: *twitch*
<sivang> seb128 : maybe I should have installed the libgnomevfs from warty as well, to allow it to work with samba of hoary?
<seb128> sivang: that mean switching all the GNOME package to the warty version, good luck
<sivang> seb128 : ahhhhh
<sivang> seb128 : :-)
<sivang> seb128 : ok, I'll make it work , for real now.
<sivang> seb128 : do you know anything of authentication problem with nautilus when accessing shares with user authentication on samba?
<seb128> basically samba support is crap
<seb128> alex doesn't know a lot about samba and has not windows network to test it
<sivang> seb128 : who's alex?
<seb128> s/not/no/
<seb128> the gnomevfs main hackers
<seb128> and the nautilus maintainer too
<sivang> seb128 : ok, they hang on the gnome-love || gnome-hackers? Where can I bug them? :)
<seb128> bug alex about what ?
<seb128> send any patch on the list
<sivang> seb128 : help them test ask them about the bugs etc..
<sivang> seb128 : ok, I will. tnx :)
<seb128> sivang: http://mail.gnome.org/archives/gnome-vfs-list/2004-November/msg00010.html
<seb128> you can read the recent thread
<sivang> seb128 : tnx again!
<seb128> np
<seb128> s/the/this/
<sivang> seb128 : the strange thing here, that it's missing the authentication dialog when tying to log on into one, but when I right click the share, the auth dialog suddenly appreas, however the right menu prevents you from doing any typing in the auth dialog , so I figured this may have something to do with nautilus gui or it's communication with smb auth.
<seb128> no idea...
<sivang> seb128 : then the right mouse button menu stays on, and I need to do killall nautilus to get a gold back of my desktop.
<sivang> seb128 : ok, I'll write that list maybe
<daniels> elmo: please install l-k-h from ~daniels/l-k-h in davis's hoary chroot
<daniels> elmo: (scared yet?)
<elmo> err, why?
<daniels> elmo: because asm/setup.h includes asm-m68k/setup.h, which funnily enough doesn't exist on powerpc
<daniels> elmo: (creating a hoary-crack chroot may be useful)
<mdz> daniels: what's this for?
<daniels> mdz: remember the bug you just assigned me?
<daniels> at least, I think you did
<daniels> yes, you did.
<daniels> https://bugzilla.ubuntu.com/show_bug.cgi?id=2728
<daniels> asm-ppc/setup.h is just #include asm-m68k/setup.h, basically, so I pretty much just inlined it
<daniels> ditto traps.h, which was in the same situation
<daniels> but yes, if I can get l-k-h fixed, then I can test the l-r-m build on powerpc
<daniels> and close a bug while I'm at it, at 0013 on Saturday night
<elmo> so how is inlining it the right fix?
<elmo> or are you not actually trying to fix 2728?
<daniels> do you have a better idea?
<elmo> did you read the bug?
<elmo> https://bugzilla.ubuntu.com/show_bug.cgi?id=2728#c3
<mdz> daniels: yes, but you mentioned it well before that
<mdz> daniels: before you knew about that bug, apparently
<daniels> elmo: i'm working on the least-invasive principle
<daniels> mdz: yes, this is for l-r-m (madwifi is perfectly capable of building on both powerpc and amd64)
<mdz> hmm, so it is
<mdz> there's a bug about the amd64 half of that
<mdz> you can have that one, too, since you're working on it anyway
<daniels> mdz: yes, which is marked as being closed in the changelog; you can d.s@c.c/PENDINGUPLOAD it if you like
<daniels> yeah, amd64 already works (sitting in concordia:~daniels)
<daniels> s/works/builds ok/
<daniels> mdz: are you happy with elmo/herbert's suggestion?
<daniels> elmo: thankyou for your input
<bob2> (*cough*2.6.9.*cough*)
<daniels> bob2: look at the lkh version number
* Matt| hands bob2 cough lozenges
<Matt|> hey bob2 you guys got a tv in that house?
<Matt|> you should check out channel 3 - english c-list celebrities in the australian bush being idiots
<bob2> um, yeah
<elmo> kdelibs4-dev | ubuntu-artwork
<elmo> *BOGGLE*
<bob2> hahha
<GotD0t> anybody know why after upgrading to hoary my system is slow as hell?
<mojo> has anyone seen pitti recently?
<mojo> GotD0t: it's normal, it's still buggy
<bob2> GotD0t: install ubuntu-desktop
<Matt|> GotD0t, have you installed gamin?
<GotD0t> Matt|, whats that?
<Matt|> GotD0t, it is a replacement for fam, which is removed
<Matt|> ?
<GotD0t> Matt|, no i haven't
<GotD0t> Matt|, is that why?
<Matt|> yup probably
<Matt|> daniels needs a hug
<GotD0t> bob2: whats ubuntu-desktop
<GotD0t> why Matt|
<Matt|> his quit message
<bob2> GotD0t: a package you should have installed
<GotD0t> bob2, will it help?
<bob2> GotD0t: yes, it will bring in gamin
<GotD0t> Matt|, after installing gamin do i need to do anythign else?
<Matt|> nope
<Matt|> *laughs* ubuntu-desktop installs 61 new packages on my system
<GotD0t> it wanted to remove fglrx-control and fglrx-driver... somehow that seems wrong
<bob2> meh
<bob2> or just install gamin
<Matt|> ;)
<GotD0t> i did bob2 
<Matt|> perhaps gamin should be brought in by another package as well as ubuntu-desktop
<GotD0t> Matt|, perhaps it should be brought in along with the upgrade
<Matt|> that's what i mean
<bob2> if you remove ubuntu-desktop, you need to do this stuff manually
<GotD0t> Matt|, yea... because it was ridiculously slow... i couldn't burn a CD and talk to someone in gaim at the same time
<Matt|> hmm... i think its naive to expect everyone to put up with all the packages in ubuntu-desktop. However EVERYONE needs gamin right?
<bob2> no
<Matt|> well all gnome users anyway
<bob2> only people using ubuntu desktops ;-)
<Matt|> grrr damn you and your deliberate obtuseness
<bob2> there could be a good reason to install it, somehow
<Matt|> :p
<GotD0t> any of you know why I cannot run 3D games after my upgrade?
<Matt|> *laughs*
<Matt|> GotD0t, 3d graphics acceleration is not workin
<Matt|> you need to get that working
<GotD0t> well it crashes X
<Matt|> GotD0t, probably you should remove fglrx-control and fglrx-driver like it said ;)
<GotD0t> Matt|, really?
<GotD0t> Matt|, ok
<Matt|> GotD0t, wait for confirmation from someone else
<GotD0t> Matt|, oops...
<Matt|> GotD0t, what is your graphics card?
<GotD0t> Matt|, 9700 Pro
<Matt|> what make
<GotD0t> ATI
<Matt|> i think that xorg has its own drivers and so you won't need those non-free ones, but i'm not 100%
<GotD0t> well i hope so
<GotD0t> i installed xserver-xorg... do i need to restart X?
<Matt|> you haven't done that yet?
<Matt|> reboot the whole thing after a major upgrade is probably not a bad idfea
<Matt|> cross your fingers tho
<GotD0t> Matt|, well would you consider xserver-xorg to be a major upgrade?
<Matt|> GotD0t, you've just upgraded to hoary?
<GotD0t> Matt|, not today...
<GotD0t> Matt|, i had already rebooted after upgrading
<Matt|> well xorg comes with hoary
<GotD0t> well xorg-common was installed with it
<GotD0t> but not xserver-xorg
<Matt|> ok restart x
<GotD0t> k
<daniels> elmo: please install l-k-h b-ds in concordia chroot, comment on proposed 2728 fix, and install package in davis:~daniels/l-k-h to chroot if sensible.
<GotD0t> anybody have dual-head configured for hoary?
<tseng> holy crap, new monthly pr0n update
<tseng> s/crap/craaack
<calc> anyone happen to know about the ide chipset driver loading late issue on ubuntu warty?
<fabbione> morning guys
<calc> fabbione: hi
* lamont heads to bed.  night all
<Matt|> mjg59, around by any chance?
<jdub> thom: around?
<Kamion> any reason we don't have "install gamin" in HoaryUpgradeNotes? we just say to remove fam and portmap
<Keybuk> Kamion: dep of ubuntu-desktop
<Kamion> Keybuk: see #ubuntu, HoaryUpgradeNotes should document things for people who don't have ubuntu-desktop installed too
<Keybuk> ah
<daniels> gnar
<daniels> mdz: it appears that Synaptics touchpads happily respond to ALPS queries
<daniels> mdz: as well as normal Logitech mice
<daniels> mdz: i'm very much inclined to just ditch synaptics-alps-support.dpatch
<sivang> Kamion : is a daily iso of hoary suitable for laptop install? :) what's state is it in?
<Kamion> sivang: you can try, but I haven't tested since the last big round of changes
<Kamion> still in flux
<Kamion> feel free to use it if you don't mind if it breaks :)
<sivang> Kamion : ok, well, then I'll install warty and upgrade, this path I already taken and familiar with :)
<mvo_> amu: the kde-3.3.1-2 FTBFS seems to be fixable with a additonal b-d on "libxinerama-dev"
<daniels> mvo_: don't forget libxau-dev and libxdmcp-dev also, iirc
<daniels> i sent a mail about it, but used the wrong From, blah
<mvo_> daniels: so it awaits moderation now?
<daniels> yah
<mvo_> who is doing the moderation? mako?
<daniels> jdub, iirc
<daniels> i'll just send another one with the right from
<amu> mvo_: nope, you've to apply many selfwritten patches
<daniels> amu: ... what?
<daniels> you need to revert the debian-pic-shlibs patch or whatever it is
<daniels> but that and proper build-deps should do it
<amu> daniels: name of some of your xlib changed :)  
<daniels> yes, so just delete debian/patches/debian-pic-shlibs.patch, or whatever it is
<amu> daniels: not such easy
<daniels> how not?
<Matt|> guys I can't boot either the new 2.6.8.1 kernel in hoary, nor the 2.6.9 test kernel. I get a kernel panic straight away, with vfs error, unable to mount root on unknown block (0,0) or something similar. can someone help me with my grub?
<bob2> configure grub to use an initrd
<Matt|> bob2, problem is that i don't understand the grub config for this 2.6.9 kernel
<bob2> it will be the same as for the 2.6.8.1 one
<bob2> but with a different number at the end
<Matt|> bob2, the 2.6.9 line is commented out and it says in the wiki to leave it commented out
<Matt|> its really weird
<Matt|> can i PM you the menu.lst?
<bob2> #flood
<bob2> and this is a #ubuntu thing
<amu> daniels: i still got some errors ex. on kdm, the fast solution for me was, not to use kdm. Sure if you invest some work in it, you can fix them, but i've total no time for it now.   
<daniels> amu: kdm needs libxau-dev and libxdmcp-dev
<amu> daniels: and probably it was cause haggai said, he'll fix it.
<amu> daniels: yeah you told me this before ;)
<amu> daniels: sure it's a easy part, which someone must invest, but why i should fix it, i'm overloaded with work, it works for me, and haggai takes care about it, why i should invest my limited time for it? I just said in my mail, it isnt such easy you can solve the problem in 5min, cause of xorg 
* haggai reads backlog
<Keybuk> rofl
<Keybuk> Been using Sun's Java Desktop System as my day to day machine. It's surprisingly decent. Basically GNOME with alot of purple
<haggai> amu: btw I'm sitting in the same room as daniels at the moment :)
<amu> daniels: give haggai a clout from me :) 
<Matt|> *laughs*
<daniels> amu: dude, OOo takes longer to build than X
<daniels> amu: there's no way I'm punishing the poor bastard further
<amu> daniels: *g*   
<amu> daniels: nope i packages kde before, and if i cant solve it in 5min. you cannot do it also :) so if i say you need some time, you need it 
<daniels> i know a little about packaging kde ...
<amu> yeah i know ;) 
<amu> we bat a pizza ? 
<amu> s/bat/bet
<amu> aehm let say a nice dinner in spain 
<amu> daniels: ok? that a deal?  
<amu> haggai: he started? 
<haggai> amu: I'm making a chroot...
<ogra> guys....i am playing with a simplified services tool but i am nit sure what should be in the list of manageable services.... any suggestions ? : http://www.grawert.net/services.png
<sivang> ogra : looks nice, you're working on it?
<ogra> yes, currently....it has no backend...
<ogra> i am not sure if ssh should be in there
<sivang> ogra : oh well, the backend part could be relatively easy to implement, couple of calls to /etc/init.d/<service> {stop|restart|start} ?
<sivang> ogra : have you seend what gst offers in that regard?
<ogra> yes, i thought about invoke-rc.d
<ogra> sivang: way too heavy in my opinion....
<sivang> ogra : Ah, I see what you mean :)
<ogra> you know my bootoptions tool....i could put in a real load of grub options, but i only want to squash the common tasks....no real admin tools, just simplification as much as possible.....
<sivang> ogra : I see, seems nice and would probably help the clueless users to start services :) however I do see a place for gst in a larger setups, or in the less home more corporate deployments.
<ogra> sivang: i see this part of g-s-t as a real admin tool....nothing i would give a normal user, but fine for "real" admin tasks
<thom> jdub: que?
<Matt|> is bug 3138 likely to be assigned at all does anyone know?
<nobse> hi
<nobse> The following packages have unmet dependencies:
<nobse>   perlmagick: Depends: libmagick6 (= 5:6.0.2.5-1ubuntu1) but 5:6.0.2.5-1ubuntu1.1 is to be installed
<nobse> E: Broken packages
<nobse> are you aware of that?
<tseng> nobse: search bugzilla.ubuntulinux.org
<tseng> if you dont see it, file it
<nobse> Can I use reportbug?
<tseng> sure.
<nobse> ok
<tseng> does that still go to BTS?
<tseng> or bugzilla now
<nobse> ubuntu-users
<bob2> erm, are yo usure reportbug does anything useful on ubuntu?
<nobse> bob2: no, that's why I asked
<tseng> there is some branding, but i dont see anything that is similar to s/debian bts/bugzilla
<nobse> but the mail was sent to ubuntu-users
<nobse> btw, a fixed package is available in universe, but doesn't appear in Packages.gz
<RubenV> hmmm
<RubenV> does gstreamer need the gstreamer-ffmpeg package to be able to play any divx/xvid movie?
<RubenV> lately i'm finding more movies that don't work that those who do with gstreamer
<GotD0t> how do i reinstall grub? another operating system wrote over it and now its all fugly
<Mithrandir> GotD0t: grub-install /dev/hda should work
<GotD0t> Mithrandir, thanks
<GotD0t> so anybody know how to get my ATI 9700 pro 3D accelerated in hoary?
<thom> GotD0t: wrong channel
<GotD0t> thom, sorry... misread the tab
<daniels> elmo: please install l-k-h on davis if the packaging seems sane
<Matt|> is bug 3138 likely to be assigned at all does anyone know?
* magnon orders a golf shirt
#ubuntu-devel 2004-12-10
<thom> hrm, must get popcon setup finished
<lupus_> jdub, can you make a wiki for the UbuntuJava and UbuntuEclipse so I can add some interresting links and info?
<lupus_> I'm searching on developers blogs about related stuff
<thom> lupus_: dude, you can DIY
<lupus_> DIY?
<thom> do it yourself
<lupus_> see private plz
<sivan> mdz : ping
<mdz> sivan: pong
<thom> please don't send me private messages, they're completely useless to everyone else
<lupus_> I don't want to flood :)
<thom> and if you can't sign up, you're not gonna be able to edit pages either, so i suggest you send mail to webmaster@ubuntu.com with your problem
* thom goes to bed
<sivan> mdz : what's up? :) I have reinstalled Ubuntu on the laptop, this time with ext3, currently upgrading to hoary..disk operations seems again very very slow , did you have any insights regarding this? :)
<sivan> mdz : the thing is, I recalled you said something about overheating..But the fan seems to start work and stop in a "normal" way...do we have any fixed kenrel to use on hoary or anything else that might help?
<mdz> sivan: can you follow up to Bugzilla instead?
<sivan> mdz : yes sure ! :)
<mdz> someone else reported a similar problem, but I couldn't find your bug at the time
<sivan> mdz : sorry for even bringing this up on the irc bit disposal medium :)
<lupus_> wasn't there an issue with hal
<lupus_> that made hd very slow
<lupus_> http://article.gmane.org/gmane.comp.freedesktop.hal/1184/match=+slow
<lupus_> don't know if it is related
<jdub> hrm, OOo powerpc failed :|
<tseng> x86 still going?
<mdz> jdub: already in bugzilla
<mdz> tseng: i386 and amd64 still pending
<magnon> yay, ubuntu golf shirt on its way.
<GotD0t> magnon: haha
<spotter> anyone awake?
<mdz> yes
<spotter> think I found a bug in nautilus or something, unsure which really
<spotter> basically gnome-volume-manager works correctly when i insert a DVD
<spotter> i.e. mounts it and launches totem
<spotter> but then when I open the mounted desktop icon, it just opens it in nautilus, and doesn't start totem
<spotter> seems wrong
<spotter> seem to recall it working correctlhy w/ 2.8 out of debian experimental (well, gnome-volume-manager didn't work, but playing a mounted DVD via nautilus did)
<spotter> mdz: seems wrong to you too?
<mdz> spotter: you just filed a bug in bugzilla about this
<spotter> yes
<spotter> sheesh, you check up on me
<mdz> I read bugs as they come in
<spotter> that could lead to lots of mail in the future
<spotter> :)
<mdz> it is already a lot of mail
<mdz> anyway, seb128 will look at it tomorrow
<spotter> a new bug about to be filed
<spotter> music view doesnt seem to work in nautilus either
<spotter> should I make sure to say this is all hoary?
<spotter> or is that sort of assumed?
<mdz> it's a good idea to mention which release you are running
<spotter> and not set target milestone myself :-[
<spotter> :)
<fabbione> mdz: that kernel upgrade problem.
<fabbione> does it look like this:
<fabbione> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281953
<fabbione> ?
<mdz> yes, it does
<fabbione> it claims to be fixed in our packages
<mdz> yes
<mdz> Buildinfo: "This was produced by kernel-package version 8.114ubuntu1."
<mdz> that is what linux-image-2.6.8.1-3-powerpc_2.6.8.1-19_powerpc.deb says
<fabbione> so either the merge or the fix is wrong
<mdz> merge looks fine
<mdz> http://people.ubuntulinux.org/~scott/ongoing-merge/kernel-package/kernel-package_ubuntu.debdiff
* lamont wanders in, waves, heads for bed.
<mdz> lamont: what happened with alsa-driver?
<fabbione> night lamont
<mdz> there has been another kernel-package upload to unstable, though
<mdz> nothing in the changelog about fixing the fix, though
<lamont> mdz: what happened?
<mdz> lamont: it seems like you did a merge (1.0.6a-10ubuntu1) and then overwrote it with a sync (1.0.6a-11)
<lamont> oh.
<lamont> that
<mdz> it's in bugzilla, worry about it tomorrow
<lamont> ISTR it looked like -11 had all of our diff from 10ubuntu1
<lamont> yeah.  will actually look at it tomorrow
* lamont never had the doors frozen shut on his car before today.  Most, um, interesting.
<lamont> but to sleep
<mdz> it is at the least missing the unmuting magic
<fabbione> mdz: i need a way to reproduce that bug
<mdz> fabbione: all that I can provide tonight is a transcript of the upgrade
<mdz> tomorrow I will try to burn a powerpc and recover the system
<mdz> but currently it is unbootable
<fabbione> ok
<mdz> let me know if you would like the transcript
<mdz> it contains the kernel-package output
<mdz> The link /boot/initrd.img is a dangling link
<mdz> Removing symbolic link /boot/initrd.img
<mdz>  you may need to re-run yaboot
<fabbione> well i am not even sure i will have the time to fix it before Mataro
<mdz> Not touching initrd symlinks since we are being reinstalled (2.6.8.1-17)
<mdz> there is the bug
<mdz> well, I don't understand the first part either
<fabbione> neither do i
<mdz> but in any case it should have fixed the symlink in postinst
<mdz> I think perhaps the fix was not correct
<fabbione> i tend to agree on that
<mdz> does anyone here know yaboot?
<mdz> if it is possible for me to specify an alternate initrd location, I should be able to get the system up and investigate
<fabbione> no, but i can explain to you about silo :P
<mdz> from my reading of the postinst, if it emitted that message, it must have already generated the initrd
<mdz> so it seems like there must be a /boot/initrd.img-<ver> but no /boot/initrd.img symlink
<fabbione> mdz: let me see a yaboot manpage
<mdz> I know it is possible to specify the path to the kernel
<mdz> I don't see anything in the man pages about it
<mdz> kamion might know
<fabbione> http://penguinppc.org/bootloaders/yaboot/
<fabbione> mdz: i think you can specify the initrd as easy as you specify the kernel patch
<fabbione> ehm
<fabbione> path
<mdz> I don't see how
<fabbione>          boot: hd:3,/vmlinux root=/dev/hda3 ro
<mdz> with the kernel, you write the path to the kernel at the boot: prompt
<mdz> right
<fabbione> initrd is a kernel parameter, isn't it ?
<mdz> but then it gets the initrd path from yaboot.conf
<mdz> no, the initrd must be read by the boot loader
<fabbione> hmmmmm
<fabbione> i am not sure
<mdz> I am trying to figure out why initrd.img was a dangling link
<mdz> that makes no sense
<mdz> because the system booted before that
<mdz> kernel-package seems overcomplicated for what it does
<mdz> with 2.6 and only Ubuntu architectures, it could be much simpler
<fabbione> mdz: no
<fabbione> the initrd.gz is a kernel parameter
<fabbione> label linux
<fabbione>         kernel debian-installer/i386/linux
<fabbione>         append DEBCONF_PRIORITY=critical vga=normal initrd=debian-installer/i386/initrd.gz ramdisk_size=12314 root=/dev/rd/0 rw  --
<fabbione> so you can add it after
<mdz> if it is passed to the kernel, the kernel ignores it.  it will only work if the boot loader parses the command line and reads the initrd
<mdz> I'll try
<fabbione> brb
<mdz> tried, doesn't work
<mdz> still tries to load plain initrd.img
<mdz> I can burn a CD tomorrow to get it fixed, just not tonight
<mdz> I don't think I will be able to find much, though
<mdz> somehow the symlink became dangling, but I have no idea what it was pointing to
<mdz> certainly the initrd.img-<ver> was there before, because the system booted
<mdz> maybe /etc/kernel-img.conf was changed somehow
<magnon> hm, what uses gnome 1 libraries in ubuntu anyway?
<mdz> magnon: some packages in universe
<mdz> hmm, some in main too
<mdz> but not in the default desktop install
<mdz> we tried to get rid of those which could be easily eliminated
<magnon> yeah, I just discovered that having them around can be a little confusing when installing packages
<fabbione> mdz: the only thing i can think about is that the initrd image is generated in postinst
<mdz> I just noticed this
<fabbione> mdz: probably the prerm script removes it?
<mdz>   if (-f $realimageloc . "initrd.img-$version") {
<mdz>     unlink $realimageloc . "initrd.img-$version";
<mdz>   }
<mdz> why the hell does it do that?
<mdz> (this is in postrm)
<fabbione> is it inside a if [ "$1" = "purge" ]  ?
<fabbione> or does that unconditionally?
<mdz> if ($ARGV[0]  !~ /upgrade/) {
<fabbione> hmmm
<mdz> I don't think that is related, but it is such a bad idea
<fabbione> Manoj is awake.. let's talk with him
<mdz> freenode or oftc?
<fabbione> here
<pitti> Morning folks
<fabbione> morning pitti
<doko> morning all!
<fabbione> hey doko
<fabbione> thanks for pushing new libc6 :-)
<fabbione> my buildd hates you now :P
<fabbione> mdz: ok.. what should we do with the kernel?
<fabbione> should we wait Manoj to fix?
<fabbione> should we start working on 2.6.9?
<fabbione> hmm
<fabbione> mdz_: i guess you didn't read above, did you?
<doko> fabbione: hey, it did even build on all supported archs ;)
<fabbione> doko: SCARY!
<pitti> elmo: please sync cyrus21-imapd 2.1.16-11
<jdub> jamesh: did you have a poke at that gnome-vfs patch?
<jamesh> jdub: the HAL one?
<jdub> mtools
<jamesh> no
<jamesh> is there a bugzilla id for the patch?
<jdub> not sure, i sent a link to the mailing list archive post, though
<pitti> Kamion: I'd like to fix #4093; any objection if I upload a new base-config?
<pitti> mdz_: still here?
<mdz_> pitti: barely
<mdz_> fabbione: lost power
<pitti> mdz_: okay, it's not that urgent
<fabbione> mdz_: no problem
<fabbione> <fabbione> mdz: ok.. what should we do with the kernel?
<fabbione> <fabbione> should we wait Manoj to fix?
<fabbione> <fabbione> should we start working on 2.6.9?
<mdz> 2.6.9 should happen soon
<mdz> do you have time to do it?
<fabbione> mdz: i think so..
<mdz> Manoj will examine the bug, so we can wait and see what he says
<fabbione> i can spend max 2 working days in 2.6.9 in this week
<lucas_> Hi
<lucas_> Kamion: you there ?
<lucas_> I finally went for the solution of hacking the pool by adding my packages in it
<lucas_> then regenerate */Packages with apt-ftparchive
<lucas_> however, d-i's Package need installer-menu-item headers
<lucas_> I don't know how to generate them
<lucas_> any ideas ?
<lucas_> s/d-i's Package/d-i's Packages/
<lucas_> mhh actually that's not my problem
<lucas_> but I don't know what my problem is :)
<seb128> morning
<pitti> Hi seb128!
<seb128> hey pitti 
<pitti> Hi sivang!
<Kamion> fabbione: I suspect that the bug was actually in the older kernel packages, but we only noticed the bug when we upgraded
<Kamion> mdz: sorry, it's not possible to specify an initrd at yaboot's command line
<Kamion> lucas_: those are all in the .udebs, apt-ftparchive should copy them into Packages; if it doesn't, investigate why
<fabbione> Kamion: yes, we had a long discussion with Manoj in #d-d
* fabbione is preparing 2.6.9
<pitti> fabbione: does it contain inotify?
<Kamion> fabbione: is that what Manoj said then?
<fabbione> pitti: easy.. i just unpacked the orig
<pitti> fabbione: oh, okay
<fabbione> Kamion: yes
<pitti> fabbione: will you go to vacation while it builds? :-) 
<fabbione> pitti: ehhe
<fabbione> pitti: do you use dpatch for any of your packages?
<fabbione> or who does?
<pitti> fabbione: not for my own ones, but I'm quite used to it
<fabbione> pitti: ok.. how can i do an anal check of the patches?
<pitti> fabbione: the current hoary version seems to be broken (dpatch-edit-patch)
<pitti> fabbione: do you mean that?
<pitti> fabbione: ahem? Mind to explain that?
<fabbione> last time i added a duplicate patch, dpatch managed to apply both with no errors
<pitti> fabbione: ugh, it should fail then
<fabbione> but clearly compilation failed
<fabbione> it didn't
<pitti> fabbione: usually I try with debian/rules patch
<Kamion> fabbione: did anyone check whether this affects direct upgrades from warty to hoary?
<fabbione> Kamion: not yet.. in anycase new packages will have to deal with it
<fabbione> Kamion: possibly also in security update
<fabbione> Kamion: that means uploading a new kernel-package for hoary
<fabbione> but both mdz and I will wait for Manoj to investigate properly when kernel-package got broken
<fabbione> there is a good chance that warty is ok
<fabbione> the problem might have appeared the 21st of Oct
<daniels> fabbione: where do you want the extra patches?
<daniels> (kernel)
<fabbione> daniels: people?
<daniels> k
<daniels> fabbione: p.u.c/~daniels/l-i/
<daniels> "
<fabbione> daniels: where did you grab these patches?
<daniels> fabbione: most of them were tarballs from external websites designed to built externally that I modified to build in-tree
<fabbione> ok
<fabbione> now.. this is funny
<fabbione> in 2.6.9 if i do ./debian/rules clean it trashes the debian directory...
<Kamion> fabbione: the maintainer scripts for -16 and -16.1 are identical
<Kamion> fabbione: I don't have -17 and -18 to check those, though
<fabbione> -18 is garbage
<fabbione> -17 is in the morgue
<fabbione> on jackass 
<daniels> the morgue is mirrored to rookery, btw
<Keybuk> when elmo pushes the button ...
<daniels> i don't know how regularly, but it's certainly there
<daniels> yeah
<fabbione> interesting
<fabbione> it's make-kpkg
<fabbione> ehhe
<fabbione> kernel people are really funny
<pitti> sjoerd: ping
<Kamion> fabbione: ah, yes, looks like -16 was OK, an 'exit 0' was moved down a paragraph by -17
<fabbione> Kamion: cool
<pitti> Kamion: Hi! do you think Debian's base-config can still be fixed to put the initial user into plugdev and camera?
<Kamion> pitti: that depends; persuade joeyh
<Kamion> there's still time, sure
<pitti> Kamion: okay, I will ask him
<fabbione> 2.6.9 is another monster patch orgy
<daniels> OH FRIG
<daniels> usr/X11R6/lib/libXRes.so.1.0 usr/X11R6/lib/libXres.so.1
<Mithrandir> daniels: ew.
<Mithrandir> thom: could mod_rewrite cause performance problems or is it just ugly?
<daniels> thom: it is sssssssssssllllllllllllllooooooooooooooooooowwwwwwwwwwwwwwwww
<daniels> s/thom/Mithrandir/
<Mithrandir> daniels: ok, so I'll look into getting rid of it.. I hope the people responsible doesn't kill me.
<daniels> Mithrandir: ah, a vic^Wdistro team member
<daniels> Mithrandir: do you want to test some xorg packages before I upload?
<Mithrandir> not really, I have a server which needs booting. :P
<daniels> heh
<azeem> mako: hey, did they force you into dropping docbook for presentations, or did switch to OOo Impress yourself? :)
<azeem> mako: the GNOME icon you used for the 'pope-slide' has been deprecated for a couple of years I believe, they have a slightly different one now
<pitti> daniels: ping
<daniels> pong
<sjoerd> pitti: pong
<pitti> sjoerd: just FYI, I had to introduce another patch
<sjoerd> pitti: for ?
<pitti> sjoerd: I fixed the hal -> 20hal transition to not ask a dpkg conffile question on upgrade
<sjoerd> hrm, does it do that ? didn't when i tested
<pitti> sjoerd: I just remove the old file if it is unmodified
<pitti> sjoerd: it works as long as a new package comes along with the same conffile as the old one
<pitti> sjoerd: but my merged package has a different conffile (LSB, remember)
<sjoerd> aha
<pitti> sjoerd: so it first mv'ed the old conffile to the new
<pitti> sjoerd: then tried to replace it with the one shipped in the package
<pitti> sjoerd: if you modify the file in the future, this will hit you as well
<pitti> sjoerd: well, Debian folks are used to these questions, but Ubuntu must avoid them in all cases
<sjoerd> right
<Kamion> Ubuntu's not going to be able to avoid them in all cases. We can and should avoid them for upgrades of default installations, but they can't be avoided when people have actually changed the conffiles.
<azeem> it would be nice to have the dialog use the respective debconf-frontend eventually, though
<sjoerd> pitti: as sarge will release with a transitioned hal, it wouldn't be a problem imho (as in you won't get the question on a sarge -> etch upgrade)
<sjoerd> pitti: but thanks, one patch less to check out next time :)
<pitti> sjoerd: yes, right
<Kamion> azeem: (if debconf is installed - debconf isn't Essential: yes and dpkg never relies on it)
<azeem> Kamion: sure
<Kamion> pitti: you might want to look at Debian's current openssh packages for a warty update
<Kamion> pitti: (information leak)
<Kamion> I'm doing the hoary build now
<pitti> Kamion: thanks, I'll do
<pitti> Kamion: hasn't there been a DSA?
<Kamion> pitti: no, don't believe it affects woody although I could be wrong
<Kamion> heh, it does
<pitti> Kamion: I did not see anything on full-disclosure, I will look at the changelog and interdiffs
<pitti> Hi mjg59 
<Kamion> I'm not sure that the Debian security team is all that bothered about information leaks in woody though
<Kamion> pitti: it's an old issue, you won't have seen it recently
<pitti> Kamion: any bug report?
<Kamion> pitti: Debian #248747, #281595; corresponding Ubuntu #4196, #3768
* thom growls at the ludicrously huge courier diff for init prettiness
<pitti> Kamion: ah, that one. Thanks
<thom> morning, y'all
<pitti> Hi thom
<fabbione> thom: hey
<fabbione> who is the acpi guru?
* thom points at mjg59 very fast
<mjg59> Haha
<fabbione> ahah
<fabbione> do we need this patch acpi-20040826 for 2.6.9?
<mjg59> No
<mjg59> We need something newer...
<fabbione> mjg59: to start with, is it good enough what is in 2.6.9 or we will have regressions?
<jdub> fabbione: oh, you're integrating suggested patches in your 2.6.9 update?
<fabbione> jdub: no
<jdub> d'oh.
<fabbione> i am trying to get a 2.6.9
<thom> damn, was just about to ask for inotify
<jdub> what are the chances of tempting you to integrate inotify in this release? :)
<fabbione> and i am only revisiting the patches that we applied to 2.6.8.1
<fabbione> jdub: <0
* thom ^5 jdub
<jdub> and mjg59's acpi patches
<fabbione> i doubt 
<fabbione> not for the first release at least
<Kamion> fabbione: are you merging with Debian's kernel-source-2.6.9?
<fabbione> Kamion: yes
<Kamion> good
<fabbione> that too
<mjg59> fabbione: Hang on, let me check what I put in
<Kamion> hm, if nothing else their new patch-series system looks a lot easier to handle than the mad thing we have at the moment where you can't upload a new version without adding another 00list-* file
<mjg59> fabbione: Ok, I dropped the 20040826 patch
<thom> yeah, the current ubuntu packages are a bitch to work with
<fabbione> Kamion: right now i am only trying to get all the parches either to apply or out of the way
<fabbione> Kamion: all the other stuff will come later on
<fabbione> i am stil merging -1 from debian
<jdub> hrm
<Kamion> sure
<mjg59> fabbione: We'll want newer acpi than is in 2.6.9, and we'll want a pile of swsusp code
<jdub> what's with openoffice.org finishing its build on i386, but not being in the archive?
<fabbione> mjg59: ok
<jdub> and inotify
<jdub> did i mention we needed inotify?
<fabbione> jdub: yes and the answer is no
<fabbione> not for this release
<mjg59> fabbione: "this release" meaning Horay, or just the first cut of the packages?
* jdub keeps picking on fabbione 
<jdub> mjg59: there won't be much horay if we don't have inotify in hoary -> ha ha ha!
<seb128> liboil0.2-dev and libswfdec0.3-dev from universe needed to build gst-plugins 0.8.6
<Kamion> mjg59: first cut I'd imagine
<mjg59> jdub: Argh
<fabbione> mjg59: first cut
* thom kicks jdub
<thom> that was terrible
<jdub> here to serve you :)|
<jdub> and the veal
<jdub> i am also serving veal
<jdub> be here all week
<seb128> jdub: if
<jdub> so will the veal
<seb128> oups
<jdub> don't have the veal on friday
<jdub> it will kill you
<jdub> hi Md 
<mjg59> Hmm.
<seb128> jdub: for "liboil0.2-dev and libswfdec0.3-dev" ... they need to be added to main before the gst-plugins upload ?
<mjg59> The Intel people need one of these laptops that breaks.
<Kamion> seb128: that's what dep-wait's for
<robtaylor> mjg59: i was playing around with the init-ec patch last nithg.. unformatiately i now cant remeber where i got it from :/
<Md> who wrote the default firewall script? If it has not been fixed before the release, I noticed that it filters multicast packets
<Kamion> we have a default firewall script?
<mjg59> init-ec?
<seb128> Kamion: right
<mjg59> robtaylor: Can you stick a copy of it up somewhere?
<Md> Kamion: I have seen on the newly installed system of a friend that IGMP packets from his ISP were filtered and logged, so I suppose that there is one
<Kamion> Md: last I checked we didn't install a firewall at all
<robtaylor> mjg59: unfortuantly its on my laptop, not here. i'll put it somweher tonight (and i'll try and mangle it for 2.6.8.1 as well)
<jdub> seb128: yeah, i would support those
<haggai> jdub: OOo isn't built on powerpc, doku forwarded the (strange) error.  Would that stop it from being installed in the archive?
<jdub> haggai: not sure why it would
<jdub> lamont: ping?
<mjg59> robtaylor: What was it supposed to do? Additional embedded controller setup?
<robtaylor> mjg59: yeah, seemed to do some extra scanning. i'd tell you more if i had it in front of me =)
<robtaylor> (gah, rellay wish i could remember which bugzilla it was in =))
<thom> jdub: should a libfam-dev change to libgamin-dev |libfam-dev ? can i get away with doing just that?
<elmo> or'ed build-deps make baby jesus cry - why not just drop libfam-dev?
<thom> or that
<Keybuk> yeah, how's the buildd supposed to know which one is preferred?
* sid77 hi!
<Kamion> Keybuk: that much is trivial; first is always preferred
<jdub> thom: yeah
<Mithrandir> Keybuk: libfam-dev won't be in main, so it won't be preferred. :)
<Keybuk> Kamion: sure, but how does it know to remove libfam-dev if it had it installed in favour of the first one in the list?
<robtaylor> mjg59: ok, heres some relevent sounding patches i';m trying out http://bugme.osdl.org/attachment.cgi?id=4124&action=view andhttp://bugme.osdl.org/attachment.cgi?id=1757&action=view 
<jdub> on epiphany-list:
<jdub> I want to thank you guys for the work behind Epiphany. I just got
<jdub> acquainted with Gnome and its HIG guidlines by way of trying Ubuntu. I
<jdub> had not used Gnome as such since somewhere around Red Hat 7.3, and
<jdub> must say the change in policy is just spot-on.
<jdub> 
<Keybuk> robtaylor: bug#s ?
<mjg59> robtaylor: Do you have the bugs these are linked from?
<robtaylor> mjg59: all from http://bugme.osdl.org/show_bug.cgi?id=1744
<seb128> is there anything to consider before changing a package source-name ? 
<seb128> or I just upload it with the new name ?
<pitti> Kamion: do you think these openssh issues should be fixed in Warty? They do not look very severe
<Kamion> Keybuk: true
<Kamion> pitti: up to you, don't mind either way personally, just thought you should know
<pitti> Kamion: I prepare a package and wait for some days
<pitti> Kamion: in the meantime the Hoary and Sid packages can be tested by a broader audience
<Kamion> ok, we'll see how it goes; it's a fairly isolated patchset
<pitti> Kamion: by "isolated" you mean few/no side effects?
<pitti> Kamion: testing the fixed functionality itself is easy
<Kamion> both that and well away from other patches
<Kamion> merging to 3.9p1 will be more entertaining, mind :)
<robtaylor> mjg59: so what do you reckon to those patches? think they'll help the issue you were talking about last night?
<mjg59> Doubtful
<robtaylor> ah well :)
<mjg59> We don't get any EC errors on the craptop
<mjg59> But yeah, it could be because some piece of hardware isn't enabled
<mjg59> OH CHRIST WHY IS THERE A HELICOPTER OVERHEAD?
<robtaylor> THEY'VE COME FOR YOU
<lucas__> Kamion: I've a problem with my custom Ubuntu
<lucas__> anna complains about a "bad d-i Packages file"
<lucas__> I don't quite understand the "retriever" concept in the anna source
<Kamion> it's a general interface for anna to get udebs from cdrom/network/whatever
<Kamion> perhaps your Release file is wrong
<Kamion> also try 'debconf-get mirror/suite' on tty2, make sure that's set to warty
<Kamion> or stable
<lucas__> ok
<Kamion> if it's stable, make sure that the CD has a /dists/stable symlink
<lucas__> one of the things I changed
<lucas__> is that I don't have a restricted/debian-installer/binary-i386/Packages
<Kamion> nor do we?
<lucas__> since I merged restricted, universe and multiverse into  main
<lucas__> ah true
<Kamion> udpkg doesn't know how to merge multiple d-i Packages files, so it's only possible to have main/debian-installer/binary-$arch/Packages at the moment
<bob2> lucas__: <obwarning>make sure you check you can distribute that at all</obwarning
<Kamion> especially for multiverse
<lucas__> yup, I'm not going to distribute much of multiverse
<lucas__> stuff like scilab or graphviz mainly
<lucas__> debconf-get mirror/suite returns nothing
<Kamion> ok, do you have /dists/stable/Release?
<lucas__> ye
<lucas__> s
<bob2> 'It's also necessary to take steps like limiting the number of pages currently queued for writing out. This limit will affect users, in that it will reduce performance. It has been noted, however, that deadlocks tend to have an even worse impact on performance.'
<Kamion> that suggests a problem in cdrom-detect BTW
<lucas__> (stable is simlinked to warty)
<Kamion> lucas__: see mdz's comment at the end of https://bugzilla.ubuntu.com/show_bug.cgi?id=2640; does that help you?
<Kamion> you may have a CD drive with DMA problems
<lucas__> no, DMA is ok
<lucas__> my Release file isn't
<Kamion> missing Suite: line?
<lucas__> yes
<Kamion> that'd do it
<lucas__> thanks a lot for the pointer :-)
<lucas__> Kamion: I'm using apt-ftparchive to generate the Release file, but I can't find any option to specify Origin, Label, suite, Codename. Is there a better way ?
<Kamion> lucas__: afraid I don't know
<lucas__> ok, I just added the Suite line by hand
<Kamion> lucas__: it appears to be documented quite clearly in the apt-ftparchive man page, though
<Kamion> lucas__: search case-insensitively for "suite"
<lucas__> oh true sorry
* pitti laughs about the new image at http://www.sco.com
<pitti> Hey, do these guys have a new PR strategy? :-)
<bob2> 'honesty in advertising' ;-)
* Kamion brushes up his i386 assembly
<zul> morning
<whiprush> does gnome-user-share not have a bugzilla component yet? Should I file a bug under Nautilus instead?
<lamont> jdub: oo.o will inter the archive in about 10 minutes.  patience..
<lamont> well, i386 will.  ppc has, um, issues
* lamont bbl
<jdub> lamont: :)
<elmo> speaking of oo.o why does it b-d on libneon23-dev?  that means we can't have oo.o and tla build-deps in the same chroot :(
<jdub> lamont: when you're back -> why so long between the build finishing and hitting the archive?
<elmo> jdub: it was NEW
<jdub> oh
<elmo> doko: done
<lucas__> Kamion: debconf-get mirror/suite says warty now
<lucas__> but it still doesn't work
<lucas__> /var/cache/anna/Packages is empty
<Kamion> sorry, I'm kind of buried in grub debugging right now
<Kamion> I would suggest looking through the cdrom-retriever source and trying bits of it by hand
<Kamion> you're going to need a Components: line, certainly
<lucas__> in the Release file ?
<Kamion> yes
<Kamion> the retriever should probably error out if there are no components
<jdub>   openoffice.org-l10n-en: Depends: language-support-en but it is not installable
<jdub> d'oh
<lucas__> Oh I missed that
<lucas__> thanks again
<Kamion> np
<seb128> jdub: any opinion if we should use the smooth engine from gnome-themes or from the gtk-smooth-engine package ?
<jdub> seb128: hrm
<seb128> jdub: gtk-smooth-engine has been moved to universe during the warty time. But Josselin don't want to use the gnome-theme one (he says than the engine in gnome-theme are often outdated and we should better keep the gtk-smooth-package) 
<seb128> jdub: since I'm going to sync gnome-theme dunno what to do :)
<jdub> seb128: i imagine debian will go with the non-gnome-themes package, and it sounds like the best choice ;)
<seb128> ok, done so :)
<seb128> should be update a seed to get gtk-smooth-engine back in main ?
<seb128> s/be/we/
<jdub> yeah
* thom shakes his fist at npmmcallum
<pitti> jdub: this dependency bug is not that serious; the package depends on oo.o | language-support, so it's only a non-default alternative
<pitti> thom: troubles with LSB init scripts? :-)
<thom> pitti: yeah
<pitti> jdub: I delayed the upload of the language-support package until we have a decision 
<thom> i've been on #1580 the whole day
<jdub> pitti: can't install it with apt, though
<pitti> thom: I hope that Debian adopts the idea after Sarge release
<pitti> thom: it's a good concept
<pitti> jdub: but if you can't install then the fault is the OO.o version, not the language-support package
<haggai> elmo: neon23->24 was too big a change.  _rene_ looked at it
<thom> pitti: agreed entirely
<jdub> pitti: thus the bug ;)
<thom> if not just to stop us having to merge them every time :-)
<pitti> jdub: ? but without the alternative dependency the installtion would fail as well
<haggai> jdub: you should be able to install with apt, it's never been a problem in the past
<haggai> unless something else has been broken
<jdub> $ sudo apt-get install openoffice.org openoffice.org-bin openoffice.org-debian-files openoffice.org-l10n-en openoffice.org-thesaurus-en-us ttf-opensymbol
<jdub> ...
<jdub> The following packages have unmet dependencies:
<jdub>   openoffice.org-l10n-en: Depends: language-support-en but it is not installable
<jdub> 
<haggai> eh?
<elmo> haggai: yeah, but oo.o includes glibc in it's source, why not neon? :P
* haggai peers at source
<jdub> Depends: language-support-en
<haggai> elmo: heh, oh yeah it does include it :P
<jdub> ^ that'd be it
<seb128> jdub: where are made the seed changes nowadays 
<haggai> elmo: its' just we don't build against it
<jdub> seb128: in arch
<haggai> elmo: we had a lovely security bug..
<jdub> seb128: i'll do it for you
<jdub> seb128: just gtk2-engines-smooth ?
<seb128> jdub: thanks :) gtk-smooth-engine and "liboil0.2-dev libswfdec0.3-dev" for gst-plugins
<seb128> jdub: oups, gtk2-engines-smooth yes
<haggai> jdub: I don't see that Depends: in our CVS, it must have been added by someone else
<pitti> jdub: for met it is "Depends: openoffice.org (>> 1.1.1+1.1.2) | language-support-en", as it should be
<haggai> pitti: but we removed the Depends completely
<jdub> elmo: so if a package in main is uploaded with new depends, we have to put those depends in the seed temporarily so the package in main will build?
<pitti> jdub: if this is from a new version, somebody screwed up the dependencies
<haggai> pitti: for tasksel
<elmo> jdub: um, either that, or I have to ignore the seeds and promote them
<elmo> this is why I think doing the component isolation stuff at the buildd level is the wrong place to do it
<jdub> elmo: do you mean that you reckon the buildds should have access to universe and multiverse all the time?
<elmo> yes, I think they should and we should enforce consistency at a higher level
<pitti> haggai, jdub: I still don't understand. Which package has this dependency "Depends: language-support-en"
<jdub> pitti: l10n-en
<jdub> 1.1.3-2.3ubuntu3
<jdub> elmo: can you ignore the seeds and promote those two libs?
<pitti> jdub: 1.1.2dfsg1-2ubuntu2 is correct
<pitti> jdub: whoever uploaded 1.1.3 screwed up the dependencies then
<jdub> pitti: wanna reassign that bug to doko? :)
<pitti> jdub: he should still have this hog on his hd
<pitti> jdub: I don't really want to download OO.o sources just for this change
<pitti> doko: ping
<jdub> pitti: yeah
<elmo> jdub: which two ?
<elmo> oh, nm
* thom fixors courier and keeps going
<elmo> done
<fabbione> elmo: can you install linux-source build-dep on hoary chroot (concordia), please?
<fabbione> and kindly be sure that kernel-wedge is ubuntu5 
* fabbione kicks DPATCH
* pitti agrees to fabbione
<fabbione> JEEEEEE
<fabbione> i have spent 6 and more hours cleaning up patches
<fabbione> and that fucker still didn't get it right
<zul> heh..
<fabbione> now there are bits and pieces in the .diff.gz
* thom hugs dpatch and tells it to ignore fabio
<fabbione> thom: wanna fix it for me?
<thom> nope :P
* fabbione isn't suprised
<thom> you wouldn't give me inotify love :P
<azeem> fabbione: fixing that is easy when using dpatch: just mv the debian/ tree away, rm -r the source, unpack the orig.tar.gz and mv debian/ back in
<elmo> fabbione: done
<fabbione> azeem: oh yeah... i want to see now how many patches will fail to apply because of that
<fabbione> elmo: thanks
* fabbione switches the kernel to use dbs
<fabbione> or even better
<fabbione> manual patching
<thom> yada!
<elmo> the kernel's use of dpatch is particularly 'special'
<elmo> and not really representative of dpatch in sane packages
<azeem> thom: yada is more like cdbs?
<azeem> fabbione: did you try quilt?
<fabbione> elmo: did you ever see my name associated to *sane* packages? ;)
<thom> yada is more like death, as far as i can make out
<seb128> $ LC_ALL=C dpkg -S /usr/include/X11/XKBlib.h
<seb128> dpkg: /usr/include/X11/XKBlib.h not found.
<seb128> gni ?
<fabbione> seb128: libkbdfile-dev ?
<elmo> seb128: s#/##
<seb128> fabbione: not installed
<seb128> $ ls -l /usr/include/X11/XKBlib.h
<seb128> -rw-r--r--  1 root root 31130 2004-11-18 16:40 /usr/include/X11/XKBlib.h
<seb128> WTF
<seb128> fabbione: oh, ii  libxkbfile-dev           6.8.1-1ubuntu3           X Keyboard Extension file parsing library development files
<elmo> oh, they fixed that - never mind
<seb128> (you made a typo in the name)
<jdub> hrm
<jdub> no OOo gnome packages
<elmo> universe-by-default ...
<jdub> oh
<seb128> fabbione: 
<seb128> $ dpkg -L libxkbfile1 | grep XKBlib.h
<seb128> $
<jdub> but they're in the seed
<Keybuk> w00t!  we have the bonobo-slay branch of nautilus now
<seb128> arg
<jdub> oh
<jdub> no they're not
<seb128> $ dpkg -L libxkbfile-dev | grep XKBlib.h
<seb128> $
<fabbione> seb128: there is also anotherone kbd related..
<seb128> ok, anybody with a XKBlib.h coming from a package ? It's needed for libxklavier
<fabbione> seb128: let me remember
<seb128> fabbione: I don't understand how I can get this file coming from nowhere
<seb128> fabbione: and libxklavier used to build and today's upload FTBFS
<fabbione> libx11-dev: /usr/X11R6/include/X11/XKBlib.h
<fabbione> doh!
<seb128> gni ?
<fabbione> gni?
<fabbione> what that means?
<seb128> why in libx11 and not libxkb* ?
<fabbione> seb128: ask daniels
<seb128> daniels: ping ?
<fabbione> seb128: otherwise just open a big bug
<seb128> fabbione: "gni ?" is a sort of interrogation :)
<jdub> mmm, OOo gnome integration :)
<fabbione> that will pull in another bunch of FTBFS!
<seb128> kind of "what's going on" 
<fabbione> that's sooooo coooool
<jdub> seb128: the knights who say, "gni!"
<jdub> _rene_, haggai: YUM!
<haggai> jdub: :)
<jdub> gute nacht alles
<pitti> jdub: Gute Nacht!
<pitti> jdub: However, it's not "alles" :-)
<pitti> jdub: "Gute Nacht an alle" is better :-)
<jdub> thanks :)
<pitti> your're welcome
<pitti> jdub: we should start to exercise Spanish anyway 
<jdub> yeah
<jdub> estoy buscando mis pantalones
<pitti> ???
<jdub> some spanish you *need* to know
<jdub> it's very useful
<carlos> pitti: http://archive.pemas.net/GNOME/GUAD3C/guad3c.ogg
<jdub> night :)
<pitti> jdub: and it means?
<carlos> look that video and you will understand it :-P
<carlos> jdub: night!
<pitti> carlos: argh
<pitti> carlos: 124 MB? This will take me a while
<carlos> pitti: The translations is: "I'm looking for my pants"
<pitti> I should have known
<pitti> carlos: I can barely count to ten now, thanks to my gf
<carlos> it comes from the GUADEC 3 (or there's the first time I saw jdub saying that :-P)
<carlos> pitti: :-P
<pitti> carlos: btw, do you offer rentals for playing BCN city guide? :-)
<carlos> pitti: well, I was in Barcelona once (outside the rail station) so... don't think I will know much more than you :-D
<fabbione> thom, mjg59: Disable ACPI for systems before Jan 1st this year (ACPI_BLACKLIST_YEAR) [0]  (NEW) 
<fabbione> what do you want here?
<eruin> apm?
<zul> is the conference going to be online as well?
<zul> since i cant afford to go
<lamont> moop
<elmo> seb128: you know about the uninstallables due to xklavier, right?
<seb128> elmo: control-center/gnome-applets ?
<elmo> yeah
<seb128> yes
<elmo> cool
<seb128> the new libxklavier ftbfs
<elmo> meh, and there's not even any point in me upgrading 'cos of OO.o's screwed deps
* elmo whines
<seb128> xorg packages have changed again, thanks daniels 
<elmo> 911 upgraded, 57 newly installed, 11 to remove and 9 not upgraded.
<elmo> Need to get 675MB of archives.
<elmo> good lord
<eruin> haha
<eruin> I just finished the last set
<eruin> ;)
<lamont> seb128: are all the gnome deps there now, or should I wait to do the mass give-back of waiting things?
<seb128> lamont: gnome deps for what ?
<lamont> seb128: nevermind.
<lamont> DANIELS...
<lamont> you gonna upload xorg ubuntu4 sometime soon?
<fabbione> hey lamont 
<lamont> seb128: I found the root of the problem. :-)
<lamont> hey fabbione
<seb128> lamont: I've some problem, libxklavier ftbfsing .... XKBlib.h in libx11-dev, it was in libxkb* before
<seb128> lamont: should I change the buil-deps again or wait for a new xorg ?
<seb128> build-deps
<fabbione> seb128: bug daniels
<fabbione> and keep bugging him :-)
<lamont> the pile I was seeing (on investigation) is all ia64, where there is no xorg.  But there is xorg-common, so anything that build-depends anything that depends any X library is d-w (but not automated) on ia64.  hence the pile-o-mail for me
<lamont> seb128: so it's completely unrelated to your issues.
<seb128> ok
<lamont> however the first couple of packages I looked at had gnome-libs that were uninstallable, hence my question..
<seb128> ok
* fabbione is tired
<fabbione> does anybody remember where the prism2 driver is hosted?=
<Mithrandir> lamont?
<lamont> Mithrandir: yo
<Mithrandir> lamont: how on earth did libdb3 build on amd64?
<bob2> fabbione: linux-wlan.org?
<lamont> Mithrandir: recently, or back in the beginning of time?
<thom> mjg59: 15:28 < fabbione> thom, mjg59: Disable ACPI for systems before Jan 1st this year (ACPI_BLACKLIST_YEAR) [0]  (NEW)
<fabbione> bob2: thanks
<mjg59> Did I not reply to that?
<mjg59> Maybe the network was already fucked at that point
<mjg59> 0 ought to give the current behaviour
<fabbione> yes i left 0
<Mithrandir> lamont: it does LD_ASSUME_KERNEL=2.4.24, which blows up on amd64.
<Mithrandir> lamont: and if you comment that out, it tries to link to pthread.
<lamont> Mithrandir: at the time, the buildd was an i386 kernel
* lamont works on cleaning up the alsa-driver init.d file, pukes at it's previous state
<lamont> mdz: nfc where my brain was on alsa-driver.
* lamont wonders if it's worth looking to see if he screwed up by (1) requesting the sync, or (2) fat-finger uploading -11 himself...  Doesn't really make much difference.
<lamont> Keybuk: around?
<lamont> eep.  brb
<Keybuk> lamont: yup
<Mithrandir> lamont: hm, true.  Should I just ignore the ftbfs?  Is libdb3 even used by anythong any more?
<Mithrandir> s/thong/thing/
<Mithrandir> hm, exim uses it
<Mithrandir> and half of gnome
<elmo> and like, pam
<Mithrandir> who cares about pam? :P
<daniels> lamont: PONG
<daniels> elmo: ...
<daniels> elmo: how is my blog snafu?
<daniels> seb128: pong
<daniels> seb128: EH
<daniels> seb128: XKBlib.h should be in xkbfile-dev iirc -- I certainly never moved it
<seb128> daniels: 
<seb128> $ dpkg -L libxkbfile-dev | grep XKBlib
<seb128> $
<seb128> $ dpkg -L libx11-dev | grep XKBlib
<seb128> /usr/X11R6/include/X11/XKBlib.h
<elmo> daniels: ERROR:planet:Error 404 while updating feed <http://www.fooishbar.org/daniel/blog/?flav=rss>
<daniels> elmo: that's because it's /blog/
<daniels> elmo: is this p.d.o?
<daniels> seb128: ?!?
<daniels> let me look at it
<elmo> daniels: p.u.c
<elmo> and I didn't change planet, so ...
<daniels> oh
<daniels> could you please change p.u.c?
<elmo> no - I'm not responsible for it, and I'm not willing to become responsible for it by virtue of being the only one who does anything with it.  please file a bug and/or mail Jeff
<magnon> daniels: OT, when can I expect fd.o svn to work again?
<daniels> magnon: don't know, depends on when the projects using it get together and check their archives
<daniels> elmo: ok.  have you looked at lkh?
<magnon> daniels: are checked stuff archived anywhere?
<elmo> daniels: the hoary upgrade of doom ismaking ithard for me to do interactive stuff ATM
<daniels> magnon: no svn repositories have been checked.  either that, or they've checked it all and are too afraid of me to lev me know.
<daniels> elmo: k
<magnon> hehe, alright
<magnon> wanted to play with galago, but I guess that'll wait
<seb128> daniels: XKBlib.h so ?
<daniels> seb128: give me a second dude, I'm checking it out
<Kamion> lamont: any possibility of daily d-i builds for hoary?
<Kamion> lamont: I'm just about to have to make another no-source-changes upload, and would rather have working daily builds if possible
<daniels> seb128: XKBlib.h has always been in libx11-dev; if it ever worked with a libxkbfile-dev b-d it was an accident
<daniels> seb128: if I told you it was in libxkbfile-dev -- sorry about that
<lamont> Kamion: sure.  do you need warty daily-builds anymore? :-)
<mako> azeem: i still use docbook sometimes.. it depends on what i want to do :)
<mako> azeem: as far as i can tell, i'm the ONLY person using docbook slides :)
<mako> azeem: because there are unbelievably obvious bugs that go unreported for long periods of time.. like hitting next takes you to the last slide, and vice versa :)
<seb128> daniels: I had a /usr/include/X11/XKBlib.h before 
<daniels> seb128: from libx11-dev, presumably :)
<daniels> http://packages.debian.org/cgi-bin/search_contents.pl?word=xkblib.h&searchmode=searchfiles&case=insensitive&version=unstable&arch=i386
<seb128> ok, I don't understand why the previous version used to build fine 
<daniels> *shrug*, maybe an implicit b-d
<daniels> i.e. it b-d'd something that depped libx11-dev
<seb128> xklavier_xkb.c: In function `_XklXkbGetXkbEventName':
<seb128> xklavier_xkb.c:442: error: `XkbNewKeyboardNotify' undeclared (first use in this function)
<seb128> in a pbuilder
<seb128> with libx11-dev installed
<seb128> grrr
<daniels> i suspect that's from libxkbfile-dev
<seb128> /usr/include/X11/extensions/XKB.h:#define       XkbNewKeyboardNotify            0
<daniels> that's libxext-dev, IIRC
<seb128> ok, my system has a -I/usr/X11R6/include/ in the build line which is not in the pbuilder
<daniels> oh, right
<daniels> let me guess -- you don't build-dep on xlibs-dev anymore
<seb128> right
<seb128> I should ?
<daniels> dingdingding!
<daniels> hack one: -L/usr/X11R6/lib -I/usr/X11R6/include
<daniels> hack two: b-d on libxt-dev
<daniels> real solution: beat autoconf until it bleeds
* ironwolf giggles
<seb128> ok, I'll pick libxt-dev for now
<seb128> thanks daniels 
<daniels> no worries
<Kamion> lamont: hell no :)
<seb128> hum, nop
<Kamion> lamont: I think elmo's bitbucketing them anyway even if they are built
<seb128> libxt-dev already installed in the pbuilder
<daniels> seb128: does your configure output say 'searching for X ... libraries /usr/X11R6, headers', or similar?
<daniels> (grep for X11R6)
<seb128> oh ok
<seb128> checking for X... libraries /usr/X11R6/lib, headers
<seb128> checking for X11/extensions/XKBrules.h... no
<daniels> ok, the 'headers' bit is bong
<daniels> should say 'headers /usr/X11R6/include'
<daniels> do you have /usr/X11R6/include/X11/Intrinsic.h?
<seb128> yes
<daniels> craptastic
<daniels> could you please put the full configure.{in,ac} and config.log somewhere?
<seb128> the configure is ok, it fails during the build
<daniels> the configure shouldn't say 'headers'
<seb128> http://people.ubuntulinux.org/~lamont/buildLogs/libx/libxklavier/1.12-0ubuntu2/libxklavier_1.12-0ubuntu2_20041129-1608-i386-failed
<seb128> build log
<daniels> if it doesn't say 'headers /usr/X11R6/include', it won't add -I/usr/X11R6/include to CFLAGS
<daniels> which is the cause of the problem
<seb128> configure.in and log coming
<daniels> ta
<seb128> http://pkg-gnome.alioth.debian.org/configure.in
<seb128> http://pkg-gnome.alioth.debian.org/config.log
<lamont> 810 upgraded, 48 newly installed, 8 to remove and 3 not upgraded.
<lamont> Need to get 654MB of archives.
<lamont> sigh
<lamont> otoh, 63Mbits ain't bad.
<daniels> seb128: does it work if you install xutils?
<elmo> yeah, it will
<elmo> that's the classic "I need xutils" configure trace
<seb128> yep, that works
<daniels> word.
<seb128> it needs to Build-Depends on xutils so ?
* daniels radiates further hate at autoconf.
<daniels> b-d on libxt-dev, xutils
<daniels> i'm seriously going to fix this shit tonight
<seb128> nop
<daniels> ?
<seb128> # apt-cache show libxt-dev | grep utils
<seb128> #
<seb128> oups
<daniels> ehm
<seb128> I misread
<seb128> nevermind
<daniels> heh :)
<seb128> thanks, all is fine
<daniels> rad
<seb128> I'll upload that and have a good dinner now :p
<daniels> heh
<daniels>   if (xmkmf) >/dev/null 2>/dev/null && test -f Makefile; then
<daniels>     # GNU make sometimes prints "make[1] : Entering...", which would confuse us.
<daniels>     eval `${MAKE-make} acfindx 2>/dev/null | grep -v make`
<daniels> OH MY GOD
<elmo> daniels: you should be forced to be like 10 years older and have had to actually deal with the crap-shoot horror show world that was commercial unices back then - then you might not be so disgusted by autoconf
<elmo> well, okay maybe not not be so disgusted, but at least be more tolerant of
<daniels> elmo: this is autoconf -- the stuff that's meant to make it better
<elmo> it DOES make it better
<daniels> btw, if you know of some way to magically make me ten years older, let me know :P
<elmo> the alternative is people fixing this themselves.  or simply not doing so.
<daniels> yeah, I understand
<daniels> but so many things in autoconf are tremendously disgusting hacks when they shouldn't have to be
<kylem> daniels, grow a real beard, it will at least make you feel old. ;-)
<daniels> and not the 'let's work around random broken crap'
<daniels> the whole 'let's do stuff in a totally half-arsed way' thing
<daniels> kylem: heh
<spotter> anyone know where I can get language-support-en needed by the new openoffice packages?
<elmo> daniels: btw, the l-k-h looks fine to me - I assume you want it installed, and if you do, it's not going to break anything fabbione's doing, right ?
<daniels> elmo: l-i and l-r-m both built fine on my machine with it
<daniels> and yeah, if it's installed on davis, I can get back to working on ppc lrm
<elmo> installed
<daniels> ta
<daniels> otoh, maybe I should just piss autotools right off and get with the pkgconfig groove
<elmo> why does scrollkeeper build it's database in the foreground?
* lamont uploads alsa-driver :-(
<lamont> is somoene working on the ppc oo.o ftbfs?
<elmo> doko had me install the b-d's in davis' chroot, dunno if he's doing anything tho
<elmo> btw, is that cut'n'paste of X vs. gtk in zorg, fixed, yet?
<elmo> daniels: ^--
<lamont> krb4 is ftbfs on amd64 as well... /me checks bugzilla/bts
<daniels> elmo: x vs gtk?  which?
<daniels> lamont: i'll take that
<daniels> NO I WON'T
<elmo> daniels: seb128 was talking about cut'n'paste not working between emacs and gtk apps or summat in x.org, back when you first released it
<daniels> lamont: toolchain?!?
<daniels> elmo: oh.  no, we have no idea.  but it's only gtk1.
<daniels> so your fonts will be so hideously bad you won't want to paste anything into there
<daniels> or maybe it wasn't.  but we didn't ever figure out the problem to start with.
<Kamion> geez. my routine "start up d-i" dance in this edit/compile/test/debug cycle now involves "anna-install openssh-client-udeb; mkdir /etc/udev/scripts; mv /etc/udev/*.sh /etc/udev/scripts/"
<lamont> daniels: actually, krb4 is most probably the lack of an include file.  I'll play with it
<lamont> dbs feh
<daniels> lamont: thanks.  i fixed it up as far as b-ds go today
<lamont> daniels: ah - that explains the upload
<elmo> hmm, that's not cool - after upgrading to hoary, 'logout' doesn't work
<Kamion> elmo: uh. how on earth?
<Kamion> hm. I think my i386 assembly might not be what it once was
<daniels> jbailey: hey dude
<jbailey> Heya Daniel!
<mako> so evidently, debian-amazonas is making a CDD based on ubuntu
<daniels> One way to solve this would be e.g. convmv (universe) to convert the /home
<daniels> partition on an update installation automatically (if its possible to figure out
<daniels> the old encoding) to UTF-8 or to mention this issue and a way to solve it to the
<daniels> user. Then the convmv package should go to main.
<daniels> !!
<lamont> cat >>conftest.$ac_ext <<_ACEOF
<lamont> extern int h_errno;
<lamont> int foo() { return h_errno; }
<lamont> we have a winner.
<lamont> md?
<lamont> mdz?
<lamont> mdz: pls sync 273615
<lamont> daniels: fixed
<Md> lamont: ?
<lamont> md: meant to type mdz.
<Md> lamont: BTW, any ideas about the mount segfault bug? I think it should be upgraded to RC
<lamont> md: no clue
<elmo> ugh, why on earth did nautilus move a library around without changing the package name?
<Matt|> sup with the openoffice packages guys?
<seb128> elmo: what ?
<seb128> elmo: oh yes, nautilus 2.9 design is in change, should be fixed soon
<lamont> Kamion: daily builds scheduled for hoary (but not warty - it rejects uploads... .:-)
<pitti> mvo_: ping
<pitti> fabbione: got a minute for me?
<seb128> lamont: do you know if epiphany-browser is waiting on something to build ?
<pitti> Kamion: do you have a minute for me?
<haggai> Matt|: they are b0rken
<Matt|> haggai, k fine
<Matt|> haggai, you doing em?
<Matt|> just wanted to make sure someone knew
<mvo_> pitti: png
<mvo_> pong even
<mdz> lamont: done
<haggai> Matt|: doko did the last set
<Matt|> kthx
<lamont> mdz: btw, is fixed in  krb4_1.2.2-11ubuntu3
<mdz> lamont: please close it, then :-P
<lamont> yeah
<lamont> that was the plan
* lamont must run to town for a bit. lunch and a couple errands.  back in 2-3 hours.
<seb128> lamont: any idea for epiphany-browser ? 
<seb128> lamont: oups, later 
<spotter> anyone know where I can get the language-tools-en needed by new openoffice debs?
<tseng> its not merged to ubuntu yet, give them some time to work it out.
<Md> mdz: look at http://www.reactivated.net/udevrules.php
<mdz> Md: regarding #1293?
<Md> mdz: yes. basically, you can choose a device by its bus position, model (human readable name or PCI/USB/whatever ID) or MAC address
<mdz> Md: looks like what we need, thanks
<mdz> Md: we'll have a mail->bugs gateway soon :-)
<mdz> Md: what do you think we should use for a naming scheme?
<Md> mdz: cool. this is what I really miss in bugzilla
<mdz> we could try to make the numbered devices persistent, or name them according to some other scheme
<Md> mdz: I'm busy right now. let's talk about it at the next break
<Md> keep writing :-)
<haggai> spotter: you don't actually need it.  Make a dummy package or use a dpkg --force flag
<mdz> jdub: around?
<mdz> Md: I added some notes to bugzilla
<mdz> elmo: do you have a knob which lets us say "sync this package the next time it's updated, overwriting the ubuntu version"?
<mdz> what's the story with openoffice.org?
<tseng> it deps on some l10n stuff
<elmo> mdz: no
<tseng> that doesnt seem to be merged
<mdz> is there a bug in bugzilla already?
<tseng>   openoffice.org: Depends: openoffice.org-l10n-en (> 1.1.2+1.1.3) but it is not going to be installed or
<tseng>                            openoffice.org-l10n-1.1.3
<tseng> elmo: Broken packages
<mdz> I don't see one
<tseng>   openoffice.org-l10n-en: Depends: language-support-en but it is not installable
<tseng> i shall make you one in 10 minutes
<tseng> bbiaf
<mdz> nothing in Debian or Ubuntu builds language-support-en
<mdz> or oo.o-l10n-1.1.3
<tseng> thats fairly odd
<mdz> did dput suddenly stop defaulting to passve ftp or something?
<fabiand> hello, doesn anyone know the problem when modprobbing pktgen?
<mdz> nope
<fabiand> i'm not sure whether it is a bug or not ..
<mdz> I don't know what the problem is, because for me there is no problem
<fabiand> ha - okay ... so works for you?
<fabiand> it says that my machine hasn't got a "working cycle counter" even google doesn#T know what this is ..
<Md> mdz: I think that the solution depends on how many resources you can throw to the problem. in an ideal world we would have a configuration program which would generate the udev rules to statically bind hardware devices to names, and something which at boot time would check if some devices (dis)appeared and ask the user (email? DBUS?) to run the configuration program
<ggi> I've been using Synaptic for the first time in a while, and I've noticed that it uses a fairly curious turn of phrase for many of its menu entries and prompts. One example that sticks out is "To be not upgraded" in the summary dialog. Other examples (in the preferences dialog), while technically correct, also read rather obtusely. It may just be me, I suppose.
<mdz> ggi: mvo_ is the person to talk to about synaptic
<mvo_> ggi: are you a native speaker?
<ggi> mvo_: Of English, yes.
<mvo_> I'm not, so any help with wording is appreciated :)
<sivang> mdz : ping
<sivang> hey ggi
<mdz> sivang: pong
<sivang> mdz : I was just reading the trail in my bug and in #3401, does debian also use hald?
<sivang> mdz : (recalling that when using debian sarge everything's fine)
<ggi> mvo_: I'll have a more detailed look through it, and see what I can improve.
<mvo_> ggi: that would be great! thanks a lot
<mdz> sivang: I'm not sure what you mean
<mdz> sivang: debian contains hald and you can install it
<sivang> mdz : ok, sure I'll restate - does debian install it by default like warty/hoary?
<spotter> seb128: saw my dvd bug report?
<sivang> mdz : I'm trying to understand why debian doesn't have that problem
<mdz> sivang: which bug # is yours?
<seb128> spotter: #nnn ?
<sivang> mdz : 2315
<mdz> sivang: did you not try the test that I suggested?
<mdz> sivang: that is a much simpler way to find out, rather than comparing with Debian
<sivang> mdz : hadn't had a chance yet, as this is borrowed laptop, but I will tommorow, however I think it's interesting to try and understand what debian has/hasn't that exempts it from carrying the bug, from my memory I recall that debian doesn't install hald by default, am I right?
<spotter> seb128: https://bugzilla.ubuntu.com/show_bug.cgi?id=4205
<seb128> spotter: yeah, I've read this one but no idea for the moment
<spotter> ok
<sivang> mdz : ok, I will report tommorow on my finding with stopping hald :) thanks!
<mdz> sivang: with Debian it is entirely up to you and what you select
<mdz> by default you get a minimal system
<sivang> mdz : yes I almost had it forgotten, that almost every tiny bit of automation or support comes with loads of apt-gets and editinf conffiles :)
<tseng> mdz: sorry, getting pretty busy now
<tseng> ill get to filing that bug later if no one else has
<sivang> mdz : I especially recall one install I did on this same laptop using bf2.4, 3 days went before everything was set up. I had to manually fine tune X values to make X use the whole area of the lcd...
<tseng> bbl
<pitti> mdz: re derooting unix_chkpwd: as far as the Debian bug report says, setgid shadow will fail for NIS logins
<mdz> pitti: ah, good point
<pitti> mdz: okay, NIS should die and be replaced by LDAP, but there are still a lot of NIS systems around
<mdz> pitti: perhaps the nis package could provide a setuid root version, and the default could be setgid shadow
<pitti> mdz: I would still favor a debconf question (normal, default setgid)
<pitti> mdz: hmm, could work as well
<pitti> mdz: but then nis had to use dpkg-statoverride?
<mdz> pitti: I was thinking it could be two separate programs
<pitti> mdz: or do some dirty trick with dpkg-divert, copy the executable binary and chmod it
<mdz> pitti: anyway, this one is a low priority; that is a small and auditable program
<mdz> there are worse offenders
<pitti> mdz: yeah, just thinking about it
<pitti> a matter of pride :-)
<thom> pitti: take a real challenge, make wu-ftpd not suck
<pitti> mdz: btw, I recently thought about a suid wrapper for dhcp3 client
<pitti> thom: good idea
<pitti> mdz: the daemon itself already runs fine
<thom> pitti: i don't think there's time before the next iceage, mind
<pitti> mdz: i'm still unsure how to call the script
<pitti> mdz: it would be pointless if the wrapper would accept anything dhclient would call through it
<pitti> thom: is vsftpd any better?
<pitti> thom: proftpd runs as normal user
<thom> pitti: much
<mdz> pitti: I think a privsep approach would be best, with one process continuing to run as root
<pitti> thom: argh, wu-ftpd is universe
<pitti> thom: so why bother about it at all?
<pitti> mdz: two continuously running daemons? Wouldn't that be a recursive problem then?
<thom> pitti: dude, i was joking. sorry
<pitti> thom: hmm, okay. Then I go back derooting X.org now :-)
<thom> pitti: it's just that wu-ftpd is the most insecure and buggy piece of software on the face of the planet ;-)
<pitti> thom: looking at the number of security issues I already read about it, I wholeheartedly agree :-)
<ggi> Any ideas what should I change "To be not upgraded" to in Synaptic? I think I recall it being "To be kept back" in the past.
<mvo_> ggi: eugenia (from osnews) complained that "kept back" sounds too much like it was kept back because of problems
<mvo_> that was the reason why it was initially changed
<mvo_> ggi: https://bugzilla.ubuntu.com/show_bug.cgi?id=1309
<mdz> mvo_: how about "unchanged"?
<mvo_> "unchanged" sounds pretty good to me. short and simple :) what do you think ggi?
<ggi> mvo_: Possibly. I'm not quite sure what "unchanged" would imply to a user.
<Kamion> lamont: thanks a lot
<Kamion> pitti: yep?
<pitti> Kamion: ?
<pitti> Kamion: oh, the ping
<pitti> Kamion: that was about reviewing the libgd security update, but this is already done :-)
<Kamion> pitti: ok, cool, I was out at karate training
<|trey|> Can someone please fix the OOo packages... Matias Klose uploaded a package that depends some kde stuff... and everyone is going nuts  :(
<ggi> mvo_: But even something like "Not upgraded" could be interpreted as referring to the unchanged entirety of the repository, I suppose. Hmm.
<pitti> Kamion: hey, nice. I do Tae Kwon Do, which is not too far apart...
<Kamion> pitti: cool; what belt?
<ggi> mvo_: The part of the repository not affected by the current upgrades/downgrades/installs and so on, that is.
<mvo_> ggi: ok. 
<pitti> Kamion: still the white one :-( There are no trials in my club
<Kamion> likewise, unfortunately I'm going to miss the red-belt grading due to being in Mataro
<Kamion> so I get to double-grade for orange in March
<pitti> orange???
<pitti> oh, the Japanese system
* amu wears the 3rd DAN ;)  
<pitti> wow
* Kamion bows. :-)
<pitti> Kamion: you can do a new belt every three months?
<pitti> amu: how long have you done this now?
<Kamion> pitti: red, orange, yellow, green, blue, purple, purple+white, brown, brown+white, brown+red, black
<Kamion> pitti: for the first five or six at least, yeah
<pitti> Kamion: you _start_ with a red belt? That's odd
<amu> pitti: something about 16years
<Kamion> pitti: yeah, basically just goes through the rainbow it seems
<pitti> Kamion: we have white, yellow, green, blue, red, black
<pitti> Kamion: with while-yellow, yellow-green and so on in between
<pitti> amu: wow, I only started at my 3rd uni semester, about 4 years ago
<pitti> oh, and sorry for being so OT :-)
<pitti> Kamion: btw, I did not read anything about training facilities in the Mataro hotel :-(
* pitti really liked the squash court in Oxford
<amu> pitti: hehe 4 years and still white? 
<pitti> amu: as I said, no trials in our uni
<Kamion> pitti: haven't checked on that myself
<amu> pitti: yeah thats little bad, same here i've null time for it to my the 4th 
<amu> s/my/make
<Kamion> pitti: sadly I'm not sure I'm advanced enough to train usefully with somebody from another discipline, although I could try
<pitti> Kamion: when did you start?
<Kamion> three months ago
* mvo_ goes to bed now
<Matt|> chaps bit of help needed. A guy has this error when starting firefox + thunderbird. He's tried everything that anyone in #ubuntu can think of. Sorry to disturb but someone might know
<Matt|> <ulisse> (firefox-bin:8683): Gdk-WARNING **: locale not supported by Xlib
<Matt|> <ulisse> (firefox-bin:8683): Gdk-WARNING **: cannot set locale modifiers
<Matt|> <ulisse> *** loading the extensions datasource
<Matt|> <ulisse> *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping.
<Matt|> <ulisse> Segmentation fault
<mdz> Kamion: problems committing to the seed archive again :-(
<mdz> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<mdz>     tree: /home/mdz/data/src/canonical/seeds/hoary
<mdz>     revision: ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-34
<mdz> hmm
<mdz> elmo: I think you'll need to be the one to fix it
<pitti> mdz: did you happen to cancel a commit with ^C?
<pitti> mdz: this happened to me 
<mdz> pitti: no, I have encountered that situation in the past though
<mdz> this time the repository is just broken
<mdz> e.g., someone committed with a wrong umask
<pitti> mdz: ah, I had that once, too
<pitti> mdz: it required to manually remove the lock directory from the server
* pitti is too tired to do anything more useful today
<pitti> Good night everybody!
<mdz> pitti: yes, but I don't have permission in this case
<mdz> pitti: good night
<pitti> mdz: same for me back then, I had to ask Oliver elphick to remove the dir
<pitti> mdz: somehow I felt that this was outright buggy...
<mdz> pitti: there is a bazaar bug in bugzilla already
<mdz> Kamion: wow, openssh is still back on DH_COMPAT=2?
<elmo> mdz: fix it how?
<mdz> elmo: g+w
<mdz> elmo: on the ++revision-lock directory, I think
<mdz> that's my best guess, anyway
<daniels> mdz: whoohoo!!
#ubuntu-devel 2004-12-11
<elmo> mdz: done
<tseng> #3811 imported from BTS and #4219 are dupes
<tseng> ah, i can do that :)
<sivang> night all
<jdub> mdz: pong
<lamont> moo
<lamont> seb128: here?
<seb128> yes
<lamont> figure out epihpany-browser?
<seb128> no
<lamont> gnome-media ftbfs
<seb128> no log on people, only for ia64 in fact
<mdz> fabbione: here?
<lamont> gnome-media says nautilus is uninstallable
<lamont> gnome/epiphany-browser_1.5.2-0ubuntu2: Dep-Wait by buildd+mcmurdo [optional:out-of-date] 
<lamont>   Dependencies: libgtk2.0-dev (>= 2.5.6)
<lamont> libs/gtk+2.0_2.5.5-0ubuntu2: Installed [optional:out-of-date] 
<lamont> have a nice day. :-(
<lamont> seb128: if you change the dep in epiphany-browser, let me know so I can kick the dep-wait
<seb128> lamont: yeah, I've switch the glib/gtk versions in the first upload and fixed with the second
<lamont> seb128: gnome-media's issue is that   capplets: Depends: libxklavier9 (>= 1.11) but it is not installable (libxklavier10 replaces it...)
<lamont> seb128: so clear the depwait?
<seb128> yeah please
<seb128> I'll fix the libxklavier/control-center issue
<lamont> seb128: kicked
<seb128> thanks
<lamont> seb128: you'll be uploading new capplets, yes?
<seb128> yes, in about 10min
<lamont> ok.  just trying to figure out what to d-w
<jdub> pants off
<seb128> hey jdub 
<jdub> seb128: craaaaazy gnome release action :)
<lamont> amusingly, control-center is d-w libgnomeui-dev (>= 2.8.0-1)
<seb128> he he
<lamont> and we have -0ubuntu1
<seb128> lamont: arg, will fix that in the same time
<seb128> thanks
<seb128> due to the sync with deb
<lamont> seb128: if you upload within 8 minutes, that'd be just dandy...
<seb128> lamont: grrr, nop, will not be ok. I need to add a patch will take a few min ..
<lamont> seb128: np
* lamont has to run out for an hour or 2 in about 45 minutes max, would like to release it by then.
<lamont> so would be best if you get it uploaded before the hour. :-)
<lamont> otherwise, at is my friend.
<seb128> rebuilding it with the fix now
<seb128> it the build is ok I'll upload in a few min
<lamont> kewl
<mdz> lamont: what's the latest on #4078?
<lamont> mdz: checking now
<mdz> thanks
<lamont> mdz: mlocktest.c gives 1 in a chroot on i386, 0 on the other 2.
<mdz> lamont: what kernel is it running?
<lamont> and outside the chroot gives 0
<mdz> aha
<mdz> so the question becomes
<mdz> "wtf"
<lamont> Linux macaroni 2.6.8.1 #1 SMP Wed Nov 17 15:00:00 GMT 2004 i686 GNU/Linux
<mdz> so it's a chroot thing, apparently
<mdz> what's different about that chroot?
<mdz> it has /proc mounted and all that nice sort of stuff?
<lamont> proc mounted
<mdz> lamont: strace it and see what error is returned my mlock
<mdz> s/my/by/
<lamont> sec
<elmo> meh, alsa's so crap
<elmo> if I run xmms with alsa, I can stall music entirely by doing 'ls /usr/lib'... oss is fine
<elmo> that's even with xmms reniced to -15
<lamont> GAH
<lamont> now it's working
<lamont> even not-strace
<lamont> d
<chrisa> I decided to shy away from alsa since my sb live! cards work flawlessly with oss
<seb128> lamont: control-center uploaded
<lamont> seb128: thanks
<seb128> np
<lamont> seb128: once I finally get back home, I think I may just clear all the dep-wait.s..
<seb128> should be ok
<lamont> mako: so is the key-signing bof scheduled already?
<lamont> seb128: control-center given back
* lamont dinners.  bbiab
<jdub> seb128: going to propose python-gnome2-extras for desktop? :)
<seb128> yep
<jdub> cool
<seb128> but not today, that's time to sleep :)
<seb128> and the packaging is stucked at this point
<jdub> sleep well :)
<jdub> aww, and i'm just uploading eog ;)
<seb128> some of the new modules need the new gnome-vfs, new gnomevfs without vfolder -> new panel -> gnome-menu -> not released
<jdub> heh
<jdub> d'oh
<seb128> so this part is for tomorrow :)
<seb128> 'night guys
<mdz> jdub: are you using mvo's apt-authentication stuff yet?
<jdub> no
<mdz> why not? :-)
<mdz> I'd harrass everyone else, too, but you're awake
<jdub> heh
<jdub> maaaaaaan
<mdz> it should be totally transparent if you only use Ubuntu sources
<mdz> and other sources should present a nice warning prompt (apt-get) or dialog (synaptic)
<jdub> mdz: hrm, can't find the url
* jdub thought it had been mentioned on the lists
<mdz> jdub: deb http://people.ubuntulinux.org/~mvo/apt-authentication/ /
<mdz> it had
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | Hoary is here: http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | Want to help? see https://www.ubuntulinux.org/wiki/HoaryGoals | TEST ME: http://lists.ubuntu.com/archives/ubuntu-devel/2004-November/001743.html
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | Want to help Hoary? see https://www.ubuntulinux.org/wiki/HoaryGoals | TEST ME: http://lists.ubuntu.com/archives/ubuntu-devel/2004-November/001743.html
<mdz> (hoary is old news :-P)
<jdub> ;)
<jdub> oof, there goes my entire packaging toolset ;)
<mdz> hey, there's no dpkg in there
<tseng> off topic, but i know you guys are into this
<tseng> is it worthwhile to switch to arch for a small project
<Clint> tseng: absolutely
<mdz> the best answer I can give is...almost :-)
<mdz> tseng: there is a certain amount of pain involved in arch at the moment, which may not be offset by the benefits for a small project
<jdub> tseng: it will progressively get better ;)
<mdz> tseng: but that pain is actively being reduced
<mdz> tseng: http://www.canonical.com/projects/bazaar/
<tseng> CVS is pain
<mdz> tseng: if you're doing the sorts of things that make CVS painful, then by all means, go for arch
<tseng> thanks for the link, ill try that once i grok the basics
<mdz> the baz repository makes a good test case for the apt authentication code in /topic :-)
<tseng> hm
<tseng> ya back in gentoo they are still quibbling over how to validate/distribute keys
<tseng> longest running project ever
<tseng> im sure you folks will come up with a clever solution
<mdz> that's the hardest part of the problem
<mdz> our clever interim solution is to ship a key with the package
<mdz> which can authenticate things in the Ubuntu archive
<tseng> which works until someone along the line is compromised, the key is revoked, and you publish a new apt
<jdub> i thought mvo disliked that solution?
<tseng> but it fails to authenticaate with the new key
<mdz> jdub: none of us are particularly happy with it in the long term
<jdub> Release.gpg!
<mdz> but it lets us bootstrap things
<mdz> tseng: in the event of a key compromise, there isn't much to be done except validate by hand to get things going again
<tseng> jdub: sorry about your oo bug, i was running in and out
<jdub> whichwhat?
<jdub> oh
<jdub> yeah
<tseng> i mis-duped you =/
<mdz> http://www.lalugs.org/#meetings
<mdz> ^^ all the LUGs I can visit within an hour or so travel time
<mdz> armed with a nice stack of CDs now
<tseng> a LUG around here was crazy enough to ask me to speak at their mini-conf
<tseng> http://cplug.net/conference
<tseng> its like the selinux symposium after-party
<mdz> nice
<mdz> got ubuntu CDs? :-)
* jdub wipes the ubuntu cds off his lip
<tseng> no cds here
<mdz> didn't order any, or they haven't arrived yet?
<tseng> never ordered
* mdz faints dead away
<tseng> i didnt immediately grasp the concept
<mdz> where do you live?  I have some extra :-)
<tseng> free cds, it felt like leeching
<tseng> now that they are going out in mass shipments i realize the point
<jdub> tseng: it's purposeful leeching :)
<tseng> its like a dealer passing out his sweetest crack at the concert
<tseng> mdz: PA
<mdz> wrong coast
<Clint> no, you're on the wrong coast
<tseng> this time of year, he's on the proper coast
<tseng> come summer time he'll be sorry
<Clint> no, no, it's almost ski time
<mdz> over here we have both a pleasant climate _and_ better skiing
<jdub> 35 degrees C here :)
<jdub> going up :)
<Clint> mdz: I don't believe you.
<mdz> I'll confess, I'm not much of a skier myself
<mdz> but the mountains are, well, _bigger_
<Clint> I hear bad things about the wetness.
<Clint> You're not counting the Rockies, are you?
<mdz> of course
* Clint grumbles.
<Clint> that's a bit of a stretch from the coast
<mdz> a few thousand miles closer to here than there :-P
<mako> lamont: that's a very good point re the keysigning
<mako> lamont: i will need to do that
<mako> mdz: they go fast
<jdub> mako: when's the second lot of CDs going out?
<mako> mdz: i ordered nearly 400 that came in two boxes.. iD[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D just threw away the first box today 
<mako> jd	i've already sent the list
<mako> whoa
<jdub> hr
<jdub> ahr
<jdub> ok
<mako> they should be going on this week
<mako> and the next couple
* jdub will suffer with only an extra 200 ;)
<mako> i'm going to order like 300 more i think
<mako> i've been giving them out to people i meet in bars
<mako> seriously
<mako> people love it :)
<mako> everybody <3 ubuntu
<mdz> mako: I ordered about 200; they came in ~10 bags
<mako> mdz: really?! :)
<mako> wow.. that sounds pretty annoying
<mdz> XF86XK_AudioRaiseVolume
<mdz> er
<mdz> http://www.ice-nine.org/matt/pics/mjw/2004/11/29/
<mdz> about 10 of those
<mako> un/pw?
<mdz> yin/yang
<mdz> I was fairly sure the authentication dialog had the u/p in it :-)
<mako> yes, you did
<tseng> omg, they have pr0n on the box
<mdz> but my browser's cached it
<mako> i saw it just after i ask:)
<mdz> that's actually a different matt's page
* mdz points at m_tthew 
<mako> yeah, we might as well have two matts
<mdz> but that's the sort of bag they came in
<mako> we have two of everything else :)
<mdz> we have more than two already :-)
<mako> excellent!
<mako> backups
<mdz> mdz, mjg59, m_tthew off the top of my head
<mako> only one mako
<mako> but there is a guy who has posted a few times onto debian-devel named Ben Hill
<mako> he reads my blog and posts comments sometimes
<Clint> how'd your nylug thing go?
<mako> Clint: i will post slides and stuff in the next couple days
<mako> Clint: it went really well i think
<mako> people seemed to be really into it
<mako> clint: i met with jimmy kaplowitz with greg pomerantz saturday night as well :)
<jdub> only one jeff
<jdub> i've taken out the others
<Clint> sorry I missed that
<mako> Clint: nylug is a pretty good crowd.. it's a bit more formal than i'm used to in a LUG but the people are interested and active
<Clint> yeah, they're the most suity of the NYC LUGs
<mako> Clint: heh, it's a little bit of a culture shock with me
<mako> Clint: i'm not so suity, to say the least
<Clint> have you encountered the rival lugs yet?
<mako> i mean, i wear suits, but culturally
<jdub> nylxs :)
<mako> yeah, there is that one that is super exclusive
<mako> like you can't become a member unless you write articles for them and do all this other crazy stuff
<Clint> nylxs claims not to be a lug, no?
<mako> and there is the one seems to be the linux + BROOKLYISTHECENTEROFTHEUNIVERSE user group
<mako> yeah i think so
<Clint> well, brooklyn is the center of the universe
<mako> fair enough :P
<Clint> this is making me all nostalgic
* Clint sobs.
<mako> also there is LXNY
<mako> or something like that
<mako> that seems to be mostly defunct but organized a talk with steve bourne
<mako> who convinced me to write an article on packaging
<mako> which is due tonight and which i am not done with
<mako> DOH
<lamont> mako: thank you
<mako> steve bourne was *super* interested in packages.. i think he'd never heard of them :)
<Clint> lxny has the most interesting characters, IMO
<mako> so as part of this packaging article, i spent all yesterday afternoon having someone teach me about redhat packaging
<mako> OMG ITS INSANE
<Clint> people like their .spec files
<mako> why would you ever want more than one file?
<mako> when he told me about the localization is ALSO done within the same single file i nearly lost it
<mako> the localization stuff seems pretty indefensible
<mako> one of those situations where you wonder if personaly teaching your users english would be a better use of time and effort than i18n/l10n for your software :)
<mdz> mako: i18n of what exactly?
<mdz> surely not the software itself
<lamont> mako: it's just like a tarball of debian/*, only different...
<lamont> seb128 is not here. bummer
<jdub> i just switched network devices with netapplet
<jdub> and it unmounted every filesystem
<jdub> or something...
<jdub> mmm
<jdub> i had to remount /, mount /home and mount /proc
<jdub> bizahr
* lamont notices that he's very tired, decides to go to bed soon
<lamont> g'night
<mako> mdz: everything that would bein the debian directory basically
<mako> mdz: so they have localized sections, descriptions, and a bunch of other thing
<mako> mdz: all in that one file :)
<stuNNed> so got acpi suspend to ram working disabling agp modules using nvidia driver, a first...and i have ques: can i file a bug regarding linuxant hsf modem support with ubuntu's bugzilla or am i barking up the wrong twig?
<stuNNed> and last ques in 'gnome-pkgview' using hoary (report bugs when i can) i see alot of *-sharp gnome packages, is gnome-pkgview for real?
<fabbione> morning
<mdz> morning
<jdub> morning
<jdub> dude
<jdub> totem http://home.waugh.id.au:8800/
<jdub> or mplayer
<jdub> or i guess you can load it up on your tv or something with mythtv ;)
<fabbione> jdub: gimme an on-line finger :)
<jdub> two! two!
<fabbione> ARGH
<fabbione> again?
<pitti> Morning
<fabbione> the stram just got interrupted
<fabbione> and again
<fabbione> your network sucks
<jdub> my upstream b/w is horrific
<fabbione> AHHAHA
<fabbione> got them!
<jdub> i'll kill the audio stream
<mdz> jdub: what software are you using to drive that?
<jdub> FLUMOTION
<fabbione> ffmpeg would do too
<mdz> mizar:[~]  apt-cache search flumotion
<mdz> mizar:[~] 
<fabbione> i used it to stream the tour the france in ericsson
<jdub> mdz: it didn't build, still working on the package.
<jdub> (only silly build-dep error; just uploaded it while elmo was awake)
<jdub> stream's back
<mdz> openoffice.org_1.1.3-2.3ubuntu4_source.changes ACCEPTED
<jdub> woo
<jdub> vorbis encoding is harsh on cpu
<jdub> er, theora, rather
<mdz> yes
<mdz> and no hardware encoders
<mdz> and we thought vorbis was an uphill battle :-P
<jdub> heh
<fabbione> OMG
<fabbione> you are hugly at higher resolution
<fabbione> HAHA
<jdub> hugly? great! hug me now! :)
<fabbione> do you mean spank me now?
<fabbione> ok..
<fabbione> now.. get naked
<jdub> heh
<jdub> ECHAN for cyber!
<fabbione> AHHAHA
<fabbione> Ogg : Page out not synced, we skip some bytes
<jdub> was cool to be streaming as well as saving to disk
<fabbione> jdub: remember to take the webcam to Mataro
<fabbione> so we can stream some stuff live
<jdub> :)
<jdub> yeah, using mataro as a test case for linux.conf.au
<Mithrandir> jdub: how bad is theora?
<jdub> it sucks the life out of your cpu :)
<jdub> to encode
<jdub> but very little attention has been paid to optimisation so far
<fabbione> jdub: you could try ffmpeg
<Mithrandir> jdub: what kind of CPU do you need to do it real-time in decent quality?
<jdub> Mithrandir: not sure, haven't spent enough time playing with it
<jdub> fabbione: flumotion can encode anything gstreamer supports :)
<jdub> http://www.onlamp.com/pub/wlg/5988
* thom wakes up, sees how much stuff there is still to pack in his room, and bursts into tears
<jdub> "While some of its ideas and technologies may not be new, I feel Ubuntu offers a degree of refinment that's just not present in similar projects."
<mdz> someone just said on -users that their machine was "incredibly faster" after switching from linux-386 to linux-686
<mdz> it's amazing what a little perception can do :-)
<Mithrandir> mdz: don't ask them to measure. :)
<fabbione> lol
<fabbione> do we know where daniels is?
<fabbione> yesterday he wasn't much around
<mdz> he has been active in Bugzilla
<mdz> fabbione: he just followed up to a bug a few minutes ago
<fabbione> mdz: ok thanks
<mdz> jdub: what's the latest on ubuntu-bugs?
<thom> i need to work out how to twiddle bugzilla i guess
<mdz> thom: alternatively, you could hook me up with mysql privileges, since I seem to have inherited de facto bugzilla admin status for now
* mdz wonders whether oo.o will land on the buildds which should have it still in ccache
<thom> sounds fine to me; can you send mail to admins since i'm surrounded by boxes currently? :/
<mdz> thom: I'd be perfectly happy with a warty-bugs->ubuntu-bugs alias for now
* fabbione takes out his biggest cluebat
<mdz> should I ping elmo on that?
<thom> prolly best right now, yeah
<mdz> done
<mdz> gah, tech board in <8 hours.  bed soon
<Keybuk> Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
<Keybuk> *giggles*
<mdz> we should schedule a different time for this stuff
<Keybuk> mdz: such as?
<Mithrandir> what kind of hard drive does the X40 use?  1.8" or 2.5"?
<mdz> maybe afternoon .au / late night .au / morning europe
<mdz> er
<mdz> afternoon .au / late night .us
<fabbione> mdz: MORNING EUROPE
<mdz> <fabbione> morning <-- approximately 0700 local time
<Keybuk> mdz: dude, late night .us is past any reasonable time for me and Mark :)
<thom> grah. APUE, UNP, and Applied Crypto are all great books, but bloody hell they weigh a tonne
<mdz> anyway, bed
<mdz> night all
<thom> night mdz
<Keybuk> nite dude
<thom> oh, and Unix Power Tools just to add to the fun
<Keybuk> thom: you're only going to .es, not .au
<thom> no dude, that's thursday
<thom> today i'm moving house
<Keybuk> ahh
<Mithrandir> thom: have phun :)
<Keybuk> heh, I swear my book shelf defies gravity
<fabbione> thom: you have all my understanding for the pain of moving
<fabbione> thom: good luck
<Keybuk> APUE, TCP/IP 1, 2 & 3, UNP 1 & 2, Knuth 1, 2 & 3 and The C Standard
<thom> Keybuk: i'm beginning to think mine is a gaping hole in the space/time continuum
<Keybuk> how far are you moving?
<thom> the worrying thing is that trotsky's history of the russian revolution outweighs applied cryptography by some margin
<Mithrandir> thom: why is that worrying?
<Keybuk> which Russian Revolution?  or does it cover all of them?
<thom> Mithrandir: the weightiest tome on my shelf is by a communist revolutionary terrorist! (or something)
<thom> Keybuk: The. ;-)
<Mithrandir> thom: he fought in his own country, then it's customary to call him freedom fighter.
<Mithrandir> Keybuk: probably the October revolution (the one that happened in November).
<Keybuk> we don't call them terrorists anymore
<Keybuk> we call them "Mr. President"
<Mithrandir> not when they're assassinated by order of the General Secretary of The Party.
<thom> Mithrandir: yeah
<pitti> mdz: still here?
<fabbione> Kamion: ping
<Kamion> mdz: openssh DH_COMPAT> there's no reason to bump it really - I don't believe in raising build-deps unnecessarily anyway, and all the backporters would whine at me :)
<Kamion> fabbione: pong
<fabbione> Kamion: did sven luther get worst with his skizophrenia recently?
<Kamion> fabbione: it seems to ebb and flow
<Kamion> fabbione: why?
<fabbione> Kamion: because he doesn't even know how to count
<fabbione> or he lost such ability quite recently
<fabbione> :-)
<Kamion> heh
<Kamion> reference?
<Kamion> ah, life is so much better now that I've kicked spamd into ACTUALLY DOING NETWORK TESTS
<fabbione> Kamion: debian-boot or debian-kernel mailing list
<fabbione> about the patch for udebs integration
<fabbione> i am not sure what kind of mess he has in his head
<fabbione> really
<fabbione> i am confused
<Kamion> fabbione: for what it's worth I totally agree that that patch is inappropriate for Debian
<Kamion> fabbione: I'm glad you sent it, but it's just not going to work with the way d-i development runs
<fabbione> Kamion: that's why i wrote "do what you want with it"
<Kamion> d-i kernel packages are often uploaded much more frequently than actual kernel packages
<fabbione> and that i am not pushing it for inclusion
<Kamion> I haven't checked what Sven said; we certainly did have problems with apt limits at one point
<Kamion> due to length of Binary: lines
<fabbione> in terms: it can be done.. here is the patch or the prove
<Keybuk> ooh!  5. Ubuntu 943 , 4. MEPIS 969  ... we could be about to swap places again :p
<Kamion> fabbione: right
<daniels> Kamion: yeah, Binary lines are fun
<fabbione> Kamion: he is starting again the game of bouncing people around
<fabbione> without even answering questions
<fabbione> because he doesn't really understand what he is talking about
<daniels> fabbione: sven luther?
<fabbione> daniels: ahhaha
<fabbione> how could you guess so?
<doko> pitti: ping?
* daniels is psychic.
<seb128> morning
<daniels> eeeeeeeeeeelllllllllllllllmmmmmmmmmmmmmmooooooooooooooooooo
<daniels> elmo: jackass's ftpd hates me
<daniels> seb128: morning dude
<seb128> hello daniels 
<doko> mdz: ping?
<daniels> seb128: did you just upload eog via ftp?
<seb128> daniels: yes, why ?
<daniels> i'm getting connection refused on jackass
<daniels> sorry, connection reset by peer
<Keybuk> daniels: seems ok from here
<Keybuk> 220 jackass.warthogs.hbd.com FTP server (Poppy Upload Server) ready.
<bob2> PUS!
<daniels> shit, dbus broken
<pitti> Hi sivang!
<sivang> hi pitti! what's up?
<pitti> sivang: the usual stuff. security review
<pitti> silbs: this time it's a little more since I got a whole bunch (some 135) messages to review from the past
<sivang> pitti : oh. researching/patching stuff..
<sivang> pitti : do you remember the bash line to make foremail resort email from enrico?
* fabbione thanks dpatch for trashing one morning of work
<pitti> sivang: no, I don't have the formail line
<daniels> does anyone know if i8xx/i9xx hardware is available for ia64?
<elmo> err, no
<daniels> phat
<mjg59> daniels: The graphics hardware is in the northbridge, so, uh, no
<pitti> ping Kamion 
<daniels> fabbione: should etc/X11/xinit/xinitrc.d/92xprint-xpserverlist.sh
<daniels> be installed anywhere?
<daniels> it's in all the manifests, but never installed
<daniels> notabug?
<fabbione> daniels: notabug
<fabbione> it's part of the xprint packages
<jdub> HA HA HA:
<jdub> http://article.gmane.org/gmane.comp.video.gstreamer.devel/12118
<jdub> very funny on so many levels
<daniels> fabbione: phat
<daniels> jdub: heh
<fabbione> daniels: but was somebody bitching about it?
<fabbione> clearly dpatch is crap
<daniels> fabbione: no, I'm just trying to decipher the rather cryptic output of mir
<fabbione> hmmm
<fabbione> where is it?
<daniels> elmo: is there a proper ia64 hoary chroot yet?
<daniels> fabbione: scripts/manifest-install-reconcile validate
<daniels> branden's crack script
<fabbione> daniels: ah that!
<daniels> yeah
<fabbione> daniels: it is broken on i386
<fabbione> i never had the time to look at it
<elmo> daniels: dunno, haven't heard back from lamont about gcc-3.4, so I guess not
<daniels> hooray!!!
<daniels> elmo: k
<elmo> doko: ?
<daniels> lamont: new xorg on p.u.c/~daniels/xorg/ which should build fine on ia64, please run another build around
<Kamion> whoa, major display badness in base-config
<daniels> fabbione: ping
<fabbione> daniels: ?
<fabbione> hmmm ok.. 2.6.9-1 at least compiles now
<fabbione> on i386
<fabbione> daniels: i will push your patches in -2 together with the other stuff
<fabbione> given that i can manage to build it on ppc and amd64
<daniels> fabbione: config.log for xpdf would be great
<fabbione> on the way
<daniels> cheers
<fabbione> but these were the relevant part
<fabbione> as usual this is on sparc dude
<fabbione> if it works on our archs don't bother
<fabbione> but i am pretty sure most of the failures are common
<daniels> yeah
<daniels> i don't see how it fails when it b-ds xlibs-dev
<fabbione> daniels: probably something to do with libxkb ?
<daniels> oh, christing puce
<daniels> nope, I bet it needs xutils
<fabbione> or any of the others that we splitted
<daniels> but I have no idea htf that suddenly slipped out, because we didn't touch that
<daniels> could you please throw xutils in b-d and run it around the sparc again?
<fabbione> daniels: not in a short time
<fabbione> i am giving love to 2.6.9
<jdub> * fabbione humps 2.6.9's leg.
<fabbione> jdub: where is the inofity patch?
<daniels> fabbione: ok
<jdub> fabbione: one sec
<jdub> fabbione: people.ubuntulinux.org/~jdub/inotify-0.15.diff
* Kamion looks for decent Unicode console fonts
<Kamion> LatArCyrHeb-* seem to have the greatest coverage
<fabbione> jdub: fix the permissions :-) 403
<jdub> d'oh :)
<jdub> try again?
<fabbione> 403
* jdub grumps, and doesn't cheat this time ;)
<jdub> go go go!
<fabbione> better
<fabbione> hmmmm
<fabbione> it's not extremely intrusive
<daniels> fabbione: re dpatch, I know what you mean -- I lost a fair bit of work to it also
<fabbione> daniels: is sabdfl there around?
<elmo> how do you lose work to dpatch?
<daniels> fabbione: yah
<fabbione> elmo: when it doesn't realize about conflicts and keep patching pile of crap on top of each other
<fabbione> daniels: is he busy?
<daniels> reading mail afaict
<fabbione> ok
<GyrosGeier> elmo, BTW, would you appreciate being sent patches against the gnupg package to bring it up to 1.2.6, or would I waste time preparing them?
* GyrosGeier has an issue with a particularly nasty bug which prevents him from reading stuff encrypted to him with current gpg
<azeem> elmo: dpatch makes your life easier, thus you have to work less :)
<daniels> fabbione: btw, the thunderbird ftbfs is libxp-dev's fault, and xrestop wouldn't get proper shlibs until a fixed libxres is up
<daniels> fabbione: so I'm waiting to upload xorg first (should happen today, barring any major disasters)
<fabbione> daniels: ok
<elmo> GyrosGeier: erk, I didn't realise there was that kind of bug fixes in 1.2.6
<elmo> GyrosGeier: don't worry about it, i started at the weekend - if it's got important bug fixes, I'll try and look at it.. err not this evening, 'cos I'm travelling, but by tomorrow anyway
<GyrosGeier> elmo, no hurry.
<GyrosGeier> elmo, the bug fix in question isn't in 1.2.6, it will probably only be in 1.2.7.
<GyrosGeier> elmo, I'd have sent that one as an extra dpatch.
<elmo> oh - well do you want to send me the patch to it?
<daniels> fabbione: well, I want to get a successful build on ia64 first
<daniels> make lamont quiet down ;)
<daniels> elmo: is there an ia64 chroot anywhere I can build in?
<GyrosGeier> elmo, sure
<daniels> elmo: waiting until 7pm or so for lamont to show is ... er, unappealing
<elmo> daniels: dude, do you have ADD?
<elmo> I'm sure you asked me that question less than 3 hours ago
<daniels> elmo: 'anywhere' doesn't imply 'proper'
<jdub> dudes
<jdub> need some skin testing
<elmo> daniels: I can give you a sid or sarge chroot?
<jdub> http://people.ubuntulinux.org/~jdub/calendar/
<daniels> elmo: that would be great, if I could build render, get that installed, build xrender, get that installed, then kick off xorg
<GyrosGeier> elmo, it's the key selection algorithm, which happily selects a key with only unknown "usage" flags for default usage -- which means my RSA authentication key is used for encryption to me, but my smartcard can only sign with that key. :-)
<daniels> jdub: well, my background capplet hangs, fwiw
<daniels> writev(21, [{"GIOP\1\2\1\0\272\2\0\0", 12}, {"\260\351\377\277\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0Z\316"..., 698}] , 2) = 710
<daniels> futex(0x8090060, FUTEX_WAIT, 
<daniels> word
<Mithrandir> so does nautilus here
<fabbione> there... and 2.6.9 compiles on amd64
<daniels> jdub: aside from the hang, it's rad
<rburton> jdub: re: wallpaper. WAHEY
<daniels> the only word to describe it is 'guff'
<jdub> there's another one of eileen too
<daniels> ok, am I drunk, or is this just stupendously crap?
<daniels> include/asm/setup.h:8:28: asm-m68k/setup.h: No such file or directory
<jdub> but it's a bit more raunch
<daniels> (hoary-chroot)daniels@davis:~/kernel/linux-restricted-modules-2.6.8.1-2.6.8.1.4 $ head -n 1 /usr/include/asm-m68k/setup.h
<daniels> /*
<daniels> jdub: which one is eileen?
<jdub> the blonde
<daniels> ahr
<daniels> so is that january?
<GyrosGeier> elmo, send as a (wishlist) bug or as mail?
<jdub> december
<elmo> GyrosGeier: either is fine
<daniels> jdub: er, didn't you just put december up?
<GyrosGeier> elmo, okay, thanks a lot!
<jdub> oh
<jdub> right, so, eileen-raunch won't be january, because we're using her for december
<jdub> january will probably be CONTROVERSIAL MAN NUDITY
<fabbione> jdub: nooo
<jdub> i expect people will make a big deal about it ;)
<fabbione> put naked santa for december!
<jdub> heh
<Kamion> GAH
<rburton> jdub: december should be naked santa + elves
<Kamion> it would *really* help if the tools I was using to look for characters in fonts (on a powerpc system, as it happens) were endian-clean
<daniels> Kamion: yow
<fabbione> jdub: do you realize that inotify patches only for i386?
<Kamion> I was wondering why U+2500 (BOX DRAWINGS LIGHT HORIZONTAL) looked suspiciously like a percent sign
<fabbione> jdub: i can try to add the few missing lines to amd64/ppc, but it will really need some extra test
<jdub> serious?!
<fabbione> patching file include/asm-i386/resource.h
<fabbione> patching file arch/i386/kernel/init_task.c
<fabbione> that's it
<fabbione> do an lsdiff on the patch
<Kamion> quality
<jdub> fabbione: http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/0.16/inotify-0.16-wip-rml-2.6.10-rc2-9.patch
<jdub> fabbione: that's rml's work in progress on 0.16
<jdub> doesn't touch those files
<fabbione> hmm
<fabbione> too bad.. this onw was applying erfectly :-)
<jdub> heh
<fabbione> http://www.kernel.org/pub/linux/kernel/people/rml/inotify/README.dev
<fabbione> Optionally set the permissions as you like:
<fabbione> % chown root:root /dev/inotify
<fabbione> % chmod 666 /dev/inotify
<daniels> nice.
<fabbione> And run, run free!
<fabbione> jdub: are you going to package inotify utils?
<jdub> fabbione: didn't know about them until about an hour ago ;)
* jdub is not too concerned about them
<fabbione> ahah this guy is fun
<fabbione> inotify and you, happy ever after
<jdub> yeah, rml is fun :)
<seb128> jdub: please add "libgnome-menu0 gnome-menus libgnome-menu-dev" to the desktop seed 
<jdub> seb128: ok :)
* sid77 hi!
<seb128> grrrr, new soname change in libgtop
<seb128> that's getting annoying
<daniels> (hoary-chroot)daniels@davis:~ $ cat foo.c
<daniels> #include <asm-m68k/setup.h>
<daniels> #include <stdio.h>
<daniels> int main(int argc, char **argv[] ) { printf("christing puce\n"); return 0; }
<daniels> (hoary-chroot)daniels@davis:~ $ gcc -o foo foo.c
<daniels> (hoary-chroot)daniels@davis:~ $ 
* daniels radiates pure hate at davis.
<fabbione> dude
<fabbione> don't mess davis around
<fabbione> i will need it soon and alive
<fabbione> ;)
<daniels> well, apparently asm-m68k/setup.h is unfindable as an include
<daniels> which is funny
<daniels> because it seems to be right there, in /usr/include
<Kamion> what does "eth0: duplicate address detected" mean?
<fabbione> Kamion: an ipv6 error probably
<Kamion> my current install is spewing it over the terminal every so often
<jdub> seb128: does gnome-menus depend on libgnome-menu0?
<Kamion> didn't use to happen
<fabbione> DAD has detected 2 machines with the same address
<fabbione> Kamion: do you happen to have 2 machines with the same macaddress?
<fabbione> even faked
<fabbione> that would cause that kind of errro
<fabbione> error
<seb128> jdub: no, dunno if it should. It only contain .desktop/.menus files and gnome-menu-spec-test ... hum yes, it should for the gnome-menu-spec-test 
<seb128> jdub: why ?
<jdub> seb128: i'm just adding gnome-menus, that ought to bring the whole source pacakge into main
<jdub> seb128: panel depends and so on will handle the other two :)
* fabbione starts to feel less rusty on the kernel code
<seb128> jdub: ok
<Kamion> fabbione: don't think so, will check when I can
<fabbione> Kamion: it can easily be a bug in DAD
<lamont> daniels?
<daniels> lamont: dude!
<daniels> lamont: new xorg? :)
<lamont> daniels: last I heard, it died in manifest, and I gave you the files... been waiting for an upload...
<lamont> elmo/daniels: gcc-3.4 is a doko question, I believe
<daniels> lamont: there's a new one on p.u.c/~daniels/xorg that I wouldn't mind a test on
<daniels> easier than another upload
<lamont> ah, ok
<daniels> lamont: ok, cool
<fabbione> Inotify file change notification support (INOTIFY) [Y/n/?]  (NEW) 
<fabbione> i am really not sure what to answer here
<fabbione> ;)
<jdub> yay :)
<jdub> YAY FABBIONE DON'T MAKE ME HURT YOU
<fabbione> jdub: we need to see if it compiles everywhere first
* lamont beats daniels
<lamont> xorg is ftbfs...  no xorg
<fabbione> let's not get overexcited
* jdub crushes resistance from weaker architectures
<lamont> daniels: this is going to require more time to get started than I have right now.  need to take the kids to school in about 5 minutes.
<daniels> lamont: how's it ftbfs, btw?
<lamont> jdub: working on spark, eh?
<zul> umm...on the conference page on the wiki shouldnt that be Devember 5 rather than august 5
<lamont> daniels: missing build-deps
<daniels> lamont: huh?
<daniels> they haven't changed since the last run
<lamont> because of xorg delivering some arch: all packages that replace xfree86 ones.
<zul> mdz: ping
<daniels> i'm confused, but ok
<lamont> daniels: I upgrade the chroots nightly
<daniels> lamont: ehm, ok
<lamont> amd a recent nightly upgrade broke everything that needs X.
<fabbione> daniels: mozilla fails exactly as thunderbird
* lamont will argue with it for a mintue or two now and see how bad it really is
<daniels> fabbione: yeah, libxp-dev bustage
<daniels> lamont: nice!
<fabbione> daniels: i am adding stuff to 4208
<fabbione> daniels: let's keep it as metabug
<daniels> k
<daniels> but
<daniels> please file a separate bug for xp-depends-on-xau
<fabbione> daniels: i am not digging into the details
<fabbione> daniels: i am just watching failures
<elmo> apt-get: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory
* elmo beats doko
<lamont> daniels: Note, selecting xorg-common instead of xfree86-common
<daniels> elmo: oops
<Mithrandir> elmo: known problem.
<daniels> lamont: right
<lamont> elmo: that's a missing Depends that I thought got fixed.
<lamont> Depends: libunwind7, fwiw
<elmo> Mithrandir: I know it's known
<elmo> but the fact is, sid is still fux0red
<lamont> daniels: and that's why xorg won't build without applying a bat
<daniels> lamont: xorg build-deps on xorg-common?
<lamont> no.  xorg build-deps on something (X, from xfree86), that in turn, depends on xfree86-common
<daniels> hooray!
<lamont> and then we pick xorg-common instead, and none of the xf86 libraries are installable
<lamont> and we die.
<lamont> once I forced xfree86-common to install (wget & dpkg -i), then (and only then) are the build-deps for xorg installable.
<daniels> heh
<lamont> (which is to say, build started)
<daniels> phat, thanks dude
<daniels> by the way, nice work jimmying the jelly belly machine
* daniels -> dessert
* lamont has to run the kids to school, then has to get his car looked at before he can do anything else.  may be gone for a while, hoping/planning to make the TB meeting today.
<lamont> daniels: so if you get anxious, beg elmo to look on floe for you.  (elmo - don't restart the buildd there - I need to prune the chroot before that happens.
<lamont> log file won't go to rookery automatically
<daniels> thanks dude
<lamont> no log file --> totally opaque.
<daniels> elmo: can you please look on floe?  are we there yet?  is it done?  are we there?
* daniels goes to grab some more sugar.
* lamont throws rocks after daniels, so that elmo doesn't have to get violent
<rburton> daniels: so how long would X take to build on a 200mhz 64-meg netwinder?
<lamont> daniels: last build attempt died at 2:11:26 into the build attempt
<lamont> but that's essentially done
<lamont> so don't pester elmo before 2.5 hours have elapsed.
* lamont runs kids to school, car to mechanics
<jdub> elmo: u-c{,-d} incoming
<daniels> rburton: almost as long as the train from orpington to arrive
<daniels> possibly longer
<jdub> orpington spa!
<rburton> daniels: blimey
<daniels> elmo: is it possible to get access to floe so I can poke the logs without ADDing you out?
<lamont> oh, and xpdf_3.00-9ubuntu3 is b0rked if no one has uploaded -4 yet
<lamont> daniels: I expect the answer to that is 'no'
<daniels> lamont: bugger
<jdub> night boys and girls. and daniels.
<thom> night jeffyweffy
<daniels> agh, so much crack
<daniels> jdub: night fluffy bunny
<rburton> jdub: sleep tight
<daniels> AGH
* daniels beats xpdf severely.
<sivang> daniels : is it dead yet?
<daniels> no, it's still bleeding and I intend to keep it alive for as long as possible
<bob2> just add Type3 font rendering to gpdf
<daniels> elmo: ping
<daniels> elmo: (not about xorg)
<elmo> daniels: ?
<daniels> elmo: how difficult is it to get a hoary chroot + b-e + xpdf build-deps?
<elmo> b-e?
<daniels> this xpdf problem is totally wack
<elmo> and what arch?
<daniels> build-essential
<daniels> i386 is fine
<daniels> but i'll take what I can get
<elmo> you get... [spins wheel] ... concordia!
<bob2> haha
<daniels> da da da da!
<daniels> (can I pluck a duck?)
<fabbione> not concordia please :-)
<fabbione> i need to build the kernels :-)
<thom> i doubt concordia cares
<fabbione> i do
<elmo> fabbione: dude, it's a dual proc machine
<elmo> it really can handle a build of the kernel +xpdf at the same time
<daniels> xpdf is, um, smal
<fabbione> elmo: oh did you enable it in smp?
<daniels> l
<daniels> yes
<elmo> fabbione: yeah
<daniels> oh, bite me
<daniels> xpdf is the frigging xprint issue
<daniels> elmo: you can delete xpdf b-ds now, thanks
<elmo> it was only lesstif, I'll leave them there
<daniels> kthx
* fabbione hugs and dances around elmo
<fabbione> next time i can run make -j 4
<fabbione> and kill it :-)))
<fabbione> MUHA MUHA MUHA
<thom> you'll need to try harder than that
<daniels> ... yeah
<daniels> like, full archive rebuild in parallel
<daniels> all with -j2
<Kamion> ooh, 'sudo charset --tty=/dev/tty1 G0 /usr/share/consoletrans/trivial.trans' makes base-config's window borders display properly
<Kamion> BECAUSE THAT WAS OBVIOUS
<fabbione> AHHA
<daniels> Kamion: duh
<elmo> gaaaar
<elmo> our buildd hacks break multi-distro uploads
<elmo> daniels: halley has a sarge chroot if you still need it
<daniels> elmo: ia64, yeah?
<elmo> yeah
<daniels>  ta
<daniels> it's just xorg, really
<lupus_> daniels, I have a multimedia keyboard and I open xev to get to keycodes and like 6 keys seem to generate no keypress event 
<daniels> lupus_: yeah, that will happen
<lupus_> why is this?
<daniels> you have to load the layout for your keyboard
<daniels> because they all use dodgy hacks that violate usb hid and ps/2 kb specifications
<lupus_> hmm
<lupus_> I found a patch from the keyboard manufacture
<daniels> OH MY GOD THE POWERPC TOOLCHAIN IS SO BROKEN
<lupus_> it has 2 patches: hid-core.c and hid-input.c
<daniels> if I run make with CFLAGS=-I/usr/include, it works
<elmo> dude, the chance that that is in fact the toolchain being broke is so unbelivably small
<elmo> if gcc couldn't get /usr/include right, I think we would have noticed by now
<daniels> elmo: davis:~daniels
<daniels> in the hoary chroot, cd to ~daniels/kernel/linux-restricted-modules-2.6.8.1-2.6.8.1.4
<daniels> broken: make -C /usr/src/linux-headers-2.6.8.1-3-power3 SUBDIRS=/home/daniels/kernel/linux-restricted-modules-2.6.8.1-2.6.8.1.4/debian/build/2.6.8.1-3-power3/madwifi/ath_hal modules
<daniels> not broken:  make -C /usr/src/linux-headers-2.6.8.1-3-power3 SUBDIRS=/home/daniels/kernel/linux-restricted-modules-2.6.8.1-2.6.8.1.4/debian/build/2.6.8.1-3-power3/madwifi/ath_hal CFLAGS=-I/usr/include modules
<Kamion> seems more likely that the un-overridden CFLAGS includes something that brekas
<Kamion> breaks
<daniels> Kamion: well, alright, but it was convenient to blame the toolchain ;)
<fabbione> daniels: i don't want to destroy your dreams
<fabbione> but linux-restricted-modules is NOT supposed to build anything on ppc
<fabbione> only amd64 and i386
<daniels> fabbione: yes it is.
<Kamion> fabbione: recent change
<daniels> fabbione: madwifi supports i386, amd64 and powerpc
<fabbione> ahhhh
<daniels> can you even tell gcc to ignore /usr/include?
<elmo> yes
<elmo> in fact, if you give "-I", I think that wipes out the default includes
<elmo> tho that may have been a bug that was fixed
<Kamion> -nostdinc suppresses /usr/include
<Kamion> hmm, I wonder where my old stack of floppies went
<Kamion> oh yes, that's right, *1990*
<Mithrandir> heh, that's one of the reasons I saved a huge bunch of floppies when we cleaned a bit in a room at my father's workplace.  Unused win95 install floppies.
<Mithrandir> they were crucial to d-i's initial development. :)
<Kamion> :)
<Kamion> I'm sure MS would be happy to hear that
<Mithrandir> it's probably in violation of the EULA or something
<zul> nah...they wouldnt care
<daniels> Kamion: ping?
<Kamion> daniels: pong
<daniels> Kamion: how flexible is your kernel-package-fu?
<daniels> Kamion: i just had a flash of realisation -- l-k-h is irrelevant to *kernel* *modules*
<daniels> so we need to install asm-* in the kernel packages
<fabbione> eh?
<fabbione> daniels: l-k-h is all you need... really
<daniels> fabbione: for building a kernel module (i.e. madwifi)
<fabbione> yes
<fabbione> like the nvidia and all the others
<daniels> which all build-dep on the relevant linux-headers package for each flavour
<daniels> and use -nostdinc
<fabbione> correct
<daniels> ...
<fabbione> see the nvidia bits.. they don't ask for kernel-source
<fabbione> they ask for headers
<fabbione> that's all they need
<Mithrandir> fabbione: you do _not_ want l-k-h, you want l-h.
<daniels> the nvidia bits ask for l-h
<daniels> l-k-h is for userspace programs, l-h is for kernel stuff
<daniels> why I didn't realise that I was building a kernel module ages ago is beyond me
<fabbione> Mithrandir: yes.. that one
<daniels> fabbione: right
<fabbione> daniels: sorry it was l-h
<daniels> fabbione: what's happening is that asm-ppc/setup.h in l-h #include's asm-m68k/setup.h
<daniels> which gets nicely optimised out
<fabbione> i would suggest you nicely ship your own copy of that file
<daniels> argue it with elmo
<lupus_> oeh openoffice now upgrades :)
<fabbione> daniels: i really think this is a "one exception" situation
<daniels> fabbione: not really, it's sprinkled throughout asm-*
<fabbione> daniels: otherwise we should change all l-h
<daniels> that's what I'm doing with l-s
<fabbione> daniels: yes, but not all archs have that kind of situation
<daniels> and the solution herbert suggested and elmo agreed to
<daniels> s/to/with/
<daniels> so I'm going to defer to those experience
<Kamion> daniels: heh, I see everyone else beat me to it while I was hunting for floppies
<daniels> Kamion: l-h?
<Kamion> daniels: yep
<Kamion> daniels: l-k-h is only for internal use by glibc
<daniels> yeah
<Kamion> (and by broken packages)
<daniels> Kamion: a sound of me smacking my head into the desk resonated around the lunchpad
<daniels> well, not really, but it was a massive 'oh shit' moment
<pitti> Hi doko!
* #ubuntu-devel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
(elmo/#ubuntu-devel) daniels: what about them?
(daniels/#ubuntu-devel) elmo: is it still building on ia64?
(elmo/#ubuntu-devel) dh_install --sourcedir=debian/tmp
(elmo/#ubuntu-devel) cp: cannot stat `debian/tmp//usr/X11R6/lib/modules/dri/ffb_dri.so': No such file or directory
(elmo/#ubuntu-devel) dh_install: command returned error code 256
(daniels/#ubuntu-devel) thanks
(elmo/#ubuntu-devel) is that all you need?
(daniels/#ubuntu-devel) could you please remove usr/X11R6/lib/modules/dri/ffb_dri.so from debian/xlibmesa-dri.install.ia64, and run fakeroot d/r install?
(sivang/#ubuntu-devel) ubuntulog is so shy today
<elmo> make: Nothing to be done for `install'.
<fabbione> sivang: ehehe
<fabbione> sivang: it will never answer
<daniels> elmo: er, sorry, binary-arch
<fabbione> useless to msg him
<elmo> dh_install --sourcedir=debian/tmp
<elmo> cp: cannot stat `debian/tmp//usr/X11R6/lib/modules/dri/ffb_dri.so': No such file or directory
<elmo> I did edit the file ...
<daniels> ahr, crap
<daniels> could you please kick it out of xlibmesa-dri-dbg.install.ia64 also?  sorry
<sivang> fabbione : well, I tried my luck :) I used to have long life philosophy talks with dpkg
<elmo> cp: cannot stat `debian/tmp//usr/X11R6/lib/modules/fonts/libxtt.a': No such file or directory
<lupus_> lupus@lupus ~ $ oowriter
<lupus_> I18N: X Window System doesn't support locale "en_US.UTF-8"
<lupus_> normal?
<daniels> lupus_: yes
<daniels> bug, will be fixed
<daniels> elmo: please prune that from xserver-xorg.install.ia64
<daniels> elmo: sorry about this
<elmo> cp: cannot stat `debian/tmp//usr/X11R6/man/man1/gtf.1x': No such file or directory
<fabbione> all the man1 are now 1 and not 1x
<fabbione> you can catch all of them in one shot
<daniels> please change gtf.1x to gtf.1 and remove i810.4x in xserver-xorg.install.ia64
<daniels> and that'll be it afaict
<elmo> what about all the other 1x's, change them like fabbione said?
<daniels> elmo: that's the only one left
<elmo> oh, they're 4x's
<daniels> yah
* elmo goes back to sleep
<daniels> heh
<fabbione> anybody with amd64 that feels REALLY lucky today?
<bob2> thombot!
<fabbione> http://people.ubuntulinux.org/~fabbione/kernel/
<fabbione> ppc and i386 will arrive later
<elmo> cp: cannot stat `debian/tmp/usr/X11R6/lib/X11/doc/Status': No such file or directory
<elmo> if [ -e debian/tmp/usr/X11R6/man/man1/Xorg.1x ] ; then \
<elmo> shouldn't that be .1 ?
<daniels> good catch
<fabbione> no
<fabbione> the one after renames it
<fabbione> to Xorg.1
<fabbione> doesn't it?
<elmo> not that I can see
<daniels> elmo: please ditch just the Status
<daniels> fabbione: i'll deal with Xorg.1*
<daniels> fabbione: yeah, elmo's right, it's busted, so I've fixed
<elmo> daniels: ditch it from where?
<fabbione> xserver-xorg.doc iirc
<daniels> xserver-xorg.docs.ia64
<fabbione> mdz: http://people.ubuntulinux.org/~fabbione/kernel/changelog
<fabbione> mdz: i know you have an amd64...
<fabbione> so dig in that dir and test please :-9
<fabbione> daniels: i will try to add your patches tomorrow
<fabbione> daniels: 210 lines of summarized changelog are scary enough already
<elmo> looks happier now, it's up to dh_shlibdep-ing
<daniels> fabbione: nice
<daniels> elmo: thanks heaps
<lupus_> oeh inotify :p cool :)
<fabbione> lupus_: if it works...
<fabbione> these packages are like: they compile: cool.. they work
<lupus_> I wonder if gamin needs a recompile to make it use inotify
<fabbione> lupus_: don't run
<fabbione> there are several things that needs to be done before that
<lupus_> k :)
<fabbione> like making udev aware of inotify
<fabbione> and test
<lupus_> ah didn't know udev also could use it
<fabbione> udev needs to create the device
<fabbione> it doesn't use it
<fabbione> but without the device the application does nothing
<lupus_> ic
<elmo> daniels: that worked btw
<enrico> fabbione: Lupin usa Linux!
<enrico> sorry, that shuold have been private
<daniels> elmo: cheers
<Kamion> elmo: are the other daily-installer-* uploads still waiting in byhand?
<daniels> concordia is whizzy and fun
<elmo> Kamion: they didn't exist last I looked
<elmo> yeah, just amd64 got uploaded
<Kamion> huh, weird
<Kamion> they all built fine
<fabbione> Kamion: why weird?
<fabbione> because they found the udebs?
<fabbione> ;)
<Kamion> fabbione: I thought lamont autosigned and autouploaded stuff nowadays
<Kamion> fabbione: no, I mean weird that they didn't get uploaded, not that they built, you tramp :P
<fabbione> Kamion: ahahha
<fabbione> Kamion: amd64 built 2.6.9-1 + udebs btw
<fabbione> and dunno if you noticed that there is a ufs udeb
<fabbione> not sure where that come from
<fabbione> (also in 2.6.8.1)
<mxpxpod> daniels: when is xorg 6.8.2 scheduled to be released?
<Kamion> fabbione: yes, I noticed, that's been there for ages
<Kamion> fabbione: it's support for os-prober code that Alastair never got round to writing
<fabbione> ah ok
<Kamion> fabbione: guess I have to change debian-installer over to 2.6.9 soon ...
<fabbione> Kamion: i need at least another day to be able to upload
<fabbione> + consider the breakage
<Kamion> indeed
<fabbione> because i am sure that something will go wrong
<fabbione> it's too long that i don't play with the kernel at this level
<Kamion> fabbione: the installer's broken at the moment as it is :P
<Kamion> (thanks, udev)
<fabbione> eheh
<fabbione> that will give you a couple of days before it will break for the kernel
<fabbione> ahha
<daniels> mxpxpod: dec 17th, but that will almost certainly slip to the new year, thanks to the fd.o compromise
<elmo> Kamion: d-i's reset back to the non-daily variant for i386, powerpc.. you might want to bug lamont about it
<mxpxpod> daniels: suck
<Kamion> elmo: hmm? EPARSE
<elmo> oh, sorry.. in wanna-build
<elmo> the version number's gone back to what's in the archive, rather than the version number hack, lamont uses for the daily build
<Kamion> lamont_r: good timing to show up
<elmo> which is why it can't upload
<Kamion> lamont_r: (this is re the daily d-i build, see what elmo said ...)
<lamont_r> gah
<lamont_r> version number hack got lost?
<elmo> no, worked for amd64
<elmo> but not i386/powerpc.. maybe it's a timing issue again?
<lamont_r> daniels: you here?
<elmo> lamont: btw, I finished the floe build for him
<lamont_r> finished == gave him the error log?
<lifeless> mdz: care to package baz 1.0 now ?
<lifeless> sample debs on bazaar.canonical.com
<mdz> lifeless: TB meeting in progress
<lifeless> oops, sorry.
<lamont_r> could be a timing issue, could be that the script didn't get overwritten on amd64...  will look
<lifeless> I won't ask what TB means.
<elmo> lamont: iterated through, building it until it finished successfully
<daniels> Uploading via ftp xorg_6.8.1-1ubuntu4_source.changes: done.
<daniels> Successfully uploaded packages.
<daniels> Not running dinstall.
<daniels> daniels@chinstrap ~/tmp-upload $ 
<daniels> \o/
<daniels> lamont_r: sup?
<daniels> lifeless: tech board
<lamont_r> ah, ok.  because the last log I saw had errors...
<daniels> lamont_r: yeah, elmo coaxed it through and I fixed stuff
<lamont_r> ah, ok
* lamont_r kills the rsync he was doing
<lamont_r> daniels: when did you upload 4?
* lamont_r could look, but...
<lamont_r> is in archive?
<elmo> -rw-r--r--    1 poppy    poppy       15967 Nov 30 17:23 xorg_6.8.1-1ubuntu4_source.changes
<elmo> in queue/unchecked
<Kamion> lamont_r: if this is non-trivial to fix please let me know, 'cos otherwise I need to upload debian-installer - the version currently in the archive is broken
<lamont_r> Kamion: will deal with it.  relatively trivial either way, just need to do it.
<lamont_r> ok.
<lamont_r> elmo: I need to babysit that through floe once it shows up, then I can restore floe to normal operation.
<lamont_r> daniels: xorg/ia64 build-for-upload running now
<elmo> err, if you're having to manually bootstrap this, aren't debian arches going to have the same problem?
<daniels> lamont_r: awesome, thanks
<lamont_r> elmo: xorg builds fine on architectures taht have xorg
<elmo> which is crack, surely?
<lamont_r> the issue is that apt chooses xorg-common over xfree86-common, so you have to force that issue before it builds on xfree86
* lamont_r points at daniels
<elmo> what are you going to do, manually bootstrap the 9 other arches in Debian?
<lamont_r> elmo: xorg-common is arch: all
<lamont_r> so as long as all the binaries upload together.....
<lamont_r> otherwise, daniels has some issues...
<lamont_r> daniels: it might be easiest for debian if there weren't any arch: all packages (that were depended on by anything at least) for the initial upload, until all architectures have uploaded..
<lamont_r> which is still a crackful hack
<elmo> if it's just xorg-common apt gets wrong, surely you can just make that arch: any?
<daniels> OH MY GOD
* daniels stares at elmo.
<elmo> what?
<daniels> dude, crack
<elmo> Size: 826834
<elmo> that x 11
<lamont_r> elmo: xorg-common is the one I know.  the issue is anything else that he has replacing that thuroughly, which is depended on by anything
<elmo> or manually bootstrap 8 architectures
<elmo> I know which is crack, and it's not my suggestion
<fabbione> daniels:    * Stop writing out HorizSync and VertRefresh lines to xorg.conf; if it can
<elmo> but hey, it's your call, just don't expect me to manually bootstrap any of my Debian arches for you :-P
<fabbione> this is going to break horribly
<fabbione> good luck :-)
<daniels> fabbione: so you say :)
<fabbione> daniels: i can open a bug right now for it
<daniels> elmo: blah, interesting
<daniels> fabbione: eh, assign it to yourself if you're going to open it before we have any real bug reports
<fabbione> daniels: you plug your nice monitor, ddc works perfectly
<fabbione> daniels: you put a kvm switch, ddc doesn't go trough
<fabbione> kthkbye...
<fabbione> that's it
<fabbione> same hardware
<fabbione> the driver will go banana
<fabbione> daniels: if you want i can test it with my 17" 
<daniels> at the same time, we're actively tanking LCDs and DVIs with HS/VR
<fabbione> daniels: directly connected it returns ddc
<daniels> my first response to any display problems is to tell people to remove HS/VR, and it works in like almost all cases
<fabbione> daniels: but not via the kvm
<daniels> yes, I know the KVM case
<fabbione> daniels: and i know my kvm is ok, since it returns properly ddc info from the 21"
<daniels> i think the damage from KVM is far, far, far, far, far, far, far, far, far less than the current damage
<elmo> why do kvm's hide ddc info anyways?
<daniels> elmo: can you please requeue xpdf?
<elmo> uh?
<daniels> fabbione: xpdf just needs a requeueing also
<elmo> requeue it wear?
<elmo> err where
<daniels> elmo: all our buildds
<fabbione> elmo: because some of them are cheap and instead of passing all the 25(??) cables, they only pass the minimum they need
<daniels> elmo: aiui vga needs the data pins, so it's also easier than dtrt in the ddc case
<elmo> fabbione: duh, that sucks
<fabbione> elmo: others simply don't amplify signals properly
<fabbione> elmo: like you can see the image a bit blurry
<fabbione> instead of sharp
<fabbione> elmo: i agree, but it is still a reality
<elmo> yeah, I stopped using a mini-kvm thing at work 'cos of the image degradation
<fabbione> elmo: i got a good one and i can't complain
<elmo> that looked like a student's electronics homework tho
<fabbione> it starts altering the image only over 1600x1200
<fabbione> ehhehe
<daniels> fabbione: requeue mozilla/mozilla-thunderbird also
<elmo> daniels: what's changed that'll make xpdf build?
<fabbione> daniels: i will after ubuntu4 will build
<fabbione> daniels: otherwise it's useless
<daniels> elmo: libxp-dev needed to dep libxau-dev; it was looking at the motif includes, which used the xp includes, which needed to dep libxau-dev, but didn't, so it decided we didn't have motif
<daniels> thumbs up to motif!
<fabbione> food
<fabbione> later
<elmo> daniels: then surely we have to wait for the new X to build?
<daniels> elmo: er, yah
<daniels> forgot about this 'multiple buildds' concept
<daniels> fabbione: how far along are you with with 2.6.9?
<Kamion> daniels: so presumably it needs a dep-wait rather than a requeue
<daniels> fabbione: i want to look at it as soon as i can to get l-r-m up to speed
<daniels> Kamion: well, yeah
<daniels> Kamion: but don't bring sense into this
<elmo> daniels: please ask lamont to do that then - i can't do it particularly easily
<daniels> elmo: 'k
<daniels> lamont_r: please dep-wait xpdf on libxp-dev 6.8.1-1ubuntu4
<lamont_r> daniels: ok
<daniels> lamont_r: ta
<lamont_r> done
<lamont_r> seb128: gnome-menus yours?
<seb128> yep
<lamont_r> :-(
<seb128> raaaaah, I've tested it in a pbuider before uploading !
<lamont_r> gnome-media is unhappy too
<seb128> stupid control.in -> control stuff, I've forgotten to update it before rebuilding
* lamont_r is just the messenger.. :)
<seb128> yep, ok, will fix both now
<seb128> thanks for noticing
<seb128> we should have a http://people.debian.org/~igloo/status.php :p
<lamont_r> what does that do?
<lamont_r> is that ij's crap?
<lamont_r> er, stuff/
<elmo_away> no
<elmo_away> it's igloo's, it's probably reasonably sane, but really we should spend time on a better backend, than frontend niceness
<elmo_away> plus PHP makes me want to run screaming into the night
<enrico> Hello.  Small question from the docteam: does ubuntu use stable->warty, unstable->hoary links like Debian?
<enrico> Ehm, testing->hoary
<enrico> plovs: I just asked
<Kamion> enrico: not in the archive
<Kamion> enrico: the CD has them for historical reasons (i.e. Kamion never got around to removing them from debian-cd and seeing what broke in d-i)
<enrico> Kamion: ok.  since people were working on apt manpage, that is a needed piece of information
<daniels> Kamion: kamion decided that in his wisdom, did he?
<Kamion> daniels: yuh-huh
<fabbione> daniels: probably tomorrow
<daniels> fabbione: ok
<daniels> Kamion: and how is Kamion today?
<fabbione> daniels: amd64 needs testing, ppc and i386 are still building
<daniels> fabbione: any chance I could get a look so I could start building l-r-m against it and see what breaks?
<fabbione> daniels: the configs need to be alligned and than i need to stick your patches in
<fabbione> daniels: hmmm not really.. no
<daniels> fabbione: ok
<fabbione> daniels: you can look at amd64
<Kamion> daniels: 'nuff of the third person already. :)
<fabbione> daniels: people.u.c/~fabbione/kernel
<daniels> fabbione: er, source packages?
<fabbione> daniels: ehm no.. i builded -b -B
<fabbione> you will have to wait
<_rene_> -b -B? isn't that redundant? ;)
<daniels> well, as soon as you can give me a source package, I can start testing l-r-m with madwifi across amd64/i386/powerpc, nvidia across amd64/i386/ia64, fglrx just on i386, and updated versions of all three
<fabbione> there is no ia64 kernel
<daniels> not yet
<daniels> but I put the infrastructure in for it to handle multiple versions on different architectures
<fabbione> daniels: ppc just finished the build. i am rebuilding to verify the configs with arch all
<mxpxpod> fabbione: we have a 2.6.9 .deb?
<fabbione> mxpxpod: no
<fabbione> not yet
<mdz> thom: is today moving day?
<mdz> ah, yes
<daniels> mdz: yah, he's offline
<fabbione> mdz: p.u.c/~fabbione/kernel <- please test :-)
<Kamion> ooh, I think I might be making progress with #3007
<fabbione> mdz: sorry.. did i ever ask you to test the amd64 kernel?=
<mdz> fabbione: no, but I can do that
<fabbione> oh thanks
* fabbione mutates in the sparcporter
<fabbione> now.. time to figure out why the sparc kernel doesn't show char devices
<fabbione> mdz: btw.. another hoarygoal is gone.. inotify is in 2.6.9
<fabbione> no idea if it works
<fabbione> we will figure it out :-)
<mdz> fabbione: can you generate a Packages.bz2?
<fabbione> mdz: sure...
<mdz> fabbione: great, thanks
<fabbione> sec
<fabbione> mdz: deb http://blabla/kernel/ ./
<mdz> thanks
<pitti> fabbione: will gamin automatically use inotify if it is available?
<fabbione> pitti: ENOCLUE
<pitti> fabbione: or does that need some compile time tweaks?
<pitti> fabbione: okay, nevermind
<fabbione> pitti: read above what i wrote to lupus_
<fabbione> pitti: first we need something (udev) to create the inotify device properly
<fabbione> than check how to use it
<fabbione> and see if the overall works
<fabbione> repeat until
<fabbione> pitti: instead i would like to know something more about the mail mdz has been sending
<fabbione> since i am planning the upload for tomorrow
<mdz> fabbione: booting amd64
<fabbione> mdz: with the new kernel?
<mdz> yes
<fabbione> uhuhuh
<mdz> 2.6.9-1-amd64-k8
<fabbione> check in the dmesg if you see something about inotify
<mdz> I will, if it comes up :-)
<fabbione> oh..you do have a monitor to check, don't you?
<pitti> fabbione: I will collect the outstanding issues and write you
<fabbione> mdz: your silence is scary.. talk to me
<fabbione> pitti: yes asap please
<mdz> mdz@andy:~ $ dmesg | grep inotify
<mdz> inotify device minor=63
<mdz> fabbione: works
<fabbione> AHAHAHA
<fabbione> YEAH YEAH YEAH YEAH YEAH
<fabbione> AHAHAHAH
<pitti> fabbione: congrats! :-)
<fabbione> pitti: this is one out of N archs
<fabbione> let's take it easy
<pitti> but it's a major step
<fabbione> atleast i can still have a wage for the next month not crashing mdz pc
<pitti> and it's nice to see that _something_ is already working :-)
<mdz> fabbione: we don't need to worry about s390 security fixes quite yet :-)
<fabbione> and that's a great step :-)
<daniels> fabbione: hey man, I tanked his XKB stuff with X.Org in Oxford, and I'm still here
<fabbione> mdz: it's a 2 line patch and it doesn't touch any code outside s390
<fabbione> so i didn't care to merge it.. i just did it
<fabbione> daniels: are you sure?
<fabbione> daniels: are you sure you are not dreaming to be here?
<mdz> fabbione: I think there are CVE references which can be added for several of the security fixes which don't have them yet; pitti should have the info
<fabbione> because when the dream is so real and you don't wake up.. how can you distinguish the dream from the reality?
<pitti> mdz: I asked Herbert to change the 16.1 changelog
<pitti> mdz: I have them, yes
<daniels> fabbione: heh
* fabbione needs an overdose of crack.. first X.. now the kernel
<mdz> fabbione: what happened to mlock-as-user?
<pitti> getting poetical?
<mdz> fabbione: is it included in 2.6.9, or did it conflict?
<fabbione> mdz: there are a lot of bits that have been merged upstream
<fabbione> mdz: and i am not completely sure if what is in upstream replaces what we have in 2.6.8.1
<fabbione> if only there was a fucking line of documentation from herbert
<mdz> fabbione: why ACPI_BLACKLIST_YEAR=0?
<fabbione> all the patches are naked
<fabbione> mdz: because that is the current behaviour
<fabbione> mdz: so there will be no regression
<fabbione> there is not a single line that tells when/where the patch was stolen
<mdz> fabbione: ah, ok
<daniels> eh
<mdz> I thought the default was 2000 or such
<daniels> no
<daniels> it blacklists everything < 2001
<fabbione> mdz: not according to mjg59 
<daniels> i had to do acpi=force on my omnibook
<daniels> i can tell you for absolute certainty that it blacklisted by year previously
<daniels> my omnibook had a great acpi implementation (s3 and all) that just worked out of the box, but i had to do acpi=force, because it was 'too old'
<mdz> fabbione: if he says we should use ACPI_BLACKLIST_YEAR=0, I believe him
<fabbione> mdz: that's why i did ask him this morning :-)
<mdz> fabbione: was sk98lin-update merged upstream as well?
* fabbione estracts the sodomotron remote control and points it to the kernel sparc porters
<mdz> oh, that was taken from bk I think
<mdz> I was thinking of skge-hotplug
<fabbione> mdz: sk98 is another one that partially merges
<mdz> that has not been submitted upstream I don't think, and perhaps is not exactly what upstream wants
<mdz> fabbione: I think that deleting both mlock-as-user and sk98lin-update is correct
<fabbione> the 2 that are temporary disabled are the only ones on which i was really in doubt due to lack of references
<fabbione> mdz: for now the patches as there
<fabbione> just disabled
<mdz> fabbione: yes, perfect
<fabbione> i purged the others
<mdz> are any of us able to test ppc64, other than elmo?
<fabbione> mdz: gimme a ppc64 and i will :-)
<mdz> I mean with existing hardware :-P
<mdz> fabbione: have you tried to resync the kernel-wedge/udeb stuff yet?
<daniels> mdz: davis exists ...
<fabbione> mdz: there are plenty of ppc64 around the world.. just move one into my house :-)
<mdz> daniels: who or what is davis?
<zul> i can test sparc if there is a need
<daniels> (just not under my desk at present)
<daniels> mdz: g5 xserve port box
<mdz> daniels: in the DC?
<daniels> mdz: it's there, we own it, it's just in the wrong country
<fabbione> daniels: how would you test a kernel on?
<daniels> mdz: jah
<mdz> daniels: that means elmo would need to test it :-P
<daniels> fabbione: step 1: call up tnt, step 2: pay them lots of money, step 3: remember to ship over some wacky xserve -> au power adaptors
<fabbione> zul: thanks.. we are very close to get sparc for *
<mdz> ooh
<mdz> new oo.o on amd64
<mdz> without an oo.o-amd64 update
<daniels> fabbione: i have another patch for you also
<mdz> oo.o-amd64 is obsolete now?
<mdz> lifeless: still here?
<daniels> fabbione: could you please change linux-source's debian/post-install
<lifeless> yah
<daniels> fabbione: the asm check needs to install asm-*
<fabbione> no daniels
<fabbione> that is not part of linux-source
<fabbione> that is kernel-package
<tseng> thats odd, oo 1.1.3 is even uglier than usual
<fabbione> and you want to talk with Manoj about it
<fabbione> since he is taking 99% of our patches
<tseng> oh, its a plugin
<fabbione> brb
<Kamion> mdz: any opinion on the slight dilemma at the end of #3007?
<mdz> Kamion: reading
<mdz> Kamion: getting input from upstream seems wise
<Kamion> AFAIK it's a choice between making some installations possible and making drive-switching a bit more difficult
<Kamion> yeah
<mdz> Kamion: so basically the BIOS boots from drive 0, and then tells you it was booted from drive 1?
<Kamion> yep
<Kamion> good, isn't it?
<Kamion> LILO ignores that information because it already knows what drive it wants to boot from the configuration file; Windows ignores it presumably because it can only boot from C:, or something
<mdz> reading about the 'd' option
<mdz> what grub does now sounds so much more sane
<Kamion> the 'd' option basically ends up being the equivalent of what LILO does, and avoids all such BIOS crapness
<mjg59> Kamion: Are you going to the pub tonight?
<Kamion> mjg59: where?
<mjg59> Carlton
<mjg59> (Mobbsy's birthday)
<Kamion> hm; was planning to go to the Old Spring with Kirsten's choir lot
<Kamion> not sure yet
<mjg59> Heh
<mdz> lamont?
<mdz> jdub: what are gnome-menus and gtk2-engines-smooth?
<mdz> lamont, pitti: what was the resolution to the buildd mlock test mystery?
<pitti> mdz: I did not hear any update about it
<pitti> mdz: I'd like to have the test program executed on the buildds
<pitti> lamont: ^
<mdz> pitti: it was
<pitti> oh?
<mdz> zul: pong
<mdz> pitti: pasted privately
<pitti> mdz: hmm, very odd; heisenbug?
<pitti> mdz: maybe this gets fixed automatically with the next update, as automatically as it was introduced... :-/
<zul> zul: i noticed in the wiki that there is an error on the conference its says the registration is august 5
<zul> shouldnt that be december 5
<mdz> zul: I think you meant to say that to me :-)
<mdz> zul: what page?
<zul> mdz: yeah you are probably right...im not awake :)
<zul> just a sec
<zul> mdz: http://www.ubuntulinux.org/wiki/Conference
<zul> mdz: even better..http://www.ubuntulinux.org/wiki/ConfAgenda
<mdz> zul: I don't see the word "registration" at all on the Conference page
<sivangAFK> zul : me neither
<zul> mdz: on the conference agenda besides Attendees arrive and check in
<sivang> mdz : is it in rest? :)
<mdz> zul: fixed
<jdub> mdz: gnome-menus is the xdg menus implementation, gtk2-engines-smooth is the separate packaging of an engine shipped in gnome-themes
<mdz> jdub: gnome-menus isn't in the archive yet
<seb128> it has built fine
<mxpxpod> mdz: when is it scheduled to be in?
<seb128> oh jdub !!!
<seb128> jdub: dude, I'm a bit annoyed at this point
<mdz> mxpxpod: I didn't even know what it is until 2 minutes ago
<jdub> seb128: mmm?
<seb128> jdub: the menu changes are heavily based on the vfolders so porting them for gnome-panel will need some serious work. 
<jdub> :-)
<seb128> jdub: dunno if we should wait to upload the new panel/gnomvfs/gnome-utils/....
<seb128> or upload a panel with the standard layout for a moment
<seb128> time to get the changes back in
* jdub would err on the side of testing :-)
* jdub suffocates in morning email
<seb128> jdub: have we planned some need changes for hoary in the menu ? ie a place menu ?
<seb128> s/need/new/
<jdub> seb128: let's do that at mataro :)
<stratus> aren't all the packages on main with a changelog modified by anyone at ubuntu ?
<Kamion> stratus: only those with *ubuntu* version numbers
<stratus> Kamion, i see the diff is what was modified and what wasn't only?
<Kamion> stratus: don't understand, sorry
<Kamion> stratus: the .diff.gz is against upstream exactly the same way as Debian does
<Kamion> stratus: use interdiff or debdiff if you want the diff against Debian
<stratus> Kamion, no i was asking about the versioning scheme of ubuntu.
<Kamion> so, I still don't understand. :)
<stratus> Kamion, the packages that weren't changed (e.g: gaim) aren't with a ubuntuX and the latest changelog entry points to unstable and not hoary?
<Kamion> stratus: indeed
<Kamion> stratus: we rebuild all binary packages from source, though
<stratus> Kamion, hmm i know.
<Kamion> stratus: where we've made source modifications, the version numbers have ubuntuX at the end, yes
<stratus> Kamion, no problem thanks i was just thinking about it after i see that gaim package wasn't changed.
<Kamion> if we can just sync packages from unstable unchanged, we do.
<stratus> yes, np for me but isn't it confusing users? I don't think that normal users go to read changelog entries but these entries are being displayed at 'ubuntu update manager'.
<Matt|> bold fonts in openoffice still boned
<Kamion> stratus: not so far
<stratus> Kamion, ok thanks again.
<Kamion> stratus: they're still updates in the Ubuntu archive, even if those updates come from Debian
<Kamion> stratus: in the same way, Debian updates are still updates in the Debian archive even if most of the work was done by upstream
<stratus> Kamion, i forgot that the first line containing 'unstable' and not 'hoary' isn't being displayed.
<stratus> it was my point about confusing users.
<Kamion> ah, you're talking about apt-listchanges output
<stratus> no, no 'ubuntu update manager'
<Kamion> yeah, same difference :)
<stratus> I'm thinking about normal users and not us.
<stratus> yes, it's ok
<stratus> my failure
* stratus home
<mdz> Kamion: no, you would think that update-manager would use apt-listchanges changelog code, but no :-P
<stratus> see you.
<stratus> "gaim (1:1.0.3-1) unstable; urgency=low"
<jdub> mdz: i believe the intent is to show changes before you download them
<Kamion> stratus: yeah, pretty much inevitable
<stratus> It's the line that can't be displayed to the users, but it's ok atm
<Kamion> stratus: and probably better to leave it there or it would be more misleading
<wasabi> Heh. I also thought that we should have a changelog.Users or something instead.
<wasabi> That was more user oriented. But I guess that's what NEWS is.
* jdub does not think this is a good method of doing it
<wasabi> changelog tends to list very technical stuff.
<stratus> hmm, well
<stratus> i need to leave the building now.
<stratus> see you
<Kamion> wasabi: NEWS.Debian has things people need to see on upgrades.
<wasabi> Well, i think you know what I mean. "This patch fixes a remote buffer overflow found by blah in the blah of blah. It is an important install."
<wasabi> vs "[blah.c]  applied upstream patch to fix foo bar"
<wasabi> And also that these packages shoudl be grouped somehow. Consider how MS and apple do it.
<wasabi> They say "Security update for core windows component" or some stuff.
<wasabi> And they say it once, even if it upgrades IE, the kernel, and half a dozen system .dll's
* wasabi shrugs.
<wasabi> recent example:
<wasabi> perl (5.8.4-2ubuntu0.1) warty-security; urgency=low
<wasabi> * added patch 03_safe_tmpfiles.patch:
<wasabi>  - lib/Memoize/t/{tie.t,tie_gdbm.t,tie_ndbm.t,tie_sdbm.t,tie_storable.t},
<wasabi>       ext/DB_File/t/db-recno.t: create tem
<wasabi> ... onward ...
<wasabi> my mom would not like seeing that.
<wasabi> But something like "This patch fixes a security vulnerbility in a core Ubuntu system component etc etc to prevent local users from comprimising your information." would be a bit more understandable.
* Mithrandir wonders if upgrading this p166 to hoary is a good idea.
<mdz> jdub: that's been an intended feature in apt-listchanges for years
<mdz> Mithrandir: from what?
<mdz> wasabi: that's what NEWS.Debian is for, indeed
<jdub> mdz: great for apt-listchanges, not so great for user-centric-update-thingy
<mdz> but it's only provided when there is something important to say
<wasabi> Well then upgrade-manager should be showing NEWS.Debian
<Mithrandir> mdz: from warty.
<wasabi> Or we need some other file.
<Kamion> mdz: you're still doing the mdz@debian.org thing in changelogs
<mdz> jdub: are you kidding? they're both python, apt-listchanges even provides a library for this stuff
<Mithrandir> mdz: I'm more concerned about it taking forever to maintain than anything else, really.
<mdz> Kamion: only in ubuntu-meta; it invokes dch as part of the update process and I always forget
<Mithrandir> it's a nice box.. might be the one I'm stuck with in BCN
<jdub> mdz: not talking about code, talking about usefulness of showing changelog to users
<Kamion> wasabi: actually I'd rather have stable update changelogs written with a paragraph at the top explaining the change in fluffy language
<jdub> Kamion: yea
<wasabi> I think me and jdub are on the same subject just different angless
<Kamion> wasabi: ... than create yet another damn file that has to be maintained
<mdz> jdub: oh, you're questioning whether it should display NEWS.Debian at all
<wasabi> Yeah, I like that idea.
<mdz> yeah, the NEWS.Debian stuff that comes from Debian is highly technical
<jdub> mdz: questioning news and changelog.
<wasabi> A special area in teh change log that can be parsed out.
<mdz> jdub: changelog is right out
<wasabi> With a button to show the more advanced change log details
<wasabi> you just want to hide that stuff from people by defaul.t
<mdz> changelog is for developers
<wasabi> it's mind numbingly confusing
<wasabi> well, there could be a seperate file, done by the security team................... 
<Kamion> well, people *did* ask to dive into the details of the update
<wasabi> or not. ;)
<mdz> it wouldn't be a bad idea for security updates to add NEWS.Debian entries
<mdz> except that most packages don't have one
<wasabi> I'm just saying there should be too peices.
<mdz> and so that's a bit more change than I'm comfortable with in security updates
<wasabi> User centric, and developer centric
<mdz> wasabi: we already have that
<wasabi> mdz: where?
<lupus_> [Invalid UTF-8]  Could not parse file '/usr/share/applications/ooo645calc.desktop': desktop entry contain line 'Comment[ca] =Fulla de c\xc3| lcul d'OpenOffice.org' which is not UTF-8
<mdz> wasabi: NEWS.Debian and changelog.Debian
<wasabi> So people actually hew NEWS.Debian for plain-english update text?
<wasabi> s/hew/use/
<mdz> most don't use it at all
<mdz> so, very few
<mdz> but look at, e.g. /usr/share/doc/alsa-base/NEWS.Debian.gz
<mdz> mind, this is "Linux user centric" as opposed to "computer user centric"
<wasabi> Yeah.
<wasabi> It's my opinion that the user should NEVER have to know that modules are no longer loaded in /etc/init.d/alsa
<Kamion> wasabi: the place for that is the USN
<wasabi> That's not a radical idea. ;)
* mdz waves his magic retroactive feature wand
<mdz> wasabi: tada! they aren't shown that :-)
<Kamion> as regards fluffy descriptions of security updates
<Kamion> perhaps the update manager should be able to download those
<wasabi> There we go.
<mdz> there's already an RSS feed, isn't there?
<wasabi> or the USN could be put into debian/
* wasabi duck.
* Kamion tends to think that's a bad idea
<jdub> hooray for updates!
<wasabi> I only mention it because upgrade-manager might be run after logoff.
<wasabi> Connect, download, log off, install.
<wasabi> For those with big bandwidth bills.
<wasabi> And metered internet.
<Kamion> you can download the USN at the start of the download
<mdz> if we were going to do apt-listchanges right, we'd put the changes data in control.tar.gz
<Kamion> doing it from the net rather than in the package also allows for better translations
<mdz> it would be about 10 times faster and 10 times simpler than the current implementation
<wasabi> True. That's not bad then either.
<Kamion> security updates usually have to go out quickly, but translations can happen later
<wasabi> Can the USN's be put in apt? =/
<mdz> wasabi: say what?
<wasabi> Or is it a seperate band?
<wasabi> like, you have to hook up the USN's with the packages.
<Mithrandir> mdz: get keybuk drunk and make him promise that? :)
<jdub> seb128: gnome-system-monitor not built yet?
<mdz> fabbione: still here?
<mdz> fabbione: I can test powerpc and i386 kernels if you're ready
<seb128> jdub: I've just uploaded it, some work was needed to port the gksudo patch to the new version
<jdub> ok, ta.
<magnon> jdub: do you have a minute?
<sivang> mdz : seen my comments on the bug? :)
<jdub> magnon: yeah
<wasabi> i guess it would also be neat if third party apt repositories could issue their own security vuln announcements into this thing.
<mdz> sivang: yes, you said that you thought it may have helped but you weren't sure
<mdz> that doesn't seem like much information
<mako> http://people.ubuntulinux.org/~mako/ksp-mataro/
<mako> i'm about to send out a link to that
<mako> now is the chance to make last minute changes/suggestions
<mdz> I guess I had better sign keys from Oxford before leaving for Mataro
<mako> mdz: that would be ideal :)
<sivang> mdz : ok, I'll add some more info now
<mako> going once...
<fabbione> mdz: 2.6.9-1 ppc is on roockery, i386 is uploading now
<mdz> mako: is my key in there?
<fabbione> mdz: if you can give them a shot it would be wonderful
<fabbione> mdz: and please send me a mail with the results
<mako> mdz: nobodys key is in there yet
<mako> mdz: not even mine
<fabbione> i need to go and finish some stuff
<fabbione> cya
<mdz> mako: bah, that's the important bit :-)
<mako> this is an "opt-in" event
<mako> :)
<mdz> mako: December 3rd is a Friday
<mdz> er
<mdz> yeah
<mdz> By Saturday December 3, you will be able to fetch both the complete ke
<mako> ahh, you are correct
<mdz> it's correct earlier up
<mako> right, i meant 4th
<mako> fixed
<mdz> mako: what's the fastest way to turn ksp-wartyconf.asc into something that signkey.pl will accept?
<mdz> seems I would need to create a new keyring, import that into it, list-keys, check the list against my paper
<mdz> I'd like to collapse the first two steps into something simpler
<mako> mdz: i have some scripts
<mako> mdz: but what i usually do is set GNUPGHOME=sometmp directory
<mdz> why is gnupg such crap
<mako> and then i can input the new keyrinCg into a new pubring
<sivang> mdz : added the trail
<mako> then i go through the paper and edit my ksp-wartyconf.txt file to include only the keys that i will sign (you are checking against the file after alll, not hte paper so you don't need to read the keys against the paper)
<jdz_> mako: stylistic point: the whole third bulleted section, in "How the Keysigning Will Happen" is grey text, while the others are black text.
<mako> then i use a script to check the fingerprint in the keyring with the fingerprint on the paper
<mako> jdz_: yes, that because you can't do that yet :)
<mako> jdz_: it will be black when you can :)
<mako> mdz: i can send you that script to do the checking
<mako> mdz: is's like 15 lines of perl
<mako> but then you just do the md5sum, edit the txt file to include the keys you want to sign and you just run something like sign key on the output of the result of the script.. pretty easy
<mako> mdz: let me know if you want my script
<sivang> mdz : Now I'll set mount to allow regular users to mount cdrom media at least
<pitti> night everybody
<sivang> night pitti
* jdub cries downloading all of openoffice.org again for one depends change :|
* carlos is happy because it was not ready for ppc last time he checked it, so he saved one download :-P
<mdz> mako: sure
<mdz> simplification is the only way I'll actually get around to doing it
<seb128> jdub: 
<seb128> [Invalid UTF-8]  Could not parse file '/usr/share/applications/ooo645calc.desktop': desktop entry contain line 'Comment[ca] =Fulla de c\xc3| lcul d'OpenOffice.org' which is not UTF-8
<seb128> jdub: you will cry on the next upload to fix that warning :p
<jdub> ha ha
* jdub spanks seb128 
* jdub reassigns every bug on b.g.o to seb128 
<_rene_> I don't btw see that in our sources. iconv doesn't complain on that file... anyway, if there is a bug we have to fix, diffs welcome ;-)
<jdub> elite!
<jdub> WARNING: The following packages cannot be authenticated!
<jdub>   bazaar
<jdub> Install these packages without verification? [y/N]  y
<jdub> 
<mdz> fabbione: Linux potpal 2.6.9-1-686 #1 Tue Nov 30 20:30:09 CET 2004 i686 GNU/Linux
<jdub> although we should fix the bazaar archive :)
<mdz> nah
<mdz> we should upload baz to hoary
<mdz> I'll work on that shortly
<jdub> true, true
<jdub> rock!
<mdz> lifeless: is it intentional that the bazaar tarball has {arch} directories in it?
<jdub> yes
<mako> mdz: sent
<jdub> it's just a tarball of arch, basically
<jdub> (ppffftt)
<mdz> that is so uncool
<mdz> mizar:[/tmp/bazaar]  find . -name ++pristine-trees | xargs du -sch
<mdz> 1.5M    ./src/docs-hackerlab/{arch}/++pristine-trees
<mdz> 2.5M    ./src/docs-baz/{arch}/++pristine-trees
<mdz> 280K    ./debian/{arch}/++pristine-trees
<mdz> 4.2M    total
<mdz> (from the dist tarball)
<mdz> I don't think it's intentional
<jdub> it's not purposeful, but it's not avoided :)
<mako> pristines, no good
<Mithrandir> mako: I asked about getting CDs for a party in February, I guess the right way is just to order them using shipit?
<Nafallo> I got an ubuntu amd64 with a sarge i386 chroot. how to compile a kernel for i386 inside the chroot?
<jdub> mdz: i'd really like to migrate to sudo-by-wheel-equivalent-group for hoary.
* lamont_r finishes with the tire people.  Got to remember to not take the camaro off-roading
<Mithrandir> Nafallo: make ARCH=i386 menuconfig all ?
<mdz> lamont_r: mlocktest?
<lamont_r> mdz: still trying to figure out why it works sometimes and not others
<Nafallo> Mithrandir: thanks :-)
<Mithrandir> Nafallo: that ought to work
<Nafallo> Mithrandir: it did :-)
<lamont_r> daniels?
<mako> Mithrandir: if you have already ordered cds, you need to also talk to me
<Mithrandir> mako: I have gotten a first shipment, but I want a second one with more.
<Mithrandir> mako: I have not ordered a second one, I think.
<lamont_r> mako: btw, if I wanted to come home with like 5 each of ppc and amd64, is that trivial, or painful?
<Mithrandir> (or I might have, but that's just 20 or so I ordered in the second run)
<mako> Mithrandir: ok, so go in and update teh number you want and then send me an email saying to special case you
<Mithrandir> mako: willdo
<mako> lamont_r: from the conference?
<lamont_r> yeah
<lamont_r> or even in the second run
* lamont_r didn't order any
<mako> lamont_r: shouldn't be a problem as you'll be there before anyone else :)
<lamont_r> heh
<lamont_r> mako: just hide 5 each in your bag for me. :)
<mako> lamont_r: we'll we're shipping like 500 to hotel this week i think
<mako> lamont_r: but i'll bring/hide some backups for myself as well
<mako> with the LUG trip and the open day i suspect that it might not be enough
<lamont_r> mako: I see.  thanks
<mako> i have yet to leave an event with any CDs
<lamont_r> hrm.. wonder why the house dropped of the network.
<lamont_r> mlocktest. hrm.
<stockholm> hi
<seb128> jdub: an other solution that could work, if we want to keep the current layout, would be to add back the vfolder to the current gnomevfs package ...
<seb128> jdub: so we can go ahead and perhaps made it working with the vfolders for computer
<jdub> nah
<seb128> that's ugly and not in the right direction 
<jdub> yeah
<jdub> would prefer to test the changes
<lamont_r> mdz: I'm having problems reproducing either the gpg error, or mlocktest failures
<seb128> but we switch back to the standard applications/action layout for some time so. Perhaps we should mail ubuntu-devel before going with that ?
<lamont_r> given that we know we have a working mlock, we should just use it. (that is, ripping out the code - or #if 0'ing it - doesn't seem like much of a hack to me.
<jdub> seb128: yeah :)
<mdz> lamont_r: do you believe that if we rebuild gnupg, it would pass the test and resolve the issue?
<mdz> mako: can you make sure that the printing process is utf-8 aware this time around? :-)
<elmo> we should record the 'uname -a' output as part of the build
<lamont_r> mdz: I'll verify that, but I can't reproduce the issue.
<lamont_r> was it just i386 where we were seeing that?
<mdz> lamont_r: you could reproduce it yesterday
<mdz> yes, only i386
<lamont_r> mdz: no - I thought I could.
<lamont_r> pb was in chrooting into the chroot and the fact that the test didn't print anything
<lamont_r> checking exit codes is not always the best way to see an error... :-(
<mdz> lamont_r: somehow, gnupg on i386 got built in such a way that the code used if that test fails was activated
<lamont_r> anyway, I'll verify that building it anew fixes the issue on all three architectures and then deal with it.
<mdz> lamont_r: pleasae do
<mdz> thanks
* lamont_r must fetch kids from school. back online in a while
<mdz> Mithrandir: really? (XP using UTC for the hardware clock)
<Mithrandir> mdz: according to some people who have checked it, yes.
<Mithrandir> mdz: I haven't verified it myself, but I could do that, sure.
<mdz> that should silence an entire segment of complaints, if true
* jdub is tempted to install xp in his spare partition
<Mithrandir> give me two minutes to boot the live cd on my XP box.
<jdub> Mithrandir: reboot and look at the bios :)
<Mithrandir> well, that works as well
#ubuntu-devel 2004-12-12
<jdub> Kamion: around?
<jdub> elmo: ping
<elmo> jdub: ?
<Mithrandir> mdz: hmm, I can't reproduce it.. I'm asking the guy who told me.
<jdub> elmo: can you reaim bugzilla at ubuntu-bugs now? :)
<elmo> jdub: err, not unless someone tells me how?
<jdub> hrm
<jdub> actually, i might be able to do it
<jdub> i don't think i can
<sivang> was modconf removed from hoary?
<mdz> Kamion: around?
<elmo> jdub: can you give me any hints?
<mdz> sivang: modconf has never worked properly with 2.6 kernels, I don't think
<mdz> it was not in Warty either
<elmo> beyond grep -r warty-bugs 
<jdub> elmo: i have no idea, really
<sivang> mdz : ok, sorry I should have known that.
<mdz> elmo: I can mysql it if you give me access
<mdz> I don't think I can do it via the interface without having it mail an auth token to the list
<mdz> hmm, actually no
<mdz> I think that bit is hardcoded
<mdz> elmo: grep -r it is
<fabbione> and right now i can declare the first room of my house FINISHED
<mdz> elmo: Bugzilla/BugMail.pm, ~line 342
<elmo> yeah, it's part of the patch set
<mdz> yeah
<mdz> 007
<mdz> fabbione: congratulations
<mdz> I don't think i can say that about any room in my house
<mdz> and I've been here a year
<fabbione> mdz: eheh i know that feeling... the rest is gonna take much longer
<elmo> I can kind of say that about my bedroom, but only because I moved everything in it to the spare room to make room for the new bed ;)
<fabbione> at least tomorrow i can move to the new office
<mdz> fabbione: i386 kernel is go
<fabbione> mdz: cool
<fabbione> waht about ppc?
<mdz> I am downloading a warty powerpc image so that I can fix the kernel-image breakage that is making it unbootable
<mdz> i.e., can't test yet
<fabbione> ok thanks
<mdz> I was going to use a hoary CD to fix it, but it was busted
<fabbione> and thanks for signing my keys
<fabbione> yeah Kamion said so before
<carlos> mdz: do you know the fix? did you saw my bug report?
<mdz> fabbione: finally :-)
<mdz> carlos: no and no
<fabbione> mdz: there is always a hope..
<fabbione> joey was much slower than you :-)
<carlos> mdz: https://bugzilla.ubuntu.com/show_bug.cgi?id=4190
* carlos remembers that he didn't signed yet any key...
<mdz> carlos: oh, that
<mdz> carlos: that's a duplicate, shame on you :-P
<carlos> really?
* carlos needs to learn to search better
<mdz> carlos: I thought you were asking about the powerpc hoary CD
<mdz> rather than the kernel-image breakage
<sivang> carlos : he makes me feel very bad when I open duplicates also ;-)
<carlos> which one is the other bug so I could close that one?
<carlos> sivang: :-)
<nictuku> hi. I'm willing to make an interface to help easy translation of the site and documentation, but I need some support from you guys.
<mdz> I am so much nicer about ubuntu duplicates than I am about debbugs duplicates :-P
<nictuku> my idea is to help translators to keep versions in synch easily, by providing them a simple interface showing the differences between versions, and letting them just translate the part that changed (although it can't be too strict on this).
<mdz> [Clint] : eek, versioned conflict in an essential package
<mdz> now there's a scary apt test case
<elmo> I hope it's not two Essential packages; that's an amusingly unknown special case 
<Clint> mdz: to work around a bug in a non-essential package.  yes, it's great.
<Clint> oh, and it's a replaces now, per Kamion
<Clint> not sure how that matters to apt
<nictuku> well, i'll just write it. if you find it useful, lucky me.
<sivang> mdz : is there a way I can leave dbus-1 running, and just disable hald?
<jdub> sivang: tried removing hal?
<sivang> jdub : I did! It works falwlessly now, and with gamin, it's faster like a bullet
<sivang> jdub : is there any point in leaving dbus-1 and just disabling hald?
<jdub> yeah, other things use dbus
<jdub> so hal is slowing your machine down badly?
<mdz> Clint: replaces is much more apt-friendly
<mdz> Clint: it's very nearly ignored
<sivang> jdub : it was so badly, the machine became completly stoned :)
<sjoerd> sivang: just disk access slowing or really the complete machine ?
<sivang> jdub : ok, how can I just leave dbus-1 on and disable hald, there is not /etc/init.d/hald 
<jdub> sivang: just uninstall hal
<sivang> sjoerd : disk access seems to be the one which is most badly influneced, yes.
<jdub> see also /etc/dbus-1/event.d/ -> but removing hal would be simpler
<sjoerd> sivang: laptop with both hd and cd on the same ide bus ?
<sivang> sjoerd : how do I check that? lspci shows only one IDE interface.
<sjoerd> what device is your cd ? hdb ?
<sivang> sjoerd : yes
<sjoerd> ah, just turn of media checking, no need to remove hal completely
<sjoerd> known problem.. buy real hardware next time :)
<sivang> sjoerd : real hardware? :)
<sjoerd> sivang: something that has a dedicated bus for the hd and one for the cd
<sivang> sjoerd : why this is not a problem on other machine which use the same bus for both devices?
<sjoerd> other machine == laptop too ?
<sivang> sjoerd : no :)
<sivang> sjoerd : but not everyone reported that with their laptop, guess they have dedicated busses per device.
<sjoerd> the problem is that your cd drive goes into ``sleep'' between two hal polls
<sjoerd> so when it polls again it has to be waken up, which makes the bus unavailable for some time
<sjoerd> on dekstop machine, cd drives don't have this behaviour apparently
<jdub> sjoerd: nice!
<sivang> sjoerd : how did you find this out?
<sivang> sjoerd : and also, why your nickname appears on the first python example at python.org ? ;-)
<sivang> sjoerd : (the addressbook example)
<sjoerd> that's a coincidence :)
<sjoerd> sivang: i know because your not the first one and there was some discussion about it on the hal list
<sjoerd> jdub: actually, not so nice :)
<sivang> sjoerd : ok, I'll mv the startup links back to SXX and try just diabling media check :)
<jdub> sjoerd: well, in "challenging things to work around" bug kind of nice ;)
<sjoerd> dunno if it happens a lot.. We could provide some fdi rules in the example to disable the media checking on just the internal cdrom.. So it still checks plugged in devices
<sjoerd> sivang: imnsho everything a laptop that has both hd and cd on the same ide bus is just a toy.. that's what i ment with, buy real hardware
<sivang> sjoerd : well, this isn't mine even :) if I buy one I think it's going to be a thinkpad
<sivang> or better yet,
<sivang> a PowerBOok
<sjoerd> hehe
* sjoerd loves his powerbook
<sivang> people here say all the time how wonderful ubuntu is on the pb
<sivang> :)
* sjoerd doesn't run ubuntu
<sjoerd> but debian is wonderfull :)
<mdz> sjoerd: sjoerd doesn't run ubuntu.....yet :-)
<mdz> fabbione: still up?
<sivang> mdz : hehe
<mdz> fabbione: powerpc booted and seems to work
<mdz> fabbione: however, I found a regression on i386
<mdz> my CD writer is no longer recognised correctly
<sjoerd> mdz: don't hold your breath for that :)
<sjoerd> time too sleep.. night!
<sivang> sjoerd : night!
<fabbione> mdz: yes.. i was testing 2.6.9 on i386
<fabbione> mdz: and i got some kind of error in dmesg that i didn't like
<fabbione> mdz: about a release function in a driver
<fabbione> mdz: anyway i really really need to go and get some sleep
<mdz> fabbione: I've gotten that for many versions, nothing to worry about
<fabbione> it's like 1:30am
<mdz> fabbione: I'll see if I can debug my problem
<fabbione> mdz: ah ok
<fabbione> mdz: what regression do you have?
<mdz> fabbione: <mdz> my CD writer is no longer recognised correctly
<mdz> (USB)
<fabbione> hmmm
<fabbione> i recall something about changing usb stuff
<fabbione> and it was related to usb-mass storage
<mdz> yeah, my CD burner gets detected as mass-storage
<mdz> works fine under the current hoary kernel
<mdz> (gets incorrectly detected as mass-storage under 2.6.9)
<mdz> I'm googling it, I'll let you know tomorrow
<fabbione>       . usb-storage-vendor-count.dpatch
<fabbione> that was changed
<fabbione> mdz: it's like a 2 line diff
<fabbione> iirc
<mdz> hmm
<mdz> that patch was added by Debian?
<fabbione> no it was stolen from upstream
<mdz> fabbione: is your .dsc/.diff.gz available somewhere?
<fabbione> but there were 2 lines that were in conflict
<mdz> fabbione: who added it to the package?
<fabbione> i can uploaded
<mdz> or it was in 2.6.8.1?
<fabbione> it was in 2.6.8.1
<fabbione> upstream in 2.6.9
<fabbione> but with 2 lines that were different
<fabbione> let me dig it up ..
<fabbione> mdz: the orig is on my home on davis or concordia
<fabbione> mdz: anyway if you check the patch from 2.6.8.1
<fabbione> it's like 2 addition and one removal
<jdub> oh no
<jdub> i'm going to have to choose between mjg's acpi love and inotify
<fabbione> jdub: why?
<mdz> fabbione: looking at it
<mdz>  1 files changed, 2 insertions(+), 1 deletion(-)
<jdub> well, yours won't have those crazy dsdt patches, right?
<fabbione> yeah...
<fabbione> jdub: not yet...
<jdub> and mjg's doesn't have inotify :)
<mdz> I think it's unrelated
<fabbione> i need to discuss with mjg about them
<jdub> unless we can convince him to rebuild against yours :)
<fabbione> jdub: actually i would be more happy to merge the 2 in a sane way
<mdz> that patch smells a bit like crack
<fabbione> mdz: but it has been applied upstream
<mdz> fabbione: no, the dsdt patch
<fabbione> just slightly differnt
<fabbione> ah ok
<fabbione> dpkg-source: building linux-source-2.6.9 in linux-source-2.6.9_2.6.9-1.diff.gz
<fabbione> few secs :-)
<jdub> mdz: really handy though
<jdub> mdz: to the point where we might be able to ship dsdt files for known b0rk hardware :)
<mdz> jdub: if we already know about them, we can fix them in the kernel
<mdz> the patch only lets you fix it after the fact
<mdz> and leaves the user to dig up some workaround and not report a bug :-P
<jdub> that means we'd have to create something in the kernel which would select the right dsdt, and crank up the kernel size with dsdt foo
<mdz> http://www.linuxquestions.org/questions/history/254610
<mdz> fabbione: ^^ that's the problem I'm having
<mdz> jdub: my understanding is that new ACPI patches work around this stuff in other ways
<mdz> not shipping DSDTs
<fabbione> mdz: checking
<mdz> but I haven't checked
<jdub> mdz: the dsdt tells acpi what's going on...
<mdz> http://lkml.org/lkml/2004/11/3/147
<mdz> that's the same problem
<mdz> fabbione: ^^ has a workaround
<mdz> apparently just disabling the ub driver
<mdz> er, compiling it in
<sivang> night all!
<mdz> fabbione: perhaps we should just do CONFIG_BLK_DEV_UB=n
<fabbione> mdz: ok.. easy :-)
<fabbione> let me finish to read
<fabbione> you are fresh and dandy ;)
<mdz> fabbione: now that I know what to look for, that is the prevailing advice
<fabbione> i am close to crash
<mdz> "don't use ub"
<mdz> fabbione: since this is the only problem found, I would like to make that change and upload if it's OK with you
<fabbione> why on heart my machine is running update-db at this time
<mdz> (after testing that it fixes my problem, of course)
<fabbione> mdz: wait for upload. i have other changes pending
<fabbione> mdz: test the fix is more than OK
<jdub> mdz: http://lists.ubuntu.com/archives/ubuntu-bugs/
<mdz> fabbione: I would like to get something into the archive (as non-default) since it fixes many bugs, and gives something to test for unknown bugs
<fabbione> mdz: please let me do it tomorrow
<mdz> jdub: excellent
<mdz> fabbione: ok, ok
<fabbione> mdz: i want daniels changes in too since they fix other ubuntu bugs
<mdz> fabbione: X has put you in the habit of making huge uploads with many changes :-)
<mdz> there is nothing wrong with making two uploads
<fabbione> mdz: because the kernel takes 3 times as much as X to compile
<mdz> buildd cycles are cheap
<fabbione> CONFIG_BLK_DEV_UB=y -> n
<fabbione> mdz: for our buildd yes...
<fabbione> not for my test machines ;)
<fabbione> mdz: diff and dsc are on p.u.c/~fabbione/kernel/
<mdz> we have already tested the current stuff; if you make more changes we need to re-test
<mdz> thanks
<mdz> jdub: should we announce its existence?
<fabbione> mdz: i know.. and we didn't test probably 1/10 of the changes anyway :-)
<fabbione> the changelog for 2.6.9 is like 1.5MB
<jdub> mdz: yeah
<fabbione> + our changes
<jdub> mdz: want me to post?
<fabbione> anyway i need to get some sleep
<fabbione> otherwise tomorrow i will be dead
<mdz> jdub: sure, thanks
<mdz> fabbione: night
<fabbione> night
<mdz> jdub: is there anything else hiding out on rince that we should publicise?
<jdub> nup
<jdub> (just checked the list)
<lamont> sigh... mako?
* lamont dinners
<mdz> fabbione: eek
<fabbione> mdz: i found plastic pieces all over
<fabbione> and thanks god i had another fan big enough to replace this one
<fabbione> but i need to change it
<fabbione> this is a really bad hack
<mdz> fabbione: does this mean no kernel builds for you today? ;-)
<fabbione> i think i also had some disk corruption
<fabbione> mdz: not at all.. all my devel stuff is mirrored across 3 machines :-)
<fabbione> but the worst thing is that the kernel didn't boot with a really annoying CRC error
<mdz> fabbione: do you think you can get 2.6.9 into hoary today?
<fabbione> that means i need to build a new one and replace it
<fabbione> mdz: sure
<fabbione> no doubts
<mdz> great
<fabbione> mdz: i need to wait pitti stuff
<fabbione> mdz: that's the only bits i need to finish to merge
<fabbione> and i need to wait one hour at least to let all my secondaries MX to flush the cache into my server :-)
<mdz> those aren't regressions from 2.6.8.1, so if those bits can't be done today for whatever reason, don't let it delay you
<fabbione>       [>....................]   recovery =  0.0% (101308/117220672) finish=2058.2min speed=948K/sec
* fabbione sighs
<fabbione> mdz: i am still not sure what bits are missing...
<fabbione> mdz: did you check that cd burner stuff?
<mdz> fabbione: some of the patches in -16.1
<mdz> fabbione: I tried, but was not able to get it working
<fabbione> aren't they upstream?
<mdz> fabbione: some, but not all
<fabbione> ok
<mdz> -16.1 and some other stuff in preparation
<mdz> herbert and pitti have details
<fabbione> now i remember why i did upgrade the kernel
<mdz> fabbione: I tried removing the ub module from the usbmap, but it still didn't work for some reason
<fabbione> at that speed it will take ages to rebuild the raid
<fabbione> mdz: ok...
<fabbione> i guess we will deal with it later
<mdz> fabbione: there was no .orig.tar.gz in your directory, and the md5 is not the same as Debian's
<mdz> so I could not go much further
<fabbione> mdz: on davis and concordia yes
<fabbione> and no.. i am not using their orig.tar.gz because it is different (prune-non-free)
<mdz> fabbione: are you using a kernel.org tarball, then?
<fabbione> mdz: almost.. yes
<mdz> almost?
<mdz> where can I download your tarball?
<doko> morning all
<fabbione> there is one file that needs to be removed because DPATCH is RETARTED
<fabbione> mdz: from my home directory on davis or concordia
<fabbione> mdz: same as 6 hours ago :-)
<fabbione> mdz: i didn't change location
<fabbione> davis:~ $ ls
<fabbione> linux-source-2.6.9_2.6.9.orig.tar.gz
<mdz> unknown host davis
<mdz> unknown host concordia
<fabbione> .ubuntu.com
<fabbione> they are not in the other dns
<fabbione> and you need to proxy them
<fabbione> via chinstrap
<mdz> I was on chinstrap
<mdz> gah
<mdz> they only resolve fully qualified
* fabbione doesn'
* fabbione doesn't lie :-)
<mdz> fabbione: any ideas for another quick test for the usb problem before I go to bed?
<fabbione> mdz: other than recompiling the kernel without that thing no
<fabbione> mdz: it is compiled it
<fabbione> in
<fabbione> so there is no point in removing it from the usbmap
<mdz> fabbione: Nov 30 16:32:27 <fabbione>      mdz: the orig is on my home on davis or concordia
<mdz> fabbione: that is all you said before, not .ubuntu.com :-P
<fabbione> mdz: next time don't go in holidays for too long :P
<mdz> CONFIG_BLK_DEV_UB=m
<mdz> that is 2.6.9-1
<fabbione> oh
<fabbione> hmmm
<fabbione> you can try compiling it in?
<fabbione> or rm the module from /lib/modules
<jdub> W: GPG error: ftp://ftp.nerim.net unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
<jdub> 
* sid77 hi
<lifeless> morning
<tuo2> no it's not :)
<fabbione> pitti: ping
<pitti> fabbione: pong
<fabbione> dude.. your mail is like: "hey have fun!"
<pitti> fabbione: it already took me very long to extract this out of Herbert's changelogs and the mail flood
<fabbione> ehhe
<pitti> fabbione: why, you have CAN numbers, links to patches, what else do you want?
<fabbione> pitti: we need to go trough it together
<pitti> fabbione: of course
<fabbione> pitti: you!
<fabbione> i want you
<pitti> fabbione: this is only my personal track list
<pitti> fabbione: I'm back in about 5 minutes
<fabbione> me to
<jdub> morning boys and girls. and Keybuk.
<daniels> morning mr dub
<jdub> yo daniels 
<Keybuk> morning mrs jdub
<doko> jdub: ping?
<jdub> pong
<doko> is #3811 still an isue? that's reported for OOo-1.1.2
<jdub> doko: i don't believe so
<jdub> didn't hit me when i installed 1.1.3
<doko> ok, thanks.
<fabbione> WOW
<fabbione> only 300 lines of changelog for 2.6.9
<fabbione> and i still have to finish!
<fabbione> + it's not even anal as it was before dpatch trashed half of it
<daniels> fabbione: that's nothing, kid :P
<fabbione> daniels: go back and fix xorg
<fabbione> my glxgears shows me 7598 fps instead of 7599 
<fabbione> I CANNOT LIVE WITH THIS REGRESSION
<fabbione> ahhaa
<daniels> RESOLVED/WONTFIX
<pitti> fabbione: you have to add today's dollar value, remember
<daniels> stop buying crappy nvidia hardware :P
<Matt|> grrrrr
<Matt|> i'm rocking at 400
<daniels> Matt|: unless you can tell the difference between 400 and 450 FPS in glxgears, and care about that difference, it's unimportant
<Matt|> daniels, im not blaming you, just whinghing about my computer
<daniels> why does it matter?
<daniels> no-one actually sits there and watches glxgears
<daniels> and notices the difference
<Matt|> daniels, i want 7598
<daniels> benchmark games if it bothers you
<daniels> but benchmarking glxgears is stupid
<Matt|> whoa ok it was just a joke man
<mvo_> ping mdz
<pitti> mvo_: he already went to sleep
<mvo_> pitti: thanks
* calc kicks HPT for their crappy hardware
<calc> it overwrites part of the grub stage1_5
<calc> and makes grub give a very useful error 21 output after first reboot
<daniels> fabbione: ping
<fabbione> yeah kid
<fabbione> oh
<pitti> daniels: ping
<fabbione> daniels: ?
<daniels> fabbione: any luck with the kernel?
<fabbione> daniels: yes. i have almost done
<fabbione> daniels: i am including your patches now
<fabbione> after that it is a run of buildds
<fabbione> and upload
<fabbione> dilinger: sure... i will put them on the web in a sec
<fabbione> erhm
<daniels> fabbione: let me know when you upload so I can get it out of the archive to fix l-r-m
<fabbione> daniels: yes i know you are waiting for it :-)
<fabbione> daniels: 2 of your patches require kernel config modification
<fabbione> + you shouldn't modify debian/ in dpatch
<Kamion> jdub: yo
<Kamion> mdz: yo
<jdub> hey Kamion 
<daniels> fabbione: ahr, yeah
<Matt|> guys what package provides gnome-panel-screenshot do you know?
<jdub> Kamion: have some interesting questions about installer
<fabbione> daniels: i will keep ipw2100-fsam7400.dpatch  synaptics-cpad-support.dpatch for -2
<jdub> Matt|: gnome-utils will include it
<fabbione> daniels: because it will require a resync of the configs
<jdub> Matt|: it moved upstream
<Matt|> thanks
<Kamion> calc: hey, if you know more details about that, could you add them to bug #2254 please?
<daniels> fabbione: dude, it's one line!
<fabbione> daniels: and it takes hell of a lot of time
<daniels> the diff should even apply cleanly
<fabbione> daniels: that's not the point
<daniels> what is?
<fabbione> daniels: you changed for i386 & co...
* Kamion has a fun idea
<daniels> fabbione: right ...
<fabbione> if the patch is not clean, ppc and amd64 will bitch about it
<Kamion> if the installer detects a low-memory system, it should automatically select custom mode
<daniels> fabbione: define 'not clean'
<Matt|> jdub, i already have gnome-utils but can't find the command
<fabbione> daniels: arch specific
<Kamion> jdub: go ahead
<Matt|> jdub, and the screenshot keybinding does not work
<jdub> Matt|: it's not in the current package, that's why it doesn't appear in the menu
<Matt|> oh right
<Matt|> jdub, i see what you mean by "will" now, sorry :)
<Matt|> kewl thx
<Matt|> has the command changed to launch openoffice spreadsheets?
<jdub> shouldn't have
<Matt|> nautilus doesn't know how to open xls files
<jdub> but there may be borkage between the versions, perhaps in the .desktop files
<Matt|> not worth a bug right?
<haggai> Matt|: oowriter
<haggai> someone said there were UTF-8 errors in .desktop files, I haven't seen them myself
<Matt|> haggai, oocalc still works ok i think
<haggai> Matt|: oops, yeah that's what I meant
<Matt|> haggai, its a nautilus problem i guess
* fabbione spins concordia and davis
<elmo> fabbione: no -j 4 ??
<fabbione> elmo: not now.. i need to test the packages for real and upload
<fabbione> elmo: i will play leter if you don't mind :-)
<elmo> no, I don't mind, curious to see if it stays up
<elmo> buildd does, but then very little uses > 1 CPU
<fabbione> elmo: with -j 4 is not an issue
<fabbione> elmo: run more than one buildd daemon on each box :-)
<fabbione> fuck
<fabbione> concordia has basically finished the first kernel
<daniels> concordia doesn't run buildd, does it?
<daniels> yeah dude, it pantses davis
<fabbione> the others are still in the middle of nowhere
<thom> elmo: i think the buildds were seeing a nasty scsi/smp interaction
<elmo> fabbione: no, concordia, davis and halley are dedicated port boxes
<thom> (for amd64)
<elmo> thom: ah
<fabbione> elmo: i know they are... i didn't even question that :-)
<fabbione> <daniels> concordia doesn't run buildd, does it?
<thom> which i guess conc. wouldn't see
<elmo> one day, I'm going to bring my computer down with me to the DC, plug it in, rename it to concordia and take the real concordia home ;)
<thom> heh
<elmo> and see who notices that the amd64 port box, err, isn't an amd64 first ;P
<elmo> fabbione: "dedicated" --> "no buildd"
<thom> see, i could get away with that :P
<fabbione> elmo: yes.. i meant that if you have SMP on the buildd (not concordia or davis or ..) just run more instances of buildd :-)
<daniels> elmo: i'd notice when my xorg builds didn't finish three times as quicker as davis
<thom> i don't think anyone would notice a single amd64 3k v two opteron 2500s, would they? :P
<daniels> thom: no, not half!
<bob2> guv'na
<Kamion> hooray, lamont/elmo fixed the daily d-i build
<elmo> oh, damn that means I have to install them again
<daniels> bob2: sun 'ill
<jdub> thom: DUDE
<jdub> thom: i enabled header caching today
<jdub> thom: HOLY COW
<elmo> debian-installer | 20041118ubuntu4.0.20041201 | i386 | 5 hours old
<elmo> kamion; hmm, doesn't seem fixed
<jdub> thom: i wish it were something we could configure by default
<Kamion> elmo: well, I see stuff in /dists/hoary/main/daily-installer-*/
<Kamion> maybe somebody bodged it?
<elmo> oh, that's yesterday's
<Keybuk> jdub: dude, GtkFileChooser should be spatial ... I want to go into a parent folder, and have it scrolled down to the same place as last time I was in there
<elmo> GtkFileChooser should just plain suck less
<elmo> typeahead doesn't even work
<Keybuk> elmo: it does in hoary?
<jdub> Keybuk: :)
<elmo> oh, does it? yay
* Kamion finally arranges to be able to switch between installer-* and daily-installer-* by flipping one switch rather than having to go and edit $NUM_ARCHES scripts
<Keybuk> I'm determined to find time to write my Firefox-esque completion idea for Nautilus
<jdub> i will lock you in a cupboard "accidentally" at matar
<Keybuk> kinky
<jdub> i didn't even mention the positive reinforcement
<thom> jdub: yeah, header caching kicks the lama's ass
<daniels> thom: 'whips'
<jdub> it's seriously fast
<jdub> very helpful for u-u
<thom> aye
<Kamion> jdub: header caching in what?
<jdub> mutt
<thom> mutt
<jdub> # header caching directory
<jdub> set header_cache = ~/.mutt/cache
<jdub> 
<jdub> ^ yum
<jdub> $ du -sh .mutt/cache/
<jdub> 56M     .mutt/cache/
<jdub> heh
<thom> jdub: um, is g-u-s supposed to work?
<jdub> thom: yeah
<thom> 11:43 ~% ls -lh tmp/mutt-header-cache
<thom> -rw-------  1 thom thom 118M 2004-12-01 11:21 tmp/mutt-header-cache
<jdub> you went with one file
<jdub> ?
<thom> jdub: is it supposed to show up in nautilus?
<thom> jdub: yeah
<jdub> thom: it should appear in Network, yeah
<jdub> thom: ah, you might be hitting some funny mdnsresponder bugs
<thom> when i started using header cache you could only have one file ;-)
<thom> oh?
<thom> fixable?
<jdub> thom: you're connected to a network with a default route, etc?
<thom> yep
<jdub> try restarting mdnsresponder
<seb128> jdub: #2596, your comment was for this bug ?
<thom> nautilus segfaulted, but i still see nothing in Network
<jdub> seb128: yes
<seb128> how the missing link is connected to this problem ?
<Keybuk> jdub: what appears in network?
<jdub> "jdub's Public Files"
<jdub> lower case though ;)
<Keybuk> how do you set what your public files are ?
<jdub> you don't
<jdub> it's ~/Public
<Keybuk> hmm
<Keybuk> I don't have one of those
<jdub> thom: hrm, do you have a ~/Public?
<thom> yep
<jdub> Keybuk: see discussion on d-d-l :)
<Keybuk> that's a long discussion :p
<jdub> you can ignore the dobey-being-a-child bits
<Keybuk> so I made a ~/Public. put a file in it, and still don't have any public files in Network
<jdub> have you run gnome-file-share-properties?
<thom> yep
<jdub> thom: i imagine you've done the right thing...
<jdub> but it's this Keybuk character i'm worried about
<thom> heh
<thom> apache is running correctly, and i can connect
<Keybuk> jdub: ah, there's not an icon for that anywhere :p
<jdub> nup
<jdub> that'll go through some change, i imagine
<Keybuk> so how do I see tom's public files?
* thom finds a large h and beats Keybuk 
<jdub> if you're on the same local link, you should just see it in Network
<thom> i can see neither me or Keybum
<Keybuk> nope ... :(
<jdub> haw haw keybum
<jdub> hrm
<jdub> okay
<jdub> install howl-utils
<jdub> and do this for me:
<jdub> thom, run "mDNSBrowse _webdav._tcp"
<thom>  mDNSBrowse _webdav._tcp
<thom> [assert]  error: 111 (Connection refused)
<thom> [assert]  where: "socket.c", "sw_socket_tcp_connect", line: 720
<jdub> keybuk, run "mDNSPublish bong _webdav._tcp 8080"
<Keybuk> jdub: if I do the same thing ... I 
<jdub> thom: stop mdnsresponder and start it again
<Keybuk> I see:
<Keybuk> syndicate scott% mDNSBrowse _webdav._tcp
<Keybuk> browse reply: Add Service 0x2 scott's public files _webdav._tcp. local.
<Keybuk> resolve reply: 0x2 scott's public files _webdav._tcp. local. 192.168.1.11 34549
<jdub> Keybuk: great :)
<jdub> Keybuk: in which case, it really ought to appear in your Network window :)
<Keybuk> jdub: your Publish thing made a bong folder appear in Network
<jdub> Keybuk: great
<Keybuk> yeah, I see my folder in Network now ... just needed enabling
<fabbione> 2.6.9: ppc is GO
<thom> feh, still can't see it
<thom> i get the browse replies in mdnsbrowse
<thom> but nada in nautilus
<jdub> are you using warty or hoary?
<daniels> er, hold on
<daniels> this isn't because you can't do wireless broadcast, is it?
<thom> hoary
<thom> daniels: no, it's just nautilus that's having problems
<jdub> killall nautilus
<daniels> i see 'bong' and 'scott's public files'
<daniels> RESOLVED/WORKSFORME
<daniels> maybe it objects to your choice of keyboard layout? :)
<thom> ahr
<thom> yeah, killing nautilus again cured it
<jdub> probably the mdnsresponder b0rk there
<Keybuk> so how do we use this to talk to people? :p
<Keybuk> other than publishing silly folder names?
<thom> rendezvous advertises a different service
<daniels> that could work awesomely with jabber
<thom> it nearly works
<daniels> _jabber_.tcp
<thom> daniels: that's what rendezvous is, yes
<daniels> or _jabber._tcp
<daniels> thom: oh?  i thought it was some aim-based crap
<Keybuk> so where's the Gossip + Howl integration?
<ross> iirc, hallski said that is in the plan
<daniels> mvo_: could you please upload xpdf 10ubuntu2 without the libxau-dev b-d?
<thom> daniels: AIUI rendezvous is jabber
<mvo_> daniels: it fails to build for me without the dev
<daniels> mvo_: xpdf doesn't use anything from libxau, that's xprint, and i fixed libxp-dev last night
<thom> iChat supports jabber entirely, they just don't expose it :(
<daniels> mvo_: upgrade to libxp-dev 6.8.1-1ubuntu4
<mvo_> all right, thanks
<daniels> cheers
<jdub> thom: so depressing
<thom> jdub: aye
<daniels> that's really impressive -- my iriver has been off for at least ten minutes
<daniels> yet there is apparently 2GB of cached data
<thom> might be fixed in tiger
* daniels doesn't question it on the premise that it may fall over.
<Keybuk> I'm so patching g-t-m to say "Take the hint!" after the third time you postpone it
<thom> heh
<thom> workrave++
<Keybuk> workrave I'm patching to add silly exercise suggestions
<daniels> Keybuk: yah, workrave does crap all over g-t-m
<Keybuk> "mosh"
<Keybuk> "hop on one leg and sing, bitch"
<thom> heh
<jdub> pants off, mjg59 
<daniels> PANTS
<Keybuk> daniels: so, dude, do you want to keep your hair? :)
<daniels> you didn't seriously bring clippers, did you?
<Keybuk> yup
<daniels> christ
<Keybuk> he had messy long hair too... yes
<thom> 019 thom      25   0  5420 2172 4120 R 89.1  0.4  33:02.85 gnome-user-shar
<thom> what the hell is it doing?
<mjg59> jdub: PANTS
<mjg59> Aww. My lca talks didn't get accepted.
<mjg59> Sob.
<thom> suck :(
<mjg59> Poor me.
<mjg59> I'll just need to find some other excuse to go
<Keybuk> heh
<Keybuk> Canonical Conference, if that happens over there? :)
<daniels> mjg59: bugger
* daniels hits Send/Receive a few million times.
<seb128> Keybuk: have you read my mail about the panel changes ?
<thom> jdub: so, why is g-u-s spinning my cpu so hard?
<Keybuk> seb128: yeah, I agree with Jeff I think -- short time screwage, then reimplement things with a Places menu
<seb128> the problem is the "short"
<seb128> do we have a good idea of what we want ?
<daniels> oh, heh!
<daniels> i deleted my LCA mail as spam
<thom> dumbass
<daniels> but!  trash knows all.
<Keybuk> seb128: just talking to Mark...
<seb128> Keybuk: ok. Perhaps we should wait a few day and speak about all this during the conf
<Keybuk> go with upstream, do the fd.o menu changes with Applications, Places, System? sounds like the plan
<seb128> jdub: here ?
<seb128> Keybuk: Ok, I'll start by looking on the internal of the new system. gnome-menus handles the applications menu, dunno how easy it'll be to move categories in an another top menu (like the computer one)
<Keybuk> have upstream done anything about integrating Nautilus' Places and the GtkFileChooser bookmarks yet?
<seb128> I was speaking with alex (the nautilus main devel) about this 2 days ago
<seb128> since he has finished the bonobo-slay
<seb128> he has not decided yet, but he agreed that would be nice to get this for 2.10 ... I need to ping him again
<Keybuk> that's pretty much a requisite of our Places menu, no?
<Keybuk> or is that GnomeVFS'd ?
<seb128> hum, good question. Since there is not unification for the moment about this ...
<seb128> ok, I'll ping alex about this
<seb128> and delay the new panel until next week so we can figure all that exactly during the conf
<pitti> ping daniels 
<daniels> pitti: pong
<mjg59> daniels: Man, you suck
<daniels> ...
<GotD0t> daniels: any word on 3D accleration in hoary with those new fangled drivers of yours?
<azeem> is there a canonical place for build logs?
<thom> people.ubuntu.com/~lamont/buildLogs
<thom> iirc
<fabbione> yeah
<fabbione> it's that one
<azeem> thansk
<Keybuk> jdub: theme!
<daniels> GotD0t: on which card?
<GotD0t> daniels: ati 9700
<daniels> nope
<GotD0t> daniels: are there any cards with 3d accleration?
<daniels> er, yeah
<fabbione> who wants some real good crack?
<daniels> like everything except radeon >= 9500 or nvidia cards
<fabbione> mput linux-source-2.6.9_2.6.9*
<fabbione> 49117455 bytes transferred in 3 seconds (16.90M/s)                             
<fabbione> Total 4 files transferred
<fabbione> enjoy
<GotD0t> hmm
<Keybuk>      Battery 1: charging, 100%
<Keybuk> hmm
<daniels> more of that legendary HP ACPI support :P
<GotD0t> daniels: well if you need me to test ill gladly be your guinea pig ;-)
<daniels> GotD0t: as soon as I have that code, I'll be bouncing off the walls and annoucing it loud and clear
<GotD0t> daniels: haha
<fabbione> elmo: i think the kernel will need some of your love
<fabbione> elmo: afaik it should be new
<Keybuk> daniels: it's just determined to *really* charge the battery
<Keybuk> present rate:            11 mA
<GotD0t> daniels: well your work is certainly appreciated
<elmo> processed
* fabbione shakes elmo violently
* fabbione hugs elmo
<fabbione> ehehhe
<fabbione> thanks man!
<Kamion> eject
<Kamion> oops
<fabbione> ehehhe
<Kamion> damn that ircsh
* Kamion nearly strangles himself on a laptop power cord - I hate the layout of this desk
<thom> at least you have a desk currently
<GotD0t> Kamion: thats... interesting
<fabbione> Kamion: how would you feel to start working together on the kickstart thingy?
<pitti> Hi mvo_ :-)
<mvo_> hi pitti 
<Kamion> fabbione: sounds good; why don't we kick it off in mataro?
<fabbione> Kamion: fully agreed
<fabbione> Kamion: i would be busy anyway the next 2 days :-)
<fabbione> oh i can also help you with USB installations
<fabbione> i have done that before
<Kamion> those should be easy, I just need to flip the switch
<Kamion> yeah, likewise
<fabbione> too bad that i prepared the usb thingy with everything
<fabbione> until i realized i had no pc that could boot from usb
<Kamion> they'll be essentially netboot
<Kamion> I have several :)
<fabbione> i have one now
<fabbione> yeah
<Kamion> dunno if people follow #debian-boot, but I'm thinking of switching to the Debian experimental branch for parted
<Kamion> it will help us out by possibly killing off that damned Windows-trashing bug, and it will help Debian out by getting them additional testing
<fabbione> Kamion: break it early? ;)
<Kamion> yep
<zul> break it often? :)
<fabbione> break it. <- full stop
<zul> heh
<fabbione> well have fun guys
<fabbione> (specially when 2.6.9 will hit the mirror)
<fabbione> i really need to get some sleep
<lamont> Kamion: for the record, the "fix" on the two broken ones was to re-run the build script... 
<lamont> please avoid doing uploads around 6AM london time.
<lamont> for NEW, same goes for elmo. :-)
<lamont> d-i stuff, that is.
<Kamion> that's fairly safe for me :)
<elmo> lamont: err, that doesn't expllain today's breakage, surely?
<lamont> elmo: sigh.
<lamont> yet newer source, or just the next-day build of yesterdays?
<lamont> daniels: doh!
<elmo> lamont: 20041201 build of same source that's been in the archive for a while now
<lamont> ok.  will look at it.
<lamont> doko?
<magnon> Arh. Does anyone else have a broken nautilus?
<lamont> Kamion: you about?
<Kamion> lamont: yep
* Kamion uploads scary parted 1.6.19
* thom ducks and covers
<bob2> pbbuttonsd seems fucked in hoary
<bob2> it ignores notap, so I get random mouse clicks from typing and hitting the touchpad
<lupus_> if I remove /.gconf
<Keybuk> thom: how often do you move patches about?
<thom> move the order infrequently
<Kamion> elmo_away: could you bump pciutils-udeb to standard please?
<thom> bob2: elmo has mentioned that too, i think
<bob2> yay
<thom> so you're not entirely on crack, for once
* Mithrandir idly hates openoffice.org
<bob2> if I get an x40, you have to fix bugs for me
<bob2> so watch it
<thom> Mithrandir: only idly? you should be radiating ACTIVE and TOTAL hate at it
<thom> ahem
<thom> bob2: there are no bugs on x40
<Mithrandir> thom: it's saturating my DSL.
<haggai> thom: if is wasn't so huge it wouldn't be all that bad.
<Keybuk> thom: I guess in the dpatch-world you just mv the patch?
<haggai> thom: the code itself isn't so bad
<Mithrandir> haggai: I'm on amd64, so it's doubly bad.
<haggai> Mithrandir: yeah, there's that small problem
<Mithrandir> and I only have a slow 3MBit DSL.
<thom> Keybuk: mv then twiddle 00list
<Keybuk> thom: aside from daniels's "non-functioning" wireless?
<Mithrandir> haggai: I need to download about 400MB to update the version now.
<thom> well, that's just atheros suck
<Keybuk> I'm trying to decide whether "hct mvpatch" is sane
<bob2> people who use 'slow' and '3bmit dsl' in one sentence suck
<thom> you mean rename-patch; i guess
* Mithrandir throws 400MByte of OOo source at bob2
* bob2 takes a picture with his shiny camera
<Keybuk> thom: could be ... remove-patch and rename-patch ?  bit zsh-reliant
<haggai> 400??
<thom> mvpatch implies dealing sensibly with patch ordering, i guess
<Mithrandir> haggai: amd64 sources is 200, i386 is 170.
<Mithrandir> or amd64 "sources".
<Mithrandir> bob2: what kind of camera did you end up with?
<haggai> Mithrandir: you mean, sources for dependent libs, or something?
<bob2> Mithrandir: dsc-p150
* haggai scratches head
<Mithrandir> bob2: rock! :)
<Mithrandir> haggai: no, sources + i386 binaries.
<thom> haggai: for enough of a 32bit binary system to run OOo
<Keybuk> thom: I hate ui :-/
<thom> Keybuk: heh
<haggai> Mithrandir: ah, ok so not really sources
<Mithrandir> haggai: sources + i386 binaries.
<Mithrandir> ia32-libs-ooo is in addition
<Kamion> haggai: the sooner this goes away, the happier my source CD builds will be :)
<Mithrandir> mumblemumblemultiarchmumblemumble.
<haggai> Kamion: just gimme a bounty to finish off the port...
<Kamion> haggai: talk to mdz :)
<haggai> ok :)
* Mithrandir thinks multiarch is much sweeter
<Kamion> Mithrandir: in this instance it's a workaround though
<Mithrandir> Kamion: it's a sweet, crackful workaround, though.
<Kamion> Mithrandir <- weirdo
<Mithrandir> Kamion :)
<Kamion> elmo_away: likewise usbutils-udeb priority -> standard please; those two give us lspci and lsusb in the installer environment
<mdz> haggai: hmm?
<Mithrandir> haggai: where has ooo-crashrep gone?
<Kamion> elmo_away: (by default, without having to do weird stuff with expert mode or anna-install)
<mdz> mvo__: pong
<mdz> Kamion: I was going to ask you about hoary d-i on powerpc
<Kamion> mdz: yep?
<mdz> Kamion: it doesn't detect my CD-ROM, and if that's not entirely expected, I can help debug it
<lamont> elmo/kamion: btw, it appears that the d-i daily failure was due to timing between cron.daily and BuildDI
<lamont> I time shifted it to 0615 local, should be happier come morning
<lamont> but I'll check then.
<Kamion> mdz: that's probably the generic udev problem that got fixed in the newer d-i build
<Kamion> lamont: ah, good
<Kamion> mdz: workaround: when languagechooser comes up, switch to tty2 and 'mkdir /etc/udev/scripts; mv /etc/udev/*.sh /etc/udev/scripts/'
<Kamion> mdz: see if that helps
<mdz> Kamion: this was a daily, 1-2 days old I think
<mdz> I can just rsync down a newer one
<Kamion> mdz: sure, 20041201.1 is fixed
<Kamion> haven't tried it on powerpc yet; I have a kernel build going here for Debian so I can't do so just now
<haggai> Mithrandir: it was too much trouble to be worth it
<Mithrandir> haggai: ok
<haggai> mdz: I idly suggested a bounty for the OOo 64 bit port
<haggai> Mithrandir: under KDE I get the KDE bug buddy (with openoffice.org-kde); I wonder if the gnome bug buddy does the same
<mdz> haggai: I vaguely recall when we talked about this before, that 64-bit work was planned for a later release which probably wouldn't make our cutoff; is that still the case?
<Keybuk> seb128, jdub: uh, why has "Session" disappeared from Desktop Preferences ?
<haggai> mdz: yes, that's true it's not worth doing the work on 1.1 (which I guess Mithrandir is more worried about)
<Mithrandir> haggai: I'm mostly moaning, just ignore that. :)
<haggai> :)
<Mithrandir> would anybody care if we didn't ship openoffice.org-dev for amd64?
<haggai> Mithrandir: nope
<Mithrandir> I'm not sure it would work at all, and it's universe.
<haggai> it's only interesting for people developing stuff against OOo anyway
<haggai> mdz: we'll have to see what happens for 2.0.  Time is beginning to run out to fix up the 64 bit port for 2.0, but since it is likely to be just after hoary, we'll have several months to worry about it for grumpy
<mdz> Mithrandir: no, certainly not important
<mdz> haggai: is there a published schedule for 2.0?
<mdz> haggai: or is that an estimate of when the required work will be completed?
<seb128> Keybuk: hum, part of the new panel changes, the .desktop has been moved to /usr/share/applications instead of /usr/share/control-center/
<seb128> Keybuk: and the old panel doesn't use /usr/share/applications for the Desktop Preferences
<Keybuk> so how much stuff are we going to lose before we get the new panel?
<seb128> we will stay in the current situation, next step is the new panel
<seb128> so you can count the missing items :p
* lamont decides that maybe this week is a bad week to upgrade the home desktop
<seb128> but right, the sooner we push the new panel the better
<seb128> jdub: ping ?
<Mithrandir> uhm, is ooo-l10n-en supposed to be uninstallable now?
<Kamion> Mithrandir: I thought that'd been fixed
<Kamion> http://people.ubuntu.com/~cjwatson/testing/hoary_probs.html says it's ok
<Mithrandir> yeah, just an old packages file, it seems
<haggai> mdz: the schedule for 2.0 is March 2005, but there is no schedule for the 64 bit port
<mdz> haggai: if it doesn't make it, it'd be a fine Grumpy bounty
<mdz> not to encourage it to slip or anything :-)
<mdz> interesting that oo.o and GNOME are both releasing in March
<haggai> mdz: yeah, that's one way to look at it.  Problem is, if the port turns out to need drastic changes it will be difficult to get them upstream quickly if we wait until 2.0
<haggai> s/until 2.0/after 2.0/
<mdz> would it be a crazy idea for Hoary to track oo.o 2.x development and release with 2.0?
<mdz> that's what we're going for GNOME 2.10
<mdz> s/going/doing/
<haggai> not completely crazy
<Kamion> feature goal! *cough*
<haggai> Novell are already concentrating on 1.9
<mdz> maybe package it up in parallel, and decide later whether we should make the switch
<thom> elmo has just been broken by gnome-terminal prettiness
<haggai> yeah, we can consider packaging in parallel anyway.  I find it does better than 1.1 quite often already
<mdz> Kamion: it's not too late for a new feature goal; I imagine several will surface during Mataro ;-)
<mdz> haggai: has oo.o always done time-based releases?  how likely is it that the date will be met?
<Kamion> mdz: I'm not objecting, just lobbing peanuts from the gallery really :-)
<mdz> Kamion: hey, you're on the wrong side to be lobbing peanuts ;-)
<haggai> mdz: yeah, they try to stick to their schedules.  It could slip, but it is quite possible they'll get it out on time
* haggai hands Kamion some more peanuts
<mdz> it's awfully tempting
<Kamion> mdz: d'oh
<haggai> we already have several 2.0 features :) native cups, fontconfig, widget backports
<haggai> so those are already getting good testing
<Mithrandir> haggai: why does ooo ship ./usr/lib/openoffice/program/libtl645li.so which is linked to libgnomevfs?
<haggai> Mithrandir: gnome vfs support, but that should be in a seperate pkg
<haggai> openoffice.org-gnomevfs
<haggai> Mithrandir: you could drop it if it's hard
<_rene_> it *is* in a separate package ;-)
<Mithrandir> haggai: : tfheen@golem ..amd64-1.1.2-2ubuntu6/pkgs > dpkg -c openoffice.org-bin_1.1.3-2.3ubuntu4_i386.deb|grep libtl645li.so
<Mithrandir> -rw-r--r-- root/root    723136 2004-11-30 15:23:51 ./usr/lib/openoffice/program/libtl645li.so
<_rene_> Mithrandir: one is in -bin and one in -gnomevfs
<_rene_> Mithrandir: the latter one diverts the one from -bin
<Mithrandir> _rene_: can we _please_ get rid of the one in -bin?
<Mithrandir> or at least make it not link to gnomevfs?
<_rene_> Mithrandir: no. because then we would have -bin depending on gnomevfs
<_rene_> Mithrandir: the -gnomevfs one depends on gnomevfs
<haggai> Mithrandir: the one in -bin isn't supposed to link to gnomevfs
<_rene_> (when everything went right...)
<Mithrandir> _rene_: /usr/lib/openoffice/program/setup.bin: error while loading shared libraries: libgnomevfs-2.so.0: cannot open shared object file: No such file or directory
<_rene_> worked on my 1.1.3-x builds anyway
<Mithrandir> it says when I run openoffice from the command line
<Mithrandir> and ldd says:
<_rene_> probably a ubuntu-only problem? ;)
<Mithrandir> : tfheen@golem ..amd64-1.1.2-2ubuntu6/pkgs > ldd /usr/lib/openoffice/program/libtl645li.so | grep gnome
<Mithrandir>         libgnomevfs-2.so.0 => not found
<Mithrandir> this is a _big_ problem for me. :)
<haggai> chris@feathers:/usr/lib/openoffice/program$ ldd libtl645li.so  | grep gnome
<haggai> chris@feathers:/usr/lib/openoffice/program$
<mdz> haggai: oo.o 1.1.3 gave me an EULA dialog the first time running it; is thaht normal?
<_rene_> mdz: no
<Mithrandir> mdz: can you please check on an i386 system?
<haggai> mdz: no, that shouldn't happen.  How did you start it?
<mdz> it was on an i386 system
<mdz> started from mutt, opening a .doc file
<Mithrandir> mdz: no, check the ldd line we're talking about
<mdz> that was the first time running 1.1.3
<_rene_> mdz: what does mutt run?
<mdz> Mithrandir: oh :-)
<mdz> _rene_: whatever is in /etc/mailcap
<mdz> openoffice '%s'
<_rene_> mdz: if it doesn't run the wrapper script (openoffice, oo*) that shouldn't happen
<_rene_> errm
<_rene_> s/shouldn't happen/happens/
<Mithrandir> mdz: as I don't have any hoary i386 systems around :)
<elmo> seeeeeb
<elmo> seb128: is it known that clicking on .html documents in nautilus doesn't work?
<elmo> even right clicking and 'Open with firefox' doesn't work
<mdz> Kamion: what are udeb priorities used for?
<mdz> mizar:[/space/tmp/mdz/tmp]  ldd /usr/lib/openoffice/program/setup.bin | grep gnome
<mdz> zsh: done       ldd /usr/lib/openoffice/program/setup.bin |
<mdz> Mithrandir: ^^^
<seb128> elmo: not, it's not ... it's not even opening the file in a tab of an existant firefox ?
<mdz> mizar:[/space/tmp/mdz/tmp]   ldd /usr/lib/openoffice/program/libtl645li.so G gnome
<mdz>         libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0x400eb000)
<seb128> elmo: works here
<Mithrandir> mdz: and you don't have ooo-gnomevfs installed?
<mdz> Mithrandir: correct
<mxpxpod> is it planned to get 2.6.9 into ubuntu?
<mdz> mxpxpod: it is already in hoary
<Mithrandir> mdz: ok, then something broke when it built.
* mdz waves the retroactive feature wand
<Mithrandir> haggai, _rene_: anybody of you know why this have happened?
<Matt|> guys any idea why I would have /proc and /home randomly unmounted for no reason? It is happening to me a lot these days. Since the last 2.6.8.1 kernel in hoary
<haggai> Mithrandir: hold on a sec
<mxpxpod> mdz: I don't see a linux-source package
<thom> mdz: is G an alias to |grep, by chance?
<haggai> mdz: can you uninstall ooo-gnomevfs and then try?
<mdz> Matt|: jdub said that happened when he was trying out some network config app, I think
<mdz> thom: yes
<Mithrandir> haggai: he doesn't have ooo-gvfs installed
<haggai> Mithrandir: ah ok I got the wrong sense
<Matt|> mdz, i was just using xchat and firefox :( first thing i noticed was me pinging out of irc. Same story yesterday
<haggai> it's _rene_'s bit of hackery, that one
<haggai> _rene_: ?
<mdz> mxpxpod: http://lists.ubuntu.com/archives/hoary-changes/2004-December/000710.html
<_rene_> hmm?
<_rene_> yeah, the two libtl building is a bit hackish
<haggai> _rene_: any idea why your dirty hack broke? *hide*
<Kamion> mdz: priority >= standard gets installed by anna by default
<_rene_> no ;-)
<mdz> elmo: is 2.6.9 waiting in queue/new by any chance?
<mdz> looks like it built on i386 and amd64
<_rene_> Mithrandir: have a buildlog somewhere?
<Mithrandir> _rene_: http://people.ubuntu.com/~lamont/buildLogs/o/openoffice.org/1.1.3-2.3ubuntu4/openoffice.org_1.1.3-2.3ubuntu4_20041130-0742-i386-successful
<mdz> haggai: I don't have ooo-gnomevfs installed
<mxpxpod> mdz: hrmm, that's strange... and apt-get cache search linux-source only shows me 2.6.8.1
<mdz> mxpxpod: it has been built, but hasn't entered the archive yet
<mdz> it was just uploaded today
<mxpxpod> mdz: ahhhh, ok
<mxpxpod> mdz: that makes sense
<Kamion> elmo: are you running germinate at least as new as patch-11?
<Kamion> elmo: (i.e. can I use the new substitution variables feature in the installer seed?)
<mxpxpod> mdz: btw, where do I get the cramfs patch so I can make an initrd image?
<Kamion> mxpxpod: cramfs is in 2.6 by default
<Kamion> (AFAIK)
<elmo> kamion; no
<Kamion> elmo: could you be? :)
<mdz> mxpxpod: it's part of linux-patch-debian-2.6.8.1, or in the linux-source-<ver> source package
<mxpxpod> mdz: ah, ok
<mxpxpod> mdz: thanks
<elmo> mdz: yes, processed
<elmo> kamion: no
<elmo> ;-)
<mdz> elmo: thanks
<smurfix> 
<mdz> good timing, since I find that I need to burn a CD
<mdz> which doesn't work with the 2.6.9 pre-release I'm running, and hopefully fabio's final build fixes it
* Kamion takes away elmo's germinate support licence ;)
* elmo sues kamion for breach of contract
<elmo> kamion: [updated] 
<elmo> apparently I have no local changes anymore, hmm
<elmo> mdz: can you/someone seed it please?
<lamont> mdz: ppc upload is going to miss this cron.daily
<lamont> (just finished)
<mdz> elmo: will do
<lamont> s/ed/ing/
<mdz> Kamion: the cramfs initrd patch is in 2.6 by default?  I didn't think it was
<mdz> though I don't see it in the source package, so I suppose you're right
<mdz> we should patch all that obnoxiousness out of kernel-package, then
<mxpxpod> mdz: ok, how do I build the ubuntu kernel with an added patch of my own?
<Matt|> mxpxpod, get the source, patch it, build kernel
<mxpxpod> mdz: just grab linux-source-2.6.9 and linux-patch-debian-2.6.9?
<Kamion> elmo: ta
<Kamion> mdz: I'm fixing the installer seed now
<mxpxpod> Matt|: where do I get the default config they use?
<Matt|> mxpxpod, /boot?
<mxpxpod> Matt|: isn't it housed somewhere in the linux-source?
<Matt|> mxpxpod, not sure, it's def in /boot tho
<Matt|> mdz, sorry to bother you again, but do you know if any progress has been made on the acpi patch in the kernel? #2711 was still there in the 2.6.9 i tried
<mdz> Matt|: mjg59 would be the person to ask
<Matt|> mdz, kthx
<mdz> thom: all unpacked yet? :-)
<mjg59> Matt|: I'm just about to head home - can you ask me in an hour or so?
<Matt|> mjg59, of course
<mjg59> Thanks
<Matt|> thank YOU
<Matt|> :)
<Matt|> its not really a question
<thom> mdz: haha
<thom> mdz: i'm at marks
<thom> my house is still in boxes
<thom> i'm going to go home and unpack enough to find some clothes for BCN
<daniels> thom: g'night captain
<thom> ciao
<elmo> new fonts are SO SHINY
<mdz> what new fonts?
<daniels> elmo: hinting by default
<daniels> s/elmo/mdz/
<mdz> haven't noticed a difference
<daniels> warty->hoary change
<elmo> mdz: dude, on my laptop it's freaking incredible
<daniels> powerbook shiny, news at 11 :P
<elmo> mdz: I've started running a) gnome-terminal rather than xterm, b) emacs in a gnome-terminal just to get more of the shiny
<Matt|> *laughs*
<Matt|> openoffice 1.1.2 looked betta tho imo
<mdz> elmo: you just started using gnome-terminal rather than xterm?
<mdz> elmo: so you didn't even have anti-aliased fonts before?
<kylem_> gnome-terminal is slooowwwww. but yeah, it's shiny.
<mdz> the shininess is enough to outweigh the slowness for me
<zul> what about aterm?
<Matt|> me too
<seb128> aterm doesn't support utf-8 atm IIRC
<Matt|> aterm didn't work properly on warty when i tried it ages ago, dunno if it does now
<mdz> fabbione: 2.6.9-1 in hoary breaks in the same way with regard to my USB writer
<mdz> GAH
<fabbione> mdz: there has been no code changes in that way
<mdz> fabbione: I thought you changed it to CONFIG_BLK_DEV_UB=n
<fabbione> mdz: you said that it made no difference
<fabbione> since it was a module
<fabbione> or i might be confused
<fabbione> anyway.. -2 stuff
<elmo> mdz: yep
<mdz> I said that it did make a difference
<fabbione> ah
<fabbione> mdz: than i misunderstood, sorry
<fabbione> mdz: go ahead with a -2
<fabbione> i will take it from there
<mdz> I am building a kernel without UB now to test if it actually solves the problem
<fabbione> ah so i was right that you didn't test it directly
<fabbione> or at least i remember properly
<fabbione> ok 
<fabbione> later
<fabbione> if i don't finish for this evening i won't be able to work tomorrow :-)
<mdz> elmo: dude, welcome to the 21st century
<elmo> dude, gnome-terminal in warty is unusably slow on 1600x1200 or higher
<mdz> I run it at 1600x1200
<mdz> you just get in the habit of redirecting things to files :-P
<Kamion> that sucks :)
* lamont tried gnome-terminal, threw  it away
<Kamion> I really must get pterm linked against gtk2
<elmo> lamont: dude, try hoary gnome-terminal.. SHINY SHINY SHINY
<Mithrandir> elmo: but slow
<mdz> gnome-terminal actually gets the mouse-selection stuff right that xterm gets wrong
<Kamion> it kicks xterm's arse speed-wise let alone gnome-terminal
<mdz> which is completely the opposite of how it used to be
<Kamion> mdz: xterm's totally configurable there surely?
<elmo> Mithrandir: no, it's a lot better, at least on my powerbook's res, I haven't tried ultra-high-res desktop yet
<Mithrandir> elmo: dog slow on my 2GHz athlon64 at 1280x1024
<elmo> boggle
<Mithrandir> and dog slow on my P4 2.4GHz with the same res at uni.
<mdz> Kamion: I don't think so; for example, I could never get xterm to un-wrap multi-line selections from less(1) output
<Mithrandir> if I do find /, I'm able to vgrep for stuff
<elmo> ...... EWW
<elmo> okay, gnome-terminal hasn't actually been fixed, it's only usable with small fonts
<Mithrandir> elmo: and it consumes 100% cpu while doing that.  Or 80% or something.
<elmo> yeah
<elmo> I just found that out.
<elmo> wah.  rock (lack of shiny), hard place (crap scrolling)
<Kamion> elmo: I've switched the installer seed to 2.6.9 now; I'll upload new debian-installer when the powerpc udebs are there
<daniels> elmo: patch in gnome bugzilla
<elmo> Kamion: processed ppc
<Kamion> d'oh, memo to self, xargs vi considered CONFUSING
<mdz> elmo: I'm also completely addicted to the session save/restore features of gnome-terminal
<elmo> how's that differ from screen?
<mdz> pretty different idea
<mdz> puts all your terminals back in the same places on the same desktops
<mdz> with the same cwd
<Keybuk> ya know ... I'm going to start talking about all the uploads I do in my activity report
<Keybuk> today I uploaded 5 packages
<Keybuk> look, here's the changes files
<Keybuk> :)
<daniels> elmo: http://bugzilla.gnome.org/show_bug.cgi?id=122656
<Kamion> Keybuk: which you put how much personal effort into? :)
* ironwolf cheers on Keybuk.
<Keybuk> Kamion: there's man-MONTHS of work there
<Kamion> Keybuk: per day ... impressive
<Keybuk> the fact that an automated system produced them
<Keybuk> and someone else entirely uploaded them
<Keybuk> (and just didn't bother to change the debian/changelog entry)
<Keybuk> is all irrelevant :p
<elmo> mdz: oh, I get around that by having one big terminal that covers the entire screen :->
<Kamion> Keybuk: you'd better snip off the GPG signature :)
<elmo> Keybuk: oh, that was really you uploading them?  I assumed it was another impostor
<Keybuk> mdz: I disable the gnome-session stuff
<Keybuk> elmo: no!
<mdz> Keybuk: disable?  isn't it simpler to just not check the "save session" box?
<Kamion> Keybuk: (why don't you set debian/changelog to something more obviously to-be-changed, incidentally?)
<mdz> (i.e., the default)
<Keybuk> I'm subtly bitching about all the "ACCEPTED" mails I get that are nothing to do with me! :p
<Keybuk> mdz: that's what I do
<Mithrandir> poor Keybuk
<Keybuk> Kamion: because then people still wouldn't change it
<mdz> Keybuk: I set everything up once, check the box, and use that session on future logins (and don't save again)
<Keybuk> ah right
<Keybuk> I rely on too many apps that don't frakking work
<mdz> ooh
<Keybuk> Mozila "I spawn 2000 Choose Profile windows" Firefox
<mdz> I just remembered about firefox gnomesupport
<mdz> maybe it can restore itself now, too
<Kamion> mdz: most of my terminals are too transient for that to be worthwhile; the ones that aren't are logins on other systems
<elmo> Keybuk: dude, I can take you off the whitelist
<mdz> Kamion: I restore those too
<elmo> oh, I promsied to remove a bunch of debian.org addreses, and didn't.. meh
<Kamion> that session restore idea sounds ideal for slackers who never change working directory, though ;)
<Keybuk> elmo: but then I wouldn't be able to upload myself, *again* :p
<mdz> Kamion: where I typically have a session open to a remote system, I create a gnome-terminal profile for it, so it restores and logs me in
<mdz> Kamion: I don't actually take advantage of the cwd thing, but I find it incredibly cool that it does it :-)
<mirak> hi
<mirak> I ask a question here
<mirak> there is a problem with revision of the 2.6.8 kernel on hoary
<mirak> with lilo
<mirak> lilo won't boot this kernel
<mirak> it says the kernel is to big and it overwrites the stack of lilo stage 2
* lamont__ heads into town for a few things.  bbl
<mdz> mirak: grub boots it fine
<mirak> mdz, how do I setup grub ?
<mirak> I am on knoppix right now chrooted in ubuntu
<mdz> mirak: search the web
<mdz> generally, grub-install "(hd0)"
<mirak> where is the config file ?
<Mithrandir> mirak: /boot/grub/menu.lst, but it's read run-time
<jdub> hooooly crap
<jdub> mdz: around?
<mdz> jdub: yep
<mdz> I hope that's a good "hooooly crap"
<stratus> where's the ubuntu december wallpaper?
* stratus hides
<jdub> mdz: noticed Matt| raised the "stuff is unmounted" thing
<jdub> stratus: already uploaded
<mdz> jdub: yeah, what was it that did that? I forget
* stratus still hidden
<jdub> mdz: it's happened in two instances i'm aware of atm,
<jdub> mdz: both involving unloading the ipw2200 driver
<jdub> and switching between my wifi and wired links
<jdub> (i unload ipw2200 in interfaces)
<Mithrandir> jdub: my desktop does not have any ipw2200 and I saw it a couple of hours ago
<Mithrandir> though, I did unload the driver to reset the card.
<mdz> fabbione: disabling BLK_DEV_UB fixed my problem
<jdub> Mithrandir: aha
<stratus> jdub, thanks.
<jdub> Mithrandir: yeah, doesn't seem specific to ipw2200, but related to network configuration and driver changes
<jdub> Mithrandir: which kernel are you using?
<Mithrandir> 2.6.8.1-3
<mdz> are you guys using networkmanager or something?
<Mithrandir> amd64
<mdz> I've never seen this crack
<_rene_> Mithrandir: the normal version of libtl built fine, maybe the cp into the tree somehow did not work...
<Mithrandir> mdz: not that I know of.
<mdz> jdub, Mithrandir anything funny in /etc/network/*.d ?
<Mithrandir> mdz: I haven't touched that directory.
<_rene_> you may want to try to cp -v it and/or objdump -p solver/645/unxlngi4.pro/lib/libtl645li.so to find out
<jdub> mdz: haven't touched
<Mithrandir> _rene_: is that done in debian/rules or somewhere else?
<jdub> just wireless-tools for me
<mdz> Mithrandir, jdub: packages install files there; would you just look please? :-P
<_rene_> Mithrandir: the cp? in debian/rules
* jdub is good boy :(
<jdub> :) rather
<mdz> jdub: what method do you use to switch interfaces when it happens?
<Mithrandir> wireless-tools for me too
<mdz> ifdown/ifup or something fancier?
<Mithrandir> mdz: ifdown + rmmod
<Mithrandir> _rene_: ok, I'll use that for tracking it down.  Thanks.
<jdub> mdz: first time it happened i used netapplet (which i believe uses ifupdown)
<mdz> Mithrandir: you run ifdown and rmmod and your filesystems are unmounted??
<mdz> that's insane
<jdub> mdz: second time i just used ifupdown manually, but keep in mind that ipw2200 is rmmodded in my interfaces
<Mithrandir> mdz: I haven't tried to reproduce it, yes.
<Mithrandir> s/.$/t/
<Mithrandir> and it didn't duplicate now
<jdub> i'll try switching to wired
<jdub> and test where it happens
<jdub> watch "cat /proc/mounts" will break fairly obviously when /proc is unmounted :)
<Mithrandir> heh
<Mithrandir> hi maswan
<maswan> hi there
<maswan> finally back on good old kenny
<Mithrandir> I fixed up nyu's account
<jdub> yeah, did it again
<jdub> Mithrandir: can you bring up your network interface again after it happens?
<Mithrandir> jdub: yes.
<mirak> how to install grub from a running livecd ?
<Mithrandir> jdub: note that I'm using the acx_pci driver, not the ipw2200
<mirak> on the ubuntu hard disk
<jdub> Mithrandir: pity ipw2200 has to have a spew
<jdub> now i ahve to reboot ;)
<jdub> or be stuck to the network umbilical cord
<Mithrandir> jdub: I was taking down the interface to reset it :)
<sladen> what's the situation regarding CUPS on localhost:631 wanting the root password?
<sladen> (somebody asking on #ubuntu)
<Matt|> jdub, sup with that random /proc and /home unmounting stuff?
<Matt|> mine happens totally randomly afaics
<Matt|> lemme see if i can get it
<sivang> sladen : last time I checked, it didn't allow me to log in out of the box, but IMHO the gnome iface works great
<jdub> sladen: we haven't fixed it, and chose not to support the web interface yet
<jdub> sladen: System Configuration > Printing should work
<Matt|> jdub, mdz told me that you have the random /proc and /home unmounting thing too: any idea what causes it
<jdub> un oh
<jdub> Matt|: see the discussion above
<Matt|> hmm k
<jdub> hrm
<stuNNed> is it possible for mozilla-mplayer and mplayer-custom to crash the whole system in ubuntu hoary?
<jdub> mdz: did the dsdt-attached-to-initrd patch get into fabio's 2.6.9?
<Matt|> jdub, dunno if that is related to mine: i use a custom module for wifi, and i just reloaded it without difficulty. It seems totally random.
<mdz> jdub: no, same reasons. see bugzilla
<Matt|> jdub, i have nothing in the /etc/network/*d directories. 
<Matt|> oh well
<Matt|> lemme know if you want me to test anything
<jdub> mdz: so that's a "can't do it unless the kernel guys love it" -> why do we take that stance on this patch in particular?
<mdz> jdub: that's our stance on pretty much all intrusive feature patches
<mdz> we're not in the business of putting all the world's kernel patches into one tree
<fabbione> mdz: is there any meeting going on?
<mdz> fabbione: meeting?
<fabbione> i need to shutdown the server for a few minutes
<fabbione> like doc meeting...
<mdz> I have no idea
<fabbione> ok
<fabbione> thanks
<fabbione> bbl
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
(jdub/#ubuntu-devel) hrm
(mdz/#ubuntu-devel) Kamion: never mind; re-burned and it's chugging along happily
(jdub/#ubuntu-devel) we have to educate people to not set the target
<jdub> can we make a maintainer group, who can see target, etc.?
<mdz> jdub: yeah, I thought that not being able to set it when you file a bug would be enough
<mdz> jdub: but people will actually go back to the bug just to set it
<jdub> yeah
<jdub> persistent!
<mdz> not worth bothering with it at this point
<jdub> given migration to other systems :)
<calc> anyone happen to know why libacl and python bindings are in ubuntu but not the "acl" package itself?
<jdub> sounds like an oversight
<fabbione> amen
<fabbione> 2 new fans for the server are crap
<fabbione> they aren't fast enough
<fabbione> it's not my lucky day...
<fabbione> mdz: did you test the kernel without CONFIG_USB_BLK_UB?
* fabbione needs to set vlans on the switch
* fabbione goes and gets some sleep
<fabbione> night all
<mdz> fabbione: yes
<mdz> fabbione: it fixed my problem
<mdz> however, I seem to have some stability problems with that kernel on my laptop
<mdz> seb128: here?
<fabbione> mdz: i didn't test on laptop yet
<seb128> mdz: yes
<mdz> fabbione: actually I didn't notice the problem with your kernel
<mdz> fabbione: only the one that I built to test the UB change
<fabbione> mdz: do you want to prepare -2? otherwise i will do it tomorrow and include also the last 2 patches from daniels
<fabbione> ah
<fabbione> HMMMM
<mdz> seb128: I think we talked about this before, but how much work would it be to allow totem and totem-xine to be installed in parallel?
<mdz> fabbione: I am going to try your kernel again as a test
<jdub> mdz: bad idea.
<seb128> mdz: not a lot but I don't like the idea
<mdz> why?
<fabbione> mdz: ok.. please send me a mail with the results if we won't meet when i wake up
<jdub> because totem provides a number of binaries that are not easily selectable
<seb128> because we need to start renaming exe, making an alternative to the default
<seb128> that's making a complicate solution
<seb128> with potential problems
<mdz> we don't need alternatives
<mdz> just rename things which conflict
<jdub> (nautilus property tabs, thumbnailer, etc)
<jdub> mdz: it's very icky
<mdz> the current situation is very icky
<seb128> mdz: gnome will search for known components
* fabbione enjoys the extra noise from the cisco switches
<mdz> no one who actually uses totem regularly uses totem-gstreamer
<seb128> mdz: what's icky with the current situation ?
<jdub> mdz: totem-gstreamer will be greatly improved in the next release
<seb128> so ?
<mdz> and removing it causes ubuntu-desktop to be removed
<jdub> mdz: and trying to do clever parallel install things will onlyc cause more problems
<seb128> I agree with jdub here
<mdz> you guys said that about totem-gstreamer before warty, too :-/
<jdub> yeah
<jdub> and it did improve :)
<seb128> I never said that
<jdub> this time around, there's one person working very solidly on improving it
<seb128> if we don't get gst-ffmpeg people will never be happy with it
<jdub> yeah
<mdz> that doesn't seem like a big problem
<jdub> ffmpeg?
<mdz> it has exactly the same issues as totem-xine
<seb128> jdub: gst-ffmpeg doesn't do compression, should be as fine as xine ...
<seb128> ffmpeg is an another cazse
<seb128> case even
<mdz> it is packaged someplace already, is it not?
<seb128> s/compression/encoding/
<seb128> mdz: I've put it on the pkg-gnome repository on alioth
<Kamion> calc: I'm here extremely briefly, but leaving again straight away; better if you just say what you want and I'll have a look tomorrow
<seb128> mdz: the other solution is to put "totem" in ubuntu-desktop
<seb128> totem is totem-gstreamer | totem-xine
<jdub> seb128: yeah, good point.
<mdz> I thought totem depended on only totem-gstreamer
<jdub> nup
<seb128> mdz: it's totem-xine | totem-gst for debian
<mdz> right
<mdz> I thought we changed that in warty
<seb128> for the same reason, people wants to depend on totem and let people choice which one that is
<mdz> but in hoary at least it is an alternative
<jdub> we reversed it
<mdz> aha
<jdub> i don't mind doing that too much
<jdub> at least it's not explicitly making it an option in the meta package
<calc> Kamion: not sure if you are still here, but i replied to the bug report you mentioned earlier
<jdub> Kamion: ah! i remember the other question i had
<jdub> Kamion: if someone has an existing RAID array
<jdub> Kamion: can that be started and mounted as /home (eg) in the installer?
#ubuntu-devel 2005-12-12
<\sh> daniels: but you agree with "xauth is the cause"?
<daniels> \sh: nope, sounds like the server simply isn't starting to be honest (note how it fails to kill the process -- i assume this is the server)
<daniels> ogra: oh?
<daniels> mvo: sweet
<\sh> daniels: when you check xvfv-run...it wants to create an xauth entry bla...and it failes..check the lines in xvfb-run (where it's failing, from the buildlogs)
<ogra> daniels, i have the same  /usr/lib/xserver/SecurityPolicy prob seb128 has 
<mvo> isn't that cute :) I guess I should report a bug on freedesktops bugzilla? I get "unknown device id, assuming plain r300", maybe that is the cause already
<ogra> daniels, linking it to the right place i dont get this error anymore, but the server still doesnt start ... no errors though 
<seb128> 'night guys, see you tomorrow
<mvo> night seb128 
<daniels> /usr/bin/xvfb-run: line 158: kill: (13770) - No such process
<daniels> lines 157 and 158:
<daniels> # Kill Xvfb now that the command has exited.
<daniels> kill $XVFBPID
<daniels> line 153 is where it actually runs the *command* you ask it to, and that tanks because it raises SIGTRAP
<daniels> that is, glade-2 does
<daniels> and again, line 158 fails
<daniels> so my guess is that the server isn't starting for some reason
<\sh> daniels: the other buildlog has no glade-2 but python :) but as well gtk2 deps I think :)
<daniels> mvo: might want to fake it to some random chipid listed in http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_chipset.h?
<daniels> maybe _chipset.c
<daniels> \sh: right
<\sh> it's somehow confusing..
<daniels> \sh: and notice how it doesn't fail at line 153 there
<daniels> it just says that it couldn't connect to the server
<daniels> and then later it says that it can't kill the server because it's an invalid pid
<daniels> my guess is that the font path is broken in the same way as xnest
<ogra> its running an Xserver during build o_O ?
<daniels> ogra: which server?
<ogra> daniels, trident
<daniels> ogra: yes, this is fucked, but people always do it for some reason
<daniels> ogra: ah, xorg
<ogra> yup
<daniels> ogra: can you please send the full log?
<ogra> eys, but its not really helpful
<ogra> *yes
<\sh> ogra: it's running an X app during build...and it needs somehow xvfb..for whatever strange reason and without some rational...but I don't want to fight with debian upstream
<\sh> daniels: I'll check it tomorrow in a clean dchroot want me to file a bug against xvfb with the results? 
<daniels> \sh: to be honest, not particularly; i'll fix the font path issue today or tomorrow, depending on how progress goes with rc3, so try when the new xorg-server hits
<\sh> daniels: great...
<\sh> s/tomorrow/today in a few hours/ :( I need some sleep
<mjg59> Right, that's the ACPI plumbing done...
<ogra> daniels, 20563 is for you :)
<lifeless> daniels: be sad to see you go, but enjoy uni ;)
<daniels> ogra: the SIGILL is the useful bit ...
<daniels> it should be giving a backtrace though
<daniels> ogra: i assume that using vesa would fix it
<daniels> lifeless: heh, thanks
<ogra> i'll try
<daniels> lifeless: not for a month and a half yet
<lifeless> daniels: well, advance warning then :)
<daniels> yeah
<azeem> daniels: oh, cool
<azeem> what you gonna study?
<daniels> azeem: ?
<daniels> heh
<mjg59> So now I have a kernel that will tell me whenever I plug/unplug the CD drive in this laptop
<daniels> i'm in the middle of a software engineering + arts (indonesian) degree
<ogra> daniels, nope 
<azeem> ah
<daniels> ogra: interesting
<daniels> ogra: if you want to run gdb from another machine and get a bt, that'd be rad
<ogra> wow, you can mix software engeneering with arts ? 
<daniels> two degrees -- engineering and arts
<ogra> daniels, i wont do the gdb session today anymore (its late here and  had much wine already) will follow up on the bug
<daniels> ogra: that's cool, thanks
<ogra> :)
<mvo> daniels: I found (and hopefuly fixed) the dri message, let's see if it helps :) 
* mvo rebuilds mesa
<daniels> mvo: cool
<daniels> mvo: fixed in cvs?
<mvo> no idea, I need to check that
<ryanpg> Hi all... I read the mail from Keybuk on devel-announce, I've experienced some issues with the udev switchover... we're asked to report here?
<mdke> ryanpg, keybuk isn't here right now, I filed a bug on udev, it gets assigned to him. You can try doing that?
<ryanpg> mdke, sure thing... you started a bug? should I add to it? if so do you know the #?
<mdke> ryanpg, only if it is the same problem... mine is about a sata controller for a laptop hard disk
<ryanpg> mdke, ok different issue
<mdke> ryanpg, have a search of bugzilla :)
<ryanpg> yep... mdke I'll be doing that :)
<jdong> elmo: I gotta go end world hunger; if you have anything you need to talk to me about, please don't hesitate to e-mail me
<jdong> have fun everyone
<jdong> or at least get snowflakes unbanned from our school :)
<jbailey> jdong: You can have ours. =)
<ryanpg> ok I made a new bug, any kind soul with time on their hands is encouraged to check bugzilla.ubuntu.com #20564 for "goodness", it's my first ubuntu bug :D
<jdong> jbailey: thanks... and i also need bells, gifts, horseshoes, snowflakes, snowmen, crosses, giving tree, bunny, turkeys unbanned too :)
<jbailey> I'm all up until the last two.
<jbailey> And then it depends if you're planning on eating them or not. =)
<jdong> jbailey: the bunny?
<jbailey> or the turkey. =)
<jdong> lol, have fun guys
<ryanpg> aww crap... dapper bugs should go to "malone"?
<Burgwork> ryanpg, universe bugs go to malone
<EdLin> The Ubuntu bugzilla website is acting non-functional when I try to enter a new bug report.
<ryanpg> Burgwork, ok so my udev bug is correctly placed in bugzilla.ubuntu
<ogra> yup
<EdLin> ogra, is that "yup" directed at me?
<ogra> EdLin, nope at ryanpg 
<EdLin> I've got the bug report exported to a file, but don't have a mail server operating, is it possible to mail the information somewhere with evol?
<ryanpg> EdLin, I just entered a bug there a few minutes ago btw
<EdLin> ryanpg, OK. I just noticed that the bug report program's exported text file contains an email address (at gnome.org) that I can use, I'll use that - especially since it would probably be marked "upstream" anyway.
<seth_k|lappy> who staff
<seth_k|lappy> blast
<seth_k|lappy> sorry, forgot my slash
* ryanpg resists urge to make a joke about axel rose
<ryanpg> thanks for the help all... I'm off
<lathiat> Aavahi 3
<maswan> Nafallo_away: pong
<wasabi> jbailey: initramfs evms stuff is busted.
<wasabi> again. heh.
<jbailey> wasabi: How this time?
<jbailey> infinity: ^^^
<wasabi> Not sure, was at work, had to fix it and get back to work hehe.
<wasabi> Looked like the md local-top script wasn't detecting my md.
<wasabi> Again.
<wasabi> (and since evms isn't going to do it, it never got done)
<jbailey> If you can record what you did to get it running and fire that into bugzilla that'd be lovely.
<wasabi> =)
<xhaker> there is a regression on laptop-mode-tools i think... hibernation is spawned when i reduce the LCD brightness of my Acer laptop
<wasabi> Well, what I did was slam modprobe raid1 and force_load raid1 into it.
<wasabi> So I might GUESS that those were missing. ;0
<jbailey> I don't really hack on initramfs-tools much now, it's mostly adam and scott.
<wasabi> Ahhh.
<jbailey> I can still help with it, since I'm quite familiar with the code, but I'm headed to bed shortly. =)
<jbailey> I'm quite tired.
<wasabi> s'ok, I'll take a look at it again
<jbailey> (I think I'm fighting something.  Hopefully sleep will keep it away)
<wasabi> uh oh
<desrt> is dapper version frozen?
<infinity> ...?
<infinity> Oh, you mean have we hit upstream version freeze?  No.
<desrt> is it in UVF yet
<desrt> excellent.
<infinity> https://wiki.ubuntu.com/DapperReleaseSchedule
<desrt> thanks.
<YokoZar> Am I allowed to promote my own spec from braindump to drafting?  I think it's ready to be reviewed: https://wiki.ubuntu.com/UsefulDisksManagerSpec
<ajmitch> if it's ready for reviewing, set it as pending review
<ajmitch> you are doing this in launchpad, right?
* ajmitch doesn't know who would be reviewing & approving specs outside of meetings like UBZ
<ajmitch> YokoZar: I'd say it'd need the implementation section filled in a bit before it got reviewed
<YokoZar> ajmitch it's linked in launchpad, yes
<YokoZar> Isn't the implementation section for...stuff that's done?
<DsM> anyone know how to sign up to be a mirror for ubuntu?
<ajmitch> YokoZar: no, implementation is for how you're going to do it
<YokoZar> What if I don't know, since I have no idea how the disks manager applet is configured?
<YokoZar> Err, coded.
<ajmitch> not sure what you'll want to fill in , sorry :)
<YokoZar> I'll put it up to drafting and ask for review, heh
<YokoZar> While we're on the subject, what do you think of this: https://wiki.ubuntu.com/BetterIntegratedWineSpec
<ajmitch> you might wait awhile for review
<ajmitch> you'd need to fill out implementation there as well, saying how you'd do it
<YokoZar> Indeed.  This is what I get for not thinking of the idea before you all ran off into the snow-filled wastes of Canada
<ajmitch> :)
<YokoZar> ajmitch: that part I actually can do, heh
<ajmitch> there wasn't any snow around, sadly
<YokoZar> (for Wine)
<ajmitch> I'd like to see some menu integration there, but as you said, it's likely for dapper+1
<YokoZar> I think the fonts idea can be done in time, though
<ajmitch> at least winetools appears to have gone from dapper
<ajmitch> or was it that winesetup that needed removed?
<YokoZar> ajmitch: winesetuptk and xwine needed to be killed
<YokoZar> ajmitch: as soon as I get my key signed and upload rights they'll probably get removed since they'll conflict with their dependency, heh
<ajmitch> or you could get someone to put in the conflicts now
<ajmitch> I know that winesetuptk is quite obsolete with the config changes now
<LaserJock> is there a reason why there are no Contents-*.gz for dapper on a.you.c?
<LaserJock> kamion| mdz| lamont| infinity| elmo: ping? ^^
<psusi> I did an update of dapper today and x won't start now because it can't find my usb mouse... the kernel seems to see it but the devnode isn't being created... isn't there some major overhaul going on of the plug and play stuff?
<daniels> udev
<daniels> 'Dapper has new kernels and new world order, upgrading for the adventurous only (and those with another machine to use)'
<daniels> from the topic
<psusi> what about it?  I still don't understand devices.. it used to be you just used mknod to make the dev nodes you need... then there was something about a devfs... now udev... hotplug... I can't figure it all out
<elmo> psusi: then you probably shouldn't be messing with dapper at the moment
<TerminX> speaking of udev, where do I put stuff now that previously went in udev.rules?  tried adding custom rules to stuff in rules.d but had no luck
* psusi has breezy on another partition and a tarball of an earlier working dapper
<TerminX> had to go get the udev package from sid because the one in dapper won't do a thing for me now (such as create mouse device nodes)
<psusi> so... udev was a deamon that handled creating the devnodes for detected devices... and dapper is dropping it for something else?
<daniels> psusi: this probably isn't the forum for explaining udev, I'm afriad ...
<psusi> what would be?
<LaserJock> elmo: is there a reason why there are no Contents-*.gz for dapper on a.you.c?
<whiprush> just blame daniels for everything. :p
<psusi> lol
<elmo> LaserJock: it's expensive to run, and I haven't gotten round to setting it up for dapper yet
<psusi> actually... it's kind of nice not having X working... I got too used to it... it's nice being back in a console running bitchx with a custom console font
<LaserJock> elmo: oh, ok. no problem. I was trying to run apt-file but it uses the Contents-*.gz files so I couldn't use it on dapper. I just used breezy instead
<infinity> I must be suffering a case of mechanic's syndrome, cause USB mice work fine for me.
<psusi> infinity did you update today?
<infinity> psusi : Not yet.  Did it just break today?
<TerminX> no, not today
<TerminX> the latest udev is 5 days old
<psusi> the other day I noticed that the mouse broke when I tried to use my old kernel isntead of the new one in dapper.. custom 2.6.14... but it worked fine with the 2.6.15 that dapper finally got
<psusi> but today I updated and it broke using the new kernel
<infinity> Oh, well, yes.  I do use the dapper kernel. :)
<psusi> there was a new kernel today
<infinity> I know.
<infinity> Rebooting to it in a few minutes.
<psusi> so where can I read up some more on the changes to udev in dapper?
<infinity> ubuntu-devel-announce
<infinity> Which you should subscribe to if you're using dapper.
<psusi> I'm substrubed to ubuntu-devel... isn't the announce redundant then?
<whiprush> check out dapper-changes as well.
<daniels> Kamion: are you still planning to do flight 2 tomorrow?
<infinity> psusi : No, announce isn't redundant.
<psusi> hrm... ok... I'll subscribe to those too then
<infinity> In this case, though, reading changelogs before installing, I'll lay my blame with the new udev.
<infinity> 0.77's changelog looks... Interesting.
<psusi> hrm... that's another thing I've noticed lately... changelogs don't work or are not being made
<psusi> even in breezy
<infinity> Install apt-listchanges.
<psusi> I have a server at work running breezy and I noticed today it had a few new packages... apache and whatnot
<infinity> The changelog-grabbing feature in update-notifier is a bit delayed.
<psusi> I chose the option in synaptic to get the changelog and it said it failed to fetch it
<infinity> (ie: stuff doesn't get to changelogs.ubuntu.com for a while after the packages hit the archive)
<psusi> that's what I figured...
<psusi> why's it take so long?
<infinity> You have a server running X? :)
<psusi> yea... got it running tightvnc server started from xinit too, so it's like a terminal server
<psusi> it's prety neat
<psusi> I mean xinetd
* infinity grumbles at ogra's kino upload.
<infinity> ogra : Your kino package overwrites files from kino-dvtitler.
<ajmitch> he knows
<infinity> Oh, good.
* ajmitch harassed him earlier about it
* infinity reboots with the new kernel...
<elmo> infinity: umm, I thought you fixed our buildd-watcher?
<elmo> infinity: weddell is being bad anyways
<fabbione> morning
<ajmitch> hi fabbione 
<Orborde> How do I determine what arch a package installed on my system is from?
<Orborde> s/arch/repo/
<desrt> uname -m
<desrt> look in /var/lib/dpkg/status
<desrt> eek.  then cross-reference the version against what's in each repo, i guess
<Orborde> Arg
<crimsun> Orborde: apt-cache policy foo
<fabbione> hmmm
<fabbione> desrt: i am so sleepy that for a second i thought you were clueful :P
<Orborde> crimsun: Thanks
<desrt> fabbione; die.  my first answer was a good one :p
<fabbione> hahaha
<desrt> it's a good question though... why doesn't source distribution end up in dpkg status
<desrt> i guess because it's not known at package build time?
<fabbione> the dpkg status doesn't need these info
<fabbione> you are looking in the wrong place
<desrt> so that answer to "How do I determine what arch a package installed on my system is from?" is actually "you don't."
<fabbione> i am not even sure i understand the question
<desrt> since, for example, in dapper and breezy right now, a -lot- of packages have exactly the same version
<fabbione> you can't mix i386 and amd64 .deb on a system
<crimsun> I think he means repo instead of arch
<desrt> 00:33 <Orborde> s/arch/repo/
<fabbione> oh sure.. one sec...
<fabbione> i was just looking at something like this yesterday
<Orborde> fabbione: crimsun answered it already :)
<fabbione> Orborde: that's the lazy way :)
<desrt> Orborde; but does that tell you the installed one or if you were to install it now?
<crimsun> Orborde: that really only works if you have one set of repos, too
<fabbione> desrt: installed one i am pretty sure
<desrt> apt-cache?!
<desrt> hmm
<fabbione> ok i will cast my right to answer after the coffee
<Orborde> Argh. I dun wanna sign up for launchpad :(
<Orborde> I have an Xfce4-related bug, but xfce4 is universe and thus out of the Bugzilla
<crimsun> https://launchpad.net/malone
<fabbione> Orborde: launchpad is fun :)
<Orborde> It wants me to register.
<infinity> elmo : I think I saw something shinier and got distracted.
<ajmitch> registration isn't painful
* infinity sits around waiting for keybul to wake up, so he can give him what-for in regards to udevplug
<infinity> keybuk, too.
<dilinger> what's a whatfor?
<Tm_T> what for
<Tm_T> ;)
<Tm_T> anyway, dunno is it init.d/networking script or something else but my network connection doesn't come up(or if does, it comes down too) at startup
<Tm_T> oh, dapper is humorous sometimes =)
<infinity> elmo : Okay, buildd-watcher fixed.
<crimsun> elmo: please sync xerces25 and xerces26 from Sid (ok to override Ubuntu changes), thanks
<zakame> elmo: please sync ickle from sid, ok to override Ubuntu changes, thanks :)
<HiddenWolf> Is some part of apache part of the default install?
<crimsun> elmo: please sync scim from Sid (ok to override Ubuntu changes), thanks
<dholbach> good morning ubuntites :)
<whiprush> dholbach: hey ubuntero. :)
<dholbach> hey whiprush! :)
* dholbach hugs whiprush 
<dholbach> long time no se
<dholbach> see
<whiprush> heh
<dholbach> whiprush: how are you?
<whiprush> dholbach: busy at work. 
<dholbach> i can imagine
<dholbach> but you always found time to fridge :)
* dholbach hugs whiprush 
<whiprush> lots of ubuntu deployment stuff actually.
<dholbach> COOL! :)
<whiprush> well, wrestling with gconf isn't what I'd consider "cool", but it's working out.
<whiprush> but hey, life on the edge I suppose.
<dholbach> :_D
<dholbach> :-D
<whiprush> keep rocking that tango package man, it's sweet.
<dholbach> really? i think it got a bit too blue-ish  for my nerves
<whiprush> dholbach: one of the novell guys in #tango mentioned that they would keep the gray icons for NLD.
<whiprush> I'd like to see a ubuntuized set in the tango style for the folders personally.
<dholbach> whiprush: if we'd get our artwork team to work on that, i'd be happy
<whiprush> is andy fitz still around?
<dholbach> AndyFitz: ping :)
<whiprush> heh.
<AndyFitz> dholbach: pong
<dholbach> whiprush: he is :)
<dholbach> AndyFitz: whiprush would liked to see a ubuntuized set of tango icons - what do you think about that?
<whiprush> hey so dude, Tango-human?
<sivang> morning all!
<AndyFitz> dholbach, whiprush.  I'm already on it.  checkout the svg files at http://www.brisgeek.com/file/sample.tar.bz2
<whiprush> AndyFitz: you rock.
<AndyFitz> I'll be releasing the full set at LCA along with instructions on how to modify the global stylesheet ;-)
<AndyFitz> all using the tango metaphors and naming spec
<dholbach> page not found
<AndyFitz> imagine toggling drop shadows, outlines shifting the opacity of 'shiny' gloss effects and total palette changes ;-)
<AndyFitz> http://www.brisgeek.com/files/sample.tar.bz2
<AndyFitz> oops
<AndyFitz> hacking on a drupal install at the moment
<AndyFitz> the tango naming spec and the metaphors list to keep things familiar for all users is awesome work
<dholbach> yeah, that's great
<HiddenWolf> Will that be the new look for dapper? :)
<infinity> AndyFitz : I still don't dig that chat icon, BTW... The speech bubble (when shrunk down small) looks like a tooth.  Looks like something I'd see at a dentist's office.
<infinity> AndyFitz : Not entirely sure how a happy face relates to chatting either. :)
<AndyFitz> well mate, you just sent me one
<HiddenWolf> infinity, you dug yourself in there ;)
<infinity> (I don't use graphical emoticons, so they don't register with me as "relating to chatting")
<AndyFitz> I'm following the metaphors on the tango site. so nothings 'all my fault ;-)'  whats funky about those is in the xml
<infinity> It's like saying the "uh oh" sound relates to chatting, because we all used ICQ 8 years ago.
<HiddenWolf> Now _THAT_ was annoying.
<AndyFitz> rsvg and inkscape don't support external stylesheets .  btu the inline styles are easily  sed/awked out of there and replaced with consolidated classes when they both do support it .   we are talking <10kb icons
<AndyFitz> infinity, stop being emo.  smiling is chatting. if its not use a different icon..  like the logout one
<AndyFitz> hehe
<infinity> Thpt. :)
<infinity> The speech bubble is chatting, no arguments there.
<infinity> (Though obscured by the smiley, it turns into a tooth, I SWEAR TO GOD)
<AndyFitz>  I don't see that.  even so :  _tooth_ is  in the _mouth_  which is what you can  _talk with instatly_ 
* infinity laughs.
* dholbach collects the crack pipes in the channel
* HiddenWolf mugs dholbach 
* AndyFitz puts away his crack
* HiddenWolf hides his dope
<ajmitch> elmo: please sync spplus, slides from debian, dropping changes
<mahangu_> any LoTR fans here?
<\sh> hehe this morning on heise.de
<\sh> "German Stock Exchange removes Elmos from TecDax List"
<seb128> morning
* seb128 kicks udev
<infinity> I've already kicked it enough for both of us.
<seb128> thanks ;)
<infinity> What's your udev issue? :)
<Tm_T> uh
<seb128> infinity: eth not bringed up at boot, which is not an issue, and xorg refusing to start because no mouse which bother me actually, I had to downgrade udev
<infinity> Oh, you're another "no mouse" guy.  Neat.  I wonder why my mouse works...
<infinity> My complaint it with my hard drive being randomly renamed, but I've tracked that bug.  I just need to yell at Scott about it when he gets online.
<seb128_> re
<Tm_T> seb128_: my eth isn't bringed up at boot either
<seb128_> this one is a known issue IIRC
<Tm_T> good
<Tm_T> then I'm not worried
<minghua> infinity: now you have yet another "no mouse" guy here :-)
<doko> seb128_: strange panel behaviour: the Applications menu doesn't stay open, it just blinks and then minimizes to a small point, the other menus do work. any hints?
<mvo> doko: knonwn issue
<mvo> it's a gamin bug apparently 
* sivang wonders how despite all of his upgrades to his work machine that was installed from a dapper flight 1, does not see any gamin bugs, but on his home machine which was dist-upgraded from breezy, it does show.
* MindOfChaos wonders if he will ever get the energy to try and get his LAN going in linux
<seb128_> doko: yeah, known issue, I've forwarded it upstream but they are not really responsive
<seb128_> doko: I don't have the issue on my box to debug it ...
<hunger> siretart: Yes.
<\sh> upgrading to dapper again :)
<Diziet> otu
<Diziet> Oops.
<dholbach> you surely mean Motu :)
<Diziet> That's what I was searching for in scrollback :-).
<Diziet> Launchpad has sent us this silly mail and I was wondering if anyone had grumbled and suggested it should send it to a smaller group of people.
<dholbach> Diziet: i grumbled already
<dholbach> but in #ubuntu-motu
<Diziet> What did they say ?
<dholbach> we agreed on not making ubuntu-dev or ubuntu-core-dev administrators, which would solve the problem
<dholbach> (but keep the team model intact)
<Diziet> Mmhmm.
<Kamion> they aren't administrators now; I assume that was fixed by the time I went to look at it earlier this morning
<siretart> hi
* mvo reboots for new kernel
<dholbach> siretart is the motureviewers team architect :)
<siretart> ah
<siretart> Diziet: Kamion I removed ubuntu-dev from administrator status of motureviewers now. Now the team MOTU is admin of motureviewers and should therefore get all the spam
<siretart> this was done just a few hours ago, just after dholbach notified me about that spamming
* siretart hopes this is okay and everyone is happy
<Kamion> siretart: that's fine, thanks
<ogra> yippie, only pmi and acpi-support left as uninstallables on the CD :)
<sladen> wifi/sound aren't loaded atm
<Kamion> ogra: those should be fixed RSN; I did a couple of promotions this morning
<ogra> sladen, hmm, i'm not at the -7 kernel yet but it works here since -5
* ogra sees a livefs at the horizon :)
<Kamion> the most recent build failed because language-support-en was uninstallable for some reason
<ogra> meh
<Keybuk> wasn't that a firefoxism?
<Kamion> I was just saying that to infinity, yes
<Kamion> please somebody update mozilla-firefox-locale-all
<Kamion> it should be relatively straightforward; the source is basically just a pile of XPIs you can download
<Kamion> you'd need to test it in various locales
<infinity> Testing, schmesting.  It can't get any more broken than it currently is. :P
* infinity looks into this.
<sladen> mozilla-firefox-en-gb still needs to be uninstalled to do an update
<ogra> infinity, are you an active kino user ? 
<infinity> ogra : Not frequent, no.  Just enough to notice that it was broken.
<ogra> hmmkay
<ogra> but you could test it  ? i'm missing the right HW here ...
<infinity> Define "test".. I can test the video editing bits, I can't do any DV.
<ogra> would be enough for now ... i'm hoping anyway that debian updates to 0.8.0 before UVF .... 0.7 doesnt run with newer gtk versions and i had to close the merge bug ...
<infinity> Oh great, there's no m-f-l-a package in experimental yet.
<infinity> ogra : Kay, bug me tomorrow when I'm not on a livefs warpath.
<ogra> yup
<ogra> will fix the package first
<zyga> hello
<zyga> ogra: is that hwdb-client branch ready? :)
<ogra> zyga, i'll make it ready after the edubuntu meeting today 
<zyga> ogra: thanks :-)
<zyga> I'm finally done withmy RL jobs and I've got some more time to spend 
<MindOfChaos> Hello
* infinity wonders why m-f-l-a only includes the lang-COUNTRY.xpi langpacks, and not all the lang.xpi ones.
<infinity> I'll ont question it for this update though, I'll let pitti deal with it later.
<pitti> infinity: you mean the source package is missing some xpis?
<seb128> hey pitti, you should not be working today :p
<pitti> seb128: I'm not :)
<seb128> good ;)
<seb128> doing distro meeting this night?
<pitti> I'm searchign for xmas presents *sigh*
<pitti> (working is soo much easier...)
<seb128> ah ah :)
<pitti> seb128: yes, sure, I'll set my alarm clock and annoy my gf :)
<seb128> he he
<ogra> pitti, could you prioritize the gnome-screensaver main inclusion report ? mdz wants it on flight 2
* Kamion hacks choose-mirror evilly, hopefully avoiding the mirror question on dapper CD installs
<fabbione> Kamion: it would be nice if we can also kill the apt-setup mirror quesion on netinstall
<Kamion> fabbione: already dead
<fabbione> great!
<Kamion> apt-setup has been reimplemented and now just uses choose-mirror's data
<slomo_> elmo: please delete the mplayer i uploaded a few minutes ago... it should go to revu instead :( sorry for the problems...
<fabbione> slomo_: if it has been accepted, you can't delete it
<siretart> no problem
<siretart> we can also fix it in universe ;)
<slomo_> fabbione: ok, np... then we have to repair it there ;)
<fabbione> *cough*multiverse*cough*
<siretart> excatly
<siretart> the only problem is that the resulting mplayer binary package depends on a completly NEW package, 'mplayer-skins', which I just uploaded
<Kamion> dholbach: shouldn't bakery2.3 be -15c2a rather than -15a? normal practice seems to be to use c2a even if it wasn't c2 before
<Kamion> also makes for easier greppability
<siretart> who processes the NEW queue?
<dholbach> Kamion: hmmm, i thought i read "add 'a'" somewhere
<Kamion> siretart: generally elmo
<Kamion> dholbach: ah, check with doko then
<siretart> ok
<siretart> thanks
<Kamion> siretart: mdz and I *can* do so but generally don't
<dholbach> Kamion: i have no doubt that the soname will change soon again :)
<dholbach> then i'll be able to remove the "a" :)
<siretart> Kamion: its not that important. it is just mplayer in multiverse not being installable in dapper
<siretart> without mplayer-skins I just uploaded
<Kamion> siretart: it's only been there for 10 minutes; be patient, the queue is rarely very long
<Kamion> (the oldest thing in the queue is 1 hour)
<siretart> oh. sounds great :)
<sivang> I am wondering, is that fact that I need to install portmap on a mchine in order to NFS mount a specific partitoin on antoher mahcine, an issue? Could this be made easier for the user to manage?
<doko> dholbach, Kamion: maybe just reject, and sync from incoming
<dholbach> doko: no, we have a newer version
<Keybuk> hmm, why are some manpages executable?
<Kamion> bug
<Keybuk> they shouldn't be, then?
<Kamion> I can't think of a good reason for a man page to ever be executable
<Kamion> usually it's that somebody used 'install', which defaults to executable
<Kamion> and didn't use dh_fixperms or similar
<Keybuk> I. Hate. Dpatch.
<sivang> hmm ,and also install nfs-client
<pitti> Keybuk++
<Keybuk> and do you know what I hate more than dpatch?
<Keybuk> people who use dpatch to patch debian/*
<ogra> eeek ...
<Keybuk> deliberately
<fabbione> you joking?
<Keybuk> nope
<fabbione> what pkg is that?
<Keybuk> this is why it's taken me a week so far to merge sysvinit
<fabbione> ah
<Keybuk> you know how Debian maintainers bitched at us for changing their packages to dpatch?
<Keybuk> I wonder whether we could bitch back about them changing packages to dpatch :p
<fabbione> ahah
<\sh> Keybuk: well...changing packages to dpatch is one...but generating libfoo.so.<major>.<minor> via automake from debian/changelog is much more weired
<pitti> \sh: from changelog? that's interesting :)
<Keybuk> \sh: generating libfoo.so.<major>.<minor> is a shooting offense
<Keybuk> seriously
<Keybuk> point me at them, and I'll break their arms
<Keybuk> and then teach them lovingly about why SONAMEs matter while they're in hospital recovering
<\sh> pitti: I had a package, it had selfmade m4 rules which checked debian/changelog version and took it to cr
<\sh> eate the so.version
<pitti> \sh: boggle
<\sh> and working with an ubuntu version == no way
<Keybuk> whoah
<Keybuk> even better
<Keybuk> this patch patches debian/rules
<\sh> I had to friggle around this shit
<Kamion> Keybuk: how does it work at all?
<\sh> time for motu school...I tell ya
<Kamion> I guess it must be patching something in a later target
<Keybuk> Kamion: it's not listed in 00list, thankfully
<Keybuk> so I think it must be just a "I need a revision control system" patch
<crimsun> seb128: ping 
<\sh> send jblack to him :) 
<Keybuk> right
<Keybuk> that's better
<seb128> crimsun: pong
<Keybuk> I'm gonna pop out and get some lunch shopping, back in 1h30 or so
<crimsun> seb128: Hi, do you plan to do the libstdc++ allocator transition for verbiste in Sid anytime soon? If not, I'll go ahead and do it in Dapper/universe, but I don't want to duplicate your efforts.
<seb128> crimsun: there is no transition to do, just a rebuild, right?
<crimsun> seb128: needs a new lib name, though
<seb128> oh, crap
<seb128> nothing use it
<seb128> it has no rdepends out of verbiste itself
<seb128> I'll not change the package name :)
<crimsun> hmm, ok.
* ogra remembers having the same conversation with seb128 in breezy :)
<crimsun> hmm, I wonder what it's doing on http://lists.ubuntu.com/archives/ubuntu-devel-announce/2005-November/000016.html
<seb128> crimsun: ?
<seb128> crimsun: this list is probably autogenerated of stuff that need to be transitionned
<seb128> crimsun: I just say since this one has no rdepends that doesn't seem to be useful to rename it
<\sh> seb128: do you actually if debian maintainer will do this transition? we will have another difference then from debian...
<\sh> insert "know" between actually and if
<Kamion> \sh: seb is the Debian maintainer
<crimsun> that's why I asked seb ;)
<\sh> Kamion: that's why I asked him as well :)
<Kamion> Debian has been pretty consistent about renaming even if there are no rdepends, to avoid breaking local users
<seb128> you ask me if as a Debian maintainer I'll do it differently from Ubuntu?
<Kamion> but I'm not sure I can be bothered having the argument :-)
<\sh> seb128: see kamions remark :)
<seb128> Kamion: I don't really care either way, just seems to be useless change to me :)
<Kamion> I imagine you can expect a Debian bug from one of the release team if you don't, so you could regard it as avoiding that ;)
<\sh> seb128: let crimsun do it, he will send your the debdiff..so you don't have any work with it...:)
<ogra> he will have the work i debian ...
<ogra> *in
<seb128> Kamion: I didn't get one for the other transitions :p But right, patches are welcome if a MOTU wants to do the job and send one :)
<\sh> ogra: well...crimsun can create a real deb version package as well...and seb128 can sponsor :)
<crimsun> seb128: ok. I just wanted to check with you since I didn't know if you had it queued.
* mvo goes for lunch
<seb128> crimsun: no, I'm quite busy with other stuff atm
<seb128> crimsun: your patch is welcome :)
<crimsun> seb128: ok
* ogra grumbles about crossposts ...
* ogra resends the anwer to the right list...
<Diziet> I wish people would stop uploading stuff.  My mirror is still running (since 2am this morning).
<Treenaks> Diziet: get a faster link  :)
<Diziet> I did !
<Diziet> Just a week or two before Dapper opened.
* Kamion solves this problem by not mirroring universe locally
<ogra> Diziet, main will see a "pre flight 2 freeze" soon i guess, so you'll have time to catch up :)
<dholbach> a11y meeting, if you're interested, in #ubuntu-meeting
<jsgotangco> yay
<slomo_> elmo: please sync swt-motif, skippy, most, libofx2 from debian/unstable... ubuntu changes can be dropped
<sivang> pitti: wow, g-c-a takes ages to load, known?
<Diziet> Damn, where did I put my python manual printouts ?
<Riddell> infinity: could you give back gwenview please
<infinity> Riddell : I'll make you a deal.  I'll give it back when you upload a bunch of kde* that doesn't FTBFS. :P
<infinity> (given back)
<Riddell> infinity: hmm, kdeartwork and kdeutils have their problems but kdeaddons, kdesdk, kdeutils (then when kdesdk is done kdevelop3 and kdewebdev) could all benefit from being given back
<infinity> Riddell :   libkipi0-dev: Depends: libkipi0 (= 0.1.2-2ubuntu2) but it is not installable
<infinity> Riddell : (gwenview failure)
<Nafallo> infinity: hi! do you understand what goes wrong with linuxdcpp?
<infinity> Nafallo : <shrug>... Look at the configure script and see how it's testing for pkg-config, dude.  I'm not any more psychic than you. :)
<Nafallo> infinity: you're not?! :-O. well, it builds in my pbuilder ;-)
<kaushik> hey Can anyone please tell me how to get a shell with admin priviliges in UBUNTU
<azeem> kaushik: please ask in #ubuntu
<kaushik> Hey dude please help me... just I want a shell
<kaushik> and that su is not allowed
<Nafallo> sudo -s
<Nafallo> and that's a question for #ubuntu, as already said
<kaushik> Thanks..
<kaushik> Got it and sorry...
<kaushik> for asking silly questions
<infinity> Nafallo : You realise that if you make me look into this and it turns out to be something trivial, you'll have to send me gifts, right?
<HiddenWolf> kaushik, wiki.ubuntu.com/RootSudo
<Nafallo> infinity: hehe, hold on. I'm already looking ;-)
<sbalneav_> Mithrand1r: Tollef, is that you?
<infinity> Nafallo : Oh, crap.  It could be scons.  Anything with scons in the build-deps scares me.
<Nafallo> infinity: it is scons :-P
* Nafallo goes to learn something new and evil ;-)
<infinity> Nafallo : If it's scons failing, it might be something you can't easily fix, and is best worked around on our end.
* infinity curses scons.
<Nafallo> oki
<Nafallo> oh. it tries to run pkg-config --version and doesn't exit with 0 it seems.
<infinity> Oh, it's not scons involved at all at that point?
<Nafallo> SConstruct, so yes. it scons :-)
* Nafallo runs it with debug=1 :-)
* dilinger hands jbailey a cookie
* jbailey sniffs the cookie. 
<jbailey> dilinger: Is it vegan?
<jbailey> And generally not laced with cyanide? =)
<dilinger> jbailey: initramfs-tools drops you into a shell if root cannot be mounted.  that is the best thing since sliced Xu.
<jbailey> Sliced Xu does *not* make for vegan cookies. =0
<infinity> Of course, that fact that everyone's discovering this feature due to all the missing roots recently is NOT such a good thing.
<azeem> new features should be easily discoverable
<dilinger> infinity: oh, i'm using qemu and hacking on a distribution
<dilinger> infinity: i didn't expect this thing to find root
<Keybuk> I thought of a way to do it right
<Keybuk> ...why are we loading ide-generic for a scsi device?
<Keybuk> why not just not load it if the root device name begins with "s" :p
<infinity> That's sick.
<infinity> But okay!
<infinity> It'll fix my bug, screw everyone else!
<jbailey> Keybuk: Well,  it's not  like it would be the only place where I employed that logic.
<Keybuk> well, I really can't think of a way around it
<jbailey> See the md, lvm and evms hooks. =)
<Keybuk> the problem is that the scsi subsystem takes ages to wake up
<Keybuk> (I know how it feels, some days)
<Nafallo> infinity: feel free to work on linuxdcpp. pkg-config is found by my pbuilder :-P.
<Keybuk> and if we wait 20s before loading ide-generic, that still might not be enough
<infinity> Nafallo : yes, I know what the bug is.  Well, I know what the bug LOOKS like, I don't actually know what it IS.
<Nafallo> scons? :-P
<infinity> Well.  It's a fight between scons, ccache, and a hideous hack we employ only on the buildds, which is why you can't reproduce it.
<Nafallo> must be the hideous hack then. I use ccache in my pbuilders aswell :-)
<\sh> 64bit power now
<\sh> and never buy a benq dvd dual-layer writer, which reads our shipit cds with fully 48x speed...and stops at e2fsprogs udeb
<\sh> I tried now 20 amd64 cd sets..all the same...now I have an old sun blade 1000 24x times cdrom installed...and it workds
<\sh> works even
<elmo> Kamion: have you had any further thoughts/cunning plans WRT the task fuckage in breezy?
<pitti> sivang: yes, I noticed; dunno why
* sivang searches for a bug report
<Riddell> infinity: any idea why libkipi0 might not be installable?  installs fine in a fresh dapper chroot for me
<elmo> siretart: ?
<siretart> elmo: yes?
<elmo> siretart: mplayer-skins says artistic license, but nothign in the source package says that, unless I'm missing it?
<sivang> dholbach: did you discuss a11y stuff that required addition/modification of the test plans?
<Kamion> elmo: not really, unfortunately
<Kamion> elmo: I've fixed the base-config issue that made it break, and have pending commits to debian-cd to
<siretart> elmo: its inside the tar.bz2 package in the orig.tar.gz
<Kamion> o
<Amaranth> seb128: What exactly are you trying to say is wrong on http://bugzilla.gnome.org/show_bug.cgi?id=323476 ?
<Kamion> but I think we may just have to revert and suck down the lack of working kubuntu/edubuntu netboot :-/
<Kamion> maybe soyuz can deliberately emulate the breakage if they really want to regenerate the indices
<siretart> elmo: I included only a selected number of skins in the package, and most of them do not particulary claim any copyright
<elmo> Kamion: ok
<elmo> siretart: I extracted those - couldn't find it?
<siretart> elmo: I downloaded them from here: http://www.mplayerhq.hu/homepage/design7/dload.html
<infinity> Riddell : universe.
<siretart> elmo: most of them dont have any claim about any licence, just the author who took them
<siretart> elmo: do I really need to ping each contributor or is this fine for multiverse?
<Riddell> infinity: aaah.  yes
<elmo> siretart: stuff without a license isn't distributable legally
<Riddell> Kamion: could you promote libkipi0/libkipi0-dev and libkexif1/libkexif1-dev, renames of c2 libraries
<elmo> siretart: so, yes, sorry to be a fascist, but we need a license for these skins
<siretart> elmo: I see. will look for other skins (with licence) then
<sivang> pitti: I've opene a bug about that, feel free to add your reproduction there and see if it takes the same amount of time for you.
<seb128> Amaranth: I'm not sure if gnome-menus should list NoDisplay=true entries ...
<siretart> elmo: the problem is, that none of these skin tarballs contain a proper licence statment. is it okay to assume the licence stated on freshmeat is correct?
<seb128> Amaranth: the menus should, but gmenu_tree_directory_get_contents ()?
<crimsun> Keybuk: I'm getting darned good at running those commands up through ''mountroot'' ;)
<seb128> Amaranth: it has the effect that gmenu-simple-editor can't unhide what you mask with alacarte :p
<seb128> Amaranth: I guess that you don't have the issue because you use pyxdg and not gnome-menus for it
<infinity> Nafallo : Can you mail me a reminder about that package, so I remember to fix the chroots tomorrow and retry it?... I'm too busy right now to fix it up.
<elmo> siretart: ugh, if they were added to freshmeat by the upstream skin author/artist, then maybe?
<Amaranth> seb128: that's ok, alacarte can't unhie what you mask with gmenu-simple-editor
<siretart> elmo: for example: http://themes.freshmeat.net/projects/xfce4_mplayer/
<Amaranth> seb128: pyxdg appearently treats <Exclude> as "does not exist"
<siretart> claims to be gpl
<Kamion> siretart: safest way by far is to e-mail the author and as
<Kamion> ask
<Nafallo> infinity: oki
<siretart> Kamion: will do
<Keybuk> crimsun: heh, you mean you haven't got as far as building custom initramfs with them already seeded into the busybox shell's history? :p
<seb128> Amaranth: GNOME upstream seems to think that "Exclude" should be the way to work for a menu editor
<crimsun> Keybuk :p
<Amaranth> seb128: If lanius ever gets his new key uploaded to fd.o I'll see if he can make them show up in getEntries() again
<Kamion> Keybuk: if you say you have, I'm scared
<seb128> Amaranth: you can roll tarball to an another place you know? :)
<Amaranth> seb128: I know he has some code in there to make unhiding stuff also remove any <Exclude> tags
<Kamion> Riddell: done libkipi0, libkexif1 requires a cron.sync run first
<Amaranth> seb128: I don't even have a computer at home right now.
<Amaranth> seb128: And when I do I don't have internet access on linux to work on things.
<seb128> Amaranth: speaking for lanius, not you, he's upstream no?
<Amaranth> seb128: I haven't actually seen him in awhile...
<pitti> Diziet: here?
<Amaranth> seb128: Yeah, he is upstream but the design of the code is basically "whatever alacarte needs" so I do some patching. :)
<Keybuk> Kamion: then I won't say I have
<Diziet> pitti: Hello.
<pitti> Diziet: hi! do you know what happened to update-mozilla-firefox-chrome?
<Diziet> It's abolished.
<Diziet> AFAICT.
<pitti> Diziet: I'm currently updating m-f-locale-all to 1.5
<pitti> hmm
<Diziet> So you should just remove the references to it.
<pitti> firefox complains about a chrome error when I just install it
<Diziet> Harmf.
<Diziet> Maybe the chrome you're installing is wrong ?
<pitti> Diziet: no idea, I'll check it now
<pitti> chrome installation is a black hole for me...
<Diziet> Me too :-/.
<seb128_> re
<seb128_> Amaranth: BTW you may want to join #ubuntu-desktop for desktopish discussions like that :)
<Diziet> It may be that there's some other thing that needs doing instead of umfc.
<Diziet> But I haven't seen any sign of it.
<Kamion> check one of the extension packages like mozilla-tabextensions that has been updated to cope with 1.5
<pitti> Diziet: ok, thank you
<Kamion> I need to do that for my own extension package
<pitti> ah, good idea
<Diziet> Kamion: You have a ff extension package ?
<pitti> hm, no, m-tabextensions doesn't seem to be
<Kamion> Diziet: mozilla-nukeimage
<Diziet> Ah :-).
<Kamion> provides a context menu option to set CSS display: none on any image in a page; good for blinking advertisements
<Treenaks> adblock + filterset.g work on those too :)
<HiddenWolf> adblock is the bomb. :)
<pitti> with 1.0.x I used adblock, but it doesn't work for 1.5
<wasabi_> Hmm.
<wasabi_> Did smp support move out of -smp?
<wasabi_> Looks like it.
<Kamion> wasabi_: for i386, yes
<wasabi_> k.
<wasabi_> Could ubuntu-desktop depend on xchat | xchat-gnome?
<greenpenguin13> the right-click 'Copy Disk...' option for audio cds appears to require cdrdao, should this be as a dependency for something?
<slomo_> elmo: is my key already in the main keyring?
<greenpenguin13> 
<elmo> slomo_: I think I replied and said that?
<Kamion> wasabi_: ubuntu-desktop probably won't ever get |-ed dependencies (in the near future) because of the way it's built, although I'd be happy for it to depend on something that in turn depends on xchat | xchat-gnome. We do that for totem.
<wasabi_> (ot:) You know synaptic is getting rad when you find yourself using it because it's faster than apt-cache
<HiddenWolf> wasabi, how the heck is that possible? :)
<ogra> wasabi_, nvo will be pleased to hear that :)
<wasabi_> HiddenWolf: opening a terminal and typing, then scrolling up to read it.
<jbailey> wasabi_: Nice, I'll have to try synaptic again.
<wasabi_> synaptic can now download changelogs too
<slomo_> elmo: no... or the mail disappeared ;) anyway... thanks :) did you get my sync requests earlier today? and what will we do about gnunet-gtk? you didn't want to sync it from debian last time
<HiddenWolf> wasabi, grep it. :)
<elmo> Kamion: mdz/seb were talking about switching to xchat-gnome anyway
* jbailey wonders if he has it installed.
<Kamion> elmo: fine by me, I don't use either ;)
<wasabi_> Can lock packages to specific versions. Can install specific versions.
<jbailey> wasabi_: I know I started liking Nautilus alot more when it became faster to use it for scp'ing than command line.
<wasabi_> xchat-gnome isn't in main, which could be one of the problems.
<Kamion> wasabi_: that's kind of trivial to fix if mdz decides he wants it in main ;-)
<wasabi_> Yeah heh
<Kamion> i.e. it's a symptom not a problem
<wasabi_> No, I agree. It's just nobody has bothered moving it to main now, and it's a bit inconvient to have to uninstall u-d to use it.
<seb128_> I'm supposed to make a main promotion for xchat-gnome
<seb128_> mdz asked me to do it yesterday
<wasabi_> Ahh.
<wasabi_> Problem solved. ;)
<seb128_> I just need to do the wiki page for it
<Amaranth> seb128_: Does xchat-gnome have the option to go back to buttons instead of a treeview?
* mvo installs xchat-gnome
<wasabi_> I wish it would just use normal tabs.
<lamont> pitti: ping
<wasabi_> somehow.
<greenpenguin13> the right-click 'Copy Disk...' option for audio cds appears to require cdrdao, should this be as a dependency for something?
<seb128_> Amaranth: I've not tried, I've switched to xchat-gnome because of the treeview to start
<seb128_> buttons were not fitting on my screen
<pitti> Hi lamont
<seb128_> and I was not noticing the queries stuff
<Amaranth> seb128_: Yeah, joining #ubuntu-desktop just screwed me up there, I had to exit a channel to make it fit.
<Amaranth> it's just hard to get used to
<seb128_> greenpenguin13: https://wiki.ubuntu.com/MainInclusionReportCdrdao
<seb128_> greenpenguin13: https://bugzilla.ubuntu.com/show_bug.cgi?id=13168
<seb128_> Amaranth: was easy for me, and xchat-gnome is cool
<slomo_> infinity: hi... any ideas why mod-mono isn't tried to build on ppc/ia64?
<seb128_> it sets autoaway according to what gnome-screensaver is doing
<Amaranth> neat
<seb128_> can use libnotify for notification
<Amaranth> brb
<Amaranth> that's better, i turned server tabs back on so the treeview makes sense
<seb128_> mvo: what's wrong with it?
<mvo> seb128: don't take me too serious :) it's all so "bright", so much white compared to the original xchat
<wasabi_> I like the preferences dialog, the treeview i am mostly indifferent to.
<wasabi_> Oh, and the "mission statement".
* mvo discovered the "color-scheme" option
* ogra goes to try xchat-gnome
* pitti did and switched back again a while ago
<seb128> pitti: why?
<pitti> dunno any more, something was ugly about it that I couldn't change
<wasabi_> I guess having the user list and treeview in the same place kinda doesn't work. Never enough vertical space.
<jbailey> If it's the one I'm thinking of, I couldn't get the white background to go away.
* wasabi_ likes the white background.
<seb128> jbailey: for the text area or the user list?
<jbailey> seb128: Text area.
<seb128> jbailey: my text area if grey on black atm
<seb128> s/if/is/
<jbailey> wasabi: It's fine until I hit a nick highlight or something that makes me read yellow on white.
<pitti_xg> seb128: ah, now I know again
<pitti_xg> seb128: xchat-gnome does not allow me to split off channels to a separate window
<pitti_xg> seb128: which means that I cannot follow two channels at once
<seb128> ah, /me files a bug upstream for you
<ogra> hmm, not being able to type while the preferences are open is lso a bit odd
* pitti goes back to good ol' xchat
<wasabi_> Ahh. I see. No seperate windows.
<pitti> and that sucks
<wasabi_> I kind of wish this used the same UI metaphore Gaim did.
<ogra> and is there a way to not have the channellist on the left ? 
<wasabi_> Tabs.
<wasabi_> And you can just drag them away.
<seb128> pitti: that's on valid usecase I guess :)
<pitti> seb128: xchat sucks wrt session support; I always have to rearrange detached channel windows after login
<wasabi_> guess if gaim's IRC didn't suck I'd probably use it.
<Amaranth> tabs have the same problem the button list did
<seb128> I hate gaim
<Amaranth> too many channels open == screwed
<ogra> seb128: is there any way to rearrange the layout ...?
<seb128> like?
<seb128> what layout?
<seb128> or, chans order? no
<ogra> having channels and userlist on the right, i dont like it on the left side
<Amaranth> i dunno how xchat-gnome does it but this windows xchat version would rock if i could have the user list under the window list
<Amaranth> i only user the user list to see if someone is around, so scrolling doesn't matter
<Amaranth> err, use the user
<ogra> same here ... i find a bright white window on the left very distracting
<seb128> I don't care about the user list
<ogra> but i'd b fine if i could just flip the list and the chatwin
<pitti> Kamion: hmm, the only change tabextensions did for 'install.rdf: Allow tabextensions to work with firefox 1.5.' was to update 'maxVersion' to 1.5 in install.rdf...
<Amaranth> if i were to install breezy and upgrade to dapper right this minute would it work?
<Kamion> pitti: hm, wonder how it works then since Debian doesn't seen to have u-m-f-c now either
<seb128> Amaranth: fear udev :)
<Kamion> Amaranth: you're not going to get any better answer than "maybe".
<Kamion> and see the topic ...
<Amaranth> seb128: You're saying to lock my current kernel, hotplug, and udev versions at breezy? :)
<Kamion> no don't do that ...
<seb128> no
<wasabi_> it is also annoying that xchat-gnome doesn't seem to use the gnome URL handler.
<pitti> Kamion: m-t works fine with my ffox here, and so does manually installnig a language xpi
<wasabi_> It always opens firefox for me.
<Kamion> if you're going to upgrade, upgrade - mixing will just confuse things even harder
<seb128> but I run 2 udev versions ago atm
<seb128> because xorg doesn't start with the current one
<seb128> it chocks on the mouse
<Amaranth> ok, i think i'll stick with breezy
<Amaranth> i need to get some work done, not unbreak things :)
<ogra> seb128: just put your mouse driver n /etc/modules ;)
<seb128> I've psmouse loaded
<seb128> and listed by /etc/modules too
<ogra> oh
<Keybuk> huh?
<Keybuk> there's no known "my mouse doesn't work" bug with udev
<Keybuk> there's just the 2.6.15 bugs in general
<ogra> works fine here as well
<seb128> Keybuk: maybe not udev bugs, but it works with udev 076-0ubuntu4
<seb128> and not with 076-0ubuntu5
<Keybuk> and you didn't tell me about this yet, why?
<seb128> I told it this morning, you were not around and infinity said "<infinity>     Oh, you're another "no mouse" guy.  Neat.  I wonder why my mouse works...
<seb128> "
<seb128> so I assumed it was a well known stuff
<Keybuk> heh
<Amaranth> latest OSNews post: "What is it About Ubuntu?"
<Keybuk> nope, I didn't know about it anyway
<Keybuk> what kind of mouse is it?
<HiddenWolf> Amaranth, they run one of those every week. ;)
<seb128> Keybuk: standard logitech on ps2
<seb128>         Option          "Device"                "/dev/input/mice"
<seb128>         Option          "Protocol"              "ImPS/2"
<seb128>         Option          "Emulate3Buttons"       "true"
<seb128>         Option          "ZAxisMapping"          "4 5"
<Keybuk> isn't psmouse in /etc/modules?
<seb128> it is
<infinity> Keybuk / seb128 : Fascinating, the other "no mouse guy" was a USB mouse user.
<infinity> (And my USB mouse works fine, as does my PS/2 mouse)
<Keybuk> and you're saying you don't get a /dev/input/mice ?
<seb128> correct
<Keybuk> kooky
<seb128> and I do with udev 0.76-0ubuntu4
<seb128> I can upgrade/reboot if you have extra questions :)
<Keybuk> not right now, but I'll deal with you later <g>
<Keybuk> oh, just to check
<Keybuk> grep psmouse /etc/modprobe.d/isapnp
<seb128> $ grep psmouse /etc/modprobe.d/isapnp
<seb128> alias pnp:dPNP0f13 psmouse
<Keybuk> grep PNP0f13 /sys/bus/pnp/devices/*/id
<seb128> $ grep PNP0f13 /sys/bus/pnp/devices/*/id
<seb128>  /sys/bus/pnp/devices/00:0a/id:PNP0f13
<ogra> probably it just doesnt speak french :)
<pitti> erm, you guys to that check with the udev that works, right?
<seb128> pitti: correct
<Keybuk> /lib/udev/pnp_modules /bus/pnp/devices/00:0a
<seb128> $ /lib/udev/pnp_modules /bus/pnp/devices/00:0a
<seb128> pnp:dPNP0f13*
<Keybuk> freaky
<seb128> what?
<Keybuk> in theory, that version of udev SHOULD NOT work
<seb128> lol
<seb128> why?
<Amaranth> pnp:dPNP0f13* != id:PNP0f13
<Keybuk> cat /sys/bus/pnp/devices/00:0a/id
<seb128> PNP0f13
<Kamion> slomo_: normal versioning for a branch of -0pre2 would be -0pre2ubuntu1, by the way
<wasabi_> So here's an interesting question. When storing per-device information, what should it be indexed by?
<wasabi_> the udev id?
<wasabi_> Example being network manager, whcih needs to remember interfaces.
<slomo_> Kamion: ok, will do the next time
<Kamion> slomo_: (it's relevant in case the Debian package's postinst does an 'if dpkg --compare-versions "$2" lt 1.1.10-0pre3' check, in which case you now have a complicated upgrade problem)
<Keybuk> seb128: just that line?
<seb128> Keybuk: yep
<Keybuk> right
<Keybuk> and if you now do this, what happens
<Keybuk> modprobe --first-time -n -ba pnp:dPNP0f13
<slomo_> Kamion: yes, i didn't thought about this... sorry. i'll take care of it when merging it from debian in the future
<seb128> Keybuk: "WARNING: Module psmouse already in kernel."
<Keybuk> *blink*
<Keybuk> ok
<Keybuk> and there's nothing in /dev/input/mice ?
<Keybuk> uh, nothing in /dev/input ?
<seb128> I've /dev/input/mouse0 with this version of udev, you said to not reboot yet
<Kamion> slomo_: thanks
<Keybuk> but not mice?
<seb128> $ ls /dev/input/
<seb128> event0  event1  event2  js0  mice  mouse0  ts0
<seb128> mice too
<Keybuk> oh, right
<Keybuk> is mousedev in /etc/modules ?
<seb128> $ grep mouse /etc/modules
<seb128> psmouse
<seb128> 
<seb128> that's all
<Keybuk> oh, well, somebody's been breaking your /etc/modules file then
<ryanpg> pitti, hi and ping
<Keybuk> we've always put mousedev in there by hand
* Keybuk declares pedocide
<seb128> "by hand"?
<mjg59> Keybuk: Always?
<Kamion> always> since 3 September 2004 anyway
<pitti> ryanpg: hi
<highvoltage> pedocide?
<Kamion> so an early pre-warty install wouldn't have had it
<Keybuk> seb128: it's put in there by the installer
<ryanpg> pitti, I recently filed a bug against udev but it looks like it's been handed off to you... just wondered if you wanted/needed any testing or info :)
<mjg59> Keybuk: Any reason load hid doesn't pull in mousedev as well?
<seb128> Keybuk: right, maybe I've used my Debian /etc when installing this Ubuntu like 1 year ago
<pitti> ryanpg: which one?
<Keybuk> mjg59: I don't know
<ryanpg> pitti, #20564
<seb128> Keybuk: so I just put mousedev to modules to fix it?
<ryanpg> "udev 076-0ubuntu5 + gvm 1.5.3-0ubuntu2 = no auto mounting"
* Keybuk hands highvoltage a latin dictionary
<Keybuk> (though it might need to be pedicide, my latin's a little rusty)
<Keybuk> mjg59: hmm... I note that mousedev isn't showing up in modules.inputmap *again*
<pitti> ryanpg: ah, I didn't look at that one yet (you know, I'm not officially here today :) )
<pitti> ryanpg: in any case, doing the steps on http://wiki.ubuntu.com/DebuggingRemovableDevices would help me
<pitti> ryanpg: also, does 'pmount /dev/sda1' work?
<ryanpg> pitti, heh ok well of course I'm happy to oblige... 
<ryanpg> lemme check
<ryanpg> pitti, yes pmount does work
<ogra> seb128: id anything change that could affect nautilus' sftp handling ? i cant open my rookery folder anymore ... it worked yesterday 
<ogra> s/id/did
<pitti> ryanpg: ok, great, then it's breakage at the higher gnome level
<pitti> ryanpg: the g-v-m and lshal output should help me
<ryanpg> pitti, ok I'll do http://wiki.ubuntu.com/DebuggingRemovableDevices and add to the bug
<pitti> ryanpg: thanks
<ryanpg> err.. bug report :P
<ryanpg> np thanks to you
<ogra> seb128: nevermind, its a DNS prob
<Keybuk> uh, in fact, I note that the mousedev module has disappeared entirely
<Keybuk> BENC!
<Keybuk> seb128: try upgrading to 2.6.15-7 and udev 077-0ubuntu2 and see what happens then
<Keybuk> make sure you have latest module-init-tools too
<seb128> Keybuk: will do, thanks
<infinity> Keybuk : I think there are problems other than mousedev... One user complained earlier today that his USB mouse didn't work (same symptoms, no /dev/input/mice)
<Keybuk> yeah, there was a kernel bug where usbmouse and psmouse would fight
<Keybuk> maybe that's got fixed by compiling them both in
<infinity> "was"?
<infinity> He claimed it only started on the latest kernel/udev bump.
<infinity> (started failing)
<Keybuk> I used to get it in the early 2.6.15 kernels
<Keybuk> you had to rmmod psmouse and modprobe it again
<Keybuk> though I still get the "synaptics doesn't act like one" bug
<infinity> Meh.  I guess it'll all shake out.
<infinity> Colour me glad we're not releasing in a month.
<Amaranth> i know, i'll install breezy in this vmware drive, make a copy, then upgrade one copy to dapper
<ryanpg> pitti, ok files attached... however to my eye everything looks just fine, I really hope this isn't "operator error" somehow
* Keybuk sends infinity to bed
<infinity> Yes ma'am.
<BenC> Keybuk: !!
<Keybuk> BenC: what did you do to mousedev?
<pitti> ryanpg: hah, easy one
<pitti> ryanpg: brw-rw---- 1 root disk 8, 18 2005-12-07 11:36 /dev/sdb2
<pitti> ryanpg: the device should have group 'plugdev'
<Keybuk> what does that?
<ryanpg> pitti, ah
<pitti> Keybuk: well, an udev rule
<BenC> seems it is built-in
<Keybuk> there isn't a udev rule to do that <g>
<pitti> hm, there was
<pitti> with the device-removable script test
<Keybuk> what script is that? :p
<pitti> /etc/udev/scripts/removable.sh in breezy
<Keybuk> cute, I appear to have dropped all that on the floor
<pitti> BUS=="scsi", KERNEL=="sd[a-z] *", PROGRAM="/etc/udev/scripts/removable.sh %k 'usb ieee1394'", RESULT="1", MODE="0640", GROUP="plugdev"
<Keybuk> you know, that script is total crack?
<pitti> BUS=="usb", KERNEL=="ub[a-z] *", NAME="%k", MODE="0640", GROUP="plugdev"
<pitti> Keybuk: I know, if you have something better, I'd be glad to use it :)
<Keybuk> BUS=="usb", SYSFS{removable}=="1", GROUP="plugdev" would suffice
<BenC> Keybuk: somehow on a config update I did on 12/05, it went from modular to built-in
<BenC> Keybuk: does it need to be modular?
<Keybuk> BenC: ah, right, it wasn't deliberate then
<Keybuk> *shrug*
<Keybuk> we always load it
<ryanpg> oh... somehow my /etc/udev/ is filled with *.pkg-new that a problem?
<Keybuk> leave it compiled in <g>
<Keybuk> ryanpg: dpkg --configure -a
<ryanpg> k
<pitti> Keybuk: ok, and another rule for ieee1394?
<BenC> Keybuk: ok :)
<Keybuk> pitti: at least, if I'm reading the intent of this script correctly
<pitti> Keybuk: and another one for the removable attribute
<Keybuk> cute
<Keybuk> I put removable devices in the "floppy" group
<pitti> Keybuk: BUS=="ide", KERNEL=="hd[a-z] *", PROGRAM="/etc/udev/scripts/removable.sh %k", RESULT=="1", \
<pitti>   MODE="0640", GROUP="plugdev"
<pitti> Keybuk: that was for internal flash card readers, and the like
<pitti> Keybuk: if that script would be turned into a couple of udev rules, so much the better
<Keybuk> so why does pmount/gvm work for me?
<pitti> Keybuk: oh, floppy works as well; hal can do floppy, cdrom, and plugdev
<ogra> Keybuk:Thin Clients are improving btw :)  http://people.ubuntu.com/~ogra/edubuntu/dapper-20051205-1.png and http://people.ubuntu.com/~ogra/edubuntu/dapper-20051208-1.png
<Keybuk> ah
<Keybuk> I bet I broke it yesterday when I fixed the scsi device groups
<ryanpg> Keybuk, pitti floppy works for me (after a few minutes of waiting)
<pitti> Keybuk: I still have the old udev, I didn't reboot since today's distupgrade
<Keybuk> so, should that be
<Keybuk> either on a usb/ieee1394 bus OR removable
<pitti> Keybuk: right, my devices are in floppy ATM, that's why it works
<Keybuk> or should it be on a usb bus and removable?
<pitti> Keybuk: no, or is fine
<Keybuk> right ...
<pitti> Keybuk: hotpluggable or removable
<Keybuk> SUBSYSTEM=="block", BUS=="usb", GROUP="plugdev"
<Keybuk> SUBSYSTEM=="block", BUS=="ieee1394", GROUP="plugdev"
<pitti> Keybuk: removable is the kernel sysfs attribute
<pitti> and hotpluggable is usb/firewire
<Keybuk> SUBSYSTEM=="block", SYSFS{removable}=="1", GROUP="plugdev"
<Keybuk> like that?
<seb128> Keybuk: if mousedev is builtin with the current linux should I still wait for an update to get my mouse issue fixed? :)
<BenC> Keybuk: actually, the kernel forces it to "y" now if we aren't doing an embedded system
<pitti> Keybuk: looks good enough; although the last one could be cdrom
<Keybuk> BenC: oh, good
<pitti> Keybuk: well, the only removable devices I know are CD-ROMs
<Keybuk> pitti: it should?
<pitti> hm, card readers maybe
<Keybuk> what about floppies?
<BenC> USB floppies are all around
<pitti> Keybuk: right
<ryanpg> dpkg --configure -a but the .pkg-new files remain, I'm guessing I should take this to #ubuntu for help?
<Keybuk> ok ...
<Keybuk> so does this make sense
<Keybuk> (given that a later matching rule overrides an earlier one)
<Keybuk> default all non-removable block devices to disk
<Keybuk> default all removable block devices to floppy
<Keybuk> anything on a usb bus (walking upwards) goes into plugdev
<Keybuk> anything on a ieee1394 bus (walking upwards) goes into plugdev
<Keybuk> ide cdroms go into cdrom
<Keybuk> ide tapes go into tape
<pitti> sounds good
<Keybuk> scsi tapes and cdroms go into tape/cdrom
<pitti> Keybuk: if udev rules can walk upwards the bus, that's great
<pitti> Keybuk: but at least in hoary, usb drives were bus SCSI, that's why I had to invent this script in the first place
<pitti> (in breezy as well)
<Kamion> ogra: 20051208? is your machine in the future?
<pitti> infinity: yay, the ffox locales finally work
<Keybuk> pitti: udev has always walked up the bus
<Keybuk> pitti: if BUS== fails to match, it looks up at the parent device, and so-on
<Keybuk> pitti: what about permissions
<pitti> ah, cool
<pitti> didn't know that
<Keybuk> should they all be 0640, except for cd-roms which need to be 0660 (I assume for eject to work?)
<Kamion> elmo: any idea why user-setup-udeb is in both the deb and udeb overrides?
<ogra> Kamion: yes, no time sync at all anymore for thin clients ;)
<pitti> Keybuk: plugdev has always been 0640, that should be kept
<Kamion> elmo: (I noticed when jessica started complaining about its priority, which it isn't meant to do for udebs)
<Keybuk> right
<elmo> Kamion: someone probably did the new_universe trick badly
<pitti> Keybuk: hmm, dunno about floppies, I don't have one
<Kamion> don't *think* it was me ...
* Keybuk supresses a fnarr
<elmo> Kamion: fixed
<pitti> Keybuk: when it's 660, users could format them without being root
<Kamion> can't've been, I knew it was headed for main so I'd have shoved it straight in :)
<infinity> pitti : \o/ ... Thanks, dude.  You're a champion.
<Kamion> elmo: thanks
<Kamion> pitti: locales> hooray
<Keybuk> infinity: B.ED.
<Kamion> Keybuk: I think it's a bit late for him to be retraining as a teacher now
<pitti> infinity: uploading now, but it requires some NEW love
<Keybuk> elmo: WHY IS HOTPLUG STILL IN THE ARCHIVE?
<elmo> keybuk: BECAUSE STUFF IN MAIN STILL DEPENDS ON IT!
<Keybuk> elmo: kick that stuff out of main then <g>
<doko> Keybuk: fix the packages ;-P
<pitti> infinity: hehe - RTL in Hebrew looks interesting :)
<Keybuk> doko: it's just one of them, and it looks complicated and scary
<infinity> pitti : Yeah, I played with it and it broke my brain.
<tepsipakki> BenC: thanks for fixing #17547 ;)
* infinity goes to study for his B.Ed now...
<BenC> tepsipakki: np
<Kamion> Keybuk: p.s. grepmap still Enhances: hotplug
<Keybuk> http://people.ubuntu.com/~cjwatson/germinate-output/dapper/rdepends/hotplug/hotplug
<pitti> infinity: s.leep well
<Keybuk> does it?  oops :p
<Keybuk> thank god nothing uses Enhances then
<Kamion> there are still a lot of Recommends and Suggests lying around too
<Kamion> d-i uses Enhances actually :)
<Kamion> my packaging system is more advanced than yours, nee-ner-ner-ner-ner
<Keybuk> I guess it's still true actually, grepmap *does* enhance hotplug
<Keybuk> Kamion: bite me
<Keybuk> http://psp.weebls-stuff.com/mp3/happy_badgers.mp3
<Keybuk> ^ thom sends his love
<elmo> ok, so seriously, hot plug is held in by multiseat
<elmo> what do you want  me to do?  remove it and break it, demote multiseat, none of the above?
<siretart> elmo: ok. now I reuploaded mplayer-skins, both tarballs state it was gpl
<Keybuk> it's an interesting question
<Keybuk> because there's no way you can install hotplug anyway
<Keybuk> which makes multiseat uninstallable
<FireRabbit> is it possible to send mail to everyone that is somehow related (assignee, subscribed,, etc.) to a specific launchpad specification to kick of discussion about it?
<Keybuk> actually, interestingly, it's installable in a bad way
<Keybuk> installing it would cause udev to be removed, which is what used to make hotplug work, so the installed package wouldn't work
<Keybuk> I guess multiseat needs rewriting, but nobody seems to know much about it anymore
<Keybuk> it's broken now, so removing hotplug wouldn't change that
<mpt> FireRabbit, not yet
<FireRabbit> mpt, alright.... so are people just using ubuntu-devel now?
* Kamion would be inclined to say demote multiseat for now, but leave it in the seeds so that anastacia reminds us of the problem
<mpt> FireRabbit, or ubuntu-desktop@ as appropriate (which unfortunately I didn't know until today:-)
<FireRabbit> ah alright... this would be a very useful launchpad feature...
<Kamion> whoa, the gfxboot config language is a bit scary
<Kamion> so I'm reading through the documentation and it's all starting out with simple stuff like code definitions and arithmetic operators
<Kamion> then it hits me with:
<Kamion>    blend  - blend image with alpha channel
<elmo> kamion/keybuk: ok, done.  multiseat demoted, hotplug removed
<Kamion> elmo: great, thanks
<Keybuk> thanks
<\sh> gentlemen...I want to create an pbuilder env on amd64 for i386...pbuilder --binary-arch 386 create will do this for me?
<elmo> linux32 it
<elmo> as well, and then it should.  it does with debootstrap; I don't do pbuilder
<Kamion> and --binary-arch i386
<mjg59> Kamion: You pasted a blank line
<\sh> elmo: linux32 it means? 
<elmo> sh: apt-get install linux32, then 'linux32 <blah blah pbuilder stuff>'
<\sh> elmo: ah thx :)
<Kamion> mjg59: I did?
<mjg59> 18:20 < Kamion> then it hits me with:
<mjg59> 18:20 < Kamion>
<mjg59> And that was it
<Kamion> mjg59: your UTF-8 is weak old man
<Kamion>   <bullet> blend  - blend image with alpha channel
<mjg59> Oh, right. So screen is fucked.
<Kamion> well, U+25CF BLACK CIRCLE anyway
<seb128> pitti: http://blogs.gnome.org/view/alexl/2005/12/07/0 ....  we need beagle on the desktop :p 
<FireRabbit> hmm mpt - is it possible to just post a comment to a launchpad specification?
<Kamion> FireRabbit: edit the referenced wiki page and put a comment in a separate section near the end
<FireRabbit> what if it doesn't have any URL associated?
<Kamion> if there isn't a Comments section, create one
<Kamion> then there has been no work done on that specification and it's basically just a stub
<FireRabbit> it seems like it might be nice to have the ability to post comments directly to launchpad
<mpt> FireRabbit, no
<FireRabbit> heh, no? :)
<Kamion> better to start off the necessary wiki page with a comment if so, I'd've thought
<Kamion> launchpad is much better at collating and referencing content than it is at actually storing it itself
<FireRabbit> alright, I guess I still don't completly understand it's overall goal yet
<Kamion> to be a database of everything it can lay its hands on in the free software world, approximately
<Burgwork> FireRabbit, after toilet cleanup is the next module planned
<FireRabbit> 'after toilet cleanup'?
<Burgwork> wipe your ass, in the vernacular
<FireRabbit> I, uh, can't tell if you are trying to tell a joke or what.
<Burgwork> yes, I am joking, but what Kamion said is basically correct. Mark wants LP to be the centre of the free software universe
<FireRabbit> right, ok.
<Riddell> Kamion: could you move the renamed kdepim packages to main?
<Riddell> kdepim-kresources libkcal2b libkdepim1-dev libkdepim1a libkgantt0 libkgantt0-dev libkleopatra1 libkleopatra1-dev libkmime2 libkpimexchange1-dev libksieve0-dev libmimelib1-dev libmimelib1c2
<ogra> FireRabbit: imagine it as a next generation sourceforge that also cooks your coffe and cares for your kids if you have no time :)
<mvo> *gar* sf *gar*
<ogra> yeah, its a lot more indeed :)
<FireRabbit> ah but sourceforge provides forums etc for user collaboration on issues
<Diziet> So in Python, if I have a list, and want to pass it to exec and capture the stdout in a Python variable (and bomb if the program exits nonzero), how do I do this ?
<mvo> Diziet: look at the subprocess module
<mvo> Diziet: http://docs.python.org/lib/node241.html
<Diziet> Ah, new in 2.4.
<mvo> and very nice indeed
<Kamion> Riddell: when you ask me this kind of question it would be useful if you could indicate whether they're already listed in anastacia output: http://people.ubuntu.com/~mdz/anastacia.txt
<Diziet> Urgh, I still have to faff about with a pipe.
<Kamion> then I'll know how much work it's going to be
<mvo> Diziet: "faff about" == "mess around" ?
<FireRabbit> what i am getting at is that if i come across a specification that looks interesting, it would be nice to have a mailing list (or something similar) dedicated to that specification so I could see what has already been done and discuss with the other developers working on it how I can help, etc.... just ignore me, i am thinking outloud again.
<Diziet> mvo: Yes.
<Riddell> Kamion: ok (they are)
<mvo> Diziet: how big is the data you expect (in the kb range or rather in the mb range)?
<Kamion> FireRabbit: in general a list for each spec would be overkill, and I'd encourage you just to mail ubuntu-devel@ about /distros/ubuntu/ specifications
<Diziet> Bytes.
<Kamion> Riddell: done
<Riddell> thanks Kamion 
<Diziet> Maybe 100 ?  200 ?  In this case it's a pathname.
<FireRabbit> yeah, ok.
<mvo> Diziet: (out,err) = Popen(["ls", "-R"] , stdout=PIPE).communicate()
<mvo>  will just do the right thing
<mvo> Diziet: out,err is the output of the command as strs
<Diziet> Yes, I just found communicate in the FM.
<Diziet> Thanks.
<mvo> cheers
<Riddell> ogra: dpkg: error processing /var/cache/apt/archives/xscreensaver_4.23-2ubuntu1_i386.deb (--unpack):
<Riddell>  trying to overwrite `/usr/share/xscreensaver/config/README', which is also in package xscreensaver-data
<Riddell> known?
<ogra> hmm, nope
<ogra> from which version do you upgrade ? 
<ogra> the split already happened in breezy ...
<Riddell> upgrading from 4.21-4ubuntu17
<ogra> hmm
<ogra> oh, actually... right ...
<ogra> fixing
* Kamion pokes the gfxboot docs. Array dimension != array length
<fabbione> elmo: thanks for NEW'ing the sparc kernel. I was really waiting for it :)
<Riddell> ogra: something happened to ant xscreensaver?
<ogra> nope
<ogra> its still in xscreensaver-gl 
<ogra> /usr/lib/xscreensaver/antinspect and /usr/lib/xscreensaver/antspotlight
<Riddell> but no "ant"
<ogra> was there a separate "ant" ?
<Riddell> kdeartwork expects one
<Riddell> no problem if it's not there, I'm just wondering what to put in the changelog
<ogra> hmm, actually there is an ant.c in the code ...
<ogra> can this wait some days or is iturgent ? 
<Keybuk> right, going to drop off for a few hours, be back at 0000UTC
<Riddell> xscreensaver-data in breezy has /usr/lib/xscreensaver/ant
<ogra> again, is it urgent ? 
<Riddell> ogra: not urgent in the slightest, I'll just upload kdeartwork without it, but if you add it back please let me know
<ogra> Riddell: will do, i didnt notice it wasnt built ..
<ogra> grr.... there is no manpage for ant anymore, not even upstream ...
<\sh> damn...this bitch is bloody fast...I won't use the nc6000 anymore for building packages
<dholbach> good night everybody
<\sh> elmo / pitti: topic "backports": if a dapper package was backported to breezy, and this package has now some security issues, but the newly uploaded package to dapper can't be backported to breezy, how should we proceed?
<seb128> backports are evil
<shaya> is anyone here at LISA?
<\sh> seb128: serious...actually I was waiting for such a thing to happen...and it looks like it will happen soon
<seb128> what package?
<\sh> Amaranth said vlc
<Amaranth> \sh: I didn't say vlc has security issues.
<ogra> looks like jdong needs to become a motu soon :)
<Amaranth> \sh: I said if it did backports would be screwed.
<\sh> [21:09]  <Amaranth> what happens when something is backported, has a security problem, but the fixed package in dapper no longer cleanly backports?
<Amaranth> <Amaranth> there isn't an example of this yet
<Amaranth> <Amaranth> but i believe the vlc package in dapper doesn't build anymore on breezy but an older one got backported
<\sh> Amaranth: so..I translate it "it could have a security issue"
<Amaranth> *shrug*
<Amaranth> btw, it looks like it's a build-dep but vlc build-deps on about 100 things and it's hard to compare
<\sh> Amaranth: if I understood you wrong..sorry
<\sh> Amaranth: but we have to raise this question anyways...so it doesn't matter what package we are talking abiout
<fabbione> Amaranth: you will have to backport the security patches.
<Amaranth> fabbione: No source changes in backports.
<\sh> fabbione: there are no source uploads to backports
<fabbione> Amaranth: sucks to be you than :)
* Amaranth does not manage or use backports
<Amaranth> i'm just an observer
<fabbione> Amaranth: well sucks to be who uses backports.
<sivang> seb128++
<sivang> seb128: (backports are evil)
<ogra> pitti benefits from backports ... made his inbox smaller :)
<ogra> backporting pmount that is
<\sh> where is inti-sourceview hiding in dapper?
<mpt> mjg59, ping (low priority)
<fabbione> later guys
<wasabi_> Woh my ibook just woke up with the new kernel.
<mjg59> mpt: Hi
<wasabi_> TWICE IN A ROW!
<wasabi_> now that is nice to see.
<dilinger> w/ the success of my other box, i should give dapper's kernels a try on my laptop, too.  see if the hibernate stuff works now
<mpt> mjg59, an early Thinkpad wakes up without networking ~50% of the time. Restarting usually fixes it, but not always. What information should be included in a useful bug report?
<mjg59> mpt: Restarting what?
<mpt> Restarting the computer
<mpt> (the "Deactivate" and "Activate" in network-admin don't work)
<mpt> (or at least, don't bring the network back up)
<mjg59> mpt: dmesg, lspci, cat /proc/interrupts
<mpt> thanks mjg59
<mjg59> No problem
<Mithrand1r> elmo: (re ooo-amd64 and why build them):  It's mostly as a courtesy to upstream.  If we think they're usable, they might be in universe for dapper (I don't think we want them in main)
<eruin> if glcore fails to load when using the ati driver, should I submit a bug?
<eruin> or is the whole xorg situation in dapper so unstable atm that it's not really necessary?
<mvo> BenC: we don't ship misdn in our kernels anymore, right?
<BenC> mvo: no idea what that driver is
<BenC> if it was in breezy, it should be in dapper
<mvo> BenC: I think we removed it for breezy already because it was buggy, but I'm not 100% sure. i'm going over old bugreports right now
<BenC> me too :)
<eruin> ouch, second hardlock on the ati driver
<daniels> i have glcore under control
<daniels> as for r300 hardlocks ... yeah
<daniels> that happens
<lamont> misdn was dropped for the reason of being unmaintainable and buggy
<sivang> hmm, firefox now also displays the welcome page
<sivang> it's ugly
<lamont> ask fabbione - it's a great way to get him going...
<eruin> daniels; I've been looking at mailinglists and bugzillas, and saw something about dlopen
<eruin> has that got anything to do with it?
<BenC> lamont: heh, no thanks :)
<daniels> eruin: for glcore?
<eruin> daniels, hardlocking I believe
<eruin> bah, I've lost my bookmarks.. nevermind ;)
<seb128> daniels: dunno if that's a known issue, but dch stopped working for me, it displays squares instead of normal chars ...
<seb128> Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
<mdz> mvo: doko would know about misdn
<daniels> seb128: dch just invokes $EDITOR, IIRC
<mvo> mdz: thanks, I looked over our config and we don't ship it anymore
<seb128> daniels: emacs works fine when not started by dch
<seb128> hi mdz
<sladen> isn't it bedtime in .no
<mdz> seb128: hi
<Simira> not yet
<Simira> sladen : it's half past ten
<HiddenWolf> it is in .nl. :)
<dilinger> bedtime is for people who sleep
<sladen> Simira: it's certainly bedtime in .fi.  /me looks hintingly at other people still geeking
<sladen> dilinger: valid point.  I suck at that...
<seb128> mdz: did you read my hint for xchat-gnome / ^W yesterday?
<mdz> seb128: hmm, no, I don't remember seeing it
<mdz> I have been switching IRC clients due to moving around
<Simira> sladen : you are there? You aren't by any chance going back via Oslo/Norway?
<daniels> seb128: errrr ... i have no idea how dch is invoking emacs to screw up its fonts
<daniels> that's quite impressive
<seb128> daniels: do you have the issue too?
<seb128> mdz: 
<seb128>  <seb128>       mdz_: open the "Discussion" menu, go on the "close" label, press backspace
<seb128>  <seb128>       mdz_: you need to have /desktop/gnome/interface/can_change_accels (gconf) set
<daniels> can't really test because a) I don't have emacs installed, b) my X server only recognises two core fonts
<daniels> (fixed and cursor)
<seb128> it'll not make ^W works the way you want, but it'll stop it closing your tabs :)
<mdz> seb128: but the shortcut there already says shift+ctrl+w rather than ctrl+w
<seb128> weird
<mdz> I'll try it though
<seb128> mine says Ctrl+W
<\sh> hey sladen...
<mdz> seb128: yay, it works
<seb128> cool
<mdz> seb128: and also makes ^W DTRT
<seb128> oh, cool
<HiddenWolf> seb128, is any of that jds-performance-hacks blog stuff on planet gnome interesting for ubuntu?
<mdz> I tried that approach with old xchat and it didn't work; the shortcut was hardcoded
<seb128> right
<seb128> you need to do it at every restart atm with xchat-gnome but that's fixed with the current SVN
<mdz> seb128: any idea why my applications menu is broken?  it flashes open for a very short time, then disappears with only a tiny square under the menu bar
<seb128> mdz: gam_server/inotify bug, I've forwarded upstream with some debug log I got from mvo but I don't get the issue here so it's not easy to debug
<mdz> seb128: it happens on my desktop but I don't think it happens on my laptop
<seb128> mdz: workaround is to run your session with GAM_TEST_DNOTIFY=1
<seb128> so gam_server uses dnotify
<doko> BenC, mvo: it would be nce to have it enabled now, so we can test with it and then decide if it' mature
* ogra grss at himself ...
<Mithrandir> mdz: I'm not going to make the meeting at 0200 UTC tomorrow, is that ok (since I've been on vacation, there's not much to report).
<daniels> seb128: oh, the other thing is
<daniels> seb128: your performance issues could well be due to the new kernel seemingly not providing mtrr support
<daniels> seb128: does it help if you downgrade the kernel to 2.6.12?
<seb128> daniels: I'll give it a try
<seb128> daniels: what help is to use a color instead of an image for the background :p
<mdz> Mithrandir: ok, please send a note to JaneW
<eruin> mdz, I had the menu bug too, but it didn't appear on a fresh install a few days ago
<daniels> seb128: heh.  a little bit less data, yeah.
<daniels> okay, I should have a fix for the worst of the image breakage soon
<seb128> daniels: what image breakage?
<seb128> daniels: stuff like http://bugzilla.ubuntu.com/show_bug.cgi?id=20286 are due to xorg?
* ogra kicks xchat-gnome hard
<ogra> what an odd software 
<daniels> seb128: almost certainly
<seb128> ?
<daniels> ah yes
<seb128> daniels: rock, I'll reassign to you. Seems that all those guys have ati/ppc config
<daniels> if changing from 24bpp to 16bpp fixes it, then please reassign to xserver-xorg-core, title fbCompositeGeneral is horrifically broken, PENDINGUPLOAD
<seb128> k
<daniels> and yeah, per c#7, changing to 16 does fix it
<seb128> daniels: bug changed
<daniels> cheers
<seb128> daniels: is "left handed mouse setup not working correctly" also a known issue?
<seb128> buttons are not reversed
<seb128> jdub: your comments on the ubuntu-desktop thread about the new session dialog would be welcome
<jdub> ok
<jdub> thanks
* jdub wades through thick treacley email
<seb128> jdub: mpt seems to be suggesting something totally different of what we discussed at UBZ :/
<daniels> seb128: yeah, mouse handling is screwed at the moment
<jdub> but he's closer to sanity than what we discussed at UBZ (though far too many menu entries)
<seb128> jdub: rah. Mark asks for one dialog with the 2 categories of action right?
<jdub> yep
<ogra> does he ? 
<ogra> ouch
<seb128> jdub: I don't really mind either way but we need to decide something and stick to that
<jdub> i'm pushing for the 'turn off / log out' separation, ala windows xp
<seb128> not to come with new ideas every time we are half implementation of something
<ogra> jdub: but we have to many buttons
<seb128> ogra: have you read the ubuntu-desktop list discussion/seen the screenshot?
<wasabi> nice. xvimage sink is seg faulting
<jdub> ogra: splitting like windows xp reduces that
<ogra> seb128: yup
<seb128> screenshots of the new dialog
<daniels> wasabi: gstreamer problem
<wasabi> think so?
<ogra> and i find the buttons wonderful, but the layout awful
<daniels> wasabi: yeah, the client-side part of Xv is utterly tiny
<daniels> 'tis seb's fault ;)
<wasabi> Heh.
* wasabi grabs xine
<seb128> wasabi: don't listen to him :p
<ogra> seb128: the title must go completely... the checkbox seems misplaced in the dialog, there i agree with mpt
<seb128> ogra: that everybody agrees I think :)
<wasabi> true 'nuff.
<ogra> and i dont think we need ok and help buttons
<seb128> the question is about the principle of 2 rows of icons like this
<daniels> seb128: well, it's either gstreamer or gtk :P
<ogra> then just shuffle the buttons around in a sane manner (get a real layouter to do that)
<seb128> daniels: gstreamer, freedesktop is yours, isn't it ? :)
<ogra> seb128: lets ask a typographer who does that professionally i'd say
<ogra> they know how to weight things
<daniels> seb128: nuh-uh, its bts is gnome.org
<ogra> jdub: cant your design guy have a look at it ? (the one who also makes spalsh and wallpapers)
<jdub> that's art, not user interface design
<daniels> also I couldn't help but notice that you've been doing all the Ubuntu uploads
<seb128> daniels: still, as you said, the client part is tiny, I blame the server part which is yours :p
<jdub> seb128: 0.10 going in?
<ogra> jdub: but he will know how to lay out stuff in a sane manner
<daniels> seb128: er, how could the server make the *client* segfault?
<daniels> seb128: xv's usual failure mode involves seeing chroma key blue for a couple of seconds before your machine completely tanks
<jdub> ogra: not really (this proposal is not sane anyway)
<ogra> jdub: i think thats a very difficult one ...
<ogra> that too
<seb128> jdub: I've gstreamer0.10 almost done and gst-plugins-base0.10 with most of the work done, but it's not easy work, we need to rework all the plugins split, binaries packages, etc
<jdub> erk
<seb128> jdub: I'm a bit slow because I work with lool to decide on a common packaging with Debian and he's a bit busy this week
* mvo is afk until the meeting
<seb128> mvo: 'night :)
<ogra> mvo: sleep well 
<jdub> you want to do separate 0.10 compatible packages for rb, totem and friends, or just switch outright?
<jdub> yo mvo
<jdub> night mvo ;)
<daniels> mvo: 'nacht
* jdub remembers the spec saying switch outright, but that may no longer be appropriate ;)
<seb128> jdub: good question, I guess Depending of the app/how it works with gst0.10
* mvo grumbles about getting up again in 3h 
<seb128> jdub: switch totem probably, we have totem-xine for people who wants an usuable version :)
<ogra> mvo: just stay up :)
<seb128> jdub: if rhythmbox works fine enough with ogg/mp3 switch to gst0.10 too
<seb128> ie: not bother to make new packages if not required
<jdub> cool
<neuralis> fyi for everyone: latest rumor has it that harvard will be switching its core servers to ubuntu shortly. i'm investigating.
<ogra> kde discovers gambas :) http://www.kbasic.org/
<\sh> ogra: old news
<\sh> ogra: i'll package it the next days i think
<ogra> eek
<\sh> ogra: and gambas I fixed today somehow...it's evil upstream
<Riddell> ogra: ?  gambas is qt
* ogra lols about the poll on the above page
<\sh> if DESTDIR!=ROOT  then set some random symlinks in /usr/bin
<ogra> Does Linux need a modern BASIC? Yes, I would like to use my BASIC skills.
<ogra> 	No, BASIC sucks. C++ is the king.
<ogra> 
<ogra> 
<ogra> haha
<ogra> someone should tell them there are other langs :)
<daniels> god that site is horrendous
<\sh> ogra: the evilness comes with the future..."rewrite of linux kernel in vb#" "we click code a new kernel"
<ogra> BenC would love it :)
<\sh> oh well
<ajmitch> it would make maintenance a lot easier, I'm sure
<\sh> linux + windows on one page..together with kbasic professional and linspire
<\sh> FUD
<ajmitch> that kbasic page looks a little flashy :)
<Riddell> \sh: how is it FUD?
<Riddell> crappy yes, but not FUD
<\sh> "You can create modern BASIC applications for Windows and Linux "
<\sh> ms bought linspire...to tell the world "ms is evil" and "linspire rocks"? therefore linspire sponsors a broken kbasic so ms gets all basic cracks to vb-click-sharp ... FUD ,)
<\sh> time to go to bed
<ogra> pfft 
<jdub> hooray for smp by default
<\sh> oh well.no bed...knoda links against python2.3
<bigozs> is there anyone working on that migration assistant listed at launhpad?
<mpt> bigozs, no, do you want to? :-)
<bigozs> it's an interesting idea
<\sh> oh wow...
<bigozs> are there any guidelines about what to use to write this ?
<mpt> I don't think so
<mpt> At Ubuntu we're generally fans of python, but for something that difficult I think we'd be impressed if anyone implemented it at all :-)
<mpt> (As long as you didn't use, oh, kbasic or something)
<bigozs> no :)
<bigozs> Python is fine
<bigozs> shell scripts Ok too?
<mpt> I don't see why not
* mpt should be quiet and let actual programmers talk, however
* mdke appeals for keybuk to come online
<mdke> anyone good with udev/new kernel issues?
<mpt> bigozs, if it was going to be part of the installer you'd want to talk to Kamion
<bigozs> mpt: i thought it could be postinstall
<mpt> Well the problem with that is, post-install the Windows partition might not exist any more :-)
<bigozs> a point for you, hehe
<bigozs> :)
<mpt> but it would rock to start up the live CD and launch a browser and oh! there's all your bookmarks from Windows
<mdke> by the way mpt, did you see I edited the wiki license spec in line with your ideas, and added you as contributor to the spec?
<mdke> feel free to make any more suggestions!
<bigozs> we'll.. i'll try some basic ideas, if i come out with anything that makes sense i'll then let you all know... thanks for the answers :)
#ubuntu-devel 2005-12-13
<ogra> mdke: you have probs with the new kernel/udev ? 
<mdke> ogra, yeah, i can't boot
<ogra> oh ? 
<mdke> my hard disk disappears ;)
* ogra just rebooted
<ogra> mdke: Keybuk is your man ...
<mdke> yeah I know
<mpt> mdke, I didn't see that, thanks for the pointer
<ogra> i have a reciepe anywhere
<mdke> we exchanged bugmail, but I wanted to see if I can get anyone in here to help out
<ogra> mdke: see /query
<mdke> yeah
<mdke> ogra, thanks, but I can boot the old kernel ;)
<mdke> ogra, just wanted to see if I can help someone fix the new one by debugging
<ogra> ah, k
<mpt> mdke, url? (searching for "wiki license" on the wiki shows nothing relevant)
<mdke> mpt, WikiLicensing
<mpt> thanks
<mdke> mpt, i answered your specific points on the docteam mailing list in the Packaging guide thread... but i bet you have quite a bit of mail to get through ;)
* mpt seethes at Moin
<jdub> ogra: lordy, gnome-screensaver is ugly atm - when are we going to do the seed switch to bring that in by default?
<ogra> jdub: its in the main inclusion queue since 2 days on mdz request... i hope pitti finds the time for it before flight 2
<mdke> yeah, what happened to the pretty breezy screensaver?
* mdke strokes the shiny dialogues
<ogra> jdub: its an awful lot of work to make the hacks work with gnome-screensaver 
<ogra> jdub: i dont understand their decision for .desktop files for each hack at all :/
<torkel> ogra: there is a script in g-s that creates the .desktop files from the hacks (but you probaly already knew that :-)
<ogra> torkel: err, nope 
<mhz_cook> smurf: ping
<ogra> torkel: but i question the whole concept, it silly 
<ogra> *its
<mhz_cook> jdub: any chances to get that ML?
<torkel> ogra: I more or less agree with you
<jdub> i've just returned from trveling, not yet sure whether i have access to the main server
<jdub> so, not just yet
<mhz_cook> okis
<ogra> torkel: migrate-xscreensaver-config.sh doesnt help much for the packaging, but i'll try to use it for the .desktop generation in xscreensaver 
<ogra> thanks for teh hint :)
<lamont> mdz: new util-linux and postfix uploaded to debian, which should be able to just sync in to ubuntu and conform
<mdz> lamont: cool, ask elmo for the sync
<lamont> mdz: they have to make it into the archive first...
<lamont> that's tomorrow's dinstall run
<mdz> lamont: iirc elmo can sync from incoming now
<lamont> ah, neato
<Kamion> bigozs: right now, parts of the installer need to be in shell or C (generally shell if possible) for maximum portability
<Kamion> things that will be specific to the live installer can be python
* Kamion looks sideways at the SuSE gfxboot theme code
<Kamion> it has a function called enough_mem which appears to return true iff biosmem < 4MB || biosmem >= 200MB || !syslinux
<Kamion> I confess to being somewhat baffled by the first part of that, unless the RPN language is confusing me
<daniels> dude, you have TOO MUCH MEMORY
<daniels> lose 60MB of that 64
<bigozs> Kamion: is there any specific way shell scripts are integrated into the installer?
<Kamion>     key keyF7 eq or {
<Kamion>       % call super penguin
<Kamion>       p.call.super
<Kamion>     }
<seb128> daniels: 2.6.12 doesn't do a difference for this desktop switching slowness
<Kamion> uh-huh
<Kamion> bigozs: that question either has a very short answer or a very long one
<Kamion> bigozs: mostly they use debconf for interaction and database access
<daniels> seb128: scheiss
<Kamion> bigozs: but really you probably just want to have a look at a bunch of them :-)
<daniels> seb128: could you please ht me up with an xorg.0.log?
<bigozs> I may be asking stupid questions but I'm completely unfamiliar with the installer architecture :)
<seb128> daniels: my chinstrap dir has it
<Kamion> bigozs: easiest way to get the whole lot at once is to check out the upstream repository, svn://svn.debian.org/svn/d-i/trunk/ (beware there's rather a lot of it)
<daniels> seb128: cheers
<Kamion> look in installer/doc/devel/ for various bits of documentation, intro and otherwise
<bigozs> ok, will look
<Kamion> most of the actual code is in packages/
<Kamion> bigozs: a useful thing to look at might be os-prober, which pokes around in other filesystems on the disk to figure out in generic terms how to boot them; that at least is kind of in the same ballpark as what you're looking at
<bigozs> ok
<nekohayo> hey just a randomish question, do you know if any of those gnome performance hacks have already been uploaded to dapper or not yet?
<bigozs> os-prober looks interesting, i have to look at it when i have more than 3 hours sleep :)
<bigozs> my life is governed now by my daughters sleep cycle
<daniels> ah, it's the destroyer of worlds
<daniels> good morning
<Kamion> mdz: oh, wow, not only does gfxboot support changing the keymap (in syslinux, even), but it can do keymap defaulting by locale or whatever other arbitrary criteria we dream up
* Keybuk pops a couple of extra spoonfuls into the coffee pot
<Kamion> writing a theme may well be an utter bastard, though; I'll probably start with a hacked SuSE one and go from there
<Kamion> since "theme" => "7000+ lines of something that looks a bit like PostScript"
<ogra> heh
<ogra> the suse way of life
<Keybuk> we could get sladen in to not do it
<daniels> zing!
<Kamion> gfxboot provides you the facility to draw on the screen, handle input, and all the rest of it from the bootloader, but no widgets or policy or whatever
<Kamion> it's like udev for shiny
<jdub> Kamion: policy is for fascists!
<daniels> MECHANISM NOT POLICY
<mdke> ooh Keybuk 
<Keybuk> uh-oh
<Keybuk> I dislike "ooh Keybuk" this week
<Keybuk> what critically important part of YOUR system doesn't work? :p
<ogra> lol
<mdke> Keybuk, your call, if you fancy some udev debugging
<mdke> it's the hard drive
<jdub> my system is pretty funky atm
<jdub> trackpad doesn't work
<Keybuk> SATA?
<jdub> usb mouse dies after a while
<Keybuk> jdub: yeah, that's a kernel bug afaict
<jdub> usual fglrx fuckage
<mdke> Keybuk, yes, #20557
<Keybuk> so blame BenC for those ... though there have been "mouse is broken" bugs since all through 2.6.15 so far
<daniels> you're using fglrx??
<jdub> (this time it oopses the kernel, and doesn't shutdown/reboot)
<jdub> daniels: have to on this
<Keybuk> mdke: ah, good
<jdub> daniels: ati driver just makes a very bright mess on the screen
<Keybuk> mdke: you'll want the upload I'm going to do in a short while then
<daniels> oooh, shiny blooming
<mdke> Keybuk, ah good news
<daniels> which chipset?
<jdub> not blooming though
<Keybuk> mdke: echo ide-generic >> /etc/modprobe.d/blacklist ; update-initramfs -u ; reboot ; profit
<Keybuk> (temporary fix)
<daniels> jdub: oh?
<mdke> Keybuk, that's ok, I have a breezy partition :)
<daniels> zsh: profit: command not found
<jdub> really messy flickering, looks like very bright high resolution cga colours :)
<mdke> Keybuk, will try tomorrow and close/comment on bug
<daniels> jdub: ah, sweet
<jdub> xorg thinks it's a radeon xpress 200M RC410
<daniels> ah, right
<daniels> and it fails with dapper?
<daniels> i expect MAXIMUM FUCKTASMIC with breezy for that chipset
<daniels> but it should be orright with dapper
<jdub> i'm running dapper
<mdke> Keybuk, thanks :)
<jdub> fglrx -> fine apart from oops, no vga, etc
<daniels> wack
<Keybuk> mdke: if you want the boring details, libata takes ownership of devices asynchronously -- so sometimes the "modprobe ide-generic" happens before its done so, and ide-generic steals all the devices
<jdub> ati -> messy interesting flicker
<jdub> actually, i'll try again with -7 fglrx
<jdub> er
<jdub> ati
<Keybuk> the fix is obvious, we're not going to modprobe ide-generic if ROOT==/dev/sd* :p
<mdke> ok
<mdke> you guys know what you're doing :)
<mdz> Kamion: wow, nice
<daniels> jdub: i think cvs might have the hot fix action
<mdke> i have no clue what you said
<daniels> well
<daniels> cvs + anholt's patches
<jdub> ok
<Keybuk> do you know what the funny thing is?  breezy is broken here too ... except busybox's shell is so slow, the extra echo in between the two modprobes is enough to make it work <g>
<mdke> Keybuk, so I don't need ide-generic?
<Keybuk> mdke: no, not for your root filesystem anyway
<jdub> daniels: so that'll be basic FOSS ati support, no 3d and so on?
<mdke> Keybuk, if I need it for something else, it'll be there?
<Keybuk> yup, it'll be loaded once the real root filesystem is running as soon as anything that smells like IDE is found
<mdke> Keybuk, ah great
<Keybuk> you only need it for pcmcia ide devices though
<Keybuk> and even that might not be true now
<Keybuk> (I'm going to still err on the side of loading it though, just in case)
<mdke> sounds fine
<mdke> Keybuk, thanks
<Keybuk> mdz: btw, how is your laptop today?
<mdz> Keybuk: out of reach
<daniels> jdub: well, there's 3d support, but it may well fail to draw anything and hang your machine
<mdz> I left it in the car, and can't get there until later
<mdz> (floor varnish is drying)
<jdub> heh
<Keybuk> fair enough
<Keybuk> mdke: randomly, is your laptop-that-doesn't-boot reachable at the moment
<mdke> Keybuk, on my lap
<Keybuk> right
<Keybuk> so I guess you can't reboot that to check something for me? :p
<mdke> Keybuk, sure
<Keybuk> reboot into dapper, and it should fail with /dev/sda* not found -- and drop you to a shell
<mdke> yeah
<Keybuk> then cat /proc/modules and note down the list
<Keybuk> just want that
<mdke> ok i'll try
<mdke> Keybuk, bad news
<mdke> it booted
<mdke> is this a "sometimes it does, sometimes it doesn't" job?
<Keybuk> yup
<Keybuk> that's good
<mdke> want me to try again?
<Keybuk> reboot a couple more times until it doesn't
<mdke> k
<mdke> brb
<Keybuk> sometimes (entirely serious) waving it around a bit to cool off helps
<seb128> daniels: grumpf, slowness happens with fglrx too
<seb128> I've downgraded gtk, no change neither
<seb128> and cairo version didn't change
<daniels> seb128: so if you downgrade to xserver-xorg-core 6.8.2-77, and downgrade drivers as appropriate, does it get quicker then?
<daniels> i'll be shitted off if it's slower in the core
<seb128> daniels: would grabbing 5.10 debs would work?
<seb128> s/would work/work/
<mdke> Keybuk, lol. Ok I have them: you don't want the numbers too right?
<Keybuk> right, just the names for one that failed
<mdke> i just wrote them all down...
<mdke> some failed?
<Keybuk> no, I mean all of the names you wrote down ... from the failed boot :p
<mdke> ah cool
<BenC> daniels: can you verify 6841 on breezy (strip on xfs)?
<mdke> Keybuk, /query
<Keybuk> sure
<daniels> BenC: yep
<daniels> seb128: yep
<seb128> daniels: all drivers need to be downgraded?
<seb128> daniels: or just the ati one?
<BenC> daniels: is that "yep" it is still a bug, or "yep" you can test it? :)
<daniels> seb128: -core, -input-kbd, -input-mouse, -driver-ati
<daniels> BenC: yep it's still a bug
<BenC> daniels: no change with 2.6.15 either?
<daniels> BenC: dude, I'm not trying .15 :P
<BenC> daniels: come on, I'm running it on 6 machines here :P
<daniels> seriously, I'm going to try to get all my machines up to .15 and the new shiny broken stuff next week
<daniels> so I'll let you know then
<daniels> but it only happens when building the monolith, so I haven't tried that environment for a while now
<Keybuk> 15+new-world-order, when it works, is a lot better
<BenC> ok, thanks
<Keybuk> and if it doesn't work, it's better I know now, so it will
<daniels> Keybuk: is this a lot like the new X world order, which was stupendously great for me, who was generally hanging five or so revisions back, and had a hand-hacked transition anyway? :P
<jdub> ogra: xscreensaver-dataq and xscreensaver conflict on /usr/share/xdscreensaver/config/README
<ogra> jdub: not anymore 
<ogra> jdub: 4.23-2ubuntu3 is what you want
<Keybuk> daniels: nah, this actually feels really good -- we have a huge flexibility to debug and arrange things
<Keybuk> it's just doing some fine-tuning now
<Keybuk> of course, fine-tuning the mounting of the root filesystem
<Keybuk> which appears major :p
<Keybuk> I go with what infinity said this morning
<jdub> ogra: i had it during upgrade to that
<Keybuk> I'm glad we're not releasing dapper this month, but I'm glad we're going to release dapper with this stuff
<ogra> jdub: exact error ? 
<daniels> Keybuk: this was exactly the case with breezy
<ogra> jdub: since thats what the ubuntu3 upload was for ...
<jdub> ogra: can't paste - -data tried to replace config/README owned by xscreensaver
<jdub> from ubuntu1 -> ubuntu3
<ogra> hrm
<BenC> I should do atleast one xfs install so I can test these things
<jdub> worked on the second run through though
<daniels> seb128: if you say that it's all fixed now, I'm going to be really upset
<ogra> jdub: either yours or Riddells system was f*cked then ..
<daniels> i like blaming things on the kernel
<seb128> daniels: downgrading those 4 packages fixes the left handed mouse and the slowness of desktop switching
<daniels> d'oh
<seb128> daniels: sorry
<daniels> the mouse was expected
<daniels> the slowness sucks
<seb128> that feels so good
<seb128> the 2s to switch desktops is ugly to use when you switch desktop often
<seb128> and I do switch often
<daniels> two seconds?
<seb128> that's my estimation on how low it takes it to redraw the background
<seb128> maybe 1s
<daniels> jesus christ
<ogra> seb128: where do i set the scrollback buffer in xchat-gnome ? 100 lines is really not usable
<daniels> can you please put up the log from -77 on chinstrap or so?
<daniels> i'd like to diff the two
<seb128> daniels: Xorg.0.log.speed at the same place
<daniels> heh
<jdub> seb128: redrawing the background?!
<seb128> jdub: with new xorg, it takes 1-2s to redisplay nautilus' icons and stuff on the desktops when switching between them
<seb128> s/desktops/workspaces/ rather
<jdub> hrm, not happening here
<seb128> lucky you :)
<jdub> ;-)
<seb128> happens to dholbach on one box too
<jdub> everything else sucks, mind! :)
<jdub> (stupid quebecistani laptop!)
<seb128> I still have an outdated udev because Keybuk broke my mouse :p
<Keybuk> I did nothing of the sort
<jdub> does your mouse work for a while and then stop?
<Keybuk> BenC broke your mouse :p
<daniels> seb128: if you comment out Load "dri" in xorg.conf, is it any happier then?
<seb128> jdub: not, xorg refuse to start because it claims there is no mouse
<seb128> daniels: k
<daniels> seb128: (in dapper)
<seb128> daniels: I upgrade again, comment and try, that's it?
<daniels> yeah
<BenC> if your mouse breaks in X, don't blame me until you can reproduce it with gpm :P
<daniels> also, what sort of card did dholbach have?
<daniels> BenC: DUDE GPM IS THE DEVIL
<daniels> BenC: also, if /dev/input/mice doesn't exist, it's *so* not X's fault
<daniels> i blame udev
<BenC> yeah, me too :)
<jdub> daniels: apart from the kernel working around X being a doofus :-)
<jdub> daniels: so strictly speaking, it's *all* X's fault :-)
<daniels> jdub: the what now?
<jdub> /d/i/m is a hack to work around X not having reasonable hardware autoconfiguration
<jdub> so we can always boil down to blaming X
<jdub> which must be a relief for the kernel hackers
<jdub> though they have a lot to be blamed for too ;)
* ogra thinks xchat-gnome is odd.... and reinstalls xchat
<seb128> daniels: nop, still slow without dri
<daniels> seb128: whoohoo
<daniels> seb128: if you're feeling really brave, you could start it in gdb from another machine, and ^C it from there while it's redrawing the background
<daniels> based on previous stuff, I suspect fbComposeGeneral()
<daniels> which will !!HURT!! for background-sized stuff
<daniels> jdub: yeah, X is pretty nice, shame the server's so shit
<seb128> daniels: I'm trying to build sysprof with current linux atm, would it do the trick?
<daniels> what's sysprof?
<ogra> ah, thats better :)
<seb128> daniels: profiling tools, you don't read federico's blog? :)
<daniels> i'm still digesting nat's last entry
<daniels> i expect to be done next week
<seb128> it was before UBZ
<seb128> how much do you have to catch up? :)
<seb128> daniels: you have not read the blogs about pango, fileselector, etc?
<daniels> ah, I see
<daniels> that thing
<OgMaciel> elmo, excuse me... do u have a minute?
<daniels> well, it won't help *that* much, as you'll likely get stuff with much higher cumulative totals
<daniels> a lot of time in WaitforSomething, f.e. :P
<daniels> interrupting it with gdb will tell you which code path it's hit at that particular point
<daniels> the radeon exa support is much better here, because you can just turn on fallback debugging and have it tell you exactly when and why you're falling back
<seb128> daniels: according to sysprof 81.32% is spent to XAAComposite
<daniels> does it say which child functions it's calling?
<seb128> I like this tool :)
<daniels> into fbComposite*, or RADEONCPComposite*?
<seb128> daniels: http://people.ubuntu.com/~seb128/ati.png
<seb128> daniels: useful for you?
<daniels> very useful, thanks :)
<seb128> grr, switching between windows on the same workspace is slooow too
<daniels> so yeah, falling back to fbComposite -> YOU LOSE
<daniels> don't see *why* it's needing to do that though
<daniels> nautilus shouldn't be doing stupid tricks with argb
<seb128> how do I workaround that? :)
<daniels> heh
<seb128> do you think it's nautilus?
<seb128> or cairo?
<daniels> i386 or amd64?
<daniels> i think cairo, tbh
<seb128> amd64 box but with an i386 install
<daniels> (fb* is the pure-software rasteriser)
<daniels> i'll see if I can get you a debugging i386 build
<seb128> daniels: I can do a xorg rebuild on my box if you want
<daniels> it shouldn't take that long to do an MMX copy though
<seb128> just send me a patch if there is something you want try
<daniels> seb128: if you want to do that and just stick ErrorF("src_x %d, src_y %d, dst_x %d, dst_y %d, w %d, h %d\n", src_x, src_y, dst_x, dst_y, w, h); at the top of fbCopyAreammx in fb/fbmmx.c, that would be useful
<daniels> but yeah, I just don't see how it could be that slow to do a memcpy
<jdub> daniels: it's probably doing it 200 times just for good measure :)
<ogra> jdub, do you care for gamin nowadays ? is there an update in the queue ? 
<seb128> why should he care for gamin?
<OgMaciel> ogra, hi... can you spare a minute?
<jdub> ogra: seb128 does - unfortunately DV still just puts it on his website
<ogra> seb128, because he did once :)
<jdub> seb128: launchpad seems to think so ;)
<ogra> OgMaciel, if its only a minute, yes ... i'm busy preparing a report for the meeting
<seb128> daniels: what source package has fb/fbmmx.c?
<OgMaciel> ogra, can I pvt then? it will take a minute
<ogra> sure
<daniels> seb128: xorg-server
<seb128> k
<daniels> seb128: and just drop obj-i386-gnu-linux/hw/xfree86/Xorg into /usr/bin when you're done
<daniels> so you get debugging
<seb128> k
<ogra> seb128, i'm still hoping for my app menu to magically reappear with a gamin update ;)
<daniels> jdub: planet.g.o is down now.  i demand to know what you plan to do about this.
<seb128> daniels: gnome.org is down
<jdub> daniels: the server was hammered, all the sites are down
<azeem> daniels: man, you're out of luck.  One posting in month and nobody can see it!
<daniels> hammered?
<azeem> s/month/months/
<daniels> azeem: eh, I'm not on p.g.o
<azeem> daniels: d'oh
<daniels> just p.fd.o, p.d.o, planet.slug.org.au and planet.linux.org.au
<azeem> daniels: alexl's posting is linked to by lwn.net, and you can easily read Nat's post till the server is responsive again
<seb128> daniels: speaking about fd.o, Amaranth was saying that pyxdg has no new version because the maintainer his waiting to get is key back to use the CVS again or something, is that you who does that? :)
<daniels> seb128: i saw that ... who's the maintainer who needs a key?
<seb128> (not that I really care, but we could use a fixed pyxdg :p)
<daniels> seb128: i mean, theoretically I'm responsible for that kind of crap but I try to avoid it as much as possible
<daniels> azeem: rad
<seb128> daniels: <Amaranth>     if a fd.o admin ever uploads lanius' key
<seb128> if you know who this lanius is
<daniels> ah, lanius
<daniels> yeah, he pinged me, uh
<daniels> two months ago
<seb128> hehe
<azeem> "Serious problems with Mr. Stone"
<ogra> *giggle*
<daniels> ------- Additional Comments From h_wendel@cojobo.net  2005-12-01 06:39 -------
<daniels> sorry, in the meantime i created a new key, i'll attach it
<Keybuk> right ... so let's see whether shiny-new-initramfs-script works
<Keybuk> sooooo.....
<Keybuk> who has a SATA or SCSI root filesystem and is feeling adventurous? :p
<Keybuk> coz it worketh for me
<jdub> hrm, only on my server :)
<jdub> which is not running dapper yet ;)
<Keybuk> heh
<sistpoty> Keybuk: I guess HPT37X won't count?
<sistpoty> (sata controller handled by hpt37x)
<Keybuk> does it show up as /dev/hda or /dev/sda?
<sistpoty> as /dev/hda
<Keybuk> no, doesn't count then
<Kamion> Keybuk: I do, although I think it already worked
<Kamion> it was the one that showed up as a RAID controller
<wasabi> hmm. /usr/lib/mozilla-firefox/libgtkembedmoz.so has vanished.
<wasabi> Hmm. Nope it's there.
<Keybuk> bah, where's the T43 fan-club when you need them? :p
<fabbione> GOOOOOD MORNING EU EARLYBIRDS
* maswan waves a bit to fabbione 
<zul> hey fabbione 
<dholbach> hellas fabbione 
<fabbione> maswan: hey dude...
<fabbione> maswan: is there any possibility to get buttercup back online?
<fabbione> maswan: we have a workaround for the kernel and soon a proper fix
<fabbione> hi dholbach , zul
* ogra yaaaaaaawns
<maswan> fabbione: yeah, I'll try to get it done, I think we are mostly done with using it as a solaris test install subject, but I'll have to check with the solarisers
<fabbione> maswan: cool thanks
<seb128> daniels: no weird value with the debug outpud
* Keybuk wonders what the fuck is generating the weird "unable to mount /selinux/" error
<dholbach> hey seb128 :)
<ogra> Keybuk, thats ajmitch in your initramfs ;)
<seb128> re dholbach
<seb128> daniels: src_x 0, src_y 1030, dst_x 0, dst_y 2054, w 1280, h 1024
<Keybuk> ogra: what tool is doing that?
<ogra> no idea, but ajmich migh know 
<Keybuk> as long as it's nothing I broke, that's ok
<Keybuk> but it's annoying
<ajmitch> ogra: I didn't touch it
<ogra> ajmitch, but you mght know what it means
<ajmitch> yes, but I'm not sure why it's trying to mount it
<ajmitch> it can't mount if the kernel is booted with selinux disabled (as the default is)
<ajmitch> hi pitti 
<ogra> Keybuk, so dont we boot with selinux disabled anymore ?
<pitti> *yawn* good morning
<jdub> hello pitti!
<ogra> BenC, did that change ? ^^^^
<pitti> Hi jdub, how are you?
<jdub> hot!
<jdub> you?
<BenC> what?
<pitti> jdub: tired
<mdz> infinity: ping
<ogra> BenC, selinux off by default
<ogra> BenC, see Keybuks mumbling above
<BenC> it defaults to off, yes
<Keybuk> ajmitch: what's "it" ?
<BenC> you have to pass selinux=1 for it to be enabled
<BenC> I just took default settings for that based on breezy, so if it's different, it was unintentional
<ajmitch> 'it' being /selinux
<Keybuk> right, but what's trying to mount that and generating the error?
<ajmitch> you get complaints about unknown fs type selinuxfs
<Keybuk> the kernel itself?
* ajmitch hasn't touched anything in that area - the kernel would not be trying to
<Keybuk> gah, need to find a new musical
<BenC> ogra: anything I need to fix?
<ajmitch> the only think I see that changed recently was sysvinit
<ogra> BenC, ask Keybuk :)
<ogra> probably if he finds something
<BenC> Keybuk: anything wrong with the selinux default config?
<Keybuk> no idea
<Keybuk> selinux smells
<Keybuk> I keep far far away from it
<Keybuk> it was there before I broke^Wmerged selinux
<Keybuk> uh, sysvinit
<BenC> heh, it's probably just the stinch of NSA on it :)
<Keybuk> unless it is Manoj's patch
* ogra suspects secret undermining of trulux in the main kernel *g*
<ajmitch> and I haven't been brave enough to reboot yet
* Keybuk disables it
<Kamion> Keybuk: my SATA box boots fine with current dapper; if you want me to try something else, I can
<Keybuk> yup, was manoj's patch
<daniels> seb128: hrm
<Amaranth> *sigh*
<Amaranth> fscking computers
<Amaranth> always breaking
<Keybuk> what's broken now?
<Amaranth> my motherboard
<Amaranth> fans turn on, nothing else, won't turn off
<ajmitch> Keybuk: selinux mounting was debian #329328 ?
<Keybuk> no idea
<Keybuk> I just disabled the entire patch
<Keybuk> I imagine it's fixed in Debian and will get re-enabled when I turn mom on again
<ajmitch> right, the other option is (14:46:49) slb12stephanie: ok thats relieving
<ajmitch> sigh
<ajmitch> export SELINUX_INIT=NO
<Keybuk> where do you do that? :p
<Keybuk> how do you export something to _INIT_
<ajmitch> it says in the initrd, so in initramfs, no?
* ogra screatches head about malone #5492 and wonders if mdz could have a look there after meeting
<ajmitch> or as a kernel option if you want to
<Keybuk> I thought run-init purged the environment?
<Keybuk> otherwise all the initramfs variables would be leaked to the world
<jdong> Breezy doesn't support dm-bbr?
<jdong> I thought Hoary did
<Amaranth> dm-bbr?
<jdong> evms/device mapper's bad block relocation
<jdong> i.e. handling bad sectors at a level below the filesystem
<jdong> [4482447.706000]  device-mapper: unknown target type
<jdong> dm-bbr.ko not in Ubuntu kernels
<jdong> heh, not in Ubuntu kernel sources for Breezy
<jdong> hmm
<jdong> and to think we use evms and don't support its features... :-/
<whiprush> jdub: CC/a11y summary in the fridge queue if you want to check it out.
<Keybuk> fabbione, mdz: for dapper, I recomment only using /dev/disk/by-* for removable devices (which all appear as SCSI)
<mdz> Keybuk: oh, that's a good criterion
<Keybuk> for dapper+1 we can convince the kernel guys, or do ourselves, to add some "WAIT! THIS BUS IS NOT READY YET!" flag to /sys we can wait on
<Riddell> infinity: please give back gwenview again
<fabbione> Keybuk: hmmmm
<fabbione> so why i can see my ata disks there?
<Keybuk> because it's generic and done for every block device
<Keybuk> what won't work is the initramfs bit :)
<Keybuk> it'll fail for people with non-PCI/generic ide controllers because the initramfs won't know it needs to load ide-generic
<fabbione> Keybuk: ok.. i think it's better to defer the specs than.
<fabbione> we don't want to be so inconsistent in such delicate part of the installer
<Keybuk> it'll work fine for SATA drives
<fabbione> Keybuk: i don't think we want to play with this for dapper.. this really sounds something for dapper+1
<Keybuk> by dapper+1 we may find that the kernel guys go with their plans to move all the old ide drivers into libata
<fabbione> yes, and i think for the sake of consistency we should avoid dapper
<HrdwrBoB> Keybuk: if that was the case, installing to USB would work
<Keybuk> you should be able to install to usb now
<HrdwrBoB> you can, but it won't boot
<Keybuk> will
<Keybuk> just change the root= line
<HrdwrBoB> because the device waits to settle, and the initrd tries to boot
<HrdwrBoB> then fails
<Keybuk> initramfs waits for the device to settle now :)
<HrdwrBoB> ah :)
<whiprush> jdub: MOTU school announcement in the queue also, I think we should run that one on friday though.
<mdz> fabbione: we should do it for cases where otherwise the install doesn't actually work properly (e.g., USB)
<mdz> I think Keybuk's idea of doing it only for removable devices is safe and will fix some bugs
<fabbione> mdz: i disagree. even an IDE disk can be removable
<fabbione> and we have no way to know if it will be shuffled around
<fabbione> it creates a big inconsistency in the installs
<mdz> fabbione: the kernel has a concept of removable devices; that's what I'm talking about
<mdz> e.g., flash media and USB
<fabbione> mdz: i have a USB disk..
<fabbione> it's a 2.5"
<fabbione> that's something i stick into laptop's and becomes IDE
<Keybuk> fabbione: if an IDE disk is removable, it doesn't show up as an IDE disk
<fabbione> Keybuk: it might in the next boot
<fabbione> go figure
<fabbione> user case: my cdrom is broken and my laptop doesn't boot from netcard
<fabbione> i stick my hd in a usb thingy
<fabbione> install ubuntu put it back in the laptop
<fabbione> assuming that we claim to be able to recognize root, that will just be bad
<ogra> Kamion, do you think flight 2 might happen this week ? 
<Keybuk> right, but that's new functionality
<fabbione> mdz: i really really believe that this is not material for dapper. either we can be consistent, or we skip
<Keybuk> if we just advertise it and test it for known-removables like installing to USB
<Keybuk> and worry about the "move things around" for dapper+1
<fabbione> Keybuk: i still don't like it really.. let's do it for dapper+1 and do it properly, once. it sounds too hairy to me to go around and check if drivers are removable or not, try to guess and so on
<Keybuk> that's easy
<Kamion> ogra: depends largely on how much work fixing casper turns out to be
<mdz> Keybuk: surely we can use a smarter test than looking at root= and address it that way
<Keybuk> mdz: if you can think of one, I'm all ears
<ogra> Kamion, ok, i just want to know if i need to push my ppc dealer :)
<Kamion> ogra: 3am is not the best time to ask me this kind of question ;)
<mdz> Keybuk: we need to know before the device is created?
<ogra> Kamion, sorry ... :) i'm used to it, normally up until 4 :)
<mdz> Keybuk: it still seems like a kernel bug to me
<Kamion> my normal bedtime is more like 11 these days
<Keybuk> yup
<Keybuk> we need to know what bus it's on in order to do the right thing to create the device
<Keybuk> I'm inclined to agree
<Keybuk> the kernel doesn't inform us that the driver is still poking around
<Kamion> zul: I do think it'd be more helpful to get Flight 2 out and then ping people to retest with that
<ogra> Kamion, yes, forgot, youre a father now ;)
<Kamion> (grub)
<Keybuk> if there were a sysfs attribute to say whether the driver was scanning the bus or not, it'd be easy
<Kamion> just because that gets us 0.97
<Kamion> ogra: stepfather
<Kamion> important distinction around here
<ogra> still a child involved :)
<Keybuk> IDE is actually helpful, it doesn't let modprobe exit until it's claimed all the devices it wants
<Keybuk> SCSI isn't helpful, it lets modprobe exit and then starts poking around
<zul> Kamion: sure no problem...just going through them
<Keybuk> and anything implemented using SCSI (SATA, USB, IEEE1394, etc.) gain this unhelpfulness
* ogra wonders how the heck ltsp-client-builder ended up on launchpad ....
<ogra> thats such a mess ... people just register packages randomly
<Keybuk> if we could wait for a scsi driver to stop scanning for devices in a udev rule, the job would easy
<Keybuk> 1) poke every storage controller we can find
<Keybuk> 2) if $ROOT still doesn't exist, try loading ide-generic
<Kamion> zul: you may also find some bugs filed on grub-installer
<Keybuk> without a way to know whether the driver is scanning (where we are now) we can't do #2 because #1 hasn't finished
<Keybuk> the only way to know whether the driver has finished scanning is to loop until $ROOT exists, and for scsi (especially usb) that can take up to 30s
<Keybuk> and I'm inclined to think people with ISA/generic IDE controllers won't be happy about that 30s wait
<Keybuk> (we actually have requests to make that wait up to 3 MINUTES)
<Amaranth> top forums guys are threatening to split if the CC tries to say they have any control over their operation
<Keybuk> (and to truly support usb root, we should make that wait forever, to allow them time to find it and plug it in)
<zul> Kamion: i selected all of grub* in my bug query 56 bugs found
<ogra> sounds like we should put up a motto for the next bugday ... call it gub bugday or something to point bugsquasher to them
<ogra> s/gub/grub
<zul> ogra: kernel has 500+ ;)
<zul> ogra: kernel has 500+ ;)
<ogra> zul, kernel has an upstream ;)
<zul> brb
<ogra> who eventually fixes bugs :)
<Kamion> so does grub to some extent
<ogra> i thought its unmaintained
<Kamion> as I said in the meeting we got a new upstream release relatively recently
<ogra> v1 that is
<Kamion> it's not very actively maintained but the maintainer does IME respond to mail, at least eventually
<ogra> ah, k
<Kamion> I'm not sure general bug-squashing manpower helps with grub; you need a lot of specialist boot knowledge
<Kamion> or else you end up just flailing around saying WORKSFORME
<ogra> usually the bugday squashers only confirm etc ... 
<Kamion> Amaranth: please, that isn't an #ubuntu-devel issue
<ogra> but you could get them o do all the paperwork of pinging reporters etc
<Kamion> what I really don't want is people repeatedly pinging reporters when there's no possibility that a bug has been fixed
<Kamion> that just annoys reporters and eventually they stop answering you ...
<Kamion> anyway, bedtime
<ogra> night Kamion 
<zul> same here..
<zul> night
<ogra> night
<Keybuk> yup, definitely bed time
<Keybuk> back in ~8hrs
<jdub> mjg59: not sure it's crucial functionality
<jdub> mjg59: but if it's a quick patch, it'd be way sweet
<mjg59> jdub: No, but getting beyond just hanging the machine would be good
<jdub> mjg59: have you seen any Z series machines yet?
<mjg59> jdub: We can get at least as good as the people using hdparm to register/unregister their IDE bus, which is what currently happens
<jdub> winkle: 13
<jdub> boh
<mjg59> jdub: I haven't, no
<mjg59> jdub: You? I'm curious to know how Thinkpad-like they are
<jdub> me too
<whiprush> howdy jdub.
<jdub> have to think about my next machine
<lifeless> x1
<lifeless> you know you want to
<mjg59> jdub: Just tested
<ogra> bah, you dell addicts
<mjg59> jdub: Pulling out the CD drive just closed the Nautilus window open on it
<jdub> lifeless: don't really want a keyboard that size
<mjg59> jdub: Putting the CD drive back in mounted the CD in it automatically
<jdub> i'm really only looking at X40, possibly Z series at this point
<jdub> i was very happy with the formfactor of the X300 (plus it had a trackpad)
<jdub> mjg59: phwoar, rad :)
<lifeless> keyboard is the same ;)
<mjg59> jdub: With a file selector open on it, ripping out the CD drive just removes the CD drive from the left pane and blanks the right pane
<mjg59> We are /so/ shipping this patch
<jdub> pipka will love you for that :)
<jdub> lifeless: the X1 keyboard was not the same as the X300
<mjg59> jdub: And putting the drive back in results in the files appearing in it again
<lifeless> mm, felt the same to me
<jdub> (of course, that will make her ask if she should upgrade to dapper again)
<mjg59> jdub: So now I just have to figure out a way of doing it for PATA (or convince Ben that switching to the somewhat experimental PATA/libata drivers is a good idea)
<jdub> and perhaps whiltelist the good ones of those?
<mjg59> jdub: The only really interesting ones are the Intel and VIA ones, really
<mjg59> Unless Alan writes an ATI one
<jdub> can we choose between ide layer and libata drivers like that?
<mjg59> There are two issues:
<mjg59> 1) They claim the same PCI IDs. Without blacklisting/whitelisting/something then we're not sure which one we'll get
<mjg59> 2) They result in people's drives moving from hda to sda, and we have to work out how to manage that transition
<mjg59> jdub: At the moment, I'd lean towards building them but not having them loaded by default - then people can play if they want to, but I doubt they'll be ready for primetime by Dapper
<wasabi> One of these days I've like to see EVMS be used by default for everything. ;)
<jdub> i'd like to see zfs on linux instead :)
<ogra> ogra@honk:~/dapper-xss/bastel/xscreensaver-4.23 $ free
<ogra>              total       used       free     shared    buffers     cached
<ogra> Mem:        506164     500124       6040          0       1232      25224
<ogra> -/+ buffers/cache:     473668      32496
<ogra> Swap:       979956     556660     423296
<ogra> hmm, i have xchat, evolution and 2 terminals open 
<wasabi> How does ZFS fix this?
<wasabi> What's so great about ZFS anyways he
<wasabi> oh, uh, checksums.
<wasabi> Wow.
<jdub> there's a great presentation by jeff bonwick which is well worth reading
<jdub> that goes through the salient points
<SEJeff> link?
<wasabi> google.com
<jdub> googleable, i'm sure - it's just sitting on my desktop atm
<ajmitch> ogra: that's looking a little heavy
<daniels> jdub: so are you in melbourne today?
<ogra> ajmitch, killing evo freed 800MB
<daniels> jdub: or is that tomorrow?
<jdub> daniels: nup, back home
<daniels> jdub: bastard.
<daniels> YOU DON'T LOVE ME ANYMORE
<daniels> you and pipka not having lunch and/or beer with me is against the code of conduct
<jdub> yeah
<SEJeff> But I don't think zfs supports online resizing. ext3 does so ext3 makes more sense for a server
<jdub> eh? dude. read up.
<jdub> zfs is intensely cool for a server
<jdub> totally different kettle of fish to ext3/lvm/evms
<wasabi> Hmm.
<wasabi> Raid built into the file system.
<mjg59> daniels: If you continue with this criticism, you'll be banned and have your posts deleted
<SEJeff> I just found the article. Checksums and other niceties. http://www.sun.com/2004-0914/feature/
<ajmitch> ogra: usually it's firefox or galeon that does that for me :)
<seth_k> mjg59, NOOOOO, don't make me have forums flashbacks, I'm already banned from there :P
<ogra> ajmitch, i started it again and it immediately claims 200M of ram and 300M of swap ... 
<wasabi> This is hilarious: http://blogs.sun.com/roller/page/bonwick/20040925
<wasabi> I do actually wonder how hard it would be to create a OpenSOlaris/LInux fs bridge
<jdub> mmm, usb over ip patches proposed by gregkh
<wasabi> usb over IP?
<wasabi> I might actually have a use for that.
<wasabi> So might LTSP heh
<ogra> yeah
<ogra> jdub, got an url ? 
<wasabi> http://usbip.naist.jp/
<ogra> ah that one.. iinspected it for ltsp local devices
<jdub> BenC: will dapper kernels on breezy be scary?
<ogra> wasabi, but jdub sounded rather like it'd be a upstream kernel thing ...
<Amaranth> jdub: Hotplug went away, I'd say that's a given.
<wasabi> ogra, dunno, maybe that one was submitted? I dunno
<ogra> wasabi, pre alpha ? 
<ogra> unlikely
<ogra> lats release 20041130
<infinity> Yeah, there's never been pre-alpha code in Linus's tree...
<ogra> *last
<infinity> The part where it's unmaintained since 2004 is a bit worse, though.
<fabbione> ogra:
<fabbione> Unpacking replacement xscreensaver-data ...
<fabbione> dpkg: error processing /var/cache/apt/archives/xscreensaver-data_4.23-2ubuntu3_amd64.deb (--unpack):
<fabbione>  trying to overwrite `/usr/share/xscreensaver/config/README', which is also in package xscreensaver
<StevenK> Whee.
<infinity> fabbione : I just uploaded a fix for that.
<fabbione> infinity: ok thanks
<jsgotangco> hey moquist long time no chat
<tux-rox> jdub, just wanted to say thanks for the great presentation at PSU. I brought a friend along who is relatively new to FOSS and she also enjoyed to talk as well.
<jdub> tux-rox: cool, thanks :)
* jdub had fun in portland again, despite the winter!
<tux-rox> Ya, you were here at a strange weather time. It is usually not so crappy...
<tux-rox> Rain, yes, but it was a bit colder than usual for this time of year.
<tux-rox> Anyhow, I am glad you enjoyed the visit. Take care.
<sivang> morning all
<pitti> Good morning
<Mithrandir> hi pitti
<pitti> Hi Tollef
<dholbach> good morning
<\sh> moins
<\sh> grrrr..fighting with dd-wrt on linksys and wanting wireless xdmcp sessions 
<ajmitch> hi
<pitti> infinity: thanks for cleaning up m-f-l-all
<pitti> Riddell: ping
<dholbach> he uploaded until 5 - i doubt he's awake
<dholbach> past 5
<doko> chmj: pong
<chmj> doko: nm, figured out 
<slomo> infinity, lamont-away: any idea why mod-mono isn't even tried to build on ppc/ia64? should work fine imho
<tseng> slomo: its probably blacklisted from way back
<slomo> tseng: why? was it completly broken in the past?
<tseng> slomo: at one point mono* was broken :)
<ogra> fabbione, sorry, Riddell reported exactly the opposite, thats why i "fixed" it in first place yesterday, jdub has the same prob as you
<Diziet> Bizarre.  The postman just called and has delivered a document to do with a lawsuit in the US about VA Linux.  Somehow, apparently, I was hard done by in an unfair and illegal way, when they gave me free money.  Boggle.
<lifeless> woo
<Diziet> It seems to suggest that because they so unfairly gave me free money earlier, I might be entitled to compensation now.  I think it must be a get-very-rich-over-many-years scheme for lawyers.
<Diziet> When I get a moment I think I'll post to debian-devel or -private about it.  Presumably other people from the time of the VA IPO will have had them too.
<Mithrandir> so since you were given free money, they are giving you more free money?
<Diziet> Something like that.  Actually I think mainly lawers will get money.
<Diziet> It's all quite dense and I haven't read it properly.  When I have I'll post to debian-devel, I think.
<Diziet> But now I should do some actual work rather than boggling at the mad USAian legal system.
<pitti> Mithrandir: hm, if you actually changed something in nmap, it shuold be -ubuntu1, not -build2
* Mithrandir blames emacs.
<pitti> Mithrandir: oh, not dch?
<pitti> :)
<Mithrandir> no, the emacs-changelog mode.
<Mithrandir> pitti: anyway, thanks, fixed.
<pitti> thanks
<seb128> daniels: around?
<pitti> speaking of daniels, am I the only one who experiences video driver regressions with both nv and ati?
<pitti> on nv I get flickering while pressing keys, on radeon my screen gets scrambled and colored oddly
<seb128> pitti: ati on ppc?
<pitti> seb128: yes
<pitti> and nv on amd64
<seb128> pitti: does using 16bpp fixes it?
<pitti> seb128: no idea, I just filed a bug so far, but didn't play with it
<Kinnison> pitti: breezy + nvidia + amd64 is definitely a regression from hoary
<pitti> Kinnison: I don't use the nvidia driver, just the opensource nv one
<Kinnison> pitti: breezy + nv + amd64 doesn't render stably on my boyfriend's pc
<seb128> pitti: the ati/ppc issue is likely http://bugzilla.ubuntu.com/show_bug.cgi?id=20286
<Kinnison> pitti: It puts snow and distortion on the screen
<pitti> Kinnison: and it worked fine on breezy, regression is on current dapper
<Kinnison> pitti: Hmm
<seb128> pitti: if using 16bpp fixes it, that's this bug
<Kinnison> pitti: I think the quality of the driver is regressing because for my rob, hoary was fine, breezy was slightly not worky
<pitti> seb128: ah, cool; I'll check that and close mine as a dup then
<pitti> seb128: thanks Seb (you have an awesome memory for bugs :) )
<seb128> np ;)
<seb128> (not really, this bug was just assigned to nautilus and I sorted that with daniels this night before meeting :p)
<slomo> pitti: i have the same problem with a radeon on ppc
<pitti> slomo: I'm fairly sure it's the same bug as I have, but I'll check it
<pitti> I need to boot the iBook first, sleep doesn't work any more
<slomo> pitti: hm, works for me
<zyga> guys how long does it take for new members to appear on the official list on launchpad?
<pitti> slomo: well, it works with 2.6.15, but this breaks my wireless; and with 2.6.12 I don't get /dev/pmu any more with new udev
<slomo> pitti: hm, i unplug my usb wireless thingie every time before sleep... the airport extreme doesn't work with wep currently
<pitti> slomo: I use prism2_usb (l-wlan-ng), it doesn't work with 2.6.15 any more; which driver do you use for the usb?
<slomo> pitti: exactly the same... weird
<pitti> slomo: https://bugzilla.ubuntu.com/show_bug.cgi?id=20498
<slomo> pitti: i get this message about /proc/net/wireless too but it works nonetheless
<pitti> slomo: hmm, thanks; which usb card do you have? I have a Netgear MA-111
<slomo> pitti: d-link dwl-122
<janimo> is ALSA supposed to work with current kernel/udev already?
<pitti> janimo: WFM
<janimo> forgot what that means :)
<pitti> works for me
<janimo> aha
<janimo> automatic eth interface bringup?
<pitti> mvo: hm, poppler-utils C/R/P xpdf-utils since hoary
<pitti> mvo: so it seems that only the versioned dependency of xpdf should be dropped
<mvo> pitti: fine with me
<seb128> Diziet: do you have some bug about /usr/lib/mozilla-firefox/components/compreg.dat still installed on dapper?
<seb128> Diziet: it's shipped by firefox 1.0.7 package but no 1.4.99, it should be removed on upgrade, no?
<slomo> elmo_: can you sync from debian NEW?
<pitti> slomo: we don't do it in general, we wait for Debian's sanity checks
<seb128> pitti: it's for binary change
<seb128> ie: not a new NEW package
<Kamion> syncing from Debian NEW would require elmo to use his position as a Debian ftpmaster to work on Ubuntu, since NEW isn't public
<Kamion> I don't know if he does it or not but if I were him I'd be worried about mixing up the hats too much
<Mithrandir> incoming is fine to sync from, though
<Kinnison> Kamion: I'd have invited you to come to the kingston but I don't have your home number and your mobile is off. You should join us :-)
<Kamion> yes, incoming's basically "pending part of the archive but apt-ftparchive's too slow to run continuously"
<Kamion> (etc.)
<Kamion> Kinnison: ooh. when? now?
<Kinnison> Kamion: aye
* Kinnison is sat with some smokestack lightning and has a venison in entire-stout on order
<Kamion> Kinnison: ok, I'll head out in five
<Kinnison> Kamion: I think there's parking space in front of the pub
<Kinnison> Kamion: otherwise there's room in the gwydir st car park
<Robot101> Kinnison: are you at the Kingston perchance? :D
<Kinnison> Robot101: of course
* Robot101 reads sb... hmmm....
<Kinnison> Robot101: smokestack lightning
<Kinnison> So good
* Kinnison purrs
<GnuKemist> elmo_, good morning...  can you help me change my email on launchpad from og-maciel@ubuntu.com to ogmaciel@ubuntu.com (no dash)?  I need to be able to give people I've been advocating to my corrected email...
<jbailey> wasabi: ping?
<mvo> Diziet: mind if I reassign #13750 to you (ff enhancement request)?
<ssam> is there a due date for flight 2?
<ssam> http://bugzilla.ubuntu.com/show_bug.cgi?id=8320#c11 implies its out now
<seb128> daniels: ping?
<Kamion> ssam: no, and it's not out
<Kamion> ssam: the comment is valid for the future :-)
<Keybuk> well, that's gotta be good.  I've been on for a while and nobody's jumped one me yet
<ssam> kamion thanks
<ogra> oooh Keybuk !!
<pitti> Keybuk: run!
<ogra> Keybuk, just wanted to say good morning ;)
<Keybuk> heh
<Keybuk> ogra: how's your laptop this morning?  do you have dma?
<sivang> anybody idea what's with the fridge? it seems down..
<ogra> yup
<zakame> er, is it possible for pdebuild to sign both {source,$arch}.changes? I currently have it so that it signs only $arch.changes, but not the source.changes...
<ogra> Keybuk, everything fine over here
<Keybuk> good-o
<ogra> zyga, http://people.ubuntu.com/~ogra/bzr-archive/hwdb-client/ this is for you ... but beware, the code is a mess, i'll jump on it the next days and rearrange/clean up a lot
<zyga> ogra: thank you :-)
<zyga> ogra:I'll have a look in 30 minutes, most of my patches should be non-intrusive
<ogra> oki
<ogra> BenC, for your kids (i'll package it the next days, but if you need it soon, grab it) https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=226
<BenC> ogra: nice, let me know when it's ready and I'll test it
<ogra> yup :)
* sivang waits for the fridge to go back up again.
<lamont-away> %mod-mono: amd64 i386                                                  # i386-only, but should it be?
<lamont-away> slomo: that's why... should we change it?
* lamont-away fixes
<slomo> lamont-away: i see no reason why it shouldn't build on ppc/ia64... but if you want i can testbuild on ppc in a few minutes
<lamont-away> I just made it the same as the rest of the mono packages
<slomo> lamont-away: thanks... what is it for the other mono packages? i386, amd64, powerpc, ia64?
<lamont-away> %mod-mono: amd64 i386 powerpc arm ia64 s390
<slomo> ok :)
<Diziet> python--
<Diziet> >>> output = Popen(["false", "diedammit"] , stdout=PIPE).communicate()[0] 
<Diziet> >>> 
<seb128> Diziet: have you read about http://bugzilla.ubuntu.com/show_bug.cgi?id=20183 ? It makes all apps using gecko crashing on some boxes, would be one of the bug nice to sort :)
<crimsun> elmo_: please sync osdsh and lablgl from Sid (ok to override Ubuntu changes), thanks
<pitti> Riddell: here?
<Diziet> seb128: Yes, um, I'd seen it but I'm confused about it.
<Diziet> You say this file (compreg.dat) is supposed to be removed.  So do we know why it isn't ?
<seb128> Diziet: I supposed it's supposed to be removed, it's not installed on my dapper
<seb128> the package .list doesn't mention it
<seb128> and it was listed with 1.0.7
<Diziet> Are you sure that the package is supposed to be removed ?  Perhaps it's a mistake that it has disappeared.
<Diziet> I can't see how it would fail to go away during the upgrade if it's in the old package but not the new one.
<seb128> if a file is shipped by 1.0.7 and not 1.4.99, it's supposed to be removed by dpkg on update, no?
<Diziet> Yes.  Except perhaps if it's a conffile.
<seb128> there was some symlink stuff to /var too with 1.0.7, but I don't know firefox well, just discussed with epiphany upstream
<seb128> I just know that we have like 4-5 bugs now of people have gecko apps crashing with firefox1.5
<seb128> and we tracked the crash this morning to this file, removing it fix the issue and it's not installed on my box/listed as a firefox file ... ie: it should not be here
<seb128> $ grep compreg /var/lib/dpkg/info/firefox*
<seb128> /var/lib/dpkg/info/firefox.prerm:    rm -f /var/lib/mozilla-firefox/components/compreg.dat
<Diziet> /var/lib ??
<seb128> <chpe> firefox.list:/usr/lib/mozilla-firefox/components/compreg.dat
<daniels> seb128: REPRESENT
<seb128> <chpe> here on breezy it's a symlink to /var/.... ?
<Diziet> So on the systems that have the file, where it's breaking, what does  dpkg -S  say ?  And what about  dpkg -s firefox  ?
<Diziet> symlink to var> So it is, on my breezy install too.
<seb128> <chpe> doctau: does /usr/lib/mozilla-firefox/components/compreg.dat exist ?
<seb128> <doctau>       yep
<seb128> <chpe> what does dpkg -S say for that file? is it installed by the package?
<seb128> <seb128>       chpe: nop
<seb128> <doctau>       not owned by a package
<Diziet> I don't see how compreg.dat could be in firefox.list if they've got the new firefox package.
<Diziet> ????
<seb128> Diziet: chpe uses breezy with 1.0.7
<seb128> doctau uses 1.4.99
<seb128> sorry for not beeing clear
<Diziet> Ah.
<seb128> and according to chpe, /usr/bin/firefox does some stuff with this file on breezy
<Diziet> So which machine doesn't work ?
<seb128> the issue is with current dapper
<seb128> some people have this file and they should not
<Diziet> doctau's machine then ?
<seb128> yep
<seb128> some people have it and it doesn't come from a package according to dpkg
<Diziet> Oh, err, just a mo, I have an idea.
<Diziet> Let me think.
<Diziet> I'm guessing here, but here's my theory:
<Diziet> This file is a registry of components including extensions.
<Diziet> If you have pre-1.4.99 extensions installed then this compreg.dat file is updated by those extensions somehow, normally.
<Diziet> But the 1.0.7 package makes it a symlink to /var so the file ends up in /var.
<Diziet> Now the 1.5 package removes the symlink.  Then if anything were to try to create the file in /usr it would just go ahead and do so.
<Diziet> So we need to find out who is creating this file.
<Diziet> I'm tempted to suggest a test version of the ff 1.5 package which does chattr +i on it.
<Diziet> Also, I suppose if you have ff running as root when you upgrade it might manage to create this file somehow.  I have no idea what bits of the ff and extensions touch it.
<seb128> hum, maybe yeah
<seb128> but is it useful?
<seb128> maybe firefox postinst should just clean it?
<seb128> if -f ... rm -f it
<Diziet> What, this file ?  Evidence suggests that the file is not used in 1.5.
<Diziet> Err, how would that help ?  dpkg has already removed it.
<Diziet> The problem is obviously that something is creating it again later.
<seb128> right
<Diziet> And it has to be something than runs as root.
<Diziet> s/than/that/
<Diziet> So my best guess at the culprit is some extension or embedder's maintainer scripts, probably indirectly.
<Diziet> Obviously normal dapper systems don't have this.  So I suspect that it happens when you run an old Breezy package's maintainer scripts when that package is updated after ffox.
<Diziet> What do you think of my theory ? :-)
<Diziet> Let me think what the best way to test it would be.  Hmm.  Install breezy (or find a not-yet-upgraded breezy system).  Update just firefox.  Create this file again as a symlink to /dev/enoent/firefox.
<Diziet> Then do the rest of the upgrade.
<seb128> doctau has installed a dapper flight1
<seb128> which had firefox 1.0.7
<Diziet> Or alternatively make a firefox 1.5 package which has /usr/lib/mozilla-firefox/components/compreg.dat -> /dev/enoent/firefox
<seb128> and upgraded since
<Diziet> Mmm.
<Diziet> But so did I and it doesn't do it for me.
<Diziet> Presumably doctau has more extensions and stuff than I do.
<seb128> note than doctau doesn't use firefox
<Diziet> Does this mainly seem to happen with epiphany ?
<seb128> I'm not even sure it runned firefox once before, I'll ask him
<seb128> the file breaks gecko (epiphany doesn't run, devhelp/yelp crash)
<seb128> firefox works fine
<Diziet> Is this epiphany etc. built against ff 1.0.7 -dev packages ?
<seb128> no
<Diziet> Hmm.
<seb128> that's the current dapper i386 package
<seb128> and I've updated the Build-Depends to say >= 1.4.99
<seb128> 1.4.99something to be exact, where something is the version you didn't built staticly :)
<Diziet> How about this for a plan: since we have a workaround (delete the file) I will postpone dealing with this until my next round of firefox maintenance (ie probably at least a week).  In the meantime if any information surfaces about what creates the file we can add it to the bug report.
<Diziet> I'll change the bug priority to P1 to make sure I pick it up later.
<seb128> Diziet: fine with me. I was just pointing it as something we want to try to sort before 6.04, no hurry
<Diziet> Right.  Indeed, thanks for drawing it to my attention and helping out.
<Diziet> seb128: Done, thanks.
<seb128> Diziet: np, thank you :)
* mvo needs to buy some stuff now, bb in 1h
* maswan mumbles a bit about flight-1 being too ancient to install on his hardware
<zyga> ogra: how do you properly translate help calls (yelp) that has /C/  inside, should I add magick that makes C -> locale?
<ogra> i'd be grateful if you did, yes ;)
<Keybuk> yup
<Keybuk> ww
<Riddell> pitti: hi
<zyga> ogra: gaa, you are using a mixture of tabs and spaces
<zyga> ogra: can we agree on a tab-or-space style? I prefer spaces
<ogra> i prefer tabs :) 
<zyga> ogra: any vim settings you use?
<ogra> but switch it as you like, i can handle it
<zyga> ogra: that will make the diff huge
<ogra> only default vim
<ogra> as i said, the code is ugly as hell :)
<ogra> so i'm expecting ugly big diffs ...
<zyga> ogra: hmm, so you wont mind if I retab everything and do all sorts of cleanups?
<ogra> nope, not at all ...
<zyga> allright, thank you :)
<slomo> BenC: any idea when you will look at the libraw1394 update i sent to you? some packages are waiting for it now :/
<BenC> slomo: someone in debian is supposed to do the new package and push it through their mentor/proxy
<BenC> I honestly haven't  had the time to even think about it
<BenC> check the bug reports on it, and you can find the guy that is wanting to do it
<BenC> ping him for progress
<slomo> ok, i'll do it on saturday... i've no time before :/
<BenC> this was about a week ago, so I was really expecting it to be done by now
<zyga> ogra: http://ubuntu.suxx.pl/hwdb-client--main 
<zyga> ogra: just my branch, not done at all
<ogra> zyga, great, i'll monitor it :)
<fabbione> elmo_: can you please sync util-linux from sid. ok to override ubuntu changes
<fabbione> (in incoming)
<lamont> elmo_: also postfix, same story
<zyga> ogra: just a question: in hwdb-bastel, the longish filename... what is it supposed to do?
<zyga> (it looks like it's supposed to be random')
<ogra> hmm, i have a bastle foler in there... oops... didnt notice
<zyga> bastle?
<ogra> oh, no its not a folder ...
<Kinnison> Everyone: Kamion has had a disk failure in his server and thus will be offline for a while
<ogra> thats the server side, its accidentially in there ...
<zyga> ogra: k, I'll leave it as is
<ogra> zyga, ignore it, i'll remove it
<ogra> the filename is the actual filename that gets bzipped and uploaded btw
<zyga> I see
<ogra> the app generates a md5 sum of the file which becomes the filename ... and the HW id on the server for this record
<zyga> ogra: hmm, other issue
<zyga> you do .startswith and endswith often
<zyga> that smells sensitive to gettext corruption
<ogra> yup, that'll be part of the cleanup
<ogra> my string handling skills in python were quite bad back then, it has improved, dont worry ...
<ogra> if you want to change ti, feel free, elsewait until i get to it ...
<ogra> (note it wasnt touched at all in berrzy, i only fixed 2-3 minor bugs) 
<ogra> *breezy
<ogra> also the xml handling will see a rewrite
<zyga> hmm
<zyga> actually I dont mind endswith and such
<zyga> I'm just not sure on how to handle those
<zyga> I cannot wrap that in _()
<zyga> it needs a smarter test
<ogra> yup
<zyga> all I did so far was the non-intrusive changes
<ogra> ok
<zyga> now I'm looking at the hard bits
<ogra> thats good for a start
<zyga> I still need to read everything and understand how this works exactly
<ogra> heh, might be hard :)
<zyga> nah
<zyga> I'll learn how to use xml from python
<zyga> :-)
<ogra> its rather perl style written in another lang, so it suffers in this area 
<zyga> hehe
<ogra> (i must admint that i'm shocked myself by the code somethimes :) )
<ogra> -h
<zyga> I like python
<zyga> it forces clean code somehow
<zyga> unlike perl that loves !@!#%@53436 for variables
<ogra> me too, but i just had started with it when i started hwdb
<Diziet> Punctuation isn't dirty, you know.
<zyga> Diziet: only when spelled 'punctuation' ;-))
<ogra> and the odd thing is that you can still write it lik a perl app even if its python
<zyga> ogra: I had tabstop=4  so your code looked like random indent
<ogra> just omit brackets and smicolons *g*
<zyga> heh
<zyga> :)
<zyga> k, back to work
<Diziet> zuga: So how do you spell it ?
<zyga> Diziet: punctuation, do not confuse with , . ; : _ and other such maddnes
<Diziet> I see.  What a strange opinion.  I find Python *very annoying*.
<paxer> hi who is responsible for the NetworkMagic Spec?
<tseng> paxer: last i heard Keybuk 
<Diziet> https://launchpad.net/distros/ubuntu/+spec/network-magic
<Diziet> That info is supposed to be up to date.
<paxer> mhh I would like to help, because the current wifi situation in breezy sucks.
<paxer> Diziet, I didn't found any CVS or impementing specific information.
<Diziet> You mean, a link to the source, etc. ?
<paxer> yes
<paxer> something to start up with anything
<Diziet> I think you should probably talk to Keybuk since he's the assignee.
<Diziet> (If you're serious you should probably subscribe to the network-manager upstream list, too, although it's quite noisy.)
<paxer> ok thanks, I have ne experience in the ubuntu development process, so I thought I better ask here, before spaming some harmless persons
<paxer> How is the code management handelt in general? is there something like a ubuntu cvs? or has every project an own cvs / subversion solution?
<zyga> paxer: ubuntu uses bzr
<paxer> have you some URL for me, where I can get an overview?
<paxer> I found it myself :)
<mdke> bazaar.ubuntu.com 
<paxer> thx
<mhz> hi
* zyga goes to deliver cd, bbl
<ryanpg> pitti, hi I see you've closed bug 20564 (udev ieee1394 rule permissions) but... it still doesn't work for me
<pitti_> ryanpg: even with the latest udev?
<ryanpg> yes
<pitti_> ryanpg: what are your device permissions now?
<ryanpg> one sec
<ryanpg> brw-rw---- 1 root disk 8, 3 2005-12-08 09:48 sda3
<pitti_> ryanpg: blame Keybuk :)
<pitti_> ryanpg: sorry for that, please reopen the bug then
<Keybuk> what's the device?
<ryanpg> ok
<ryanpg> firewire hard drive
<pitti_> ah, good test case
<Keybuk> you have /sys/block/sda/sda3 ?
<ryanpg> yes
<Keybuk> ok, can you supply the output of:  udevinfo -a -p /block/sda/sda3
<ryanpg> yes I'll add it to the bug
<Keybuk> and while you're doing that, I'll put an extra "e" in the rule
<thierry_> seb128 : don't wan't to stop you doing important stuff, but could take a fast look at malone bug 5544 ?
<pitti_> Keybuk: heh, just saw it
<Keybuk> ryanpg: edit /etc/udev/rules.d/40-permissions.rules
<Keybuk> change BUS=="iee1394" (near the top) to BUS=="ieee1394"
<ryanpg> yeah I'm doing that ;P
<Keybuk> then sudo udevplug /sys/block/sda/sda3
<Keybuk> and see if the permissions become right
<ryanpg> yep
<ryanpg> 60640
<Keybuk> uh, I mean the group
<ryanpg> oh duh sorry... one sec
<ryanpg> plugdev
<Keybuk> goodo
<pitti_> \o] 
<pitti_> \o/ even
<ryanpg> now do I need to restart hal
<pitti_> although the first one could be 'scratching my head' :)
<pitti_> ryanpg: shoudn't be necessary
<pitti_> ryanpg: just unplug/replug should do
<ryanpg> hm... well it's still not working :(
<ryanpg> nothing mounted... but I've got a meeting I have to attend
<pitti_> ryanpg: can you please do the DebuggingRemovableDevices tour again now?
<pitti_> and please do try after a clean reboot, just in case
<ryanpg> sure... this afternoon
<ryanpg> pmount works btw
<rtcm> pitti_: cupsys is using a link in /etc/cups/pdftoos.conf which does not exist (in dapper)
<ryanpg> ok I'm off for now
<rtcm> pitti_: maybe poppler-utils should include it?
<pitti_> rtcm: right, it should
<pitti_> rtcm: can you please file a bug against it?
<rtcm> sure
<mvo> Keybuk: the MoM output for aptitude looks a bit odd, any idea?
<Keybuk> define odd
<freelove> can i talk to mr. mark shuttleworth here plzzzzzzz?
<tseng> not like that
<Keybuk> I expect it has something to do with the fact we can't sync/merge from experimental
<ogra> freelove, sabdfl isnt around currently :)
<Amaranth> sabdfl isn't on IRC regularly, your place bet is email
<Amaranth> err, best bet
<freelove> his personal email? will he read my email?
<ogra> Amaranth, not true he's around quite often :)
<Mithrandir> freelove: yes, why shouldn't he?
<Amaranth> ogra: But not on any consistent schedule.
<ogra> nope
<ogra> but several times a week ...
<Amaranth> email is easier :)
<freelove> whats his email id ogra?
<ogra> that might be true 
<freelove> there are so few ppl in #kubuntu-devel......
<ogra> mark@ubuntu.com i think
<mdz> morning
<tseng> 'lo mdz 
<ogra> morning mdz
<freelove> ogra thx
<Mithrandir> Keybuk: could I have /etc/udev/rules.d/60-symlinks.rules and /lib/udev/cdrom_id in the initramfs, please?
<pitti> Hi mdz 
<Keybuk> no
<Mithrandir> Keybuk: why not?
<Keybuk> neither symlinks or permissions are suitable for the initramfs, because they can't be "undone" by the real filesystem
<Mithrandir> they'd be very useful for the live CD.
<Keybuk> why?
<Keybuk> you shouldn't rely on anything in 60-symlinks anyway, they almost never work
<Mithrandir> because then I can just iterate over /dev/cdrom* and try mounting until I found the right CD.
<Keybuk> that won't work, because there's no guarantee that there's a /dev/cdrom* for every CD
<Keybuk> in fact, it almost always works out that there isn't, and there's just one
<Mithrandir> hm
<Keybuk> if you need something like that, you'll need to use the ungodly hack the installer uses
<Mithrandir> that kinda sucks.
<Mithrandir> I was hoping to not use ungodly hacks. :-)
<Keybuk> iterating CDs is an ungodly hack ;)
<Keybuk> use /dev/disk/by-label or something to pick exactly the right one
<Mithrandir> nono, that's nice and pretty.  Almost, at least.
<Mithrandir> nocando, we can't predict the label.
<Keybuk> you could walk /sys and look for CDs yourself, then look them up in the udevdb to find out what block device they have (if any)
<Mithrandir> how do I know if something is a CD?
<freelove> will dapper be faster than breezy:) ??
<Keybuk> cdrom_id does that
<Keybuk> (you can have _that_ in the initramfs, just not the symlinks rules)
<tseng> freelove: please address general questions to #ubuntu
<Mithrandir> Keybuk: ok, if I could have that, I could live with running it over the whole of /dev
<Keybuk> you'll need ide_media too (I think that's there already)
<Keybuk> oh, no, ignore me
<Keybuk> cdrom_id does work on IDE drives
<Mithrandir> cdrom_id will work on SCSI, SATA and IDE drives?
<Keybuk> probably
<Mithrandir> "probably" is a bit weak. :-/
<Keybuk> there are no guarantees
<Mithrandir> I don't have a SATA drive, but I could dig out a SCSI drive at least.
<Keybuk> it does seem to do the right thing for everything tested so far
<Mithrandir> let's hope it continues doing that, then. :-)
<Keybuk> that's what it's for
<Keybuk> it's the binary to know all about the silly corner cases for every damned driver
<Mithrandir> ok
<Keybuk> if you're going to write something to find CD drives, could you replace the installer's cdrom-detect while you're at it
<Mithrandir> I'm going to do one thing at a time first, I think
<Keybuk> something like:
<seb128_> thierry_: thanks for the patch
<Keybuk> for sysblock in /sys/block/*; do
<Keybuk>     devname=$(udevinfo -q name -p ${sysblock#/sys})
<Keybuk>     cdrom_id /dev/$devname
<Keybuk> done
<Keybuk> would iterate all block devices looking for CD drives
<Mithrandir> you don't have to chop off /sys, it seems
<Mithrandir> and I'd need udevinfo in the initramfs
<Mithrandir> sbalneav: yes, I'm Tollef
<sbalneav> Hey Mithrandir!
<Mithrandir> hiya
<Keybuk> Mithrandir: that's also easy to arrange
<ogra> sbalneav, scotty !!
<Keybuk> you could also do something a little more ungodly if you liked ...
<Keybuk> for magic in /dev/.udev/db/block@*; do
* ogra secretly takes jammcq's part :)
<sbalneav> I had a quick question about a ubu box I'm setting up and pam_umask.  Probably not acceptible in this channel, can you join me in #pamumask?
<sbalneav> Hey ogra!
<Keybuk> but ahem, you're not supposed to do that <g>
<Mithrandir> sbalneav: sure
<Mithrandir> Keybuk: I would prefer not to, please. :-)
<Keybuk> anyway, given you're modifying the initramfs yourself to add this code
<Keybuk> either copy the udev helpers with your own initramfs hook
<Keybuk> or give me the complete finished thing if it's suitable for the real initramfs
<Keybuk> and I'll put it in the udev package
<Mithrandir> yup, willdo
<Keybuk> the reason the /dev/cdrom* isn't suitable is that there's no checking the symlink doesn't already exist
<Keybuk> so if you have two cdroms, they might try and both use /dev/cdrom
<Keybuk> the %e thing doesn't have a great big lock around it
<Mithrandir> ah
<Keybuk> for the installer, we do it using an evil shell script that does have a great big lock around the plugging of drives
<Keybuk> udevd would probably get the /dev/sda and /dev/sdb events (two CD-ROMs) at the same time, if they come from the same driver
<Keybuk> as there's no path conflict they'd be processed at the same time
<Keybuk> so they'd both test for the non-existance of /dev/cdrom at the same time
<Keybuk> and both make a /dev/cdrom symlink
<mdke> Keybuk, my sata drive controller is looking better now, thanks
<Keybuk> mdke: your laptop boots?
<mdke> yeah
<mdke> everything else works too
<Keybuk> Mithrandir: upstream have preferred to deprecate %e rather than fix the problem -- and I tend to agree with their logic as predictable names like the /dev/disk tree are better
<Keybuk> if you give people /dev/cdrom0 and /dev/cdrom1 they'll bitch that they swap round every other boot
<Mithrandir> Keybuk: if I could have /dev/cdroms, I wouldn't mind. :-)
<Keybuk> that has the same problem
<Keybuk> /dev/cdroms/0 and /dev/cdroms/1 would swap every other boot
<Keybuk> whereas /dev/disk/bu-id/ata-HP43CDROM is forever
<Keybuk> as is /dev/disk/by-path/ etc.
<Mithrandir> have it be /dev/cdroms/ata-HP43CDROM, then
<Keybuk> see, now that's an interesting idea
<Keybuk> right now /dev/disk doesn't have a by-type
<Keybuk> we could add that to the persistent rules
<Keybuk> /dev/disk/by-type/cdrom/$ID
<Keybuk> /dev/disk/by-type/disk/$ID
<Mithrandir> yup, that'd be useful
<Mithrandir> you think that's upstreamable as well?
<Keybuk> potentially
<Keybuk> it could also be considered irrelevant though, as upstream for those rules might just retort "they're all called scd*"
<Mithrandir> except my DVD drive is called /dev/hda
<Keybuk> it's increasingly likely that in a couple of kernels time, it won't be
<Mithrandir> oh?
<Keybuk> they're fast moving towards replacing the IDE subsystem with libata
<Mithrandir> scd would also be fine, I just want something which is nice to iterate over.
<Mithrandir> also, that wouldn
<Mithrandir> 't cover the ancient CD subsystems
<Mithrandir> pre-IDE
<Keybuk> hmm, I don't think they work anyway
<Keybuk> we don't bother with them in initramfs
<Keybuk> you have to load the driver to find out whether you have one, and the driver often hangs the machine if you don't
<freelove> can i speak to dear mr. mark shuttleworth plz??
<Mithrandir> freelove: he just left the channel.
<Mithrandir> freelove: 17:50 -!- sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl]  has left #ubuntu-devel [] 
<freelove> nooooooooooooooooooooo! 
<freelove> :(
<Mithrandir> just send him a mail
<Keybuk> mark.shuttleworth@canonical.com
<freelove> will he reply?
<Mithrandir> if you write something interesting, quite likely.
<Keybuk> it depends, he receives a lot of e-mail, so it's worth taking your time over writing it
<Mithrandir> if you write "are you mark", maybe not
<freelove> ok
<Keybuk> but yes, if it's interesting and exciting, I'm sure
<Keybuk> "can I have some of your money?" doesn't tend to get replies, unless it's "if I send you into space again, can I have some of your money?" :p
<freelove> lol:)
<Keybuk> Mithrandir: do you want to support old CD drives then?
<Mithrandir> Keybuk: if it's not painful, I don't see a reason not to.  I'm not going to jump through lots of hoops to get them supported, though
<Keybuk> aiui, it's very painful
<Keybuk> I don't think our current installer supports them?
<Mithrandir> I'm not sure.
<Keybuk> anything pre-PCI means you have to know you want the driver, and load it by hand
<Mithrandir> it's probably easier just to ship anybody who shows up with such a drive a new DVD drive.
<Keybuk> we only support them in the real system by people adding them to /etc/modules
<Keybuk> heh
<Mithrandir> and cheaper
<Keybuk> I doubt anyone with such a drive has the computing capacity to run X, let alone anything else
<Keybuk> unless my memory is deceiving me, they died with the 386
<Mithrandir> they didn't.  You get 486DX2 machines with them, but yes, they're quite old.
<Keybuk> ACTION=="add", SUBSYSTEM=="block", KERNEL=="*[!0-9] |sr*", IMPORT{program}="cdrom_id --export $tempnode", ENV{ID_CDROM}=="?*", IMPORT{program}="path_id %p", SYMLINK+="cdroms/$env{ID_PATH}"
<Keybuk> Mithrandir: ^ knock yourself out ;)
<Mithrandir> nah, I'm using your udevinfo thingy
<Mithrandir> seems to work
<Keybuk> yeah, the nice thing about the new world order is that this kind of thing is actually rather simple
<mdz> seb128: does xchat-gnome  have a shortcut for next/previous channel, like ctrl+pgup/pgdn did in xchat?
<seb128> mdz: alt-up/down
<ogra> argh... my usb writer cant write dvds anymore
<Keybuk> ogra: somebody else was having problems with that
<Keybuk> why can't it write dvds?
<crimsun> I can't even get my usb cdrw to do anything useful.
<ogra> cdrecord: Unspecified command not implemented for this drive.
<ogra> cdrecord: Cannot get next writable address.
<ogra> i get this for blanking RW as well
<ogra> sg is loaded and i can access the drive for reading just fine
<mdz> seb128: hmm, doesn't work for me (acts like up/down)
<mdz> would my gtk-key-theme-name affect it?
<Keybuk> are the permissions right?  (ie. does it work if you're root)
<ogra> nope, tried already
<Keybuk> could be a new kernel bug then
<dholbach> mdz: i revamped the testplan pages, they're now at http://wiki.ubuntu.com/Testing
<dholbach> mdz: the installation matrix is at http://wiki.ubuntu.com/Testing/Current - do you think i should do additional pages for Kubuntu and Edubuntu to test their instlalation methods?
<seb128> mdz: hum, maybe. Let me try with Emacs mode
<dholbach> (i will change bits in the individual items on the the short and long test plans though, especially the media related tasks)
<Riddell> dholbach: yes please
<dholbach> Riddell: the test plans themselves are generic, so it says "Your mail app", i'll add CurrentKubuntu, ok?
<Riddell> ok
<dholbach> ogra: same for edubuntu?
<ogra> the install is different, i'll look after dinner
<mdz> dholbach: yes
<dholbach> ogra: oh ok
<mdz> dholbach: "does the resolution match?" in the short test is a bit vague
<ogra> dholbach, but generally, yes
<dholbach> mdz: i'll review the individual items and make changes to them now (some bits are from the BOF session at UBZ)
<mdz> Keybuk: the T42 is booting, with DMA, in 1:05
<mjg59> mdz: Is suspend still broken for you?
<mdz> mjg59: will test now
* ogra raises hand ... waves to mjg59 
<mdz> mjg59: goes down quickly but refuses to wake up
<ogra> mine doesnt go down ... 
<mdz> no response to any keys or power button, moon light stays on
<mdz> this is with 2.6.15-7
<mjg59> mdz: Ok, fair enough
<mjg59> I'll try to debug
<mjg59> It works fine here using ata_piix, so I think it's probably something in the IDE suspend support
<mdz> 0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
<mjg59> mdz: Can you do kernel builds there?
<mdz> mjg59: I can, but they take a while
<mjg59> mdz: Can you disable USE_DPMS in /etc/default/acpi-support and see if it gives you anything useful looking?
<mdz> mjg59: some text flashes by too quickly to read, then a blinking cursor, then blank and the same state of death
<mjg59> Right. What fun.
<mjg59> mdz: What was the last previous version to work?
<mdz> mjg59: breezy
<mdz> last known to work
<mdz> hibernate at least was working with dapper + the breezy kernel
<mjg59> mdz: Do we still have older 2.6.15 packages?
<mjg59> Oh, yes, of course - it was generally broken for ages. Hrm.
<Riddell> infinity: please give back kdebluetooth
<mjg59> Grah. Any chance you can get a git checkout from a while back and change the config to enable HOTPLUG_CPU?
<mdz> I've never used git, but can follow instructions
<mjg59> Then if that works, git bisect it to the patch that breaks it
<mjg59> Basically, get git, then do git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
<mjg59> Then you need to check out an older version
<zyga> ogra: back to hwdb-client
<mdz> guh
<mdz> git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git  -> git: fatal error: `chdir' failed: permission denied.
<ogra> Keybuk, hmm, i get the same error with my internal IDE DVD writer ...
<ogra> zyga, yup
<mjg59> Delete everything in debian/config/x86 except i386 and generic, then edit that to enable CPU_HOTPLUG and do a dpkg-buildpackage
<infinity> Riddell : Mail those requests if I'm not obviously around (I was idle for several hours)... The fact that I'm restless and awake at 4:45am is a fluke. :)
<seb128> mdz: alt-up/down works fine for me with xchat-gnome/emacs keybindings, that's weird
<mjg59> mdz: Ah, sorry - there should be a " ubuntu-2.6" on the end of that
<mdz> git: warning: invalid extra options ignored
<mdz> strace says it is trying to chdir to 'clone'
<mjg59> git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git ubuntu-2.6 seems to work for me
<mdz> what version of git?
<mdz> ii  git            4.3.20-7build1 GNU Interactive Tools, a file browser/viewer
<mjg59> That's entirely the wrong git
<mdz>  haha
<mdz> of course it is
<infinity> Riddell : Also...
<infinity> make[2] : Entering directory `/build/buildd/kdebluetooth-0.99+1.0beta1'
<infinity> ./admin/cvs.sh: line 13: autoconf: command not found
<mjg59> Anyway, I have to get some food
<mdz> what do we call the right git?
* mjg59 runs away
<mjg59> I have git-core, ubt I'm not sure where it came from
<Riddell> blurg
<mjg59> kernel.org has debs, I think
<ogra> mdz, shouldnt BenC know ? ;)
<infinity> https://wiki.ubuntu.com/KernelGitGuide claims that "git-core" is in dapper.
<mdz> ok, git-core works much better
<mdz> infinity: it is
<zyga> ogra: I've started with hwdb-send, can I modify it to use python stuff instead of external commands?
<ogra> zyga, i rather wanted to integrate it in the main client
<ogra> what wouls you like to change ? 
<ogra> *would
<zyga> ogra: cleanup glade mess, cleanup md5 digest
<zyga> I'm not sure why you copy stuff around so I'll leave that part intact
<ogra> thats if the server can be pinged ... so the file gets moved to the Desktop, asking the user to mail it to hwdb@ubuntu.com
<ogra> *cant
<zyga> ogra: neet :-)
<zyga> ogra: ok, so should I leave that alone? glade is really messy overe there
<ogra> is there an alternative included in python to generate md5sums and rename files accordingly ? i'm not aware of any internal methods
<zyga> ogra: md5 is easy I'm not sure about file moving but I didn't look yet
<ogra> the bzip2 part could be lolved internally ...
<ogra> solved
<ogra> the important pat is that the filename is the md5sum in the end, thats an essential piece of hwdb
<lamont> slomo: btw, debian's mod-mono says 'Architecture: i386'
<zyga> ogra: that's easy
<ogra> if you have a way to solve that in plain python i'm fine with it
<zyga> ogra: does rename fail on fs boundary?
<ogra> fs boundary ? 
<slomo> lamont: yes, for whatever reason... i talked with one of the maintainers and he said he will change it to arch any for the next upload
<ogra> zyga, you mean if /tmp doesnt exist ? 
<zyga> filesystem boundary, say /tmp is on partition foo and $HOME/Desktop is on bar
<zyga> (so that rename is non trivial and needs to copy the data)
<ogra> oh, nope, that cant happen 
<slomo> lamont: must've been in the old days where mono was only available for i386
<lamont> yeah
<zyga> so os.rename can be used instead of os.system('mv %s %s')
<ogra> zyga, mv works over partitions without probs
<slomo> doko: ping?
<tseng> slomo: lamont still has nightmares about mono 1.0
<zyga> ogra: mv does, but does os.rename? :)
<ogra> zyga, i guess so
<zyga> k, I'll test
<ogra> hmm, i'd think so
<zyga> ah
<zyga> OSError: [Errno 18]  Invalid cross-device link
<zyga> not good
<tseng> has to be a hardlink i think
<zyga> tseng: ?
<zyga> tseng: it's a regular file, touched for this test
<ogra> sadly there is no os.move ...
<theCore> Diziet, what are the packaging procedures in Ubuntu ? i'm currently working on the PackagingGuide and I would like to make a chapter on this for new maintainers 
<zyga> ogra: you don't test for any failure
<zyga> ogra: we could write an os.move equivalent easily
<ogra> do it if you like :) 
<zyga> k
<zyga> I'll ping you when it's done, if it doesn't match the direction where the code is going bash me :)
<ogra> zyga, for which failure should i test ? 
<ogra> if hdwb-send is called i have the guarantee that the file exists ... if /tmp doesnt exist on your system, the system is broken anyway
<zyga> ogra: mv can fail
<ogra> the only failure that can happen is that the server isnt reachable ...
<zyga> ogra: not enough free space 
<zyga> ok
* zyga grabs dinner
<zyga> later :)
<ogra> hmm... mv ... its a 200k file ...
<zyga> ogra: theory :)
<zyga> bbl
<ogra> sure there could be space issues, but then it would break earlier already
<ryanpg> pitti, hia back for a few... I did the removable media routine again... is it kosher to attach a .tar.gz to the bug or should I just attach all the logs individually
* mvo is wawy to play hockey, bbl
<ryanpg> somehow I suspect this line from dbus will be meaning ful "12:26:54.764 [I]  blockdev.c:602: Ignoring hotplug event - no parent
<ryanpg> "
<dholbach> elmo_: please sync libglademm2.4 from sid, ok to override
<doko> slomo: pong
<slomo> doko: you asked xine-lib to be updated to 1.1 in #19356... did you already take a look at 1.1 (i.e. if it's ABI compatible, etc)? and it's a development version judging from their homepage... 1.0 is stable
<doko> slomo: 1.0.x is not ready for g++-4.0, 1.1.x is.
<slomo> doko: ok, that's a good argument to update ;) i'll take a look at it then, thanks
<doko> slomo: thanks!
<doko> ahh, 1.1.1 is current ...
<slomo> doko: judging from their release notes it should be safe to upgrade to 1.1.1... i'll test it locally later
<Amaranth> the X mouse fix was to modprobe psmouse, right?
<slomo> doko: but our current version is patched to work with gcc4 too
<doko> allowing playback on x86_64 systems (previously QDM2 was only
<doko> possible using win32 codecs).  ... from the release notes ...
<dholbach> slomo: the less delta the better - we had bug reports, which indicated, that upstreams version was good, ours wasn't :)
<LaserJock> whois Diziet
<dholbach> LaserJock: the person with the nick name "Diziet", maybe?
<ogra> lol
<LaserJock> dholbach: sorry forgot the / :-)
<dholbach> no need to be sorry :)
<Diziet> laserjock: How may I help you ? :-)
<LaserJock> trying to get the hang of irssi
<slomo> dholbach: i have to introduce a big delta anyway... need to split of patent encumbered stuff into a another source package to not have this stuff in main ;)
<LaserJock> Diziet: I am working on the Ubuntu Packaging Guide
<dholbach> slomo: oh, i see
<Diziet> Ahh.
<LaserJock> Diziet: and I wanted to check in with you about the Ubuntu Developer's Reference
<Diziet> Ah.  Well, I haven't really started that yet.
<slomo> well, i'll go for 1.1 then...
<LaserJock> Diziet: well, we are still in the organizing stage too 
<ssam> i am getting messages "OIL: ERROR liboiltest.c 266: oil_test_check_impl(): illegal instruction in fbCompositeSolid_nx8888mmx" in amongst the output when i run apt-get in dapper. any ideas what it is?
<LaserJock> Diziet: I have an outline at https://wiki.ubuntu.com/UbuntuPackagingGuide/Outline
<LaserJock> Diziet: but I am wondering how much packaging you are going to cover in the UDR
<LaserJock> Diziet: I been thinking of the two as, the UDR covers the policy and the Packaging Guide is a tutorial
<Diziet> I was going to try to keep it light on detailed information about packaging.  Did you read the wiki page DeveloperDocumentation ?
<LaserJock> Diziet: yes, that is why I wanted to talk to you
<Diziet> I think the right distinction between the UDR and your Packaging Guide is reference vs. tutorial.  Do you agree ?
<LaserJock> Diziet: I guess, although that is a bit finer distinction
* Amaranth cries over his poor dead X
<Diziet> On the contrary, I think it's a very good distinction.  It changes the structure of the document completely.
<LaserJock> Diziet: yes, but it might be somewhat confusing to have a packaging reference and packaging tutorial in two different places. I will have to think about it.
<Diziet> Tutorials are allowed to leave stuff out, and also to have a much clearer preference on things where there are several permissible answers.
<LaserJock> Diziet: true
<Diziet> And of course the material is organised by taxonomy rather than functionally.
<LaserJock> Diziet: ok, we will try to keep that in mind and if we need to shift material that shouldn't be a problem
<Diziet> shift material> Quite so.
<LaserJock> the should be complimentary docs in any case
<LaserJock> s/the/they/
<LaserJock> Diziet: How will the UDR be developed, bzr?
<ryanpg> hey pitti have you been away? I ran the removable debugging gamut again is it ok to attach a tar.gz with the logs to the bug?
<pitti_> ryanpg: that's fine, thanks
<infinity> ARGH.
<infinity> siretart : Around?
<infinity> siretart : 'mplayer-586' depends 'mplayer' depends 'mplayer-skins' conflicts 'mplayer-586'.  Spot the problem.
<siretart> infinity: err, what did I break?
<infinity> siretart : I assume you only wanted "Replaces", not "Replaces/Conflicts"
<siretart> infinity: ah, damn, my bad
<siretart> sorry, will reupload in a sec
<siretart> infinity: if mplayer-skins just replaces (without conflicting) will the old mplayer packages be removed?
<infinity> No, and you don't want them to be.  You need mplayer-586 to be installible to get people to upgrade to mplayer.
<infinity> I fixed this same bug in mplayer itself earlier today.
<siretart> right
<slomo> infinity: thanks for that btw :)
<infinity> "Replaces" is for files moving between packages.  "Conflicts" is when two packages CURRENTLY have the same file (and it's not moving anywhere)
<infinity> Replaces/Conflicts together is to work around an old dpkg bug that is long fixed.  Never use that combination unless you're positive it's what you want.
<siretart> ok. uploaded
<Amaranth> oh, Replaces/Conflicts together isn't needed anymore?
<Amaranth> i just copied mozilla-firefox/firefox
<infinity> Amaranth : The bug was fixed ages ago, and the fixed dpkg is in (at least) sarge, hoary, and breezy... Maybe warty too.
<infinity> So, yeah.  Don't do it anymore. :)
<siretart> aaaah. this explains
<infinity> (Now, if you really want the other package completely removed, you can use the combination, but don't use it for arbitrary file overwriting)
<infinity> In the case of mplayer-586, the world blows up when you try.
<Amaranth> oh, i wanted the other package completely removed
<infinity> (cause upgrades won't work)
<infinity> Amaranth : Then you're probably okay doing it your way.  So long as you make sure you didn't create a hideously broken upgrade loop.  (which happens a lot with Conflicts/Replaces)
<infinity> Oh, this is laghable.  I still haven't slept, and I supposedly start work in 3 hours.  Go me.
<infinity> laughable, too.
<dholbach> infinity: please go to bed and sleep whatever time you need :)
<jdong> (kick him for 3 hours)
<Diziet> No, Replaces/Conflicts isn't obsolete.  But I don't have time to explain right now :-).
<Diziet> But A -Replaces-> B -Replaces-> A is always wrong (with intervening packages too), regardless of any Conflicts.
<infinity> Diziet : The primary reason it was frequently used (working around the fact that dpkg didn't pay attention to Replaces when installed a "replaced" package) is obsolete.
<infinity> Diziet : The other reason (completely whacking package B) is still valid, of course, but that's not why it was most frequently used.
<infinity> Diziet : As for circular Replaces, that should be fine with versioned replaces... It would blow up miserably with unversioned replaces, obviously.
<infinity> Which reminds me.
<infinity> siretart / slomo : You're much less likely to make dpkg unhappy in the future (should you, say, have to move files around again, split the packages again, god knows what) if you make those Replaces correctly versioned, instead of unversioned... (ie: mplayer Replaces: mplayer-586 (<< $firstDummyVersion))
<siretart> infinity: thanks. will remember that
<slomo> infinity: ok, thanks... will keep that in mind :) but the package layout for mplayer will stay as it is now
<feugan3333> Hi all. After installing the nvidia-glx package xmms is segmentation faulting. I don't see a bug report for this. Anyone know about it?
<feugan3333> Does xmms make use of opengl?
<slomo> feugan3333: for visualization plugins, yes... but this is not a support channel... better ask in #ubuntu or on the mailinglist
<feugan3333> slomo: I'm really trying to find out if I should report a bug, if so how?
<crimsun> feugan3333: general troubleshooting occurs in #ubuntu
<Flare> feugan3333 ==> http://bugzilla.ubuntu.com/
<feugan3333> ok thanks
<Flare> Next time read the topic please.
<feugan3333> Flare: I though developers would like to know about a program that seg faults on startup. Not much support can be given.
<psusi> shouldn't local X apps be connecting to the X server using the unix domain socket and not tcp/ip?
<Mithrandir> they should
<Mithrandir> especially given that the X server doesn't listen on TCP
<psusi> of course it does
<psusi> it listens on port 6000 + display_num
<psusi> and it seems most apps are using TCP to connect to the server instead of the unix domain socket
<psusi> under ubuntu
<HrdwrBoB> erm
<HrdwrBoB> by default it doesn't listen on TCP at all
<psusi> lsof a gnome-terminal
<HrdwrBoB> you have to specifically remove -notcp from the config
<psusi> well... yea... it does... netstat -a -n
<psusi> wait...
<psusi> maybe the local one isn't... on this machine
<HrdwrBoB> I'm not making this up, the default is notcp
<psusi> ok... yea... the local server isn't listening... the tightvnc server is... and apps are using TCP to talk ot it instead of the unix domain socket... also I noticed on my home machine that apps will TRY to use tcp and take forever to time out and fall back to the unix domain socket
<psusi> if you don't configure your lo interface
<HrdwrBoB> yes
<psusi> shouldn't they be trying the unix domain socket first?  not tcp?
<HrdwrBoB> lo sometimes fails on wake up from sleep on my laptop, with no lo, things go terribly broken
<HrdwrBoB> possibly, if you see that they are and shouldn't be, submit a bug
<psusi> well yea... they are... which is why things break down when you don't have a loopback
<psusi> hrm...
<slomo> doko: fyi, xine-lib 1.1.1 works fine with at least totem-xine and gxine and judging from soname it should be completly compatible... i'll do some further tests and upload it then... splitting it will come later this weekend
<seb128> slomo: rock
<slomo> seb128: do you want to take a look at my current work? (i.e. merge and update to 1.1.1)
<seb128> slomo: why not, are the sources somewhere online atm? 
<slomo> not yet, i'll upload them now to my server
<seb128> k, thansk
<\sh> damn...I just fucking resigned 
<spacey_ki> why
<tseng> \sh: eh?
<\sh> spacey_ki: because my indirect boss is a fucking social asshole..thats why
<\sh> tseng: not eh..the truth the real the reality
<greenpenguin13> wahey that round of updates fixed all my problems :)
<slomo> seb128: get it from here http://slomosnail.de/~slomo/temp/
<Riddell> elmo_: please sync libgii from debian, overwriting ubuntu changes
<slomo> seb128: btw, i've written wavpack main inclusion report today... maybe it's ready when debian added wavpack support to gst-plugins
<seb128> slomo: cool, download xine-lib atm
<hunger_> BenC: My system boots again with the newest udev. It was broken inbetween for a while. Bluetooth is working again, too.
<psusi> same here... except for bluetooth... I have no bluetooth
<hunger_> Even my CDROM works again (have not yet tested burning something with it though).
<hunger> Even pcmcia cards are detected! This is getting really nice!
<hunger> Thanks for all the great work on udev and the new kernel! Keep it up, please.
<Kamion> hunger: pcmcia> hooray
<BenC> hunger: cool
<Kamion> (16-bit PCMCIA, or CardBus?)
<hunger> Kamion: it is a 16bit card... in a cardbus-capable slot.
<Kamion> rock on
<Kamion> those are the hard ones
<hunger> Kamion: Just grabbed the old wlan card from my wife's laptop...
<slomo> seb128: if you're fine with it i'll send it up later... btw, it works on one video file (h264) where mplayer only shows a distorted picture ;)
<seb128> slomo: it's still building, not quick to build
<slomo> seb128: no... but way faster than mplayer ;)
<greenpenguin13> hmm
<greenpenguin13> i cant start x with the latest two kernels
<greenpenguin13> something to do with nvidia-glx
<mvo> what are the magic words to see more than 10 translations in rosetta?
<mpt> there are none, mvo
<mpt> sorry
<mpt> (and try #launchpad for Launchpad questions)
<mvo> mpt: oh :( and searching is not possible as well
<mpt> not yet, no
<mpt> though that's high on the list of unimplemented features
<zyga> mvo: there is a translators whishlist somewhere on the wiki
<seb128> slomo: xine, DOH
<slomo> seb128?
<seb128> slomo: totem-xine works way better than totem-gstreamer :/
<crimsun> always has in my experience
<seb128> slomo: 1.1.1 works great, no ABI breakage, I've diffed the symbols exported
<seb128> crimsun: yeah, but I tend to have the -gstreamer variant installed to debug it :)
<slomo> seb128: yes, let's work together to get totem-gstreamer working at least as good as xine :)
<seb128> I hope gst0.10 will works better
<slomo> it must ;)
<seb128> slomo:I'll probably upload a gstreamer0.10 ready to upload tomorrow
<seb128> just change the unversionned stuff hover the current online one
<seb128> s/change/changing/
<seb128> s/hover/over/
<seb128> slomo: have you looked at this one? (not speaking about gst-plugins-base0.10 which needs some work)
<slomo> yes, i only looked at gst itself... plugins was only a quick look over
<slomo> if you change the unversioned stuff it seems to be fine for me... even compiles in pbuilder etc ;)
<slomo> seb128: lool was ok with your decision about the tools?
<Amaranth> seb128: xchat-gnome is awesome
<Amaranth> although i don't enjoy the things i had to do to get it on breezy
<fabbione> guys, who has been playing with mplayer recently?
<dholbach> fabbione: if you're going to give a lecture, you're a bit late :)
<fabbione> dholbach: no
<fabbione> there is a regression i would like fixed :)
<dholbach> ah ok, because infinity did an hour ago
<fabbione> nothing about packaging
<fabbione> it's how they build it
<fabbione> (i think)
<slomo> Amaranth: is the trayicon of x-g finally working?
<dholbach> slomo and siretart are motumedia :)
<fabbione> slomo, siretart: ping?
<fabbione> Requested video codec family [wmv9dmo]  (vfm=dmo) not available.
<fabbione> Enable it at compilation.
<fabbione> Requested video codec family [wmvdmo]  (vfm=dmo) not available.
<fabbione> Enable it at compilation.
<slomo> fabbione: i've done that package, yes
<fabbione> that's playing .wmv 
<fabbione> no video
<seb128> slomo: yep, lool is ok
<seb128> Amaranth: rock :)
<crimsun> err, can anything actually play wmv9 video?
<fabbione> slomo: can you please check all the configure log and see what did you or siretart miss?
<fabbione> crimsun: yes. it was working with the version of mplayer i had in breezy
<dholbach> and crimsun is motu media too
<slomo> fabbione: yes, i'll put it on my todo list for tomorrow
<fabbione> crimsun: + codecs
<fabbione> slomo: ok thanks
<crimsun> fabbione: k
<Amaranth> slomo: dunno, probably not here
<slomo> fabbione: can you give me a testfile?
<fabbione> crimsun: these porn^Wfiles are at least 2/3 years old
<fabbione> ;)
<crimsun> I know it absolutely won't work with vlc because it's in universe, but mplayer should have no prob then since it's in multiverse
<fabbione> slomo: grab any from the net..
<Amaranth> fabbione: w32codecs?
<slomo> fabbione: well, i could play various wmv files ;)
<fabbione> slomo: the all fail 
<fabbione> slomo: this is amd64
<slomo> fabbione: are you on x86 or amd64?
<fabbione> Amaranth: yes
<slomo> fabbione: w32codecs or only native stuff?
<dholbach> crimsun: i was quite pleased with vlc, when i tested it
<fabbione> slomo: w32codecs
<Amaranth> wmv9 without w32codecs is unpossible at the moment
<crimsun> elmo_: please sync libsdl-sound1.2 from Sid (ok to override Ubuntu changes), thanks
<dholbach> crimsun: i mean it didn't explode every five minutes :)
<slomo> fabbione: isn't enabled for amd64 because we didn't know if it works... thanks for reporting :) i'll enable it now
<crimsun> ah, w32codecs.
* fabbione larts slomo with a huge clebat
<fabbione> cluebat even ;)
<crimsun> I was about to say that I didn't know of a *nix lib to handle it
<seb128> what an idea to use mplayer
<dholbach> slomo: don't worry, i received the same treatment from fabbione once, it's "coming of age" in ubuntu land :)
<Amaranth> *poof*
<fabbione> dholbach: ehehe
<slomo> fabbione: anything else you want to see fixed? :)
<dholbach> slomo: evolution next, please
<dholbach> slomo: oh wait... and gamin :)
<fabbione> slomo: yes.. ATI driver for r300 on ppc. kthxbye
<slomo> bah, i mean in mplayer ;)
<fabbione> ah also world peace
<slomo> but i want the other 3 fixed too :P who can do it? ;)
<fabbione> slomo: it would also be nice if you could fix my tax return statement...
<lifeless> fabbione: I think thats illegal
<lifeless> 'fixing' it I mean ;)
<fabbione> ahah
<lifeless> but perhaps your consiglieuri could help ;)
<dholbach> seb128: fabbione must be french, he said "ahah" :)
<seb128> ;)
<slomo> fabbione: mplayer uploaded ;) tell me if it works later :)
<fabbione> slomo: ok thanks
<fabbione> slomo: i will let you know tomorrow.. i am almost on the way to sleep
<slomo> fabbione: ok, then tomorrow :) i plan to go to bed now too
<Riddell> elmo_: please sync libgii and ekg from debian, overwriting ubuntu changes
<mdke> Riddell, yo
<mdke> Riddell, i was trying to put that svn:externals property back the other day, but totally failed. Would you do it for me?
<Riddell> mdke: ok
<Riddell> it's not very well explained
<Riddell> mdke: are any of the other docs in generic going to be used?
<mdke> Riddell, erm: the active docs in there are the serverguide and packaging guide. I've been building the latter with ubuntu stylesheets for the website, thoughts on shipping with kubuntu?
<jbailey> Anyone know if Launchpad has something like the Debian watch file support to get notified of new versions when they come out?
<lifeless> products, upstream imports, productseries
<lifeless> jbailey: IOW the hooks are there but notification is a bit of a loose term
<jbailey> lifeless: Intentionally so. =)
<Riddell> mdke: if it's shipped with ubuntu, we want it for kubuntu too :)
<jbailey> lifeless: I'd be happiest with an rss feed that I could hook onto so that I had a work list. =)
<jbailey> lifeless: Second place is a web page that I have to remember to check, and failing that, an email.
<lifeless> jbailey: do up a use case. Probably on launchpadpersonalsubscriptions
<mdke> Riddell, the decision kinda hasn't been made yet about whether it is a useful doc for shipping in the distro, but right now, it's in there, so you can add it too if you like
<jbailey> lifeless: Thanks.  Use case #3 of https://wiki.launchpad.canonical.com/ProductSubscriptions seems to cover it.
<jbailey> Well, not the email part, but everything else in there is RSS.
<jbailey> Mmm, actually #4 covers it almost better.
<lifeless> so, add a note saying 'mee too' ;)
<lifeless> noone knows *who* those cases satisfy unless you say os
<shawarma> Who is the mastermind behind the suspend/resume functionality in Breezy? I've got a quick question..
<slomo> seb128: i'll take a closer look at base plugins tomorrow then after you've uploaded gst itself :) and i could take a look at the 0.10 ffmpeg plugin later... should be a fairly easy one
<lifeless> shawarma: mjg59 
<shawarma> lifeless: Thanks.
<jbailey> lifeless: What sort of form shouldI use for that?
<lifeless> jbailey: under the use case: -- JeffBailey Hey this rocks, I'd love that.
<seb128> slomo: don't bother on gst0.10, it's trivial
<seb128> slomo: just a standard update, no split, or anything like that for it
<seb128> jbailey: how know what would be nice? multibuild with cdbs ... what's going on with cdbs2? :)
<jbailey> seb128: cdbs2 is dead.  Long live cdbs3.
<seb128> ?
<slomo> seb128: oh ok, then let's get base plugins in and and worry about the bad/ugly/ffmpeg then :) but for good i think i'll prepare a splitting proposal at the weekend
* mvo goes to bed now
<seb128> dead before beeing born, wth?
<jbailey> seb128: Not at all.   I demoed it to a number of people in Sydney.  Didn't you see it?
<seb128> slomo: k, I'll have gstreamer0.10 sorted by tomorrow, then we can discussed -base and move on others stuff
<seb128> jbailey: no!
* seb128 grumpfs
<dholbach> jbailey: demo! demo! demo! :)
<seb128> k, so what cdbs3 is? :)
<jbailey> seb128: Anyhow, I got too busy to finish it, and the others I showed it to all ran in fear.
<Mithrandir> jbailey: just like scott "demoed" hct more than a year ago? ;-)
<jbailey> The wimps couldn't handle posix shell.
<Mithrandir> jbailey: OO posix shell, I assume?
<jbailey> Mithrandir: In a similar vein, yes.  As in it worked for my contrived test cases, but needed lots of love before first upload.
<slomo> jbailey: you wanted to ping ivoks and me about cdbs some time in the future ;)
<jbailey> Mithrandir: Yes!  Implementing associative arrays in pure posix shell was brutal, BUT I OVERCAME IT! MWAHAHAHAH
<seb128> jbailey: anyway, any cdbsN with multibuild would be welcome
<Mithrandir> jbailey: You. Are. Insane.
* Mithrandir goes to bed.
<Mithrandir> :-)
<slomo> gn8 Mithrandir :)
* dholbach ponders running away in fear too
<Mithrandir> it can't be that bad, can it?
<jbailey> Mithrandir: True, but my insanity makes me cute. =)
<jbailey> Good sleeps, Tollef.
<dholbach> good night everybody
<jbailey> G'n Daniel. =)
<jbailey> seb128: cdbs3, as proposed by dilinger, is more automake-style.
* seb128 runs away
<jbailey> seb128: So the idea is to generate at package generation time a very clean rules file so that it's easy to tell what's going on.
<seb128> (hate hate hate autocrap)
<seb128> hum
<seb128> that would be nice but not that useful if cdbs works correctly :)
<azeem> jbailey: this will also frequently change the .diff when cdbs changes, right?
<jbailey> azeem: Ideally, no.
<jbailey> azeem: The idea is that unlike the output from Automake, there's not alot of portability consideration that needs to be taken.
<jbailey> azeem: There's usually one correct minimal rules file.
<azeem> but packaging procedures tend to change over time, which has been abstracted by CDBS so far and will now reflect in different rules files
<jbailey> azeem: Right.  One of the critisisms of tools like debhelper and cdbs is that it's hard to keep them deterministic.
<lifeless> but I like debhelper
<lifeless> jbailey: is cdbs3 in python ?
<jbailey> lifeless: And cdbs will continue to use debhelper.  It's the best tool for the job.
<marian> hello
<jdub> jbailey: y'know what we need - a little rules language for making it really easy to package binaries
<jbailey> lifeless: I think that's what we settled on, yes.
<lifeless> sweet
<lifeless> you might sway me yet
<lifeless> I like things I can unfuck without writing perl
<lifeless> or shell
<Kamion> jbailey: generate rules file> argh, sounds like yada
<jbailey> jdub: Unforutnately, upstream packages aren't near regular enough for that.
<jbailey> Kamion: yada's output is absolute schite, though.
<jbailey> Kamion: And it's input isn't any better.
<Kamion> indeed so
<Kamion> but my impression has always been that it's the rules file generation that really drives people insane about it
<jdub> jbailey: 'copy tree of files' sort of stuff
<jbailey> Kamion: The idea is to take input that looks essentially like a cdbs1 rules file, and spit out something like you'd expect to write yourself.
<Kamion> rather than the actual input/output formats
<Kamion> (after all when working on Debian packages you end up dealing with just about every format known to man; what's one more?)
<Kamion> the issue is that we have ten years of expectation that debian/rules is the core file driving everything
<Kamion> changing that would be incredibly confusing ...
<jbailey> Ah, you mean so it would suck to discover that it had been generated when you get around to editting it.
<jbailey> Hmm
<Kamion> exactly
<Kamion> if debian/rules was the driving file and it produces debian/rules.out or something, that'd be less bad
<lifeless> store a checksum
<Kamion> lifeless: so missing the point
<lifeless> Kamion: not really. I think its very useful to be able to edit fucked output
<azeem> I think the history with debian/control{,.in} shows that this is a valid concern
<Kamion> losing your changes sucks, yes, but my point is more that breaking really hardcoded developer expectations is bad
<lifeless> so if one runs a tool to make debian/rules, and its buggered, just fix the rules file
<azeem> OTOH, debian/rules is more free-form than control, so you might rather expect something like that
<lifeless> so the question is - is the generation done per build or when the developer feels like it ?
<Kamion> lifeless: fine as long as one is running a tool to make some file *other* than debian/rules, please
<Kamion> lifeless: my point is that taking a file which has historically always been source and making it autogenerated is bad, when you consider that this will be hacked on by random people diving in quickly to fix a bug
<lifeless> ok, I see what you mean, but I am not convinced which the lesser harm is. Would you be happy with a stub rules file that says 'foo is the source, this file calls foo.bar for all targets'
* azeem still prefers the current CDBS way of doing things
<lifeless> s/foo.bar/foo.out/
<azeem> but I see how others don't like it
<Kamion> if their changes get clobbered, that's arguably better, because then we won't end up with source packages containing debian/rules files which started out as autogenerated and then were randomly hacked on
<Evaso2> hi, i doesn't know if could be also useful for developer but there is a list of package not in sync with his upstream version ordered by popcon values. There are also available upstream NEWS/Changelogs when you click on the upstream version number. If anybody would test it could find here: http://dehs.alioth.debian.org/no_updated.html
<jdub> so why isn't cdbs regarded as deterministic?
<Kamion> lifeless: I don't know if you've ever seen a configure file that somebody decided to hack by hand and then had to carry over its changes, but it isn't pretty
<lifeless> Kamion: I have
<lifeless> I also had to try to fix said configure.in.
<Kamion> jdub: its debian/control editing mode (optional) produces nondeterministic results because it's editing files after buildds have already inspected them to decide on what to do
<lifeless> I *know* why they hacked configure in that case. ewww.
<jdub> Kamion: *oh*
<azeem> I think CDBS has lost much credit due to nyu's random 'let's do this so to fix that' stuff people weren't prepared for
<jbailey> jdub: Because it's a tool with large scope that can be hard to track down the specific verions.
<Kamion> jdub: oh, I guess people are referring to substantial behaviour changes of the tool
<jbailey> jdub: The thing that debhelper did well is that when it broke, the app was probably only doing one little thing.
<jbailey> jdub: When cdbs breaks, it can take out completely random things.
<Kamion> debhelper is also very careful about compatibility
<jbailey> azeem: Yeah, that's probably true.
<Kamion> the DH_COMPAT / debian/compat stuff
<jbailey> cdbs was while I was still the main person hacking on it. =(
* seb128 just wants a multibuild for cdbs1
<azeem> seb128: fork it!
<jbailey> The other folks who did things with it tended to ignore the fact that it had a testsuite.
<jdub> i'd be surprised if sebuild and dhbuild were as efficient if not for cdbs :)
<seb128> and some "list of targets for common actions you may want to do" :)
<jbailey> Even a recent upload to Ubuntu *disables* one of the tests rather than fixing it.
<lifeless> garh
<lifeless> whodidthatcanyouhurtthembadlyplease
<seb128> jbailey: yeah, those KDE guys, breaking everything :p
<jbailey> One of the problems I ran into with cdbs2 was convincing folks to hack on it as well.  I could cheerfully dig the code up, but it's hard to find a decent common denominator that people will put up with.
<jbailey> Posix shell was the one thing that could be guaranteed to be on everyone's system.
<lifeless> and that noone will respect
<jbailey> Even doing the pieces in bash would make the code alot simpler.
<jbailey> lifeless: You can ask infinity or keybuk, my shell code is purty. =)
<lifeless> its not about you!
<lifeless> ;)
<jbailey> That's what my shrink says too...
<lifeless> say hi to her
<Kamion> work-in-progress bootloader screens can be really weird sometimes: http://people.ubuntu.com/~cjwatson/gfxboot/weird.png
<jbailey> Kamion: Clearly this is original work ;)
<seb128> jdub: you have not commented on the ubuntu-desktop session dialog discussion !
<Kamion> I'll leave credit, don't worry :)
<jbailey> To wrap this up, do you think it's worth me dusting off the cdbs2 codebase and keeping that going?
<jbailey> The rules files are like cdbs1 ones, but cleaner, and the codebase already has more documentation that cdbs1
<jdub> seb128: not yet
<jbailey> And hey, it's not written in obscure gnu make.  It *has* to be better. =)
<lifeless> jbailey: if you have a python version planned, start it ;)
<seb128> jbailey: as an user I don't really care about cdbs1/cdbs2/cdbs3, I want something easy to use and powerful enough
<jdub> #!/usr/bin/debian-packaging-ini-file-configuration-processor
<jdub> ;_)
<seb128> jbailey: cdbs1 with multibuild and some "list of targets to use for doing common actions" would be good enough
<jbailey> jdub: Policy says it has to be make.
<lifeless> jdub: #!/usr/bin/env debian...
<jdub> policy can bite my precious golden arse!
<jdub> that's interesting though
<lifeless> ---
<lifeless> $*:
<lifeless>   /usr/bin/debian-packaging-ini-file-configuration-processor $*
<jbailey> procmail based debian/rules files? =)
<lifeless> jbailey: my make syntax needs a refresher, I think there is a wildcard target facility though
<Kamion> policy> last time it came up it was observed that all the present examples that *weren't* make were deliberate exercises in obfuscation
<lifeless> so just thunk it through
<psusi> jbailey: hey... do you think you might have some time soon to take a look at http://bugzilla.ubuntu.com/show_bug.cgi?id=15897 again?  I think it needs reassigned back to Fabio
<jbailey> lifeless: There is, I do.
<Kamion> (and yes, that you could always thunk so it didn't restrict actual innovation as opposed to piss-taking)
<jbailey> I'll dig up the code base, dust it off and show it around.
<lifeless> Kamion: I wasn't piss-taking, as jbaileys comment shows I think ;)
<seb128> jbailey: why not sendmail configuration files while you are at it :p
<slomo> lamont-away, infinity: please give-back banshee on ppc, thanks :) and what happened to mod-mono?
<jdub> i'm not really piss-taking
<jbailey> seb128: I *like* sendmail.
<jdub> jbailey: jebus. lucky we don't support it. :)
<Kamion> lifeless: I wasn't talking about you
<seb128> jbailey: I know, and that's not normal :)
<Kamion> the piss-taking was years ago
<lifeless> Kamion: ahha. ok.
<jbailey> seb128: When I look at specs like PostfixCandy, I keep thinking about how trivial it would be in sendmail.
<Kamion> shoop, IIRC
<lifeless> 'Its not about you *either* lifeless
<lifeless> '
<jbailey> jdub: Hmm.  True.  I guess I'm in a position to argue that we could support sendmail, aren't I? =)
<jdub> luckily, no :-)
#ubuntu-devel 2005-12-14
* jdub shores up support policy decision matrix with some silly string
<jbailey> psusi: Right.  I'll assign this to Adam Conrad.  he's handling initramfs-tools now.
<psusi> jbailey: ahh... ok...
<psusi> hopefully those scripts are correct and can then be integrated into the dmraid package, and then that package added to the main seed
<jbailey> One of these days I'm going to have to get people to explain to me their anti-sendmail bias.
<slomo> lamont: ping?
<psusi> sendmail was a source of a LOT of remote root exploits over the years for one... for another, it is a royal pain to configure iirc
<jbailey> There hasn't been an exploit in *years* in it.  Configs that are dozens of lines long are maybe 4 or 5 lines in sendmail.
<lamont> slomo: ack
<jbailey> psusi: The biggest configuration problems that people have is that they try to edit sendmail.cf, I think.
<SEJeff> Overcomplex config files *cough* m4 macros are more likely to be misconfigured
<slomo> lamont: do you read what someone said to your lamont-away nick? ;) can you give-back banshee on ppc? and what happened to mod-mono now? :)
<jbailey> SEJeff: Do you think so?  Hmm.
<jbailey> I always liked the fact that there was a compile pass that would usually catch the worst of my mistakes.
<SEJeff> jbailey: That is a general rule. Most "hacks" stem from misconfigured software. Difficulty in configuration is directly proportional to security in most cases
<SEJeff> jbailey: See apache. apachectl configtest.
<SEJeff> jbailey: The apache config is human readable (arguably) sendmail.cf is not
<jbailey> Well, sendmail's exploits at the time were because the Berkley people regularily did acid before coding.
<jbailey> sendmail.cf is not intended to be treated like a config file any more than a compiled executable is.
<jbailey> The fact that some of us *cough*lamont*cough* can occasionally read compiled executables doesn't mean it's a good idea.
<SEJeff> jbailey: I realize that, but do you see my point?
<SEJeff> od is your friend :)
<lamont> slomo: lamont-away and lamont are two diff machines...
<jbailey> I don't actually.  Your statement still treats it like a config file.  What screws with me about postfix and (worse) exim is that the config files are always more than a page long.
<jbailey> I haven't a hope of keeping it all in my heda.
<jbailey> s/heda/head/
<jbailey> Especially when trying to match braces, or make sure that semicolons are lined up and such.
<jbailey> My biggest attraction to sendmail is usually that my mail config has no reason to be more than about 4 lines long.
<SEJeff> jbailey: The more difficult software is to configure, the higher the probability of misconfiguration. The higher the probability of misconfiguration, the lower the security. Most hacks come from misconfigured software
<jbailey> Right.  Your argument there seems in support of sendmail.
<SEJeff> Surely that is rational
<SEJeff> Easy configuration != sendmail
<jbailey> I'm just looking.  Literally a 3 line configuration file to act as a mail hub.
<SEJeff> I would say that more lines that are easier to read is less prone to errors than less lines and more difficulty to read
<SEJeff> In some ways, I equate sendmail to gnu hurd. It was designed overly complex from the start. That is it's main problem
<jbailey> Mmm, I think GNU Hurd's failings are far simpler than that. =)
<jbailey> I think that the maintainers of the software have never had any interest in seeing it finished.  So they would never accept a hack to make it work, all patches had to be correct instead.
<SEJeff> I was making a very loose analogy
<jbailey> SEJeff: Ah.  I was until recently one of the main debian hurd-i386 porters. =)
<SEJeff> Sendmail works very well. It is just grossly "over-engineered"
<SEJeff> nice
<SEJeff> If it was designed to be a bit more simple from the beginning (similar to qmail) it likely would have had less security problems
<jbailey> I truly think that sendmail's security history stems more from the fact that until the mid 90's noone cared about programming securely.
<SEJeff> You are right, but a simpler codebase is easier to audit
<jbailey> And by the mid 90's sendmail was old enough to have acquired *alot* of history. =)
<SEJeff> true true
<marian> z600cups-1.0-1.gz.sh
<GnuKemist> ogra, hi... busy?
<GnuKemist> stub, hi... u around?
<stub> ?
<GnuKemist> stub, I'm OgMaciel
<GnuKemist> stub, we talked last night
<GnuKemist> stub, about changing my email
<GnuKemist> in launchpad
<GnuKemist> remember me?
<stub> Sure
<GnuKemist> stub, can I pvt?
<stub> pervert?
<GnuKemist> private
<GnuKemist> hehe
<\sh> tstststs
<stub> Sure
<GnuKemist> \sh, hi
<\sh> hey og :) how's life?
<GnuKemist> \sh, so far so cold... =)
<GnuKemist> \sh, you?
<\sh> hehee....
<\sh> GnuKemist: see planet...and excuse my words :)
<GnuKemist> \sh, hold on
<GnuKemist> \sh, read this in the meantime...  =)  http://blog.ogmaciel.com/?p=28
<GnuKemist> \sh, that really sucks man...  all I can say is wish you a better job next time...  I sort of did the same about 15 months ago
<\sh> GnuKemist: hmmm....is portugese? I can understand "apri of 2006"
<GnuKemist> hehe
<GnuKemist> \sh, sent you the portuguese version
<GnuKemist> hehe
<GnuKemist> sorry
<GnuKemist> hold up
<GnuKemist> \sh, here... http://www.ogmaciel.com/?p=219
<\sh> GnuKemist: the job was good and the people were good as well..but those new bosses..with their non human attitude ... sorry..not my thing...and I told myself, be honest
<GnuKemist> \sh, but feel free to ask me anything in portuguese ;)
<GnuKemist> \sh, you know... unfortunately I ended up at another place where they treat people like garbage...  it is paying the bills...  =/
<GnuKemist> stub, can anybody help me with my issue?
<\sh> GnuKemist: well...it's "bom dia" right now :)
<GnuKemist> \sh, yup... but for me (UTC - 5) is actually "boa noite"
<mdke> GnuKemist, #launchpad?
<\sh> GnuKemist: "bom dia" == good morning, right?
<GnuKemist> mdke, went there already... thanx
<GnuKemist> \sh, yup... boa noite == good evening
<mdke> GnuKemist, they are the only people who can help with launchpad problems
<Kamion> if anyone cares to figure out why the current installer images can't manage to reboot (ctrl-alt-del, or when you reach the end of the first stage), please be my guest
* Kamion -> bed
<daniels> Kamion: 'nacht
<GnuKemist> mdke, thanks...  I was told to look for elmo but was also talking to stub ... will move on with the subject though...  ;)
<\sh> good night..
<GnuKemist> \sh_away, night
<mjg59> mono-best: symbol lookup error: /usr/lib/beagle/libbeagleuiglue.so: undefined symbol: _ZN13nsCOMPtr_base25assign_from_gs_contractidE24nsGetServiceByContractIDRK4nsID
<mjg59> Nngh.
<mjg59> What is it with mono and shlibs breakage?
<ajmitch> mjg59: it might be firefox love
<ajmitch> we'll get beagle 0.1.3 in within a couple of days, I think
<lamont-away> jbailey: grep -ve ^# -e ^$ /etc/postfix/main.cf | wc
<lamont-away>      48     149    1564
<lamont-away> and that's a _complex_ config
<lamont-away> stock ubuntu config is about 12 lines long
<sistpoty> elmo_: please sync childsplay from unstable, ubuntu override ok
<YokoZar> Is there a way to give a nonroot user permission to use ports below 1024?
<lifeless> you can probably do that with SELinux, but why
<TerminX> does anyone know offhand when the KDevelop packages might be rebuilt to work with the newer stuff in Dapper?
<sistpoty> TerminX: what do you mean with "work with the newer stuff in dapper"?
<TerminX> kdevelop doesn't appear to be installable
<TerminX> it looks like it hasn't been rebuilt with fixed dependencies and all that after the KDE 3.5 stuff went in
<sistpoty> TerminX: since kdevelop is in universe, you might want to come to #ubuntu-motu and ask there
<TerminX> ah
<jbailey> lamont-away: Right, my criticism of bad configs was more targetted at exim than postfix.
<jbailey> lamont-away: In postfix I couldn't figure out how to do some of the things I wanted, but I suspect that was me not finding the documentation rather than it not being possible.
<spacey_ki> https://wiki.ubuntu.com/FirefoxNewVersion
<spacey_ki> :o
<spacey_ki> mozilla ffox faster then ubuntu build?
<jdong> spacey_ki: not necessarily
<jdong> spacey_ki: true for 1.0.x in Breezy
<jdong> spacey_ki: untrue for any other builds for any other versions or any other releases
<calc> anyone here happen to know why gdm would work with MergedFB mode but gnome itself just clones the same screen for both monitors?
<currios84> x
<calc> currios84: do you know how to properly setup MergedFB?
<calc> i did the way i read on ubuntuforums but it doesn't seem to work for gnome itself, just for gdm :\
<jamesh> calc: the xorg ATI drivers?
<jamesh> I have this in the device section of xorg.conf: Option "CRT2Position" "RightOf"
<jamesh> I've also got CRT2HSync, CRT2VRefresh and MetaModes set
<calc> Section "Device" Identifier      "ATI Radeon 9600" Driver          "ati" BusID           "PCI:1:0:0" Option          "MergedFB"              "true" Option          "CRT2Position"          "RightOf" Option          "OverlayOnCRTC2"        "true"
<calc> EndSection
<calc> that is what i have on mine
<calc> i'm using the open source drivers for 9600
<calc> that are part of xorg in dapper
<calc> MetaMode is required for it to work
<calc> it would be nice if the manpage mentioned it must be defined... or else its cloned
<calc> this dual head is at the limits of sanity
<wasabi> Odd. I'm a bit curious why I have libc 2.3.5-6 installed... when the latest in Dapper is 2.3.5-1ubuntu17
<infinity> Installed from sid?
<wasabi> Not sure.
<wasabi> I don't know why I would have done that.
<wasabi> The most I've ever had from sid was the deb-src lines.
<wasabi> Heh. highend and lowend kernels.
<wasabi> Interesting seperation.
<infinity> We were having a hard time coming up with good names to describe what they were meant for. :)
<wasabi> One of these days there will be one kernel to rule them all.
<wasabi> With all this special core stuff in modules.
<infinity> If we used something meaningless like "Server" and "Enterprise Server", users would all just go and install the latter, assuming it has "cool enterprise features!"
<infinity> In reality, the highend server kernel is for almost no one.  Wankload of CPUs, gobs of RAM, NUMA support, etc.
* HrdwrBoB raises hand - I need that one
<infinity> You'd be one of the few. :)
<infinity> server-lowend will be fine for me.
<HrdwrBoB> well realistically I need both 
<infinity> 8 CPUs, 32G of RAM...
<HrdwrBoB> depending on the boxes
<infinity> If I had kit bigger than that, I'd be pretty happy, but...
<HrdwrBoB> surely lowend has numa support for amd64
<infinity> Why would it need to?
<HrdwrBoB> because it would be faster?
<infinity> ...
<infinity> Does Linux actually keep track of which CPU owns the memory?
<infinity> My understanding of amd64 was that, despite the memory controller being embedded in the CPUs, the system presented the RAM as one massive block.
<infinity> But, I'll admit I haven't done much amd64 SMP.
<infinity> Ahh, some quick googling shows I'm mistaken and Linux can actually do NUMA on amd64 kit.  Neat.
<HrdwrBoB> I guess it depends on your definition of lowend
<wasabi> SO what is NUMA anyways?
<wasabi> Wait I can just look that up.
<wasabi> gg lazyweb
<infinity> HrdwrBoB : Well, our definition of lowend is pretty "high" to most people.
<infinity> HrdwrBoB : Perhaps we should discuss this in #ubuntu-kernel at some point.
<infinity> HrdwrBoB : For one thing< I'd like to see benchmarks of plain SMP versus NUMA on amd64 systems, since NUMA is an option there, not a necessity.
<infinity> (As opposed to other systems, where no NUMA means no RAM, or missing lots of it)
<infinity> s/amd64 systems/lowend amd64 systems/
<infinity> I'm sure there are some crazy highend amd64 configurations that NEED NUMA.
<infinity> I'm not so sure we boot on them. :)
<HrdwrBoB> infinity: well I have a few single amd64 computers
<HrdwrBoB> most of the servers are dual cpu, the higher end ones are dualcore-two way
<HrdwrBoB> given the relative cheapness of an smp opteron box
<HrdwrBoB> I would class a single amd64 machine as a desktop level machine, and a two way dualcore a low end server
<HrdwrBoB> a high end server would be 4+ dualcore CPUs
<fabbione> morning
* infinity curses CUPS and anything even vaguely related to it.
<HrdwrBoB> er... does anyone here use a HP DL385 and have a few minutes?
<bob2_> how do I tell totem and firefox to never evr ever try to load the plugin to play movies?
<bob2_> all it appear to do is crash firefox
<jdub> bob2_: view and edit actions on the downloads page
<jdub> bob2_: turn off the plugins
<fabbione> hey jdub
<jdub> yo fabbione 
<fabbione> jdub: got a minute for me?
<jdub> sure!
<fabbione> cool
<jdub> sineine made your list during the server transition btw, if you didn't already know
* infinity wonders how long start-stop-daemon has been broken..
<dholbach> hellas
<torkel> HrdwrBoB: depends on the question :-)
<wanglei1123> hello?
<wanglei1123> is anyone here?
<crimsun> (yes?)
<wanglei1123> hi , is anyone can help me answer my question? 
<Mithrandir> probably not, since you don't ask it.
<wanglei1123> :)
<Mithrandir> and also, this is not a support channel, so if it's not development related, please use #ubuntu instead.
<wanglei1123> i wanna know , what script do the hardware scaning of installing ubuntu
<wanglei1123> and what scripts recognize your scsi device and modprobe it ?
<fabbione> wanglei1123: there is no such script.. it's all done by kernel/hotplug/udev
<wanglei1123> and what scripts recognize your scsi device and modprobe it  when you installing ubuntu system, thank you sooo much !: )
<fabbione> it's all kind of "automatic"
<Mithrandir> udev just acts on the information exported by the kernel and available hardware
<wanglei1123> udev and detect , recognize and modprobe my scsi device ? 
<infinity> I've come to the conclusion that concordia is too slow.
<Mithrandir> infinity: I told you that a long time ago, didn't I? :-P
<infinity> Yes, well, I made the mistake of building something there.
<infinity> Because my girlfriend's actually using her computer.  How dare she.
<wanglei1123> hi everyone ,does udev and detect , recognize and modprobe my scsi device ? 
<infinity> s/and detect//
<wanglei1123> ? it doesn't make sense to me :(
<wanglei1123> fabbione:  does udev can  detect , recognize and modprobe my scsi device ? 
<fabbione> wanglei1123: stop flooding this channel
<fabbione> we already answered your question
<wanglei1123> sorry .......
<fabbione> no actually i did
<calc> anyone happen to know when usb hotplug mounting was added to ubuntu? i tried 4.10 live/install and 5.04 live so far and they don't actually mount
<fabbione> or Mithrandir 
<wanglei1123> but it still don't make sense to me ........
<calc> i'm looking for what it does to add it to a custom debian dist
<wanglei1123> Mithrandir: hi :)
<wanglei1123> Mithrandir: hi : )
<calc> but upon looking for it i can't seem to make it work :\
<jdub> calc: it worked with warty
<calc> i wonder if its some kind of weird interaction with vmware
<calc> i'm running ubuntu under vmware where i am doing the testing (at work)
<wanglei1123> ...
<wanglei1123> anyone....
<crimsun> wanglei1123: please migrate to #ubuntu. Your question has been answered already.
<calc> crimsun: hi :)
<crimsun> 'lo calc 
<calc> crimsun: i found out recently i may have more time to work on linux again :)
<wanglei1123> crimsun: thanks so much : ) 
<calc> i'm going to be working with one of my friends at a company he started, so i won't have a commute anymore :)
<pitti> Hi
<crimsun> 'morning pitti :)
<pitti> Hi crimsun 
<siretart> fabbione: do you have some wmv files so that I can test mplayer/amd64?
<siretart> morning, btw ;)
<fabbione> siretart: i think the last mplayer is FTBFS on amd64
<fabbione> indeed
<siretart> fabbione: ok. will look into this now
<fabbione> siretart: thanks. the culprit is to enable the w32codecs support. it's working fine from marillat archive, so i assume the fact that you disabled it at random have broken the stuff :)
<siretart> fabbione: I think the marillat package build just by sheer luck. The build system slomo did is WAY saner
<fabbione> siretart: well.. it FTBFS ;)
<siretart> fabbione: first, I will fix the ftbfs, then I will compare our mplayer package with how marillat builds on amd64
<fabbione> siretart: ok :=)
<siretart> fabbione: do you have a media file for me to test afterwards?
<fabbione> yes
<fabbione> just any wvm you find on the net
<fabbione> none of them play video
<siretart> fabbione: suprisingly, marillat does not compile with --enable-win32 on amd64. now I'm a bit confused..
<fabbione> siretart: ok, i will debug it and send you a patch
<siretart> fabbione: I have found a wmv now, which can be played in both mplayers!
<siretart> the new one and the one from breezy
<siretart> fabbione: but it is wmv8. there seem indeed to be problems with wmv9
<fabbione> yes that's correct
<siretart> fabbione: for me, the correct solution seems to be the same approach as for openoffice: introduce a mplayer32 package for amd64, which is compiled in 32bit
<Mithrandir> siretart: that's very, very crackful.
<fabbione> siretart: dude.. it was working.. there is no need of mplayer32 or something
<siretart> I tried a wmv9 file (I only have one here), but the breezy mplayer had problems with that, too
<Mithrandir> : tfheen@thosu ~ > ldd /usr/bin/mplayer | wc -l
<Mithrandir> 90
<Mithrandir> you don't want to provide a 32 bit libkrb5support for mplayer, do you?
<fabbione> siretart: probably i was using the marillat one in breezy.. check with that
<siretart> fabbione: will do
<siretart> Mithrandir: wtf mplayer needs krb5?!
<fabbione> siretart: otherwise just gimme time.. mplayer is not first priority for me
<fabbione> to fix at least ;)
<Mithrandir> siretart: it is linked to something which is linked to something which is linked to kerberos, I guess.
<fabbione> ldd /usr/bin/mplayer
<fabbione>         libporn.so.0 => /usr/share/porn/libporn...
<fabbione> ;)
<Mithrandir> you, you, FHS-rampager
<siretart> lol
<fabbione> Mithrandir: the "share" was NOT a case :P
<dholbach> elmo_: please sync libglademm2.4 from sid, ok to override, thank you
<ogra> whops
<siretart> fabbione: I just installed the original marillat mplayer binary on my amd64 system, and it is not able to play wmv9, too
<siretart> and this was painful!
<fabbione> siretart: ok i will look at it myself.. don't worry. thanks
<pitti> Riddell: here?
<siretart> fabbione: please let me know what you find out. every fucking webforum in the web claims that the only way to view wmv9 on amd64 is to compile a 32bit binary (which doesn't seem to be that hard, even suse lusers seem to manage it)
<fabbione> ahahah
<fabbione> ok
<siretart> and I didn't succeed to play a wmv9 video with breezy's mplayer, like you claim. so now I'm a bit confused
<ajmitch> hi
<siretart> hi ajmitch 
<fabbione> siretart: the main issue for me is to roll back to breezy to test
<fabbione> siretart: i only have one amd64
<fabbione> and it's doh.. running dapper
<fabbione> ;)
<siretart> fabbione: I'd love to upgrade my amd64 box to dapper, but I really need the *caugh* nvidia binary drivers  *caugh*
<fabbione> siretart: they work..
<fabbione> i am using them
<siretart> they do?
<fabbione> infinity: made them a while ago
<fabbione> yeps
<ajmitch> apparantly
<siretart> cool!
* ajmitch hasn't rebooted yet to test them, but they're installed here
<fabbione> ajmitch: i am using them as we speak
<fabbione> i am force to use them actually
<siretart> hmmmmm :)
<fabbione> otherwise my 3 heads setup doesn't work
<ajmitch> ah
<fabbione> speaking of which..
<ajmitch> 3 sounds nice
<fabbione> this weekend i could plug another 3 heads
* ajmitch only has 2 CRTs
<ajmitch> another 3? how big a desk do you have?
<siretart> fabbione: so you are hacking on multiseat?
<fabbione> ajmitch: big
<fabbione> siretart: no. it's just my fancy workstation
<siretart> ah
<fabbione> ajmitch: they would be 2 rows by 3
<ajmitch> my desk is only big enough for 2 monitors :)
<fabbione> ajmitch: well i did hack my desk too ;)
<fabbione> there is a kitchen table 3 cm thick on top of a normal desk
* siretart is also at 2 heads (plus laptop). 6 heads sounds really nice :)
<fabbione> that helps in space and to distribute the weight along all desk
<ajmitch> if I moved the spare computer I could fit another couple of screens on it
<lbm> slomo_: around?
<stewski> hi any edubuntu developers in
<fabbione> stewski: #edubuntu is probably a better place to ask :)
<stewski> cheers Im in there too
<stewski> just found this review http://www.bloggingbaby.com/entry/1234000340071196/
<dholbach> haha :)
<stewski> might be useful feedback, just wanted to say keep up the amazing work
<dholbach> stewski: i laughed, because it had the wrong observation about ogra being mr. shuttleworth :)
<stewski> ah yeah I didnt pay much notice to that
<stewski> I thought edu was primarily targeted at schools not home users (at the moment)
<dholbach> stewski: but thanks for your words of praise, ogra will appreciate them
<ajmitch> ogra = mark? haha
<stewski> but fairly objective feedback I thought?
<dholbach> (as everybody else who is involved)
<ogra> i thin its corrected now .... at least the author said so in a mail last night
<ajmitch> morning ogra :)
<ajmitch> ogra: just think what fun you could have if you could sign his cheques ;)
<stewski> lmao
<ogra> ajmitch, he said it would be ok with him, but i'd have to take *all* his mail :P
<stewski> I'm hoping to become a teacher and take ubu to school
<stewski> s
<dholbach> ogra: and you could hack on launchpad for him :)
<ajmitch> dholbach: don't be so evil
<ogra> heh
<stewski> any tips for where to go to find out about setting edubuntu up as a LTSP thin client set up?
<ogra> http://wiki.edubuntu.org/EdubuntuInstallNotes
<ogra> its done by default, you only need to edit one file post install ...
<stewski> really sounds too good to be true :-)
<ogra> heh
<stewski> better get some space on my pcs and test this out
<ogra> unlike the article claims, we dont target the home market in first place ;) thats only an addon ...
<ogra> our main target is the ltsp managed classroom ;)
<stewski> do you target at school hardware at all? Research Machines etc?
<stewski> yeah I thought the article was kind of ascue for that, first schools later parents/home?
<ogra> later we'll also do that ... thats only our first release, so a single classroom was targeted... we'll grow over releses
<ogra> the current CD has both options (school and home) its just that chool is the default ;)
<ogra> *school
<stewski> Im thinking when in the UK weee directive comes in there will be plenty of PC recycling going on, should give the cause a real boost here at least
<ogra> yeah :) 
<stewski> cool do you have anything to do with the cutter project?
<ogra> nope, never heard of it ...
<stewski> http://www.cutterproject.co.uk/
<stewski> Im studying at the moment but putting together details for FLOSS in schools in the UK
<stewski> there have already been a couple of excellent examples, but I see what you guys as doing taking it to a new level
<ogra> ah, yes i remember, there is a guy sometimes in #edubuntu from the cutter project
<pitti> Riddell: I found yet another flaw in the xpdf patch; when you arrive, can you please ping me? then we sort out the patch together
<stewski> xpdf and pdf handling in general under linux seems rather weak, or am I mising something?
<pitti> stewski: define weak?
<stewski> sorry yeah not helpful I know
<stewski> copying text not possible
<pitti> xpdf, poppler, evince, pdflatex, openoffice - they all deal well with PDFs
<stewski> difficult to do anything with pdfs other than view
<ogra> pitti, where is the reason for xpdf ? i thought we had switched everything to evince in breezy already
<pitti> stewski: oh, yesterday I impressed my flatmate with that - I wrote 100 lines of python which take a PDF telephone bill and calculate the costs for the three people that use it :)
<pitti> ogra: it's still in main in warty and hoary, and we can't change that :)
<pitti> ogra: and the same code is in poppler, warty's cups, and kpdf and koffice
<pitti> ... and tetex
<ogra> sure, if you finally finish your time machine we can ! 
<pitti> ogra: then I had to fix poppler instead of xpdf in warty and hoary, which doesn't make it any different :)
<dholbach> ogra: the time machine is just a big box and around 100 lines of python code, pitti will make it happen
<pitti> heh
<pitti> we could fix vulns even before they appear in the wild :)
<ogra> dholbach, i guess the box is the problem here :)
<pitti> right at the time the author writes a vulnerable piece of code, we can retroactively hit him with a cluebat
<dholbach> nono, that's easy too
<stewski> a right I saw pdflatex but in terms of gui tools that work with pdf I seemed to have problems just grabbing a bit of text
<stewski> although fair point could be user err
<pitti> stewski: what's wrong with copy&paste from evince?
<pitti> stewski: if you need the whole text with or without layout, pdftotext does fine; pdftohtml works well, too
<stewski> thnx a bundle, jsut not aware of them
<pitti> stewski: but if you look for something like Acrobat, then we have to disappoint you
<stewski> well not having acrobats not a biggy
<dholbach> how well does scribus work with that?
<pitti> there is a reason Adobe can charge a good chunk of money for it (and it's indeed a good piece of software)
<pitti> but most people don't need acrobat for the tasks they want to do
<stewski> does evince handle pdf ona default ubuntu?
<pitti> stealing a picture from a PDF, or a chunk of text can be done with less effort
<pitti> sure
<ogra> yup
<stewski> oh my install mustve got monkeyd with :-) mines going for xpdf
<stewski> cant think who couldve done that :-0
<ogra> which version is that ? 
<ogra> the older ones used xpdf
<stewski> 5.04 upgrade to 5.10
<ogra> ah, and you forgot ubuntu-desktop before upgrading ? 
<pitti> stewski: I assume you removed ubuntu-desktop?
<stewski> I didnt think I missed that but it possible
<dholbach> seb128: !
<ajmitch> hey seb128 
<\sh> ok...time to get up..have a shower pack the rest of the company notebook stuff and go to my ex-office...get my ass whipped
<ogra> tsk, seb128 what about your holiday you addict ...
<stewski> gotta dash like I say, you guys are good eggs one and all! and thanks for the tips
<pitti> we are 'good eggs'? is that good or bad?
<ogra> heh
<pitti> :)
<ajmitch> good, I hope
<ogra> i was wondering too
<\sh> it's xmas time not easter time :) so we are good donkeys but not good eggs :)
<seb128> hey everybody
<pitti> Hi seb218
<pitti> and seb128, too :)
<ogra> hi seb128 :)
<lunitik> Is there any way you could sink packages from wine.sf.net 's debian repo, instead of mainstream Debian? They are far more recent, it would be much appreciated.
<lunitik> I tried to file this as a feature request via bugzilla... but launchpad doesn't make it very obvious in regards to how to file this...
<Kamion> err ... we already do?
<Kamion>       wine |      0.9-1 |      unstable | source, i386
<Kamion>       wine | 0.0.20050725-0ubuntu1 | dapper/universe | source, i386
<Kamion> somebody might need to update them but we certainly aren't tracking Debian for wine
<Kamion> Scott Ritchie's looking after those
<lunitik> Kamion: hmm... I searched packages.ubuntu.com, and it doesn't list the 0.9.x series?
<Kamion> oh, hang on, 0.0.20050725 < 0.9, hmm
<Kamion> talk to Scott Ritchie
<dholbach> YokoZar is his ircnick
<Kamion> lunitik: "unstable" => Debian not Ubuntu
<YokoZar> hi
<lunitik> Kamion: he maintains the Ubuntu packages? because if Ubuntu is sinking with Debian, its taking forever to get in....
<sladen> aren't the wine packages coming *directly* from the winehq guys, because they had so much trouble pushing them to Debian?
<YokoZar> It's taking forever since I don't have my key signed until the holidays
<Kamion> sladen: yes
<lunitik> Kamion: sinking with *his* archive would surely make things better?
<YokoZar> Yes.  Speaking of which, I just put up a new package a few hours ago (0.9.3)
<Kamion> lunitik: "syncing", and yes elmo could do that if requested and if it didn't require Ubuntu-specific modifications
<lunitik> Kamion: his packages are stable ime, however, its it'd be more convenient to not have to add his repo every time...
<YokoZar> I saw no rush to do so, since I assumed I'd find some sap to sign my key in time, heh
<YokoZar> (get elmo to do it that is)
<lunitik> Kamion: if you could please look into that and talk to him about it, it would be much appreciated... I'm banned from #ubuntu since a few months ago, so don't have much contact with the community lately  :/
<YokoZar> lunitik: I'm right here duder
<Kamion> lunitik: no, I can't
<ogra> lunitik, until YokoZar can take over in ubuntu, \sh might be your best bet to talk to, he cared for the breezy and dapper packages so far
<Kamion> lunitik: I was just helping you out, I don't want to become responsible for it
<YokoZar> I don't see what the rush is anyway
<lunitik> YokoZar: ahh, my mistake... hah... any chance of that... simply installing the packages on Ubuntu dapper works fine (other than not editing gnome menu), so it shouldn't be _that_ much work  :P
<YokoZar> if the packages at winehq don't work in Dapper I'd like to know
<YokoZar> They should work
<ogra> lunitik, \sh will be able to request the sync from winehq ...
<lunitik> YokoZar: they do... winehq.com points you to wine.sf.net packages if you click on Ubuntu packages, so we are refering to the same thing  :)
<Kamion> winehq isn't listed in josie (the sync script) so evidently no-one has yet done a direct sync
<YokoZar> Well they're built against breezy at the moment, not dapper
<Kamion> syncs are sourcewise not binarywise; they'd be rebuilt on our buildds
<ogra> Kamion, i know \sh uses only the winehq packages ...
<YokoZar> Right
<lunitik> YokoZar: they still work fine... GNOME menu issues appear to be upstream because it doesn't work on any distro....
<ogra> we talked about it several times ... probably elmo syncs the manually or something ...
<YokoZar> Basically a sync shouldn't be needed since putting in the package is something I should do after I get my car back and drive to a key party o'er the holidays
<Kamion> ogra: that seems highly unlikely
<ogra> strange 
<YokoZar> lunitik: Yes, this is known
<ogra> sad \sh isnt here to answer ...
<YokoZar> If you play video games, you use the latest Wine ;)
<Kamion> ogra: josie has a huge load of listings for other sites. why on earth would elmo sync them manually when he has a very configurable script he wrote to do it for him?
<YokoZar> What do we track other than Debian unstable?
<ogra> Kamion, i dont know elmos sync practise, i was just guessing ... they have to come in somehow ...
* lunitik mumbles something about getting him unbanned from #ubuntu while he's at it.... 3 months ban for questioning someone is kinda dumb, the ubuntu code of conduct etc states that arguments happen, but should be avoided.... continual things will be dealt with, mine wasn't, 98% of the time, I was helpful  :/
<ogra> YokoZar, do you already have your launchpad account and wikipage ready for becoming a member ? 
<YokoZar> pretty much, I might need to clean it up a bit though
<YokoZar> I remember doing that stuff a few months ago
<ogra> just because i dont seeyou on launchpad anywhere ;)
<Kamion> YokoZar: far too many to list, mostly small archives picked up from apt-get.org synced into multiverse
<YokoZar> lunitik: don't bring it here, bring it to forums
<YokoZar> ogra: I've filed a launchpad spec...
<lunitik> YokoZar: alright, sorry.
<Kamion> blackdown, marillat, mythtv, xfce are notable ones
<infinity> ogra : Uhm, it's pretty obvious from the version number that wine isn't synced at all, it's hand-merged.
<YokoZar> ahh
* dholbach hugs Keybuk
<ogra> infinity, ah ... that explains it ...
* Keybuk hugs dholbach back
<ogra> didnt look at the version no
<dholbach> :)
<YokoZar> version "OLD"
<infinity> YokoZar : I was referring to the -XubuntuX .. :)
<mvo> Keybuk: hello! do you have any plans to switch to bzr for dpkg eventually?
<lunitik> YokoZar: where exactly? I don't see a relavent forum?
<dholbach> lunitik: talk to Seveas, crimsun, tritium, somebody else who is op?
<Keybuk> mvo: yeah, eventually ... probably when I next sit down and hack on it
<Keybuk> I have plans to do it over the christmas break
<lunitik> dholbach: Seveas banned me for a personal dispute  :/
<mvo> Keybuk: nice, I talked to bubulle about it today because I would like to switch apt to it too (after my last "fun" with baz I'm feed up)
<dholbach> lunitik: then talk to him - this is definitely the wrong place
<lunitik> dholbach: pretty immature really... and the ban has been way drawn out  :/
<ogra> that sounds highly unlikely
<mvo> Keybuk: and apparently dpkg and apt are currently his only projects that use tla/baz
<lunitik> dholbach: lots of ops here *cough*ogra*cough*, I think Seveas is /ignore'ing me  :(
<dholbach> lunitik: as i said... this is the wrong place
<lunitik> dholbach: I understand that, YokoZar pointed me to the right place, however I don't know where, and I asked....
<ogra> lunitik, i wont unban people Seveas banned without knowing what was the issue, please talk to him, and pleas not in this channel as dholbach says
<Keybuk> mvo: yeah, dpkg is now my only baz project
<dholbach> apart from that, you can always mail
<lunitik> ogra: Ask him to unignore me, and I will be more than happy to talk to him about it....
<Kamion> lunitik: #ubuntu-devel *is not an escalation channel for disputes in #ubuntu*. It is a development channel. *Please* respect that!
<lunitik> blah, whatever though... I care too much imo, one less person willing to devote time to supporting users is affects Ubuntu, and saves me time  :/
<sivang> seb128: did you fix the panle application thingy? 
<sivang> (just asking)
<seb128> what "panle application thingy"?
<seb128> empty menu?
<sivang> seb128: yes, and application menus that doesn open due to gam_server
<seb128> it opens, it has just no content :p
<seb128> and no
<seb128> I don't have the issue here
<sivang> ah ok, then I need to upgrade at least it will open :)
<seb128> upgrade will not do anything
<sivang> I need to restart panel? or kill and restart session?
<seb128> we have not changed anything for 2 weeks or so
<seb128> ?
<seb128> for what?
<sivang> nono , sorry. my bad
<sivang> ok, thankss
<siretart> seb128: I just upgraded to dapper on my amd64 box, I'm not bitten by the bug there. strange, no?
* siretart lunch. cu
<dholbach> siretart: bon apptit
* dholbach grabs food too
<jdub> Kamion: bootchart-udeb for bootcharting installer/livecd?
<pitti> crimsun: do you plan to fix osh for warty?
<Kamion> jdub: yes, https://wiki.ubuntu.com/LiveCDPerformance
<Kamion> it only activates if you put 'bootchart' on the kernel command line (AIUI)
<jdub> Kamion: fun :)
<jdub> Kamion: are we still doing the simplified livecd for dapper?
<Riddell> pitti: there's new xpdf patches in KDE's SVN but not available through the security page yet and apparantly dirk is waiting on confirmation from the xpdf author
<pitti> Riddell: he also asked on vsec for confirmation
<pitti> jbailey: Hi Jeff, how are you?
<jbailey> pitti: I'm ALIVE!
<jbailey> pitti: I'm ALERT!
<jbailey> I FEEL GREAT!
<pitti> yay :)
<jbailey> pitti: You? =)
<fabbione> jbailey: time to stop smoking crack? ;)
<jbailey> fabbione: Nah, occasionally I wake up really cheerful.
<jbailey> fabbione: It's days like today that it's probably best that I work alone. =)
<fabbione> jbailey: i am not going to suggest reasons why you wake up so cheerful :P
<Kamion> jdub: so I believe; Mithrandir is taking care of that
<jdub> cool
<pitti> jbailey: knee deep in patches :)
<jbailey> fabbione: You wouldn't want to be vain and say that it was from seeing your smiling face? =)
<jdub> seb128: 'volume monitor' and 'recording level monitor' in 'sound & video' -> shouldn't be there anymore - should i file a bug for you?
<Kamion> (yes, I think I've finished uploading apt-setup for now)
<Keybuk> only two?  that's not worth a daniels memorial award
<janimo> Keybuk, any reason why alsa-utils.rules is in /etc/udev and not under rules.d ?
<Keybuk> yes, I haven't fixed it yet
<janimo> I am trying to figure out why my ALSA card doesn;t work
<janimo> OSS driver gets loaded before
<Keybuk> I'll be attacking ALSA ~Monday/Tuesday
<Keybuk> yes
<janimo> i810
<janimo> ok thanks
<Keybuk> sound cards are known broken currently
<Keybuk> the OSS driver is loaded because the OSS blacklists haven't yet been rewritten as modprobe blacklist files
<Keybuk> (they're still the old hotplug blacklist files)
<janimo> ok, others said they have ALSA working so I thought I have an exception, glad it's not the case
<Keybuk> once over that hurdle, you'll still find that the sound card mixer state, etc. aren't restored
<Keybuk> nah, some people are just lucky
<janimo> once this is done /etc/hotplug can go away I gues?
<Keybuk> yes
<janimo> ok rock on then :)
<seb128> jdub: no, get a buildd to kick the build back
<seb128> jdub: it failed to build due to ncb Depends issue which is fixed, just need a retry
<seb128> jdub: thanks for the reminder :)
<seb128> infinity, lamont-away: please give a retry to gnome-media
<fabbione> jbailey: ehehe
<jdub> seb128: rawk
<tseng> lo jdub 
<tseng> jdub: my mom ordered that 24" dell
<jdub> raw
<jdub> k
<tseng> ya cant wait to see what that thing looks like
<tseng> next to my "tiny" 20"
* ogra dies in envy ...
<tseng> hi ogra :)
<ogra> hey tseng, congrats :)
<tseng> hm the 24 is hers :P
<tseng> not even in the same town as me
<ogra> ah, dmaned, i thought it was your christmas present ;)
<Kamion> Keybuk: three
<ogra> Kamion, did you intentional time it in exact 10min intervals ? :)
<ogra> (the middle one differs in 1 sec thiugh )
<ogra> *though
<jbailey> Hmm.  Evolution needs address affinity.
<jbailey> If I'm emailing with my @ubuntu.com address, it should prefer the recipients @ubuntu.com address.
<ogra> yeah... thats a long missing feature
* ogra reboots to breezy to be able to burn CDs ....
<janimo> ogra is the hwdb database accesible somewhere?
<tseng> hwdb.ubuntu.com
<janimo> thanks
<Kamion> ogra_: queue/unchecked is processed from a cron job that runs every five minutes, so that isn't too surprising
<janimo> not very detailed
<ogra_> Kamion: /usr/bin/report-hw: 12: discover: not found
<ogra_> The final umounting fails
<Kamion> ogra_: known, fixed in the archive
<Kamion> the discover thing I'm ignoring, it doesn't matter
<ogra_> oki, fine
<Kamion> fixed> busybox 1:1.01-3ubuntu5
<ogra_> hmm... ltsp-client-builder is borked too :( .... doesnt find breezy on the CD .... how surprising
* ogra_ goes back to te other room
<Kamion> oh my god it's hardcoded in ltsp-build-client
<Kamion> MDZ
<Kamion> should be an option that ltsp-client-builder can fetch from mirror/codename in the installer
<Kamion> (was mirror/suite in breezy)
<ogra> hmm, base config fails to configure postgresql-8.1
<ogra> pitti, `
<ogra> ?
<mdke> mdz, ping?
<pitti> ogra: again, why does base-config try to configure postgresql?
<ogra> no idea ...
<ogra> err
<ogra> indeed
<ogra> its edubuntu ;)
<pitti> ogra: can you please show me the actual error message?
<ogra> just trying to find it ...
<mdke> mdz, i'll send you a query
<seb128> jdub: ping ?
<ogra> pitti, there is not much :/
<ogra> dpkg: error processing postgresql-8.1 (--configure):
<ogra>  subprocess post-installation script returned error exit status 1
<pitti> hmm
<ogra> directly below Setting up postgresql-8.1 (8.1.0-3) ... 
<pitti> which -common version do you have?
<ogra> there are locale errors all over the place, does it depend on proper set up locales somehow ? 
<jdub> seb128: pong
<ogra> (it works with the other packages...)
<pitti> ogra: yes, a bit, but you should get more output in that case
<seb128> jdub:  /j #ubuntu-desktop please
<pitti> ogra: does apt-get -f install fix it?
<pitti> ogra: if not, can you please add set -x to /var/lib/dpkg/info/postgresql-8.1.postinst and apt-get -f install again?
<ogra> will do...
<ogra> postgresql-common_36_all.deb btw
<ogra> common and client seem to have worked fine
* ogra reboots to testinstall again
<Mithrandir> jbailey: any reason why circular dependencies in initramfs exit 1's rather than giving you a panic shell?
<jbailey> Mithrandir: Not that I can think of.
<jbailey> Mithrandir: I probably wrote that before I wrote the panic shell logic.
<Mithrandir> holy shit, it's booting.
<zakame> whao
<Keybuk> hmm, whatever happened to ... xsnow!
<Amaranth> Keybuk: It doesn't work with new DEs. :/
<Keybuk> aww
<Keybuk> probably gets stuck on the top panel
<Keybuk> or the big nautilus window of doom
<Amaranth> it doesn't know how to tell nautilus to redraw
<Amaranth> or something
<BenC> anyone here have xfs and running dapper kernel?
<BenC> if so, can you verify #6841
<pitti> BenC: I do
<ogra> pitti, http://paste.ubuntulinux.nl/5555
<ogra> apt-get -f install doesnt help ...
<pitti> ogra: ok, that's good
<pitti> ogra: does running the postinst with -x help?
<ogra> phew ...
<ogra> err, you mean set -x ? 
<Keybuk> BenC: doesn't happen here, I can strip 644 binaries
<pitti> right
<ogra> thats what i got with it
* ogra slaps forehead and chroots ... silly me ..
<pitti> BenC: works fine for me, too
<Keybuk> I do get Permission Denied if the binary isn't writable ... but I expect to
<ogra> seb128, dholbach, 
<ogra> Setting up gnome-terminal-data (2.12.0-0ubuntu2) ...
<ogra> /var/lib/dpkg/info/gnome-terminal-data.postinst: line 19: gconftool-2: command not found
<ogra> /var/lib/dpkg/info/gnome-terminal-data.postinst: line 19: gconftool-2: command not found
<ogra> dpkg: error processing gnome-terminal-data (--configure):
<ogra>  subprocess post-installation script returned error exit status 127
<ogra> known ? 
<Amaranth> it needs a dep on gconf?
<pitti> ogra: ok, your locales seem to be busted
<ogra> pitti, yup
<ogra> but should that affect the postinst ? 
<pitti> ogra: the postinst tries to create a database under en_US.UTF-8
<pitti> which is set as the default locale
<pitti> but doesn't seem to exist
<ogra> ah, k ....
<pitti> language-pack-en should fix it
<pitti> ogra: what does 'locale -a' say? does it complain?
<ogra> locale: Cannot set LC_CTYPE to default locale: No such file or directory
<ogra> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
<ogra> locale: Cannot set LC_COLLATE to default locale: No such file or directory
<ogra> C
<ogra> POSIX
<pitti> heh, I knew :)
<ogra> at least in the chrooted env ...
<dholbach> pitti: i guess a ${misc:Depends} in gnome-terminal is missing
<pitti> ogra: then either install the lanpack, or fix /etc/environment
<ogra> dholbach, that are two different errors
<ogra> pitti, i'm doing test installs here :)
<ogra> so something is missing on the CD i think ...
<pitti> ogra: hm, language-pack-en is installed by default...
<pitti> hm, wait
<ogra> pitti, yes it doesnt show up in my problem list for the CD either
<pitti> Kamion: I think our new locales handling doesn't play well with the installer
<pitti> Kamion: if the user chooses a locale, and it is written into /etc/environment, but the langpack ist not installed, it will break
<ogra> i'm probably lagging behind with the iso ... Kamion fixed busybox already, might be related
<BenC> Keybuk, pitti: thanks
<seb128> pitti: what the heck are you doing with glib?
<seb128> ups
<seb128> not for you
<seb128> smurf: what the heck are you doing with glib?
<pitti> seb128: added the gettext patch for desktop files, just as we discussed?
<seb128> pitti: no, smurf shlibs bump without any notice
<seb128> pitti: was not for you :)
<seb128> pitti: is your patch changing the public API?
<pitti> seb128: *phew* :)
<smurf> seb128: glib2.9 added new symbols, what else should I have been doing?
<pitti> seb128: not at all
<seb128> smurf: asking the maintainer so it get fixed for Debian too?
<ogra> dholbach, hmm, might be you are right with the missing dep ...
<seb128> smurf: especially that it was a pending change
<ogra> dholbach, on the test system only gconf2-common ended up to be installed
<seb128> ogra: the control.in miss a Depends on misc:Depends for it
<ogra> yup
<ogra> thats why i said he might be right ...
<ogra> :)
<seb128> ogra: what is right?
<seb128> ogra: Debian has already fixed it, we just need to sync the package
<ogra> seb128, <dholbach> pitti: i guess a ${misc:Depends} in gnome-terminal is missing
<ogra> seb128, great
* ogra waits for tomorrows iso then ...
<seb128> ogra: you have nothing else triggering gconf on your iso?
<ogra> seb128, seems like gnome-panel-data is the first thing using it 
<ogra> s/gnome-panel-data/gnome-terminal-data
<ogra> seb128, i have only these two packages failing currently ... (gnome-terminal-data and postgresql-8.1)
<seb128> I'll fix gt now
<pitti> ogra: I'll talk to Kamion about locale handling
<ogra> pitti, might be related to the busybox error ... i'm not sure 
<smurf> seb128: the version number sortof indicates that 2.9 isn't from Debian, so I decided to fix it first and look at Debian et al. later, instead of the other way 'round. Sorry if I mis-stepped. :-/
<seb128> smurf: that's easy to ping on IRC before uploading no?
<seb128> anyway, next time please before uploading like this
<smurf> sure
<slomo_> lbm: now, yes...
<slomo_> siretart: ping?
<pitti> lamont-away: argh, ppc buildd troube - are you here?
<pitti> lamont-away: procps failed to install on royal, which broke the warty/courier build
<pitti> infinity: ^ (just in case you are awake)
<lbm> slomo_: about your banshee package, libmono0 is missing as a dependency
<slomo_> hmm, can someone look at a build failure on ia64? it's xine-lib and i don't want to upload any other tries to fix it without knowing that they actually work ;) http://people.ubuntu.com/~lamont/buildLogs/x/xine-lib/1.1.1-0ubuntu2/
<slomo_> lbm: thanks, i'll add it... :)
<lbm> slomo_: great :)
<lbm> slomo_: banshee segfaults all the time. i haven't tried compiling the source, so i can't really tell if your package is the problem
<slomo_> lbm: uh... it doesn't for me since 0.10 anymore :/ can you give me a backtrace?
<lbm> slomo_: in an hour or two, yes
<Amaranth> slomo_: Don't suppose you can relax the monodoc dependency there.
<Amaranth> slomo_: Switch it to recommended or whatever and just disable the docs if it isn't installed.
<lbm> slomo_: can you tell me how to backtrace it?
* lbm fires up qemu
<slomo_> Amaranth: for backports you mean? we'll most probably backport the complete mono stack soon so this will be no problem anymore...
<slomo_> lbm: either by using gdb... or often mono gives you already a backtrace if the segfault wasn't too hard
<lbm> slomo_: let me get back to you
<slomo_> lbm: sure, just ping me again :)
<lbm> slomo_: ;)
<psusi> has anyone been messing with unionfs?  I'm wondering if it could be used to move files read in by readahead-list to a romfs image and overlay that on top of the root fs
<psusi> that way readahead-list could do it's thing much faster due to much less seeks
<\sh> mvo: thx :) 
<mvo> \sh: got the mail already? great :)
<ogra> mvo, you rock !
<ogra> !!
<ogra> !
<\sh> mvo: yeah..thx alot :)
<infinity> pitti : Not awake, but fixed anyway.  Cheers.
<pitti> infinity: merci :)
<mvo> cheers :)
<pitti> infinity: it's great that you can work even when being asleep :)
<ogra> the somnambulating buildd admin !
<infinity> seb128 : gnome-media given back everywhere, but failed on i386 attempting to link to dbus-glib-1, which it can't find.  I assume an underlying library needs a rebuild, or something.  Have fun.
* infinity goes back to sleep now.
<pitti> sleep well, Adam
<seb128> infinity: yeah, nautilus-cd-burner, that I fixed some days ago ... will figure why it's still failing, thanks
<seb128> g'night
<ogra> pitti, did you also just get a MS virus on the ubuntu-de ML ?
<pitti> ogra: I get thousands of bounce notifications
<ogra> yes thats what i get for edubuntu-devel currently ...
<ogra> its an admin thing ... seems gmail has probs 
<ogra> but i just got a virusmail as user on ubuntu-de, seems it somehow slipped through the scanner
<ogra> (on the ml server)
* ogra wonders if mdz is up already ...
<Diziet> Why oh why oh why does os.open() default to mode 0777 ?
<Diziet> It seems to be just Python being gratuitously annoying again.
<psusi> it doesn't obey umask?
<ryanpg> hi all... is it appropriate to file a bug about nautilus-cd-burner not working as non-root user in dapper? or is this expected behavior for a pre-release?
<ogra> ryanpg, does it work with other apps ? 
<ryanpg> ogra, you mean do other burner apps work? well, g-cd-b works when run as root... I can check some others
<ryanpg> what's a good one to try?
<ryanpg> I have serpentine, I'll try that
<ogra> for me it deons work with root either as well as it doesnt work with cdrecord, 
<ryanpg> ogra, doesn't work with serpentine either
<LaserJock> elmo: ping?
<ogra> ryanpg, so its unlikely to be a n-c-b bug
<ryanpg> ogra, yeah... unfortunately bugzilla seems not to allow me to submit without picking a package so n-c-b it was
<ogra> pick unknown next time ;)
<ryanpg> ogra, hmm... good suggestion
<ryanpg> ok, could someone help me acculturate here... is it appropriate/good/helpful to be filing bugs against dapper? I don't want to ruin the s/n ratio here. :)
<crimsun> yes, it's fine
<ogra> its preferred *g*
<ogra> since we can more easily fix them ;)
<ryanpg> ok good thanks crimsun ogra, just don't want to be a nudge! ;)
<mdz> ryanpg: so long as you check that your bug isn't already reported
<ogra> mdz !
<ogra> mdz, can you please merge http://people.ubuntu.com/~ogra/bzr-archive/ltsp/fixes/ and upload the ltsp package before flight 2 ? 
<ogra> (its a one line fix)
<ogra> without it the stage 1 install breaks ...
<Mithrandir> mdz: I have simplifiedlivecd mostly implemented \o/
<Mithrandir> mdz: mostly minor faff left, like my live image not having the same kernel version as the kernel I'm booting with.
<dholbach> elmo: please sync aiksaurus from debian, ok to override
<pitti> YAY
* pitti got the first successful attempt to build tetex-bin against poppler
<mdz> Mithrandir: cool, is it in bzr or otherwise browseable?
<Mithrandir> mdz: yes, in bzr, but not published anywhere yet.
<mdz> ogra: will have a look
<ogra> thanks :)
<Mithrandir> I gotta vacuum for a bit, I'll put it up later.
<dholbach> Mithrandir: that's what i did, when gnome-system-tools test-built :)
<seb128> Keybuk: around?
<dholbach> elmo: merci
<pitti> seb128: poppler rocks :)
<seb128> cool ;)
<seb128> happy that you like it :)
<pitti> seb128: well, tetex-bin is the last xpdf copy (and these really hurt)
<seb128> pitti: BTW have you tried if your crasher is fixed with the evince update?
<pitti> seb128: a bit, it didn't crash any more
<seb128> cool, so that's the right fix for it :)
<Gerrath> Were can I find out what modules are loaded in the kernel ram-disk image for a stock ubuntu kernel?
<Gerrath> example: initrd.img-2.6.12-10-686
<Gerrath> Heres why, I can remove the dethforce module completely from the kernel and it still loads so I'm starting to think it is in the initrd.
<siretart> slomo_: pong
* pitti does the dapper dance
* ogra joins
<pitti> had I known that tetex builds so easily with poppler, I should have done it in breezy
<pitti> now I pay for not having done it...
<zyga> hello
<siretart> a friend just asked me: are there plans to have mysql5 in dapper?
<sladen> siretart: is it certified? ;-)
<siretart> sladen: nope, but I know people who don't care about this and just want the latest mysql.. *shrug*
<zyga> who is the one to ping about being added to the UbuntuMembers team on launchpad?
<BenC> any ETA on flight 2?
* Diziet url-encodes the python script to get it through dchroot (and hence su -c).
<neuralis> siretart: ping infinity about what he decided, but i recommended against it based on 5.0.15
<neuralis> siretart: it's yet to be seen how much they fixed in .16
<siretart> neuralis: ok
<Diziet> -anarres:virt-chroot> really strace -fot dchroot -q true </dev/null 
<Diziet> stdin: is not a tty
<Diziet> -anarres:virt-chroot> echo $?
<Diziet> 0
<Diziet> ???
<gouchi> Hi
<gouchi> Is there a bugreport for labtec pro webcam ?
<gouchi> because It freezes ubuntu breezy
<gouchi> running gnomemeeting
<ogra> gouchi, bugzilla.ubuntu.com
<gouchi> ok
<gouchi> I will make a search
<gouchi> it seems not
<gouchi> strange
<dholbach> good night
<mvo> bye dholbach 
<Hieronymus> gouchi: I have a similar problem, I believe
<Hieronymus> gouchi: http://bugzilla.ubuntu.com/show_bug.cgi?id=20520
<gouchi> yep
<Hieronymus> When gnomemeeting or another program tries to capture from my webcam, my complete system freezes
<gouchi> same here
<Hieronymus> gouchi: okay. Please add a comment to that bug and put your e-mail in CC. Maybe dmesg and lspci output will help aswell.
<gouchi> I gonna try to recompile the module : https://wiki.ubuntu.com/Spca5xx?highlight=%28webcam%29
<Hieronymus> gouchi: is that the module?
<gouchi> yep
* lamont-away grumbles at util-linux
<zyga> lamont-away: who manages the ubuntu members team?
* lamont-away shrugs
<zyga> sorry for bothering you, thanks
<lamont-away> np
<crimsun> zyga: ping Seveas about the ubuntu members team
<zyga> crimsun: thanks
<zyga> Seveas: ping
<Amaranth> sounds like 7zip could allow you to put more language packs on the CDs, even if you only compress the language packs themselves with it
<Amaranth> and, as a bonus, it's actually faster than bz2 :)
<zyga> Amaranth: isn't there a spec somewhere about 7zip evaluation?
<psusi> aye... 7zip kicks ass
<mdke> mdz, did you see my query earlier?
<mdz> mdke: no
<mdke> mdz, ok :)
* lamont-away needs gimp-print to be fixed
<gouchi>  Hieronymus : works with new module ;-)
<Hieronymus> gouchi: you followed the wiki?
<gouchi> yep
<gouchi> very easy
<gouchi> Hieronymus : uses gcc-3.5 if you have breezy kernel
<Hieronymus> oh, I thought 3.4..
<crimsun> (gcc-3.4)
<gouchi> Hieronymus : gcc-3.4 sorry :)
<gouchi> Hieronymus : remember before to insmod ,  rmmod spca5xx.ko
<zyga>   .0
<Kamion> crimsun: huh? Seveas isn't a community council member and thus doesn't administer ubuntumembers
<crimsun> Kamion: I thought he was asking about something else
<Kamion> ok ...
<crimsun> (the FN cloaks)
#ubuntu-devel 2005-12-15
* #ubuntu-devel  [freenode-info]  If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks!
(Mithrandir/#ubuntu-devel) jbailey_: true, but I would argue multiarch is saner. :-)
(Kamion/#ubuntu-devel) multiarch is a very much more constrained problem. I agree with you that it's similar in nature but I think the difference in degree produces a very big difference in feasibility.
(wasabi/#ubuntu-devel) Well, I was pondering the idea of setting up the infrastructure for it, anyways, and restrcting them to .local-dpkg or something in the home dir. Perhaps allowing the possibility of per-user software to exist as downloadable .debs.
(Kamion/#ubuntu-devel) and I don't think we should even think about it until we've done multiarch.
(wasabi/#ubuntu-devel) Guess it doesn't matter though.
<wasabi> I don't have a problem to solve.
<mdke> jbailey_, the debdiff appears to show that a shitload of files have changed, although I didn't touch em. :(
<mdke> http://paste.ubuntu-nl.org/5568
<mdke> jbailey_, I changed the debian/ files, and gnome/aboutubuntu, nothing else
<mdke> jbailey_, actually don't worry, none of that junk is actually in the package
<jbailey_> Oh good. =)
<mdke> jbailey_, the source package just has the whole svn tree in though, so the debdiff is like 10MB, may be hard to get that past mdz with the excuse that none of the files are actually shipped with the package
<jbailey_> jbailey@starshine:~$ cat .devscripts
<jbailey_> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-I.bzr -I.svn"
<jbailey_> mdke: Suggest that you do that. =)
<mdke> yeah but that still leaves a whole load of shit
<jbailey_> That shouldn't leave any svn stuff behind.
<mdke> it cuts it down to 700kb or so
<jbailey_> Yay, finally off the phone.
<mdke> jbailey_, but it includes loads of stuff which we don't actually ship, such as all the stuff on here: http://paste.ubuntu-nl.org/5568
<jbailey_> The amazing part is that my coldless seems to have about 5 hours of talktime.
<jbailey_> I just got low battery warning, but it didn't die.
<mdke> lol
<jbailey_> Can you install interdiff and redo the debdiff?
<mdke> jbailey_, if you walk me through it to some extent I can :)
<jbailey_> mdke: sudo apt-get install interdiff
<Mithrandir> mdke: s/interdiff/patchutils/
<jbailey_> Right, what tollef said.
<mdke> done
<jbailey_> If you have the old package from apt-get source ubuntu-docs, and the new package from running debuild on it in a directory, you can then do debdiff *dsc
<mdke> ok gimme a tic, just rebuilding the package
<mdke> hmm
<mdke> it builds a lot of stuff we don't need for the package
* mdke twiddles thumbs
<mdke> jbailey_, all the localised html isn't actually installed in the package, should I remove it from the build, or just bite the bullet and leave it in?
<jbailey_> mdke: You want to make the fewest number of changes you can to the stable version.
<mdke> so i'll leave it
<jbailey_> mdz will look at anything that's not a necessary change and question it, since it runs a risk of breaking things in a way you didn't expect.
<mdke> it's sorted for dapper anyway
<jbailey_> Didn't you say this is for breezy-updates?
<mdke> yes
<mdke> i'll limit changes to only the absolutely necessary ones
<mdke> jbailey_, doing the debdiff, does it save it for me or do I need to > ?
<jbailey_> >
<mdke> jbailey_, it's quite fat: http://doc.ubuntu.com/debs/breezy/ubuntu-docs.diff
<jbailey_> Eh, why are all the KDE imagaes different?
<maswan> I wrote a thingie about the breezy release (and sarge) from a main mirror point of view, comments and bugreports would be nice: http://www.acc.umu.se/~maswan/2005-12-10/2gbit-freesoftware.html
<mdke> jbailey_, they are probably uploads which we did in order to upload to the website
<jbailey_> I'm a bit concerned about all the instances of Binary files /tmp/Isvitm01NH/ubuntu-docs-5.10/gnome/quicktour/UbuntuStrapLogo.png and /tmp/w2i1S3YrUF/ubuntu-docs-5.10/gnome/quicktour/UbuntuStrapLogo.png differ
<jbailey_> and the like.
<jbailey_> The actual text changes generally seem fine
<jbailey_> (without having validated the CSS chanegs and such)
<mdke> jbailey_, those files are not in debian/install tho
<mdke> hardly anything in that diff is
<mdke> oh shit quicktour is
<mdke> jbailey_, dunno what to do about that :(
<jbailey_> Dunno.  I'm tired and not thinking clearly.
<mdke> jbailey_, ok we can try again another time :)
<mdke> in the meantime I'll work on getting new translations
<mdke> jbailey_, crazy thing about the quicktour is that it is not referenced by any program in Ubuntu, it just sits on the harddrive there. It was never really intended to be shipped, it's more of an online doc
<psusi> bootchart does a nice job of logging how much IO is going on during boot... but is there a way to find out which files are being accessed?  I think there is a lot more that could be added to readahead-list
<elmo> hmm, lilo has a very purty splash screen - is gfxboot giving us that?
<mdke> jdub, was any progress made on the planet synching issues?
<BenC> have we ever considered including linmodem/pctel drivers, and if so, what was the outcome?
<calc> related to that is there any plans to setup xinerama at install time, or did i just miss it?
<Robot101> what lsb-base version does log_daemon_message appear in?
<Robot101> the breezy one appears not to have it, but this dbus 0.60 deb uses it
<mdke> hi all
<jdong> dumb question of the night: Would gstreamer 0.10 backport? ;)
<jdong> btw hi mdke 
<mdke> hiya
<mdke> dapper looks like it's working, but in tty1 I am getting constant errors from ata2 like this: http://pastebin.com/457952
<mdke> flying past all the time
<mdke> is this a kernel problem?
<jdong> cool, libata passthru?
<jdong> (cool in the not my computer is affected way)
<mdke> well the computer seems to work ok
<jdong> so it seems like non-critical ATA commands aren't translating well
<jdong> <- not a kernel expert by any measure
<mdke> where do I file the bug?
<mdke> kernel?
<jdong> that's definitely kernel
<jdong> though idn if the guys would appreciate a bug on it
<jdong> they might already know
<jdong> given the sheer volume of these errors ;)
<jdong> I gotta get a Dapper box up
<ptlo> jdong: there seem to be no gst 0.10 packages for breezy available anywhere on the net, although, I just compiled it from source am happy to say that it doesn't require any stuff that cannot be found in breezy - so there's no reason why it wouldn't backport (soon/one day)
<jdong> ptlo: currently compiling it also (though my other tasks are slowing it down) -- saw something in the changelog about conflicting gstreamer0.8-tools
<jdong> that concerned me
<jdong> I suppose some gst-* packages need to be pulled back as well
<ptlo> jdong: afaik all the libs and the tool names end up in either 0.8 (for the old one) or 0.10 (for the new gst); there's no clash, they should be paralel-installable
<jdong> cool
<jdong> god vmware slows everything down
* #ubuntu-devel  [freenode-info]  If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks!
(mdke/#ubuntu-devel) wb
(jdong/#ubuntu-devel) lol
(jdong/#ubuntu-devel) is it just me or is freenode plain weird today
<djk_> the latter
<jdong> yeah....
<jdong> 2nd dumb question of the day: is gstreamer-tools 0.10 backwards-compatible with 0.8?
<djk_> will Dapper support Reiser4?
<jdong> djk_: not unless it gets in mainline linux soon
<djk_> mmh, i suppose that's not likely.
<jdong> djk_: you got that right :-/
<djk_> :(
<jdong> djk_: reiser4 makes a few kernel patches deep down, so it's not like other filesystems in that aspect
<jdong> djk_: maintaining it will be more trouble than it's worth
<djk_> well, it needs to be tested though :)
<jdong> djk_: that's not our job :)
<jdong> djk_: there are already a few distros that include varying levels of reiser4 support
<jdong> some gentoo derivatives (rr4), SuSE 9.3+, Linspire....
<jdong> but they made quite a commitment to reiser4
<maswan> is it worth it? I mean, outside reiser's own benchmarks?
<djk_> well, gentoo would be an option.. but suse and linspire..naa.
<jdong> maswan: if it's in mainline, I'd be using it right now
<maswan> jdong: why?
<jdong> speed and reliablity improvements are REAL
<jdong> it's the only atomic filesystem
<maswan> realiabilty from reiser? that is indeed a new development
<jdong> well, don't be too prejudiced
<jdong> reiserfs is nowadays one of the most reliable FSes
<jdong> reiser4 is fully atomic
<jdong> only ext3/reiserfs under data=journal currently can do the same
<jdong> at a GREAT performance cost
<maswan> well, I guess I might take a look at it in a few years, after it has seen a couple of years of mainline usage and testing
<maswan> sorry, have some bad experiences. and bad impression from hans too.
<jdong> maswan: likewise, in the 2.4 days for me
<jdong> maswan: reiserfs has stabilized nicely recently
<jdong> from Hoary on, reiserfs has treated me well
<jdong> and trust me -- at times I'm a VERY terrible PC user :)
<jdong> especially while hacking wifi drivers ;)
<maswan> well, the worst thing I've done to a filesystem is to have it mounted with atime and locate for a couple of weeks. on a raid system where ever 64th bit became a 0. lots of intEresTingLy.cApseD.fiLes in directories
<djk_> jdong: why did you say that maintaining reiser4 will be more trouble done it's worth if you think that it's great?
<maswan> well, to start with, after a while, all the directory entries were shot due to atime updates
<jdong> djk_: reiser4 patches are some of the most finicky patches out there
<jdong> djk_: I mean, applying unrelated ck patches can cause reiser4 to start panicking for no apparent reason
<maswan> after fixing the raid module, I got all the files back though. in lost+found. luckily one of the files was an MD5SUMS of all the other files.
<jdong> maswan: so can you blame your problem on reiser then?
<jdong> hi, seth
<maswan> jdong: that wasn't reiser, that was xfs.
<jdong> OH
<jdong> then that's a completely different story
<jdong> don't get me started on XFS
<maswan> don't know how reiser would react to having all the directory entries overwritten with crap data
<jdong> maswan: reiserfs is amazingly recoverable
<maswan> we use it all the time for production use at work
<maswan> jdong: so is XFS
<jdong> maswan: agreed, though in my experience XFS corrupts a lot more than reiserfs
<maswan> well, current reiser is way out anyway, due to performance
<jdong> maswan: most of the time it can be attributed to XFS's caching, but I've experienced METADATA corruption on abrupt shutdowns before
<jdong> maswan: I can't reproduce the latter, so for now I won't blame XFS for it
<jdong> however, it has too high CPU usage for my tastes
<maswan> oh, we very seldom have abrupt shutdowns. happened 3 times the last 4 years or so.
<jdong> maswan: that's why you've had such good luck  with XFS
<jdong> give it some power backup, it's a great FS
<jdong> otherwise, don't expect to find your non O_SYNC files....
<jdong> ever
<jdong> xfs's userland tools rock, too
<jdong> dump, freeze
<maswan> I know it has some issues for some use cases where it is perhaps a bit too agressive in write-back, but, *shrug*, not a prolbem for us
<jdong> maswan: i.e. laptops
<maswan> also, for us, it is a fileserver, it isn't going to do much else with the cpu anyway.
<jdong> true
<jdong> but on a desktop when unpacking a huge nicely compressed tarball causes multimedia to grind to a halt....
<maswan> hmm.. last reboot was the breezy upgrade. I think I had 170-180 days before that. :)
<jdong> lol
<jdong> JFS is currently my favorite
<djk_> is there some non-biased literature about the different FSs?
<maswan> yeah, it was xfs vs jfs, and we had slightly better streaming performance through xfs. also, we got a bad case out of that when it replayed the journal for a couple of days.
<maswan> hmm.. that might have been my fault too though, I thnk that was when I was stress-testing another raid controller for reliability.
<maswan> if you switch two disks on an older 3ware controller (so that no writes are done when they are out), it won't detect that you have removed a disk and assumes the raidset is ok.
<jdong> XFS is faster; I won't dispute that
<jdong> but JFS is reasonably fast
<jdong> is reliable under repeated hard shutdowns
* maswan nods
<jdong> and also excels at not having disk IO interrupt other work
<jdong> i.e. video playback
<jdong> I have 3 vmwares running right now
<maswan> well, we only really care about performance for fileservers on ups/diesel, so.. :)
<maswan> fileservers with performance demands
<jdong> XFS is your friend then
<jdong> and it online defrags too
<jdong> which helps out after prolong heavy write use
* netjoined: irc.freenode.net -> brown.freenode.net
<fabbione> morning
<viviersf> lo fabbione 
<shadeofgrey> hello everyone
<zakame> heya shadeofgrey :)
<shadeofgrey> uh...  ive never officially introduced myself...  my name is Chris Kelly and im very interested in helping out with testing / suggesting improvements to the accessibility modules availasble in ubuntu
<TheMuso> shadeofgrey: Firstly I suggest you join the ubuntu accessibility mailing list, and look at the accessibility wiki page at http://wiki.ubuntu.com/Accessibility.
<zakame> ooh, that's good!
<TheMuso> YOu can find out the mailing list address in one of the links from that page.
<shadeofgrey> i was  born eight weeks premature addicted to crack cocaine and hertoin, and as a result im severely handicapped...  i have cerebral palsy, am a spasdic quadreplegiuc, and only have good control of one limb -- my left arm
<shadeofgrey> i type with three fingers on my kleft hand and when sober can average 70 words a minute...
<rob1> thats pretty quick with one hand
<shadeofgrey> but as you can imagine, any sort of aides that could be worked into ubuntu to help people with limited mobility get the most out of their system would be a great thing...
<TheMuso> shadeofgrey: We would be happy to have you join us. Nice to have a few different disabled people on the team.
<shadeofgrey> robl:  i practived 7 hours a day every day every summer between school years
<shadeofgrey> im also capable of totally dressing myself except for my shoes, and dont need help with showers or anything either...  im fiercely determined and very independant.
<shadeofgrey> it took me a decade to figure out how to put my clothes on by myself, and i started working on that when i was six...  you can imagine my excitement when i dsuccessfully put all my clothes on by myself for the first time ever on my 16th birthday
<shadeofgrey> so
<shadeofgrey> with me on the team, i think we can make great things happen...  i happen to kbow a few things about overcoming insurmountable odds...  and if nothing else, ill be great moral support to all the folks that actually do all the code writing
<shadeofgrey> sadly, im not a coder
<shadeofgrey> but im one hell of a thorough program tester
<TheMuso> I am not really a coder either, yet.
<shadeofgrey> and if nothing else i could definately help with maintaining or even creating whatever documentation we need to make publically available.
<shadeofgrey> im not a smart man, and im no good at contact sports, but I am one hell of a genuinely talented and driven writer -- i write full lerngth novels -- i hope to be the next tom clancy/michael critchton/john griusham
<shadeofgrey> im also good with poetry and motivational material for disabled people -- or really anybody that struggles with something
<shadeofgrey> i firmly believe that we all face huge struggles in each and every one of our lives..  its just a matter of how visible they are
<shadeofgrey> oh and just for the record - i didnt tell my lifestory with the intrention of fishing for pity...  i just wanted to make my position very clear, so that you guys and gals can better decide where i mighty be of best use among all the other team members
<shadeofgrey> without a doubt, i am by far one of the coolest disabled folks you'll meet...  i believe in the power of courage, and in helping others whenever possible...  im also steadfastly loyal ...and a hopeless romantic
<shadeofgrey> ...just in case there happen to be a few single gorgeous code-writing geeks somewhere in this channel
<shadeofgrey> anyway thankds for the guidance....
<shadeofgrey> ...i dont suppose i could convince of you nice people to supply me with a sources.list file so i can upgrade to the test release of Dapper?
<shadeofgrey> no worries - all my important crap is stored on a secondary drive, so if i screw my main ubuntu installation to hell all i have to do is replace it
<Amaranth> shadeofgrey: change breezy to dapper in sources.list
<shadeofgrey> amar:  can you please just paste the contents of your sources.list file to a query window?  itd make my life a LOT easier
<shadeofgrey> Amaranth:  id reallyappreciate the extra help
<Amaranth> i don't have it handy, i'm on windows right now
<fabbione> hey pitti
<pitti> Hi fabbione 
<tseng> jdub: http://video.google.com/videoplay?docid=4817874081068161718 < pimp my fridge!
<siretart> Thanks for your interest in Google Video.
<siretart> Currently, the playback feature of Google Video isn't available in your country.
<siretart> :(
<dl1bku> Q: In order to compile an Input-driver for xorg the package xorg-x11-sdk (rpm name) is necessary. Is there a similar ubuntu package for this? (google and friends say there isn't). Do I need to install the complete xorg-sources?
<mdke> jbailey_, for when you wake up: how about I work on a copy of the breezy source for preparing the update, rather than the branch in svn? it might eliminate a lot of changes :) alternatively, I could make a new branch with that source
<dl1bku> Using the header files from an xorg-x11-sdk.rpm (using alien) helped... gb
<pitti> Hi seb128 
<seb128> hey pitti
<crimsun> elmo: please sync vm from Sid, overriding Ubuntu changes, thanks
<crimsun> elmo: please sync varconf from Sid, overriding Ubuntu changes, thanks
<jbailey_> mdke: That's generally what I do.  The problem with SVNs versus packages is that there's always the chance that someone modified the version in the archive.
<jbailey_> Native packages suck that way.
<jbailey> mdke: hct is ultimately the right solution for that.
<mdke> jbailey, hct?
<jbailey> mdke: It's magic crack that Keybuk is working on.  If you think of it as a version control system that's hosted on the Ubuntu servers with a magic button that says "upload what's in the repository", that's it.
<jbailey> The trick is that folks will be forced to use that eventually.
<mdke> ok...
<jbailey> So that way, you're guaranteed that uploads match what's in the version control.
<mdke> how many version control systems are you guys working on?!?
<jbailey> Well, it's wrapped around bzr.
<mdke> aha
<jbailey> What hct does that bzr doesn't is understand packaging.
<mdke> jbailey, so for now I'll just work locally with the source, and then if necessary, I'll make a separate branch or something
<jbailey> Right.
<StevenK> "Magic crack"
<StevenK> Heh
<jbailey> StevenK: It truly is. =)
<\sh> StevenK: it was quite impressing what scott showed us during ubz
<jbailey> You know how dpatch and simple-patchsys has patch management and such, right?
<jbailey> It has the ability to unpack a working directory as each patch iteration.
<jbailey> You just go through and edit the code, and it'll roll it into that patch file.
<jbailey> That way you can clearly track what's upstream, what are hacks to make it work, and what is packaging outside of that.
<StevenK> But it's just crack laced with a few hallucinogenics!
<jbailey> It's shared, so that let's say I have a little tweak to ubuntu-docs, I can just go in and make it.  It'll be easy for mdke to see that I've made the change and merge it in before he uploads it.
<jbailey> I don't even need to tell him about it, and it could be to any part of the system.
<StevenK> Geez, magic crack indeed.
<StevenK> Who's Keybuks dealer? :-)
<jbailey> sabdfl =)
<zakame> hrhr
<StevenK> Bwahaha
<\sh> the daily python crack pipe 
<siretart> jbailey: around? 
<siretart> jbailey: do you know where lddlibc4 has gone?
<jbailey> lddlibc4?
<jbailey> What's that?
<StevenK> I'm sorry I even read that line now.
<siretart> ldconfig spits at me that it cannot find it
<jbailey> libc4 was the old a.out libc.
<StevenK> *blink*
<jbailey> siretart: I'm pretty certain it has never existed in Ubuntu.
<siretart> jbailey: it used to be in libc6: http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=libc6&version=hoary&arch=i386&page=1&number=all
<siretart> jbailey: it has
<jbailey> Eh?  When did we get a packages.ubuntu.com?
<siretart> jbailey: some time ago
<StevenK> A while ago.
<ogra> jbailey, ith hoary
<ogra> *with
<siretart> >> dpkg -L libc6 | grep libc4
<siretart> /usr/bin/lddlibc4
<siretart> on a breezy/x86 system
<jbailey> Ah, interesting.
<sladen> jbailey: about 18months ago
<jbailey> It must've been dropped when we switched to libc2.3.5
<StevenK> It still exists on my sid machine.
<siretart> well, I get this one: >> ldd doom.x86
<siretart> /usr/bin/ldd: line 95: lddlibc4: command not found
<siretart>         not a dynamic executable
<siretart> so I'm a bit confused
<jbailey> Hmm, it's still in the tree.
<sladen> that must be a very old doom executable...  there are plenty of source-based versions built to modern standards around
<siretart> hm. it exists on x86 but not on amd64. 
<jbailey> /* Stub for ldd script to print Linux libc4 dependencies.
<siretart> sladen: it is doom3. not that old ;)
<jbailey> siretart: If it's libc4, you're talking 10 years or so.
<siretart> jbailey: it is not libc4. it is shipped with a libstdc++5
<mdke> jbailey, the debdiff is a lot smaller now :D
<mdke> http://mdke.org/debdiff.txt
<jbailey> Yeah, random note to all people.  In dapper+1, executables like these are almost guarnateed to not work again.
<StevenK> Noooooooooooooooooooooo
<crimsun> jbailey: out of curiosity, does it make sense to execute /lib64/ld-linux-x86-64.so.2 on i386?
<StevenK> How am I supposed to run ut2004 and doom3 then?
<jbailey> crimsun: What problem are you trying to solve?
<siretart> jbailey: it is rather some weird elf format, so /lib/ld.so.conf --verify fails. now ldd tries to fallback to lddlibc4, which fails because it does not exist
<jbailey> StevenK: Make a dapper chroot.
<crimsun> jbailey: http://people.ubuntu.com/~lamont/buildLogs/a/alsa-lib/1.0.10-1ubuntu1/alsa-lib_1.0.10-1ubuntu1_20051203-0850-i386-failed.gz
<crimsun> jbailey: the dpkg-shlibdeps call on line 3189
<jbailey> crimsun: Without looking, can I guess that it's in dokg-=shlibdeps?
<crimsun> indeed
<siretart> jbailey: do you know how to install the nvidia glx libraries without kernel modules (in dapper that is)?
<jbailey> Right.  I need to file a bug on dpkg, critical, saying that if they don't fix dpkg-shlibdeps a reasonable portion of i386 is going to no longer build soon.
<jbailey> *sigh*
<siretart> excatly :(
<jbailey> siretart: No idea.  My nVidia setup Just Works, and I don't pay much attention to it.
<siretart> yeah. saves much headaches..
<jbailey> crimsun: It's a casualty of the biarch stuff.
<siretart> I should do as well
<jbailey> crimsun: It'll have to get fixed in the next week or two, I'm guess.  We'll be giving that same love to X, gtk, etc...
<crimsun> jbailey: k, as long as it's valid. Thanks.
<jbailey> crimsun: Very much so.
<jbailey> crimsun: dpkg is crufty.  It relies on ldd to give it the right answers for things, and ldd can't do cross arch well.  Specifically, it requires that it be run on an amd64 machine.
<crimsun> jbailey: right, that's what I was led to believe
<infinity> siretart : Why would you WANT nvidia-glx without a kernel module?
<siretart> infinity: to run 32bit games in a 32bit dapper chroot
<siretart> with hardware acceleration
<infinity> Erm.
<infinity> Install ia32-libs and play them in the host system.
<infinity> You can play 32-bit games on amd64 just fine.
<infinity> (In fact, I use doom3 for testing nvidia-glx on my girlfriend's amd64 machine before I upload)
<siretart> infinity: the game in question refuses to do so, because it depends on a 32bit libSDL
<siretart> infinity: interestingly enough: doom3 works, but quake4 broke yesterday :/
<infinity> Anyhow, you could always do 1 of 2 things.  Either install nvidia-glx in your chroot with --force-depends, or install a kernel in your chroot too.  It's not like having a kernel package in the chroot HURTS, it's just wasted space.
<infinity> I need to grab Quake4 for "testing"...
<StevenK> Mmmmm, me too.
<siretart> :)
<StevenK> See if it gets boring like Quake3.
<infinity> StevenK : I still vaguely recall whuppin' your ass at Quake3 several years ago...
<crimsun> heh, no chance for me w/ this intel i915
<infinity> siretart : You could also use 'equivs' to build a dummy package that provides the nvidia-kernel-### package that nvidia-glx is whining about.
<\sh> I wonder if it's possible to play doom3 or quake4 via xdmcp enabled x host
<siretart> infinity: good point
<StevenK> infinity: I don't ...
<siretart> I just installed it (with kernel, udev and crap). now doom3 magically segfaults.. grml..
<infinity> siretart : Anyhow, I'm intentionally not going to make it any easier than that, cause the average user kinda needs that dependency there to avoid shooting themselves in the foot any more than they already do.
<siretart> infinity: I agree
<infinity> Now, if we need a 32-bit libSDL for gaming, perhaps we should roll an ia32-libs-videogames package..
* infinity ughs.
<jbailey> infinity: Feh, don't add more packages to the list.  ia32-libs is supposed to go away, remember?
<infinity> I also need to update both the nvidia and fglrx drivers this weekend.  Joy.
<siretart> well, I've seen webforums recommending putting your usr and usr/lib from the chroot to /etc/ld.so.conf 
<infinity> jbailey : Get me multiarch, and I agree.
<ryanpg> morning, is the plan to move to bogofilter with evolution?
<infinity> jbailey : We won't have proper multiarch for dapper, and binary-only videogames are pretty fun. :)
<jbailey> infinity: True.  But most binary-only video games will need a dapper chroot after that to work.
<infinity> ?
<siretart> jbailey: doom3 runs fine without chroot
<infinity> binary-only stuff tends to target reasonably old and stable libraries.  Usually.
<jbailey> infinity: Dropping linuxthreads.
<infinity> Oh, which you'll break.
<infinity> Hrm.
<jbailey> Right.
<jbailey> It was supposed to be dropped for dapper originally, but since this is the long lived, it makes sense to keep it here.
<infinity> How can I easily disable linuxthreads in my current system to guage how badly the world will explode?
<jbailey> Then people will have 5 years to learn to like newer video games.
<jbailey> infinity: cp /lib/tls/* /lib
<jbailey> infinity: Or I can produce you a glibc deb that's nptl only. =)
<siretart> YAY FUN: LD_LIBRARY_PATH=/lib32:/usr/lib32/:/usr/local/:/var/scratch/dapper/usr/lib ./quake4
<zakame> whoa
<siretart> this works for me *ugh*
<infinity> jbailey : Dropping linuxthreads will make my nvidia-glx packaging less ugly... Since it ships TLS and non-TLS versions of it's crap.
<infinity> jbailey : Anyhow, I'll test some games later and see how they fare.
<infinity> jbailey : I suspect most won't actually care much at all.
<jbailey> infinity: It'll make alot of things less ugly.
<jbailey> I expect most will. The trick is that the NPTL libraries and glibc don't allow "extern int errno" in their code.
<jbailey> You'll get a fail at load time.
<jbailey> Subtle thread bugs are another thing, as well.
<infinity> Threading issues are likely to not be a problem.
<jbailey> That I don't have a guess on.
<infinity> Very few older video games are well (or at all) multithreaded, and newer ones are probably tested against NPTL.
<infinity> But I'd curious about this other change yo umention.
<jbailey> Mm, cool.
<jbailey> And part of me wonders how many people we'll discover still running 2.4. =)
<infinity> I still remember cursing your name when you dropped LT for ppc and my breezy chroots stopped working.
<infinity> Forced kernel upgrades are no fun.
<jbailey> Yeah, you were sort of who I was thinking of ;)
<infinity> :)
<infinity> Well, I don't have 2.4 on any i386/ubuntu hosts.
<infinity> Still have it on some i386/debian hosts.
<infinity> So they'd need a kernel bump if I wanted to sidegrade.
<jbailey> Right.  Wasn't the problem that you were running Ubuntu in a chroot?
* infinity shrugs.
<infinity> Yes, it's a sid box with ubuntu chroots.
<infinity> Still is (the powerpc machine, that is)
<infinity> Oh well, it's forced me to look at OldWorld support in 2.6
<infinity> There's a SCSI driver (MESH) I need to drag into the current century still.
<infinity> How long can I expect to see "warning: foo uses a deprecated function bar()" before it becomes an error, I wonder.
<infinity> I guess I'll just have to make time to fix it before that happens.
<jbailey> infinity: If the driver's in-tree, I thought they didn't usually like to kill interfaces that were in use?
<infinity> It's in-tree, but I get the impression that OldWorld is more likely to get drivers removed than fixed, unless someone steps up.
<siretart> infinity: which information/documentation should I read to make a ia32-libs-videogames package?
<fabbione> siretart: i think it's easier to declare world peace before going there
<siretart> fabbione: I see
<lamont> hrm... php5_5.0.5-2ubuntu2 needs to convert to db4.3 so that it's not ftbfs
<lamont> ditto for php4_4:4.4.0-4
<fabbione> lamont: yes.. infinity knows about it
<fabbione> they also need to switch to libsnmp-9
<Tm_T> ok, any news/fixes related to network connection not coming up at boot
<Tm_T> I remember several users got that problem here
<zyga> Seveas: ping
<Tm_T> aww
<Tm_T>  /etc/network/interfaces was missing "auto eth0"
<sistpoty> elmo: please sync snmpkit from unstable, ubuntu override ok. thx.
<Seveas> zyga, pong
<raphink> wow taht's a very long ping pong table
<zyga> Seveas: hi, it seems I was not added to the UbuntuMembers team
<mdke> zyga, you need to contact a community council member to be added to the launchpad team
<zyga> mdke: I thought that process is automatic after you become a member (other people from the same session were added)
<mdke> zyga, someone needs to approve you
<zyga> I asked to join the team via launchpad, is that enough?
<mdke> zyga, yes, but one of the CC members needs to accept you into the team
<zyga> okay
<zyga> so I guess what I did is enough
<mdke> sure yeah
<zyga> thanks :-)
<slomo> short question... are libmpeg2, liba52, libdts and libgsm1 ok for shipping on cd? or applies the same as for libmad on one of them?
<poningru> \sh_away:: dude you know that your last post is still on planet ubuntu right? and assuming on many other planets
<poningru> the I FUCKING QUIT blog
<ogra> poningru, he apologized in his next post
<seth_k> ogra, but after that he made a post saying he removed the post, b/c of possible legal issues
<ogra> hmm, true, he should put up a new one for the apology ...
<ogra> oh, they are just in the wrong order ... its still there
<poningru> ogra: he did
<poningru> he put up a new blog entry
<poningru> and he removed his old one
<poningru> but the old one persists on the planet
<ogra> oh, yes ... planet needs to sync ... it will go i guess
<slomo> no... the planets don't remove removed entries :/
<ogra> how odd
<Seveas> zyga, if you're on the list of proposed members instead of the list of members, ping kamion or mako at the next CC meeting
<zyga> Seveas: okay
<zyga> Seveas: on the wiki I'm listed as new member
<Seveas> wiki == what's said on the meeting
<Seveas> launchpad == official list
<zyga> so launchpad is out of sync, but that's okay as you've said
<desrt> is it possible to change the product that a bug is assigned to in launchpad?
<ogra> desrt, #launchpad ? 
<desrt> ahah.  thx.
<zwnj> seems libxml++ package has wrong dependencies: http://rafb.net/paste/results/6l61gL12.html
<\sh> never trust a debian package
<\sh> AC_OUTPUT([debian/Makefile \
<\sh> bah
<crimsun> zwnj: it works fine in Dapper
<crimsun> zwnj: works fine in Breezy, too
<zwnj> crimsun: but i'm trying to install it on breezy too
<zwnj> crimsun: which version do you test on breezy?
<crimsun> zwnj: let's move this to #ubuntu
<nasdaq7> hi i was wondering: how many Ubuntu users are there?
<Hieronymus> nasdaq7: I'm the only one
<nasdaq7> i mean how many times has it been downloaded?
<Hieronymus> you can't really tell that as you can't count all mirrors
<nasdaq7> ok
<nasdaq7> i've heard a few people say they use ubuntu
<nasdaq7> so it must becoming quite a lot
<Mithrandir> nasdaq7: we passed 1M CDs shipped in April.. No idea what the current number is.
<nasdaq7> for the month?
<Mithrandir> no, physical CD sets shipped.
<nasdaq7> i was wondering
<nasdaq7> where is ubuntu going?
<nasdaq7> will it offer the same developer opportunity as windows someday?
<HiddenWolf> nasdaq7, in which sense?
<\sh> "developer opportunity" means? 
<HiddenWolf> "getting hired by massive company" 
<HiddenWolf> "developing cool stuff"
<HiddenWolf> what?
<mpt> or getting hired by a cool company to develop massive stuff :-)
<\sh> "clicking an application"?
<nasdaq7> sorry i was just away
<nasdaq7> i mean what is the goal?
<nasdaq7> create an os to rival microsoft's os
<nasdaq7> or create ubuntu and make money off the application development
<mpt> nasdaq7, https://launchpad.net/malone/bugs/1
<mpt> but as for "the goal", different people have different reasons for contributing to Ubuntu
<\sh> actually we want world domination...after finishing with the world domination we will fly to mars and dominating the aliens
<LaserJock> \sh: that's right
<Mithrandir> mpt: like, \sh obviously wants to dominate aliens.
<mpt> A pre-emptive war to prevent the Martians from terrorizing us
<\sh> mpt: but a war with love only...
<\sh> because "Ubuntu" :)
<mpt> \sh, I'm not interested in your love life or whether you like dominating :-)
<Mithrandir> well, Martians != Humans, though.  So we're speciesist.
<\sh> mpt: ugh...that wasn't my s.. preferences
<Hieronymus> nasdaq7: Ubuntu is Free software. That means, everyone can modify and/or redistribute it
<nasdaq7> are there companies you know off that are developing applications for ubuntu?
<Hieronymus> http://www.gnu.org/philosophy/free-sw.html
<mpt> Like the saying goes
<mpt> You can have any OS you like, as long as it's brown
<\sh> dum-dum-de-dum *ubuntu* de-dum-dum-de-dum *ubuntu*
<Mithrandir> nasdaq7: vmware, for instance.
<\sh> everything else is a thoughcrime
<nasdaq7> but you guys are all being paid to develop right
<nasdaq7> ?
<HiddenWolf> Some, some not.
<Mithrandir> nasdaq7: most Ubuntu developers are not paid to develop Ubuntu, no.
<nasdaq7> so they just like linux
<nasdaq7> etc.
<nasdaq7> and develop
<Mithrandir> nasdaq7: people have different motivations, but yes, that they want their OS of choice to be even better is certainly a motivation.
<nasdaq7> ok
<nasdaq7> thanx all
<nasdaq7> see ya
<zwnj> md5sum of  universe/source/Sources.gz seems to be wrong
<zwnj> http://rafb.net/paste/results/Lwj2ca56.html
<LaserJock> zwnj: did you do it on the .gz
<zwnj> LaserJock: Oops, you're right
<zwnj> LaserJock: but, apt-get tell me this too
<LaserJock> zwnj: doesn't for me
<\sh> elmo: please sync dar from unstable, dropping ubuntu changes, thx
<\sh> elmo: please sync debmirror from unstable, dropping ubuntu changes, thx
#ubuntu-devel 2005-12-16
<\sh> elmo: please sync doodle , drpython from unstable, dropping ubuntu changes, thx
<\sh> elmo: please sync exiv2 , fluidsynth , fsh , gdal , geos , gdome2-xslt , gendameng from unstable, dropping ubuntu changes, thx
<\sh> elmo: please sync xchat-systray , gpib , rubber from unstable, dropping ubuntu changes, thx
* mdke smacks ozamosi- 
<mdke> bad!
<mdke> jbailey__, with a clean breezy source, the debdiff is over 8MB :)
<mdke> ozamosi, DUDE!
<psusi> oh my... anyone else notice that the download window in firefox in dapper is broken now?
<seth_k|lappy> psusi, yep, i was wondering if it was just me. but it's broken on both my dapper boxen
<infinity> Yeah, it's definitely not just you guys.  I've just not gotten around to irritating Diziet about it.
<infinity> And before you go deleting your profile to see if that helps, it doesn't.
<LaserJock> hmm, I guess I use wget too much. I haven't noticed it
<infinity> Yeah, I usually copy links from my web browser and paste them in terminals too.
<infinity> There are times, though, when that's not feasible.. (like downloads started from Javascript)
<infinity> Or HTTP redirects, or, or...
<LaserJock> yeah, I hate that
<zakame> elmo: hi, please sync lostirc from Sid, ok to override Ubuntu changes.  Thanks! :D
<Mithrandir> gnnr, I hate how nautilus _sucks_ over ssh connections.
<Mithrandir> sits there consuming vast amounts of CPU and bandwidth.
<tseng> Mithrandir: sshfs is cool
<tseng> Mithrandir: hm oh, not gnomevfs
<Tm_T> sshfs is very good
<pef> elmo: hello, ca, you help me with an upload problem ?
<fabbione> something in the last initramfs broke usplash on ppc
<hara> uhum uhum uhum
<hara> i don't want to register to report a bug
<hara> is it okay to report it here?
<hara> not a big bug
<fabbione> hara: nope.. you need to report it on either bugzilla (if the pkg is in main) or launchpad (if universe)
<fabbione> here it will pass unseen
<hara> uhh, how do i know where it's from?
<jpatrick> hara: apt-cache show <pkg name>
<hara> ahh, okay, it's universe
<hara> thx
<raphink> so it has to be reported on malone ;)
<sivang> hara: why don't you want to register on launchpad?
<raphink> pb is : to report on malone, one needs to be registered on LP
<fabbione> raphink: LP doesn't spam people with ads or so
<raphink> fabbione: that's entirely right
<fabbione> raphink: it sends the bare minimum related to what you do in LP
<fabbione> so i see very little problem with it
<raphink> yes I know that fabbione ;)
* sivang agrees
<hara> okay i registered to launchpad, waiting for the confirmation mail
<fabbione> ops
<sivang> ah, cool :)
<fabbione> raphink: that was for hara
<fabbione> sorry
<raphink> oh ok
<raphink> hara: this way it'll be faster next time you need to report a bug :)
<sivang> hara: when you add some contributions, LP makes it easier for you to track activities. You can now also create all sorts of content and suggestion for Ubuntu.
* sivang thinks we really need the "Report A Bug" LPI item enabled already...
* raphink thinks it's not easy for basic users to report bugs
* \sh just feels stupid now...because he reads a documentation and the behaviour described doesn't work
* raphink hates documentation
<hara> i've used linux for about 8 years and never reported bugs...
<\sh> fabbione: you don't have an amd64 and you are not running an i386 pbuilder environment on it?
<raphink> hara: good you're doing it now
<sivang> hara: that's a shame, reporting bugs when using linux is a inter-national sport :-)
<hara> or maybe not, still haven't received the mail
<hara> sivang: i am sooo bad explainer that you can't believe, that's why i haven't reported
<sivang> hara: ah I see, well - I understand that. I sometimes also feed that bad that I think of not reporting something, but then, I would never get improved if I don't practice :)
<hara> even more because of english is not my native language... and linux is english...
<sivang> hara: neither for me English is not native, worse my native lang is RightToLeft, and even not of latin ancestry, you get the idea :)
<hara> my only contribution to linux is a driver information for v4l
<hara> okay 
<sivang> if you check Ubuntu Code of Condut, you'd see that there are no small contributions. Everybody counts. 
<hara> sure
<raphink> hara: so after 8 years using lost of distros, you come to help channels, ask for help, fixes a bug and don't get back?
<raphink> hara: is that your view on how linux works and improves ? ;)
<hara> raphink: no no no. i'd like to report bugs and so on, it's just that i explain things sooo badly that people have hard time understanding what i'm saying
<hara> i'm sort of an topic killer
<hara> still waiting for the mail from launchpad...
<sivang> hara: let's make a deal, whenever you have something, and you open a bug in either bugzilla / malone (LP) please CC me on the bug report, and I will triage it and possibly provide more info and explenation if I see they're needed, deal? :-D
<hara> huh? don't scare me away ;)
<sivang> sorry if I did, that was not the intention.
<hara> lol
<sivang> But I hate to see important bugs that can suggest imrpoved quality get lost ;-)
<hara> i see your point
<hara> still waiting for the mail from launchpad...
<mpt> sivang, I thought LPI was going to be used for bug reporting too, but apparently that would result in too many bug reports
<fabbione> \sh: ?
* Tm_T is wondering who's Irssi package maintainer
<dholbach> Tm_T: in ubuntu we have the concept of team maintenance
<Tm_T> aah
<Tm_T> anyway, 0.8.10 is out
<Tm_T> :)
<Tm_T> long over 2 year waiting is over ;)
<dholbach> you could do some hardcore testing to it and maybe file a wishlist bug
<mdke> hey there dholbach 
<dholbach> hey mdke
<infinity> dholbach : We're already shipping 0.8.10 release candidates anyway, so I'm sure someone will get around to rolling a new version.
<Tm_T> irssi-text/unknown uptodate 0.8.9+0.8.10rc5-0ubuntu4
<dholbach> Tm_T: ^
<mdke> dholbach, i've been making a package of ubuntu-docs for breezy-updates with some translations and a nicer firefox/epiphany home page
<Tm_T> infinity: I thought so :)
<dholbach> Tm_T: you can't say we're much behind :)
<Tm_T> dholbach: I'm not saying at all, actually I'm very pleased how uptodate we've been
<mdke> dholbach, you wanna have a quick look at it to make sure it's alright?
<infinity> Tm_T : If you really want to, file an "enhancement" bug in bugzilla and assign it to "adconrad@ubuntu.com" and I'll personally bump the version tomorrow.
<infinity> Tm_T : But if I didn't do, it someone else would. :)
<dholbach> mdke: could you put a source package online?
<dholbach> mdke: so we could check the debdiff
<mdke> the debdiff is absolutely huge I'm afraid
<dholbach> mdke: :/
<mdke> you can see it all at http://doc.ubuntu.com/debs/breezy-updates
<mdke> it's 8.5MB
<Tm_T> infinity: I'll try to do that later, been busy testing apps and reproducing crashes ;)
<mdke> ;)
<dholbach> mdke: mdz will want to review it for breezy-updates
<mdke> dholbach, yeah I know
* dholbach cries silently
<mdke> heh
<mdke> sorry, it's a lot of lines of translations
<dholbach> mdke: it'd be great, if we could fix that pt_BR bug
<Tm_T> infinity: anyway, thanks :)
<mdke> dholbach, i have no idea how to fix that
<dholbach> *nod*
<dholbach> mdke: i'll look at the debdiff later
* sivang lols at mpt's previous comments about the LPI "Report A Bug" item :-)
<mdke> tank yew
<dholbach> de rien
<mdke> you won't say that when you see the debdiff
<dholbach> we'll see :)
<mdke> the problem is that all the translations are part translated and part english
<mdke> but even the english bits go into the debdiff, making it huge
* fabbione hits radeon with a cluebat
<fabbione> did anybody ever managed to get dual head out of a radeon card on a powerbook?
<Treenaks> fabbione: is it an M9 or M10/
<Treenaks> ?
<Treenaks> fabbione: those are weird
<sivang> wb mpt 
<fabbione> 0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
<Treenaks> fabbione: M10
<Treenaks> fabbione: I've only got mine to do mirroring
<fabbione> Treenaks: mirroring would be fine
<fabbione> can i see your config?
<fabbione> actually mirroring is exactly what i am looking for
<Treenaks> fabbione: I nuked it (reinstall)
<fabbione> except i can't get to work that either
<fabbione> ok
* fabbione offers a human sacrifice to st. google
<juliux> hi all
<fabbione> Treenaks: ehhh i got dual head now..
<fabbione> time to get clone to work
<mdke> jdub, in the last week or so there has been a massive increase in the amount of spam going to list owners and lists in general: any idea why?
* ogra didnt recognize more spam than usual to edubuntu-devel ... but a ton of overflown gmail accounts that resulted in bounce messages
<mdke> oh yeah we had one of those too
<Treenaks> ogra: an _overflowed_ gmail account?! WTF?
<mdke> but in general, on ubuntu-it the spam has been massively increased, both coming via -owner and via the list itself
<Treenaks> mdke: same in -nl
* mdke nods at Treenaks 
<ogra> Treenaks, mails come back with "out of space" messages
<mdke> i've heard the same from another locolist admin
<Treenaks> ogra: we were just discussing that song on #ubuntu-nl..
<ogra> lol
<sivang> mdke: I've been reciving LOTS of spam emails ever since my loco list was created..
* ogra kicks MOM 
<mdke> the lists moved server last week didn't they?
* ogra boggles on the new xscreensaver changelog in debian ...
<ogra> WTF?  "* Build-depend on autotools-dev."
* \sh is stucked
<Pygi> hehe
<\sh> I should give back my upload rights...I'm not able to understand any computer anymore
<Pygi> hehe, what happened?
<\sh> ok...g-wrap build-deps on guile-1.6-slib
<\sh> guile-1.6-slib depends on slib
<\sh> and slib installs via apt-get install cleanly but tries to remove guile-1.6-libs
<\sh> apt-get -s install guile-1.6-slib tells me that slib is not installable...
<\sh> so where is the logic...guile-1.6 rebuild? but why, when guile-1.6-slib only install dep on slib
<Pygi> heh, dependency hell
<Pygi> tried installing gnucash? It does use G-wrap
<\sh> Pygi: i'm merging g-wrap...
<Pygi> yup, I understand..
<\sh> so i'm stucked
<Pygi> hm, I'll take a look at it now
<sivang> anybody has an idea if /usr/bin/notify-send supports callbacks / actions from the notification balloon ?
<\sh> Pygi: use the debian package of g-wrap :)
<Pygi> sh: I just did it, and no problems emerged
<Pygi> heh, but not debian ones :P
<\sh> Pygi: pbuilder build g-wrap?
<\sh> Pygi: use the debian source of g-wrap...and build it in a dapper pbuilder
<Pygi> hehe, guess what happened
<Pygi> I installed it, and now when I want to remove it it says that it isn't installed :/
<\sh> great
<\sh> jbailey__: your cdbs is assimilated by da b0rk
<ogra> \sh, didnt Riddell take oer cdbs ? :P
<ogra> *over
<Pygi> I need to take over the Anjuta :) hehe
<\sh> well...actually it doesn't matter who broke it...but actually there are only a hand full of people, who are cdbs specialists...and believe when I'm saying this: I'm not one of them..
<\sh> but somebody has to fix it..
<slomo_> Pygi: good idea :) i wanted to play with 2.0 anyway ;)
<Pygi> with \sh's permission, or whoever's permission I need, I'll take over the anjuta package :)
<Pygi> slomo_, have you tried the 2.0 series?
<slomo_> oh wait...
<\sh> Pygi: whoever said, that you need my permission to do anything in ubuntu..HE IS WRONG
<slomo_> in debian/experimental there is already 2.X
* slomo_ tries it
<Pygi> well, whose permission do I need :)
<Pygi> I can't just take over the package from "someone"
<ogra> Pygi, you need to bcome a motu first
<Pygi> oh, yes, the MOTU thingy...
<slomo_> Pygi: maybe it's not necessary to fight with anjuta anyway ;)
<\sh> Pygi: we don't have something like "maintainership" or "indiviual packages" like debian...we are working in teams
<ogra> and iirc seb128 was planning in brezy already to bring 2.0 in
<Pygi> ogra: ah, well, ok then
<ogra> Pygi, if youre a motu, you can just care for it 
<Pygi> well, you see, I ain't a motu :)
<ogra> no need to "greb it from someone" ;)
<ogra> *grab
<slomo_> ogra: hmm, i'll try the experimental version and talk to him later :)
<tuhl> hi all
<tuhl> when will we get openoffice 2.0?
<tuhl> final
<ogra> with dapper
<Pygi> Last thing I tried to do for Ubuntu didn't go very well... I speaked with Kamion about helping to code the UbuntuExpress, he said no problem, I can help, and no word from him in a long time :/
<Pygi> firefox 1.5stable also with dapper I think
<ptlo> Pygi: don't be shy, you're advocating ubuntu in croatian schools
<ogra> Pygi, just grab the bzr source and offer your patches to him
<Pygi> ogra: kk, I'll try
<ogra> i.e. in a bzr branch online he can inspect ...
<Pygi> ptlo: hehe, no comment
<\sh> Pygi: well you read the specs..you know bzr...start :) don't wait for people coming to you :)
<Pygi> :)
<tuhl> ogra: no backporting for breezy?
<ogra> unlikely 
<mdke> maybe in breezy-backports?
<ogra> but ask on the ubuntu-backports list ... ther was a thread already iirc
<\sh> pitti: wake up and fix cdbs :)
<ogra> \sh, fix it yourself :P
<mdke> on a sunday as well! harsh
<\sh> ogra: never...I never touch cdbs...
<Pygi> \sh: may I ask what's wrong with cdbs?
<\sh> ogra: my name is not voldemort :)
<ogra> its cdbs :)
<slomo_> \sh: reverting the last change should be enough for now
<dholbach> ogra: go home
<dholbach> *gnarf*
<ogra> dholbach, blblbl :P
<\sh> Pygi: it's mysterious black magic....akbra kadavra
<dholbach> poor cdbs is broken
<\sh> hihi
<Pygi> well, it'll get fixed eventually...sooner or later :)
<\sh> apt-get source cdbs
* sivang takes \sh and hide away .oO(I hope nobody will know we broke it ;-) )
<Pygi> sivang: heheh
<\sh> slomo_: and only in gnome packages right?
<dholbach> \sh: no
<slomo_> \sh: not yet sure... raphink told me it also broke for some kde stuff
<jpatrick> .pot files
<\sh> ok...so we have to people who did harm to cdbs
<\sh> 1. riddell
<dholbach> not only stuff with pot files
<ogra> wasnt that fixed recently ? 
<\sh> 2. pitti
<slomo_> \sh: and i have a package which only uses the autotools class and breaks ;)
<\sh> great...
<ogra> "Don't remove whole po/ directory in kde.mk.in, only .pot files in it"
<pitti> \sh: meh? what's broken}
<ogra> last changelog from Riddell ^^
<pitti> \sh: I only changed gnome.mk
<\sh> pitti: meh...make install target doesn't get executed sometimes
<raphink> slomo_: yes it seems, since Riddell changed the pot stuff in cdbs on the 6th.... seems to me at least. I dropped a not about this on my kyamo package's page on review
<raphink> REVU
<\sh> pitti: gtkmathview that is
<pitti> \sh: that's nothing I touched 
<raphink> s/not/note/
<\sh> pitti: but it's reproducable...
<slomo_> pitti: and gnome-mk-update-pot (at least sometimes but for one package always) goes in a infinite loop
<pitti> slomo_: ok, that sounds like my breakage - which build log?
<dholbach> try to build anything with cdbs :)
<\sh> or...not pitti or riddel are to blaime...no...cdbs started to live it's own life in the ubuntu archive...it happend once on the enterprise 
<pitti> dholbach: sure, I uploaded it without any testing, since testing is for wimps
<ogra> hehe
<dholbach> pitti: i didn't blame you... honestly. something else might have broken it.
<pitti> dholbach: ok, so the current version loops with any gnome package?
<slomo_> pitti: none yet... a package which isn't uploaded yet... gst plugins base 0.10... i can mail you the buildlog if you want it
<dholbach> make install    seems to be broken with packages not using gnome.mk as well
<\sh> pitti: I don't blame you either...I know how hard it is..but you know..we need always someone to blame..,(
<\sh> eh :)
<pitti> \sh: sure, nevermind, but I need to reproduce it to fix it
<\sh> pitti: make install issue...gtkmathview from unstable 
<pitti> I have 0.4.32ubuntu9
<pitti> \sh, dholbach: ok, so I try to build gtkmathview 0.7.5-2 with cdbs 0.4.32ubuntu9. Is that right?
<\sh> 0.4.32ubuntu9
<\sh> yes
<\sh> and the version of gtkmathview is also right
<\sh> well...I just recreated my pbuilder chroot...and building this package again..lets see
<dholbach> stuff built nicely with cdbs yesterday
<dholbach> hrm
<dholbach> and it was the same version
<dholbach> weird
<ogra> gremlins ....
<zyga> hey guys
<pitti> Hi zyga 
<\sh> dholbach: you build stuff yesterday..with the same cdbs version ..and today it doesn't build nicely ?
<zyga> working on sunday?
<dholbach> \sh: i just looked at buildlogs
<pitti> zyga: trying to avoid it :)
<zyga> steer clear from the keyboard ;-)
<\sh> "Computer, please save and secure Program Data Startime 20051211 under Filename cdbs and protect it with a complicated encryption"
* pitti beats the proxy of his ISP to death - build dep download stuck at 16%
<\sh> pitti: a proxy?
<pitti> \sh: transparent one, I can't circumvent it
<zyga> \sh: good luck on finding a new job, it takes some guts to stand up to the manager like that :)
<\sh> zyga: to be honest...it was stupid...but for me it was the correct way...anyways..if I don't find a job latest in january...well...I have to find a bridge with wifi connection
<\sh> pitti: it's not telekom right?
<pitti> \sh: no, http://www.fbn-dd.de
<pitti> (works now, btw)
<zyga> \sh: wifi with a bridge, could be ... rare
<ogra> hostap ;)
<zyga> \sh: when being in danger of being fired make sure to plant traps in the production system ;-)
<\sh> zyga: the bridge must be near a university :)
<zyga> ah, my first im client has just logged in :-)
<\sh> zyga: well there is no need...I just resigned :) and our security officer was telling anybody in the company: "This guy will destroy our network" and I honestly don't know what drugs he was using 
<Pygi> :/
<zyga> \sh: what were you doing? I only jammed the production server with something that essentially was a nice for(;;) fork() but the whole network!
<\sh> zyga: actually..i didn't do anything..I left my company laptop and all passwords etc. in the company...I just wrote my resignation and I just walked home :)
<\sh> zyga: I called my colleague and told him that..and that he should remove all my accounts from the servers...
<\sh> zyga: what he did after I called him..so I can't do and I won't do anything :)
<slomo_> \sh: i can reproduce the cdbs make install problem with 4 packages now... in fact all packages i tried to compile lately ;)
<\sh> slomo_: on i386 or amd64...I have it on amd64 :)
<\sh> not tested on i386 :)
<slomo_> \sh: x86
<slomo_> \sh: seems like i'm a bug-magnet currently :) everything i touch is broken in some way
<\sh> slomo_: not only you :) I have some packages who are waiting for daniels and a fixed xauth :)
<slomo_> pitti: does "Deep recursion on subroutine "main::SubstituteVariable" at /usr/bin/intltool-update line 878, <CONF> line 64647." say something to you? that's probably the cause of the infinite loop in gnome-mk-update-pot
<pitti> make: *** Keine Regel vorhanden, um das Target install,
<pitti>   bentigt von binary/libgtkmathview0c2a, zu erstellen.  Schluss.
<pitti> aah
<pitti> do you guys mean this?
<pitti> slomo_: never heard about that one
<slomo_> pitti: yes, exactly that :)
<\sh> pitti: thats it
<slomo_> pitti: the other one happens with http://people.ubuntu.com/~seb128/gst0.10/gst-plugins-base0.10/  (gtk-doc-tools, python-xml are missing from B-D there)
* \sh is bbl..need to find something to eat and some tobacco..
<slomo_> \sh: good luck :)
<sivang> c'ya all, be back later.
<Kamping_Kaiser> is there a recomended method for debuging suspected udev problems? i asked in ubuntu a few hours ago (probalby 5) and havnt got a response, so i thought i might try here
<ogra_> Kamping_Kaiser: just file a bug and wait until the udev maintainer answers
<Kamping_Kaiser> ok. thanks ogra_
<mdke> does anyone know how to limit planet to aggregating specific categories in a feed? i can't find anything in the examples/ folder
<spacey> depends on the blog i guess
<spacey> if the blog has a rss per catogory
<mdke> well say, an rss feed with <category> tags
<tseng> mdke: i think the blog engine would have to offer a feed for that category
<spacey> but thats not as flexible
<mdke> tseng, ah damn
<spacey> then it would be crap to select like 2 cats
<spacey> mdke, well you can always hack it in yourself :P
<mdke> spacey, i've only read the introductory chapters of A Byte of Python so far...
<mdke> i wondered if it was already in there
<spacey> mdke, while i was setting up planet i didn't encounter it
<spacey> in the docs
<spacey> to be sure you should poke on of the devs
<mdke> there are docs?
<spacey> uh
<mdke> aside from the examples and the INSTALL/README
<spacey> readme at least
<mdke> heh the readme is 10 lines or so
<spacey> :D
<mdke> i'll poke em
<mdke> jdub, *poke* can planet aggregate single categories in a feed with more than one category?
<\sh> mdke: if your blog can create category rss feeds sure (e.g. like s9y(
<tseng> \sh: nice plug
<zyga> how do I get my blog hooked up to the planet?
<\sh> zyga: ping or mail jdub and be a member
<zyga> jdub: around?
<\sh> tseng: it's default behaviour of s9y :)
<spacey> \sh, yeah but if he wants to add two cat. then the person would show up two times in the subscribers list, no?
<\sh> spacey: well..first of all...subcats are this what he wants and selecting cats to include into the feed..
<mdke> zyga, planet ubuntu is broken right now so you can't get added :/
<mdke> \sh, i meant a single rss feed with more than one category
<\sh> mdke: hmm...so your blog should have the possibility to select categories to include in one feed
<mdke> \sh, ?
<mdke> most blog software does that...
<mdke> i want to know, can planet separate out the categories?
<\sh> mdke: I don't think so
<\sh> mdke: and many blogs can't select categories to include in one special feed
<mdke> \sh, the situation I'm talking about is where the blog software produces a *single* feed with multiple categories
<\sh> mdke: s9y can't do that either, but that's why I do sub categories and let create s9y a feed
<Kamping_Kaiser> thanks ogra_, i filed a bug on it. i will wait for a responce. thanks and bye all
<mdke> am i being unclear? :(
<\sh> mdke: linux.blogweb.de
<\sh> mdke: see the right pane..
<\sh> mdke: e.g. Desktop is a parent category..when you subscribe to this feed, all subcategories of this parent will be included into one feed
<mdke> \sh, dude, i'm talking about aggregating blogs which _don't_ do that
<mdke> which have a single feed, with more than one category in
<\sh> mdke: ok..planet can't select cats from one single feed..not that I know off..so you should work around it on your side :)
<mdke> \sh, as I said before, I don't know python, but I will see what I can do
<\sh> mdke: what blog software do you use? pybloxom?
<zyga> hmm, whenever I come in things start to break down
<mdke> \sh, planet is in python
<mdke> zyga, it's been broken for several months, but hopefully it will be fixed soon
<\sh> mdke: yes...but planet is an aggregator...and subscribes to feeds .. so your blog should do what you want :) not planet :)
<mdke> \sh, no i disagree, in an ideal world planet would have this feature
<mdke> anyway, I'm not doing this for my blog, which doesn't have categories
<mdke> i want to include many people's blogs into a planet which do have categories (generally running wordpress)
<\sh> mdke: but the world is not ideal :) and planet is has some other serious bugs...and when I have time I have to check it, how to fix it
<mdke> \sh, that is why I was asking if it does it already
<zyga> hmm
<zyga> isn't there some 'stock' planet software we could use?
<mdke> zyga, it's not the software that is broken on planet ubuntu
<zyga> so what is?
<\sh> mdke: you can try out one s9y planet aggregator plugin :)
<mdke> zyga, the synching process between jeff's archive, where he amends the configuration, and the webserver
<zyga> amends?
<mdke> modifies
<zyga> ah
<zyga> communication problems?
<zyga> (personal communication)
<mdke> no, i don't think so
<zyga> ah
<zyga> so technical stuff
<mdke> something wrong with bzr i think
<\sh> hmmm
<mdke> \sh, out of interest, which feeds from your blog get aggregated to planet ubuntu?
<\sh> mdke: the whole one
<mdke> oh right
<\sh> mdke: all..but if I give another feed of another parent cat...it uses the special feed
<mdke> ok
<mdke> how come you include "Real World" to planet ubuntu?
<\sh> mdke: planet.ubuntu.com -> right pane -> second paragraph :)
<\sh> Planet Ubuntu is a window into the world, work and lives of Ubuntu community members and developers.
<mdke> ah
<\sh> i think it's different then planet.gentoo.org where on the main planet is only gentoo orientated stuff...and on planet.gentoo.org/universe or something like this, is everything
<mdke> ok
<mdke> because I noticed some other people just include [tech]  posts and such
<sistpoty> I've got some kernel/init? probs with 2.6.15-7 with module hpt366... what is needed for a bug report?
<\sh> mdke: like daniels ?
<\sh> mdke: i think it's a matter of the tagging and category system of their blog software...
<mdke> sure
<mdke> i guess people choose whether to include specific linux related categories or everything
<\sh> mdke: well...I think ubuntu is more then only linux....
<\sh> mdke: I have to say, that ubuntu developed more then just to be technical...it has changed people completly in their views sometimes...
<\sh> and jabberoo hit again the cdbs bug
<HiddenWolf> \sh, agreed. I've never encountered a community that works together so well, and so friendly.
<HiddenWolf> \sh, guess it hits a nerve with people in an age where individualistic consumption is the norm.
<\sh> HiddenWolf: well..it hit at least me :)
<HiddenWolf> \sh, a bit of a sanctuary full of like-minded people, isn't it? 
<\sh> HiddenWolf: to be honest, i don't know...but the idea behind the whole thing touched me...sometimes it's hard to be compatible with the CoC but well...time will tell :)
<HiddenWolf> \sh, got spanked for the language in that blog post, did you? ;)
<\sh> HiddenWolf: no...I spanked myself
<\sh> HiddenWolf: but sometimes it's better to let everything out...and after all..I had some comments, which were more nasty then the "f" word
<HiddenWolf> \sh, I understand, and I don't blame you.
<\sh> HiddenWolf: and when I write about some people, I don't expect others to bash them more...at least they don't know the people
<\sh> HiddenWolf: I blame myself :) but I'm working on it :)
<HiddenWolf> \sh, That comes with being popular. People will take up for you, even if it's not apropriate.
<\sh> HiddenWolf: I learned the lesson :) 
<HiddenWolf> \sh, so you got rid of frustration, grew as a person, and got wiser to boot.
<\sh> HiddenWolf: well...got rid of the frustration yes...grew as a person, I can tell...this I will know later, when I'm standing in front of the holy court :)
<\sh> I can't tell even
<ogra> grumble ...
<HiddenWolf> *chuckle* Don't wait for that, just do what is best. :)
<\sh> HiddenWolf: well..I
<\sh> 'm merging now :)
<HiddenWolf> \sh, it's sunday. don't work yourself out. 
<\sh> HiddenWolf: well..for the next couple of weeks it will be sunday all the time :)
<HiddenWolf> take my word for it, keep your rhythm.
<\sh> HiddenWolf: well...if i'm feeling burned out..nobody will see any upload in a couple of months :) but right now...I'm fresh, and ready to work :)
<GnuKemist> \sh, good morning... ;)
<GnuKemist> ogra, good morning to you too...  ;)
<ogra> hi
<GnuKemist> ogra, what's new?
<nekohayo> am I dreaming or GST 0.10 is in dapper? :)
<ogra> a lot of breakage in ltsp ... 
* ogra cant get the keymaps to work ... 
<GnuKemist> ogra, ouch...
<ogra> seems its an xorg bug
<GnuKemist> ogra, anyone else experiencing the same?
<HiddenWolf> nekohayo, it's in, but it's only a first version. Don't know if any programs use it already.
<slomo_> nekohayo: it is, yes... but currently there are absolutely no plugins and no program using it ;)
<nekohayo> I see
* hunger sighs.
<ogra> GnuKemist, i doubt anybodz plays with ltsp currently
<hunger> box does no longer boot... any ideas what might be causing it this time?
<nekohayo> actually I realized there are only 1-3 modules of gst that are 0.10, the rest is still 0.8.11
<GnuKemist> ogra, I know a few Brazilians who are...  I could drop them a line
* hunger only gets a black screen, nothing happens at all.
<ogra> but: "(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
<ogra> " might affect non ltsp setups too in flight 2
<ogra> seems rather like general xorg breakage
<GnuKemist> wish I could be more of help
<ogra> test flight 2 if its out :)
<HiddenWolf> ogra, that'll be this week?
<ogra> hopefully
<ogra> but no promises
<HiddenWolf> ogra_, pending the boot-sequence being debugged nicely?
<sivang> hmm, I dist-upgraded now to latest kernel, and certrinly the new udev. everything works :)
<hunger> sivang: I only get a black screen... box no longer boots.
<hunger> sivang: Before the latest upgrade I could no longer burn CDs.
<sivang> hunger: ah, I think I have that as well - minor glitch :)
<sivang> hunger: are you on x86 ?
<hunger> sivang: Yes (using the latest linux-686 image).
<sivang> hunger: as in 2.6.15-7-686 #1 SMP PREEMPT ?
<hunger> sivang: I already changed the permissions on the cdrom/cdrw so that group cdrom can write to it. Didn't fix it.
<sivang> hunger: probably not a permissions problem..:-/
<slomo_> hunger: hi... what's the state of the xen 3.0 packages?
<hunger> sivang: linux-image-2.6.15-7-686 version 7.9
<hunger> slomo_: Trying to build a as ubuntu-like as possible kernel of version 2.6.15.
<hunger> slomo_: Xen has the merge-tree that comes close, but there are still lots of bugs to get it to build.
<hunger> slomo_: I do not see xen in ubuntu before it is part of the vanilla kernel.
<slomo_> hunger: sounds promising :)
<slomo_> hunger: oh :/
<hunger> slomo_: It would be easier if upstream were a bit more responsive wrt. their linux-merge repository...
<hunger> slomo_: They are lagging behind both the tree of linus and the patches submitted for their own tree on their ML:-(
<ogra> slomo_, same prob as low latency audio kernel... we wont have more than one kernel image in the distro ... whats not upstream and in the ubuntu kernel must be maintained separately
<ogra> so bad luck for low latency audio as well as XEN until linus adopts it
<hunger> ogra: Suse, redhat and intel are teaming up to get xen support into vanilla:-) Let's see how long linus can resist.
<ogra> hehe
<HiddenWolf> hunger, quite long, quite possibly. He's stubborn as hell. :)
<hunger> ogra: Even though there is not much happening in the repossitory used to prepare the vanilla patch:-(
<ogra> i think thats what linus sees too 
<hunger> ogra: I suspect that much work is done internally.
<ogra> but they should make it public fo linus ....
<hunger> ogra: Xen isen't all that open:-( People do a lot of communications/developments done in a group that is not publicly visible.
<ogra> thats bad 
<hunger> ogra: The bonus and bane of having everybody close together.
<HiddenWolf> ogra, happens in any project. People getting together form the best ideas, and when everyone is close, there is little reason to document and publish.
<ogra> there is reason, as you can see :)
<ogra> if the work would be public and easy to follow, linus would probably already have adopted it .... who knows
* HiddenWolf chuckles
<Treenaks> sounds Reiserish
<HiddenWolf> Treenaks, exactly
* ogra *shudders* at the mentioning of reiser
<HiddenWolf> ogra, can't be that bad, surely?
<ogra> reiser is crap ...
<ogra> trading speed for stability is not the answer ...
<HiddenWolf> Isn't it the other way around?
<ogra> ??
<ogra> you mean reiser is stable but slow ? 
<HiddenWolf> Hm, no, I read you wrong.
<ogra> heh
<ogra> ok :)
<HiddenWolf> ogra, "trading stability for speed"
<HiddenWolf> ogra, "trading a chicken for a cow" you get the cow, give the chicken.
<ogra> err, yes, my bad :)
<HiddenWolf> Then again, it's a filesystem, how unstable can it be?
<Treenaks> HiddenWolf: don't underestimate that :)
<HiddenWolf> if it's not solid, people won't use it. one should hope.
<HiddenWolf> Outside of the gentooish crowd.
<Treenaks> HiddenWolf: l33t g4m3rs (the gentoo type) only care about speed. not about stability
<HiddenWolf> Treenaks, I sincerely doubt that anyone serious about gaming would even bother with linux.
<ogra> HiddenWolf, suse included the first reiser in a highly unstable state as the default fs ...
<HiddenWolf> ogra, That's suse. ;)
<ogra> if you trust your distributor you are fucked in this case ...
<HiddenWolf> Treenaks, that leaves the 14-year-olds. :)
<wasabi__> Yeah we need ZFS.
<ogra> HiddenWolf, i've seen company admins trusting suse back then ... they had hard times :)
<\sh> lol
<ogra> ...or even lost thier jobs if the backups didnt work
<\sh> I just heard a good joke
<\sh> "oh..it's starting kubuntu...and now a bluescreen...why doesn't it work?"
<HiddenWolf> ogra, any company sysadmin should be knowedable enough to know what he's installing. :)
<wasabi__> In a world filled with Windows, I totally disagree.
<HiddenWolf> wasabi__, notice the should
<ogra> HiddenWolf, guys who just switched from windows ... they had MCSE ... and just learned about linux
<Treenaks> HiddenWolf: RFC-something SHOULD ? :)
<wasabi__> In the Windows world you don't need to know anything to get the job done.
<HiddenWolf> ogra, still, anyone with half a brain shouldn't blindly trust what he's not familiar with.
<hunger> ogra: Even MCSEs should and usually do know what they are doing:-)
<wasabi__> Which is good or bad depending who you are. ;)
<ogra> wasabi__, you need the MCSE multiple choice test to get into the job ;)
<hunger> ogra: Usually they stay away from linux because they can not do a multiple choice exam on that;-)
<wasabi> Yeah.
<ogra> HiddenWolf, they *payed* for the OS, it must be good and well tested
<wasabi> I hate to say it, but Windows isn't as bad as ya'll think.
<HiddenWolf> ogra, paid, and yes. But that same thing applies to XP. ;)
<wasabi> I am quite happy with my work network, all Windows.
<ogra> HiddenWolf, sure :)
* hunger agrees with wasabi. Windows has done lots of catching up in the last couple of years.
<HiddenWolf> wasabi, I die without middle click pasting and multiple workspaces.
<HiddenWolf> otherwise, I can deal.
<wasabi> ... that is hardly a bit deal.
<wasabi> big
<HiddenWolf> wasabi, for me it is. :)
<hunger> In fact Active Directory is nicer than any linux-solution out there IMHO.
<wasabi> Uh huh.
<wasabi> Agreed.
<HiddenWolf> wasabi, specially with an IE without tabbed browsing.
<wasabi> I have done a lot of recent work just trying to get a proper Linux Kerberos/LDAP setup on a client to do what AD does.
<wasabi> Pain in the freaking ass.
<HiddenWolf> wasabi, and on a 17" at school, as opposed to my 24" at home. ;)
* ogra watches \sh spamming -changes
* HiddenWolf looks at \sh
<hunger> HiddenWolf: Bashing windows for IE?
<\sh> lol
<\sh> elmo just woke up :)
<\sh> elmo: THX :)
<wasabi> I think Firefox 1.5 does full Kerberos auth now, so it's pretty usable on a corporate network.
<hunger> HiddenWolf: You can get firefox for windows, you know?
<ogra> seb128, i just noticed that my first login attempt in gdm seems to always fail on boot ... i suspect a race condition somewhere ...
<HiddenWolf> hunger, not bashing. but in the two years I've been at university, I sat in the computer lab maybe 10 times.
<HiddenWolf> hunger, I know, but not at my university. ;)
<seb128> ogra: autologin, ldap, nfs, local.. ?
<ogra> seb128, local
<seb128> autologin?
<ogra> seb128, i guess something in the bootprocess is there to late
<wasabi> Does pam have a way to signal a drop down box?
<ogra> nope
<ogra> manual
<wasabi> or multiselection of some sort?
<ogra> seb128, just a default setup
<hunger> HiddenWolf: Blame that on the admins at your uni.
<HiddenWolf> hunger, it's perfect for others, but it's enough to drive me home. :)
<seb128> ogra: learn to type correctly your password maybe :p
<ogra> seb128, second attempt is fine 
<hunger> HiddenWolf: In fact I fully understand using IE instead of FF in a corporate setting.
<ogra> :P
<seb128> yeah, learn to type it correctly from the first time :)
<ogra> seb128, i tried it several times, its reproducable 
<hunger> HiddenWolf: IE can get locked down... try that with mozilla:-(
<seb128> change debug to true to gdm.conf and look on the gdm logs maybe
<HiddenWolf> hunger, when did this turn into a debate? ;)
<ogra> yup, will do
<slomo_> btw, is someone still having the liferea crash? it disappeared for me ;)
<seb128> epiphany can be locked :)
* ogra goes trying
<HiddenWolf> seb128, yeah, but epiphany lacks the community and the marketing. :(
<akurashy> hmm a little help, i get this weird thing while compiling latest xmms, GTK+ >= 1.2.2 not installed - please install first , when i check synaptic nothing with "GTK+ is there
<wasabi> I love Epiphany.
<seb128> HiddenWolf: it's the GNOME browser, it has the community
<slomo_> akurashy: is libgtk1.2-dev installed too?
<wasabi> I should rewrite my link mime readahead in a proper python epiphany extension.
<HiddenWolf> seb128, true, but they're not as vocal. :) I have high hopes tho.
<akurashy> slomo_, gah, stupid thing, nop it wasn,t i stay to see if i get any other errors :), thanks!
<seb128> HiddenWolf: if people take decisions according to the marketing rather than the quality of the product that's not the product fault imho
<HiddenWolf> seb128, basic fact of life. There is too much info out there to know it all. If the product is not brought to attention, it's not used.
<HiddenWolf> seb128, that's not the products fault, but it's reality.
<seb128> HiddenWolf: I use epiphany and I'm happy to use it
<seb128> HiddenWolf: people can keep using firefox and complain about it if they like, I don't really care
<HiddenWolf> seb128, it has my vote too. :)
* desrt scrolls up to find out if this is a 'change the default' discussion
<HiddenWolf> desrt, no, it came out of bashing IE
<desrt> ok.  so we know IE ought not to be the default
<desrt> but what about ephy? :)
<HiddenWolf> seb128, but as long as people think there is only IE and Firefox, they won't use epi, that's the biggest problem it's facing today.
<robtaylor> i feel a bit stupid.. can someone tell me how to switch off image loading in epiphany?
<akurashy> slomo_, still the same error
<HiddenWolf> robtaylor, #ubuntu, shame on you! ;)
<desrt> robtaylor; it's very likely that you can't :)
<robtaylor> HiddenWolf: oops! thought i was in #g-h for a moment :/
<robtaylor> desrt: i've a sneaking suspicion that that could be the case ..
<desrt> robtaylor; ephy, being a gnome app, means that it only offers preferences that people actually use
<robtaylor> desrt: hmm, when i'm on GPRS, its definitly a pref i want to use ;)
<desrt> unfortunately "people actually use" is a fuzzy term so sometimes people get hurt :(
<desrt> $/bit?
<desrt> if you can't find the option you should (reasonably) file a bug... if you can convince them that there's a real use for it.....
* robtaylor decides to just go poke crispin ;)
<ogra> seb128, hmm, doesnt happen anymore ... but i had it four times in a row before ... 
<seb128> weird
<seb128> keep the debug maybe
<seb128> so if it happens again ..
<ogra> yup, will do
<ogra> gdm just restarted, it didnt mon about wrong passwrod or something ... thats what bothered me
<ogra> *moan
<mdke> dholbach, around?
<dholbach> mdke: yes
<dholbach> mdke: didnt look yet
<mdke> dholbach, no, i wanted to ask something else
<mdke> dholbach, if you have a couple of minutes, can you join #ubuntu-doc?
<jpatrick> who reviews MainInclusionReports?
<\sh> mdz and kamion and?
<ogra> only pitti
<\sh> only pitti?
<ogra> mdz promotes the packages to main after they show up in anastacia, Kamio does that if mdz isnt around ...
<ogra> the reviews are mostly security related
<\sh> s/mdz and kamion and\?/only pitti/
<jpatrick> because Riddell asked me to write one for my ksplash-engine-moodin : http://wiki.kubuntu.org/MainInclusionReportKSplashMoodin
<ogra> mdz/Kamion will only look at the review results and probably at the rationale
<\sh> strike wtf
<ogra> jpatrick, look at UbuntuMainInclusionQueue , the procedure is described there
<\sh> Security: No security incidents (the program is quite new).
<jpatrick> \sh: well yeah
<\sh> this means the app is quite untested?
* ogra goes cooking
<jpatrick> ogra: I added it there
<jpatrick> It was recently uploaded (2 weeks ago (I think) to universe)
<\sh> well...i'm drinking beer .. but I don't work while i'm drinking beer
* #ubuntu-devel  [freenode-info]  If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks!
<dilinger> hm
<dilinger> is ubuntulinux.org and ubuntu.com down?
<jpatrick> looks like it
<Znarl> Yes, fixing it now.
<HiddenWolf> Znarl, what happened?
<Znarl> Hardware failure it looks like.
<Znarl> OK, it's back.
<dilinger> great, thanks
<\sh> hmmm...sounds like mcgyver.."I need a pen, a chewing gum and some salt" "what do you want to do with it?" "well, fixing ubuntu.com" ,)
<Znarl> ...and a penny too this time, exactly \sh!
<\sh> Znarl: A "I kick the machine" didn't help?
<maswan> Znarl: thought you might be interested in this, and perhaps have some comments: http://www.acc.umu.se/~maswan/2005-12-10/2gbit-freesoftware.html
<Znarl> Thanks maswan, looks interesting.
<maswan> Znarl: was thinking of "publishing" it more widely after I get OK to use the graphs from stats.sunet.se
<HiddenWolf> The 42TB total network traffic over the week around the Breezy release shown in this last graph is equivalent to about 70 thousand cd-images. We estimate that about 10-15 thousand cd-images were downloaded during the first day.
<HiddenWolf> wow
<maswan> HiddenWolf: there, slightly updated to include a 100k iso figure too
<HiddenWolf> impressive
<hyperactivecrond> err... how stable is dapper?
<hyperactivecrond> oops wrong channel
<Pygi> hehe
<mdke> seb128, hiya, are you seeing this strange password dialogue in dapper? http://mdke.org/epiphany.png
<mdke> or anyone
<seb128> mdke: nop
<seb128> mdke: ask on #epiphany on irc.gnome.org if you want
<mdke> hmm
<mdke> seb128, i only started seeing it after the new firefox came in...
<seb128> mdke: that probably comes from firefox
<mdke> seb128, that is what I thought but I couldn't see any bugs about it
<sivang> mdke: I'm checking as well
<sivang> bah, I Need a page where I didn't yet ask to remember the password for
<mdke> seb128, i don't see it in firefox though, the dialogue looks fine
<sivang> mdke: I get it as well, but what's wrong about it ?
<sivang> (I was sure that was epiphany's version for that same dialog)
<mdke> see the & signs?
<mdke> in the middle of the words?
<sivang> mdke: ah right
<mdke> you see em too sivang ?
<sivang> yes
<mdke> ah good
<mdke> ok i'll file the bug
<czr> first off, thans all for a great distro. I've been recommending it for almost everyone that considered using linux at home. but I also have a question: does anyone here know the place to check what extra patches goes into ubuntu stock kernels? I need to check whether it has ext2online-patches
<sivang> I mistook them for valid chars :)
<seb128> mdke: don't
<mdke> seb128, it's filed already?
<seb128> mdke: no, but I don't want to be flooded by upstream bugs when not required, I'm pinged them on IRC
<seb128> if they know about this no need to flood bugzilla.ubuntu
<sivang> czr: https://wiki.ubuntu.com/KernelGitGuide <== you might find that useful
<czr> sivang, thanks
<mdke> seb128, you're sure it is upstream? I'm happy to look in gnome bugzilla
<sivang> mdke: if it's not filed upstream, go ahead and file it but if it us, I guess a reference would suffice..
<seb128> mdke: I'm speaking with them on IRC, a min, and like 99% of the software bugs that's an upstream issue yep
<czr> sivang, the wiki says that I shold get git-core from dapper, is it a good idea? breezy is good enough for me :-)
<mdke> ok i'll come and join in
<sivang> mdke, seb128 : is this on g-h ?
<sivang> czr: I've never actually tried that, you might have luck using git-core from dapper :)
<czr> well, last time I started used multiple repos like this I ended up with quite funny system, but thanks for the links, I'll try to get git somewhere
<sivang> czr: np, just make sure you have fully working backups and all the blah before funking your system :)
<czr> sivang, nah, I'll just get git from somewhere else. just borked my main system couple of days ago, don't want to go trough the whole mess again :-)
<czr> sivang, this is the first time I'm using ubuntu myself, been using debian for far too many years. ubuntu is delightfully nice
<seb128> sivang: no
<czr> sivang, also git seems to be also in breezy/universe, so I'll just install it from there
<sivang> czr: you seem to know what you're doing - rock on,  and I will make sure to forward your nice comments to those who deserve the nice feeedback :) 
<sivang> czr: you can also join #ubuntu-kernel, and find there a happy bunch that will welcome any contribution or bug reporting etc.
<czr> sivang, nice, thanks. I was playing with online resizing on ext3s on top of LVM2
<czr> sivang, the problem seems to be that ubuntu kernel does not support this (RHEL4 does)
<sivang> czr: ah I see, well if you think this should be included in the ubuntu tree I guess the ubuntu kernel development mailing list would be a good place to start discussing it, if you like.
<sivang> czr: why do you need it ontop of LVM2 ?
<sivang> (I mean, if you alrady have online resize without it)
<czr> sivang, so that I can resize LV underneath first and then ext2 on top of that online
<czr> ext2online doesn't work for me. says that 'kernel problem' or smt similar
<czr> but I haven't traced the root cause yet, so that's why I'm asking all these questions
<czr> RH only managed to get this working in the newer versions of RHEL4, was missing from there as well for a long time
<sivang> czr: well, try to ask over the #u-k , I think I reached the point where I can no longer help :)
<czr> will do/did that already :-) thanks for your help
<ajmitch> czr: unless you're using warty, I'd say the kernel does have online resizing capabilities
<czr> ajmitch, breezy with 2.6.12-10-386
<ajmitch> iirc they went into 2.6.10
<czr> LV resize works just nice, as it should
<czr> ext2online doesn't unless I umount the filesystem first, which is counter productive in this case
* ajmitch has used it in the past on an ext3 fs
<czr> ajmitch, with LVM or raw partitions?
<ajmitch> LVM
<czr> weird
<czr> ext2online: resizing to 524288 blocks; resize failed while in kernel; invalid argument
<czr> going from 1G to 2G (so there shouldn't be problem that requires running ext2prepare)
<ajmitch> fun
<czr> I'm running pretty vanilla rig too, nothing fancy
<czr> ajmitch, in your opinion it should work? should I post a bug about this then?
<sivang> czr: what package are the resize / ext3 tools in?
<ajmitch> ext2resize, in universe
<czr> yes
<sivang> ajmitch: ah I was sure we had soemthing in main, ok.
<lifeless> meh they should be main surely.
<lifeless> in terms of support, and doesn't the installer use em ?
<czr> universe/main :-)
* sivang had the same idea. Apparetnly thinking wrong.
<czr> lifeless, why should installer use them?
<czr> parted can do it when fs:es not mounted
<czr> hmm, can someone check the git version in dapper?
<czr> seems that the wiki-instructions don't work for the version in breezy/univ
<czr> oh heh. git = GNU Interactive Tools ;--)
<mdke> jdub, around?
<jdub> yeah
<mdke> jdub, heya :) do you know if planet supports filtering an rss feed with more than one category so as to display just a specific category?
<jdub> it's easier to just get a category feed
<jdub> most producers do that
<mdke> jdub, ok
<mdke> so it doesn't, but it doesn't need to?
<jdub> depending on what it produces, keyword filtering can work
<mdke> jdub, what's the config look like for that?
<jdub> filter = blah
<mdke> thanks :)
<mdke> jdub, next question: have you noticed an increase in spam through the mailing lists? a number of list owners (including myself) have noticed
<mdke> last week or so
<jdub> probably
<jdub> it moved hosts, so the config may not have been fully moved, or perhaps it was made less tough just in case
<mdke> that's what I was thinking might be the reason
<elmo> no, that's not the reason
<elmo> the exim config on esperanza is more strict than the one on rince
<elmo> there's been a global (AFAICT) increase in spam recently, it's far more likely to be that
<mdke> oh
<mdke> i just get a lot through from -owner and to the list
<jdub> elmo: was /etc/mailman copied or reconfigured?
<elmo> copied
<lifeless> elmo: yay
#ubuntu-devel 2005-12-17
<bmonty> elmo: please sync libapache-mod-auth-kerb from unstable, ok to drop ubuntu changes
<dholbach> good night guys, i'm off to bed
<mdke> night dholbach 
<daniels> night dholbach
<sivang_away> night dholbach 
<bmonty> elmo: please sync sam from unstable, ok to drop ubuntu changes
<bmonty> elmo: please sync sidplay-libs from unstable, ok to drop ubuntu changes
<bmonty> elmo: please sync beecrypt from unstable, ok to drop ubuntu changes
<bmonty> elmo: please sync buddy from unstable, ok to drop ubuntu changes
<xkahn> ARGH!
<xkahn> the cupsys package has some problems with directory ownership.
<xkahn> /etc/cups/interfaces and /var/run/cups/printcap are both root owned.
<xkahn> they should be owned by lp.lpadmin
<ajmitch> elmo: please sync vrms from sid, drop changes
<fabbione> morning
<ajmitch> hi fabbione 
<daniels> morning bella
<lathiat> ajmitch: haha
<ajmitch> lathiat: ?
<lathiat> vrms
<lathiat> :)
<ajmitch> ah right :)
<fabbione> hey dani
<fabbione> bah
<pitti> Good morning
<ajmitch> morning pitti 
<freelove> is ogra here?
<freelove> hi ogra:)
<freelove> is ogra here?
<Pygi> maybe yes, maybe not
<Pygi> hehe :)
<sivang_away> morning all
<Pygi> mornin
<Pygi> wb sivang
<sivang> hey Pygi , had some trouble with my freenode conneciton. Had to reconnect to make it work again
<Pygi> hehe :)
<rob1> jdub, are you around?
<Pygi> seems nobody is around ;)
<rob1> dam, I'm chasing the channel contact for #ubuntu, which is him
<pitti> Pygi: 'two people are not around -> all people are not around' is not a valid logical conclusion :)
<Pygi> logic is not logical :)
<sivang> hey pitti :)
<Pygi> and btw. the way you put it, it is logical ;) deduction or somethin'
<Pygi> on the behalf of few, conclusion on many
<pitti> Pygi: hm, I still need to learn the finer weirdnesses of English :)
<pitti> Hi sivang 
<Pygi> pitti: heh, me too ;)
<rob1> umm, does anyone else here have ops in #ubuntu?
<crimsun> what's the issue?
<rob1> some bans that are set
<crimsun> any particular ones?
<rob1> for eg. the *.tor.* ban
<janimo> crimsun, hey
<janimo> I have removed the two other xfcemotu members as they are not motus
<rob1> if your trying to stop tor users from accessing #ubuntu, use */tor/* instead, as your also stopping people from toronto from using the chan
<crimsun> janimo: hi, ok.
<janimo> and the group desc says active members
<janimo> I hope it's ok
<crimsun> janimo: sure
<rob1> freenode has a special agreement with tor, all users will have that cloak
<rob1> we are getting a lot of complaints about it
<rob1> in fact, the *.tor.* ban is now ineffective with the latest hyperion upgrade
<crimsun> fixed.
<rob1> thanks crimsun 
<rob1> also, *!*@*iam.net.ma
<rob1> and this takes out about a million ips: *!*@85.9*
<crimsun> the latter seems to host a lot of spambots
<crimsun> while I didn't set any of those, I'm not sure of a good way around that
<rob1> yeah, they were all done by Seveas 
<rob1> its the tor one I'm mainly concerned about
<rob1> next time I catch him on here I'll take it up with him, thanks for that crimsun 
<crimsun> np
<janimo> is there a TB meeting tomorrow? I don't see it on the fridge
<infinity> Any votes on whether or not I should temporarily roll back make to a version that makes CDBS work again?
<pitti> infinity: sounds like the easiest fix ATM?
<pitti> Hey dholbach 
<dholbach> hey pitti, hey everybody else! :)
<jsgotangco> hey dholbach 
<janimo> hey dholbach
<jsgotangco> :D
<dholbach> hey jerome, jani!
<infinity> pitti : Done.
<infinity> Yay, obscure version number.
<infinity> make_3.80+3.81.b3.3.80-1ubuntu1_source.changes
<siretart> hi
<Pygi> hi 
<ajmitch> hello siretart 
<Pygi> welcome sabdfl
<sabdfl> moin moin all
<ajmitch> hi
<viviersf> lo ajmitch 
<sabdfl> Riddell: help, my desktop wont update because of kde-guidance
<viviersf> and elo sabdfl 
<sabdfl> hey hey
<Pygi> sabdfl: any specific info you can give us? any errors when trying to update?
<infinity> Pygi : It's a known issue, no need to grill the man. :)
<lbm> sabdfl: you know "moin" is from the southern denmark? :)
<Pygi> infinity: kk :)
<viviersf> Riddell, is currently stil afk
<sabdfl> lbm: i have a peculiar fondness for denmark, and danes :-)
<infinity> sabdfl : Yet more stuff that still needs to be rebuilt for the c2a C++ transition, that's all.
<sabdfl> infinity: ok, looks like its down to a single package
<infinity> sabdfl : If Riddell doesn't show up and unbreak your desktop soon, I may do it.
<lbm> sabdfl: thanks, we like you too ;)
<infinity> sabdfl : Two packages.  kde-guidance and python2.4-kde3...
<viviersf> heh
<lbm> sabdfl: have you visited denmark?
<infinity> sabdfl : Well, some others still look a bit goofed too, but those two are causing YOUR issue. :)
<spacey> infinity, they also say it in parts of germany
<royce> i have an hp zv5000 laptop, using live ubuntu cd most of my hardware works great.  I only have issues with my internal wlan card, it a broadcom chip, any ideas, i've heard about ndis wrapping, but I really am a n00b
<spacey> especially the part close to denmark iirc :o) 
<Mithrandir> royce: it's documented on the wiki, and this is not a support channel, please ask in #ubuntu
<siretart> pitti: re ffmpeg: AFAIR they don't care about sonames, I think they rather recommend linking it statically, because they don't care that much about even API compatibility :(
<pitti> siretart: that's retarded
<lbm> spacey: they do :)
<siretart> pitti: and that a real problem with ffmpeg. marillat is introducing a 'cvs' package of ffmpeg, which he updates with every new mplayer/transcode upload to his archive
<siretart> pitti: I know :(
<Treenaks> pitti: the ffmpeg perl module depends on the ffmpeg SOURCE tree, instead of the headers, because of this
<Treenaks> pitti: (this is also why it isn't packaged)
<spacey> lbm, seen some german beer commercial in which they say it as well ;)
<pitti> siretart: ok, this fact alone makes it totally unsuitable for main :(
<lbm> spacey: it may be from germany, adopted by the close-german danes in the southern denmark :)
<spacey> :)
<siretart> pitti: sadly, but true
<ajmitch> pitti: changing f-spot to use libsqlite3-0 is easy, but preservation of the user data on upgrade isn't so simple - it'll be a little bit before I write up a main inclusion report for you :)
<pitti> ajmitch: I feel you pain, sorting out the libdbX.Y mess is similarly horrible...
<ajmitch> pitti: changing the source of f-spot was as simple as changing the connection string, but it refuses to start if there's an older photos.db now
<pitti> ajmitch: is there a conversion tool at all?
<ajmitch> just using sqlite dump
<ajmitch> which requires the older lib, etc to be installed
<pitti> ouch
<Kamion> ajmitch: scrollback on ext2/ext3 resize from last night: resize2fs is part of e2fsprogs and is thus in main
<Kamion> I'd generally advise using that instead of ext2resize as I think it's better-maintained
<ajmitch> yes, ext2online went quite awhile without any updates
<ajmitch> it worked for me, once, but I'm not brave enough to risk vital data to it
<nakeee> opss:)
<nakeee> is bug  #288948 from debian libc fixed on ubuntu?
<dholbach> Diziet: good morning. i built the new yelp (2.13.3), which complains about undefined symbol PR_GetPhysicalMemorySize in /usr/lib/mozilla-firefox/components/libdocshell.so (nm -D knows about it) - do you have an idea, where i might look for answers?
<dholbach> that should be 2.13.2
<infinity> (base)adconrad@cthulhu:/usr/lib/mozilla-firefox$ for i in *.so; do echo "$i:"; nm -D $i | grep PR_GetPhysicalMemorySize; done
<infinity> [...] 
<infinity> libnspr4.so:
<infinity> 000185ed T PR_GetPhysicalMemorySize
<infinity> So, you need libnspr4.so
<infinity> And, bets are it's linked to it, then resolving to the one in /usr/lib, which DOESN'T have that symbol defined.
<infinity> Then goes boom.
<dholbach> ok, i'll poke at it... thank you
<infinity> Diziet : When are we going to get libnspr4 shipped from firefox instead of mozilla?
<carlos> seb128, morning
<carlos> seb128, Are you aware of the problem with gnome's menu on dapper?
<dholbach> carlos: applications menu?
<carlos> dholbach, yes
<dholbach> carlos: that's a gamin issie
<carlos> it opens but 1 second later disappear
<dholbach> carlos: we received the bug report already
<carlos> ok
<jordi> doko: I wonder if you can join #launchpad for a min
<seb128> carlos: gam_server/inotify bog
<carlos> and the problem with applications being really slow?
<carlos> seems like I don't have 2D/3D acceleration at all
<carlos> this reminds me when I was using a framebuffer console when X server was missing my video card driver
<doko> jordi: ok
<fabbione> hey doko
<fabbione> doko: thanks for fixing bash...
<fabbione> did you see also the error at line 370 ?
<fabbione> doko: sh -n would do
<pitti> Riddell: ping
<infinity> \sh : Around?
<doko> fabbione: yes, yes, I did see it, too llate for the upload
<fabbione> doko: ok thanks :)
<infinity> \sh / Riddell : Whoever feels like taking ownership of it, the current python-kde3 is FTBFS, which is preventing it from making the C++ transition, which is pretenting kubuntu-desktop from being installable, which is preventing you from having LiveCDs built.
<Diziet> infinity: I ought to do that by the end of the week, I think.  If I miss that it'll have to wait until the new year.
<pitti> Keybuk: did you ever hear about /dev/fd not existing? it happened to seb128 last week, and at Friday it happened to me, too
<Keybuk> fd?
<Keybuk> floppy or video?
<Kamion> oh, this is nice. screw vga=771, the 1024x768 mode on this laptop is much nicer
<Kamion> /dev/fd is normally a symlink to /proc/self/fd, so neither ...
<pitti> Keybuk: /dev/fd -> /proc/self/fd
<pitti> Kamion: it breaks e. g. bash script which try somethign like "echo bla > &2"
* Kamion uploads bootloader shiny
<Keybuk> pitti: not existing when?
<Keybuk> (ie. do they not exist in the initramfs, in the real root, etc.)
<ogra> Keybuk, http://people.ubuntu.com/~ogra/edubuntu/dapper-20051211-1.png see when ldm starts on my lappie :)
<pitti> Keybuk: in the real system
<pitti> Keybuk: it's there now, it only seems to happen sometimes
<pitti> Keybuk: if you don't know that bug yet, I'll watch out for it
<Keybuk> pitti: that's screwy, that suggests that /etc/init.d/udev isn't run sometimes
<Riddell> pitti: hi
<seb128> Keybuk: I had the issue on my desktop friday, cups was not working we tracking it to /dev/fd not beeing present
<ogra> cups relies on /dev/fd ? 
<Keybuk> grab me next time it happens
<pitti> ogra: shell scripts do
<pitti> ogra: echo bla >&2, for example
<ogra> ah ... 
<Keybuk> those don't use /dev/fd unless the shell is *really* badly written
<Keybuk> usually it's just for things like <(echo foo)
<Keybuk> and those should already use /proc/self/fd (zsh, at least, uses this)
<pitti> Keybuk: maye it's from perl
<Keybuk> again, that shouldn't use /dev/fd
<pitti> Keybuk: I saw the error when installing postgresql-common
<pitti> hm, no idea
<pitti> it wasn't there
<pitti> then I created the symlink, and then the package installed fine
<Keybuk> /dev/fd is just for when you want to pass a file descriptor to something as a filename
<ogra> lamont, ping ? 
<Keybuk> for debugging next time it happens, it's copied over from /lib/udev/devices
<Keybuk> so if it doesn't exist, that sounds a lot like the udev init script didn't fun
<Keybuk> uh, run
<Keybuk> but if udevd is running, and you still don't have /dev/fd, the world is buggered :p
<pitti> Keybuk: hm, that means I shouldn't have had /dev/null either?
<Keybuk> you shouldn't have /dev/anything :p
<pitti> Keybuk: oh, I definively had :) my box was running all the day
<Keybuk> right
<Keybuk> so get me next time you don't have that link
<pitti> yep, will do
<Kamion> http://people.ubuntu.com/~cjwatson/gfxboot/20051212.png <-- new CD bootloader display, if anyone's interested
<Kamion> menu items won't be exactly as shown there
<hno73> Kamion: look cool :)
<hno73> looks even
<Keybuk> Kamion: I have an mp3 you could play while those dots go out :p
<pitti> wow
<Kamion> Keybuk: heh
<Kamion> it technically *is* capable of playing sound, but I'd rather avoid overstressing firmware bugs
<seb128> "foomatic-gswrapper: gs .... '-sOutputFile=/dev/fd/3' '/dev/fd/0' 3>&1 1>&2' from the cups log, which gives "ESP Ghostscript 815.01: **** Could not open the file /dev/fd/3 ."  (that's from friday)
<ogra> Kamion, WOW !
<Kamion> uses mod files
<lathiat> Kamion: nice
<pitti> Kamion: oh, btw, is it possible to add a menu point 'boot from hard disk'? that way you don't need to reboot again if you forgot to take the CD out
<lathiat> btw a really cool feature would be a simple 'restore boot laoder' inside the rescue stuff
<lathiat> pitti: thatd be cool too
<Kamion> pitti: yes, although which hard disk? :-)
<Kamion> lathiat: already done for yaboot; should be a simple matter of programming to do for grub now
<lathiat> Kamion: the winxp boot cd somehow kicks out to boot normally
<sabdfl> Kamion: very slick
<lathiat> maybe we can do that?
<pitti> Kamion: at least /dev/hda, but it would be ubercool to probe for all available ones :)
<Kamion> lathiat: it assumes first hard disk I think
<lathiat> hrm
<lathiat> well thats better than nothing
<Keybuk> http://www.netsplit.com/tmp/ITVon4_Clock_1993.rm
<lathiat> since that is often the case
<Kamion> but yeah, it's probably possible
<Mithrandir> you can just chain to bios 0x80
<Kamion> sabdfl: thanks
<Keybuk> ^ nearly everyone won't understand that link ... you have to be british and of the right age
<Kamion> Keybuk: haha
<Kamion> Keybuk: I was also thinking of the Countdown music ...
<Keybuk> that'd work too
<Kinnison> Keybuk: Oh my, that's really quite sniggerworthy
<Kamion> Mithrandir: which sometimes works ;-)
<Kamion> some fun grub bugs about that
<Keybuk> seb128: I'm not disputing whether or not you had that bug ... I just need to see a machine like that to know what's wrong
<Keybuk> seb128: for example, that same error could be caused not by udev not making a /dev/fd symlink but by the calling process closing too many file descriptors
<seb128> Keybuk: it was to point what uses /dev/fd instead of /proc/self/fd :)
<Kamion> pitti: OK, "boot from first hard disk" item added
<Kamion> BIOS 0x80, anything else you lose
<Kamion> pitti: I don't think I have a way to probe hard disks at that level yet
<pitti> Kamion: oh, wow, thanks :) (I didn't expect that to happen that quickly)
<pitti> Kamion: that should already cover a very large majority of the cases, I guess
<Kamion> yeah. it just got a lot easier fr me to do bootloader stuffbbCD 
<Kamion> (argh)
<Kamion> yeah. it just got a lot easier for me to do bootloader stuff
<Kamion> although gfxboot is in x86 assembly and porting it to powerpc would be highly non-trivial, so that's a sticking point
<Keybuk> doesn't the ppc have an x86 emulator in it somewhere to boot PCI cards? ;)
<Kamion> Keybuk: I didn't know that, but in any case I doubt user code can get anywhere near it. :)
<Keybuk> Kamion: well, you're still pretty close to the BIOS at that point
<Kamion> yaboot talks through Open Firmware, which is a fairly thick abstraction layer
<pitti> crimsun: just replied to your osh patch; I thought I already did it on friday, but I just pinged you in IRC, as it seems :/
<Kamion> pitti: would you care to review gfxboot and gfxboot-theme-ubuntu main inclusion for me?
<ogra> and if you're at it, gnome-screensaver would also be nice ... mdz wants it on flight2
<jbailey> https://wiki.ubuntu.com//TechnicalBoardAgenda says the next meeting is on 2005-11-29.  Should that say 2005-12-13?
<nakee> jbailey, any idea if bug #288948(debian number) in glibc is fixed in ubuntu's glibc?
<jbailey> nakee: It's a kernel bug, fixed in 2.6.14, IIRC.
<jbailey> Might have been 2.6.15, though.
<jbailey> nakee: So bleeding edge Dapper will solve your problem. =)
<nakee> jbailey, ok thanks. BTW if you look at the patch attached to the bug you'll see that it's a glibc bug as well  (some fields there are not checked right) but I gave up on glibc people a while ago as long as it stop bothering me:)
<jbailey> nakee: The glibc folks disagree.
<jbailey> nakee: Apparently trond didn't feel like pushing the point enough, so he tweaked the kernel to provide what glibc expects.
<nakee> jbailey, I can understand him, the bug/fix were reported almost 3 years ago if not more:)
<jbailey> True.  And for a while we had it patched in Debian glibc.
<jbailey> After looking at the patch and looking at the defined kernel interfaces, I agreed with drepper and didn't bother forward porting the patch from 2.3.2 to 2.3.5
<jbailey> By that time, trond already had a patch to make the kernel behave correctly.
<nakee> in debian, they merged the patch with some weird irix problem, and it didn't solve the problem we had
<nakee> jbailey, even if the stracture is a kernel issue the overflow caused IMOH is a glibc bug
<jbailey> It's been over a year since I looked at it.
<jbailey> Glibc's job is not to check for overflows and such.
<jbailey> If you hand it a bad value, it's job is to crash is strange and wonderful ways. =)
<sivang> hehe
* nakee sigh
<nakee> sivang, btw how is hebuntu going?
<nakee> sivang, or whatever other name it has now:)
<nakee> sivang, did you get the mozilla patchs working?
<infinity> Riddell : <poke>
<Riddell> infinity: hi
<infinity> Riddell : Pretty please, with sugar on top, make python-kde3 buildable again. :)
<infinity> (It's FTBFS in current dapper, which prevents it from transitioning)
<infinity> If you fix that, kde-guidance can be rebuilt, and kubuntu-desktop can be installed.
<infinity> And you get livecds!
<Riddell> infinity: \sh said he was waiting on a new upstream release which was happening weekend just past
<Riddell> \sh: what's the status?
<infinity> I hit upstream's webpage and saw no such release.
<\sh> Riddell: I'm working on it
<infinity> You may have to do a CVS/SVN/whatever pull yourself.
<infinity> \sh : Oh, yay.
<\sh> infinity: jim said there will be a snapshot soon
* infinity unpings you both, then.
<infinity> \sh : Flight-2 is happening "any hour/day now", so if you can get an interim snapshot that builds, you can get in on the action.
<\sh> infinity: and if there is not a one in the middle of the week, i'm taking the actual release and fix it...well it won't give you any 3.5 stuff
<\sh> infinity: k...give me this night :)
<\sh> i catched a stupid cold
<sivang> \sh: you too?
<infinity> I'm off to bed.  If I see that you uploaded python-kde3 while I was asleep, I'll clean up after it and make sure kubuntu-desktop works.
<\sh> throat pain and fever...typical stuff
<infinity> Cheers, guys.
<\sh> infinity: rock thx :)
<sivang> \sh: yeah, me too - bad.
<janimo> Riddell, ping
<janimo> is system-tools-backend going to be used in kubuntu?
<\sh> preparing a new pyqt 3.15.1 upload...grrr
<janimo> and another: ivman is still a dep of kubuntu-desktop is it still used by kde?
<\sh> did anybody fix cdbs and this install target problem?
<infinity> \sh : I rolled back make, so yes, it's fixed.
<infinity> \sh : Well, "fixed".
<Riddell> janimo: we don't use system-tools-backend, knetworkconf includes its own copy of the network backend
<\sh> infinity: cool :)
<infinity> \sh : The real fix will happen later, but it will work fine for you on an up-to-date system (and the buildds are all up to date)
<Riddell> janimo: oh aye, seeds were giving me bother, I'll remove that now
<\sh> infinity: i just updated my pbuilder
<janimo> Riddell, us s-t-b a moving target or why was it chosen to copy instead of linking to it?
<Riddell> janimo: I suspect when knetworkconf started there was no separate system-tools-backend package from upstream
<Riddell> I should talk to the author about that
<janimo> ok, thanks
<doko> pitti: adding /etc/xpdf/xpdfrc to popple-utils would mean a conflict to xpdf?
<pitti> doko: depends
<pitti> doko: poppler-utils already conflicts to xpdf-utils
<pitti> so if xpdf-utils ships that conffile, then we would already have the conflict
<pitti> if it's shipped by -common, though...
<pitti> doko: would that conffile actually make sense for poppler-utils?
<pitti> i. e. does it actually use it?
<doko> I don't know, didn't look
<pitti> doko: if p-u doesn't use the conffile, then I'd just remove the symlink from cups
<doko> pitti: I would have to grep the sources ;-)
<tseng> pitti: have you looked at avahi for main inclusion?
<tseng> pitti: sorry no rush, just curious
<pitti> tseng: hrm, still busy with security updates
<tseng> pitti: id rather have those :) thanks.
<carlos> vuntz, hi, are you around?
<vuntz> hi carlos
<ogra> hey lamont__ 
<ogra> any news about edubuntu-live ? 
<\sh> Riddell: first package up...sip4 4.3.2
<Riddell> \sh: you rock :)
<\sh> well..now for a new version of pyqt3
<Gagatan> regarding pyqt.. any news about pyqt4 yet?
<Gagatan> from a developer/user point of view.. not maintainer
<\sh> Gagatan: that is pyqt-ml...not ubuntu-devel :)
<Gagatan> \sh: was afraid you'd say so.. ;) it was worth a shot ;)
<\sh> Gagatan: but thinking about an crippeled pykde implementation (not ready for 3.5) I don't wanna think about pyqt4
<\sh> Gagatan: so it makes me cry
* Gagatan gives \sh a papertowel
<\sh> *sniff* thanks
<ogra> Gagatan, you really want him to get a sore nose ? 
<\sh> ogra: i already have one....
* ogra gives \sh a handkerchief instead
<ogra> (a real soft one) :)
<Gagatan> ogra: its with moisturiser and stuff :)
<ogra> lol
<Gagatan> or however its spelled 
<\sh> ogra: well...thinking about my cold...and you are caring about suse :) I should come to you..I need someone who takes care about me as well :)
<ogra> argh ...
<\sh> *cough* 
<ogra> i already am near the edge of my capacity ...
<zakame> ogra: awww
<ogra> 4h sleep max ...
<ogra> then i have to rush and cook tea for her, get the pills etc ...
* mvo waves to \sh 
<\sh> ogra: well for me only a grog
<ogra> but it seems to get better 
<\sh> hey mvo 
<\sh> mvo: I had to postpone the call to hartmut...my voice is a bit croaky
<mvo> \sh: no problem
<\sh> i'm wondering where my upload is...
<ogra> gone to unstable ? 
<\sh> no
<\sh> woooow
<\sh> you actually don't know who send me an email
<ogra> tell us
<jsgotangco> hello
<lamont__> ogra: edubuntu livecd fs images have been building just fine since the 2nd run on dec 9
<ogra> oh cool !!!
<lamont__> ==> new target
<ogra> lamont__, thanks a big lot ...
* lamont__ tosses the potato to Kamion
<Mithrandir> they don't work, partly due to a kernel bug.
<Mithrandir> I have spent some time investigating it today, there's a certain amount of insanity needed to fix it.
<lamont__> Mithrandir: "they"?
<Seveas> there's insanity enough in here :)
<Mithrandir> lamont__: they as in "the live cds"
<lamont__> edubuntu, or everything?
<Mithrandir> lamont__: everything.  The kernel's busted wrt cloop images and devmapper snapshots.
<Mithrandir> lamont__: benc has a fix in the pipeline/to be uploaded, though.
<\sh> Riddell: python-qt3 3.15.1 will hit katie soon
* Riddell does the python-qt3 dance
<lamont__> seb128: .libs/gatomic.o: In function `IA__g_atomic_int_exchange_and_add':/build/buildd/glib2.0-2.9.1/build-tree/glib-2.9.1-deb/glib/gatomic.c:417: undefined reference to `__sync_fetch_and_add'
<lamont__> what's that mean?  (ia64)
* lamont__ asks seb128 because he owns the letter 'g'
<\sh> mvo: btw...debtags raises errors...
<seb128> lamont__: that ia64 sucks maybe? :p
<lamont__> seb128: it sucks, but not that way.
<seb128> lamont__: I don't really have an idea on this issue in fact :)
<lamont__> seb128: I kinda figured it was arch-specific code that was just missing for ia64
<lamont__> I'll play with it sometime soonish
<lamont__> glib2.0 and vbetool seem to be all that's breaking ubuntu-desktop installability on ia64 atm
<silbs> jsgotangco: ping
<jsgotangco> silbs: hi there
<mvo> \sh: should be fixed with the upload from today
<\sh> mvo: k
<\sh> and I found a really serious bug in python-qt3
<\sh> but I hope I will fix it now
<seb128> lamont__: what version of gcc do you have on ia64? current archive one?
<\sh> brb
<seb128> lamont__: 
<seb128> <mclasen> seb128: could also be a glibc version issue, I guess. I don't actually know where these __sync... functions live
<seb128> <mclasen> seb128: the patch to change __sync_..._si to __sync_... came from suse
<seb128> lamont__: http://bugzilla.gnome.org/show_bug.cgi?id=321229
<seb128> lamont__: I guess the issue is this patch: http://bugzilla.gnome.org/attachment.cgi?id=54637&action=view
<Kamion> ogra: as Mithrandir says ... but I'll turn Edubuntu live on once that's all fixed
<ogra> great 
<ogra> i'm eager to see it :)
<mdz> ogra: your latest ldm branch seems to include an unrelated change adding 'quiet splash' to the pxelinux config
<ogra> is that bad ? since we wanted to enable it anyway 
<mdz> ogra: I have no problem with the change, but it's confusing to mix it with the ldm changes, and splash won't have an effect until usplash is installed
<ogra> yes, it would belong into the fixes branch, but i had no such branch at that time ...
<Kamion> pitti: did you see my note about gfxboot and gfxboot-theme-ubuntu? sorry to rush, but I'd like to get it in for Flight 2 (now just blocked by kernel and casper) if possible for widespread testing
<ogra> and found cosmetiacl stuff would fit in there
<pitti> Kamion: I saw the wiki diff, yes
<ogra> mdz, i wont do it again, that what the fixes branch is for now ...
<jsgotangco> mdke: hello
<mdke> hi jerome :)
<\sh> jesus fixed
<ogra> mdz, also most of peres fixes have no effect at all with our xorg ...
<ogra> the preseeding just doesnt get accepted
<\sh> I wonder why nobody including me saw that python2.4-qt3-gl was missing 
<pitti> Kamion: just promote it now, and I process the report formally tomorrow; it does not have any security history, and if you are fine with the packaging etc., then it's certainly ok
<mdz> ogra: merged
<ogra> YAY !
* ogra dances 
<pitti> Kamion: I'll try to do it today, but I'm not sure whether I'll manage that
<Kamion> pitti: ok, I just didn't want to make that decision myself since as author of the latter I wasn't qualified
<Kamion> thanks
<mdke> mdz, got 2 minutes to discuss the ubuntu-docs possible update? some problems with it...
<Kamion> but yes, I think security issues are rather implausible by nature
<pitti> Kamion: erm, I'd rather say as author of that package you are :)
<mdz> ogra: I don't have time to test it; I'm uploading 0.61
<mdz> ogra: if you need to make uploads while I'm away, please create a dapper branch
<Kamion> pitti: perhaps "disqualified" is a better word
<ogra> mdz, fine, will test and report back ...
<pitti> Kamion: right, there is hardly some user input, and at the boot level there is not much room for exploits
<ogra> mdz, will do
<mdz> mdke: ok, go ahead
<pitti> Kamion: or, rather, many possibilities to avoid exploits
<Kamion> hm, possibly gfxboot-theme-ubuntu should be Architecture: amd64, i386
<mdke> mdz, cool. It works good afaics, but the introduction of a number of new translations has meant that the debdiff is absolutely enormous. This is partly because a lot of part-done translations are included, with both translated and english text...
<pitti> Kamion: it isn't arch:all?
<Kamion> pitti: it is at the moment, but it depends on gfxboot which is only available on amd64/i386, so I create an uninstallable on powerpc the way it is now
<Kamion> I'll fix that
<mdz> mdke: I understand
<mdz> Kamion: will you still be able to release flight 2 this week given thurs/fri?
<mdke> mdz, to keep the debdiff manageable it might be possible to include just "common" or completed translations, but at the same time it might be a shame that others efforts don't go in.. any ideas?
<Kamion> mdz: I sincerely hope and believe that it will be long past come Thursday
<Kamion> the kernel upload will happen in a few hours, I'm told
<hunger_> yahoo, with the latest usplash update my system boots again:-)
<Kamion> then it should be straightforward to fix casper (I think Mithrandir has this mostly done)
<Kamion> Mithrandir: if we kick stuff through quickly this evening with the new kernel, will you be able to sync down a live CD for casper testing/upload?
<Mithrandir> Kamion: as in, tonight or tomorrow?
<Mithrandir> (UTC)
<Kamion> Mithrandir: tonight
<Mithrandir> yes, I could do that.
<Kamion> thanks
<jsgotangco> good night
<ogra> night jsgotangco 
<ogra> mdz, you didnt merge http://people.ubuntu.com/~ogra/bzr-archive/ltsp/fixes/ ?
<ogra> (its a one line change that unbreaks the edubuntu CD)
<mdz> ogra: I only read the subject of your mail
<ogra> ah...
<mdz> ogra: will have a look now
<ogra> the default distro is still breezy in ltsp-build-client ... doesnt work if you run it from CD :)
<mdz> ogra: merged, uploaded, pushed
<ogra> thanks :)
<ogra> i wont bother you anymore then :)
<mdz> and permissions fixed on rookery as a bonus
<ogra> heh
<ogra> what was wrong there ? 
<mdz> ogra: https://launchpad.net/products/bzr/+bug/4800
<ogra> ah
<ogra> i dont use james bond premissions locally, thats why i never noticed ;)
<mdke> mdz, so what do you think about this update?
<mdz> mdke: it sounds OK, though I would like to see the diff
<mdke> mdz, of course, i just wanted to make sure you were prepared to read it... it's 8.5MB long...
<mdke> mdz, if you are, when its finalised I'll ping you. If not, we can work something else out
<mdz> mdke: I'll sort it out
<mdke> great
<mdke> mdz, thanks!
<mdz> mdke: has it already been  built on breezy and tested on breezy?
<mdz> mdke: was it tested in multiple locales_?
<mdke> mdz, yes. I tested in my locale and in IT, i'll do a few more later
<mdke> need to test "ast" ;)
<\sh> hmm..when I'm introducing a new binary package build from source...does elmo have to NEW it? 
<mdke> the language selector on breezy is only showing my installed locales, and doesn't give me a list of new languages I can add... anyone reproducing?
<ogra> \sh, yup
<mdke> nm
<\sh> ogra: thx
<seb128> pitti: hum, cups eats 100% of CPU looping on "write(1, ptrace: umoven: Input/output error 0x7c514d6, 4498984)            = -1 ENOSPC (No space left on device)" if /var is used at 100%
<mvo> mdke: is you package list up-to-date?
<mvo> mdke: usually a apt-get update fixes it
<mdke> mvo, yeah it's fixed, sorry :(
<mvo> mdke: no worries
<\sh> elmo: please sync glabels , jabberoo , istanbul from unstable, dropping ubuntu changes, thx
<\sh> elmo: and please move python2.4-qt3-gl from NEW (it was missing from the former sources and it's important for flight-2) thx again
<\sh> infinity: python-kde3 just builds...will upload it in a few
<\sh> bbl...
<pitti> lamont: do you know why curl_7.12.3-2ubuntu3.4_source.changes (hoary-security) doesn't build?
* lamont__ looks
<lamont__> Built successfully
<lamont__> Rejected: libcurl2-dev_7.11.2-12ubuntu3.2_ia64.deb: old version
<lamont__> +(1:7.11.2-12ubuntu3.2) in hoary-security >= new version (1:7.11.2-12ubuntu3.2)
<lamont__> +targeted at hoary-security.
<lamont__> note that the version of libcurl2 is hardcoded in debian/rules.  kthxbye
<lamont__> must be manually bumped
<pitti> lamont__: argh, I bet that's it
<pitti> lamont__: thanks
<pitti> that's soo retarted...
<eruin> looks like there's something wrong with http://archive.ubuntu.com/ubuntu/dists/dapper/main/source/Sources.gz - gzip exits with errors according to apt
<ogra> works here
<eruin> lovely.
<mdke> does anyone have any idea why the default homepage on firefox might be a different address depending on which language the user selects when logging in?
<Hieronymus> mdke: yes
<ogra> mdke, thats a change from  breezy afaik
<mdke> what's going on?
<ogra> mdke, there is a wikipage anywhere describing it
<mdke> ogra, yeah but not describing what I'm seeing...
<ogra> hmm
<mdke> english and french have the about ubuntu page. italian has google start
<mdke> maybe something in the firefox localised package?
<mdke> ogra, what is german?
<mdke> brb, trying a couple more languages
<ogra> mdke, hmm, i switched it to about blank ... 
<ogra> but i think i remember it was the mozilla page 
<ogra> mdke, if i remove about:blank its the ubuntu page as well
<siretart> pitti: apropos retarted stuff: I just had another look at ffmpeg. ffmpeg in debian/main ist a static lib only. Marillat therefore has 'cvs' versions of ffmpeg, which DO introduce a proper soname
<mdke> ogra, yeah it works on all languages I've tried, except italian, weird :)
<mdke> gnome fonts are screwed in czech too ;)
* ogra reboots to test new ldm
<mdke> mdz, ok the package is tested on german, czech, english, italian and french with a new user on Breezy and works fine (subject to an unrelated bug with Italian firefox having the wrong homepage). Uber-debdiff is at http://doc.ubuntu.com/debs/breezy-updates . Let me know if you need anything else, i'll be online later.
<crispin_> Keybuk: ping ?
<Keybuk> crimsun: yup?
<crispin> I'm the reporter of that 'unbootable system' bug, and have my machine back in its unbootable state
<Keybuk> *nods*
<Keybuk> give me five minutes, just dealing with something else, and I can give you my full attention
<crispin> ok
<Keybuk> can you get that machine to the point it's sitting at "ALERT! The sky fell on my head!" or whatever it said
<Keybuk> and then join #ubuntu-boot
<crispin> yep, will do
<BenC> Keybuk: hey!
<BenC> Keybuk: is there a problem with us having ide-core built-in?
<ogra> mdz, ldm works fine ...
<mdz> good
* ogra tries new usplash on thin client ...
<pitti> lamont: are you still responsible for building livefs images?
<pitti> mdz sent me a log with a failing cupsys-driver-gimpprint, but it works fine for me
* mvo goes for hockey
<dholbach> mvo: have fun
<lamont__> pitti: I build em, yes
<lamont__> but I need more detail on what you're asking...
<pitti> lamont__: do you still get that error?
<pitti> lamont__: cupsys-driver-gimpprint was uninstallable on that log (failed on configure)
<lamont__> architecture, which livefs, build error or runtime? etc
<pitti> lamont__: i386, terranova, Thu,  8 Dec 2005
<pitti> lamont__: build time
<lamont__> ubuntu?
<lamont__> vs {k,ed}ubuntu?
<pitti> yes
<mdz> mdke: ok, looks good, ping me or Kamion for final approval once it's uploaded
<ogra> mdz, btw, latest bootchart from my laptop s client: http://people.ubuntu.com/~ogra/edubuntu/student-control-panel_shot.png
<ogra> oops, wrong paste
<ogra> mdz, http://people.ubuntu.com/~ogra/edubuntu/dapper-20051211-1.png
<ogra> look when ldm starts :)
<mdz> ogra: that looks very strange
<mdz> why does that chvt run forever?
<ogra> what? booting in 20seconds ? 
<mdz> that chart should end at about 25 seconds
<mdz> but instead it's 1:34
<ogra> bootchart is very slow ... no idea it takes about 2 minutes on the thin client to get the login, but the chart stops earlier there
<ogra> (console login that is)
<ogra> mdz, i rather think its a problem with bootchart than chvt
<mdz> ogra: it doesn't look that way to me
<ogra> hmm
<mdz> bootchart is clearly still sampling during that time
<mdz> you can see the changes in Xorg
<ogra> right ...
<ogra> i'll investigate ... but the booting is incredible fast on this laptop ...
<Keybuk> bootchart is stopped by the zzz-bootchart-stop script
<ogra> yes
<mdz> Mithrandir: feel free to make uploads to dapper from your casper branch while I'm away; just be sure to sort out the bzr situation so that I can merge when I return
<Keybuk> that's not being run ... because that chvt is running
<Keybuk> you can see the slight space that it's own parent script is run at the end
<Mithrandir> mdz: sure.  Worst-case, I'll just replay the revisions.
<Mithrandir> mdz: I'd like to let Kamion release flight 2 first.
<Kamion> (doing install CD testing with gfxboot nowish)
<mdz> Mithrandir: agreed
<ogra> so its a prob with console-screen ? hmmm
<Mithrandir> Kamion: rock, that'll unblock a couple of things for me. :-)
<Kamion> although of course I need to switch to the new kernel anyhow, but I want to catch any other trailing stuff
<Kamion> I have a nagging feeling that I've forgotten one piece of the gfxboot deployment work, but never mind ...
<tseng> Kamion: do i need to do anything to test beyond installing the packages?
<ogra> infinity, the new usplash leaves the d of failed on the screen, the status (ok/failed) is to far to the right it seems
<Kamion> tseng: for what?
<tseng> Kamion: gfxboot
<Kamion> tseng: our gfxboot stuff only supports syslinux at the moment, so it's only useful for install CDs right now
<Kamion> (and live CDs)
* tseng ohs
<Kamion> there's not much point installing it on a normal system unless you want to grab the grub patches from SuSE and try those out
<Kamion> I'm very strongly inclined to avoid those for dapper, though
<ogra> mdz, i guess chvt hangs in the unicode_start/stop calls, there is no locale set in the thin client env ...
<Kamion> I suspect gfxboot-theme-ubuntu doesn't fully handle the normal-boot/non-syslinux case anyway
<mdz> I see no reason why a lack of locale would cause it to hang
<Kamion> chvt surely doesn't call unicode_{start,stop} itself anyway
<ogra> because console-screen.sh tries to set UTF-8 locales ? 
<Kamion> it just changes the vt
<mdz> ogra: strace would probably be enlightening
<ogra> yup
<Mithrandir> Keybuk: gnrr, udevinfo -q name -p /block/cloop0 claims it doesn't know anything about that device. :-/
<Keybuk> heh
<Keybuk> probably doesn't
<Keybuk> udev isn't a device database
<Mithrandir> Keybuk: did in breezy.
<Keybuk> yeah, udev change upstream
<Keybuk> the db only contains information on things there are rules for
<Mithrandir> hmkay.
<Mithrandir> so.. just look for /dev/cloop0, then?
<Keybuk> yeah, if udev doesn't know about it, look for the name you expected
<Keybuk> BenC: could you come back into #ubuntu-boot please
<ogra> oh, cht isnt from console-screen ....
<ogra> *chvt
<mdz> nope
<Kamion> oh, I forgot splash.pcx, I knew there was something
<mdke> mdz, thanks. I'd upload it now, if I knew how :D
<Kamion> yay for YA splash image format
* ogra makes a astonished face seeing the head of /etc/init.d/usplash
<ogra> so does DCC support usplash ?  *grin*
<seb128> elmo: please sync gtk+2.0 from Debian incoming
* tseng points ogra at "skeleton"
<tseng> ogra: look at some more init.d headers
<mdz> sabdfl,mjg59,Keybuk: don't forget about TB tomorrow; I won't be there
<ogra> tseng, ah, thanks :)
<ogra> tseng, i thought it referred to the usplash script :)
<Keybuk> mdz: would you like me to drive in your place?
<mjg59> mdz: Ok
<mdz> Keybuk: yes
<mdke> Diziet, do you know if https://wiki.ubuntu.com/BreezyFirefoxStartPageTranslation is working?
<ogra> hmm, putting strace in the uspalsh script in front of the chvt seems not to work ...
<ogra> but running it manually produces a strace that complains about missing locales
<\sh> damn..pykde still compiling
<mjg59> seb128: What do I need to do to make sure an icon-theme.cache gets updated when I install new icons?
<mjg59> Just gtk-update-icon-cache in the postinst?
<seb128> mjg59: we don't use the icon cache out of some themes because the implementation is a crapy one
<mjg59> seb128: Currently, the situation is that I install new icons and my package can't find them
<seb128> you have to update the mtime of the directory every time a package install an icon
<seb128> or the cache masks silently the icon
<seb128> which make apps crash and other funny stuff
<mjg59> And how should that be done?
<mdke> Diziet, if it is, it struck me that it would rock pretty hard to actually ship some translated html
<seb128> patch every single package existing to update the mtime
<seb128> or don't make an icon cache
<seb128> we picked the second one, we don't make an icon cache for hicolor
<seb128> if you have one the easiest way is probably to rm the file
<mjg59> seb128: Same in Debian?
<mjg59> I'm just wondering where I got this one from now
<seb128> yep
<mjg59> Ok
<ogra> mdz, seems it was a bug in the old usplash package, it doesnt happen with the upgraded one 
<ogra> http://people.ubuntu.com/~ogra/edubuntu/dapper-20051212-1.png
<ogra> mdz, ^^
<mdz> Mithrandir: what is the purpose of findcommandinroot in your casper-reconfigure?
<mdz> Mithrandir: does the chroot(1) in initramfs not search $PATH?
<ogra> compared to http://people.ubuntu.com/~ogra/edubuntu/dapper-20051211-1.png
<mdz> ogra: what was the bug?
<Mithrandir> mdz: no, it doesn't search path
<mdz> Mithrandir: I'd be inclined to treat that as a bug, since it should be trivial to fix in busybox/klibc/whatever
<ogra> mdz, no idea, but the bootchart was from yesterday, i had the old usplash ... it doesnt happen at all with the new one ... do you want me to roll back to the old package ? 
<Mithrandir> mdz: sure, that'd be nice.
<Kamion> Mithrandir: that's really odd, because busybox chroot uses execvp()
<mdz> Kamion: klibc includes a chroot command, too
<Kamion> ... which uses execve()
<Mithrandir> yeah, it might be the klibc chroot command I'm calling.
<Kamion> there we go, smoking gun
<Kamion> we should just use the busybox one
<Mithrandir> if we fix that, I'd be very happy
<Kamion> (since klibc is probably going away anyway)
<mjg59> mdz: Did you have any joy in finding the patch that broke suspend?
<mdz> ogra: it could just as easily be a race or something; I know of no such bug being fixed in usplash, there is nothing which looks relevant in changelog, and it would be very odd in the first place for usplash to cause chvt to hang somehow
<Kamion> Mithrandir: chroot is disabled in the busybox initramfs config; shall I enable it?
<ogra> mdz, i'll keep an eye on it, but with five boots i did now it didnt happen
<mdz> mjg59: none whatsoever; I got as far as a git checkout by week's end
<mjg59> mdz: Ok
<Mithrandir> Kamion: please do
<mjg59> mdz: I don't have time to track that down now, I'm afraid
<mdz> Kamion: klibc is going away entirely, or just from our initramfs?
<mjg59> But there's been another bug filed (another Thinkpad user, no idea if it's linked)
<mdz> mjg59: me either; I leave town tomorrow
<Mithrandir> mdz: http://err.no/tmp/dapper-20051212-1.png
<mdz> Mithrandir: that's the existing livecd, right?
<Mithrandir> bootchart from simplifiedlivecd
<mdz> oh, interesting
<mdz> do you have a standard livecd bootchart from the same machine for comparison?
<mdz> 40 seconds for adduser seems way excessive
<Mithrandir> loading perl takes a while
<Mithrandir> as well as libc6, etc, etc.
<Mithrandir> I'll get you a chart, wait a little
<mjg59> Mithrandir: Hmm. X is starting after 155 seconds?
<mdz> init.d/hplip calls dpkg-statoverride? freakish
<Mithrandir> mjg59: sounds about right.
<Mithrandir> mdz: yes, it's crack
<Mithrandir> mdz: note that I got distracted by IRC and such so the boot chart is a bit longer than it should be.
<Mithrandir> but since there's no interactivity, it doesn't really matter
<Kamion> Mithrandir: oh, hmm, you would have to use 'busybox chroot' explicitly though; we don't ship the symlinks
<Mithrandir> Kamion: more or less anything to get rid of the evil hacks I've added so far
<Kamion> mdz: from our initramfs, as I understand it; we currently often/always (?) include glibc for things like raid/lvm that haven't been ported to klibc yet, and Scott/Jeff seemed to be leaning towards "oh, let's just use glibc"
<ogra> hmm, that might be odd for thin client memory usage
<Keybuk> right
<Keybuk> porting to klibc is annoyingly hard for not-a-huge benefit
<Keybuk> if every app in there was klibc, it would be a benefit
<Keybuk> but as soon as one isn't, it's actually a deficit
* ogra sees the target of 32MB clients dissapear at the horizon
<Kamion> oh god, I so want to kill base-config
<Kamion> Mithrandir: done
<Mithrandir> Kamion: \o/
<mdz> Kamion: meaning "let's just use coreutils/util-linux/etc."?
<mdz> Kamion: or "let's just use busybox linked with glibc"?
<Kamion> mdz: I don't think it matters much, although busybox would keep the initramfs size down
<Kamion> the cost of klibc is AIUI much higher than the cost of busybox right now
<mdz> really?
<Kamion> we could continue to use klibc-utils built against glibc
<Kamion> cost as in amount of work we have to do to support it
<mdz> klibc is like 250k, lib + utils
<Kamion> not as in space
<mdz> oh, the PITA cost
<Kamion> meh, broken locale configuration in today's installer, I guess that isn't surprising
<Mithrandir> mdz: http://err.no/tmp/dapper-classic-livecd.png is the classic livecd.
<Mithrandir> mdz: note that the kernel versions are not the same here
<Mithrandir> (the header of the last of them lies)
<Kamion> I think I'm going to have to install a language pack as part of the base system
<robtaylor> Kamion: I guess ulibc isn't a win here?
<mdz> Mithrandir: what causes it to lie?
<Mithrandir> mdz: that I didn't have a header file from the run, so I just stuck the one from the previous boot on top of it. :-P
<Mithrandir> so, not a bug, just me being lazy.
<Kamion> robtaylor: I imagine it has pretty much the same detriments as klibc, i.e. more work for no gain unless you convert everything
<Kamion> robtaylor: there's nothing wrong with klibc itself, it's just worthless unless you convert everything to use it
<Mithrandir> mdz: note that my machine has 2GB of ram, so anything read in generally won't be thrown out again.
<robtaylor> Kamion: well last i saw it was pretty near to a drop in replacement apart from really obscure stuff
<Kamion> and that either involves multiple build passes or else multiple libcs running on the real system
<robtaylor> Kamion: like on scratchbox, you can actually make a debian distro against ulibc
<Kamion> the former risks introducing subtle bugs, and the latter just sucks
<Kamion> robtaylor: er, sure, but we're not building the whole of Ubuntu against uclibc
<robtaylor> Kamion: thats true
<jbailey> Kamion: I'm lagging quite a lot since I'm on a phone call, but part of the idea has been that busybox ought to be able to be removed for the initramfs.
<robtaylor> Kamion: heh, i know,just using that as an example of its completeness, but you're right, its not a win here as space isn't the primary concern and you end up with having multiple build passes..
<Mithrandir> mdz: hmm, when looking at the second graph, it's just until the pivot_root.. :-/  I thought I had a full one.
<mdz> Mithrandir: was the classic boot using a kernel with IDE_DMA_ONLYDISK?
<Mithrandir> mdz: it's a bit since, so I'm not sure, but we'll be able to measure it once we get the live cd working again.  The measuring code is in the live cd already.
<Mithrandir> mdz: but you can look at the graph and see that rcS starts at approximately 69s, while it's 91s+ for the old cd.
<mdz> Mithrandir: yes, very encouraging
<ogra> robtaylor, for me with ltsp space is a huge issue ...
<mdz> Mithrandir: the DMA change happened in 2.6.15-1.1, so if it was any 2.6.15 kernel, it had that change
<mdz> BenC: (^^ thanks for expanding the changelog)
<Mithrandir> -rwx------  1 tfheen tfheen  504168 2005-11-21 13:14 proc_diskstats.log*
<robtaylor> ogra: hmm, well, it'd be less of a pita than using klibc, i think, but added installation complexity and more chance of f*kups, it seems.. *shrug*
<Mithrandir> that's pre .15 or not?
<Kamion> Keybuk: is there a good way to get vesafb loaded on boot if you boot with vga=<number>?
<Mithrandir> Kamion: I think usplash already does that.
<Kamion> and probably fbcon, I guess; we use this logic in a few places at the moment:
<Kamion>                                 (modprobe -q vesafb >/dev/null 2>&1 && grep -q . /proc/fb && modprobe -q fbcon >/dev/null 2>&1) || (modprobe -q vga16fb >/dev/null 2>&1 && grep -q . /proc/fb && modprobe -q fbcon >/dev/null 2>&1)
<Kamion> oh, hmm, maybe usplash is broken then
<BenC> mdz: no problem :)
<Kamion> 'cos this installation here gets no framebuffer
<ogra> robtaylor, my target for dapper was to fit on 32MB thin clients ... if my initramfs is already several 10 MB big i wont even get near that
<mdz> Mithrandir:  -- Ben Collins <bcollins@ubuntu.com>  Sat, 12 Nov 2005 23:34:38 -0500
<robtaylor> ogra: ah, in that case you really do need to start thinking about using ulibc, i'd say
<Kamion> oh, usplash isn't installed
<mdz> Mithrandir: in which case, the difference relative to Breezy is probably even greater (assuming DMA gets enabled on your hardware)
<Mithrandir> haha
<ogra> robtaylor, yes, but then we are in the same situation as with klibc and could even keep it
<Mithrandir> mdz: it's a fairly new amd64 rig, so I would expect it is.
<robtaylor> ogra: same situation in what sense?
<Mithrandir> mdz: might very well have the change in, then.  I've promised Colin to see if I can get him a working live cd tonight, so if so, I'll whip up a few bootcharts as well.
<ogra> robtaylor, linking against another libc than the default ...
<mdz> Mithrandir: was that a daily CD or one you built?
<robtaylor> ogra: ah yes indeed. but at least you dont have to do the porting work
<Kamion> damnit, not going to get to karate tonight :(
* Kamion fixes base-installer to install usplash
<Mithrandir> mdz: one I built.
<mdz> Mithrandir: we didn't switch the default kernel until 30 November
<mdz> or thereabouts
<Mithrandir> mdz: probably old kernel, then.
<Mithrandir> mdz: anyway, we'll see if there's a big difference once we have flight 2.  Not much use speculating.
<mdz> yep
<ogra> mdz, any opinion about the libc stuff for ltsp ? i really fear my low memory target ...
<mdz> ogra: what libc stuff?
<mdz> ogra: for initramfs?
<ogra> if we get rid of klibc
<ogra> yes
<mdz> getting rid of klibc won't change the size of the initramfs significantly
<ogra> doesnt it need glibc then ? 
<mdz> it already has glibc
<ogra> oh...
<ogra> i thought klibc replaced it in initramfs
<Kamion> and the initramfs is only 5.6MB with both klibc and glibc
<Kamion> so stop panicking :)
<ogra> ooook
<mdz> ogra: zcat /var/lib/tftpboot/ltsp/initrd.img | cpio -tv | grep libc
<ogra> oh,ah ok
<mdz> if your thin client doesn't have enough memory to hold a 10M initramfs plus the kernel, I don't think it would finish booting either
<Kamion> (ok, 13MB uncompressed)
<ogra> yes, but i feare we'd raise the limit ...
<ogra> *feared
<ogra> but dropping klibc will even gain some bytes, so yay :)
<mdz> kilobytes
<ajmitch> morning
<Kamion> can people try booting the current daily install CD? it won't install very well, so don't bother running all the way through, but I'd like to know if the boot screen looks right
<ogra> i cant burn it :(
<ogra> cd writing is broken in dapper 
<Kamion> I've already tested in qemu, so no point trying that :)
<mjg59> Hm.
<Kamion> it is? I'm burning it from dapper right now
<mjg59> Have we looked into using resmgr at all?
<Kamion> though I use growisofs with my DVD burner, not anything graphical
<mjg59> ajmitch: I emailed you about Dell laptop stuff - did you get back to me on that, or have I just overlooked the mail? :)
<ptlo> err..uhh...what encoding should we use when translating the apps (through rosetta, but working offline and then uploading) into native language? utf8?
<ajmitch> mjg59: I did tell you that my dell got stolen, right? :)
<mjg59> ajmitch: Oh, crap. Yeah, sorry :)
<Kamion> ptlo: I think that as long as the .po file's Content-Type is correct then it'll be fine
<Kamion> e.g.
<Kamion> "Content-Type: text/plain; charset=iso-8859-2\n"
<Kamion> for base-config's current hr.po
<Kamion> but UTF-8 is generally sane for new work
<ptlo> Kamion: oh, ok, thanks
<mjg59> Robot101: Around?
* ogra ARGHS very *loud* about http://wiki.ubuntu-fr.org/edubuntu/traduction
<HiddenWolf> ogra, what is wrong?
<ogra> HiddenWolf, they build their own liveCD, its apparently totally broken
<ogra> and i have not enouch manpower ...
<Mithrandir> ogra: so is our, atm. :-P
<Mithrandir> ours, even
<ogra> i wasnt even aware that there is a parallel project called edubuntu-fr
<ogra> they never ever talked to us 
<ogra> *grumble*
<HiddenWolf> ogra, sue!
<ogra> i'd love any helping hand :/
<ogra> what a waste :(
<dholbach> why don't you just mail and invite them?
<ogra> dholbach, i just talked to a frenc guy who complained about the brokeness, he'll forward my invitation ...
<dholbach> cool
<ogra> my french is quite bad :)
<dholbach> haha :)
<ajmitch> better than mine :)
<ogra> hmm, i think its time for official localized edubuntu lists ... i guess i'll introduce a edubuntu-de ml 
* Kamion finally goes to fix the cdebconf build failure
<Kamion> no doubt the buildd admins can stop hating me now, since it's been spinning every half-hour or so for a month :-/
<daniels> Kamion: so, speaking of buildd admins hating people
<daniels> Kamion: you, uh, didn't have any plans to do flight 2 today or tomorrow?
<Kamion> daniels: er, yeah
<daniels> hm
<daniels> Kamion: chinstrap:~daniels/tmp/dapper
<Kamion> er, ok, yeah, please delay that if you could
<daniels> gladly
<Kamion> Flight 2 is once we have new kernel in (inc. ABI bump) and Mithrandir fixes the live CD and we test it all
<daniels> when are you planning to do it, ooi? (not because I'm AWTYing the uploads, but because I figure I should probably generally be on top of these sorts of things)
<daniels> cool
<lucasvo> hi
<lucasvo> mjg59: I have some problem with acpi
<lucasvo> mjg59: ogra said I should talk to you
<mjg59> lucasvo: Sure, go ahead
<lucasvo> FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.12-10-386/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device
<mjg59> Are any other cpufreq modules loaded?
<lucasvo> mjg59: how can I find out?
<mjg59> lucasvo: What sort of CPU do you have?
<lucasvo> http://pastebin.com/461387
<lucasvo> mjg59: amd sempron
<lucasvo> I think
<ogra> lucasvo, lsmod|grep cpufreq
<mjg59> lucasvo: Does modprobe powernow-k8 work?
<lucasvo> ogra: pastebin
<mjg59> lucasvo: sudo modprobe powernow-k8, that is
<lucasvo> FATAL: Error inserting powernow_k8 (/lib/modules/2.6.12-10-386/kernel/arch/i386/kernel/cpu/cpufreq/powernow-k8.ko): No such device
<lucasvo> no
<ogra> k8 ? isnt that amd64  ? 
<mjg59> lucasvo: Can you put up dmesg
<mjg59> ogra: semprons are crippled AMD64s
<ogra> but 32bit only afaik ...
<mjg59> ogra: Yes, but they're still k8s
<lucasvo> [4398568.052000]  powernow-k8: Processor cpuid 681 not supported
<ogra> hmm ... i'd have guessed k7 ... but my guessing is often wrong :)
<mjg59> lucasvo: Ok. And sudo modprobe powernow-k7 ?
<lucasvo> nothing
<mjg59> lucasvo: Nothing?
<lucasvo> [4398690.304000]  atkbd.c: Unknown key released (translated set 2, code 0xaa on isa0060/serio0).
<lucasvo> [4398690.304000]  atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
<lucasvo> ^^^ this is some strange thing I get but nothing else
<mjg59> lucasvo: Does dmesg show any output?
<ogra> does it show up in lsmod ? 
<lucasvo> no doesn't
<mjg59> lucasvo: Ok, so the problem is that the kernel doesn't know how to support your CPU
<mjg59> It's not an acpi problem
<lucasvo> hm, so what should I do?
<\sh> infinity: python-kde3 just uploaded you will get it latest in 1h :) 
<ogra> here is a sempron user, but apparently he uses powernow-k8 http://www.komputilo.org/~joostje/linux/maxdata/
<ogra> even if he reports CPU throttling Doesn't work.
<Keybuk> (&)
<Keybuk> ww
<daniels> Keybuk: the real question here is, why on earth were you trying to use a dog smiley anyway?
<lucasvo> ogra: hm
<Keybuk> daniels: wuff ;)
<ogra> hehe
<ogra> meow ....
* ogra runs away from the dog
<fabbione> slomo: ping??
<slomo> fabbione: pong
<fabbione> slomo: did you notice that xine full screen is broken?
<slomo> fabbione: hm, works here in gxine... what are you using?
<ogra> Keybuk, GNOME Space Chart just gets famous in -motu *g*
<fabbione> slomo: xine-ui, on a xinerama machine
<slomo> fabbione: i don't have xinerama... could this be the cause? what exactly is broken?
<fabbione> well when i swith to full screen i can only see a little bar on a side on one of the screens
<fabbione> let me try gxine
<slomo> fabbione: xine-ui works for me too in fullscreen
<fabbione> slomo: ok. it's a xine-ui problem, probably just a missing B-D..
<crimsun> ok, I'll fix those since I touched them both last
<fabbione> gxine starts and shows full screen but it crashes (known X issue with threaded apps)
<Keybuk> ogra: oh?
<fabbione> crimsun: let me check what's missing first :)
<slomo> crimsun: consider updating xine-ui and gxine while you're at it :)
<daniels> threaded apps should be fine?
<crimsun> slomo: yep
<slomo> crimsun: thanks :)
<crimsun> slomo: was reading xinehq.de while fabbione was looking :)
<fabbione> daniels: check /msg
<daniels> fabbione: score
<ogra> Keybuk, "<cyberix> Have you seen http://www.netsplit.com/software/gnome-space-chart/" ... i guess he'd like to package it
<fabbione> crimsun: meh well. you will need to check for B-D yourself.. compare them with a build log from breezy and build on a clean dapper chroot
<fabbione> my system is way too pollutted to do it
<crimsun> fabbione: np
<fabbione> otherwise wait tomorrow :)
<fabbione> i want to watch a movie and you guys are almost on edge of being slaughtered by me :P
* fabbione shows his half meter knife
<slomo> fabbione: use mplayer until it's fixed ;)
<fabbione> slomo: no! i want menu's and stuff :P
<daniels> ogle?
<fabbione> anyway.. later ;)
<crimsun> cya ;)
<fabbione> i like xine.. i want xine MOMMY CAN YOU BUY ME XINE? :P
<slomo> bye bye ;)
<Keybuk> ogra: heh, it needs finishing first
<ogra> yes, i thought so ... ajmitch already answered him :)
<Mithrandir> fabbione: that's called "shortsword". :-)
<zyga> does anyone maintain vim around here
<zyga> I've noticed a small bug with iso->utf-8 transition
<jbailey> I think vim doesn't need maintenance, it just occasionally sits in the corner and fights with emacs.
<jbailey> Sort of like my two cats.
<Mithrandir> jbailey: they also fight with emacs?
<lucas> zyga: bug or misunderstanding of the doc ? ;)
<Mithrandir> jbailey: considered just teaching them elisp instead?
<zyga> lucas: bug, 
<lucas> zyga: url?
<jbailey> Mithrandir: My cats have a surprisingly good grasp of English, but not of French.  I think I'll focus on continuing teaching them French before I move onto elisp.
<zyga> vim tutorial is encoded with iso encoding and fails to 'notice' that, locale characters are corrupted
<zyga> I can simply file a bug
<lucas> the english tutorial ?
<zyga> lucas: no, the polish one
<Kamion> hmm, vim is normally reasonably good at spotting the encoding of a document, unless you forcibly override it
<zyga> I think they all should be encoded in utf8
<Mithrandir> jbailey: ours don't even understand Norwegian, but they do understand The Stare they get when they're in a place they shouldn't.
<zyga> Kamion: I don't override it, vimtutor on LANG=pl_PL.UTF-8 is corrupted
<Kamion> it tends to automatically decode stuff in ISO-8859-1 unless it's quite UTF-8-clean
<zyga> Kamion: I've also noticed something stranger
<jbailey> Mithrandir: It's not great vocabulary.  Sit, Stay, Come, Food and OFF are generally enough for what we actually need.
<Kamion> yes, seems so in Debian too
<zyga> there are /usr/share/vim/vim63/tutor/tutor.$LANG.$ENCODING
<jbailey> Mithrandir: I think they understand a bit more than that based on occasional reactions, but those are the easiest to measure.
<zyga> It seems someone has put the windows encoding for some obscure reason?
<Kamion> it's possible that the automatic encoding detection relies on having a vimrc
<Kamion> which vimtutor explicitly disables
<zyga> Kamion: maybe tutor is somehow special, there seem to be multiple encodings of many tutorials
<zyga> but not all 
<Kamion> ah, if it's a Windows encoding it's probably lost
<Kamion> or actually, it's probably just parsing it as ISO-8859-1
<zyga> Kamion: 
<zyga> /usr/share/vim/vim63/tutor# ls tutor.pl*
<zyga> tutor.pl  tutor.pl.cp1250
<Kamion> no
<zyga> I'll add .utf-8 and test
<Kamion> try ':e ++enc=iso-8859-2'
<Kamion> in vimtutor
<zyga> k
<Kamion> looks OK here; you're right that recoding to UTF-8 would solve it
<zyga> Kamion: looks fine
<lucas> I can't tell for tutor.pl, but tutor.fr is iso-8859-1 and is correctly displayed in my utf-8 term
<lucas> (when I vim tutor.fr)
<Kamion> yes, iso-8859-1 is the default fallback from utf-8
<Kamion> it's only languages whose legacy encoding is ISO-8859-N for N != 1 that have a problem here
<zyga> gaa
<zyga> I've added .utf-8 and it's even worse
<zyga> the file is encoded okay but it seems to be re-encoded somehow 
<Kamion> I'll file a Debian bug and see what the maintainers there say
<zyga> oh, no - It actually ignored the .utf-8 file
<zyga> I've got the iso file again
<Kamion> you need to edit tutor.vim
<zyga> I've removed .pl and .pl.cp1250 (leaving only .pl.utf-8) and it said it cannot find .pl :/
<zyga> I don't think it even looks for alternate encodings
<Kamion> see tutor.vim
<zyga> looks way over-complicated
<Kamion> putting a modeline at the top or bottom of tutor.pl declaring the encoding might be a better solution
<Kamion> certainly much less intrusive, probably
<Kamion> "certainly, probably". time for more coffee
<zyga> I don't really understand why it needs anything apart .utf8, can vim be compiled without support for other encodings?
<Kamion> a modeline encoding declaration should do just fine
<Kamion> minimal change always good
<zyga> how do I define that?
<zyga> Kamion: removing old crap is also good IMHO but I agree 
<zyga> Kamion: especially since tutor.vim doesn't look complete, I doubt it works for all encodings
<zyga> (locales)
<Kamion> yes, vim can be built without UTF-8, I believe
<Kamion> and historically almost certainly way
<Kamion> was
<Kamion> there are still plenty of people using non-UTF-8 locales
<zyga> (poor folks)
<zyga> anyway vim should be able to handle conversion from utf-8 to anything, right?
<zyga> (so that we don't really need to keep obsolete cp1250-encoded file around 
<Kamion> my efforts to do it in a modeline aren't succeeding, but I'll pass the problem upstream
<zyga> Kamion: I'll test the opposite case
<Kamion> only if vim is built with multi-byte support AFAIK, which is presumably why vim upstream keep it this way
<zyga> LANG=pl_PL with utf-8 file
<Kamion> patches that are acceptable to upstream are always superior
<Kamion> as I say, I'll file a Debian bug, don't want to spend too much time on this
<zyga> uhh, it defaulted back to C
<zyga> really strange
<robtaylor> hmm, one of these days i should submit a patch so gnome session integration isnt fubard in gvim ;)
<zyga> k, thanks Kamion 
<zyga> Kamion: I'll try to patch tutor.vim to be smart about utf-8
<zyga> if it works I'll ping you and we can attach that to the bug report
<Kamion> bug filed
<Kamion> don't have a bug number yet, see http://bugs.debian.org/vim shortly
<Kamion> don't ping me, just mail the bug
<zyga> Kamion: fine
<dholbach> have a nive evening
<mdke> ciao
<jdong> bye :)
<Kamion> zyga: http://bugs.debian.org/343118
<Kamion> argh, please somebody make btmakemetafile faster
<Kamion> oh, no, it's md5sum on *-src-*.iso, sigh
<jdong> Kamion: it's not as bad as trying to pipe a 12GB dump through 7zip
<jdong> I really hope you guys don't adopt 7z as the default deb compressor ;-)
<lifeless> daniels: during breezy->dapper my touchpad lost its right-hand-side strip for scrolling
<lifeless> daniels: was there a transition of some sort where I could have chosen the wrong package ?
<mdke> lifeless, i think it's missing the synaptics module, at least on my laptop
<daniels> lifeless: yes
<daniels> lifeless: xserver-xorg-input-synaptics, instead of xorg-driver-syanptics
<lifeless> daniels: thank you
<daniels> i live to give
<lifeless> you do it so well
<lifeless> except
<lifeless> that package is not in my packages list 
<mdke> me neither
<daniels> jooniverse
<daniels> Filename: pool/universe/x/xserver-xorg-input-synaptics/xserver-xorg-input-synaptics_0.14.3+seriouslythistime-0ubuntu1_i386.deb
<lifeless> oh lovely
<lifeless> Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/dapper/universe/binary-i386/Packages.bz2  MD5Sum mismatch
<lifeless> Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/dapper/universe/source/Sources.bz2  MD5Sum mismatch
<daniels> that would be a pretty clear case of SEP
<jdong> daniels: how do these version numbers work??
<mdke> daniels, universe?
<daniels> jdong: 0.14.3 -> 0.14.3+revertedto+0.13.6 -> 0.14.3+seriouslythistime
<daniels> mdke: yes
<mvo> lifeless: hm, au.archive.u.c out of sync? maybe Znarl can help
<mdke> daniels, is that going to main?
<lifeless> mvo: planetmirror is FUCKED.
<jdong> daniels: aha
<lifeless> they are having some serious shit from what I hear
<daniels> mdke: yeah, when I fix the seeds (probably post-Flight 2, to prevent Colin losing hair)
<daniels> lifeless: yeah, it's been going on for a while
<mdke> daniels, so can I reopen my bug until then?
<HrdwrBoB> lifeless: I use mirror.pacific.net.au
<daniels> lifeless: not profitable, *shock*
<mdke> daniels, you never know, you might forget ;)
<daniels> mdke: if it'd make you happy, I guess
<lifeless> daniels: *and horror*
<Kamion> daniels: go ahead and commit that seed change, if it's just to supported
<mdke> daniels, it might stop people filing more i suppose
* Kamion <- doesn't really care about supported most of the time
<daniels> Kamion: s/xorg-driver-synaptics/xserver-xorg-input-synaptics/ in desktop
<Kamion> ah, less ideal
<daniels> Kamion: the issue is that people are getting a useless -synaptics installed (still /usr/X11R60
<Kamion> right
<daniels> Kamion: right.  hence waiting. ;)
<mdke> daniels, are there bugs open on that already that I missed?
<lathiat> hrm i thought au.archive.u.c was pointing to uwa.edu.au not pm
<lathiat> and indeed it is
<daniels> mdke: #20166
<mdke> ty
<Pygi> Hello
<seb128> daniels: hi
<daniels> what ... the fuck ... is the new usplash artwork
<daniels> by new, I mean yesterday or something
<daniels> seb128: TOP OF THE MORNING TO YOU SIR
<seb128> :)
<daniels> (i just dist-upgraded to current dapper and the udev new world order.  that all worked, but I'd broken xserver-xorg-core, so now I'm stuck in the console.  irony.)
<seb128> daniels: have you read the cairo bug (I Cced you)
<daniels> seb128: i remember reading it in passing, yeah
<seb128> daniels: short story, turned that's the speed issue is due to cairo workarounding xorg 6.8.2 but not current one
<daniels> seb128: it's weird though, I thought we fixed that bug
<daniels> seb128: but if you just want to force it on for flight 2, that would be good
<daniels> seb128: the failure mode of that bug should be that pixmaps get rendered incorrectly, not slowly
<daniels> so I guess I'm just wondering what's really going on
<seb128> daniels: right, the rendering issue is fixed, but seems that the work around avoid a slow path too
<seb128> daniels: the small example of the bug triggers it without any issue, resizing quickly a basic one colored window takes 100% CPU and with an update like every seconds on an athlon 3000 
<daniels> seb128: how much longer are you going to be around for?
<daniels> seb128: the only thing I can think of would be fixed in the new server, but it's pretty implausible
<seb128> daniels: I'm still around for like an hour today, let me know if I should try the CVS for this bug
<seb128> not I big deal though, I run a cairo with the workaround forced atm :)
<daniels> seb128: heh
<daniels> seb128: i should have a new xserver-xorg-core built in about 10min that should fix your troubles
<daniels> and also mine (god I hate the console)
<seb128> cool :)
#ubuntu-devel 2005-12-18
<LaserJock> in general how long does it take from when a package hits dapper-changes until it is in archives.u.c?
<Riddell> LaserJock: it enters the build queue on a 5 minute cron job, then it has to wait to be picked by the build daemons which usually doesn't take too long, then it has to build which takes however long then it has to be uploaded which is on a half hour cron job I seem to remember
<\sh> Riddell: amu and I decided to have a hack session now to fix at least all serious kubuntu rc bugs ,)
<Robot101> mjg59: moo
<LaserJock> Riddell: thanks
<Riddell> \sh: excellent
<jdong> BTW guys great job on the Dapper artwork :)
<mjg59> Robot101: Still there?
<Riddell> jdong: where's that?
<\sh> daniels: tour bug headlines are very weired
<\sh> s/tour/your/
<daniels> \sh: how so?
<\sh> daniels: "xvfb font path is screwed, news at 11" 
<daniels> heh
<seb128> daniels: BTW, when are you going to fix xnest? vuntz had to downgrade it to make a sabayon demo previous week
<daniels> seb128: i've fixed it in the server packages I'm working on now
<seb128> rock ;)
<daniels> unfortunately it does interesting things to my laptop display
<daniels> interesting in the sense of, if I leave this on for long enough, my panel will be totally fucked
<seb128> don't blame the panel! :p
<daniels> so it's possibly a net loss
<daniels> haha
<daniels> it's always the panel, man
<daniels> any bug reports involving an lcd -> seb128
<seb128> iz gtk bog
<seb128> :-P
<daniels> so yeah, just chasing up what changed in the core to break that
<seb128> I should give gtk to dholbach ;)
<daniels> good plan
<seb128> speaking of GTK, before going to bed, if anybody complains about a suite of new FTBFS due to GTK stuff
<daniels> colin may murder you in your sleep
<seb128> it's fixed with GTK 2.8.9 which I've uploaded to Debian and asked elmo to sync a few hours ago on IRC
<seb128> but seems he's not around
<\sh> seb128: no excuses
<daniels> daniel's tip for tuesday: if you leave your mainly-steel watch on the window sill during a blazing 30degC day, it will probably be really hot when you try to put it on the next day
<seb128> ah ah :)
<\sh> well..I think I will close #12427
<daniels> don't close it, just reassign to the kernel where it belongs
<\sh> daniels: dude...I don't think "laptop gets hot when it's not using USB" is a kernel thing
<daniels> how could it possibly not be?
<\sh> daniels: well...my laptop gets hot when it's increasing cpu speed..but this is know by manufacture
<daniels> \sh: if you read it, you'll note that he says as soon as he plugs something into the USB port, the fans kick in, so the temperature reduces a great deal
<daniels> which sounds exactly like badly busted ACPI
<\sh> k...i'll read something about an hw problem...
<\sh> "If I have all my USB ports free my computer starts getting hotter."
<\sh> well...lets see what mjg will tell us
<zul> jbailey: ping
<Nafallo> elmo: please sync grisbi from debian unstable (ubuntu override okey)
<mgalvin> does anyone know if we have any current hard numbers of boot speed improvements yet and maybe some of those nice before and after graphs?
<Nafallo> mgalvin: http://www.magicalforest.se/~nafallo/bootchart/ :-)
<Nafallo> it's not a pure ubuntu-desktop though :-P
<mgalvin> Nafallo: rock! thanks
<Nafallo> np :-)
<mgalvin> do you know what the old breezy ~boot time is by any chance?
<Nafallo> nope
<Nafallo> I would guess the oldest one + ~10 secs
<mgalvin> ok, thanks, maybe I will just install bootchart on my breezy machine so I can get a graph of that too
<Nafallo> :-)
<mjg59> infinity: YOU HAVE BROKEN USPLASH
<mjg59> infinity: (It no longer scrolls a big enough area since you moved the status text further out)
<infinity> Erm, really?... It worked here.
<infinity> Do you have some really long status text?
<mjg59> #20911
<infinity> Oh, feh, I was testing with the word "fail", not "failed".  LAME.
<infinity> Also, this is the reason why I'm replacing the proportional font with a fixed-width font, so we can right-justify that column and stop guessing where the text might end up.
<infinity> mjg59 : But, for now, since we write NOTHING to the edges, why are not just scrolling everything from 0 to 640, instead of guessing where the text will land?
<infinity> s/are note/are we not/
<mjg59> Because I thought there might be artwork there
<infinity> Some frilly laurels or something?
<mjg59> Yeah
<infinity> Well, if we had a proper bounding box for the text, I'd agree that it's all we should scroll.
<infinity> But in the current "write some stuff, and guess that it might end up vaguely thereish" world order...
<mjg59> Ha
<mjg59> Yeah
<mjg59> But the status stuff is fairly well constrained
<mjg59> And normal text is wrapped
<mjg59> So...
<infinity> Status is constrained, until you write a long status message.
<infinity> You can keep writing status as long as you want, and it just keeps pushing to the right. :)
<infinity> "FAILURE failederooney"
<infinity> You know someone will do it. :)
<mjg59> Yeah, but they suck
<infinity> (But, yeah, I'll just push the scroll are out a few pixels to fix this bug)
<infinity> area, too.
<infinity> Unless you already have.
<mjg59> Not yet
<mjg59> I'm writing a website to get me sued instead
<infinity> Kay.  Doing it now, then.
<infinity> Oh, those are fun.
<infinity> Who's suing you this week?
<mjg59> http://www.srcf.ucam.org/~mjg59/GPL/ so far
<infinity> mjg59 : When you say "contain GPLd code", do you mean "contain someone else's GPLd code", or just "the work is licensed under the GPL by the copyright holder"?
<mjg59> infinity: If it's not in violation of the GPL, then the latter
<mjg59> But only the former case is something where there's potential litigation
<infinity> mjg59 : The latter being a fuzzier area, since it's not ILLEGAL to license your own work incorrectly, just stupid.
<infinity> Right.
<infinity> \sh : Thanks for sorting python-kde3
<\sh> infinity: my pleasure...you have now sip4 + pyqt newer then in debian and pykde building with kde3.5 but without kde3.5 api 
<infinity> Good enough for now.
<\sh> infinity: well I hope so..and we have now python2.4-qt3-gl which was MIA a long time
<SEJeff> mjg59: You are suing Linuxant, or you work for them and someone is suing you? I'm confused over what you said and what that website says
<mjg59> SEJeff: No, nobody is currently being sued
<SEJeff> Does the guy that runs gpl-violations.org know about Linuxant? I know a few projects signed over their copyright to him temporarily so he could sue the german companies
<mjg59> I haven't, no
<mjg59> But I've contacted the copyright holders
<SEJeff> Ok, you might contact him too. That guy goes for the jugular and has resolved several cases
<mjg59> Linuxant aren't German, sadly
<mjg59> They're based in Montreal
<SEJeff> Are you in CA?
<mjg59> Nope
* zakame prays for the enlightening of Linuxant :/
<SEJeff> hmmmmm, that makes it pretty hard to open a case against them
<mjg59> Yeah
<infinity> USPLASH IS HATE
<mjg59> So I'm just hoping they'll threaten me with a lawsuit or takedown notice
<SEJeff> But suing them and winning would set a precedence that I don't think exists in northern america
<jsgotangco> zakame, bleahhh
<mjg59> infinity: LIES
<infinity> TRUTH.
<mjg59> LIESLIESLIES
<SEJeff>  /. here we come :-)
<zakame> jsgotangco: err, do you want me to lose all hopes of connectivity? :p
<jsgotangco> zakame, that's not the point
<SEJeff> mjg59: What did the copyright holders say?
<mjg59> SEJeff: There may be interesting kernel patches forthcoming
<mjg59> (of the "oops, was that your business model we just destroyed?" variety)
<SEJeff> mjg59: I'm guessing to break the linuxant drivers?
<infinity> Oh, duh.  I'm retarded.  (and usplash is hate)
<mjg59> infinity: YOU ARE HATE
<SEJeff> infinity: don't hate
<robtaylor> we are all love... ommmm.....
<jsgotangco> haha
* robtaylor hope he will never have to manually rebuild gst 0.10 again...
<SEJeff> mjg59: If anything serious comes of your page, let me know and I will help you to the best of my ability
<mjg59> SEJeff: Heh. Thanks :)
<SEJeff> mjg59: I'm going to take a crazy guess and say that patch you were talking about was from Adrian Bunk. I found something about linuxant and ndiswrapper on lkml
<mjg59> Nah, that's a different one (that breaks driverloader)
<SEJeff> mjg59: Found it, thanks
<jdub> NEW KERNEL! NEW KERNEL!
<mjg59> GOGOGO
<whiprush> NEW USPLASH!
<mjg59> WHAT COULD POSSIBLY GO WRONG HERE?
<mjg59> Haha
<whiprush> I haven't rebooted yet, is it still a gimp-nightmare? (usplash)
<tseng> no
<mjg59> I love that we ship a splash that I wrote while very drunk and hungover in a dorm room in Helsinki
<mjg59> whiprush: Nah
<jsgotangco> heh
<whiprush> I think you should ship that for a while longer
<mjg59> So do I
<whiprush> put the fear of god into anyone daring to use dapper.
<jsgotangco> yeah its just awesome
<mjg59> But infinity changed it
<mjg59> infinity: HATER
<jsgotangco> UGH
<mjg59> Don't worry
<whiprush> maybe add a "X isn't going to work either dude." on the bottom
<mjg59> I'll change it next time I do an upload of usplash
<zul> mjg59: its called quality
<mjg59> usplash is your guarantee of quality
<jdub> *cough* should be using X!!! *cough*
<mjg59> jdub: Hater
<mjg59> jdub: (0.2 seconds startup time against at least 5)
<infinity> mjg59 : <laugh>... I changed it back so Flight-2 would be a bit more "professional" or some crap.  Change it back after Flight-2 is out. :)
<infinity> mjg59 : I wouldn't oppose a splash-of-the-week until we get new/final artwork.
<fabbione> jdub: ping?
<daniels> listen
<daniels> X WORKS
<daniels> i haven't upload the verson which will probably fuck my panel on i810 if I run it for long enough
<daniels> i just wanted to make that clear
<fabbione> daniels: ?
* fabbione takes the pipe away from the kid
<daniels> 02:58 < whiprush> maybe add a "X isn't going to work either dude." on the bottom
<fabbione> oh
<jsgotangco> doh
<jsgotangco> surely he was jesting..because of our beautiful usplash
<daniels> definitely in jest, because it's been ages since I've broken X :P
<fabbione> daniels: would you be so kind to SMS jdub: "fabbione is waiting for you, or he will make you an offer you can't refuse. kthxbye"?
<daniels> done
<fabbione> daniels: thanks dude
<daniels> amazingly my phone knew the word 'testicles' without me having to teach it
<fabbione> ahahah
<jsgotangco> hahaha
<Treenaks> next question: why are you sending messages with the word 'testicles'?
<Treenaks> + in them
<daniels> Treenaks: i'm trying to communicate with jdub on his level
<janimo> no TB meeting today?
<Pygi> don't know
<robitaille> none scheduled yet:  https://wiki.ubuntu.com/TechnicalBoardAgenda
<janimo> last time it was scheduled some hours before, so I want to get ready
<smurf> Bah. dh_gconf forgets to add a dependency on a new-enough gconf2.
<infinity> Ugh, gnome-terminal is completely and utterly hosed.
<smurf> infinity: Happily I didn't upgrade that yet. What does it do, insert "sudo rm -rf /" in front of every statement?
<sivang_away> morning all
<Pygi> mornin' sivang
<sivang_away> hey yi 
<sivang_away> err
* sivang_away can't type this morning
<Pygi> hehe ;)
<sivang_away> also, can't change my nick back for some weird reason
<Pygi> heh :/
<fabbione> sivang_away: leave #launchpad, change nick, enter again
<fabbione> no idea why that channel is making problems
<sivang_away> fabbione: yes, that is it. We need to fix that :)
<sivang_away> maybe close channel, reopen 
<sivang_away> anyway - be right back
<sivang> ah, that's better
<Pygi> good
<mdke> fabbione, because it is +R i think
<mdke> they set it because of some huge spam bot attack the other day
<mdke> sivang, works ok if you register both nicks and link em
<sivang> mdke: ah ok, I didn't know that. I will try that, thanks.
<mdke> sivang, in fact I think just linking them does the job, you don't have to register them separately
<sivang> mdke: how do you link between nicks?
<mdke> sivang, /msg nickserv group
<mdke> change to your away nick, do /msg nickserv group sivang password
<mdke> i think
<pitti> eek - how the f*** slipped ffmpeg into main for hoary?
<HiddenWolf> -NickServ-     LINK       Link your nickname to another
<HiddenWolf> ./msg nickserv link <other-nick>
<pitti> jdub: we will all go to jail. ^ :/
<fabbione> pitti: check the dates on the Packages.gz files
<mdke> HiddenWolf, heh i was looking at the wrong network
<mdke> sivang, what he said :)
<pitti> fabbione: hm?
<fabbione> April 7 2005 ?
<pitti> fabbione: no idea, this is madison on jackass
<pitti> Hi slomo
<fabbione> pitti: i think it's a known problem..
<slomo> pitti: hi :)
<HiddenWolf> "pitti: we will all go to jail! -> slomo: Hi :)"
<fabbione> ahahah
<pitti> yes - summoning powers ;)
<slomo> pitti: what happened?
<pitti>     ffmpeg | 3:0.cvs20050121-1ubuntu1 | http://de.archive.ubuntu.com hoary/main Sources
<pitti> slomo: this happened
<HiddenWolf> Filename: pool/universe/f/ffmpeg/ffmpeg_0.cvs20050918-4ubuntu1_i386.deb
<HiddenWolf> that's on my breezy box.
<fabbione> HiddenWolf: source != binary
<fabbione> HiddenWolf: and hoary != breezy
<pitti> slomo: yes, it's in main only for hoary
<slomo> pitti: i know... i moved it out of main for breezy
<slomo> pitti: it was there only for kino iirc
<slomo> pitti: what's exactly the problem now? we still have ffmpeg in main in xine-lib but it will disappear soon :/  (sorry for stupid questions, i'm still almost asleep ;) )
<pitti> slomo: I was just surprised to see these codecs in main, but OTOH we have libmad in main forever...
<fabbione> elmo: can you please autosync util-linux from debian? thanks
<Pygi> welcome dholbach and sabdfl
<sabdfl> hi
<Tm_T> hullo
* mvo waves
<Tm_T> sucky, no kernel borkage since... 15-5
<infinity> dholbach : Your gnome-terminal update is making me cry. :/
<dholbach> hey sabdfl and Pygi - hi everybody else :)
<Tm_T> works too well ;(
<Treenaks> Tm_T: we should put up a sign..
<infinity> dholbach : I had to downgrade.
<Tm_T> Treenaks: yu
<dholbach> infinity: really?
<dholbach> infinity: how so?
<dholbach> it works nice on 3 of my boxes
<infinity> dholbach : I have a launcher on my panel to launch g-t.  If I try to launch a second instance, the first freezes (and the second never shows up)
<infinity> The launcher does "gnome-terminal --geometry=100x37" (don't ask)
<infinity> Nothing terribly odd.
<Pygi> hehe, dholback, remember the most favorite quote of all developers? ;) "It works on my computers" ;) hehe ;)
<Tm_T> haha
<dholbach> Pygi: it's all i could do :)
<Tm_T> infinity: I might try that too if I have gnome-terminal installed
<Tm_T> as soon as my updates are downloaded and installed, so less than an hour
<dholbach> infinity: i can reproduce it - but the back trace looks weird
<dholbach> *grmbl*
<infinity> As long as you can reproduce it, I'm happy.
<infinity> I'll leave it in your capable GNOMEy hands and go back to doing what I do best.
<dholbach> so that's one of us happy :)
<Pygi> hehe, so dholbach, it does *not* work on your computer ;) hehe ;)
<dholbach> Pygi: i don't use strange geometry options :)
<Pygi> hehe, see? ;) excuses, excuses ;) 
<dholbach> i'm not awake enough to retort something :)
<Pygi> heh ;)
<Pygi> It'll get fixed, eventually ;)
<sivang> dholbach: you got along with the lpi patches?
<dholbach> yes, so far so good, but there are still some tarballs left
<sivang> hi sabdfl 
<sabdfl> hey sivang
* sivang is sad to see lpint-bonobo slowly, but surely loosing grip into packages ;-)
<ajmitch> evening
<Pygi> mornin', mornin' ;)
<sivang> dholbach: actually it's a good thing, it'd be good to see apps standartize on UIManager
<pitti> Kamion: odd, there are no debs for gfxboot-theme-ubuntu, just the source package...
<seb128> pitti: hey
<pitti> hi seb128 
<Kamion> gfxboot-theme-ubuntu |      0.1.1 |        dapper | source, amd64, i386
<Kamion> pitti: they're there
<seb128> pitti: dpkg-reconfigure locales doesn't do anything now, what is the new way of changing locales settings from now?
<pitti> Kamion: ah, ok. I looked at 0.1.0 in universe
<Kamion> pitti: oh, yeah, I promoted it as you suggested
<Kamion> (pre-review)
<pitti> seb128: just install/remove the according language pack
<seb128> pitti: hum, so you force users to install a language-pack to generate a locale?
<pitti> seb128: ATM yes
<seb128> pitti: gedit upstream wanted to try a bug on their software with zh_CN, and they probably don't want to install <n>MB of language-pack for this ...
<seb128> hum
<pitti> seb128: if you have a good use case how it should be done differently?
<seb128> dunno how the new locales work
<seb128> but dpkg-reconfigure locales was nice
<pitti> seb128: the langpacks ship and install/uninstall the locales now
<seb128> that really sucks :/
<pitti> so that we can manage them through rosetta
<seb128> I've usually 10 locales or so on my box
<seb128> but I don't want 10 language pack for sure
<pitti> seb128: hm, but you are not the average case :)
<seb128> right, but we have non average case upstream using Ubuntu too
<pitti> seb128: anyway, if you need it, I can invent a way to manually intstall a locale
<seb128> that would be nice
<seb128> I think it's quite common for people testing a bug to want to generate a locale without installing <n>MB of translations for it
<pitti> Kamion: would a locales-all package help you for the installer?
<pitti> Kamion: we wouldn't update locales-all post-release, but at least people could use additional locales
<Kamion> pitti: not sure yet
<Kamion> but quite possibly for build purposes at least; we wouldn't have the installer install it
<Kamion> I've made the installer install the appropriate language pack just after installing the base system, BTW, if you didn't see
<pitti> ah, cool
<Kamion> probably need to tweak localechooser some more, but I think it'll do for now
<pitti> Kamion: does the gfxboot license require us to ship all the SuSE theme stuff? It blows up the deb quite considerably
<Kamion> pitti: no, it just seemed reasonably useful; we should probably arrange to ship a prebuilt theme rather than the source
<Kamion> certainly I think penguins.xcf is unnecessary
<Kamion> (which is big)
<pitti> I just wondered about > 1 MB for just the tools
<pitti> Kamion: oh, wait, do we need to ship that deb on the CD?
<pitti> it just looks like tools
<pitti> nitpick: Suggests: s/kanotix-graphics/gfxboot-theme-ubuntu/ ?
<Kamion> pitti: no, we don't
<pitti> Kamion: ok, then it doesn't really matter; thanks
<Kamion> pitti: yeah, that Suggests predates gfxboot-theme-ubuntu, I'll change it
<Kamion> what happens is that the CD build process looks up the gfxboot-theme-ubuntu .deb in the archive and fishes the theme binary out of it, then dumps that in /isolinux/ on the CD
<pitti> btw, that looks really cool - even with proper keymap support
<Kamion> yeah, it's an unexpectedly nice system
<Kamion> elmo: I've NEWed l-r-m, hopefully the right way this time round (i.e. mostly with lisa except where it bitched viciously about stuff in restricted/debian-installer). If that was wrong, let me know what I *should* be doing ...
<pitti> Kamion: I think I found some potential buffer overflows with malicious dictionaries with overly long entries
<Kamion> in gfxboot?
<pitti> Kamion: i. e. by tricking sb to run the tools on a malicious theme, you could probably run arbitrary code
<pitti> yes
<pitti> unchecked sprintf
<pitti> into a statically sized buffer
<pitti> it's not something that should immediately concern us
<pitti> but eventually it should be fixed
<Kamion> ok, I think a malicious theme could probably just run arbitrary code anyway :)
<Kamion> but sure
<Kamion> could you file a bug and I'll have a look?
<pitti> Kamion: no, that's not what I mean
<Kamion> oh, I see what you mean
<pitti> Kamion: i. e. I compile a theme as normal user in my normal system
<Kamion> is this in mkbootmsg.c then?
<pitti> and you give me a malicious theme
<pitti> yes
<Kamion> right
<seb128> if I make nautilus Depending on beagle, will you people try to track me down or something? :p
<Kamion> seb128: ayup
<seb128> right, I'll mail ubuntu-devel about it
<pitti> Kamion: line 1935 and ff.; it looks at least suspicious
<Kamion> depends on the CD size change probably
<seb128> is there an easy way to determine how much a package impact on the CD?
<seb128> like a script doing this
<Kamion> pitti: hm, yes
<Kamion> seb128: germinate
<Kamion> run it before and after, it has options to look at custom seeds you provide
<seb128> k, I'll give it a try later, thanks
<pitti> Kamion: erm, sorry, line 1876
<pitti> Kamion: anyway, I'll file a bug
<Kamion> yep, thanks
<seb128> elmo: could you sync GTK 2.8.9 from Debian?
<pitti> carlos: sorry to nag, but is there any ETA when rosetta will export tarballs again? I need to update the langpacks in the near future and would like to test rosetta again
<carlos> pitti, let me ask for the staging status...
<carlos> pitti, seems like the mirror is not being updated...
<carlos> pitti, hmm, it could happen next week, but anyway I will try to move the language pack generation to production so we don't have this problem anymore...
<pitti> carlos: given the chaos at the breezy release, it would be nice to get the process solid well before dapper release comes in sight
<pitti> :)
<carlos> yeah
<\sh> hmm..don't we have today TB meeting?
<doko> infinity, lamont: please requeue gcj-4.1 on amd64
<infinity> doko : Building.
<\sh> first rule: never go out when you have a cold...it makes things worse
<Nafallo> \sh: doh :-P
<pitti> \sh: go swimming, it helps a lot
<\sh> pitti: not with 39 Deg C fever
<pitti> \sh: ok, right; it helps me when I just have a cold, but no fever (which is the common case)
<\sh> pitti: I hope it's gone later this week...just before my interview
<pitti> \sh: with google? I wish you all the best for it!
* pitti crosses fingers
<\sh> *no comment* 
<\sh> pitti: *no comment* 
<Kamion> was anyone planning to seed the server kernels?
<Kamion> they might fit well in the ubuntu-server seeds
<sabdfl> Kamion: is a usb-boot image very different to a cd-boot live image?
<Kamion> sabdfl: well, we don't have any USB live images yet ...
<Kamion> sabdfl: the way we do USB installation is to stick a netboot image on a USB stick and boot from that
<sabdfl> Kamion: would it be tricky to make them?
<Kamion> sabdfl: there's an alternative method as well if you have large enough sticks:
<Kamion> sabdfl: a special image with somewhat different sets of kernel modules and a special udeb that looks for an ISO image as a file on the USB stick, loop-mounts it, and then proceeds from there roughly as if it were a CD
<Kamion> sabdfl: it would be relatively straightforward in the hoary/breezy live CD, although we never actually got round to doing it and it would probably require 1GB sticks which weren't all that common at the time
<sabdfl> are 1gb sticks reasonable now?
<Kamion> sabdfl: in the dapper simplified live CD, I'm not sure, because we won't be able to take advantage of existing d-i components any more; Mithrandir would know more
<Kamion> (that simplified live CD hasn't landed yet, but the code's there and it'll land in a couple of days)
<sabdfl> ok, i'll ask Mithrandir about it when that is testable
<sabdfl> thanks muchly
<Kamion> sabdfl: certainly more so than they were
<Kamion> sabdfl: random local computer store quotes 55 pounds
<infinity> seb128 / dholbach : I'm not entirely positive about this, but I thought I should give you fair warning that if you keep breaking ubuntu-desktop, Kamion might do Very Bad Things to you.
<Kamion> I think when we did casper originally it was more like 200
<Kamion> a lot of people still have 128/256MB sticks lying around, though
<seb128> infinity: what is broken?
<Kamion> http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html
<Kamion> it's the usual gnome-{applets,control-center,panel,session,terminal} mess, on powerpc
<sabdfl> erk. i just updated and got the new gnome bits (thanks seb128) is it safe to re-login?
<seb128> sabdfl: should be yep
<dholbach> sabdfl: why not?
<Kamion> sabdfl: we're only talking about uninstallables here ...
<seb128> Kamion: actually if elmo was doing sync in less than 1 day that would help
<sabdfl> ok
<sabdfl> seb128: why?
<seb128> Kamion: GTK is known to be broken, I've uploaded 2.8.9 to Debian and asked for a sync yesterday and I'm still waiting
<sabdfl> seb128: why no upload direct to ubuntu?
<seb128> sabdfl: because we have no Ubuntu specific change and we do that to lower the sync work usually
<seb128> I could make an artificial ubuntu version right
<Kamion> gtk+2.0 is in sync, it should be autosynced
<dholbach> sabdfl: and if the upload is broken, we're not the only ones to suffer from it :-p
<seb128> Kamion: from experimental?
<Kamion> oh
* infinity slyly admits that he's done manual sync uploads before, when the urgency warranted it, by copying the pseudo-headers from a real sync.
* infinity will never admit that in elmo's presense.
<sabdfl> mvo: ping
<Kamion> sabdfl: oh, installation *to* a USB drive
<mvo> sabdfl: pong
<Kamion> sabdfl: entirely different from installation *from* a USB drive
<sabdfl> Kamion: i thought he was asking about a USB Live
<Kamion> he said "installation on"
<seb128> Kamion: can we get a GTK sync now or should I go with an Ubuntu versionning for it?
<Kamion> I think it's mostly just grub bug fixes and such
<sabdfl> hmm... that would give you the same effect, would it not?
<seb128> it breaks half on GNOME builds atm
<sabdfl> you could boot off that installed image off a usb stick and voila? faster than live-cd?
<Kamion> sabdfl: not if you wanted to keep your changes around, no
<Kamion> only if you have no worthwhile data ;-)
<sabdfl> ?
<Kamion> you can't save your documents unless you muck around with partitioning on the USB stick
<Kamion> there's a valid use case for installation on USB stick, which is different from the (also valid) use case for running USB live
<fabbione> that's scary.. some sticks really don't like partitioning
<Kamion> fabbione: indeed
<Kamion> seb128: go for an artificial Ubuntu version for now; I'm not doing syncs
<seb128> k
<lathiat> i saw someone get bootin gof a usb drive pretty good, main problem was waiting to mount / till the usb storage was detected
<lathiat> the whole "waiting for device to settle" thing
<Kamion> it may well be easier with the new udev, and grub 0.97
<lathiat> i keep reading about this udev new order, is there a good email/page/blog someone wrote up exlaining that?
<Kamion> powerpc USB installation is always going to be a bit tricky because finding the Open Firmware path to the device is just plain hard work
<Kamion> lathiat: http://lists.ubuntu.com/archives/ubuntu-devel-announce/2005-December/000028.html
<lathiat> hrm must of missed that
<lathiat> cheers
<ogra_> and thre are the ubz specs as well ;) look at launchpad 
<herzi_x41> is it possible to use the post-update-note to tell information to other users? which command is needed for that?
<mvo> herzi_x41: it is, every user who runs update-notifier will see the information
<dholbach> herzi_x41: ask mvo, you have to deploy a file somewhere
<Kamion> sabdfl: hmm, rereading, I sort of see what you mean
<mvo> herzi_x41: https://wiki.ubuntu.com/InteractiveUpgradeHooks
<Kamion> sabdfl: I think that would be something best created by the installer rather than regarding it as a live image, though; the difference between an installed system and a live image is almost precisely that the build process for the latter doesn't attempt to make it bootable on its own without the aid of casper
<Kamion> and the problems are mostly in making it bootable, so solving those would probably make both cases work anyway :-)
<lathiat> there any specs about making xorg configuration regenerate itself if X fails to start and it isnt custom?
<ogra> lathiat, see the head of the file ;)
<lathiat> which file?
<ogra> xorg.conf
<lathiat> oh, in dapper?
<ogra> lathiat, in any system ...
<Kamion> ogra: that's about you regenerating it manually, not about it regenerating itself
<ogra> even in xfree86 there is a description
<Kamion> it's a very different question
<lathiat> yes im asking, e.g. you change video card
<lathiat> x fails to start
<lathiat> config is stock
<ogra> ah, k... i missed that, right
<lathiat> try a standard autodetect
<Mithrandir> Kamion: VERY VERY SHINY. :-)
<Kamion> Mithrandir: hmm?
<Mithrandir> Kamion: the new live cd is so shiny it's not even fun.
<lathiat> cus i know thats got quite a few people i know stuck for a while
<Mithrandir> the menu stuff
<Kamion> hooray :)
<lathiat> anything horribly broken in dapper atm?
<Mithrandir> we should make the "loading linux kernel" more slick, though.
<Mithrandir> it looks like it's from window 2.0 with the window 3.0 colour theme
<Kamion> Mithrandir: yeah, noticed a few bugs there. Do you see the console messages showing up at the top of the screen in duplicated green?
<pabs3> is there an equivalent of http://people.debian.org/~seppy/d-i/level1/POT/ for ubuntu/kubuntu?
<Mithrandir> Kamion: my system booted to quickly for me to notice it.
<janimo> Kamion, Mithrandir: so the dapper liveCD will no longer share much code with the installer because that has speed disadvantages?
<Kamion> pabs3: http://people.ubuntu.com/~cjwatson/installer-po/ is sort of there, but I've been talking with Carlos about how to get that moved into Rosetta, so it'll end up there
<aleXL>  Dunno how 2 xchat... sorry dholbach... d'u know how I can use the spell check f7 to run festival? I'm really green at this...
<aleXL>  within oo2 or txteditor?
<Kamion> janimo: http://wiki.ubuntu.com/SimplifiedLiveCD
<Mithrandir> Kamion: and the live cd shouldn't care that it doesn't see my hard drive. :-P
<ogra> Kamion, that'd be great, i had a bunch of people asking in #edubuntu yesterday about translations ...
<pabs3> thanks Kamion 
<Kamion> Mithrandir: huh?
<dholbach> aleXL: i don't get what you are asking me
<Mithrandir> Kamion: for some reason, it doesn't see my hard drive and complains.  Unsure what part of d-i that is, though.
<dholbach> aleXL: what are you sorry for? 
<Kamion> Mithrandir: that would be disk-detect
<aleXL> porting festival into openoffice for spell checking (dyslexics)
<ogra> dholbach, he wants to use festival alongside with the spellchecking in ooo2
<aleXL> thought i'd knocked you off....
<ogra> aleXL, you need to be a OP to knock people off ;)
<dholbach> aleXL: you sent a ctcp ping and some time later xchat was out
<Kamion> Mithrandir: ok, I see. We could maybe preseed disk_detect/module_select to avoid that
<Kamion> disk-detect/module_select, sorry
<Kamion> or cannot_find maybe
<Kamion> could be done by casper-check
<aleXL> dholbach: pinging's knocking on door, right? CTCP or external?
<Kamion> probably doesn't make sense to work on it with simplified-live-cd round the corner though
<Mithrandir> Kamion: it'll go away post-flight, so..
<Mithrandir> Kamion: anyway, the new live cd works a lot better for me, I think I can get casper working in a little while.
<dholbach> aleXL: you did a ctcp one, but anyway... sorry, no idea about festival
<Mithrandir> Kamion: "boot from first hard disk" should probably clean the screen before chaining
<Kamion> it doesn't? sorry, I didn't really actually try that much
<Kamion> I think that ought to be syslinux' jobs
<Kamion> job
<Kamion> hm, or maybe not, I can see the argument for gfxboot clearing
<Kamion> but there's no special case for that option AFAIK
<Nafallo> *sigh* what's up with gnome today? lots of stuff seems to segfault.
<Kamion> Mithrandir: ah, I see the problem; local_boot in syslinux should probably call gfx_done
<herzi_x41> dholbach, mvo: thanks
<herzi_x41> mvo: https://launchpad.net/distros/ubuntu/+source/update-notifier/+bug/5752
<Mithrandir> Kamion: yes, I see the text as well, on top.
<mvo> herzi_x41: thanks
<tseng> jdong: do you have a document describing proper backports versioning for people putting stuff in the wild?
<Mithrandir> fabbione: you're working on boot off usb, aren't you?
<fabbione> Mithrandir: kinda.. it's blocked by detect root fs atm
<Mithrandir> fabbione: ook.
<Mithrandir> fabbione: just got a request about being able to install on USB pen drives and such.  Should I forward it to you?
<fabbione> Mithrandir: it is possible to install on USB.. 
<fabbione> that's not a problem
<fabbione> the real issues are:
<Mithrandir> fabbione: can you boot off it afterwards too? :-)
<fabbione> - / device might not be there. (reason why there is a spec)
<fabbione> - if you change position / will never be found (other spec)
<fabbione> Mithrandir: my MOBO supports boot from USB
<fabbione> if his/her mobo doesn't, he can still install on USB.. but it will never work..
<fabbione> you know...
<Kamion> Mithrandir: localboot display glitch fixed, thanks
<Kamion> ROCK, USPLASH FIXED MY CRAPTOP
<Kamion> er, not usplash
<Kamion> KERNEL 640x400 FIXED MY CRAPTOP
<Mithrandir> Kamion: \o/
* Kamion sends eternal gratitude in infinity's direction
<fabbione> ahha
<Kamion> and the best bit is that it landed at almost exactly the same time as we got a video mode selection knob in the bootloader, so people can't even complain that they have less visible screen text in the installer now
<jdong_> elmo: can I get an ETA on those backports?
<tseng> jdong_: do you have a document describing proper backports versioning  for people putting stuff in the wild?
<jdong_> tseng: upstream~breezy0.x
<jbailey> Kamion: Is there a TB mtg today?
<tseng> eh, fair enough
<jbailey> Kamion: When I looked yesterday, the agenda still had a date from 2 weeks ago, and the /topic didn't mention one.
<tseng> jdong_: would i be correct in saying that ipod_0.3.5-0filefind.net0_i386.deb is wrong?
<jdong_> tseng: absolutely that's wrong :)
<tseng> ok, issuing clue
<jdong_> LOL
<tseng> thanks.
<Kamion> jbailey: I don't know; I'm not on the TB
<jbailey> Kamion: Oh?  Sorry. I thought you were.
<Kamion> jbailey: discussion yesterday suggested there would be I think, but you'd have to ask sabdfl/mdz/Keybuk
<Kamion> er
<Kamion> sabdfl/mjg59/Keybuk
<jbailey> Two of those, anyway. =)
<ogra> jbailey, there is one afaik ...
<jbailey> ogra: Cool, thanks.
<mjg59> There is, yes
<jbailey> seb128: Ping?
<seb128> jbailey: pong!
<ogra> hmm, but the agenda needs cleanup ...
<jbailey> seb128: gnome-terminals seem to be hanging on me.  Is there any information I ought to collect for the bug report?
<seb128> jbailey: dholbach did the update and is on it afaik
<seb128> he was speaking backtrace with infinity some hours ago
<seb128> dholbach: ping? :)
<dholbach> pong :-(
<dholbach> h:)
<jbailey> Ah, cool.  I didn't see the bug when I looked quickly in bugzilla.
<dholbach> jbailey: there's no bug report yet
<dholbach> jbailey: what is your usecase?
<jbailey> dholbach: Jeff Bailey wants to use gnome terminal for more that 90 seconds at a time.
<jbailey> s/that/than/
<jbailey> Or do you mean steps to reproduce?
* jbailey hides
<jbailey> =)
<dholbach> hehe, yeah, do you do anything special?
<dholbach> like   --geometry=100x87    in the launcher or whatever infinity uses ;)
<jbailey> dholbach: No.  I'm lazy. =)  My only customisation is white on black.
<dholbach> ok, will try that too
<dholbach> thanks
<ogra> wow, it crashes for me here with the edit profile dialog ....
<ogra> but the term itself works fine ...
* jbailey runs everything in screen today. =)
<pitti> re
<ogra> hmm, that as a one timer, now it works ...
<\sh> ogra: hmmm...did someone removed the "edit profile dialog" because he thought the "idiots" don't need that? *run*
<ogra> \sh, blblb :P
<tepsipakki> kamion: should the new installer-initrd be mountable somehow? I haven't figured out how
<tepsipakki> as a loop-fs
<\sh> ogra: anyway...linus is wrong (tm)
<Kamion> tepsipakki: no, create a temporary directory, cd to it, zcat | cpio -id
<Kamion> it's not a filesystem itself
<StevenK> Mmmm, cpio
<tepsipakki> ok
<pitti> Kamion: could you please approve gtk+2.0_2.6.4-0ubuntu5_source.changes for hoary-updates? it's a security update for the current -updates version that I uploaded long ago
<Kamion> pitti: I don't generally do -updates, but mdz's away, so ...
<pitti> Kamion: can elmo do that?
<pitti> Kamion: there are no debs, not sure whether the buildds don't see the source until it's approved
<StevenK> pitti: Are you counting the days until warty stops getting security support? :-)
<pitti> StevenK: doesn't make much of a difference, at that day dapper support begins :)
<Kamion> pitti: I'll do it
<StevenK> Heh
<pitti> Kamion: thank you
<Kamion> just waiting for apt-ftparchive to finish running
* jdong_ hates his internet connection
<Kamion> pitti: done
<pitti> merci
* StevenK ponders begging people in #launchpad to fix/add his u.c address
<Kamion> er, did I not add you to the ubuntumembers team?
<StevenK> You did.
<jdong_> hey, let's make today official bug everyone about everything day!
* jdong_ starts with Backports :)
<Kamion> oh, I did
<Kamion> StevenK: it should be semiautomatic, I don't think #launchpad has anything to do with it
<StevenK> Kamion: Apparently the script that generates the virtual alias table is offline due to refactoring.
<Kamion> StevenK: I think it's in the admins' court (Znarl/elmo)
<Kamion> oh, bleh
<StevenK> Or so I read in a bug filed against LP.
* Kamion beats the refactoring monkeys with a "keep it working" stick
<tseng> jdong_: i sent some guy to backports with the hope he will agressively test and poke mono backports instead of publishing crappy ones on his webspace
<StevenK> Kamion: So I beat up elmo or #launchpad? :-)
<tseng> jdong_: he has a fairly complete set
<Kamion> StevenK: probably #launchpad then, from what you said
<ogra> eeek
<ogra> tftpd-hpa shows up as ftp service in the service admin tool 
* tseng gives ogra a carrot
<ogra> :P
<ogra> it should not say ft service, thats very confusing for users ...
<Treenaks> tseng: no pony?
<ogra> *ftp
<tseng> Treenaks: that wouldnt be very useful in a regex, would it
<Treenaks> tseng: maybe in perl rege
<Treenaks> x
<jdong_> tseng: yeah, I've talked to him briefly
<tseng> jdong_: filefind or whatnot?
<tseng> jdong_: i think he is rolling some of his own stuff as opposed to using dapper
<jdong_> is elmo extremely busy recently?
<StevenK> s/ recently//
<tseng> is he ever not?
<tseng> right.
<jdong_> I mean, he's not done any backports builds since the 29th of nov
<jdong_> and requesters are growing impatient
<jdong_> In addition, I'm sure some of the packages the versions have chanced since request
<jdong_> changed*
<Kamion> AFAIK he's been sucked into writing ftpmaster tools for Launchpad in preparation for it taking over the archive, which is like massive trump-everything-priority
<jdong_> Kamion: do you see any need/possibility to change the way Backports is being handled?
<jdong_> i.e. have multiple people be able to push builds
<tseng> jdong_: if the archive and buildd are controlled by LP it could be done by authorized groups
<tseng> jdong_: we just need to get there.
<jdong_> tseng:ETA?
<tseng> "massive trump-everything-priority"
<ogra> aside from that it would be nice to have someone from the BP team who could care for packages ... Mez is seen very rarely recently
<jdong_> ogra: what would that take?
<jdong_> MOTU? (here it comes...)
<ogra> jdong_, going the MOTU path to be able to upoad changes and fixes
<ogra> indeed ;)
<tseng> ogra: we cant pull someone with mez's skillset out of our hat
<jdong_> ogra: I've been seriously considering it
<ogra> jdong_, that would be really cool ...
<janimo> jdong_, go for it, there's a TB meeting tonight
<jdong_> janimo: what time?
<StevenK> Whee.
<ogra> since if you need to do changes to a package to be able to backport, your team has nobody currently
<janimo> nobody knows, but today it is rumored
<StevenK> I wanted to attend said TB meeting.
<jdong_> lol
<jdong_> I'll be back like 3PM EST to check up again
<jdong_> got class right now
<ogra> yes, someone should put a date on the agenda :)
<StevenK> Yes. Someone Should.
<jdong_> see ya later, guys
<ogra> mjg59, Keybuk ?
<StevenK> I hope it isn't on at 1am local time like the CC meeting was.
<zakame> evening all! :D
<zakame> when's the TB?
<ogra> zakame, thats what we're wondering
<\sh> damn..slept again
<StevenK> 'At some point' is the best we've all come up with.
<zakame> ogra: well, I got news from the wiki that it's not decided yet...
<ogra> zakame, thats not *news* :)
* StevenK curses his hiccups.
<zakame> ogra: err, right :))
<ogra> heh
<ogra> StevenK, hey, we already are at the "its today" point at least ;)
<StevenK> It's today by what timezone?
<ogra> apparently one the TB can bear 
<StevenK> Like what, GMT-5?
<ogra> all currently available TB members are in europe
<StevenK> Wonderful. Leisurely afternoon TB meeting, meanwhile it's 2am in .au
<StevenK> .. do I have to attend the TB meeting, like the CC meeting?>
<StevenK> s/\>//
<ogra> thats up to you ...
<StevenK> Well, it's more with the CC meeting if you don't turn up, nothing happens wrt you. Is it the same thing for the TB meeting?
<ogra> oh, janimo goes for main !
<ogra> wow
<ogra> StevenK, yup
<\sh> ogra: xubuntu needs it :)
<janimo> yes
<janimo> :)
<ogra> if you want something from the TB, you should show up
* ogra crosses fingers for janimo 
<janimo> ogra, thanks :)
<ogra> tseng, why do you apply to ubuntu-dev ? 
<ogra> you are already in there
<tseng> i was in coredev and motu
<tseng> and noticed everyone else was in ubuntu-dev
<ogra> and coredev is a member of ubuntu-dev
<tseng> dunno what the difference is
<tseng> (oh)
<tseng> that explains it
<ogra> coredev is main, ubuntu-dev is universe (MOTU)
<zakame> hehe
<pitti> doko: oowriter seems to be broken, it can't find /usr/lib/openoffice2/program/soffice.bin; any idea?
<Kamion> jdong: multiple people> as tseng said
* StevenK wonders if libwnn6 in Dapper has gone.
<StevenK> s/if/where/
<doko> pitti: oowriter2
<pitti> doko: yes, that's what I mean
<thierry> seb128 : my malone bug 3947 should be rejected right?
<doko> works for me
<pitti> doko: it looks for /usr/lib/openoffice2/program/soffice.bin but there is only /usr/lib/openoffice2/program/soffice.bin.real
<seb128> thierry: correct
<doko> pitti: not for me
<pitti> doko: I'm on amd64, you?
<pitti> doko: do you have a /usr/lib/openoffice2/program/soffice.bin.real?
<pitti> doko: if you have soffice.bin, in which package is it?
<doko> ahh, amd64 -> Mithrandir ;-)
<doko> should be -core
<pitti> /usr/lib/openoffice2/program/soffice.bin
<pitti> umgeleitet durch ia32-libs-gtk zu: /usr/lib/openoffice2/program/soffice.bin.real
<pitti> Mithrandir: (^ that's a diversion)
<pitti> Mithrandir: but oowriter2 still looks for soffice.bin
<Mithrandir> there should be a soffice.bin put in there
<Mithrandir> do you have ia32-libs-gtk installed?
<pitti> Mithrandir: no, I haven't
<pitti> Mithrandir: I just aptitude install openoffice.org2
<pitti> so the dependency is missing?
<pitti> Mithrandir: btw, calling soffice.bin.real works just fine here, even without ia32-libs-gtk
<Simira> any dates for distro-sprint yet?
<Simira> official?
<Nafallo> baah, libopenal0 still wants libsmpeg0c2. rebuild anyone? ;-)
<Mithrandir> pitti: you probably had it installed in the past and there's a bug in the postrm, then.  Please file a bug.
<pitti> Mithrandir: yes, I clean up my packges from time to time to save bandwidth, and aptitude dependency tracking could have killed it
* rob^^^ is absolutely astonished that gnome's usability list managed to avoid a massive flamewar from Linus' posting. Kinda makes you feel all warm inside.
<Keybuk> pitti: your sudo test thing was discussed at the last TB meeting, right?  You don't want to discuss it again today?
<pitti> Mithrandir: done
<pitti> Keybuk: it seems that my argumentation for supporting local sudo configuration didn't find any supporters, so, no
<Keybuk> no you don't want to discuss it?
<pitti> Keybuk: the current compromise works for the common default case and breaks for customizations, but it is safe to implement
<Keybuk> ok
<pitti> right, I don't plan to discuss it again, unless you want to?
<Keybuk> just updating the agenda, it was never removed
<pitti> oh, sorry
<doko> Keybuk: why is there no python-docutils merge bug report?
<Keybuk> doko: should there be?
<mvo> Keybuk: while we are at MoM, the aptitude merge looks a bit odd
<doko> Keybuk: last debian version at Sat, 27 Aug 2005
<doko> so yes
<Keybuk> mvo: looks fine to me
<seb128> infinity: could you kick eel2 build?
<Keybuk> doko: oh, right, no .orig.tar.gz for it
<Keybuk> doko: elmo's forgotten to fix that, I guess
<Keybuk> dpkg-source: error: file python-docutils_0.3.7.orig.tar.gz has size 625773 instead of expected 679649
<Keybuk> hmm
<Keybuk> looks like the two origs are different, mom can't process that
<jimygc> hi
<jimygc> got a question, maybe anyone can help
<jimygc> I'm programming an app through traditional c. How should I do if I want this app to not be able to have more than one instance on the system?
<Gagatan> use a lockfile?
<doko> Keybuk: anyway, filing a bug report for those cases would be useful
<doko> we just miss these during merges
<jimygc> I've been reading about semaphores and threads, which loos quite similar to what I need, as I might need as well to pass the first argument from the second one to a function of the first one
<jimygc> yes gagatan, I've tought on that as well, I'm just asking myself how a proffesional handle this
<Gagatan> jimygc: e.g. /var/run/<yourappnamelockfile> and test if it exist. You will have a problem with existing lockfiles if your app doesn't clean up 
<jimygc> and what about of catching the first argument to be passed to a function of the existin instance?
<Keybuk> doko: what would the bug say?
<jimygc> Gagatan?
<Nafallo> Keybuk: "diffrent .orig.tar.gz in debian and ubuntu" ? :-)
<Keybuk> Nafallo: then I'd get a hundred questions each week of "what do I do about it?"
<doko> Keybuk: new version in debian, but cannot generate a diff due to differing .orig tarball's. please merge manually ...
<Keybuk> anyway, mom doesn't know that
<Nafallo> you don't get those already? :-)
<Keybuk> it just knows "cannot generate a diff"
<Keybuk> so you'd get a bug saying "Newer version in Debian that needs merging manually"
<Keybuk> and that would be it
<doko> yes, that seems to be ok
<Nafallo> seems okey.
<Keybuk> I'll look into that for dapper+1
<Nafallo> better than silence and no merged version :-)
<Keybuk> I can generate a manual list a week before UVF for now
<doko> Keybuk: can you give a list of these packages in a short time frame?
<ryanpg> hi all, after a recent update, several gnome apps (alacarte being one) segfault with "gnome_program_init_paramv: assertion `nparams > 0' failed" know issue or "bugworthy"?
<Nafallo> ryanpg: mvo looks in to it atm :-)
<Keybuk> doko: for main, yes
<Keybuk> that's easy
<doko> that would be nice
<mvo> Nafallo: seb128 has apparently already a solution
<Keybuk> it would be "all outstanding merges" though
<Keybuk> including those mom has processed
<ryanpg> Nafallo, mvo cool
<Nafallo> yay! :-)
<Keybuk> which is why I was suggesting doing it when we turn off mom
<Keybuk> so I can filter out those it has processed
<doko> hmm, I just don't want to miss some updates, if it's too late one week before UVF
<Keybuk> the list of things needing updates is easy to obtain
<Keybuk> the list of things that mom has processed that version for is hard
<Keybuk> a rough guess (things mom has never merged) would be:
<Keybuk> bootchart, firefox, libmms, pgtcl, python-docutils, redland-bindings, vim, vino
<Keybuk> at least two of those are indepandantly packaged
<Keybuk> some of those might be just because mom is still running
<Keybuk> I think vim only appeared today
<Keybuk> ok
<Keybuk> manually grepping that list out
<Keybuk> the list of things that mom has never processed are: python-docutils and vino
<Keybuk> oh, wait, vino is packaged separately
<Keybuk> ok
<Keybuk> python-docutils is the only one :p
<Keybuk> (the primary reason I ignore those errors is that they do tend to sort themselves out if you just ignore them)
<pitti> jbailey: do we still need initrd-tools in main?
<jbailey> lamont: Do you still need hppa and ia64 to boot, or can we do without that for a week or two?
<jbailey> lamont: Martin's getting trigger happy. =)
<pitti> Kamion: do you need dash-udeb? the current dash wants dietlibc, but I don't really want another libc in main just for that
<pitti> Kamion: so I'd rather build it against glibc again
<jbailey> There's a dash in klibc as of 1.1.3 as well.
<seb128> mvo: back. About what?
<Keybuk> jbailey: hmm, do they boot now?
<jbailey> Keybuk: Yes.  AFAIK both produced usable dapper CDs.
<Keybuk> if they do, I don't see how we can support them
<Keybuk> because they don't boot anything like the real architectures
<jbailey> Err, what?
<jbailey> elilo's not that weird.
<Keybuk> I assume the initrd doesn't use anything like the same scripts as initramfs
<Keybuk> so the mounting of the root filesystem will be totally different
<Kamion> pitti: dash-udeb is already in universe
<Keybuk> plus udev won't be setup the same way
<Keybuk> etc.
<Kamion> and has been since warty
<jbailey> Keybuk: They're still using 2.6.12
<pitti> Kamion: ah, ok; so I'll build it against libc
<jbailey> Keybuk: It's the same thing we've had all along.
<Keybuk> jbailey: *blink*
<Keybuk> uh, dude
<Keybuk> if they're using 2.6.12, then they can't boot
<Keybuk> because no modules will be loaded
<Keybuk> unless they have everything compiled in
<jbailey> Right, no hotplug anymore.
<Keybuk> right
<ogra__> i'm going mad ... how the hell should i test my isos if i cant brun them to disk ? grrr
<pitti> ogra__: ?
<Keybuk> ogra: mount them?
<jbailey> pitti: Don't demote it to universe, morgue it instead I think.
<ogra__> pitti: in dapper it doesnt work at all ...
<pitti> jbailey: demote what?
<pitti> jbailey: ah, initrd-tools?
<jbailey> pitti: initrd-tools
<jbailey> Right. =)
<pitti> jbailey: how do I 'morgue' something?
<Keybuk> "Dear Elmo, ..."
<Kamion> the normal English verb is "remove"
<pitti> ah, ok
<ogra__> pitti: and apparently my only breezy box i have cant convince my dvd writer to blank the media ... worked on my lappie though
<jbailey> Kamion: I don't think English actually has verbs.  There are just funnily conjugated nouns with implied meaning.
<Kamion> jbailey: you should learn Lojban. :-_)
<Kamion> s/_//
<jbailey> Kamion: (I was actually surprised when I started studying for my GMAT that there is a format English grammar.  I had made it through all of my public education without ever hearing someone mention this.)
<pitti> jbailey: I thought Noam Chomsky totally failed to write down a grammar for English?
<pitti> jbailey: I mean, his hierarchy and his studies of formal languages are invaluable and interesting, they just failed to fulfil his original goal :)
<Nafallo> ogra: works for me. are you using up-to-date dapper or is your /dev/hd? owned by group floppy? :-)
<Keybuk> Nafallo: there appears to be a kernel bug wrt dvd writers
<ogra__> Nafallo: its a usb DVD writer 
<Nafallo> oh
<ogra__> the odd thing is that it doesnt work in breezy either now ...
<mvo> what would be a good (and common) 3rd party repository? I'm looking for some to test changes to gnome-app-install
<Keybuk> ogra: are you sure that your dvd writer isn't broken? :p
<Nafallo> opera? skype? people.ubuntu.com? :-)
<jbailey> pitti: I've never read any of his work.  Neat website, though.
<pitti> jbailey: we already got to know him in the first semester
<pitti> 'Basics of theoretical computer science'
<Kamion> mvo: http://people.ubuntu.com/~jbailey/snapshot/bzr/ ?
* mvo slaps forehead
<jbailey> *lol*
<mvo> Kamion: thanks :) maybe I should have taken a look into my own sources.list before asking stupid^W questions
* jbailey would be curious to see the logs on that repo.
<jbailey> I'd always assumed that noone used it until I broke it one day. =)
<Nafallo> hehe
<mvo> jbailey: how many angry mails did you get on that day?
<pitti> mvo: do you happen to know the bug number of 'gdm must be reloaded to see new locales'? I can't find it
<jbailey> mvo: Like 30, and was swamped enough on IRC that I wound up doing that instead of working for most of that day.
<pitti> mvo: ah, 16678 (langpack-selector changelog); sorry
<mvo> pitti: and it's assigned to me
* mvo cries
<Nafallo> \sh: dude. ALT+F# works in XChat as well :-)
<mvo> jbailey: haha, nice!
<pitti> mvo: with the change to locales that I'll upload soon you should be able to close it
<Kamion> ok, FWIW, we're switching to SimplifiedLiveCD for Flight 2, 'cos the alternatives are Too Hard
<pitti> mvo: oh, well, it'll still break gdmflexiserver
<Kamion> infinity/Mithrandir/me are coordinating that change now
<Kamion> well, I'm testing first before we commit to it
<Kamion> but it seems likely at this point
<Nafallo> Kamion: time to start testing those cds then? :-)
<Kamion> Nafallo: feel free to test the current install CDs, but there is no point at all in testing live CDs yet
<\sh> Nafallo: which is the 2nd way of doing something 
* ogra__ cries 
<ogra__> nothing works :(
<pitti> ogra__: if it helps you, for me neither; the desktop is falling apart into pieces today
<ogra__> pitti: i'm on breezy currently
<ogra__> and things that worked on my laptop before i upgraded it to dapper seem not to work on my desktop 
<ogra__> and i'm out of media, so i need to blank it first 
<Nafallo> Kamion: I'm rather okey with my current install but will be happy to try the new livecds :-). any estimation about when a good .iso is made? :-)
<ogra__> but i only get illegal request errors from cdrecord and dvdrecord
<Kamion> Nafallo: no, not yet
<Kamion> please don't "are we there yet" right now
<Kamion> too busy :)
<Nafallo> hehe, just tell me when it's time then :-)
<Nafallo> ogra: when I got those I called tech. support and explained that the drive would be totally broken in a couple of days. they sent me a new one right away ;-).
<Nafallo> ogra: but hey! that was Targa/Lidl ;-)
<ogra_thin> unbelivable ...
<ogra_thin> n-c-b can blank and write to the disk, cdrecord and dvdrecord both cant
<zakame> ogra_thin: er?
* ogra_thin yays for gnome 
<zakame> wow
<ogra_thin> ah, my mistake
<ogra_thin> i didnt try growisofs ...
<ogra_thin> thats what n-c-b apparently uses 
<Nafallo> n-c-b?
<Nafallo> ah nautilus...
<jdong_> I see the TB meeting has a time now :)
<janimo> ogra_ can't you use qemu to test the images?
<doko> ogra_thin ? that's a contradiction ... ;-P
<pitti> Keybuk: oh, tmpfs for /var/run? Happy package fixing :)
<pitti> Keybuk: many packages create a /var/run/package and rely on it
<pitti> Keybuk: I fixed some in the past, but I'm sure that there are more
<ogra_thin> doko, you mean the nick 
<ogra_thin> heh
<jdong_> would it be a bad idea for me to put the Backports situation up for discussion on the Tech Board?
<jdong_> that is the right place to bring it up, right?
<pitti> lamont: xdelta does not really look well maintained in Debian - is it a package we could safely put into main?
<Kamion> pitti: cupsys-driver-gimpprint fails to install from a current i386 install CD
<Kamion> "cupsd: Child exited on signal 15"
<pitti> Kamion: ah, it's *only* i386? That might explain why it works for me
<Kamion> could be because the locale isn't generated (bug which I'll fix in a moment), but then again maybe not
<Kamion> I have no idea if it's only i386, haven't tested the others
<pitti> Kamion: I'll try it in a chroot, but I need to create one first, so it'll take me a bit
<Kamion> thanks
<zakame> elmo: good evening! please sync meld from Sid, overriding Ubuntu changes ok. Thanks! :)
<Keybuk> pitti: yeah, I'm aware of the need for a mkdir -p in a lot of init scripts
<pitti> Keybuk: I agree to you that it is the right thing to do, though
<Keybuk> well, it's the only thing to do fwict
<Keybuk> we need to have somewhere to put pid files
<Keybuk> and we're starting far more things before the root fs is read/write now
<Keybuk> things like dhcp ;)
<jbailey> Is gdm there yet? =)
<pitti> Keybuk: I already fixed /var/run mkdir for dhcp :)
* jbailey keeps thinking that it would be interesting to hack gdm such that the box in the middle of the screen got replaced with the usplash_write text window.
<jbailey> And then do your 2-seconds-to-gdm hack.  Watch along there for a while and then it gets replaced with your login prompt.
<pitti> jbailey: ... or with a tail -f /var/log* for the geeks :)
<pitti> log/* even
<jbailey> pitti: Right.  For people who want text terminals, it could be an integrated gnome-terminal widget. =)
<pitti> heh
<jbailey> But something ISTR Linspire doing really well in the demo at Debconf2 was that it was reasonably high res graphics from the beginning as if it were already in X.
<jbailey> Max-like.
<jbailey> Mac, even.
<pitti> o links: links
<pitti>    [Reverse-Build-Depends: dictionaries-common] 
<pitti> WTH?
<pitti> people seem to use all kinds of crazy build deps
<HiddenWolf> pitti, isn't it obvious, it's used for spellchecking in the changelog ;)
* HiddenWolf ducks
<Nafallo> lol
<lamont> pitti: xdelta is pretty much unmaintained.  there's an xdelta3, totally incompatible with its predecessors, which has never been pacakged.
<pitti> lamont: two ttf font packages need it as a build dep
<pitti> lamont: they have binary patches in debian/ and apply them; pretty crazy...
<lamont> that's just plain scary
<pitti> lamont: I already rejected the package, FWIW
<lamont> pitti: you're welcome to upload it to debian making yourself the maintainer... :-)
* lamont would reject it for main as well.
<pitti> lamont: no thanks, fabbione already tricked me into becoming an apache 1.3 uploader
* pitti does not want another crappy package  in his DDPO
<lamont> hehe
<seb128> lamont: hi.did you figure what is wrong with glib? is the suse patch I pointed wrong?
<pitti> elmo: can you please sync mysql-dfsg-5.0 into our universe? eventually we want to convert everything to 5.0 and drop 4.0 and 4.1
<Nafallo> hmm
<Nafallo> elmo: could you sync beecrypt (ubuntu override okey) or will this request have to come from a core developer? :-)
<lamont> seb128: been slammed with assigned tasks - haven't actually looked yet.
* lamont heads for the office
<ivoks> am... there is one package (kdevelop3) that is blocking whole kde
<ivoks> it needs only rebuild
<ivoks> is there any reason not to do that?
<Riddell> ivoks: nope, we just need to politely poke infinity I think
<ivoks> Riddell: oh, ok
<Riddell> infinity: please clear dep-wait on kdevelop3
<fabbione> hmm i think we can demode dash in universe now
<pitti> fabbione: several packages still depend on it
<fabbione> afaik the only reason why it was in main was for initrd-tools
<fabbione> pitti: uh? i just purged it and only initrd-tools was complaining
<Kamion> fix hppa/ia64 kthxbye
<fabbione> ah right
<Kamion> initrd-tools is still in dapper for those
<pitti> fabbione: initrd-tools, gcc-4.0, gcj-4.0, linda, localechooser
<Kamion> oh, stupid localechooser build-dep, I'll kill that with my next upload
<Kamion> it's only for syntax-checking
<Kamion> linda's probably similar
<fabbione> pitti: not according to apt-cache rdepends.. i don't see gcc or gcj listed...
<pitti> fabbione: I checked with melanie -R
<Kamion> fabbione: rdepends doesn't list build-deps
<fabbione> oh right...
<fabbione> damn B-D
<fabbione> who needs them anyhow :)
<Keybuk> Kamion: there's no particular reason for initrd-tools to be in main, those ports are broken anyway because they still don't have a .15 kernel
<fabbione> Keybuk: hmm yes they do
<Keybuk> they do?  then jbailey lied
<jbailey> Keybuk: In a working state?
<fabbione> lftp ports.ubuntu.com:/ubuntu-ports/pool/main/l/linux-source-2.6.15
<jbailey> I thought they weren't generally working because of non-function initramfs-tools
<jbailey> (lagging phone)
<Keybuk> no idea, I don't care about either of them
<fabbione> it shows me both hppa and ia64
<Keybuk> we shouldn't have initrd-tools in main
<fabbione> Keybuk: i think ia64 is almost fixed
<fabbione> or fixed
<fabbione> it's only hppa lagging that iirc
<fabbione> let's ask lamont when he is back
<Keybuk> the initrd won't start udev, or mount the root filesystem correctly, etc.
<fabbione> ok
<fabbione> new kernel
<fabbione> brb
<fabbione> (hopefully)
<persia> Could anyone recommend where I should file a bug on linux-restricted-modules-2.6.15?  It's not registered in Malone.
<Keybuk> bugzilla
<persia> Keybuk: Thank you.
<ogra__> damn
<ogra__> nfs booting is totally broken it seems
<fabbione> seb128, dholbach: ping?
<dholbach> fabbione: pong
<seb128> dholbach: pong
<fabbione> dholbach: i just finished to upgrade to dapper... and there is a "Network Servers" on my desktop.. it wasn't there before...
<fabbione> i do i kill it
<seb128> fabbione: gconftool-2 -t bool -s /apps/nautilus/desktop/network_visible false
<fabbione> seb128:  thanks.. is that going to be the default for dapper or are you going to kill it in the pkg?
<seb128> will be switching with next upload
<fabbione> ok thanks
<seb128> np
<dholbach> is that too confusing for our users? *duck*
<fabbione> dholbach: eheh 
<pitti> fabbione: btw, how well does your airport extreme work by now?
<fabbione> pitti: it doesn't yet
<fabbione> i managed to see a few pkts going between my AP and the card. that's it
<fabbione> right now i am back to breezy because i need a stable laptop for thursday
<mjg59> Works reasonably for me
<fabbione> to make a presentation
<mjg59> I should grab the latest build and test it again
<pitti> mjg59: but you don't test it on ppc, or do you?
<mjg59> pitti: Not yet, no
<mjg59> But other people have had some success on ppc
<pitti> I'd be interested in getting a sane wireless on the iBook
<pitti> but it's good to know - up to a month ago, I hadn't even think about the possiblity of buying an AE
<mjg59> My PPC is my mail server, so I'd prefer not to test experimental drivers on it
<mjg59> (It's running off USB wireless right now)
<fabbione> mjg59: ah that might be why it works for you.. i am on ppc
<pitti> Keybuk: I want to update libsysfs to 2.0 - will that knowingly break udev?
<pitti> oh, udev doesn't seem to use libsysfs
<Mithrandir> pitti: it has its own copy, iirc
<Keybuk> pitti: nope, won't affect it at all
<pitti> ok
<pitti> Keybuk: out of interest, why does udev use its own copy?
<Keybuk> afaik the version in udev is always newer than the released version
<Keybuk> or they could be just majorly divergent trees
<ogra> woah, thats was an adventure ....
<sabdfl> ogra: ?
<ogra> Keybuk, infinity the initramfs cant nfsmount any rootfs in ltsp anymore ? 
<ogra> sabdfl, if you do an i386 install on a amd64 machine that has already a system on it, the existing system isnt in grub ... and chrooting from i386 to a mounted amd64 partition fails with bash exec format errors 
<ogra> was quite exciting to get into my system again :)
<ogra> Keybuk, did anything change in the nfs code ? i only get rootserver=0.0.0.0 on the thin clients
<ogra> pitti, thanks for gnome-screensaver :)
<pitti> ogra: you're welcome
<pitti> Keybuk: oh, libsysfs changes soname - I guess I wait with that until after flight-2
<pitti> erm, Kamion ^
<mjg59> Robot101: Hello?
<Robot101> hi
<mjg59> Robot101: So it turns out that at_console is basically what we want for dbus crack
<mjg59> Robot101: Suse have a modified dbus that uses resmgr rather than pam_console for that
<mjg59> So it sounds like the semantics are going to vary
<Robot101> you're going to pack your dbus full of grade A crack?
<mjg59> Robot101: That's what I'd like to do
<mjg59> Now I just need to convince pitti
<mjg59> pitti: Hello :)
<Robot101> and drive it across the border out of columbia? :)
<pitti> hm?
<mjg59> pitti: the at_console security policy in dbus is useless in Ubuntu
<pitti> right, we don't use pam_console
<mjg59> How would you feel about helping make it useful? :)
<pitti> what is resmgr?
<mjg59> pitti: Suse thing that does sort of pam_console stuff, but also rather more crack
<pitti> even *more* crack than  pam_console? :)
<mjg59> One of its features is a helper running with access to device nodes. You ask it for a device, it checks if you're authorised, opens it and passes you the filehandle
<mjg59> I'm not suggesting that :)
<Robot101> could we just use utmp or something, or am I being dense?
<pitti> hm, that sounds like a replicated kernel permission system
<Kamion> pitti: yep
<Robot101> wow that *is* crack
<mjg59> For a sensible scenario (and to avoid fast user switching fun), we need to know user->vt mappings
<pitti> mjg59: access to devices like acpi stuff?
<mjg59> pitti: No, like /dev/cdrom
<pitti> mjg59: ah, fgconsole without suid root for X?
<mjg59> pitti: Uhm. No.
<mjg59> pitti: I don't really care about the filehandle stuff, we just solve that with groups
<Kamion> uh
* mvo goes to play hockey
<Kamion> surely the filehandle stuff is there to work around the lack of revoke() in the kernel
<Kamion> groups aren't a solution to something you might want to revoke later
<mjg59> Kamion: Not really, since I don't think it actually revokes them
<mjg59> But it stops you leaving a sgid app to do stuff later
<pitti> why would we want to controll access to /dev/cdrom with something different than a group in the first place?
<mjg59> pitti: We don't. That's an entirely separate sidepoint (you asked what resmgr did)
<pitti> ah, ok
<pitti> sorry
<mjg59> Heh
<mjg59> Ok
<pitti> I'm still a bit unclear about what we are trying to achieve
<mjg59> We need infrastructure to tie VTs to users
<mjg59> Then we just change the at_console code in dbus to check that rather than looking for pam_console crap
<pitti> I don't understand that part; what's wrong with looking at /dev/ttyN?
<mjg59> pitti: Because that's useless in the X case
<mjg59> X owns the TTY, and it's running as root
<pitti> ah, ok
<mjg59> So in the at_console case, we check if the user sending the message is the one who's at the foreground console
<Robot101> random idea: add an interface on the system bus daemon itself which, security policy permitting, gdm could use to update a cache?
<mjg59> Then we can switch g-p-m back to using hal for triggering suspend
<mjg59> Robot101: Seems like unnecessary complexity
<mjg59> And we don't want to tie it to gdm
<Robot101> it could be org.freedesktop.DBus.TellTheSystemBusAboutWhoIsAtTheConsole :P
<mjg59> Easiest thing I've thought of:
<PupenoL> Hello.
<PupenoL> I have created a kernel module package with module-assistant (zaptel-module), my problem is that it ends on /lib/modules/2.6.12 instead of /lib/modules/2.6.12-10-686/, any ideas ?
<mjg59> 1) Get GDM/KDM/whatever to stick the username in a file 
<mjg59> 2) Get the DM to pass that filename to the X server
<mjg59> 3) Get the X server to write the VT number it gets in there
<mjg59> PupenoL: This isn't a support channel, but it's because you're not setting EXTRAVERSION in the build
<pitti> hm, that sounds hackish, but it should work
<mjg59> Beagle is still broken
<PupenoL> mjg59: is that an environment variable that module-assistant can pick up ? (I know about the kernel variable, but supousedly module-assistant should work with the packaged kernel, and not a modified one, maybe my own package is the problem).
<mjg59> PupenoL: No idea, I'm afraid
<mjg59> tseng: Around?
<PupenoL> any other channel you'd recommend ?
<pitti> Keybuk: do you have an idea why /proc/sys/net/ipv4/ip_forward is not controlled by /etc/network/options any more?
<pitti> mjg59: so we would end up with a world-readable, root-writable map X console -> user?
<mjg59> pitti: Yes
<pitti> mjg59: wouldn't that break sudo and the like?
<mjg59> pitti: Then the message will be coming from root
<mjg59> I can't think of a use case that that actually breaks
<pitti> corner cases, as always
<pitti> sudo -u joe app
<pitti> I do that pretty often
<pitti> but not for PM control
<mjg59> pitti: I think that's an impossible to solve case
<mjg59> The point of at_console is to say "Is this user on the console"
<pitti> I agree
<pitti> mjg59: btw, can the output of 'who' be forged in any way?
<pitti> $ who
<pitti> martin   :0           2005-12-13 15:01
<pitti> that looks exactly like what you want
<mjg59> pitti: No, we need the VT
<pitti> ah, right, ssh -X...
<mjg59> pitti: Uh, no - :0 doesn't tell us what VT something is on
<mjg59> And fgconsole gives us a VT number
<pitti> do you actually need the particular VT number?
<mjg59> Yes
<mjg59> Since that's what defines who's on the console
<pitti> mjg59: hm, why not create a suid wrapper around fgconsole then?
<pitti> ah, crap, no
<pitti> just forget that
<mjg59> pitti: Because that only tells us what the foreground console, not which X display it is
<mjg59> tseng: The beagle dependency on firefox isn't tight enough
<mjg59> ** (best:31246): WARNING **: Missing method chmod in assembly /usr/lib/beagle/Util.dll, type Mono.Unix.Native.Syscall
<mjg59> Cool!
* mjg59 upgrades mono as well
<pitti> mjg59: hm, so 'who' tells me that 'martin' is at X server :0, and 'ps aux' tells me that there is a local X server for :0 at console vt7; but I guess that's too unreliable?
<mjg59> pitti: That's based on the command line from X, yeah?
<pitti> right
<pitti> as I said, unreliable
<mjg59> Yeah
<pitti> works in the default case, though
<pitti> and X certainly has a default if no vt is specified
<Robot101> what if the X server is on a different box to the login session? :D
<pitti> mjg59: btw, I don't question that you have thoroughly thought about that problem, I just like to understand why we can't use the alternatives :)
<mjg59> Robot101: The user isn't at the console
<Robot101> mjg59: he is on the X server's machine though
<pitti> Robot101: there wouldn't be a local X server with the same DISPLAY
<mjg59> Robot101: But that's not the machine that the dbus signal would be sent to
<Robot101> mjg59: assuming you've trunked the system bus over X or something :P
<mjg59> Robot101: Once that's done, we'll worry about it
<pitti> Robot101: the existance of an X process with the 'who' display number tells us that this login is local, and the command line tells us the vt
<pitti> oh, phone
<pitti> re
<mjg59> pitti: There's potential raciness
<mjg59> The user could be on a different vt, but start an X server with arguments that make it look like he's on the foreground one
<mjg59> If the pids have wrapped around, we could hit that first
<pitti> mjg59: but then that X server would not run as root (if it's possible to run an X server as normal user at all)
<mjg59> pitti: X is suid
<seb128> Kamion: I've uploaded a new evolution-data-server, if you could accept it/promote the new binaries (soname change for 2 libs)
<mjg59> And you can run it if Xwrapper has been configured accordingly
<mjg59> Which might be a reasonable thing to do, under certain circumstances
<mjg59> We can't trust the command line of an unrelated process for security-critical cases
* Amaranth wonders how a kernel seems to have fallen out of main
<Keybuk> pitti: yeah, it was deprecated in Debian so I decided just to drop it
<Keybuk> pitti: use /etc/sysctl.conf
<Kamion> seb128: ugh, this is a bad time for soname changes, I'm trying to sort out a CD release
<Keybuk> pitti: I haven't got around to the migration script yet, I have it written, but is gonna upload with the rest of s-b
<seb128> Kamion: that will be sorted quickly, one lib has not rdepends out of evo, and the other need a few rebuild
<Kamion> (underlying cause already fixed, that is)?
<Kamion> er
<Kamion> quickly == 30 minutes?
<seb128> hum, no, new evo following, rather 1-2 hours
<seb128> I guess that you can block it the time to do the CD
<Kamion> yeah, I probably will
<seb128> just trying to get moving on GNOME 2.13.3 because I want to get that done and plugins for gstreamer0.10 uploaded this week
<Kamion> sure, I've been hammering away at this release for days and just keep on hitting roadblocks :-/
<Keybuk> I hope I'm not responsible for too many of them :)
<shaya> strange thing, linux-restricted changelog says fglrx will crash 2.6.15, but I have the exact opposite situation, regular ati driver hangs my t42p, while fglrx works fine (besides for now XV)
<dholbach> infinity: if you could give the new gnome-terminal (once it's build) a spin, i'd be happy to hear your feedback
<mdke> Diziet, *nudge*
<Diziet> mdke: Hello.  Just off for a call of nature.  Back in 2.
<mdke> ok
<Kamion> damnit, installation fails due to the network not coming up and something being wrong with archive-copier (I guess)
<Diziet> mdke: Back.
<Diziet> Thanks for your mail, which is a nice explanation.
<mdke> Diziet, hope that cleared it up a bit
<mdke> Diziet, so what is the position on the firefox side, do you know?
<Diziet> So I think from what you say that BreezyFirefoxStartPageTranslation probably didn't happen.
<Diziet> I haven't looked at it myself (the changes aren't in the ffox package as it happens).
<mdke> Diziet, well it certainly didn't happen from the ubuntu-docs side
<Diziet> Hrm.
<mdke> Diziet, i guess it's in the firefox language packs?
<mdke> jbailey, around?
<mdke> Diziet, but we could make it happen :)
<jbailey> mdke: Laggy as always.
<mdke> jbailey, ok, if you have time, we're having a quick discussion of BreezyFirefoxStartPageTranslation
<Diziet> mdke: Yes, it could be, but if so then the .html wouldn't be there and it wouldn't find the file.
<mdke> Diziet, well shall I just try building a package with the files and see if it works on my system?
<Diziet> I wonder if this is related to http://bugzilla.ubuntu.com/show_bug.cgi?id=20763.  (It seems unlikely, but ...)
<Diziet> mdke: It seems unlikely to work.
<mdke> Diziet, ah right
<Diziet> ff has no machinery for looking first for one file and then falling back to another.
<Diziet> That's the thing that we ought to do for localised start page in dapper.
<jbailey> mdke: Is there a summary pag,e or is the discussion here?
<Diziet> So I would say, yes, please ship the .html files and I may be able to make it work.
<mdke> Diziet, but the individual firefox lang packages specify a separate home page i suppose?
<mdke> specify/are able to specify
<mdke> jbailey, yeah, that page on the wiki, i think you wrote it ;)
<Diziet> mdke: They are supposed to, yes.
<Diziet> But if the ubuntu-doc doesn't ship them, and they do specify them, then ff is broken in those locales.
<mdke> Diziet, so to make it work we'd have to ship the html, then you'd have to alter those firefox langpacks?
<mdke> Diziet, well it certainly isn't broken, it works
<Diziet> (excuse me if I seem a bit distracted; I'm having an spi board mtg <--- just over there.)
<mdke> np
<Diziet> But you don't get a German page, obviously.
<mdke> Diziet, no, either it is set to the english page, or it is set to a german page, falling back to the english page if the german one isnt there
<Diziet> No, there is no fallback.
<Diziet> Unless I'm very confused and it's hidden somewhere.
<Diziet> But yes you should ship the German page.
<Diziet> It won't work but at least then it can be made to.
<mdke> Diziet, ok, btw it's clear we're still talking about breezy yeah?
<Diziet> Err, um, no!
<mdke> ok
<Diziet> I think surely that this is too late to fix for breezy.
<Diziet> The change to the default start location is an incompatible change.
<mdke> Diziet, the reason i was asking is that I've been preparing an update for breezy for ubuntu-docs
<ogra> Keybuk, infinity, jbailey, any idea why my thin clients cant find the NFS rootserver anymore in dapper ? i always get rootserver=0.0.0.0 on booting, NFSROOT is set to auto in initramfs.conf
<Diziet> That is, if you change that in the langpack but not in -doc then ff breaks.
<Diziet> mdke: I see.  In that case don't bother shipping the tranlated .html unless it's easy.
<Diziet> I mean, don't bother changing it but don't fork anything to avoid shipping the translated .html.
<mdke> Diziet, it's easy, but I won't do it unless there is a chance of you making firefox see them...
<Diziet> Not in Breezy.
<Keybuk> ogra: nothing I would have broken
<Diziet> Breezy's ff is already groaning under 50kloc of nightmare patches.
<mdke> Diziet, ok great.
<Diziet> Thanks, sorry for confusion.
<dilinger> woohah
<dilinger> dilinger@jack:~ $ posh
<dilinger> *** glibc detected *** malloc(): memory corruption: 0x08065738 ***
<dilinger> Aborted
<Diziet> Could you c&p this and put it in an email ?  If not I'll do it later.
<ogra> Keybuk, hmm, its quite strange ... since the config of all services is the same as in breezy ...
<mdke> Diziet, sure
<Diziet> Just so we have a record of the decision and the reasons.
<dilinger> i should go make fun of Clint a bit
<mdke> Diziet, last thing. for dapper, the new version of the doc isn't translated.
<mdke> Diziet, but I can upload some translated html anyway for testing purposes, if you like
<mdke> with the old text
<mdke> that way, you can see if you can make ff see it in dapper
<Diziet> That would be very sensible, yes.
<mdke> Diziet, ok, thanks v much
<Diziet> When you do that file a bug against firefox, P1, to tell me you've done it.
<mdke> Diziet, sure ting
<Diziet> I'll try to get it in my next upload then.  Or downgrade the bug if it's too hard :-).
<mdke> :)
<Keybuk> ogra: the right network card module is loaded, right?
<mdke> dholbach, go ahead and upload [breezy-updates]  ubuntu-docs when you're ready please :D
<ogra> Keybuk, yes, the system bots absolutely fine until it wants to mount its nfsroot from 0.0.0.0
<elmo> dilinger: at least you can be sure it's posix certified corruption
<dilinger> hah
<dilinger> elmo: great!
<ogra> Keybuk, and since the nfsroot should be determined inside the intiramfs somewhere if set to auto, it must be a change there thats responsible
<Keybuk> right, blame infinity ;)
<Kamion> damnit, I'm going to have to inflict pure evil on apt-setup again
<Kamion> I was hoping to have got rid of that workaround but apt is too stupid
<ogra> Kamion, grub didnt pick up my installed system on my test install here... known ?
* dilinger hums the Blame Infinity song
<Kamion> ogra: no, file a bug with a description of your system and with /var/log/installer/partman and /var/log/installer/syslog attached please
<Kamion> on grub-installer for now
<ogra> oki
<Mez> ogra: didnt edubuntu have some sort of "filtering proxy" in it ?
<ogra> nope
<ajmitch> morning
<ogra> i'm deeply looking into willow for the next rlease, but no promises 
<Mez> ogra: was it planned or something
<Mez> willow ?
<Mez> hmm
<Mez> looking at a program called censornet at the moment - based around debian - but breaks SSH with windows and breaks completely if you apt-get upgrade (cause it was built on woody)
<Loevborg> Are there instructions somewhere for debugging (and filing bug reports on) suspend-to-disk crashes?
<ogra> Mez, it requires a high level of configurtion and the existing solutions even require to keep recent urllists ... we cant take such a maintenance burden ... willow works with bayesian filtering and teachjes itself, so that might be an option fo the latter
<Mez> hmm sounds confusing
<jbailey> seb128: Is "Shared Libraries" Really  Bibliothques Partages  ?
<seb128> jbailey: correct
<seb128> why?
<jbailey> It just seemed like too literal of a translation.
<seb128> s/P/p/
<seb128> we don't capitalize every word :)
<jbailey> Right, it's not a proper name here. =)
<pitti> yay my network
<PupenoL> Sorry to bother you again, but I am really lost here...
<PupenoL> I am using apt-ftparchive to make a repository, I configured it like: BinDirectory "ubuntu/breezy/rs/" { Packages "ubuntu/breezy/rs/Packages"; } and I get the error "E: Could not open file ./ubuntu/breezy/rs/binary-i386/Packages.gz.new - open (2 No such file or directory)". Why is it tring to access binary-i386 ? my packages are not there. Or how can I tell dpkg-buildpackage to store them there ?
<pitti> mjg59: sorry, I got disconnected a while ago
<pitti> mjg59: btw, Xorg is not suid in dapper
<mjg59> pitti: X is
<pitti> I see
<pitti> mjg59: how would your approach cope with the PID file race?
<mjg59> pitti: It wouldn't involve pid files
<mjg59> But I'll need to think about that a little
<Keybuk> mjg59: #ubuntu-meeting
<mjg59> Keybuk: Sure
<mdke> Diziet, ok I've updated https://wiki.ubuntu.com/BreezyFirefoxStartPageTranslation?action=show, will that be good enough or do you want an email too?
<pitti> mjg59: anyway, I would be fine with the way you proposed, I'm just desperately trying to avoid the big effort that this solution would require
<mjg59> There's not a lot required
<Kamion> dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext
<Kamion> hmm
<elmo> Kamion: how careful do I have to be about removing NBS kernel images?
<Kamion> elmo: go for it, we've finished this week's kernel transition
<elmo> but in general I should ask?
<Kamion> nah, we never release CD images when the archive is part-way through a kernel transition
<elmo> ok
<Pygi> heh, Kamion, you here? ;)
<Kamion> Pygi: yes
<Pygi> ok, so when can I finaly start contributing to the UbuntuExpress? ;)
<Kamion> Pygi: I haven't been talking to you about ubuntu-express (now called espresso) because there isn't much to talk to you about yet
<Pygi> so it's still not in coding phase?
<Kamion> I've been too busy with other stuff like the CD bootloader changes and all the 2.6.15/new-udev work, and work on espresso has only just started
<Pygi> ah,ok
<Kamion> it's in coding phase, but not in a state where it's useful for anyone else to contribute yet really
<Kamion> I'm working on all the prerequisites, like .debs of various pieces of d-i that Espresso will call
<Pygi> kk, does a new wiki page for the project exists or?
<Kamion> some of that's in the archive already; you may have seen espresso-utils and os-prober arrive
<Kamion> no, I'm adding status updates to the various existing UbuntuExpress/* pages on the wiki
<Kamion> I don't really intend to go through the busywork of renaming all the pages
<Kamion> I've been completely blocked lately because we haven't had a working live CD to test things on
<Kamion> we've been sorting much of that out today, although the result is still very raw
<Kamion> (http://wiki.ubuntu.com/SimplifiedLiveCD)
<Pygi> no problem, just please tell me once it's ready for outside contribution
<seb128> Kamion: how is the CD build going, should we hold uploads for now?
<Kamion> I then have to release Flight CD 2, and only then can I actually get back to Espresso development
<Kamion> seb128: please hold uploads, yes, I'm trying to figure out why X broke
<Kamion> and whether the impact is widespread
<Kamion> testing the current install CDs would be appreciated; they aren't final but nearly so
<Kamion> Pygi: sure
<Pygi> Kamion:kk,thanks
<ogra> Kamion, X worked here in my recent install 
<zul> jbailey: you are going to be here later correct?
<ogra> Kamion, it doesnt with my thin client with the trident card ...
<Pygi> just as a thought, anyone here working on fixing the "keyboard layout change" bug?
<Kamion> "keyboard layout change"?
<jbailey> zul: No, Angie's got a video that I'm helpign with tonight.
<Pygi> Kamion: yes
<Pygi> once you add "Croatian" as your default layout for instance, whatever you do, it refuses to use that layout
<Pygi> change in xorg.conf, and then restart of X server
<Pygi> it asks you what layout you wanna use because there is a mixup (use X setting or Gnome), then you choose Gnome and everything works fine from then on
<Kamion> oh, that I have no idea about, sorry
<Pygi> but this is not a convinient way for new users
<Pygi> kk
<zul> jbailey: cool..no problem...i know when im not wanted ;)
<janimo> elmo, please add jani@ubuntu.com to main uploaders when you have time, I just got approved in #u-m. thank you
<elmo> janimo: send mail to the address listed in the wiki
<janimo> ok
* janimo goes to find that page in wiki
<ogra> Uploads ;)
<janimo> ogra, thanks :)
<janimo> hmm, upload@ubuntulinux.org ?
<ogra> yup, i think so ...
<Kamion> s/ubuntulinux\.org/ubuntu.com/g
<ogra> hmm, then the wiki needs an update 
<ogra> janimo, would you ? while youre at it ? 
<janimo> I am editing right now ;)
<ogra> thanks :)
<janimo> ogra, does REVU new package policy apply to main as well?
<janimo> do I need two MOTUs to endorse packages?
<ogra> janimo, not really ... 
<janimo> great! 
<ogra> but its more safe if you feel unsure about a package to ask someone
<janimo> now I won't have any excuse for being slow ;)
<janimo> yes, the new packs are mostly clones of kubuntu/edubuntu art/doc stuff
<janimo> nothing dangerous ort complicated
<ogra> but note that new packages always enter universe first :P
<janimo> hmm I didn;t know that
<Riddell> Kamion: are there any plans for a flight-2?
<ogra> they are staging up through main inclusion reports and anastacia with more or lees manual work of outhers involved
<Kamion> Riddell: working on i
<Kamion> t
<Kamion> testing tonight would be good; I'll build you a new Kubuntu install CD now
<ogra> Riddell, he doesnt even sleep anymore ... or if he does he dreams of gfxboot themes i guess :)
<Kamion> I can assure you my wife makes me sleep
<ogra> :)
<Mez> hmm
<Mez> where was that guide for makeing your own livecd ?
<tseng> LiveCDCustomizationHowto
<Kamion> 6501 N   Dec 13 Ubuntu Archive  (  48) Accepted db4.4 4.4.16-1 (source)
<Kamion> oh you have to be kidding, not another one
<pitti> aaaargh
<fabbione> LOL
<Pygi> hehe
<pitti> and *of course* it changes log file format again
<Pygi> heh
<sivang> pitti: what's that ? :)
<pitti> sivang: an evil, incompatible mess of database drivers you don't actually want to know about :/
<sivang> pitti: that bad?
<Pygi> really bad ;)
<pitti> sivang: yes, as soon as you have apps that use db transactions, i. e. you cannot build them against the latest db
<sivang> bah
<Pygi> hehe
<sivang> hmm
<sivang> Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/dapper/universe/binary-i386/Packages.bz2  MD5Sum mismatch
<sivang> Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/dapper/main/source/Sources.bz2  MD5Sum mismatch
<sivang> is that known?
<jdong> lol, deja vu from #u-m :)
<sivang> jdong: eh, something I am doing wrong?
<pitti> this kind of mirror breakage is pretty common
<jdong> lol, nothing, just that mirror breakage was just discussed
<sivang> ah, right :) I though #u-m == #ubuntu-motu
<sivang> maybe I should switch mirrors
* sivang dropps and falls asleep
<seb128> Kamion: in fact the new e-d-s is to the archive now, so I should upload the packages that need to be transitionned , right?
<Kamion> seb128: oh, yes please, I should have asked elmo to hold that in NEW
<Kamion> sigh, oh well
<elmo> urgh, sorry
<slomo_> elmo: please sync lesstif1-1 from debian/unstable... ubuntu changes can be dropped
<greenpenguin13> am i the only one that's had their screen resolution change after those updates?
<greenpenguin13> my screen looks like 800x600 but it says 1280x1024 in xorg.conf
<greenpenguin13> how odd
<Treenaks> greenpenguin13: what does /var/log/Xorg.0.log tell you?
<greenpenguin13> err...
<greenpenguin13> (WW) Warning, couldn't open module GLcore
<greenpenguin13> ah here we are
<greenpenguin13> (II) NVIDIA(0): Not using default mode "640x350" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "320x175" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "640x400" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "320x200" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "720x400" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "360x200" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "640x480" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "320x240" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "640x480" (vrefresh out of range)
<greenpenguin13> (II) NVIDIA(0): Not using default mode "320x240" (vrefresh out of range)
<Treenaks> greenpenguin13: DONT PASTE HERE
<greenpenguin13> and so on
<Treenaks> *cry*
<fabbione> greenpenguin13: you want to ask in #ubuntu
<greenpenguin13> lol sry
<sivang> guys, this is probably a #ubuntu issue, no?
<fabbione> this is not a support channel
<Treenaks> greenpenguin13: please please please use #ubuntu and a paste-bin
<Pygi> Penguin, please don't flood 
<greenpenguin13> yeah
<sivang> also, forums
<Treenaks> sivang: eek?
<sivang> Treenaks: hmm, did I say something wrong?
<mdke> sivang, no
<mdke> a good suggestion
<Treenaks> sivang: no, but I'm still a bit scared of the forums
<Treenaks> (but I have that for most forums)
<mdke> forums are a good way to get support, better than irc
<Treenaks> mdke: depends on the forum :)
<mdke> and the irc, yes
<Nafallo> elmo: please sync util-vserver from debian unstable (ubuntu override okey) :-)
<sivang> mdke: I've had some folks starting to translate some very good stuff there to hebrew :)
<sivang> that's why I suggested it
<sivang> it apepears to have some nice solution for part of the issues
<mdke> sivang, hebrew translation |= nvidia support, but still, that's cool
<sivang> mdke: well, not *about* hebrew translations, but translating to hebrew some support replies there :)
<mdke> ah i see, cool
<Kamion> Riddell: you have new Kubuntu install CDs - please test
<Kamion> Riddell: let me know if the boot screen looks funny
<sivang> anyway, I fall asleep for real now..night..
<ogra> Kamion, bootscreen was cool for edubuntu bte with yesterdays image
<ogra> *btw
<ogra> especially being able to install with 1024x786 is very impressing
<ogra> i only had locale probs and a broken install due to the postgres breakage resulting from this
<Kamion> ogra: excellent; yes I like the easy support for different video modes too, that was a sort-of-unexpected bonus
<ogra> Kamion, is the locale prob solved in todays image ?
<Kamion> the background is just the usplash image run through 'convert -extent 640x480' at the moment
<ogra> note that i dont need any manually built ones 
<ogra> i wont test tonight anymore
<Kamion> ogra: solved but I don't think I've built Edubuntu since; it took a while because I didn't notice localechooser FTBFSing
<ogra> Kamion, i'm fine with the normal cron job, dont care about me
<Kamion> normal cron job's disabled for now actually, I'll just fire off a rebuild for you
<ogra> i'll start my rsyncs before bed and will be fine with testing toimorrow
<Riddell> Kamion: thanks, downloading now
<jdong> aww, why'd the Dapper splash revert?
<greenpenguin13> i was getting fed up of the old dapper spash :p
<ogra> jdong, because mjg59 had to many offers from art galleries whanting to buy it
<jdong> ogra: oh, I can imagine so :)
<ogra> ;)
<McFergus> libavahi-bonjour-howl is already in Dapper ?
<mdke> McFergus, packages.ubuntu.com
<McFergus> sorry
<mdke> McFergus, no problem!
<jdong> or madison-lite if you really wanna be up to the minute! LOL
* Kamion hopes all that e-d-s stuff builds - current livefs builds fail :(
<jdong> wow, that apt-get dist-upgrade really screwed up my Dapper :)
<dholbach> jbailey: could you give the new gnome-terminal a spin and see, if your use case works now? :)
<ogra> Kamion, didnt you call for an upload stop ? 
<\sh> elmo: ping
<Kamion> ogra: ideally I'd like safe uploads that don't change package names only at this point
<ogra> oh
<\sh> elmo: you synced glabels today, but not jabberoo or istanbul...was there an issue with it?
<\sh> infinity: and thx for debian/dirs :) I missed that really 
<jdong> any objections to a backport of gedit 2.13.0?
<seb128> I'm away for ~1hour, will fix the eds issues if there is one then, but everything builds fine for now (evolution-exchange will just need a retry when evolution is built)
<seb128> bbl
<ogra> does a .13 version make sense ? 
<jdong> ogra, I asked the same at first, but what could POSSIBLY go horribly wrong with a TEXT EDITOR that one wouldn't notice after a few hours of testing?
<dholbach> jdong: lots of internal changes, new build-depends - it's the unstable release
<Tm_T> any known issues/anything to test with 15-8 kernel?
<ogra> jdong, thats a development package, might have unknown bugs
<dholbach> first unstable release
<jdong> dholbach: ok, so not a good idea then :)
<dholbach> jdong: no, i did the update and there were quite a lot of changes :)
<ogra> jdong, in any case you would have to update it later to a stable version
<mdke> but... i thought all backports come from the unstable release
<jdong> ok, thanks for letting me know
<jdong> mdke: but not necessarily all unstable releases
<mdke> isnt that part of the bargain
<jdong> mdke: i.e. stable package versions hitting Dapper
<ogra> so it would require some maintenance work even if it built finbe for now
<mdke> jdong, ah sure
<jdong> mdke: I tend to stay far away from GNOME related stuff in main :)
<\sh> mdke: gnome is following ubuntus release cycle...so 2.14.x will be in ubuntu...so backporting 2.13 is not a good idea ,)
<mdke> \sh, i don't follow that, but i don't know much about backports anyhow
<jdong> ok.... CTRL+ALT+BKSP zaps vmware ALONG with the host's X :)
<Nafallo> elmo: please sync php4-idn php4-imagick from debian unstable (ubuntu override okey) :-)
<jdong> elmo: what are all the *-given-back.gz failures in buildLogs?
<Nafallo> elmo: ...and thanks for util-vserver and co. :-)
<jdong> it seems to be happening with more than Backports builds, actually
<jdong> do the buildd admins know about this?
<azeem> jdong: yes, that's their job
<jdong> excuuuuuse me for asking :)
<jcole> a floppy image, lol... can som
<jcole> uh
<jcole> how can i install ubuntu via floppy? i have an old laptop that has no cdrom drive in it... i did an "apt-get source debian-installer" on another machine and trying to figure out how to build a floppy image, lol... can someone please point me to a doc?
<seth_k|lappy> jcole, #ubuntu is where you want to ask
<lathiat> McFergus: not yet, but will be
#ubuntu-devel 2006-12-11
<exlt> I've been searching for why a blacklisted module is still loaded, even though it is listed in /etc/modprobe.d/blacklist - I can unload it manually fine - this worked in 6.10, however is not working in feisty
<exlt> $ grep pcspkr /etc/modprobe.d/blacklist
<exlt> blacklist pcspkr
<exlt> $ lsmod |grep pcspkr
<exlt> pcspkr                  4352  0
* exlt just read topic - sorry
<Kano> hi Riddell , are you here
<Kano> ok, will come back tomorrow...
<infinity> Wow, this is special....
<infinity> apt has suddenly decided I don't have anything installed.
<Burgundavia> infinity: it loves you
<Burgundavia> I had my db corrupted the other day as well, first time ever
<infinity> It's rather odd, since dpkg is fully aware of everything being installed, but apt claims nothing is.
<infinity> What did you need to force it to regenerate to fix it?
<infinity> Oh, perhaps the pkgcache.bin
<infinity> Yup, that fixed it.
<infinity> Weird.
<Solarion> can someone help me figure out why gnome-cups-manager refuses to set the cups printer properties?
<Solarion> *something* is hosed.
<somerville32> See #ubuntu for support :] 
<Solarion> man, I don't want support
<Solarion> I want to debug the bug
<Solarion> no?
<jdong> <whine> will there ever be a scriptable interface to launchpad </whine>
<jdong> clicking on a billion buttons and dealing with $browserlagtime is getting really old now
<LaserJock> kinda depends on what you're looking for
<LaserJock> you can do some stuff with email
<zul> there is an email interface
<LaserJock> it still could use more for data mining kind of stuff
<LaserJock> but you can at least file and change bugs via email
<crimsun> imbrandon: got an amd64/feisty chroot?
<crimsun> sorry, -ECHANNEL
<jdong> LaserJock: how does that work?
<LaserJock> jdong: how does what? email?
<jdong> the main things I need to do are (1) change status (2) subscribe ubuntu-archive (3) get a list of bugs for source package foo in ubuntu
<jdong> LaserJock: yeah, the e-mail interface
<LaserJock> well for 1 and 2 you should be able to use the email interface
<jdong> ok, that's a really good start :)
<jdong> how would I do that thru e-mail
<LaserJock> for 3 you can use +bugstext
* somerville32 m
<LaserJock> jdong: https://help.launchpad.net/UsingMaloneEmail
<LaserJock> jdong: for 3 us https://launchpad.net/distros/ubuntu/+source/<foo>/+bugs-text
<jdong> LaserJock: cool. Is there any way to filter that bug list
<jdong> LaserJock: I am only interested in open ones
<jdong> or are those open ones
<LaserJock> no, there is an LP bug open about that I think
<jdong> hmm
<jdong> I'd rather not bombard launchpad by scraping every single ticket it tells me about
<jdong> and is there a way to retrieve a bug in text?
<jdong> the url you gave simply lists all the bugs
<jdong> and I've tried a few permutations of that
<LaserJock> that's all I know of
<LaserJock> but #launchpad might have better answers
<jdong> ok
<iambob> does ubuntu supports parallel startup of services ?
<LaserJock> jdong: just getting a plain text copy of the bug from some url would help
<jdong> LaserJock: that's exactly what I need
<jdong> I can use some cheap code to parse the rest
<LaserJock> jdong: I'd +1 a bug on that ;-)
<jdong> I'm just trying to build that into a souped-up prevu that presents all the info I need to decide on a backport in one step
<jdong> :)
<jdong> in other words, I'm getting lazy
<LaserJock> bah, I just need to keep track of a lot of packages
<LaserJock> iambob: I really don't know for sure but I don't think yet by default
<LaserJock> jdong: do you know if upstart does parallel service startup?
<jdong> not currently
<iambob> i think it should be a wanted feature... it is supported by windows, mac os and the like... but we need that in linux also
<jdong> it will be able to from what I'm told
<jdong> but right now upstart behaves exactly like sysvinit
<jdong> but it is intended that upstart will soon be able to parallelize
<jdong> iambob: does that answer your question?
<iambob> yes
<Burgundavia> elmo: ping
<Burgundavia> elmo: re -devel-discuss and -news moderator passwords
<dholbach> good morning
<somerville32> dholback: Trinity promised me you'd pay me with a hug.
<somerville32> *dholbach
<dholbach> heya somerville32
<somerville32> Hi :] 
<dholbach> somerville32: oh really? for what? ;-)
<somerville32> He got mad at me sending an MRI review request to ubuntu-devel but then I pointed out that it is in the workflow as described on the wiki
<somerville32> *for
<somerville32> He said he wasn't very good at the hugging thing but he'd get you to give me one the next time he saw you.
<dholbach> MRI? MainInclusionReport?
<somerville32> Yes.
<crimsun> s/Trinity/infinity/g
<somerville32> Gah
<dholbach> ah ok, that's a MIR ;-)
<somerville32> It is 5am here now
<somerville32> I can't be held responsible for typos
<somerville32> <g>
* dholbach hugs somerville32 anyway - which package do you want in main?
<somerville32> xjump
<crimsun> apparently an alarming number of people are addicted to it
<dholbach> uh huh?
* dholbach installs it
<dholbach> . o O { produtivity ~> 0}
<dholbach> ok, addiction won't happen - I'm too stupid for it :)
<jdub> wii!
<somerville32> Who is going to the cc on Tuesday?
<elmo> with any luck the CC will
<Fujitsu> elmo: I find that unlikely, considering their previous record.
<Fujitsu> Or at least not until 30 minutes or so after it starts.
<somerville32> Has the CC lineup changed or is that secret information?
<Fujitsu> It hasn't been put to vote yet, so no.
* Fujitsu notes the lack of Keybuk over the past number of days.
<lfittl> infinity: please give back the build of vdrift, thanks
<somerville32> Gah, the xjump game is hard. :/
<Fujitsu> somerville32: Yeah, it can be.
<Fujitsu> Icy Tower was popular for quite a while at school.
<somerville32> Trippy
<Fujitsu> I think they've modified the algorithms to make it significantly easier than XJump.
<somerville32> I can't make it past floor 9
<Treenaks> I've been to 13
<neuralis> i've made 27
<tepsipakki> 28 :)
<dholbach> floor 3
<dholbach> !
<Fujitsu> 3!
<neuralis> you need to use counter-balance (i.e. don't just jump in one direction). that makes it easier to control.
<dholbach> neuralis: thanks a lot, but I think I don't want to find out ;-)
<neuralis> heh
<somerville32> Someone in Xubuntu made it above 100
<neuralis> i just did 46 on my third try.
<somerville32> Oh god, I got #ubuntu-devel addicted now too
<somerville32> Doh.
<elkbuntu> somerville32, what did i tell you about distracting the developers?
<somerville32> Hobsee is going to get me good now. : (
<elkbuntu> i have her phone number around here somewhere
<PuMpErNiCkEl> Oh god, it's more addictive than tetris. o.O
* thom predicts moonbuggy will be next
<Treenaks> thom: moon-buggy is SO 2003
<Treenaks> (or was it 2002?)
<elmo> 2002
<elmo> if not earlier
<thom> yeah, #u-d seems to be doing the same trends now though :_)
<somerville32> elmo: Burgundavia was looking for you earlier. Did you get a hold of him?
<elmo> somerville32: he sent his request to RT, and it'll get dealt with, thanks
<somerville32> Awesome. :] 
<mvo> Mithrandir: good morning. re sync request #72988. why do we need a changelog if the delta of ubuntu<->debian is empty (modulo changelog)?
<dholbach> hey Tollef
<Mithrandir> hiya Daniel, Michael
<Mithrandir> mvo: a bit unsure actually; It's listed unconditionally in the "Syncs" bit of developerresources, but I agree it's kinda pointless.
<mvo> Mithrandir: ok, thanks. maybe this can be disussed in the next meeting or just changed to exclude packages with empty delta
<Mithrandir> mvo: I think we can just change the procedure, I'll change the ext.
<Mithrandir> text, even
<mvo> Mithrandir: great, thanks a lot :)
<Mithrandir> mvo: actually, I think I'll leave it since it makes a lot more sense after UVF.
<mvo> Mithrandir: right, for UVF that is true. its less important for the other times
<Mithrandir> before UVF it's less important, yes.
<Mithrandir> mvo: https://wiki.ubuntu.com/DeveloperResources#syncs looks good to you?
<mvo> Mithrandir: yes, looks good
<fabbione> cjwatson: when you are around, i would like to look at network-console with you to start working on sparc64-installer.. mind to ping me when you are alive enough?
<cjwatson> fabbione: I'm alive, after a fashion
<mneptok> cjwatson: moin.
<cjwatson> yo
<Fujitsu> Evening, cjwatson.
<fabbione> cjwatson: ok... i think to test nc we will need at least to move it to main.. 
<fabbione> cjwatson: so that i can actually tell anna to load it..
<fabbione> cjwatson: do we need a MIR for such small piece of sshd wrapper?
<cjwatson> yes
<cjwatson> I'll do one
<cjwatson> I already have the seed diff in my tree somewhere
<fabbione> cjwatson: you are too fast for me :)
<fabbione> cjwatson: if you want i can do the MIR and offload you
<cjwatson> it's ok, it'll help me wake up
<Mithrandir> mvo: however, it would be good if you in the future also included the rest of the information, like version number.
<fabbione> cjwatson: ok as you wish :)
<fabbione> cjwatson: afaict network-console is the only one that needs source and binary move to main. all the other sources are in main.. 
<fabbione> cjwatson: i don't think there is any binary that needs shuffling
<cjwatson> 10:14 < cjwatson> untrue
<cjwatson> 10:15 < cjwatson> openssh-server-udeb | 1:4.3p2-6ubuntu1 | feisty/universe/debian-installer | amd64, i386, ia64, powerpc, sparc
<cjwatson> 10:15 < cjwatson> don't worry, I can keep track of this sort of thing myself
<cjwatson> fabbione: ^--
<fabbione> cjwatson: oh right.. yes and i even saw that one :) but the source is in main so it's not a major pain
<cjwatson> indeed, and I've mentioned it in the inclusion report
<fabbione> cjwatson: i was only trying to be somehow so to speak useful :)
<cjwatson> it's not important, but you claimed the opposite so :)
<fabbione> thinko.. becuase i saw it
<fabbione> whatever anyway.. thanks for double checking :)
<cjwatson> I'd already written that part of the report ;)
<cjwatson> MainInclusionReportNetworkConsole, anyway; in the queue for review
<mvo> Mithrandir: ok, sorry for that
<Mithrandir> mvo: no problem, I just got a tad confused about the one which had been synced already.
<cjwatson> so ... any objections to me switching d-i over to using the -generic kernels?
<cjwatson> I was planning to leave the netboot installer on -386
<cjwatson> so that there's still *some* way to install with the -386 kernel, just not by default
<cjwatson> this will free up a bit of space on the i386 CDs because we won't have to ship linux-headers-386 any mre
<cjwatson> more
<Mithrandir> I'm all for anything which gives us more space
<cjwatson> might actually have two netboot builds, one -386 and one -generic; that would work ...
<Fujitsu> Keybuk: Can you please convince MoM that it wants to work again?
<Keybuk> Fujitsu: what isn't working at the moment?
<Fujitsu> It hasn't updated in 4 days.
<Keybuk> so it hasn't
<Fujitsu> It makes merging a little more difficult when you can't easily see what actually needs to be merged.
<Keybuk> it's stuck updating the pool for some reason
<Fujitsu> What fun.
<Keybuk> *kicks it*
<Fujitsu> I've been doing that for days :P
<gnomefreak> mvo: you around? apt is not marking packages with depends issues as held back again
<mvo> gnomefreak: what bugnumber? 
<mvo> gnomefreak: or how to reproduce :) ?
<gnomefreak> havent filed it yet
<gnomefreak> mvo: i just ran dist-upgrade
<gnomefreak> i just woke up so havent gottent o a bug yet i will file one now 
<cjwatson> fabbione: note that os-prober is in bzr, if you're working on it
<fabbione> cjwatson: i am only looking at it for now.. nothing more
<cjwatson> ok, well https://bazaar.launchpad.net/~ubuntu-core-dev/os-prober/ubuntu anyway
<fabbione> cjwatson: but thanks. i will make sure to give you branches in case it needs change
<cjwatson> just commit directly
<fabbione> ok
<gnomefreak> mvo: https://launchpad.net/distros/ubuntu/+source/apt/+bug/75343
<Ubugtu> Malone bug 75343 in apt "[Feisty]  dist-upgrade not marking as held back" [Undecided,Unconfirmed]  
<fabbione> cjwatson: i assume/guess all of d-i is in bzr now...
<gnomefreak> mvo: im gonna see if there is a work around maybe upgrade will work
<cjwatson> fabbione: lots, not quite all
<cjwatson> fabbione: https://wiki.ubuntu.com/InstallerDevelopment has some random witter about this
<fabbione> cjwatson: ok. i will make sure to coordinate uploads with you anyway. 
<cjwatson> sure, thanks
<fabbione> no problem at all
<mvo> gnomefreak: I have a look, thanks. maybe it is related to the recent "Breaks: " changes
<gnomefreak> mvo: only thing that works is apt-get -f install
<gnomefreak> mvo: aptitude might but rather use -f install
<Riddell> Keybuk: is merge-o-matic being updated?
<azeem> Riddell: see 15 minutes ago
<gnomefreak> mvo: i added the output of apt-get -f install so you can see what will be removed/installed
<Keybuk> Riddell: yes
<mvo> gnomefreak: ok, thanks
<gnomefreak> yw
<Riddell> Keybuk, azeem: ok
<Riddell> mvo: I finished my qt-language-selector changes, do you want to review them or do you trust me to merge and upload?
<StevenK> mvo: I wanted to get you to have a look at build failure when you have a spare moment, too.
<StevenK> mvo: It builds fine on Debian, but not on Ubuntu, and I think I've nailed it down to the Ubuntu changes. The package in question is libept.
<Riddell> mvo: screenshots at, https://wiki.kubuntu.org/FeistyFawn/Herd2/Kubuntu, I think the changes make it much more usable
<StevenK> (The Ubuntu changes for apt, that is.)
<Riddell> StevenK: uh oh
<Riddell> StevenK: which ubuntu changes?
<mvo> Riddell: feel free to upload, screenshots look good
<StevenK> I haven't quite pulled it apart, given the patch is 4Mb.
<mvo> StevenK: can you give me the url with the build failure message?
<mvo> StevenK: i.e. were it fails
<mvo> ?
<StevenK> mvo: http://librarian.launchpad.net/5346111/buildlog_ubuntu-feisty-i386.libept_0.4.7_FAILEDTOBUILD.txt.gz
<Riddell> StevenK: libept should be in sync with debian
<mvo> StevenK: thanks, I check it after lunch
<StevenK> mvo: Thank you.
<StevenK> Riddell: It is. *Apt* has changed
<mvo> Riddell: we added support for translated package descriptions, not sure that is available upstream yet
<Riddell> mm
<gnomefreak> mvo: FYI for when you return. using apt-get -f install worked than after that i ran sudo apt-get install <packages that were removed> and after changing a few versions of a couple apps it seems to have worked.
<mvo> gnomefreak: do you have any unusual sources.list?
<gnomefreak> nope i had a koffice repo but got rid of it when 1.6.1 hit feisty repos
<Hobbsee> is this for kubuntu-desktop?
<gnomefreak> but that doesnt explain everything else :(
<gnomefreak> Hobbsee: just upgrade
<Fujitsu> Keybuk: Is MoM likely to be fixed at any point in the near future?
<StevenK> Fujitsu: Bed, huh?
<Hobbsee> ah
<Fujitsu> StevenK: Maybe bed, but maybe not :P
<gnomefreak> mvo: libegroupwise and libexchange-storage changed versions and libgnutls12 is no longer in repos
<Keybuk> Fujitsu: no, mom will never work again
<Hobbsee> Keybuk: why not?
<Keybuk> because I'm clearly not the kind of guy who fixes something when a problem is alerted to him
<Hobbsee> you've written another, super-leet tool for merging?
<Keybuk> (hint: MoM is running now)
<Hobbsee> ah
<Fujitsu> Ah, it takes a significant amount of time to run?
* StevenK teaches Hobbsee about "facetious"
* Fujitsu teaches StevenK about IRC being a text-based medium.
<Hobbsee> StevenK: actually, the lines were probably sent at about the same time
<Keybuk> Fujitsu: yes, hours
* StevenK whispers "Microsoft Comic Chat"
* Fujitsu clobbers StevenK.
* Hobbsee washes StevenK's mouth out with soap
<Fujitsu> Keybuk: Ah, that'd do it.
<StevenK> Eeek
<Fujitsu> Hobbsee: Industrial strength, I hope?
<StevenK> :-p
<Hobbsee> Fujitsu: of course
<Mithrandir> doko: about your ia32-libs-scim ; what about ia64?  I assume there aren't native OOo binaries for that arch?
<doko> Mithrandir: we removed the openoffice.org-amd64 source, so there's no need to keep ia32-libs-scim
<lucas> Question: cd ; touch /tmp/toto ; ln -s /tmp/toto
<lucas> (sans vrifier, sinon c'est trop facile) (A) a marche (B) a marche pas, il faut donner une destination  ln
<lucas> oops
<Mithrandir> doko: oh, ok.
<lucas> wrong channel, wrong language :-)
<doko> Mithrandir: keeping ia32-libs-gtk makes sense because of apps like third party apps like acrobat. not that sure about ia32-libs-kde
<Mithrandir> doko: doesn't acrobat include its own copy of libgtk?
<elmo> Mithrandir: if they do, they're not installed into the right directory
<doko> Mithrandir: or was it skype? not sure, but I remember bug reports asking for the package
<thom> definitely not skype, since that's qt
<Mithrandir> doko: ok; I haven't used skype ever and not acroread since Pentium Pros were the new kids on the block.
* mode/#ubuntu-devel [-o thom]  by thom
<thom> (definitely not skype to the gtk thing)
<Mithrandir> (and iirc acroread used motif then)
<doko> hmm, bug 24942 mentions realplay
<Ubugtu> Malone bug 24942 in ia32-libs-gtk "realplay fails due to gdk-pixbuf not finding loaders." [Medium,Fix released]  http://launchpad.net/bugs/24942
<Hobbsee> j ubuntuforums
<thom> hey, would anyone object to adding mmv to minimal and promoting it to main? it's a stunning 86kb, but hella useful
<Mithrandir> stefg: any reason standard wouldn't be enough?
<Mithrandir> s/stefg/thom/
<Mithrandir> that's quite a typo.
<stefg> heh
<Mithrandir> StevenK: https://bugs.launchpad.net/distros/ubuntu/+source/pouetchess/+bug/72052 ; you seemed to be happy with it, but I'd prefer one of you in the motu-sru team to vouch for the correct debdiff, not just the first one.
<Ubugtu> Malone bug 72052 in pouetchess "MOTU SRU proposal" [High,Unconfirmed]  
* StevenK looks.
<thom> well, standard'd work too
<StevenK> Mithrandir: All done.
<Mithrandir> StevenK: thanks, now I just want it fixed in feisty too before accepting.
<StevenK> Mithrandir: That isn't my issue. :-)
<Mithrandir> StevenK: no, I wasn't trying to ask you either. :-)
* StevenK grins
<Mithrandir> seb128: can you upload a new totem without updated config.{sub,guess}, please?
<Mithrandir> (to edgy-updates)
<seb128> Mithrandir: why?
<seb128> I can probably do that
<seb128> I didn't update them
<cjwatson> "The package difference must be a minimal change to fix the bug. Spurious changes to build systems, documentation, functionality will be rejected."
<ogra> seb128, any news aboiut libgnomekbd ?
<seb128> debian/rules must be doing it
<seb128> ogra: ask to some ftpmaster, it's sitting to NEW 
<Mithrandir> seb128: because I'm going to reject the one in there since it has build system changes.
<ogra> seb128, oh, thanks 
<Mithrandir> seb128: yeah, it probably copies /usr/share/misc/config.{sub,guess} into the source
<ogra> some-ftpmaster, ping :)
<seb128> cjwatson, Mithrandir: ok, I'll hack that out
<Mithrandir> this is usually a good thing, but not for stable updates.
<cjwatson> you can probably avoid that by making the change in a clean unpacked source package and doing 'debuild -S' just once; avoid running debuild in that tree at any other point
<seb128> cjwatson: yeah, I though I did
<seb128> lemme fix that
<cjwatson> well, unless it does it in the clean target, in which case you might be boned and have to do it by hand
<ogra> cjwatson, Keybuk, can one of you un-new libgnomekbd please its holding up gnome screensaver
<seb128> Mithrandir: should I update the version?
<Mithrandir> seb128: same version is fine.
<seb128> ok
<Mithrandir> ogra: I can NEW it.
<ogra> Mithrandir, then do so please :)
<ogra> giskard, any news about ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttthe power manager package ? else i need to package 2.17 myself, we have some apps that rely on patches to 2.17 now ...
* ogra grumbles at xgl for keyboard bugs ...
<seb128> ogra: why do you use xgl?
<ogra> seb128, its the only thing that works on my laptop for beryl/compiz with fglrx
<seb128> oh, you are bling addict now :p
<pitti> carlos: hi!
<carlos> pitti: hi!
<pitti> carlos: is there any ETA for feisty langpacks?
<ogra> well, if we push it in feisty i should know about the drawbacks ;)
<ogra> so i run one machine with beryl :)
* carlos has a deja vu....
<carlos> pitti: I will plan it today with kiko and danilo
<seb128> pitti: I asked him about feisty like one hour ago on #launchpad :p
* pitti hugs seb128, didn't know that
* pitti hugs carlos, too
* seb128 hugs pitti
<pitti> wrt desktop effects, with the current feisty packages I lose all window decorations when I enable the effects -- is that just me?
<StevenK> pitti: Beryl, or Compiz?
<ogra> pitti, i've seen the same in compiz ....
<seb128> StevenK: compiz
<ogra> bery works though
<ogra> +l
<StevenK> I've seen it in Beryl, when you have two copies of Emerald running.
<seb128> do you have the window decorator thing running?
<pitti> StevenK: erm, compiz I believe
<Ng> pitti: it's supposed to start gnome-window-decorator, but I don't appear to have that installed
* pitti just played dumb, installed the three packages mjg59 suggested and clicked on 'enable effects'
<Ng> oh, it's gtk-window-decorator now
<seb128> ogra, pitti: is that ppc?
<Mithrandir> ogra: please ask libgnomekbd upstream to update the FSF address in the GPL headers
<ogra> seb128, amd64 here (with i386 OS)
<Mithrandir> actually, s/ogra/seb128/
* pitti hugs seb128, evolution doesn't crash any more after today's dist-upgrade
<pitti> seb128: no, my amd64 workstation; on the ppc, effects are FUBAR anyway
<pitti> seb128: (way too slow, tinted in blue, no decorations either)
<pitti> Ng: Hm, I do have a gtk-window-decorator binary available
<pitti> and on my amd64 the new nvidia driver doesn't give me the full resolution
* pitti sighs and wants dapper back :-/
<Mithrandir> ogra,seb128: libgnomekbd accepted
<ogra> Mithrandir, TA! :)
<seb128> Mithrandir: thank you
<ajmitch> pitti: you're not alone in losing decorations
<seb128> pitti: oh, it was crashing, backtrace welcome when that happens :)
<seb128> pitti: query BTW?
<ajmitch> & I've got all the bits turned on for xorg.conf that I'm aware of :)
<Mithrandir> ok, it's slightly hard to read a discussion between Sebastien Bacher and Sebastian Breier. :-P
<pitti> seb128: manually calling gtk-window-decorator --replace doesn't help, BTW
<pitti> seb128: crash> probably just due to libraries and evo out of sync; now everything is 2.9 and works again
<pitti> seb128: query?
<seb128> pitti: grumpf, /me not registred
<seb128> pitti: I used Breaks for avoid the out of sync for evo, weird, anyway if it's fixed :)
<Mithrandir> seb128: https://bugs.launchpad.net/distros/ubuntu/dapper/+source/gnome-vfs2/+bug/48579 needs some action from your side, can you do that?
<Ubugtu> Malone bug 48579 in nautilus "Opening remote locations hangs nautilus" [Unknown,Fix released]  
<pitti> seb128: ah, I remember; nice
<pitti> seb128, ajmitch: hmm, after I log out and back in, the effects button is still enabled, but effects are off again
<seb128> Mithrandir: will do, thank you for pointing it
<Mithrandir> dholbach: in some cases, I have backport requests which aren't really appropriate as backports, but rather SRUs.  What's a good way for me to point the motu SRU team to those bugs?
<dholbach> Mithrandir: subscribe  motu-sru  to the bug?
<seb128> gra
<seb128> pitti: do I need a main promotion for libgnomekbd? ;) That's code which was copied to gnome-control-center and gnome-applets which has been moved to a proper library
<Mithrandir> dholbach: sounds good to me.
<cjwatson> SRUs need to be prepared as well as approved in those cases, though
<pitti> seb128: not for my sake
<seb128> Mithrandir: ? (cf what I just wrote to pitti)
<pitti> seb128: to the contrary, that makes sense
<Mithrandir> seb128: if it's just reshuffling of code into different packages, I'm fine with putting it directly in main.
<seb128> Mithrandir: yep, that's moving code copy to a lib, thank you :)
<seb128> control-center Build-Depends on it for a week
<Mithrandir> seb128: I guess you want all the binaries in main too?
<seb128> so it should jump somewhere on the "to promote" list
<seb128> Mithrandir: yes please
<Mithrandir> I'll do that once libgnomekbd is published, then
<seb128> ok, thank you
<Mithrandir> seb128: also, I'm doing archive administration full time those days, but there's so much to do, so little time.. :-)
<Mithrandir> feel free to poke about specific problems like "I need this lib now", though
<seb128> ok, noted, thank you
* seb128 hugs Mithrandir
<giskard> ogra, ping
<ogra> giskard, pong 
<giskard> http://www.buntudot.org/people/~giskard/
<giskard> ogra, i will be away the entire day.. here ^ you can find dsc and diff for gpm-2.17.3
<dinosaur-rus> hi
<dinosaur-rus> is SVN 1.4 going to be packaged?
<ogra> giskard, yay, thanks a lot
<cjwatson> dinosaur-rus: it's on the queue at http://merges.ubuntu.com/main.html, so yes
<cjwatson> (feisty)
<dinosaur-rus> cjwatson, that's good. but is there any way to install it on Edgy? (may be wrong channel for this question)
<cjwatson> ask the backports folks; I imagine there won't be at least until it's in feisty
<dinosaur-rus> heh, I'd better wait until Feisty :P
<dinosaur-rus> thx anyway
<divansantana> hi develepors! :)
<divansantana> please can someone help me!
<divansantana> I am not a developer and not sure what i'm doing. Its quite simple sure someone here can help me
<divansantana> I am trying to rebuild the squid src package to include --enable-follow-x-forwarded-for option
<divansantana> I have apt-get source squid; cd squid-2.6.1; ./configure --enable-follow-x-forwarded-for option
<darek> hi
<divansantana> now how would i make a deb file?
<divansantana> is there a ubuntu doc website for this??
<zul> ask in #ubuntu-motu
<dsas> divansantana: https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html and #ubuntu-motu
<divansantana> wil try
<divansantana> thanks
<bddebian> Heya
<Mithrandir> pitti: we might want to do an SRU to update mailman to fix https://bugs.launchpad.net/distros/ubuntu/+source/mailman/+bug/69760, but that also requires us to backport the security fixes from python's email module to mailman.  How do you feel about us doing that?
<Ubugtu> Malone bug 69760 in mailman "TypeError: iso-8859-1" [Unknown,Fix released]  
<pitti> Mithrandir: pretty intrusive... AFAIR I just put the workaround into -security (intercepting the exception) instead of the new email pacakge
<pitti> Mithrandir: but edgy's mailman should already have the latest email pacacke, or did we forget about this?
<Mithrandir> pitti: unsure, but mailman ships its own copy.
<pitti> right, I mean the internal copy
<Mithrandir> it's probably old
<Mithrandir> or old-ish
<sistpoty> Mithrandir: please don't subscribe motu-sru unless enough info for an sru (as in debdiff, s.o. who will take care for uploading and so on) is present. we only accept/reject sru's but don't do them ourselves ;)
<Mithrandir> sistpoty: I did it after discussion with dholbach 
* sistpoty slaps dholbach
<sistpoty> *g*
<pitti> Mithrandir: ok, I know too little about the mailman guts to say off-hand how intrusive it would be, but in the current state it can't get much worse
<Mithrandir> pitti: heh, ok.
<sistpoty> ping dholbach: can we discuss the "assign motu-sru" briefly? (maybe on -motu)
<Mithrandir> pitti: I'm not very happy about this, but mailman shunts messages into a queue and just logs it without doing any further notification.
<pitti> right, that's evil
<pitti> Mithrandir: but that doesn't seem to affect Dapper, right?
<pitti> Mithrandir: when I did the security update, I did some tests with non-ASCII chars, too, and mail was delivered normally
<Mithrandir> pitti: it affects dapper too.  And breezy, but I don't think I care that deeply there.
<Mithrandir> pitti: non-mimeencoded?
<pitti> hm, weird
<pitti> Mithrandir: not sure, I just tried sending stuff with mutt, which does mime encoding AFAIK
<Mithrandir> sistpoty: from an archive admin POV, what I fairly often come across is "this package is broken, we must backport" in which case the response is almost always "no, you get to do an SRU" and I'd like to ask a useful subset of the MOTUs to do that.
<pitti> or, wait, it might not encode the charset, I gotta check
<Mithrandir> pitti: I think this isn't a problem in that case; it's only a problem if mailman gets unencoded stuff
<Mithrandir> AIUI, anyway
<dholbach> sistpoty: sure
<sistpoty> Mithrandir: but asking motu-sru to do that would be counterproductive for the team: if I work on an sru myself, I don't vote for accept/reject myself, so all other team members would need to vote
<Mithrandir> sistpoty: sure; I asked dholbach for a procedure and he said "subscribe motu-sru"; I presumed that you'd have a procedure you then followed to actually get an update done.
<sistpoty> Mithrandir: hehe... we're just discussing this now on -motu ;)
<dholbach> Mithrandir: ok, then ask the people to write to ubuntu-motu@ about it, so they can discuss and get explanations on how to do it properly
<sistpoty> dholbach, Mithrandir: for the 2 bugs I'll write a short mail to -motu
<dholbach> sistpoty: thanks a lot
<sistpoty> no problem ;)=
<CarlFK> if anyone cares:  http://packages.ubuntu.com   contents, Keyword:  libmysqlclient.so Search - the formating on the results page is tweaked.  
<bSON> hi
<Chipzz> seb128: ping?
<seb128> Chipzz: pong
<Chipzz> seb128: can you rebuild gnome-panel and gnome-applets?
<seb128> Chipzz: I can do that
<Chipzz> they need to be rebuild against libedataserver1.2-9
<seb128> weird
<seb128> I've uploaded gnome-panel some hours ago
<seb128> how did it pick the wrong one?
<seb128> let me look
<Chipzz> seb128: hrrrm, lemme run apt-get update
<Chipzz> but I think I just did that
* Chipzz double-checks
<seb128> maybe it didn't build yet
<seb128> anyway I'll sort that
<jdong> Does dpkg have any plans to switch to an alternate form of compression than gzip?
<jdong> has this been discussed anywhere that I can read up on?
<mvo> jdong: bzip2 is supported since some time and lzma is part of the latest dpkg IIRC
<jdong> mvo: cool, that is sweet
<_ion> Yay.
<cjwatson_> ... but we're only using bzip2 on selected packages because the decompression overhead is comparatively high
<jdong> mvo: so how would one generate a deb with these alternate forms of compression?
<jdong> cjwatson_: yeah, that's understandable
<cjwatson_> dpkg-deb --help | grep -- -Z
<cjwatson_> dpkg-deb --help | grep -A1 -- -Z
<jdong> LZMA on the --fast setting tends to compress similarly to bzip2 but do it about 15% faster....
<jdong> so provided that we can promote lzma to main that might be a future option
<jdong> mvo: will lzma support propagate to Ubuntu or will lzma have to be in main?
<mvo> jdong: lzma support is part of debian dpkg now, so we will get it eventually
<jdong> mvo: cool
<cjwatson_> it would have to be in main to be usable though
<cjwatson_> the bzip2 support just uses the library (statically linked), not the binary; I assume the same is done with lzma ...
<cjwatson_> mvo: are you sure? I don't see it in 1.13.24
<cjwatson> oof, gparted's i18n is painful
<cjwatson> "Create Primre Partition #1 (ext3, 1.99 GiB) on /dev/hda"
<mvo> cjwatson: my data is from "Subject: dpkg 1.13.24 hint and next upload". he talks about two patches he want to upload, one for lzma. I haven't followed from that point on
<cjwatson> might be in revision control but not uploaded, I guess
<mvo> yes, probably
<cjwatson> ugh, they did it by fork/exec not a library
<cjwatson> Mithrandir: question for you in a comment on bug 68243 (I subscribed you after adding the comment, unfortunately)
<Ubugtu> Malone bug 68243 in gparted "manual partitioning still can't create HFS bootstrap partition" [High,Confirmed]  http://launchpad.net/bugs/68243
<mdz> doko: my upgrade in feisty wants to remove g++-3.4 and libstdc++6-dev. why is that?
<cjwatson> Mithrandir: cdimage change in bug 67961 untested; let me know if it suddenly can't find any seeds tomorrow :-)
<Ubugtu> Malone bug 67961 in Ubuntu "use more up-to-date seed mirror" [Wishlist,Confirmed]  http://launchpad.net/bugs/67961
<doko> mdz: it's in universe and you don't have universe enabled?
<mdz> doko: I do have universe enabled, and apt-get doesn't remove packages if they disappear from the archive
<mdz> there seems to be some version skew
<mdz> The following packages have unmet dependencies:
<mdz>   g++-3.4: Depends: gcc-3.4 (= 3.4.6-3ubuntu1) but 3.4.6-4 is to be installed
<mdz>   gcc-3.4: Depends: gcc-3.4-base (= 3.4.6-4) but 3.4.6-3ubuntu1 is to be installed
<mdz>            Depends: cpp-3.4 (= 3.4.6-4) but 3.4.6-3ubuntu1 is to be installed
<mdz> oh, probably skew between the mirrors
<doko> mdz: I could install g++-3.4
<mdz> doko: the US mirror is slightly behind
<doko> works for me
<seb128> Keybuk: what is that "Bugs closed in Debian" about? It lists bugs closed between when and when?
<Keybuk> seb128: "yesterday" and "today"
<Keybuk> it's been going to ubuntu-devel for about a year :op
<seb128> hum
<Keybuk> but nobody's been moderating ubuntu-devel until today, apparently
<ivoks> didn't catch it cause of the noise :)
<seb128> it doesn't look realistic for between yesterday and today :p
<Keybuk> seb128: yesterday = the last Debian day that mom run and didn't crash
<Keybuk> seb128: today = the most recent Debian day that mom ran in
<seb128> could you include those informations somewhere in the mail? ;)
<Keybuk> no
<Keybuk> it's pretty meaningless :P
<seb128> I see
<Keybuk> I should probably just arrange for them not to be sent
<seb128> who cares, that list is moderated once a year anyway :p
<Keybuk> now it's moderated daily
<Burgwork> Keybuk: I used to be moderating -devel
<Burgwork> I nuked those emails and didn't let them through, as per our discussion a month or so ago
<psusi> is there any way to have a postinst step that is run after ALL packages are installed rather than only after that individual one is?
<cjwatson> nothing built into the packaging system
<cjwatson> the feature is known as "triggers", but has never been implemented
<psusi> blast....
<psusi> hrm.. is there a spec for it somewhere?
<psusi> would be nice to have that
<iwj> psusi: No.  I agree.
<cjwatson> it's unclear what the correct thing to do when it fails is
<iwj> It has to be agreed with Debian too, which makes it a bit more complicated.
<iwj> cjwatson: I think I know the answer.
<cjwatson> iwj: oh?
<iwj> I just have to write it up.
<iwj> Treat the package owning the trigger roughly as if its postinst failed.
<psusi> or give the package an option of specifying how it wants it handled
<psusi> some things you don't really care if they fail
<cjwatson> psusi: then the trigger should use || true; no need to build that into the packaging system
<psusi> I just get frustrated seeing a dozen different packages all do an update-initramfs, or rebuild the font cache, and such
<psusi> cjwatson: true
<iwj> psusi: Yes, there are lots of things like this.  With a good spec I think getting it a good priority for implementation will be a no-brainer.
<cjwatson> iwj: would be fun if the package in question wasn't even being configured in the current run
<cjwatson> but I can see that that could work
<iwj> cjwatson: Yes, then you defer it.
<darek> hi
<cjwatson> psusi: (this is why I rejected your post from ubuntu-devel, BTW; it comes under "Ideas and suggestions about future development of Ubuntu")
* iwj goes off for dinner ...
<psusi> really?  that should go on the new list?
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
<cjwatson> yes
<psusi> so a spec needs written for it eh?  maybe I'll give that a go
<cjwatson> psusi: it's preferable to let iwj do it if he already knows what needs to be done
<cjwatson> psusi: I doubt that the blocking issue is writing a specification, anyway
<proppy> infinity: ping
<proppy> hi
<psusi> k
<Mithrandir> cjwatson: 68243> your solution is fine with me
<darek> hi
<Riddell> cjwatson: experimental-qt4-port up and working, should be ready to merge
<Riddell> cjwatson: still a lot of gaps to fill in, but basicly it works
<Riddell> cjwatson: qt 4 doesn't let you have nested mainloops, so I had to set a flag and do while flag: processEvents(), which isn't ideal but doesn't seem to cause any problems
<Riddell> cjwatson: any the xembed of qtparted caused a segfault so I've left that out for now.  no idea why, it works fine in a small test app
<psusi> I am confused.... we appear to have a seperate gnus package for gnus, but the base emacs package also contains ( an older version of ) gnus
<psusi> hrm... wonder if that's a result of upstream
<proppy> infinity: ping
<jdong> apart from using one of the pmount hacks floating around, is there any other way of having ntfs-3g be used to mount ntfs volumes rather than kernel ntfs?
<theBishop> has anyone booted Ubuntu on a PS3 yet?
<jdong> do we support the Cell architecture?
<jdong> maybe Feisty?
<Burgwork> it is in .19
<jdong> Burgwork: that's what I thought
<jdong> so Feisty then :)
<jdong> even then
<jdong> does the PS3 boot like a ppc?
<jdong> or would you need to do a FC5 install then debtakeover it
<jdong> :)
<jdong> what a lovely script btw
<theBishop> it will theoretically boot any PPC distro
<jdong> theBishop: cool
<theBishop> however, it gives you a kboot loader, it doesn't simply boot the CD
* jdong doesn't have a PS3 though
<theBishop> and i can't figure out how to boot the ubuntu installer
<theBishop> i'm riffing on basically this command: kexec -l --command-line="ro root=LABEL=/" -initrd="/mnt/cdrom/install/powerpc/initrd.gz" /mnt/cdrom/install/powerpc/vmlinux
* jdong doesn't want one either... after a close one camped 3 days in hopes of getting me one but failed
<theBishop> aww
<jdong> apparently he didn't get the memo that I don't want surprise presents anymore
<theBishop> it sounds like they are getting shipped every week, if you were serious about getting one, i bet you could
<jdong> theBishop: I really don't need one
<jdong> I don't game
<theBishop> :(
<jdong> and I have enough CPU power to heat my house through the winter
<jdong> it's just... I'm the nerdy tech guy
<theBishop> if you're an Iraqi dictator, you could use one to launch a scudd missle
<jdong> and people struggle thinking of presents that would "impress" me
<jdong> lol as a joke one of my contacts sent me a COA for Vista x64 RTM
<jdong> :)
<theBishop> haha
<theBishop> i'd get Vista... but it probably wouldn't believe i bought it
<theBishop> and lock me out
<jdong> I don't want to spare 20GB to the  behemoth
<jdong> I want my HD space dammit
<jdong> and I've already determined USB installing it is too much effort for my curiousity to justify
<cjwatson> Riddell: thanks
<cjwatson> will have a look
<somerville32> cjwatson: ping
<psusi> shouldn't the mailcap default for text be to invoke $EDITOR rather than force vi?
<psusi> looks like the vi package installs a mime rule to run vi for all text
<psusi> although I guess it might not be good if you have EDITOR=/usr/bin/edit
<infinity> proppy: pong
<cjwatson> somerville32: mail me if you like; I'm going to bed
<somerville32> cjwatson, k
<wasabi> bug 75410   guy's pretty fast.
<wasabi> bug#75410
<wasabi> Gah. What's the trigger for that bot?
<kylem> malone #75410
<Mithrandir> probably just Ubugtu being slow.
<Mithrandir> the first syntax is fine
<somerville32> The bots are experiencing some technical difficulties at this time.
<proppy> infinity: hi, could you trigger the build of two stalled, package in dep-wait ?
<proppy> infinity: https://launchpad.net/distros/ubuntu/+source/poker-engine/1.0.20-1 first
<proppy> infinity: https://launchpad.net/distros/ubuntu/+source/poker-network/1.0.31-1 second
<infinity> proppy: Uhm, I can't magically make the packages it dep-waits on exist...
<proppy> infinity: dholb* tell me you're the human trigger to this thing, if it hang
<proppy> infinity: it already exist
<proppy> infinity: it's just a timing issue
<infinity> If it did, it wouldn't be in dep-wait..
<Mithrandir> hmm, would anybody mind if I disabled the ubuntu-4.10 and ubuntu-5.04 milestones?  Targetting bugs to them now that they're no longer supported would be quite useless
<proppy> infinity: it was synced from debian the 07/12
<proppy> infinity: and the build was triggered the 06/12
<infinity> proppy: I see no python-pypoker-eval in the archive.  Do you?
<proppy> infinity: Missing Dependencies:  	python-pypoker-eval
<Mithrandir> infinity: I synced it yesterday, it's probably stuck in NEW
<proppy> infinity: https://launchpad.net/+builds/+build/265873
<Mithrandir> but given it's past midnight now, I don't think I'm going to do anything about it.
<infinity> proppy: For future reference, dep-waits are auto-cleared when the needed package is in the archive.
<infinity> Anyhow, I'll pop it through the new queue for you.
<proppy> infinity: you mean the build is already triggered ?
<infinity> The build is in dep-wait because its build-deps aren't in the archive yet.  When the build-deps get into the archive (which I'm doing now), the build will retry automatically, yes.
<proppy> infinity: cause poker-eval (which seems to be the dep-waited dedpendencies) successfully build 08/12
<proppy> infinity: https://launchpad.net/distros/ubuntu/+source/pypoker-eval/133.0-2
<proppy> infinity: how ok
<infinity> proppy: Yes, it was built, but it wasn't in the archive, because the binaries were new, and needed manual processing.
<proppy> infinity: ho  ok
<proppy> infinity: i'm sorry to bother you with this, i'm pretty new to the sync process
<proppy> infinity: i don't really now what are the human step and which aren't
<proppy> infinity: thanks
<proppy> infinity: so it was already scheduled to be moved to the archive, cause the build was ok, right ?
<infinity> proppy: In cases like this, there can be some human steps, but thet also don't really require bugging.  We get to them when we get to them.
<infinity> proppy: dep-wait is something that should never require manual intervention, though, unless I wrote the code wrong.
<proppy> infinity: it was just a matter of time 
#ubuntu-devel 2006-12-12
<proppy> infinity: ok, i though i should ping you, because of the sync, that occured *after* the build trigger, which result in a dep-wait status
<infinity> No need.
<proppy> infinity: but i didn't know about the *move to archive* step
<proppy> infinity: i thought that a successfully build automaticly trigger an r-depend build
<proppy> infinity: but it seems to be the *move to the archive* step which does this
<infinity> proppy: It would, if the package was in the archive. :)
<proppy> ok
<infinity> proppy: Like I said, the package didn't hit the archive because the binary was new, and thus required some manual processing.  Normally, this isn't the case, and it's all automatic.
<proppy> thanks for debugging my head :)
<infinity> But we do new processing all day, every day, and don't generally need to be reminded to do so. :)
<proppy> oh ok
<proppy> i just realised why the binary is new
<infinity> ... says Adam, after seeing that queue/new is 75 deep, and makes plans for the morning.
<proppy> cause it changes its name
<infinity> proppy: Right.
<proppy> because of  the new python naming policy
* proppy hugs infinity
<jdong> infinity: did I hear that ubuntu-archive works all day every day?
<infinity> jdong: Pretty much, yeah.
<infinity> jdong: The joys of a distributed team.
<jdong> cool
<jdong> that means the billion backports in approved state will be handled right?
<jdong> lol
<infinity> Eventually. :)
<jdong> :D
<infinity> We have priorities, of course.
<jdong> mmm hmm :)
<infinity> And, more to the point, I have priorities, since I don't have "archive days", like some of the other guys.
<infinity> I just do the stuff that blocks the world.
<infinity> (queue/new, queue/unapproved, etc)
<jdong> infinity: I understand, keep doing what you do :)
<proppy> infinity: you're the savior
<jdong> infinity: and speaking of clearing backports binary NEW... ;-)
<jdong> could a mono deity please comment on if any of f-spot's bugs can be resolved SRU-ly?
<jdong> namely bug 75390 landed in my inbox
<jdong> ahem, ubotu, BUG 75390
<somerville32> jdong: Who are you talking?
* somerville32 doesn't see anyone named ubotu.
<somerville32> :D
* jdong sputters
<crimsun> (ubugtu timed out 22 minutes ago)
<jdong> <ubotu> Malone bug  75390 in edgy-backports "f-spot 0.30" [Untriaged,Unconfirmed]   https://launchpad.net/bugs/75390
* bhale points at ajmitch 
<jdong> there
<jdong> almost as good as the real thing :)
<bhale> meh
<bhale> picasaweb is a rather large chunk of code
<bhale> you could diff the dir and maybe update some api here and there I guess
<jdong> so would you rather have it backported or SRU'd?
<bhale> the problem with that question is the lack of motivation for volunteer maintainers to do SRU on stable releases
<bhale> I dont use stable releases
<jdong> that's what I've been seeing
<bhale> it would be the right thing to do
<jdong> ubuntu-archive tells me to reroute many backports thru SRU, then the bugs just sit there and collect dust....
<jdong> there just doesn't seem to be enough SRU manpower
<jdong> it's even worse when it's in universe territory
<Burgwork> SRUs are basically boring and don't bite many develoeprs
<jdong> yay for boredom
<mc44> plus the fear you could break everything
<jdong> so perhaps Backports should stay with handling everything then?
<jdong> a Backports fix and a SRU fix are pretty exclusive
<bhale> again, SRU is definately "the right thing"
<LaserJock> well, -backports only works if people are using it
<LaserJock> I generally don't use -backports as I'm not interested in updated versions
<LaserJock> but I do use -updates as I want bug fixes
<jdong> LaserJock: that's what I was implying
<jdong> LaserJock: the fact that I release a backport for something doesn't affect the ability of SRU to handle it for everyone else
<jdong> backports has a niche
<jdong> bhale: but it would appear like nobody wants to do the right thing....
<bhale> jdong: I don't..
<jdub> http://ubuntu.wordpress.com/2006/12/11/ubuntu-linux-for-non-geeks-the-book/
<jdub> yg
<jdub> uh
<jdub> that cover is, um, disturbing
<bhale> jdong: the original title of "linux for non-geeks" was "linux for your mom"
<Zober> Im getting the error message: aclocal: configure.ac: 142: macro `AM_CFLAGS' not found in library.  Has anyone seen this before?
<jdub> it's like an educational book about penguins discovering the great bunghole
<bhale> is that like the great pumpkin?
<bhale> of bungholes?
<Zober> has anyone seen this issue?
<Zober> Please?
<jdong> lol, jdub and I should really battle to the death about ^jd.*$ usernames
<bhale> jdong: no offence but jdub has a bit more cred to the name
<jdong> bhale: it was a joke :)
<jdub> jdong: if we're fighting dub vs. dong, somehow i think you win ;)
<jdong> ha
<infinity> cjwatson: Still around?
<infinity> cjwatson: Hrm, probably not, given the time.
<infinity> cjwatson: Do you want to handle the overrides for dmraid-udeb, since it's all installerish and such?  kthx. :)
<lfittl> infinity: got my message about giving back vdrift on the buildds?
<infinity> lfittl: Doing now.
<lfittl> infinity: thanks
* proppy hugs infinity
* infinity feels warm and fuzzy.
<proppy> seeya
<bddebian> Wow, is infinity going soft? :)
<bhale> it is all part of the image
<bhale> goes with the hat
<jdub> auxesis: http://www.engadget.com/2006/12/11/wiisaber-star-wars-kid-do-your-thing/ <-- dork patrol on parade.
<zul> hey infinity 
<jdub> fabbione: ha ha, nice jabber avatar
<xipietotec> just something I thought I'd mention, the language for aptitude/apt-get coming up with unsigned packages is bad...and confusing. It should be something more along the lines of "Continue Anyways? Yes/No
<mardi_soir> hello 
<somerville32> Hello mardi_soir 
<mardi_soir> i have a problem 
<somerville32> mardi_soir, What is your problem?
<Hobbsee> #ubuntu for support, btw
<mardi_soir> to make a deb checkinstall -y give me this http://pastebin.be/4212/
<Hobbsee> checkinstall sucks, dont use it
<Hobbsee> and #ubuntu for support
<mardi_soir> d'accord could you just say what else try  ?
<Hobbsee> nope
<Hobbsee> catn tell what it is
<mardi_soir> .. humf .. really nice .. 
<Hobbsee> sorry, but...
<Hobbsee> mardi_soir: no one in this channel actually uses checkinstall at all
<Hobbsee> so you'd have better luck elsewhere
<mardi_soir> Hobbsee,  i would like just to  know what you use instead 
<Hobbsee> mardi_soir: proper debian packaging.  [16:09]  <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
<Hobbsee> or just compile it
<mardi_soir> ok. 
<mardi_soir> bye
<fabbione> jdub: with love. Fabio
* mneptok floats past a window
* Hobbsee watches as mneptok floats into the hot lava
<Hobbsee> ouch!
<xipietotec> just in case someone didn't catch it the first time...
<xipietotec> just something I thought I'd mention, the language for aptitude/apt-get coming up with unsigned packages is bad...and confusing. It should be something more along the lines of "Continue Anyways? Yes/No
<LaserJock> xipietotec: that's what bug reports are for
<xipietotec> LaserJock: It's not really a bug, it's just bad form...and I don't know how to use the bug report thingy anyways
<Hobbsee> someone can mark it as a wishlist for you
* Hobbsee wonders what it is now
<xipietotec> Hobbsee: It's something similar to this "To continue, type "Yes", to abort, "No"."
* Hobbsee doesnt see anything overly wrong with that.  dont remember that option, either
<xipietotec> maybe It's just me but my first inclination every time I see it (Especially since just typing y or n does nothing) is to see it as "Yes" and "Abort" 
<xipietotec> to mentally I think "Yes to abort"
<Hobbsee> LaserJock: what package would the "my wireless card doesnt resume after hibernate in feisty" bug belong to?  (intel 3945)
<xipietotec> plus it's just a highly parsed up sentence that could be said much easier and more clearly, with fewer letters
<MoronShrek> Edgyw00tH4x0r
<Hobbsee> MoronShrek: are you a troll or what?
<Burgundavia> Hobbsee: geez, don't be so quick to judge :)
<Hobbsee> well, it just seemed like an odd thing to chuck into -devel :P
<Burgundavia> yep
<MoronShrek> hello everybody
<Hobbsee> hey :)
<pitti> Good morning
<LaserJock> morning pitti 
<Burgundavia> hey pitti, LaserJock
<somerville32> Hi :)
* Hobbsee waves to pitti 
<somerville32> pitti: Did you get a chance to review my MIR?
<pitti> somerville32: "your's"?
* pitti hugs the channel
<somerville32> 0_0
* the channel hugs pitti back
<LaserJock> hah
<pitti> Hobbsee: I'm delighted
<somerville32> :] 
<Hobbsee> :P
<somerville32> pitti: It can be yours if you want :P
<pitti> somerville32: I meant, which package? :)
<somerville32> Ah.
<somerville32> xjump
<somerville32> <g>
<somerville32> Very addictive, light-weight game that we'd like to promote to main to consider inclusion in the Xubuntu seeds
<pitti> somerville32: no, didn't see that one yet
<somerville32> pitti: You're on the SRU Team, right?
<pitti> somerville32: no, I'm not
<LaserJock> somerville32: SRU != MIR
<somerville32> I know that :P
<somerville32> I just thought I'd bug him about one of my SRUs because I thought for a second he might be on the SRU team
<somerville32> ;] 
<namdum> hello
<mdke_> cjwatson: here?
<cypher1> is anyone working on bug 66637 ?
<Ubugtu> Malone bug 66637 in util-linux "After upgrade from dapper to edgy, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]  http://launchpad.net/bugs/66637
<mdke_> cjwatson: ok, nm
<LaserJock> cypher1: I would think so
<LaserJock> I wondered why hibernation didn't work
<Hobbsee> invalid swapfile?
<cypher1> LaserJock, yes even i was in edgy without hibernation for a month :) the solution there works
<cypher1> LaserJock, now my hibernation works !
<Hobbsee> LaserJock: if the swapfile doesnt exist, well isnt found, then it cant hibernate to swap
<cypher1> Hobbsee, yup
<LaserJock> I just wondered because it used to work
<Hobbsee> LaserJock: you didnt answer my above questoin about hibernate and wifi cards - was that deliberate, or you didnt know?
<LaserJock> hm?
<LaserJock> what was your question?
<Hobbsee> LaserJock: what package would the "my wireless card doesnt resume after hibernate in feisty" bug belong to?  (intel 3945)
<cypher1> Hobbsee, LaserJock it seems to be a problem with the new UUID
<Hobbsee> cypher1: yes
<LaserJock> Hobbsee: I don't know
<LaserJock> :-)
<StevenK> Hobbsee: The kernel
<Hobbsee> LaserJock: awww, pity
<Hobbsee> right
<cypher1> does anyone know who is working on 66635
<cypher1> i meant fixing bug 66635
<Ubugtu> Malone bug 66635 in mythtv "Merge more changes from debian multimedia before edgy release" [Undecided,Rejected]  http://launchpad.net/bugs/66635
<cypher1> sorry bug 66637
<Ubugtu> Malone bug 66637 in util-linux "After upgrade from dapper to edgy, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]  http://launchpad.net/bugs/66637
<fabbione> cypher1: stop flooding the channel.. you asked once.. wait
<cypher1> fabbione, sorry
<fabbione> cypher1: it's assigned to a developer so it will be addressed eventually.
<cypher1> fabbione, ok thanks.. i was interested in working in that too so thought of having a discussion with the concerned person :-)
<fabbione> cypher1: you are looking for Keybuk that's not online now
<cypher1> fabbione, ok thanks a lot.. i will check when keybuk is online
<doko> pitti: did you already start the apache2 merge?
<Hobbsee> doko: he's on holidays tomorrow?
<fabbione> <fabbione> i need to take down ubuntulog for about 10/15 minutes for urgent maintainance
* Starting logfile irclogs/ubuntu-devel.log
<pitti> doko: thus I'm ignoring the merge now and defer judgement to infinity/Tollef
<doko> pitti: which holds back the subversion merge as well ...
<cjwatson> infinity: done
<cjwatson> mdke_: yes?
<pitti> doko: oh, new svn only works with 2.2?
<doko> pitti: no, but installability of build-dependencies
<doko> infinity, Mithrandir: what is the reason to delay the apache2 merge?
<dholbach> good morning
<Fujitsu> Morning, dholbach.
<dholbach> hey Fujitsu
<mvo> hey dholbach!
<dholbach> hey mvo
<fabbione> cjwatson: i don't understand one bit in os-prober/init/10filesystem... 
<fabbione> cjwatson: there are 2 entries in FILESYSTEMS. fs-core fs-secondary
<fabbione> but i can't find how they get expanded to real fs'
<fabbione> or does that happen only in d-i via anna-install?
<Lure> infinity: any idea why this build dep fails: https://launchpad.net/+builds/+build/284062
<Lure> infinity: it has lilo as build-dep, which is not installable in chroot as it seems (i386/amd64)
<Lure> infinity: not sure how it worked before (as depend was already there in previous upload)
<elmo> why on earth would you build-depend on lilo?
<StevenK> Why do you need to?!
<Lure> elmo: I do not know - I have just added one simple patch to the package already in the archive (merged from debian by Riddell)
<Lure> elmo: I can try dropping lilo build dep and try, I was just supprised it was only seen on my simple change (and not on previous uploads)
<elmo> Lure: I wouldn't just drop it blindly, but rather find out why it's there.  it's probably something stupid like a configure script checking for the path to lilo
<Lure> elmo: I suspect there is grub/lilo GUI config tool in the package - so it may need some stuff
<elmo> Lure: but in any event, that error isn't that lilo can't be installed in a chroot per se, but that it can't be installed right now.  it should be reproducable in a clean chroot which only has main (i.e. not universe etc.) in it's sources.list
<Lure> elmo: I will investigate this evening - I am just suprised that it failed now and not before
<cjwatson> fabbione: they're just %s-modules udebs
<cjwatson> they aren't expanded to real filesystems
<fabbione> cjwatson: ok.. i found out.. i think
<Lure> elmo: so how can we get clean chroot (/me has no clue about buildd details)
<cjwatson> note the case just below that excludes them from being used for modprobe
<cjwatson> Lure: debootstrap
<cjwatson> yeah, it's an overrides bug at the moment, needs either that dependency removed from lilo or an MIR for mbr
<fabbione> cjwatson: is there any reason for os-probes/x86 dir to exist at all? it's empty...
<cjwatson> it's not that package's problem as such
<cjwatson> fabbione: probably not. who cares? :) if a cleanup mission is necessary, it should happen upstream
<fabbione> cjwatson: i was checking that too and probably get rid of it :)
<cjwatson> upstream, not in Ubuntu
<fabbione> cjwatson: yes.. i have svn access to d-i
<fabbione> cjwatson: i am just doing an svn up to make sure what's the right thing
<fabbione> cjwatson: yeah it seems it can be nuked on both
<fabbione> anyway it's a detail
<fabbione> cjwatson: how often do we sync from svn into our branch? is it worth to commit on both or just wait?
<cjwatson> fabbione: please don't commit on both
<fabbione> cjwatson: ok
<cjwatson> unless it's truly necessary, and this isn't
<fabbione> no it's not..
<cjwatson> I merge after releases
<fabbione> i just need to understand the workflow that you are using
<fabbione> ok
<fabbione> works for me :)
<cjwatson> commit to *one* branch. If it's necessary, merge to the other and note in debian/changelog that it's a backport.
<pitti> mvo: if avahi gets disabled due to a .local domain, I now create a tag file /var/run/avahi-daemon/disabled-for-unicast-local, and the session can pick it up via inotify; I think this asynchronous flow is more suitable
<pitti> mvo: would you be opposed if we add this inotify check/notification to u-n?
* Fujitsu notes that u-n is getting a bit... not-entirely-related-to-updates-y.
<pitti> Fujitsu: the plan has been to boost it up to 'event notifier' for a long time :)
<mvo> pitti: no, that is fine
<Fujitsu> Hah.
<mvo> pitti: we should just rename it :P
<pitti> mvo: ok, I'll take a look at the code and add something
<pitti> mvo: oh, u-n is not in bzr?
<Mithrandir> does avahi slow down all dns lookups for everybody, not just me?  It gets some sort of a timeout.
<mvo> pitti: I'm fine with doing it 
<mvo> pitti: it is
<mvo> pitti: let me check if it is on bazaar and if not move it there
<pitti> mvo: could you add it to https://wiki.ubuntu.com/BzrMaintainedPackages?
<pitti> Mithrandir: didn't notice a delay, but I can do some exact measuring
<mvo> pitti: its currently living on people.u.c, I will move it to bazaar now
<Mithrandir> pitti: ah, the problem is if I have "search blah.foo.local" in my resolv.conf
<Mithrandir> which for some insane reason the DHCP server here gives me
<pitti> Mithrandir: but still, I thought mdns would just resolve xxx.local, not subdomains
<pitti> Mithrandir: perhaps it doesn't check for that case and thus starts the full mdns resolution until it fails
<pitti> Lathiat: ^ any idea?
<Mithrandir> pitti: yeah, by the looks of it, it does.
* Lathiat looks up
<pitti> Lathiat: btw, you rock! avahi works wonderfully now with n-m
<Lathiat> pitti: IIRC< when we discussed this last, it only tried to resolve 1 level
<Lathiat> pitti: no, i suck for breaking it in the first place :(
<pitti> Lathiat: so the credential checking stuff was useful after all, nice
<Lathiat> pitti: yeh, i just want to verify it actually *does* something before i release it
<pitti> Lathiat: I just don't understand how uid==0 is sufficient; avahi-daemon doesn't run as root?
<Lathiat> i.e. i want to try "forge" some netlink packets 
<Lathiat> pitti: the netlink packets come from the kernel, which is seen as uid=0
<Lathiat> but, i do wonder if netlink sockets actually set the UID at all
<pitti> Lathiat: ok, same like hal then
<Lathiat> also i think the nlmsg_pid thing might be a kernel bug
<Lathiat> i was going to look into that
<pitti> right, a pid 1834023478 doesn't make sense at all
<Lathiat> yep
<Lathiat> i still want to know wtf NM does to make it go down and up with different netlink messages
<seb128> Mithrandir, infinity: could you give a retry to gtkhtml3.8 eog nautilus-cd-burner file-roller epiphany-extensions builds on sparc ia64 amd64
<mvo> pitti: added
<Mithrandir> seb128: gedit too, I suspect.
<pitti> mvo: *hug* in the meantime, I branched off from your people url
<seb128> Mithrandir: gedit has no build problem according to my packages page
<Mithrandir> seb128: that's because dholbach uploaded it last. :-P
<seb128> it's "Needs Building" on amd64 and sparc
<Lathiat> hrm i just tried to netboot install edgy and debconf was eating 100% cpu for a good 20 minutes on x11-common
<seb128> hum
<seb128> Mithrandir: I'm looking at https://launchpad.net/distros/ubuntu/+source/gedit/2.17.1-0ubuntu1
<Mithrandir> seb128: yes, after I just gave it back
<Lathiat> some bugy in an update perhaps?
<seb128> Mithrandir: ah, ok
<seb128> thank you :)
<seb128> Mithrandir: gcalctool too
<dholbach> I think those were build daemon failures
<Mithrandir> seb128: all done
<cjwatson> Lathiat: DEBCONF_DEBUG=developer would help
* seb128 hugs Mithrandir
<Lathiat> cjwatson: how do i do that within the installer?
<seb128> dholbach: if they were not I would not ask for a retry :p
<seb128> dholbach: like if that was a package bug a retry would make no diff ;)
<cjwatson> Lathiat: hang on, which debconf was eating CPU?
<cjwatson> Lathiat: the one in the installer environment or the one in /target?
<Lathiat> well it was a process called 'debconf' while it was configure x11-common, trying to do a netbooted install
<Lathiat> uh, im not sure
<dholbach> seb128: I didn't read the whol conversation
<Lathiat> i'll have to restart the install
<dholbach> s/whol/whole
<seb128> dholbach: ah, ok ;)
<cjwatson> Lathiat: try booting with DEBCONF_DEBUG=5 on the kernel command line
<seb128> dholbach: that was basically me asking for build retries on a bunch of packages and Mithrandir noticed gedit too
<dholbach> ok
<Mithrandir> seb128: actually, I was wondering why gedit was uninstallable on amd64 for the second day in a row
<seb128> Mithrandir: could you give a retry to shared-mime-info too?
* seb128 is tracking desktop packages which failed to build
<seb128> Mithrandir: and rhythmbox
<Mithrandir> seb128: why don't you ask me to just give back all of gnome? :-P
<seb128> Mithrandir: please, give back all of gnome ;)
<seb128> DONE :p
<Mithrandir> (please don't I don't have the big hammers that infinity uses.  *sniff*)
<seb128> joke aside the current list should be pretty much everything that needs a retry
<Mithrandir> g-a-i, rhythmbox given back
* seb128 hugs Mithrandir
<Hobbsee> Mithrandir: why dont you get them?
<seb128> g-a-i? s-m-i you mean?
<Mithrandir> seb128: yea, s-m-i.
<seb128> :)
<Mithrandir> Hobbsee: I think I can use them, but it involves running scary SQL directly against the production LP database.  I'd like not to do that, but rather have a tool that does all the scary work for me.
<Hobbsee> Mithrandir: ahhh
<Fujitsu> Aw, why not? Accidentally slip and type DELETE FROM bugs;? That'd be good.
<Mithrandir> Fujitsu: that might be a serious CLM
<Hobbsee> CLM?
<Fujitsu> CLM?
<Fujitsu> CareLess Mistake?
<ajmitch> career-limiting move
<Fujitsu> Hahahahah
<Mithrandir> what ajmitch said.
<Fujitsu> You never know.
<Hobbsee> haha
<ogra> shriek ...
<ajmitch> morning ogra 
<ogra> cjwatson, does your mail mean we'll loose -i386 completely ? 
<ogra> *lose
<cjwatson> ogra: no; did you actually read my mail? :)
<ogra> (LTSP needs it)
<ogra> well, apart from "use the new netboot/386 build as a workaround" i didnt see any trace that we'll keep -386 anywhere
<cjwatson> how do you think netboot/386 would build without the -386 kernel flavour?
<elmo> magic
<ogra> heh, sorry then 
<Mithrandir> cjwatson: what, we can't just make strip(1) strip all the non-i386 instructions from it?
<ogra> as long as a linux-image-386 package exists, i'm fine ....
<mjg59> Tollef is a bad man
<Lathiat> cjwatson: will that work from pxelinux?
<cjwatson> Lathiat: you can pass kernel arguments from pxelinux, right?
<cjwatson> ogra: my change does not affect that at all
<cjwatson> it is precisely and only an installer change
<Lathiat> well im trying ot, see if it works
<Lathiat> yeh that works
* Lathiat reproduces
<mjg59> ogra: Why does edubuntu need linux-image-386?
<cjwatson> ogra: you should stop panicking about random changes. :-) LTSP is an important goal; if something does accidentally break it, we'll work it out
* mneptok waves his hand (again)
<Tmob> hi, i recompiled a kernel module and copied it to /lib/modules/2.6.17-10-386/kernel/drivers/usb/core, but when i reboot its still seems to load the old module
<Tmob> what else do i need to do?
<Tmob> i put a few prints and its not printing them.. kinda sure its loading the old stale copy of the module
* Hobbsee defenestrates mneptok to prove he isnt being ignored
<mvo> Seveas: we talked (briefly) about your sources.list replacement spec. what was the name/url again?
* pitti wonders whether mvo got his /msg, or whether freenode is weird again
<mvo> pitti: just answered, sorry for the delay was disctracted
<pitti> mvo: no hurry, just wondering; thanks!
<Tmob> hmm its possible this driver is part of the initrd image
<Tmob> hmm.. and usb is loaded very early perhaps
<cjwatson> Tmob: update-initramfs
<cjwatson> (possibly with the -u option; I forget)
<Tmob> yup thats right
<Tmob> hope this works..
<Tmob> brb
<Seveas> mvo, https://wiki.ubuntu.com/SoftwareChannelSpec
<Seveas> I'm out for the day, please e-mail comments
<mvo> Seveas: thanks
<divansantana>  hello everybody! :)
<divansantana>  Is there anyone here that can pretty please help me with getting squid to work with the --enable-follow-x-forwarded-for=yes option
<divansantana> pleaase :)
* Fujitsu looks towards the topic.
<Fujitsu> Thanks cjwatson.
<pitti> Keybuk: I uploaded a new avahi an hour ago, which should fix operation; testing feedback appreciated
<pitti> Keybuk: works perfectly for me now on amd64 and ppc with and without n-m
<cjwatson> Fujitsu: np
<fabbione> cjwatson:
<fabbione> --- linux-boot-probes/common/50mounted-tests    2006-06-23 19:28:24 +0000
<fabbione> +++ linux-boot-probes/common/50mounted-tests    2006-12-12 10:36:52 +0000
<fabbione> @@ -33,7 +33,7 @@
<fabbione>  fi
<fabbione> 
<fabbione>  for type in $(grep -v nodev /proc/filesystems); do
<fabbione> -       if mount -o ro -t $type $partition $tmpmnt 2>/dev/null; then
<fabbione> +       if mount -o ro -t $type $partition $tmpmnt 2>/dev/null || mount -t $type $partition $tmpmnt 2>/dev/null ; then
<fabbione>                 bootpart=""
<fabbione>                 if [ -e "$tmpmnt/etc/fstab" ] ; then
<fabbione>                         # Try to mount any /boot partition.
<cjwatson> fabbione: why?
<Lathiat> pitti: amd64+ppc is a good sign
<Lathiat> pitti: i hate the bsd socket api
<fabbione> cjwatson: because when running on a live system, if partition foo is mount rw, it will fail to mount it ro somewhere else
<fabbione> cjwatson: but i wanted to talk to you about it before committing
<pitti> Lathiat: heh
<cjwatson> hmm, interesting
<cjwatson> is ro/rw the only thing for which that happens?
<fabbione> i can show it if you want.. basically linux-boot-probes will return nothing
<cjwatson> no, I believe you
<fabbione> cjwatson: in that set of options yes.. afaics
<cjwatson> hmm, let me think, there are some possibly unexpected implications of that change I want to think through
<cjwatson> specifically in the installer we don't want to probe /target
<fabbione> or we need to grow a more clever logic that will check if that partition is already mounted somewhere and with what options or change the dir to check from /var/lib.. to the real mountpoint
<cjwatson> need to be VERY CAREFUL here
<fabbione> yeps.. hence it's not committed :)
<cjwatson> fabbione: no, this needs to be conditional on DO_MOUNTED
<cjwatson> currently 'linux-boot-prober --mounted' deals with this by unmounting; teaching it how to do something cleverer wouldn't hurt
<fabbione> umounting is broken (and needs fixing) and you can't always umount stuff
<cjwatson> see the last paragraph of README
<cjwatson> hello, see the way I said "teaching it how to do something cleverer wouldn't hurt"? I *know*
<cjwatson> but it's important not to break primary functions of os-prober
<cjwatson> fabbione: hmm, exactly what situation is this coming up in?
<cjwatson> it's important not to probe /target, but probing random other mounted filesystems would be ok
<fabbione> cjwatson: i am testing os-prober & Co. to write a linux-boot-thingy for silo
<cjwatson> fabbione: so it wouldn't have to be conditional on DO_MOUNTED as long as it excluded stuff mounted on /target, /target/boot, that sort of thing
<fabbione> and i was comparing different arches as well
<fabbione> that's how i spotted it
<fabbione> pure testing luck
<cjwatson> it's a well-known problem in os-prober
<cjwatson> affects things like creating grub stanzas for Windows if the Windows partition is automounted
<cjwatson> fixing it would definitely be useful
<ogra> mjg59, many of my clients are only 386/486 compatible ....
<fabbione> cjwatson: hmmm why do i always open a pandora's box? :P
<fabbione> cjwatson: next time i feel to look at the installer please remind me not to :)
<Lathiat> cjwatson: blah, it worked this time 
<cjwatson> Lathiat: yay reproducibility
* StevenK ponders running Katapult under gdb
<StevenK> But first, let me bone up on gdb.
<cjwatson> fabbione: I think checking if it's already mounted and not mounted on /target or /target/boot and if so using a directory on which it's mounted instead of $tmpmnt would be sufficient
<fabbione> cjwatson: the good news is that we don't need silo support... the fallback works just fine...
<cjwatson> fabbione: though there's still a wart in that we also need to mount the /boot partition if necessary
<cjwatson> (within the to-be-checked partition)
<cjwatson> so it'll be a bit fiddly
<fabbione> cjwatson: ok.. i will think about it but there is a lot of things that needs extra checking like mount by uuid need to be unrolled to the real block device and stuff like that...
<cjwatson> fabbione: the output of mount(1) already seems to canonicalise device names
<cjwatson> so I don't think that's really necessary if you're careful ...
<fabbione>  /dev/disk/by-uuid/2c15f439-31d4-4a1f-bb8a-9207c93fa374 on /boot type ext3 (rw,data=ordered)
<fabbione> not on all arches or so it seems
<fabbione> sparc is normalized
<fabbione> i386 isn't
<cjwatson> fabbione: I have that in /proc/mounts, but not the output of mount
<fabbione> i have that in mount output
<cjwatson> ok, I stand corrected then
<fabbione> go for consistency
<cjwatson> comparing device major/minor numbers would be the simplest anwer
<cjwatson> answer
<fabbione> hmm no
<fabbione> we will need a silo
<StevenK> Sigh. Attaching gdb to katapult drops it to T state.
<fabbione> the fallback pulls in too much junk
<StevenK> No, I stand corrected. Trying to use katapult with gdb attached to it drops it to T.
<StevenK> And if kill -CONT doesn't help, what the heck will?
<pitti> StevenK: you need to 'cont' in gdb to make katapult run
<pitti> StevenK: as long as the katapult process is ptrace()d, it can't go on
<StevenK> And now it seems obvious.
<StevenK> pitti: Thanks.
<pitti> StevenK: you're welcome
<divansantana> hello all
<divansantana> pretty please can someone tell me how to rebuild a deb file(from source?) with addiotnal configuration options
<pitti> divansantana: #ubuntu, please
<Hobbsee> gosh, we could almost do with this moderated too..
<haypo> hi! i have to create a package of a Python program. Should I use cdbs, python-central, or something else?
<haypo> I read that python-central is not in Ubuntu Dapper (and I'm using Dapper)
<Hobbsee> haypo: try #ubuntu-motu
<Hobbsee> haypo: also, see the /topic
<haypo> oh, ok
<Mithrandir> doko: what's the point of the -dbg packages for ooo now that we have ddebs?
<Hobbsee> jono!!!
<jono> heya Hobbsee
<Hobbsee> heya!
<_ion> During the last 24 hours, divansantana has asked for support and been told to ask somewhere else three times.
<Hobbsee> _ion: needing a banforward?
<doko> Mithrandir: just synced from Debian
<Mithrandir> doko: ok
<doko> Mithrandir: I can explicitely disable them, if that's what we do want to do
<Mithrandir> doko: I don't see a point in them with ddebs, maybe pitti has an opinion.
<Mithrandir> pitti: ^^ 
<pitti> Mithrandir, doko: in general we don't need them, but apart from archive clutter they don't hurt; so if we have an ubuntu-modified version anyway, then disabling the package should be considered; if it was the only delta to Debian, then we shouldn't worry
<doko> pitti, Mithrandir: ok, I'll disable these for 2.1/2.2
<Mithrandir> doko: thanks
<Mithrandir> doko: planning on uploading that soonish?
<doko> Mithrandir: no, depends on the final release. it's not yet released
<Mithrandir> doko: ok.
<Keybuk> has anyone ever been able to get valgrind suppressions to work?
<fabbione> pitti: ping?
* pitti hugs Padre Fabio
<fabbione> ehehhe
<pitti> ogra: wrt mount-all-local-filesystems> if the icons were hidden if the user is not an 'admin', would that DTRT for ltsp?
<ogra> no
<ogra> your patch checks for permissions afaik
<ogra> so if a user is allowed to access the device its shown
<ogra> i think we should use the same mechanism for mount-all-local-filesystems
<ogra> (or even for everything=
<ogra> )
<ogra> seb128, is libpanel-applet a new lib ? funnily g-p-m ftbfs'es because its not in the build-deps, but it worked in edgy
<seb128> ogra: no it's not
<seb128> ogra: it's part from gnome-panel since before warty
<ogra> weird
<seb128> ogra: is that a new g-p-m version? maybe they use that lib now
<ogra> yep, its 2.17.3
<ogra> i didnt want to keep you from taking your break... dotn worry, i'll handle it, i just found it strange since it wasnt needed until edgy
<seb128> oh, no problem, few minutes is fine
<seb128>  libpanelapplet-2.0 >= $LIBPANEL_REQUIRED \
<seb128> from the configure.in
<ogra> yeah
<jonh_wendell> will feisty be LTS?
<ogra> seems its to fix the "a icon sized window with g-p-m hangs around if the panel dies" bug
<ogra> dunnon the # from the top of my head, but seems reasonable
<seb128> ogra: 
<seb128> + gnome-keyring-1 >= $GNOME_KEYRING_REQUIRED \
<seb128> + libpanelapplet-2.0 >= $LIBPANEL_REQUIRED \
<seb128> diff between 2.16.1 and 2.17.3 configure.in
<ogra> oh, right, thanks :)
* ogra adds gnome-keyring as well
<seb128> np
<seb128> ogra: in fact it's used by the new applets
<seb128> they added a brightness and an inhibit applet
<ogra> ah
<ogra> good to know :)
<seb128> $ grep panel-applet * -r
<seb128> gnome-power-manager-2.17.3/applets/inhibit/inhibit-applet.h:#include <panel-applet.h>
<seb128> gnome-power-manager-2.17.3/applets/inhibit/inhibit-applet.c:#include <panel-applet.h>
<seb128> gnome-power-manager-2.17.3/applets/brightness/brightness-applet.c:#include <panel-applet.h>
<seb128> gnome-power-manager-2.17.3/applets/brightness/brightness-applet.h:#include <panel-applet.h>
<seb128> 
<seb128> ogra: you might want to split the package
<ogra> into g-p-m and g-p-m-applet you mean ? 
<seb128> yep
<seb128> -applets, there is several of them
<seb128> of maybe by applet
<seb128> you should talk with giskard about it probably
<ogra> sounds like a plan ... let me get it building first :)
<ogra> well, he gave me the package i'm fiddling with atm ...
<seb128> ok
<ogra> and i'd like him to take over at some point ...
<cjwatson> jonh_wendell: no
<seb128> ogra: would be nice ;)
<cjwatson> iwj: have you made any progress on winmodem-support?
<ogra> gpm-manager.c:25:20: error: sys/wait: No such file or directory
<ogra> GRMBL
<pitti> ogra: re
<pitti> ogra: 'your patch' for gnome-vfs doesn't exist yet
<ogra> pitti, ahem, and how do we handle the ltspfs devices in edgy ?
<pitti> ogra: so the permission check in this case would be to check for admin membership, which we generally use as approximation of 'gksu will work'
<ogra> i thought you just need to adapt that one
<pitti> ogra: something similar, right
<pitti> ogra: i. e. on a single workstation, non-admins shoulnd't see the icons, but admins should
<ogra> and why the admin group ? shouldnt we probably have a disk access specific group ?
<pitti> ogra: my question was just if that behaviour would suit the ltsp case as well, of if we need to add more conditions
<ogra> no, that should be fine for ltsp then
<pitti> ogra: admin because we essentially call 'gksudo gnome-mount'
<ogra> i thought you asked because of my mail
<ogra> oh, ok, so you get a password prompt anyway ...
<pitti> ogra: right, I asked because of your mail
<pitti> ogra: 'anyway'? no
<pitti> ogra: -> /msg
<fabbione> Keybuk: why did you reassign udev-mdadm to me and marked as completed?
<fabbione> Keybuk: what has been done to actually get it going?
<cypher1> Keybuk, hi
<Keybuk> fabbione: because you did it?
<Keybuk> the spec says "sync mdadm from Debian"
<fabbione> Keybuk: i did sync mdadm from Debian yes, but that's not enough..
<fabbione> Keybuk: does udev take care of calling mdadm on each device now?
<fabbione> otherwise we did solve nothing.. mdadm in debian doesn't wait for devices to appear
<Keybuk> the mdadm in Debian has a udev callout?
<Keybuk> if it's not enough, then the spec is incorrect
<Keybuk> I believe you boycotted that bof?
<Keybuk> we looked over the Debian mdadm package, madduck had done a lot of work to make it work with udev and had a complex udev script in there
<fabbione> mdadm calls udev when starting the raids, but there is still no guarantee that the devices from kernel/udev will be there
<Keybuk> ok, in that case the spec is wrong; could you investigate what needs to happen instead?
<fabbione> Keybuk: i already know :)
<fabbione> Keybuk: basically it's always the same race at boot
<fabbione> mdadm needs devices that might not be there
<Keybuk> that's why for lvm and evms, we call them from a udev rule
<fabbione> once a raid starts we need to inform udev sending events (that's what debian does more that we didn't)
<Keybuk> so that they get re-run every time a new device gets added
<fabbione> exactly.. that's what we need for mdadm too
<fabbione> if i was not clear about it, i take the full blame
<Pretto> hi mvo 
<fabbione> i thought i did tell you BUT again.. i take the blame if i am wrong
<Pretto> CypherBIOS,  :)
<Keybuk> it looked like Debian had all of that, to me
<fabbione> Keybuk: no it doesn't.. i can ensure you that :)
<fabbione> Keybuk: they only handle the second bit of sending udev events for raids
<CypherBIOS> Pretto: hi man :P
<fabbione> but it doesn't wait for devices before activating the raids
<Keybuk> "sending udev events for raids" ?
<fabbione> that's something i partially addressed in edgy
<fabbione> let me find the right words for it
<fabbione> Keybuk: mdadm-raid as reference and /msg for the code snippet
<fabbione> that's all it does for udev
<Keybuk> ok
<Keybuk> so you need to call mdsomething in a udev rule every time a block device is added?
<Keybuk> if that's safe to do, go ahead
<Keybuk> see iwj's changes to lvm
<fabbione> Keybuk: it should be safe in theory.. but i can look at it
<pitti> fabbione: network-console looks good to me, approved
<fabbione> pitti: thanks
<Riddell> cjwatson: that's most of the gaps filled in for ubiquity experimental-qt4-port
<Riddell> cjwatson: but I've not actually tried an install yet, I don't have a machine set up for that, so there's a smallish chance it'll break after the last step
<cjwatson> Riddell: does it just need a Kubuntu live session?
<cjwatson> Riddell: did you figure out the xembed stuff?
<cjwatson> Riddell: -> #ubuntu-installer maybe
<Keybuk> pitti: new avahi seems much better; the icon appears and disappears from rhythmbox just by checking and unchecking the box on the other machine
<pitti> Keybuk: yay
<Keybuk> pitti: likewise, stopping and starting avahi on quest made it disappear and appear on syndicate
<pitti> Keybuk: merely bringing the interface down and up should do the same
<pitti> Keybuk: with network-manager, it didn't in the previous version
<pitti> lamont: tinycdb MIR approved
<Keybuk> pitti: switching to a different network => all vanished
<Keybuk> heh
<Keybuk> I confused N-M
<Keybuk> err
<Keybuk> pitti: seems to work
<pitti> Keybuk: thanks for testing
<Keybuk> certainly when I killed NM and restarted it, they came back
<Mithrandir> pitti: yay, thanks, promoted
<Keybuk> (NM got confused; I tried to switch to a nearby WPA network, cancelled it on the key dialog; but then it was waiting for a key for my unsecured network and kept smacking down the IP everytime it came up -- ho hum)
<Keybuk> of course, every time the IP came up, avahi found the services, and a millisecond later, lost them again
<Keybuk> so that's a stress test, I suppose :p
<fabbione> iwj: given the udev rule you added in lvm2, is there really any need of the initramfs local-top script?
<fabbione> iwj: it was my understanding that these udev play nice with * was to get rid of these scripts
<tkamppeter> Anyone here who has a Samsung laser printer, bw or color?
<pitti> tkamppeter: I have an ML-1610 (bw laser)
<iwj> fabbione: Err, I'm not sure which script you're referring to.  Is this something mkinitramfs does ?
<tkamppeter> I have packaged a new driver for these printer, Splix, see bug 59829 and bug 44407.
<Ubugtu> Malone bug 59829 in Ubuntu "No driver for Samsung ML-1610 printer" [Wishlist,Needs info]  http://launchpad.net/bugs/59829
<Ubugtu> Malone bug 44407 in foomatic-db "Samsung clp510 not working" [Medium,Needs info]  http://launchpad.net/bugs/44407
<fabbione> iwj: lvm2 ships an initramfs local-top script that's used by update-initramfs and mkinitramfs
<jonh_wendell> Who is responsible for mounting cd/dvd? There is a bug about problem mounting cd/dvd against no package
<fabbione> iwj: with the udev changes you made (adding the rule), should theoretically kill the need of a initramfs script
<iwj> fabbione: Err, probably.  Let me take a look.
<fabbione> iwj: sure. no hurry. i noticed only 2 minutes ago trying to figure why i deserved udev-mdadm...
<tkamppeter> pitti, excellent, then download my package onto a Feisty box and install it. After that set up a queue with a SpliX PPD (with web interface or gnome-cups-manager).
<pitti> tkamppeter: I got your mail as a reminder, I'll try that
<fabbione> OMG I got UDEV
<tkamppeter> SpliX gives once a better support for not too old bw models (better than the GhostScript built-in "gdi") and introduces support for the CLP color laser series. Very old printers (ML-12xx and ML-14xx) are not supported (stay with "gdi" for them).
<tkamppeter> I have also good news for the introduction of printerdrake. Mandriva's config tool developers want to add Mandriva's Perl libraries for the GUI stuff into CPAN.
<pitti> tkamppeter: hm, but didn't we want to get rid of this library since the UI is not very userfriendly?
<fabbione> iwj: sorry.. i think the script comes from lvm-common and not from lvm2..
<tkamppeter> Yes, but there are different libraries. There is an "interactive" library which we really want to get rid of, but also a perl-gtk2 library with which the main window of printerdrake is made. This latter one can be useful.
<fabbione> iwj: you still want a little portion of it but other stuff should be able to die
<tkamppeter> In addition, all libraries can be used for first integration tests and later be removed as soon as the better UI is there.
<ogra> grmpf, since when is calling getenv an error ?
<ogra> gcc seems not to like it
<lamont> pitti: postfix thanks you
<Mithrandir> ajmitch: I uploaded a new samba for you with type-handling actually dragged out of the build-depends. :-P
<pitti> lamont: happy postfix users like me will thank you in return :)
<Keybuk> seb128: the gnome-power-manager icons have gone fuzzy again
<cjwatson> ogra: forgot to #include <stdlib.h>?
<ogra> cjwatson, might be that this code had no include for it, i just saw g-p-m uses g_getenv everywhere
* fabbione takes off for the afternoon... later
<ogra> so i'm trying with g_getenv now ....
<ogra> (its a patch that worked with getenv in edgy)
<mvo> hey Pretto
<ogra> pitti, g-p-m has still --disable-policykit in its configure stanza, do we use it now in HAL (since you use gnome-mount as well)
<pitti> ogra: no, we don't have PK packaged yet (no release yet)
<ogra> fine then, thanks
<seb128> Keybuk: that was expect, we dropped the hicolor patch which was breaking other things and we will fix it from the panel
<iwj> fabbione: Yes, you seem to be right.  The only thing that still seems relevant are the two silly symlinks.
<fabbione> iwj: yes the symlinks are somehow mandatory. afaict you can't create the symlinks when building the initramfs or cpio will convert them into real file
<fabbione> iwj: and i don't think we want to copy the lvm binary N times
<iwj> Bizarre.  Why isn't cpio passed some sane option ?  Well, never mind ...
<fabbione> iwj: but if you know a solution to that, we can kill the entire local-top script
<fabbione> iwj: dunno.. really.. i didn't fell lucky to dig into it.
<iwj> Yes, quite.
<fabbione> iwj: thanks for the check tho.
* fabbione takes off for the afternoon for real
<Pretto> hey mvo, how are you doing?
<iwj> Hopefully all of this will still happen in the right order.
<fabbione> iwj: i have / on lvm.. if it breaks i will let you know :)
<fabbione> with lots of love.. Fabio
<pitti> carlos: hey
<carlos> pitti: hi
<pitti> carlos: does the rosetta import need the *.mo files from the translation tarballs at all?
<carlos> no, we don't use them right now
<carlos> pitti: why?
<pitti> carlos: IOW, if we might lose a few (or all for some packages), would that be a potential problem in the future?
<pitti> carlos: I'm pondering only ever creating the translation tarball once
<pitti> carlos: instead of once for every binary package
<pitti> carlos: this would speed up pkgstriptranslations dramatically, especially for packages like OO.o (needs 2 hours there)
<carlos> well, OO.org will stop using .po files quite soon
<pitti> carlos: so I can either add an OO.o specific hack
<pitti> to speed up just 'openoffice.org'
<carlos> but in general, I think is fine to remove the .mo files, anyway, we are going to accept non .po files to translate
<pitti> or I generally drop *.mo files from translation tarballs
<carlos> so we cannot depend completely on those files
<carlos> pitti: I think you can drop them
<pitti> carlos: ok, great
<carlos> as long as you leave the source/ tree untouched
<pitti> yes, of course
<darek> hi
<seb128> mjg59: hi. Do you think you will have time to have a look on the compiz update soon?
<iwj> fabbione: Well, I've uploaded that but I don't have a system with an LVM root atm so I haven't tested it.  If it breaks by tomorrow let me know and I'll fix it, otherwise you may have to revert it yourself as I'll be away ...
<pitti> doko: new pkgbinarymangler for you :)
<doko> pitti: thanks :)
<pitti> BenC: got a minute to discuss the apport kernel stuff today?
<BenC> pitti: sure, can you give me a few minutes to get some coffee?
<pitti> BenC: good morning
<pitti> BenC: oh, of course, I'll be online for at least four hours still
<pitti> BenC: no hurry at all :)
<pitti> Gloubiboulga: ping
<pitti> Gloubiboulga: got a minute for discussing https://wiki.ubuntu.com/GnomeMount for Xubuntu?
<fabbione> iwj: ok thanks.
<Gloubiboulga> pitti: sure, but I must say I haven't looked that
<Gloubiboulga> s/taht
<Gloubiboulga> grrr
<Gloubiboulga> s/that/at this yet
<pitti> Gloubiboulga: janimo apparently wanted to get gnome-mount for Xubuntu, too
<pitti> Gloubiboulga: but right now it uses gnome-keyring and libgnomeui for the password dialog
<pitti> Gloubiboulga: and I guess either of those or even both are a no-no for Xubuntu?
<Gloubiboulga> pitti: we already have gnome-keyring iirc, but libgnomeui is a problem for us
<pitti> Gloubiboulga: ah, if at least having the keyring is ok, that's already much better
<Gloubiboulga> pitti: gnome-keyring is used by xubuntu-system-tools, so it's not a problem
<pitti> Gloubiboulga: how do you handle removable devices ATM in Xubuntu?
<pitti> Gloubiboulga: i. e. what drives hal?
<Gloubiboulga> pitti: thunar-vfs handles this
<pitti> Gloubiboulga: so not getting gnome-mount into Xubuntu feisty wouldn't be much of a problem?
<Gloubiboulga> pitti: I don't think so, I don't really know why Jani wants to use gnome-mount
<pitti> Gloubiboulga: if it's not a blocker, then we should just defer this spec until upstream moved the gnome password dialog stuff to gtk proper; unless, of course, some of you guys feel like replacing the code in gnome-mount with some gtk bits :)
<Gloubiboulga> pitti: Jani is supposed to work on this AFAIK
<pitti> Gloubiboulga: probably for the same reasons why we want it for Ubuntu
<pitti> Gloubiboulga: (1) handles LUKS encrypted devices, (2) now handles mounting of fixed partitions, (3) per-device gconf mount options configuration
<Gloubiboulga> ok
<Gloubiboulga> I see why now ;)
<pitti> Gloubiboulga: ok, I'll talk to him then, I just didn't seem him around much recently
<Gloubiboulga> pitti: neither did I
<pitti> Gloubiboulga: ok, thanks!
<Gloubiboulga> pitti: np :)
<Riddell> pitti: able to look at exiv2 today?  it's passed NEW
<Riddell> the versioning is indeed strange
<pitti> Riddell: oh, sure
<ogra> pitti, do you require a MIR for the switch from netkit-inetd to openbsd-inetd (debian already did that switch)
<pitti> in principle yes, unless it's the very same codebase (which I doubt?)
<ogra> no, it isnt ... i'll write you one
<ogra> just wanted to ask in advance ... i'm lazy, you know that ;)
* proppy hugs infinity
<malix0> hi all, can I ask a question about kubuntu here?
<Riddell> malix0: yes, but #kubuntu-devel probably better
<Riddell> assuming it's a development question, else #kubuntu
<malix0> is a bug (I think) on logout dialog
<mvo> cjwatson: I'm going over the CommonCustomizations spec right now and just want to confirm that we do install linux-image-generic now by default, right?
<cjwatson> mvo	yeah
<mvo> cool, thanks
<iwj> fabbione: Uh, I see that LP thinks that udev-device-mapper is `Not Started'.  This suggests that that lvm2 upload will break things.  Could you give it a test ASAP ?
<iwj> mvo: Will the edgy->feisty update-manager run with edgy's or feisty's ?
<Keybuk> iwj: I haven't done anything for udev-device-mapper yet
<iwj> Keybuk: So LP is accurate.  Hmm.
<wallace> 	x)
<mvo> iwj: how do you mean? the design is such that the edgy version will download the feisty upgrade application. so in a sense, we use the feisty version
<iwj> I think that this isn't likely to work well, then, as the dm creation events for the root fs volume might well just be ignoored.
<mvo> iwj: why? do you need some special support from it for something?
<iwj> mvo: Right, exactly.  Is that actually going to be the case in feisty ?  I know we didn't manage it for edgy.
<iwj> Because the dist-upgrade fix for Breaks: would be good.  If we don't have it then we have to be a bit more careful about where we use breaks.
<mvo> iwj: its planed to support it fully, but it needs support from soyuz. I will try to push for it, but its beyond my control. but its important for me
<mvo> too
<iwj> mvo: OK, so I think given what happened last time I shouldn't count on it.  Fair enough.
<iwj> I think that basically means that Breaks should be used only amongst packages in main.
<iwj> Since the handling of unsatisfiable Breaks by apt-get dist-upgrade is not ideal in edgy.
<mvo> iwj: the issue is the missing patch that was added with the last version?
<iwj> Right.
<mvo> right, we can certainly get it into edgy-updates
<mvo> its a trivial change
<mvo> and a codepath that is not touched in edgy normaly anyway
<iwj> Ah, yes, that's another idea.
<iwj> Mmm, I think I like that better.  I should stare at the change just to make sure it's really safe.
<mvo> :)
<iwj> I'll push it through the SRU then, in the New Year.
<sabdfl> #ubuntu-meeting
<sabdfl> erk
<mvo> iwj: thanks for taking care of it!
<iwj> My head's full of gdm atm.
<iwj> mvo: NP.
<mvo> I really appreciate that
<psusi> Keybuk: hey... I was wondering, is it really needed to patch libdevmapper to not create the dev node?  udev will just try to recreate it won't it?  and if it already exists, will that make udev pissy?
<iwj> psusi: Not IME.
<psusi> IME?  In my estimation?
<iwj> In my experience.
<psusi> ahh
<iwj> BICBW.  I was doing things with lvm2 symlinks not device nodes and I wasn't looking specifically for this problem.
<psusi> I've also been wondering if g-v-m shuold continue to be in charge of auto mounting or if udev should take that over?
<Keybuk> psusi: the trouble is that the way devmapper creates the device node means that devmapper gets pissy if udev beats it
<Keybuk> udev would just go "oh, a device node, let me fix the perms"
<psusi> Keybuk: ahh, does it?  it doesn't just figure hey, it already exists... goody... and go on?
<Keybuk> no
<psusi> well then that would be a problem.... 
<CypherBIOS> mvo: hi
<mvo> hi CypherBIOS
<psusi> guess I'll have to dig back into that code again and fix that...
<cjwatson> mvo: what do you need from soyuz?
<Keybuk> it also makes sense to spin in devmapper until udev has received the kernel event anyway, to ensure whatever calls devmapper doesn't return until udev is aware of the device
<psusi> I ran into another question last night about mailcap.... it seems that the vi package installs a mailcap rule making it the viewer/editor for text/*
<CypherBIOS> mvo: download repository of aptoncd working :)
<mvo> cjwatson: the ability to upload the dist-upgrader as arch=any
<psusi> isn't that bad?  I mean what if the user uses another EDITOR?
<mvo> CypherBIOS: nice!
<iwj> Keybuk: Urr, that's not going to work - with the way udev-lvm does it atm that'll deadlock.
<Keybuk> iwj: why?
<cjwatson> mvo: as I said in a comment on that spec, I'm pretty certain that that's there already
<Keybuk> add /sys/block/sda/sda1 => vgchange => devmapper => (spin for dm-0)
<cjwatson> mvo: "all" isn't mentioned in the code, so I see no reason why it wouldn't Just Work
<psusi> iwj: lvm needs changed so that it lets udev create the dev node instead of vgchange
<Keybuk> add /sys/block/dm-0 => mknod => (release spin)
<Keybuk> etc.
<iwj> Keybuk: vgscan does: lock, create dev node (devmapper call) which is waiting for udev.   Meanwhile udev does: scan rules, find vgscan, vgscan does: take out lock ...
<mvo> cjwatson: oh, than this may have changed since my originial implementation, I need to check this out. thanks for this info
<Keybuk> oh, I see, vg* would lock because we're calling vg* from the devmapper rule as well
<iwj> Exactly.
<Keybuk> s/devmapper rule/dm rule/
<iwj> Precisely to make sure that everything happens in the right order.
<cjwatson> mvo: I reckon you should just try it and complain if the upload breaks :)
<psusi> the dev node will already exist though when the second vgscan runs
<Keybuk> I'm trying to think whether it matters whether things that create the dev node return before udev has the event
<mvo> cjwatson: haha, good idea :)
<psusi> so the first vgchange will return and drop the lock
<psusi> allowing the second to continue
<psusi> no?
<Keybuk> assuming we modified devmapper to not mind if the device node already exists with the right details
<CypherBIOS> mvo: when we'll start the work?
<iwj> Keybuk: I think if it does then we have to change things like lvm2 and evms to make a separate `wait for my events to be handled' call.
<iwj> Because lots of those are going to involve reentering lvm2/evms/etc.
<iwj> So you have to wait outside the lock.
<Keybuk> dunno
<Keybuk> would have to test and play
<psusi> if libdevmapper waits for udev to create the node, that should work fine... udev creates the node, allowing the libdevmapper client to finish up and exit, THEN invokes vgscan
<iwj> (Less true of evms since it does the recursion itself.)
<iwj> psusi: Presumably the idea is to make san-add-device or whatever it's called not return until all the LVs on that SAN are actually online.
<mvo> CypherBIOS: are your changes in svn yet?
<Keybuk> I think psusi is right, I don't think there's a deadlock here
<CypherBIOS> mvo: yes, I've uploaded the download rep on svn yesterday
<iwj> And if you do that then san-add-device has to wait for the udev event to be _completed_.  And all of the consequent udev events, in fact.
<psusi> yea... what is wrong with that?
<iwj> Keybuk: libdevmapper will wait only for the block device node and not for the RUN+= to be finished ?
<Keybuk> iwj: right
<iwj> Keybuk: I think that's harmless.
<Keybuk> that's what the spec says, anyway
<Keybuk> of course, the principal flaw of the spec process is writing all this stuff down without actually trying any of it out <g>
<iwj> If you make the device node creation in libdevmapper idempotent then you don't have a race any more.
<Keybuk> one only finds the problems when you try and implement it
<CypherBIOS> mvo: need more polish, because we're doing everything from-scratch, but already get the deb files of selected repository :)
<iwj> Keybuk: No shit.  But such is life.  Think how bad it would be if we tried to do it without even writing anything at all down first ...
<Keybuk> iwj: how do you mean?
<psusi> at least when you write it down, others have a chance to look it over and say hey... I don't think that will work
<mvo> CypherBIOS: cool! I will update my local tree and check it out
<iwj> Keybuk: I mean the problem here is that libdevmapper throws a wobbly if udev gets there first with mknod.  So make it say mknod(temp name); rename() and then the race goes away.
<psusi> or hey... it might be better like this
<iwj> The only problem you're left with is that the perms might be those from libdevmapper or those from udev.
<psusi> iwj: libdevmapper needs to not mknod at all
<Keybuk> iwj: or mknod(real name), check for EEXIST
<CypherBIOS> mvo: Also, I'm packaging the aptoncd, and putting it on REVU, if you want take a look... http://revu.tauware.de/details.py?upid=3748
<iwj> psusi: If you do that then it has to wait since other things libdevmapper's caller is about to do will depend on it.
<iwj> Keybuk: Err, yes.
<psusi> iwj: right.. it just needs to wait a second or three for udev to create the node
<iwj> Keybuk: Is it possible somehow for udev and libdm to disagree on what the node should be like, or for there to be some race where one is adding and the other is removing, or something ?
<iwj> psusi: No no no, definitely no random waiting.
<Keybuk> (if you want to implement udev-device-mapper, btw, go ahead -- I won't get to it until January or so)
<Keybuk> iwj: udev could have a different name for it, I guess
<iwj> Keybuk: Me neither.  I'm trying to replumb gdm right now.
<Keybuk> oh, cool; I'm looking forward to the gdm spec
<iwj> Keybuk: That would work.  Or we could suppress udev's node creation.
<iwj> Keybuk: Not the face browser one, the no insane switch users one.
<Keybuk> that's the one I'm looking forwards to
<Keybuk> don't care much about face browsers
<Keybuk> having a single screen for login, unlock, switch user, etc. has been a pet gripe of mine for a while <g>
<iwj> suppress udev> Since we now have a lock to make sure udev won't continue until the caller has made the node, for evms and lvm2 and will have for the next thing.
<psusi> what does libdm need with the node after it is created?  doesn't it set it up before then via the control?
<psusi> or does it just create it, then has to configure it?
<Keybuk> iwj: suppressing udev would be bad, that'd mean we couldn't use the ADD block/dm-* events to mount things, because we couldn't guarantee the device node existed
<Keybuk> that's what we do today
<iwj> psusi: Typically the caller is something like evms and is going to peer into it to see what it is.  That is, actually read and write the dm device.
<psusi> iwj: ok... so what's wrong with waiting for udev to create the node?
<iwj> Keybuk: yes, you can, because the things that create dm nodes all have one of these `rerun vgchange'-a-likes in RUN+= which get done first.
<psusi> it is already fully accessible by that point right?
<psusi> or is it just an empty device with no table yet?
<iwj> psusi: Well, it's hassle to talk to udev.  You seemed to be suggesting sleeping and polling or some nasty thing.
<Keybuk> iwj: dm nodes are created by more than just lvm and evms
<iwj> psusi: And yes, the creator will typically create it and then load a table.
<psusi> iwj: yea... poll and sleep for a while
<iwj> Keybuk: Yes, but we could make it a rule that they have to do some lock like this.
<psusi> crap... well if the table isn't loaded until after the add event, that is a problem
<Keybuk> iwj: that rule would be insane
<iwj> psusi: That's a hideous hack which makes the boot slow.
<Keybuk> and involve modifying huge amounts of things
<psusi> the add udevent needs to be surpressed until after it is setup and enabled
<psusi> or another event needs to happen that actually does the work isntead of add
<Keybuk> and would fail every time someone found a new use for device-mapper
<Keybuk> psusi: the add event occurs because it has been setup and enabled
<iwj> In my tests both lvm2 and evms generated ADD and CHANGE udev events.
<iwj> In that order.
<fabbione> iwj: yes.. in about 10 minutes
<psusi> iwj: how does it slow down anything?  it won't take long for udev to make the node and libdm to carry on
<iwj> fabbione: Great, thanks.
<fabbione> iwj: i want to check the debdiff. 
<fabbione> iwj: did you only change the script or also change its dependencies and where it run?
<iwj> Keybuk: Yes, I agree it's not very good.  But I want to understand all the possibilities.
<iwj> fabbione: I also removed the prereq.
<psusi> does the add uevent happen before the table is installed to the device is the question?
<fabbione> iwj: because in this new setup lvm needs to run before udev
<iwj> Since it wasn't relevant.
<fabbione> iwj: otherwise udev rule can kick in without the symlinks being there
<fabbione> but i didn't verify.. it was only flashing in my head
<iwj> fabbione: Err, yes, that's what I was talking about before.
<fabbione> iwj: sorry i was feeding the baby and lost the scrollback
<fabbione> but i will test soon enough
<iwj> fabbione: Hmm.  OK.
<psusi> yea... I'm thinking that you get the add event first, before the table is set up... then a change event
<psusi> that's a problem
<fabbione> lvm-common_1.5.20ubuntu9 ?
<iwj> fabbione: t
* fabbione upgrades
<psusi> that means that udev needs to NOT try to look at the device when it gets an add event because it may not yet be accessible
<psusi> you need to wait for the first CHANGE event before trying to access the device... and there can be subsequent CHANGE events that you would want to ignore?
<fabbione> iwj: lvm-common doesn't invoke update-initramfs-. we need to fix that
<iwj> fabbione: Urr, I'm not convinced it should.
<psusi> what's more, the block device can be in a suspended state where attempts to scan it will block... that could be bad
<iwj> If your current setup is working it probably ought to leave it.
<fabbione> iwj: ok.. let's talk about it a few
* fabbione reboots and hopes
<psusi> iwj: who says it is currently workign?  if you are installing lvm it needs to update-initramfs to get its init script in there
<iwj> psusi: I was talking to fabbione there.
<iwj> Oh, I see.
<iwj> You can't move your / to lvm without doing quite a lot of stuff.
<iwj> Arguably mkinitramfs is just another entry in that list.
<psusi> think boot from livecd, chroot into lvm
<psusi> then install the lvm package
<psusi> at that point it is not in the initramfs
<psusi> so when you reboot, it won't work... I'd expect it to be working after installing the package
<Mithrandir> Riddell: I'm going to reject the kopete SRU; please reupload where you use the appropriate -v parameter to dpkg-buildpackage/debuild.
<Riddell> Mithrandir: ok
<psusi> hrm.... how could you make sure you don't block trying to probe the dm device if it is suspended?  hrm....
<fabbione> iwj: it didn't really work.. 
<fabbione> iwj: the commands where there.. vgchange and co.. but it's like they have never been executed
<fabbione> iwj: debugging now...
<iwj> fabbione: What does lvdisplay and dmsetup table say ?
<iwj> Urr, I suppose the initramfs may not have these ...
<psusi> come to think of it this is a more general problem... you don't want udev blocking on the utility that scans a cd for its volume ID if it is going to take 5 minutes because the cd is dirty
<fabbione> iwj: none of the vg were activated
<fabbione> iwj: i had to run manually vgchange -a y 
<iwj> That's just weird.
<iwj> And then that worked ?
<fabbione> yeps
<fabbione> i wonder if the issue might be watershed
<iwj> Oh, that's probably missing too still.  Duh.
<iwj> *thumps head on desk*(
<iwj> Sorry to put you to pointless trouble, that was entirely predictable.
<iwj> I will revert this change right away.
<fabbione> iwj: wait...
<fabbione> isn't watershed already in udev?
<iwj> Keybuk says it's in some patch he has but which isn't in our udev.
<fabbione> don't revert.. let's get it fixed.. testing on this machine is a pain
<fabbione> we might as well do it now that i am in ub3r t3xt m0d3
<iwj> patch> which he's going to review RSN honest guv.
<fabbione> Keybuk: ^ can you confirm pretty please?
<fabbione> ok
<fabbione> iwj: i assume that if i remove the call via watershed it should work
<iwj> Yes.
<fabbione> ok
<fabbione> let me test that
<iwj> Well, apart from (a) the symlink race and (b) the lack of udev-devmapper.
<iwj> So really no.
<psusi> hrm... does udev wait for RUN+= to complete or does it fork it in the background?
<iwj> psusi: It waits.
<psusi> damn... that is not good
<psusi> what if the program hangs?  udev stops processing events?
<iwj> Only that event.
<psusi> ohh.... ok...
<fabbione> iwj: still worth a shot
<fabbione> brb
<iwj> fabbione: Good luck.  You have more keenness to watch your machine not boot than I do I think ...
<cjwatson> that's what break= is for :-)
<cjwatson> ("hi, I'd like to boot up my machine by hand. Pass the toggle switches")
<sbalneav> BenC: Have you got a minute?
<BenC> sbalneav: depends if it's a real minute, or one of those extended ones :)
<psusi> you said udev will block processing of that event for the duration of the external program.... do you mean that event, or events from that device?
<iwj> I think that event.
<psusi> i.e. can a device generate an add, then a few changes, and have them all processed by udev in paralell?
<iwj> Does udev even internally connect different events for `the same device' ?
<psusi> hrm.... 
<sbalneav> heh, well, I'm doing some edubuntu stuff here.  Trying to share /home via NFS, and getting bitten by #62308.  ogra suggested trying 2.6.19 from feisty, but it hard panics on boot.  I'm running the -bigiron variant on a dual xeon 5 gig ram.
<bddebian> Heya
<alex-weej> any idea how i can debug ACPI suspend? my PC just turns off then instantly back on again (sans working sound card)
<iwj> psusi: But note that I'm really guessing here.
<sbalneav> Thought you might like to know the 2.6.19 hard panics
<BenC> sbalneav: dual xeon just needs -generic
<BenC> bigiron isn't mean for a machine that small
<ogra> that didnt detect the 5 gig iirc
<BenC> meant
<BenC> -server than?
<sbalneav> Will I see the 5 gigs then? I needed the -bigiorn for the memory stuff to see beyond 3.5 gig
<ogra> -server might be suitable
<sbalneav> I'll try
<BenC> I think -server will work
<sbalneav> ok, let me try, thx
<BenC> np, let me know how it goes
<cjwatson> sbalneav: BTW, I had a look at turning off encryption in ssh. There's a patch out there that allows rekeying to the null cipher *after* authentication, which I think is much better than plain Cipher=none; it forbids rekeying to null if there's a tty open, and IIRC it forbids password authentication if you're using that feature. Would that work for you?
<sbalneav> That would be tres sexy.
<ogra> BenC, in any case i need proper NFS in feisty #62308 would bite me hard since edubuntu will run ldap and nfs mounted homes by default 
<cjwatson> sbalneav: the patch isn't in a suitable form at the moment, so it would take some work, but the upshot would be that you'd do NoneEnabled=yes on the server and NoneEnabled=yes + NoneSwitch=yes on the client.
<cjwatson> or words to that effect
* sbalneav slides cjwatson an e-beer
* ogra puts a box of e-beers on top of that :)
<cjwatson> I'm not all that happy with the option naming, but given that the patch is out there and semi-widely used (it's part of the HPN-SSH patches), it's probably the lesser evil to stay compatible with it.
<BenC> bug 62308
<Ubugtu> Malone bug 62308 in linux-source-2.6.17 "Permission Denied on nfs clients for only some files" [High,Confirmed]  http://launchpad.net/bugs/62308
<sbalneav> Dealing with that's just a doco problem.
<cjwatson> sbalneav: so you definitely don't need to open a terminal over the ssh session with Cipher=none - just X forwarding?
<ogra> cjwatson, just call it TotallyInsecure=Yes ... would work as well, and give you a subtile warning
<BenC> ogra: I think we have a fix for that bug, and I'm pretty sure it's edgy-only
<sbalneav> Just X forwarding
<iwj> option naming> You should counter with SomeEnabled, AnyConditionallyEnabled, MysteryOptionValue=313, etc.
<ogra> BenC, ah, cool, thanks
<BenC> ogra: Kyle worked on it with support last week, so we have a patch that fixed issues with nfs
<kylem> BenC, it's edgy only afaict... nobody has complained about nfs <4 being broken on lkml afaict.
<cjwatson> ogra: heh, as I say I think it's probably the lesser evil to stick with what other people are using and let upstream fight that battle at some point
<sbalneav> BenC: Is the fix in the works? i.e. will we see a new kernel shortly?
<ogra> heh, ok
<BenC> kylem: Did that make it into the last edgy kernel upload?
<cjwatson> upstream typically renames options when they accept them, and I'm unlikely to be able to predict how they'll do that anyway
<kylem> BenC, no, it wasn't in the security tree. there's a rub to it too.
<cjwatson> iwj: :-)
<fabbione> iwj: ok.. i think i found the problem. lvm is in local-top and it's executed way after udev. It looks to me that vgchange isn't there at the time we need it.
<fabbione> iwj: i am going to test this theory too
<kylem> BenC, while it fixed the problem for $client, i got an email reporting it broke things worse for someone.
<fabbione> iwj: sorry if it takes so long but i need to wait the 3 minutes timeout to get to busybox on each reboot
<iwj> fabbione: I think you're wasting your time but it's up to you.
<BenC> kylem: Maybe just reverting all of nfs/nfsv4 in edgy to stock code would be the best thing
<kylem> BenC, i think that's probably best.
<iwj> fabbione: but re the symlink think, obviously we should fix it so we can include the links in the initramfs.
<iwj> s/think/thing
<wasabi> ya'll debugging the failure of lvm/md in feisty initrd?
<iwj> wasabi: Ah, hello.  fabbione is trying to get it to work but I think he's doomed.
<ogra> wasabi, no, some of us do regular work as well :P
<wasabi> Seems to me to be that nothing is forcing them to wait for udev to find actual devices.
<iwj> There are too many bits missing.
<wasabi> so it's a simple race
<fabbione> iwj: well i am going to test this last one and then stop. 
<wasabi> they run before udev even knows drives exist.
<iwj> wasabi: Half of the new arrangements for feisty have been implemented but not the other half.
<wasabi> Yeah.
<iwj> fabbione: OK, have fun :-).
<fabbione> iwj: since i am in debugging mode i might as well check what's needed for the other bits
<wasabi> I've just stuck a 5 second wait in my initramfs until somebody finishes it. :0
<iwj> wasabi: I'm just going to wait for fabbione and then I'm going to revert it (assuming I can persuade fabbione that this isn't a hideous idea).
<wasabi> All that local-* stuff just needs to fire in response to udev events properly... which it doesn't.
<wasabi> heh
<wasabi> Did we decide authoritatively to use evms for all?
<iwj> wasabi: No.
<wasabi> Or was that just crack.
<wasabi> alas. That would sure simplify the situatioon (except for raid10 users!)
<fabbione> iwj: DOH! udev rules are not all copied in the initramfs!
* fabbione digs that
<fabbione> iwj: i blame udev :)
<fabbione> check /usr/share/initramfs-tools/hooks/udev
<fabbione> it just doesn't copy all
<Keybuk> of course not
<Keybuk> most of them are entirely inappropriate
<Keybuk> if lvm has rules, it's up to lvm to ensure they're in the initramfs
<psusi> yea, the initramfs hoook scripts need to copy additional udev rules you install
<wasabi> lvm's package probalby just needs a set of rules specific for initramfs.
<wasabi> repeat for evms and mdadm
<iwj> Keybuk, fabbione: yikes.
<iwj> fabbione: Please please say you want me to revert this now.
<wasabi> what's the change being reverted?
<wasabi> or, proposed for revertion.
<Keybuk> iwj: the lvm hook needs to copy its udev rule
<fabbione> iwj: i have almost done.. let me check if it works.. 
<fabbione> iwj: lvm-common doesn't update the initramfs so it won't break too much
<iwj> fabbione: You've almost reverted it ?
<iwj> wasabi: lvm-common (1.5.20ubuntu9) feisty
<fabbione> iwj: no, fixing the copy of the udev rule
<fabbione> iwj: don't worry about my ws.. i can still boot it manually.. it's not an issue at all
* fabbione tests again
<iwj> fabbione: Yes, but I want to not break everyone else's !
<iwj> Or at least to undo it before it breaks someone's machine.
<fabbione> iwj: screw everyone else :) this is feisty .. breakage is expected
<fabbione> brb
<wasabi> It's feisty. Who cares.
<wasabi> =)
<psusi> so you have udevified lvm in feisty now?
<wasabi> part of it.
<psusi> I need to get cracking on doing that for dmraid
<wasabi> same needs to be done for mdadm
<wasabi> Actually, this is bugged.
<wasabi> Needs to be thought of a bit more.
<wasabi> These udev rules will run even when they shouldn't: when evms is being used.
<wasabi> Hence, mdadm will build arrays that evms should be responsible for.
<psusi> isn't evms just lvm + mdadm sloshed into one?
<wasabi> Yes, but it builds the arrays on it's own, using different devmapper devices.
<psusi> why bother with evms then?
<psusi> just let lvm and mdadm handle it
<wasabi> Because it does it better. :0
<psusi> how so?
<wasabi> For instance, if you have md0 containing /dev/sda2 and /dev/sdb2, evms will use devmapper to make /dev/evms/sda2 which is not the same device as /dev/sda2
<iwj> I've uploaded a reverted version now.  With entries in the changelog explaining what was wrong.
<iwj> There's no harm in uploading a working version later when we have one.
<wasabi> psusi: Because it brings the entire stack into one management tool/api.
<wasabi> It is a pleasure to use.
<psusi> wasabi: you mean evems sets up a direct linear mapping for the physical devices to support snapshots?
* iwj goes back to gdm.
<wasabi> Pretty much. It duplicates hte kernel partition support.
<psusi> wasabi: ok... then just use evms and ditch lvm/mdadm ;)
<madduck> wasabi: what use is /dev/evms/sda2 when it's part of a RAID?
<wasabi> Exactly.
<wasabi> madduck: evms uses /dev/evms/sda2 to assembly the md device.
<fabbione> iwj: ok.. copying the rule works
<madduck> so?
<wasabi> If mdadm goes off an assemblies the device ALSO using /dev/sd.
<wasabi> You'll get two devices.
<psusi> wasabi: yea, but what good does that do?  why not just use the real sda2?
<madduck> sure, but i am much more interested in why evms is supposed to be so much better
<fabbione> iwj: and that's the only change (+ the watershed) that i had to do
<wasabi> psusi: Sort of goes to the heart of the design of evms.
<wasabi> psusi: The goal to be one API and interface to manage all partitions all teh way to the top layer.
<madduck> "brings the entire stack into one management tool/api" and "duplicates hte kernel partition support" sounds like a windows application to me, not Unix.
<wasabi> So you can do high levle operations, and it can use the various pieces in the stack intelligently to prevent dumb operations.
<psusi> wasabi: so evms ignores the existing partition devices, finds the raw disk device, and makes its own partition devices for it?
<wasabi> Correct.
<psusi> wasabi: ok... so let's use evms only, and disable the partition code in the kernel ;)
<wasabi> It would be safe to say evms is designed to replace mdadm/lvm and kernel partition code.
<madduck> great idea
<wasabi> psusi: That's what we talked about at UDS.
<madduck> and rewrite all tools that use the established standards.
<wasabi> I just don't think anybody has taken reponsibility for driving that out.
* madduck fades out of the discussion
<wasabi> Am I wrong?
<iwj> fabbione: I think also the symlinks need fixing and there's a race where it might not find your root fs if the lvm stuff is too fast.
<psusi> ohh yea... that will break things like fdisk and parted
<wasabi> Won't break fdisk I don't believe.
<wasabi> fdisk will modify the real device, /dev/sda.
<psusi> yea.. it will... fdisk expects the real block device and for it to support the BLKPRT ioctl
<fabbione> iwj: probably.. but very unlikely... this machine is very fast at bringing up devices and lvm in local-top did still run faster
<psusi> dm does not
<wasabi> Something, either the kernel partition table or evms will need to rescan the devices and recreate the parititon maps
<fabbione> iwj: anyway the rule work and that's good
<wasabi> Oh.
<iwj> fabbione: Right, that's good to know.  I think this is definitely useful info.
<iwj> I've captured it in the changelog entry I think.
<psusi> so you could still run fdisk on the raw block device, but you would have to reboot for changes to take effect
<fabbione> iwj: well it's only 2 changes... -watershed and copy the rule... that's all i did at the end
<wasabi> How so?
<wasabi> You'd just need to have evms rescan.
<fabbione> iwj: or at least what i have now to boot the system
<psusi> well, yea... you could manually force a rescan
<iwj> fabbione: I think we need udev-device-mapper too but you were lucky.
<psusi> but fdisk doesn't know how to force evms to rescan, and neither does parted
<wasabi> Those would have to be corrected, yes.
<iwj> fabbione: Either that or I don't quite understand the boot process.
<iwj> Which is quite likely :-).
<fabbione> iwj: probably yes, but i was able to observe the devce-mapper race only when doing some very complex operations
<iwj> fabbione: Mmhm.
<fabbione> iwj: like take 200 lvm snapshots of the same device
<fabbione> iwj: that was triggering the race that we discussed at UDS
<iwj> That's just cruel.
<fabbione> iwj: i wish nobody did that.. but well there is a bug in LP
<wasabi> So how are you all proceeding? Using udev or not?
<iwj> wasabi: We're going to have udev but I think not quite yet.  In January.
<psusi> udev handling of dm devices is going to be very sticky
<iwj> psusi: https://blueprints.launchpad.net/distros/ubuntu/+spec/udev-device-mapper
<wasabi> So what's up with the current setup? Will mdadm/lvm wait for devices to appear?
<psusi> since the device isn't neccesarily accessible when udev gets the add event
* psusi heads to lunch
<iwj> wasabi: edgy has a kludge, which I've just redeployed.
<wasabi> Does the kludge effect just lvm-common or mdadm too?
<wasabi> My current trouble has been with mdadm.
<fabbione> wasabi: that will be fixed too
<fabbione> wasabi: needs udev integration
<wasabi> Not until a lot of discussion takes place. ;)
<fabbione> wasabi: it already happene
<fabbione> +d
<fabbione> and it has been decided
<wasabi> Does it disable itself when ROOT=/dev/evms/*?
<wasabi> Because otherwise people are going to be not to happy.
<fabbione> what had that to do with running raids?
<wasabi> currentl local-top/mdadm local-top/lvm are DISABLED when ROOT=/dev/evms/*
<wasabi> For good reason.
<fabbione> no they are not...fabbione@gordian:/usr/src/ubuntu/mdadm/mdadm-2.5.6/debian/initramfs$ grep evms script.local-top 
<fabbione> fabbione@gordian:/usr/src/ubuntu/mdadm/mdadm-2.5.6/debian/initramfs$ 
<fabbione> wasabi: and never was
<fabbione> not even in debian
<wasabi> Read the top of local-top/mdadm
<wasabi> Oh, sure nuff.
<wasabi> lvm is though. ;)
<fabbione> wasabi: i am not sure to what code you are looking at, but there is no such thing you are mumbling about
<wasabi> Hmm. That's scarey.
<wasabi> Give me a minute, going back in time.
<wasabi> vg=${ROOT#/dev/mapper/}
<wasabi> case ${vg} in
<wasabi> ... blah blah
<wasabi>         /*)
<wasabi>                 exit 0
<wasabi>                 ;;
<fabbione> dude...
<fabbione> read the code
<fabbione> that's not to skip evms but to make sure that we have vg and lv
<fabbione> for the next check
* madduck is looking forward to mdadm patches
<fabbione> if by mistake you have a root=/dev/mapper/evm-root it will check for /dev/evms/root
<wasabi> Am I not correct that that code wille xit when ROOT does not start with /dev/mapper ?
<fabbione> madduck: speaking of which... i reduced the delta between our packages a lot
<madduck> fabbione: very nice. thanks.
<azeem> is Ubuntu using bzip2 for the data.tar in .debs?
<fabbione> madduck: are you back from vac?
<fabbione> madduck: or are you busy? 
<azeem> or just (optionally) for the orig.tar?
<madduck> yes and yes
<elmo> azeem: on a very tiny proportion of .debs, yes
<fabbione> madduck: ok.. you let me know when you want to talk about it
<azeem> elmo: eh, to the former?
<elmo> azeem: we're not using it for orig.tar (except in the way debian does)
<wasabi> Hmm. Sure nuff.
<elmo> azeem: yes, to the former
<fabbione> madduck:  8 files changed, 15 insertions(+), 30 deletions(-)
<azeem> elmo: oh, I thought orig.tar.bz2 wasn't allowed for Debian yet
<madduck> fabbione: currently i don't know if that'll be this year. maybe towards the middle of next week.
<azeem> elmo: thanks
<fabbione> madduck: next week i will be in Seattle.. next year it is
<cjwatson> azeem: Debian does it by .tar.bz2 inside .tar.gz, or by recompressing
<elmo> azeem: right, it's not.  by the way "the way debian does", I mean orig.tar.gz with bz2 inside
<madduck> yup
<cjwatson> we're the same
<azeem> elmo: ah, ok
<cjwatson> azeem: we use bzip2 on data members of .debs for language packs and a couple of other manually selected things where it's a big win
<elmo> diveintopython being the canonical example
<elmo> (ba boom tish)
<cjwatson> that was a test case :)
<cjwatson> azeem: it's set in debian/rules, anyway
<azeem> cjwatson: thanks
<wasabi> Keybuk: Do you remember the conversation we had at UDS... at some point, which I don't remember... where it came up that if you are using evms, md and lvm should not be used?
<wasabi> I remember you being there. That's all I remember.
<wasabi> Since mdadm will essentially do the same work evms will do, using differnet partitiond evices, resulting in the same array existing twice or some such.
<wasabi> Surely I'm not dreaming this up.
<Keybuk> yes, I remember that we discussed that
<Keybuk> EVMS is able to manage block devices ordinarily managed by both LVM and MDADM, for this reason these two services will be disabled if EVMS is installed, ideally we'd like to prevent them from being installed at all, but this has consequences for upgrades from when we used to install evms by default.
<Keybuk> -- 
<Keybuk> so does the spec
<wasabi> Okay. Here's my worry, fabbione, right now, it works fine. Whether this is an accidental byproduct of the order that local-top/evms|md|lvm run, perhaps alphabetically, I'm not sure. Evms maps this right. I'd be concerned about this situation changing when using udev, since the detection of a new device will invoke all of mdadm/vgchange/evms_activate.
<wasabi> Perhaps in a differnt order, or at the same time.
<wasabi> (what will udev do there?)
<Burgwork> evand: ping
<ogra> Keybuk, thanks for the clearification then ... i'll dig my way through the ioctls
<ogra> (fusermount needs still to be there anyway)
<Keybuk> ogra: I don't know the precise mechanism about how it all happens
<Keybuk> but it's definitely along those lines
<ogra> yeah, i'll just dig my way along loop :
<psusi> what is /dev/evms?  the device mapper devices it creates go in /dev/mapper
* dholbach hugs keescook
<keescook> :)
<keescook> woo! more emblems! :)
<psusi> I have noticed that vi installs a mailcap rule making it the viewer/editor for text/*... isn't this improper?  shouldn't mailcap respect $EDITOR and use the user's choice of editor?
<seb128> doko: fix gcc!
<mvo> seb128: you are in a mood today, aren't you :P
<seb128> mvo: well, I can't build any package without gcc :p
<seb128> mvo: and I would not have removed it for sure if something would have asked me about it :p
* mvo hugs seb128
<ogra> that wouldnt have happened if you would have written your software in binary code from the beginning 
* mvo will add a "gcc can never removed if user == seb128"
<mvo> ogra: exactly right! binary code frees you from your dependencies!
<ogra> yeah !!
* seb128 hugs mvo
* psusi starts flipping the toggle switches to enter program code
<ogra> faster, go faster !!
<psusi> I'm workin' as fast as I can captain, I just dunno have the power!
<ogra> heh
<ere> I have a problem with xserver-xorg-video-intel and vga-out on Edgy. Use 1024x768 on the LCD display on a Dell Latitude D520. Toggle vga-out with Fn+F8 and get 1360x768 on the projector! (the projector displays the resolution when the video source is found). Any suggestions? I want 1024x768 4:3 on the projector too. And it works well with Dapper
<iwj> cjwatson: AYT?
<iwj> cjwatson: I wanted to run this apt dist-upgrade Breaks SRU idea past you.
<ere> Dapper with the i810 driver that is. I tried the intel driver to get better performance in Google Earth. 
<proppy> infinity: ping
<psusi> rather than just guess the mime type of a file based on its extension, shouldn't mailcap invoke file -i to find out?  and why does it default to application/* instead of text/plain?  would be nice if you could just run "see somefile" or "edit somefile" and have it work
<sistpoty> proppy: you could try pinging Mithrandir instead (and it would make sense to also state the reason for the ping ;)
<proppy> Mithrandir: ping (buildd Chroot problem)
<proppy> from http://librarian.launchpad.net/5372767/buildlog_ubuntu-feisty-i386.poker-network_1.0.32-1_CHROOTWAIT.txt.gz
<proppy> The following packages will be REMOVED:
<proppy>   apt* build-essential* g++* g++-4.1* libstdc++6* libstdc++6-4.1-dev*
<proppy> weird
<proppy> which result in a Status:  	 Chroot problem
<proppy> could i ask for a retry ?
<evand> Burgwork: pong
<proppy> sistpoty: thx
<chuchiperriman> someone are working on anjuta project??
<iwj> There seem to be more and more people with corrupted /var/lib/dpkg/status.
<Mithrandir> proppy: I know about it.
<proppy> Mithrandir: ok np
* proppy hugs Mithrandir
<Mithrandir> proppy: doko just phoned me, it requires manual hand-holding which infinity will do once he gets up.
<Mithrandir> but thanks for telling me.
<proppy> np
<proppy> so sad it happened the day after he left :)
<Mithrandir> yeah, but such things happen.  It's not that hard to get fixed, but I don't have access to fix it myself.
<Mithrandir> anyway, back to roleplaying.
<proppy> happy dungeoning
<psusi> nethack? ;)
<Mithrandir> no, pen and paper
<Mithrandir> anyway, afk for real.
<ajmitch> morning
<keescook> hiya ajmitch
<bhale> sabdfl: can I ask a question without derailing your meeting?
<sabdfl> bhale: fire away, quickly, i'm about to head afk
<bhale> sabdfl: i am wondering about the CC calls, it feels like that detracts from transparency quite a lot
<bhale> if decisions will be made there
<bhale> I think Seveas is a fantastic secretary, and I of course trust your judgement, it is really the spirit of the thing
<bluefoxicy> heh
<sabdfl> bhale: they happen very rarely
<bluefoxicy> apt desparately need the ability to downgrade; or Feisty desperately needs new packages
<sabdfl> we had one recently to discuss binary drivers
<sabdfl> this latest one was to discuss new CC nominations
<sabdfl> those are by necessity private conversations
<sabdfl> we also have a private mailing list
<seb128> bluefoxicy: apt can downgrade, apt-get install package=version
<sabdfl> but traffic is very low
<bhale> makes sense
<sabdfl> i understand your concern, hope you can appreciate there are some things that do require discretion
<sabdfl> there are non-canonical folks on both TB and CC, and more coming (i hope :-))
<bluefoxicy> seb128:  ah, cool.  I'm staring at something I got from the repos when I switched to feisty (gimp, xorg, and about 15 libs) that all say "local or obsolete," they're higher versions that the feisty repos report now.  Maybe they floated over from dapper or something.
<bhale> of course, it just came as a suprise now
<bluefoxicy> seb128:  I'll try that.
<fjg> who can i talk to regarding the ubuntu websites?
<bhale> thanks sabdfl 
<sabdfl> np
<dsas_> fjg: newz is the webmaster
<dholbach> bhale: you said I looked like paul mccartney?
<dsas_> fjg: See also https://launchpad.net/products/ubuntu-website
<bhale> dholbach: very young paul indeed
<bhale> dholbach: i was watching some dvds, he is very energetic and all smiles
<dholbach> hehehe - it really made me laugh :)
<fjg> thank you
<bhale> dholbach: here
* dholbach hugs bhale
<sabdfl> newz2000 iirc
<bhale> http://beatles.at.infoseek.co.jp/pa5.jpg
<bhale> dholbach: ^
* bhale hugs dholbach
<ajmitch> definitely the same
<dholbach> I was just about to ask who else thinks that way... ;-)
<Burgwork> fjg: is it a minor bug or a major change?
<fjg> minor
<bhale> dholbach: Corey knew what I was talking about
<Burgwork> file a bug at https://launchpad.net/products/ubuntu-website
<Burgwork> sabdfl: a few of the community can fix minor bugs as well
<fjg> ok thx
<Burgwork> fjg: no worries, thanks for the bugs
<ere> I have a problem with xserver-xorg-video-intel and vga-out on Edgy. Use 1024x768 on the LCD display on a Dell Latitude D520. Toggle vga-out with Fn+F8 and get 1360x768 on the projector! (the projector displays the resolution when the video source is found). Any suggestions? I want 1024x768 4:3 on the projector too. I get correct resolution with dapper and the i810 driver
<_ion> I could swear i've seen someone saying that before. There's probably a bug report already.
<keescook> are the feisty buildd chroots hosed at the moment?  (been seeing inkscape build emails...)
<ajmitch> yeah, apt/gcc fun I think
<imbrandon> ugh
<imbrandon> it is the 2gb limit in 2.0.59
* imbrandon might just install apache 1.3
<imbrandon> man i dident wanna deal with this today
<cypher1> i have one enhancement for apt-get, apt-get should have the capability to download packages from repositories across multiple sessions
<LaserJock> got the code for it?
<keescook> cypher1: I thought it already did that?
<cypher1> LaserJock, no
<cypher1> keescook, ah.. is it mentioned somewhere..i have not seen anyone mention or use it.. 
<keescook> cypher1: you're talking about partial download resumes, right?  I've seen it do that.  :)
<cypher1> keescook, yes
<cypher1> keescook, even the packages that it had stopped in middle ?
<keescook> cypher1: as far as I know, yeah.
<_ion> I don't remember apt-get ever *not* doing that.
<keescook> it puts all that stuff in /var/cache/apt/
<cypher1> keescook, ok then thats cool
<cypher1> keescook, yes if that works for the package whose download is in progress then its ok
<cypher1> let me try it out.. i am downloading a package.. i will do a ctrl-c and restart it
<cypher1> keescook, bingo it resumed :)
<darek> hi
<keescook> cypher1: excellent.  :)
<mdke_> cjwatson: I wanted to let you know I couldn't be at the CC meeting and to flag up the WikiLicensing agenda item. I'm just checking the log now
<mdke_> cjwatson: looks like it wasn't discussed. I can't even find a reference to it being put off...
<gnomefreak> mdke_: we put off most of the top agenda items
<gnomefreak> including yours. cjwatson and mako had to leave
<mdke_> right, thanks
<mdke_> I'll try another email, you never know when your luck will change
<somerville32> Does anyone know what apt-index-watch is?
<somerville32> Oh wait, it is apt-index-watcher. nvm :] 
<gnomefreak> somerville32: we are waiting for an update for it i bellieve
<somerville32> gnomefreak: IT is using up 90% of my CPU in Edgy and if I kill it then it restarts
<mako> mdke_: sorry about that
<gnomefreak> somerville32: what version?
<somerville32> apt-index-watcher version 0.3.9
<gnomefreak> ubuntu?
<gnomefreak> it should be 3.9ubuntu5?
<gnomefreak> or 4?
<somerville32> Thats not the package version
<gnomefreak> somerville32: you didnt get it from ubuntu?
<somerville32> Version: 0.3.9ubuntu5
<gnomefreak> ty
<gnomefreak> mine is barely using anything.
<somerville32> 11% memory and 70-90% CPU
<somerville32> I tried restarting
<somerville32> It is rather weird
<gnomefreak> somerville32: rebooting work?
* somerville32 shakes head.
<somerville32> I noticed the issue last night
<somerville32> Turned my computer off while slept
<somerville32> Woke up for CC 
<somerville32> and noticed the issue
<somerville32> And in top, it is marked as running
<somerville32> Which is weird
<gnomefreak> yeah it is mines not in top just in ps aux
<gnomefreak> somerville32: unless it is running right now on yours
<somerville32> If I kill it, it restarts.
<gnomefreak> somerville32: does update/'upgrade/dist-upgrade still work?
<somerville32> It is a naughty process
<somerville32> Let me check
<gnomefreak> brb drink while your checking
<somerville32> gnomefreak: Appears to work. I just upgraded mdadm.
<gnomefreak> hmmmmmm that i didnt expect
<gnomefreak> somerville32: im not sure but you might try  sudo rm /var/cache/apt/*.bin
<gnomefreak> brb drink still
<somerville32> gnomefreak: That fixed it. Thanks
<gnomefreak> somerville32: yw
<cjwatson> iwj: Breaks SRU> maybe tomorrow now? but happy to discuss it ...
<cjwatson> mdke_: yeah, sorry, we did as much as we could before I left, and anything after that wasn't my responsibility :)
#ubuntu-devel 2006-12-13
<bddebian> Heya
<hardaway_> when will openoffice 2.1 be in feisty
<jdong> in 5..4...3...2...1....
<jdong> 0.5....0.25.....
<bddebian> heh
<Hobbsee> 42!
<jdong> it's there now!
<jdong> (ha ha, made ya look)
<_ion> hobbsee: 1405006117752879898543142606244511569936384000000000
<Hobbsee> :P
<jdong> aha, that's 42!
<jdong> (yeah, I'm a bit slow this evening)
<_ion> And it's m6jperiu2qj2escmbvoo5edc000000000 in base-36!
<_ion> Actually quite interesting that the final nine digits are zeros in both base-10 and base-36.
<cjwatson> true for any multiple of 180^9 with no further factors of 5 or 18
<cjwatson> but yes :)
<cjwatson> er, just no further factors of 10 or 36 I guess
<Hobbsee> Mithrandir: ping?
<Hobbsee> Mithrandir: is http://librarian.launchpad.net/5372957/buildlog_ubuntu-feisty-i386.sylpheed-claws-gtk2_2.6.0-1ubuntu1_CHROOTWAIT.txt.gz known about?  i seem to ge tit on most arches
<MoronShrek> I just got a $300,000us year contract
<MoronShrek> w00t!
<deltab> congratulations!
<fabbione> morning
<Hobbsee> hey fabbione!
<fabbione> hi Hobbsee 
<Laser_away> hi Hobbsee and fabbione 
<fabbione> hi
<Hobbsee> hey Laser_away 
* Hobbsee fights with LP
<Hobbsee> STUPID LAUNCHPAD!  DO WHAT I WANT!
* Hobbsee smashes LP with a brick
<Laser_away> Hobbsee: easy now
<pitti> Good morning
<_ion> Hi
<pitti> hi _ion 
<_ion> What's up?
<proppy> hi
<fabbione> pitti: wget is not that bit and we can strip busybox wget from being built
<fabbione> pitti: we already pull in libssl for other stuff anyway
<fabbione> so the size bloat would be minimal
<pitti> fabbione: ah, if we do have a libssl udeb, then maybe you should just have a wget udeb then, with ssl support?
<fabbione> pitti: that was the idea.. yes
<pitti> right, that's what I meant
* pitti hugs fabbione 
<fabbione> i need to talk to cjwatson first
<fabbione> adding udebs at random can be dangerous
<fabbione> specially when replacing "known to work" busybox commands
<Mithrandir> fabbione: I suspect that gnu wget is way bigger than busybox wget.
<pitti> Mithrandir: hm, seems that your postgresql-8.2 sync went to Nirvana :/
<Mithrandir> pitti: maybe it just went to NEW.
<pitti> just checked the queue, it's not there
<pitti> Mithrandir: does the sync stop completely if an error occurs/
<pitti> s_/_?_
<fabbione> Mithrandir: well it can be made optional only for system-integrity-check
<fabbione> we don't necessarely need to replace wget in busybox by default
<Mithrandir> pitti: hmm, let me investigate.  And hope I didn't sync it into edgy or something.
<Fujitsu> Hahah.
<pitti> slomo_: I wonder whether we actually need to carry this dbus at_console patch -- it's broken, and we don't use it after all
<owh> Just wondering what the protocol is for editing/adding/removing tags. I've been searching for bugs with the word ThinkPad in them and tagging them accordingly - seeing that I have one of those, and I figured I could help out in a small way. In the process I've also edited tags where the majority of the tags were plural and a few singular.
<owh> Should I cease and desist this, or am I doing an appropriate thing>
<owh> s/>/?/
<dholbach> good morning
<pitti> hey dholbach 
<Mithrandir> seb128: https://wiki.ubuntu.com/FeistyReleaseSchedule ; can you take a look at the herd milestones and tell me you don't go "aiee"? (wrt gnome's releases, etc)
<dholbach> heya pitti
<dholbach> hey Mithrandir
<dholbach> hey seb128
<seb128> sure
<seb128> hi dholbach
<seb128> hi Mithrandir
<Mithrandir> mornining Daniel
<Mithrandir> morning Sebastien
<seb128> Mithrandir: Herd-2, aiee
<dholbach> morninigningningning everybody else :)
* owh wonders if anyone noticed the tags question :-)
* owh asked initially in #launchpad and was directed here by jamesh.
<seb128> Mithrandir: herd-4, aiee
<seb128> Mithrandir: well, tarball are due on monday and usually we are done with packaging on wednesday, so it you don't freeze too soon that's fine
<Mithrandir> seb128: we'll be aiming for a thursday release in the common case, but I'd like to not have the world falling down on wednesday.
<seb128> Mithrandir: we can be done on tuesday evening, not before though
<cjwatson> fabbione: I'd rather patch wget/https into busybox; minimal impact
<seb128> Mithrandir: if that works for you ...
<seb128> Mithrandir: http://live.gnome.org/TwoPointSeventeen for reference
<Mithrandir> seb128: we could move all the herds out one week if that'd make it better for you?
<fabbione> cjwatson: i phear a lot of code there and tons of bugs.. 
<cjwatson> fabbione: might need to dlopen libssl though, or something like that, otherwise we'll pull libssl into the initrd
<fabbione> cjwatson: yes that too...
<seb128> Mithrandir: I'm happy to keep like that if you are happy to freeze on tuesday evening, that makes us ship with almost crack of the day new GNOME for herds ;)
<seb128> Mithrandir: otherwise shifting one week would be better, though it would conflict with the distro sprint by example
<Mithrandir> seb128: no, I'd move them out, as in, a week later.
<cjwatson> I suppose a wget-udeb isn't impossible; it could be /usr/bin/wget.gnu or something
<fabbione> cjwatson: the latter is what i was thinking
<Mithrandir> seb128: but CotD sounds excellent to me.
<fabbione> cjwatson: a lot less code and only pulled in if rescue is selected
<Mithrandir> seb128: we can at least try it for the first one and if it's too painful, we move the herds.
<seb128> ok
<fabbione> cjwatson: so it's not too much overhead in code or size
* seb128 hugs Mithrandir
<cjwatson> not rescue in general surely?
<cjwatson> just s-i-c?
<fabbione> cjwatson: well rescue will pull in s-i-c unconditionally
<fabbione> cjwatson: given that's a menu hook.. etc .etc .etc
<fabbione> brb
<fabbione> re
<pitti> cjwatson: dapper/edgy-proposed langpacks are out for 8 days now, and got some feedback (Russian tsclient continues to be broken, but not any different than before, and all other people just reported improvements)
<pitti> cjwatson: can you give an ack for an -updates upload, or only mdz?
<pitti> hi doko
<doko> good morning
<cjwatson> pitti: I can. What happened to getting the process onto the SRU wiki page?
<pitti> cjwatson: there's still no formally agreed-on process yet, I should bring this up in the next TB meeting
<pitti> cjwatson: so far it was just 'propose, collect feedback on the -translators ML, test yourself, go'
<seb128> dholbach: did you do any launchpad change which makes me receive universe sponsorship mails now?
<pitti> carlos: could you please take a look at bug 68646?
<Ubugtu> Malone bug 68646 in tsclient "Russian l11n in tsclient is broken" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68646
<carlos> pitti: sure
<pitti> carlos: the Russian tsclient.po contains just garbage
<pitti> msgid "Connect to a remote computer"
<pitti> msgstr "   "
<pitti> carlos: it's a bit weird
<pitti> carlos: the letters are all perfectly cyrillic, but they do not make sense at all
<carlos> is it specific for Rosetta?
<pitti> carlos: and some strings are fine
<pitti> carlos: let me look into the upstream source
<carlos> I mean, I guess the upstream translation is not broken that way, is it?
<carlos> pitti: in Edgy, most translations come from upstream
<pitti> carlos: upstream translations are in KOI8-R, I msgconv and check
<pitti> carlos: msgconv -t UTF-8 po/ru.po |view - looks fine
<dholbach> seb128: no, I'm not aware of what might cause that
<seb128> dholbach: some team change apparently, I'm getting mails for the universe sponsors team
* carlos gets the file
<seb128> am I the only one?
<pitti> carlos: http://people.ubuntu.com/~pitti/tmp/tsclient.ru.po <- original file from upstream
<carlos> pitti: don't worry, I got it from apt
<dholbach> ajmitch: can you deactivate 'ubuntu-dev' in 'ubuntu-universe-sponsors'?
<dholbach> ajmitch: http://launchpad.net/people/ubuntu-universe-sponsors/+members
<dholbach> seb128: ^ - ajmitch or Hobbsee can fix that
<pitti> carlos: I added a comment to the bug and mangled it a bit, FYI
<seb128> dholbach: thank you
<dholbach> de rien
<carlos> ok
<carlos> pitti: That's weird, I guess the problem broke the encoding of that file uploading it in Rosetta
<carlos> pitti: we could track it now, but that was a year ago or so
<pitti> carlos: so could we just reimport the upstream file into Rosetta?
<carlos> so I cannot tell you who did it. The only thing I could do is to revert to whatever upstream has
<carlos> pitti: yes
<carlos> let me ask something in the bug report first 
<pitti> carlos: that shouldn't kill the strings that were added to Rosetta proper, right?
<carlos> no
<carlos> but I think the additions are also broken
<carlos> so I need to check one of those with someone that knows Russian
<carlos> (that's what I'm going to ask in the bug report)
<pitti> carlos: I can tell you
<pitti> carlos: I can read Russian and understand it a bit
<carlos> pitti: Do you know Russian?
<carlos> ok
<carlos> ;-)
<pitti> carlos: in any case I can tell you whether something makes sense or not
<carlos> pitti: https://translations.launchpad.net/distros/ubuntu/edgy/+source/tsclient/+pots/tsclient/ru/4/+translate
<pitti> carlos: for example, this one isn't present upstream and is fine:
<pitti> msgid "New Connection..."
<pitti> msgstr " "
<carlos> ok
<carlos> that's exactly what I wanted to know ;-)
<pitti> hehe
<carlos> pitti: I guess that means that wiz was not the one breaking translations ;-)
* carlos do some uploads to fix this issue.
<pitti> carlos: great, thanks
<proppy> Mithrandir: Chroot problem changed to Need building
<cjwatson> proppy: it wasn't Mithrandir's problem; infinity fixed it
<proppy> oh ok
<proppy> nice
<Mithrandir> proppy: you don't need to tell me about any state changes for packages in the archive. :-P
<proppy> sorry
<proppy> i'm diing to see a green bar, on it since one week :)
<pitti> meh @ evolution crashing
<fabbione> cjwatson: so can i spend sometime to make that wget-udeb or do you prefer to investigate other solutions?
<cjwatson> go ahead
<fabbione> ok.. wget.gnu it is..
<cjwatson> fabbione: done the modules -> anna/choose_modules alias in my d-i tree; I'm just checking upstream to ensure no-one objects violently to that name
<fabbione> cjwatson: great thanks
<iwj> cjwatson: Morning.
<iwj> cjwatson: re this `Breaks' SRU.  The basic bug is this: edgy's apt-get dist-upgrade breaks if there are unsatisfiable Breaks relationships.
<iwj> There is a one-line fix which I haven't yet double-checked for safety.
<iwj> We can either 1. fix this bug in edgy-updates; 2. make update-manager edgy->feisty use feisty's apt (depends on soyuz change and generally a bit of a palaver) or 3. use Breaks only in and referring to main.
<iwj> If you don't think (1) is a daft idea then I'll do some more checking and make a proper SRU proposal.
<cjwatson> dist-upgrade breaks as in falls over in a heap and refuses to continue?
<mvo> iwj: did you got my mail? I just prepared a SRU for this (and two other trivial fixes)
<cjwatson> I'm happy to consider a one-line fix for this
<cjwatson> though note that I'm fairly sure 2. doesn't actually depend on a soyuz change, although it remains a bit of a palaver
<mvo> cjwatson: yes, dist-upgrade fails over and refuses to continue
<cjwatson> fabbione: your os-prober changes look fine to me
<fabbione> cjwatson: ok can i upload or do you have more stuff in the queue?
<fabbione> or do you prefer to upload?
<fabbione> (all works for me..)
<cjwatson> fabbione: nothing from me. just use debcommit --release after updating the changelog and commit to bazaar.launchpad.net when you upload
<fabbione> debcommit ?
* fabbione digs
<cjwatson> (dunno if you use debcommit --release normally; I like to standardise on that for installer work because, lacking bzr tags, it makes releases easier to find)
<cjwatson> it's in devscripts
<fabbione> reading...
<pitti> cjwatson, Mithrandir: for apache2.2, we need to promote 'apr' to main; it's just a split-out from the former apache package, are you fine without an MIR?
<cjwatson> fabbione: oh and please use -I.bzr to dpkg-buildpackage if you don't normally
<Mithrandir> pitti: yes, as well as for apr-util.
<fabbione> cjwatson: i usually add -i that does the same
<cjwatson> fabbione: not for native packages
<cjwatson> -i is only for the .diff.gz
<fabbione> ok
* fabbione tries all of the above
<iwj> mvo: No, I haven't read my mail this morning yet.
<mvo> iwj: ok, its just that I prepared a sru for apt for two unreleated bugs and added this fix as well to my proposal
<iwj> mvo: Makes sense.
<pitti> cjwatson: do you want the langpack SRU process blessed from TB before this update, or is the informal feedback enough?
<pitti> hi slomo__
<slomo__> pitti: i would be fine with dropping it, especially when considering that it's insecure... but at least avahi is using it...
<pitti> slomo__: then we should teach avahi not to
<cjwatson> pitti: no, it's fine. do you have the updates prepared?
<pitti> cjwatson: yes, I have, sources are on rookery
<cjwatson> path?
<pitti> rookery:/srv/language-packs.ubuntu.com/{dapper,edgy}-updates-proposed-20061205/sources-update/*sources.changes
<iwj> mvo, cjwatson: OK, I've just double-checked the code and it very clearly has absolutely no effect in the absence of any Breaks fields so the worst case is that it breaks upgrades to feisty (but that's what it's actually fixing, of course).
<slomo__> pitti: right... but are you really sure nothing else uses it? what about n-m for example? and how would the solution for avahi look like? it's only a dbus method that allows setting the zeroconf hostname and was requested by n-m upstream
<cjwatson> scp: /srv/language-packs.ubuntu.com/dapper-updates-proposed-20061205/sources-update/*sources.changes: No such file or directory
<cjwatson> scp: /srv/language-packs.ubuntu.com/edgy-updates-proposed-20061205/sources-update/*sources.changes: No such file or directory
<cjwatson> pitti: ^--
<fabbione> cjwatson: debcommit --release in this case will commit straight to LP
<cjwatson> fabbione: fine
<pitti> cjwatson: argh, s/sources/source/, my bad
<fabbione> cjwatson: so update changelog .. debcommit --release .. upload
<fabbione> cjwatson: ok all worked fine i guess
<fabbione> cjwatson: thanks for the guidance
<pitti> slomo__: but for avahi, our modified at_console would be actively wrong
<cjwatson> pitti: ah yes
<cjwatson> fabbione: yes
<pitti> slomo__: so perhaps we should modify our dbus patch to just behave like libpam-console, i. e. at_console matches everyone being logged in locally, not just the currently active session
<slomo__> pitti: what does n-m do to prevent unrestricted access to the interfaces?
<pitti> slomo__: for programs where the difference matters (like g-v-m and g-p-m) we can just continue using their patches which check the forground console themselves
<pitti> slomo__: allows access to at_console=true and context=default
<pitti> slomo__: the context=default scares me
<pitti> slomo__: in the long run, the difference (at_console and current_console) just has to be added/fixed upstream
<slomo__> pitti: ok, so n-m has exactly the same problem... hm, i have to leave for ~1 hour or something... let's talk about it again when i'm back, ok? :)
<pitti> slomo__: so ATM our nm-applet doesn't work correctly with or without the dbus at_console patch
<pitti> slomo__: yes, let's
<sivang> hmm, n-m works quite nicely here, no issues so far (I followed some nice howto somewhere)
<pitti> sivang: probably just out of coincidence, that two nm-applet's will do the same thing at the same time
<sivang> pitti: maybe, at least it's working far better then the ifupdown setup I had before
<sivang> pitti: also nicely supports all of my WAP-PSK networks
<sivang> (e.g. auto-detects that a key is required, asks for them, sets up and connects)
<pitti> infinity, Mithrandir: was there a specific reason to rename apache2-common to apache2.2-common? this is a real PITA for correct upgrades (which maintain enabled modules, etc.)
<pitti> infinity, Mithrandir: for example, we want to enable mod_userdir by default for fresh installs, but telling apart a fresh install from an upgrade isn't trivial
<Mithrandir> pitti: yes, apache2-common and apache2.2-common aren't ABI compatible
<Mithrandir> the alternative is the biggest conflicts line the world has seen
<pitti> Mithrandir: enabling mod_userdir is our only Debian delta, btw, and IIRC infinity wanted to fix that in Debian, too
<pitti> Mithrandir: but anyway, Debian's version a2enmod's a lot of stuff by default
<pitti> Mithrandir: does that mean you are fine with deliberately changing the users' configuration on upgrades?
<Mithrandir> pitti: uh, Debian doesn't enable mod_userdir?  That's easily enough fixed.
<pitti> that breaks the Golden Rule
<pitti> Mithrandir: no, just tried (built the Debian package and installed it from scratch)
<Mithrandir> pitti: it upgrades fine in the trivial case; people do too much weird shit with their apache configs in a lot of cases than we can reasonably handle.
<Mithrandir> so in those cases, we just throw our hands up in the air and leaves the admin to fix.
<pitti> Mithrandir: ok
<Mithrandir> like, there's no reasonable way we can do the authn/authz split automatically.
<Mithrandir> I'm sure thom'd love to elaborate further. :-)
<pitti> Mithrandir: I just feel a bit nervous about automatically enabling security relevant stuff like userdir without telling the admin
<pitti> Mithrandir: but I'm happy to merge it for now and discuss this further in a Debian bug
<Mithrandir> pitti: you can check whether /etc/apache2/mods-available/userdir.load exists and if not assume that the userdir module didn't exist before.
<Mithrandir> pitti: actually, #debian-apache on OFTC is a better place to discuss the development.
<Keybuk> pitti: non root processes notifying users => isn't this what dbus is for?
<pitti> Mithrandir: right
<pitti> Keybuk: s/non//
<pitti> Keybuk: right
<pitti> Keybuk: but you need something in the user's session that actually listens to dbus
<Mithrandir> pitti: it's a low-traffic channel and it sometimes takes a bit of time to get responses for people, but it's a useful place for discussions.
<pitti> Keybuk: e. g. it would be possible to talk to notification-daemon (with some su wrapping, etc.)
<pitti> Mithrandir: thanks, will do that
<thom> (the list of modules enabled on 2.0 is more or less meaningless compared to 2.2 in a lot of cases, so the upgrade will almost never work right, as tollef pointed out)
<pitti> Keybuk: but the problem is that at boot time (when avahi might already get disabled), there's no user session yet
<pitti> Keybuk: thus I needed to decouple the process: the dhcp script sets the tag, and the user session picks up the tag
<pitti> Mithrandir: hm, checking for the presence of the file wouldn't work for fresh installs
<pitti> anyway, /me moves to #d-a
<Keybuk> oh, complicated
<Riddell> pitti: did you get to look at exiv2?
<pitti> Riddell: just finished dealing with apache, will donow
<pitti> s/donow/do now/
* Riddell hugs pitti 
<pitti> Riddell: approved, with some bad gut feeling about maintenance overhead due to soname
<Riddell> Keybuk: able to move exiv2 source and libexiv2-dev, libexiv2-0.12, libexiv2-doc sources to main?  just approved by pitti
<Keybuk> Riddell: one moment
<cjwatson> fabbione: partman-auto-lvm's in bzr now, in case you need to touch it again
<Keybuk> Riddell: all binaries
<Keybuk> ?
<fabbione> cjwatson: great thanks. is ddaa handling the imports?
<fabbione> cjwatson: it would be nice to have silo-installer too
<Keybuk> Riddell: oh, sorry, you meant "binaries" :p
<Keybuk> Riddell: there's several packages still depending on the old version of libexiv2
<cjwatson> fabbione: ddaa is generally helpful for imports when I need them, yes
<Keybuk> can you fix those
<cjwatson> fabbione: OK, I'll see if I can get you silo-installer
<cjwatson> may take a while though
<fabbione> cjwatson: no hurry as usual. thanks
<Keybuk> Riddell: done
<pitti> oh dear, now that I finally figured out how to enable this compiz thing in the first place, I have to see that it totally sucks :(
<cjwatson> fabbione: import requested
* pitti files a couple of bugs and switches off that damn thing again
<fabbione> cjwatson: cheers dude
<pitti> brb
<fabbione> seb128, dholbach: ping?
<dholbach> fabbione: pong
<fabbione> dholbach: http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html
<fabbione> dholbach: can you please tell me what did FTBFS in the sparc/gnome world so we can get something to actually install?
<dholbach> I'm sure most of them are due to the buildd problems
<fabbione> they were there even before that
<fabbione> like yesterday morning
<fabbione> even before doko did break gcc
<Mithrandir> fabbione: mono is broken, but you know that, right?
<dholbach> eel would probably resolve nautilus and nautilus-cd-burner
<fabbione> Mithrandir: yes mono i know.. i am talking about all the other gnome stuff
<bhale> Mithrandir: there is a bug upstream
<fabbione> bhale: about sparc?
<bhale> yes
<Mithrandir> fabbione: eel2 too, but it looks transitional so I'll just give it back.
<bhale> http://bugzilla.ximian.com/show_bug.cgi?id=80027
<Ubugtu> Ximian bug 80027 in io-layer "[Linux/SPARC]  Segfault in System.IO.FileSystemInfo.Refresh" [Unknown,Reopened]  
<bhale> fabbione ^
<dholbach> not sure what gnome-{applets,panel,mount,volume-manager} are waiting for
<fabbione> bhale: unlikely to get fixed if either david miller or I will fix the code
<dholbach> fabbione: a bit hard to figure out with no sparc machine to test it on
<dholbach> most of the stuff that is not installable and causes build failures built fine itself
<dholbach> http://librarian.launchpad.net/5167973/buildlog_ubuntu-feisty-sparc.gnome-applets_2.16.2-0ubuntu1_FAILEDTOBUILD.txt.gz shows such a build failure
<dholbach> https://launchpad.net/distros/ubuntu/+source/gnome-python/2.16.2-0ubuntu1 failed on all archs
* dholbach tries a rebuild
<Mithrandir> dholbach: ImportError: No module named gnomevfs
<Mithrandir> in the tests.
<Mithrandir> I suspect that might be culprit
<dholbach> yeah, saw that - investigating
<fabbione> Mithrandir: can you perform a massive give-back for sparc?
<fabbione> or just those gnome-crap packages? :P
<Mithrandir> fabbione: I can do single give-backs, I don't have any nice tools to do mass give-backs, so please give me a list of packages.
* dholbach slaps fabbione
<fabbione> dholbach: can you give that list to Mithrandir once you have done the investigation? i suspect the usual unversioned B-D thingy
<dholbach> unversioned b-d?
<dholbach> fabbione: there are only a few that failed to build and it's a bit hard for me to figure out without having any means of trying to test install those packages
<fabbione> dholbach: you can use faure chroots to figure that out
<fabbione> dholbach: you or seb often upload pkg foo that needs bar-dev in version X or higher but you don't express this B-D properly and just rely on the fact that buildd will be fast enough to make bar-dev available before you upload foo
<fabbione> dholbach: that's often cause of these kind of FTBFS
<dholbach> no, I don't
<dholbach> i always check the diff of configure.{in,ac} before
<fabbione> well it did happen in the past so it might still happen now and you just don't notice...
<fabbione> anyway.. it's enough Mithrandir get a list of things to retry
<dholbach> uh huh... I'll see if I can resolve that ftbfs i found
<Keybuk> dholbach: I've still not managed to get gossip-telepathy to login to google talk; is there some trick to this?
<Keybuk> I get odd errors like "Connection Refused" or "Non-specific protocol error"
<dholbach> Keybuk: I'm afraid, I don't know - I didn't try it and there's a bug open about it - I'll try to find out
<Zdra> dholbach: there is a bug about that ?
<Zdra> Keybuk: did enabled ssl support and set port 5223 ?
<dholbach> sorry, that was cohoba - bug 70215
<Ubugtu> Malone bug 70215 in cohoba "Audio of Google Talk does not work" [Medium,Needs info]  http://launchpad.net/bugs/70215
<Keybuk> Zdra: that seemed to be the trick, yes
<twb> Mithrandir: ping?
<Mithrandir> hi Trent
<twb> Mithrandir: so I've been getting the hang of bzr doing merges of casper and casper/debian.
<Mithrandir> twb: yay
<Mithrandir> does that mean you have shiny branches for me to merge?
<twb> One thing the debian branch does is move debian/changelog to debian/changelog.upstream, and then use that file iff the host is Ubuntu.
<twb> i.e. one you merge my branch, you'd need to edit changelog.upstream instead of changelog.
<twb> Is this a problem, ideologically?
<seb128> fabbione: I would start by doing a retry on every of those
<Mithrandir> twb: they seem to install it unconditionally.  I'd probably merge it, move the file back and rm the debian one.
<dholbach> seb128: he left
<twb> Well that's what I was doing, but the debian/rules file appears to (AFAICT) install the appropriate file depending on what host you build the .deb under.
<twb> Same for the control file.
<cjwatson> pitti: sorry, I screwed up slightly while processing the language packs and caused a few mails to -changes; I think only three or four or so
<pitti> cjwatson: that won't hurt; thanks a lot for processing!
<Mithrandir> twb: it seems to install the .upstream file unconditionally?
<cjwatson> I managed to ctrl-c before it got too far
<twb> Mithrandir: no.
<Keybuk> Ctrl-C worked?
<Keybuk> Normally I Ctrl-\ Soyuz :p
<twb> Mithrandir: 
<twb> ifeq ($(BUILD_SYSTEM),Debian)
<twb> 	dh_installchangelogs -a debian/changelog.upstream
<twb> else
<twb> 	dh_installchangelogs -a
<twb> endif
<cjwatson> twb: the packaging toolchain relies on the version you're building being at the head of debian/changelog, so that won't work for us at all
<seb128> dholbach: what do you mean? he's still on the chan, he'll probably read whenever he's in front of IRC again
<twb> cjwatson: it works for me.
<cjwatson> i.e. if you have to edit debian/changelog you'll get a source package with the wrong version number.
<cjwatson> twb: have you tried dpkg-buildpackage?
<twb> If I build it, I get version 1.79
<twb> Yes.
<dholbach> seb128: right, I meant to say that he's *currently* not there
<cjwatson> what's at the head of debian/changelog and debian/changelog.upstream respectively?
<twb> ==> changelog <==
<twb> casper (1.68+debian-3) unstable; urgency=low
<twb> 
<twb> ==> changelog.upstream <==
<twb> casper (1.79) UNRELEASED; urgency=low
<Mithrandir> twb: I can't say I'm happy about renaming debian/changelog at all, but reverting that is easy enough to do.
<Keybuk> you'll get 1.79 binaries, but a 1.68+debian-3 source
<Keybuk> and probably a totally bogus changes file
<cjwatson> what Keybuk said
<twb> Keybuk: nope.
<cjwatson> debian/changelog is hardcoded for source uploads
<Keybuk> twb: yes.
<seb128> dholbach: well, I pong with context, I don't need a reply now
<twb> Well, dpkg-buildpackage gives me a 1.79 tar.gz
<cjwatson> where is your branch?
<Keybuk> twb: only if you've built it previously
<Keybuk> twb: unpack the source fresh, and then run dpkg-buildpackage in it
<Keybuk> twb: you'll get a 1.68+debian.tar.gz
<dholbach> seb128: right...
<twb> Keybuk: ok
<Keybuk> debian/changelog is completely hardcoded
<twb> Keybuk: again, I only get 1.79 files.
<Mithrandir> Keybuk: (it's not, dpkg-genchanges can be passed -l)
<cjwatson> Keybuk: ctrl-c ctrl-\ I think - I do it automatically nowadays so don't notice
<cjwatson> Mithrandir: but isn't by our buildds
<twb> cjwatson: http://twb.ath.cx/~twb/scratch/casper
<twb> cjwatson: but it has unresolved conflicts
<Keybuk> twb: can you upload this package somewhere for me to try?
<twb> Keybuk: one moment.
<Keybuk> oh, is that URL it?
<twb> That's the bzr branch
<twb> All I did was `bzr branch .../casper && cd casper && dpkg-buildpackage -rfakeroot'
* Keybuk waits for bzr
<twb> Note: that branch isn't properly cleaned up (yet), so actually installing it is a bad idea.
<twb> Use dpkg -x to look inside it.
<twb> That is, inside the .deb
<cjwatson> dpkg -c
<twb> That, too.
<Keybuk> twb: the top revision in your debian/changelog is 1.79
<cjwatson> that branch has no debian/changelog.upstream
<Keybuk> and there's no changelog.upstream
<twb> Perhaps bzr is behaving differently for you because you're doing a branch over http.
<twb> Let me commit the merge, then try again.
<Keybuk> you have to commit, yes :)
<cjwatson> branch over http = branch over sftp
<cjwatson> or locally or whatever
<Keybuk> make sure you 'bzr add' any new files, etc.
<LarstiQ> but uncommited changes can't be reached remotely :)
<Keybuk> or locally :p
<twb> LarstiQ: but they can if I branch locally over the filesystem? >confused<
<Keybuk> twb: no, if you branch locally they can't be reached either
<cjwatson> the files are available by http on twb's website, but no invocation of bzr, local or remote, will fetch them
<Keybuk> bzr branch will only branch the committed changes
<LarstiQ> Keybuk: there you have more leeway, like merge --uncommitte
<Keybuk> of course, if you use "cp -a" to "branch locally", it'll copy the uncommitted changes
<LarstiQ> right.
<twb> http://twb.ath.cx/~twb/scratch/casper-merged/
<cjwatson> pitti: langpacks done
<pitti> \o/ cheers
<LarstiQ> twb: sorry to confuse you, a `bzr branch` will not copy them.
<twb> Hmm.
<twb> I must have been looking at the wrong working tree when I was checking debian/changelog etc.
<Keybuk> quest casper% dpkg-parsechangelog | grep Version
<Keybuk> Version: 1.68+debian-3
<Keybuk> quest casper% dpkg-parsechangelog -ldebian/changelog.upstream | grep Version
<Keybuk> Version: 1.79
<Keybuk> quest casper% dpkg-buildpackage  
<Keybuk> dpkg-buildpackage: source package is casper
<Keybuk> dpkg-buildpackage: source version is 1.68+debian-3
<Keybuk> dpkg-buildpackage: source changed by Marco Amadori <marco.amadori@gmail.com>
<Keybuk> dpkg-buildpackage: host architecture amd64
<Keybuk> dpkg-buildpackage: source version without epoch 1.68+debian-3
<Keybuk> generates 1.68+debian-3 sources
<Keybuk> and 1.68_debian-3 debs
<twb> You're right.
<cjwatson> the more usual approach is to just change the files and let bzr remember what the other side has, rather than carrying around silly .debian and .ubuntu files
<cjwatson> I believe Tollef has had debates with the Debian casper people about their packaging already ...
<twb> So I should bzr rm the .debian file and bzr mv the .ubuntu one back to just debian/changelog?
<Mithrandir> cjwatson: their first diversion is a commit with a diffstat of:  31 files changed, 957 insertions(+), 253 deletions(-)
<cjwatson> yeah, same with debian/control if you haven't already
<Mithrandir> somehow, I've put off merging that for a while. :-P
<twb> OK.
<cjwatson> (I see there's some weirdness there already, but debian/control is another hardcoded file and messing with it in the build process is a bad idea unless you REALLY know what you're doing)
<twb> What will bzr do when the next merge from casper/debian tries to edit the (now deleted) file?
<Keybuk> cjwatson: debian/control.in should be punishable by death
<cjwatson> twb: I believe nothing (edit ignored) but at worst you get to resolve a conflict
<twb> All the more reason to make debian/ a Scheme program instead of flat files! ^_^
<twb> cjwatson: good-o.
<twb> What about the stuff outside of debian/ that checks for Debian or Ubuntu at boot time?
<twb> Should I leave it in, or revert it?
<Mithrandir> twb: I'm fine with keeping that.
<twb> Righto.
<twb> Is there a convention for casper for recording GNU Coding Standards-style commit messages?
<twb> (From bzr log, it appears not.)
<Mithrandir> twb: no.  Just use what you put in debian/changelog.
<tkamppeter> doko, ping
<doko> tkamppeter: pong
<twb> Hmm.  So for every commit I should put a note in debian/changelog?
<tkamppeter> doko, can you have a look at bug 67892?
<Ubugtu> Malone bug 67892 in hplip "HPLIP failed to start PyQt/Qt missing" [Medium,Confirmed]  http://launchpad.net/bugs/67892
<tkamppeter> I have made a suggestion there about how to package HPLIP to fix the problem of Python/Qt not being there by default. WDYT?
<Mithrandir> twb: make sure that every commit is documented in debian/changelog, yes.  Unless it's just fixing up an earlier commit in the same upload and the previous changelog entry covers it.
<twb> OK.
<doko> tkamppeter: the extra desktop file seems to be a merge error
<twb> When I'm merging in casper/debian changes, it is sensible to put integrate their changelog entries into debian/changelog, or should I just add a single-line note `merged casper/debian rNNN' to the latest entry?
<tkamppeter> doko, is somewhre an automatic mechanism which removes the "NoDisplay=true" lines in the .desktop files if Python/Qt is there?
<Mithrandir> twb: in that case, I'd merge both the changelog entry and note it in the latest one too.
<twb> OK.
<doko> tkamppeter: what do you mean?
<tkamppeter> doko, if we take the hplip.desktop away, as it is there in error, there remain 3 .desktop files (for hp-toolbox, hp-sendfax, and hp-fab) which all contain a line "NoDisplay=true". This means the entries do not get visible in the menus.
<doko> tkamppeter: yes, that's intended
<tkamppeter> Now if the user has Python/Qt on his system (either a Kubuntu or package installed manually) the menu entries still tay invisible.
<tkamppeter> This would mean that the user has to open the menu editor to make them visible.
<geser> doko: I overlooked your sync request for wireshark and did a merge. should i close the sync request?
<pitti> geser: depends on whether the remaining ubuntu delta is actually relevant
<Mithrandir> pitti: if it's merged, it can't be synced until a new version is uploaded into debian
<doko> geser: well, that sync request is obsolete, independent of the the merge was necessary or not.
<simontol> hi
<pitti> Mithrandir: right, but we should keep track that it can be synced on the next possibility
<simontol> anyone here who tried Feisty-Herd1 CD?
<tkamppeter> I am asking now whether there is an automatic mechanism somewhere which removes the "NoDisplay=true" lines when Python/Qt is/gets installed.
<doko> tkamppeter: no
<Mithrandir> simontol: yes, people test it before it's released.
<simontol> I can't install... It freezes just after selecting keyboard type
<simontol> Is there a way to install w/out GTK installer?
<Mithrandir> simontol: use the alternate CD?
<tkamppeter> So no I am suggesting in that bug report instead of using "NoDisplay=true" lines moving the .desktop files into a separate package named "hplip-gui" which requires Python/Qt.  If the user installs "hplip-gui" Python/Qt gets automatically installed.
<Mithrandir> seb128: libslab0 should go to main, I presume?
<simontol> Does alternate CD have PPP support ? 
<seb128> Mithrandir: yep, gnome-control-center Depends on it
<Mithrandir> seb128: cheers, thanks.
<seb128> Mithrandir: thank *you* for looking at it ;)
<Mithrandir> seb128: oh, no trouble.  Figured I'd do a bit of NEW.
<simontol> Mithrandir : I can install edgy and then upgrade too , do you agree?
<Mithrandir> simontol: yes, that would work too.
<Mithrandir> simontol: but you really don't want to run feisty unless you are interested in the development of Ubuntu, it's not ready for end-user usage.
<simontol> Yes I'll keep Edgy on separate parttiton
<simontol> *partition
<tkamppeter> pitti, have you already uploaded splix (bug 59829 and bug 44407)?
<Ubugtu> Malone bug 59829 in Ubuntu "No driver for Samsung ML-1610 printer" [Wishlist,Needs info]  http://launchpad.net/bugs/59829
<Ubugtu> Malone bug 44407 in foomatic-db "Samsung clp510 not working" [Medium,Needs info]  http://launchpad.net/bugs/44407
<cjwatson> simontol: this is a known problem with some graphics cards (we think); it's still under investigation
<simontol> I thought It was GPU rpoblem...
<Mithrandir> simontol: does it work for you if you go to the console with ctrl-alt-f1 and then back with alt-f7?
<Mithrandir> cjwatson: speaking of this; I see the same on simira's laptop, so if there's anything I can do to help debug it usefully..
<simontol> I tried to restart X several times but I freezes every time just after keyboard type selcting (step 4 of7)
<Mithrandir> simontol: don't restart X, just change to another virtual console and then back.
<simontol> I'll try this.
<simontol> So You're saying there is no other method then gtk-installer to setup with desktop-cd
<Mithrandir> yes
<simontol> I'll reboot now  and try your  solution, see you later ... Thanks
<bhale> -
<bhale> < simontol> So You're saying there is no other method then gtk-installer to setup with desktop-cd
<bhale> ugh, sorry
<bhale> (morn all)
<Mithrandir> morning, tseng
<Mithrandir> Adri2000: please tell the homebank upstream author to update the FSF address in the source (including all the GPL header blurbs)
<cjwatson> Mithrandir: bug 73955 has a reduced test case; maybe you could dig down through that?
<Ubugtu> Malone bug 73955 in console-setup "Clobbered X screen state during installation" [High,Confirmed]  http://launchpad.net/bugs/73955
<elkbuntu> Mithrandir, cjwatson, i dont have complete x freeze/warp/whatever, cjwatson's seen my pics of it.. but what you suggested works here fwiw
<Mithrandir> cjwatson: I see it again and again for the later pages as well, iirc.
<Mithrandir> cjwatson: I'll ask her to test when she's back.
<twb> Well, the merging the first casper/debian-only revision doesn't work, because casper-snapshot doesn't exist.
<twb> How can I look to see when that file was added, in the debian branch?
<twb> It exists in the tip.
<Mithrandir> dholbach: please tell gnome-specimen upstream to update the FSF address in the package.
<Mithrandir> twb: unsure, try doing a binary search for it.
<twb> This seems to work:
<twb> bzr annotate casper-snapshot | grep -o '^ *[0-9] \+' | sort -n | uniq | head -1
<cjwatson> Mithrandir: that's even weirder
<truz_`24> So, if someone says "my ubuntu box keeps locking up, when i restart it, it takes a while to come back up" what do you look at first?
<truz_`24> Logs don't seem to suggest any problems :-(
<twb> truz_`24: binary drivers
<simontol_>  Mithrandir : I'm back your ctrl-alt-F1 + alt-F7 suggestion worked
<simontol_>  Thanks
<Mithrandir> simontol_: cool, thanks.
<simontol_> I have another question ... Don't know if this is the right place...
<simontol_> I have to patch usbserial module in kernel 
<simontol_> Do I have to compile all from sources to do this?
<dholbach> Mithrandir: will do - did you reject it because of that?
<Mithrandir> dholbach: no, I rejected decibel because of no licence in the orig.tar.gz, gnome-specimen was accepted.
<dholbach> Mithrandir: will chase upstream up - thanks a lot
<Mithrandir> dholbach: I don't reject packages based on having the old FSF address in the GPL blurb.  I don't have _that_ much free time. :-)
<dholbach> I'm glad to hear that. ;-)
<Mithrandir> dholbach: tapioca-qt should have its FSF address updated too
<dholbach> alrighty - will try to check the next packages before they hit NEW :)
<Mithrandir> don't let it hold you up; but if you'd chase upstream up about it -- excellent
<dholbach> yeah no prob
<ogra> pitti, when did you approve gobby ? its listed under approved on the main inclusion queue
<pitti> ogra: oh, long time ago, when you kept asking me about it :)
<ogra> hmm
<ogra> i was under the impression you never approved it ... weird ...
<ogra> so time to add it to the seeds, thanks :)
<bddebian> Heya
<ogra> slomo_, so your fix to bug 65690 makes sure the gstreamer db is regenerated on every login so that the right sink is selected if i switch from being logged in on the server (alsa/dmix) to a ltsp client (esd) ?
<Ubugtu> Malone bug 65690 in ltsp "should select the esdsink for LTSP_CLIENTs" [High,Fix released]  http://launchpad.net/bugs/65690
<ogra> (pulse isnt used in edubuntu yet, and surely wont be used for local users, only for ltsp)
<ogra> pitti, ^^^^ ?
<ogra> (just saw your mail)
<pitti> ogra: right, but if you use it for LTSP by default, then the bug is settled, right?
<ogra> the explanation slomo_ gave in the bug doesnt look like it ...
<ogra> thats why i asked
<ogra> "Order is (if installed) pulse > alsadmix > esd > alsa > oss..."
<pitti> ogra: we just ditched the patch since it was broken anyway
<ogra> i dont care about the order ...
<pitti> ogra: if you want to continue using esound for ltsp, then we need to write a new patch
<ogra> i care about dynamically swit5ching the sink based on where i'm logged in
<pitti> ogra: but if you use pulse, then it should just work now
<BenC> Can someone push linux-source-2.6.20 through NEW processing please?
<ogra> pulse is the plan... but not there yet ...
<twb> Mithrandir: what's the policy on bashisms in #/bin/sh scripts in casper?
<Mithrandir> twb: /bin/sh => no bashisms allowed.
<twb> quite a few export PATH=blah's.
<pitti> ogra: ok, if you need that dynamic switch, we need to add an ltspesdsink
<Mithrandir> twb: that's POSIX, or at least supported by dash
<twb> Hmm, OK.
<Mithrandir> The shell allows the value of a variable
<Mithrandir>             to be set at the same time it is exported by writing
<Mithrandir>                   export name=value
<ogra> pitti, well, i'm fine with it as long as it switches dynamically ... i dont think we'll need any esd crap, but i cant test the patch before pulse is integrated
<Mithrandir> BenC: main, I presume?
<BenC> Mithrandir: yes please :)
<twb> Mithrandir: one of the debian changes makes it only honor the last access=X boot parameter.
<pitti> ogra: it won't; if you have pulse installed, it'll always use the pulse sink
<ogra> hmm
<twb> Mithrandir: it is likely that someone would want something like access=m1 access=v1?
<ogra> pitti, even if i dont use pulse ? 
<ogra> i.e. if its not running
<pitti> ogra: if pulsedaemon is not running, it'll fall back to alsa
<ogra> great
<ogra> thats what i need :)
<Mithrandir> twb: unsure; Henrik would know.  I don't see a reason to make it unsupported.
<pitti> ogra: i. e. the autoaudiosink just detects availability and uses what works: first pulse, then alsadmix, then esd, then alsa
<ogra> good
<pitti> ogra: but it will *not* change the order of the sinks that it tries dynamically
<ogra> i'll drop my workaround from ltsp then :)
<Mithrandir> BenC: done
<pitti> (that's what we did in dapper)
<twb> Mithrandir: the only reason is that bzr can get quite confused if you try to back out changes from one branch, but not both.
<BenC> Mithrandir: thanks!
<pitti> ogra: great
<ogra> even its sad to lose that file ;)
<twb> Mithrandir: oh wait
<twb> Nope, nm
<ogra> its handy to have something to influence the session
<pitti> ogra: oh, is it?
<Mithrandir> twb: you can merge a change, then revert the actual change to the files and it won't try to merge it later.
<Mithrandir> but, I need to pick up some dinner, so I'm afk for a while now.
<twb> Well, clearly I'm doing it wrong.
* twb grumbles
<ogra> pitti, well, to abuse it for other stuff than sound ;)
<pitti> ogra: hehe; well, then just keep an empty skeleton file around
<ogra> yeah, that was my idea :)
<simira> cjwatson: I reproduced the bug (the one with screen going black after choosing keyboard layout)
<pitti> is any Ubuntu Weekly News editor here? It seems that https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Ideas is obsolete; where to send suggestions to?
<seaLne> BenC: http://behindubuntu.org/interviews/BenCollins/
<BenC> seeLne: sweet, I'll be famous :)
* kylem fanboys Ben
<seaLne> heh
<twb> Mithrandir: ok, I made a dodgy-ass merge that at least builds correctly.
<twb> I'm gonna try sticking it in a live cd now, but first I need to update transmuter to install new initramfses correctly under Ubuntu.
<dholbach> BenC: haha... your hot teacher in 4th grade... hahaha :-)
<cjwatson> simira: right, somebody needs to dig into it and figure out exactly what's failing
<cjwatson> insanely hard to do remotely ...
<simira> cjwatson: well, I kinda know this colleague of yours...
<cjwatson> uh-huh :)
<cjwatson> just emphasising that it's hard to help from this end beyond providing a starting point
<simira> cjwatson: well, I really have no clue what this bug is about. But Tollef might have an idea.
<\sh> benc: nice interview :)
<BenC> \sh: thanks
<lamont> mdz: you around yet?
<lamont> mdz: fixed postfix uploaded to debian, will hit the archive in today's dinstall - so whenever that syncs, the update-inetd thing will be happy
<psusi> anyone feel like sponsoring a backport upload?  the dmraid package that shipped with edgy was fubar... the one now in feisty is good... a number of users have had their systems broken by this and would like the fixed version uploaded to -backports, or to the main universe repo if possible
<psusi> seeing as how the released one was fubar
<fabbione> cjwatson, Mithrandir: can i beg you to promote network-console to main so that tomorrow morning when my son will wake me up at 4am i will have something to work/test ?
<fabbione> and with this last pray i am off for the evening
<pitti> bye fabbione 
<kylem> night fabio
<cjwatson> fabbione: done
<jdong> out of curiousity, how helpful has -fstack-protector been in  protecting Edgy?
<jdong> I see a few buffer overflow USN's for edgy already... would those have been exploitable with stack protector (apart from just killing the app in question)
<Keybuk> pitti: be interesting to see how many people trip over the fact that you can't create ad-hoc networks if  you have an atheros card :)
<pitti> Keybuk: oh, the driver doesn't support ad-doc mode?
<Keybuk> pitti: the driver is stupid
<Keybuk> you create virtual interfaces, and each virtual interface has a mode set
<Keybuk> ath0 is one such virtual interface
<Keybuk> and the default one is always in the managed mode
<Keybuk> to make an adhoc one, you have to use wlanconfig on wifi0 to remove the ath0 virtual and make a new one in ad-hoc mode
<_ion> Wow. :-)
<_ion> That's really great engineering.
<Keybuk> it has some advantages
<Keybuk> e.g.
<Keybuk> wlanconfig ath0 create wlandev wifi0 wlanmode ap
<Keybuk> wlanconfig ath1 create wlandev wifi0 wlanmode ap
<Keybuk> ifconfig ath0 10.x.x.x
<Keybuk> ifconfig eth1 192.168.x.x
<Keybuk> echo 1 > /proc/sys/net/ipv4/ip_forward
<Keybuk> etc.
<Keybuk> uh, s/eth1/ath1/ in that example :p
<_ion> I don't have a problem with that, but not being able to *change* the wlanmode is quite stupid. :-)
<Keybuk> yes
<Keybuk> they should support the ioctl to change the mode of an existing virtual interface
<mdz> lamont: ok, if it's unmodified in ubuntu then that's just ducky
<LaserJock> mdz: you got a minute? I need your opinion about a possible SRU
<mdz> LaserJock: cjwatson is the primary point of contact for SRUs, but I can have a quick look
<LaserJock> mdz: well, it's bug #75021 and #74906
<Ubug2> Malone bug 75021 in python-imaging "critical missing dependencies (edgy)" [Unknown,Fix released]  http://launchpad.net/bugs/75021
<Ubug2> Malone bug 74906 in psycopg "python-psycopg: Missing dependencies? (libc6, libpq4)" [Unknown,Fix released]  http://launchpad.net/bugs/74906
<LaserJock> mdz: basically ${shlibs:Depends} got dropped on a couple python transitions
<LaserJock> mdz: my concern is that the dropped deps are picked up by many Desktop packages
<LaserJock> mdz: so it's really only a problem for server people
<mdz> LaserJock: looks definitely worth fixing
<cypher1> Keybuk, hi
<Keybuk> cypher1: hi
<LaserJock> mdz: ok, I just wanted to ask because of the somewhat limited scope
<mdz> low risk, completely breaks the package for a substantial number of folks
<cypher1> Keybuk, sorry for disturbing still with bug 66637
<Ubug2> Malone bug 66637 in util-linux "After running mkswap, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]  http://launchpad.net/bugs/66637
<LaserJock> mdz: ok great, just didn't want to seems stupid when I showed up with a debdiff
<Keybuk> cypher1: yes?
<mdz> LaserJock: np
<cypher1> cypher1, but to end up with the same problem even i had not run mkswap.. i had just upgraded from dapper -> edgy
<Keybuk> cypher1: then you have a different bug
<Keybuk> you should file  a new one
<Keybuk> to avoid confusion
<cypher1> Keybuk, no suddenly in between i saw the "invalid signature" for swap sprang up from somewhere 
<Keybuk> cypher1: that bug is purely that mkswap generates a new UUID when run over an existing swap partition
<Keybuk> if you have a different problem ("I upgraded and lost my swap space") then you have a different bug
<cypher1> Keybuk, ok thanks
<Keybuk> and when that bug is marked "Fix Released", you won't have had your problem solved
<Keybuk> although the symptoms may sound a little similar, the problem will be totally different
<Keybuk> we prefer to have one bug per problem, rather than one bug per symptom
<cypher1> Keybuk, is mkswap run during upgradation ?
<Keybuk> otherwise we go mad, and start gibbering :p
<Keybuk> cypher1: it's not supposed to be
<cypher1> Keybuk, :)
<cypher1> Keybuk, if a swap exists and we use it, right ?
<Seveas> Keybuk, the upstart announcement was sent to the @netsplit.com list, shouldn't that be the @lists.ubuntu.com list?
<Keybuk> Seveas: oops
<Keybuk> :)
* Keybuk updates his address book
<Seveas> Keybuk, btw: upstart makes one of my projects sooooooooooooo much cleaner - for that alone I almost got a raise ;)
<Keybuk> "almost" ? :-(
<Seveas> hey, I work there only since late october, give them a break ;) I already got a big christmas bonus ;)
<fabbione> cjwatson: thanks a lot
<jdong> how does ubuntu automagically reconfigure xorg.conf when I boot it up on different hardware?
<jdong> where is it detected that the configuration changed and dpkg-reconfigure xserver-xorg run?
* LaserJock starts singing "Oh, oh ... it's magic"
<jdong> speaking of magic
<jdong> the bad kind....
<jdong> http://ubuntuforums.org/showpost.php?p=1881753&postcount=107
<jdong> please tell me that's PEBKAC
<Burgwork> jdong: likely using a 3rd party nvidia driver
<jdong> Burgwork: I hope so...
<jdong> though the ABI for the recent kernel update wasn't bumped
<jdong> it's still 2.6.17-10
<jdong> so that means that all current modules should still work for the new kernel update, right?
<keescook> jdong: they were pretty careful about making sure the ABI didn't change.
<jdong> ok
<jdong> then my next theory is an nvidia-glx mismatch
<jdong> the 3rd party 9xxx repos must've been too conservative in their version numbering
<jdong> and 87xx nvidia-glx userland must've overridden their 9xxx's
<keescook> I hope so... *cringe*
<Burgwork> yay! 3rd party repos
<Burgwork> on the matter of support, I just learnt that my largest customer has been calling support every day
<Burgwork> for three months...
<jdong> Burgwork: trying to tell people to wait 6 months for beryl AIGLX is a lost cause... ? ;-)
<jdong> keescook: I think so. Most people are using 9xxx nvidia's for beryl-mania
<jdong> one person reports nvidia breakage with self-compiled nvidia binary drivers, with nvidia-glx uninstalled and lrm nvidia blacklisted
<jdong> that worries me
<delire> i'm writing an application for Ubuntu in Python that requires the user provide a password for sudo via a widget console. 
<Treenaks> delire: why not use gksudo?
<delire> i'm successfully using the pexpect module on a Debian unstable system to send a password to sudo, but on Ubuntu this fails due to sudo wanting the password itself to be sent by a root user. are there any strategies that might suit better?
<jdong> delire: you should call gksu
<delire> Treenaks: how is gksudo different from sudo?
<jdong> delire: to pop up a GTK dialog for sudo...
<delire> <-- long time Debian user /me greps
<jdong> delire: gksudo/gksu interface with pam and sudo directly
<delire> jdong: no, this is a fullscreen application. this isn't possible.
<jdong> delire: or you can look at their source and do something similar tot hem
<delire> hmm.. perhaps.
<jdong> delire: but you shouldn't be prompting for a password and pexpecting it
<jdong> that's just not safe
<delire> i'm really hoping for a Python interface.
<delire> jdong: it seems to be safe, having read documentation on it and looking at memory.
<Treenaks> there's a libgksu 
<Treenaks> maybe it has bindings in pythno
<delire> Treenaks: interesting.. cheers
<delire> Treenaks: hmm it seems to have no Python bindings. i may write some if i get time later.
<LarstiQ> delire \o/
<delire> LarstiQ: hey ;)
<delire> on a related note, one thing i notice quitting my application while it's in fullscreen mode on Dapper (at least) is that i'm dumped back into X in a 'zoomed' mode. is this likely a fault of Xorg on Dapper or my application?
<twb> Mithrandir: I just tried to install my whizz-bang merged casper, and I get 
<twb> [: 43: ==: unexpected operator
<twb> when running `update-initramfs -u'.  However, I can't find any source file with an inadequately quoted test(1) clause.  Any idea where this might be coming from?
<delire> (it's an SDL application btw)
<twb> delire: try Ctrl+Alt+KP_Minus
<delire> twb: cheers, that's all very well but i'd rather users don't have to do this.
<Treenaks> how do you set fullscreen mode?
<Treenaks> just map a window right? no cracky vidmode extensions etc.
<twb> I think the correct way to avoid it is to not segfault the SDL application.
<delire> Treenaks: nope, just a mapped window.
<delire> twb: it's not segfaulting, it's quitting gracefully according to the stack trace.
<twb> Can't help.
<twb> Try #sdl or whatever.
<delire> twb: right, so it is a likely problem of my application.
<twb> It's almost certainly NOT an ubuntu-specific problem, and therefore not on-topic for #ubuntu-devel.
<delire> twb: ok, good to have established that. i only ask as i don't have the problem on my Debian box running Xorg7.
<twb> I see.
<twb> Still, #ubuntu is more appropriate than #ubuntu-devel.
<delire> twb: well, i'm developing an application i hope to maintain for Ubuntu, but sure.
<twb> (Note: this are just my opinions.  Others may disagree.)
<Mithrandir> twb: == is a bashism, use =
<twb> Er, [ is a binary.
<twb> It has nothing to do with bash.
<Keybuk> the [ binary only accepts =
<Keybuk> it's the bash builtin that accepts ==
<twb> You're right.
<twb> Stupid bash.
<Keybuk> scott@syndicate:~$ type [
<Keybuk> [ is a shell builtin
<twb> Aha, yes.
<twb> The next question is, did they mean string= or number= ?
<Keybuk> = is string equal
<Keybuk> -eq is integer equal
<twb> Right.
<Mithrandir> twb: they meant =
<twb> But I'm discovering Marco's typos, not making them myself.
<twb> Mithrandir: righto.
<Mithrandir> if [ "${BUILD_SYSTEM}" == "Ubuntu" ] ; then
<twb> If it was up to me, we'd all write sh in this style:
<twb> if test "$x" = "$x"
<twb> then foo
<twb> fi
<Keybuk> heh, I remember when people used to claim test was more portable than [
<twb> All those nasty semicolons everywhere... yecch.
<Keybuk> because they'd been used to only using test in autoconf macros
<Keybuk> (when, in fact, that was because [ ... ]  is a quote character in m4 :p)
<twb> I use test over [ because [ looks ugly, and newbies forget the mandatory spaces.
<psusi> what's a shell script way to take a STRING="foo bar" and split it into two strings, one with "foo" and one with "bar"?
<twb> psusi: ${STRING% *}
<jdong> ok, guys, nvidia problem for you...
<twb> psusi: ${STRING##* }
<twb> psusi: see also #bash.
<psusi> hrm....
<jdong> if you have a non-lrm nvidia kernel, after installing today's update you will get the following error:
<jdong> FATAL: Could not open 'lib/modules/2.6.17-10-generic/nvidia/volatile/nvidia.ko': No such file or directory
<jdong> a subsequent depmod -ae fixes this
<_ion> Why have a non-lrm nvidia kernel module?
<jdong> _ion: i.e. 9xxx-series beryl crack etc
<_ion> jdong: Why not build your own l-r-m package with an updated nvidia driver?
<jdong> _ion: that appears to have been broken by today's kernel update too
<jdong> though I'm only 90% sure of that
<jdong> still trying to get in touch with users
<jdong> reproducing this
<jdong> so far I fixed a few users' problems just by depmod -ae
<jdong> still trying to get to the bottom of this
<tkamppeter> pitti, ping
<twb> Mithrandir: the debian merge changed the default username and hostname to `casper' and `live' respectively.  Should these be changed back to `ubuntu'?
<twb> I notice the isolinux.cfg for Edgy includes a ramdisk_size kernel argument.   What does this do, and what are the consequences of changing the ramdisk without updating or removing this argument?
<alex-weej> is beryl for feisty a dead cert?
<alex-weej> or is there still time to persuade the naysayers that METACITY IS THE OBVIOUS CHOICE GRR :P
<jdong> it's over
<alex-weej> damn
<jdong> until metacity spins cubes, makes windows pop out, or simulates hurricane Katrina
<jdong> it's a lost cost
<jdong> cause *
<alex-weej> naeh
<alex-weej> that's ridiculous
<alex-weej> i'm actually pretty upset that we're throwing out gnome software yet again
<twb> alex-weej: who cares, nobody uses the default WM
<alex-weej> it's like the firefox vs. epiphany thing all over again
* alex-weej is rapidly losing faith in Ubuntu policy
<twb> People who don't care enough to choose a better WM will buy an Apple Mac instead of running Ubuntu.
<jdong> of course firefox
<jdong> sheesh
<jdong> unless you don't like having your print dialog options
* jdong ducks :D
<seb128> alex-weej: I would prefer compiz
<seb128> and it's not decided on beryl, no
<twb> It's not like GNOME actually makes usable software.
<alex-weej> ...
<seb128> twb: not the right chan to troll
<twb> Yeah, sorry.
<seb128> twb: could you use an another chan for that?
<seb128> np
<twb> GNOME makes me angry.
<alex-weej> ok ok 
<twb> Like a lot of other stuff.
<alex-weej> go to #ubuntu and talk about that
<seb128> well, not the right place to speak about your frustation though
<twb> yeah.
<alex-weej> seb128: has metacity been totally disqualified from the race?
<seb128> alex-weej: it'll be available and used for "slow" machines
<seb128> alex-weej: and switching to it will be like one click
<twb> seb128: you mean the installer will automagically pick one of the two?
<alex-weej> does it not make sense to put the effort into making metacity optionally do the fancy stuff than maintaining two WMs?
<seb128> twb: no, compiz or beryl should rather fallback to run metacity if they decide they can't work correctly
<twb> Ah, at runtime.
<twb> Good, good.
<alex-weej> means too much inconsistency
<alex-weej> they are merely two apps pretending that they are each other plus or minus features
<seb128> alex-weej: according to redhat and novell guys who looked at it it's easier to write a composite manager from scratch and make it manage windows than to make metacity being a composite manager
<alex-weej> interesting
<alex-weej> i won't pretend to understand the situation, it just saddens me a bit
<seb128> well, it's not perfect
<seb128> and nobody is 100% happy about it
<seb128> but there is no other way around
<alex-weej> let's be honest
<Fujitsu> Does anybody really think Beryl is going to be stable enough?
<alex-weej> what's the goal here, to make the best software we can? or to get one up on Vista?
<mdke> both of those
<imbrandon> both
<alex-weej> it seems the second goal is just dragging us along with decisions we don't want to have to make yet
<alex-weej> there are a zillion other areas that need to be caught up with first
<alex-weej> like webcams and video conferencing
<seb128> Fujitsu: not me
<mc44> alex-weej: this really isnt the place to discuss this. If you have a problem with the decision, bring it up with the Technical Board
<alex-weej> or wireless networking
<alex-weej> jdong: does Firefox support session management yet?
<jdong> alex-weej: 2.0 does
<alex-weej> jdong: any reason why session saving is disabled by default in Ubuntu?
<jdong> alex-weej: it isn't
<slomo_> ogra: sorry that my explanation was not verbose enough... but i saw that you discussed it with pitti already and now like it ;)
<jdong> alex-weej: killall -11 firefox-bin
<alex-weej> jdong: x session that is
<jdong> or killall -9
<alex-weej> jdong: i mean desktop sessions
<jdong> X session management?
<jdong> oh
<jdong> I don't think it supports that
<Mithrandir> twb: you can merge it and then revert the content of the merge.
<twb> That is what I'm doing.
<twb> I'm asking about specific changes because I'm not sure if they are wanted by Ubuntu; what Ubuntu wants is not something I can answer.
<twb> http://twb.ath.cx/~twb/scratch/casper now builds and installs and boots (under qemu) on a vanilla Ubuntu 6.10 livecd.
<twb> I'm now building netboot images to see if they work, too.  (Netbooting wasn't supported in casper 1.78.)
#ubuntu-devel 2006-12-14
<keescook> wow.  *that* reboot was exciting.
<sfllaw> Mithrandir, cjwatson: Re: Bug 74004...  Have you also accepted the changes to initramfs-tools to edgy-proposed?
<Ubugtu> Malone bug 74004 in udev "Doesn't include qla2xxx firmware" [High,Confirmed]  http://launchpad.net/bugs/74004
<sfllaw> Mithrandir, cjwatson: Nevermind, I see it now.
<BenC> can someone publish linux-source-2.6.20 and accompanying packages please?
<jdub> fisty's switching to python2.5?
<bhale> aha fisty
<bhale> hi jdub 
<jdub> yo bhale
<jdub> i have an autocorrect in irssi to do that ;)
<LaserJock> hmm, "Fisty - the Break My Python release"
<LaserJock> so many ways that could be taken wrongly :/
<bhale> The Fawning Fist 6.09
* bhale shuts up
<jdong> bhale: that doesn't sound right....
<bhale> yeah no kidding
<jdong> that sounds like a terrible joke I'd make
<jdong> I've seen worse though
<bhale> bluefoxicy isnt here
<bhale> im filling in
<jdong> one particular non-fluent english speaker at the forums....
<jdong> in a thread he used "suppository" rahter than "repository" at least 20 times
<LaserJock> hah
<bluefoxicy> hahaha
<jdong> eventually I had to go through and edit most of that
<jdong> and pm him informing him of what suppository means
* bluefoxicy hands jdong a pill the size of his head
<bluefoxicy> You need to take this with a half a glass of water
<jdub> with a nick like jdong, of *course* it sounds like a terrible joke you'd make!
<jdong> because people were making terrible cracks (eugh pun) about it
<jdub> <- win!
<bhale> jdub ftmfw!
<jdong> lol
<jdong> ok, there needs to be a really brute-force rough-around-the-edges nuclear superhammer for dealing with 3rd party stuff breaking core ubuntu functionality
<jdong> ;-)
<LaserJock> "core"? :-)
<LaserJock> nv is workin' just great for me :p
<jdong> LaserJock: I was referring to a mass apt-get install --reinstall, apt-get remove $unofficial_packages
<jdong> :)
<keescook> jdong: probably scriptable by examining the install source of a package.  :)
<jdong> keescook: certainly it's very scriptable
<jdong> just someone needs to have the guts to write it :D
<LaserJock> hah, do we need a vsabdfl package?
<keescook> haha
<jdong> keescook: and did I read my inbox correctly  that there's more clamav patching fun for {dapper,edgy} now?
<ajmitch> afternoon
<keescook> jdong: yeah, there is.  the update is giant; I've got it prep'd for dapper/edgy already, but haven't had a chance to test it yet.
<keescook> hiya ajmitch 
<jdong> k
<jdong> not in a hurry
<jdong> just noted it
* jdong still has to deal with that dapper-backports oversight
<jdong> I'm just considering infinitely backporting from edgy-security for now :D
<keescook> heh
<jdong> of course that's nowhere near LTS timeframe
<jdong> but meh
<jdong> that'll give me 13 more months to come up with a better idea
<arpu> hi @all i hvae this problem  usb 3-1: device descriptor read/64, error -71 please can anybody help me ? 
* bluefoxicy stabs openoffice.org for crashing every time he tries to copy from it and paste into another program ><
<bluefoxicy> 
<bluefoxicy> I can past ehere
<bluefoxicy> pasting in firefox crashes oOo
<arpu> but i tested it with different kernels 
<arpu> so i think is not a kernel problem 
<arpu> a know this usb works for some time 
<_ion> arpu: Press the grey button on the device, the one to the right from the LED. That will definitely fix the problem.
<arpu> _ion: sorry i do  not understand 
<arpu> this is a webcam with pwc modul i pached the modul  with the unofficell pc modul 
<arpu> pwc ^
<minghua> arpu: please ask on #ubuntu for support, or file bugs in launchpad
<minghua> arpu: this is not a support channel
<arpu> minghua: ok thx a lot but i found a bug report but no solution 
<arpu> mom i search 
<bluefoxicy> this isn't a bug channel either
<minghua> arpu: please add your comments in that bug then
<bluefoxicy> as much as I flame the devs periodically for the particularly annoying ones.
<bluefoxicy> i.e. the ones that cause me to lose data 6 times in 5 minutes
<arpu> minghua bluefoxicy sorry and thx for your time and ork on ubuntu 
<arpu> minghua: https://bugs.launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/54419 ii do not know what i can write to help 
<Ubugtu> Malone bug 54419 in linux-source-2.6.15 "usb change between 2.6.15-23 and 2.6.15-26 breaks working setup" [High,Confirmed]  
<minghua> arpu: I don't know anything about kernel either, sorry
<locsmif> hi, i'm looking for the much talked about 'livecd.sh' script, where can i find it? (trying to rip ideas from it)
<LaserJock> locsmif: "much talked about", hmmm
<locsmif> mostly infinity and mithrandir, from what i could find on google
<locsmif> if it's public i'd like to take a look at it and rip ideas from it for my own ubuntu or debian based livecd possibly :)
<Seveas> locsmif, afaik it's not public
<locsmif> oh..ok
<locsmif> Well, at least i can stop looking for it then ;)
<locsmif> ty
<LaserJock> they might be able to give you a cleaned up version or something
<LaserJock> I'm not sure
<delire> isn't the livecd.sh used in http://reconstructor.aperantis.com/  or have i got my proverbial wires crossed?
<LaserJock> I doubt it, if it's the script I'm thinking of
<delire> ok
<LaserJock> changing an existing .iso is quite a bit different then making it frm scratch
<alex-weej> dmix is causing crackling in my stock u610 installation... :(
<twb> Mithrandir: OK, at last I'm trying to boot the merged caspre via NFS.
<twb> Sadly, ipconfig can no longer see eth0, a sis900-based NIC.
<crimsun_> alex-weej: and not reproducible with plughw:0 itself?
<twb> If, at the fallback initramfs shell, I do `modprobe sis900', ipconfig can detect eth0.
<alex-weej> crimsun_: correct
<twb> Any idea what's responsible for doing that modprobe when things are working?  I suspect udev.
<twb> It appears that casper is not doing the 0x02 udev magic, which is in the nfs-top/udev script.  I'm gonna try that myself, now.
<Chipzz> twb: sure ipconfig can't see it; that's because iPconfig is a windows command ;P
<twb> Chipzz: nope
<twb> ipconfig is a klibc command
<twb> And doing the 0x02 thing fixed it.
<twb> Yaaaay!
* Chipzz frowns
<ulinskie> hello!
<ulinskie> anybody here from ubuntu trademarks?
<twb> Mithrandir: any idea where casper-premount/udev comes from?
<LaserJock> ulinskie: "from" Ubuntu trademarks?
<LaserJock> ulinskie: http://www.ubuntu.com/ubuntu/TrademarkPolicy
<jdub> `anthony: oi.
<twb> Mithrandir: aha, the udev file is in the udev package.
<fabbione> morning
<imbrandon> moins fabbione 
<glick> hi
<BlackCheese> hi
<glick> i have a question
<glick> i work with redhat at work
<BlackCheese> fire away
<glick> and the way they bring up the different runlevels with S scripts and K scripts is what im used to
<glick> how does ubuntu do it
<glick> i guess to bring up runlevel 3 it just runs the scripts in rc3.d?
<glick> but i dont see any kill scripts
<glick> all S scripts
<fabbione> glick: they are no different
<BlackCheese> Ubuntu does E and J scripts mostly and ubuntu is unfit so it doesnt runlevel it walklevels with I scripts. Here at Ubuntu we believe Jebus is the light.... We take all very seriously
* Hobbsee glares at BlackCheese 
<imbrandon> ?
<fabbione> BlackCheese: ???????
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<fabbione> glick: the only main difference is that we use rc2 by default
<glick> fabbione, so how does it switch from level 4 to 3 for example
* mode/#ubuntu-devel [+b BlackCheese!*@*]  by Hobbsee
<fabbione> glick: the same way as redhat does
<glick> how does it stop services
<fabbione> glick: same way
<glick> fabbione, but i dont see K scripts
<fabbione> note:
<glick> only S scripts
<fabbione> yeah let me write :)
* mode/#ubuntu-devel [+b *!*@125-236-172-192.broadband-telecom.global-gateway.net.nz]  by Hobbsee
<fabbione> most of the K scripts are totally unnecessary
* mode/#ubuntu-devel [-b BlackCheese!*@*]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<fabbione> they are only missing from rc0 and rc6
<fabbione> because no matter what you do
<fabbione> the system sends a kill to all processes
<fabbione> and that's the same as using a K script
<fabbione> the few apps that still require a K script will retain it
<fabbione> the others have been removed
<glick> fabbione, hah ok
<glick> i see em
<fabbione> one of the side effects is a faster reboot/shutdown
<glick> ubuntu doesnt have a runlevel where it doesnt include X?
<fabbione> less code to run that's going to die anyway
<fabbione> glick: not as RH does
<imbrandon> glick: not really ( other than single user mode , but its not the same )
<glick> why not add such a runlevel?
<imbrandon> if there isnt a need , why add it :)
<fabbione> glick: google for it :)
<fabbione> glick: there have been tons of discussions about it
<glick> imbrandon, i don know there might be a need
<glick> i guess thats what server edition is for though
<glick> so i guess its not needed in the desktop distro
<imbrandon> or you could simply tell gdm/kdm/xdm not to start :)
<imbrandon> but exactly
<glick> do i use the service command in ubuntu like in redhat?
<fabbione> glick: really... google for it to find all possible reasons/objections/discussions
<imbrandon> you'll also notice too coming from redhat that we done beleive in having services installed that arent used, like sshd etc thus the split between ssh-client and -server
<imbrandon> but yea you have /etc/init.d/service stop|start|blah 
<imbrandon> but as fabbione said there is tons of disscussions that can be found on good as to why its done this way
<imbrandon> google*
<pitti> good morning
<imbrandon> moins pitti 
<ajmitch> morning pitti 
<pitti> hi imbrandon, hey ajmitch
<imbrandon> anyone know the reason ( other than everyone is super busy ) we've been holding off on apache2.2 ?
<Chipzz> fabbione: there's another difference
<pitti> imbrandon: I filed a sync request yesterday
<glick> heh ive used redhat so much
<glick> im used to it now
<Chipzz> fabbione: we start gdm from /etc/rc?.d/, while redhat starts gdm from init(tab)
<glick> and i cant stand redhat!
<fabbione> Chipzz: i am sure there are...
<imbrandon> pitti: rock on, good i found out i needed it today on my edgy webserver :(
<imbrandon> hopefully it wont be too much of a pita for me to backport
<imbrandon> :)
<Chipzz> so to stop gdm, on redhat you have to go to runlevel 3 (instead of 5), and on ubuntu you can do /etc/init.d/gdm stop
<imbrandon> Chipzz: or just install broken drivers and wait for gdm to time out </sarcasim>
<Chipzz> imbrandon: hehe :)
<imbrandon> sadly i know that from experince
<imbrandon> evil evil X :P
<Chipzz> yea, me too
<glick> hey in the next ubuntu release where compbiz an xgl will be the default, will there be easy options to not install them?
<glick> i mean will it be a choice? like install 3d desktop yes or no?
<pitti> glick: I truly hope so :)
<somerville32> Me too
<imbrandon> yes it should be a choice and it hasent been decided if its compiz or beryl and it most likely WONT be xgl, it will be AIGLX
<pitti> glick: right now, the desktop-effects package allows you to easily enable it
<somerville32> I have a 333mhz w/ 128mb of ram - 3d stuff would kill my box.
<glick> i just dont want it forced upon me
<imbrandon> somerville32: sounds like a good xubutu canidate :)
<pitti> glick: if we enable it by default, the same switch should be available to turn it off
<glick> im happy living in my 2d desktop world
<somerville32> imbrandon, Thats what I'm running ;] 
<glick> pitti, but it just seems like it should be off by default and enabled by a switch
<pitti> glick: I feel with you, I tried out compiz yesterday and found it so utterly broken that I immediately returned
<glick> especially if you have crappy vid hardware
<twb> The equivalent of service(8) in Ubuntu is invoke-rc.d(8).
<glick> i just dont want to see ubuntu become one of those annoying distros where you have to disable a bunch of stuff for it to be bearable
<twb> For interactive use, it's better to use /etc/init.d/<service>
<HrdwrBoB> glick: otoh, if it works, it's *amazing*
<glick> i still use dapper on my desktop
<twb> It's just chrome
<ajmitch> HrdwrBoB: I don't find it that special
<glick> HrdwrBoB, but its highly experimental software, im sure it has dozens of security holes in it
<HrdwrBoB> glick: security holes in my window manager isn't going to ruin my day
<imbrandon> dozens? wow they must have plugged some up /me stops
<imbrandon> time for sleep yall, gnight
<pitti> glick: I'm rather concerned about usability and hardware support here
<glick> HrdwrBoB, its more then a window manager
<glick> and it certainly can ruin your day
<glick> well it can ruin my day cause i have important files on my pc
<HrdwrBoB> well, it's unlikely to ruin my day, but it would be quite possible to ruin lots of peoples days 
<HrdwrBoB> glick: attack vectors on your window manager  are very little
<glick> HrdwrBoB, its not just a window manager
<glick> it has kernel access to hardware
<twb> Uh, surely the window manager has permission to exec and permission to talk to the x server.
<imbrandon> aiglx does not compiz :)
<imbrandon> anyhow any holes are not good holes
<HrdwrBoB> imbrandon: absolutely
<HrdwrBoB> but in order to own your WM, you'd have to run compromised code
<HrdwrBoB> .. in which case all bets are off in any case
<glick> Xserve and X.org have been around like 20 years, regular 2D and are still full of security holes
<glick> i mean i know you cant get ANY software completley bug free
<glick> but you can asomtotically approach an "acceptable" level
<imbrandon> glick: you know aiglx is part of x.org right, you guys are mixing the X server and the WM and the composite manager
<imbrandon> anyhow really really off
<glick> imbrandon, yeah
<glick> imbrandon, thats what im saying its not just a WM
<twb> If it really worries you, don't run X.
<twb> You can play dvds and look at pictures on the framebuffer.
<glick> sure would be faster :)\
<glick> but not as sexy
<twb> Actually, framebuffer terminals are significantly slower than 2d-accelerated X servers running xterm.
<twb> They also don't do antialiased fonts :-(
<twb> So yeah, I fixed a bug in the udev package.  Anyone interested?
<Hobbsee> twb: keybuk or someone probably is, when they're here.  would help if you gave the bug #
<twb> I haven't filed a bug yet.
<twb> The bug is actually introduced by feature patch that I'm waiting for Mithrandir to pull into the casper package.
<keescook> hey fabbione, can you have a look at an mdadm patch I pulled together?  I ran into a race with initramfs+md.  #75681
<fabbione> keescook: edgy or feisty?
<keescook> fabbione: feisty.
<pitti> hi keescook, still up?
<keescook> basically, my sata drives come online after local-top/mdadm has already aborted
<keescook> hiya pitti!  yeah, long evening.  :)
<pitti> short night for me :)
<fabbione> keescook: you have done a lot of work that has been already done and needs to be moved to udev-mdadm
<fabbione> +  wait=$(sed -e 's/ /\n/g' < /etc/mdadm/mdadm.conf | grep ^devices= | cut -d= -f2- | sed -e 's/,/ /g')
<fabbione> you have no guarantee that devices are listed in mdadm.conf
<keescook> fabbione: yeah, i know.  :P
<keescook> actually, that's a requirement for mdadm now (says the readme)
<fabbione> keescook: hem no.. it's not
<fabbione> ARRAY /dev/md0 level=raid5 num-devices=4 UUID=e4ac4774:c730d28b:0978c89e:2173da3d
<fabbione> this won't match anything in your entry
<fabbione> and stall
<keescook> aaah, you mean the device= isn't a requirement... good point
* fabbione has been there...
<fabbione> keescook: just wait for the spec to be implemented.. really
<fabbione> keescook: i didn't spend time fixing mdadm in feisty..
<keescook> the udev-md spec says it's implemented, so this led to my confusion.  :)
<fabbione> see the big SRU for mdadm in edgy
<fabbione> no it has been mistakely marked as implemented and reassigned to me
<keescook> oh! hah.  okay.  :)
* fabbione changes status
<jdong> keescook: is it true that madwifi has some buffer overflow
<keescook> jdong: yup.
<jdong> keescook: exploitable to gain root?
<jdong> keescook: lovely :)
<jdong> but there is good news?
<keescook> jdong: unsure if it's been proven to gain root, but it's a stack attack, so it's likely.
<jdong> keescook: mmm :-/ not something I like to wager :D
<keescook> fabbione: cool, I'll leave my patch in place on my machine for now.  Let me know when you want beta code tested.  :)
<fabbione> keescook: i am blocked by Keybuk that needs to do a udev upload
<fabbione> keescook: and i have plenty of raids to test, but yes.. i will let you know..
<fabbione> one more test > *
<keescook> :)
<desrt> pitti; hello :)
<pitti> hey desrt 
<desrt> do you know when the new kernel for dapper will be out?
<pitti> desrt: erm, the ones I released yesterday?
<desrt> ((btw: having my security notifications signed by someone whose pgp key i have signed directly is cool))
<pitti> heh
<desrt> the firewall fix isn't in the dapper kernel
<desrt> you mentioned that in your mail, i think
<pitti> desrt: ah, right; there was some serious trouble with backporting that patch
<pitti> desrt: we have a patch which is currently reviewed by upstream
<pitti> desrt: so I hope we can get another update in January
<desrt> !!
<desrt> well, in any case,  idon't think the bug affects me
<desrt> i guess if you have fragment reassembly in place then it doesn't matter
<desrt> it sort of makes me consider upgrading to edgy, though
<pitti> desrt: argh, I should have mentioned that it only affects IPv6
* pitti fixes this on the webpage
<pitti> done
<desrt> oh.  nice.
<desrt> ipv6 is for suckas :)
<fabbione> desrt: ipv6 is teh winnar.. you suck
<fabbione> pitti: dude...
<fabbione> usn-395-1
<desrt> ya.  seriously.
<fabbione> pitti: CVE-2006-5648 affects sparc too. the kernel is patched, but the USN needs to be updated
<fabbione> pitti: 
<fabbione>   * [SPARC64] : Fix futex_atomic_cmpxchg_inatomic implementation.
<fabbione>     Upstream GIT-SHA: c7fed9d75074f7c243ec8ff2c55d04de2839a6f6
<fabbione>     - Malone #68266
<Ubugtu> Malone bug 68266 in linux-source-2.6.17 "unkillable cpu-eating zombie children left by glibc build" [Medium,Fix released]  http://launchpad.net/bugs/68266
<desrt> that bug has, perhaps, the best summary ever
<fabbione> desrt: luckly i didn't do the usual make -j 4096
<desrt> holy crap.  i haven't signed martin at all.
<desrt> !
<desrt> travesty
<fabbione> desrt: did i ever sign you?
<desrt> yes
<fabbione> desrt: i am pretty sure i did.. 
<fabbione> ok
<desrt> and i signed you and emailed the sigs
<fabbione> yeps
<desrt> but you couldn't open them or something
<fabbione> yeah i think i did it
<desrt> oh.  good :)
<fabbione> what's your gpg uid?
<desrt> afaa6ff6
<fabbione> uid as in email
<desrt> desrt@desrt.ca
<desrt> lots of gdm flaws today
<fabbione> hmmm
<pitti> fabbione: ok, /me fixes wiki page
<desrt> eep.  only one flaw.  just looked like lots from the volume of emails i got
<fabbione> pitti: thanks
<fabbione> desrt: it looks like i don't have them.. oh well
<desrt> fabbione; i used scott's script.  at the time you said you were having difficulty opening them
<desrt> fabbione; you could probably check in your received mail for them
<desrt> (if you really care) :)
<fabbione> desrt: no i am sure i don't have them in my inbox
<pitti> fabbione: done, thanks
<fabbione> desrt: i guess we will resign next time
<desrt> fabbione; i'm sure i'll see you soon :)
<desrt> any word on where the next one will be?
<fabbione> desrt: and if not.. i wish you a good travel in the other life
* desrt will probably be in the area if it's in europe
* pitti tests 2.6.20, rebooting
<desrt> pitti; on your laptop?
<pitti> desrt: both amd64 desktop and ppc laptop
<fabbione> looks good on sparc
<desrt> hold it up to your ear
<desrt> is it ticking anymore?
<pitti> desktop is running now
<pitti> argh, usb 2.0 broken
<desrt> usb 2.0 was broken before you rebooted your desktop, dear :)
<pitti> desrt: 'ticking'???
<desrt> pitti; the new kernels are supposedly "tickless"
<desrt> or, rather, circa 2.6.17-8 i heard "we'll be tickless by 2.6.20"
<desrt> ie: the timer interrupt (HZ) no longer constantly runs
<desrt> but, rather, is only scheduled when it needs to be
<pitti> ah, I remember
<desrt> not sure how you find out if you're tickless or not
<desrt> (i doubt the trick with holding it up to your ear actually works)
<jdong> desrt: pfft
<jdong> desrt: doesn't fix C3/C4 buzzing on my laptop
<jdong> desrt: tickless patches that is
<desrt> well
<desrt> that's because the entire userland is retarded
<jdong> I hope that's why
<desrt> come see my talk at linux.conf.au about how to fix it :)
<jdong> :)
<jdong> I see the .au and somehow think it won't happen :D
<desrt> dude.  summer in january.
<jdong> but i'll be awaiting the day I can send my alptop to C3
<pitti> cjwatson_: may I nag you about the SRU bug 59946 again?
<Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,In progress]  http://launchpad.net/bugs/59946
<twb> Anybody know if usplash can be made to work over pxelinux?
<twb> s/over/with/
<fabbione> twb: what do you mean over pxelinux?
<fabbione> usplash starts from initramfs
<pitti> argh, why does gdb get more broken with every release recently?
<twb> I think the underlying problem is that the framebuffer isn't being used.
<fabbione> twb: pxelinux is just a minimal piece of code to download kernel and initramfs
<twb> I just get a boot: prompt instead of the full gxfboot thing that you get when booting with isolinux.
<fabbione> works fine here
<twb> Hmm, maybe it's because I'm using CentOS4's pxelinux.0 instead of Ubuntu's
<twb> (I'm stuck with CentOS on the server, against my will)
<fabbione> you can still use pxelinux.0 from ubuntu
<twb> That's what I'm about to do.
<fabbione> anyway this is become #ubuntu stuff
<twb> Sorry.
<twb> fabbione: (moved to #ubuntu)
<Zober> Is there an svn system out there that does not require installation?  For example, if i want to host a repository on my site, but its a shared host with no shell privilages.
<pitti> Zober: setting up svn requires shell access TTBOMK
<Zober> is there a knockoff of svn that run on say php/mysql?
<Zober> or perl and mysql or something
<pitti> Zober: however, bzr does not :) it can use sftp, rsync, or you can copy it with ftp, or whatever
<Zober> nice!
<desrt> </sales-pitch>
<desrt> sigh.
<desrt> every time i read a get-women-involved-in-linux document i am depressed
<desrt> i'm like "oo.  magic solution"
<desrt> and then it's either the same-old, or worse
<desrt> :/
* desrt goes to bed
* mdke points at #ubuntu-offtopic
<dade`> don't go to bed
<dade`> we have 2.6.20 \o/
<dade`> desrt: have you tried it ?
<Zober> pitti, have you ever set up bzr?
<pitti> Zober: sure, I use nothing else :)
<Zober> where is the server side portion of it?
<Zober> in downloading the client
<Zober> screenshots look something like tortoise
<pitti> Zober: this is off-topic here, btw
<pitti> Zober: there is no server-side
<pitti> Zober: please read the tutorial on https://bazaar-vcs.org
<Zober> thanks
<pitti> Lathiat: I'm going to update dapper's and edgy's avahi now; did you see any regression with the current patch? (I didn't)
<pitti> Lathiat: I know you wanted to actually test injecting bad netlink packets, but since it's such a serious regression, I'd rather make it work RSN
<Mithrandir> so, what should we do about the missing update-inetd?  Fix the apps or add the dependency and wait until shit is fixed in Debian?
<pitti> seb128: so, the pkg-create-dbgsym testsuite works for you on current feisty?
<pitti> seb128: if you boot to 2.6.20, could you run it again and compare? I'd appreciate that
<pitti> seb128: to see the comparision between i386 and amd64
<seb128> let me try
<seb128> I just need to build pkg-create-dbgsym ?
<pitti> seb128: no, just apt-get source and ./testsuite
<seb128> running
<seb128> brb
<pitti> wb seb128 
<seb128> re pitti
<seb128> pitti: "2.6.20" on my chinstrap user dir, that the testsuite on i386 with 2.6.20
<pitti> seb128: did it succeed?
<seb128> no
<seb128> well, there is some PASS and some FAIL too
<pitti> seb128: right, the failed ones are the gdb
<seb128> compare with 2.6.17 at the same place
<pitti> seb128: and it passed on 2.6.17
<seb128> exact
<pitti> seb128: ok, I wait until the gdb testsuite (and thus the package build) has finished here and test on amd64 again
<pitti> seb128: fun, with our current feisty package, gdb failed *all* tests...
<seb128> for some value of fun :p
<seb128> I'm happy to be still running 2.6.17 :p
<pitti> seb128: why doesn't .19 work for you? for me, it only breaks the nvidia driver resolution
<seb128> my network card stop communicating after some time
<seb128> and the only way to get network again is to reboot
<pitti> hey dholbach 
<seb128> some time being 30min to one hour usually
<dholbach> good morning
<dholbach> hey pitti, hey seb128
<seb128> hi dholbach
<somerville32> Good Morning! :)
<dholbach> heya somerville32
* somerville32 hugs dholbach.
<seb128> hi somerville32 Keybuk
* dholbach hugs somerville32 back
<Keybuk> morning
* somerville32 hugs keybuk.
* Keybuk hugs somerville32
* dade` hides
<fabbione> cjwatson_: i did test network-console and found only 3 minor issues. Do you have time to discuss them when you will be around?
<pitti> seb128: \o/ my gdb loves me again
* seb128 hugs the great pitti
<pitti> and so does apport again
<seb128> how did you fix it?
<pitti> seb128: I grabbed the patch to support the .gnu.hash ELF section from upstream CVS
<pitti> seb128: ok, I uploaded the new gdb; it would be great if you could test it again on i386 once it's built
<seb128> pitti: sure
<fabbione> hmmmmmmmmmmm
<fabbione> who broken samba upgrade? ...
<fabbione> Mithrandir: don't you feel guilty today? :P
<pitti> argh, vmware doesn't like 2.6.20, brb
<fabbione> actually
<fabbione> Mithrandir: never mind.. it's that update-inetd thingy
* Keybuk wants to know who broke ondemand
<seb128> fabbione: https://launchpad.net/distros/ubuntu/+source/samba/+bug/73734 ?
<Ubugtu> Malone bug 73734 in samba "update-inetd dependency missing on 3.0.22-1ubuntu4 (feisty)" [Unknown,Fix released]  
<fabbione> seb128: yes... that one
<seb128> there is a patch if you feel like sponsoring the upload :)
<fabbione> seb128: that's why i removed Mithrandir from the list of suspicious people
<fabbione> seb128: i think Mithrandir is working on a more general thing
<seb128> ok
<Mithrandir> fabbione: the general fix is "add the missing dependencies". :-P
<Mithrandir> fabbione: the limit of my guilt would be "not testing the package prior to upload", but I just changed the build-deps, so. :-P
<fabbione> Mithrandir: you still touched it last :P
<doko> Mithrandir: are you able to requeue packages?
<cjwatson_> 21:00 < twb> I notice the isolinux.cfg for Edgy includes a ramdisk_size kernel argument.   What does this do, and what are the consequences of changing the ramdisk without updating or removing this argument?
<cjwatson> twb: I think ramdisk_size is actually unnecessary now; I removed it from feisty CDs a week or two back
<cjwatson> twb: it was a hangover from when we used to use an initrd rather than an initramfs
<Mithrandir> doko: yes
<cjwatson> twb: gfxboot != usplash; I don't think pxelinux has been fully educated about gfxboot yet, so you'd need to do so. Assembly hacking ahoy
<cjwatson> fabbione: network-console> sure
<doko> Mithrandir: please requeue eclipse on ia64, maybe on another machines. looks like random failure to me
<Mithrandir> doko: given-back
<fabbione> cjwatson: ok.. so the 3 things i noticed are: network-console did not run automatically even if installed. from the partitioner i went back to the main menu and netcon entry was before (higher priority?) of choose mirror. when ssh into the system and selected to run the installer, i was in very low debconf priority. AFAICT we should move netcon after choose-mirror (otherwise on netinstall you don't have netcon installed when it's supposed 
<fabbione> to run). Probably we need to increase it's priority to make it run by default when selected (assuming this isn't just a fallout from the previous issue) and last we should preserve the default debconf priority when ssh'ing into
<fabbione> cjwatson: last problem is that i am not sure how to do any of the above....
<fabbione> cjwatson: so i am seeking your god-alike 31337 sk1ll5 here
<cjwatson> well, this is kind of awkward
<cjwatson> network-console should be as early as possible after the network is up, to avoid having to use the serial console more than you have to; remember that there are situations where it's included in the initrd, and moving it after choose-mirror would be suboptimal for those
<cjwatson> this is really http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288053
<Ubugtu> Debian bug 288053 in network-console "network-console - Regression: is not correctly added in menu" [Important,Closed]  
<fabbione> cjwatson: ok, than we have some kind of chicken-egg problem because if we need to download it from the mirror then choose-mirror is mandatory
<cjwatson> or we could just include it in the initrd *shrug*
<fabbione> i vote against initrd
<fabbione> i'd rather ask one more question in console
<fabbione> the real pain of console is the partitioner and the package installation
<cjwatson> well, I don't approve, I'd rather fix that main-menu bug somehow
<fabbione> dropping netcon in the initrd means pulling in sshd and ssl
<fabbione> that would be a bloat IMHO
<cjwatson> fixing the main-menu bug would be optimal and would avoid the need for either of these breakages
<cjwatson> needs some care though
<cjwatson> I don't understand why the priority would be any different
<fabbione> i wouldn't know how to.. i did never fiddle with main-menu
<cjwatson> network-console doesn't set it
<fabbione> cjwatson: probably the drop of debconf priority is a fallback from me having to <go back> to main menu to select it
<cjwatson> oh, probably. main-menu knows to restore that, but it probably doesn't get a chance in this case
<cjwatson> I'm not concerned about that, then
<fabbione> i have the feeling that 2 of these issues are just fallouts of netcon not being configured automatically... 
<fabbione> well you understand what i mean
<fabbione> i am not too concerned either.. i just would like to verify that sometimes
<cjwatson> yes, the priority is just fallout
* Mithrandir hugs shell, awk and grep
<twb> cjwatson: thanks.
<twb> Mithrandir: merged casper that works for me is available
* pitti arghs at avahi FTBFSing in dapper -- the world just seems to hate me today
<fabbione> cjwatson: what would be your ideal solution in the short term that won't require casting black magic on main-menu?
<cjwatson> fabbione: ENOENT
<cjwatson> fabbione: fixing main-menu (or having time to investigate without being asked for workarounds) is my ideal solution
* Mithrandir wonders wtf language-support-sco is.
<cjwatson> Scots I think
<Mithrandir> looks like it
<fabbione> cjwatson: ok.. i will let you quiet.. i didn't expect you to dig into this fast
<cjwatson> fabbione: the reason that it's currently skipped is Debian bug #224633
<twb> sco Scots Scoats leid; Lallans
<twb> http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
<fabbione> cjwatson: feh yeah i remember that too
<Mithrandir> twb: coolie, what's the URL?
<twb> http://twb.ath.cx/~twb/scratch/casper/
<twb> Mithrandir: I had to make a minor change to udev, too, to make it load the network drivers before trying to nfsmount.
<twb> http://twb.ath.cx/~twb/scratch/udev/
<twb> ...that change is only needed if you are netbooting, however.  You can boot from a CD-ROM without it.
<Mithrandir> twb: I'll take a look at it; thanks a lot!
<twb> No no, thank you!  Once it gets into feisty, I can just install it via apt-get instead of having to ship the .debs around myself.
<fabbione> Keybuk: davem is working on the kernel to export that sysfs attrib we did talk about.
<Keybuk> sweet
<twb> Keybuk: I found a typo in the udev bzr branch.
<Keybuk> twb: oh?
<twb> Keybuk: yeah, in debian/udev.docs
<Keybuk> twb: what's the typo?
<twb> -doc/writing_udev_rules/index.html
<twb> +docs/writing_udev_rules/index.html
<Keybuk> twb: where's that referenced?
<Keybuk> it is docs here
<twb> http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/
<twb> Admittedly, I may be branching the wrong branch.
<Mithrandir> there, main fixed wrt update-inetd mess.
<StevenK> Keybuk: What do you think about putting a "Last updated: <date>" on the MoM pages?
<Keybuk> StevenK: *shrug* just look at the date in the header, or on the listing?
<Keybuk> twb: oh, that branch has never been used
<Keybuk> udev isn't in bzr
<twb> Why are there branches for it, then?
<StevenK> Keybuk: On the listing.
<StevenK> Keybuk: Just to give a clue that MoM isn't updating, or so.
<Keybuk> twb: because I attempted to put it into bzr, and gave up
<twb> Bummer.
<Keybuk> and there's no way of deleting branches in LP
<twb> Keybuk: so if I want a change to the initramfs stuff that udev installs for casper, what's the best way to go about it?
<Keybuk> twb: send me a patch
<Keybuk> apt-get source udev to get the current code
<twb> OK.
<twb> Basically the file that ends up in casper-premount/udev needs an extra
<twb>  /sbin/udevtrigger -s -Bpci -Iclass=0x02*
<Keybuk> ?
<Keybuk> that file doesn't exist in feisty
<twb> Hmm.
<twb> I'm working with edgy atm
<Keybuk> (and why do you need network cards to mount the casper root fs?)
<twb> Keybuk: because the casper rofs is on an NFS export, not a CD.
<Keybuk> I see
<Keybuk> you'll have better lucky with feity, as that just triggers everything
<twb> If casper-premount/udev is not in feisty, what has replaced it?
<Keybuk> nothing
<Keybuk> the init-premount script (that starts udevd) now just calls udevtrigger on everything
<Keybuk> that only takes 0.03s on my laptop
<twb> I see.
<twb> Why didn't it do that in Edgy?
<Keybuk> because we needed to settle the events in edgy
<Keybuk> (ie. wait for them to actually finish)
<Keybuk> feisty it's ok for them not to be finished, any script should expect the device it wants to not be ready yet
<Keybuk> e.g. mountroot spins
<twb> Does it spin asynchronously?
<twb> Perhaps that question doesn't make sense.
<cjwatson> fabbione: untested main-menu patch heading towards http://bugs.debian.org/288053
<twb> When does feisty release?
<Keybuk> April 19th
<ogra> you should ask "when is feistys feature freeze ?" rather ;)
<fabbione> cjwatson: ok..
<fabbione> cjwatson: got the patch.. i will try to build an installer either later today or tomorrow to test it.
<cjwatson> ok
<fabbione> bah screw that.. 
* fabbione builds now
<Lathiat> pitti: i havent seen any problems
<Lathiat> pitti: so if youd like should be ok
<pitti> Lathiat: great, thanks; /me releases
<fabbione> cjwatson: booting the image now...
<fabbione> cjwatson: nope.. didn't work...
<fabbione> bahhhh
<fabbione> nevermind
<fabbione> scratch that
* fabbione retest
<fabbione> cjwatson: I LOVE YOU..
<fabbione> that patch seems to work just fine'
* fabbione hugs installation using sshd
<pitti> fabbione: yay
<fabbione> pitti: we still need cjwatson supermagic power for main-menu fix
<fabbione> otherwise it works
<Mithrandir> fabbione: now we just need tftp over ssl.
<fabbione>    | To continue the installation, please use an SSH client to connect to  |    
<fabbione>    | the IP address 192.168.1.5 and log in as the "installer" user.        |    
<fabbione> Mithrandir: sickness :P
<ogra> openvpn ?
<Mithrandir> ogra: do you know of any firmwares that support openvpn?
<ogra> Mithrandir, firmware ? didnt you talk about tftp ?
<Mithrandir> ogra: yes, firmwares often support tftp for you know, netbooting. :-P
<fabbione> ogra: patches to OBP are welcome :P
<ogra> pfft ... that use for tftp is totally overrated :P
<ogra> we were experimenting with openvpn initramfs inbtegration for ltsp ... but indeed thats after tftp :=)
<fabbione> ogra: dude.. you start to scare me now....
<ogra> fabbione, why ? whats wrong with wrapping nfs into a vpn tunnel to make it more secure ? :)
<fabbione> ogra: nothing wrong.. but at that point you might as well send the entire installation in the initramfs :)
<ogra> haha
<ogra> there is a guy who does that ... as an alternative to ltsp ...
<ogra> its pretty ugly, but seems to work
<Mithrandir> ogra: it's only ever-so-slightly stab-yourself-in-the-eye, but apart from that, it's nice and lovely.
<dholbach> heno: you're not in #ubuntu-bugs! :-)
<pitti> doko: did you already do anything with till's new hplip package?
* dholbach hugs heno
<dholbach> heno: how's it going?
<doko> pitti: no, not yet
<fabbione> ogra: what's wrong with that? you can get almost full OS with less than 40Mb of compressed initramfs
<fabbione> ok..
<fabbione> time to stop
<ogra> fabbione, right ... 
<fabbione> cya later at the meeting
<pitti> doko: ok, since AFAIR you cannot test it either any more, I just eyeball and upload, ok?
<doko> pitti: ok with me
<pitti> doko: argh, I wish he would put source.changes there, not i386.changes
<heno> dholbach: yeah I don't auto register to many channels, was just sitting in on the LP meeting as distro rep, will report later
<dholbach> heno: ah nice
<fernando> moin all
<neutrinomass> mjg59: (I was redirected to you ) On what basis are acpi issues assigned to the kernel vs. acpi-support ?
<dholbach> ogra: there's a new dia release
<ogra> dholbach, thanks
<dholbach> de rien
<mjg59> neutrinomass: If it's a bug in the kernel, it goes against the kernel. If it's a bug in the shell scripts, it goes against acpi-support.
<mjg59> Which means that it should pretty much always be against the kernel
<neutrinomass> mjg59: Ok, thanks 
<seb128> mjg59: hi
<seb128> mjg59: sorry to ping you again about the new compiz, I just want to get that moving and in shape before then people try to replace it by beryl
<seb128> mjg59: if you don't have time to work on the update I can do it, just let me know
<mjg59> Ok. Feel free to do so - I'm busier than expected right now
<seb128> mjg59: ok, I'll just do the update to the new version for now, we can discuss package split and other changes later
<mjg59> Ok
<ogra> dholbach, hmm, that dia release is called 0.96-pre1 ... not sure we want that ...
<seb128> ogra: why not?
<ogra> we never used the -pre versions ...
<seb128> well, depends if they will have 0.96 before feisty
<ogra> they are not followint the gnome schedule, do they ? 
<ogra> *following
<seb128> no
<cjwatson> fabbione: woo, nifty. rock on untested patches
<Lathiat> pitti: your goign to love me
<dholbach> ogra: it's still a while until uvf :)
<ogra> hmm, it ftbfs'es anyway with a tom of compiler errors
<ogra> *ton
<dholbach> nice :)
<bddebian> Heya
<salgado> I assume dpkg-buildpackage -nc is the fastest way to rebuild a package after I did some changes to it, is that right?
<cjwatson> pitti: reading the g-s-t bug now
<cjwatson> pitti: so this is basically just reverting the auth mechanism to dapper?
<pitti> cjwatson: right
<cjwatson> pitti: did you grep for anything else that does the same sort of thing done by time-tool?
<pitti> cjwatson: plus reintroducing the gksudo calls from various applets
<pitti> cjwatson: those were the fixes we made in dapper; I didn't grep the archive for more, just discussed that with seb128 
<pitti> and I went through the menus to find more, but didn't
<pitti> cjwatson: oh, the time-admin patch is not 'reverting to dapper', it's a new patch
<pitti> cjwatson: since dapper's time-admin didn't yet try to talk to the session dbus
<pitti> cjwatson: the patch is in feisty for a while
<cjwatson> pitti: ok, I'm happy with the general approach; could you upload that lot?
<pitti> cjwatson: sure, thanks
<cjwatson> I'd like to be able to use Breaks for this, but I suspect that is not really safe for edgy-{proposed,updates} since upgrades from dapper will use that
<pitti> right, the newer s-t-b breaks the older g-s-t
<cjwatson> pitti: in edgy, doesn't it have to be gksudo rather than gksu? I thought the sudo-mode stuff was new in feisty
<pitti> hmm, AFAIR I did test it in edgy, but I'll do it again just to be 100% sure
<pitti> cjwatson: but from what I can see it was in dapper
<pitti> gksu (1.3.7-0ubuntu7) dapper; urgency=low
<pitti>   * debian/patches/02_ubuntu_gksuexec.patch:
<pitti>     - removed, no longer needed because we can always use gksu and
<pitti>       it will use a gconf key to determine what backend (su, sudo) to use
<cjwatson> hmm, ok
<cjwatson> maybe I'm thinking of when corresponding changes were introduced in Debian
<seb128> mjg59: in fact that compiz upgrade is not that easy that I though since there is no .diff.gz but everything to the tarball. Is there any distro change we should keep? If that's the case I'll let you do it rather than dropping changes because I don't know about them
<cjwatson> pitti: your gnome-applets change has a memory leak: you need to (a) free application and gksu in the early return since one of them might be non-null (b) free gksu at the end
<pitti> cjwatson: oh, good catch; I'll fix that
<cjwatson> pitti: would it be a good idea to drop to SUDO_GID as well as (before) dropping to SUDO_UID?
<cjwatson> I know that ubiquity does that when poking gnome-screensaver
<pitti> cjwatson: it's not necessary for connecting to the session dbus
<pitti> cjwatson: my initial patch had that, but I removed it since I didn't see a benefit
<cjwatson> ok, I guess it's not a big deal
<pitti> and I prefered a smaller patch
<cjwatson> all the diffs are fine with the exception of the gnome-applets one
<pitti> cjwatson: updated gnome-panel is building
<pitti> erm, -applets
<cjwatson> can we maybe add a Conflicts or something in s-t-b?
<cjwatson> if it breaks the old g-s-t, then we could end up in a situation where users can't run any administrative tools ...
<cjwatson> well, they could run synaptic and update-manager I suppose, but still
<cjwatson> would need to be on g-s-t plus the other binaries you changed
<pitti> cjwatson: if that wouln't disrupt apt, I'm fine with that
<cjwatson> well, it's no worse than any of the other Conflicts << in the archive
<pitti> cjwatson: the other changes are not really that important IMHO, they are just convenience shortcuts
<cjwatson> ok, then just on g-s-t
<pitti> cjwatson: ok, could you please rejest the s-t-b upload?
<cjwatson> done
<pitti> Conflicts: liboobs-1-1 (<< 0.5), gnome-system-tools (<< 2.15.5-0ubuntu3~prop1)
<pitti> (the liboobs one was there before)
<cjwatson> yep
<cjwatson> does the new g-s-t also break the old s-t-b?
<cjwatson> I guess not
<pitti> cjwatson: no, that way works
<cjwatson> well, it won't be able to talk to the user's session bus
<pitti> cjwatson: that's fine, since the session bus fix is in g-s-t itself
<pitti> not in s-t-b
<pitti> i. e. the new gst is fully operational with the old s-t-b
<cjwatson> right, ok, all the other dbus communication is on the system bus?
<pitti> right
<pitti> I verified that with a grep
<pitti> and, of course, by testing all the apps
<cjwatson> ok
* pitti edits control.in instead and goes back to start, without getting $4000
<pitti> cjwatson: ok, new g-applets work fine with new patch, also tested with mv /usr/bin/gksu{,.old}
* pitti attaches
<pitti> cjwatson: new patch attached, I marked the old one as [obsolete] 
<pitti> cjwatson: g_free(NULL) is safe, thus this works
<cjwatson> pitti: right, my thought too
<ogra> ogra@edubuntu:~/packages/edsadmin-1.0$ dpkg -S /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so
<ogra> dpkg: /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so not found.
<ogra> ????
<ogra> seb128, ^^^ any hint ?
<seb128> ogra: 
<seb128> $ dlocate gobject.so
<seb128> python-gobject: /usr/lib/python-support/python-gobject/python2.5/gtk-2.0/gobject/_gobject.so
<seb128> python-gobjec
<seb128> grumpf
<seb128> python-gobject: /usr/lib/python-support/python-gobject/python2.5/gtk-2.0/gobject/_gobject.so
<seb128> python-gobject: /usr/lib/python-support/python-gobject/python2.4/gtk-2.0/gobject/_gobject.so
<seb128> without _ :)
<ogra> ah
<seb128> ups
<seb128> yeah, it's available correctly for me
<cjwatson> moved to /usr
<ogra> oh
<ogra> right, i didnt even see that
<ogra> anyway, this package build deps on python-gtk2 ... isnt that a metapackage that should pull in python-gobject ?
<ogra> or do i need to explicitly list all pygtk bindings nowadays ?
<pitti> cjwatson: fine to upload gnome-applets?
<fabbione> cjwatson: well dude.. you rock.. we know that...
<seb128> ogra: ?
<pitti> seb128: ah, your g-s-t upload to edgy-updates beat mine
<seb128> ogra: python-gtk2 Depends on it
<cjwatson> pitti: yeah
<ogra> seb128, i have a package that build-deps on python-gtk2, configure of this package runs "import gobject" to check for pygtk availability
<ogra> apparently it fails, even though the build dep is there
<seb128> ogra: weird, what is the package? something I can try from a pbuilder?
<ogra> its edsadmin, let me look up the repo url
<ogra> http://mrroach.okmaybe.com/software/edsadmin/debian/
<cjwatson> pitti: edgy-updates language-packs belatedly accepted
<cjwatson> pitti: except for language-pack-af, which for some reason soyuz isn't letting me accept
<pitti> cjwatson: g-s-t and friends all uploaded, I got accepted mails
<pitti> cjwatson: is there anything special about -af?
<cjwatson> I think it was my fault - there may have been some weirdness during queue processing that led to a duplicate item in unapproved
<cjwatson> it's in the accepted queue as well, so I've just rejected it
<Keybuk> cjwatson: there's a pesky soyuz bug
<Keybuk> I've ended up with things in multiple queues simultaneously when doing syncs
<ogra> woah ... gnome-screensaver is evil ...
<Treenaks> ogra: it is?
<ogra> yeah, 2.17.3 just kills my session if i lauch the settings tool
<Treenaks> ogra: cool
<ogra> intrestingly that happens wit the 3d bubbles hack selected ... which is unlike the name suggests a 2d screensaver
<ogra> damned, who had this crappy idea to translate all the hacks in the g-s-s UI ...
<Treenaks> ogra: your employer? :P
* ogra tries to find out which screensaver is which
<dholbach> snu u u  u
<radix> man that is not a thing that should be possible
<Spads> haha
<Spads> that is some fantastic abuse of unicode
<Spads> although gnome-terminal doesn't handle the overwrite control stuff very well
<dholbach> xchat-gnome neither
<Spads> perhaps that ought to go on the agenda :)
<ogra> hmm, my i is broken if its upside down
<Spads> ogra: he was using U+0131  LATIN SMALL LETTER DOTLESS I and U+0323   COMBINING DOT BELOW
<radix> yeah, I just figured that out with python :P
<radix> isn't there a LATIN SMALL LETTER TURNED I? :)
<Spads> ogra: and gnome-terminal doesn't seem to do combining characters very well
<ogra> yeah
<Spads> a ought to just look like 
<radix> gedit messes up the i + combined dot
<radix> as well
<Spads> there are a lot of problems with even attempting to support fixed-width unicode
<Spads> so I'm not surprised
<seb128> ogra: 
<seb128> # grep Build-Depends edsadmin-1.0/debian/control 
<seb128> Build-Depends: debhelper (>= 4.0.0)
* ogra slaps forehead
<ogra> seb128, so sorry ... 
<psusi> pitti: ping
<seb128> ogra: np
<pitti> psusi: in a meeting, pong
* ogra now sits there blushing 
<seb128> ogra: happens to everybody no worry ;)
<psusi> pitti: ok.... just wanted to let you know in case you had not yet noticed, I updated bug #60894 with a debdiff and assigned it to you since you were the last person to update the reiserfsprogs package
<Ubugtu> Malone bug 60894 in reiserfsprogs "mkfs.reiserfs creates an unmountable file system" [Unknown,Confirmed]  http://launchpad.net/bugs/60894
<pitti> psusi: ah, fine
<psusi> pitti: someone else could upload it I'm sure, but I figured you might want to since you touched the package last
<Chipzz> anyone seen this? http://parker1.co.uk/satanic/
<Chipzz> </offtopic>
<pitti> psusi: I don't have a particular affection for the package, but if it just comes down to sponsoring, that's fine for me
<psusi> pitti: if you think you will get to it soon great, otherwise if you don't care I can ask for someone else to sponsor
<pitti> psusi: I set it to 'in progress' to catch my attention
<pitti> psusi: but it might take until January
<pitti> psusi: if you find someone who has time for it now, go ahead
<psusi> lol... ok... I'll try to find another sponsor to upload ;)
<psusi> so... anyone else have time to upload a very simple patch correcting the man page of mkreiserfs? ;)
<pitti> psusi: oh, just the manpage? consider it done then
<pitti> psusi: I thought it was something that requires much brainpower to check
<psusi> pitti: hehe, ok... yea... I just fixed the man page to note that the kernel does NOT support block sizes other than 4096 bytes
<pitti> psusi: ok, will upload in some minutes
<psusi> cool
<psusi> I also emailed the debdiff to the debian bts
* psusi screams at yet another notice of waiting for moderator approval
<psusi> pitti: well I replied to your email about the local file mount in gnome, but it's currently waiting for moderator approval... anyhow... why do we no longer use pmount?  don't we want devices that are either flagged as user or not in fstab at all to be mountable by non admins?
<pitti> psusi: we do, but the hal backend + gnome-mount do that now
<psusi> pitti: oh, it sounded like you were saying that it now required sudo to do the mount
<pitti> psusi: no, only for fixed hard disk partitions; that didn't work at all before
<psusi> yea, that's what I'm talking about... if you have a fixed partition that is marked as user mountable, you shouldn't need sudo to mount it
<pitti> psusi: ah, right, that's a special case
<psusi> and I'm not entirely sure I agree with non admins not being able to mount fixed partitions that don't appear in fstab at all
<pitti> I'm paranoid about that
<pitti> other partitions == other Unix systems, windows systems, etc.
<psusi> if it is really a fixed disk, then it should have an entry in fstab
<psusi> and if the admin doesn't want users to mount it, it should say noauto nouser
<pitti> but admin has super-powers, it's not an 'user'
<psusi> I'm talking about a non admin user.... unless the admin set fstab to say nouser noauto, then the non admin user should be able to moutn it I think
<pitti> no, that should be an opt-in, not an opt-out
<pitti> and the 'user' flag is not relevant here anyway
<psusi> how isn't it?  it means that non admin users are allowed to mount/unmount it
<pitti> psusi: right, but this spec is entirely about providing access to devices for admins through the GUI :) (devices normal users don't have access to)
<psusi> pitti: right... but non admin users should also be able to mount partitions shown in fstab as user... and I think partitions not found in fstab at all.
<pitti> psusi: I agree to the first one; can you please file a bug about it?
<psusi> that's how pmount behaved before and I agreed with it
<pitti> (I'm not sure whether it works, didn't test it)
<pitti> pmount didn't mount fixed partitions which weren't in fstab
<psusi> ok.... I'll test it to make sure if it works or not first
<pitti> great, thanks
<psusi> yes, it did... it's just that g-v-m did not try to call pmount on fixed partitions
<pitti> noauto,user might already be handled by g-v-m
<psusi> pmount's rule was if it isn't in fstab, go ahead and let users mount it... that's what it was created for afaik
<pitti> psusi: it didn't; at least it's not supposed to, if that works on your hardware, I'll issue an USN for that :)
<pitti> psusi: ... *and* if the device is removable/hotpluggable
<psusi> hrm... I thought it was g-v-m that checked that?
<pitti> psusi: that would be pretty pointless
<psusi> I could have sworn I tried manually using pmount on disk partitions and it worked as a non admin if the partition was not in fstab
<pitti> since it wouldn't be a security policy any more
<pitti> psusi: if that worked, please file a critical bug and assign it to me
<psusi> the security policy is to honor fstab, but if there is no fstab entry, default to allowing non admins to mount it
<psusi> that is why pmount was created as I understand it
<pitti> psusi: no, pmount was created to mount removable devices
<pitti> I'm the original designer and sole upstream :)
<psusi> right, but that is just a specific case of "no fstab entry?  let user mount it"
<psusi> ahhh
<pitti> psusi: right, 'no fstab entry && removable'
<pitti> (&& a couple of other conditions)
<psusi> I see....
<pitti> hey sbalneav 
<psusi> so why treat non removable disks differently though I guess is my question?
<sbalneav> sorry, quick logout-n-in needed
<psusi> especially since the removable or not information is not 100% accurate ;)
<pitti> psusi: you can't trust removable hard disks anyway
<pitti> psusi: right, not 100%, but it errs on the side of caution
<pitti> psusi: but at least in certain environments people do trust their internal hard disks
<psusi> what harm could be done by allowing users to mount non removable disks?
<psusi> ( that don't have an fstab entry )
<pitti> psusi: modifying other OS installs, spying out passwords, breaking hibernation images from Windows, accessing other user's files, etc.
<psusi> pitti: isn't it the responsibility of the admin to set permissions within those filesystems, and fstab itself, appropriately?
<pitti> psusi: permisssions within that file system are fairly moot if you allow a user to access it...
<pitti> noone guarantees that uids match, let alone that the other fs even has uids
<pitti> psusi: oh, btw, reiserfsprogs uploaded
<psusi> pitti: true.. but that's why we have fstab; so the admin can set it to not be mounted... 
<psusi> cool
<psusi> one bug down... 9 million to go ;)
<pitti> psusi: so the admin can as well configure it to allow users to mount it (that's what you can do in theinstaller)
<psusi> true.... if it really is a permanent fixed disk....
<psusi> and one of these days I need to go through and slap around ext2/3/reiser/etc and make them respect the uid/gid/umask mount options
<psusi> at least I got udf to do so
<psusi> but reiser might make more sense on a large removable disk... but you probably don't want to rely on the ids on the filesystem as they may differ between multiple systems that you plug the disk into
<pitti> psusi: uid= makes sense for udf (but already supports it)
<pitti> psusi: I have my doubts for real unix file systems like extN and reiser
<cjwatson> ogra: 
<cjwatson>         Packages must not modify their own or other packages conffiles
<cjwatson>         programmatically.
<psusi> pitti: I had to patch it a few months ago because it would not honor uid= properly... it used it as a default if the id on disk was -1, but ignored it if there was a non -1 id on disk
<cjwatson> ogra: what in particular was vagrant referring to?
<cjwatson>         Packages must not modify other packages' configuration files
<cjwatson>         except by an agreed upon APIs (eg, a /usr/sbin/update-foo command).
<cjwatson> there's that
<cjwatson> agreeing an API would make sense, though, and shouldn't block your work?
<ogra> cjwatson, gimme a sec, i'll look it up in the archive
<cjwatson> it's just a little more effort
<psusi> pitti: the other filesystems shuold respect it as well since you can be mounting a filesystem that belongs to another instal or os with different uids
<psusi> pitti: or used on a shared removable disk ;)
<ogra> cjwatson, http://lists.alioth.debian.org/pipermail/pkg-ltsp-devel/2006-December/000537.html
<pitti> psusi: I have a bad feeling about that, though; if you don't want permissions on such devices, then use udf or vfat, not an unix fs
<pitti> otherwise the semantics of uid= would just be to turn ext2/reiserfs etc. into something like vfat
<cjwatson> mdz: in practice RMs decide what counts as a serious bug, which is pretty close to deciding on policy. It's a very old RM vs. policy maintainer dispute ...
<ogra> mdz, RM's apparently decide what NEW packages are allowed to get in right before the freeze
<ogra> and it seems vagrant was quite late with the request for ltspfs
<mdz> cjwatson: I think there's a clear line between interpreting policy and setting new policy
<psusi> pitti: vfat sucks though due to poor space use and such... and udf has shortcomings as well.... and that still doesn't accoun for the case of mounting a hard disk partition that belongs to another os
<Mithrandir> cjwatson: that bit also comes from policy, IIRC.
<mdz> this is clearly the latter, and it isn't done well
<Mithrandir> (the "not change other package's configuration files")
<cjwatson> actually, it seems pretty sensible to me
<cjwatson> "don't screw around with configuration files when you can't guarantee that their format won't change on you"
<mdz> cjwatson: that's not what it said
<mdz> it said "other packages' configuration files"
<mdz> and configuration files which aren't conffiles often don't have a clear owner
<cjwatson> mdz: also, it looks like an interpretation of policy 10.7.4 to me
<mdz> like /etc/modules
<cjwatson> "sharing configuration files"
<cjwatson> If it is desirable for two or more related packages to share a configuration
<ogra> well
<cjwatson> file and for all of the related packages to be able to modify that
<cjwatson> configuration file, then the following should be done:
<cjwatson> One of the related packages (the "owning" package) will manage the
<cjwatson> configuration file with maintainer scripts as described in the previous
<ogra>  /etc/modules isnt owned by *anything* 
<cjwatson> section.
<cjwatson> The owning package should also provide a program that the other packages may
<cjwatson> use to modify the configuration file.
<Mithrandir> ogra: it's probably owned by base-files?
<cjwatson> /etc/modules is a difficult case, but there are many easy cases where the above does make sense
<ogra> Mithrandir, so created == owned ?
<Mithrandir> ogra: not necessarily.
<ogra> right
<pitti> ogra: it's mainly a matter of defining an owned package; the package which exposes the interface gets to be the owner, I'd say
<psusi> pitti: also udf wasn't usable before my patch because pmount would give uid= and the user would create files, then when it was unmounted, the kernel actually wrote uid=0 to the disk... so when you remoutned it, the file that had been yours was now root's
<pitti> ogra: simple then: coreutils is the owner, and the interface is 'cat' :-P
<cjwatson> ogra: (in particular the installer creates certain configuration files, but can't own them)
<ogra> right
<cjwatson> I think it's OK for the API to be "it's a text file, one module per line, feel free to change it" as long as the owning package documents that
<ogra> i think /etc/modules is a very grey area here ...
<cjwatson> it's just that that's not OK for some files people like to modify ...
<ogra> right
<cjwatson> sshd_config is a nice case - the key names keep changing
<pitti> cjwatson: oh, that's certainly a conffile?
<pitti> oh, it's not
<cjwatson> nope
<cjwatson> its contents used to vary based on debconf questions - they don't any more, but it's too hard to retrofit conffile-ness
<pitti> cjwatson: if the key names keep changing, how do you manage upgrades? is upstream friendly enough to read older versions (and key names)?
<cjwatson> no, openssh-server.postinst gets to fiddle the file on upgrade
<cjwatson> s
<cjwatson> it's not a lot of fun
* pitti had some real fun getting upgrades right for postgresql.conf
<pitti> cjwatson: heh, same boat then
* pitti wrote lots of perl codes and test suite stuff to get that right
<cjwatson> I can patch in older key names, but I prefer not to do that indefinitely - easier to migrate
<pitti> right, so did I
* Keybuk is so patching gnome-typing-monitor to have a "Disable Breaks" checkbox in the menu
<ogra> ??
<ogra> why would you use gnome-typing-monitor then ?
<somerville32> Doesn't that defeat the purpose of the application? lol <g>
<Keybuk> I don't understand the question
<Keybuk> the application forces me to take hourly typing breaks
<Keybuk> there are occasions (such as team meetings) where that's not possible
<ogra> right, thast its purpose
<ogra> ah
<Keybuk> a checkbox to temporarily disable it during those times would be useful
<thom> Keybuk: just use workrave then?
<Keybuk> workrave is ... over the top
<Keybuk> I've never managed to configure it to not take up most of the panel; and just lock the screen once an hour
<seb128> BenC: any news on the directfb merge?
<BenC> seb128: With 2.6.20 finally uploaded, I'll be able to do some merges this next week
<ogra> does that mean the alternate installer will switch to directfb as debian did ?
<fabbione> BenC: i did look at it... it's a pain
<BenC> fabbione: Doesn't looking at it mean you accept responsibility for it? :)
<fabbione> BenC: forget it :) i was trying to merge it to satisfy a Depends and i had to tell myself: "Screw that.. i so much do NOT need this app"
<cjwatson> ogra: probably not
<seb128> BenC: ok
<ogra> ah, good
<BenC> hehe
<pitti> BenC: do you accept bribes for the apport stuff? such as me taking merges from you or so? :)
<cjwatson> ogra: I have absolutely no problem with the idea, but the execution of it isn't ready yet
<BenC> pitti: I'll have time after the meeting to discuss it if you want
<ogra> oh, i thought etch will ship with it
<pitti> BenC: would be great; although it's mainly a matter of finding time to implement it, unless I wrote something unclear into the spec
<ogra> (i'm fine with alternate as is ...)
<cjwatson> ogra: etch will, although optionally
<BenC> pitti: Ok, I'll refresh myself with the spec and go from there
<cjwatson> the newt installer ain't going away any time soon
<ogra> thats good
<pitti> ogra: is my grep-dctrl fu not strong enough, or do we really not have an inetd in main yet?
<ogra> netkit-inetd
<cjwatson> unfortunately we need a libd-i fix and ABI change to make it possible to start doing proper cdebconf plugins to improve the UI
<pitti> ah, right, that doesn't Provide:.*inetd of course
<pitti> ogra: can we drop netkit-base to universe then? IOW, adding openbsd-inetd should fully replace netkit-inetd?
<ogra> yeps it should
<ogra> debian made the transition some months ago
<pitti> yay
<pitti> well, it replaces another source and it has openbsd in the name, how much better can it get? :-P
<thom> um.
<pitti> hey thom, how are you?
<thom> hungover. office party last night ;-)
<thom> other than that, good. you?
<pitti> good as well, without the hungover :)
<somerville32> pitti: Just to be on the safe side, have you seen this bug?: https://launchpad.net/distros/ubuntu/+source/fai/+bug/75779
<Ubugtu> Malone bug 75779 in fai "fai-doc: Root password hash stored in log files." [Undecided,Unconfirmed]  
<pitti> somerville32: no, didn't see it so far
<somerville32> pitti: Should it be marked as a security vulnerability?
<pitti> somerville32: I don't understand the bug from the brief description yet, I'll write a followup question
<pitti> somerville32: not sure what fai-doc has to do with root password hashes
* somerville32 nods.
<ogra> it documentzs the password for later use :P
<cjwatson> rather reminiscent of the breezy installer vulnerability, that
<cjwatson> I'm perversely glad that somebody else's installer had the same kind of thing ;)
<ogra> :)
<pitti> somerville32: the password of the buildd root account?
<pitti> anyway, I'll look into it
<ogra> just call it a feature :) you will never lose your root pw with it :)
<somerville32> pitti: I didn't report it :P
<pitti> glad that it's universe, though
<pitti> spares us another brown-paperbag USN
<jdong> cjwatson: haha, is it healthy to take relief in others' security bugs? ;-)
<Mez> any idea why I get this: 
<Mez> checking whether the C++ compiler (gcc   ) works... no
<Mez> configure: error: installation or configuration problem: C++ compiler cannot create executables.
<pitti> jdong: shared blame is half the blame ;)
<pitti> Mez: did you try CXX=gcc?
<cjwatson> jdong: schadenfreude, baby
<ogra> Mez, get a sane compiler ? 
<pitti> Mez: gcc -> C, g++ -> C++
<pitti> cjwatson: wow, Schadenfreude is used in English?
<Mez> ogra: I'm using the ubuntu ones
<Mez> pitti: hmm - I'll have to hack on the damn code now
<ogra> pitti, did you know that doppelgaenger is used in english ?
<cjwatson> pitti: I'm not sure it's universally understood, but yes
<pitti> ogra: I knew that one from a Star Trek episode
<ogra> ah, i never watched them unduubbed
<ogra> -u
<Ng> we say kindergarten too, for pre-school. basically the english will steal anyone's words ;)
<ogra> and zeitgeist :)
* bhale imagines a german guy doing a voice over of Captain Picard
<bhale> thats funny
<somerville32> pitti: IF there is a bug report that says that a security update borked something, should I subscribe you?
<pitti> somerville32: absolutely
<thom> dubbing is utter crack :-)
<pitti> somerville32: and IRC-ping me, for the sake of prioritizing (my bug inbox is as big as a planet)
<ogra> thom, hey, all our actors live from it in germany 
<somerville32> Low priority: https://launchpad.net/distros/ubuntu/+source/dovecot/+bug/75785
<Ubugtu> Malone bug 75785 in dovecot "After security update (1.0.beta3-3ubuntu5.4), no service" [Undecided,Unconfirmed]  
<pitti> somerville32: hm, I was so proud of my thorough testing :/
<pitti> somerville32: will look, thnaks
<somerville32> k
<dade`> somehow in my ubuntu hald starts before acpi stuff
<dade`> starts before acpi modules are loaded
<dade`> this way acpi does not know about my battery
<jdong> doesn't the acpid init script modprobe all the acpi modules?
<dade`> it does, but does it after hald has beel started
<ogra> arent they loaded in initramfs already ?
<ogra> (just guessing)
<dade`> no
<dade`> hmm
<dade`> wait
<somerville32> Whats the name of that new program that automatically collects crash data?
<ogra> apport
<jdong> better known as "what's making my differential backups 3x larger"
<somerville32> ogra: I thought the name was something like a bomb or something, lol. Are you sure it is apport?
<ogra> pretty sure, yes
<pitti> yes, it is :)
* jdong kicks his 933MHz pity box
<somerville32> Does apport do the balloon notification or does it use the notification daemon?
<jdong> it does its own balloon to my knowledge
<pitti> somerville32: n-d does the bomb and notification
<jdong> it's a sad day when it's faster to compress something on that box by mounting sshfs over adhoc B wifi and having my other boxes do it
<pitti> somerville32: and n-d calls apport-gtk when you click onto the bomb
<somerville32> Is the bomb in the systray on in the balloon?
<somerville32> The systray
<somerville32> So what if the systray crashes?
<shawarma> somerville32: It'll show up some other time.
<jdong> LOL
<jdong> what if apport crashes? ;-)
<somerville32> jdong: Don't laugh :P I'm trying to figure where to reassign this bug report (Bug #62705) to :P
<Ubugtu> Malone bug 62705 in xubuntu-meta "[edgy xubuntu uptodate]  "report crash" balloon should be clickable" [Wishlist,Confirmed]  http://launchpad.net/bugs/62705
<pitti> jdong: the code jumps through some hoops to defend against that, but if the phython interpreter dies underneath apport, then things go bad, of course
<pitti> somerville32: erm, it is clickable... anyway, it's update-notifier
<somerville32> In Xubuntu though?
<pitti> no idea if they use u-n
<somerville32> We should get ubugtu to have someway to easily check to see if a package is in the seeds
<pitti> somerville32: apt-cache rdepends update-notifier|grep desktop
<pitti> somerville32: not in xubuntnu
<pitti> s/nu$/u/
<pitti> ogra: approved openbsd-inetd
<ogra> thanks !
<ogra> is there anything else in main depending on netkit-inetd ? 
<ogra> i'm fine caring for the transition if there is
<ogra> (actually i'd expect the debian transition to be fine though)
<pitti> ogra: can't see anything
<pitti> ogra: openbsd-inetd Provides:/Replaces: netkit-inetd
<ogra> great ... i'll monitor anastacia
<pitti> so it should Just Work (tm) with Dependencies
<ogra> yeah
<pitti> something needs to force the upgrade for users, though
<ogra> in case of ltsp its simply ltsp-server ... 
<pitti> so that they don't get into using an universe package after an upgrade
<ogra> i'll look around for other possible candidates
<pitti> ogra: I'm afraid we'll need a proper transitional package
<pitti> n-inetd has very few rdepends
<ogra> meh, ok, i'll do one ...
<pitti> unfortunately openbsd-inetd version < netkit-inetd version
<ogra> ah, k i didnt notice that 
<pitti> ogra: Debian has to cope with that as well, did they epoch o-i?
<ogra> (simply because i didnt look :) )
<ogra> not that i know of, we should have their latest package ...
<ogra> and ours has no epoch
<ogra> anyway, i need a break, back in 30
<pitti> mdz: FYI: https://blueprints.launchpad.net/distros/ubuntu/+spec/live-system-fs-mounting
<mdz> pitti: thanks
<pitti> ogra: if we don't care about netkit-inetd any more at all, we could just change the current package to become transitional
<pitti> ogra: although, no, that'd mean to keep it in main
* pitti -> dinner
<tkamppeter> There was a program to easily auto-generate patches, one started it, it opened a shell in which one did changes and after typing "exit" one got a patch, only I have no idea any more of the name of this program. can someone help me?
<bhale> tkamppeter: dpatch-edit-patch, cdbs-edit-patch
<tkamppeter> Thanks.
<jdong> wow, that's sweet
* jdong goes and tries them out
<jdong> to think I was using bzr for stuff like that...
<bhale> cdbs-edit-patch gives you a "plain" patch
<bhale> thank pitti 
<psusi> hrm... can't view the changelog of a package on launchpad eh?
<psusi> hrm... I bet you could rewrite those patch management tools to use a unionfs instead of copy/chroot/diff/delete... would probably be faster since you could avoid making all the copies
<pitti> jdong: https://wiki.ubuntu.com/MOTU/School/PatchingSources, FYI
<cjwatson> pitti: the Conflicts in the s-t-b change has the wrong version
<cjwatson> +Conflicts: liboobs-1-1 (<< 0.5), gnome-system-tools (<< 2.15.5-0ubuntu3~prop1)
<cjwatson> should be 0ubuntu5~prop1 in both places
<cjwatson> pitti: I'm rejecting s-t-b on that basis; please reupload once you've corrected that. The others look fine so far and I'm accepting them
<BenC> any archive folks alive?
<cjwatson> BenC: very briefly ...
<BenC> cjwatson: Nm, I forgot lowlatency went into universe and not main
<cjwatson> ok, I'm slightly bemused but no problem :)
* cjwatson -> pub
<pitti> cjwatson: done; thanks for catching
<pitti> cjwatson: I uploaded s-t-b before bumping the g-s-t version
<seb128> BenC: what information would be useful on a bug "network card stop working after a while with 2.6.19 and 2.6.20" out of syslog messages and lspci?
<siretart> mmmh. after upgrading to feisty, mdadm barks with 'mdadm: No devices listed in conf file were found'. Does anyone happen to know whats going on here?
<jpetso> hi all. i got a question with packaging. very basic, very newbie, i hope i don't offend anyone by asking such easy questions ;) anyways...
<jpetso> i'm maintaining the lila icon set, or at least the kde part of it, and somebody uploaded some control files to make a .deb package to http://revu.tauware.de/details.py?upid=3333
<jpetso> now... how can i rebuild this package on my own?
<jpetso> so that we can offer it through our website, and update it timely, and stuff
<keescook> hm... gdb has FTBFS on i386/amd64.
#ubuntu-devel 2006-12-15
<keescook> so, it looks like "tee" is getting stuck on the i386/amd64 builds of gdb.  very odd
<Riddell> jpetso: KDE questions often best in #kubuntu-devel (but I'm off to sleep
<jpetso> Riddell: well it's not a kde question, technically
<jpetso> Riddell: but thanks anyways, good night
<sistpoty> lamont: did you upload libnss-ldap (universe sru) yet?
<mjg59>  /win 10
<mjg59> Ng.
<cr3> what's the difference between daily and daily-live? the only difference I can see is that the former provides alternate and the latter provides desktop.
<jdub> cr3: yes, the desktop cd is the new live cd
<jdub> cr3: 'daily' vs. 'daily-live' is a historical thing
<cr3> jdub: is there any guarantee at which time the daily and daily-live directories on cdimage.ubuntu.com are updated? is that cronned at a particular time?
<jdub> cr3: they are but i forget when
<bhale> jdub: The Office is 1 hr
<lamont> sistpoty: dunno - probably not
<lamont> uploaded to sru, I thought
<lamont> or rather, proposed updates
<fabbione> morning
<jdong> what is a SIGABRT in the context of Openoffice?
<jdong> the latest 0day word exploit causes a SIGABRT in openoffice
<jdong> (on Edgy)
<jdong> (haven't tried anything else)
<jdong> http://www.milw0rm.com/sploits/12122006-djtest.doc   <-- POC
<jdong> OOo dies with a stack trace
<jdong> Fatal exception: Signal 6
<PuMpErNiCkEl> http://en.wikipedia.org/wiki/SIGABRT
<jdong> PuMpErNiCkEl: I know that much
<jdong> I was wondering what it means in terms of OpenOffice in this specific exploit
<dieman_> jdong: nice.
<jdong> more importantly, if OOo is open to a similar exploit as MS Office
<jdong> some people on other distros report a segmentation fault
<jdong> which raises a big red flag in my  mind
<dieman_> i'd collect debug information and open a bug
<jdong> dieman_: ok, will do
<keescook> jdong: it's either OOo calling abort() or glibc calling it as a result of heap corruption.
<jdong> keescook: yikes... so it shouldn't be exploitable then on Edgy?
<jdong> or is it still up in the air?
<jdong> keescook: is it worth me filing a bug on it then?
<keescook> I haven't had the time to study it, but the "exploits" floaitng around won't work on linux.
<keescook> jdong: best to get a backtrace, actually.
<jdong> keescook: openoffice did print something at the console that starts with this
<jdong> Stack:
<jdong> /usr/lib/openoffice/program/libuno_sal.so.3[0x4387d4fb] 
<jdong> /usr/lib/openoffice/program/libuno_sal.so.3[0x4387d631] 
<jdong> is that good enough as a backtrace
<jdong> or is there some other procedure I should follow?
<keescook> nah, I'd like to get one out of apport.
<keescook> do you have gdb installed?
<jdong> (it didn't trigger apport)
<jdong> I do have gdb
<keescook> apport ignores abort.  okay, edit /usr/share/apport/apport
<keescook>     if signum == str(signal.SIGQUIT) or signum == str(signal.SIGABRT):
<keescook>         sys.exit(0)
<keescook> drop the "or signum == str(signal.SIGABRT)" part, and try crashing OOo again
<jdong> that's simple enough :)
<jdong> keescook: it still doesn't trigger apport
<jdong> :-/
<jdong> ah, oowriter is a shell script
* jdong chases down binary
<jdong> yes!
<jdong> I think I triggered apport
<jdong> the disk grinding is all too familiar
<jdong> yep
<jdong> sheesh it's 5MB :)
<keescook> jdong: cool.  can you open a bug and attach the crash?  I think it's heap allocation or something.  ooffice just ate my machine alive trying to open that file.  :P
<jdong> keescook: bug is 75847, apport blob is uploading
<jdong> keescook: bug  75847, apport blob is uploading
<keescook> cool, thanks
<jdong> ahem, bug 75847
<Ubugtu> Malone bug 75847 in openoffice.org "OOo crashes when opening MS Word Exploit POC" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75847
<jdong> ha the bot doesn't like double-space
<somerville32> lol
<jdong> keescook: while we're waiting I linked to a /. discussion on this that a google turned up
<jdong> keescook: oh look at that, it uploaded :)
<keescook> cool, thanks.
<jdong> (by the way jeez Firefox traces are gigantic)
<jdong> that really does explain half my incremental dumps :D
<keescook> btw: you may want to put that SIGABRT thing back into apport... there are lot of things that barf that don't produce useful traces on an abort.  :)
<jdong> lol yeah
* jdong reinstalls apport
<keescook>  #2  0x420cfef3 in abort () from /lib/tls/i686/cmov/libc.so.6
<keescook>  #3  0x4387d636 in osl_raiseSignal ()
<keescook>     from /usr/lib/openoffice/program/libuno_sal.so.3
<keescook> so it looks like an OOo lib raised the abort, so that just means it's a bug in OOo, as far as how it handles reading the file.
<keescook> (so, not a security vuln)
<jdong> keescook: that's good to know
<jdong> keescook: what about the /. folk who reported segfault
<keescook> that's slightly more interesting, but plenty of stuff that segfaults isn't a security problem.  :)
<jdong> :)
<jdong> either way, it still (1) worries me
<jdong> (2) is a problem that OOo doesn't gracefully handle the error
<jdong> it still makes this word exploit at minimum a denial-of-service to OOo
<jdong> I'm sure upstream has heard about this by now :D
<keescook> well, i386 just crashes.  amd64 it eats all available memory.  :P  We need to invesgitate some kind of popup that SIGSTOPs massive hogs and pops up "process Blah is eating your system for lunch.  Kill it?  [ Ok ]  [ I like trashing ] "
<keescook> okay, dinner time.  cya
<jdong> enjoy, keescook
<Chipzz> keescook: that would stop my firefox every time I start it :P
<pitti> Good morning
<Hobbsee> pitti
<Hobbsee> !!!
* pitti hugs Hobbsee 
* Hobbsee hugs pitti 
<AnAnt> hello
<AnAnt> I think there is a problem with libc6-dev
<AnAnt> in libieee.a
<AnAnt> I got a program linking against it
<AnAnt> and it gave this error:
<AnAnt> /usr/lib/libieee.a:(.data+0x0): multiple definition of `_LIB_VERSION'
<AnAnt> /usr/lib/libieee.a:(.data+0x0): first defined here
<mdke> AnAnt: this isn't a support channel. You can file bugs in the bugtracker at bugs.ubuntu.com
<Hobbsee> AnAnt: filed a bug?
<keescook> late night hackin'
<keescook> pitti: so there relro won't go in like ssp did, eh?
<pitti> hey keescook 
* Hobbsee waves to keescook 
<keescook> hiya pitti, Hobbsee :)
<pitti> keescook: well, we might be able to sneak relro into gcc, if it's really that unintrusive as it sounds
<pitti> keescook: but PIE? we shouldn't do that...
<keescook> PIE, no way.
<mdke> mmm, pie
<keescook> I want to test it with stuff in feisty first.
* keescook likes PIE
<keescook> relro is hardly anything at all.
<keescook> I looked at the patch to enable ssp.  kinda scary
<pitti> keescook: for that, using a ~/bin/gcc wrapper should work
<keescook> what's the reason for not doing it the way ssp was done?
<pitti> keescook: ccache manages to divert cc/gcc/etc. quite well, too
<pitti> keescook: mainly because it alters the default gcc behaviour which might lead to unexpected things when building upstream software
<pitti> keescook: for the short term I'd prefer a gcc wrapper while we discuss this with Debian
<pitti> keescook: after all, we had a package 'gcc-opt' on the buildds for a loong time
<keescook> okay, cool.
<pitti> keescook: and got rid of it about the time when we started discussing SSP :/
<keescook> heh
<pitti> keescook: how's 2.6.20 wrt. ASLR? does PIE do any good there to enable more juggling?
<keescook> can you or doko mock something up so I can see how that would look?
<keescook> I haven't tried 2.6.20 yet; i've been dog-fooding compiz, so unwinding stuff without lrm wasn't something I wanted to jump on.  :P
<pitti> keescook: a ~/bin/gcc with '#!/bin/sh\nexec $0 -fPIE "$@", something like that
<keescook> oh, seriously that simple of a wrapper?
<pitti> keescook: for testing, why not
<pitti> keescook: ccache does it much the same way
<keescook> fair enough.
<keescook> I'd be stuffing it into my build schroot's
<pitti> keescook: a gcc wrapper could look much like the ccache package
<keescook> relro> -Wl,-z,relro
<keescook> PIE> -fPIE -pie
<pitti> the effect would be much like the global build flags, but a centralized change, so the only drawback is that you don't see it in build logs
<AnAnt> Hobbsee: nope
<keescook> I'll add logic to notice -norelro, etc.
<pitti> keescook: for proper operation, we would need to change dpkg-buildpackage to add the wrapper gcc's to $PATH, of course, but for initial testing, a hack should suffice
<keescook> sure.  I was thinking I could model the expected "real" correction instead of just hacking it.  :)
<keescook> so, for ASLR, I swear we saw heap randomization while at UDS, but I don't see it on feisty now.
<keescook> exec randomization is for sure not happening.
<pitti> keescook: I envision a package ubuntu-gcc-wrapper with wrappers in /usr/share/ubuntu-gcc/ and a diversion of dpkg-buildpackage which mangles $PATH
<keescook> ah, very good.
<pitti> well, crackful, but effective
<keescook> Program Headers: Type           Offset             VirtAddr           PhysAddr
<keescook> hm
<keescook> Program Headers:
<keescook>   Type           Offset             VirtAddr           PhysAddr
<keescook>   LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
* keescook rubs his hands together gleefully
<pitti> keescook: ah, that's from relro? 0 == arbitrary random location?
<keescook> 555555554000-555555555000 r-xp 00000000 fd:00 1412097                    /scratch/ubuntu/build/local/pie
<keescook> nah, that's PIE.
<pitti> ah
<keescook> relro is just an extra header with a few sections:
<keescook>   GNU_RELRO      0x0000000000000de8 0x0000000000200de8 0x0000000000200de8
<keescook>                  0x0000000000000218 0x0000000000000218  R      1
<keescook>    08     .ctors .dtors .jcr .dynamic .got 
<pitti> keescook: while at it, that dpkg-buildpackage wrapper should make any build fail which has ELFs with pages that are w and x :-P
* pitti changes from crack mode to sanity again
<keescook> Oooh!  Great idea!
<keescook> that will break all KINDS of things, though.  :P
<keescook> there are tons of packages that still have exec stack due to asm code.
<keescook> :)
<keescook> er
<keescook> :(
<keescook> gdb ftbfs> did you see that insanity?  tee isn't quitting.
<keescook> should I upload gdb with the PIE patches even though the builds are busted?
<keescook> it seems to work fine, and (at least) fedora has been running with it for a while now, so it's reasonably stable.
<keescook> I've started trying to get it merged upstream, we'll see how that goes.
<pitti> keescook: hm, I saw the FTFBS logs from my upload from yesterday
<pitti> keescook: but it looked like it failed due to unexpectedly failed tests
<pitti> keescook: was a bit strange, it built fine for me
<pitti> locally
<pitti> keescook: I suspect different kernels (I built under .20 AFAIR, buildds are probably edgy)
<keescook> from what I see, the make check runs and finishes.  but the pipe open to "tee" stays.  tee is blocked on read(stdin...) and the shell is blocked on a wait() for tee.  bizarre
<pitti> oh, ugh
<keescook> hm, I'm still on 2.6.19-7
<keescook> but I saw exactly the same behavior as the buildds (on both amd64 and the i386 chroot)
<keescook> anyway, should I up the PIE patch anyway, and the build failures can be sorted out as we go?
<pitti> keescook: it would only make sense if the package actually builds again
<pitti> and we need a built gdb, the current one is totally broken
<pitti> keescook: so feel free to throw in the PIE patch if you have a workaround/solution for the hang
<keescook> I don't have anything yet.  :(
<pitti> keescook: oh, right
<pitti> the previous package even had *more* unexpected failures than my upload
<pitti> and it still finished building
<keescook> heh
<pitti> so it's not that
<pitti> keescook: maybe:
<pitti>  $(MAKE) -C objdir/gdb check > objdir/check.log 2>&1
<pitti>   cat objdir/check.log
<keescook> yeah, the gnu.hash fixes the tests quite a bit.  (without your changes, the tests just grind away forever, slowly timing out)
<pitti> keescook: if you can reproduce the hang, does that work for you?
<pitti> keescook: right, I tried the previous package on current edgy, all tests fail
<keescook> I can try that; I guess we don't need tee for automated builds.  :)
<pitti> still strange...
<pitti> as if make wouldn't close stdin or stderr...
<Yagisan> it just doesn't like you pitti 
<pitti> hi Yagisan 
<Yagisan> long time no see
<Yagisan> How are you mate ?
<pitti> I'm great, and you?
<Yagisan> going ok
<pitti> keescook: right, buildds won't care, but it would suck for local builds of course
<Yagisan> overloaded myself time-wise
<keescook> If this actually works, I could just fake a tee:  touch log; tail -f log &; pid=$1; make check >> log 2>&1; kill $pid   :P
<pitti> keescook: are you sure that & DTRT in scripts?
<pitti> last time I tried something like that it blew up on my face
<keescook> If you do it all on the same "line", I think it's safe.  I'll try it if this build is okay
<pitti> keescook: did you happen to strace the make process when it hanged?
<pitti> is it just select()ing? (i. e. poll())
<keescook> the rules make?  I didn't.  the make check had already quit, though.
<keescook> I'm wondering if it's a dash vs bash thing.
<pitti> oh, good point
<keescook> I couldn't reproduce it using simple cases, either.
<keescook> pitti: yup, dropping tee fixes the build.  :(
<pitti> keescook: weird, weird, weird
<pitti> Mithrandir: btw, your give-back of gnome-panel in edgy-proposed didn't work
<pitti> Mithrandir: but now the apt error message mentions different packages, so it did *something* :/
<Mithrandir> pitti: I saw it; Adam's fixing it now.
<pitti> ah, great
* pitti hugs infinity and Mithrandir 
<keescook> pitti: okay, off it goes, gdb_6.5.dfsg-2ubuntu3 has been uploaded with PIE and the tee-- fix.  I'm off to bed.
<pitti> \o/
* pitti hugs keescook 
<slomo> keescook: congrats :)
<pitti> hey seb128 
<seb128> hi pitti!
<cjwatson> morning
<pitti> hi cjwatson 
<pitti> cjwatson: I uploaded a new s-t-b with the fixed conflicts yesterday
<cjwatson> judging from shell history, I noticed that last night before I went to bed but then collapsed before remembering to process it
<cjwatson> I'll do that now
<pitti> great
<cjwatson> pitti: could you attach the most recent s-t-b patch to the bug for completeness, please?
<pitti> oh, sure, doing now
<cjwatson> pitti: all done, please proceed to testing
<pitti> great
<stub> Launchpad will be going down in 15 minutes for a code update. Estimated downtime is 10 mins.
<MidMark> hi I've a question: is there a motivation because a very stupid bug that annoy ALL people that uses amule, and that has a patch based in ONE line took 3 months (and still not fixed) to be committed in wxwidgets?
<MidMark> where is the maitainer??
<dholbach> good morning
<MidMark> https://launchpad.net/distros/ubuntu/+source/amule/+bug/59138
<Keybuk> MidMark: Ubuntu doesn't have maintainers (at least, not in the Debian sense).  amule is in universe, so you'd be best off asking on #ubuntu-motu
<Ubugtu> Malone bug 59138 in wxwidgets "amule crashes when I close a tab" [Unknown,Unknown]  
<MidMark> oook will do now
<dholbach> ?
<dholbach> sorry
<jsgotangco> ah
<mneptok> belligerent ghouls run Manchester schools. spineless bastards all.
* dholbach hugs mneptok ecstatically
<seb128> mjg59: around?
<pitti> carlos: I'm curious, how did your attempt for feisty langpacks work out?
<carlos> pitti: waiting for kiko
<pitti> ooh, new LP with icon and task tree shinyness
<pitti> carlos: what do I have to do to clean up https://translations.launchpad.net/distros/ubuntu/edgy/+source/tsclient/+pots/tsclient/ru/+translate ?
<carlos> pitti: nothing, I'm able to do it today
<carlos> pitti: I had a problem with permissions
<carlos> but today it was fixed
<pitti> ah, cool
* pitti hugs carlos
<maswan> BenC: hey, any chance of a CONFIG_DEBUG_INFO in the near future for -dbg- stuff (aka make systemtap work, AIUI)
<CypherBIOS> mvo: ping
<Hobbsee> mvo: just merged apt-watch, hope that's OK.
<gnomefreak> Hobbsee: apt-index-watcher?
<Hobbsee> gnomefreak: er, yeah
<Hobbsee> the one that's in universe
<gnomefreak> thats not in universe 
<gnomefreak> phew
<CypherBIOS> mvo: when you come back, see this http://en.cypherbios.org/archives/4
<seb128> mjg59: http://people.ubuntu.com/~seb128/compiz-update/, I've updated to the new version, switched to cdbs and moved changes to debian/patches too. If you want to have a look and let me know if you have some objection, I'll wait for your comments before uploading. What is the rational to use indirectRendering by default BTW?
<gnomefreak> is beryl-core still FTB?
<seb128> gnomefreak: hint: you want to use compiz ;)
<gnomefreak> oh no :(
<seb128> why no?
<gnomefreak> seb128: last time i used compiz was during dapper devel and it was crap. i hope it has gotten better
<seb128> gnomefreak: good reason to try it again
<seb128> gnomefreak: http://people.ubuntu.com/~seb128/compiz-update/, I've started working on updating it to the new version if you want to try
<gnomefreak> ok cool i will ty
<gnomefreak> should i still grab the desktop-effects package?
* Hobbsee wonders how it works with kde
<seb128> gnomefreak: yep, that's an easy way to enable it and revert if it doesn't work fine (just use esc key or wait)
<gnomefreak> ok ty
<seb128> np
<gnomefreak> seb128: the package cgwd shouldnt be a recommend since there is no package
<gnomefreak> seb128: for the desktop-effects package ;)
<seb128> gnomefreak: 
<seb128> $ apt-cache show desktop-effects | grep Recommends
<seb128> $
<seb128> for compiz you mean
<seb128> right :)
<gnomefreak> yeah sorry
<gnomefreak> i was installing the -effects package and it depends on compiz and the recommends shows up i forgot compiz was gonna be installed
* gnomefreak missed a deb :(
<Mithrandir> dholbach: do you understand why my networkmanager build doesn't seem to update the gtk icon cache on installation?
<ogra> again ?
<Mithrandir> (it uses cdbs, so I though it was supposed to call dh_iconcache and get that thing fixed automatically)
<Hobbsee> Mithrandir: because it needs to call dh_iconcache.  i'll bet it's a custom cdbs.mk
<ogra> seems we have that every beginning of a new release 
<Mithrandir> ogra: you're not helping.
<Mithrandir> Hobbsee: nope
<Hobbsee> ogra: i saw that bug in edgy, but didnt fix it, as i'd need a sponsor
* Hobbsee looks
<Mithrandir> ah, it's only called if you add the gnome package too
<Mithrandir> as in, gnome.mk
<dholbach> ah! :-)
* dholbach hugs Mithrandir
<Hobbsee> Mithrandir: gnome.mk isnt included in it
<Mithrandir> Hobbsee: see four-five lines up. :-P
<Hobbsee> Mithrandir: i meant at pre-install time
* Hobbsee wonders if that's the correct syntax
<Mithrandir> I think I got it now.
<Hobbsee> cool
<seb128> is anybody working on the xorg-server merge with Debian?
<Hobbsee> seb128: shouldnt you be asking that in #ubuntu-x or something?
<seb128> Hobbsee: well, I expect that most of people are on -devel too
<Hobbsee> ah
<Hobbsee> true that
<seb128> Hobbsee: and believe it if you want some non-xorg people are doing merges for xorg packages too :p
<zul> morning
<pitti> seb128: geser :)
<pitti> hi zul
<gnomefreak> morning zul 
<seb128> hi pitti
<Hobbsee> seb128: that's scary.  i've not attempted that
<seb128> Hobbsee: the xorg-server one is assigned to me according to the merge list because I touched it to fix a bug before edgy :p
<geser> pitti: I only merged the xserver-xorg-input-* from universe
<pitti> geser: oh, I thought I saw more from you
<gnomefreak> seb128: is there a theme package? i hate this boarderless windows. it happens on beryl also changing theme normally works
<seb128> gnomefreak: compiz should respect the metacity theme no?
<Hobbsee> seb128: heh.  poor bugger.
<gnomefreak> its not i have no boarders
<geser> pitti: no, only xserver-xorg-input-* and xserver-xorg-video-i810-modesetting
<pitti> gnomefreak: bug 73544
<Ubugtu> Malone bug 73544 in desktop-effects "enabled desktop effects window decoration" [Undecided,Confirmed]  http://launchpad.net/bugs/73544
<gnomefreak> and window is stuck in upper left hand cornber
<gnomefreak> pitti: ty
<pitti> gnomefreak: Option "AddARGBGLXVisuals" "True"
<gnomefreak> it is
<gnomefreak> ff has boarder
<gnomefreak> terminal doesnt :(
<pitti> gnomefreak: right, current compiz' idea of workspaces is, erm, totally broken
<gnomefreak> brb let me see what i can do
<seb128> pitti: hum?
<seb128> pitti: how so?
<pitti> seb128: bug 75597
<Ubugtu> Malone bug 75597 in compiz "workspace handling totally broken" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75597
<seb128> the workspace switcher applet is working fine for me with 0.3.4
<seb128> pitti: 
<seb128> <seb128> http://people.ubuntu.com/~seb128/compiz-update/ is anybody wants to try compiz 0.3.4
<seb128>  it understands workspaces now
<pitti> oh I might have filed a dup of bug 74767 with that
<Ubugtu> Malone bug 74767 in compiz "Use workspaces instead of viewports by default" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74767
<seb128> pitti: from #ubuntu-desktop 1h30 ago :p
<pitti> seb128: ah, was away at that time :)
<seb128> pitti: I would appreciate if you can give it a try
<pitti> seb128: does it also solve the horribly slow window resizing?
<pitti> seb128: right, will do
<seb128> well
<seb128> I think that's because the package is patched to use indirectRendering by default
<seb128> I've pinged mjg59 about that, I'm waiting for a reply
<seb128> you can maybe try compiz --direct-rendering --replace
<seb128> I get a white screen when doing that
<seb128> cube rotation works though
<seb128> all the face are all white though :/
<seb128> I had to run metacity --replace to get my screen back :p
<pitti> hm
<cypher1> is anyone part of upstart-devel ML ?
<seb128> pitti: BTW https://launchpad.net/distros/ubuntu/+source/compiz/+bug/58373
<Ubugtu> Malone bug 58373 in xorg-server "Blue compiz for PowerPC" [Unknown,In progress]  
<pitti> seb128: it's just that with normal metacity it's smooth and slick
<gnomefreak> i added the boolean option and it worked
<seb128> pitti: your blue screen on ppc is xorg-server bog
<pitti> oh, that too
<seb128> gnomefreak: which one?
<seb128> pitti: that's why I'm asking about the sync, it's fixed to Debian, and I'm pondering just patching for that or doing the sync
<gnomefreak> Option          "AddARGBGLXVisuals"    "true" Option          "AddARGBGLXVisuals"    "boolean"
<gnomefreak> both of those are needed
<seb128> ok
<seb128> what videodriver do you use?
<gnomefreak> atleast on my nvidia 5200
<gnomefreak> :)
<gnomefreak> nvidia 9xxx
<gnomefreak> oh wait crap
<cypher1> by any chance, is anyone using ATI Rage 128 with direct rendering on ?
<gnomefreak> ok yep still working good :) i forgot to enable compiz :(
<cjwatson> seb128: I don't know for sure, but from the way that rodarvus hasn't done any uploads to feisty, I'm guessing that other people need to step in
<seb128> cjwatson: ok, what I thought, I figured I would ask first
<cjwatson> I'll mail him and ask
<seb128> I'll upload that on monday if I get no reply before
<seb128> I don't want to upload some xorg package on friday
<gnomefreak> seb128: no it doesnt fix it
<cjwatson> seb128: sensible
<seb128> gnomefreak: "fix" what?
<gnomefreak> seb128: the boarderless windows
<seb128> gnomefreak: what plugins do you have to /apps/compiz/general/allscreens/options/active_plugins ?
<seb128> you need "decoration"
<gnomefreak> hmmmmm
<pitti> seb128: compiz amd64 debs in chinstrap:~pitti if you want to copy them to your people dir
<gnomefreak> seb128: how do i open the plugins package?
<gnomefreak> there is no menu
<seb128> gnomefreak: "unset" the gconf key from gconf-editor to get the default list
<seb128> gnomefreak: that's a gconf key
<seb128> pitti: danke
<pitti> seb128: de rien :)
<gnomefreak> i see it now i thought compiz removbed gconfig awhile ago
<seb128> gnomefreak: user config stays to gconf
<seb128> nothing clean your user data
<gnomefreak> decoration is there
<seb128> gnomefreak: what about /apps/compiz/plugins/decoration/allscreens/options/command ?
<gnomefreak> gtk-window-decorator
<seb128> pitti: copied
<seb128> gnomefreak: weird, is gtk-window-decorator running?
<gnomefreak> yep its in ps aux
<seb128> so I don't know
<pitti> brb, restarting X with new nvidia option
<Treenaks> is the decorator plugin loaded?
<seb128> I've the same theme as with metacity
<seb128> Treenaks: <gnomefreak> decoration is there
<gnomefreak> Treenaks: i would assume since its in ps aux
<seb128> gnomefreak: are you sure than the window is not simply under the top panel? Does alt + click for move it work?
<gnomefreak> ah
<gnomefreak> ummmm shouldnt the panels respect the windows?
<gnomefreak> seb128: and moving it worked 
<cjwatson> seb128: if you have xorg-server at all ready, please take it
<cjwatson> seb128: it might need some library merges first, though
<pitti> seb128: ok, tested; window resizing is fine now, but workspaces are as broken as before
<seb128> cjwatson: no, I've not started on it yet, but since it's on my list and I want some fixes from Debian I was going to start on it if nobody else already started
<seb128> pitti: you get one workspace only on the workspace switcher?
<pitti> seb128: well, there still seem to be two different concepts around
<pitti> one is the cube workspace, and the other the workspace switcher workspace
<seb128> pitti: desktop-effect has a box to map workspace on cube faces
<pitti> and on top of that, the switcher only shows windows at the current space, not from the others any more
<seb128> but right, it's still optimal
<seb128> *not* optimal
* Mithrandir blinks.
<pitti> seb128: oh, that option; I thought it was 'show cube effects', not 'break my workspaces'
<Mithrandir> pitti: your avahi patch applied without fuzz or rejects.
<Mithrandir> (to nm)
<pitti> Mithrandir: \o/
<pitti> seb128: ouch, when I disable that option it gets worse -- now I'm totally confused
<seb128> pitti: still some way to go, I think I'll have a look to those libwnck patches too
<seb128> pitti: it's still early, let's give it a try next year when new versions and patches will have landed ;)
<Zdra> dholbach: hi ! do you know if there is a package repos with backport of telepathy stuff for edgy ?
<pitti> seb128: right
<pitti> seb128: so the idea is *not* to put that into feisty by default?
<seb128> pitti: well, that's either that or beryl as I understand it
<pitti> urgh
<seb128> pitti: so the idea is that I'll spend some time from now to get *that* on shape :p
<seb128> from now being next week
<seb128> landing new version and the wnck patches going with it maybe
<seb128> and some configurator tools available on revu
<gnomefreak> is there an easy way to enable all plugins?
<apokryphos> gnomefreak: on the command-line. compiz --replace gconf decoration.......
<gnomefreak> and list the plugins?
<apokryphos> yeah
<cjwatson> Keybuk: <request type="implausible">It'd be lovely to have merges.ubuntu.com topologically sorted in build-dependency order</request>
<apokryphos> gnomefreak: i.e. compiz --replace gconf decoration wobbly fade minimize cube rotate zoom scale move resize place menu switcher water &
<gnomefreak> ah ty i got my rain back :)
<Hobbsee> cjwatson: in build-dep order?
<rodarvus> cjwatson: I'm doing X.Org merges now. I had to start very late (due to personal problems), but I expect to have them completed this weekend
<pitti> seb128: argh, the keyboard indicator applet suddenly grew to a hundred pixels or so :/
<pitti> seb128: I switched to the German keyboard layout for a minute, and then it suddenly displayed 'de nodeadkeys' instead of 'DE'; and now it doesn't shrink any more (even though it just displays 'us')
<seb128> pitti: nice bug
<pitti> will file later
<cjwatson> rodarvus: hmm, OK, that would be great. Can you keep me informed?
<seb128> rodarvus: ah, nice, so xorg-server is on your list too? ;)
<cjwatson> rodarvus: I expect quite a few syncs in the list, based on our experiences last time round; let me know if you need to coordinate with the archive team
<Hobbsee> seb128: *grin*.  you're just trying to avoid it
<seb128> Hobbsee: like you would not? :p
<Hobbsee> seb128: i'm not crazy enough to touch it in the first place, just so that i wouldnt have to merge it :P
<Mithrandir> Hobbsee: you can merge it anyway! :-)
<StevenK> Surely a non core-dev doing main merges is a little pointless?
<rodarvus> cjwatson: sure, I will
<rodarvus> seb128: yes
<seb128> cool
<seb128> I'm away for ~45min, bbl
<rodarvus> cjwatson: this time I'm doing the packaging locally, so it will be a long queue of uploads in one time, instead of a longish upload, taking a few days
<rodarvus> so the uplods are (hopefully) less disruptive
<cjwatson> rodarvus: you don't expect it to matter whether uploads are built against old or new libraries, then?
<seb128> most of those uploads should not break anything
<cjwatson> we were probably overly conservative last time, I agree
<Hobbsee> Mithrandir: i'm not insane :P
<Hobbsee> Mithrandir: besides, i'd need a sponsor.
<Hobbsee> StevenK: depends how good that person is at gettign people to do what they want
<Mithrandir> Hobbsee: you're here, so the former is clearly not true. :-)
<Hobbsee> Mithrandir: hehe, good point. 
<Hobbsee> Mithrandir: i'm just in here as part of my master plan to take over the world.
<rodarvus> cjwatson: no, this is not what I said. I *will* wait for new binaries to be published when/if needed. (or Build-Depends on the new version, if necessary).
<rodarvus> what I'm doing differently is that I will proceed with all uploads/sync requests when I have it all updated, instead of doing small bits of the upload every day
<rodarvus> I believe this tends to be less disruptive to the quality of the archive, as the transition time will be smaller
<cjwatson> rodarvus: oh, I see
<cjwatson> rodarvus: hmm, the only problem is that it's harder for the rest of the team to tell how much has been done in the event that they're waiting for something, and you have a higher risk of conflicts
<cjwatson> rodarvus: but if you've already started down this path and you'll be done by the end of the weekend, then yoou might as well continue now
<cjwatson> youo
<cjwatson> damnit. "you"
<elmo> english is hard
<cjwatson> keyboards are hard
<cjwatson> speaking of merges, I'm still on top of pam, but just asking vorlon about a couple of weird-looking bits in the Debian patch
<ailean> pitti, thanks for fixing the scots bug
<matthewrevell> heno: Howdy - did you get any feedback from the rest of the team for Fix-it Friday?
<heno> matthewrevell: generally positive, I'll speak with simon today and draw up some ideas
<heno> matthewrevell: do you want to have a talk as well about it?
<dholbach> Zdra: no, there's not
<matthewrevell> heno: I'd be happy to. My main involvement is to report what's been fixed, at the moment. Once it's happened a few times, I'll let people know it's happening a little more.
<matthewrevell> heno: Let me know when and where  and I should be there.
<heno> matthewrevell: ok, cool. I've forwarded you a mail I sent to the team yesterday
<matthewrevell> heno: Thanks.
<heno> dholbach: thanks for making the bughelper code look sane :)  I've pushed up your changes
<dholbach> heno: rock and roll :-)
<dholbach> heno: I thought about adding the feature to handle queries with more than 75 bugs next
<heno> and peaking into attachments
<dholbach> right
<dholbach> 10MB crash files - yay! :-)
<bddebian> Heya
<heno> :) the LP guys and server admins will love us
<heno> then post it on the fridge :)
<Keybuk> cjwatson: <response type="glib">I'll get one of my people on it, right away</response>
<bddebian> heh
<pitti> ailean: you're welcome
<pitti> Keybuk: 'glib'?
<bddebian> flippant?
<pitti> oh, nothing to do with libglib, sorry :)
<Keybuk> pitti: polite, and positive, but with no intention of going through with it
<Mithrandir> there, new network-manager uploaded.  
<Mithrandir> it might work.
<Mithrandir> ;-)
<bhale> Mithrandir: woo!
<bddebian> "If it compiles it works" right? :)
<pitti> bddebian: right, everything else is a gcc bug, and thus doko's
<Mithrandir> bddebian: hey, it even installed on _two_ machines here.  It's clearly ready for release.
<bddebian> hehe
<giskard> Mithrandir, 0.6.4?
<cjwatson> Keybuk: heh
<Mithrandir> giskard: yeah, based on your merge; thanks.
<Keybuk> Mithrandir: the fact that neither machine can now access the network is just a minor detail?
<Mithrandir> Keybuk: yeah.
<Keybuk> after all, the work being done and uploaded is good enough for Feature Freeze
<Keybuk> the fact it doesn't work is just a bug, and can be done after
<Keybuk> ? :)
<Mithrandir> Keybuk: actually, this machine is really good, since it manages to talk to my IRC client without networking!
* pitti stops hacking to learn from Keybuk's QA skillz
<mjg59> seb128: Indirectrendering needs to be default for aiglx
<giskard> Mithrandir, rejected :(
<bddebian> doh
<Mithrandir> giskard: meh, I suck.
<Mithrandir> there, reuploaded
<mjg59> seb128: Otherwise, looks good
<seb128> mjg59: nothing against the switch to cdbs? Should I upload the update then?
<mjg59> seb128: Well, I hate cdbs with a passion, but I seem to be in a minority so feel free :)
<seb128> mjg59: ok, let's keep it to be coherent with the other desktop packages then ;) thank you
<ogra> mjg59, you are not in a minority ... :)
<seb128> ogra: you don't make a majority :p
<Keybuk> CDBS Must Die.
<ogra> mjg59, i'll check the CVS for g-p-m over the weekend, if that isnt sufficient, i'll disable pieces in the existing glade file
<ogra> seb128, i didnt say that :P
<giskard> ogra, why you want do this?
<ogra> giskard, did you try the new UI ?
<ogra> its horrible ... 
<giskard> no :( 
* pitti uploads a new libgphoto2 that unbreaks the world
<giskard> did you already talked with hughsie?
<ogra> giskard, apart from that i have bug 75811, bug 75804 and bug 75803 since the upload
<Ubugtu> Malone bug 75811 in gnome-power-manager "gnome-power-manager UI has become unnecessarily complicated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75811
<Ubugtu> Malone bug 75804 in gnome-power-manager "performance setting missing" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75804
<Ubugtu> Malone bug 75803 in gnome-power-manager "non privilege user can change cpu speed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75803
<ogra> giskard, mjg59 mailed the g-p-m list and hughsie replied we should have a look at CVS...
<ogra> which i plan to look qat if i find time over the weekend
<jdong> o_O
<jdong> mr evolution says "Getting message 40 of 98"
<jdong> I'm guessing today's archive day?
<jdong> nope, nvm, just a bunch of spam
<giskard> ogra, he said "Checkout CVS - I've made things a lot simpler."
<giskard> (but you probably already know this)
<ogra> yep, i'm subscribed to g-p-m
<pitti> Mithrandir: just reading your merge log; was the autoipd patch already accepted in Debian? (no -v :( ) or did you simply not mention it in the merge log?
<giskard> pitti, no :(
<giskard> pitti, i will add it but afaik it will not enter in etch.
<pitti> giskard: I sent it to upstream, let's see what he says
<pitti> giskard: it's not really that crucial any more
<pitti> giskard: I erroneously thought that you had to use avahi-autoipd to make SD work, but that was just due to the broken avahi security patch with network-manager
<pitti> giskard: I didn't try, but nss-mdns should actually work with n-m's internal ipv4ll implementation as well
<giskard> ok.
<slomo> pitti: nss-mdns doesn't need a ipv4ll implementation at all, only mdns by avahi-daemon
<pitti> right
<pitti> seb128: btw, new gdb is in the archive; running the pkg-create-dbgsym test suite with that on 2.6.19 and .20 would be great
* pitti -> baking cake, bbl
<slomo> pitti: have fun :)
<seb128> pitti: 
<seb128> PASS: dbgsym ddeb for dhtest1_2.3-1_i386.deb exists
<seb128> PASS: unpacked/usr/bin/crash has .gnu_debuglink section
<seb128> Failed to read a valid object file image from memory.
<seb128> etc
<seb128> $ uname -r
<seb128> 2.6.20-1-generic
<seb128> ii  gdb                      6.5.dfsg-2ubuntu3        The GNU Debugger
<dieman_> wow, encrypted disk is really not as much of a performance hit as I would have figured
<jdong> dieman_: got a powerful CPU?
<pitti> seb128: hmm, wfm on amd64; so that's still the kernel bug
<pitti> seb128: bug 74691, something for BenC
<Ubugtu> Malone bug 74691 in linux-source-2.6.19 "Unable to debug under 2.6.19: Failed to read a valid object file image from memory" [High,Fix committed]  http://launchpad.net/bugs/74691
<pitti> seb128: thanks for testing!
<seb128> pitti: ok
<seb128> np
<dieman_> jdong: im using a 1.2Ghz ULV chip in my laptop...
<dieman_> jdong: its not insanely powerful.
<jdong> dieman_: what kind of ULV chip? who makes it?
<dieman_> jdong: i think its because the kernel in edgy (I don't think the dapper kernel had this) has the i586 optimized aes module
<dieman_> jdong: intel 1.2ghz ULV pentium m
<jdong> dieman_: the kernel in dapper was "more" optimized
<jdong> dieman_: i686
<dieman_> ahh, nifty
<jdong> but that's pretty irrelevant
<jdong> the relevant issue is...
<jdong> dieman_: you realize your processor has similar power to a mid-grade Opteron chip from last year?
<jdong> ;-)
<dieman_> this isn't a core or core2 tho :)
<jdong> A 1.2GHz P-M is not a low-power chip
<dieman_> this box is over 1.5 years old :)
<dieman_> "753 (1.2 GHz) models are ultra-low voltage (0.940 V) with a TDP of 5 W."
<dieman_> http://en.wikipedia.org/wiki/Intel_Pentium_M
<dieman_> i'll admit, its not OLPC 'low voltage'
<dieman_> though
<dieman_> i'm just seeing a huge push at my employer for encrypting all laptop disks
<dieman_> basically the fallout of privacy laws
<\sh> Keybuk: do you happen to know why diacanvas2 (source pkg) is not on the universe merging list? :)
<Keybuk> \sh: because it's up to date?
<\sh> Keybuk: not as p.u.c. tells me somehow
<\sh> 0.14.2-2ubuntu1 in feisty and 0.14.4-4 in debian unstable
<geser> \sh: diacanvas2 FTBFS
<\sh> ah...I can see now...:(
<geser> I have a fix for it but it is blocked by bug 75606
<Ubugtu> Malone bug 75606 in pygtk "Module codegen.createdefs is not installed" [Unknown,Unconfirmed]  http://launchpad.net/bugs/75606
<Keybuk> \sh: right, source package is newer than the binaries because it FTBFS
<Keybuk> https://launchpad.net/distros/ubuntu/+source/diacanvas2
<\sh> Keybuk: yepp
<BenC> pitti: Work on specs  today, which includes apport :)
* pitti hugs BenC 
<seb128> BenC: hi
<BenC> seb128: hey
<BenC> seb128: I'm going to try to get around to that gdb thing over the weekend
<seb128> BenC: do you know if there is already a bug open about 8139 network cards breaking after some time on 2.6.19 or 2.6.20?
<seb128> BenC: ok, thank you
<BenC> seb128: I remember there is a bug about it in edgy/2.6.17
<BenC> or maybe that was 8169
<seb128> BenC: well, 2.6.17 works fine for me, 2.6.19 crash like several time a day (I did try for a long time, I rolled back to using 2.6.17 while waiting for 2.6.20), and I got the same problem once with 2.6.20 since I'm running it
<seb128> what informations are useful for such bugs out of lspci and syslog log?
<BenC> seb128: Please test 2.6.20
<BenC> if you need lrm, I should have it uploaded over the weekend
<jdong> BenC: are the metapackages updated yet for 2.6.20 in feisty?
<seb128> sorry, xorg crashed
* jdong too lazy to reboot and see for himself
<BenC> jdong: no
<seb128> BenC: I'm running 2.6.20 atm, network card stop working only once since I use it
<seb128> when it stops working it prints that to syslog
<seb128> kernel: [  259.246426]  NETDEV WATCHDOG: eth1: transmit timed out
<seb128> kernel: [  259.246436]  eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x2, t=180.
<seb128> a bunch of times
<BenC> seb128: That may be work queue related breakage
<seb128> what information could be useful with a bug like that?
<kylem> BenC, if it happened with .19 then it probably isn't workqueue related...
<BenC> oh, true
<kylem> seb128, what kind of network card? :)
* kylem is going to guess sky2?
<seb128> kylem: 
<seb128> 02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
<seb128>         Subsystem: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
<seb128>         Flags: medium devsel, IRQ 19
<seb128>         I/O ports at c000 [size=32] 
<xipietotec> question regarding Fiesty re: recent kernel news regarding binary blobs, does this mean that feisty won't be distributed with Nvidia and ATI drivers pre-installed?
<jdong> xipietotec: what recent kernel news regarding binary blobs?
<jdong> xipietotec: I thought Linus posted a retort to it, and the patch was retracted
<kylem> seb128, what driver and can you paste just the first line of the -n so i can see what pci id it has?
<xipietotec> the patch was retracted, but the linux kernel the plans to have the kernel free of all binary blobs are still going through
<xipietotec> the patch was retracted because it prevented users from adding binary blobs as well (If I'm not mistaken)
<jdong> I doubt it'll happen with Feisty though
<jdong> if anything happens
<seb128> kylem: 8390                   11904  1 ne2k_pci
<seb128> kylem: 02:09.0 0200: 10ec:8029
<xipietotec> 'cause It seems to be the prevailing opinion of people in #gnu and #fsf that binary blobs in the kernel are illegal
<kylem> seb128, oh wow. that's a seriously classic piece of hardware.
<keescook> xipietotec: that patch didn't stop anything; it just issued a warning.  so, no, I think the mainline kernel will continue to allow binary drivers for some time.
<Mithrandir> pitti: I just forgot to mention it.
<seb128> kylem: well, my other network card broke so I got an old one out of the stock, and it's working fine for months now so I didn't bother replacing it :)
<xipietotec> keescook: hrrm, cool
<xipietotec> I guess
<seb128> hey keescook
* keescook hugs seb128 
* seb128 hugs keescook back
* pitti gets seriously angry at latex still producing a pdf even when explicitly calling it with -output-format=dvi
<orvils> Hello... I have a question about gnome latvian (lv) localisation package. Due to the rosetta bug 68014 we had a lot of mistakes in Latvian translations of gnome. Today I uploaded fixes to rosetta, and I would like to know when we can expect update to gnome-lv package?
<Ubugtu> Malone bug 68014 in rosetta "Rosetta reverts translation fixes to old faulty values" [Critical,Fix released]  http://launchpad.net/bugs/68014
<orvils> Can anyone make an update of gnome-base-lv or gnome-lv packages?
<cjwatson> orvils: contact pitti
<pitti> orvils: hi
<orvils> pitti, hi... can you help with the update?
<pitti> orvils: was this a regression of the -updates pacakges uploaded yesterday? or has it always been broken?
<pitti> orvils: the next regular update is on January 2nd, but if the latest edgy/dapper updates introduced a regression, I'm fine to do an -lv update out of band
<orvils> it was broken for a while (some 2 month), but due to the bug i mentioned uploads to rosetta were disabled and we couldn't fix these mistakes... now they are fixed 
<pitti> orvils: oh, I see; well, a stable release update is painful, so TBH I'd rather wait until January
<pitti> orvils: however, please test the daily language packs and tell me if/when they get fixed
<pitti> orvils: deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates/ ./
<pitti> orvils: (likewise with dapper)
<orvils> ok
<orvils> january is notthat far away... we can wait :)
<dholbach> hey heno
<pitti> orvils: and, as I said, you are welcome to use the daily packages
<dholbach> heno: how's it going?
<pitti> orvils: in general I recommend translators to use them to immediately get and give feedback
<orvils> ok... thanks...
<heno> dholbach: good, triaging :)
<dholbach> heno: nice :-)
<heno> dholbach: even fixed a bug after you in bughelper ;)
<dholbach> heno: ROCK, I'll merge from you :)
<dholbach> heno: does your bughelper mail mean that we'd get a HUGE xml blob containing all bug information? or did I get that wrong?
<heno> dholbach: I've asked the LP guys for some XML data
<heno> it would make sense if we could choose a subset
<dholbach> and it'd probably be quite big and probably not always up to date?
<heno> like the evo bugs with the word 'pop' in them
<heno> right, but it could be set up to rsync I guess
<heno> it should be a feature on the advanced search page: dump to xml
<dholbach> ah ok
<heno> so you can get what you need
<heno> imo
<dholbach> but I guess this is a feature that is planned and might take some time to get implemented, right?
<heno> yes, but I'm sure we can get some sample data to play with
<dholbach> if that's the case, I think we should continue with our efforts and at some stage start to write the xml code - that could happen plugin-esque
<heno> it's a feature they were planning anyway, which was set to low priority, but now elevated to high again
<dholbach> that's great to hear
<heno> the previous usecase was projects considering malone, but worried about how to get the data back out if they changed their minds
<dholbach> I think we should continue with our efforts. stuff like the command line interface and making the .info file structure cleverer will have to happen anyway
<dholbach> right
<heno> dholbach: agree, the info files need some love (and content ...)
<jdong> nm-netlink-monitor.c:52:27: error: linux/if_addr.h: No such file or directory
<jdong> aww, no nm 0.6.4 on edgy for me :(
<pitti> jdong: current feisty package has a patch for that
<pitti> jdong: oh, argh, no; not for that
<cjwatson> jdong: there's a post on ubuntu-devel-announce from a month or two ago explaining how to fix that problem in general
<cjwatson> from Fabio
<dholbach> heno: i'll look into pitti's xml file structure for the apport bug patterns
<pitti> cjwatson: that explained it in the other direction
<jdong> cjwatson: oh?
<pitti> jdong: my gut feeling is that merely removing the #include should work on edgy
<dholbach> heno: which is xml but gives us more flexibility
<heno> dholbach: yep, hat sounds good
* dholbach hugs pitti
* pitti hugs heno and dholbach 
<heno> pitti: explained that a bit for me yesterday
<pitti> dholbach: heno and I had a quick talk about this yesterday; we want to get something cool at the sprint
<heno> \o/
<dholbach> pitti: it'd be great to have a shared set of .xml/.info files
<cjwatson> actually, it may have been ubuntu-devel and not -announce
<heno> yep, catch the bugs in both ends :)
<dholbach> i'll have a look at them and see how that could make sense
* jdong removes 16_undefined_macros.patch and rebuilds
<cjwatson> jdong: https://lists.ubuntu.com/archives/ubuntu-devel/2006-November/022171.html
<heno> dholbach: where can I see them? the apport source?
<cjwatson> pitti's right, it's the other direction
<pitti> heno: http://people.ubuntu.com/~pitti/bugpatterns/
<heno> cool, thx
<jdong> cjwatson: useful nonetheless
<dholbach> pitti was faster :)
<dholbach> heno: we shouldn't feel guilty about making ubuntu-bugsquad@ a bughelper-dev@ list ;-)
<pitti> heno: erm, the coreutils one is still the demo that I gave on the annoucement; it's bogus, of course :)
<dholbach> heno: I'm happy to work on that xml code (but will look at pitti's code first)
<heno> makes sense
<pitti> dholbach, heno: the format is as general as I could think of; you can do arbitrary matches on apport-style reports; but we might need more operators; if you need something, I'm happy to add it
<jdong> yay, it appears to have gotten past that build step
<heno> pitti: I didn't see version # in there but I'm sure you'll add that (the version at which the bug is kown to be fixed for example)
<jdong> successful build; thanks cjwatson, pitti
<heno> from that we should have bughelper look up distro release version, to make it easier to triagers
<heno> that's a common question
<dholbach> pitti: generally we want to be able to say 1) this bug is a dup of #24797 or 2) give out an arbitrary message like "You might want to subscribe ubuntu-x-swat on this" - I think it'd make sense to have several DoesInclude and DoesNotInclude tags to determine if it's a match
<dholbach> pitti: I'm not sure if it makes sense to integrate that into the apport bug patterns - atm we're still in the brain storming phase :)
<pitti> dholbach: not sure yet; let's collect some use cases, write them down, and then do the pattern design on them
<pitti> dholbach: since it's more or less the same thing (identify a bug based on some properties of a report), I think it should make sense to have those in the same db
<pitti> dholbach: for crashes I only need the properties -> bug # mapping, but if the db has more info, that won't hurt me :)
<pitti> dholbach: and likewise, if you feed a bug through that db, you can find out whether it's already known as another bug
<pitti> oh, door bell, bbl
<dholbach> pitti: makes perfect sense
<pitti> dholbach: the arbitrary message thing is interesting, though, and should be added
<pitti> dholbach: maybe as a second stage; (1) properties -> bug#, (2) bug# -> further information
<heno> pitti: I think they key difference is that with apport you want to be quite sure when you indentify a dupe and drop the bug, while with debhelper you can tell the triager: It's similar to all these 10 bugs, go have a look
<pitti> debhelper?
<pitti> ah, bughelper
<dholbach> bughelper! :-)
<heno> erm, bughelper
<pitti> heno: right, that might be an issue
<pitti> argh, have to leave for a bit, sorry
<dholbach> pitti: no problem - you'll be off for VAC then?
<dholbach> heno: thanks for the fixes - I'll push them to ~bugsquad/bughelper/main if you don't mind
<heno> dholbach: please do
<pitti> dholbach: semi-off; I'll still be around now and then, as I wrote
<dholbach> pitti: have a good, refreshing, relaxing time :-)
<dholbach> heno: done
<bluefoxicy> ugh
<bluefoxicy> I have like 2 copies of beagled in my start-up programs according to gnome-session-manager
<jdong> bluefoxicy: that does tend to happen...
<jdong> bluefoxicy: amusingly nm-applet has done that to me before
<jdong> that was a bit more amusing
<jdong> since apparently nm doesn't deal well with two clients trying to simultaneously operate
<bluefoxicy> jdong:  one of them isn't from a package
<bluefoxicy> jdong:  I guess it got there by me telling beagle to start up beagled automatically, long ago, when I wanted to play with it
<bluefoxicy> i.e. somehow beagle, without my authorization, wrote root-owned files into a root-owned directory
<jdong> bluefoxicy: yep
<jdong> bluefoxicy: same with nm-applet; I accidently saved my session with it running
<bluefoxicy> it just magically got root
<bluefoxicy> jdong:  this was in /etc/xdg/autostart/
<jdong> whoa
<jdong> that's weird :)
<bluefoxicy> ~$ dpkg-query -S /etc/xdg/autostart/beagled.desktop 
<bluefoxicy> dpkg: /etc/xdg/autostart/beagled.desktop not found.
<bluefoxicy> ~$ sudo rm /etc/xdg/autostart/beagled.desktop
<bluefoxicy> that ends that.
<keescook> BenC: 2.6.20-1> so far, so good.  boots my X2 3800+ okay
<bluefoxicy> jdong:  someone needs to background modprobe, damn.
<BenC> keescook: Great, thanks
<jdong> bluefoxicy: I'm not sure how well that'd work :)
<bluefoxicy> jdong:  my boot process halts for 10 seconds waiting for modprobe
<bluefoxicy> jdong:  when upstart is fully integrated that will probably go away anyway
<jdong> bluefoxicy: modprobes tend to stall everything anyway
<bluefoxicy> jdong:  some of the DT_GNU_HASH stuff is trickling in; most of /lib has it, I'm waiting on /bin/bash to get rebuilt
<jdong> cool
<Ng> bluefoxicy: the "beagle" package owns that autostart file, there's no magic root stealing going on
<bluefoxicy> Ng:  the beagle package owns beagled-autostart.desktop
<bluefoxicy> It didn't own the SECOND beagled autostart file.
<Ng> bluefoxicy: on my edgy and feisty boxes, beagle owns /etc/xdg/autostart/beagled.desktop and there is no beagled-autostart.desktop
<bluefoxicy> Ng:  that's weird; on my feisty box, I uninstalled beagle and beagled-autostart.desktop vanished
<bluefoxicy> but beagled.autostart stayed there
<bluefoxicy> jdong:  http://rafb.net/paste/results/u6KjAC63.html
<cbx33> hey guys I'm trying to edit a glade file...but it says a required catalog was not found....the catalog is gnomecanvas
<cbx33> do i install the gnomecanvas-dev library
<superm1> ping infinity 
<superm1> oh away...
<pitti> dholbach: thanks, you too!
<pitti> keescook: btw, new gdb == , thanks
<pitti> have a nice weekend everyone
<crimsun_> bye pitti 
<keescook> pitti: new gdb?
<keescook> oh! that "?" I saw was probably unicode.  gah, gotta fix my terminal.
<crimsun_> it's a heart
<keescook> sweet.  thanks crimsun_
<sistpoty> cjwatson: around? seems like we got a non-free file in universe (edgy + feisty): copy is here http://revu.tauware.de/revu1-incoming/pax-utils-0612122225/pax-utils-0.1.13.dfsg.1/macho.h
<sistpoty> cjwatson: should we do s.th. urgently about it?
#ubuntu-devel 2006-12-16
<minghua> sistpoty: is it just non-free or non-distributable?  there doesn't seem to be a license in it
<sistpoty> minghua: I don't know actually, since there is no license but a copyright statement 
<sistpoty> minghua: might be non-distributable, but might be given to public domain from apple as well
<minghua> right.  so it's quite unclear
<minghua> for non-distributable files I suppose things should be fixed
<minghua> non-free probably doesn't matter much
<cjwatson> sistpoty: I'd be inclined to see what upstream know before panicking
<sistpoty> cjwatson: it's coming from gentoo, and afaict is still in the repos
<cjwatson> though I see it was removed in a Debian update, hmm
<cjwatson> sistpoty: modifying edgy itself is kind of a nuclear measure, and I'd prefer not to do it unless there is an actual legal threat
<cjwatson> sistpoty: I'd certainly be willing to discuss an update, or something, but not at 23:40 on a Friday night. :-)
<cjwatson> sistpoty: feel free to mail me
<sistpoty> cjwatson: ok... will do so. Just wanted to know if that's s.th. really urgent ;)
<sistpoty> cjwatson: I guess I'll do it via the regular motu-sru policy then, ok?
<cjwatson> that's fine with me. If there's a threat of legal action, please let me know and I'll see that it's escalated appropriately
<sistpoty> cjwatson: alright. thanks
<cjwatson> I don't think we've ever modified a released suite before (apart from some changes to the Task headers in breezy's Packages files, which was sort of by accident and ended badly anyway)
<sistpoty> oh, nice
<elmo> sistpoty: if it's only that file, I very much doubt that's a copyrightable work
<sistpoty> elmo: only this file, yes
<elmo> sistpoty: then, FWIW, I really wouldn't worry about it in released distributions
<sistpoty> elmo: ah, k... thanks
<cjwatson> (I agree with elmo, but didn't want to make that claim off my own bat while as tired as I am)
<cjwatson> it falls under the "only one way to do it" thing
<cjwatson> anyway, bed
<imbrandon> gnight cjwatson 
* imbrandon is headed to sleep too
<sistpoty> gn8 cjwatson
<imbrandon> see yall
<sistpoty> gn8 imbrandon as well
<Drako60> i know this isn't the place for help, but i need some help befor my kernel deciedes to crash again, http://pastebin.ca/280555
<minghua> Drako60: please report bugs instead of asking here
<bronson> Does anyone cross-compile their packages for different architectures?
<bronson> I have some kernel packages that I'd like to provide on more than just x86.
<bronson> And I don't want to buy a Sparc64 box.
<bronson> Actually, yes I do.
<bronson> I don't want to *pay for* a sparc64 box.
<Hobbsee> bronson: use a VM or something?
<bronson> Maybe.  I'd be afraid of the speed if it's emulating.
<bronson> Seems better to just run gcc natively, but outputting packages for a different architecture.  Just wondering if anyone's done this before.
<Hobbsee> probably.  i havent
<bronson> Gotta admit, sounds like a fun thing to play around with.
<bronson> Wish I had more time...
<keescook> hmpf, the python.a file in python-dev wasn't compiled with -fPIC?
<BenC> Mithrandir: ping
<bronson> I found a bug in the graphviz-cairo package but I can't figure out how to enter it in Launchpad.
<bronson> Do I have to register graphviz-cairo as a product?
<bronson> When I search in Launchpad, it says "graphviz-cairo" is not known.
<bronson> Ah, forget it.
<bronson> Launchpad is just too difficult to use.
<bronson> And this bug is not big enough to worry about -- just bad dependencies.
<cjwatson> bronson: start at https://launchpad.net/distros/ubuntu/+filebug and enter graphviz-cairo as the source package
<bronson> Ah good, I'll give that a shot.
<bronson> cjwatson: thanks.
<cjwatson> np
<cypher1> http://shootingthekids.dpblogs.com/2006/12/14/yo-mamma-likes-ubuntu/
<cypher1> thanks to ubuntu guys ! :)
<theBishop> has anyone booted Ubuntu PPC on a Playstation3 yet?
<sistpoty> hi folks
<mdke_> who is the right person to talk to at Canonical about questions of copyright?
<BenC> Mithrandir: ping
<BenC> mdke_: Exactly what type of question do you have?
<mdke_> BenC: I have a question about whether Canonical are prepared to waive their copyright on some material
<BenC> ping anyone that can process NEW archive stuff
<BenC> mdke_: Hmm...I would guess the best starting point is Matt Zimmerman <mdz@ubuntu.com>
<mdke_> BenC: ok, I'll try him. Thanks
<mdke_> mdz: if you're here, let me know.
<mdke_> mdz: alright, no worries, I've mailed
<Amaranth> BenC: did the fix for bug 74472 fix sound on your laptop?
<Ubugtu> Malone bug 74472 in linux-source-2.6.20 "[ALSA]  quiet sound until after hibernate" [Undecided,Needs info]  http://launchpad.net/bugs/74472
<Mithrandir> BenC: please include a bit of context with your pings; if it's NEW-ing lrm, I'll do that when I get home (I'm going out now-ish)
<BenC> Mithrandir: Sorry, it's newing LRM, but also need linux-source-2.6.20 published, it has some new udeb's that need processing
<twb> Mithrandir: hey, so you know how I merged the debian stuff into casper?  When can I expect that to turn up as a .deb in feisty?  (Maybe it's already there; I haven't looked yet.)
<Zmax> have you ever heard an operating system named "SignalOS"?
<shackan> it used to be a popular joke
<Zmax> lol
<Zmax> popular?
<Zmax> google for SignalOS
<Zmax> there are some sites
<Zmax> stc
<Zmax> etc
#ubuntu-devel 2006-12-17
<jdong> is there a way to tell rm -r not to recurse into another filesystem?
<jdong> that's a mistake I can seriously see myself making some day
<twb> jdong: you could use find -xdev -exec rm {} +
<jdong> twb: yeah, good idea, might just do that
<rmjb> lamont: I'm taking a crack at merging asmail
<bddebian> I requested a sync of it today
<jdub> assmail? awesome.
<bddebian> And someone else already had a merge posted for it
<bddebian> I got your assmail.. ;-P
<rmjb> oh...
* rmjb should have checked the bugs filed against it
<rmjb> you requested a sync? you're not keeping the libxext-dev build dep?
<bddebian> Not necessary
<jdub> hrmph. the only thing keeping restricted on my laptop is the ipw3945 binary. grr.
<Burgundavia> jdub: indeed. madwifi for me
<twb> Mithrandir: ping?
<testsusf> hello im trying to figure out the script that checks the filesystem.. and im woundering.. what maked the files /fastboot and /forcefsck im currently looking at the checkfs.sh script in /etc/init.d/
<testsusf> do anyone know
<azeem> testsusf: please ask in #ubuntu
<testsusf> they dont know
<azeem> then ask elsewhere, this is not the right channel
<twb> I've often had the problem where #ubuntu is full of people asking relatively simple (i.e. beginner) questions, flooding out anyone trying to work out something complex.  Is there an #ubuntu-experts or something?
<Keybuk> heh
<Keybuk> there should be
<twb> What is the procedure for organizing one?
<Keybuk> /join #ubuntu-experts
<Keybuk> get other people to join too
<Keybuk> announce it on ubuntu-devel-discuss or similar
<twb> That's a bit de facto, but OK.
<Keybuk> no official procedure
<twb> I think #ubuntu-expert would be better.
<bhale> seems i am the only person there
<Keybuk> #ubuntu-i'm-a-developer-get-me-out-of-here? :p
<twb> Ya
<twb> The only problem, of course, is that now my modeline has [#ubuntu-d]  instead of [#u]  :-(
<twb> Ah, c'est la vie.
<mdke> maybe a separate channel for beginners would work better than a separate channel for experts
<twb> mdke: I disagree strongly.
* mdke backs away from twb 
<twb> New users will join #ubuntu, because they don't know any better.
<BenC> mdke: Yeah, you don't want new people going into #ubuntu and then being told to go to #ubuntu-lusers
<twb> Otherwise every second post to #ubuntu will be "go to #ubuntu-n00b, noob!"
<mdke> I was simply thinking that this is the way the forum works, and it does a good job
<twb> Yes, well, fora.
<mdke> anyway, given the strength of your reaction, I won't pursue it
* twb has Views about fora.
<bhale> hah most of us have Views
<bhale> best to live and let live
<Keybuk> my gods, the dbus low-level API is evil
<cypher1> Keybuk, hi
<Keybuk> cypher1: hello
<twb> I say we go back to abacusen
<bluefoxicy> low level api?  It doesn't have a high-level abstraction layer?
<Keybuk> bluefoxicy: it has them for GTK+, Qt, etc.
<twb> What about ncurses?
<twb> I mean, surely dbus is independent of the UI toolkit you use?
<bluefoxicy> wtf
<bluefoxicy> how the hell do you need a tool kit to pass data around
<bluefoxicy> what exactly is d-bus for now
<jdub> Keybuk means glib and Qt
<Keybuk> jdub: glib is just the GTK+ library
<jdub> (and the non-UI Qt bits with Qt 4)
<bluefoxicy> ah
<bluefoxicy> glib makes more sense though
<jdub> Keybuk: "no"
<Keybuk> jdub: yes; I know they like to think of it as a generic library, but it's *FAR* too heavy
<Keybuk> and far too closely tied to GTK+
<jdub> hardly
<Keybuk> the fact it's the library that implements the GTK+ object system, signal system, etc.
<Keybuk> glib is *HUGE*
<Keybuk> it's ten times the size of upstart, for example
<Keybuk> entirely inappropriate for linking there
<jdub> that's a forced example
<Keybuk> why is it?
<Keybuk> it's the relevant example
<jdub> it's unnecessary, and /usr
<jdub> not even on the radar
<Keybuk> eh?
<Keybuk> it was very much on the radar
<jdub> and then you worked out the obvious
<Keybuk> which is that glib is only suitable for projects using GTK+, or non-GTK components of the same project
<Keybuk> and that if you are writing a project that doesn't involve GTK+ at all, it's far too heavyweight and there are more suitable libraries or code collections
<jdub> well, no, but i'll leave you to it
<Ng> on the other hand, a typical desktop has glib loaded anyway
<BenC> wow, the buildd's look totally fucked
<BenC> https://launchpad.net/+builds/+build/286708
<BenC> the builds log there for linux-meta shows it trying to build kdebluetooth
* mdke guesses the latter isn't a dependency of linux-meta, eh?
<BenC> linux-meta got put into depwait because of libopenobex1-dev, because kdebluetooth failed to build :/
<BenC> On i386, the linux-meta build shows
<BenC> Automatic build of swig1.3_1.3.29-2.1ubuntu1 on rothera by sbuild/i386 1.170.5
<Keybuk> interesting
<mdke> do the cds still include windows foss software?
<wasabi_> So... apport. Are we going to replace bugbuddy with this?
<Lathiat> that seems to have happened already?
<wasabi_> hmm did it. sure though I'd seen bug buddy recently.
<dsas> bug-buddy is still used in most (all?) gnome apps
<wasabi_> Heh. Nice. Another change which seems to have ignored evms/lvm users.
<wasabi_> My /boot partition is now listed in the disk mounter app. And it lets me mount it.
<wasabi_> Except, it's already mounted.
<mdke> wasabi_: what's the disk mounter app?
<wasabi_> It's that gnome panel app. They appear in nautilus too
<mdke> ah that one
<wasabi_> bug#76177
<wasabi_> Ubugtu: ?
<wasabi_> He must not like me. =(
<crimsun_> bug 76177
<Ubugtu> Malone bug 76177 in nautilus "allows mounting of partitions that are already mounted (corruption!)" [Critical,Unconfirmed]  http://launchpad.net/bugs/76177
<wasabi_> oh, spaces. =(
<bluefoxicy> what
<bluefoxicy> you can mount the same partition twice wtf
<wasabi_> dev mapper stuff.
<bluefoxicy> oh
<bluefoxicy> yeah, then it becomes 2 different devices to the kernel and the FS driver
<bluefoxicy> last I looked mounting /dev/hda5 on /mnt/1 and /mnt/2 just kind of hooked up two mount points to the same VFS object
<wasabi_> Actually it should error saying it's already  mounted.
<bluefoxicy> hmm.. in that case it'd be a kernel issue, not nautilus
<wasabi_> Don't really think so.
<wasabi_> Probably more likely hal.
<wasabi_> Well, it's HAL which is advertising it as mountable... so, it's either HAL's decision to not do so, or somebody elses decision to tell HAL not to.
<Lure> wasabi_: this is probably related to changes done by pitti (hal)
<wasabi_> Yeah, looks like all known partitions are shown now.
<wasabi_> And sure enough, that's know.
<_MMA_> Hi guys. Can anyone point me to who works on Usplash?
<bSON> hi
<bSON> the ubuntu version of gnome-session's gnome-wm script must be updated to support compiz like the upstream version
<neuralis> _MMA_: you want to talk to mjg59.
<_MMA_> neuralis: Thank you. Where is he located? Im in the states.
<neuralis> _MMA_: uk.
<_MMA_> Thanx again.
<_MMA_> mjg59: ping
<adam0509> hello, I wrote about (important) bug in Dapper/Edgy, but I didn't get any feedback yet...
<adam0509> so please check : 
<adam0509> https://bugs.launchpad.net/distros/ubuntu/+bug/75097
<Ubugtu> Malone bug 75097 in Ubuntu "Ubuntu Dapper/Edgy can't mount some CD-Drive" [Undecided,Unconfirmed]  
<adam0509> thanks Ubugtu ;)
<mdke> you have to be quite patient - there are 20,000 bugs filed, it takes some time to go through them
<adam0509> okay... if you say so
<adam0509> But I hope it will be fixed in Feisty...
<owh> Keybuk: Would you have a moment to discuss bug #48806?
<Ubugtu> Malone bug 48806 in sysvinit "vfat filesystems checked by fsck" [Wishlist,Confirmed]  http://launchpad.net/bugs/48806
<owh> Keybuk: The bug is marked as wishlist and I was wondering how a bug that causes data loss could be marked as such.
<owh> Keybuk: I realise that a work-around, by not having the fs being checked during boot would not be an actual fix, so would it be fair to say that a resolution could be provided in two steps, an initial fix that stops the vfat partitions from being checked and an actual fix that fixes dosfsck - or am I being a dummy and you're already doing this?
* owh wonders what time it is in London right now.
<owh> @now London
<Ubugtu> Current time in Europe/London: December 17 2006, 17:56:03 - Next meeting: Technical Board in 2 days
<stefg> around tea-time, I'd guess :-)
<owh> Hmm, perhaps Keybuk is chewing on food :-)
* owh should be asleep.
<owh> @now Perth
<Ubugtu> Current time in Australia/Perth: December 18 2006, 01:56:49 - Next meeting: Technical Board in 2 days
<owh> Hmm, and that time does not include day light saving :-)
<owh> stefg: I'll send him an email.
<owh> stefg: FYI: owh==onno-itmaze on launchpad
<stefg> thx ..chew...chew...
<owh> stefg: How do I get in touch with you?
<Keybuk> ajmitch: ping?
<Keybuk> owh: arguably the bug there is in dosfsck for corrupting the filesystem
<owh> Keybuk: That was exactly how I read it too.
* owh cancels the email :-)
<owh> Keybuk: Would it be fair to suggest a fix in two stages?
<Keybuk> owh: if you can find a non-error-prone way to fix the boot fsck
<owh> Keybuk: Am I incorrect in understanding that marking column 6 as 0 does not prevent the check?
<owh> Uhm in fstab that should be.
* owh scratches head at impossible English construct.
<Keybuk> that's true, yes
<Keybuk> 0 means fstab won't check the filesystem
<owh> So, would that give the users of an fstab filesystem less of a heart-attack?
<stefg> which is advisable, if the fscker is chewing your files....
<owh> I realise that this won't actually fix the problem.
* owh is considering looking at the dosfsck source code :)
<stefg> sudo chmod -x dosfsck ....
<Keybuk> the trouble is, there's no way to do that
<owh> I don't understand what you're telling me.
<Keybuk> not without disabling checking on filesystems that the user might actually have wanted checked
<Keybuk> no way to modify fstab "properly"
<wasabi_> So... I notice that we are now listing all partitions in UI such as nautilus.
<wasabi_> That's hal making that decision right?
<owh> You mean, parse fstab and change the appropriate value, or do you mean something else?
<owh> Or do you mean detect which ones to disable at some (installation) time?
<stefg> The real problem is not that the fstab isn't 'right'... having it checked would be a valid choice if dosfsck would work... so it's dosfsck that must be  fixed, not /etc/fstab ( or dosfsck must be disabled, as long as it is not fixed). 
<Keybuk> owh: ?
<owh> Yes, but fixing dosfsck is a much bigger problem, the actual fix, the first step is to stop trashing someone's filesystem.
<Keybuk> we can't stop trashing them
<stefg> yup, by disabling it altogether
<Keybuk> that's what I'm saying
<Keybuk> not without disabling checking where a sysadmin has explicitly enabled it
<owh> Ah, now we're talking on the same page :-)
<owh> Yes, I understand that changing fstab doesn't actually fix the issue.
<Keybuk> changing fstab causes another issue
<owh> So, is there a sane default, that is, don't check?
<owh> What issue does it cause?
<Keybuk> it would disable checking of fat filesystems that should be checked
<Keybuk> and that the user has explicitl
<Keybuk> +y marked to be checked
<stefg> No, there's in insane default that eats peoples files, without a chance to prevent that (except interupting the installation and changin fstab manually)
<mjg59> Keybuk: We still don't autoload modules on isapnp systems?
<owh> So, would a work-around be a wrapper script around dosfsck that checks the fs-type and only checks fat16 and spits out a warning and does nothing if it's a fat32?
<Keybuk> mjg59: uhh, we autoload those lists of modules in /etc/modprobe.d/isapnp
<mjg59> Keybuk: Ah, so not really :)
<owh> That is, until dosfsck is actually fixed.
<mjg59> Keybuk: We should handle soundcards in that
<Keybuk> mjg59: to my knowledge the kernel still isn't exporting a MODALIAS from the pnp subsystem, and still isn't exporting aliases from pnp drivers
<mjg59> They all provide modalias lines, but they don't seem to get properly associated with them
<Keybuk> mjg59: right, some do; but the kernel doesn't generate a MODALIAS for pnp devices
<mjg59> They're exported via /sys/bus/pnp
<mjg59> Surely we can hack around that?
<Keybuk> no, they're not
<Keybuk> ls: /sys/bus/pnp/devices/*/modalias: No such file or directory
<mjg59> Keybuk: /sys/bus/pnp/*/id
<Keybuk> that's not the modalias strng
<mjg59> No
<Keybuk> and doesn't match the modalias strings
<mjg59> But it's a unique identifier
<Keybuk> no, it's not unique
<mjg59> Keybuk: For the hardware, it is
<Keybuk> no
<Keybuk> they're classes
<Keybuk> (you know this :p)
<mjg59> For the devices we care about, they're not
<Keybuk> and you know that we both tried to turn those id lists into a unique string that matched the device
<Keybuk> and failed
<mjg59> No, the issue was that we couldn't figure out WTF the modalias lines in the modules referred to
<Keybuk> we seem to have this conversation about once every 6 months, at about this point in the release <g>
<mjg59> So we probably ought to get someone to tell us that
<Keybuk> I've tried that, didn't get anywhere
<Keybuk> the kernel should be exporting MODALIAS for the devices
<Keybuk> after all, it can match devices and drivers
<Keybuk> BenC may be able to help
<owh> Keybuk: I've just been googling a little and came across this: How to determine the width of a FAT: http://homepages.tesco.net/J.deBoynePollard/FGA/determining-fat-widths.html
<owh> Keybuk: Also: http://homepages.tesco.net/J.deBoynePollard/FGA/determining-fat-widths.html
<owh> Keybuk: So, is a good summary of the issue: "dosfsck is broken. If we let it loose on fat32 it kills it. We cannot disable it because some users want to check their fat12/fat16 drive (which presumably isn't broken). We cannot turn off fsck for FAT volumes because of this."
<Treenaks> owh: so if you can make it detect fat32 and abort, all is well?
<owh> Well, in as far as the fat32 won't be hosed, yes.
<owh> But if you want to check a fat32, then it won't check it.
<owh> So, you will get behaviour where the admin sets that they want to check the filesystem, but a fat32 won't be checked.
<mjg59> We could fix dosfsck
<owh> That's my understanding of the problem.
<owh> mjg59: That of course is the real fix :-)
* owh has been programming for way too long, but file-system checking tools -- shudder.
* owh last checked a file system manually on a Vic20 :-)
* owh even wrote a disk editor in BASIC :-)
<sistpoty> what's wrong with dosfsck? how to reproduce?
<owh> sistpoty: It appears to trash a fat32 volume.
<owh> sistpoty: From my reading, any fat32 volume, but that may be wrong.
<owh> sistpoty: It seems to die on long file names.
<sistpoty> owh: hm... I didn't find any corruption of my fat32 volume yet... and I bet there are long filenames
<owh> Hmm, that's interesting.
<sistpoty> owh: might be interesting to first find out exactly *when* dosfsck does stuff wrong
<sistpoty> but maybe I just didn't recognize corruption yet *g*
<owh> sistpoty: Up to right now, when you said that I was under the impression that it always trashed it. Have you done a fscheck in DOS afterwards?
<owh> +or Doze.
<sistpoty> owh: I assume so, I did... but I'll find out in a minute... brb
* owh hopes that sistpoty doesn't loose any data ...
<_MMA_> mjg59: Im wondering if you can point me to current documentation for Usplash and or whomever is working on the Feisty Usplash.
<finalbeta> _MMA_, you can probably find the information you want here :http://www.netsplit.com/blog/articles/category/upstart
<mc44> _MMA_: try Seveas 
<mc44> finalbeta: usplash!=upstart
<finalbeta> lols, indeed. sry
<_MMA_> :)
<_MMA_> np
<sistpoty> owh: re... nope, xp file check thingy didn't yield any errors
<mjg59> _MMA_: What documentation currently exists is what's in the package
<Seveas> _MMA_, docs -> apt-get install usplash-dev
<Seveas> and for feisty afaik nothing big happened yet
<owh> sistpoty: Well I'm glad to see that :)
<mjg59> There's no real development planned for usplash other than bug fixing. It does pretty much what we want it to.
<_MMA_> Thanx Serveas. I need to figure it out for Ubuntu Studio.
<Seveas> mjg59, well, I have some theming improvements planned, but that's minor
<owh> So now we have a bug that trashes *some* fat32 filesystems.
<_MMA_> I was mot looking for what its capable of.
<_MMA_> s/mot/more
<sistpoty> owh: hm... I do have filenames > 8 chars... but it would be really interesting when/what is being crashed
<owh> sistpoty: I wholeheartedly agree with you.
<owh> I also suspect that the bug shouldn't be allocated to sysvinit.
<owh> I think that's just a symptom.
* owh thinks that it should be dosfstools
<sistpoty> owh: hm... but my fat32 partition is only 80Gb. maybe it's related to the size of the partition
<owh> sistpoty: Hmm, lemmie see if the person who came to me told me how big their partition was. One mo...
<sistpoty> owh: 140 Gb
<_MMA_> Seveas: Would you chat with me on -artwork please? :)
<owh> sistpoty: Was that in the bug report or on the channel?
<sistpoty> owh: bug report
<owh> sistpoty: Yeah, I saw that, I was trying to add another data point :-)
* owh is having a little hunt in dosfstool bug reports.
<owh> sistpoty: Look at that: Bug #47215
<Ubugtu> Malone bug 47215 in dosfstools "fsck.vfat hangs, eats CPU on problematic file" [Medium,Unconfirmed]  http://launchpad.net/bugs/47215
<owh> Well, we can confirm it :-)
<owh> sistpoty: It's a bit scant on detail ;-)
<sistpoty> hm...
<owh> sistpoty: There's another one, that truncates a file, looks to be > 4Gb file. Bug #62831
<Ubugtu> Malone bug 62831 in dosfstools "fsck.vfat truncates files of 4294967295 bytes length to 0 bytes at boot-time" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62831
<owh> sistpoty: That report actually tells us how to reproduce it. I wonder if it's all the same bug?
<sistpoty> owh: that would at least give some hints where the bug originates
<owh> sistpoty: From reading the reports, not having seen a single line of code I would suspect that there is an assumption being made that is a FAT16 assumption, a pointer is being trashed and the application sh*ts itself and writes the wrong information to disk. But that's *speculation* only.
* owh is still trying to locate other bugs and is also looking at Debian reports.
<owh> sistpoty: Whoa, there's a pile of them: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dosfstools;dist=unstable
<sistpoty> owh: I'll try to reproduce this bug. maybe the fix is trivial... but first I'll grab s.th. to eat, so I'll probably be afk for an hour
<owh> sistpoty: Hmm, it's 4am here, I am slinking off to bed :-)
<sistpoty> gn8 owh
<owh> sistpoty: I'll check in in the morning :-)
<owh> sistpoty: owh==onno-itmaze on launchpad.
<sistpoty> owh: ok, thx
* owh goes off to sleeeeeeeep.
<ajmitch> Keybuk: pong
<Keybuk> ajmitch: did you get much further with the selinux patch for upstart?
<ajmitch> haven't had time due to work
<soothsay> I'm trying to package something (for myself) for the first time. I'm using debhelper. It's a library and seems to compile cleanly and also seems to install into the correct directory when using prefix. I run dh_make, edit control and then run dpkg-buildpackage -rfakeroot. The package appears to be built cleanly but the .deb is essentially empty (only Copyright notice and changelog). What am I doing wrong?
<soothsay> gen_control gives a warning unknown substitution variable ${shlibs:Depends}
<soothsay> same for ${misc:Depends}
<gpocentek> soothsay: could you upload your package somewhere, and move this discussion to #ubuntu-motu ? :)
<soothsay> The source or the deb?
<soothsay> Will goto motu
<soothsay> Sorry BTW. Didn't read the topic :(
<bluefoxicy> this is so weird
<bluefoxicy> connect(4, {sa_family=AF_FILE, path="/tmp/ssh-IBZEow7532/agent.7532.seahorse"}, 110) = 0
<bluefoxicy> ^^^ ssh
<Fujitsu> I don't think that to be particularly weird, nor particularly appropriate for random insertion into a development channel.
<bluefoxicy> Fujitsu:  ssh hangs on feisty, for me only.
<bluefoxicy> also yeah
* bluefoxicy => #+1
<mdke> can it be that someone doesn't read my blog?
* mdke slaps the absent bluefoxicy
<ajmitch> sadly so
<mdke> outrageous.
<ajmitch> I know
<ajmitch> who wouldn't hang off your every word?
* mdke nods
<mdke> what's his real name? I'll email him
<mdke> gosh, not only does he not read my blog, he conceals his real name too. Outrageouser and outrageouser
<jmantha> mdke: totally
<mdke> bluefoxicy: ah, there you are. See bug 76030
<Ubugtu> Malone bug 76030 in seahorse "ssh (client) stops working after upgrade to Feisty" [Undecided,Confirmed]  http://launchpad.net/bugs/76030
<bluefoxicy> mdke:  saw your link.
<mdke> bluefoxicy: relieved to hear it
<bluefoxicy> and it works, yay.
* owh pokes sistpoty
<sistpoty> owh: still awake?
<owh> Nope, just came back online with a strong coffee in hand :-)
<sistpoty> hehe
<sistpoty> owh: I'm just about to test if I can reproduce the bug
* owh downloaded the source for dosfstools - the readme starts off with "WARNING - ALPHA CODE" -
* owh adds that there is a final disclaimer at the end that says - BTW, this is no longer Alpha code :-)
<owh> sistpoty: How did you do that, with a large file?
<sistpoty> owh: yes... in a minute I'll know more ;)
<owh> The suspense is killing me :-)
<sistpoty> owh: hm... no result :(
* owh guesses that this means it didn't break.
<sistpoty> yep
<sistpoty> didn't find anything, at least with -n
<owh> Is there any point in contacting all the reporters and asking them for more information?
<sistpoty> owh: let me retry without -n... maybe that will lead to results
* owh has a corrupted SD card at the moment, but suspects a hardware failure, so dosfscheck is likely to barf for lower level issues :-|
<owh> The reports in Debian point to "weird" characters in file names, back slashes and spaces - one report is on Japanese characters, could it be a character set problem?
<sistpoty> owh: might be as well, no real clue
* owh is just checking version numbers, the source I have does not have a real changelog.
<sistpoty> owh: hm... still no sign that dosfsck did anything to my partition. I'll restart xp and do a test... brb
<owh> Cool
<sistpoty> owh: nope, still no error or anything... *clueless*
<owh> sistpoty: It appears that the last activity in this code was in May of 1998, making me wonder if we're barking up the wrong tree.
<owh> sistpoty: Let me postulate: "What if the code is fine and the user data loss is a result of a corrupt FAT32 that the Windows version of scandisk does not properly fix or notice."
<sistpoty> owh: hm... haven't thought about this one yet... 
* owh recalls that in the late 90's, MacOS disk repair utility didn't see problems that Norton could and I'm recalling something similar in DOS 3.1 days.
<sistpoty> owh: I guess we should ping submitters for further info, how to reproduce this bug
<owh> sistpoty: I don't know if we're going to get any useful answers though. Most likely it will be along the lines of "a rabbit ate my data"
<sistpoty> owh: it's always worth a try
<owh> stefg said that the workaround of making fstab not check worked there, but I didn't get the opportunity to ask for further details. I've got to go and drop off my wife, back in 20 minutes, but I'm happy to ping the submitters of all the bugs that look the part.
* owh is back in 20...
<sistpoty> owh: ok, would be great
<twb> Mithrandir: ping?
* owh lied, it only too 15 minutes :-)
<owh> +k
<owh> sistpoty: I'll draft a quick request for more information...
<sistpoty> owh: thx... I've already written s.th. to 62831
* owh looks
#ubuntu-devel 2007-12-10
<pwnguin> what controls the creation of /dev nodes in Ubuntu?
<ion_> udev
<pwnguin> hrm
<pwnguin> how on earth does one read udev logs?
<tjaalton> lamont: ping, re: fbset/hppa in xserver-xorg
<pitti> Good morning
<ion_> Good evening
<StevenK> Morning pitti
<StevenK> pitti: How do you feel about doing some NBS work? :-)
<pitti> hey StevenK
<pitti> sure
<pitti> oh, except that my laptop's ssh key can't get to the DC yet
 * pitti pings IS
<StevenK> pitti: If you NBS out libicu36-dev, libicu-dev ought to then stand in for it and I can test build the seven rebuilds for that.
<StevenK> pitti: net-snmp is in NEW, and once you let it out, I have 26 rebuilds to upload.
<dholbach> good morning
<ion_> Good evening.
<dholbach> hey ion_
<ion_> Hi
<StevenK> pitti: No DC access for you?
<pitti> StevenK: NBSed/NEWed
<pitti> StevenK: I'm back on my desktop now :)
<StevenK> Ah
<StevenK> Yay
<StevenK> pitti: If you also process bug 175059, that will mean asterisk can stop depending on libsnmp10 and actually build
<ubotu> Launchpad bug 175059 in openh323 "Please sync openh323 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/175059
 * StevenK wonders if he can fool build.py
<pitti> StevenK: done
<pitti> StevenK: fool in what way?
<StevenK> pitti: build/bin/build.py from Helix, not your magical script
<StevenK> pitti: Thanks
<kagou> Good morning
<dholbach> hey lloydinho_ :)
<lloydinho_> morning dholbach :-)
<pochu> pwnguin: re gtkfilechooser - gtk+2.0?
<MacSlow> Greetings everybody!
<StevenK> pitti: net-snmp is marked as DONE, do you think it's safe to throw 26 uploads to Soyuz?
<Fujitsu> StevenK: They'll be marked done fairly early in the publisher run, but it should be safe by now.
<lool> Is an archive admin around?  I'm failing to see why the lpia binaries for x264 as built in <https://edge.launchpad.net/ubuntu/+source/x264/1:0.svn20070930-0.0ubuntu2/+build/459260> don't appear in http://ports.ubuntu.com/pool/multiverse/x/x264/
<lool> This is causing another build (gst-plugins-multiverse) to be stuck waiting for libx264-dev and the MBU team needs it
<pitti> lool: lpia is a supported architecture and thus will appear on archive, not ports
<lool> pitti: Uh?
<lool> pitti: http://ports.ubuntu.com/dists/hardy/multiverse/ => binary-lpia http://archive.ubuntu.com/ubuntu/dists/hardy/multiverse/ => no binary-lpia
<pitti> oh, seems I'm wrong
<pitti> since when did we move it?
<pitti> lool: sorry, seems I'm out of date
<lool> pitti: Probably a while ago, I always remember it like that
<pitti> libx264-dev | 1:0.svn20070930-0.0ubuntu2 | hardy/universe | amd64, i386, ia64, lpia, powerpc
<pitti> at least it's there on drescher
<pitti> http://ports.ubuntu.com/pool/universe/x/x264/libx264-dev_0.svn20070930-0.0ubuntu2_lpia.deb
<lool> I'm a bit lost that in my rmadison output the source is in multiverse but builds binaries in universe
<lool> I thought it was allowed the other way aound
<lool> *around
<pochu> It's in universe here
<lool>       x264 | 1:0.svn20070930-0.0ubuntu2 | hardy/multiverse | source
<pochu> Nope. You're right.
<lool> Also, whereever the binaries are, gst-plugins-multiverse builds should see it: they have universe and multiverse?!
<pitti> lool: thanks for the hint; seems someone incorrectly overrode it
 * pitti fixes
<geser> lool: I guess someone moved the debs to the wrong component when the debs got accepted
<lool> pitti: Ah cool
<pitti> lool: yes, indeed multiverse should build against universe
<lool> pitti: I am not sure your fix will be enough to get this building: https://edge.launchpad.net/ubuntu/+source/gst-plugins-bad-multiverse0.10/0.10.5-1/+build/364774
<lool> pitti: I don't really understand why it's not building if the binaries are in universe
<pitti> no, it won't help
 * pitti looks
<pitti> lool: simple: -1 is not current
<pitti> lool: -3 is current, and it has built on lpia
<pitti> soyuz won't bother building superseded versions
<lool> pitti: Ok, someone handed me that direct URL, I should have checked it's the latest source
<lool> pitti: Thanks!
<StevenK> I found a corner case where it did.
<pitti> yw
<pitti> StevenK: s/won't/shouldn't/ then :)
 * StevenK grins
<geser> pitti: while you are at it: please also move the i386, amd64, powerpc debs of x264 from universe to multiverse (see http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/)
<pitti> geser: done already
<StevenK> You'd think the scripts would enforce that.
<Fujitsu> Bug #132234
<ubotu> Launchpad bug 132234 in soyuz "packages in 'multiverse' can have binaries in 'main' " [High,Fix released] https://launchpad.net/bugs/132234
<Fujitsu> Well, apparently not.
<Fujitsu> Ah, that's PPA.
<StevenK> Right, I was about to say.
<geser> pitti: please give-back: xscavenger. Thanks
<pitti> done
<geser> pitti: please give-back: tseries rcmdr rxvt-unicode snack
<pitti> geser: done
<tkamppeter> pitti, hi
 * ogra waves from seville
<ogra> cjwatson_:  in case ou want me to talk about any particular task here, i'm sitting in the HW session here (only http open on teh firewall, so connection might be wonky)
<pitti> hi tkamppeter
 * ogra wishes for a company sponsored spanish training :/ i wish i'd understand anything
<tkamppeter> pitti, it is about avahi.
<tkamppeter> The "update-rc.d -f avahi-daemon remove" I have from the doc file /usr/share/doc/sysv-rc/README.Debian.gz
<pitti> tkamppeter: that's bad advice, I think
<tkamppeter> It does not remove the actual init script, but only the links in the /etc/rc.... directories. This causes new links to be added by the part of the .postinst script which gets inserted at #DEBHELPER#
<pitti> tkamppeter: well, I'm open for other opinions, but IMHO the way /var/lib/dpkg/info/dbus.postinst does it is better
<pitti> tkamppeter: I know
<tkamppeter> I will look, but what I will change is checking for the package version instead of checking for presence of a file to decide whether to do something. On a system where the user has manually changed the boot configuration, the fix would not get applied otherwise.
<geser> tkamppeter: you need to keep at least one symlink if you don't want that new symlinks get created by update-rc.d
<soren> Sheesh, packages.debian.org is slow today.
<tkamppeter> geser, I want to have new symlinks, as I want to change the boot order so that avahi starts before CUPS.
<ogra_> cjwatson: hey, i'm sitting in a (spanish) session about HW compatibility atm if you want me to ask/tell anything particulary ....
<ogra_> gah this web-cgi IRC client sucks ... :(
 * ogra__ grumbles about firewall admins that only offer http ...
<tkamppeter> pitti, I am applying the method from /var/lib/dpkg/info/dbus.postinst in avahi now.
<tkamppeter> pitti, thank you for this hint.
<geser> doko: Hi, have you time to look over the debdiff in bug #174749?
<ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
<geser> pitti: please give-back: gabber giblib libtk-img nspr. Thanks.
<doko> geser: looks fine
<tkamppeter> pitti, I have updated avahi now, 4ubuntu2 at the usual place ready for upload
<tjaalton> tkamppeter: some of the hplip-gui desktop-files lack a OnlyShowIn=KDE -tag, can I add them?
<Riddell> tjaalton: those apps are useful outside of KDE
<tjaalton> are they?
<tjaalton> ok
<Riddell> I'm sure non-KDE users own HP printers too
<tjaalton> sure, I'll just blacklist from the local menu then ;)
<Riddell> if you don't want the apps then uninstall the package
<tjaalton> we install both *-desktop's
<geser> pitti: please give-back: aalib
<seb128> is there a known issue with fonts in firefox and gecko applications in hardy?
<Fujitsu> seb128: I noticed my Gecko fonts got all strange with this morning's upgrade.
<ion_> My fonts have looked like crap for a while now (after a fontconfig update, i think). I havenât investigated the problem yet, though.
<seb128> ion_: everywhere or just firefox and gecko?
 * soren misses packages.debian.org
<pitti> soren: PTS still works, though
<soren> ..that does't make requestsync happy :(
<crimsun> pitti: Hi, do you have insight into https://edge.launchpad.net/ubuntu/+source/pulseaudio/0.9.8-1ubuntu2/+build/465314, or is cprov the go-to?
<ion_> seb128: Hm. Seems like just firefox. Bitstream Vera seems to look fine in all apps, but MicrosoftÂ® corefonts seem to be missing hinting alltogether in Firefox, whereas Nautilusâ font preview shows them correctly.
<Fujitsu> That looks like a cprov bug.
<pitti> crimsun: yes, indeed cprov
<crimsun> pitti: ok, thanks!
<stgraber> Is there any way to disable that SSH agent part of the gnome-keyring ? I haven't seen anything in the config dialog nor in gconf-editor ...
<Fujitsu> crimsun: Note the recent arrival.
<asac> hmm ... any mono (semi-)expert here?
<seb128> stgraber: I don't think so, any issue using it?
<dholbach> asac: ajmitch and slomo are our experts
<pochu> stgraber: I think you can, http://live.gnome.org/GnomeKeyring/Ssh
<seb128> asac: slomo knows about mono but he just closed his IRC
<pochu> stgraber: --components arg
<asac> thanks
<asac> ajmitch: ?
<seb128> pochu: that means patching gnome-session code no?
<StevenK> pitti: Would you mind punting openh323 out of binary NEW?
<pitti> StevenK: doing
<StevenK> pitti: Danke
<pochu> seb128: hmm, does it? I don't know.
<seb128> pochu: gnome-keyring is started by gnome-session, not sure how to add an argument there without changing the code
<cjwatson> pitti: a fixed finish-install for bug 174689 is in hardy now; could you review my -proposed upload?
<ubotu> Launchpad bug 174689 in finish-install "hvc/hvsi consoles not handled" [Undecided,In progress] https://launchpad.net/bugs/174689
 * StevenK watches Firefox chew up large amounts of CPU time as he asks it to open 26 new tabs
<Fujitsu> StevenK: Why do rebuilds take tabs?
<StevenK> Fujitsu: Because I open a new tab for each upload to pounce on build failures
<pochu> seb128: I thought I could change it in gnome-session-properties...
<StevenK> Which is a throwback from before LP mailed you
<Fujitsu> StevenK: Ah.
<StevenK> I don't think Firefox likes having 70 tabs open
<seb128> pochu: you can for applications listed in the session and using an autostart, the keyring start is coded though
<persia> StevenK: It can handle a couple hundred, but your chances of session corruption rise significantly.
<cjwatson> does it not save the session atomically?
<StevenK> Oh, grumble hplip got rejected.
<Fujitsu> StevenK: Pffft, I often have >150 open. It gets unmanageable eventually, though.
<crimsun> Fujitsu: thanks (I'm normally gone for work by now).
<crimsun> cprov: Hi, do you have insight into https://launchpad.net/ubuntu/+source/pulseaudio/0.9.8-1ubuntu2/+build/465314?
<StevenK> tkamppeter: Ping
<cprov> crimsun: let me check, one sec.
<tkamppeter> hi StebenK
<tkamppeter> hi StevenK
<StevenK> My name has no B. :-P
<StevenK> tkamppeter: The hplip merge doesn't do the Maintainer spec change; I have to upload a rebuild due to the net-snmp merge, do you want me to do it?
<tkamppeter> StevenK. what is a Maintainer spec change?
<persia> tkamppeter: https://wiki.ubuntu.com/DebianMaintainerField has context
<tkamppeter> pitti, have you seen my CUPS change on the SVN
<cprov> crimsun: builds 465307 & 465314 rescued, they will build in 15 minutes or so.
<crimsun> cprov: many thanks!
<pitti> tkamppeter: yes, I'll get to them
<tkamppeter> StevenK, Mark Purcell and me are managing the HPLIP package on the Debian SVN, in principle we keep the Debian and Ubuntu versions of the package equal.
<stgraber> seb128: well, I have some scripts where I would prefer to have the text prompt instead of the gtk one + I would need to check but I'm pretty sure that some times the ssh keyring was kept open even without the "Automatically unlock" thing checked
<seb128> stgraber: that would be a bug
<tkamppeter> StevenK. is you rebuild simply to get new binary packages so that they link with a new ABI of the netsnmp library? Or are there any changes except debian/changelog?
<tkamppeter> pitti, OK.
<StevenK> tkamppeter: No changes aside from debian/changelog
<StevenK> tkamppeter: It's to link against libsnmp15 rather than libsnmp10
<stgraber> seb128: I just reproduced it, I opened my irssi terminal (which connects to my server using SSH), I had the prompt for my key, entered it without checking the unlock thing
<stgraber> seb128: then closed the window and open it again
<tkamppeter> pitti, I have one doubt with Ghostscript. I want to package it as upstream made a patch to solve the problem of encrypted PDFs not printing out of Adobe Reader 8.
<stgraber> seb128: it didn't ask for the key
<tkamppeter> This is no problem, but on Saturday there was a discussion on removing the transitional package gs-common from ghostscript.
<tkamppeter> StevenK, I think you can go ahead, such a rebuild does not need to be registered in the Debian SVN. I assume that you simply add an entry in debian/changelog and then upload the source package to the build server which has libsnmp15 installed and so binaries using libsnmp15 will get generated?
<StevenK> tkamppeter: Right
<pochu> stgraber: I can confirm that it remembers it until I end the session
<tkamppeter> StevenK, then it's OK, go ahead.
<tkamppeter> pitti,
<seb128> stgraber: can you open a bug with the details to trigger the bug (without using irssi if possible ;-)
<tkamppeter> pitti, they tell gs-common is not needed, as ghostscript updates/replaces gs-esp and gs-gpl, but I think if on a system with the old gs-... Ghostscript gs-common is installed, and the new ghostscript has no gs-common transitional package, the old gs-common will stay and conflict with ghostscript. as ghostscript contains the files of the former gs-common.
<stgraber> seb128: sure
<StevenK> tkamppeter: Uploaded, thanks!
<pitti> tkamppeter: not unless the newer ghostscript Conflicts:/Replaces: gs-common
<pitti> tkamppeter: (which it should); then upgrades will work without a transitional pacakge
<pochu> stgraber: let me know the number and I'll confirm it ;)
<tkamppeter> pitti, ghostscript Replaces, Conflicts, and Provides gs-common (<< 8.60).
<tkamppeter> pitti, for which case are the transitionals needed then?
<pitti>  gs-common | 8.61.dfsg.1~svn8187-0ubuntu3 | gutsy/universe | all
<pitti> tkamppeter: it should replace/conflict to << 8.61.dfsg.1
<pitti> then it will work
<pitti> tkamppeter: you only need a transitional package if you actually want to keep the original name; that's not necessary for libraries, or -common packages which users usually don't want to install directly
<tkamppeter> Yes, I understand. The transitional allows the user to do "apt-get install gs-esp" and he gets ghostscript.
<tkamppeter> pitti, thanks, I will update ghostscript appropriately.
<persia> tkamppeter: It also allows packages to continue to depend on the old name for a bit, to soften the upgrade transition (doesn't work for libraries, where the ABI changed anyway)
<pitti> tkamppeter: so Debian dropped the transitional package in an earlier version?
<pitti> tkamppeter: we need to keep that change until after hardy then, then we can drop it
<tkamppeter> pitti, I do not know what Debian did.
<tkamppeter> On Saturday they only told me that the gs-common is not really needed.
<pitti> tkamppeter: I mean when they dropped gs-common
<stgraber> seb128, pochu: bug 175288
<ubotu> Launchpad bug 175288 in gnome-keyring "[Hardy] SSH key kept unlock after usage" [Undecided,New] https://launchpad.net/bugs/175288
<seb128> stgraber: thanks
<tkamppeter> pitti, I merged with Debian on the last upload (8.61.dfsg.1-0ubuntu2) and Debian did not remove gs-common
<pitti> tkamppeter: hm, then maybe the newer gs-commons don't have any files any more, so that they don't conflict?
<pitti> cjwatson: done
<tkamppeter> gs-common got a transitional (without files) when I introduced the merger of ESP and GPL GS with the name ghostscript into Ubuntu. In Debian Masayuki Hatta introduced this ghostscript on Oct 14.
<pitti> tkamppeter: ah, ok; that should be fine then
<pitti> tkamppeter: so why again do you want to modify anything?
<tkamppeter> pitti, so I will remove gs-common
<pitti> tkamppeter: but that will break several reverse dependencies
<tkamppeter> pitti, the motivation to make a ghostscript package is fixing bug 172264
<ubotu> Launchpad bug 172264 in ghostscript "Ghostscript in Gutsy and Hardy is not able to print encrypted PDFs out of Adobe Reader 8.1.1" [High,In progress] https://launchpad.net/bugs/172264
<pitti> tkamppeter: TBH I wouldn't bother ATM and just leave the transitional package as it is until Debian removes it
<tkamppeter> pitti, so better leaving gs-common in?
<pitti> tkamppeter: right; just apply the patch and you should be good AFAICS
<tkamppeter> pitti, OK, so only the patch for bug 172264 ...
<pitti> tkamppeter: I agree that it would be cleaner to remove it, but then we have to do the transition and introduce a delta
<pitti> tkamppeter: right
<StevenK> Hobbsee, pitti: Can you give-back asterisk on all arches, please?
<pitti> StevenK: done
<StevenK> pitti: Danke!
<Hobbsee> pitti: can you shove meta-kde4 sources and binary to universe please?
<Hobbsee> pitti: they're currently in main
<Hobbsee> er, source and binaries
<pitti> Hobbsee: done; hm, there are no binaries, is that correct?
<Hobbsee> pitti: i've only just accepted the binaries
<pitti> ah
<Hobbsee> i'm not sure how long they take to publish
<pitti> about an hour
<pitti> but I can move them in ACCEPTED
<Hobbsee> which does what?  where are they now?
<Hobbsee> in limbo, or in accepted?
<pitti> ok, done
<Hobbsee> thanks
<pitti> Hobbsee: they are not published yet, but in the ACCEPTED queue ("to be published")
<Hobbsee> ah right
<Hobbsee> so accepted is the limbo.  got it.
<Hobbsee> launchpad is so confusing, at times.
<StevenK> At time, you say?
<StevenK> times, even
<Hobbsee> yeah well.
<Hobbsee> the stuff that has documetation probably isnt' too bad
<cjwatson> the modern display of the ACCEPTED queue is a whole lot less confusing than it used to be, and IIRC less confusing than the same state in dak
<cjwatson> FWIW
<Hobbsee> cjwatson: i'm comforted :)
<Hobbsee> cjwatson: progress is good!  :)
 * Fujitsu notes that it's even more confusing now that sources don't ever go through ACCEPTED.
<cjwatson> in the modern Launchpad display, it just shows up as DONE (and you might be a little confused for a short while, but at least you know it exists somewhere)
<cjwatson> in old-Launchpad and dak, the corresponding state meant that the package was invisible and you had no idea what was going on
<cjwatson> so I think it is definitely an improvement
<Fujitsu> Sources used to go through ACCEPTED, though.
<cjwatson> the DONE-but-not-yet-published state existed regardless, merely at a different time
<Fujitsu> Right.
<cjwatson> it used to be ACCEPTED -> DONE (but not published, so limbo) -> published
<cjwatson> now it's DONE (not published, but you can see its state) -> published
<cjwatson> except when the distro is frozen in which case ACCEPTED is still involved
<lamont> tjaalton: sup? (fbset/hppa)_
<lamont> *** You don't have any defomized font packages.
<lamont> *** So we are trying to force to generate pangox.aliases...
<lamont> there's just something about that inglish there... :)
<tkamppeter_> pitti, patched Ghostscript is ready for upload.
<tjaalton> lamont: right, so our xserver-xorg.postinst has carried a diff that uses fbset for hppa, with a note that the functionality should be moved to xresprobe. Well, xresprobe is now going away, and the idea is to rely on the server&drivers to do the right thing insted
<tjaalton> *instead
<lamont> ah, right.
 * lamont looks at xserver-xorg.postinst
<tjaalton> lamont: so the question is, will something break?
<Hobbsee> tjaalton: we'll find something to blame you for breaking, yes.
<Hobbsee> whether it was your fault or not is entirely different.
<tjaalton> hehe
<lamont> tjaalton: how about if we comment it out for now?  then I'll have an idea of what I have to fix if it does break?
<lamont> tjaalton: and of course something will break... Hobbsee will see to that.
<tjaalton> lamont: well, I think the whole xresprobeint() will be deleted :)
<lamont> tjaalton: ah, well then, OK.
<Hobbsee> tjaalton: and while you're at it, fix whatever needs to be fixed so my system stops crashing please :_
<lamont> Hobbsee: PEBCAK
<Hobbsee> lamont: hmph :P
<lamont> tjaalton: the one gutsy/hppa box I have easy access to doesn't have a graphics card... I'll look at one in the office otday
<tjaalton> 05:24 < gravity> This shouldn't even work really, unless xresprobe isn't present
<tjaalton> 05:24 < gravity> If it is, the fbset call on hppa will get overridden by xresprobe, and you're  back where you started
<tjaalton> 05:28 < gravity> Plus the fbdev driver should get the resolution from the fbdev interface
<tjaalton> lamont: ^
<tjaalton> lamont: ok, so you could try commenting that out and see what happens?
<tjaalton> Hobbsee: I think we came to the conclusion that it was compiz :)
<cjwatson> lamont: you have a fair few main merges on your list; do you need help with them?
<Hobbsee> tjaalton: and amaranth says it's the driver giving bogus things, and compiz dying over it.
<lamont> cjwatson: ah yes.
 * lamont should do those.
<tjaalton> Hobbsee: it's intel, so there you go :)
<lamont> cjwatson: anything where I'm not the debian maintainer can be considered fair game, and I'll get on them later today.
<lamont> today I need to spend the morning explaining something to a customer.
<Hobbsee> tjaalton: so, fix it for me please :)
<lamont> (and the ones where I am the debian maintainer, I'll do first.)
<Hobbsee> you're hte X whiz ;)
<lamont> Hobbsee: apt-get remove --purge compiz
<tjaalton> Hobbsee: heh, well I guess bryce is more uptodate with intel than me :)
 * lamont thought keithp was the X whiz...
<tjaalton> and no, I'm not :)
<Hobbsee> you lot all are, compared to me :)
<Hobbsee> lamont: yeah well.  i'd prefer *not* to do that.
<Hobbsee> if i were to do that, then i may as well go back to kde as well
<lamont> Hobbsee: perish the thought.
<Hobbsee> why?
<tjaalton> Hobbsee: I'll get a stinkpad X61s soon, so if I'm hit with the same bug then I'll take a closer look at it :)
<Hobbsee> heh :)
<StevenK> Stinkpad? I lost that opinion of them when I got an X40
<Hobbsee> tjaalton: if you were actually here, you could borrow my laptop for a bit or something.  but you're a bit far away
<tjaalton> StevenK: yeah, I currently have a T23, and had a X60 at UDS and it was niec
<tjaalton> niec
<tjaalton> uh, niCE
<azeem> so why do you call it stinkpad?
<tjaalton> Hobbsee: put it in a bottle, it'll get here sooner or later ;)
<seb128> StevenK: any news about the gimp update to hardy?
<tjaalton> azeem: ok ok, Thinkpad!
<seb128> StevenK: to gutsy rather
<StevenK> seb128: Geh?
<StevenK> seb128: Oh, right.
<Hobbsee> tjaalton: hah.
<Hobbsee> tjaalton: then i'll have no internet!
<StevenK> Oh yeah, those users we want to silence
<seb128> yes
<sladen> tjaalton: I gave back the T60 with the job at the weekend, so don't have an ATI anymore
<StevenK> seb128: I think it'll be a fun merge. :-/
<seb128> StevenK: there is no merge when doing a SRU, it's basically taking the gutsy version and running uupdate
<lamont> doko: gcc-3.4 is your's, contrary to what http://merges.ubuntu.com/main.html may say... I just triggered a rebuild...
<lamont> (please)
<seb128> dholbach: will you do your main merges or should we look at taking over those?
<StevenK> seb128: My problem is ABI bumps
<lamont> doko: and zope3... what's a "fake sync"?
<Hobbsee> lamont: differing .orig.tar.gz sums
<doko> lamont: gcc-3.4 doesn't need a sync
<dholbach> seb128: if you find somebody to do them, I'm happy
<doko> lamont: listen to that women ;)
<seb128> StevenK: ABI? there is a libgimp and it changed because RC3 and 2.4?
<seb128> dholbach: well, somebody will be me ;-)
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<StevenK> seb128: I think the shlibs file changed at least
 * lamont wonders why we have a different orig.tar.gz
<Hobbsee> mmm...merges
<seb128> StevenK: ABI bump usually is no issue, ABI breakages are
<cjwatson> anyone brave enough to take the e2fsprogs merge?
<Hobbsee> lamont: does upstream distribute as a .tar.bz2?
<Hobbsee> cjwatson: s/brave/insane/
<cjwatson> looks like Ted solved a similar issue differently from how Ian addressed it
<StevenK> soren is
 * StevenK hides
 * lamont picks Ted's solution.
<soren> I'm waht?
<lamont> :-)
<cjwatson> so the merge will not be trivial
<soren> Erk..
<cjwatson> it looked to me as if Ian's fix was a bigger hammer and perhaps less likely to result in the bug coming back
<lamont> doko: gcc-3.4 needs an upload to shut up MoM then
<cjwatson> but also potentially less correct; hard to say
<seb128> soren: I'll do your tsclient merge if you didn't start on it, that's sort of a desktop team package
<doko> lamont: not really
<soren> seb128: That would be great. I only did it to score experience points for my core-dev application :)
<seb128> soren: ok, will do it then
 * soren hugs seb128 
<doko> lamont: it's a changed tarball (to exclude the gfdl docs) which we do not want
<lamont> http://merges.ubuntu.com/main.html  3.4.6-6ubuntu2 	3.4.6ds1-6 	3.4.6-4
<lamont> doko: but MoM won't leave us alone until the hardy version is higher than debian
<cjwatson> I think such cases are OK to ignore in MoM
<doko> lamont: just ignore MoM on these two cases
<lamont> cjwatson: cool
<cjwatson> doko: you could add a blacklist feature to MoM, if there isn't one already, maybe?
 * lamont doesn't like to bitchslap MoM. :0)
<StevenK> MoM already blacklists certain packages, I thought
<tjaalton> sladen: hmm, so you had some ATI bug you reported or..?
<lamont> doko: also, I finally gave in and turned on unaligned on the buildds... so what do we need to do about java?
<doko> cjwatson: yes, maybe it's worth that
<cjwatson> StevenK: it's entirely possible it just needs stuff added to a list, yes
<sladen> tjaalton: yeah, this whole, y'know ...avivo thing.
<sladen> tjaalton: puts a damper on fixing any fixing any more issues on that laptop
<tjaalton> sladen: "There are currently no open bugs" :)
<Hobbsee> uh oh.  everyone behave.  sabdfl is here.
<lamont> Hobbsee: that was your out-loud voice.
<Hobbsee> oh, whoops
 * Hobbsee resends it, telepathically then.
<lamont> morning sabdfl
<tjaalton> sladen: anyway, no worries
<lamont> cjwatson: like udev? :0)
<sabdfl> howdy folks
<lamont> (it took me a while to come up with an example...)
<pitti> hi sabdfl
 * lamont takes kids to school.  offline for about an hour
<soren> cjwatson_: FWIW, I think Ted's approach looks sufficiently sane. Ian's patch might do the trick, too, but (not surprisingly) Ted's is more correct. I vote for Ted's approach, too.
<slomo> asac: whats with mono
<asac> slomo: its about csharp gtkmozembed binding for xulrunner 1.9 ...
<asac> slomo: do you know how to interface with native libs in mono?
<cjwatson> pitti: you set the bug to fix-committed, but finish-install still seems to be in the gutsy-proposed unapproved queue
<pitti> huh? /me must be asleep then
<pitti> cjwatson: sorry, accepted now
<cjwatson> thanks
<slomo> asac: yes... http://www.mono-project.com/Interop_with_Native_Libraries
<slomo> asac: so you want to create one or there is one?
<slomo> asac: (gecko-sharp(2) already exists)
<asac> slomo: yes, but it needs to be adapted for xul 1.9
<slomo> asac: bbl, write me a mail please slomo@ubuntu.com
<slomo> sorry
<asac> slomo: ok thanks
<seb128> asac: read my question on #ubuntu-desktop? ;-)
<asac> seb128: which?
<pitti> slomo: did you see my /msg?
<geser> pitti: in case you missed my previous request, please give-back: gabber giblib libtk-img nspr. Thanks.
<pitti> geser: done
<pitti> Lure: got a minute to talk about digikam?
<Lure> pitti: yes
<pitti> Lure: I just spent some time reading http://bugs.kde.org/125696
<pitti> Lure: in short, digikam does not find libgphoto plugins because kdelibs has its own nonstandard libtdl
<pitti> Lure: Debian has a normal libgphoto, and digikam depends on libgphoto2-dev
<Lure> pitti: I think that should be fixed in hardy - last merge of kdelibs got proper fix from debian
<pitti> so that it gets the .la files
<pitti> Lure: oh, great; it uses the system libtdl now?
<pitti> Lure: I would like to drop the libgphoto Ubuntu delta for the .la files, and also the digikam delta
<Lure> pitti: did not check the actual kdelibs, but the comment is very clear that it fixes need for .la files
<pitti> Lure: awesome
<pitti> Lure: so we can get rid of both deltas
<Lure> pitti: I paln to merge digikam and recent digikam in debian already droped -dev depends
<pitti> Lure: I'll merge libgphoto2 now; please cry out if it causes any problems
<pitti> rock
<Lure> pitti: good, will check probably tonight/tommorow when I will look in digikam merge
<Lure> pitti: http://packages.debian.org/changelogs/pool/main/k/kdelibs/kdelibs_3.5.8.dfsg.1-4/changelog
<Lure> pitti: btw, am I ok to merge from debian/expirimental instead of the version suggested by MoM?
<pitti> Lure: absolutely, if you tested it
<pitti> well, since we always test our uploads anyway, that doesn't add any constraint, right? :)
<Lure> pitti: will do, digikam 0.9.3 will be released before our FF, so will pick beta from experimental
<Lure> pitti: ;-)
<pitti> that sounds fine; early testing FTW
<Lure> pitti: I have to test at least my main packages not to get ugly looks from Riddell (who is sponsoring uploads) ;-)
<evand> does anyone want to pick up the syslinux merge?  I gave it a shot, but my assembly-foo just isn't strong enough to rework the gfxboot patch.
<soren> evand: I think doko was trying a few days ago, too?
<evand> oh, perhaps we just overlapped.
<evand> Fantastic, if he is.
<stgraber> I'm doing the iTalc integration for Edubuntu/LTSP and trying to move to clean way to logout/shutdown/reboot for the different desktops, KDE was easy with DCOP, now I'm trying to find an equivalent for gnome
<stgraber> what I need to do is to have a scriptable way to close the session and trigger the shutdown/reboot action of gdm
<stgraber> I tried with gdm-signal without much success and "gnome-session-save --kill" just shows the logout box instead of directly triggering a direct logout
<stgraber> oh, I just noticed the --silent for gnome-session-save, so this one is good
<stgraber> but I still need to find a way to shutdown/reboot :)
<seb128> stgraber: gnome-keyring upstream argue that storing the passphrase is the purpose of an ssh-agent so that's not a bug, they have a point there ;-)
<stgraber> seb128: yes, but maybe I don't want to use the agent and still enter my key instead of the password :)
<stgraber> seb128: currently I have no way to just enter my key and not see it stored :)
<seb128> stgraber: right, which is a different issue of the one you described
<seb128> well, don't use an agent if you don't want it stored
<seb128> which is wishlist for "make the agent being optional"
<stgraber> that's a regression (vs standard SSH without any external agent) :)
<seb128> stgraber: right, and that will be fixed before hardy
<stgraber> my current problem is that I want the keyring part of the daemon but not the SSH one and I have no way to fix that as I can't simply kill it + reload with the -c thing (the env variables would point to a no longer existing process ID)
<seb128> stgraber: agreed, there should be a gconf key or something to set for people who don't want the ssh agent
<seb128> stgraber: about the reboot option, gdm-signal should do that, if it doesn't work it should be fixed
<seb128> stgraber: or maybe you can speak to gnome-power-manager over dbus like for suspend and hibernate
<pochu> seb128: but if the ssh agent will store it anyway, what's the point of the 'Remember me' check box?
<stgraber> pochu: I think it'll remember not only until the session close, but even after you logout
<pochu> stgraber: oh, that makes sense.
<seb128> pochu: it stores it in the keyring
<seb128> pochu: so it's available for next sessions
<stgraber> seb128: ok, just gave gdm-signal a try on Hardy and it doesn't work either, so it's not working on Feisty/Gutsy/Hardy :) I will file a bug
<stgraber> seb128: but I suspect a bug in gdm itself for this one as stracing the gdm-signal shows that it correctly sent the actions (SET_LOGOUT_ACTION REBOOT) and received an OK from the gdm server ...
<seb128> stgraber: well, that's the logout action, you need to log out then
<stgraber> oh, right :)
<stgraber> It was easier to do with KDE :) (just send a DCOP signal and that's it)
<seb128> stgraber: with the new gdm (might not land in hardy) that will likely be a signal to send over dbus
<stgraber> cool
<seb128> stgraber: looks like gnome-power-manager has methods for that already, so talking to it over dbus should work there
<bryce> heya stgraber
<stgraber> hi bryce
<cjwatson> mdke: will you have a chance to do your gnome-user-docs merge by Thursday?
<soren> evand: I'm not sure if he actually finished it. I'm looking at it right now, too, actually. I'll give it a shot. Give me... 15 minutes.
<cjwatson> calc: there's an hsqldb merge outstanding that looks (at first glance, though please check) as if it may be a sync; could you look at this?
<calc> cjwatson: ok
<calc> cjwatson: i am fairly certain it is just a sync
<calc> cjwatson: will verify it now
<evand> thanks soren
<cjwatson> doko: stealing your libept merge, which I believe is a sync (only remaining diff is the apt build-dep which we don't have to keep as a delta)
<calc> cjwatson: yep its a sync
<calc> cjwatson: should i file a sync bug or is there someone who can do the sync right now?
<cjwatson> calc: I'll do it now, thanks
<cjwatson> ajmitch: is python-mysqldb a sync? I didn't check all the details, but Debian builds the -dbg package now
<cjwatson> lamont: stealing your db4.3 merge; it's a sync because Clint dropped Java support altogether
<cjwatson> doko: stealing freeglut, which is a sync
<ScottK> cjwatson: While you're doing sync's, would you please have a look at Bug #175036
<ubotu> Launchpad bug 175036 in lintian "Please sync lintian (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/175036
<geser> cjwatson: a sync request for freeglut was filed as bug #174729 already
<ubotu> Launchpad bug 174729 in freeglut "Please sync freeglut 2.4.0-6  (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/174729
<cjwatson> ScottK: whoa. You've checked that in detail?
<cjwatson> geser: oh, whoops, missed that. I'll close, thanks
<cjwatson> sigh, and fltk1.1 too
<ScottK> cjwatson: Yes.  I reveiewed the entire diff between what we have and the new revision.  I've also been using it since I did.
<soren> I think I might have managed syslinux. I'll need to take it for spin first, though.
<ScottK> cjwatson: Laserjock has merged lintian before and so I think his ack is worthwhile too.
<ScottK> cjwatson: The reason I ask is so the I can get the backport request for gutsy in.
<cjwatson> nod, it just surprised me :)
 * ScottK too.
<pitti> cjwatson: I checked fltk1.1, ack'ing
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.  I've already tested it in Gutsy.  Any chance you could just run the magic backport script or do you want a bug for that?
<cjwatson> I'm supposed to be going shopping, but sure, just for you ;-)
<ScottK> cjwatson: Thanks.  persia will be happy too.
<ScottK> He's the one that guilted me into reviewing it in the first place.
<doko> evand, soren: I asked upstream; the gfxboot part isn't yet updated
<cjwatson> ScottK: feisty has a lintian backport too; should it be updated?
<soren> doko: I think I've managed to do it.
<soren> doko: I'll know in a bit.
<cjwatson> ScottK: oh, err, can't run backport-source until it's actually in the archive
<cjwatson> ScottK: remind me later
<ScottK> cjwatson: I would assume so, althougth I haven't personally tested it.  Let me file a bug for that so someone can check.
<ScottK> cjwatson: Will do.
<ScottK> I'll probably just file the bug so I don't forget.
<ScottK> Thanks again.
<geser> could someone please sponsor bug #157668 and bug #174749?
<ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20071203-1ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/157668
<ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
<coNP[uni]> geser: this means testing and eventual uploading?
 * coNP[uni] was sure graphviz is in universe.
<geser> coNP[uni]: graphviz is in main and currently in depwait as libttf-dev is in universe
<coNP[uni]> (sure, I checked that inbetween)
<lamont> cjwatson: cool
<soren> Well, syslinux compiles now. That's a good start.
<elmo> ship it
<soren> :)
<LaserJock> any archive admins about?
<LaserJock> I'm not sure why goffice0.4 hasn't made it into Hardy, we don't have to explicitly ask for new packages from Debian do we?
<ScottK> LaserJock: Not for another 3 days.
<ScottK> I don't think.
<LaserJock> hmm, it's been over a month since it made it into Debian
<pochu> LaserJock: maybe it's blacklisted
<LaserJock> pochu: do you know where the blacklist is?
<elmo> http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt
<pochu> LaserJock: goffice0.4 # pitti, transitional oldlibs in Debian
<LaserJock> pochu: bah
<LaserJock> that's not right at all
<LaserJock> elmo: do you have power to fix that or do I need to wait for pitti?
<elmo> LaserJock: I'm just pasting links, I don't have any power in this area :)
<elmo> I think you want  any archive admin tho
 * LaserJock liked the days when the answer to anything was "ask elmo" but I suspect elmo doesn't feel the same ;-)
<LaserJock> hmm, I don't know why Debian ftpmasters did an override to send it to oldlibs
<LaserJock> the source package has libs I think
<LaserJock> so ... any archive admins still around today?
<ScottK> LaserJock: Riddell's been active in #kubuntu-devel recently.
<LaserJock> Riddell: can you do an ubuntu-archive favor for me and un-blacklist goffice0.4 ?
<Riddell> not something I've done before
<Riddell> LaserJock: what's the reson?
<LaserJock> Riddell: because it shouldn't have been blacklisted to start with :-)
<LaserJock> it is a new version of goffice (goffice is currently 0.5) to make sure apps other than gnumeric can build
<LaserJock> I've been waiting on it for a couple of merges
<soren> \o/ isolinux boots.
<Riddell> "goffice0.4 # pitti, transitional oldlibs in Debian" LaserJock have you confirmed it with pitti?
<LaserJock> no, but that's wrong
<LaserJock> for some reason Debian put it into oldlibs when it shouldn't have
<LaserJock> and I'm guessing that's why he did that
<LaserJock> but it's not transitional
<LaserJock> it's barely 1 month old
<LaserJock> and the stable version of the library
<LaserJock> I can take it up with pitti if you're not comfortable with doing it
<Riddell> LaserJock: I expect you're right but I'd like to check with pitti first, please file a bug and subscribe ubuntu-archive and ask pitti to comment
<Riddell> it's my archive day tomorrow anyway
<LaserJock> alright, will do
<soren> evand: I believe syslinux is done. I'll upload in a bit.
<evand> Fantastic.  Thanks a bunch, soren
<soren> \o/
<soren> it at least builds and isos boot fine. I haven't tested anything else yet.
<mdke> cjwatson: I will have a go at merging from Gnome, but I doubt I'll be able to look at any changes to the packaging in Debian by thurs. Unlikely there is anything significant
<warp10> Hi all!
<emes> where can I get the kernel config file for the stock kernel?
<sn0> emes this isn't really the channel to ask, see topic. but check in /boot/
<emes> thanks
<soren> Hm... firefox is throwing SIGBUS all over the place.. Highly annoying.
<soren> who can fiddle with PAS?
<soren> Archive admins? buildd admins?
<slangasek> soren: "lamont, elmo, and infinity", I think?
<slangasek> AFAIK Ubuntu pulls directly from the same source that Debian uses, and they're the maintainers of that file
<soren> Ok.
<soren> I just noticed that lpia was added to the list of architectures in the syslinux package, but there are no build records for it. I'm assuming this is due to pas.
<slangasek> http://buildd.debian.org/quinn-diff/Packages-arch-specific says yes
<soren> Interesting.
<soren> lamont: Could you add lpia to the list of architectures for which we build syslinux?
<soren> slangasek: Have you by any chance seen the e2fsprogs merge?
<slangasek> soren: no
<soren> slangasek: Ok.
<slangasek> soren: I can take it, though
<soren> slangasek: I looked at it already.
<slangasek> ok
<soren> slangasek: I'm just looking for a second opinion.
<soren> slangasek: The thing is that Ian made a workaround for bug 131201, and now upstream has provided a different workaround.
<ubotu> Launchpad bug 131201 in e2fsprogs "always fscks first boot after install" [Low,Fix released] https://launchpad.net/bugs/131201
 * slangasek gets really, really tired of seeing that bug :)
<soren> slangasek: I can imaginge.
<soren> slangasek: Ian's patch basically ignores the error, while the upstream fix allows the sb->s_lastcheck to be up to 24 hours in the future.
<slangasek> hmm
<slangasek> I suppose that should cover it, yes
<soren> slangasek: I vote for upstream's approach, but this is not entirely my area of expertise.
<slangasek> I do too :)
<soren> Cool. I'll file the sync request tomorrow.
 * soren head to bed
<slangasek> 'night
<soren> 'night :)
#ubuntu-devel 2007-12-11
<keescook> oh whoa.  I didn't realize you could actully debdiff .deb files.  :P
<elmo> haha
<elmo> and changes files
<keescook> yeah... just reading the manpage now.  :P  I've used it on .dsc for so long I didn't even think it could be used for other things. heh
<Pelo> evening guys,  can I ask a silly question ?
<Fujitsu> Pelo: Perhaps, if it is related to Ubuntu development.
<Pelo> why doesn't the live cd default to vesa when detecting a nvidia or ati video card ?
<Pelo> does that count ?
<Fujitsu> That looks like an appropriate question, but I can't answer it.
<Pelo> I've been giving out ubuntu cds and dvd telling ppl they could try it without installing but this particluar issue is becomming a problem, I get why it doesnt have ati or nvidia driver , the non FOSS thing, but I started to wonder why not just vesa in those case, that is what get's instaled anyway
<LaserJock> Pelo: what does it do currently?
<Pelo> LaserJock,  is just fails
<LaserJock> hmm, I think it's supposed to fall back to vesa
<Pelo> ifyou try the live cd or live dvd on a comp with either an nvidia or an ati videocard it just doesn,t recognise it
<Pelo> LaserJock,  during the install yes,
<Pelo> well in text mode instal anyway it will instal the vesa driver
<Pelo> mind you,  I'M starting to wonder if it is not supposed to be fixed in gutsy
<Pelo> I dont, hae a nvidia card myself so I don'T have this particualr problem but friends have , and there are a lot of ppl comming into the support channel with this issue as well
<LaserJock> Pelo: I wonder if it's just certain cards or something
<Pelo> LaserJock,  I think some older cards might work but they seem to be the exception
<Pelo> any way I have to go,  consider it a suggestion for the hardy live cd if nothing else
<Pelo> thanks for your time
<LaserJock> thanks for stopping by
<cellofellow> hello
<cellofellow> Why did my spec, https://blueprints.launchpad.net/ubuntu/+spec/dapper-to-hardy, not get excepted and this one, https://blueprints.launchpad.net/ubuntu/+spec/lts-upgrades, did? They accomplish the same thing.
<cellofellow> I think it has something to do with how I worded it, but not sure. I never submitted a spec before.
<cellofellow> Why did my spec, https://blueprints.launchpad.net/ubuntu/+spec/dapper-to-hardy, not get excepted and this one, https://blueprints.launchpad.net/ubuntu/+spec/lts-upgrades, did? They accomplish the same thing.
<cellofellow> I think it has something to do with how I worded it, but not sure. I never submitted a spec before.
<slangasek> cellofellow: repeating yourself is not necessary...
<slangasek> cellofellow: the reason lts-upgrades was accepted is that it's the one that includes the link to the full specification with design information, https://wiki.ubuntu.com/LTSUpgrades
<slangasek> it appears that the lts-upgrades blueprint was also created 5 months earlier...
<cellofellow> slangasek: sorry about the repetition, I just saw knew people in the channel and wanted them to hear too.
<cellofellow> slangasek: I couldn't find dates in the Blueprints stuff.
<slangasek> cellofellow: the dates are shown under "lifecycle" on the left
<cellofellow> so, what's some advice for spelling out specs in the future
<cellofellow> (I did try to find one that was like this before submitting. I guess I just didn't search the right terms.)
<slangasek> cellofellow: well, in general terms, communicating with the developers who are going to have to do the work to make it happen is an important first step. :) For many specs, this happens at UDS where the developers are face-to-face
 * lamont looks around for a package that delivers both python2.4 and 2.5 .py files
<lamont> site-packages type, eh?
<RAOF> lamont: python-pyinotify?
<lamont> kewl
<LaserJock> hmm, in general packages aren't supposed to do that are they?
<lamont> IRC works even better than google for somethings...
<RAOF> No, in general packages are supposed to ship .py for as many python versions as possible?
<LaserJock> IRCpedia
<RAOF> Oh.  Except they won't actually be shipping different .py files in the deb, the postinst script will be doing byte-compiling for all the installed python versions.
<LaserJock> well, they should ship .py and let python-central/python-support handle versions
<RAOF> Heh.  We converge on the answer from different directions :)
<lamont> LaserJock: except that if you want pycentral to handle versions for you, you still have to build 2.4 and 2.5
<lamont> as I've been learning.
<LaserJock> why?
<lamont> doko told me that if I want 2.5 versions, then I need to build them.. is that not the case>
<lamont> package currently delivers python2.4/site-packages/$mumble...
<LaserJock> hmm, that's weird
<lamont> are you telling me that 2.5 will magically appear?
<LaserJock> I thought so
<lifeless> es
<lifeless> bleh
<lifeless> you tell pycentral what versions you want
<lifeless> it then in the postinst symlinks and byte compiles appropriately
<lamont> lifeless: and deliver .py files where?
<lifeless> if you ahve a C extension they get built for the python version specifically.
 * lamont notes that pyinotify specifically builds both versions
<LaserJock> that's weird
<LaserJock> I don't know why it would do that
<LaserJock> unless it's legacy
<lifeless> lamont: dpkg -L python-gmenu
<lamont> maybe it cloned from another package like I just did from it??
<lamont> hrm... OK.
<lifeless> lamont: pyinotify probably has a C extension in it
 * lamont tweaks his source again
<lamont> hrm...  can I put wild cards in ${package}.files, I wonder....
<RAOF> LaserJock: Yeah.  It's the C extension.  It has to be built against each python version.
<RAOF> LaserJock: Or you get the pyinotify bug I fixed, where you could use it in 2.5 but not in 2.4 :)
 * lamont can hardly wait to see if there are any .so files in the build
 * RAOF thought ${package}.files was generally generated during package build?
<lamont> RAOF: in my experience, I've generated it myself
<lamont> as in it's checked into source control
<RAOF> Maybe I was thinking of something else.
<persia> lamont: Some of the automated package checkers say it's deprecated (although it may still be required for your packages)
<lamont> given that dh_movefiles uses it, and I use dh_movefiles...... :-)
<RAOF> Oldschool
<LaserJock> lamont is deprecated ;-)
<lamont> feh
<lamont> you kids always creating new crackful ways of doing things...
<lamont> why when I was a kid..... :-)
<LaserJock> did you use CDBS?
 * persia notes that dh_movefiles is more new-fangled than just calling install lots of times.
<lamont> LaserJock: hell no.
<lamont> CDBS is a maze of twisty mess
<lamont> the only good thing about it is that it's miles less crackful than DBS
<lamont> then again, when I look at a makefile, I want to look at a makefile
<persia> I also like it because it tends to reduce the use of debian/rules as a "bash script"
<lamont> not an include of something that takes side-effects from  a number of strange variables in the top level makefile
<lamont> LaserJock: I expect that if I adopted a package using CDBS, it'd not be using CDBS sometime shortly thereafter.  (for DBS, make that certainly wouldn't be :)
<lamont> and these days, ditto for dpatch/quilt/etc.
<LaserJock> if it's a really easy package where you can do a 2-line debian/rules it's not bad
<LaserJock> but I tend to stay away from it
<lamont> first I'd have to learn CDBS.  and that would tend to make me drop in a trivial example debhelper makefile and be done.
<LaserJock> seems like if I run into some problem it's always "solved" by some totally cryptic rule
<lamont> my usual approach to fixing FTBFS packages with CDBS is to pester people who understand CDBS.
<lamont> (since it's someone elses package, and ripping CDBS out to fix an ftbfs is kinda, um, rude. :)
<LaserJock> heh, how about adding CDBS to fix a ftbfs? :-)
<LaserJock> lamont: not a fan of dpatch?
<lamont> I'd rather see my code as it will build.  dpatch isn't so bad, other than the pain of not seeing exploded/patched code while you're working on it.
<lamont> SCM belongs in SCM.  implementing SCM in dpkg is kinda silly
<LaserJock> so what do you do?
<LaserJock> make upstream fix everything so you don't need patches? :-)
 * lamont has the, uh, privilege of working on the debian-packaged kernel for his day job.  That package boasts the ability to produce any earlier version of the package from the source package.
<lamont> LaserJock: git clone git://git.debian.org/~lamont/bind9.git
<lamont> that'd be one of my packages
<lamont> if you want to see the patches, go to the SCM.  if you want to build the source, there's this nice monolithic patch in diff.gz. :-)
<LaserJock> right
<lamont> I was using dpatch before (when my packages were all in cvs and arch and old bzr).  When I switched everything to git, I retired my dpatch usage.
<LaserJock> not to bzr?
<lamont> and adding cdbs to fix an ftbfs would be equally rude.... and very unlikely to be adopted by the debian maintainer (unless he told you to do it...), so your patch becomes unwieldy
<lamont> I deal with git all day.
<lamont> and bzr infrequently.
<LaserJock> makes sense
<lamont> and bzr and I didn't understand each other wrt repositories at the time.  so git won.
<lamont> I expect that bzr has everything I care about now, so it's just a question of familiarity
<lamont> and bzr checkouts have historically caused me pain in my bandwidth meter.  I expect that's improved now, too.  right lifeless?
 * lamont has no real recent bzr history
<LaserJock> lamont: how do you handle a new upstream release when the whole source is in git?
<lamont> LaserJock: in the ideal case, I say 'git fetch origin' (see util-linux)
<lamont> :)
<LaserJock> well, yeah
<ion_> I switched from bzr to git a while ago. Subjectively git seems faster (i havenât done actual benchmarking, though) and i just love how it handles branches as opposed to bzr.
<LaserJock> but that's more of a corner case at this point
<lamont> in the less ideal case, I smash the new upstream in as one (or maybe more if I'm in a good mood) commits into either the upstream branch, or upstream git repo
<LaserJock> do you keep debian/ in a separate branch?
<persia> lamont: Do you use pristine-tar, or just pull the upstream externally?
<ion_> I learned about âbzr switchâ after the fact, but it only comes a few steps closer to how nicely git handles them IMHO.
<lamont> hrm.. of 9 packages: 1 in git upstream, 1 where I _am_ upstream (git), and 1 with published upstream cvs, 1 with unpublished upstream cvs, and the rest are tarball only uploads
<lamont> LaserJock: debian exists only in the debian branch, which is derived from upstream.
<LaserJock> ok
<lamont> git branches are decended from things, not separate source trees.
<lamont> so it makes sense (in some way) to have two repos for upstream and debian, or one repo for the combination.
<lamont> different source on different branches is contrary to the design.
<lamont> at least as far as I understand it
<lamont> persia: pristine-tar?
 * persia goes to find a pointer to docs
<lamont> if there's an upstream SCM, I pull from it for my tree.  Where there's not an upstream SCM, then the upstream tarball gets to get unpacked and committed.
<slangasek> pristine-tar is joeyh's "recreate tarballs from repos" trick
<lamont> ah
<lamont> given that gzip tends to give a different hash everytime I create a tarball, I just use the upstream tarball.
<slangasek> which I'm still waiting to hear of a naming convention for, that's recommended for use with things like svn-buildpackage
<persia> known to work with git, but I didn't know if anyone other than joeyh actually used it.
<slangasek> lamont: it has an extension that's supposed to be usable for recreating tgz as well
<persia> lamont: git://git.kitenet.net/pristine-tar/
<lamont> I may have to look at that.
<LaserJock> so the problem is that often the tarball downloaded from upstream has a different md5sum than a tarball created from the identical files in a SCM?
<persia> LaserJock: Yes, and moreso that the gz of the tarball has a different checksum as well.
<lamont> OTOH, I had a nice chat today with a coworker about how to have an upstream branch, from which was derived a debian branch, and package a .orig.tar.gz and a diff.gz that delivered a debian/patches/foo and friends, so that the build process could untar upstream/tarballs/*.gz and patch them, and such
 * lamont throws nmap at the grinder again, just for good measure. I might actually manage an experimental upload tonight
<lamont> ScottK: pinentry is your merge - I just did a trigger rebuild...
<lamont> OTOH, no reason I can't do it
<persia> lamont: It's late there: you may be waiting ~6-8 hours for a response
<LaserJock> hmm, jbailey seems to be sending me lots of pharmaceutical offers ;-)
<lamont> feh.  he can't stay up until 1:30 AM just to talk to me?
<lamont> OTOH, bed time for me too... alarm clock in 5.5 hours.
<ion_> Has anyone noticed compiz hanging, like, all the time, after an update a couple of days ago?
<lamont> ion_: I thought that was it's purpose. :-)
<ion_> Iâll take a look at LP bug reports.
<lamont> (was that my out-loud voice?)
<ion_> :-)
<lamont>         dh_installman -pzenmap docs/zenmap.1
<lamont> so why does zenmap.1 wind up in the nmap package instead, I wonder.
<LaserJock> maybe CDBS hear your comments earlier and switched out dh_installman with it's own, more nefarious, version
<lamont> heh
<choudesh> where are the nightly build ISOs at for Hardy?
<lamont> cdimage.ubuntu.com/daily or so
 * lamont workraves while the build runs
<choudesh> lamont: is the script available that starts this nightly ISO build?
<lamont> ??
<choudesh> what software do they use to create the nightly builds or do they just have scripts as cron jobs?
<lamont> the script that starts the build is run either from cron, or manually, on some machine in the data center.
<lamont> and, iirc, that stuff is checked into bzr somewhere.
<lamont> the livefs is built by the package livecd-rootfs, iirc
<lamont> and that's in the archive
<LaserJock> choudesh: what are you wanting to do?
<lamont> LaserJock: oh sure, remove the mystery...
<choudesh> LaserJock: setup a nightly build iso repo for a ubuntu derivative
 * lamont is trying to figure out if he wants someone to kick a daily build, or if he wants to build a custom CD
<LaserJock> lamont: I was figuring the later
<LaserJock> choudesh: you might want to check out https://code.launchpad.net/~kamion/ubuntu-cdimage/mainline
<lamont> yeah... so he wants the script that builds the ISO, not the script that starts it... :)
<choudesh> ahh - that is where it is.
<choudesh> thanks.
<lamont> which is just me having challenges parsing english tonight
<lamont> choudesh: and that looks to be the right repo
<LaserJock> choudesh: make sure to look in config/devel , it has more code to look at
<choudesh> ight
<choudesh> thanks guys
<lamont> LaserJock: I wasn't remembering where kamion kept it... thanks
<LaserJock> np, I did some debian-cd/ubuntu-cdimage patching for Edubuntu and learned about that
 * lamont needs to clean that code up for non-alternate ISOs for hppa/ia64
<lamont> it currently has a "FIXME" for those...  and they're not likely to clear the cutline any release soon
<lamont> unless I either do it myself, or find someone else to badger into it.
 * lamont sleeps.
<warp10> Hi all!
<gQuig1> is this where I should post for guidance with getting a blueprint accepted?   (https://blueprints.launchpad.net/ubuntu/+spec/no-mono-by-default)  Need to know what to do next
<LaserJock> gQuig1: generally you want to have some discussion around a spec
<LaserJock> gQuig1: I suspect there will be lots of discussion around that subject
<LaserJock> probably a good place to get feedback would be the ubuntu-devel-discuss mailing list
<gQuig1> LaserJock: has been on forum, ok.. I'll post to the mailing list
<gQuig1> http://ubuntuforums.org/showthread.php?t=634805
<LaserJock> I'm aware of the thread :-)
<LaserJock> gQuig1: you might want to try to come up with some more info for implementation, like what you're going to propose to replace the current mono apps
<gQuig1> That's really only F-Spot..
<gQuig1> and gThumb does something very similar to F-Spot
<gQuig1> (https://blueprints.launchpad.net/ubuntu/+spec/hardy-reducing-duplication for more info)
<gQuig1> but you are right, I need to make my blueprint clearer in that regard
<LaserJock> gQuig1: right, but if you're proposing to remove software you need to have good replacements so that's gonna be key to your argument
<gQuig1> LaserJock: if the apps in question already have their primary functionality covered in other default applications?
<LaserJock> well, the argument will be that they aren't covered
<LaserJock> Tomboy != StickyNotes, Gthumb != Fstpot for instance
<LaserJock> FSpot
<gQuig1> what critical functionality is not in StickyNotes and is in Tomboy?
<LaserJock> gQuig1: quite a bit actually
<LaserJock> I can see F-Spot and Gthumb being more similar than Tomboy and StickyNotes
<gQuig1> the only thing I know of is WikiLinking
<LaserJock> Tomboy is killer
<gQuig1> really?  I had thought the opposite
<LaserJock> syncing, exporting to HTML, and linking is good
<gQuig1> to properly do this, I am going to have to do in-depth reviews of all the apps in question
<LaserJock> that would be a good idea
<LaserJock> a feature comparison would be good
<LaserJock> I think arguments of "we can get the same functionality without the overhead" will go much further than "Mono is evil"
<gQuig1> definitely
<pitti> Good morning
<LaserJock> ah pitti
<LaserJock> morning
<ion_> Hi
<LaserJock> pitti: I have a question/request for you
<ion_> Now my ISP offers native IPv6 connectivity for free, yay!
<LaserJock> pitti: I need goffice0.4 un-blacklisted
<gQuig1> good night all.  thanks LaserJock
<warp10> Morning pitti! :)
<LaserJock> gQuig1: night
<pitti> LaserJock: ah, can we sync from Debian now?
<pitti> hey warp10! back again? how was the moving?
<LaserJock> pitti: for some reason Debian put it into oldlibs, the package is only 1 month old
<LaserJock> pitti: goffice0.4 was created to provide a lib for packages that use the stable version
<LaserJock> gnumeric uses the unstable version 0.5 so that's what goffice is at
<warp10> pitti: yep, I am back! Unfortunately I lost the fight against that hated usb modem :-S
<LaserJock> pitti: does that make sense?
<pitti> LaserJock: and you need 0.4 for something?
<LaserJock> yep
<LaserJock> gchemutils/gchempaint use it
<LaserJock> I'm waiting on goffice0.4 to merge them
<pitti> alright, I'll sync it then
<LaserJock> ok, thank you very much
<LaserJock> chemists around the world will thank you :-)
<dholbach> good morning
<ion_> Good whatever.
<MacSlow> Greetings everybody!
<stgraber> moin
<mdke> heya dholbach
<dholbach> hey mdke
<mdke> dholbach: colin asked me yesterday to have a look at updating gnome-user-docs; I've created an ubuntu-hardy branch in Launchpad, which is the ubuntu-gutsy branch, merged with Gnome svn. I don't know whether there is anything we should merge from Debian
<dholbach> mdke: slomo did the update in debian - you could either check out what was changed in debian or ask him if it's worth
<mdke> dholbach: ok, I'll try and do that
<dholbach> mdke: great
<dholbach> mdke: just file a upload request bug and subscribe ubuntu-main-sponsors once you're done
<mdke> dholbach: thanks, I will.
<dholbach> rock on
<TheMuso> Would a core dev be so kind as to sponsor bug 172310 please? Gnome-orca needs it to function. Thanks in advance.
<ubotu> Launchpad bug 172310 in brltty "Please upload merged brltty 3.9-4ubuntu1" [Undecided,New] https://launchpad.net/bugs/172310
<slomo> dholbach, mdke: i only updated it to the newer upstream version which had many updates from the ubuntu package it seems...
<mdke> slomo: the upstream version only has added translations. There are a few places where the English text differs in Ubuntu from upstream, but that's because Ubuntu's desktop is a little different to regular Gnome
<mdke> slomo: so no changes to the packaging I need to worry about?
<slomo> mdke: nope
<mdke> slomo: thanks, that's very helpful :)
<geser> morning
<geser> pitti: please give-back: centerim. Thanks
<pitti> geser: good morning! done
<tkamppeter> pitti, hi
<Riddell> pitti: please give back kdepimlibs
 * pitti just read 'kdepimplibs' and thought "WTH..."
<pitti> hi tkamppeter
<pitti> Riddell: done
<tkamppeter> pitti, it is about bug 172264
<ubotu> Launchpad bug 172264 in ghostscript "[Gutsy SRU Request] Ghostscript in Gutsy and Hardy is not able to print encrypted PDFs out of Adobe Reader 8.1.1" [High,Fix released] https://launchpad.net/bugs/172264
<StevenK> pitti: kdepimplibs is for KDE 4 :-P
<Riddell> thanks pitti
<pitti> tkamppeter: the upstream bug didn't enlighten me sufficiently, so I'd like to ask you about some insights
<tkamppeter> It is really strange that this problem gets fixed by simply changing the size of a buffer, for me a buffer size change should only influence performance.
<pitti> tkamppeter: right, and that's what makes me nervous
<pitti> as if it wouldn't work with the n+1st test case, and/or break PDFs which work fine ATM
<tkamppeter> Yes it can easily happen that this fix only helps on some files
<tkamppeter> pitti, perhaps you should ask on the gs-devel@ghostscript.com list or on the #ghostscript IRC channel.
<pitti> tkamppeter: can you please ask on the upstream bug?
<pitti> (sorry, swamped)
<tkamppeter> pitti, I will talk with them on IRC.
<Riddell> pitti: hal broke my compile http://paste.ubuntu-nl.org/47814/
<Riddell> pitti: it that caused by your upload yesterday?
<pitti> Riddell: compile?
<pitti> Riddell: very well possible, sorry about that; where does that happen?
<Riddell> pitti: it happened in my compile of kdepimlibs in the buildds, but presumably any fresh hal install will fail
<Hobbsee> BenC: :(
<pitti> Riddell: can you please file a bug about this and subscribe me? I'll track this down this afternoon
<Riddell> pitti: bug 175525
<ubotu> Launchpad bug 175525 in hal "hal fails to install" [Undecided,New] https://launchpad.net/bugs/175525
<Fujitsu> .win 17
<Fujitsu> Oops.
<pitti> Riddell: thanks
<pitti> Riddell: please just add the failed builds to that bug, I'll give them back once it's fixed
<Hobbsee> ion_: which video card?
<Hobbsee> ion_: and if you're only getting a crash every 10 or so minutes, you're lucky...
 * Hobbsee wonders if hte old compiz versions still install, and crash less.
<ion_> 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4800 SE] (rev a1)
<ion_> The proprietary :-( driver.
 * Fujitsu managed to fully log in once out of a few times.
<Hobbsee> urg
<ion_> I had while read; do pkill -9 compiz; done running in the virtual console for a while, until i got fed up and switched to metacity. :-P
<ion_> It didnât help that X insists on immediately switching back when i hit ctrl-alt-F1.
<Hobbsee> that's consolekit
<stgraber> Hobbsee: talking about the : compiz eats 100% of my CPU and makes the whole session to freeze ? :)
<Hobbsee> stgraber: yup
<Hobbsee> i'ts really getting overrated.
<stgraber> I had this one after the I updated to the new compiz on my laptop (Intel card)
<stgraber> I'm currently running metacity because of it
<Hobbsee> yup.
<Hobbsee> same here
<Hobbsee> it's just not worth crashes every few minutes
 * Fujitsu too.
<Fujitsu> Yay for running dev releases.
<stgraber> we have to test and debug, no ? :) As soon as I don't have any libc/kernel/xorg issue I'm happy to run the dev release
<stgraber> running metacity instead of compiz isn't really a problem, just a bit annoying :)
 * lamont yawns, waves
<pitti> hey lamont
<pitti> hi Hobbsee
<soren> hey lamont.
<pitti> lamont: what's the plan with your 5 outstanding merges? will you do them or shall we spread them amongst the distro team?
<pitti> lamont: db4.2 is a sync, doing now
<ogra> pitti, before you nag me as well, ltspfs will see a new upstream before feature freeze and we package that independently from debian ...
<pitti> ogra: I won't, but thanks :)
<ogra> :)
<soren> I'll file the sync request for e2fsprogs in a minute..
<pitti> soren: ah, is it?
<soren> That's my conclusion, yes.
<pitti> soren: I looked at it a while ago, and Ian's patch wasn't directly applied
<soren> No, it wasn't.
<pitti> might be that it was solved in a more general fashion
<soren> But Ted T'so implemented a different workaround that looks more correct.
<pitti> ah, cool
<soren> Ian's patch made e2fsck ignore mount times in the future. Ted's patch add a new configurable to e2fsck.conf that can be set to allow mount times (and inode times) to be up to 24 hours in the future to account for differences in timezone settings.
<soren> ...and he even took care to enable it on Ubuntu and not in Debian.
 * persia notes that there are actually 25 timezones
<pitti> ScottK: would you mind merging pinentry? lamont only touched it for a rebuild, and you actually seem to care about that package
<soren> lamont: Could you add lpia to the list of archs for which we build syslinux?
<pitti> lamont: are things like http://merges.ubuntu.com/libt/libtool/libtool_1.5.24-1ubuntu1.patch still necessary? hppa should have caught up now with building?
<lamont> pitti: I need to work with doko and get java bootstrapped... hence the stalling on libtool, gettext, and such
<lamont> s/bootstrapped/bootstrapped on hppa/
<pitti> lamont: ah, so the plan is to do that and then drop the delta
<lamont> right
<pitti> cool, thanks
<soren> lamont: Or is there someone more appropriate I should be asking?
<lamont> and yeah, pinentry would be cool if ScottK did it, otherwise I'll just take it cold if no one beats me to it.
<lamont> soren: I'd be the right victim
<soren> lamont: Cool.
<lamont> or infinity or elmo
<lamont> committed.
<lamont> soren: fwiw, tradition is to send email to the 3 of us
<soren> lamont: Oh, I see.
<lamont> that way we can silently ignore stupid requests together. :-)
<soren> Hah!
<soren> Well, up until about a week ago I had no idea such a thing as PaS existed. :-/
<lamont> "please make this change.  here's a copy of the irc log where the maintainer agreed with me. .... "<maintainer> I think it would be better to get the port done" ...'
<lamont> yes, well.
<ScottK> pitti: I can try and take a look at it today or tomorrow, but all I did was make sure it met your requirements (not build the GTK version) for Main.
<pitti> ScottK: I see; well, please let us know if you don't care/don't have time
<ScottK> pitti: I'll try to find time today,  If not I'll give you a ping.  I hadn't noticed it as I just search for my name on the merges list.
<pitti> ScottK: thanks
<soren> lamont: Do I need to reupload to have a build record created for lpia or will that magically happen somehow?
<lamont> it should be automagic
<soren> lamont: Cool.
<soren> lamont: Thanks very much.
<lamont> ISTR that LP autosyncs PaS every so often (15min??)
<lamont> so if there's no build record in 90 min or so, then bitchslap #launchpad. :0)
<lamont> well, gently... so they can tell you who to really pester.
<lamont> in any case, uploads should not be required
<pitti> soren: try #soyuz instead
<soren> lamont: Ah, it's just a direct sync from Debian?
<soren> lamont: Or what do you mean by "autosync"?
<lamont> yep
<lamont> we share the file
<lamont> which has occasionally been interesting..
<soren> lamont: How so?
<soren> lamont: Well, adding lpia might have been a bit controversial, I guess?
<lamont> my favorite ever was a powerpc kernel package that was ": powerpc i386"
<lamont> with a comment of "# I feel dirty - lamont"
<soren> lamont: Erm.. Ok. :)
<lamont> it built an arch-all package...
<ogra> hmm, the devscripts update in debian adds a libfile-desktopentry-perl build-dep ... its apparently used for creating .menu files from .desktop .... do we drop that build-dep or do we want that lib in main ?
<soren> lamont: Oh, right.
<doko_> lamont: getting java bootstrapped is easy; getting a working java bootstrapped is more difficult ;-p
<lamont> doko_: I'm into option #2. :-)
<lamont> OTOH, you get your unaligned loads/stores.
<doko_> lamont: gcj-4.2 doesn't require java to build; that should be buildable on its own. then you face a problem building ecj and gjdoc. suggested workaround: don't build from source, but build-depend on the just built libecj-java, and build from bytecode. The same should be done by gjdoc after splitting out an libgjdoc-java
<lamont> doko_: that almost made sense.
<lamont> I understand the words, I'm just not sure how they translate into actions... it might help if I had any clue about java... :(
<lamont> what I need is a series of steps to get me a set of debs that I can use to build gcj-4.2, ecj, and gjdoc from source, and then use those binaries to build all 3 all over again
<doko> lamont: continuing on private channel ...
<lamont> ok. thanks
<soren> slangasek: Around yet?
<warp10> Hi all!
<warp10> pitti: May I request a sync for libpcap-ruby?
<pitti> warp10: sure, if you checked it; please file a sync bug
<warp10> pitti: done. Bug 175564
<ubotu> Launchpad bug 175564 in libpcap-ruby "Please sync libpcap-ruby 0.6-7  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/175564
<pitti> warp10: ack'ed, thanks
<warp10> pitti: :)
<soren> What are you guys doing to the Vcs-* headers when merging?
<soren> I've been renaming them to XSBC-Original-Vcs-blah..
<seb128> I don't change those
<soren> Oh, really?
<soren> On purpose?
<seb128> why should we change them?
<soren> Because they're wrong?
<seb128> well, that's where the package is maintained out of the Ubuntu changes
<soren> They tell you where Debian maintains the packages, so not changing them is misleading.
<seb128> right, I don't care enough to create extra delta ;-)
<soren> I think it'd be quite nice if I could actually trust apt-get source's warnings about the package being in a VCS somewhere.
<seb128> I guess that using XSBC-Original-Vcs would make sense
<soren> Cool. Hoever, two days before import freeze is not a quite optimal time to agree on changing them. :)
<persia> seb128: Can that be done magically by the sync scripts?  That's a painful delta to coordinate.
<soren> persia: By sync scripts, you mean MoM?
<seb128> persia: it could be handled the same way that the maintainer change, do you have code to do those?
<persia> soren: I don't think so: I was thinking of the scripts the archive admins use to pull from Debian for autosync or a sync request (is that really MoM?)
<soren> persia: No, that's not mom.
<soren> persia: Well, in the case of a sync, the headers are acutally correct.
<persia> seb128: Hmmm....  Maybe.  If we only do XubuntuY, I guess it does make sense (and would certainly make apt-get source less confusing)
<soren> persia: Since the package as is is in fact maintained in the vcs specified.
<seb128> persia: well, the change make sense only for ubuntu version
<persia> soren: Right, although that wouldn't be the appropriate place to make a change in many cases.
<soren> It would be nifty if MoM renamed them, though. Then it would be up to us to add any Ubuntu specific ones.
<seb128> persia: packages synced on Debian use the vcs indicated there
<ScottK> pitti: I'm looking at pinentry now.  Is fixing the encoding of a non-UTF8 debian/copyright file worth adding to the Ubuntu/Debian diff over?
<seb128> ScottK: no
<persia> seb128: Right, but if I want to patch a Debian package, I don't want to do it in Debian.  As a result, I just completely ignore VCS-*, which isn't necessarily ideal either.
<ScottK> seb128: Thanks.
<seb128> ScottK: is there other ubuntu changes?
<ScottK> seb128: There are.
<Keybuk> soren: if MoM is involved, it implies that the package has *already* been patched
<seb128> k, so it's up to you, doesn't really hurt
<ScottK> My question is should I add to the pile.
<seb128> you should send that to debian though
<Keybuk> which implies that the maintainer was previously negligent and forgot to update control frields
<Keybuk> (and likely forgot to update the maintainer too)
<Keybuk> I think we shouldn't encourage that
<ScottK> seb128: OK.  I'll do that (send it to Debian, but not sweat it for the merge).
<soren> Keybuk: Point.
<persia> Keybuk: Are you saying that updating VCS-* should have been done as part of variation?
<Keybuk> yes
<Keybuk> likewise for updating maintainer field
<persia> Right.  We've the spec on the maintainer field, but no spec on Vcs-*.  As a result, I think there are heaps of merges where the first was changed, but not the second (for which the script seb128 mentioned above could help).
<persia> On top of that, for syncs, we likely want to patch in Ubuntu after DIF, and push to Debian, rather than expecting work in Debian directly, which is why I wonder if we can do a sourcepackagemange type thing (although that makes it all very painful)
<ScottK> lamont: I've done the pinentry merge.  Care to sponsor it?
<lamont> ScottK: email me details, and sign your changes file.  I'll verify sig, build, resign, and upload.
 * lamont heads for a meeting, aware that the weather is gonna make him, uh, late.
 * soren lets out a deep sigh and goes to work on the multipath-tools merge
<soren> Keybuk: I assume you're doing devmapper and mdadm?
<Keybuk> soren: I haven't looked at them
<Keybuk> feel free to
<soren> Keybuk: They've got your name written all over them.
<Keybuk> be sure to keep all our changes, since we worked hard on them :-)
<Keybuk> and in the mdadm case, that does involve dropping almost all of the Debian stuff <g>
<Keybuk> yes...
<Keybuk> that's because I happened to touch them last
<Keybuk> I have zero time for merges sadly
<soren> I think I'll have my hands full with multipath-tools for now.
<soren> Keybuk: Ok... I'll see if I can fit them in.
<ScottK> lamont: Mailed.
<Keybuk> soren: devmapper is easy, I'll do that one right now :)
<soren> Keybuk: Coolness.
<sivang> Howdy all
<sivang> hey Keybuk
<sivang> has anyone had any experience booting ubuntu onto a DBAu1550 based AMD evaluation board or is ubuntu mobile only ready for i386 architectures for now?
<Keybuk> was that a question for me?
<seb128> keescook: bug #175573 in case you didn't read it
<ubotu> Launchpad bug 175573 in libcairo "libcairo2_1.4.10-1ubuntu4.2 is still broken - some text is not rendered" [Undecided,New] https://launchpad.net/bugs/175573
<soren> Keybuk: Erk... The madadm merge looks like no fun at all.
<Keybuk> soren: indeed
<Keybuk> is there any particular reason to merge it at all?
<soren> I was just thinking the same thing.
<soren> Well, we can sync up to the same upstream release, but trying to merge the Debian specific changes seems pointless.
<sivang> hey soren
<soren> Hi, sivang! Long time!
<evand> can someone in core-dev sponsor http://people.ubuntu.com/~evand/upload/partman-crypto_24ubuntu1.dsc ?
<sivang> soren: indeed, long long time
<sivang> soren : but I'm coming back gradually
<soren> \o/
<pitti> evand: grabbing
<evand> thanks pitti
<pitti> evand: MoM introduced a lot of *.po noise, did you remove that from the delta?
<pitti> evand: or, asked the other way round, can you please pastebin a debdiff between 22 and 22ubuntu1?
<pitti> evand: oh, nevermind; we actually added templates
<pitti> evand: uploaded, thanks
<evand> thanks, much appreciated!
<Keybuk> MoM always creates po noise
<Keybuk> hmm, how long does debbugs normally take?
 * Keybuk has quite honestly forgotten
<pitti> Keybuk: last time someone told me it runs at :03 and every 15 minutes
<pitti> but I think it's faster nowadays
<pitti> or I was exceptionally lucky recently :)
<Keybuk> hmm
<Keybuk> I've been waiting over 30 minutes
<pitti> it actually got delivered? you mentioned a problem with local MTA and relaying?
<seb128> I sent a bug some minutes ago, took 3 minutes to get the ack mail for this one
<Keybuk> I assume it got delivered
<Keybuk> I got a Cc, certainly
<Keybuk> clearly I am being stupid here
<Keybuk> but why can I not get any debian.org host to accept these bugs?
<Keybuk> Connecting to bugs.debian.org via SMTP...
<Keybuk> Unable to send report to scott@ubuntu.com: 550 relay not permitted
<Keybuk> also my user tags don't appear to work
<pitti> Keybuk: ah, so the bug was created, but you didn't get the confirmation email?
<Keybuk> I think I had everything all ways then :)
<Keybuk> first time I only got the Cc, not the created bug
<Keybuk> second time I got the bug created, but no Cc
<Keybuk> third time I got both
<Keybuk> still no user tags though
<Keybuk> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455747
<ubotu> Debian bug 455747 in devmapper "udev support" [Wishlist,Open]
<Keybuk> ^ has them, but they're not shown in the web interface
<pitti> ah, I just found that bug, too
<Keybuk> so that merge took me two minutes to do
<Keybuk> and over an hour to extract the patches and then fight with debbugs to submit them
<pitti> Keybuk: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ubuntu-patch;users=ubuntu-devel@lists.ubuntu.com has your bug, so your usertags work
<Keybuk> pitti: no it doesn't?
<Keybuk> it has a different bug that I forcibly added the tags with bts ?
<pitti> Keybuk: it does show 455745, isn't that the one you just submitted?
<keescook> seb128: thx, noted.
<Keybuk> one of them
<Keybuk> I also submitted 455747
<pitti> ah, I just found the other one
<Keybuk> I never thought I would say this, but debbugs makes LP seem painless and pleasant to use
<pitti> heh, I tend to agree; it evolved a lot
<pitti> although, when you are used to it, submitting an existing patch to debian is a matter of 2 minutes
<Keybuk> anyway, devmapper merge done :-)
<soren> Keybuk: Are you familiar with submittodebian?
<Keybuk> no
<soren> It extracts the debdiff between the two topmost revisions in debian/changelog (assuming you have the corresponding .dsc's in the parent directory), extracts the topmost changelog entry and turns those two into a bug report to Debian by way of reportbug.
<geser> has someone some time to sponsor bug #157668 and bug #174749?
<ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20071203-1ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/157668
<ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
<soren> Your case is clearly more advanced, but generally it makes the hassle of dealing with Debian's bts minimal.
 * pitti finds reportbug more time consuming than just creating a mail with explanations and the patch attachment to submit@b.d.o
 * soren agrees in the general case
<pitti> soren: it's nifty if the debdiff is just one atomic change, though
<soren> pitti: Precisely.
<Keybuk> in this case, I had three patches to submit upstream, and some that were ubuntu specific
<soren> Keybuk: Right. Clearly a case where you need to go manual, but in the case of single bug fixes or feature additions or whatever, it's quite nice.
<geser> are patches for lpia Ubuntu-specific or should they get forwarded to Debian?
<Keybuk> soren: does it need a local MTA?
<soren> Keybuk: It uses whatever reportbug uses.
<soren> Keybuk: ...so no.
<Keybuk> reportbug does though?
<soren> Keybuk: No?
<Keybuk> see above
<soren> Keybuk: reportbug by default uses fiordland, afair.
<Keybuk> it utterly failed
<soren> How far?
<Keybuk> I got relay access denied by whatever it was trying to use
<soren> Right, it's trying to use fiordland.
<Keybuk> which doesn't work, so it does need a local MTA :)
<soren> You can configure it to use your isp's mta if you want.
<soren> I agree that reportbug's default settings are on crack.
<Keybuk> no, I can't
<soren> Keybuk: *I* can.
<Keybuk> because it doesn't support specifying a client certificate for connecting to it
<soren> Oh.
<soren> Your ISP requires that?
<Keybuk> my mail server does yeah
<pitti> soren: what? why should fiordland relay mail to the debian BTS?
<Keybuk> why can't reportbug just use bugs.debian.org by default?
<Keybuk> if it can do SMTP, why does it need a relay?
<soren> pitti: It shouldn't.
<soren> pitti: Hence: The default settings are on crack.
<pitti> ok :)
<soren> Keybuk: No idea.
<soren> Keybuk: Well, a lot of ISP's block port 25 outgoing.
<soren> Yes, I know that blocks fiordland, too.
<soren> I'm just saying.
<soren> Did I mention I think the default settings are on crack? :)
<soren> I don't have any (much) better suggestions, though.
<evand> soren: Do you mind taking a quick look at this and sponsoring it if it's ok.  It's a very small delta against the syslinux package to get rid of a reference to "CD2": http://people.ubuntu.com/~evand/upload/syslinux_3.53-1ubuntu2.dsc
<soren> A one-size-fits-all approach to sending an e-mail is hard to find these day.s
<Keybuk> if only you could ask evo to send a mail via D-BUS :-)
<pitti> DMTP?
<soren> evand: I'd love to. I thought about doing it yesterday, too, but couldn't be bothered, so thanks!
<evand> ah, thank you
<soren> evand: Uploaded. Thanks!
<evand> thank you
<slangasek> soren: moo
<alex-weej> amyone know where i can find debugging symbols for hardy?
<alex-weej> *anyone
<alex-weej> i added the ddebs.ubuntu.com repo but the debugging symbols are out of date even for hardy
<alex-weej> in particular, i need symbols for libgnome-keyring0
<geser> alex-weej: pitti should hopefully know it
<alex-weej> i am building the package myself for now but i'd really like to know
<alex-weej> hum, that didn't work
<alex-weej> i just built it myself, how do i get the debugging symbol packages? :E
<geser> alex-weej: have your pkg-create-dbgsym installed?
<alex-weej> geser: no
<alex-weej> i've installed it
<alex-weej> what do i do with it?
<geser> rebuild again
<geser> it replaces dh_strip (?) to strip out the debug symbols into it's own ddeb
<alex-weej> oi
<alex-weej> *oic
<alex-weej> i'm trying to figure out why gnome-session hangs most of the time from gdm
<alex-weej> in hardy
<alex-weej> geser: so how do i install the symbols?
<alex-weej> or do they just go into the regular packages?
<alex-weej> ah wait i see all these "ddeb" files
<geser> alex-weej: install the ddebs like normal debs
<geser> e.g. with dpkg -i
<alex-weej> done thanks
<alex-weej> does anyone know what happened to VT switching?
<Keybuk> -v
<alex-weej> has it been disabled for a reason? GDM doesn't respond to the key combos and when doing it from a GNOME session the screen blanks for a second then dumps you back into X
<soren> slangasek: Yes?
<soren> alex-weej: iz consolekit bug.
<alex-weej> soren: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/175682
<ubotu> Launchpad bug 175682 in gdm "GNOME rarely starts from GDM in Hardy" [Undecided,New]
<alex-weej> soren: check the stack trace, sure?
<Keybuk> alex-weej: not that I'm aware
<alex-weej> soren: oh wait, you're talking about VT-switching
<Keybuk> alex-weej: I've seen it fail a few times, and done C-A-F1 thru F6 and one of them works along the way
<alex-weej> sorry
<soren> alex-weej: Yes, I am. :)
<Keybuk> soren: how does console kit break that?
<alex-weej> VT-switching hasn't worked for years for me
<soren> Keybuk: Yes. Something about X and ConsoleKit fighting over it.
<alex-weej> on any of the 3 ubuntu machines i run!
<Keybuk> years = not a known bug
<soren> Keybuk: Ian fixed it in gutsy, but his patch was dropped in the merge, apparantly.
<slangasek> soren: "pong"
<soren> slangasek: Oh, did I ping you?
<slangasek> soren: you asked me if I was around at 6am :)
<soren> slangasek: Oh, right.
<soren> Hm...
<soren> slangasek: I completely forgot what I wanted. Probably something about your keepalived merge, I'm not sure what.
<soren> I'll ask again, if I think of it :) I got to run now, sorry.
<slangasek> ok, later
<geser> bddebian: can prelink get synced or got the ubuntu changes lost in the last merge? see http://patches.ubuntu.com/p/prelink/prelink_0.0.20061201-1ubuntu1.patch
<bddebian> geser: Yikes, I must have dropped a patch in there somewhere :(
<super-6-1> hello im having troble with my apperance
<super-6-1> in Visual Effects it stays normal and when i change it, it changes itself back to normal
<geser> pitti: is it planned to import NEW packages from Debian once again before DIF?
<pitti> geser: hm, I just did so yesterday
<pitti> geser: but requests for importing them continue to be valid until FF
<geser> sorry, my error, I should have used the source package name instead of the binary one to check if it's already imported
<alex-weej> pitti: ddebs for hardy?
<pitti> alex-weej: yes?
<alex-weej> is there an uptodate repo?
<pitti> alex-weej: something wrong with http://ddebs.ubuntu.com/ ?
<pitti> it's supposed to be ok
<alex-weej> yeah. i tried to install libgnome-keyring0-dbgsym from it but it wanted to install an old version of libgnome-keyring-0 as a dependency
<alex-weej> 2.20.something i believe
<alex-weej> when we're using 2.21 in hardy now
<Fujitsu> It hasn't updated since the end of last month.
 * pitti checks
<pitti> argh
<alex-weej> are you OK?
<pitti> 1004      8859  0.0  0.0   5144  2300 ?        S    Nov30   0:07 apt-ftparchive generate /
<alex-weej> do you want us to send help?
<pitti> WTH?
 * Fujitsu agrees with pitti.
<Fujitsu> strace it and see wth. it's doing?
 * pitti goes to rescue the ddebs from the last 7 days; anything older is lost
 * Fujitsu hopes there were no important libraries uploaded during those 5 days.
<alex-weej> so what's happened?
<pitti> I think I lost my ssh connection, and it was spinning on getting the tty back, or so
<pitti> that was around the day when we moved ddebs to a new server
<pitti> alex-weej: thanks for the poke
<Fujitsu> Ahh.
<alex-weej> ok cool no problem
<geser> pitti: have you some time to sponsor #174749 so graphviz can leave depwait?
<pitti> alex-weej: ok, ddebs.u.c. has latest gnome-keyring ddebs now; not indexed yet, though
<alex-weej> pitti: i ended up building them myself, but thanks anyway
<alex-weej> by the way, is there some easy way to automatically pull debugging symbols when using GDB yet? :D
<alex-weej> i always have to use a pretty laborious iterative process when trying to view a stack trace properly
<pitti> alex-weej: man apport-retrace(1), it has a -g option to kick you into gdb
<alex-weej> alex@flash:~/Videos/Phone/7$ man apport-retrace
<alex-weej> No manual entry for apport-retrace
<alex-weej> alex@flash:~/Videos/Phone/7$ man apport-retrace(1)
<alex-weej> bash: syntax error near unexpected token `('
<pitti> alex-weej: you need to install apport-retarce
<pitti> retrace, even
<alex-weej> is this what most people do then?
<alex-weej> actually, what if i don't have a dump?
<alex-weej> as in, my program is still running
<pitti> alex-weej: hm, I should teach apport-retrace about this use case (attach to pid instead of apport crash report)
<alex-weej> that would be pretty sweet
<pitti> wishlist bug report appreciated :)
 * lamont sticks kde/hppa back in the cellar
<pitti> geser: doing
<geser> pitti: thanks
<ScottK> lamont: Did you get my mail with the pinentry merge?
<pitti> geser: will just take a while, my network is sooooo sloooooow tonight
<lamont> yeah
<lamont> off to a meeting that starts in 30 seconds, and then after that I'll finish playing with it and upload
<ScottK> lamont: Cool.  Did you see/like my comment on the bug complaining about lack of IDN support in BIND?
<ScottK> K.  See you later.
<lamont> will have to look... LP?
<geser> pitti: I already wait a half week for a sponsor so some more hours don't matter
<lamont> or debbugs?
<pitti> 5130B/s -- *sniff*
<Riddell> pitti: did you look at that hal issue?
<lamont> pitti: what's up with that?  you trying to compete with my link?
<pitti> Riddell: high on my list, promised
<ScottK> lamont: It was LP, but it was simple enough.  I just opined that perhaps lack of IDN domain name support was a security feature.
<lamont> lol
<lamont> and gone
<geser> lamont: what's the status of hppa for hardy? should we start looking at FTBFS on hppa or can we still ignore them?
<ScottK> geser: Last FTBFS mail on hppa I got it seemed some pretty basic things were left unbuilt.  I think it's probably premature.
<geser> pitti: can you also sponsor my scons merge (bug #157668)? Hobbsee doesn't want sponsor it again
<ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20071203-1ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/157668
<pitti> EBANDWIDTH
<pitti> (both mental and net), sorry
<pitti> geser: please assign it to me and set it to 'in progress', I'll do it tomorrow
<geser> pitti: both?
<pitti> geser: scons
<geser> pitti: thanks
<pitti> geser: graphviz uploaded, thank you
<alex-weej> does network manager come on server installations?
<keescook> why, when I attempt to install libopenexr2ldbl, does apt want to remove all things kde?
<jpatrick> it's a transition in process
<keescook> ah -- are things still building?
<jpatrick> yep
<Riddell> keescook: most kde 3 packages should be through the transition now
 * keescook holds on to his hat
<lamont> geser: hardy/hppa: if it's main, and not java, it warrants looking into.  there are still 1600 packages unbuilt in universe
<lamont> OTOH, we're heading over 80% any time now.
<lamont> 2007/345/22 98.1518 96.244 96.317 79.5279 95.6973 94.9352 96.7182
<lamont> hppa is the 79.5... too lazy go to get the list. ;-)
<lamont> see http://bld-4.mmjgroup.com/~wb/buildLogs/stats/hardy2-short.png
<slangasek> lamont: so is someone working on the java bootstrap?
<lamont> slangasek: boku
<lamont> OTOH, I need to hack together something that fakes up enough of gjdoc in order to build gcj-4.2 so that I can build gjdoc so that I can build gcj-4.2 :-(
<geser> lamont: I ask because hppa has the most red cells in http://qa.ubuntuwire.com/ftbfs/
<lamont> tonight I'll work on the script to touch an output file.
<lamont> geser: i expect so.
<lamont> once hppa finishes getting through the queue, I plan to have a mass-giveback done.
<lamont> ScottK: so you're sure about pinentry, eh?
<slangasek> lamont: ok. so the patches to drop db.*-java on hppa will go away in the hardy timeframe? :)
<lamont> slangasek: that is certainly the goal
<slangasek> \o/
<lamont> and yes, I know that's not an answer. :-)
 * lamont uploads pinentry for ScottK 
<Lutin> does someone have a minute to look at bug #173717 ?
<ubotu> Launchpad bug 173717 in grub "Grub has a build-depends-indep against a multiverse package" [High,New] https://launchpad.net/bugs/173717
<ScottK> lamont: Thanks.
<ScottK> lamont: I'm sure you left changed by unmodified so whatever I messed up will stick to me and I'll fix.
 * ScottK head-desk (forgot the -v when building the source package again).  Urgh.
<YokoZar> Is Hardy going to default to GCC 4.2 (or newer?)  I recently uncovered a Wine bug related to using 4.1
<ScottK> YokoZar: I understand you've got a WINE package for Hardy up on REVU.  Is it the current release?
<ScottK> YokoZar: Please fix it anyway so it'll work when we backport to Gutsy.
<YokoZar> ScottK: Almost.  I need to change the GCC version in it
<ScottK> OK.
<YokoZar> Speaking of which, I'm running into a problem with that
<ScottK> YokoZar: Ping me when you think it's ready.
<ScottK> OK.
#ubuntu-devel 2007-12-12
<slangasek> lamont: are there any blockers you know of wrt merging gettext 0.17?  if not, I'll go ahead and chase it
<slangasek> hmm, I suppose you'll be wanting to keep that hppa javaless patch in there for now, won't you :-P
<slangasek> hrm. does MoM pull in translation updates from LP?
<slangasek> the gettext merge seems to include updated translations of the GPL copyright header, which don't come from the previous Ubuntu diff
<sabdfl> :-)
<Hobbsee> oh noes, it's sabdfl!
<Hobbsee> he's smiling!  he must be plotting something, too!
 * Hobbsee brings out the evil white rabbit
<Hobbsee> soren: so, fix it.
<desrt> keybuk; !!! wru? :p
<Hobbsee> desrt: he went mad, so we shot him
<desrt> well, about time
<desrt> all this ranting about InitKit
<desrt> someone had to take the boy down
<desrt> Hobbsee; how are you this evening (er... day)
<desrt> ?
<ion_> GCC could be renamed as KitKit, since itâs a kit you use to make kits.
<Hobbsee> desrt: i'm doing OK.  fortunately, i don't have work today!  \o/
<desrt> ion_; now that would just be silly!
<ion_> duh
<desrt> people who have work -any- day are suckers!
<Hobbsee> heh
<Burgundavia> desrt: I thought you were joking
<desrt> about what?
<Burgundavia> initkit
<desrt> i'm not joking.
<desrt> btw: Hal is being renamed to DeviceKit
<Burgundavia> I just found the mailing list
<desrt> (i'm also not joking about that)
<Burgundavia> yes, well it and udev are going to undergo some sort of merger. I really don't understand much about that layer of my system
<TheMuso> Wow. A merge?
 * TheMuso sighs. Why don't people get it right the first time?
<slangasek> TheMuso: "get it right" referring to udev and hal?
<slangasek> if you ask me, udev was right from the beginning... :)
<TheMuso> Yeah, referring to udev and hal.
<TheMuso> And it seems that this crazy kit naming has caught on too much.
<TheMuso> to me anyway
<LaserJock> TheMuso: it's the new K*
 * slangasek installs the Kit Desktop Environment
<LaserJock> haha
 * TheMuso hopes that that environment has AccessibilityKit.
<TheMuso> Hmmm. Brltty to be renamed Braillekit. :p
 * TheMuso ducks
<LaserJock> heh, cool
<lamont> slangasek: for now, lets keep the java-free hppa love, and I'll be working this week on bootstrapping java
<lamont> (gettext)
<lamont> slangasek: you wanna do that merge?  that'll let me go to sleep
<lamont> otherwise, I'll do it in the morning. :-)
<slangasek> lamont: already worked through it, want to sponsor it? :)
<slangasek> https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/175775
<ubotu> Launchpad bug 175775 in gettext "Please merge gettext 0.17-2 (main) from Debian unstable (main)" [Wishlist,Confirmed]
<lamont> slangasek: sure... got a signed source.changes et al?
<slangasek> can do
<slangasek> lamont: http://people.ubuntu.com/~vorlon/gettext_0.17-2ubuntu1_source.changes
<LaserJock> hmm, anybody know if a MIR is needed for a lib split? It's the same source, just new packaging
<slangasek> LaserJock: can you elaborate on what "lib split" means?
<LaserJock> sorry
<LaserJock> goffice0.4 was added because goffice has gone to 0.5 and 0.4 is still needed
<LaserJock> goffice is in Main, goffice 0.4 was in gutsy so I would assume the code is ok
<slangasek> why are they both needed in main?
<LaserJock> I'm not sure yet if we need goffice0.4 in Main yet, but I *think* abiword is going to need it
<slangasek> since that's code duplication, that's a case that should go through MIR
<LaserJock> ok, just wondered
<warp10> Hi all!
<Hobbsee> infinity: ping
<dholbach> good morning
<LaserJock> good morning
<dholbach> hey LaserJock
<pitti> Good morning
<stgraber> arghh, anyone here knows how I can make a laptop not to turn backlight off after 10min ?? I have no ACPI/APM loaded, X started with -dpms
<stgraber> it's really old laptop crap (Toshiba from 1998)
<warp10> pitti: good morning!
<MacSlow> Greetings everybody!
<pitti> hey MacSlow, moin warp10
<MacSlow> hey pitti, seb128
<seb128> hi Mac
<seb128> hi MacSlow
<dholbach> bdmurray: do you think thekorn's text branch is ready for merging?
<pitti> hey seb128, happy archive day
<seb128> hello pitti, thanks
<seb128> started the day with almost 300 items in NEW
<pitti> ugh
 * pitti hugs seb128
<seb128> did somebody did new sources import from debian? ;-)
<seb128> pitti: new-binary-universe-debian cleaned most of those so that's alright
<seb128> pitti: I did wave glade and its binaries to universe too
<pitti> ah, ok
<pitti> seb128: yes, me (yesterday)
<Riddell> pitti: please give back nip2/7.12.5-2build1
<pitti> Riddell: done; just fixed the hal bug, BTW, I'll give-back kdepimplibs once it's built
<Riddell> yay
<geser> good morning
<pitti> hi geser
<geser> Hi pitti
<dholbach> hey geser, hey pitti
<warp10> pitti: bug #152579
<ubotu> Launchpad bug 152579 in bsdmainutils "calendar does not have new daylight savings time dates for the US" [Undecided,Confirmed] https://launchpad.net/bugs/152579
<geser> Hi dholbach
<dholbach> hey geser
<doko> asac: may I bitch about the xulrunner insanities having to patch configure files?
<glick> hello
<glick> i have a question about patents
 * Fujitsu patents asking questions about patents.
<glick> heh
<glick> what does this mean:
<glick> This application claims the benefit of U.S. provision application Ser. No. 60/024,789 filed Sep. 9, 1996, now abandoned.
<glick> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,272,467.PN.&OS=PN/6,272,467&RS=PN/6,272,467
<glick> for that patent
<seb128> mr_pouit: about the xfwm4-themes sync, don't you need the cdbs magic for the translations template update?
<StevenK> Impressive. I have a merge on my machine I don't remember doing.
<geser> StevenK: is this a bad sign or a good one?
<StevenK> geser: I have no idea. :-)
<persia> StevenK: For hardy?
<StevenK> persia: Yup
<StevenK> persia: I'm uploading it now
<slomo> asac: what happend to the xulrunner/mono issue?:)
<StevenK> Here's wishing dput had progress bars
<geser> StevenK: put "progress_indicator = 2" into your dput config
<StevenK> Ooooh
<StevenK> Now I want to upload something else :-P
<geser> How about uploading scons? ;)
<asac> slomo: i dropped the ball yesterday after learning a bit about mono native bindings :). I will probably ask things later today though.
<geser> pitti: please give-back: apt-zip
<pitti> geser: done
<lool> Not sure you people saw the Ulteo OO.o online desktop launch
<lool> I'm browsing their /etc from oowriter's file > open, and it seems to be running on dapper
<dholbach> lool: ulteo is baded on kubuntu afaik
<Riddell> yes
<lool> I kind of wonder what their security model is exactly
<Riddell> lool: got a screenshot?
<Kmos> morning!
<pitti> Riddell: kdepimlibs given back, hal is in the archive now
<lool> Riddell: Sure, there's nothing to see though
<lool> Riddell: http://people.ubuntu.com/~lool/ulteo.png
<Riddell> lool: groovy, is it using the NX java applet?
<lool> Riddell: It's using a java applet; how could I check it's NX?
<lool> I think I read about translating X events into AWT in some Google video
<lool> It certainly looks like what they are doing
<Riddell> lool: view source I guess
<lool> Riddell:         archive="SSHVncApplet-0.2.9.4-3-signed.jar,SSHVncApplet-0.2.9.4-3-jdkbug-workaround-signed.jar"
<lool> It seems it's VNC
<lool> From what I saw, there is another home dir of another user which I can't reach (unix perms)
<lool> I don't know whether they purge the servers at some point
<lool> They use PAM to store some encfs
<lool> Hmm I wonder how they auth the VNC
<lool> The web page seems to have a login and password and host and port for SSH
<pitti> geser: is that scons underquoting problem known upstream?
<pitti> and/or in Debian
<pitti> ?
<geser> pitti: see bug 87077
<ubotu> Launchpad bug 87077 in scons "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,Fix released] https://launchpad.net/bugs/87077
<geser> pitti: it was filed upstream (http://scons.tigris.org/issues/show_bug.cgi?id=1689) and the problem seems to be Ubuntu specific
<broonie> Nobody else is going to be defining environment variables with names like that.
<geser> pitti: the affected packages by this bug build successfully with the scons from Debian in Debian and inside a pbuilder but not on the Ubuntu buildds
<lool> Riddell: It would be more interesting to get a screenshot of the full desktop running
<lool> It's quite limitative to only look at OO.o
<broonie> The reason the fix is Ubuntu specific is that it just chops out the affected method of spawning child processes which isn't ideal.
 * broonie = Debian SCons maintainer and author of that patch
<lool> Globally, I find use of ooo is really unconfortable; I have plenty of bandwidth, and it's quite sluggish; I can't copy-paste one way or another; closing ooo makes it display the crash recovery tool next time around; it takes some 30 seconds at least to startup...
<Riddell> lool: have you tried the full desktop?
<lool> Riddell: I can't; it's reserved to beta testers
<pitti> geser: why the heck does someone want to pass an env var HASH(0x82db558)="" ? that looks like a bug in xmms2 itself?
<pitti> broonie: ^ (maybe you know)
<Riddell> lool: oh, right
<broonie> You'd need to ask whoever runs your buildds.
<pitti> ah, I see it in the bug, nevermind
<broonie> It looks like Python leakage from iterating over an object.
<cjwatson> perl, not python
<cjwatson> it's an sbuild bug
<geser> pitti: it wasn't only xmms2 which is affected by this, but at least two other packages too
<cjwatson> I guess in our sbuild modifications
<pitti> right, but that should be fixed asap then
<cjwatson> infinity: ^-- (reminder)
<pitti> carrying such package delta hacks over several releases just for this is ugly
<lool> cjwatson: I think I heard about similar HASH() env vars in Debian in the past; I'd suspect it's an old sbuild issue which Debian sbuild doesn't have
<lool> (anymore)
<cjwatson> quite possibly, yeah
<lool> There are so many sbuild forks though
<pitti> seb128: mono-addins approved and promoted FYI
<Riddell> pitti: did you look at libkarma?  do I need to get more information on it?
<pitti> Riddell: I think so; it's in the bug 174306
<ubotu> Launchpad bug 174306 in libkarma "MIR: Please include libkarma in hardy main" [Undecided,Incomplete] https://launchpad.net/bugs/174306
<Riddell> thanks
<pitti> warp10: hm, this changes nonessential things; is this meant for gutsy-proposed or hardy? (changelog says 'gutsy' which is invalid)
<warp10> pitti: sorry, my mistake: it is for hardy
<pitti> warp10: ah, ok
<warp10> pitti: should I prepare another debdiff or you'll take care of this?
<pitti> warp10: don't worry, I can do that simple replace :)
<geser> Hobbsee: you should hug pitti for sponsoring scons :)
<Hobbsee> pitti: thanks for becomming the maintainer of scons :)
 * Hobbsee hugs pitti
<Hobbsee> may it give you much joy and colour :)
<Riddell> pitti, seb128, Hobbsee: anyone remember rejecting python-kde4?  it doesn't seem to be in new any more and there's no message in ubuntu-archive
<pitti> Hobbsee: it doesn't have my name in the changelog, don't worry
<Hobbsee> Riddell: i only did the first one, as tonio requested.
<Hobbsee> pitti: you still show up on MOM
<pitti> Riddell: *scratching head* not really
<cjwatson> seb128: could you look at bug 131751, please? It looks like you dropped part of Ian's changes by mistake in the merge
<Riddell> Hobbsee: rejected it?
<ubotu> Launchpad bug 131751 in consolekit "Unable to switch Virtual Terminal with C-A-F[1-6] on Intel-based new laptop" [Undecided,New] https://launchpad.net/bugs/131751
<Hobbsee> Riddell: yes.  when it had not been reviewed - it was meant to go to revu.
<soren> cjwatson: Heh.. I was just looking at that, actually.
<soren> Why was it again that stracing X didn't work? :-/
<Hobbsee> Riddell: that was not the version that you're asking about, though
<cjwatson> soren: it works if you strace it from something other than an X terminal emulator
<soren> cjwatson: Why does that make a difference?
<cjwatson> soren: if you strace it from an X terminal emulator, X deadlocks when strace tries to print the pid
<cjwatson> it would probably be OK if you used strace >file 2>&1 rather than strace -o file
<soren> ??
<cjwatson> Process 30576 attached - interrupt to quit
<cjwatson> it's when it tries to print that
<cjwatson> AFAIK
<soren> That makes no sense to me.
<cjwatson> *shrug*
<cjwatson> seems to be the case :)
 * soren falls over
<persia> soren: it's a loop.  strace is the child, so all the strace output generates strace events, etc.
<cjwatson> or possibly it's the terminal emulator tries to do something else
<soren> That's..
<cjwatson> s/tries/trying/
<cjwatson> at any rate, stracing while sshed in does fine
<soren> persia: So? tcpdumping over an ssh connection works, it just goes wild. It doesn't hang or anything.
<persia> soren: Hmm.  True.
<seb128> Riddell: I didn't reject it, no
<seb128> cjwatson: looking
 * soren tries to strace the gnome-terminal that tries to strace X and see what happens
<cjwatson> seb128: looks like you kept the patch from Ian's first upload, but not the second
<Chipzz> soren: tcpdump -n not port 22? :)
<soren> Chipzz: Sure.
<seb128> cjwatson: this bug has been opened before my upload
<seb128> (reading)
<cjwatson> seb128: the thing I'm seeing is definitely due to the busted merge
<cjwatson> seb128: it's *possible* that the original bug was actually something else and I wrongly attached my report to that bug
<cjwatson> in which case, my apologies, but the problem is still there :)
<seb128> cjwatson: hum, the patch he attached on the freedesktop bugzilla is different of the one in the gutsy package and I used the bugzilla one because that was easier that getting .diff.gz changes
<seb128> cjwatson: will fix that
 * seb128 grrrrrr at people not using a proper patch system for distro changes
<soren> It doesn't apply anymore anyway..
<seb128> great
<soren> Yes, isn't it? :)
<seb128> I'm wondering why the bug would be intel specific though
<cjwatson> I don't think it is
<cjwatson> it may be timing-dependent
<cjwatson> somebody mentioned in the bug that it happened to them with nvidia
<cjwatson> seb128: thanks for fixing that; please update the freedesktop bugzilla patch if you haven't already
<cjwatson> (er, that was obvious I guess)
<seb128> cjwatson: you're welcome, I'll update the patch there
<soren> Oh, you fixed it already
<soren> ?
<seb128> soren: no, but I'm looking at it now
<seb128> soren: and I'll update the patch once I figured what is the right way to fix it ;-)
<soren> seb128: Ah, ok. Got it :)
<seb128> soren: if you have an opinion on the topic you are welcome to share it though ;-)
<soren> seb128: I still blame policykit.
<soren> seb128: Are you aware of how to switch on its debug output?
<soren> seb128: "/etc/init.d/policykit reload" toggles debug mode.
<soren> I'll pastebin the output from when this happens. Hang on.
<seb128> soren: weird, the script has no reload case
<soren> Er... I meant consolekit.
<seb128> ah, right
<seb128> thanks for the hints ;-)
<soren> I get confused by all these new kits. :)
<soren> http://paste.ubuntu-nl.org/47946/
<Hobbsee> soren: it's part of world domination
<cjwatson> tkamppeter_: well done on joining MOTU
<soren> seb128: I think I have a pretty good idea about what's wrong.
<seb128> soren: you are welcome to debug it then ;-)
<seb128> soren: the gutsy version has an extra vt_park_enable which is not in the patch I used for the hardy upload
<seb128> +       /* We park only once: enable is set when a session exits
<seb128> +        * and cleared here when we choose a new session. */
<seb128> +       seat->priv->vt_park_enable = FALSE;
<soren> Looking at the debug output, you'll notice ck_seat_set_park_vt apparantly never gets set.
<seb128> soren: ^ that's the corresponding change
<soren> Er... get called, I mean.
<soren> And that seems to be the only place where seat->priv->vt_park_num gets set, and hence it never figures out that it's supposed to stay on vt 1 (or whichever vt you're switching to, obviously).
 * soren *really* goes to lunch now.
<ogra> asac, http://people.ubuntu.com/~ogra/LightBrowser/ i couldnt resist :)
<asac> looks like fun ... whats that exactly now?
<asac> ogra: ^^
<ogra> mybrowser with hqalf way added bookmark support and some prefs stuff, its a fun project, i'll probably poke around more on it during christmas holidays and finish the functions (just a bit playing around with xul during disconnected travelling the last days)
<ogra> it was scary to recognize how much of my javascrip skills vanished over the last three years when i touched it last ...
<ogra> so a bit practicing isnt bad :) and probably it becomes an app, who knows :)
<ogra> its cool that xclrunner just inherits the plugins with just adding a link so its a fullly functional browser without tab support limited to a single window ...
<ogra> *xul
<ogra> eating only 20% of ram ff needs
<asac> cool
<asac> ogra: so i can count you in to the set of ubunt devs that can develop xul apps :)
<asac> welcome!
<ogra> lol
<cjwatson> delegation in action
 * ogra grins
<Hobbsee> or increases in insanity on display, yes..
<ogra> xul is fun, its like my old perl cgi/javascript db webapps i wrote back in other jobs :)
<ogra> just no perl involved (luckily)
<asac> ogra: so you adapted the midbrowser concept to have the toolbar at the bottom? why that?
<ion_> sub { $_[0]->("$_[1]!") }->(sub { print "Hello @_" }, "world")
<ogra> the mybrowser code had that ...
<asac> oh
<asac> ok
<ogra> i just took what was there and started adding features
<asac> ogra: actually, epiphany upstream devs are trying to do that: make a xulapp out of epiphany
<ogra> (and modifying the existing stuff)
<asac> but i guess it won't be ready for hardy (only the old gtkmozembed thing) ... so maybe help out there ;)
<ogra> that should be trivial
<ogra> well, i have a lot on my plate already i guess working into the epi code is a bit harder than taking twh 100 LOC from mybrowser and addin another 100 :) but i`ll take a look
<asac> ogra: cool ... feel free to add a bzr branch to ~mozillateam :) ... I am looking for xulapps to include in hardy. if the browser becomes usable i am happy to ship it :)
<asac> ogra: so what is missing to get a fully functional browser? bookmarks? certificate management?
<asac> anything else?
<asac> does typeahead find already work?
<ogra> i want it to run fullscreen, havent found the right trigger for that yet (and it seems xul isnt ready in that area either yet)
<ogra> adding bookmarks and setting the homepage works fine, removing bugmaks is missing
<asac> ah :)
<ogra> heh
<ogra> funny typo
<asac> fullscreen should be possible ... i will try to look it up if i need a distracting minute :)
<ogra> the font scaling only exists in the ui yet
<ogra> not in the embedded browser ... i need to look how its done in ff
<ogra> ah, and all typical ff keycombos work :)
<asac> ogra: you have to use the FullZoom method on the html document you can get from the browser
 * ogra rarely uses the mouse while browsing
<asac> (that zooms images as well ... which is what ffox 3 does now)
<ogra> ah, nice, thanks for the hint
<soren> seb128: Any progress?
<seb128> soren: didn't look at it yet, I've it next on the queue for when I'll be done with the gdm merge
<soren> seb128: Oh, ok. I'll stop pestering you then :)
<seb128> soren: I was not sure if you were on your way to fix it and didn't want to duplicate work too ;-)
<soren> seb128: Well... I was hoping that shouting random semi-useful hints here and there might magically fix it. :)
<seb128> soren: that's useful informations, thanks, I'll look at it when the gdm update is uploaded
<soren> seb128: I've got a stack of stuff, that I'm actually supposed to be looking at, which is not really the case for consolekit. I just got fed up with not having access to my console. :)
 * soren hugs seb128 
 * seb128 hugs soren back
<michael14486> does anyone know of a program to generate .deb files?
<seb128> michael14486: debuild
<cjwatson> michael14486: https://wiki.ubuntu.com/UbuntuDevelopment#head-86b3c262f4e4b222c867211cb06bb46523c7cc6f
<michael14486> thanks
<ppum> hey guys, just wanted to ask when the linux-restricted-modules 2.6.24 will be out ?
<cjwatson> ppum: it's been uploaded, just needs to actually build now
<chand> ppum: i don't know but there is a problem with amd/nvidia drivers http://lkml.org/lkml/2007/11/1/257
<michael14486> is there any way to  graphicaly  make .deb packages (none of the command line ones worked for me)
<michael14486> ???????????????/
 * ion_ chuckles
<cjwatson> michael14486: not to my knowledge; everyone here uses command-line tools for this
<cjwatson> michael14486: I would recommend finding a different channel; this channel is for development of Ubuntu itself
<bdmurray> dholbach: I plan on testing that some today
<cjwatson> we're not really set up for mentoring people who just want to do one-shot packaging
<dholbach> bdmurray: ROCK
<cjwatson> michael14486: if you're just trying to package something for your own use, checkinstall may help you
<michael14486> my programs are al shell scripts that run from bin to accsess the itunes store
<Hobbsee> cjwatson: shame on you, recommending checkinstall...
<Hobbsee> cjwatson: next you'll be mentioning yada, and other crackful tools.
<cjwatson> Hobbsee: I'm not recommending it for packaging software in the Ubuntu archive.
<ogra> Hobbsee, why, for personal use thats fine
<Hobbsee> ogra: i've seen too much of the "of personal use only.  oh, i think i'llj ust share this ready-made deb"
<ogra> you just need to keep track of it to not forget about it at dist upgrades
<ogra> since there it myght get tricky
<Hobbsee> ogra: or "checkinstall is bad, it does not package a program with a library in it correctly"
<Hobbsee> cjwatson: so you have not gone utterly insane.  good :)
<ogra> the package description should probably have a warning :)
<ogra> (up to a clever MOTU i guess :))
<Hobbsee> ogra: now really.  no one is silly enough to do such a thing.  TIL principle.
<michael14486> whats so bad about checkinstall and yada?
<cjwatson> michael14486: they produce unfortunate results when used for packages in Ubuntu itself. That isn't to say that you can't use checkinstall for local use only.
<Chipzz> michael14486: they just package up the contents of a directory, which may not be the correct thing to do
<cjwatson> Chipzz: that's what checkinstall does, but not yada. They're very different.
<ogra> michael14486, its missing dependencies fro example, so it will only work on the system you compiled on
<Chipzz> michael14486: some files are supposed to be generated
<cjwatson> yada is deprecated hereabouts because it's just obscure and hard to read
<Chipzz> michael14486: like for example the fontconfig caches and gtk icon themes (just to name a few)
<cjwatson> at any rate, I think we are confusing michael14486 far more than we are helping him
<Chipzz> if you just package these files, they'll overwrite existing files which leads to disaster
<cjwatson> michael14486: your best bet is really to read the packaging guides and take it from there
<Chipzz> cjwatson: I was only talking about checkinstall anyway ;)
<michael14486> so when its installed it will over write the files like bin that it installs to?
<Chipzz> michael14486: if the files in your package are mutually exclusive to the files installed on the system, it may not be that bad (though it's still inappropriate)
<michael14486> and will the packaging guides work with scripts and no programs (thats what i use because i dont know enough c to really do anything)
<cjwatson> packaging shell scripts is strictly simpler than packaging C programs
<cjwatson> but this is not appropriate for this channel
<cjwatson> I suggest #ubuntu-motu
<Chipzz> michael14486: the gist of it is, a lot of files are actually meant to be generated in the system in which they're supposed to work; if you make a package with checkinstall, it just (temoporarily) installs into a seperate dir and packages that. that temporary dir is distinct from (and often conflicting with) the system the package is supposed to be installed in
<geser> doko: as curl (main) depwaits now on libssh2-1-dev (universe) is it ok to drop that build-dependency?
<Chipzz> and I'll shut up now :)
<doko> geser: hmm, I think I have to ask cjwatson and pitti again about main inclusion
<pitti> geser: personally I'd prefer dropping it, yes; what actual benefit does it give us? ssh isn't even enabled for the gnutls build
<ogra> pitti, any opinion about devscripts and the added dep while youre at giving recommendations for MIRs ? :)
<pitti> openssh is a mature project, and people still find holes in it occasionally; libssh2 gets much less attention and is much younger
<pitti> ogra: that perl lib? that sounded harmless enough, but I need to read your mail again
<ogra> it is harmless i think but since we try to reduce main stuff its also something we dont use at all
<geser> pitti: as curl builds without this build-dependency, I'll prepare a debdiff
<pitti> ogra: so, if we have a diff anyway, we can leave it out; if dropping the build dep would be our only delta, it's easier to promote such trivial libs
<pitti> erm, s/dropping//
<ogra> pitti, well, there is one extra build dep diff (we add lsb-release), i'll drop it then
<ogra> still enough time for complaints and switching it :)
<geser> pitti: bug #175891 if you have time
<ubotu> Launchpad bug 175891 in curl "[hardy] Drop libssh2-1-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/175891
<geser> any other main sponsor is also welcome
<Hobbsee> someone broke amd64 quite badly, it appears.
<pitti> Hobbsee: ?
<Hobbsee> http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html
<pitti> ah, probably seb's fault :)
<Hobbsee> yeah, blame seb128 todya.
<seb128> gni?
<pitti> no, just a gtk+2.0 buildd desync, I guess
<seb128> pitti: right, looks like
<pitti> libgtk2.0-0 is held back on a dist-upgrade
<pitti> ah, it FTBFSed on i386, built on amd64
<Hobbsee> oookay?
<pitti> hm, now it's needsbuild
<pitti> seems someone just gave it back?
 * Hobbsee did not.
<seb128> pitti: needs a retry
<Hobbsee> sparc is needsbuild, not other arches
<seb128> pitti: apparently slomo changed it to require the new directfb but didn't update the Build-Depends requirement
<pitti> ah, my fault; I looked at the wrong tab
 * pitti gives back
 * seb128 hugs pitti
<pitti> argh, buildd.py fails on + in package names
 * pitti fixes that first
<Hobbsee> i thought you fixed that.
<pitti> in versions, not package names
<Hobbsee> i then thought you fixed package names as well
<pitti> no
<pitti> script fixed, gtk retried
<pitti> script on people.u.c. updated <- Hobbsee
<Hobbsee> pitti: thanks muchly
<calc> cjwatson: ping, meeting
<mantiena-baltix> hi all
<mantiena-baltix> pitti: hi, maybe you can tell me where are daily language packs now ? I tried to search and didn't found any official info where I should look for daily language packs, so, maybe you can tell me ?
<pitti> mantiena-baltix: I announced that a while ago; they are in the ~ubuntu-langpack PPA
<mantiena-baltix> I found repository http://ppa.launchpad.net/ubuntu-langpack/ubuntu/ , but I'm not sure if this is official daily language-packs repo
<pitti> http://ppa.launchpad.net/ubuntu-langpack/
<pitti> yes, that's it
<pitti> gotta run now, sorry
<mantiena-baltix> pitti: ok, thank you
<Keybuk> soren: have you been brave enough to look at the mdadm merge?
<Keybuk> (if not, I had a brief look and actually think it's not that scary -- so am happy to claim it back off you and do it tonight)
<michael14486> if i sent someone my files would they make them into a deb packedge
<michael14486> ?????????????????????
<swisgard> thats not how it works
<swisgard> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<swisgard> look at the "request a new package"
<michael14486> thanks ill try that
<claviola> I realize this is not a support channel, but #ubuntu hasn't been able to help in this regard.  I have a box in which the install CD dumps one into GDM instead of just launching a session automatically.  Is there a reason this might happen?  Does the standard 'ubuntu' user from the live cd have a password?
<cjwatson> claviola: I don't know of a reason why that would happen on the desktop (live) CD; the 'ubuntu' user has a blank password
<Spads> claviola: what image did you use?
<claviola> Spads: it's the one one orders from shipit
<cjwatson> that would be the desktop CD
<cjwatson> might be worth checking /var/log/casper.log to see if something broke in the boot process
<soren> Keybuk: No, I never got round to it, so if you could do it, that would be lovely.
<claviola> Yeah, I'm almost sure it's somehow to do with the CD drive, somehow, since this friend who's trying to boot also reported 'errors with something called squashfs'.
<claviola> cjwatson: how can you force a console login to check the log?
<Keybuk> soren: ack
<seb128> cjwatson, soren: consolekit with updated patch uploaded, it fixes the issue on my laptop, let me know if that works for you when the update is available
<soren> seb128: Will do. Thanks!
<seb128> no problem ;-)
<cjwatson> claviola: IIRC you can put 'textonly' on the kernel command line
<cjwatson> claviola: if this is 7.10, though (rather than hardy where it was broken for a bit, see seb128's consolekit comment above), shouldn't ctrl-alt-f1 work? the ubuntu user should be autologgedin there
<claviola> I vaguely remember something that looked like a PAM error
<cjwatson> claviola: if squashfs was bust, you may be just hosed as far as software efforts are concerned; my first recommendation would be to get a CD cleaning kit and apply it to the drive
<cjwatson> it was very likely an I/O error
<claviola> I asked him to not bother me again unless the verification tool says the CD seems okay. :-)
<cjwatson> claviola: unfortunately the verification tool is not a 100% indicator :-/
<claviola> damnit
<cjwatson> (I'm not sure why, I only have anecdotal reports)
<cjwatson> though I agree it is a good initial check
<beuno> hello, any archive sysadmin around?   ar.archive.ubuntu.com has been bisbehaving _seriously_ the past few days
<beuno> (seems a new mirror has been added)
<beuno> we're getting may user reports with 404s
<slomo> seb128: it will also work with the old version
<slomo> seb128: in theory at least, if it doesn't => give me the compiler error
<seb128> slomo: http://launchpadlibrarian.net/10857402/buildlog_ubuntu-hardy-i386.gtk%2B2.0_2.12.3-2_FAILEDTOBUILD.txt.gz
<slomo> seb128: thanks, will fix
<seb128> slomo: you are welcome
<seb128> slomo: thank you for working on the issue ;-)
<slomo> seb128: not now but in a few minutes or early tomorrow :)
<seb128> slomo: no hurry, the retry picked the new directfb version and built correctly
<cjwatson> beuno: perhaps best to mail mirrors@ubuntu.com
<beuno> cjwatson, will do, thanks  :D
<beuno> (wasn't sure where else to ask)
<cjwatson> there's also #canonical-sysadmin (IIRC)
<beuno> ah, yes, sounds familiar, let's give that a try too
<beuno> thanks x 2 cjwatson
<johanbr> beuno: and #ubuntu-mirrors
<beuno> johanbr, aaaaah, sounds much more accurate
<beuno> johanbr, got it, thanks  :D
<lool> keescook: I was happy with the terminus font on xterms for a while; nowadays I'm happy with DejaVu Sans Mono in xft mode, but it took some time
<keescook> lool: yeah, I tried terminus.  I seem to have found a great solution though: creating an alias for my preferred bitmap font.  :)
<jcastro> TheMuso: hi, you're listed as one of the leaders of the accessability team, do you guys have a team reporter person?
<TheMuso> jcastro: There is not much of a team atm, so there are no reports forthcoming till we've tidied up the wiki, and got thins sorted, we being me.
<jcastro> ok, so it's safe to assume no report this month then?
<jcastro> I'm just trying to clean up the contacts for each team
<TheMuso> jcastro: No report this month, and not likely for a while.
<jcastro> noted, thanks!
<ScottK> jcastro: Why don't you write up a nice generic "Getting the team established" input.  You can do it without actually knowing anything about what's going on.
<jcastro> https://wiki.ubuntu.com/BuildingCommunity/TeamReporting
<jcastro> you mean like that?
<ScottK> jcastro: Dunno (I've ignored the reporting stuff) just thought it'd be useful to include his 'team' on the list so people keep it in mind.
<jcastro> yes, that's what I'm doing now
<ScottK> OK.  Sounds like you're ahead of me then.
<DarkSun88> Hi all
<pitti> calc: is there a MIR for lzma?
<calc> pitti: yes
<calc> https://wiki.ubuntu.com/MainInclusionReportLzma
<pitti> calc: ah, great; can you please add the link to the bug? I'll have a look at it tomorrow
<infinity> pitti: I'm not sure who to thank, but as my oldest partner in crime for ReducingDuplication, I'm happy to announce that the buildd chroots have gone down from 4 (!) libdb versions to just 1.
<pitti> infinity: ooh, cool
<calc> pitti: ok
<calc> dendrobates: sure go head :)
<dendrobates> calc: thanks.
<Kmos> infinity: check sejon buildd machine.. Not available because:
<Kmos> Builder returned BUILDERFAIL when asked for its status
<infinity> Kmos: I'll poke it in a sec, thanks.
<Kmos> :)
<infinity> Kmos: Fixed, thanks.
<Keybuk> keescook: you were doing the procps merge, right?
<keescook> Keybuk: yeah, it's ready to go -- I've been waiting for the linux-meta bump so people don't freak about about the new sys entry
<keescook> (it's only in the new kernel)
<keescook> but if you want me to, I can shove it in now
<Keybuk> nothing to do with me
 * Keybuk points at slangasek
<Keybuk> he's the merge-freeze-meister
<keescook> well, I guess I better just upload it since today is the end-of-easy-merges
<keescook> it doesn't actually break anything, it'll just frighten people who watch their init scripts 'ZOMG FAIL!' (when it doesn't actually)
<Keybuk> "it's not a merge, it's a new upstream version"
<tormod> keescook, hi that gthumb debdiff I asked you to look at also fixes a autopkgtest failure. maybe it's good to get in before rebuild tests start.
 * LaserJock gives Keybuk a hug
<keescook> tormod: sorry, been behind in email -- still hunting upstream libcairo breakage.  :(
<Keybuk> ooh, huggage
<LaserJock> Keybuk: you have -motu in collective jaw-drop followed by "wow!" ;-)
<_MMA_> LaserJock: Have you seen Emmets reply? :)
<LaserJock> yes
<Fujitsu> Keybuk: What did you mean by `most of the other technical teams'? ubuntu-dev will be a member of most unsupported seed teams?
<_MMA_> LaserJock: The latter point I think is very good.
<Keybuk> err, I think that's what I meant
 * persia read it the other way, but would be happy to be mistaken
<Burgundavia> LaserJock: link to this email?
<LaserJock> https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024854.html
<Keybuk> what's the other way?
 * Fujitsu is wondering that too.
<persia> Keybuk: That those who were members of ~ubuntu-dev, and not explicitly members of other teams would only have upload rights to unseeded software.
<Keybuk> you'd need to be a member of a technical team, or ubuntu-dev or ubuntu-core-dev to upload software
<Burgundavia> Keybuk: would that also mean a merge of Restriced and Multiverse?
<Keybuk> s/ubuntu-dev/motu/ for the effect
<TheMuso> Burgundavia: yes afaiu
<Keybuk> since they're roughly equivalent teams, and I may have got them the wrong way round
<Fujitsu> ubuntu-dev is the aggregate of motu and ubuntu-core-dev.
<LaserJock> Keybuk: right, persia's argument, I think, was that as the number of technical team's becomes large the number of packages for "motu" becomes very small
<Keybuk> LaserJock: which is why it should be members of them too
<LaserJock> right, I think that's where the confusion was
<Fujitsu> That's what I thought.
<Fujitsu> Thanks for clarifying.
<Burgundavia> Fujitsu: this would make multiverse binary-only software
<Fujitsu> Burgundavia: That's what most of restricted is.
<Burgundavia> basically, take all the evil patentwise/dmcawise stuff and put it into restricted and leave the binary only stuff in multiverse
<Fujitsu> I would have thought it would be the other way around.
<Fujitsu> As restricted is meant to be safe, no?
<Burgundavia> no restricted is stuff that is "needed"
<Burgundavia> ati/nvidia drivers
<Fujitsu> Can't I install and use stuff from restricted, safe in the knowledge that I won't be chased by patent owners, wherever I am?
<persia> Keybuk: Thanks for the clarification: You've knocked down points 1 & 3 of my rebuttal.  Only one to go :)
<Fujitsu> Whereas we have patent-encumbered things in multiverse...
<Fujitsu> Don't we?
<TheMuso> Fujitsu: afaik we do yes
<Burgundavia> Fujitsu: yes, plugins-bad-mutiverse and plugins-ugly-multiverse
<LaserJock> perhaps Multiverse/Restricted is a useful split still
 * persia notes there is also a fair bit of purpose-restricted software in multiverse (non-commercial, non-military)
<Fujitsu> persia: Right.
<Fujitsu> restricted and multiverse do have distinctions other than `support'
<Fujitsu> main and universe do not.
<persia> Since multiverse is enabled by default, I don't think restricted/multiverse makes sense as it is today.  On the other hand, there is an argument for a different split based on patents / purposes / etc.
<Burgundavia> Fujitsu: not really
<Fujitsu> multiverse isn't enabled by default, is it?
<Burgundavia> restricted is merely the small subset of multiverse stuff that Canonical supports
<LaserJock> Fujitsu: I believe it is but could be totally wrong
<Fujitsu> Burgundavia: There are no patent/licensing issues in restricted, other than not being modifiable.
<Burgundavia> most of mutliverse is the same boat
<persia> Fujitsu: It is :(
<Fujitsu> persia: Eww.
<LaserJock> I thought there was also some restriction that Restricted was only drivers/firmware whereas Multiverse was anything
<Burgundavia> things like adobe reader, flash, etc.
<Fujitsu> LaserJock: It also has some MySQL documentation, IIRC.
<LaserJock> fine then ;-)
<Fujitsu> Adobe Reader is long gone.
<Fujitsu> And I don't think most of it is just unmodfiable
<persia> Burgundavia: There's heaps & heaps of stuff in multiverse that's either non-modifiable, non-commercial, or non-military, but otherwise sane (and has source).
<Fujitsu> *unmodifiable
<persia> Fujitsu: djb* (although new stuff should be going to universe for the next upload) is one example
<Fujitsu> That's some of it.
<Burgundavia> persia: yes, hence why some sort of sane distinction should be hammered out
<persia> I think the majority of multiverse is non-commercial, but that might just be the packages I tend to touch.
<persia> Burgundavia: Sure, but I think that is orthoganal to the restricted/multiverse question.
<persia> /gan/gon/
<LaserJock> I thought a lot of it was just "not quite DFSG free"
<Fujitsu> persia: The non-commercialism is my feeling too.
<persia> LaserJock: Some is even just "depends on something else in multiverse"
<LaserJock> very true
<LaserJock> so we could have just a " \o/ " pile and a "ewww" pile ;-)
<mjg59`> Trying to split multiverse into different sections based on whether there are patent issues or not would be a bad idea
<Burgundavia> we should have a clear set of criteria. ie: non-commercial --> restricted or patent issues --> multiverse
<Burgundavia> so if somebody wants to add a package, they could see what category it falls under and upload to the correct repo
<Fujitsu> Non-commercial shouldn't be going into restricted, as it's a restriction on use.
<Fujitsu> But having a proper split would be a very good idea.
<mjg59`> Burgundavia: No.
<persia> Burgundavia: PLease use alternate nomenclature to avoid confusion (even "foo" and "bar" would be preferable)
<mjg59`> Burgundavia: Firstly, we are in no position to accurately judge whether something is covered by enforced patents in most cases. Pretending that we're doing so would be giving false comfort to users.
<mjg59`> Burgundavia: Secondly, it potentially leaves us open to wilful infringement charges
<Burgundavia> mjg59`: right, the second was an example
<Burgundavia> persia: again, the basic idea of a checklist is what I am really arguing for, not the names or the specific naming of the repos, etc.
<mjg59`> In any case, depending on what you mean by "use" there's plenty of stuff in restricted that has limitations on use
<Burgundavia> right, multiverse is a whole pile of mostly really nasty issues
<mjg59`> There's no point in trying to make sense of it. Restricted is "Evil but necessary", multiverse is everything else.
<holo> hello
<holo> let me just say that amd wine package is broken
<holo> amd64 i mean
<holo> it is extremely broken, not to say more
<holo>  /usr/lib32/wine/*
<LaserJock> holo: bugs.ubuntu.com is a good place to tell us about that
<holo> ok, i will
<Fujitsu> LaserJock: bugs.ubuntu.com?
#ubuntu-devel 2007-12-13
<Fujitsu> Oh, so it does actually redirect to the right place.
<LaserJock> yeah
<LaserJock> Keybuk: would your plan help upstreams who want to just be able to maintain their packages in Ubuntu?
<LaserJock> for instance could they be given their own seed for there little set of packages? or does that become waaay to many seeds
<Keybuk> I suspect my plan would actually involve some kind of Soyuz feature where it had a link between people and source packages in distributions
<Keybuk> so you could set a maintainer team for any package
<Keybuk> and we'd keep them up to date through the seeds
<Keybuk> so in theory, a non-seeded package could be owned by a team consisting of the upstream and ubuntu-dev, yeah
<Keybuk> *shrug*
<Keybuk> or you could just make a small seed :)
<Keybuk> but yes
<LaserJock> I know Mark was keen on allowing upstreams to have a sane path for uploading their packages
<Keybuk> the idea is to make it easier for people to start contributing to Ubuntu on a more limited set of packages than "here's 10,000"
<LaserJock> and Debian seems to be doing similar stuff with Debian Maintainers
<Amaranth> "here's 10,000" scares the shit out of me :P
<LaserJock> oh come on, it's fun :-)
<Keybuk> but also, we wouldn't want "maintainers" in the debian sense - which is why ubuntu-dev should be in all of the teams
<Amaranth> yeah, that's why i'm motu but haven't uploaded a single package yet :P
<LaserJock> Keybuk: exactly
<Fujitsu> Hm, why would a package FTBFS here without libxext-dev, but not in Debian? I thought our X stuff was fairly similar.
<slangasek> Fujitsu: for some reason, the Debian libx11-dev depends on libxext-dev and the Ubuntu one does not
<somerville32> slangasek, I was doing some goggling today and you can be mean :P
<slangasek> somerville32: why yes, I can :)
<Fujitsu> slangasek: Aha. Would that be a bug on our side?
<slangasek> Fujitsu: I don't know; I haven't looked closely to see if there's bugginess anywhere, or just a difference in how the packages are built
<Kmos> Fujitsu: it's not the first one.. i've a similar one this week, let's find it
<Fujitsu> Kmos: Not the first one of what?
<Kmos> [00:44] <Fujitsu> Hm, why would a package FTBFS here without libxext-dev, but not in Debian? I thought our X stuff was fairly similar.
<Kmos> it's xdemineur package
<Fujitsu> I know there are quite a number, and we carry diffs for several.
<Fujitsu> That being the only delta.
<Fujitsu> And Debian rejecting said delta when you (Kmos) forward it to them.
<Kmos> for example.. libx11 in debian experimental doesn't depends on libxext-dev, but the version at unstable depends on it
<Kmos> so, debian maintainer of xdemineur, updated the package and added libxext-dev to b-d
<Kmos> :))
<Kmos> so we have synced it
<slangasek> Fujitsu: well, in general if a package references xext directly, and doesn't build-depend on it, this is a bug in that package regardless of whether libx11-dev should have a dep on libxext-dev.
<slangasek> Fujitsu: so if Debian is rejecting these fixes, please point me at them :)
 * Fujitsu digs up that bug.
<Fujitsu> Debian bug #455224 is an example of a rejection (one of Kmos', in fact)
<ubotu> Debian bug 455224 in bbkeys "Please add libxext-dev to build depends" [Normal,Open] http://bugs.debian.org/455224
<slangasek> ah, well
<Kmos> Fujitsu: that one is very aggressive from Bruno :( it's one of the debian developers that doesn't care about ubuntu
<slangasek> Kmos: but it's a strategic error on your part to submit a bug to Debian saying "we did this in Ubuntu, please do it too" instead of explaining why it's also a bug in the Debian package :)
<Kmos> slangasek: you're right
<Kmos> i need to go.. 2 am here
<Kmos> cya
<slangasek> ok, Debian bug #455224 reopened with commentary
<ubotu> Debian bug 455224 in bbkeys "Please add libxext-dev to build depends" [Normal,Open] http://bugs.debian.org/455224
<Fujitsu> slangasek: Danke.
 * StevenK waits for the BTS to catch up
 * persia admires slangasek's skill with a laser pointer
<TheMuso> Hrm. Is the autosync likely to be run before DIF?
 * persia hopes so, as otherwise DIF would already be in place.  perhaps at DIF?
 * StevenK waits for Bruno to reply to slangasek, "My packages don't have bugs. This is Debian."
<slangasek> StevenK: that would be unfortunate, because then I would have to give somerville32 another example of my meanness
<StevenK> Haha
<soren> If a conffile gets renamed, that should be handled in preinst, right?
 * soren is allowed to ask stupid questions at this hour
<slangasek> soren: in order to allow the dpkg conffile handling to trigger during the unpack phase, ye
<zul> hey soren
<slangasek> s
<soren> zul: Ahoy.
<StevenK> slangasek: Maybe you could take a leaf out of my book and reply back, "Bruno, I am going to eat your liver." ? :-P
<soren> slangasek: Thanks.
<slangasek> now, which was the package I NMUed where I handled conffile migration on downgrades.. :)
<StevenK> Hah
<soren> \o/ multipath-tools uploaded.
 * soren needs sleep... badly.
<slangasek> lamont: looks like gettext hasn't been uploaded yet?
<somerville32> Does the linux packages not use a patch system?
<Fujitsu> somerville32: It's in git.
<somerville32> I mean, our linux packages
<somerville32> or do we have it in bazaar or something?
<mjg59> It's also in git
<somerville32> Why are we using git?
<Fujitsu> Because upstream does.
<slangasek> for easier interop with upstream
<somerville32> Where is it hosted?
<infinity> kernel.ubuntu.com
<slangasek> https://wiki.ubuntu.com/KernelGitGuide
 * Fujitsu points at https://wiki.ubuntu.com/KernelGitGuide
<Fujitsu> Blergh.
<slangasek> :)
 * somerville32 goes to patch the kernel! :)
<lamont> slangasek: it was a bad day. doing gettext now.
<lamont> slangasek: did someone do libtool already, I wonder?
<lamont> gettext testbuild running
<slangasek> lamont: libtool is still on the menu
<slangasek> but it's a -1 increment, so I'm not too worried
<choudesh> what is up with the gnome-orca package in hardy?
<choudesh> suckers been broke for weeks
<encompass> Howdy everyone!
<doko_> TheMuso: do you merge espeak as well?
<warp10> Hi all!
<TheMuso> doko: I don't see the point, as we've essentially got the same changes as Debian. I'm going to work with Debian for the next upstream release so we can just sync.
<doko> TheMuso: ok, thanks
<kagou> Good morning
<dholbach> good morning
<TheMuso> Hey dholbach.
<ion_> Hi
<dholbach> heya TheMuso, hey ion_
<kagou> hey dholbach
<dholbach> hi kagou
<pitti> Good morning
<Burgundavia> hey pitti, mvo
<mvo> hey Burgundavia!
<StevenK> Morning pitti
<warp10> hey pitti
<MacSlow> Greetings everybody!
<pitti> hi MacSlow
<MacSlow> Tag pitti
<mvo> dholbach: do you mind if I do your gnome-mag merge?
<dholbach> mvo: not at all
 * dholbach hugs super-mvo
<mvo> thanks dholbach!
 * mvo hugs dholbach
<dholbach> :-)
<LaserJock> is there any one person that takes care of abiword?
<TheMuso> mvo: I'm already half way hrough it, if you've got more important things to do, I can finish what I've started.
<TheMuso> through it
<mvo> TheMuso: sure, I leave it then
<Keybuk> I am delighted by the BT engineer's disbelief at how my house is wired
<Burgundavia> Keybuk: the sheer number of devices or the amount of network cable?
<Keybuk> the fact that apparently one of the last endless procession of BT engineers wired it so that the phone line comes into the master socket, goes upstairs to another socket there, and then comes back to the master socket again
<TheMuso> That is crazy.
<Burgundavia> wow
<seb128> lamont: did you look at bug #175775 or did you re-do the gettext update?
<ubotu> Launchpad bug 175775 in gettext "Please merge gettext 0.17-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/175775
<mvo> anyone working on the hotkey-setup merge?
<MacSlow> hi mvo
<MacSlow> dholbach, Aaaalter... Schwede! :)
<lool> TheMuso: Hi there; just sent a proposal for promotion to main of colorblind; I heard you were interested with this subject
<TheMuso> lool: Ah right. Funny you should mention that, as if colorblind was in main, gnome-mag could be synced. :)
<TheMuso> As the only ubuntu change is to not build against it.
<lool> TheMuso: It's because I wanted to work on the gnome-mag merge that I noticed actually ;)
<mvo> hey MacSlow
<TheMuso> So, depending on how quick a turn around an MIR for something like that is, I may wait on the merge, and just sync when colorblind is in main.
<TheMuso> lool: Right.
<TheMuso> lool: Ubuntu already has the same upstream as Debian, so I think waiting for colorblind to come in and syncing makes more sense actually.
<TheMuso> .c
<TheMuso> ugh typo
<mvo> cjwatson: do we use the dash udeb? it got removed from debian
<StevenK> I thought we used busybox?
<mvo> I think so too, but I'm not sure enough
<StevenK> mvo: Me either.
<Kmos> Not available because:
<Kmos> Builder returned BUILDERFAIL when asked for its status
<Kmos> kohnen builld machine
<Kmos> *buildd
<Kmos> infinity: you already know about this error :)
<StevenK> Kmos: Yeah, but it's 3am where infinity is.
<Kmos> oh god :( sorry
<StevenK> I doubt an IRC message will get him out of bed.
<Kmos> me too
<mvo> StevenK: aren't you in the same TZ as him?
<seb128> dholbach: the vinagre sponsorship request is on hold because it requires a new gtk-vnc and this one is buggy, should I do something to get vinagre out of the "waiting on sponsor" stats?
<dholbach> seb128: no that's fine, I'll just ignore it on the list as I know you're handling it - that's fine
<dholbach> if you want, you can unsub the sponsors team
<seb128> ok
<dholbach> but it's not necessary, I'm sure it'll be done soon
<seb128> yeah, I'll not unsubscribe
<seb128> the things is that the gtk-vnc upstream tarball is buggy
<seb128> I'm wondering how the guy who did the update managed to build it
<dholbach> oh nice
<seb128> my guess is that he didn't even try
<seb128> because ./configure doesn't work, the tarball lacks an install-sh
<dholbach> ARG
<seb128> and he did a bunch of other updates, I'm wondering if he's testing anything
<dholbach> best to add that comment to the bug
<seb128> or just running dch and opening bugs
<seb128> I did, waiting for a reply now
<pitti> dholbach: will you care about your three outstanding merges, or shall I help you?
<seb128> pitti: the platform team splitted the remaining merges during the meeting yesterday
<pitti> ok, thanks
<dholbach> thanks :)
<pitti> we might actually be able to sync libgnomemm2.6, but I didn't check the small patch details
<seb128> pitti: lool said he would do this one, you might want to ask him if he had a look yet
<pitti> ok
<pitti> Keybuk: python-distutils-extra is a nice corner case; 1.91ubuntu3 is in Debian unstable, so the package is actually synced; could MoM be taught to not display those?
<Keybuk> not easily
<pitti> ok; easy enough to ignore
 * pitti holds up a transparent "geser for core-dev!"
<encompass> So MeMaker is getting REALLY busy and we need a list... how can this happen?  Does ubuntu provide any, or is there some place we can use to make a list?
<_MMA_> encompass: A list of?
<encompass> _MMA_: mail list, sorry for not being clear enough
<persia> encompass: Ubuntu has mailing lists, but only for Ubuntu.  Do you mean for https://launchpad.net/memaker?
<encompass> persia: yeah... things are getting very busy and we need to get things organized before we get burned out
<_MMA_> encompass: PM.
<persia> encompass: I think it might be tricky to get a mailing list on lists.ubuntu.com (but I'm not an expert).  You might ask in #launchpad if there is any support there.
<encompass> persia: thanks I will
<persia> encompass: Good luck.
<se2> re
<seb129> re
<seb129> I've issue with dapper being very slow to boot on a recent enough computer (PIV 2.4GHz), each boot line is taking some seconds
<seb129> did anybody already had a similar case or any idea on what could create that and fix it?
<seb129> windows works correctly on the box
<seb129> debian has the same slow boot issue
<seb129> the issue is not only at boot, it's a slow when using
<Mithrandir> seb129: it's very disconcerning when you have a off-by-one bug in your nick.
<StevenK> Bwahaa
<seb129> Mithrandir: write to the correct nickname I'll read it anyway :p
<lamont> seb128: I applied our patch to gettext 0.17-2
<seb129> ok, nobody has an idea about that?
 * lamont notes that someone bumped kde up to 5000 in the queues... I guess that means they're done uploading kde 16 times. :-)
<Hobbsee> lamont: no, just parts of it sorry
<Hobbsee> lamont: but i've put in the hope of that, yes.
<Hobbsee> lamont: whether the uploaders do it is another story, perhaps.
<lamont> and the fact that hppa hasn't launched a build in about 12 hours means that it's academic until we figure that out
<lamont> Hobbsee: given that pretty much any package whose name starts 'kde' takes 1-5 hours to build, and the burstiness of the uploads, I have been known to smack them down to a build pri of 300 so that hppa can get through the queue
<Hobbsee> lamont: by all means, but make sure the base packages get built before the rest do.
<lamont> OTOH, it's only fair to let them in sometime, and besides, LP keeps reprioritizing them.
<Hobbsee> which is why some of them got bumped in that order.
<lamont> ah, makes sense... so they don't do versioned build-deps either, eh?
<Hobbsee> well, sure they do
<Hobbsee> but LP of course goes and tries the others, before the base ones.
<Hobbsee> which still takes time and such
<bigon> hi, is it normal that there is no more usbfs mounted on hardy?
<persia> bigon: Mostly.  There's a /dev/usb/ tree that contains much of that information.
<pitti> bigon: not just since hardy; we got rid of that in feisty or so
 * persia thought it was early gutsy
<bigon> bigon@imladris:/dev/usb$ ls -la
<bigon> total 0
<bigon> drwxr-xr-x  2 root root      60 2007-12-13 07:42 .
<bigon> drwxr-xr-x 13 root root   14420 2007-12-13 14:52 ..
<bigon> crw-rw----  1 root root 180, 96 2007-12-13 07:42 hiddev0
<bigon> there is nothin usefull in /dev/usb
<persia> bigon: My mistake: /dev/bus/usb
<bigon> persia: /dev/bus/usb doesn't exist
<persia> bigon: Does for me, but my system is known to be odd.
<bigon> lsusb says nothing
<bigon> mm
 * bigon reboot
<persia> bigon: Do you have the right modules loaded?
<Keybuk> pitti, mvo: ping
<mvo> hello Keybuk
<bigon> ok it's a kernel issue with 2.6.24
<bigon> with 2.6.22 I get /dev/bus/usb, with 2.6.24 i don't
<persia> bigon: Likely a udev / kernel coordination thing.  Do you get /sys/bus/usb?
<Keybuk> that's correct
<persia> Keybuk: Is there another transition planned for that information, or is this just expected hardy breakage while development is underway?
<Keybuk> ?
<Keybuk> it's expected breakage for running non-default kernels ;)
<persia> Keybuk: Ah.  Right :)
<Keybuk> the userspace bits haven't caught up yet
<bigon> persia: yes I have a /sys/bus/usb directory
<persia> bigon: Then the kernel is doing it's job.  udev should catch up soon (likely around the same time as linux-meta)
<bigon> ok
<bigon> thx
<dholbach>  * Riddell bigs up Kubuntu Tutorials Day in half an hour in #kubuntu-devel https://wiki.kubuntu.org/KubuntuTutorialsDay
 * dholbach passes on the message :)
<seb128> soren: so, does the consolekit upgrade fix your issue?
<seb128> pitti: can you give a build retry to gdm on the archs where it didn't build?
<pitti> seb128: done
<seb128> pitti: thanks
<soren> seb128: I haven't tried it yet. I'm a few days behind on updates on this box..
<seb128> soren: ok
<wip> hi, is there people involve in the rt kernel?
<_MMA_> wip: #ubuntu-kernel is the place.
<wip> _MMA_: thanks
<pitti> mvo: hm, your python-apt merge looks like it shuold have been a sync?
<mvo> pitti: it needs to build against the right version of apt
<mvo> pitti: but yeah, its *very* close
<pitti> mvo: ah, just b-dep version change?
<pitti> well, that's just a timing issue :) but nevermind
<mvo> pitti: heh :)
<geser> lamont: can you give-back librpcsecgss and biloba? (FTBFS due to chroot problems on hppa)
<lamont> geser: are they chroot-problems, or are they build failure?
<geser> lamont: both are CHROOTWAIT: http://launchpadlibrarian.net/10192942/buildlog_ubuntu-hardy-hppa.biloba_0.4-2_CHROOTWAIT.txt.gz and http://launchpadlibrarian.net/10374771/buildlog_ubuntu-hardy-hppa.librpcsecgss_0.17-1ubuntu1_CHROOTWAIT.txt.gz
<lamont> there are 3 that are chroot-failure, I'll give all 3 back once we make sure it's working again
<geser> ok and thanks
<Mithrandir> mvo: any idea what might cause -rw------- 1 root root 4,0G 2007-12-13 06:39 /var/log/apt/term.log
<Mithrandir> ?
<geser> is DIF already in effect?
<DktrKranz> lamont, mind give-back yorick-curses yorick-hdf5 yorick-imutil yorick-soy yorick-yeti ?
<lamont> DktrKranz: architecture?
<lamont> Mithrandir: I'm gonna bet "something looping asking a question."  How'd I do?
<Mithrandir> lamont: not too bad, I believe.
<lamont> ^5
<DktrKranz> lamont, each for yorick-yeti, lpia and hppa for yorick-curses yorick-hdf5 yorick-imutil yorick-soy
<Mithrandir> lamont: it's filled with ^G, though, which is special
<lamont> oh... loop of beeping.  cool.
<lamont> for (;;) { printf("\a\n");}
<Mithrandir> indeed
<lamont> if <wtmp says userid==tfheen> { for (;;) { printf("\a\n");} }
<lamont> DktrKranz: it'll take me a bit - I need to go heads down on something for about an hour and a half or so, it'll be top-of-list after that (any and all yorick-* packages on any architecture that are failed and current)
 * lamont iconifies xchat
<DktrKranz> lamont, no hurry. thanks.
<lamont> my daughter has reviewed "Ubuntu for non-geeks, second edition": "The back of the book is completely unhelpful.  It tells us nothing of why the walruses are in the cover art."
<Asulao> hello. need to use gtk glib functions, but can't seem to find a package named glib or import library. What's the package name in Ubuntu please?
<pochu> Asulao: libglib2.0-dev
<Asulao> pochu: sorry I didn't explain... I want to use glib from python
<Asulao> have gtk installed, but can't seem to find glib functions (if they do exist)
<Asulao> pygtk
<geser> Asulao: then probably python-gtk2
<Chipzz> geser: python-gtk2 does not contain any files with glib in their name
<Asulao> geser: I do have that installed, but can't seem to find a glib.pyc or the sort.
<Asulao> nor documentation for the glib module
<Chipzz> Asulao: what functions do you need exactly?
<Asulao> g_timeout_add and so
<Chipzz> I think you should use gtk.timeout_add
<Chipzz> that's what ggogling suggests anyway
<Chipzz> *googling
<Chipzz> Asulao: anyway, I think #pygtk on irc.gnome.org would be a more appropriate place to ask
<Asulao> ok. great. I'll go there. many thankses. :-)
<mvo> Mithrandir: woah, that is impressive. what does it look like inside?
<mvo> Mithrandir: and where do you see it?
<Mithrandir> mvo: on a gutsy amd64 server.  It mostly contained ^G-s
<geser> looks like the last dash upgrade broke the sparc buildd :(
<Kmos> geser: yep..
<Kmos> http://launchpadlibrarian.net/10890584/buildlog_ubuntu-hardy-sparc.nginx_0.5.33-1_CHROOTWAIT.txt.gz
<mvo> geser: ohhhh
<Kmos> geser: Mithrandir is fixing it
<mvo> Mithrandir: could I get access to a compressed version? I assume it compresses quite well ...
<Mithrandir> mvo: sorry, I needed the disk space so I nuked it. :-(
<Mithrandir> mvo: I'll make sure to tell you if I see it again
<mvo> Mithrandir: ok, sorry for the trouble :/
<CarlFK> cjwatson: where do I submit a patch for bug #38442 ?
<ubotu> Launchpad bug 38442 in ubiquity "Ubiquity dialogues too large for 800x600 display" [High,Confirmed] https://launchpad.net/bugs/38442
<torkel> CarlFK: attach it to the bug
<CarlFK> thanks
<Burgundavia> CarlFK: I love you
<CarlFK> well, lets see if it is acceptable before we rush into things :)
<Chipzz> can't this just be fixed in the glade file or something
<Chipzz> oh and btw
<Chipzz> CarlFK: on a seperate note
<Chipzz> CarlFK: gtk+ devel had patches for natural size for widgets
<Chipzz> *has
<Chipzz> maybe these could be an improvement too?
<Chipzz> CarlFK: please take a look at: http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html
<Chipzz> (and following messages)
<CarlFK> looking
<Burgundavia> slangasek: I can write the release notes for alpha2
<Chipzz> cjwatson: ping
<bryce> I'm trying to rebuild my hardy pbuilder tree, however when I run `sudo pbuilder --create hardy`, I get this error:
<bryce> The following packages have unmet dependencies:
<bryce>   aptitude: Depends: libapt-pkg-libc6.6-6-4.5 but it is not installable
<bryce> E: Unmet dependencies. Try using -f.
<bryce> any ideas what's wrong?
<slangasek> Burgundavia: yes please :)
<slangasek> Burgundavia: but where is the camera that lets you see I was just writing mail to ubuntu-marketing?
<Burgundavia> slangasek: don't need a camera. I have a direct brain feed of every Canonical employee
<slangasek> is that what that tickle is
<bryce> heya tor
<bryce> heya tormod
<tormod> hi bryce
<Burgundavia> slangasek: send the email anyway, it will help me remember to do it
<slangasek> Burgundavia: right-o
<nixternal> any archive admins hiding around here? we are having problems with hardy and main...can't pbuild with hardy, not can we update hardy pbuilder...404 on main
<geser> bryce: a new apt in hardy, all reverse depends needs to be rebuild
<bryce> geser: ah, is this something I can work aroudn on my end, or just wait for it to finish?  is there an eta known for when it'll be working?
<geser> bryce: looks like you need to wait for the next publisher run, see https://edge.launchpad.net/ubuntu/hardy/+source/aptitude/+builds
<bryce> thanks
<blueyed> Can somebody please decide if Gimp final (2.4.2) should go through -updates/SRU or -backports, please? See bug 157642 and bug 164795. 2.4 is a bugfix only branch and users are quite embarrassed to have a buggy rc in gutsy.
<ubotu> Launchpad bug 157642 in gimp "gimp 2.4 *final*  in gutsy" [Undecided,New] https://launchpad.net/bugs/157642
<ubotu> Launchpad bug 164795 in gutsy-backports "Please backport gimp 2.4.2 from hardy to gutsy" [Undecided,New] https://launchpad.net/bugs/164795
<jdong> blueyed: what is the nature of its bugginess?
<StevenK> I still note that "buggy RC" is yet to followed up with other bug reports.
<blueyed> zless /usr/share/doc/gimp/NEWS.gz for a start
<blueyed> It might be OK to decline it for SRU, but somebody should do so.
<StevenK> blueyed: You still haven't answered my question.
<blueyed> StevenK: I don't see any question from you. And I've provided a list of bugfixes, as you've requested.
<StevenK> blueyed: Ah, I wasn't talking about bug fixes, I was talking about bug reports on Launchpad.
<StevenK> In fact, I said "bug reports"
<blueyed> StevenK: An unreported bug which got fixed is no bug? Anyway, I've not triaged gimp yet much (but enough to have seen the cry for an update). I'm just asking for a decision.
<StevenK> I'm yet to be completly convinced aside from users saying "How unprofessional is shipping an RC of gimp?"
<jdong> blueyed: well if there's a huge shotgun list of bugs/defects that users are experiencing, then I think the argument can be made, but I don't see that so far....
<StevenK> Exactly my point.
<jdong> blueyed: it'd also depend on how much testing the new version has gotten, and how much the interface/plugin-API changed
<blueyed> I understand.
<blueyed> jdong: it's bugfix-only.
<jdong> how large is the debdiff between the RC and final?
<blueyed> the one from hardy?
<jdong> well... I guess?
<StevenK> Yes, but saying it's bugfix only and pointing at real, Confirmed high-impact bugs on Launchpad are two *very* different things
<StevenK>  881 files changed, 81411 insertions(+), 105144 deletions(-)
<StevenK> Right, "bug fixes"
<blueyed> jdong: the debdiff is 50M, but most is moved changelogs and .po stuff.
<LaserJock> holy crap
<jdong> blueyed: ok, do you know what number of bugs people are actively experiencing in our RC of gimp?
<LaserJock> oops, sorry there
<jdong> blueyed: if it's a small SRU-able number I think they should be individually targeted.... this big of a change is hard to argue for -updates unless the package is totally dysfunctional to begin with
<jdong> (well all releases of gimp are dysfunctional in my hands but that's a different matter :D)
<blueyed> jdong: yes, I understand. I'll then just add a comment to the -updates-bug and ask people to name/triage real bugs. I'm not a gimp user really either.
<LaserJock> we should take care of the SRU bug though
<jdong> blueyed: right, I think that's a good start. Let's estimate the impact then decide what needs to be fixed.
<LaserJock> we tend to leave things linger
<LaserJock> +ing
<blueyed> StevenK: I have "1009 files changed, 606889 insertions(+), 371127 deletions(-)" btw (more)
<StevenK> I will deal with it when seb128 has turned up and I've spoken to him about it.
<jdong> haha
<jdong> "Attached is the debdiff for review....." :D
<StevenK> Oh god, we aren't using that
<jdong> I think this beats my Xgl debdiff record :)
#ubuntu-devel 2007-12-14
<[reed]> bryce: I can't figure out why my X is dying because silly bulletproof-x overwrites the Xorg logs when it tries to use Xorg.conf.failsafe
<[reed]> I was told that's your fault
<[reed]> is there a way I can work around it? :)
<[reed]> so I can figure out what's really wrong
<[reed]> and fix it
<persia> [reed]: Setting the log rotation to keep a few logs, and looking in the log before last may help.
<[reed]> where do I set that?
<persia> [reed]: I don't remember.  I did it once, and now have .0, .1, and .2 in /var/log/  Sorry.
<[reed]> I have Xorg.N.log(.old)? where N == 0, 9, 20... 20 is really old log from when X was working, 9 is some testserver thing, and 0 is the failsafe stuff
<persia> [reed]: What is 1?
<[reed]> persia: I don't have 1
<[reed]> I only have 0, 9, and 20
<[reed]> :/
<persia> [reed]: Odd.
<bryce> [reed]: hmm, I thought we'd configured bpx to only write a higher numbered log
<bryce> [reed]: anyway, you can disable bpx entirely by commenting out the line in /etc/gdm/gdm.conf:
<bryce> # FailsafeXServer=/etc/gdm/failsafeXServer
<[reed]> ok, restarting with that commented out, my old (and known working) xorg.conf in place, and xorg.conf.failsafe* removed
<bryce> one thing you could check is run /etc/gdm/failsafeDexconf, and then examine /etc/X11/xorg.conf.failsafe to see where it went wrong; the most common error I've seen is that it gets the BusID wrong
<[reed]> all of this is because I tried out displayconfig-gtk to see if I could change the resolution on my second monitor
<[reed]> and now X won't even start properly
<[reed]> :(
 * [reed] will never use displayconfig-gtk ever again
<bryce> look at the end of /var/log/Xorg.0.log
<[reed]> yeah, one sec... I restarted, and I'm just looking at a black screen right now
<[reed]> so, let me get to a console and check some logs
 * emgent hi
<[reed]> bryce: looks like fglrx runs through a lot of modelines, sets dpi / virtual size / display dimensions, runs through more modelines, and then crashes out with a backtrace
<[reed]> with signal 11
<bryce> [reed]: sort of sounds like you have new gfx hardware that the drivers don't know about.
<[reed]> like what? it's been working fine for months
<[reed]> I haven't changed any hardware
<[reed]> :/
<[reed]> I did get a new 22" monitor to play with, but I backed up my xorg.conf before I changed anything, and this is crashing now with my old xorg.conf
<[reed]> ugh
<bryce> well, you're not giving me much information, and so I'm limited to making guesses
<[reed]> ok, what info do you need, and I'll do my best to give it to you :)
<bryce> https://wiki.ubuntu.com/X/Debugging - see "What to Include in Bug Reports"
<[reed]> ok, coming right tup
<[reed]> -t
<[reed]> bryce: http://primedirective.net/xorg/
<[reed]> let me know if you need anything else
<bryce> your backtrace matches bug 165068
<ubotu> Launchpad bug 165068 in linux-restricted-modules-2.6.8.1 "Enabling restricted driver causes X to start in low graphics mode, defaulting to a failsafe vesa driver" [Undecided,New] https://launchpad.net/bugs/165068
<[reed]> ok
<[reed]> brb
<lamont> kobodeluxe 0.4.1-1ubuntu1
 * lamont phears what we changed.
<LaserJock> maybe it's Ubuntu branded ;-)
<Fujitsu> lamont: Phear the .desktop revolution.
<[reed]> bryce: going to try the latest driver now
<nixternal> siretart: you know there are problems with xine-lib right? you have libxine-dev deps on libxine1 which has been replaced with libxine1-bin
<fabio> hello
<fabio> im new here
<fabio> im translator of portuguese
<fabio> 	
<fabio> Everyone is asleepÂ»
<Burgundavia> fabio: try #ubuntu-pt
<fabio> burgundavia: hello friend
<fabio> thanks for the tip
<nixternal> siretart: also an issue with libxine1-dbg dep on libxine1
<persia> nixternal: Does shlibs still define libxine1 as the dep?
<nixternal> no
<nixternal> libxine-dev and libxine1-dbg had libxine1 in the deps
<nixternal> I am rebuilding on my amd64 box so I can install it on my other amd64 box to get kde4 to build...so all of it has worked thus far after a change for libxine-dev
<nixternal> woohoo, rebuilt xine-lib locally..removed libxine1, and then s/libxine1/libxine1-bin/ for -dbg and -dev build-deps and it is working like a champ
<siretart> nixternal: ops, you're right. working on it
<nixternal> siretart: no biggy, very simple fix...already did it locally and tested it..works great
<nixternal> libxine-dev and libxine1-dbg need libxine1 changed to libxine1-bin...I think that is all I fixed to get it to build
<nixternal> and seeing as libxine1-bin replaces libxine1, can you just rip that from control so it doesn't build that as well? not 100% sure on the rules there...you have to file a removal request probably I would assume
<siretart> libxine1 cannot be dropped before hardy
<persia> siretart: Could it be a transition package, with versioned conflicts for libxine1-bin, so both the meaningless transitional library and the replacement could be simultaneously installed?
<siretart> persia: it is already (more or less)
<persia> siretart: OK.  I just got libxine1 knocked out when doing the last upgrade (maybe 10 hours ago), but it could be a local issue.
<siretart> yes, the conflict is wrong, fixing that
<nixternal> that is because libxine1-bin replaces (<< libxine1) iirc
<warp10> Hi all!
<siretart> nixternal: fixed package uploaded
<nixternal> and why do you rock hardcore again? :)
<nixternal> thanks siretart...I figured it was just easier to bug ya about it as I knew you would be around shortly
<siretart> nixternal: yes, in this case this was indeed better, because I applied the fix to the debian packaging branch first, and merged that into the ubuntu hg branch
<siretart> -4 should really be a sync candidate, so that we can finally drop the diversion
<nixternal> ya, that was another reason for poking ya, plus by the time I got everything figured out, you were here anyways :)
<nixternal> I would have filed a bug and hit submit...waste of a bug number..plus didn't feel like adding to the stats for boogs :)
<geser> good morning
<dholbach> good morning
<Mithrandir> hm, I thought the cups PDF thingy wasn't supposed to overwrite files?
<soren> Mithrandir: Dream on.
<soren> Mithrandir: There might be a hug in it for you, if you fix it?
<Mithrandir> soren: currently I'm angry over so much b0rkedness here that I'm not going to do it now.
 * soren pats Mithrandir
<soren> There, there.
<lool> doko: Sorry to bug you about this, but since the fontconfig merge, I have had ugly fonts in firefox here so I guess it is something I should be fixing on my side, do you have a pointer on this?
<lool> I think pitti had the problem the same day I did, dunno if he found a workaround
<doko> lool: hmm, I forgot about that; have to check in the new year ...
<lool> Okay
<soren> cjwatson_: Do you happen to know who maintains the gfxboot patch in SuSE? I want to send the updated patch back to them.
<soren> seb128: Hi!
<seb128> hey soren
<soren> seb128: The consolekit patch seems to work brilliantly.
<soren> seb128: Thanks!
<seb128> soren: good, thanks for testing :-)
<soren> :)
<Kmos> the sparc buildd is fixed? there are several of that need a given-back on there
<geser> Kmos: I'd say no as there is a new log for sparc with the same error from the last hour
<Kmos> geser: we should wait.. thanks
<Mithrandir> Kmos: we'll give back all those once we've fixed the problem.  No need to ask for each of them.
<Kmos> Mithrandir: ok, thanks
<geser> Mithrandir: please give-back: tklib. Thanks.
<soren> At what point will the buildd's start picking a package as a build-dependency? As soon as Launchpad says it's built or not until it's been published?
<Mithrandir> geser: given-back
<Riddell> Mithrandir: please give back kdepimlibs/4:3.97.0-1ubuntu3 (since you seem to be the giving back type today)
<Mithrandir> Riddell: given-back
<Mithrandir> doko: there's nothing special we need to do wrt java on lpia?  You're working on icedtea and all that shiny, right?
 * soren kicks java.. hard!
 * Hobbsee waves
<dholbach> MOTU Q&A session in 6 minutes in #ubuntu-classroom
<tkamppeter> Is the OpenOffice.org packager here?
<Hobbsee> calc is not
<tkamppeter> problem is that "apt-get dist-upgrade" on Hardy wants to uninstall OOo.
<ion_> Often such things are due to some parts of a huge project having been built, and others being still in the queue. Unless something is actually wrong in the packaging, that problem often goes away by time.
<tkamppeter> ion_ it is the case now for more than one week. I hope our build servers are not that time behind.
<ion_> apt-get -o Debug::pkgProblemResolver=true -V dist-upgrade might print useful information.
<Hobbsee> tkamppeter: the less OOo builds, the better.
<Hobbsee> it's probably waiting for a bigger change
<tkamppeter> I have stepped back to "apt-get upgrade" now to get the more than 200 packages updated which queued up in that week.
 * soren kicks the sparc buildd
<dholbach> soren is angry today
<StevenK> He's kicking everything
<soren> I've just spent >1Â½h trying to get java working.
<soren> That will make anyone angry.
<ion_> Thatâs one of Javaâs features.
<dholbach> soren: did you chat with doko about it?
<soren> And when I finally got it to work (in a gutsy vmware instance), the frickin' applet didn't work properly with firefox.
<soren> dholbach: No.. It was not so much a debugging-and-making-notes-along-the-way kind of thing, but more of a get-the-bloody-thing-to-bloody-work-right-bloody-now-'cause-I-just-don't-want-to-know-about-it session.
<soren> Lots of files were copied around, symlinks were created, swear words were invented, core dumps removed..
 * soren grrrrrs
<soren> I just want to forget it ever happened.
<tkamppeter> -ion I have tried "apt-get -o Debug::pkgProblemResolver=true -V dist-upgrade" and it seems that OOo depends on an old version of libhsqldb-java and so the update of libhsqldb-java triggers the removal of OOo
<persia> tkamppeter: During this period of agressive archive churn, you may find aptitude's conservative update behaviour helpful.
<doko> soren: gutsy, or hardy?
<doko> soren: amd64?
<Mithrandir> doko: hiya, did you see my question about lpia and icedtea?
<Mithrandir> (or the stock JRE)
<doko> Mithrandir: no difference compared to i386 (currently ftb on the buildd); don't know why
<Mithrandir> doko: good to hear (well, the no difference part, not the ftbfs part).  You don't need us (the mobile team) to do anything in particular for java apps and the web browser plugin to work, then?
<doko> Mithrandir: not currently
<Mithrandir> doko: ok, thanks.
<soren> doko: hardy. Both i386 and amd64.
<soren> doko: on amd64, j2re1.4 makes firefox crash whenever I access a page with java on it. On i386 I just couldn't get anything to really work at all.
<doko> j2re1.4? how about icedtea?
<Keybuk> there's stuff in the installer that calls udevinfo directly, isn't there?
<Mithrandir> there's stuff in casper that does, at least.
<Keybuk> bugger
<soren> doko: It doesn't provide a plugin for mozilla, does it?
<doko> soren: icedtea-java7-plugin
 * soren takes it for a spin
<soren> doko: Well, it shows up in about:plugins, but the test thing on java.sun.com doesn't seem to work.
<soren> doko: It just leaves a grey box where the cool stuff should be.
<doko> soren: amd64?
<soren> doko: Yes.
<doko> on gutsy?
<soren> doko: Hardy.
<doko> strange
<soren> doko: Sorry, I'll try to be more explicit.
<doko> did work for me. start firefox from a terminal and look at the output. my test was to open classpath.org (and seeing the man stomping the fork)
<Mithrandir> Keybuk: why is that a problem?
<soren> doko: No go. I has saved a log file for me.
<soren> doko: You want it?
<soren> doko: Ah, there's an update for icedtea-java7-bin
<soren> doko: I'll try again.
<soren> No luck.
<soren> doko: Exact same thing happens on hardy i386.
<doko> soren: ok, I'll have it running here. strange. have to look at it after xmas
<soren> doko: Will the hs_err_pidXXXX.log files be of any use to you?
<doko> soren: not really, there's a bug report with some duplicates which have these as well.
<soren> doko: They all say "#  SIGSEGV (0xb) at pc=some_address pid=some_pid tid=some_tid" at the top.
<soren> doko: Ah, bug 152362 ?
<ubotu> Launchpad bug 152362 in icedtea-java7 "icedtea-java7-plugin always crashes firefox" [High,Confirmed] https://launchpad.net/bugs/152362
<doko> soren: one thing you could try: build the package locally and try again. we had problems with the package built on the buildd before
<soren> doko: My firefox doesn't crash. The applet just never does anything useful.
<doko> soren: maybe ask tmarble (#ubuntu-java) as well
<doko> soren: hmm ... we did switch from firefox-dev to xul recently ...
<soren> doko: As a b-d?
<soren> doko: I can grab an older version and try that?
<doko> soren: try it, yes
<soren> doko: Which version should be good?
<soren> ..trying 7~b23-1.5~20071124-4
<soren> Same.
<Keybuk> weird
<Keybuk> when I login, I get a strange "Language en_GB doesn't exist, using system default" warning
<Spads> Keybuk: yeah, server installs don't include locales
<Keybuk> this is a desktop
<Spads> Ah well.  an en_US desktop?
<Keybuk> no
<Keybuk> an en_GB desktop
<ion_> keybuk: I get the equivalent message.
<Spads> I got nothing.
<Keybuk> Spads: are you on hardy?
<ion_> It says the same about en_US in Finnish.
<Spads> Keybuk: nah
<ion_> My locale settings: LANGUAGE=en_US:en LANG=fi_FI.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8
<Keybuk> LANGUAGE=en_GB:en
<Keybuk> LANG=en_GB.UTF-8
<Keybuk> LC_COLLATE=C
<Keybuk> seems to be LANGUAGE it's complaining about?
<Keybuk> (whatever "it" is - I'm grepping strings currently)
<ion_> Whatever âitâ is, âitâ has a bug in a bug: it should have said the error message in English according to my locale settings. :-)
<minghua> ion_: Do you have en_US.UTF-8 in your "locale -a" output?
<minghua> ion_: (en_US.utf8, actually)
<ion_> minghua: Yes.
<minghua> ion_: I don't know, maybe try "LANGUAGE=en_US.UTF-8:en_US:en"...
<minghua> ion_: I assume you don't have en_US in "locale -a" output?
<ion_> minghua: I donât think one is supposed to put .UTF-8 into LANGUAGE.
<ion_> minghua: Yes, thereâs no en_US.
<minghua> ion_: I don't think so either, but who knows. :-)
<minghua> Alternatively, maybe you can do something to make en_US appear in "locale -a" output and see if that helps.
<ion_> There should be no need to do that. It used to work.
<geser> Mithrandir: please give-back: yorick-yeti smpeg-xmms whizzytex. Thanks. (I'd have asked pitti if he were here).
<Mithrandir> geser: given-back
<Keybuk> Mithrandir: was the bundle ok?
<Mithrandir> Keybuk: looks fine to me, yes.
<Mithrandir> Keybuk: I'm assuming you know what udevadm does and how it's called; I haven't verified that. :-)
<Keybuk> there were unuploaded changes in the trunk, so I figured that a bundle would let you worry about the history ;)
<Keybuk> (since merging it will make it look like you merged a branch, rather than retconning history on a new revision)
<Mithrandir> ah, true
<Keybuk> soren: ?
<Keybuk> ImportError: No module named debian_bundle.changelog
<soren> Ah, I thought someone fixed that already.
<soren> You need python-debian
<Keybuk> right
<Keybuk> thanks
<Keybuk> it gave me an editor
<Keybuk> does it expect me to explain the patch there
<Keybuk> or is that just to review the patch?
<soren> First, you review the patch.
<soren> debian/Changelog is already filtered out.
<soren> Anything else that is not appropriate for Debian, you remove manually.
<soren> :wq
<soren> and then an editor shows up with the body of the bug report, which will be based on the latest entry in debian/changelog
<Keybuk> it didn't filter out the "diff" line for debian/changelog ;)
<soren> True.. Feel free to fix filterdiff to do that :)
<Keybuk> also you don't handle epochs properly
<soren> How so?
<Keybuk> epochs don't appear in filenames
<soren> You /are/ running hardy, aren't you?
<soren> Keybuk: Oh, good point.
<soren> Keybuk: ubuntu-dev-tools depends on python-debian in hardy.
<Keybuk> http://people.ubuntu.com/~scott/std.patch
<soren> Keybuk: Thanks very much.
<geser> Mithrandir: please give-back: texpower. Thanks.
<Mithrandir> geser: given-back
<alex-weej> mvo: hi.
<alex-weej> can you prod this through please? https://bugs.launchpad.net/bugs/175646
<ubotu> Launchpad bug 175646 in notification-daemon "Notification summaries should not be parsed as markup" [Low,Triaged]
<ion_> Some guy is saying itâs been decided that this <http://img520.imageshack.us/img520/734/basicidealsactionattachqj1.jpg> will be 8.04âs default theme. Please say thatâs not true. :-)
<_MMA_> ion_: Thats concepts only.
<_MMA_> https://wiki.ubuntu.com/Artwork/Incoming/Hardy/Alternate/BasicIdeals
<Riddell> cjwatson_: am I ok to create a kubuntu-kde4 seed?
<Riddell> Mithrandir: could you give back kdebase-kde4/4:3.97.0-1ubuntu4
<geser> slangasek: need all merges of packages in main now a freeze exception?
<slangasek> geser: in a very limited sense, yes
<slangasek> geser: any Ubuntu developer can "grant" a freeze exception
<geser> I looked at texlive-bin which can be synced now and the new packages it produces would be nice to have as the would allow to install texlive-full (which now has two unmet deps)
<slangasek> geser: don't look at me, after 5 years of bad experiences with tex packaging, I reflexively run screaming at the mention :)
<geser> I just wanted to know what's needed to get it synced (besides the sync request)
<slangasek> I think a sync request is sufficient generally; for texlive, if I were the one processing the request I might want some greater detail to reassure me that it's not going to blow up
<soren> slangasek: So the lesson is: Find a miniscule patch that needs to applied, and just upload yourself?
 * soren runs away
<geser> slangasek: have you some ideas how that "greater detail" might look like? pbuilder build-log?
<slangasek> geser: probably an analysis of any changes to debian/control
<slomo> asac: can you try if http://go-mono.com/sources/gluezilla/gluezilla-1.2.6.tar.bz2 builds with new xul? :)
<asac> slomo: wanna help? i am on holiday till jan 2 :)
<asac> i can try it, but would appreciate to rather help then do it myself :)
<slomo> asac: you have new xul already installed, i just want to hear if "./configure && make" worked ;)
<slomo> but it can wait until after your holidays if you prefer that :)
<asac> slomo: i even have gluezilla here as source :)
<asac> and no ... it doesn't build because it doesn't look for the right pkg-config files
<asac> (without trying)
<slomo> ok
<slomo> thanks
<geser> slangasek: bug #176411 if you want to look on it
<ubotu> Launchpad bug 176411 in texlive-bin "[Sync request] Sync texlive-bin (2007.dfsg.1-2) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/176411
<slangasek> geser: well, /looks/ safe to me... :)
<mvo__> alex-weej: thanks, I check out 175646
<alex-weej> cool
<geser> Mithrandir: please give-back: libchipcard offlineimap c++-annotations cffi. Thanks.
<ivoks> Burgundavia: heh, regarding your blog post :)
<ScottK> I notice that there are a few backports builds for AMD64 on Gutsy that have been sitting and waiting for quite some time while the buildds are idle.  Is there an issue with the Gutsy AMD64 buildd?
<infinity> ScottK: Which builds?
<ScottK> infinity: https://edge.launchpad.net/ubuntu/+source/dkim-milter/2.4.0.dfsg-1ubuntu2~gutsy1/+build/470770 is the one I was waiting for.
<ScottK> When I looked at needs-building I saw at least one other.
<infinity> ScottK: At a guess, I'd say it's just been backlogged behing hardy builds...
<ScottK> infinity: OK.  I'd thought it was different machines.  That makes sense.  Thanks.
<infinity> ScottK: Nah, it's all the same hardware, and *-backports comes last in the queue.
<infinity> updates -> proposed -> release -> backports.
<infinity> (security is on different gear)
<ScottK> Sure.  Makes sense.  Thanks.
<imbrandon> ugh ok, i have a problem, about to email the ML about it but i thought i would kick it arround here first, as most know adobe released a new flash ( 9,0,115,0 ) and i have the updated flashplugin-nonfree in hardy and an SRU in -proposed ... here is the issue
<imbrandon> it works perfect with geko based browsers as reported on the bug, but it breaks Konquorer due to a bug that only this flash exposes
<imbrandon> so if a SRU is pushed ALL konqueror flash installs get broke, but if its not pushed then all new installs are broke
<ScottK> imbrandon: The first thing I'd do is mention that in the bug if it's not already.
<imbrandon> and hardy is broke, soooo do we update and then SRU a patch to konqueror also when it becomes available ? or ....
<imbrandon> ScottK: it is
<ScottK> OK.
<imbrandon> see my delima though ? its like leave it broken or fix some people and knowingly break others
<ScottK> Yeah.
<imbrandon> i hate binary blobs
 * ScottK too.
<ScottK> Well your a Kubuntu dev, where's the Konqueror SRU to go with it? ;-)
<imbrandon> there is no fix ( even upstream yet )
<imbrandon> and likely wont be soon
<imbrandon> as it requires konqueror to support XEmbed ( a new feature that might not be SRU worthy anyhow )
<ScottK> Is it something we could figure out in Kubuntu if we focused on it?  We'll need it fixed for Hardy.
<imbrandon> add XEmbed to konqueror heh
 * ScottK is just saying...
<imbrandon> no no i totaly understand, but thats the fix
<ScottK> OK.  So how hard is that?  Maybe we should --> #kubuntu-devel
<imbrandon> the only other options ( none will go over well with users ) is not support flash-nonfree in konqueror OR only support gnash
<imbrandon> have them conflict
<imbrandon> or something
<imbrandon> ScottK: k
<alex-weej> mvo_: happy with the patch?
<mvo_> alex-weej: patch is fine. if you don't like the patch stuff, maybe we can do something else? instead of a patch in debian/patches just include it inline in the package?
<mvo_> alex-weej: and/or put it into bzr
<alex-weej> i just think it's inefficient to roll out a new notification-daemon every time we change our theme
<alex-weej> is all :)
<alex-weej> doesn't really bother me that much though, i just remembered you talking about it before
<mvo_> yeah
<mvo_> its really not ideal this way, I think the best course of action is to try to get it upstream
<mvo_> but last I talked about it, he didn't like the yellow :)
<alex-weej> well this is the thing, we don't put ubuntulooks in upstream gtk-engines
<alex-weej> why should we do it for the notification daemon theme?
<Chipzz> alex-weej: you could also reverse the question
<Chipzz> why don't we put ubuntu-looks in upstream gtk-engines? there may be some people who like it and want to use it, who aren't running ubuntu
<Chipzz> and ubuntu-looks is not a patch I suppose, rather a seperate engine
<alex-weej> Chipzz: and at that point, we basically relinquish control over the theme to gtk-engines maints
<Chipzz> how so? you would be upstream, pushing changes to gtk-engines
<alex-weej> heh
<alex-weej> assuming i have commit access
<Chipzz> alex-weej: point being, notification daemon is a patch, gtk-engines is a seperate engine
<alex-weej> no
<alex-weej> notification daemon theme is an engine too
<alex-weej> it's its own sofile
<mvo_> yeah, we could put it into its own source package
<Chipzz> heh. then I misunderstood
<alex-weej> and maintain it in bzr
<somerville32> There is a bug in the linux kernel that prevents xfce4-battery-plugin from compiling and I'd like to have this merge done for the next alpha because it contains important patches we'd like tested. Basically, apm_event{,info}_t are userspace types but they got hidden behind #ifdef __KERNEL__ by mistake in commit ee8e7cfe9d330d6f1ce0b9b1620d6df5d9cf6b70
<Chipzz> (alex-weej: as an aside; yes there are people actually doing that (I think); a friend of mine made a post about it in his blog)
<somerville32> I imagine this might also cause other applications (such as xscreensaver) from compiling
<alex-weej> Chipzz: doing what?
<geser> somerville32: could you tell me when this is fixed as I've seen also other packages FTBFS because of this?
<Chipzz> alex-weej: using ubuntu gtk-engine outside of ubuntu
 * somerville32 nods at geser 
<somerville32> geser, I was actually wondering if maybe the kernel team would be willing to apply the very non-evasive patch to fix this in the mean time
<alex-weej> Chipzz: foresight do it, iirc
<slangasek> somerville32: addressing yourself directly to the kernel team (by name, or in #ubuntu-kernel) is probably going to be more effective at getting you an answer
<somerville32> slangasek, ok
<Lutin> would anybody have a look at bug #173717 ?
<ubotu> Launchpad bug 173717 in grub "Grub has a build-depends-indep against a multiverse package" [High,New] https://launchpad.net/bugs/173717
<slangasek> oh, clever; there are two copies of mkisofs in gutsy and hardy, even, one in multiverse and one (the dummy package) in main
<slangasek> someone should've forced package name changes on cdrtools when it was reintroducde
<slangasek> Lutin: well, I've looked but I can't upload it ;)
<mjg59> I'm sure the one in multiverse was supposed to have been removed
<mjg59> The licensing is still inconsistent
<slangasek> oh?  no bug report about it assigned to ubuntu-archive
<mjg59> Ah. I'd discussed it in email with elmo, but never actually filed a bug
<mjg59> CDDLed code linking against GPLed library without any exemptions
<Lutin> slangasek: ok :)
<mjg59> I need to email JÃ¶rg back about that, but haven't had time yet
<slangasek> mjg59: could you file a bug report if you want it removed in the meantime, so I have something I can act on (and point to :)?
<mjg59> Can't make promises about when it'll happen, but yeah
<alex-weej> Chipzz: oh, gtk engine, hm dunno then. foresight use our notification theme
<smcintyre> bug 102982
<ubotu> Launchpad bug 102982 in linux-source-2.6.22 "intel_rng: FWH not detected " [Low,Confirmed] https://launchpad.net/bugs/102982
<smcintyre> Would that bug ^^^ relate to my not being able to reboot?
<mjg59> No
<smcintyre> Hmm ok
<mjg59> Given that that's not a bug, merely an informational message
<smcintyre> failed to reset NO_REBOOT flag, reboot disabled by hardware
<smcintyre> that's my informational message
<smcintyre> Which I would suppose relates to my not being able to reboot :)
<mjg59> That's not related to the bug you mentioned...
<mjg59> And again, no, that won't prevent you from rebooting - that's only relevant for the hardware watchdog
<smcintyre> Ok I saw on the forums that they might be related and that page comes up when you search for the error message and Ubuntu
<smcintyre> So I guess there is no known workaround?
<mjg59> The messages you're getting are unrelated to your inability to reboot
<mjg59> So you should open a new bug about that
<smcintyre> mjg59: What?
<smcintyre> mjg59: The message reboot disabled by hardware is not related to my not being able to reboot?
<mjg59> smcintyre: Correct. It's only referring to the hardware watchdog, which isn't generally used.
<smcintyre> Ah
<mjg59> The watchdog is a piece of hardware that automatically reboots the system if the kernel hangs
<smcintyre> mjg59: Anyway I can get more information as to where reboot stops since that should help you
<mjg59> Yeah. It ought to be a new bug, though.
<smcintyre> mjg59: I see :) thanks for that info
<smcintyre> hi Hobbsee!
<smcintyre> mjg59: ok I have to run right now but I'll bug it later today
<Hobbsee> heya!
<smcintyre> thanks for the insight
<mjg59> No problem
<smcintyre> mjg59: Would reboot abilty from the Live CD be helpful in the bug?
<smcintyre> mjg59: I get libhal errors on shutdown (which works) would that be more related?
<mjg59> Nope, hal can't really interfere with reboots
<mjg59> ANd yeah, the liveCD should be a perfectly fair test
<smcintyre> Ok heading out then.
<ion_> Yay for tracker-applet.
<somerville32> TheMuso, ping
<somerville32> TheMuso, Can you come for a visit in #ubuntu-artwork?
<Mithrandir> geser,Riddell: given-back
<geser> Hi Hobbsee
<Hobbsee> hey geser!
<soren> eroyf: /win 7
<soren> doh..
<mekius> anyone know anything about pata_via?
<soren> mekius: that's not really the question you need answered anyway, is it?
<mekius> soren: :)
<mekius> soren: Well I'm mostly wondering why it's not included
<soren> No idea.
<mekius> soren: k
<mekius> we need it for some hardware and was hoping to avoid an extra package
#ubuntu-devel 2007-12-15
<wolfgang> look that- http://wolfgang-city.myminicity.com/
<slangasek> Riddell: bug #156320 is assigned to you and marked as assigned to you and attached to the hardy-alpha-2 milestone, but the submitter shows an error message mentioning feisty; can you help me fill in the blanks here? (wasn't this bug already fixed for gutsy?)
<ubotu> Launchpad bug 156320 in update-manager "[kde] copy XAUTHORITY may fail and crashes the upgrader (was: Upgrade tool crashed when upgrading 7.04 -> 7.10)" [Medium,Confirmed] https://launchpad.net/bugs/156320
<tekteen> Hi guys. Anyone know how ubuntu figures out ide/sata drives are hard drives and which are cdroms. I am creating a toolkit that partitions a hd.
<sladen> they're all SCSI now ;-)   Except for PCMCIA card readers, which are IDE
<tekteen> I need to figure out what devs are hds
<slangasek> tekteen: /sys
<tekteen> thanks
<tekteen> also I have a kind of noob question about launchpad
<tekteen> can you submit a blueprint if you have no Idea how it would be done?
<tekteen> as a suggestion.
<slangasek> you can, but it's unlikely that someone will take notice of it
<tekteen> ok
<tekteen> tha
<sladen> tekteen: /sys/class/scsi_device/*  vs.  /sys/class/scsi_disk/*
<tekteen> thanks*
<tekteen> ok
<tekteen> thanks again
<sladen> you can file a wishlist bugreport though
<tekteen> ok
<sladen> tekteen: remember, you have the source code:   apt-get source debian-installer
<slangasek> er? where did he say anything about the installer?
<mekius> Anyone know if there are plans to include pata_via in future kernel releases?
<_MMA_> mekius: #ubuntu-kernel
<mekius> ah :)
<mekius> thx
<_MMA_> ;)
<mekius> hopefully get an answer :)
<_MMA_> mekius: As its late in EU and east-cost of the states you might have to wait a bit.
<mekius> ok, that's fine
<mekius> just want to get everything out so when someone does answer it's not something like "More details" :P
<slangasek> it's late in the west coast states too
<mekius> 9pm here
<mekius> not too late :)
<slangasek> mekius: a little late for finding a kernel developer on a friday night
<zul> most of them are our drinking
<zul> or so they say...
<mekius> slangasek: Well I just got time to diagnose the issue :)
<mekius> slangasek: Obviously not looking for miracles here, in fact I didn't expect anything, but figured I'd give it a shot anyway :)
<chuckf> quick question. Who would be the best contact for discussing UDS planning with?
<mekius> Anyone know of any good documentation on discover2 since Progeny is dead and took the docs with them it seems.
<Burgundavia> mekius: are they not in a doc package?
<mekius> not that I can find
<mekius> At least nothing that actually explains things like how to specify options for a driver and such
<mekius> I found a README
<Burgundavia> mekius: you know that Ubuntu doesn't use discover2, right?
<mekius> nvm
<mekius> gOS does
<mekius> does ubuntu still use discover1?
<mekius> is there a reason why it still uses discover1?
<persia> mekius: You may have found it :)
<mekius> i found a guide.txt
<Mithrandir> we're going to get rid of discover1 too, fwiw.
<mekius> will take me some time to dig through though
<Burgundavia> mekius: I suspect largely because discover is mostly superceded by udev, hal, etc.
<mekius> Mithrandir: yeah, I thought I saw something like that
<Burgundavia> the last piece, afaik, is the X driver stuff, which is going away soonish as well
<mekius> Burgundavia: oh?
<Burgundavia> mekius: what are you trying to do?
<mekius> What is replacing that?
<Burgundavia> upstream X stuff
<Burgundavia> I really don't know more beyond that
<mekius> Well, dealing with some VIA hardware and need to load the openchrome driver, but with certain options
<mekius> I could have swore I saw some way to do this at some point
<mekius> Can't find it now though
<mekius> We'll see how good the X stuff is
<mekius> ok, think i found it
<fabio> hello friends
<fabio> any one know seyon?
<fabio> i think is portuguese
<Riddell> slangasek: not really sure what's going on there
<Riddell> slangasek: possibly he doesn't have XAUTHORITY set (which is done by kdesu)
<slangasek> Riddell: so it's not really confirmed as applying to hardy at all?
<slangasek> Riddell: btw, "Filen eller katalogen [...]" is ENOENT
<Riddell> slangasek: what does that mean? :)
<slangasek> Riddell: "no such file or directory"?
<Riddell> slangasek: I wonder if he's started adept through sudo instead of kdesu
<mattwalston> Any known issues with current dhcpd3-server init scripts?  New to ubuntu and can't find the bug tracker.
<persia> mattwalston: https://bugs.launchpad.net/ubuntu/+source/dhcp3
<mattwalston> persia: thanks
<persia> mattwalston: Also, you might want #ubuntu for support or #ubuntu-bugs for bug discussion.
<tekteen> hi guys. anyone know how to run a interactive program on startup on the ubuntu live cd. When I run a script from rc.local it does not allow for user input.
<sladen> tekteen: if it's a GUI app that needs the input, run it after X is up.  If it's a console app, run it in gnome-terminal, again, after X is up
<soren> Hmm... What's stdin connected to during startup?
<soren> Nothing?
<sladen> tekteen: pop something in the .xsession, or run a casper hook to inject something
<sladen>  /dev/tty ;-)
<soren> So why does that not allow for user input?
<tekteen> sladen: I want to start up a menu
<tekteen> sladen: the menu is in bash
<tekteen> sladen: if possible I want it to automatically go to terminal 2 and run the menu.sh
<tekteen> sladen: I created the cd from scratch so x does not start automatically (I did that intentionally)
<sladen> tekteen: remove splash and quiet from the kernel command line, that might/should work
<tekteen> sladen: how would that help?
<sladen> tekteen: you wouldn't be on vt8 with usplash stealing your input
<tekteen> the splash is not stealing the input
<sladen> tekteen: chvt and openvt will help you open a program on another console, if you really need to do that
<tekteen> ok
<tekteen> can I then move what the user sees to another console?
<tekteen> I need to move the user to another console then run the menu in the console
<sladen> tekteen: you can do two things  (a) run programs on particular consoles  (b) select which console the user is shown.  If those two coincide then the user might see the request
<tekteen> yep
<tekteen> I have no idea how to do them
<tekteen> sladen: thanks
<Cacahouete> Hello all!
<Cacahouete> I want to contribute to Ubuntu. Can you give me some advices to start?
<Cacahouete> I have read the page about contributing on ubuntu.com
<Cacahouete> but I need more informations.
<warp10> Hi all
<fabio_> people
<fabio_> where is the channel pt?
<somerville32> fabio_, pt?
<fabio_> portuguese
<somerville32> #ubuntu-pt ?
<geser> !pt
<ubotu> Por favor use #ubuntu-br ou #ubuntu-pt para ajuda em portuguÃªs. Obrigado.
<blizzow> How should I go about patching and recompiling a single driver/kernel module?  Specifically the cx88-alsa module.  I already installed the linux-source package and patched the /usr/src/linux-source-`uname -r`/drivers/media/video/cx88-alsa.c file.
<fabio_> people
<fabio_> i cant instal one game in cedega
<fabio_> says
<fabio_> Sorry, game folders may not have slashes in their names (either forward or backward).
<fabio_> what is slashes
<Burgundavia> fabio_: this is not a support channel
<Burgundavia> blizzow: nor is it a channel to help you compile stuff
<fabio_> im banned in ubuntu
<fabio_> channel
<fabio_> :(
<blizzow> Burgundavia: This is the channel where people who do dev work on ubuntu idle no?
<Burgundavia> blizzow: yes, but that is a support question. if they take them in #ubuntu-kernel I would try there
<soren> Cedega questions in #ubuntu-kernel? What?
<blizzow> I'll try there then, thanks.
<soren> Er. no.
<soren> that's all wrong.
<soren> That's not the right place for it at all?
<Burgundavia> soren: fabio was asking about cedega, blizzow was aksing aboutg compilig a kernel module
<Burgundavia> soren: again, you need to have less IRC channels open :)
<soren> Burgundavia: Gah..
<Chipzz> soren: fabio_ was the one asking about cedega, not blizzow
<soren> Yes, I got it now. Thanks.
 * soren crawls back under his rock
<Chipzz> whoops
<Chipzz> soren: didn't see Burgundavia already said that; apologies
<Burgundavia> Chipzz: I just second prize in the "not paying attention before I type" award
<Burgundavia> I give you, arther
<Chipzz> Burgundavia: yeah, not totally awake yet I suppose
<Chipzz> and it's 9:41 PM here :P
<fabio_> any one can help?
<Chipzz> fabio_: 21:35 < Burgundavia> fabio_: this is not a support channel
<tekteen> fabio_: go to #ubuntu (or #kubuntu)
<nixternal> Riddell: fancy joining #kubuntu-devel at all :) we miss you! :)
<Chipzz> fabio_: if you can't get an answer on #ubuntu (due to people not knowing or being banned), the forums are another alternative
<norsetto> fabio_: and https://answers.launchpad.net/ubuntu too
<nixternal> fabio_: join #cedega for your support need please
<TheMuso> c
<TheMuso> argh
#ubuntu-devel 2007-12-16
<slangasek> hmm, cute, I have no ssh agent running now with hardy
<slangasek> oh, ffs, why is gnome-keyring-daemon pretending to be ssh-agent?
<Fujitsu> slangasek: Because it's a shiny new feature that appeared a few days back.
<slangasek> it's not working very well
<Fujitsu> What's it not doing?
<slangasek> it's not accepting attempts to add ssh keys with ssh-add
<Fujitsu> You might have to use g-k-m or so, but that sounds wrong.
<slangasek> yes, that would be a regression
<Robot101> does the installer grok dmraid these days?
<Robot101> I just had to help a friend reassemble his hpt370 raid array with dmraid/hd/dd/beav and a copy of hpt37x.h
<Robot101> because ubiquity decided installing grub on one of the constituent drives would be a good plan
<Robot101> (even though he was installing onto one of the system's other disks)
<Robot101> there are a few related bugs in launchpad already, but this seems like a rather nasty failure case - even if we don't support installing to dmraid devices, surely destroying them is something worth avoiding?
<lamont> infinity: a clue:
<lamont> Dec 15 02:21:11 j6700 kernel: [1398423.164000] dash.postrm(17754): unaligned access to 0x0002be5d at ip=0x00015127
<lamont> Dec 15 02:21:11 j6700 kernel: [1398423.164000] dash.postrm(17754): unaligned access to 0x0002be61 at ip=0x00015127
<lamont> that's on an hppa box.
<lamont> so yeah.
<slangasek> lamont: that should be fixed by now in ubuntu2?
<slangasek> lamont: so just upgrading the chroot should do the trick for dash
<warp10> Hi all
<so1> hi
<so1> just wanted to ask if soprano will be updated again, because the version in ubuntu is to old to compile kde4 with it ...
<lamont> slangasek: coolness
 * lamont will freshen the local mirror
<so1> atm we have 1.99~rc2 in there, but 1.99 is needed
<so1> someone?
<Adri2000> so1: is there a bug filed about it? is it tagged appropriately? (tag 'upgrade')
<so1> ah uh ...
<so1> don't know
<Adri2000> so1: you should do that and/or ask nixternal if he intends to do this update, as he uploaded 1.99~rc2
<so1> ah ok
<nixternal> so1: soprano's latest is 1.99~rc2..check out their sourceforge downloads
<nixternal> I just grabbed it yesterday or the day before so I can rebuild kde4 on my new desktop, and it works just fine
<so1> ah ok ...
<chantra> hey there, I have uploaded 2 debdiff to bug #145458 , what should I do to have it reviewed?
<ubotu> Launchpad bug 145458 in evolution "evolution crashed with SIGSEGV in camel_object_cast()" [Unknown,Confirmed] https://launchpad.net/bugs/145458
<chantra> it is just a merge of patches found at http://bugzilla.gnome.org/show_bug.cgi?id=474118
<ubotu> Gnome bug 474118 in Mailer "Evolution crashed : clicked on 'dowload message for offline' option" [Critical,New]
<somerville32> !dev | chantra
<ubotu> chantra: Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<chantra> cheers somerville32
<somerville32> :)
<chantra> well, I guest I have to follow https://wiki.ubuntu.com/StableReleaseUpdates section "How"
<LaserJock> chantra: you're wanting the fix in stable release?
<chantra> LaserJock: not personnaly, the patch was submitted upstream, I just merged it
<chantra> if the debdiffs could be reviewed, I will make evolution's 'dowload message for offline' option work again
<LaserJock> chantra: right, I'm just wondering if you are wanting it fixed in Hardy or Hardy+stable releases like Gutsy
<chantra> gutsy, it is happening in gutsy, I haven't tested it on hardy
<chantra> simple to repro though. Open evolution, go to file->download for offline
<chantra> and evolution dies
<LaserJock> that's not very nice is it
<LaserJock> :-)
<LaserJock> chantra: hmm, worked fine here
<chantra> LaserJock: hardy ?
<LaserJock> gutsy
<chantra> :s
<chantra> http://bugzilla.gnome.org/show_bug.cgi?id=474118 + Bug #145458
<ubotu> Launchpad bug 145458 in evolution "evolution crashed with SIGSEGV in camel_object_cast()" [Unknown,Confirmed] https://launchpad.net/bugs/145458
<chantra> well, gotta go
<chantra> by guys
 * calc kicks ooo, need to do 18 MIR
<persia> calc: Just out of curiostity, are oooqs and related items still useful for Ubuntu?  The were dropped from Debian in the last cycle.
<calc> oooqs2-kde?
<calc> or something else?
<persia> calc: There's also a gnome one.
<persia> Err.  Nevermind.  It's gone now (or I misread rmadison output earlier)
<calc> persia: no idea about if its useful or not
<calc> i've never used the kde one and didn't see the gnome one in the past
<persia> calc: It was a preloader for OOo.  If you've no idea, I'd say it is good to be gone :)
<Riddell> can't say I've seen anyone using it
<calc> preloading ooo sounds like a good way to waste ram
#ubuntu-devel 2008-12-08
<RAOF> TheMuso: I see that I forgot Ubuntu constraints in my lib32asound2-plugins work.  ia32-libs is in main, so alsa-plugins can't build against it, so lib32asound2-plugins doesn't get a pulseaudio plugin.  Which was my original goal!  Urgh.
<allquixotic> RAOF: use getlibs
<RAOF> allquixotic: That's not /exactly/ what I was after :)
<allquixotic> ah, you want to push some kind of update to the real packages so that the pulse plugin is provided in the actual distribution on x86_64?
<allquixotic> for x86?
<RAOF> Yes.
<allquixotic> that's a great idea, that problem has plagued me before, along with my friends
<allquixotic> especially with wine...
<allquixotic> I solved it with getlibs but it'd be great to have that in Jaunty
<RAOF> This works in Debian, because ia32-libs is in main, and they don't have a main/universe separation.
<jdong> why don't we have a magical multilibs system like fedora/yum yet?
<allquixotic> it'd be great to have it in Intrepid too but...
<allquixotic> chances are slim for new feature
<RAOF> allquixotic: I believe ia32-libs in intrepid contains the pulseaudio asound plugin, actually.
<allquixotic> does it?
<jdong> pulse asound works on my skype on amd64.
<RAOF> jdong: Because dpkg doesn't allow you to install the same package twice :)
<jdong> I haven't added any more 32-bit libs.
<jdong> RAOF: and why don't we fix that? :)
<jdong> </easiersaidthandone>
<RAOF> That'd be cool.  The Debian multiarch proposal /looked/ pretty nice :)
<jdong> yeah and it seems like Fedora's hacked up something fairly fucntional with yum
 * allquixotic passes the buck to Debian to fix their dpkg utility. Although if we have sort of affinity for the Debuntu movement, then we are just as likely to do that as Debian
<jdong> most of their libs are installable in .i386 flavors
<directhex> RAOF, i'm sure i remember speaking to someone about multiarch years ago
<directhex> RAOF, it might've been Mithrandir
<RAOF> Yeah.  It's been simmering for quite some time.
<directhex> jdong, there's one little problem with the .i386 thing
<RAOF> It might have boiled dry at this point, though.
<directhex> jdong, one which makes sysadmins shout & scream
<allquixotic> yep, my laptop runs Fedora 10 because of # yum install alsa-plugins-pulseaudio.i386
<allquixotic> (among other things, too)
<crimsun> dpkg -L ia32-libs|grep pulse
<crimsun> err, sorry
<RAOF> crimsun: Yeah, they're there.
<TheMuso> RAOF: Did my upload fix the issue BTW?
<RAOF> TheMuso: Well, it'll now prevent people from installing lib32asound2-plugins, which is fine.
<RAOF> Because all those plugins (and more) are in ia32-libs anyway.
<TheMuso> RAOF: Yeah.
<RAOF> Oh, while you're here... :)
<RAOF> You seem to be our dmraid maintainer.  Any comments on what I think is the obviously-correct patch on bug #306114 ?
<ubottu> Launchpad bug 306114 in dmraid "Typo in hooks/dmraid" [Undecided,New] https://launchpad.net/bugs/306114
 * TheMuso looks.
<TheMuso> RAOF: Don't tell me you use that pile o crap?
<RAOF> TheMuso: No, but it seems to be installed.  That typo causes error output everytime I update the initramfs, so... :)
<RAOF> I'm not sure _why_ it's installed, but this is a fairly fresh Jaunty install and I haven't deliberately installed it.
<TheMuso> RAOF: Anyway, thats obviously something I missed that is different in Debian, thanks.
<TheMuso> RAOF: Ok, I'll upload that now, thanks.
<RAOF> No problem.
<tjaalton> RAOF: sounds nice
<shaya> ifconfig is returning crazy info on intrepid for me
<shaya> RX packets:72372 errors:0 dropped:1791015270 overruns:0 frame:0
<shaya> namely the dropped
<shaya> it keeps on cycling throgh its entire number space
<RAOF> tjaalton: I was actually wondering whether we should try to use it by default for some hardware :)
<tjaalton> RAOF: bold, I like it :)
<RAOF> tjaalton: Works pretty well for me :)
<RAOF> Therefore everyone should use it!
<tjaalton> dogfood for the masses!
<Treenaks> hmmm.. dogfood
<tjaalton> you found the diner yet?-)
 * NCommander has the only laptop at UDS that requires a jumpstart to connect to the net
<StevenK> NCommander: How does one jumpstart it?
<NCommander> StevenK, ask wgrant
<StevenK> Geez NCommander is an idiot
<wgrant> (I'm next to StevenK and one person from NCommander)
<NCommander> Riddell, your style of taste reeks horrible
<calc> ah i found the channel :)
<StevenK> wgrant has a calc buffer
 * NCommander wonders when sanity will enter ... or leave
<StevenK> it ever existed?
 * wgrant calls the Hobbsee to part NCommander.
<calc> Hobbsee: KDE is... EVIL! ;-)
<wgrant> That's just cruel. She has no laptop with her.
<NCommander> wgrant, she'll steal StevenK's laptop and make some witty remark and use the stick
<wgrant> Hmm, Luke has a convenient stick here.
<StevenK> NCommander: The stick is both metric and imperial, it has been checked over. Fear the stick
<NCommander> Do you have an International Stick Smashing Permit?
<NCommander> ^ StevenK
<calc> i can makes unsubstantiated claims of KDE's evilness due to maintaining it for several years... :-P
<wgrant> calc: Yes, but you're crazy.
<calc> i'm getting close to maintaining OOo as long now
 * NCommander is wondering how long until the fight breaks out
<calc> and i long ago learned OOo is evil ;-)
<NCommander> Just compiling it requires signing over your soul
<calc> yea
<StevenK> To Sun
<NCommander> and Sun will use it to make Java
<StevenK> NCommander: After mincing it
<NCommander> and using it to create CDDL-ed licensed code
<wgrant> Oooh, nasty.
<Riddell> NCommander: what's wrong with my style?
<NCommander> Riddell, nothing, it was simply an experiment in the concept that what you say in real life, and what you say on IRC can be completely different things
<Riddell> NCommander: are you downstairs?  did I miss you?
<NCommander> Riddell, try looking up from the keyboard
<wgrant> He's over here.
<StevenK> Riddell: He is, and you did.
<calc> NCommander: so you are in his room?
<Riddell> ah well, I'm asleep now, introduce yourself to me tomorrow
<NCommander> calc, unless your also in the same room ...
<calc> and someone Riddell is typing in his sleep
<NCommander> calc, he's simply using the Transreality Transmission Control Protocol
<calc> i need to be a track lead so i can get a spiffy shirt from bdmurray
<wgrant> calc: You can compete with NCommander for the insanity track.
<NCommander> wgrant, I thought you were the crowd favorite for that
<calc> wgrant: no one can beat me for insanity... i have maintained ALSA, KDE, and now OOo :-)
<wgrant> I don't do anything particularly insane!
<wgrant> calc: Right, but NCommander thinks m68k is worthwhile.
<StevenK> Doorstop!
<NCommander> calc, I've fixed mono bugs, I've done Ada transitions via hardy-sru
 * StevenK hides from infinity
<NCommander> I help with crackports ...
<calc> wgrant: its great for a space heater
<calc> my m68k isn't nearly as crack as NCommander's
<NCommander> calc, its not mine
<calc> just a poor 840av w/128mb
<calc> StevenK: well the US wasn't a prison...
<calc> now that we got a legimately elected president maybe we won't be a prison again :)
<NCommander> calc, you still have hope ...
<calc> StevenK: so are you the oldest Aussie? you've been on freenode for 8 years
<calc> i've been on freenode almost as long as the compiz guy has been alive ;-)
<wgrant> Hah.
 * wgrant too is just 17
<calc> Registered : Nov 04 16:56:38 1998 (10  years, 5 weeks, 1 day, 14:29:12 ago)
<NCommander> calc, that's not a good thing
<NCommander> The older your freenode account, the less of a life you have. It forms a rather interesting graph
<calc> NCommander: maybe i've just been using irc since i was a baby? :)
<NCommander> calc, I had wireless in the womb
<calc> Registered : Jan 29 01:49:02 1994 (14  years, 45 weeks, 2 days, 05:39:15 ago) <- thinks that is the oldest account
<wgrant> Oh dear.
<wgrant> No wonder you maintain OOo.
<NCommander> calc, is that lilo's account?
<calc> NCommander: yea
 * NCommander remembers when he died
<calc> yea i live in the same city he did and never managed to meet him
<calc> and riding a bike in Houston is crazy
 * calc knows other people who got hit by cars as well, but they luckily survived
<calc> there are generally no bike lanes, etc
<didrocks> morning o/
<didrocks> pitti: can you take a look at this hardy SRU (bug #212098) when you will have time to do so, please?
<ubottu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed] https://launchpad.net/bugs/212098
<LimCore> hi
<LimCore> ubuntu failed on me epically - silently destroyed lots of my files
<LimCore> this is issue on many levels, and I wanted to develop solution to one of them:  there is no way to gracefully turn of computer fastly when the power to monitor is gone.  Fix: make power button always shut down the box (instead asking damn questions and confirmations)
<LimCore> how to have is so that power button always just executs given script?
<hunger> When will OOo 3 become available in jaunty?
<pochu> hunger: possibly when bug 305790 is fixed.
<directhex> hunger, in jaunty?
<ubottu> Launchpad bug 305790 in backport-util-concurrent "MIR - move to main for openoffice.org 3 build-depends" [Undecided,Fix released] https://launchpad.net/bugs/305790
<hunger> pochu: Thanks. Just saw that it was submitted to LP for building and failed a while back.
<hunger> aka. yesterday:-)
<fbond> Hi, so most init scripts seem to have "INIT INFO" blocks at the top, but update-rc.d makes no use of them when deciding what the default runlevels for an init script should be.  Is there any plan to make use of this data, or is it only present for LSB compatibility?
<Koon> fbond: both
<fbond> Koon: Any idea where I can get info on what is happening with update-rc.d?
<Koon> fbond: you mean, info on what update-rc.d does ?
<Koon> fbond: man update-rc.d, or look directly at update-rc.d code
<fbond> Koon: No, not on what update-rc.d does, on changes to update-rc.d to make use of LSB init script comments.  Bugs or specs.
<Koon> fbond: the long-term idea is to fully make use of upstart. See http://upstart.ubuntu.com/
<fbond> Koon: And in that case, the LSB comments would still be parsed (but by some upstart tool)?
<Koon> fbond: i'm not sure.
<ScottK-laptop> Koon: Are you @ UDS?
<Koon> ScottK: no.
<ScottK-laptop> OK.  Looking for someone who's there that can maybe find out how we listen in ...
<Koon> yes, I also intend to listen to the morning conferences
<Koon> haven't found listening details so far
<lukehasnoname> Anyone know where audio streams will be for UDS, if there are to be any at all?
<ScottK-laptop> There usually are.  Lots of us are wondering right along with you.
<NCommander> lukehasnoname, I know we had to sign releases to be filmed
<NCommander> I'll ask the question now
<NCommander> I just asked Scott and he had no idea
<lukehasnoname> :(
<slangasek> http://icecast.ubuntu.com/ lists stuff, but none of them say "plenary" which is what's happening currently
<iulian> Yay!
<slangasek> ArneGoetje: I think I'm in another session at 11am, but I'm noticing with interest your session on new interfaces for font management; is there any more (tentative) design detail available yet, or should I wait until after the session to peek at it again?
<ArneGoetje> slangasek: It's not *my* session, but it touches my topic, so, I'm of course highly interested in that session.
<pitti> directhex: will do, but later (I'm at UDS)
<slangasek> ArneGoetje: ah, ok :)
 * StevenK bashes ogra. 1) You're not the UDS channel
<ogra> oh
<StevenK> ogra: 2) It's "the", not "teh" :-P
<ogra> right, i didnt plan to use my lappie
<ogra> :P
<Laney> udsserver dents too much
<Laney> >:(
<jpds> Laney: summit.u.c?
<Laney> jpds: http://identi.ca/udsserver
<jpds> Ah, right.
#ubuntu-devel 2008-12-09
<NCommander> StevenK, https://edge.launchpad.net/~sonicmctails/+archive
<tjaalton> umm, could an archive-admin promote x11proto-dri2 to main, new mesa/xorg-server will depend on it
<tjaalton> it's just protocol headers, no security issues etc :)
<tjaalton> pitti, slangasek, ..: ^^ :)
<St_Peter> Is anyone from uds listening here?
<cody-somerville> yes
<St_Peter> okey please ask them that are talking about boot up perfomance to see how to fit in the accessibility things as well in the chain.
<pitti> tjaalton: sorry, UDS madness; looking
<pitti> tjaalton: argh, source is in main; can you please file an MIR bug? I'll do it later then
<tjaalton> pitti: it is? to me it looks like it's in universe, both source and binary
<tjaalton> pitti: but I can file a bug too
<pitti> tjaalton: yes, only a quarter of a brain; I meant "universe"
<tjaalton> pitti: yes, promotable packages usually tend to be, right? :)
<ScottK-laptop> tjaalton: If source is in Universe, then it needs a MIR.
<pitti> tjaalton: I thought it was a binary in universe for a src in main
<pitti> tjaalton: if it's a trivial package, just file a bug
<tjaalton> ScottK-laptop: wouldn't be the first time a x11proto is promoted without paperwork, but I've filed a bug already
<tjaalton> pitti: right, it's bug 306383
<ubottu> Launchpad bug 306383 in x11proto-dri2 "please promote x11proto-dri2 to main" [Undecided,New] https://launchpad.net/bugs/306383
<Riddell> tseliot: does your X setup stuff have a name?
<tseliot> Riddell: not yet
<Riddell> tseliot: "new display setup tool" it is then
<tseliot> Riddell: yes, that's appropriate
<emgent> calc: really big and important question: why in Ooocal there is starwars game? :-)
<ozgurgerilla> Hi everyone I want to contribute to Ubuntu can someone tell me how to make a start
<LaserJock> ozgurgerilla: do you have a particular area you would like to contribute to?
<ozgurgerilla> LaserJock: I want to start as a tester or join the bug squad
<jdong> ozgurgerilla: Thanks for having an interest in contributing to Ubuntu; There's a lot of ways one can help the project and community; most of them are listed at http://www.ubuntu.com/community/participate
<jdong> if you have any specific questions we're all here to answer them :)
<jdong> ozgurgerilla: have you read https://wiki.ubuntu.com/BugSquad and/or joined #ubuntu-bugs?
<ozgurgerilla> I was just wondering what language do I need to know to write and test code in?
<ozgurgerilla> I'm just reading the website you've provided, many thanks.
<jdong> Ubuntu contains software written in a wide variety of languages
<jdong> debs are also built with the help of a packaging "language" if you will, that is described in the MOTU documentation too
<jdong> you can contribute with little to no programming experience and pick up bits of knowledge as you go along
<jdong> Furthermore with the volume of bugs that our userbase reports, we need a *LOT* of help just sifting through them, figuring out which ones are valid, which ones are duplicates, and so on
<jdong> and that stuff is very important work for us and doesn't really need any computer science or programming background
<ozgurgerilla> which project do you think I should join first as a 3rd year programmer with some knowledge in C, C++, Java and functional languages?
<jdong> what do you like to do? Do you like finding bugs, writing documentation, providing support to the community, creating packages for your favorite programs, etc?
<jdong> I've been told I'm magical and all, but I can't tell what your interests are :)
<LaserJock> pfft
<ozgurgerilla> :) I like creating packages and finding bugs but I am hesitating to start doing that as it might be difficult. Is there programming projects that are for intermediate or beginers level? if yes, where can I find information to join such developing groups?
<jdong> LaserJock obviously disagrees with my ego
<ozgurgerilla> LaserJock is obviously prejudging ;)
<jdong> ozgurgerilla: I don't think either of the tasks you mentioned are difficult or technically involved.
<jdong> the MOTU section of the wiki has good walkthroughs on making packages
<jdong> and #ubuntu-bugs can probably point you towards what kind of work bug-triaging typically entails
<jdong> I suggest trying both and seeing which one you like
<ozgurgerilla> jdong: is mirc the main way of communication?
<jdong> IRC tends to be the primary communications medium for developers.
<jdong> the mailing lists are also popular for the developers if you need more to engage in in-length discussions
<LaserJock> jdong: no no, I was just scoffing at the idea that you can't read minds ;-p
<jdong> I can barely read this SELinux manual set in front of me :)
<LaserJock> what has MIT done to you?!
<jdong> haha
<ozgurgerilla> :) thanks for the help jdong
<ozgurgerilla> good night.
<jdong> nor do I know why I am at "Zero Insertion Force" on wikipedia from the Mandatory Access Control page :)
<jdong> I don't know how people who actually have attention deficit issues use wikis...
<LaserJock> amen to that
<LaserJock> the other day I was looking up Density Functional Theory for a dissertation chapter
<ajmitch> jdong: getting lost in a maze of wiki links?
<jdong> yes
<LaserJock> and ended up reading an article on the rivalry between the nazi SS and SA
<ajmitch> mmm, procrastination
<jdong> I've even forgotten exactly why I opened wikipedia to begin with
<ajmitch> LaserJock: completely the same topic!
<LaserJock> there was a connection
<ajmitch> I'm sure there was, somewhere :)
<jdong> 6 degrees to Hitler, is it?
<LaserJock> something about somebody not getting a Nobel prize because one of the guys the worked with later joined the SA
<LaserJock> *they
<NCommander> nixternal, ping?
<amikrop> When will Python 2.6.x and 3.0.y be packaged and get into the repositories?
<ScottK-laptop> amikrop: Python 3.0 is already there
<amikrop> ScottK-laptop: You are right. What about 2.6?
<ScottK-laptop> I'd guess the next couple of weeks.
<ScottK-laptop> It's a matter for doko and when he has time AFAIK.
<amikrop> ScottK-laptop: He is the packager of Python, for Ubuntu?
<amikrop> ScottK: Also, will Python 2.6 be added to the repositories in that version of Ubuntu? I thought that only bug and security fixes are applied in daily updates.
<ScottK-laptop> amikrop: Yes.
<ScottK-laptop> For Intrepid, you won't see 2.6.  That'll be in Jaunty.
<ScottK-laptop> We will update the 3.0 RC in Intrepid to the final.
<amikrop> ScottK-laptop: I see. Thank you.
<calc> emgent: because they would rather write games than fix bugs at sun?
<hyperair> crimsun: ping. i'm curious to know why you removed all my attachments from bug 202089
<ubottu> Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,In progress] https://launchpad.net/bugs/202089
<philsf> I'm getting this from update-manager since last week: Failed to fetch http://br.archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/binary-i386/Packages.bz2  Hash Sum mismatch. Shoud this be looked into?
<philsf> In the first time, I thought it was a syncing issue, but it's been days since the first time I saw it
<Company> philsf: bad time to ask, the whole crew's in california for UDS
<Company> and it's 3.30AM there
<NCommander> hey StevenK
<NCommander> StevenK, morning
 * StevenK grumbles. It's morning?
<ScottK> It's always morning somewhere.  That's the problem with it.
<Keybuk> I've come up with a use case for libtool linking all dependency libraries
<Keybuk> it makes tracing reverse dependencies *much* easier since I don't have to walk a tree <g>
<alex-weej> i've noticed that bringing my notebook back from suspend sometimes the sound doesn't work -- if i kill pulseaudio and restart it comes back
<alex-weej> anyone any ideas?
* Hobbsee changed the topic of #ubuntu-devel to: UDS: occuring, Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<LaserJock> Hobbsee: you just like playing ops don't you :p
<Hobbsee> LaserJock: :P.  Nah.  Just being thrown big scary red warnings about the scripts being wrong.
<Mithrandir> hi walters
<Hobbsee> Mithrandir!
<Mithrandir> also, hi LJ, Hobbsee
<walters> hello
 * StevenK waves to Mithrandir
<Mithrandir> how's the googleplex?
<Hobbsee> interesting.
<LaserJock> Mithrandir: hello!
<StevenK> Big and scar ^W^W^WPerfectly fine.
<Mithrandir> they're still fattening up the devs, I presume?
<StevenK> The lunch yesterday was large
<luisbg`> what was the jaunty UDS irc channel?
<Hobbsee> #ubuntu-devel-summit
<luisbg`> Hobbsee, thanks!
<didrocks> pitti: thanks for the upload :) sorry for the core dev change. I might be tired when doing that as I was sure to do the contrary: motu -> core dev in control file :/
<mohbana__> how do i control how much history is saved in the command line?
<jdong> that's not an #ubuntu-devel topic.
<mohbana__> very helpful.  thanks
<jdong> y... you're welcome?
<alex-weej> crimsun: your PA packages just segfault
<alex-weej> E: shm.c: Invalid shared memory segment size
<alex-weej> times lots
<alex-weej> then SIGSEGV
<crimsun> erm, segfault?!  they're usable here :/   Can you roll back a libc6* version?
<alex-weej> i don't know, can i?
<alex-weej> if i run under GDB i get this first:
<alex-weej> [New process 12759]
<alex-weej> Executing new program: /proc/12759/exe
<alex-weej> /proc/12759/exe: Permission denied.
<alex-weej> no idea what that menas
<alex-weej> *means
<crimsun> if you roll back to jaunty's pa packages, try just placing the extracted /usr/lib/pm-utils/sleep.d/01PulseAudio
<alex-weej> i'm on intrepid...
<crimsun> hmm, I thought you were running jaunty.  Anyhow, then you need the 01PulseAudio file from 202089
<alex-weej> if all it's going to do is kill pulseaudio on sleep and then start it again on resume
<alex-weej> then there's no point, that obviously works
<crimsun> doesn't kill; suspends
<alex-weej> ok i will try it later
<alex-weej> my stomach is knacking with hunger so i gotta go!
<alex-weej> bbl
<crimsun> it's known upstream, this just works around it
<alex-weej> ok cool
<RAOF> Ok.  So, this time we've deliberately sync'd nouveau from Debian :).  I'll do the cleanup requried to make nouveau-kernel-source uploadable, then.
<phix> hey, excuse my bluntness but what idiot put pulse alsa pluging in ubuntu 8.10?
<RAOF> The person who wanted audio to work.  I presume this breaks something for you?
<RAOF> If so, a bug report is a nice permanent way of recording this in a fasion that makes it possible to diagnose and fix :).  Initial discussion here is possibly useful, but it'll want to end up in launchpad.
<Keybuk> tseliot: around?
<tseliot> Keybuk: yep
<phix> RAOF: yes it does, it doesn't pick up that I want to use hdmi as output (it is the only output device in there)
<phix> RAOF: ok
<Keybuk> tseliot: screen-resolution-backend
<Keybuk> that has a D-Bus service
<Keybuk> do you really not want anyone to communicate with it?
<Riddell> MacSlow: this is the new notifier in KDE 4.2 http://www.kubuntu.org/~jriddell/tmp/knotify.png
<tseliot> Keybuk: yes, it uses policykit
<tseliot> Keybuk: why should anything else use it?
<RAOF> phix: That sounds like it could be a pulseaudio bug; I presume that your alsa is actually exposing a hdmi output?  If so, pulse shouldn't be ignoring it.
<Keybuk> tseliot: it uses policykit?
<Keybuk> does it not have any methods of its own?
<Keybuk> it reserves the com.ubuntu.ScreenResolution.Mechanism bus name?
<tseliot> Keybuk: yes, since it has to access the xorg.conf
<phix> RAOF: yes, I am in #alsa and I can get the sound test working
<tseliot> Keybuk: yes
<Keybuk> which looks like it exports setVirtual() method?
<Keybuk> (which uses PK for authorization?)
<tjaalton> who could look at an armel/lpia build failure (mesa) ?
<tseliot> Keybuk: right
<Keybuk> but you don't have anything in your dbus conf that actually *allows* anyone to call that method
<Keybuk> you need something like:
<Keybuk>   <policy context="default">
<phix> RAOF: but I need to specify device as hdmi or hw:0,3.  I tried setting pcm!default=hdmi or somethign to that effect but alsa doesn't take any notice of that since pulse is being used or something like that
<Keybuk>     <allow send_destination="com.ubuntu.ScreenResolution.Mechanism"/>
<Keybuk>   </policy>
<StevenK> phix: But how does that also mean "but what idiot put pulse alsa pluging in ubuntu 8.10?"
<phix> StevenK: pulse in general is a beta sound daemon
<phix> StevenK: and doesn't set my default output device correctly
<RAOF> Right.  But that's a bug, rather than a bad design decision.
<phix> StevenK: and wont allow me to do it manually in alsa
<tseliot> Keybuk: I don't think I really want other programs to use that method. I'll do something similar for my other tools soon though
<Keybuk> what program uses that method then?
<tseliot> Keybuk: for my new Display Configuration tool and for other tools which will share part of its code
<tseliot> Keybuk: currently screen-resolution-extra is used in the Gnome Screen resolution applet
<RAOF> phix: Anyway, you might want to install paman - see whether pulse is seeing your hdmi output at all, and see what pulse thinks your outputs are.
<Keybuk> tseliot: I think you're missing my point
<Keybuk> *nothing* can use that dbus service
<tseliot> Keybuk: when you need to set the virtual resolution in the xorg.conf
<Keybuk> wayyy before you even get to PK
<tseliot> Keybuk: well my app does
<Keybuk> right
<tseliot> Keybuk: slangasek used it today in front of you
<Keybuk> if your app uses it, you need to allow it to communicate over dbus
<Keybuk> with the snippet I gave above
<pochu> kees: thanks for the upload :)
<tseliot> Keybuk: are you saying that my app is not using dbus?
<MacSlow> Riddell, thanks for the pointer!
<Keybuk> tseliot: no, I'm saying that your app only works because of a security flaw in dbus
<Keybuk> and as soon as we fix that, your app will break :)
<tseliot> Keybuk: ah, that's really good to know
<kees> pochu: thanks for all the packaging work!
<phix> RAOF: ok
<tseliot> Keybuk: I'll fix it in Intrepid and Jaunty then
<tseliot> Keybuk: thanks for reporting
<phix> RAOF: what is wrong with esound?
<Keybuk> tseliot: bug
<RAOF> phix: It was (a) unmaintained (b) had terrible latency problems (and would hence cause a/v desync) which caused (c) no one used it.
<Keybuk> tseliot: bug #307705, debdiff attached
<ubottu> Error: Launchpad bug 307705 could not be found
<Keybuk> bug #306705, sorry
<ubottu> Launchpad bug 306705 in screen-resolution-extra "No permission to call method (dbus 1.2.8)" [Undecided,New] https://launchpad.net/bugs/306705
<phix> RAOF: ok
<tseliot> Keybuk: did you test it?
<Keybuk> tseliot: no, not yet
<tseliot> Keybuk: I'll have to do that anyway. Thanks a lot for the patch
#ubuntu-devel 2008-12-10
<RAOF> phix: You'll want to file a bug, attaching the output of alsa-info.sh (see https://wiki.ubuntu.com/DebuggingSoundProblems) and a pulseaudio log; you can get that by killing the current daemon with "pulseaudio -k" and starting a new one with "pulseaudio -vvv 2>&1 > pulseaudio-debug-log"
<Keybuk> ugh
<Keybuk> wpa supplicant is worse
<phix> ok
<pochu> kees: btw, in case you hadn't seen it: http://www.coresecurity.com/content/vinagre-format-string
<kees> pochu: ah, I hadn't.  thanks!
<kees> pochu: though, strangely, still no CVE
<RAOF> phix: As a work around you can probably edit /etc/pulse/default.pa and defining a static alsa sink using hw:0,3 - the comments should make it obvious how to do this.
<pochu> kees: I think upstream confused that with a cve :)
<pochu> kees: so no idea if there's one...
<phix> RAOF: yes I tried that with no success, I will try again :\
<phix> RAOF: VLC doesn't play anythin, I can't use totem as it crashes when I use ATI properitary drivers
<kees> pochu: s'okay
<phix> why am I finding all of the bugs for? :)
<Riddell> MacSlow: http://www.kubuntu.org/~jriddell/tmp/notifier.py
<Riddell> http://www.kubuntu.org/~jriddell/tmp/notifier.notifyrc
<Riddell> that does into /usr/share/apps/kde4/notifier/
<kees> pitti, slangasek: uhm, okay, where is libhttp-response-encoding-perl ?  I don't see a build and I don't see it in NEW...
<slangasek> um... context?
<slangasek> was this the sync you were waiting for a while ago?
<kees> slangasek: it's related, yes
<kees> slangasek: but it should have already been pulled in.
<slangasek> hmm
<kees> (it's a build-dep for the thing I was waiting on)
 * Hobbsee wonders if that's a ppa bug, coming back to bite us
<slangasek> kees: ok; looking
<Hobbsee> seeing as LP doesn't seem to know about a source.
<kees> slangasek: cool.  mostly I just don't know where it might be hiding.
<kees> Hobbsee: it seems to know it exists, but without any files.
<Hobbsee> kees: that's why I suspect it's the ppa bug
<kees> aaah
<Hobbsee> kees: ppas were creating those pages for any new source that was uploaded to a ppa, as a package in ubuntu
<Hobbsee> but never had sources attached to them, as the sources weren't actually in ubuntu.
<kees> Hobbsee: yucky.  this package _should_ exist in Ubuntu, but ... I don't know where.  It would have been NEW on Nov 28.
<kees> (assuming a debian-sync was run then)
<Hobbsee> while they fixed the bug, i don't think they ever removed the pages that shouldn't ahve been generated.
<Hobbsee> i presume slangasek will try to resync it
<slangasek> yes, currently trying
<slangasek> since I didn't do archive admin duties yesterday anyway :)
<pwnguin> feisty's dead right?
<nhandler_> Yes pwnguin
<pwnguin> sigh, users...
<nhandler_> It has reached its End of Life
<pwnguin> heh
<pwnguin> i was just thinking, if they sit on this for much longer
<pwnguin> there wont be a good upgrade plan
<tseliot> Riddell: we need to talk. Celeste knows why
<Riddell> tseliot: that sounds worrying :)
<Riddell> I'm in the desktop room
<slangasek> doko: is gcc-spu meant to be in main instead of universe? (newlib dep-wait on powerpc)
<slangasek> kees: ^^ newlib is the package going a little funny during the autosync
<slangasek> so I'm following through on that, maybe it fixes us
<ScottK> slangasek: If you've still got your archive-admin hat on, I'd appreciate it if you'd also sync mlt++ (Bug 306257)
<ubottu> Launchpad bug 306257 in mlt++ "Please sync mlt++ 0.3.2-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/306257
<StevenK> I think mlt is still in NEW
<doko> sladen: yes please
<slangasek> StevenK: mlt didn't just FTBFS on all archs?  That's where it was last I'd looked
<StevenK> It got given back on lpia
<slangasek> and it succeeded?
<tseliot> Riddell: so am I, I hadn't noticed. No, it's nothing to worry about
<slangasek> doko: fixed
<Riddell> oh aye, there you are
<slangasek> kees: bah, have to wait for a publishing run to be sure I know what's going on there
<StevenK> slangasek: I think it should be given-back everywhere, since it was Build-Depends things
<TheMuso> crimsun: Did you attach the pulseaudio jaunty debdiff to bug 202089?
<ScottK> mlt built on i386 and amd64
<ubottu> Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,In progress] https://launchpad.net/bugs/202089
<crimsun> TheMuso: no, I can do that now (it's also in my ppa)
<slangasek> StevenK, ScottK: ah, ok
<ScottK> StevenK: mlt is out of New and built at least on amd64 and ii386
<TheMuso> crimsun: No need, I'll fetch from your PPA.
<crimsun> TheMuso: ok.
<slangasek> thanks, I'll take mlt off my to-be-followed-up list :)
 * ScottK knew he'd done a test build somehow
<kees> slangasek: cool, I'm not in a rush, just deeply curious.  thanks for digging.  did you see doko's mis-tab?
<kees> slangasek: oh, you did, I can't read
<slangasek> :-)
<StevenK> I was ignoring mlt since it hadn't built everywhere
<doko> oops
<slangasek> ScottK: looking now, but there are some other requests ahead of that one in the queue so it'll be a few minutes to churn through them
<slangasek> ScottK: doh, out of time and not there yet, will pick it up after heading back to the hotel
<candrews> I'm trying to convince XBMC to use dynamic linking instead of including all the source in their own tree and compiling everything in. Can anyone point me to a policy of Ubuntu, Debian, or another distro that demonstrated why dynamic linking is important?
<jdong> candrews: does XBMC use some ffmpeg type stack?
<candrews> they do, but they also include python, faad, pulseaudio, mplayer, and a whole lot more :-)
<candrews> I totally understand ffmpeg being included, that situation is nuts.
<jdong> yeah I was going to point out that they probably have a reason to do this with ABI-unstable multimedia stack
<jdong> ffmpeg and faad I'd put on that list. mplayer possibly.
<RAOF> s/ABI/API/ :(
<jdong> but no excuse for Python or pulseaudio
<jdong> RAOF: yeah, it's both :D
<ScottK> candrews: http://people.redhat.com/drepper/no_static_linking.html
<candrews> Here's the conversation if anyone is interested: http://xbmc.org/forum/showthread.php?p=252592
<candrews> It's driving me nuts - if I was a distro (like Ubuntu) I would never accept such a package...
<ScottK> With PIE enabled would it even run?
<jdong> only on i386 IIRC
<candrews> sdl, mad, sqlite, hal, glew, boost, libjpeg, libpng are also statically included
<candrews> there's way more too - it's like it's own distro
<jdong> ok we'd absolutely not accept that.
<jdong> it is basically its own distro.
<jdong> but then again, I don't feel you should use distribution policies as a bullying tactic for changing the project...
<jdong> that's a decision for the project to make
<jdong> perhaps for their purpose they'd rather have a no-dependencies bundled distribution
<candrews> What do you think though? If you were them and all...
<jdong> well... if I were them I'd have two separate distributions.
<jdong> I understand their motivation for an all-in-one build
<jdong> but at the same time I understand why that's a horrible nightmare for distributions.
<jdong> But, if I were them, I would be annoyed as hell if every 2 days someone came asking for the libraries to be de-bundled.
<phix> RAOF: I finally got HDMI set as default auto device :D  but it should of done that by default as it was the only device there.
<phix> auto = audio
<jdong> in my opinion the correct thing to do here is for the packaging community to debundle the libraries themselves for the reasonable libraries to debundle
<RAOF> phix: Right.  Which is why you should file a bug to document (a) your set up (b) what was wrong, and (c) how you fixed it, so we can possibly make it Just Work. :)
<jdong> I'd probably leave mplayer and ffmpeg bundled because those have very version-specific bugs, quirks, and APIs and I'd rather not be introducing extra bugs by mutant hybrid compiles of their code :)
<phix> RAOF: I will try :) but I am no expert in that area
<RAOF> jdong: And then provide patches to the project, yes.
<jdong> RAOF: right I was getting to that. Honest :)
<phix> RAOF: What is your affilation with the ubuntu project if you don't mind me asking?
<RAOF> phix: I'm a MOTU.
<jdong> I was going to say that with time upstream will probably appreciate the work you're doing and you can happily merge your efforts as an integral part of upstream.
<jdong> It's always good to do something productive/constructive instead of standing there whining, in the open source world.
<phix> RAOF: I am not familiar with that acronym
<jdong> phix: it means he's a scapegoat for not-very-maintained packages having bugs.
<jdong> (joking)
<candrews> jdong - indeed! But, I'm not that familiar with C, especially not on the sheer scale and complexity of that project... and their build system is very large and frankly scares me.
<phix> candrews: heh, what is this?
<jdong> candrews: the developers probably feel the same way about debundling.
<jdong> candrews: hence why I suggested it's probably not productive to whine at upstream to debundle
<candrews> phix xbmc
<phix> I would like to contribute to the Ubuntu project, what can I do? :)
<phix> candrews: no idea what that is :)
<jdong> phix: you can start by doing my decision theory homework...
<candrews> www.xbmc.org
<phix> jdong: heh
 * candrews cringes, and is quite glad he's out of college.
<phix> ditto
<phix> RAOF: Nice, a fellow Aussie
<mnabil_> guys, i want to customize the live cd , i wanna change the kernel on it , any idea ?
<mnabil_> guys really i got sick from the ubuntu livecd customization how to's  all failed with me, always the live cd drops the initramfs shell
<MiladKhajavi> how can I create a repository with a pool directory?
<cody-somerville> MiladKhajavi, reprepro
<MiladKhajavi> cody-somerville: thank a lot
<LaserJock> any gnome-app-install gurus happen to be around?
<wgrant> doko: hppa should be on the main FTBFS list in about 15 minutes, I guess. LP is slow.
<AtomicSpark> What is this?!
<catmando> hey all
<catmando> i think i've found a rather large bug that's somehow slipped thorugh the cracks
<catmando> the 8.10 alternate cd never installs a bootloader
<Sockan> hello
<NCommander> bdmurray, ping
<lionel> Ah NCommander :)
<NCommander> morning lionel
<lionel> Would you mind to approve this backport https://bugs..launchpad.net/hardy-backports/+bug/303265
<ubottu> Launchpad bug 303265 in hardy-backports "please backport lightning-extension-locales from intrepid to hardy" [Undecided,Confirmed]
<lionel> it would unbreak hardy-backports for lightning users :)
<NCommander> sure, I'll ack it
<NCommander> As a side note
<NCommander> Don't used confirmed in backport trackers
<NCommander> That's a good wayt o make sure your bug isnt' seen :-)
<lionel> rah, sorry. Second time I've done it :(
<NCommander> Let me just test build this
<lionel> NCommander: that beeing said, you use "In progress" when you approved it and waiting for backport for archive admin
<NCommander> YEah
<NCommander> DOn't ask, it really doesn't make a whole lot of sense to me either
<lionel> https://help.ubuntu.com/community/UbuntuBackports -> this say to put as "Confirmed" when built and tested...
<NCommander> A backporters is supposed to do it
<NCommander> s/s//g
<NCommander> test building now
<lionel> hum... that's not what I have observed in backports for some years, I think we should clarify this
<lionel> (but that's not the topic today)
<NCommander> Anyway, once it test builds, I'll ack it
<Laney> I thought anyone could confirm, but only a backporter could approve it
<lionel> <NCommander> Anyway, once it test builds, I'll ack it
<lionel> I'm a bit surprised by the fact that you can not a MOTU trust but somebody ack the lightning backport without even checking rdepends...
<lionel> +trust
<maxb> <NCommander> Don't used confirmed in backport trackers <--- but https://help.ubuntu.com/community/UbuntuBackports  says you should!
<NCommander> I fail :-P
<jdong> interesting that lightning backport caused so much trouble.
<jdong> it would seem like from bug 220166 that it received a good deal of testing.
<ubottu> Launchpad bug 220166 in lightning-sunbird "New upstream version available (v0.8)" [Wishlist,Fix released] https://launchpad.net/bugs/220166
<jdong> I guess nobody hit all the rdepends.
<jdong> I am brainstorming on a prevu QA suite for backporting that tests installability, upgradability of a requested package and all its rdepends
<lionel> jdong: if nobody use locales, it's not catched
<lionel> jdong: my "pb" is that I opened the bug two weeks ago and we can not get this fixed
<lionel> (more than things get broken, it's the game with backport)
<jdong> NCommander: anything holding us back in your opinion on approving said backport?
<tclineks> as far as i can tell io.py that is installed by python-stats breaks lxml.etree.parse
<tclineks> makes it segfault
<ruthgard> Greetings what is the esiest way to create a deb file from a binary?
<jdong> from a binary?
<ruthgard> I have a tomcat webapp that I want to make deb file from, I want it to depend on apache tomcat and to put a file in the conf/Catalina/localhost folder for the tomcat configuration.
<ruthgard> the webapp is a .war file
<jdong> Well the same way you make a deb from a source package
<jdong> only you won't have a "build" target but only an install target
<ruthgard> can you recomend any guide for creating a deb?
<maxb> I think it's usually a mistake to look for "guides" that teach you to do a single operation without understanding it
<maxb> Especially because people very seldom write them!
<ruthgard> you are correct
<maxb> Unfortunately I'm not immediately aware of the right doc to recommend for starting to learn deb packaging
<maxb> It's something I've absorbed over time
<ruthgard> I found an article about how to create a deb for debian, is there any difference with debian and ubuntu debs?
<ruthgard> or are they the same?
<ruthgard> I read something about creating a file called debian
<maxb> very little, in general. In fact, very many Ubuntu packages are built from the Debian source, unmodified
<ruthgard> sorry I mean directory
<ruthgard> and in that file create controlfiles for how the deb should be assembled
<maxb> In this case, the "debian" directory refers to the packaging system, rather than the distribution - i.e. yes, it's "debian" for ubuntu packages too
<maxb> Oh, one key thing to know is that many of the details of the format of debian packages are specified in the "Debian Policy Manual" - despite the name, it contains a *lot* of material on packaging too
<tormod> ruthgard: you want this: http://www.debian-administration.org/articles/336
<pitti> Good morning
<pitti> kees: was the libhttp-response-encoding-pel issue resolved?
<NCommander> StevenK, https://bugs.edge.launchpad.net/intrepid-backports/+bug/303245
<ubottu> Launchpad bug 303245 in intrepid-backports "Please backport amule-adunanza" [Wishlist,In progress]
<kees> pitti: let me check, one moment
<kees> pitti: no: https://launchpad.net/ubuntu/+source/libhttp-response-encoding-perl
<kees> pitti: slangasek had some theories and was letting soyuz settle before poking at it some more.
<slangasek> kees: pitti: it's a bug in sync-sources, plain and simple; I need to have a look to see exactly where the bug is
<StevenK> NCommander: Found it
<NCommander> StevenK, where did it go?
<StevenK> NCommander: I can't read, and grep can
<ebroder> Is there documentation somewhere on the process for requesting a package get imported from Debian experimental?
<ebroder> Like, I've seen wiki pages on DIF, but nothing on the Debian import itself
<crimsun> ebroder: https://wiki.ubuntu.com/SyncRequestProcess
<ebroder> crimsun: Ah, thanks. I'll check that out
<crimsun> ebroder: (there's also a tool in the ubuntu-dev-tools binary package called requestsync)
<ebroder> Even better. I'll check that out, too
<StevenK> NCommander: NEWed
<NCommander> Thanks StevenK
<NCommander> I appreciate it
<ebroder> crimsun: Does requestsync assume that you want to sync from unstable?
<crimsun> ebroder: yes, but see -d
<ebroder> Hmm...that's not documented in my requestsync. New after Hardy?
<crimsun> ebroder: yes, in intrepid
<gicmo> mvo
<gicmo> where is he
<TheMuso> gicmo: He is currently in a session, and may or may not be online.
<TheMuso> Since I can't see him on IRC, I'd say not.
<ebroder> Any backporters around who could ACK LP #301302 and LP #305001 ?
<ubottu> Launchpad bug 301302 in hardy-backports "Please backport pyyaml (3.05-2) and libyaml (0.1.1-1) from Intrepid to Hardy" [Undecided,New] https://launchpad.net/bugs/301302
<ubottu> Launchpad bug 305001 in hardy-backports "Please backport sqlalchemy 0.4.8 from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/305001
<Meztli-Xictli> hi
<ScottK> ebroder: I'll have a look at the first one.
<ScottK> ebroder: Why not 3.06-1 from Jaunty?
<NCommander> hey ScottK
<ScottK> Heya NCommander.
<NCommander> ScottK, I just had a good talk with mvo on selective backports installation
<ScottK> And ...
<NCommander> ScottK, he'd be interested in extending APT to do what we want
<ScottK> Excellent.
<NCommander> (the base is there, libapt needs a write interface, and synaptic needs an interface)
<joaopinto> how are you planning to support that ?
<ScottK> NCommander: It'd probably be good to touch base with the bpo people too and see what they'd like.
<NCommander> Well, one person showed up at my backports meeting
<NCommander> (mvo showed, but had to run)
<joaopinto> NCommander, do you have those ideas somewhere I can read  ?
<NCommander> joaopinto, I posted it in a spec
<NCommander> https://wiki.ubuntu.com/Backports/SelectiveInstallation#preview
<ebroder> ScottK: No good reason. 3.06-1 should be fine
<joaopinto> NCommander, checking, tks
<jdong> NCommander: if you have mvo hostage there's something else I want to poke him about
<NCommander> jdong, I'm eating lunch w/ him
<jdong> NCommander: in the case when a backport causes a package to be uninstallable it'd be nice for APT / synaptic to fall back on the regular non-backported version if it is installable.
<andersk> Is there an appropriate place to assign bugs in the Ubuntu APT archive itself, such as bug 201179?
<ubottu> Launchpad bug 201179 in ubuntu "Contents.gz empty in dapper" [Undecided,Confirmed] https://launchpad.net/bugs/201179
<Hobbsee> andersk: a mirror, or archive.ubuntu.com?
<andersk> archive.ubuntu.com
<Hobbsee> that's not what the bug says?
<Hobbsee> us.archive.ubuntu.com is a mirror
<Hobbsee> sorry, i was probably unclear
<Hobbsee> andersk: ubuntu-mirror-admins, iirc.
<andersk> archive.ubuntu.com has the same bug.
<andersk> So this is not just a mirror problem.
<Hobbsee> oh, so it is
<Hobbsee> slangasek: where should https://launchpad.net/bugs/201179 get reassigned to, if it's wrong on a.u.c?
<ubottu> Launchpad bug 201179 in ubuntu "archive.ubuntu.com Contents.gz empty in dapper" [Undecided,Confirmed]
<StevenK> Soyuz
<andersk> Thanks.  I assigned it to Soyuz, can someone confirm?
<btm> Are there any plans to pull multipath-tools from upstream or patch multipath-tools for an intrepid SRU to fix the API issues with udev? (LP #306723)
<ubottu> Launchpad bug 306723 in udev "udev breaks compatibility with multipath" [Undecided,Won't fix] https://launchpad.net/bugs/306723
<joaopinto> NCommander, I am not sure I got a clear understanding of the "Pinning dependencies" section, the text "Depends line which explicately pulls in the new version", means it will only pull the version if it's the dependency as a version requirement provided by the backports repos ?
<NCommander> Right
<NCommander> That means if we have a security fix in a backported library, we'd have to update its rdepends to pull it in unless the deps were pinned
<joaopinto> so, unlike now, you must be sure that the package on backports have proper versions on the dependends, right ?
<slangasek> Hobbsee: I don't have a better place for it than where it currently is :/
<slangasek> Hobbsee: "ubuntu-archive is subscribed" is more meaningful than anything else, I fear
<joaopinto> ok, got it
<Hobbsee> slangasek: ah, so it's ubuntu-archive fixable?
<joaopinto> NCommander, the implementation should be generic, so you can use this selectivity feature with PPAs or 3rd party repositories
<ebroder> ScottK: Who is the comment on LP 301302 directed at? Me?
<ubottu> Launchpad bug 301302 in hardy-backports "Please backport pyyaml (3.05-2) and libyaml (0.1.1-1) from Intrepid to Hardy" [Undecided,New] https://launchpad.net/bugs/301302
<ebroder> Oh - did you want me to switch it to use pyyaml 3.06-1?
<ScottK-laptop> ebroder: Yes and yes.
<ebroder> Ok, cool - I'll check that now
<ScottK-laptop> ebroder: You don't actually have to change anything for a no change backport.  Just build it locally, test that it installs and runs, and then say so in the bug.
<lionel> Hi ScottK-laptop, could you have a look at #303265 please?
<ScottK-laptop> lionel: Ack'ed.  It's up to the archive admins now.
<slangasek> Hobbsee: should be, at least in coordination with soyuz
<lionel> ScottK-laptop: thanks a lot!
<Hobbsee> slangasek: oh good
<ebroder> ScottK: I've updated LP 301302 - it does b/i/r on Hardy
<ubottu> Launchpad bug 301302 in hardy-backports "Please backport pyyaml (3.06-1) and libyaml (0.1.1-1) from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/301302
 * ScottK-laptop looks
<ScottK-laptop> ebroder: Ack'ed now it's up to when an archive admin has time to process it.
<ebroder> ScottK: Thanks a lot
<Picklesworth> Oh my.... the synaptics driver is indented with tabs /and/ spaces, by the same person!
<ScottK-laptop> doko: Is there some summary of yesterday's Python discussion written up somewhere?  I was trying to listen in, but could hear almost none of it.
<doko> ScottK-laptop: just the blueprint
<ScottK-laptop> doko: Thanks.  That's more than I knew before.
<mnemo> im trying to build the gvfs backends package but I get this error --> http://rafb.net/p/RcDYTK61.html
<mnemo> what am I doing wrong?
<ebroder> mnemo: You don't have the build dependencies installed
<mnemo> ok thanks
<ebroder> You should build packages with something like dpkg-buildpackage or debuild - those will tell you if you're missing build deps
<mnemo> ebroder: what is the exact command for building with these tools?
<ebroder> With debuild, you can basically just run debuild. With dpkg-buildpackage, I think you want to do dpkg-buildpackage -rfakeroot
<mnemo> ebroder: ok thanks I will try those
<ebroder> Both of them will attempt to GPG-sign packages, so you may want to add -us -uc to the command line args to keep them from doing that
<ebroder> It'll error, but it's harmless
<ebroder> (That is, it'll error if you don't pass -us -uc)
<Hobbsee> apt-get build-deps packagename is also useful.
<Hobbsee> sorry, build-dep
<mnemo> Hobbsee: I know that one already, but thank you
<Hobbsee> y/w
<doko> tjaalton: please fix mesa, ftbfs on armel and lpia, causing build failures on other packages
<tjaalton> doko: yes, ideas abou the problem?
<tjaalton> +t
<tjaalton> what to those archs share that makes it fail?
<tjaalton> s/to/do/
<doko> tjaalton: create a lpia chroot and check ...
<tjaalton> doko: hmm ok
<TheMuso> c
<pitti> Keybuk: do you see a reason to not upgrade jaunty's udev to 130?
<pitti> Keybuk: it's needed for latest DK-Power
<Nafallo> Denmark!
<pitti> Keybuk: in fact, current Devkit itself needs it already
<mnemo> im building a package using "fakeroot debian/rules binary" and then I do "dpkg -i ..." etc.... but can I do the same and also get debug symbols built into the binary???
<mok0> mnemo: man dh_strip
<gicmo> aha! mnemo is here
<gicmo> right at the time I am about to leave for lunch
<mnemo> hey gicmo :)
<mnemo> did you see the patch Peter Christoffersen attached?
<lifeless> cr3: https://code.edge.launchpad.net/%7Echeckbox-dev/checkbox/trunk/+merges
<lifeless> cr3: its odd that there isn't a ubuntu branch for this, which any ubuntu dev/motu can write to
<andersk> I'm trying to get a new upstream version of OpenAFS into Jaunty so that it will work on the Jaunty kernel: LP bug #303122.  Have I done everything right to request sponsorship for this upload?
<ubottu> Launchpad bug 303122 in elisa "[win32] File "lost.305.hdtv-lol.avi" plays partially on XP" [Undecided,New] https://launchpad.net/bugs/303122
<andersk> Sorry, LP bug #303112
<ubottu> Launchpad bug 303112 in openafs "Please upgrade to 1.4.8 for Jaunty kernel 2.6.28 support" [Wishlist,Confirmed] https://launchpad.net/bugs/303112
<jdong> lol at 303122
<lionel> andersk: I had a look yesterday night. I wanted to give it more tests before uploading
<lionel> andersk: how did you test it? server/client part?
<andersk> After installing the openafs-client package, you run m-a a-i openafs to build and install the kernel module.  Then you should be able to /etc/init.d/openafs start and see a bunch of stuff in /afs.
<lionel> andersk: looks ok for the client, but for the server
<andersk> Hmm.  Testing the server is...complicated.
<lionel> I know
<lionel> but that would be cool to have some basic test for it
<andersk> http://dietrichschroff.blogspot.com/2008/07/openafs-on-debian-configuration.html
<lionel> andersk: yeah, I configured it once, but that's not an "easy" task
<andersk> Possibly the /usr/sbin/afs-newcell makes this easier.
<lionel> andersk: well, will continue my work on it. You bug is complete, there is no problem about it, just we are a bit slow processing
<andersk> Great, thanks.
<lionel> andersk: fell free to ping me again if it's not done over the week-end
<bryce_> pitti: btw mdz is asking for you in the online services session (in the desktop room) if you're not otherwise occupied
<seb128> bryce_: he's leading a language pack session with danilo
<bryce_> seb128: thanks
<gicmo> mnemo: hmm
<tjaalton> doko: the mesa build problems are because lpia/armel don't have MAP_ANONYMOUS?
<wgrant> doko: You ran away!
<doko> wgrant: no, you did ;) anyway, meet in the lobby?
<wgrant> doko: Bah, only for a moment. Which building?
<doko> wgrant: coffe lobby
<wgrant> Sure, I'll be there in a minute or so.
<doko> $ fgrep -r MAP_ANONYMOUS /usr/include/
<doko> /usr/include/bits/mman.h:# define MAP_ANONYMOUS 0x20            /* Don't use a file.  */
<doko> /usr/include/bits/mman.h:# define MAP_ANON      MAP_ANONYMOUS
<doko> /usr/include/asm-generic/mman.h:#define MAP_ANONYMOUS   0x20            /* don't use a file */
<doko> tjaalton: ^^^
<tjaalton> doko: so bits/mman.h, not sys/mman.h
<doko> tjaalton: did you check on lpia?
<tjaalton> doko: nope
<tjaalton> but x86 has sys/mman.h
<tjaalton> doko: I'll try the chroot
<tjaalton> doko: no match for lpia
<tjaalton> oh wait
<tjaalton> doko: right, better to install libc6-dev before checking that. anyway, it's the same as with armel, so mesa should be patched to check bits/
<\sh> grmpf...why is the updated hardy kernel build with 4.2.3 but on upgraded hardy there is gcc 4.2.4?
<tjaalton> doko: sorry, bits/mman.h is included by sys/mman.h, so it's something different then
#ubuntu-devel 2008-12-11
<\sh> oh guys...
<\sh> doko: any clue how to solve this issue...hardy kernels were build with gcc 4.2.3, while gcc 4.2.4 was uploaded to proposed and then moved to -updates...it's strange to see warning messages from vmware-server e.g.
<directhex> warnings or actual problems?
<\sh> directhex: hopefully only warnings...I'll see this night, if the modules of vmware-server (1) compiled with 4.2.4 and kernel compiled with 4.2.3 are throwing real problems
<NickyMC> Yo, yo.
<NickyMC> What's going on?
<StevenK> UDS
<NickyMC> Anyone free to answer a question for me in here?
<tjaalton> doko: bingo. I found out that building on x86 with the same options failed, so I tried adding the missing options to the lpia build, and adding -D_BSD_SOURCE made it work
<doko> tjaalton: nice, some cause on armel?
<tjaalton> doko: I'll check, but most likely yes
<tjaalton> doko: oh well, obviously can't run an armel chroot on x86 :)
<StevenK> tjaalton: qemu
<tjaalton> StevenK: hmm ok
<tjaalton> StevenK: it emulates armel too?
<StevenK> tjaalton: It ought to, but I have an armel board
<tjaalton> StevenK: you've got jaunty on one?
 * StevenK does
 * StevenK is using it to track down an ICE for doko
<tjaalton> StevenK: ok, could you try compiling this file then? I can pastebin the command
<StevenK> tjaalton: And where is the file?
<tjaalton> StevenK: grab mesa source, cd src/mesa and then run http://pastebin.ubuntu.com/83774/
<tjaalton> it's 42MB unpacked..
<StevenK> tjaalton: Bleh!
<tjaalton> StevenK: :)
<StevenK> Like my armel has that much space anyway
<tjaalton> ok, let me try first to compile just that file
<StevenK> tjaalton: Trying now
<tjaalton> StevenK: the includes are problematic, can't just rip that file out
<StevenK> tjaalton: What you said in the pastebin is correct
<ogra_> StevenK, you didnt get an 8G SDHC at fry's ?
<ogra_> we all did ...
<tjaalton> StevenK: so adding -D_BSD_SOURCE did it? nice, thanks for testing!
<tjaalton> doko: ^^
<StevenK> tjaalton: No problem
<tjaalton> ogra_: whaa, they gave those?
<ogra_> tjaalton, nah, they sold them for $24.95
<tjaalton> ogra_: heh, ok.. :)
<ogra_> SDHC micro with mini and std adapter
<lifeless> fta: reed and asac want you badly outside 1500
<sladen> ah, since all you people are in the Google Campus, perhaps you could tell them that they  http://www.google.com/copyright?hl=en  link they publish at the bottom of AFP articles is broken
<emgent> bug #44194
<ubottu> Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194
<kees> slangasek: woo! yeah, NEW queue bloated nicely.  :)
<ScottK-laptop> ftp-masters had a busy weekend.
<ScottK-laptop> kees: clamav did the change to allow us to re-enable modules after we patch them for their next release.  It looks simple enough I think we might consider backporting it. http://paste.ubuntu.com/83722/
<ScottK-laptop> It's late enough here.  I'm off to bed.  Good night all.
<StevenK> Night
<mnabil> guys, i'm building a live cd and i just wanna set the default kernel for the live cd to be linux-rt but every time the iso boots it drops to initramfs shell , any idea ?
<StevenK> That the squashfs doesn't include the modules for -rt, or you didn't regenerate the initrd?
<YokoZar1> the new transparent ubuntu stickers fit great on the U key by the way
<mnabil> StevenK, i'm doing debootstrap then i chroot then apt-get install linux-rt
<mnabil> StevenK, the squashfs module is in the kernel
<Mithrandir> mnabil: look at casper.log in /, perhaps?
<Mithrandir> hm, in /var/log, I think
<mnabil> Mithrandir, casper.log says : mount: mounting aufs on /root failed : no such device
<mnabil> mount aufs failed
<kees> ScottK-laptop: cool!
<Keybuk> that hot tub is so chlorinated, I think I have second degree burns
<YokoZar> chemical burns are the best
<mnabil> i regenrate the initrd again , and made a new iso !! still the same problem ! any idea
<mnabil> or ref. or any thing
<hughsie> ayone seen glatzor?
<phix> hughsie: I could tell you where he's not
<hughsie> phix: :-) thanks!
<phix> you know, to narrow down your search :P
<joaopinto> NCommander, not sure this should be included on the specification (Backports Selective Installation), but it wold also make sense to add support on apturl, so you could provide something like apt://name;rep=backports
<yao_ziyuan> one of the few things i think fedora does well in is
<yao_ziyuan> it uses WenQuanYiHei as the default font for large-size chinese characters
<yao_ziyuan> can ubuntu do that?
<tjaalton> doko: so, should I fix the mesa build issue in the mesa package?
<doko> tjaalton: please do so!
<tjaalton> doko: ok, will do
<Riddell> tkamppeter: your session needs you
<slytherin> can some archive admin please add libjaxp1.2-java to sync blacklist and remove the source from jaunty queue? Please refer bug #251973
<ubottu> Launchpad bug 251973 in libjaxp1.2-java "Please remove the package from repositories" [Wishlist,Fix released] https://launchpad.net/bugs/251973
<lifeless> tjaalton: There is another session on at the moment - https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-hotkey-madness - that apparently you would be very relevant to
<lifeless> tjaalton: bryce says that if it is possible for you to come - to apollinaris - it would be great
<tjaalton> uhh, ok :)
<lifeless> pitti: did I get the message right about hal - 'hal -> devicekit, rm hal' (over some arbitrary time period)
<radix> Hobbsee: sorry about the wrong subscription. I had a brainfart. :(
<radix> and thanks for fixing the subscription.
<Hobbsee> radix: no great problem.  You're only the billionth one to do it :P
<radix> there should be a "find sponsorship" button in launchpad :)
<ScottK-laptop> radix: "Canonical wants to offer a new feature" isn't a particularly strong SRU justification, I don't think.
<ScottK-laptop> FYI.
<slytherin> Hobbsee: can you please add libjaxp1.2-java to sync blacklist and reject source from jaunty queue?
<Hobbsee> slytherin: i'll do the latter, i can't do the former.
<slytherin> Hobbsee: then who can do the former?
<Hobbsee> slytherin: an archive admin who is a canonical employee.
<Hobbsee> source is already rejected, it seems.
 * Hobbsee wonders why that isn't kept in bzr somewhere, like ~ubuntu-archive
<Hobbsee> slangasek: any particular reason for this?
<slytherin> Hobbsee: Ok. I will keep a watch to see if it gets autosynced again.
<Hobbsee> slytherin: it likely will, if it's not on the blacklist
<Hobbsee> they tend to keep running new package autosyncs, it seems
 * slytherin is felling sleepy, quits
<ScottK> pitti: It looks to me like the KDE 4.1.3 updates are ready for copying to -updates.  This is convenient since 4.1.4 was tagged yesterday and it'd be nice to clear the deck for the next update.
<ScottK> https://bugs.edge.launchpad.net/~ubuntu-sru/+bugs?field.bug_reporter=jr
<pitti> ScottK: right, I'll copy it soon; thanks all for testing
<pitti> lifeless: right, hal -> DK plus DK-power plus DK-disks, etc.
<ScottK> pitti: Thanks.
<tjaalton> my mesa uploads are rejected for some reason I can't understand: http://pastebin.ubuntu.com/84124/
<tjaalton> -0ubuntu2 was accepted just fine
<slangasek> Hobbsee: why isn't what kept in bzr somewhere?
<Hobbsee> slangasek: afaik it is, but it's not public?  or is hidden inside canonical somewhere?
<Hobbsee> (not in revision control)
<slangasek> Hobbsee: what was the "what" that is or isn't?
<slangasek> the sync blacklist?
<Hobbsee> correct.
<Hobbsee> oh
<Hobbsee> sorry, i misread.
<Hobbsee> yes, the sync blacklist.
<slangasek> yeah, it's in bzr; but it appears to be an in-place bzr branch
<slangasek> the answer might be "because we don't have an easy way to share it bidirectionally"
<Hobbsee> bidirectionally?
<Hobbsee> as in, can't be kept on lp as a branch for ~ubuntu-archive?
 * StevenK kicks libtool for being obtuse
<kees> infinity: PIE take 1: fail.
<slangasek> take one pie
<slangasek> nom nom
<slangasek> Hobbsee: as in, I'm not sure what cocoplum can or can't access at that point, yeah
<Hobbsee> ah, right
<slangasek> Hobbsee: the other counterargument that comes to mind is that even if we had it in a branch on LP, that could never be the authoritative branch because that wouldn't be auto-propagated to cocoplum...?
#ubuntu-devel 2008-12-12
<slangasek> (i.e.: you'd still have to ping one of the admins w/ access)
<Hobbsee> slangasek: oh, so cocoplum doesn't have access outside the DC.  Got it.
<Mez> hmm, dh_make creates a control with standards version 3.7.3, but lintian reports that the latest standards version is 3.8.0 ... Should I report that as a bug ?
<slangasek> Mez: yes, preferably after determining whether the dh_make template requires further changes to be compliant with 3.8.0
<kees> doko: can I come pick your brain briefly?
<azeem> hrm, braaains
<Mez> lol @ azeem and @ slangasek: I'll check later ;)
<Hobbsee> did someone say brains?
<Mez>    * Updated to standards version 3.8.0 - :(
<LaserJock> Hobbsee: not mine
<ajmitch> mine fled long ago
<LaserJock> laser got mine ... I think
<infinity> doko: You around?
<infinity> doko: You told me you needed a gcc-3.4 bootstrap on armel built with gcc-3.4 from unstable, except that gcc-3.4 doesn't build-dep on itself...
<infinity> doko: gcc-3.4 [!armel !hppa]
<infinity> doko: Upload a source package with correct build-deps, and I'll build it for you. :P
<infinity> doko: Worth noting also that it's not built on armel/Debian either... It's marked Not-For-Us in wanna-build and has no binaries in the archive.
<StevenK> Oooh, fun
<ogra_> infi
<ogra_> nity ...
<ogra_> hrm
<ogra_> infinity, do you have PAS power ?
<infinity> ogra_: Not since it moved.  We're discussing what to do about that.
<infinity> ogra_: Either we get upstream commit access, or we finally fork it.
<infinity> ogra_: (Forking it would be more attractive if codehosting allowed for rolling git-bzr merges)
<ogra_> whom do i poke then for packages i want to vanish from armel ?
<ogra_> lamont ?
<infinity> I don't think lamont has access to the new world order either.
<ogra_> hmm
<infinity> ogra_:
<infinity> # Please submit additions, corrections and removals as bugs against
<infinity> # buildd.debian.org to the Debian bug tracking system.  Comments may
<infinity> # also be sent to packages-arch-specific@buildd.debian.org.
<ogra_> i dont really mind if acpi and libx86 ftbfs constantly on arm, but PAS would be more proper
<StevenK> ogra_: Fix it
<StevenK> :-P
<ogra_> StevenK, get me a soldering iron and a BIOS chip that works with arm then :P
<kees> NCommander: around?
<NCommander> kees, yeah, I am :-)
<kees> NCommander: where did you find gentoo's 4.3 hardened compiler?  I'm having a hell of a time finding it.
<johanbr> crimsun: Could I ask what your opinion is on bug 275998 ? (mic volume very low on dell laptops) Kernel/alsa bug, pulseaudio bug or something else?
<ubottu> Launchpad bug 275998 in linux "audio recording very silent" [Undecided,Invalid] https://launchpad.net/bugs/275998
<NCommander> kees, its very very well buried, its in the hardened overlay for Gentoo
<kees> NCommander: yeah, I couldn't find anything past 4.0.3, and even then, it was still disabled.
<NCommander> THere was a 4.3 compiler
<kees> NCommander: can you dig up a URL for me?  :)
<NCommander> kees, sure
<radix> this ubuntu development stuff is too stressful for my fragile sensibilities
<ScottK-laptop> radix: If you'd like to discuss my comment in the bug, I'll be glad to.
<radix> ScottK-laptop: landscape has a special exception for SRU (which is about to be tested): wiki.ubuntu.com/StableReleaseUpdates
<ScottK-laptop> radix: According to the relevant Ubuntu documentation it does not.
<ScottK-laptop> radix: https://wiki.ubuntu.com/StableReleaseUpdates#Landscape says it's not approved by the tech board (which is the approval authority for such exceptions)
<ScottK-laptop> If that out of date, then a reference to some tech board meeting minutes and we can get it fixed.
<ScottK-laptop> It wouldn't suprise me if people think it has one.
 * lamont feels stupid tonight... and lazy
<lamont> so... BCM 4306 vs intrepid... how painful is that?  and is there something of clue on the wiki and or forums???
<Roey> hi
<Roey> libmysqlclient15-dev doesn't seem to be compiled with -fPIC for 64-bit architectures, and it's breaking my compile of amarok 2.
<Roey> (hmm, did this get across before I disconnected from here accidentally?)  libmysqlclient15-dev doesn't seem to be compiled with -fPIC for 64-bit architectures, and it's breaking my compile of amarok 2.
<ScottK-laptop> Roey: I thougth Amarok 2 was designed to with the the embedded ilbrary so you need mysql 5.1?
<Roey> I
<ScottK-laptop> It did get across.
<Roey> hmm.
<Roey> ok
<ScottK-laptop> One of the Kubuntu PPAs has Amarok 2 packages already made I'm pretty sure.
<Roey> is there a 5.1??
<Roey> It hought it's 1.5
<Roey> I did apt-cache search mysql 5.1 and didn't find anything for that.
<ScottK-laptop> mysql 5.1 is released.  It's in Debian Experimental, but not in Ubuntu yet.
<Roey> hrm.
<Roey> Scott, so this is the problem then, you think?
<Roey> that it's lacking the mysql 5.1 dev package?
<ScottK-laptop> Yes.
<Roey> ScottK-laptop:  thanks, I'll bring it up with the #amarok folks
<ScottK-laptop> Roey: https://launchpad.net/~kubuntu-members-kde4/+archive has an amarok 2 package for Intrepid.
<Roey> ah thanks.
<RAOF> If libmysqlclient15 wasn't built with -fPIC on x86-64 then that's a pretty serious bug; it'll render it useless, surely?
<Roey> RAOF:  well it certainly breaks my compiles of Amarok2.
<Roey> what is -fPIC all about anyway?
<RAOF> Building Position-Independent Code.
<RAOF> And you can't link to anything but PIC code on x86-64, IIRC.
<Roey> ah
<Roey> aaaah
<Roey> hee hee, I guess that needs to be addressed at the ubuntu package maintainers level then
<Roey> i.e. it is a bug.
<ScottK> The thing breaking your amarok 2 build is (I'm pretty sure) building against the wrong version of mysql.
<Roey> well let's see:
<RAOF> Yeah, it certainly looks from the buildlog like libmysqlclient is built with fPIC
<Roey> ii  libmysqlclient15-dev        5.0.67-0ubuntu6             MySQL database development files
<lamont> yay. ndiswarper did the trick
 * lamont goes to clean up the vomit
<Roey> scottk: this is what I have installed:  http://pastebin.com/m1cb3dd01
<ScottK-laptop> Roey: Right.  None of which is 5.1.  I'd suggest just use the PPA package.  I haven't built it myself, so I can't give you detailed advice.
<ScottK-laptop> lamont: I wrote another spec thingy for more automagic wonderful integrated mail server goodness for Jaunty.
<ScottK-laptop> It's on for the first session on the server track tomorrow.
<Roey> ScottK-laptop:  ok, thank you very much
<Roey> ScottK-laptop:  do you know when 5.1 will hit kubuntu?
<ScottK-laptop> No.
<Roey> ok
<Roey> well anyway
<Roey> thanks a lot for the clarification!! :)
<Roey> I'm going to sleep
<Roey> good night
<phix> :D
<phix> why doesn't Ubuntu suggest I use RAID1 when I have two HDDs the same size in my computer?
<phix> or have server "templates" so to speak with common filesystem arrangements and packages? you know something a bit more high level.
<ScottK-laptop> Something like that was a topic of discussion at the developer summit that's going on this week.
<ScottK-laptop> I didn't listen to the session, so I don't know the details.
<ScottK-laptop> #ubuntu-server might be a better channel.
<phix> thnx
<phix> ScottK-laptop: well it could be applied to desktop as well, templates being a generic name for it which may be appropiate here ;)
 * lamont wonders what the VPN stuff in the network mangler pulldown is actually talking about, or where to go to figure that out (including maybe just the source package name for the beast in question)...
<phix> jussi01: <3
<phix> Is the network manager a gnome project or part of Ubuntu?
<phix> I really dislike how it has no concept of bridges
<phix> hi
<Dyresen> When running puppetmasterd, ralsh or anything related to puppet (ruby) on intrepid you get flooded with warnings like  "warning: already initialized constant KNOWN_OPTIONS" This seems to be that it is trying to load stuff twise. /usr/lib/ruby/1.8/lib/xmlsimple.rb is symlinked back to /usr/lib/ruby/1.8/xmlsimple.rb Both of these are owned by libxml-simple-ruby as far as I can see. If you delete the symlink puppet runs fine (for me at least)
<Dyresen> Is there any particular reason I would need that symlink, or can I go and safely remove it?
<ScottK> pitti: For Kubuntu we'll need mysql on CD anyway for Akonadi, so Amarok using it too doesn't bloat the CD significantly.
<pitti> ScottK: but ... why?
<infinity> ...
<infinity> Why does kdelibs build-depend on sudo?
<infinity> Oh, looks like another case of "I don't know how to pre-seed configure, so I have to install every binary it checks for"...
<infinity> \o/
<stdin> infinity: because kdesu needs to use sudo
<stdin> and kdelibs don't use configure, it uses cmake :)
<kees> doko: can you ACK 254790?  it's an upstream changeset for binutils
<doko> kees: sure
<jdstrand_> #ubuntu-server-summit
<jdstrand_> *sigh*
 * Hobbsee hands jdstrand_ a /j
<ScottK> pitti: Because mysql is the data store for Akonadi which is meant to be the store for all kinds of user data.
<LaserJock> ScottK: can Akonadi use a different DB than mysql?
<ScottK> LaserJock: No.
<ScottK> Not AFAIK anyway.
<LaserJock> ScottK: that's kind of a bummer
<pitti> ScottK: akonadi can't use embedded mysql either?
<ScottK> pitti: As understand it, and my understanding is shallow, Amarok uses the embedded and Akonadi doesn't.
<pitti> ScottK: that still seems to be somewhere in between "crack" and "irresponsible" to me
<ScottK> pitti: Which?  or Both?
<ScottK> Note that these are both upstream issues ....
<pitti> ScottK: installing a full sql server as part of a desktop install
<pitti> ScottK: yes, I know; that doesn't change my perception, though :(
<ScottK> OK.  Just limits what we can do about it.
<ScottK> Akonadi is one of the core KDE4 technologies.
<LaserJock> I really try to avoid putting mysql server on my desktops
<kirkland> Daviey: ping
<kirkland> Daviey: can you send me your .screenrc?
<kirkland> Daviey: would you mind if I used yours, with attribution and kudos of course, in my blog post as an example?
<infinity> doko: perl/hppa's testsuite doesn't seem to have been disabled as well as you'd hoped.
<Daviey> kirkland: wilco
<dholbach> thank Alberto here: http://hall-of-fame.ubuntu.com/ :)
<ara> dholbach: i have a LP picture profile, but it does not appear when I thank somebody
<dholbach> ara: oh... that's weird
<dholbach> ara: I'll take a look at what's happening there
<ara> dholbach: I just uploaded the picture yesterday, maybe it is related
<dholbach> ara: might be - I'll let you know in a bit
 * dholbach hugs ara
 * ara hugs dholbach back :-)
 * RainCT looks how dholbach and ara hug :P
<jpds> ...
<RainCT> ^^
<ara> RainCT: voyeur!
<dholbach> ara: exactly my thoughts
<Chipzz> meh
<Chipzz> I hate the whole UUID crap
<ogra> what do you expect if you are cuddling in the hallway :P
 * StevenK blinks
<ion_> The UUID crap is for the win.
<RainCT> +1
<LaserJock> I still have more problems with UUID than with the "old fashioned" way
<ScottK-laptop> LaserJock: You use multiple drives in the same system?
<LaserJock> on a couple systems yeah
<jpds> Right, food time,
<LaserJock> not on the laptop
<LaserJock> but on my laptop I regularly have swap or other partitions go unmounted because the UUID has changed
<ScottK-laptop> I've helped people on pre-UUID systems where the BIOS and the OS had a differnt idea of which drive came first.
<ScottK-laptop> It can be a real nightmare.
<LaserJock> ScottK-laptop: yeah, I've not had that problem
<ScottK-laptop> Weird.  I've never had that.
<LaserJock> ScottK-laptop: but I know it does exist
<LaserJock> so I do see the point of UUID
<LaserJock> but for me I get better consistency if I *don't* use UUID
<LaserJock> so the benefits of having a large, non-human-rememberable identifier are lost :-)
<ScottK-laptop> I don't think I've had any trouble with it since Feisty or so.
<LaserJock> if you install other OSes it's pretty common
<ScottK-laptop> Maybe that's why I'm OK then.
<LaserJock> some OSes in particular like to reformat *any* swap partition available, regardless of if you tell it to or not
<LaserJock> sometimes they seem to change the UUID just by setting up the partitioning in the installer, very unhelpful
<ScottK-laptop> Weird.
<raylu> do ubuntu devs run virtual machines and, if so, what virtualization software do they use?
<LaserJock> raylu: people use all kinds of stuff, vmware, virtualbox, qemu, kvm, Xen
<directhex> kvm is nice if you have a cpu that supports it
<LaserJock> directhex: yeah, that's my problem
<LaserJock> only thing bad about my laptop :(
<directhex> vmware, then. 32-bit only.
<LaserJock> so I end up using virtualbox or vmware player
<slangasek> tjaalton: http://paste.ubuntu.com/84531/
<slangasek> tjaalton: halp :-)
<slangasek> tjaalton: why is X not listening on this one?
<tjaalton> slangasek: actually, it's the same thing on my thinkpad too
<tjaalton> but I have an fdi file to clear x11_driver for this device
<iGama> Hy ! is NM0.7 in 9.04 the final version already?
<tjaalton> wonder why though
<slangasek> tjaalton: I still get input.x11_driver = ''
<tjaalton> slangasek: yeah, me too..
<slangasek> it's possible that someone merged this thinkpad fdi into hal-info as a workaround for a bug... yay, wrong fix \o/ :)
<tjaalton> hehe :)
<slangasek> /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi
<tjaalton> oh...
<slangasek> "workaround for -evdev exclusively grabbing all keyboards and X not processing the extra buttons properly"
<slangasek> so: that makes sense for intrepid actually, if we think there are keys on that device that need to be split between X and hal, yes?
<tjaalton> yeah
<tjaalton> "most" of my hotkeys worked fine
<slangasek> the ones processed through hal, yeah
<slangasek> so we could flesh out the workaround by having hal deliver the switchvideomode button somewhere...
<slangasek> or we could all just upgrade to jaunty
<slangasek> I guess I should go ahead and back this workaround out of jaunty anyway, right?
<tjaalton> yeah, dogfood and all that :)
<tjaalton> I guess so, I've now removed that bit and will try all the hotkeys
<slangasek> I guess a different, non-overlapping set of them will fail because they need to be handled through hal instead
<tjaalton> right, like rfkill
<slangasek> rfkill is handled by <cough> acpi-support
<tjaalton> well it does nothing here
<slangasek> hmm, it /also/ generates a keycode
<slangasek> yay redundancy
<tjaalton> I can't see keycodes with xev
<tjaalton> from that button
<tjaalton> oh wait, Xorg.0.log has: (WW) ThinkPad Extra Buttons: unable to handle keycode 385
<slangasek> yay
<tjaalton> so that's the reason
<RainCT> did someone hilight me? (dunno how but I just terminated the screen session :P)
<tjaalton> it should be quirked in the kernel and mapped to a sane keycode below 255
<RainCT> -.-
<slangasek> tjaalton: which key is that which generates the wrong keycode - switchvideomode, or radio?
<RainCT> argh.. anyone knows why screen suddenly decided to die each time I try to autocomplete a name? :P
<tjaalton> slangasek: radio, switch.. is mapped to XF86Display
 * slangasek nods
<slangasek> RainCT: because it's really crashing irssi and screen is exiting because there are no windows left?
<tjaalton> but the bay eject button has NoSymbol, keycode 202, and that's probably a bug in xkb-data
<RainCT> :'(
<RainCT> slangasek: probably, but the question still remains: why is irssi crashing then?.. :P
<slangasek> dunno, run it under a shell to see?
<slangasek> or under gdb
<tjaalton> slangasek: btw, I thought a bit further about the case where input-listen (?) shows keycodes but xev doesn't. it can't be a bug in xkeyboard-config since there's no keycode to map to (since it's most likely above 255 which X can't handle=
<slangasek> ok
<RainCT> slangasek: Segfault
<slangasek> debug it under gdb then and file a bug?
<tjaalton> slangasek: but the ones that show in xev and with NoSymbol or produce wrong output, are bugs in xkeyboard-config
<slangasek> ack
 * RainCT will try a memcheck first
<mnemo> is there anything I can set in DEB_BUILD_OPTIONS to make sure that gcc gets "-rdynamic" when building a package??
<kees> Tonio_: *wave*
<Tonio_> kees: hey !
<slangasek> mnemo: no
<mnemo> is there any other way I can make that happen?
<Tonio_> kees: as you may know, we have a little trouble with kde 4.2 and mysql...
<kees> Tonio_: yeah, I've heard there is a 5.1 build-dep
<slangasek> mnemo: you can set LDFLAGS=-rdynamic in the environment, and that will work for some significantl number of packages
<kees> Tonio_: but that we're not ready for 5.1 in main, etc
<Tonio_> kees: hum, afaik mysql 6 can be used in the first place...
<Riddell> oy
<Riddell> it's two issues
<mnemo> slangasek: okay so can I do stuff like "LDFLAGS=-rdynamic DEB_BUILD_OPTIONS=nostrip fakeroot debian/rules binary" then?
<kees> heya Riddell
<slangasek> mnemo: yes, you can
<Riddell> amarok needs libmysql-client from 5.1
<mnemo> awesome, thanks a lot
<Riddell> akonadi (kmail) needs mysql without the daemon
<kees> Riddell: but it needs something that only exists in 5.1+?
<Riddell> amarok does yes, see our package at https://edge.launchpad.net/~kubuntu-members-kde4/+archive/+index?field.name_filter=mysql&field.status_filter=published
<NCommander> ScottK, you around?
<slangasek> wow; I just typed 'debdiff' on a line by itself in error, and it did something useful but unexpected
<kees> Riddell: okay, so the -dev is built out of main, but it links and runs at runtime against a library in universe?
<kees> why does amarok need the 5.1 client lib?  anywqy, it sounds like akonadi is the larger problem?
<Riddell> kees: I don't follow, amarok 2/mysql 5.1 is only in a PPA for now, no main or universe
<Riddell> kees: amarok uses mysql to store its library data
<kees> Riddell: ah-ha!
<kees> Riddell: but it could build against the 5.0 client?
<Riddell> kees: no, amarok needs 5.1 I believe
<Riddell> akonadi uses mysql in a different way, it can use 5.0 but doesn't need it running as a server so the packaging should be split
<slangasek> I wonder why that need shouldn't be corrected
<kees> can that be fixed?
<Riddell> kees: can which?
<kees> sounds like the 5.1 build-dep is the main issue
<Riddell> kees: I suspect so
<slangasek> tjaalton: hrm, if I've munged my fdi file and restarted hal, what do I need to do to get X to recognize the change?  Restart X?
<slangasek> (I've tried switching vts, that didn't do it)
<tjaalton> slangasek: evdev should pick it up, tail /var/log/Xorg.0.log
<slangasek> tjaalton: nope, no sign of it being picked up; if I grep the log, the only thing I see is that the device was discarded earlier with 'No input driver/identifier specified'
<ogra> slangasek, yes, you need to restart x after hal
<ogra> unless that bwas recently changed
<tjaalton> well, with jaunty + xserver 1.6bet3 + evdev 2.1.0 I didn't need to restart X
<ogra> oh, right,latest x and evdev should be more dynamic
<NCommander> hey ogra
<ogra> yo
<slangasek> tjaalton: right, I'm not on jaunty yet :)
<tjaalton> slangasek: yeah I knew that :)
<LaserJock> is there going to be an All Hands next week?
<slangasek> no
<ogra> next year
<LaserJock> ah, just wondered when people would be returning home
 * ogra returns tomorrow
<RainCT> slangasek: it's working fine again after restart (and memtest found no errors) :S
<slangasek> well, reproducible segfaults are not indicative of memory errors
<slangasek> I would've told you that, but you rebooted rather quickly :-P
<RainCT> slangasek: of course, but I did the check because I'm experiencing hard freezes from time to time
<RainCT> that's probably a kernel problem or something, though, as it started happening after I installed Intrepid :(
<ScottK> NCommander: Around now.
<ScottK> Riddell and kees: We discussed this topic (Akonadi, Amarok 2, and Mysql) at the last Server Team meeting.
<ScottK> As I understand it Amarok needs 5.1 due to using Mysql embedded which is not existent/not supported in 5.0.
<NCommander> ScottK, care to look over my backporting request?
<ScottK> Sure
<Riddell> NCommander: you wanted me?
<NCommander> For said backporting request :-)
<NCommander> ScottK, https://bugs.edge.launchpad.net/intrepid-backports/+bug/307569
<ubottu> Launchpad bug 307569 in intrepid-backports "Please backport Xfce 4.4.3 to Intrepid" [High,In progress]
<NCommander> I think I'm setting a record on number of crackports I'm doing at once ...
<Riddell> http://www.mysql.com/ "MySQL 5.1 is here"
<ScottK> NCommander: Why are you asking me?
<ScottK> NCommander: You can approve it.
<NCommander> I just wanted to make sure there was nothing wrong in doing 22 backports at once ...
<ScottK> NCommander: The biggest problem you'll have is that backports have a very low priority for the buildd's.
<ScottK> So the builds will likely be spread out.
<NCommander> That's ok
<NCommander> THe versions are tight where they need to be
<ScottK> OK.
<NCommander> And Xfce is modular, so as long as everything is properly built int he end ...
 * directhex remembers the good old days of carefully ordered xfce4 uploads
<ScottK> Riddell and kees: The added fun factor for the Amarok/Akonadi/Mysql express is that (as I understand it) different Mysql versions are not co-installable and so for a Kubuntu Desktop to actually be installable, both those packages need to be using the same mysql version.
<Riddell> ScottK: that's not the case
<Riddell> amarok's mysql use is statically compiled in (that's how mysql provides the library)
<ScottK> Riddell: OK.  That's good news.
<ScottK> We didn't understand that when we were discussing it at the Server Team meeting.
<ScottK> So for added fun I'll be running two copies of mysql then?
<Riddell> we're running no copies of mysql
<Riddell> it's not being used as a server
<Riddell> it's local store only
<ScottK> OK.  There's some myql bit that's running and it sounds like there will be two of them?
<Riddell> amarok uses libmysql to read/write its local store
<directhex> how heavy is that compared to the more usual sqlite?
<Riddell> akonadi uses a local instance of mysqld for its local store
<Riddell> (so I was half right when I said nothing mysql was running)
<Riddell> directhex: in the amarok case libmysqld is about 1MB
<ScottK> directhex: It's heavier, but that's irrelevant as these are upstream decisions that are made long ago.  We just have to figure out how to integrate them smartly.
<slangasek> tjaalton: hmm, so I've dropped the fdi file in intrepid, restarted my X server; X now listens on the device but doesn't see any keypress events
<slangasek> tjaalton: strangely, my video key now works without acpid running, but I can't figure out what's handling it
<tjaalton> slangasek: huh, odd.. on jaunty it seems to be somewhat better
<slangasek> I do get a warning in Xorg.0.log about keycode 385
<slangasek> but just the one warning, and I don't know what keypress it is
<tjaalton> should be rfkill
<slangasek> right, I don't know... it only shows up once in the log, no matter how many times I hit other keys (?)
<slangasek> I can confirm with showkey that rfkill == 385
<tjaalton> the driver probably just ignores the following keypresses
<kirkland> superm1: patch attached to https://bugs.edge.launchpad.net/ubuntu/+source/mythtv/+bug/243504
<ubottu> Launchpad bug 243504 in mythtv "mythtv-setup: unable to connect to database" [Undecided,In progress]
<superm1> great thanks kirkland
<superm1> kirkland, weren't there changes to the postinst too?
<superm1> or do they end up not being necessary?
<kirkland> superm1: i dropped those
<kirkland> superm1: not necessary
<kirkland> superm1: all done in the .config
<superm1> i suspect that i need to review what really needs to be in a postinst then
<superm1> i seem to get confused by this stuff
<kirkland> superm1: i *think* the interactive part goes in the .config
<kirkland> superm1: and it's the postinst that does stuff
 * jdong tests the new fglrx for fun
<slangasek> tjaalton: where does the rfkill need to get quirked?
<superm1> jdong, it should be able to nicely build you packages for hardy intrepid or jaunty from it's internal build scripts
<tjaalton> slangasek: the kernel AIUI
<superm1> jdong, oh i needed to bug you.  i needed some crack.  do you have some VDPAU enhanced mplayer sitting around?
<jdong> superm1: O_O I don't have any super mplayer
<superm1> jdong, man i was hoping you'd be all over that
<jdong> sorry :)
<slangasek> tjaalton: but hal has a way to poke in keycode overrides... hmm, I think information/10freedesktop/30-keymap-lenovo.fdi is supposed to be it, no?
<slangasek> I don't understand how the symbolic names like 'radio' are mapped, though
<tjaalton> slangasek: see for instance /usr/share/X11/xkb/symbols/inet, and search for XF86WLAN (maybe the correct one, dunno)
<slangasek> tjaalton: that doesn't include any name/number mappings, either?
<superm1> tjaalton, XF86WLAN is supposed to be a software kill switch though?
<superm1> apw, when you press that key on the left side of your display, is that the keycode emitted for you too?
<tjaalton> slangasek: /usr/share/X11/xkb/keycodes/evdev
<tjaalton> superm1: I've got a thinkpad, so no such key here
<superm1> tjaalton, well on a thinkpad, is that the keycode emitted when you press your software kill switch?
<superm1> if so then we might have a weird collision with the behavior among manufacturers
<tjaalton> superm1: that's the keycode I get from fn-F5, yes. there is a switch too which forces all radios off
<superm1> tjaalton, ah interesting.
<tjaalton> slangasek: I've looked at the lenovo.fdi before, and oh my .., yet another set of mappings :)
#ubuntu-devel 2008-12-13
<slangasek> tjaalton: I don't find 385 in /usr/share/X11/xkb/keycodes/evdev either...?
<tjaalton> slangasek: XF86WLAN -> <I246> -> keycode 238
<tjaalton> slangasek: you can find 238 in /usr/include/linux/input.h
<slangasek> tjaalton: and where does the 385 /come/ from?
<tjaalton> ie. KEY_WLAN
<slangasek> the scancode isn't 385, the scancode is 0xe016
<tjaalton> slangasek: the module, X can't handle keycodes >255
<slangasek>           <append key="input.keymap.data" type="strlist">e016:wlan</append> <!-- Fn+F5 wireless -->
<slangasek> what does that fdi line do?
<tjaalton> beats me :)
<slangasek> I understood that it maps the e016 scancode to the "wlan" keycode
<slangasek> but I don't see where wlan == 385
<tjaalton> hmm, there's also KEY_RADIO
<superm1> slangasek, are you using intrepid-proposed (or jaunty for that matter)?
<slangasek> intrepid-proposed, yes
<tjaalton> slangasek: how does e016 map to hex?
<superm1> slangasek, okay just wanted to make sure you had all the right bits in place.  XF86WLAN probably wasn't available until my upload of a few of the hotkey things to proposed
<slangasek> tjaalton: do you mean decimal?
<slangasek> superm1: oh - I haven't pulled from -proposed at all this week :)
<tjaalton> slangasek: input.h has only <255 in decimal, rest is in hex
<slangasek> tjaalton: well, e016 is a hex number, so I'm not sure what you mean by "map to hex" :)
<superm1> slangasek, you might want to make sure you've got the handful of my stuff from last week then.  libx11-data, xkeyboard-config particularly
<tjaalton> slangasek: heh, ok.. different format then :)
<superm1> otherwise you'll have some possibly unexpected behaviors
<tjaalton> e016 == 57366 (dec)
<soren> pitti: If you're doing archive administration stuff today, some virt-viewer love would be much appreciated.
<soren> pitti: It's just binary new, if it matters.
<StevenK> soren: Why does the virt-viewer binary only provide /usr/share/doc stuff?
<soren> StevenK: You're kidding, right?
<StevenK> Nope
<StevenK> soren: Where are you, I'll show you?
<soren> Weirdness. I'm using it *right* now.
<LaserJock> dpkg -c ?
<soren> StevenK: Err... You're right.
<pitti> soren: probably not today; sort of busy...
<jdong> in a chroot, how do I disable calling of sysvinit scripts?
<jdong> I've seen pbuilders do this
 * soren glances at his build environment, rather puzzled.
<StevenK> soren: Shall I REJECT it, then?
<soren> StevenK: That would probably be best :)
<StevenK> pitti: Do I need to mail when I reject binary packages in NEW?
<pitti> jdong: man invoke-rc.d and look for policy-rc.d
<pitti> jdong: /usr/share/doc/sysv-rc/README.policy-rc.d.gz
<jdong> pitti: cool, just what I needed, thanks!
<tjaalton> superm1: is the missing_inet_keys patch sent upstream?
<superm1> tjaalton, i've sent everything i put in proposed upstream yes
<tjaalton> superm1: ok, svu is just slow then :)
<superm1> tjaalton, i forget which patch it was, but i know at least one package they wanted to wait for other parts to play catch up before they added it
<superm1> tjaalton, so they were going to add it in jan or feb for "distributions to catch up"
<tjaalton> superm1: ok, probably after xlib 1.2 is released
<bryce_> StevenK: https://wiki.ubuntu.com/Hotkeys now with gfx
<soren> Hmm.... The plot thickens... I just rebuilt, and it's still builds correctly here.
<soren> s/'s//
<StevenK> soren: Read the build log?
<soren> Did that..
<soren> Oh..
<soren> Heheh...
<soren> *blush*
<StevenK> Now you can explain :-P
<soren> Apparantly, trying to weed out diff from Makefile.in updates by doing -i(foo|bar|\.in|baz) isn't such a hot idea. Hint: virt-viewer.install is also matched by that regex. :(
<soren> So the .install files got left out of the diff.gz. -> fail
<soren> I suppose "Don't be an idiot" isn't an appropriate changelog entry.
<Hobbsee> sure it is
<Hobbsee> if you're writing it about yourself ;)
<Hobbsee> last i checked, self-depreciation is not against the CoC.
<jdong> exactly.
<jdong> be respectful TO OTHERS :)
<Hobbsee> !jdong
<ubottu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<Hobbsee> except maybe you ;)
<jdong> :)
<LaserJock> and nixternal
<azeem> if self-depreciation was against the CoC, bddebian would've never been a MOTU
<StevenK> soren: virt-viewer REJECTed
<LaserJock> azeem: lol!!
<nixternal> quit making fun of me!
<bddebian> Hey
<slangasek> superm1: I installed everything from intrepid-proposed, restarted X; I still get keycode 385
<bddebian> He's not, azeem hates me
<slangasek> superm1: should I have restarted hal first before restarting X?
<soren> StevenK: Thanks very much. Apologies for the wasted time.
<azeem> hating is against the CoC
<StevenK> soren: You owe me a beer :-P
<tjaalton> slangasek: I get the same with jaunty, so those changes can't make a difference here
<slangasek> tjaalton: heh, ok
<slangasek> well, I still can't figure out where 385 comes from
<soren> StevenK: Can you just get it from jcastro? I don't think I could drink all the ones he says he owes me anyway.
<StevenK> soren: :-P
<LaserJock> the beer economy
<slangasek> microbrewpayments
<LaserJock> I'm sure jorge is looking for a bailout
<LaserJock> "dude, I gave away all my beer, the economy would be ruined if I ran out!"
<tjaalton> slangasek: woo, 385 == 0x181 (hex) -> KEY_RADIO
<slangasek> tjaalton: ok, where did you find that?
<slangasek> apparently this debugging document is going to be a bit longer than I expected ;)
<tjaalton> slangasek: input.h. now, thinkpad_acpi.c has KEY_WLAN instead
<slangasek> it has KEY_WLAN declared to the same value?
<tjaalton> it only has a map of KEY_*, no mappings
<tjaalton> uhm, does that make any sense
<slangasek> no :-)
<tjaalton> line ~2034
<tjaalton> drivers/misc/thinkpad_acpi.c
<tjaalton> so, it maps scancodes
<tjaalton> to keycodes
<slangasek> mumble mumble kernel
<ogra> yummy, kernel
<slangasek> tjaalton: so, KEY_WLAN is supposed to be defined to 238?
<slangasek> and if I quirk the kernel keymap to output that, we should be golden?
<tjaalton> slangasek: yes, pretty much
<slangasek> ok, then I was in the right file before and just needed to flesh it out :)
<slangasek> because the fdi file doesn't match my model
<tjaalton> so you'll quirk in the fdi file?
<slangasek> at least for testing, yes
<infinity> doko: gcc-4.3 is still busticated on powerpc, fwiw.
<tjaalton> slangasek: cool, throw the patch to me so I can verify
<doko> infinity: yep, seen. maybe ask munckfish about it? won't fix it this week
<infinity> doko: Mmkay.  Wasn't all that distressed about it, just making sure you noticed.
<superm1> kirkland, i think it's needed still in the postinst too.  it's not doing the right thing for me on fresh installs at all
<slangasek> tjaalton: /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi :         <append key="input.keymap.data" type="strlist">0x04:radio</append> <!-- Fn+F5 wifi -->
<slangasek> tjaalton: patch == fix that :)
<slangasek> (both instances)
<tjaalton> slangasek: humm, ok, but actually, my lshal actually has that already :)
<slangasek> tjaalton: by "fix that", I mean "replace radio with wlan"
<slangasek> since radio == KEY_RADIO == FAIL
<tjaalton> ahh, right
<superm1> isn't KEY_RADIO really what should be providing such functionality though?
<tjaalton> we'll see in a minute :)
<elmo> does anyone know of a 'reduce a list of packages down as far as possible' in terms of 'if you have foo and bar and foo depends on bar, only list foo'
<elmo> a script/program to do so
<tjaalton> slangasek: ok, now xev shows XF86WLAN, but nothing happens :)
<tjaalton> but if it really should be KEY_RADIO, then there needs to be some daemon to listen to it, and X shouldn't care
<soren> elmo: Isn't that sort of what deborphan does?
<soren> elmo: If "have" == "is installed" anyway.
<ebroder> elmo: "aptitude install '!~M'" can sort of do that, but it usually tends to be overly inclusive
<Hobbsee> please P-A-S acpica-unix on armel.  Thanks!
<slangasek> tjaalton: correct - there's no action implemented for XF86Wlan, AFAIK :-)
<slangasek> hmm, we did discuss that hal should be listening for this rather than current X, didn't we
<slangasek> so actually, we can revert that one, can't we
<tjaalton> slangasek: right, some keys are best handled elsewhere
<raylu> what does does it mean for a bug to be triaged?
<raylu> is it determined to be of high or low importance?
<ScottK-laptop> raylu: No, it means that it has enough information for a developer to work on fixing it.
<ScottK-laptop> raylu: https://wiki.ubuntu.com/Bugs/Status
<raylu> ScottK-laptop: thanks
<raylu> how are all the files for these two bugs generated?
<raylu> https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/270271
<ubottu> Launchpad bug 270271 in evolution "evolution crashed with SIGSEGV in g_signal_emit_valist()" [Medium,Fix committed]
<raylu> https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/247480
<ubottu> Launchpad bug 247480 in evolution "evolution crashed with SIGSEGV in e_cal_menu_target_new_select()" [Medium,Confirmed]
<raylu> i'm getting something similar and i'm about to report it, but i'm wondering where all those other files came from
<andersk> Those reports were generated automatically using apport.
<andersk> https://wiki.ubuntu.com/Apport
<raylu> ah, impressive
<ebroder> Any backporters who could ACK 301283 or 305001 ?
<ebroder> Oh, fine. LP #301283 or LP #305001
<ubottu> Launchpad bug 301283 in hardy-backports "Please backport schroot 1.2.0-1 from Intrepid to Hardy" [Undecided,New] https://launchpad.net/bugs/301283
<ubottu> Launchpad bug 305001 in hardy-backports "Please backport sqlalchemy 0.4.8 from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/305001
<ebroder> There we go
<alkisg> Hello... If I run setupcon on tty1, the console fonts display fine. If I switch to tty2 and then back to tty1, the fonts are broken. Could this be due to nvidia proprietary driver not saving/restoring correctly the vga state in my laptop? Where can I report this?
<alkisg> And another, similar one: while installing Ubuntu (any version so far), if I select Greek language anywhere, I get the "Uni1" font in /etc/default/console-setup, which doesn't containt Greek characters. It should be either Uni2 or Greek. Should I report this under console-setup, or under the installer?
<mr_pouit> directhex: xfce4 uploads still need to be ordered.
<leszek> hi
<leszek> where can I set the name of the automatic ubuntu grub installation entry in the menu.lst on the livecd. So that it shows something different in the autoinstalled grub after installation ? Is there a config file for it somewhere ?
<stewski> has anyone come across a bug where gvfs endlessly asks for passwords when connecting to a samba share
<gaspa> vorian: lemonpos has a conflicting manpage with another package (squeeze). (I asked you as seems you wrote the manpage)
<gaspa> what do you think it's better? renaming the manpage could be enough?
<vorian> gaspa: let me look at iy when i get home
<gaspa> vorian: ok. ;)
<ebroder> What's the next step on trying to get an SRU for LP #216761?
<ubottu> Launchpad bug 216761 in xen-3.2 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761
<ebroder> Someone commented that it should be assigned to the maintainer, but the maintainer of xen-utils-3.2 is "Ubuntu Core Developers"
<ebroder> And the SRU wiki page says that the fix should be in the dev release, but the xen-utils-3.2 package dead-ended in Hardy
<ebroder> Do I need to get the fix into xen-utils-3.3 before I can get it into -3.2?
<pochu> ebroder: it needs to be fixed in Jaunty first, then it can be fixed in the stable releases
<pochu> ebroder: also note that those packages are in main, so you should subscribe ubuntu-sru instead of motu-sru
<ebroder> pochu: But xen-utils-3.2 isn't in Jaunty
<pochu> ebroder: oh, true
<ebroder> And xen-utils-3.2 is in universe...
<pochu> but the source is in main, so it's up to ubuntu-sru
<ebroder> Oh, huh. Ok
<pochu> ebroder: so I'd say, fix it in jaunty for xen-3.3 (in case it needs fixing), then go for the stable releases
<ebroder> Is it useful for me to upload a debdiff that's the attached patch + a changelog entry?
<pochu> sure thing
<pochu> ebroder: if you do so, subscribe ubuntu-main-sponsors too
<ebroder> Ok
<pochu> !sponsorship
<ubottu> Sorry, I don't know anything about sponsorship
<pochu> https://wiki.ubuntu.com/SponsorshipProcess
<pochu> which basically says you need to attach patches in launchpad and subscribe ubuntu-{main,universe}-sponsors as appropriate
<mohbana> why was the font viewer removed from ubuntu 8.10?
#ubuntu-devel 2008-12-14
<nesys> Hi folks,
<nesys> I found on kubuntu 8.10 the same bug as https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/278318
<ubottu> Launchpad bug 278318 in xserver-xorg-video-intel "video tearing with textured video on intel card" [High,Fix committed]
<nesys> I've tryed to apply patches and new configs, but the problem is unsolved
<nesys> with vlc, or mplayer, or another player, when I see a DVD I have every 10 secs a video freeze (audio is ok), and the vlc debug says 'late picture skipped'
<nesys> any advice will be appreciated :)
<gbear14275> can anyone tell me what types of changes are made to programs before they go to package releases?  I'm just curious what types of changes the azureus people are claiming the ubuntu side does that makes them unable to support azureus on ubuntu?
<gbear14275> not looking for details, just generalities and was curious if this was a common thing with all ubuntu program developers
<jdong> gbear14275: sigh I can't believe this is coming up again....
<jdong> gbear14275: azureus has a serious security vulnerability where local users are allowed to do whatever the hell they want to any instance of azureus running on your system.
<jdong> this is a huge problem if you share your computer with multiple users, because I can stop your torrents or even delete them without your authorization.
<jdong> we applied a patch that reserves a range of ports for private communications
<jdong> upstream doesn't think this is a security problem and doesn't like this patch
<jdong> *shrug* I'm pretty tired of arguing with azureus upstream about this stuff.
<jdong> they also claim they need to bundle their own SWT GTK libraries rather than using the system ones
<jdong> in general, upstreams tend to be able to come up with better reasons for doing thins like this other than, and I quote, "you are a fucking idiot"
<jdong> hopefully that answers your question :)
<raylu> o.0
<jdong> whee good upstream relations!
<jdong> I suppose I shouldn't tell them I plan on stripping the Azureus core from the Vuze UI and combine the 2.5.x.x UI with the new core....
<jdong> (shhhhhhh THAT'S OUR LITTLE SECRET)
<gbear14275> jdong, wasn't questioning the ubuntu actions was just curious if I was standard or not... I trust the ubuntu devs more than the azureus guys, but thank you for the explanation again jdong
<gbear14275> I appreciate it
<alex_21> I used apt-get source for apt-get source libwebkit-1.0-1"  and it returned an unable to find source package error. What can I do?
<alex_21> Hi, I downloaded the source for webkit from the Ubuntu Repository, and untared the tar.gz. Now I ahve a .orig file. Am I doing something wrong. I jsut want to make a change to main.c in the GTKLauncher source that comes in the Webkit source that is on Webkit's site
<LaserJock> alex_21: what file did you download? just the .orig.tar.gz file?
<LaserJock> apt-get source libwebkit should work, btw
<LaserJock> actually, scratch that
<LaserJock> apt-get source libwebkit-1.0-1 works here
<alex_21> All thesource
<alex_21> qith apt-get source
<alex_21> And I am on Hardy, not II
<alex_21> And actually, I want to modify main.c in the GTKLauncher in the Webkit site's source
<LaserJock> alex_21: if you've downloaded the whole source package then there should be an unpacked source tree there
<LaserJock> if not run dpkg-source -x *.dsc
<alex_21> All I see is a .orig file
<LaserJock> alex_21: then you must not have gotten the whole thing
<LaserJock> alex_21: there should be a .orig.tar.gz file, a .dsc file, and a .diff.gz file
<LaserJock> alex_21: are you sure it's a file? it could be a directory if you untarred it
<alex_21> Yes it is a directory
<alex_21> Where is the source int question though. In this .orig directory?
<LaserJock> alex_21: well, let me ask this, what are you wanting to do in the end?
<LaserJock> alex_21: are you wanting to build a new .deb or just wanting to play around with the source or?
<alex_21> If you download the source from the Webkit site, there is a GTKLauncher browser they include under WebkitTools directory. I wan't to edit the main.c file for that and repackage it. However if this package can do it, I would love to use it instead
<alex_21> I mean, all the .deb stuff is done here
<alex_21> I eman the Ubuntu package. If it can be modified like the main.c file can, then I am good to go
<alex_21> Is this what you wanted to know?
<NCommander> hola world
<alex_21> Hola
<innovati> Â¡hola!
<alex_21> ?Hola?
<innovati> Â¿que?
<alex_21> ?Porque estas aki?
<alex_21> Lol
<innovati> me gusta Ubuntu
<alex_21> Esaba Vromiando
<alex_21> Lol
<alex_21> A mi tambien
<LaserJock> alex_21: sorry, got distracted, if you want a .deb in the end you need to get the 3 files I mentioned (.orig.tar.gz, .dsc, .diff.gz)
<LaserJock> alex_21: once you do that run dpkg-source -x *.dsc and it should unpack it all
<alex_21> Unpack it to where?
<alex_21> And is this the normal source
<LaserJock> alex_21: in the current directory
<alex_21> I modified line 100 and something in the code from Webkit, and need to duplicate this feet
<LaserJock> alex_21: the .orig.tar.gz file is the source tarball like what you'd get from the website
<alex_21> Oh, Ok
<LaserJock> alex_21: the .diff.gz is a diff to that that holds all the Debian/Ubuntu changes
<alex_21> Cool, thanks
<LaserJock> alex_21: I'd suggest talking to #ubuntu-motu if you have more questions on packaging and how to get a .deb
<alex_21> So to make this mod, I can drop the main.c file into the folder and then zip it up and repackage it and it should work?
<LaserJock> you don't need to zip it up, we have tools for handling all that
<LaserJock> https://wiki.ubuntu.com/PackagingGuide has lots of info on that type of thing
<alex_21> Yeah, but the wiki is huge and my screen reader will take ages to read that
<LaserJock> alex_21: short story is: make changes, apt-get builddep webkit, run debuild -us -uc in the source tree (make sure devscripts is installed)
<alex_21> Ok, thanks
<alex_21> So the .dif file takes care of all the changes?
<alex_21> .Diff?
<alex_21> And can I just put info from the new source that I got from the site into the .orig directory?
<alex_21> Essentially replacing the current source
<LaserJock> no
<LaserJock> you shouldn't have a .orig folder
<alex_21> No to which?
<LaserJock> your changes will show up in a new .diff.gz file
<alex_21> Well it is webkit--something.orig and is a directory
<LaserJock> is the .diff.gz and .orig.tar.gz files still there?
<alex_21> But this new .diff file will be created for me?
<LaserJock> yes
<alex_21> Yes, they are still there
<LaserJock> then remove the .orgig directory
<LaserJock> and run dpkg-source -x *.dsc
<alex_21> Why remove it, because that is where all my changes are
<LaserJock> hmm
<LaserJock> then move it to something like webkit-tmp
<alex_21> I haven't ziped it up again yet, I just untarred it, and am making changes to it
<LaserJock> that's ok
<alex_21> So I am confused, should I, ... what?
<LaserJock> mv the directory to webkit-tmp and run dpkg-source -x *.dsc
<alex_21> I want to make a .deb package out of the source I just edited
<LaserJock> I know
<alex_21> Oh, in the webkit-name directory?
<alex_21> Webkittmp
<LaserJock> but I'm unsure that the source package is properly unpacked
<alex_21> I can see all the source files, so is it unpacked?
<LaserJock> do you have a new directory?
<LaserJock> make sure that there is a debian/ directory within webkit directory
<LaserJock> bah, I gotta run for a bit
<LaserJock> ask in #ubuntu-motu if you get stuck
<alex_21> I moved it
<alex_21> Ok
<kobazik> can anyone provide me with details how the Ubuntu nightly build is being created? and howto to automate building a whole system from src.deb
<philsf> there's a (minor) issue with an archive mirror, who can I get in touch with about it?
<n1lo> How can I update to ubuntu unstable or testing?
<n1lo> ?
<Nafallo> n1lo: user support in #ubuntu
<Nafallo> n1lo: for short, you cant, cause they do not exist.
<n1lo> how can I use a unstable packages?
<Nafallo> n1lo: #ubuntu please
<n1lo> Nafallo, Ok.
<calc> anyone around that knows in detail about ppas? I have a ppa for openoffice-pkgs that i deleted some packages from but the orig.tar.gz are still there
<calc> eg http://ppa.launchpad.net/openoffice-pkgs/ubuntu/pool/main/o/openoffice.org/openoffice.org_3.0.0~rc2.orig.tar.gz and http://ppa.launchpad.net/openoffice-pkgs/ubuntu/pool/main/o/openoffice.org/openoffice.org_3.0.0~rc4.orig.tar.gz
<Nafallo> sounds like a soyuz (#launchpad) query to me :-)
<calc> ok
<Luke> i'm trying to make a deb of a C program which doesn't specify an install target. What is the correct way to handle this?
<pochu> calc: afaik they take some time to be removed
<DRebellion> Luke, probably a question for #ubuntu-motu . If the program hasn't got an install target, it's probably trivial to install the files yourself in rules.
<calc> pochu: several months?
<Luke> DRebellion: so I can just move the binaries in place pretty much
<DRebellion> Luke, yep.
<Luke> right - thanks
<pochu> calc: one hour or two I think, but it may have changed
<philsf> there's a (minor) issue with an archive mirror, who can I get in touch with about it?
<calc> pochu: well its definitely not working after just a few hours
<calc> pochu: the rc uploads were deleted at least several weeks ago (longer than that iirc)
<Jimi__Hendrix> are you guys the devs or am i in the wrong place?
<Jimi__Hendrix> because i have a question about what goes on in between releases
<calc> Jimi__Hendrix: yea we are developers, or at least some of us are :)
<Jimi__Hendrix> ok so im thinking of making my own distro (i know its a lot of work...but thats not the point) i want to know what happens between releases of ubuntu
<Jimi__Hendrix> what do you guys do between 8.04 and 8.10 and jaunty...
<calc> er package things, fix bugs, develop new code, etc
<calc> lots of things
<Jimi__Hendrix> so basically if new open office comes out
<Jimi__Hendrix> you put that in by default?
<pochu> calc: no idea then, I suggest you ask on the launchpad-users ML
<lubosz> hi
<lubosz> what hapened to this in intrepid? http://packages.ubuntu.com/hardy/atlas3-base
<lubosz> i have a .deb for hardy depending on that
<lubosz> and what to install it in intrepid, there is no intrepid specific release
<calc> pochu: ok
<calc> Jimi__Hendrix: if it comes out before Feature Freeze yes
<calc> Jimi__Hendrix: in the past we tried to cram it in regardless but that led to problems, so we stick to Feature Freeze now :)
<lubosz> is this the same as libatlas3gf-base in intrepid?
<Jimi__Hendrix> and bug fix/code wise...if theres a bug in program x that you guys find and have time do you try and edit the source...and would this mean that the kernel i install with ubuntu is different than the one i get with fedora?
<calc> Jimi__Hendrix: yes it is different, every major distro changes the kernel around
<calc> aiui kernel.org doesn't even recommend using their kernels but to use distro kernels instead
<calc> or at least they recommended doing that at one point
<jdong> linus believes so.
<Jimi__Hendrix> and what do you do to the kernel...lets say i get the source for the ubuntu kernel...and compile it...would it work with the distro i build?
<calc> the difference between a kernel.org kernel and a distro kernel is generally bug fixes, sometimes they add extra features as well
<calc> so it should generally work unless your own distro requires other kernel features that would need to be added
<Chipzz> the kernel version does have some influence on the version of glibc you want to ship though
<Jimi__Hendrix> ok 2 more questions i think...
<Jimi__Hendrix> 1...what would an example of a kernel version be...and 2 assuming i have all the time i need...could i make a distro using just the information provided in the LFS book tree?
<Jimi__Hendrix> no one?
<calc> Jimi__Hendrix: i doubt LFS gives you enough info to create a full distro
<calc> Jimi__Hendrix: the last time i looked at it (~ 5 years ago) it was outside of the scope of what they even tried to explain
<Jimi__Hendrix> well what dont they explain?
<calc> Jimi__Hendrix: well back then they only explained how to compile apps for your own system, nothing about packaging at all for example
<Jimi__Hendrix> well i would use apt and .debs because of their popularity
<calc> Jimi__Hendrix: to learn how to package you probably should read the ubuntu wiki and debian doc section
<calc> there is quite a lot to learn about
<calc> the rules file for openoffice.org for example is ~ 150K and nearly 4K lines long
<NCommander> o_o;
<Jimi__Hendrix> ok calc
<Chipzz> calc: whut? :)
<calc> Chipzz: its a bit on the large side
<Chipzz> no shit :)
<Chipzz> 4K LOC, OMG :)
<Chipzz> and heh, a sentence in all caps that actually made sense :)
<Jimi__Hendrix> calc, so if i really want my own distro...where should i go to look that up?
<Jimi__Hendrix> calc, so if i really want my own distro...where should i go to look up how to make it?
<Jimi__Hendrix> i ment
<NCommander> StevenK, you around?
<calc> Jimi__Hendrix: you probably need to start off by working with a current distro so you understand how they actually work
 * calc has to go, bbl
<calc> Jimi__Hendrix: if you want to just make a different version of *buntu that isn't that hard, but to make your own distro entirely you will need a lot more than just one person to do it
<calc> Jimi__Hendrix: eg Debian has ~ 150 active members and 1000+ total members (iirc)
<calc> Jimi__Hendrix: ubuntu and fedora have similiar numbers of developers
<Jimi__Hendrix> calc, well i would use what others have...just mash it together for the most part and make my own installer...
<calc> Jimi__Hendrix: hehe, making your own installer would be pretty much a full time job in itself
<calc> Jimi__Hendrix: its taken years of work to get the ubuntu installer the way it is
<Jimi__Hendrix> rofl
<Jimi__Hendrix> id settle with one like arch...with the blue screen...
<greg-g> Jimi__Hendrix: it isn't just what it looks like
<Jimi__Hendrix> well what does the installer actually...do
<calc> Jimi__Hendrix: a LOT
 * calc imagines the ubuntu installer is at least many tens of thousands of lines of code if not more
 * Jimi__Hendrix likes open source for a reason
<Jimi__Hendrix> ok well if you suggest i help an existing distro how would i do that...i know C++, some C, and a decent amount of python...
<calc> Jimi__Hendrix: determine what you are actually interested in doing then help in that area
<calc> if you want to help with the installer for ubuntu for example look though the ubiquity bugs and see if there is anything you can fix, etc
<Jimi__Hendrix> learning about how a distro works so i can make my own
<Jimi__Hendrix> ahh
<Jimi__Hendrix> ok
<Jimi__Hendrix> and what do i do if i fix one?
<calc> create a patch and attach it to the bug in launchpad
<Jimi__Hendrix> ok cool
<Jimi__Hendrix> one more thing...i think...for now...maybe
<Jimi__Hendrix> is there a way to test the installer without reinstalling a bunch of times on a computer...lol
<RainCT> Jimi__Hendrix: virtual machine?
 * Jimi__Hendrix shrugs
<crimsun> johanbr: RE 275998, pulseaudio-related but not the sole culprit
<johanbr> crimsun: I see. Thank you for looking into that.
<johanbr> Is it easily fixable?
<crimsun> johanbr: I need to read the attachments RSN to answer that ;)
<johanbr> ahh :)
<Chipzz> 22:29 < Jimi__Hendrix> calc, so if i really want my own distro...where should i go to look up how to make it?
<Jimi__Hendrix> yes?
<Chipzz> if you're asking this question, the answer simply is "don't"
<ion_> :-)
<Chipzz> if you're capable enough to make your own distro, you should know how to figure these things out by yourself
<Jimi__Hendrix> ok so all the people at cannical had this information when they were born?
<directhex> yes
<ion_> yep
<Chipzz> if you don't know how to figure out these things on your own, you are not capable enough and shouldn't bother
<directhex> or they learnt their craft when tinkering with debian, using published documentation
<directhex> which is the same thing, sorta
<Chipzz> or they used google
<directhex> Chipzz, or msn live search!
<Chipzz> directhex: now now, no need to be rude ;)
<Jimi__Hendrix> google returns LFS
<Jimi__Hendrix> ibm says lfs
<directhex> LFS is if you *really* want to do, well, from scratch
<Chipzz> Jimi__Hendrix: why do you want to make your own distro in the first place? What added value do you think it has to the opensource community at large (hint: I think it actually subtracts rather than adds to the opensourc community; every new distro causes more fragmentation which is not something we need IMO)
<Jimi__Hendrix> Chipzz, school project on anything...and lfs makes this sound doable...unless lfs does not result in a new distro
<Jimi__Hendrix> afk but feel free to reply...io will read it eventually
<Chipzz> school project? :P
<Chipzz> anyway you probably should be looking at LFS then, but more as a "bootstrapping linux" experiment
<Chipzz> I wouldn't go for a whole new distribution
<directhex> custom debian/ubuntu? that's achievable
<Chipzz> I don't know how much time you're supposed to be spending on this project, but I'm guessing that just the bootstrapping would fill your assigned time :)
<Dyresen> If you just want to learn stuff, run slackware for a couple of years.
<Chipzz> never tried LFS, but I think LFS would be a better way to learn things
<Chipzz> provided you don't just copy/paste all the commands
<directhex> Chipzz, remember, gentoo teaches you linux - nothing says "contributing to free software" like watching lots of 'make' output scroll past
<Dyresen> directhex: I don't agree. If you run gentoo for a couple of years you know more linux than most people.
<Dyresen> directhex: running gentoo will force you to read documentation and do a lot of editing in config files.
<directhex> quantity, not quality
<Dyresen> Then you are allready miles past most of the people asking for help in the ubuntu channel.
<Dyresen> anyway, Im hit by a ubuntu packaging bug (as far as I can see, and I know quite a few people are)
<Dyresen> https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/296605
<ubottu> Launchpad bug 296605 in puppet "puppetmasterd crash at startup!" [Undecided,Confirmed]
<Dyresen> Can some one doing ruby/rails/puppet packaging look into it?
#ubuntu-devel 2009-12-07
<robert_ancell_> how do I get a build to restart?  I updated file-roller a few days ago and it failed to build due to libgtk being broken at the time (https://edge.launchpad.net/ubuntu/+source/file-roller/2.29.2-0ubuntu1)
<RAOF> robert_ancell: Does https://edge.launchpad.net/ubuntu/+source/file-roller/2.29.2-0ubuntu1/+build/1378313 have a "rebuild" button for you?  I think that's where it'd be (I don't have main priviledges, so I can't see it)
<robert_ancell> RAOF, no it doesn't for me.  I only have MOTU privileges but I don't have a rebuild option for Universe packages either
<ScottK> robert_ancell: Is it just amd64 or all archs you want done?
<robert_ancell> ScottK: all arches for this one.  I also did an xscreensaver one a while back that needs rebuilding for ia64 and sparc
<ScottK> robert_ancell: file-roller retried on all archs
<robert_ancell> ScottK, thanks.  This seems to happen quite a lot - do I just ping someone with main privileges when it occurs?
<ScottK> Yep.
<Amaranth> weird, robert_ancell should be able to trigger a rebuild of file-roller
<Amaranth> since he has ubuntu-desktop access
<Amaranth> I can trigger rebuilds of compiz, anyway
<Amaranth> maybe the extra layer of indirection screws it up
<robert_ancell> Amaranth, how do you trigger them?
<Amaranth> robert_ancell: iirc from the build page, let me check the armel failed build to be sure
<robert_ancell> Amaranth, they've all failed build but at least now I can see the problem
<Amaranth> robert_ancell: on https://edge.launchpad.net/ubuntu/+source/compiz/1:0.8.4-0ubuntu6/+build/1379618 I have a "Retry this build" option
<robert_ancell> Amaranth, I don't
<Amaranth> is compiz in the ubuntu-desktop set? it should be but you never know
<robert_ancell> Amaranth, not sure but file-roller definitely is (I did the upload directly)
 * Amaranth looks for something in universe that failed to build
<jmarsden> Amaranth: Yes, you can do   tasksel --task-packages ubuntu-desktop | grep compiz     # to check
<micahg> is there a place where I can see the list of stuff waiting to be approved for -proposed?
<Amaranth> jmarsden: Is that the same data launchpad uses for permissions?
<jmarsden> Amaranth: I have no idea :)  As a user/sysadmin, it is how I check what is in the various task bundles...
<robert_ancell> Amaranth, can you see a rebuild option here: https://edge.launchpad.net/ubuntu/+source/xscreensaver/5.10-3ubuntu1/+build/1375403
<Amaranth> no
<Amaranth> did ScottK already trigger a rebuild for that though?
<ajmitch> no
<ajmitch> it shows up for me
<Amaranth> oh, it's in main
<ScottK> Amaranth: No, I just did file-roller
<ajmitch> (since I'm in core-dev)
<Amaranth> I only have compiz and MOTU access :)
<ajmitch> maybe you can retry compiz builds because of direct permissions to upload it
<Amaranth> right
<micahg> ScottK: is there a place where I can see the list of stuff waiting to be approved for -proposed?
<Amaranth> but motu access is based on teams too so it's a bug caused by robert_ancell only having access via a team you'd think it'd be broken there too
<Amaranth> so if it's*
<robert_ancell> Amaranth, how come you see them for compiz?
<ajmitch> motu access is based on the component, I think the packe sets are overlaid on that
<Amaranth> robert_ancell: I have direct compiz upload permissions
<ajmitch> it's all confusing :)
<Amaranth> ok, so it most likely is a bug caused by robert_ancell only having access via a team
<ajmitch> possibly
<robert_ancell> ajmitch, totally :)
<ajmitch> file a bug about it :)
 * Amaranth points to robert_ancell
<robert_ancell> anyone know what to file against?  LP?
<ScottK> micahg: launchpad.net/ubuntu/[release] and click on uploads and look at unapproved
<ajmitch> either LP or against soyuz, I think
<micahg> ok, ScottK, thanks :)
<slytherin> anyone who maintains linux-ports-meta package? We need a version bump for this package in karmic-security.
<evolio_> hi guys
<evolio_> is there a reason why no vpn clients are shipped by default in ubuntu?
<evolio_> for networkmanager
<crypt-0> no idea
<crypt-0> the devs seem to be asleep
<RAOF> evolio_: The immediate answer is: there aren't any network manager vpn clients in main.
<RAOF> A fuller answer will include: they're not in main because no one has asked for (and done the security/code maintenance/upstream health check/etc) them to be in main.
<crypt-0> still no update for jre in 9.10
<crypt-0> stuck at 1.6.16
<crypt-0> hardy has had 1.6.17 for  almost a week now
<slangasek> james_w: I have an awesome failure mode for bzr merge-package w/ brltty
<dholbach> good morning
<siretart`> slangasek: teaching upstream symbol versioning is both fun and exhausting :-)
<pitti> Good morning
<crypt-0> good night.
 * crypt-0 is waiting for cryptsetup 1.10 to be finalized, its still at RC3
<crypt-0> then a suspend could ask for the passphrase/keyfile
<crypt-0> and SHA1 hashes will be no more, any supported by libgcrypt (SHA2, and Whirlpool sound nice)
<pitti> james_w: the python-launchpadlib packaging bzr branch is horribly out of date; I'll just redo it from scratch and import the current packaging, branching from upstream; hope you don't mind?
<pitti> (it was also missing files from upstream)
<micahg> mdke: ping
<mdke> micahg: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<micahg> mdke: nevermind
<slytherin> What does it take to bump version for linux-ports-meta package so that it depends on latest version form karmic-security?
<tseliot> cjwatson: where do you deal with "safe mode" (i.e. vesa) in ubiquity?
<tseliot> I mean, the boot option
<cjwatson> ogra: I didn't touch them
<cjwatson> slytherin: it's all calculated from the changelog version
<cjwatson> tseliot: I'm not sure we do at the moment, but we need to
<slytherin> cjwatson: So someone will have to bump the version for ports-meta right?
<cjwatson> tseliot: actually, is "safe mode" still needed? can we use bullet-proof-x instead? we have a spec that calls for that ...
<cjwatson> slytherin: yes
<slytherin> cjwatson: TheMuso usually bumps the version for ports-meta. But he is not around. Any idea who is the best person?
<slytherin> I mean 'next best person'.
<tseliot> cjwatson: we were discussing the use case in which you need to pass vesa and nomodeset. Bullet-proof-x wouldn't work in this case
<cjwatson> tseliot: but we don't pass nomodeset anywhere right now?
<tseliot> cjwatson: right but we might need to
<tseliot> cjwatson: otherwise vesa may fail
<cjwatson> hm, ok. will need to update foundations-lucid-gfxboot-updates for that
<tseliot> cjwatson: thanks
<ogra> cjwatson, armel squashfs builds currently die with:
<ogra> Can't find a SQUASHFS superblock on livecd.ubuntu-imx51.squashfs
<ogra> Failed to read existing filesystem - will not overwrite - ABORTING!
<ogra> cjwatson, any objection to me adding a rm before the mksquashfs call so we make sure there is no existing squashfs around ?
<ogra> (in livecd-rootfs)
<cjwatson> ogra: fine by me
 * ogra wonders if there is a reson that we dont have that yet
<ogra> great :)
<cjwatson> (rm -f, please)
<ogra> indeed :)
<tseliot> cjwatson: I'm forwarding you the email in which we're discussing the safe mode thing
<lool> When is meta-release usually updated to list the new devel release?
<lool> after A1 or before A1?
<lool> Hmm I see lucid in -development
<lucas> I'd like to ask for the removal of some packages (~100) that are not in debian, have not been updated in ubuntu since hardy, and have a low popcon. What would be the best way to give the list of those packages? 1 LP bug/package sounds suboptimal
<lool> lucas: main + universe?
<lool> lucas: Perhaps you should send a list of candidates to ubuntu-devel?
<lucas> universe+multiverse, as a first step
<ogra> ++
<lool> or -motu if you start with -universe+-multiverse
<lucas> ok, will do that
<pitti> eww, macaroni (ddebs.u.c.) ran out of space
 * pitti kills intrepid
<ogra> The following packages have unmet dependencies:
<ogra>   python-wadllib: Depends: python-lazr.uri but it is not installable
<ogra> E: Broken packages
<ogra> GRMPF ...
<pitti> hm, they all have replaces/conflicts
<ogra> mind the dot
<pitti> yeah, they were renamed in Debian unfortunately
<ogra> looks like a typo on first sight
<pitti> no, that was intentional (although not exactly clever)
<ogra> i didnt know dots in package names are even allowed
<pitti> but it should remove lazr-uri and install lazr.uri
<lool> ogra: openoffice.org
<ogra> lool, oh, right
<ogra> ogra@osiris:~$ apt-cache madison python-lazr.uri
<ogra>   lazr.uri |    1.0.2-1 | http://de.archive.ubuntu.com lucid/main Sources
<ogra> ogra@osiris:~$
<ogra> hmm, there doesnt seem to be a binary at least my machine thinks so
<pitti> ogra: ah, so perhaps you just need to wait a little until the mirror synced up
<ogra> hmm, k
<pitti> some two hours ago I uploaded a new p-launchpadlib and ubuntu-dev-tools to finish the migration
<ogra> ok, i just tried a local livefs build ... so i'll wait
<ogra> hmm, but LP says python-lazr.uri built two days ago already
<ogra> ogra@osiris:~$ LANG=C apt-cache show python-lazr.uri
<ogra> W: Unable to locate package python-lazr.uri
<ogra> E: No packages found
<ogra> according to https://launchpad.net/ubuntu/+source/lazr.uri/1.0.2-1/+build/1379851 python-lazr.uri_1.0.2-1_all.deb should exist though
<pitti> oh, hang on
<pitti>         500 http://archive.ubuntu.com lucid/universe Packages
<ogra> http://archive.ubuntu.com/ubuntu/pool/main/l/lazr.uri/ disagrees
<ogra> aha !
<pitti> someone NEWed it to universe
 * pitti promotes
<ogra> thanks !
<pitti> with restfulclient
<pitti> done
<cjwatson> I dumped it into universe largely automatically since it was a sync from Debian
<pitti> StevenK: haha! yada wants to go back to main, thanks to libapache2-mod-auth-pam
 * soren shudders
<geser> ScottK: does your ACK to bug 490731 imply that I can proceed with upload?
<ubottu> Launchpad bug 490731 in distribute "python-setuptools: import setuptools returns ValueError: ("Missing 'Version:' ...)" [Undecided,New] https://launchpad.net/bugs/490731
<StevenK> pitti: Yeah, I've been working on it.
<ScottK> geser: Yes.
<ttx> cjwatson: At this point it's expected that the NC installer can't find the preseed file from the CC, right ?
<cjwatson> ttx: hmm, no?
<ttx> hm
<cjwatson> I did rename it but I thought I put it all the necessary aliases
<cjwatson> s/put it/put in/
<cjwatson> and indeed the NC tries the old name as well
<ttx> cjwatson: I installed a Lucid alpha1 CLC+CC+Walrus+SC and tried to install an NC
<ttx> cjwatson: it doesn't seem to get a preseed file. When I tried the 9.10 NC installer, euca_find_cluster doesn't find anything
<cjwatson> anything useful in logs?
<ttx> cjwatson: I'll retry now that I know it /should/ be working
<ttx> with the 9.10 installer, euca_find_cluster doesn't return an IP address
 * ttx tries again
<pitti> cjwatson: do you have any objections/gotchas wrt. bug 493139? if not, I'm happy to do the change in bzr now
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/493139)
<apw> mvo, do we have update-manager -d to lucid yet?
<mvo> apw: not quite yet, but I want to enable it today
<apw> that'd explain why it doesn't work then, ok, by hand it is
<ogra> pitti, hrm
<ogra> The following packages have unmet dependencies:
<ogra>   python-lazr.uri: Conflicts: python-lazr-uri (< 1.0.2-1) but 1.0-0ubuntu1 is to be installed
<ogra> E: Broken packages
<ogra> thats what i get now
<cjwatson> pitti: ym "decreases boot speed" or "increases boot time" in that bug, I think ;-)
<ogra> so there is still something out of sync
<ttx> cjwatson: ignore me. The CC publication was borked, probably due to bug 493523 preventing it to start on first boot. Now that it's rebooted, it is detected correctly
<ubottu> Launchpad bug 493523 in eucalyptus "[lucid] Eucalyptus-cc fails to start, missing axis2 apache module" [High,Fix committed] https://launchpad.net/bugs/493523
<cjwatson> pitti: fine by me, go ahead and commit
<mvo> apw: if you wait a little bit I fix it and you can test?
<pitti> cjwatson: erm, yes :)
<cjwatson> ttx: oh good
<apw> mvo how long?
<ttx> cjwatson: NC install is still failing due to bug 493582, but that's an easy fix
<ubottu> Launchpad bug 493582 in libvirt "[lucid] libvirt-bin fails to install (sed: can't read /etc/apparmor.d/usr.bin.virt-aa-helper)" [High,Triaged] https://launchpad.net/bugs/493582
<mvo> apw: now
<mvo> apw: :)
<apw> ok that works as i want to test something on lucid today
<mvo> apw: ok, its just a server side thing, I have karmic->lucid enabled now (for update-manager -d or do-release-upgrade -d)
<mvo> apw: please let me know if it works (and how well)
<apw> well it appears, that is a start
 * apw hits it
<apw> mvo, its not eaten my machine yet, which is something
<apw> mvo 752 packages to download, so its doing something
<mvo> good, good :)
<cjwatson> jdstrand: see my comment on bug 493582 for a simpler proposed implementation
<ubottu> Launchpad bug 493582 in libvirt "[lucid] libvirt-bin fails to install (sed: can't read /etc/apparmor.d/usr.bin.virt-aa-helper)" [High,Triaged] https://launchpad.net/bugs/493582
<cjwatson> ttx: how would I go about exposing a preseed file on a machine running only a CLC?
<cjwatson> ttx: a CLC-only machine doesn't seem to run apache, at least as far as I can see
 * pitti pushes the 12th MB of ubiquity branch data to LP... I thought stacked branches would avoid that..
<cjwatson> you can just commit directly to ~ubuntu-core-dev/ubiquity/trunk you know?
<cjwatson> oh, no you can't
<cjwatson> it's ~ubuntu-installer
<pitti> right; I'll just submit a MP
<cjwatson> ok
<jdstrand> cjwatson: ack
<ttx> cjwatson: it should be running jetty, I'll have to look in more details how to make it serve a static file
<cjwatson> aha
<cjwatson> this is the last major thing blocking completion of foundations-lucid-uec-installer-enhancement :)
<pitti> cjwatson: just to avoid a1 damage, do you plan to merge console-setup for alpha-1?
<cjwatson> probably not - a2
<mdz> cjwatson: I noticed that grub still has last-good-boot cruft in it. would it be a good idea to strip that out for lucid?
<pitti> (currently uploaded xorg assumes that the keyboard layout is still in /etc/default/console-setup)_
<pitti> cjwatson: ok, thanks
<cjwatson> mdz: only grub 1, I think?
<mdz> cjwatson: oh, you may be right. I am still on grub 1 on this system as upgrading to grub2 failed
<cjwatson> mdz: I'm sure it wouldn't hurt, although I want to avoid caring about grub 1 as much as possible
<mdz> cjwatson: confirmed, it's only in grub 1
<mdz> (though it's left behind in conffiles on my grub2 systems)
<mdz> it should be inert in any case
 * cjwatson wades through incomprehensible XML configuration
<ttx> cjwatson: for the jetty thing ?
<cjwatson> ys
<cjwatson> yes
<ttx> cjwatson: we must be looking at the same page :)
<cjwatson> http://jetty.mortbay.org/apidocs/index.html is not really the sort of help interface I want for this kind of thing
<cjwatson> I have http://docs.codehaus.org/display/JETTY/Static+Content, but it doesn't help with serving just a single file
<ttx> cjwatson: it's probably a matter of dropping a modified http://docs.codehaus.org/display/JETTY/Static+Content snippet into /etc/eucalyptus/cloud.d/www/
<ttx> cjwatson: I'll test it locally
<cjwatson> I don't want to serve all of /etc/eucalyptus/ though, just one file
<ttx> cjwatson: right
<cjwatson> and symlinking would involve turning off alias detection which the help warns against
<ttx> cjwatson: does the preseed file *have to* be in /etc/eucalyptus to be served downstream ?
<ttx> cjwatson: I mean components could fetch it from CLC's /etc/eucalyptus/preseed directory and copy it to /etc/eucalyptus
<cjwatson> ttx: its filesystem location doesn't matter at all
<ttx> might end up having two copies on CLC+* setups
<cjwatson> let's not
<cjwatson> we should serve it from a single place
<cjwatson> I don't care where that place it
<cjwatson> is
<cjwatson> but there's no sane reason to have two copies
<cjwatson> Apache can Alias it from anywhere
<ttx> cjwatson: ok. I'll test a snippet as soon as I'm done with that alpha1 test
<cjwatson> ttx: I was actually hoping to get the CLC preseed file stuff into a1, indeed ;)
<ttx> cjwatson: sure, I just want to make sure i caught the biggest existing showstoppers first :)
<pitti> cjwatson: ah, it's finally uploaded (ugh); MP sent
<pitti> ogra: that's from a dist-upgrade?
<ogra> pitti, livefs testbuild
<pitti> ogra: anything which still depends on python-lazr-uri?
<ogra> i dont see python-launchpadlib
<ogra> the one you uploaded
 * pitti checks
<pitti> right, seems it's not built
<pitti> Missing build dependencies: python-lazr.restfulclient
<pitti> that would be because it was in universe
<pitti> now it's in main, so it should work now; rebuilding
<ogra> thanks
<pitti> ogra: thanks for pointing out; should be good in 2 hours
<ogra> :)
 * pitti NBS-removes the old package names
<fagan> mpt: in the software center in lucid I found a funny piece of text. "it is used by 1 piece of installed software" it seems like a very strange choice of words
<mpt> fagan, the text "it is used by" is not present anywhere in <https://wiki.ubuntu.com/SoftwareCenter>, so it's a bug one way or another :-)
<mpt> Most likely, it's something that isn't specified yet
<mpt> fagan, so please report it
<mpt> preferably with a screenshot
<fagan> cool I will
<mpt> thanks
<fagan> ill have a look for it and make a patch too if thats ok
<ttx> cjwatson: with http://pastebin.ubuntu.com/336616/ as /etc/eucalyptus/cloud.d/www/preseed.xml, it will serve https://CLC:8443/preseed/hello
<ttx> ...it will serve /etc/eucalyptus/preseed/hello when asked for https://CLC:8443/preseed/hello
<ScottK> cjwatson: We uploaded a new qt4-x11 over the weekend.  It still FTBFS on armel, but it's no longer an ICE.  The error now is /tmp/ccQlrjoC.s: Assembler messages: /tmp/ccQlrjoC.s:6402: Error: selected processor does not support `swp r6,r4,[r3]' - I was thinking it might be helpful to try the Thumb workaround you suggested/tried on the previous release again?
<cjwatson> ttx: ok, something like that should be workable. thanks!
<cjwatson> ScottK: yes, I think so, that sounds more like https://wiki.ubuntu.com/ARM/Thumb2
<ScottK> cjwatson: Would you be able to try this (no hardware here)?
<cjwatson> ScottK: ok
<ScottK> Thank you.
<fagan> mpt: Bug #493618
<ubottu> Launchpad bug 493618 in software-center "[lucid] "It is used by 1 piece of installed software."" [Undecided,New] https://launchpad.net/bugs/493618
<mpt> thanks fagan
<fagan> np
<ogra> Keybuk, did anyone check plymouth with std framebuffers (i.e. i'm intrested if its supposed to work on armel)
<Keybuk> ogra: I don't have the hardware
<ogra> well *should* it work with non KMS HW ?
<Keybuk> should do, yes
<ogra> ok
<Keybuk> it has a framebuffer backend
<Keybuk> if it doesn't, it should be easy to fix
<ogra> perfect, then it should just work
<Keybuk> I've only tested it with the vga16fb - and that required some porting of code from BOGL into it to make it work with the reduced colours
<LaserJock> ogra: where was lucas' list of possible archive removals sent?
<Keybuk> (not in the code I uploaded yet)
<ogra> yeah, i'll report back in case i see breakage
<ogra> LaserJock, -motu
<Keybuk> I've had it working with i915.modeset=0 as well
<ogra> we have full coulor support on the arm platforms we support
<ogra> (X runs in framebuffer too)
<ogra> so that shouldnt be an issue
<fagan> mpt: what else is planned for this cycle for the software center?
<mpt> fagan, <https://wiki.ubuntu.com/SoftwareHandling> has a "Work for Lucid" section that links to the various blueprints
<mpt> fagan, and the blueprints in turn link to the relevant sections of <https://wiki.ubuntu.com/SoftwareCenter>
<fagan> Cool I just want to have an idea so I can test the features as they land
<mpt> fagan, if you want to try implementing something small yourself, <https://wiki.ubuntu.com/SoftwareCenter#features>
<mpt> fagan, if you want to test and report bugs, you don't need to wait for new features to land -- there are plenty of unreported bugs in the existing features :-)
<fagan> :) true
<fagan> ill have a look and ping if I have any questions
<mpt> Many of the paragraphs in the specification have test cases
<mpt> I'll add more as I have time
<mpt> thanks for helping out!
 * fagan trys to find the dodgy string 
<ueu001> Will we have packagekit,devicekit,policykit in lucid ?
<fagan> mpt: It is used by %s piece of installed software."
<fagan> What would be better than that?
<mpt> fagan, first I need to know what it's there for
<mpt> Is it something to do with dependencies?
<fagan> yep
<fagan> for packages
<fagan> I think it should be "This package is used by...
<mpt> So does it mean "X other packages depend on this one?" (not saying that's a good replacement, just trying to understand it)
<fagan> It does
<fagan> There are also recommended and suggested strings too
<mpt> So if you click "Remove", you should get the alert shown here <https://wiki.ubuntu.com/SoftwareCenter#removing>
<mpt> Do you?
<fagan> nope is shows that in the info
<pitti> mbiebl, Keybuk: Debian's dbus installs the library into /lib now, but the daemon is still in /usr/bin/; does upstart need the daemon in /bin, too?
<fagan> I attached a screenshot to the bug of how it looks now
 * pitti isn't sure whether to keep our change for this
<Keybuk> pitti: no, doesn't need the Daemon
<Keybuk> though if Debian put it in /bin now, we don't *need* it in /usr
<mpt> fagan, ok, so it's a bug to report that that alert isn't implemented -- we can remove the need for it in the software item screen itself by showing the information inline, but not everyone will be on that screen when they choose to remove the item.
<pitti> Keybuk: other way round; we install the daemon into /bin so far, but Debian doesn't
<Keybuk> pitti: oh right
<pitti> Keybuk: Debian only moved the library to /lib, not the rest
<Keybuk> ah
<Keybuk> I remember
<Keybuk> things break if you have /usr-on-NFS if dbus isn't in /
<Keybuk> since you need D-Bus to get networking
<pitti> ah, alrighty
<pitti> will move it then
<pitti> but adapt our changes to use the debian configure flags, so that our delta gets smaller
<Keybuk> *nods*
<fagan> mpt: ah, so we should have some sort of alert that they are removing something that has a depends on that package
<fagan> But not of suggests or reccomends
<mpt> fagan, yes, i.e. the alert shown in step 5 in the spec
<mpt> fagan, Suggests and Recommends, I don't know
<mpt> Some collected examples of that situation might make that easier to design
<fagan> Well a program might suggest or reccomend a plugin but it doesnt affect the program if its not installed. So I dont think we need an alert for them
<ScottK> fagan: If it doesn't affect the program, it probably shouldn't be recommends.
<fagan> hmmm I always thought that recommends was just a slightly more important suggests
<ScottK> No, recommends should be installed except in unusual circumtances.  Suggests is pure nice to have.
<fagan> Oh
<fagan> So then maybe we should warn if a reccomended package is removed
<fagan> mpt: should we be using the word "package" or is that a term humans would have trouble with?
<mpt> fagan, see <https://wiki.ubuntu.com/SoftwareCenter#def-software-item> for why we don't refer to "packages" unless we're really sure that's what we mean
<mpt> fagan, having said that, it might make sense to use "package" in that specific case, because it's packages which are dependent, not software items
<fagan> mpt: thats what I was thinking
<fagan> (because we are refering to the packages themselves)
<fagan> I have a patch if you want to switch from "pieces of installed software" to "installed packages"
<fagan> mpt: ^ is that good?
 * fagan attaches it to the bug report
<mpt> fagan, changing it to "installed software packages" would be better than it is now. The next step would be thinking about whether it should list the dependent packages somewhere.
<cjwatson> ScottK: I'm afraid -Wa,-mimplicit-it=thumb makes no difference to the build failure on qobject.cpp
<fagan> mpt: Oh ill upload a patch for that then
<ScottK> cjwatson: OK.  Thanks for checking.  I guess I'll see if I can punt this back to NCommander then.
<mpt> thanks fagan
<cjwatson> ScottK: the assembler output indicates that the problem is in explicit asm on line 361 of src/corelib/arch/qatomic_arm.h
<cjwatson> ScottK: https://wiki.ubuntu.com/ARM/Thumb2 has advice for dealing with those
<ScottK> Thanks.
<fagan> mpt: the attachment .diff is on Bug #493618
<ubottu> Launchpad bug 493618 in software-center "[lucid] "It is used by 1 piece of installed software."" [Undecided,New] https://launchpad.net/bugs/493618
<mpt> thanks
<cjwatson> ScottK: I think possibly telling Qt to use armv6 not merely arm might help
<cjwatson> ScottK: trying that now ...
<ScottK> Excellent.  Thanks.
<ogra> cjwatson, or -marm
<pitti> ogra: p-launchpadlib is in now; should work now
<ogra> that will keep v7
<ogra> pitti, will try a build soon
<cjwatson> ogra: qt has explicit asm for armv6 which differs from arm
<cjwatson> ogra: I don't mean the gcc architecture
<ogra> ah
<cjwatson> ogra: the armv6 asm looks at least a bit closer to the recommendations in the wiki page
<ogra> i though you did :)
<ogra> yeah
<cjwatson> ScottK: I note that qt4-x11/debian/rules does not set DEB_HOST_ARCH nor DEB_HOST_ARCH_OS despite referring to them. I wonder what the difference between -platform linux-g++ and -platform glibc-g++ is?
<ScottK> Lex79: ^^^ didn't you do the qt4-x11 coordination with Debian?
<ScottK> We get that unmodified from Debian, so I'm not sure.
 * ScottK is asking the Debian maintainer.
<cjwatson> ScottK: well, I'll tell you next week or so whether it built or not ...
<ScottK> OK.
<ogra> heh
<Lex79> ScottK: the part of DEB_HOST_ARCH is a bit mess in that rules and I didn't understand what fabo has done, so I didn't touch it
<cjwatson> it's not that complicated, it's just wrong ;-)
<ScottK> Lex79: OK.  I asked him on #deiban-qt-kde.
<ogra> seb128, The following packages have unmet dependencies:
<ogra>   libgnomekbd4: Conflicts: libgnomekbdui4
<ogra> E: Broken packages
<ogra> getting that with a test livefs build
<seb128> and?
<ogra> libgnomekbdui4 doesnt seem to be built anymore at all
<seb128> ogra, right, that's on purpose, change coming from debian
<ogra> oh, you didnt upload gnome-c-c and gnome-applets yet, right ?
<seb128> ogra, libgnomekbd4 provides it
<seb128> not yet
<ogra> yeah, but there seem to be deps still
<ogra> which breaks my testbuilds
<ogra> i'll wait then
<seb128> weird that the provides doesn't work
<highvoltage> shew I read that horribly wrong the first time
<seb128> are you sure you picked the current version?
<ogra> livecd-rootfs just picks whats in the archive
<seb128> can you see what version it picked for your arch?
<ogra> root@babbage2:/# apt-cache showsrc libgnomekbd4|grep Version
<ogra> Version: 2.28.0-2ubuntu2
<ogra> armel
<seb128> showsrc will show the source
<seb128> not the binaries
<seb128> https://edge.launchpad.net/ubuntu/+source/libgnomekbd/2.28.0-2ubuntu2/+build/1383201
<seb128> it built 2 hours ago only on armel
<ogra> root@babbage2:/# apt-cache show libgnomekbd4|grep Version
<ogra> Version: 2.28.0-0ubuntu2
<ogra> right, publisher
<seb128> I would not be surprised if it was not published yet
<ogra> hmm, k
<seb128> next run I guess
<ogra> yep
<jcastro> mpt: random thought, have you thought about keyboard shortcuts for USC? (I don't see any mention in the spec)
<mpt> jcastro, yes, I plan to fill them out once it does more of Synaptic does, so that I don't end up assigning a keyboard equivalent to an early feature that would make much more mnemonic sense for a later one.
<jcastro> ok
<jcastro> mpt: I guess I just wanted reassurance that they'll make sense and be easy. :p
<jcastro> like: super-i, gimp, i, y or whatever
<jcastro> for invoke, search, install, then hit yes.
<jcastro> something gnome do-ish
<mpt> ah, I hadn't even thought about keyboard equivalents for sections
<mpt> as in, a key combo for "Get Software", another key combo for "Installed Software", etc
<jcastro> something that would make it easy to derive different bits, sort of how you can guess a URL hack for lp and it mostly is correct.
<yofel> hi, would bug 402188 qualify for an SRU?
<ubottu> Launchpad bug 402188 in pida "gvim complains about "gtk_form_set_static_gravity: assertion `static_gravity_supported' failed" in the shell it's started from" [Undecided,Confirmed] https://launchpad.net/bugs/402188
<mpt> jcastro, I've made a note of that for later. <https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=269&rev1=268>
<jcastro> woo
<ybit2> so why night dh_make might not be doing anything
<apw> slangasek, i wonder if you could cast your eye over an nfs-kernel-server change i am looking to make on bug #493145 ... i am sure i am doing it wrong it being a debian package and all
<ubottu> Launchpad bug 493145 in nfs-utils "[Lucid] NFS kernel server doesn't work anymore with 2.6.32" [Medium,In progress] https://launchpad.net/bugs/493145
<nat2610> where can I get supprot for app development on ubuntu ?
<tjaalton> anyone available to sync a few xorg drivers from unstable? xserver-xorg-video-apm, -ark and -neomagic are the ones that should be synced
<cjwatson> ScottK: obviously it hasn't anywhere near finished yet, but this qt4-x11 build is well past the previous failure
<cjwatson> ScottK: I added 'DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)' before the stuff that uses that, and this after the ifeq ($(DEB_HOST_ARCH),arm) block:
<cjwatson> ifeq ($(DEB_HOST_ARCH),armel)
<cjwatson>         extra_configure_opts += -arch armv6
<cjwatson> endif
<ScottK> cjwatson: Great news then.  Armel seems to be a lot of two steps forward, one step back.  At least we've got some forward moment.
<ScottK> moment/momentum
<cjwatson> of course that change isn't syncable with Debian, unless you do an explicit "if I'm Ubuntu" conditional
<cjwatson> the proper fix would be to use gcc's __sync_* intrinsics, if at all possible
<cr3> I'm getting E: broken packages after upgrading lucid (from lucid, not karmic), apparently, ubuntu-desktop: Depends: xorg but it is not going to be installed
<slangasek> Keybuk: how often is MoM running now?  Or is it failing to complete?
<slangasek> apw: 493145> looking
<slangasek> apw: perhaps it's better to check exclusively for 'nfsd_server', if it's been around since 2005?
<nxvl> james_w: ping
<highvoltage> how does this work? https://lists.ubuntu.com/archives/hardy-changes/2009-December/012337.html
<james_w> hi nxvl
<nxvl> james_w: i'm having a problem sponsoring a branch
<highvoltage> zarafa isn't currently in the archives, how can it be added to hardy?
<nxvl> james_w: bzr builddeb does not accept -k or -u
<ScottK> highvoltage: Look at which component it's in.
<Keybuk> slangasek: just about every run fails on a new package
<Keybuk> today it is unhappy about drupal
<james_w> nxvl: not your fault, but you have to spell it "-- -k..."
<slangasek> I am unhappy about drupal most days; but why does that make MoM fail? :)
<Keybuk> slangasek: because it can't unpack it
<slangasek> wasn't that supposed to be fixed with a dpkg backport onto the server?
<nxvl> james_w: so "bzr builddeb -S -- -knvalcarcel@ubuntu.com" will work?
<Keybuk> slangasek: it clearly hasn't fixed it
<highvoltage> ScottK: hmm, I seem to miss it on that actual message, but I assume it's probably in -partner then. thanks.
<ScottK> highvoltage: Yes.  It is.
<slangasek> ok; this is news to me
<slangasek> Keybuk: any chance there are some error logs I could look at?
<slangasek> (to at least get the precise error message...)
<Keybuk> slangasek: I just get an exit status
<Keybuk> I just blacklist the package and let it run until someone notices it's failed again
<slangasek> blergh
<Keybuk> if you want to take over MoM maintenance, BE MY GUEST! :D
<Keybuk> REALLY
<Keybuk> PLZ!!!
<Keybuk> :D
<slangasek> Keybuk: what's the version of dpkg-dev in use?
<slangasek> I don't believe I have access to the server... :)
<james_w> nxvl: it should, does it?
<Keybuk> dpkg-dev	1.15.4ubuntu2~0.CAT.8.04
<Keybuk> slangasek: RT ;)
<cjwatson> slangasek: it's the one in chinstrap:~cjwatson/
<Keybuk> slangasek: seriously though, I don't have any time to look at MoM atm
<Keybuk> which is why unless someone tells me it's broke, it stays broke
 * slangasek nods
<Keybuk> and I don't really spend any time fixing the problem, I just blacklist the package
<apw> slangasek, ack will sort that
<tjaalton> slangasek: could you sync a few xorg drivers from unstable? it would help making X installable again ;)
<slangasek> tjaalton: oh, I suppose I can do that
<slangasek> tjaalton: bug #?
<tjaalton> slangasek: no bugs filed, pitti did a bunch of them earlier today, but I missed some. there are no ubuntu changes in xserver-xorg-video-apm, -ark and -neomagic
<tjaalton> so those three
<slangasek> ok
<tjaalton> then it's synaptics, vmmouse, cirrus and savage left to merge
<slangasek> generally, filing a sync bug guarantees it gets in front of the eyeballs of the archive admin on duty; though on Monday, there tends to be a backlog, so...
<tjaalton> and that should be all
<tjaalton> right
<cjwatson> Keybuk: do you know which script is exiting non-zero, even? I was wondering if I might be able to run a little bit of it locally, without a full pool
<Keybuk> cjwatson: dpkg-source
<Keybuk> ie. I know that dpkg-source -x fails on a given .dsc file
<cjwatson> oh, I meant which script from cron.daily really, but OK, that's useful information too
<cjwatson> I'll put together a hardy chroot
<slangasek> tjaalton: synced
<tjaalton> slangasek: excellent, thanks
 * Keybuk cackles
<Keybuk> I love how easy it is to debug Upstart
<Keybuk> all software should come with a feature to crash on demand and leave a core file in a given directory
<Daviey> Keybuk: my software always crashes, if i demand it or not :)
<Keybuk> I was actually thinking of having a hidden command in there, which would fork a child process and give you the pid
<Keybuk> so you could attach gdb to it
<Keybuk> thus "initctl gdb" would give you a gdb attached to init ;)
<Keybuk> I suspect kees just exploded at the very thought
<smoser> i uploaded a package to a ppa, but before it built i found an error. is there a way to kill the pending build ?
<maxb> smoser: No, but if you upload new source, the old build will be skipped without building once it reaches the head of the queue
<smoser> oh. ok. thanks maxb
<nxvl> james_w: yup, it worked
<james_w> nxvl: great. I plan to make it so that you don't need that non-obvious bit.
<nxvl> james_w: that would be great
<kees> Keybuk: root can already do that, so why would it be bad?
<apw> cjwatson, that font switch patch is not actually gone, just on the list to conider dropping.  i'll merge your info into the patch so we have it for posterity
<slangasek> wgrant: what was the reason for dpkg v3 support slipping this LP release?  That came as a surprise to me, and we're really hurting from it on the archive admin side of things (over 70 source packages already blacklisted for this issue, more every week), so I want to be sure this is landing in January
<cjwatson> apw: right, I knew it wasn't gone yet, but I like to avoid problems before they happen when I can :)
<wgrant> slangasek: The next LP release is next week.
<wgrant> slangasek: It got caught up in review and upgrade-dpkg-everywhere madness.
<slangasek> wgrant: oh, that's a much better timeline then. :)  Is the v3 support in?
<apw> cjwatson,  ahh ... message got skewed on the way.   and threatening to remove thing often engenders such a desired responce ... reasons why it is needed.
<wgrant> The code has been done for weeks...
<slangasek> ah
<cjwatson> apw: right :)
<cjwatson> Keybuk: would you mind double-checking the exact name of the package you had to blacklist? there's no 'drupal' package in Debian, and both drupal5 and drupal6 are still Format: 1.0
<cjwatson> Keybuk: the name of any other test case would be fine too
<cjwatson> Keybuk: (plus, neither drupal5 nor drupal6 appears to be in need of a merge)
<cjwatson> Keybuk: shame you don't get anything more than the exit status - I tried unpacking a random 3.0 package (fakeroot) here with my backport, and it seems to work
<Keybuk> cjwatson: it was drupal6
<hedkandi> hi
<cjwatson> Keybuk: ok, extracts fine here with my backport :-(
<hedkandi> folks, what happens when you have an unsigned int n and you do n>>32?
<cjwatson> Keybuk: is it reproducible from a shell?
<cjwatson> hedkandi: 0, assuming 32-bit unsigned int
<Keybuk> cjwatson: not sure which version it tried
<Keybuk> it may have been an old one that it's already cleaned out
<hedkandi> cjwatson, could you prove that by reference to the standard?
<cjwatson> hedkandi: yes, C99 section 6.5.7 para 5
<hedkandi> is that online?
<cjwatson> hedkandi: "If E1 has an unsigned type [or other stuff], the value of the result is the integral part of the quotient of E1 / 2^E2"
<cjwatson> hedkandi: probably not
<cjwatson> C standards tend to be payware
<hedkandi> roger well I have to go. It's not what I'm seeing.
<Keybuk> he was pleasnt
<ScottK> Probably just frustrated because he was having trouble with his homework.
<cjwatson> actually I missed a spot in the standard
<cjwatson> but his loss, if he wants to leave
<cjwatson> "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined."
<cjwatson> so nasal demons
<Keybuk> nasal demons? :p
<Keybuk> is that your example of something permitted when the behaviour is undefined? :p
<cjwatson> it's the standard example :)
<cjwatson> have you not heard that before?
<Keybuk> not that particular example, no
<cjwatson> http://groups.google.com/group/comp.std.c/msg/dfe1ef367547684b
<cjwatson> (from the jargon file)
<ebroder> it looks like gcc 4.0.1 whines at you for doing something that dumb, and then gives you back n, unshifted
<cjwatson> yes, it certainly emits a warning, which is what made me look again at the standard
<smoser> maxb, it seems that uploading new source to override a queued build will fail if the queued build was a new upstream version (ie, included orig.tar.gz)
<smoser> i tried re-uploading with the .orig, and it warns me about multiple orig.tar.gz and then i get a failed email message
<smoser> Rejected:<lp.archiveuploader.permission.CannotUploadToPocket object at 0x76a2ad0>
<smoser> if i try without the .orig.tar.gz, i get "Unable to find ec2-api-tools_1.3.45772.orig.tar.gz in upload or distribution." failure
<cjwatson> ScottK: failed again, but the failure looks much more tractable, I suspect. http://paste.ubuntu.com/336873/
<cjwatson> ScottK: might be due to the missing DEB_HOST_ARCH_OS define, perhaps. I've set that and will leave it to run again overnight.
<ScottK> Definite progress.  Thanks cjwatson.
<ccheney> does cp use prealloc on ext4?
<crypt-0> im reluctant to use EXT4
<crypt-0> from my tests etx3 has better throughput
<crypt-0> and XFS even more
 * ccheney wishes there was something other than xfs that could defrag well
<ccheney> last time i used xfs it tried to eat all my data
<crypt-0> what problem do you have with XFS?
<crypt-0> [eat data] pleas enlighten me
<ccheney> the old 0 filled data issue that wasn't solved for about 6 years (aiui)
<crypt-0> i have ahd good lick and good throughput with XFS
<ccheney> it would randomly fill your files with 00's
<ccheney> aka NULLs
<crypt-0> never happened to me, is it patched now?
<ccheney> yea i think for the past year or two
<crypt-0> yea i know a bit about zeros, and nulls
<ccheney> but the fact it existed so long in the code makes me leery to ever use xfs
<crypt-0> well i have been using XFS for the past 3
<crypt-0> im using RAID
#ubuntu-devel 2009-12-08
<ccheney> when it ate my data was around 2000 i think, and that bug wasn't fixed until around 2007-2008 timeframe
<jdong> no, it's not "patched"
<jdong> it's worked around.
<crypt-0> so it wont eat my data
<jdong> no, I never said that
<ccheney> raid doesn't protect you from a filesystem eating your data  :)
<crypt-0> (the current versions of XFS in 9.10)
<jdong> but fundamentally XFS's journal replay strategy is to zero stale data
<ScottK> crypt-0: No one with guarantee any file system won't eat your data
<ccheney> jdong: oh ok
<crypt-0> i know
<ScottK> If they do, run.
<jdong> ext3's policy is to leave it stale
<jdong> because stale is likely correct
<jdong> coming from an enterprise background, XFS's policy is that stale data can constitute privacy leaks
<jdong> i.e. it belonged to another file in the past.
<crypt-0> well i will be creating a new filesystem soon
<ccheney> all i remember well was that my fs was filled with a lot of null filled files
<ccheney> large chunks of missing data
<crypt-0> its EXT3 or XFS....EXT4 just is not there yet.
<jdong> with that said, "older" XFS did have a nasty case where the "cp a b; mv b a" atomic-modify workflow could result in "a" being entirely stale on bad shutdown
<ccheney> more than i would expect from just the journal unless it was bigger than i would expect
<jdong> which is the biggest source of the "XFS nulled my data" complaints
<ScottK> ext4 is the default on Karmic.  I think it's a reasonable assumption that it was considered reasonably safe.
<jdong> that's since then been "worked around" to happen less frequently
<ccheney> jdong: i bet i saw that or something similar to that, because it seemed much more than just what would fit in a journal
<jdong> with that said, I do find XFS like ext4, because of delayed allocation, very aggressively uses the writeback cache
<jdong> and a bad shutdown on a modern system with a boatload of RAM can easily result in hundreds of MB of unwritten data to be tossed out
<jdong> but no filesystem makes any sorts of *guarantee* this won't happen.
<ccheney> jdong: with the ext4 fix for the desktop issues it probably won't trigger data loss like that though i would imagine
<crypt-0> [bad shutdown] im on a smart UPS
<maco> since xfs is older, wouldnt it be "ext4, like xfs..."
<jdong> ccheney: delayed allocation still applies.
<jdong> maco: eh it's a commutative relationship ;-)
<jdong> I'm not gonna trace back to the first filesystem to implement delayed allocation
<ccheney> jdong: iirc any rename forces a full flush now though, right?
<crypt-0> well are you saying i should avoid XFS?
<jdong> crypt-0: that doesn't stop system freezes, etc
<ccheney> and those seem to happen all the time on desktop apps, heh
<jdong> ccheney: rename definitely places a barrier between old and new
<jdong> and to cross the barrier a flush is needed, yes
<crypt-0> jdong, i know but i have not *ever* had a system freeze with Linux.
<jdong> so either the original or the final file will be there, not in between.
<jdong> crypt-0: consider yourself very lucky.
<jdong> crypt-0: even on servers I manage I've been in the case of needing to hard-power-cycle against my will
<jdong> I'm not saying you shouldn't use XFS.
<jdong> I had my primary server on XFS for the past 3 years...
<jdong> only recently did I switch it to btrfs to contribute to the testing effort.
<jdong> note I do not of course recommend users to do this
<crypt-0> well, i have had *hardware* related system freezes....like when i boot my external HD at school and someone bumps it....still XFS does not get corrupted
<jdong> consider yourself lucky then
<jdong> particularly on external USB2 drives (which do not respect barriers)
<jdong> and on RAID or LVM devices (which do not respect barriers)
<crypt-0> jdong, so with the current versions of the XFS tolls and kernel module in 9,10 would you consider XFS a stable filesystem?
<jdong> a bad shutdown on XFS can corrupt its metadata beyond repair.
<jdong> crypt-0: I've always considered XFS a stable filesystem
<jdong> note the two caveats that I pointed out
<crypt-0> what filesystem do you recommend for RAID-1
<jdong> delayed allocation <-> writeback data loss; loss of write barriers <-> full filesystem corruption.
<crypt-0> i will be using hardware RAID-1 for my next build
<jdong> I do not have a recommendation if no corruption / data loss on hard shutdown is your goal.
<crypt-0> and XFS will be on a LVM (encrypted filesystem)
<jdong> that's simply not possible without hardware battery backed storage controllers
<jdong> (at the very minimum; stable software configuration and ECC'ed RAM above that)
<jdong> with that said, you should weigh your risks against the benefits
<crypt-0> ext3 seems to handle hard shutdowns well.
<jdong> it has a 5 second commit flush
<jdong> it also uses physical block journaling
<crypt-0> im on battery backup (UPS, my apps are stable, and if the UPS runs of battery it tells the PC to power off )
<jdong> which increases the hamming distance between valid codewords.
 * ccheney personally likes to stay with what the most users run, as its generally best tested
<jdong> if you are so confident your hardware will not flake, you should use any stable marked filesystem that best handles your workload from a performance and maintenance standpoint.
<crypt-0> EXT3 has always been good to me, and so has XFS
<jdong> in the past, ext3 has by far been best to me in resilience to abuse
 * ccheney bbl
<crypt-0> im just wondering , in your opinion is the XFS throughput worth it?
<jdong> what XFS throughput?
<jdong> depends on what you're doing.
<crypt-0> a lot of DVD rips
<jdong> I switched AWAY from XFS for performance reasons
<jdong> XFS performs extremely well when your data is comprised of large files (>50MB each)
<crypt-0> all legal of course, :)
<jdong> XFS performs extremely poorly when your data is comprised of a large number of small files
<jdong> the latter tended to be my usecase on that server (a build server)
<jdong> and sometimes XFS could take minutes where ext* would take seconds
 * RAOF wished he lived somewhere where dvd rips were legal.
<crypt-0> well , when i extract a DVD most of the chapters are over 100MB, and the final raw mpeg is 4GB
<crypt-0> the ripped version ends up at arounf 2GB
<crypt-0> im plaining on bluray rips which will have a considerably larger size
<jdong> XFS is a very reasonable filesystem for that
<jdong> just keep my caveats in mind.
<crypt-0> but i also have about 60GB of music file sizes 2-100MB per song
<micahg> maybe that's why my builds take a while on xfs :)
<jdong> micahg: rm -rf is a very bad workcase for XFS
<jdong> (1) it spends a lot of time rebalancing the B-tree that will eventually be completely gone anyway
<micahg> is there a way to shrink xfs yet?
<jdong> (2) Nowadays, it flushes barriers (16-32MB of hardware cache) every couple of transactions
<jdong> yay, write 8KB of data, flush out 32MB.
<crypt-0> since i will be using 64 bit will that help?
<jdong> why does that have any impact?
<crypt-0> XFS is a 64-bit file system. It supports a maximum file system size of 8 binary exabytes minus one byte, though this is subject to block limits imposed by the host operating system. On 32-bit Linux systems, this limits the file and file system sizes to 16 binary terabytes.
<crypt-0> so thats it, it has no other impact?
<crypt-0> i think ill go ext3...
<crypt-0> i should get decent read with any FS with raid-1
<crypt-0> and decent write with RAID class drives
<jdong> you know that XFS is a 64-bit filesystem even on a 32-bit processor right?
<crypt-0> but now that i think about it, the bottleneck is not the HD as much it is the DVD reader and CPU for encoding
<jdong> right.
<jdong> but fragmentation wise you DO want an extent-based filesystem
<crypt-0> basically, the filesystem can through a LOT more data at the encoder than the encoder can encode.
<crypt-0> but EXT4 is so slow
<jdong> umm...
<crypt-0> and i have not run into frag-related issues with ext3
<jdong> so you choose ext3?
<jdong> you've got to be kidding me
<crypt-0> i have not tested ext4 that much
<jdong> ext3's problem with dealing with large files is fragmentation when dealing with large files.
<crypt-0> i use it for /boot
<jdong> ext4's primary GOAL is to fix that limitation of ext4
<crypt-0> ah
<jdong> through extents and delay allocation
<jdong> so ext4 is ext3 with better handling of large files.
<jdong> and support for larger filesystems
<crypt-0> most of my experence with EXT4 has been with /boot
<crypt-0> i read that all the ext4 extents can decrease entropy
<crypt-0> for disk encryption
<crypt-0> but, that is probably NSA level shit paranoia
<jdong> I do not have good knowledge of the effects of ext4's disk structure on cryptanalysis
<jdong> so I cannot answer one way or another to that :)
<jdong> but my intuition from my informal experience with the subject is that it's probably not something you should be too concerned about
<crypt-0> right
<cjwatson> so, wait a sec, you tried out ext4 on /boot and then decided it was slow?
<crypt-0> like i said its probably NSA level crap
<cjwatson> not the best of test cases :)
<crypt-0> well i also used it years ago on an external partition
<jdong> considering ext4's lifespan is on the order of "year(s)" ago
<jdong> for very small instantiations of the plural...
<cjwatson> more or less the first thing my security lecturer taught me at university: "if a class 3 attacker is out to get you, you're toast anyway"
<jdong> and for the majority of that time features like extents and the mballoc werne't implemented...
<jdong> I'd say it's time for you to reevaluate ext4.
<cjwatson> don't waste time on vague cryptanalytic worries unless you actually have solid evidence
<crypt-0> NTFS uses extents....and i dont see fully-encrypted winblows machines getting their encryption broken
 * dtchen chuckles at the NSA fud
<jdong> I've found its performance with large files to be comparable if not better than XFS
<jdong> but XFS' scalability to the horrendous extremes is unbeatable
<jdong> and by that I mean things like 20TB filesystems, 1TB files, etc etc etc
<jdong> I don't think that's relevant to you
 * maco points at dtchen and yells "spook!"
<jdong> I will say that XFS's backup tools (xfsdump) and administration/maintenance tools are far superior to ext*'s
<jdong> but I also don't see that terribly relevant to your usecase for storing movie rips
<crypt-0> yeah
<jdong> one of the requirements of my XFS server involved storing home-ish directories for highly active users and that demanded nightly incremental backups, online, while files are changing...
<crypt-0> and i use LVMS so i can use a LVM snapshot, or a desynched RAID disk
<jdong> xfsdump was an instrumental part of that workflow
<jdong> for movies, they're very much write-once-change-many, and don't benefit as much.
<crypt-0> " more or less the first thing my security lecturer taught me at university: "if a class 3 attacker is out to get you, you're toast anyway" if i was worried about three letter agencies, i probably would not even use a computer :)
<jdong> lol cjwatson is absolutely correct there :)
<crypt-0> yes, the TEMPTEST attacks, i dont live in a EMI shielded cage :)
<jdong> and along those lines, there's probably a lot more weak links in your crypto setup than predictable filesystem structures
<jdong> s/predictable/uniquely identifiable/
<dtchen> there are a lot more "efficient" methods, like clubbing you over the head until you cough up the passphrase
<crypt-0> yeah
<crypt-0> that was my point
<jdong> lol and my system sits on my desk in a dorm room
<jdong> if you really want my data, come poison my bootloader while I'm in class.
<crypt-0> if your being hunted by a three letter agency they are going to decrypt you based on your EMI, or log your keystrokes via EMI, etc
<crypt-0> yeah
<chrisccoulson> crypt-0 - i work in an EMI shielded room :P
<crypt-0> i do use disk encryption, i do use a thoubrive for /boot with the GRUB MBR on it...but that is where i draw the line
<crypt-0> so come get me with a hardware keylogger if you want my data :)
<crypt-0> disk encryption, with SHA1/DES is probably good enough privacy for what i do.
<kees> chrisccoulson: I work in an accidentally EMI shielded room.
<chrisccoulson> kees - how come? the room i work in is not accidentally shielded ;)
<crypt-0> one of my professors said one of the same things about if your being hunted by 3 letter agencies....for downloading music and movies or ripping them he basically said you just have to be faster then the other guy
<chrisccoulson> i spend a lot of time in a RFI chamber at the moment
<chrisccoulson> i don't get to see any daylight ;)
<crypt-0> lol
 * spm has done tempest attacks. it's pretty cool stuff.
 * crypt-0 drills holes in your wall and starts picking up your keystrokes with an acoustic keylogger
<crypt-0> :P
<crypt-0> the one that gets me as "almost practical" is sniffing your screen, but there is too much time and effort involved in that i assume under normal circumstances
<crypt-0> it would not be used
<spm> I think the root of "assume" is "ass, you, me" :-)
<crypt-0> "Local man cought using LimeWire  with TEPMTEST attacks"
<crypt-0> true.
<crypt-0> i do use an LCD with a shielded cable, i consider it sufficient.
<crypt-0> or is it not?
 * spm has done successful temptest attacks on PC's with no monitor
<crypt-0> blah
<crypt-0> what of those attacks are standard with music/movies?
<crypt-0> the more you know....the more paranoid you get:)
<spm> think outside the square. why use technical if simpler physical or personal attacks are cheaper and more efficient
<spm> tbh tho. those agencies ahve far bigger fish to fry. there's nothing you can do to stop them if they really want your stuff. but a simplistic risk analysis would suggest - "you" have zip of value they're interested in. they have the capability; they just don't care.
<kees> chrisccoulson: no clue -- i assume the concrete and lead paint contributes.  :)  I get no radio or cell signal in my basement.  :)
<chrisccoulson> kees - yes, the lead paint will probably contribute
<crypt-0> spm yes, i have talked to people who have worked Fornesics, music/movies is the very last theing thet care about
<crypt-0> of course they always want that "example" , but they would probably target someone using less security ( the average Joe filetrader)
<spm> well yes. foreign governments and keeping our soldiers alive was more important than a few execs losing a bmw of roll's
<spm> s/of/or/
<crypt-0> or the 12 year old girls they have been known to targer lol
<crypt-0> target
<crypt-0> "Sally just got caught using the evil program LimeWire now her family has to pay 100 million dollars muhahaha"
<crypt-0> What im saying is "Can my security be beat? Yes." "Will it be as easy as taking my PC? No."
<crypt-0> the real question is who cares enough to mount Temptest attacks on me, and i believe no one does, as i dont live in China
<crypt-0> :P
<crypt-0> anyway
<crypt-0> even if 20% of my data was 100% predictable, i dont that would lead to successful cryptanalysis
<crypt-0> at least, not at this level.
<slangasek> ever the innovators, China has recently melded two of their most important industries to create the first tempest-in-a-teapot technology
<crypt-0> lol
<crypt-0> China broke WPA2 i believe also, as SAH1
<crypt-0> I have also heard and read that the MPIAA/RIAA has swiched to badgering ISPs to badger you
<crypt-0> eg
<crypt-0> "your isp says stop downloading or else:
<crypt-0> instead of "you should have stopped downloading, we are coming to milk you for every cent you are wroth"
<crypt-0> nevertheless i find Temptest attacks interesting.
<spm> why?
<crypt-0> well, i am going to be taking Forensics classes, im still a student
<spm> it's amusing watching someone play solitaire (badly)
<spm> ahh. right.
<crypt-0> my major will probably be networking, but Forensics is nice to have if you are network admin
<spm> I'd hope not!! :-)
<spm> the idea is to ensure you have very little need to do any forensics.
<crypt-0> "Boss: "Joe has been looking at porno and motorcycles all day instead of his work, can you prove it?"
<spm> that's not forensics. that's boring. yukky; seriously yucky. and tedious.
<crypt-0> yeah
<cjwatson> it's also a case where you need to make sure you are on very sound legal ground
<spm> http://www.stedee.id.au/web_proxy_log_usage_forensics_and_analysis <== wrote that for sage-au years ago; then blogged the same.
<spm> exactly
<crypt-0> but form what my professors said....you have to prove they were not ding their work
<crypt-0> doing
<spm> have been pulled in as an expert witness in one case
<spm> jurisdiction?
<spm> it all depends.
<spm> in the case I was involved in; the "porn" was but one plank of a raft of issues.
<cjwatson> crypt-0: depending on local law, you might find yourself the subject of a countersuit for invasion of privacy ... like I say, if you find yourself in that position, you might want to have taken legal advice in advance
<crypt-0> so you have to do port mirroring on their port,i assume a wireshark capture file would be enough
<spm> the guys dismissal was upheald over a range of issues; not just one.
<spm> err what's wrong qith eg proxy logs? or firewall logs? :-)
<spm> why make it hard on yourself? :-)
<crypt-0> well i recall my profs saying, you need evidence that is hard enough to go to court with, because you may have to
<crypt-0> firewall logs may not be enough
<crypt-0> they should, but not everyone in the jury is a tech guru.
<spm> like I said. which jurisdiction. it was plenty for a magistrate for an unfair dismissal case here in australia; ymmv.
<crypt-0> USA here
<spm> and again; it was only a single part of the 2 day hearing
<crypt-0> ah ok
<crypt-0> well
<crypt-0> here
<crypt-0> if you are using school/business computers
<crypt-0> the AUP is basically: we can monitor what you are doing and will if we wwant
<cjwatson> (please don't use the enter key as punctuation.)
<crypt-0> cjwatson, sorry. :)
<crypt-0>  
<crypt-0> :P
<cjwatson> note that AUPs are not necessarily in and of themselves legal
<spm> yes; huge levels of "it depends" in this area.
<cjwatson> just as simply writing something down in a contract doesn't make it enforceable
<crypt-0> Right.
<crypt-0> spm, Forensics is also useful foe Intrusion detection on the network.
<dtchen> are we still building explicitly for lpia given the dropping of the arch? (maybe a dumb question...I've been under a rock debugging linux and pulse issues)
<spm> heh. ignoring that the biggest abusers (ie $$ loss) will be your authorised users?
<cjwatson> http://en.wikipedia.org/wiki/Workplace_privacy - brief but to the point
<cjwatson> dtchen: we're stopping
<crypt-0> anyway, i plan on "downgrading" my encrypted root partition to AES128 for speed
<cjwatson> dtchen: well - for lucid, anyway. hardy-karmic PPAs will keep building for lpia
<dtchen> cjwatson: thanks
<ajmitch> someone who has access needs to remove lpia from the bottom of https://edge.launchpad.net/ubuntu/lucid
 * ajmitch doesn't know where to file that bug
<crypt-0> dtchen, yeah pulseaudio has its issues, had trouble with playing UrbanTerror
<crypt-0> and the sound
<dtchen> crypt-0: that isn't pulse; that's alsa-plugins.
<crypt-0> but it is "fixed" in a fourm o found somewhere
<dtchen> we don't sync the "hw ptr" properly
<crypt-0> oh
<crypt-0> wel
<dtchen> unfortunately it is *extremely* dependent on the audio hardware and kernel configuration
<cjwatson> ajmitch: that'll happen along the line
<crypt-0> wait....the fourms said to force it to use pulse
<cjwatson> ajmitch: I don't believe it's possible to do it yet, because other parts of the removal are not complete
<crypt-0> anyway it works.
<dtchen> crypt-0: what, using libsdl1.2debian-pulseaudio as a workaround? sure, that's a *workaround*. it doesn't at all address the fundamental bug.
<crypt-0> im very disappointed in amarok 2.0x
<ajmitch> cjwatson: I don't think many people will look there for what architectures are supported anyway
<crypt-0> dtchen, yes.
<crypt-0> but you guys have nothing to do with the development of amarok
<cjwatson> ajmitch: I'm in no rush; we have 4+ months
<crypt-0> you merely package it
<crypt-0> i still use 1.4 it rocks :D
<crypt-0> another question: Are you going to stick with the cbc-essiv mode for the default crypto installer, or for the next release try the xts-benbi mode (supposed to be more secure, but the module is still experimental)
<crypt-0> i have been using xts-benbi
<dtchen> crypt-0: experimental in an LTS is essentially a no-go.
<crypt-0> it seems pretty solid, the documentation of cryptsetup says for XTS use : xts-plain but
<crypt-0> > Is the XTS kernel module still experimental?
<crypt-0> It is marked as experimental, but it seems correct and stable.
<crypt-0> > Also, how do you recommend using it for LUKS cypher-name-xts-plain?
<crypt-0> I recommend aes-xts-benbi
<crypt-0> benbi is 'big endian narrow block index', it gives each 16 byte block a
<crypt-0> number. ('plain' is a little endian sector count, which is not standard
<crypt-0> for narrow block cipher modes like lrw and xts)
<crypt-0> Greetings,
<crypt-0> Rik.
<crypt-0> that was an email to Rik Snel <rik@snel.it>
<crypt-0> he manages the XTS kernel module i believe
<crypt-0> and here is another mail
<cjwatson> crypt-0: I'm not really interested in changing it; feel free to take it up with Debian
<crypt-0> cjwatson, inst cbc-essiv secure enough?
<crypt-0> is that what you are saying?
<crypt-0> it is secure and stable enough.
<cjwatson> I'm saying that I'm not interested in changing it, and that you should feel free to take it up with Debian
<cjwatson> I do not want to go diving down a crypto rat-hole for ages - I have too much else to do
<crypt-0> oh ok
<cjwatson> if somebody else from the d-i team wants to investigate it, determine that it's sound, make sure all the necessary tools support it, do the installer integration, and flip the default, they can feel free
<crypt-0> cjwatson, do you believe cbb-essiv is secure enough for most uses (keep three letter agency out please)
<crypt-0> *cbc
<cjwatson> have I not already sufficiently dodged the question? :)
<crypt-0> hehe
<cjwatson> I don't want to spend the time investigating, and I trust the people who made the decision in Debian
<crypt-0> yeah, after all an experimental kernel module that does crypto math can compromise a encrypted system
<cjwatson> I do not want to make an authoritative statement on something I haven't investigated myself
<crypt-0> so while the mode itself is believed more secure, it is more often from what i read the implementation that breaks.
<cjwatson> and I would much rather simply leave the defaults at the same values they are in Debian, rather than going solo on something that the Ubuntu installer team does not have extensive experience of
<cjwatson> that way, at least we have the same problems
<crypt-0> Right.
<crypt-0> IMHO TrueCrypt uses the XTS kernel module
<cjwatson> that's as may be
<crypt-0> i mailed the TrueCrypt developers, with no response.
<crypt-0> wait...thet do use it, along with dm-mod
<cjwatson> but our installer shares really rather a lot more with the Debian installer than it does with TrueCrypt. Like I say, if you really think it's wrong (not just speculating), feel free to contact the Debian installer developers
<crypt-0> because the xts module is never loaded unless i open a TC volume.
<crypt-0> Well, for now as long as the module is experimental, and there no significant attacks on cbc-essiv, there is no rush. On the other hand, if no one uses the module, then it will probably always be experimental.
<crypt-0> So when cbc-essiv attacks come out, users can switch.
<crypt-0> Is it possible to default to cbc-essiv, and at last make XTS an option?
<crypt-0> like "warning xts unsupported"
<crypt-0> like universe repos
<cjwatson> -> d-i developers
<cjwatson> upstream, please
<crypt-0> From what i recall XTS , and a few people using customized crypto installers are the only ones using XTS.
<crypt-0> huh?
<cjwatson> please take your query upstream
<crypt-0> does Debian have an irc channel
<cjwatson> Google
<crypt-0> :P lazy
<cjwatson> but mail will be more productive
<crypt-0> ok
<crypt-0> well i have mails from a lot of developers
<fbond> Hi.  Is the Packages file in an APT repository supposed to be UTF-8 encoded?
<crypt-0> and would be happy to forward to them to people willing to listen
<fbond> I've found a package description that appears to be Latin-1 encoded.
<cjwatson> Nobody's interested in mails from developers saying "use my stuff"; it is self-evident that they think that or they would not be developing it. :-) In order for anyone to be worried about cbc-essiv, you need evidence of cryptanalytic attacks.
<crypt-0> even got a mail from Schneier lol
<cjwatson> or at least sound security research on weaknesses.
<cjwatson> *relevant to the case at hand*
<cjwatson> fbond: that's a bug, yes
<crypt-0> "
<crypt-0> AFAIK, there haven't been new discoveries with respect to the safety
<crypt-0> of CBC. However, as it was never that great in the first place,
<crypt-0> switching to something new is desirable."
<fbond> cjwatson: But is it a bug in the package?  I mean, would Ubuntu retroactively correct Packages.gz for an old package version?
<crypt-0> that is from Clemens Fruhwirth, whom i believe introduced ESSIV to the Linux kernel.
<fbond> (The package in question is doc-linux-html-pt in hardy, not hardy-updates.)
 * crypt-0 shuts up
<cjwatson> crypt-0: I'm ignoring further discussion on the subject in this channel. Sorry.
<cjwatson> fbond: we wouldn't retroactively correct hardy/Packages.gz, no, and UTF-8-soundness across the board is relatively recent
<crypt-0> cjwatson, Can you point me a little closer to the debian developers than google, anyone specific in mind?
<cjwatson> I already gave you the keywords "Debian installer">
<cyphermox> crypt-0, usually, they live on the OFTC network :)
<cjwatson> cyphermox: 01:47 <cjwatson> but mail will be more productive
<cjwatson> sigh. apparently they don't teach research these days ... off to bed, anyway
<cyphermox> indeed, but the mail is easy to find :)
<cyphermox> cjwatson, good night
<fbond> cjwatson: If I'm writing code that parses Packages.gz for older releases, what can I assume about character encodings?
<cjwatson> fbond: nothing, I'm afraid
<fbond> cjwatson: Ouch.  Okay, thanks.
<cjwatson> fbond: in practice it's probably either UTF-8 or ISO-8859-1, but the odd bit of ISO-8859-2 wouldn't entirely surprise me
<fbond> cjwatson: Okay.  I'm surprised there's not control field that makes it explicit.
<cjwatson> by the time the problem was recognised it was easier to just switch to UTF-8
<fbond> cjwatson: Okay, makes sense.  Thanks for your help.
<Keybuk> though it also wouldn't surprise me if the number of fields that don't match UTF-8 is small enough to special-case them
<fbond> Keybuk: Yeah, I'll just try UTF-8, then fall back on Latin-1.  After that, I'll give up.
<slangasek> Keybuk: did MoM fail again, or is it taking a really long time to update?
<Keybuk> IOError: [Errno 13] Permission denied:
<Keybuk> +'/srv/patches.ubuntu.com/unpacked/d/dovecot/1:1.2.8-1/.pc/dovecot-drac.patch/sr
<Keybuk> +c/plugins/drac/Makefile'
 * Keybuk adds dovcecot to the blacklist
<slangasek> ... permission denied?
<Keybuk> slangasek: yeah
<Keybuk> silly package must have no readable permission on files in its tar file
<slangasek> which will be a v3-generated tarball, probably related to the quiltiness of it
<slangasek> bugger
<Keybuk> dovecot is in bzr anyway
<Keybuk> not always
<Keybuk> some upstreams fuck up too
<slangasek> well, .pc/dovecot-drac.patch/ is fairly telling
<Keybuk> aww
<Keybuk> oem-config kept HAL on the CD
<slangasek> dtchen, persia, luisbg: could one of you drop cl-pdf from the ubuntustudio-font-meta deps?  It's removed from Debian, so I'm removing it from lucid
<persia> slangasek: Sure.  I'll do that now.
<slangasek> cheers
<slangasek> tjaalton: how close are we to having installable xorg again?
<tjaalton> slangasek: looks like it's installable, at least dist-upgrade doesn't want to purge any packages here. the blobs need updates though, and wacom will have to wait until next week
<slangasek> tjaalton: all the CD builds have been failing because it's not; just got a fresh one on mythbuntu right now
<tjaalton> slangasek: what's missing?
<slangasek> checking
<tjaalton> I know that the server failed to build on sparc and powerpc, but that shouldn't hold things back?
<slangasek> tjaalton: xserver-xorg-input-all isn't installable, and that's in the seeds
<siretart> morning folks
<slangasek> tjaalton: not installable because evdev, synaptics, vmmouse all have the wrong ABI, I think?
<slangasek> and wacom
<tjaalton> slangasek: no they should be built, at least i386 works here
 * maco takes this as warning not to upgrade to lucid yet
<tjaalton> and wacom was dropped
<maco> tjaalton: dropped? for the moment, or...?
<tjaalton> maco: yes, the current one doesn't build, and xf86-input-wacom isn't packaged yet
<slangasek> tjaalton: ah; my mirror is one revision out of date, let me jab it
<tjaalton> maco: dropped from input-all
<maco> tjaalton: but will come back, right?
<tjaalton> maco: of course, with proper capability-based hotplug
<maco> i mean, support for wacom devices isnt just going to go *boom*?
<maco> ok
<maco> just checking
<slangasek> tjaalton: ah; the new xorg is only just installed on amd64 in the current publisher run
<tjaalton> slangasek: yeah, I noticed the build-backlog was hours long when I uploaded that..
<slangasek> so, all fixed with the next pulse
<tjaalton> great
<slangasek> (I assume)
<siretart> slangasek: if you have a spare minute, could you assist me please with drafting an educated answer on the last paragraph of http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/100538
<slangasek> siretart: hmm, probably not this evening, sorry
<siretart> okay, thanks anyway
<slangasek> ttx: morning
<ttx> slangasek: o/
<slangasek> ttx: do you know offhand if eucalyptus is moving to cglib 2.2 in the lucid timeframe?  Debian has removed cglib2.1 as obsolete
<ttx> slangasek: no I don't. But i can ask.
<slangasek> ok - do you need a mail or bug or anything?
<ttx> slangasek: I should be able to drive that from here, thx
<pitti> Good morning
<dholbach> good morning
<pitti> cjwatson: would you mind doing a d-i upload against 2.6.32-7?
<crypt-0> pitti, i last saw cjwatson speek in the channel at 20:56
<crypt-0> it is 03:40 here now
<pitti> crypt-0: he'll pick it up when he wakes up
<crypt-0> i should probably crawl into bed
<crypt-0> pitti, ok :)
<crypt-0> pitti, while you are here is it worth installing the 2.6-16 kernel updates
<crypt-0> i did not see anything very critical in the upstream changes.
<pitti> they'll come through -updates anyway sooner or  later
<crypt-0> yes they are waiting to be installed
<crypt-0> but i dont like rebooting
<crypt-0> maybe ill use Ksplice
<pitti> no hurry
<crypt-0> http://www.ksplice.com/uptrack/
<crypt-0>  Ubuntu 9.10
<crypt-0>     	Free for Ubuntu 9.10 Karmicâdownload now
<crypt-0>   
<crypt-0>   
<crypt-0>      Ubuntu 9.04
<crypt-0>     	Free for Ubuntu 9.04 Jauntyâdownload now
<crypt-0> whoh, sorry for that big paste
<crypt-0> pitti, i want to test ksplice
<crypt-0> babye since it is already in a .deb package bulit for 9.04, 9.10 and "comming soon" for 8.04 it can be added to unverse?
<dnivra_> i'm trying to understand how the sudo application works. I compiled it using DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc. but when I run it in gdb, I get the error "cannot find threads: generic error". the binary that i compiled works fine. what is exactly wrong?
 * crypt-0 goes to bed
 * pitti unbreaks usb-creator
<dholbach> kirkland: can you comment on bug 493243?
<ubottu> Launchpad bug 493243 in debianutils "Please merge debianutils 3.2.2 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/493243
<dnivra_> i'm trying to understand how the sudo application works. I compiled it using DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc. but when I run it in gdb, I get the error "cannot find threads: generic error". the binary that i compiled works fine. what is exactly wrong?
<dnivra_> also where exactly is this function "verify_user()" in check.c of source of sudo defined. didn't find it in the source files at all
<cjwatson> pitti: yup, will do shortly, thanks
<pitti> cjwatson: good morning! thanks
<cjwatson> Keybuk: I still can't reproduce that extract failure
<cjwatson> Keybuk: ah, but it's not an extract failure, it's files in .pc being unreadable - quilt does like to do that
<cjwatson> Keybuk: i.e. nothing to do with the tarballs as such - I wonder if it would be worth just forcing at least mode 444 on everything
<cjwatson> (modulo umask)
<cjwatson> or, I wonder if .pc should be ignored
<cjwatson> it's not as if you actually want to merge it
<free> mvo: hey!
<free> mvo: just wanted to let you know that I couldn't reproduce that problem with failing APT channels, so it might have been something transient
<cjwatson> mdz: do you have the list admin password for developer-membership-board@? it has some things in its queue which are relevant, and my .listadmin.ini doesn't seem to know its password
<free> mvo: I have another (unrelated) question though, it looks like the RELEASE_UPRADER_ALLOW_THIRD_PARTY env variable for enabling non-official sources is available only from jaunty on, right? I wondering if there is any chance to have it ever backported at some point
<mdz> cjwatson: I don't think so
<mdz> cjwatson: iirc Keybuk set it up
<mvo> free: hello! thanks for letting me know. backport> yes, but it might be simpler than that, is it for the launchpad PPA ?
<mvo> free: what url does that have?
<free> mvo: well, in this moment I'd need it for a PPA, to test the upgrade process against our RC landscape-client packages (not yet uploaded to Lucid or SRU-ed)
<free> mvo: but in general it's an option we would like to expose to our users in the UI
<free> mvo: like a checkbox
<free> mvo: https://launchpad.net/~landscape/+archive/ppa this is the PPA with the packages
<mvo> free: please try adding https://launchpad.net/~landscape/+archive/ppa  to mirrors.cfg (that is a file in the downloaded dist-upgrader.tar.gz)
<free> mvo: thanks for the tip!
<mvo> free: with that, it hopefully just works :)
<free> mvo: is there are wishlist bug open for backporting the allow_third_party feature? if not I might open one
<free> mvo: I guess so, but it involves adding code to the landscape client just for that (which isn't great), and it solves only this case
<mvo> free: do you need more than the LP ppa there? i mean, is it useful indepedant of this?
<mvo> free: if you need it for more, than just file a bug
<mvo> please
<free> mvo: hhm, I'm thinking to customers who might need to enable their repos
<free> mvo: I don't have any real request though
<free> mvo: so it might just be fine actually, because we support it for >=jaunty
<free> mvo: I'll probably open a bug if we get some real request from somebody, thanks for now
<mvo> free: ok, sounds good
<dholbach> hey free
<dholbach> free: we didn't manage to meet in Berlin :)
<free> dholbach: hey!
<free> dholbach: yeah, I'm back to Italy :/
<dholbach> free: I hope you had a good time
<free> dholbach: pretty much, a love the city, hope to come back soon
<dholbach> nice :)
 * dholbach hugs free
<free> :)
<mdz> Keybuk: I just had fsck run on 3 filesystems (/, /home and /space). once / and /home were complete, it went ahead and booted up to gdm while /space continued in the background
<mdz> this was way cool. is that how it is supposed to work though?
<ion> mdz: Thatâs intentional. If you want the system to wait for /spaceâs fsck, add bootwait to its fstab options.
<mdz> ion: what I actually want is for squid to wait until /space is mounted before it starts, because that's where my cache lives
<mdz> I suppose that will require upstartifying squid
<ion> mdz: Yeah. start on all-filesystems, or something like that.
<LucidFox> doko, are you planning to sync/merge llvm from Debian? I specifically hope to see the llvm-source package, to sync clang from Debian after that.
<pitti> cjwatson: hm, d-i failed with "udev-udeb: Depends: libgudev-1.0-0 (>= 147) but it is not installable"
<pitti> weird
<cjwatson> pitti: yeah, udev misbuild by the looks of things
<cjwatson> surely the udeb shouldn't use gudev :)
<pitti> oh, that means that it's looking for a libgudev-1.0-0 .udeb
<cjwatson> yes, because objects in udev-udeb are linked against libgudev
<cjwatson> this is not supposed to be the case
 * pitti builds local udev version and checks
<cjwatson> pitti: odd though, I don't see any offending objects there
<pitti> hm, neither do I
<cjwatson> pitti: I'm happy to figure it out
<pitti> cjwatson: I'm almost done with unbreaking X.org, then I can help with this, too
<cjwatson> no point in us duplicating work :)
<cjwatson> pitti: I see the problem
<cjwatson> pitti: (note that my commit doesn't *entirely* fix it, so please don't upload - still working on another bit)
<pitti> cjwatson: understood; thanks!
<cjwatson> pitti: judgement call: add a new libudev0-udeb package, or remove input_id from udev-udeb?
<pitti> cjwatson: I'd say the latter
<pitti> we only need it for xorg right now really
<cjwatson> oh, I'd been very slightly inclined towards the former on the grounds that we might need it in the future, but not inclined enough to argue the point :)
<pitti> unless d-i relies on persistent input device names (which would be very unlikely)
<cjwatson> it certainly doesn't right now
<cjwatson> ok, I'll remove it
<cjwatson> so the previous commit is technically moot for d-i, but correct anyway - otherwise things built against only libudev0 will be pulling in dependencies on libgudev-1.0-0
<cjwatson> I dunno, this is irritating to remove in the packaging
<davmor2> pitti: I'm having issues on todays live iso getting an ip address from my router
<pitti> davmor2: oh, I get that in vmware, too
<pitti> so it's not just me
<cjwatson> pitti: hmm, sorry to ask a question and then ignore the answer, but I think I'm going to create libudev0-udeb anyway - it's a lot less hassle in the packaging, and will probably avoid problems later
<davmor2> pitti: I'll install and see if it's still an issue
<pitti> cjwatson: heh; sure, sounds fine
<pitti> davmor2: does ubiquity actually work for you? this morning it just crashed, but then I couldn't report it because of the lack of networking
<pitti> davmor2: (still on my list to report)
<cjwatson> probably no need, should be fixed in bzr, assuming it just crashed immediately
<davmor2> no crashed
<pitti> cjwatson: some TypeError AFAIR
<cjwatson> pitti: yeah, that's fixed
<pitti> tried to check a file and probably got None
<pitti> nice, thanks
<cjwatson> no - it tried to check 'file' (the builtin), rather than 'f'
<pitti> aah
<StevenK> cjwatson: Bah, I keep doing that too. :-/
<davmor2> pitti: someone beat you to reporting it bug 492873
<ubottu> Launchpad bug 492873 in ubiquity "ubiquity crashed with TypeError in isfile()" [Undecided,New] https://launchpad.net/bugs/492873
<cjwatson> pitti: do you think it'll be ok if I upload udev?
<pitti> cjwatson: sure, why not?
<cjwatson> pitti: or are you still working on it?
<pitti> no, I'm done
<pitti> (in fact, I didn't touch it)
<pitti> cjwatson: the xorg keyboard stuff was a change in xorg-server
<cjwatson> ok
<cjwatson> pitti: uploaded; would you do the honours with binary NEW when it arrives?
<pitti> my pleasure :) I'll watch it
<pitti> won't make the publisher run in 4 minutes though, I'm afraid
<pitti> I noticed the buildd situation -- what happened?
<pitti> all but one were already disabled over the weekend
<ogra> seems libdap kills them with some kind of make -j <hugenumber> call
<pitti> and that was tried on all of those?
<apw> cjwatson, pitti did i see one of you looking at a bug where the kernel post inst was not being run as a result of lost /etc/something config options, got a reference to the bug?  damned if i can find it
<ogra> when they were reset yesterday libdap was scored in a way that it wouldnt be attempted soon
<cjwatson> apw: not I, I think
<ogra> but apparently it came back
<apw> may have been slagasek
<ogra> pitti, very likely, yes ...
<ogra> its quite odd because we cant build livefses either ... all of the archive is out of sync on arm :/
<pitti> apw: hm, I didn't hear that; the closest I've come across recently is that the new kernel wasn't booted because someone edited menu.lst
<ogra> and the livefs builder has a mksquashfs bug i cant reproduce without having the packages :/
 * pitti hugs ogra
<ogra> thanks :)
<maco> apw: /etc/kernel-img.conf?
<apw> yeah thats the file
<maco> apw: bug 470265 ?
<ubottu> Launchpad bug 470265 in grub "jaunty to karmic upgrade failed to update menu.lst (update-grub missing from kernel-img.conf)" [High,New] https://launchpad.net/bugs/470265
<pitti> ogra: I tried to revieve imbe; let's see whether that works
<pitti> ogra: no, sorry, immediately failed again; seems it needs a reboot or so
<ogra> pitti, lamont is on it, the armel machines do reboot
<apw> maco, thats the one i was thinking of, thanks
<ogra> pitti, they need someone in the DC to power cycle them manually
<ogra> (they dont come back automatically, you need someone to press the power button)
<amitk> pitti: I would like to get the patches into powertop from upstream. They haven't made a new release yet.
<pitti> amitk: in fact, we have had a synced powertop for a very long time, but in late karmic we got a bug fix
<pitti> amitk: sure, that seems fine
<amitk> pitti: we need some stuff from powertop git to tell us about disk wakeups and HDA audio states
<pitti> amitk: I remember that we talked about this at UDS
<maco> amitk: oooh lovely
<pitti> amitk: no problem at all if they are already upstream
<apw> amitk, i think those patches you requested are in the current kernel
<amitk> apw: I know. I got those patches merged in the lucid kernel. Now I need to get the tool updated to use the new kernel interface :)
<apw> amitk, i know you know you asked for them, i didn't know you knew you had them out there in the wild
<amitk> lol
<amitk> ok
<pitti> amitk: want to do the powertop update yourself?
<amitk> pitti: I'll take a stab at it
<pitti> amitk: I guess easiest is to "make dist" git head and use that as a new orig.tar.gz
<pitti> (easier than backporting patches individually and messing with autoconf)
<amitk> pitti: ok, that is exactly the kind of tip I was looking for ;)
<pitti> amitk: let me know if you need help (I'll be away for some 30 mins for lunch, but I'll read backscroll)
<amitk> pitti: thanks!
<lamont> how do I get firefox to either (1) quit dying with SEGV, and/or (2) stop STEALING FOCUS when it pops up a window, finishes rendering a page,  or all those other things that I really don't care that it's done?
<ogra> lamont, use chromium instead ?
<ogra> :)
 * ogra thinks he saw more people with chromium than with FF at UDS
<lamont> ogra: uh... no.
<cody-somerville> I find chromium has rendering issues.
<ogra> not for me ... but the URL bar search function is far behind FF
<cody-somerville> Besides having very weird/ugly fonts
<ogra> hmm, i cant agree ... but then i use driod as my default font everywhere
<cody-somerville> I can't seem to select sans-serif for sans-serif in Chromium.
<jussi01> chromium has lots of black boxes when I scroll currently... its fun :)
<cody-somerville> and it uses Times New Roman by default for serif and Arial for sans-serif
<jussi01> ogra: Have to agree with you about the chromium at uds thing
<ogra> cody-somerville, hmm, i just changed it to sans, works fine here
<artir> the rendering issues are gone with latest update
<cody-somerville> ogra, sans-serif
<ogra> cody-somerville, thats the same, no ?
<artir> also happened to me, i though it was xorg's problem
<cody-somerville> ogra, nope
<jussi01> artir: my black boxes? or something else?
<artir> yep
<ogra> cody-somerville, i dont have sans-serif in *any* font selector ...
<cody-somerville> ogra, It shows up in Firefox show.
<ogra> cody-somerville, only "Sans"
<pitti> amitk: oh, in case you wonder, I'd avise to call the new upstream version 11.1+git20091208
<jussi01> artir: updating now, thanks for the heads up
<amitk> pitti: ack
<artir> also with the chromium-daily ppa? :)
<ogra> thats what i use here
<artir> it's doesn't look like daily, it's quite stable, no fun
<ogra> and apart from the fact that url bar searching doesnt really work with searching for fragments of the url, its working flawless for everything
<artir> i only miss greasemonkey
<cody-somerville> ogra, http://people.canonical.com/~cody-somerville/sans-serif-firefox.png
<ogra> cody-somerville, yes, i belive you, whats the difference ? looks like something hardcoded in FF
<ogra> and i would guess it defaults to fontconfigs Sans
<cody-somerville> ogra, I dunno but fonts look a hell of a lot better in Firefox then chromium.
<ogra> not for me, they really look the same here
<cody-somerville> How can Times New Roman look like Serif?
<ogra> probably i have better displays :)
<cody-somerville> I wouldn't call Times New Romans looking like Serif a trait of a superior display :P
<jussi01> ogra: mind if I pm a minute?
<ogra> jussi01, i have to be in a meeting now ...
<jussi01> ogra: fine, Ill getyou later then :)
<ogra> jussi01, fine afterwards though
<jussi01> ogra: eta?
<ogra> 1h or so
<ogra> (or watch #ubuntu.meeting ;) )
<jussi01> ok, thanks. get you then :)
<ogra> s/./-/
<amitk> Keybuk: around? Need to talk about automated boot tests...
<Riddell> cjwatson: did your Qt arm changes get anywhere?  I have an upload for Qt due
<cjwatson> Riddell: been building all night and still going
<cjwatson> Riddell: let me get you a diff ...
<pgraner> cjwatson: quick question, just did a upgrade to lucid from Karmic and X failed to update, in face the xwerver-xorg package is no long on they system, known issue?
<Wazzzaaa> Im not sure but try: /topic #ubuntu+1
<Wazzzaaa> it says something about broken xorg
<pitti> pgraner: with dist-upgrade or update-manager? do you have logs in /var/log/dist-upgrade/ ?
<cjwatson> xorg was uninstallable for a bit
<cjwatson> input/video driver abi desync
<cjwatson> not sure if that's fixed yet
<pgraner> Pici: dist-upgrade and yes I have the log
<pitti> it should be fine right now
<seb128> read what dist-upgrade wants to do before give the ack to uninstall things ;-)
<mvo> pgraner: could you please mail me the log?
<pitti> hah, mvo has a hilight on "upgrade" :)
<mvo> I do ;)
<pgraner> cjwatson: trying to install xserver-xorg gives me xserver-xorg-input-all & evdev won't/can't be installed
<seb128> the issue is that all drivers didn't get rebuild yet for the new xserver...
<pgraner> mvo: sure
<mvo> this is why I got so many more gray hair :/
<pitti> but yeah, with dist-upgrade this will happen very often -- just don't do the upgrade if it wants to remove half of your system
<cjwatson> you sure you're up to date? xserver-xorg-input-all isn't listed in the automatic uninstallable check
<cjwatson> and what pitti said
<mvo> pgraner: all the stuff in /var/log/dist-upgrade/* please :)
<pitti> wacom was removed from -all yesterday (which is one uninstallable bit)
<cjwatson> and 'chdist apt-get lucid-i386 install xserver-xorg-input-all' works for me right now
<pitti> ^ me 2
<pgraner> mvo: ok I fibbed, I just went to /var/log/dist-upgrade and the dir is empty
<mvo> pgraner: oh, sorry. I misread then. if it was a apt-get dist-upgrade, then there'is no log information on why this was done (u-m keeps a copy of the why)
<pgraner> mvo: no worries, looks like switching the mirror from the "fastest" to archive.u.c is fixing it. Mirror lag
<mvo> ok
<ion> The following packages will be REMOVED: xserver-xorg-input-wacom{a}. I wonder if i could help fix lucidâs wacom support â or is someone working on that?
<pitti> davmor2: network-manager problem> ah, got it; it's a dhcp3-client/apparmor problem; sudo aa-complain dhclient3 fixes it
<pitti> (I got some violations in dmesg)
<pitti> it stumbles over /rofs again
<pitti> I thought we disabled AA on the live system for that reason, seems that doesn't work any more
<pitti> I'll have a look later on
<cjwatson> pitti: ev's already on it
<cjwatson> (#ubuntu-installer)
<davmor2> pitti: works fine from an alternate install
<pitti> ah
<pitti> seems that half of the things I plan today are already being looked at :)
<davmor2> pitti: surely you're not complaining :)
<pitti> heh
<pitti> kees, cjwatson, mdz, Keybuk, sabdfl: we'll do a DMB meeting today again?
<mdz> pitti, I have the same conflict I had for the previous one :-/
<pitti> kirkland: I have no trouble ssh'ing from kvm into the host, but I don't see how to ssh in, since there is no iface configured for this; is there a trick to get a virtual iface on the host?
<mdz> pitti, ssh out, port forward back ;-)
<kirkland> pitti: hi
<kirkland> pitti: what's the ip of your kvm guest?  10.0.2.2?
<pitti> kirkland: right
<pitti> mdz: nice, trying that
<Daviey> pitti: if you are using bridged networking (default), you won't get a dedicated interface tied to it from the host.
<ev> pitti: slight correction, discussion on the apparmor thing is in #ubuntu-release
<pitti> kirkland: sorry, that's the kvm gateway
<pitti> ev: ah, thanks; reading backscroll
<siretart`> sudo dhclient eth0 - dhclient: error loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory - is this problem already known? what package is the culprit?
<kirkland> pitti: right, so you have to have bridged networking to initiate connections from the outside to get to a guest
<siretart`> this is from today's lucid live cd
<pitti> siretart`: see above and #ubuntu-release; apparmor getting in the way
<kirkland> pitti: there's a couple of ways to do this ...  you can use virt-manager, or virsh
<siretart`> pitti: oh, nice. thanks!
<kirkland> pitti: or you can use sudo + a bridged networking script i can show you
<pitti> mdz: yay, that works
<pitti> kirkland: got it to work with -R 2222:10.0.2.15:22
<cjwatson> pitti: I think we should have the DMB meeting today anyway - we're accumulating a backlog
<pitti> cjwatson: agreed
<ScottK> cjwatson: Any news on the overnight qt4-x11 build for armel?
<cjwatson> ScottK: still running, was just about to feed Riddell the diff ...
<ScottK> OK.  Thanks.
<ogra> overnight ??
<ogra> heh
<cjwatson> not the fastest of builds
<cjwatson> Riddell,ScottK: http://paste.ubuntu.com/337275/
<ogra> yeah
<ogra> that more than half of the official armel buildds are dead wont help either ...
<cjwatson> makes no difference in my case, I'm using jocote
<ogra> no, but for ScottK it will ...
<ogra> it wont build before A1
<ScottK> ogra: I was planning on retrying all of KDE as soon as we hit the freeze.
<ScottK> ;-)
<ogra> ScottK, please dont, we dont even have the basic packageset yet
<ScottK> ogra: I was kidding.
<ogra> phew :)
<ogra> :)
<ogra> you got me
<ion> Oh, wacom works after all. Nice.
<pitti> ion: oh? I thought it wouldn't even install right now?
<ogra> pitti, i bet evdev makes it work
<ion> I wonder how to check which driver xorg users for wacom?
<pitti> ion: should be in /var/log/Xorg.0.log
<pitti> ion: right now we don't have udev rules which assign the wacom driver
<pitti> so it must be evdev
<pitti> so I suppose some features are just missing
<cjwatson> james_w: I checked out lp:ubuntu/elilo and ran 'bzr merge-package lp:debian/elilo'. It appeared to work but it only seems to have merged the packaging, not the upstream changes (e.g. 'bzr di -rancestor:lp:debian/elilo' shows a bunch of lines removed from ChangeLog). Did I do something wrong?
<ogra> it likely configures it as mouse
<cjwatson> james_w: should be repeatable if you go back to r17
<pitti> ogra: *nod*
<cjwatson> james_w: revision 2.1.4 is marked [merge] but doesn't have any other visible parents in this tree, which is a little alarming
<ion> pitti: Yeah, i canât find the information from the log. http://pastebin.com/f6468dc84
<ion> Now to find out what kind of udev rules to add for calibration. I used to have http://heh.fi/hal_fdi_policy/wacom.fdi
<ogra> wow, thats impressive
<ion> Oh, click doesnât work with wacom. Itâs âunable to handle keycode 333â.
<ogra>     2.875489] (II) "Wacom ISDv4 93": Configuring as tablet
 * ogra wouldnt have expected that
<pitti> ion: are you using the karmic/lucid -wacom package or xorg-edgers?
<pitti> it seems to recognize the tablet fine by and large
<ion> pitti: Iâm using lucid, and the latest upgrade deleted the -wacom package.
<pitti> ion: oh, btw, would you mind doing "udevadm info --export-db" and put it into a pastebin?
<pitti> ion: I'm curious whether my input_id udev bit detects the tablet as such
<ion> pitti: http://pastebin.com/faecdfef
<pitti> ID_INPUT_TABLET=1
<pitti> perfect
<pitti> ion: cheers
<pitti> x11_driver=evdev
<pitti> yup, evdev
<ion> Ah
<pitti> ion: see /lib/udev/rules.d/66-xorg-synaptics.rules
<pitti> ion: you can use the very same x11_options as in the fdi file, and select by ENV{ID_INPUT_TABLET}=="?*"
<pitti> synaptics did the same
<ion> Ah, thanks. I was just about to ask if ENV{x11_options.Foo} is supported, didnât notice the synaptics file.
<pitti> ion: in theeeory it should work
<pitti> ion: but I assume that it'll only actually work with the wacom driver?
 * pitti has no clue about wacom, sorry
<pitti> kees: you're chairing DMB today?
<ion> Ah, good point.
<ion> So, Option "Calibration" "min-x max-x min-y max-y" for evdev. Letâs try that.
<pitti> xorg.conf FTW: )
<kirkland> pitti: yeah, that's also good
<tjaalton> ogra: btw, what were the issues with using evdev for touchscreens? IIRC calibration was one, or a lack of a tool for that?
<ogra> tjaalton, evdev only works with touchscreens that are supported by udbtouchscreen in the kernel
<ogra> *usbtouchscreen
<ogra> there are only very few
<tjaalton> hmm
<tjaalton> ok
<ogra> usbtouchscreen sets a specific TOUCHSCREEN parameter on the device afaik
<tjaalton> how does evtouch make it work=?
<ion> pitti: http://heh.fi/xorg/udev/66-xorg-wacom.rules handles calibration. Now if click only worked. :-)
<ogra> it hooks in on a higher level
<ogra> though thats obsolete anyway now that hal is gone
<pitti> ion: sweet
<pitti> ion: out of interest, how did you figure out the values? is there a program for it?
<pitti> ion: do you see anything in xev if you click?
<tjaalton> ogra: do the non-usb devices show up in udev?
<ion> pitti: wacom-tools has wacomcpl which would handle calibration graphically, but it has been broken since the HAL migration. I just found the values with manual experimentation.
<pitti> bryce, tjaalton: I'm actually quite surprised that waco mdevies c already work so well with -evdev (see  ion ^); so the wacom driver just adds some extra functionality like those clicks, etc.?
<ogra> tjaalton, depends ... non USB as in serial surely dont, non USB as in PS/2 depend on the driver ...
<tjaalton> pitti: yes, evdev includes some support but wacom has all the bells and whistles
<ogra> tjaalton, all touchscreens i own are usb ones but not supported by usbtouchscreen ... they just show as /dev/input7eventX
<ion> pitti: Nothing from xev, just (WW) "Wacom ISDv4 93": unable to handle keycode 333 in Xorg.0.log.
<tjaalton> ogra: so that's a kernel bug then?
<pitti> ion: so I guess that counts as "bells and whistles" then
<ogra> not sure
<ion> 331 for the second button, which is mapped to middle mouse button by default in the wacom driver.
<ogra> i donbt know if the devices *can* even be supported by usbtouchscreen
<ion> The default calibration for the stylus panel is almost correct by default. The default calibration for the touch panel seems to be a copy of the stylus panel calibration, and it needed a big change.
<tjaalton> ogra: apparently it supports at least serial penmount devices
<tjaalton> so it's not just usb
<ogra> you mean evtouch evdev or what ?
<tjaalton> the kernel
<tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/touchscreen/Kconfig;h=8cc453c85ea704d42ee8411d232c31193e8212e1;hb=baf4974e496957681403d4bf74a3274ed3f85277
<tjaalton> anyway, gotta run
<ion> pitti: Is evdev able to provide click pressure information? If not, thatâs an essential functionality provided by the wacom driver.
<robbiew> ev: ping
<pitti> ion: in theory yes (there's an ABS_PRESSURE value)
<pitti> ion: in practice, no idea
<pitti> it should be like an axis
<ev> robbiew: pong; home
<ion> pitti: How about tilt? My wacom doesnât provide that information, just curious.
<pitti> ion: all I can say is that the evdev interface defines ABS_TILT_{X,Y}
<pitti> but of course it's up to the driver to actually implement it
<ion> Yeah, the interface was what i meant. As long as the interface supports it, it shouldnât be too big an issue to implement the missing functionality in the evdev driver. Itâs just data that comes from /dev/input/eventN in addition to position information etc.
<ion> Yay for MPX. Now if my window manager just supported it. :-P
<apw> mvo, as you probabally realised my update-manager -d upgrade completed fine ...
<mvo> apw: great, thanks
<pgraner> pitti: apport-collect just crashed
<Kano> the current live image is really funny... did somebody try: sudo dhclient?
<Kano> libc.so.6 is not found
<pitti> pgraner: any details? screen output, etc.?
<pitti> Kano: already being discussed and in progress
<bdrung> mdz: with with tools can i readout the acpi sensor data?
<mdz> bdrung: yes, there are procfs and sysfs interfaces
<Al2O3> anyone here a USB PPC on mac developer?  I have a question or two.
<pgraner> pitti: sorry got distracted here you go: http://pastebin.ubuntu.com/337368/
<pitti> pgraner: ah, that's actually bug 385811
<ubottu> Launchpad bug 385811 in apport "TypeError: add_hooks_info() takes exactly 2 arguments" [Undecided,In progress] https://launchpad.net/bugs/385811
<hedkandi> yo!
<hedkandi> hi there is cjw around?
<hedkandi> cjwatson: hello!
<cjwatson> hedkandi: hey, you left before I could correct my mistake last night
<hedkandi> sorry!
<hedkandi> what's the latest version?
<cjwatson> hedkandi: two paragraphs back in the standard, section 6.5.7 para 1
<cjwatson> hedkandi: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined."
<cjwatson> hedkandi: thus, n >> 32 when n is a 32-bit type is simply invalid C, and the compiler is entitled to do anything it likes
<hedkandi> exactly
<hedkandi> that is what I was seeing
<cjwatson> so the right answer is, don't do that :)
<hedkandi> I was actually getting n>>(m%32)
<LaserJock> is there anybody from the CC around?
<hedkandi> which is another way of writing n>>(m&0x1f)
<Pici> LaserJock: #ubuntu-community-team is usually where they hang out.
<hedkandi> cjwatson, well it's interesting
<LaserJock> Pici: ah, awesome, thanks
<hedkandi> cjwatson, I didn't expect that, I've always assumed that you get 0's as you initially stated
<hedkandi> cjwatson, but you don't
<hedkandi> cjwatson, I notice you didn't know this gotcha either.
<cjwatson> hedkandi: not offhand, I outsource that sort of knowledge to the standard
<hedkandi> I presume that the C99 standard is the same as C++
<cjwatson> you presume incorrectly!
<cjwatson> C99 is the 1999 revision of the C standard
<hedkandi> I outsource that kind of knowledge
<cjwatson> it isn't C++
<cjwatson> :-)
<hedkandi> so what does the C++ standard say?
<hedkandi> does gcc run to the c99 standard?
<hedkandi> cjwatson, I notice you run the "ubuntu-devel" list
<hedkandi> where's he gone?
<cjwatson> yeesh, I do several things, not just sit by #ubuntu-devel ;-)
<ScottK> Probably busy doing actual work.
<cjwatson> if you install the gcc documentation package, the info documentation has a lot of stuff about how gcc follows standards. the answer is not straightforward
<cjwatson> I am not a C++ standards person, and have no particular desire to become one :)
<mdz> kees, cjwatson, pitti, Keybuk, sabdfl: http://pastebin.com/f653dfa1c
<hedkandi> cjwatson, I was just installing ubuntu and it says in the installation
<mdz> (please review)
<hedkandi> "let us know about your ubuntu experience: ubuntu.com/community"
<hedkandi> and I have been to that url, and I can't find any way to "let us know about your ubuntu experience"
<mdz> that's not an ideal link for feedback
<hedkandi> mdz, well that's not my fault is it?
<mdz> hedkandi: nobody said it was, relax :-)
<pitti> mdz: looks great, thank you
<hedkandi> It also says "we want ubuntu to work as well for you as possible"
<hedkandi> hahaha
<hedkandi> but seriously....
<hedkandi> cjwatson, how shall I "let us know about your ubuntu experience"
<cjwatson> I think that that text is a bug
<hypera1r> nothing is bug free nowadays eh
<cjwatson> (I didn't write it)
<hedkandi> okay I'll file it as a bug then
<hedkandi> in launchpad, and I'll say you agree it's a bug
<cjwatson> the correct package would be ubiquity-slideshow-ubuntu
<cjwatson> hedkandi: that said, at the left of that page, there's a link labelled "Report a Problem"
<hedkandi> indeed and it sent me on to ubuntu-devel mailing list which is run by cjw
<cjwatson> I moderate that list, yes
<hedkandi> so would you like me to "let us know about your ubuntu experience" on that list then?
<cjwatson> but the first link there ("bug reporting tutorial") has directions on reporting bugs
<cjwatson> no; read the text around the links
<hedkandi> ok
<cjwatson> "Features and policy discussions should be discussed on ...", "Development ideas should be discussed on ..."
<cjwatson> the basic problem is that people have lots of different kinds of feedback, not all of which are appropriate for a single place
<hedkandi> well what category would you put "let us know about your ubuntu experience in" then?
<hedkandi> I'm just doing what I was asked to do by the ubuntu installer
<geser> is sync processing somehow on hold? (or I'm just impatient?)
<hedkandi> More specifically, I'm asking "how do I let them know about my ubuntu experience"?
<hedkandi> well you can think about that.
<hedkandi> I have a different problem to ask about.
<hedkandi> CHANGE OF TOPIC
<hedkandi> I just installed package grub from karmic, and I think I have a bug in it
<hedkandi> I'll put it in a pastebin
<geser> is there a way to figure out why a package got demoted to universe? (before I file a bug to move it back as it's needed as a build-dependency in main)
<hedkandi> http://pastebin.com/d1b5dc56b
<hedkandi> it doesn't seem to operate
<cjwatson> geser: not in general - it's usually just because it fell out of the seeds
<cjwatson> wow, hedkandi is the least patient person ever
 * cjwatson observes a file called ;! added in ubuntu-meta 1.175, and wonders if pitti is engaging in some interesting developer security experiments? :-)
<pitti> cjwatson: argh, looks like some vim spewage
<pitti> the kind of thing that mistyping :w! :q would leave behind or so
<cjwatson> yeah :) I'm nuking it
<cjwatson> I do that kind of thing all the time, really
<pitti> thanks for cleaning up :)
<kees__> mdz: DMB email looks good to me
<dmb> ?
<dmb> can i help you sir?
<mdz> dmb, different DMB, I'm afraid
<dmb> :P
<mdz> cjwatson, any comments on the developer membership board email?
<james_w> urgh, cjwatson: thanks for your bug report. Nasty bug.
<cjwatson> james_w: do you want it as a proper bug somewhere?
<james_w> cjwatson: just filing it myself
<cjwatson> ah, thanks, sorry
<james_w> unless you want the karma?
<james_w> bug 494123
<ubottu> Launchpad bug 494123 in bzr-builddeb "merge-package does the wrong thing when when upstream goes from n.m to n.p where (m < 10) and (p >= 10)" [Undecided,New] https://launchpad.net/bugs/494123
 * apw tried to update and finds a collision between kdelibs5 and ibnepomukqury5
<cjwatson> james_w: I will live without :)
<james_w> cjwatson: you could fix it, that probably gets more karma ;-)
<cjwatson> ok, I'll have a look when I have some network bandwidth again
<james_w> nah, I was just kidding
<james_w> tests are running now to confirm the one-line fix passes
<ccheney> yipee, i just read about the new feature in 2.6.32 making it 'slower' but causing systems from completely freezing on write
 * ccheney was having that problem with karmic last night
 * ccheney may upgrade his systems to lucid soon in that case
* slangasek changed the topic of #ubuntu-devel to: Archive: main frozen for alpha-1 | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Keybuk> pitti: I've noticed one thing since the HALsectomy of X
<Keybuk> when resuming from suspend, I can type my passphrase *straight away*
<Keybuk> no silly 2-3s of no input devices
<mneptok> "I'm sorry, Dave. I can't locate the keyboard right now. Why don;t you take a stress pill?"
<slangasek> Keybuk: yes, this is an expected side-effect and the reason that I was nagging bryce as actively as I was ;)
<ogra> do we need to add a "sleep 3" to not trash user experience here ?
<slangasek> God no
<ogra> :)
<Keybuk> slangasek: though I have noticed xkbcomp has come back
<slangasek> oop
<slangasek> s
<slangasek> Keybuk: hey, so I've got a solution to rc2 not waiting for localhost
<slangasek> and it's fugly
<slangasek> do you want to review it before I commit to bzr? :)
<Keybuk> sure
<slangasek> Keybuk: http://paste.ubuntu.com/337524/
<Keybuk> slangasek: will fail to switch runlevels ever again
<Keybuk> as each runlevel change will spin waiting for the loopback to come up
<Keybuk> (why the pre-start btw?)
<slangasek> Keybuk: no, that's precisely what the pre-start addresses... :)
<Keybuk> how does the pre-start address that?
<Keybuk> it doesn't do anything
<slangasek> one job to capture the loopback event and wrap it as a job status; the other job watches for this job to be up and doesn't continue until it is
<Keybuk> it's the same as not having one
<Keybuk> though your sick and twisted idea, gives me a better one
<slangasek> uhoh :)
<syn-ack> Alright, lets give this another try, shall we?
<Keybuk> hmm, no, my idea doesn't work either
<Keybuk> why not add "and net-device-up IFACE=lo" to the rc-sysinit.conf file ?
<slangasek> Keybuk: do you understand what I'm doing here, then?  I haven't changed the 'start on' condition, so runlevel changes will still work, they just all wait until loopback is started before processing anything
<slangasek> hmm
<Keybuk> slangasek: yes, though you don't need that pre-start at all
<Keybuk> slangasek: but I don't want to do it that way, the entire point is to get rid of sick while loops like that
<slangasek> what would you do instead of the pre-start?
<Keybuk> slangasek: nothing
<slangasek> yes, I realize that's the /point/, but it doesn't /work/ :)
<slangasek> looking at the rc-sysinit, though
<syn-ack> Bingo
<slangasek> I think the reason I avoided that was that conceptually, rcS should /not/ block on loopback
<syn-ack> jjohansen, Workie workie
<Keybuk> slangasek: in practice it probably should
<Keybuk> since bringing up the loopback used to be one of the very first things we did in rcS
<Keybuk> so things in rcS probably assumed it
<slangasek> I haven't found anything that does; but if you prefer that, I think it's an acceptable approximation
<Keybuk> yeah I much prefer that
<Keybuk> aside note, all processes are optional in Upstart
<Keybuk> you can have a job that just has "start on ... " and "stop on ..."
<jjohansen> syn-ack: good
<slangasek> Keybuk: ah, ok
<syn-ack> jjohansen, Thanks again, if you'd like I don't mind testing out your mainlines.
<Keybuk> (or just "description" if you really like <g>)
<jjohansen> syn-ack: I'll take all the testing I can get
<jjohansen> thanks
<syn-ack> Good deal. I have to thank Paul van der does for pointing me to you.
<jjohansen> ah, nice to know.  Just poke me if you hit any problems
<slangasek> Keybuk: ok, will test to confirm and push to bzr (and for SRU)
<ion> Or just an empty file. :-P
<Keybuk> ion: I don't think it allows an empty file
<ion> Oh, ok
<Keybuk> it might
<Keybuk> apparently it does
<Keybuk> shows what I know ;)
<apw> slangasek, thanks for the feedback on the nfs-kernel-server patch.  i've updated the patch and attached it to the bug.  perhaps you could check it over at your leisure: bug #493145
<ubottu> Launchpad bug 493145 in nfs-utils "[Lucid] NFS kernel server doesn't work anymore with 2.6.32" [Medium,In progress] https://launchpad.net/bugs/493145
<bgamari> Shouldn't gfortran now be an alternative for f77?
<bgamari> If I'm not mistaken, g77 was deprecated in favor of gfortran
<jdstrand> slangasek: hey-- I've got an ntp security update I'd like to upload to lucid. should I wait til friday or can I still get it in?
<slangasek> apw: just to be sure - "2005" means this symbol is definitely present in the hardy kernel?  (Have you checked this?)
<apw> i have not checked ... /me looks
<slangasek> jdstrand: ntp> looks like a good thing to have in ASAP, please go ahead (if it's going to get done today)
<apw> slangasek, the commit which makes that variable a global was in v2.6.15-rc1
<slangasek> ok, cool
<apw> though i wasn't expecting that change to go back before lucid
<apw> ahh debian?
<slangasek> apw: debian; and having the kernel server not fail to restart during package upgrades from hardy
<slangasek> s/kernel/nfs/
<apw> yeah sneaky
<jdstrand> slangasek: oh yes, it'll be done today. it's... uploaded just now :)
<jdstrand> slangasek: thanks!
<slangasek> apw: uploaded, thanks!
<apw> slangasek, thank you
<jcastro> chrisccoulson: thanks for pointing the transmission dev to me for bug control.
<chrisccoulson> hey jcastro
<chrisccoulson> did he contact you then?
<jcastro> yep, I got him squared away
<chrisccoulson> i just suggested yesterday that he should perhaps apply now :)
<jcastro> already approved him based on his history
<jcastro> I have an unrelated question for you since I have you here.
<chrisccoulson> jcastro - excellent, thanks :)
<chrisccoulson> fire away ;)
<jcastro> I have an upstream that depends on hal, I would like to point him in the right direction to move away from hal, I need to point him to ... ?
<chrisccoulson> it depends what it uses HAL for
<jcastro> detecting cameras, the upstream is Shotwell
<Amaranth> gphoto?
<jcastro> http://yorba.org/shotwell/ these guys
<chrisccoulson> it could possibly use gphoto for accessing cameras
<chrisccoulson> but GVFS already has a gphoto backend, making camera devices available via GIO (which is what f-spot does, I think)
<chrisccoulson> it seems that f-spot can also access cameras directly via gphoto
<ccheney> so if you don't want people filing bugs on your ppa it won't show your ppa at all?
 * ccheney is confused
<ccheney> ah nm it calls it 'external downloads' now apparently
<jcastro> ccheney: are you back on OOo this cycle?
<ccheney> jcastro: yea
<seb128> jcastro, you are a C# hater aren't you? ;-)
<seb128> jcastro, trying to get f-spot replaced now? ;-)
<jcastro> OOo upstream report is kind of hurting
<jcastro> seb128: no, I met them at guadec and they want to get into universe. :D
<seb128> oh good
<jcastro> seb128: have you tried it lately? they've really come along
<jcastro> and gthumb has been pretty brutal now too
<seb128> dunno if you have seen this guy suggesting replacing f-spot for lucid
<jcastro> I saw the thread.
<seb128> no I didn't
<seb128> I should
<seb128> but same reply than for banshee
<ccheney> jcastro: yea i need some community people to help with OOo, have lots of stuff to do and several hundred new bugs as well
<seb128> now is not good time for tech changes
<chrisccoulson> i have to admit defeat now, and say that i don't know if you can use gphoto for detecting camera devices, or whether you need to use some other mechanism
<jcastro> I appreciate the passion but tbh this kind of thing needed to be done during UDS.
<jcastro> I agree
 * ccheney will be working on firefox as well this cycle
<jcastro> chrisccoulson: I'll settle for telling them to ask someone at GNOME what to do. :D
<jcastro> ccheney: let's link up tomorrow, I'd like to help round people up
<chrisccoulson> jcastro - gphoto is the safe option, i'm sure
<chrisccoulson> and gvfs can mount these cameras anyway :)
<jcastro> seb128: I will respond to them after I respond to the shotwell guys
<ccheney> jcastro: ok
<jcastro> seb128: tbh a healthy photo deathmatch for +1 would be great
<chrisccoulson> heh, gksudo doesn't like the client-side decorated GTK
<seb128> chrisccoulson, somebody commented on the bug saying that too
<seb128> chrisccoulson, did you run into the issue or just read the bug comment?
<chrisccoulson> ah, i haven't checked that yet
<chrisccoulson> gksudo crashes with a BadWindow X error
<seb128> kenvandine, ^
<seb128> rickspencer3, ^ not pushing client side = good move
<chrisccoulson> i havent looked at it further yet, as I've got other stuff I need to get done first
<chrisccoulson> yeah, it seems like it's a bit too crack-ful right now
<rickspencer3> yeah
<rickspencer3> I would have thought that the developers had tested it a tad more by now
<rickspencer3> but I guess that's why you need breadth
<rickspencer3> anyway, PPA and call for testing was certainly the right call
<chrisccoulson> definately
<chrisccoulson> if only there was a good venue for testers to report bugs to PPA packages :)
<seb128> chrisccoulson, how come we are not using #ubunt-desktop btw?
<seb128> #ubuntu-desktop
<seb128> bratsche is there
<chrisccoulson> seb128 - good question
<chrisccoulson> i've got no idea how i ended up in here ;)
<seb128> it's all jcastro's fault
<chrisccoulson> lol
<seb128> I though we were on #ubuntu-desktop
<chrisccoulson> me too
<jcastro> me three
<seb128> ;-)
<ccheney> grr ppa description field now strips out all returns. :(
<ccheney> when editing it shows them but strips them for display
<ccheney> er not exactly, it seems to have non-determinstic behavior
<ccheney> sometimes it displays it wrong without the returns for some reason
 * ccheney stops looking at it before it breaks again
<maxb> Whenever update-manager runs debconf, I get an error: "Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit ...." - can anyone point me in any useful debugging avenues?
<kees> james_w: the gawk bzr history seems broken (it does not show my upload for karmic) ...
<james_w> kees: gawk had problems importing later versions
<james_w> so it's out of date
<kees> james_w: how do I detect/report these kinds of things?
<james_w> http://package-import.ubuntu.com/failures/.bzr/failures/ shows the current list of failures
<james_w> reporting a bug on the LP 'udd' project will get me to look at it though
<dipponaught> how do i use apport-retrace without logging into launchpad (so theres no "mess ups")?
<kees> james_w: ok, next up, "john" is not on that list, but fails to get anything to merge from squeeze.  :)
<maxb> james_w: Also, almost all of the zero-byte files have gone... except python-defaults. What's the case there?
<james_w> maxb: I told it to import them all, lool has asked me to do something special with python-defaults
<james_w> he has some more debian history, so I'm going to do that one a bit more by-hand
<james_w> was that the one that you had created -unofficial branches for?
<maxb> yes
<maxb> hence being quite interested in some official ones :-)
<james_w> kees: john will be available to merge in a few minutes
<james_w> apologies for the hassle
<kees> james_w: np, when I looked at it closely, it's a sync.
<kees> james_w: how about "smarty" ?
<kees> also not listed in failures.
<james_w> same issue?
<james_w> i.e. debian out of date, not Ubuntu
<kees> yeah
<kees> the merge-package reported "ERROR: Nothing to merge."
<james_w> kees: smarty will be available for merge in a few
#ubuntu-devel 2009-12-09
<asac> kees: i guess when getting somethign like this http://paste.ubuntu.com/337657/ adding -fPIC is to easy to be the right answer?
<asac> thats on armel
<kees> james_w: cool, thanks
<asac> too easy
<asac> a bit more context: http://paste.ubuntu.com/337658/
<kees> asac: yeah, all libs should be -fPIC
<asac> kees: hmm. so atm this seems to not use -fPIC on i386/amd64
<asac> but still works
<asac> at least builds
<asac> so using fPIC everywhere is better?
<mjr> I didn't think non-pic .sos worked on amd64 either
<asac> let me check the build log for amd64
<asac> right. its used there
<mjr> (one would think it would be prudent on i386 as well, but what do I know)
<kees> asac: hrm, so, the problem is that it lacks -fPIC when doing the .so build, for sure
<kees> I can't say that's is best to _always_ build -fPIC, but usually you'll want it.
<asac> thx. thats good enough
<asac> its probably a build system issue
<kees> the line that starts:  gcc -shared -Wl,-soname,libavutil.so.50
<kees> is using .o's that weren't -fPIC compiled.
<asac> yes
<asac> thats the point. it doesnt ad fPIC at all on armel and i386
<asac> add -fPIC
<kees> it's just that due to the stack-protector symbol, it's showing up quickly.
<kees> that's ... odd
<asac> right. just wanted to check back if thats something broken because of armel
<asac> kees: its a non autotools build system (e.g. manual configure + Makefile) ... so its not really shocking ;)
<kees> heh, ok
<kees> james_w: hrm, smarty melted down on the merge.  got confused by a remove/add it looks like and claimed conflicts that aren't really conflicts.
<slangasek> james_w: ^^ the merge-package "upstream branches have diverged" OMG failure
<james_w> what? it's just a full and clear exception message! :-)
<slangasek> yes, I was just clarifying "melted down" :)
<slangasek> james_w: the /problem/ is that the branches seem to think that the misc/ and unit_test/ subdirs are complete removals & re-additions, which is a bit of a suboptimal merge :)
<nhandler> mdz: Are you planning on sending out an email about http://mdzlog.alcor.net/2009/12/08/call-for-nominations-ubuntu-developer-membership-board/ ? The post is also missing some information (such as a timeline for the election, what team will be able to vote, is it really 100% open to anyone to run?, etc)
<mdz> nhandler, I sent email to ubuntu-devel-announce, though maybe it hasn't been moderated yet
<mdz> nhandler, the timeline I'll pattern after the TB election, and yes, it's open (I thought that was clear from the text)
<nhandler> mdz: It said it was open, but iirc, most of the other council elections had some type of basic requirement (i.e. must be an Ubuntu member or Ubuntu developer), so I wanted to make sure
<mdz> nhandler, it seems unlikely that someone with no experience as an ubuntu developer would qualify, but I saw no reason to exclude anyone out of hand
<james_w> kees/slangasek: I've no idea why that conflicts, I'm asking in #bzr
<slangasek> ok :)
<jennie> Hello
<jennie> I need assistance
<micahg> jennie: #ubuntu is for support, this channel is for development discussion
<jennie> micahg , i need a simple help , please help me its related to printer installation
<syn-ack> erg
<syn-ack> jennie, then you need to go to #ubuntu, please
<LucidFox> Hmm, Thunderbird 3 is out.
<micahg> LucidFox: indeed
<LucidFox> micahg, perhaps it would make sense to replace rc3 in your PPA? :)
<micahg> LucidFox: rc3 is the release version
<micahg> LucidFox: when there's an official .orig.tar.gz, I'll think about fixing it
 * LucidFox nods
<micahg> but that is the actual release code though, just not branded or versioned properly
<LucidFox> I actually believe Mozilla versions RCs without any mention of them being RCs in the about dialog. RC3 for Firefox 2.0 and 3.0 was byte-for-byte identical to the final release.
<LucidFox> Ah, your version is still branded Shredder. :(
<micahg> LucidFox: right :)
<syn-ack> Hey anyone know if we're gonna have a 64 bit compatible version of Enigmail anytime soon?
<syn-ack> If not, I suppose I could look into it
<micahg> syn-ack: well, that depends on how much free time I have :)
<syn-ack> hah
<syn-ack> no way
 * micahg needs it as well and is part of the mozilla team :)
<syn-ack> heh
<syn-ack> How about that. :P
<ScottK> StevenK: On the off chance you're awake and willing to help me out, plasma-desktop should have been accepted into Main, not Universe (it's split out of two Main packages).  I've fixed the seeds, would you please promote it.
<StevenK> ScottK: Looking.
<ScottK> StevenK: Thanks.
<StevenK> ScottK: Which source package builds it?
<ScottK> StevenK: kdebase-workspace
<StevenK> ScottK: Done.
<ScottK> StevenK: Thanks.
<pitti> Good morning
<pitti> Keybuk: resume straight away> oh, nice! haven't noticed that yet
<lwb> anyone please?
<ScottK> lwb: Help is in #ubuntu.
<syn-ack> Anyone care to test an apparmor script I just got working for skype?
<LLStarks> hey keybuk, what's that new kernel in boot staging do?
<LLStarks> *what does that
<LucidFox> Riddell> So the Kubuntu Karmic final release uses Konqueror rather than Arora by default after all. When was the decision to revert made?
<LucidFox> (I'm not disputing it, just curious)
<CptHowdy> can someone help me build ati drivers from src?
<CptHowdy> #ubuntu = no luck . . . #debian = got threatened
<LucidFox> CptHowdy> Threatened
<LucidFox> ?
<RAOF> I'd guess "strongly suggested to ask elsewhere".
<Darko> ... and "ubuntu has been a bloated peice of trash since ... "
<Darko> actual quote btw
<Tm_T> yay for alpha 1
<LucidFox> Darko> From Debian developers?
<Darko> not sure, probably not though
<Tm_T> I'm not sure if you should discuss about that here anyway (:
<dholbach> good morning
<mvo> hey dholbach!
<dholbach> hey mvo
<pitti> ScottK, Riddell: any idea about http://launchpadlibrarian.net/36614923/buildlog_ubuntu-lucid-i386.compiz_1%3A0.8.4-0ubuntu7_FAILEDTOBUILD.txt.gz ? Did KWD::Window change recently?
<pitti> (I need to rebuild compiz to make it installable for alpha-1)
<geser> pitti: Hi, any idea why pkgbinarymangler couldn't find DEBIAN/control? http://launchpadlibrarian.net/36598521/buildlog_ubuntu-lucid-i386.stx-btree_0.8.3-1_FAILEDTOBUILD.txt.gz
<geser> I tried it in my lucid pbuilder where it succeeds but on the buildd it failed again
<lool> geser: Looks like the build is happening in parallel though
<lool> geser: You have two dh_prep calls which might be called one after the other
<lool> geser: e.g. dh_prep (install-indep), make install (install-indep), dh_prep (cleans up), dh_install (binary-indep) => boom
<lool> geser: One way around it is to change MAKE instead of MAKEFLAGS until your rules are -j safe
<dholbach> james_w: I reviewed a bunch of merge proposals! it was fun! :)
<dholbach> james_w: now I just need a programmatic way to get them from LP onto the sponsoring overview :)
 * pitti eyes component-mismatches
<pitti>  o pmount: pmount
<pitti>    [Reverse-Recommends: kdebase-runtime]
<pitti> o_O
<pitti> Riddell: going back to the old times? :-)
<directhex> pitti, just wait for him to upload MAKEDEV!
<free> mvo: hi again! :)
<free> mvo: I've noticed a little difference between the hardy section of the meta-release and meta-release-lts files published under changelogs.ubuntu.com
<free> mvo: the upgrade tool for hardy in meta-release points to version 0.87.30, while meta-release-lts points to 0.87.31
<free> mvo: is there some specific reason for that?
<mdz> pitti, I had an X server crash last night, and apport failed to capture it due to: ValueError: Invalid process ID: [Errno 2] No such file or directory: '/proc/1167'
<free> mvo: incidentaly that appears the reason for the APT fetch errors I reported you last week, version 0.87.30 fails, while 0.87.31 is fine
<mvo> free: the explicit version numbers are workaround for a soyuz bug, it does not deal with copying the stuff from -proposed to -updates (there is a bug about that)
<mvo> free: oh? let me check
<pitti> mdz: current x server has the apport patch disabled, I think; It still needs to be ported to the current version
<pitti>   * 135_rethrow_signals.patch, 168_glibc_trace_to_stderr.patch:
<free> mvo: yeah, the point is that the two versions published are different, I'm wondering if it's on purpose
<pitti>     Disabled until fixed to work with the current version.
<free> mvo: in my tests the Landsacpe server is passing the landscape client the .30, hence the failures
<mdz> pitti, oh, hmm. I thought without the patch, apport would never see it at all because the signal was caught
<pitti> that's what I had expected
<pitti> it seems that the process went away while it was still dumping core, which seems odd
<mdz> bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/xorg-server": xorg-server in ubuntu has no default branch.
<mdz> :-(
<mdz> james_w, ^
<mvo> free: so for lts-upgrades you should always use the meta-release-lts file, as for the bug, I'm not sure, 0.87.31 is a no-change upload according to the changelog
<mvo> free: I need to diff the actual files
<free> mvo: so, okay, between two lts releases I should use meta-release-lts
<mdz> pitti, shouldn't we open bugs when we disable patches like this, so that they aren't forgotten entirely?
<free> mvo: what about between a non-lts and an lts? like from karmic to lucid
<free> mvo: supposing lucid is out already
<ogra_> hmm, i see gnome-python-desktop_2.28.0-0ubuntu2 built on all arches ... i dont get why the source isnt published at all yet
<free> mvo: should you use the upgrade tool url in meta-release or meta-release-lts in that case?
<tjaalton> mdz: they aren't forgotten
<pitti> tjaalton: ^ is re-enabling 135_rethrow_signals.patch in xorg-server on some radar? (like mdz's bug opening suggestion)
<mvo> free: it depends on what the user wants. by default on a lts we make it look at lts versions, that is configured in /etc/update-manager/release-upgrades
<tjaalton> pitti: bryce said he'd look at it after his vacation
<free> mvo: yes, I know about it
<mvo> free: maybe it would be best to just use the code from u-m (metarelease.py) in landscape too?
<free> mvo: so it's really a user conf
<tjaalton> pitti: I understood that apport was still disabled anyway
<mvo> free: than we can be sure its behaving the same
<pitti> tjaalton: it is
<mvo> free: yeah, user/admin choice, on lts we default to lts->lts, but if the user wants he is free to go from lts->non-lts of curse
<free> mvo: the thing is that we would like to be able to specify the target release from the web ui
<mdz> tjaalton, it's disabled by default, but those of us who have crashes will turn it on to capture a report
<free> mvo: without having to modify /etc/update-manager/release-upgrades
<mvo> free: I see. you could subclass MetaReleaseCore and override CONF I guess, sorry that there is no nicer mechanism at this point
<tjaalton> mdz: git clone, btw ;)
<mvo> free: I found the bug btw, but it can really only be triggered by someone doing a dapper->hardy upgrade with the version in meta-release (and not -lts)
<free> mvo: yeah, in all other cases it works indeed
 * mvo scratches his head
<free> mvo: it's the only case I'm having problems with, but know it's clear why :)
<mvo> free: :) I can make changes the the MetaReleaseCore api so that it is easier for you to point it to a different conf or force a specific behavior (if that helps you)
<pitti> geser: hm, seems the package is building in parallel on the buildds
<free> mvo: thanks, in the long run it would be probably nice to have do-release-upgrade flexible enough to be driven from the outside
<mvo> free: right, if all you need is override of the "release-upgrades" conf via a commandline, that can be done easily
<free> mvo: yeah, that would do it, I guess
<free> mvo: it's not at all urgent though, maybe we can switch to that in the long run, to avoid SRU's for this
<mvo> ok
<free> mvo: just one more thing about this specifc issue
<free> mvo: in general is it common that the urls of the upgrade tool for lts and non-lts are different? in the meta-release-lts and meta-release files
<free> mvo: or is it only in this specific case due to a bug in soyuz?
<mvo> free: no, it should not happen, they basicly should point to lucid-updates/main/dist-upgrade-all/current, its there because of the soyuz issue
<free> mvo: okay, thank you
<mvo> thanks
<mvo> free: what what might happen is that that -lts file is updated a bit later to give us extra time for testing the lts->lts upgrade path
<dholbach> can anybody give me some feedback on http://people.canonical.com/~dholbach/cheatsheet.jpg and say if I forgot anything? (still in the brainstorming phase :))
<free> mvo: okay
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/dpkg-cross/crossbuild>$ bzr import-dsc ../dpkg-cross_2.5.2ubuntu2~cross*.dsc
<cjwatson> bzr: ERROR: Unable to find the tag for the previous upstream version, 2.5.2ubuntu1, in the branch: upstream-2.5.2ubuntu1
<cjwatson> james_w: ^- how do I tell import-dsc that this is a native package and it shouldn't go looking for upstream- tags?
<james_w> cjwatson: that may well be a bug
<james_w> Steve reported something similar
<james_w> I thought it was handled, but obviously not
<cjwatson> I'll go report it then
<james_w> thanks
<james_w> the -Derror trace would be useful
<james_w> (debug flag to always print tracebacks for exceptions)
<cjwatson> james_w: cool; added
<james_w> thanks
<cjwatson> maybe just needs 'if config.native:'
<cjwatson> ?
<cjwatson> well, 'if not'
<cjwatson> hmm, now I have Unicode trouble with lool's name
<ScottK> pitti: I have not looked at the code (re compiz/kde), but we just switched from KDE 4.3 to the 4.4 beta, so I wouldn't be suprised if it had changed.
<pitti> ScottK: I hit it over the head now, it builds now
<ScottK> OK.  Good.
<dnivra_> I downloaded the source of gedit 2.29 from launchpad. However the source and diff files were downloaded separately. How do I apply the diff to the original?
<pitti> dnivra_: you need the .dsc, and then use dpkg-source -x foo.dsc
<pitti> dnivra_: but that's not the usual way, you usually just do "apt-get source packagename"
<ev> we don't have any way of doing translucent overlays in lucid, do we?  That is, I want to be able to mount A over B, and I want the files in B that aren't present in A to show through.
<ogra> ev, aufs ?
<pitti> that would stretch the "everything is a file" principle veeery far :)
<ogra> (wouldnt be an pverlay but a union mount indeed)
<ogra> *over
<pitti> oh, ignore me; I misread
<pitti> sounds pretty much what aufs does on the live system indeed?
<pitti> ev: but I wouldn't recommend that for production use
<ev> indeed, that slipped my mind
<pitti> I think there's a way to do it with LVM, though
<pitti> Fedora live systems work like that
<ev> pitti: this is simply to save me the work of tons of NFS mounts
<ev> in development on the live CD
<dnivra_> pitti: but the current repository is karmic's and i want the lucid development package. thanks
<pitti> dnivra_: (you can add deb-src for lucid)
<dnivra_> pitti: true
 * dnivra_ didn't think of that
<doko__> does dpkg already support xz?
<Tm_T> xz?
<ScottK> I think it doesn't.
<cjwatson> not yet in lucid, although I think it probably will in the lucid cycle; the work's done upstream
<mjr> Tm_T, lzma-utils's slightly more generic continuation
<ogra> me is scared
<Tm_T> mjr: ah, thanks
<mjr> provides for unpacking the old lzma format
<cjwatson> although that would require another rev of the dpkg code used by LP, so maybe not. don't bank on it
<mjr> (possibly also compression for now, not sure)
<ScottK> mjr: It does.  KDE uses xz for all it's lzma support.
<lool> I uploaded a fixed maximus since it was missing a Provide causing compiz to appear in the ubuntu-netbook-remix task
<tkamppeter> pitti, seb128, there is a problem with Lucid's Poppler.
<pitti> tkamppeter: ?
<pitti> tkamppeter: if you ask because of cups trunk FTBFSing, that's know
<pitti> n
<pitti> Debian reverted an upstream API/ABI change
<pitti> so we can't build current cups trunk in lucid
<pitti> that needs some h4ck3ry again
<tkamppeter> pitti, seb128, according to debian/changelog our Poppler is 0.12.2-2.1ubuntu1, but it doews not contain the patches of Debian's 0.12.2-2.
<pitti> tkamppeter: right, the version number is screwed up
<tkamppeter> I cannot find the files 01_revert_abi_change.patch and 02_autohinting_abi_compatibility.patch in our Poppler.
<pitti> it should have been 0.12.2-0ubuntu1
<pitti> tkamppeter: we dno't want 01_revert_abi_change.patch
<tkamppeter> And Debian's ChangeLog entries of 0.12.2-1 and 0.12.2-2 are also missing.
<tkamppeter> pitti, what is wrong with 01_revert_abi_change.patch?
<seb128> it reverts upstream abi
<seb128> there is no reason to be api incompatible with upstream
<pitti> tkamppeter: there's a patch in bzr history which was reverted again which makes it build with our poppler
<tkamppeter> pitti, CUPS I have now synced to the upstream version of the PDF filters, this works with both ABI versions of Poppler, but it requires that CUPS is run with the ABI version of Poppler with which it got compiled.
<pitti> nice
<pitti> tkamppeter: sure, we can take that for granted
<tkamppeter> Koji Otani, upstream developer of pdftopdf has made this final patch.
<tkamppeter> pitti, seb128, I have built our current version of Poppler locally, installed it, and then built CUPS. According to config.h our Poppler has the new, accidentally introduced ABI.
<pitti> mr_pouit, cody-somerville: can you please unseed gnome-games and seed the selection that we have in ubuntu-desktop? that should make xubuntu installable again
<pitti> are you interested in xubuntu alpha-1 at all?
<tkamppeter> We should have a Poppler which has the ABI which is official by Poppler upstream.
<pitti> i. e. should we put some effort into getting buildable CDs?
<pitti> tkamppeter: so the situation is that the poppler API/ABI was officially broken (without bumping soname)
<pitti> tkamppeter: so the current lucid abi is the upstream abi
<pitti> it was just reverted in Debian to not delay the huge testing transition even more
<tkamppeter> pitti, seb128, so Ubuntu is intended to use the new ABI then?
<pitti> right
<tkamppeter> pitti, then CUPS is perfectly prepared now, under Debian it compiles with the old ABI then and under Ubuntu with the new ABI.
<pitti> joss said he'd do a libpoppler5a once the dust settles in Debian, to properly handle the abi break
<pitti> yay
<pitti> thanks
<tkamppeter> pitti, so you should upload the current CUPS to both distros now.
<pitti> will do after alpha-1
<tkamppeter> pitti, I will update the debian/changelog of cups.
<pitti> tkamppeter: ugh, what did you do with bzr? you removed 3 revisions of mine and seem to have merged them back in a huge commit
<pitti> oh, it's a merge
<pitti> tkamppeter: I fixed the changelog (unstable -> UNRELEASED), please ull
<pitti> and pull, too
<tkamppeter> pitti, it accepted a "bzr push" by me though you had done three commits which I did not have downloaded. I discovered it on a later "bzr pull". So I did "bzr merge" to get your changes, solved the conflicts, synced the filters with upstream, wrote a debian/changelog entry and committed.
<tkamppeter> Now I have done another commit to update the text of my last debian/changelog entry.
<pitti> right
<pitti> cjwatson, ev: "Update this installer" -> brilliant!
<ev> all cjwatson on that one
<tkamppeter> pitti, now all is in sync again with CUPS.
<tkamppeter> pitti, will alpha-1 have CUPS working? Otherwise we perhaps need to upload this CUPS as a freeze exception. Please test.
<pitti> tkamppeter: doesn't it right now?
<tkamppeter> pitti, I do not know what is in alpha-1, I have manually installed the newest Poppler and the newest CUPS of Lucid, Poppler downloaded from LP and CUPS from BZR.
<pitti> 1.4.2-1git1 should work just fine
<pitti> except that the version number should have been "1bzr1" :0
<mr_pouit> pitti: done, I'll also refresh xubuntu-desktop
 * pitti works too much with git these days
<tkamppeter> pitti, only if the Poppler in alpha-1 is old enough (not yet containing the ABI change).
<pitti> mr_pouit: nice, thanks; should I attempt another xubuntu live build after that published?
<pitti> tkamppeter: the current cups is built against the current poppler; should be all good
<mr_pouit> pitti: yeah, probably, if xfce4-power-manager doesn't lag behing for amd64 anymore. It seems to be built now.
<cjwatson> pitti: it's a right pain to test because you have to manually backrev the ubiquity package :)
<tkamppeter> pitti, assuming that the CDs will contain the last version of each package which did not FTBFS CUPS comes as 1.4.2-1git1, which is built against 0.12.0-0ubuntu2 (old ABI) according to the i386 build log on LP, and Poppler in alpha-1 is 0.12.2-2.1ubuntu1 which is the new ABI. So for me it looks that CUPS will not work in alpha-1.
<seb128> mr_pouit, hey, do you know if somebody in the xubuntu could do a mir for psiconv which is needed by abiword?
<cjwatson> ttx: bit of a problem with the cloud preseeding stuff - I only seem to be able to talk to it by https, and busybox wget only supports http
<ttx> cjwatson: I was fearing that would be the case
<JontheEchidna> pitti: ping
<cjwatson> ttx: any idea if there's any plain HTTP interface I can use?
<ttx> cjwatson: not that I know of on the CLC itself, the other one seems hardwired to the webservices stuff. You should ask the eucalyptoids for advice.
<cjwatson> I suppose this is only for eucalyptus, I could use wget-udeb
<cjwatson> that might be easier
<mr_pouit> seb128: abiword seems to be seeded by only xubuntu-desktop & lubuntu-desktop, so is there a reason to keep it in main?
<cjwatson> yeah, I'll do that
<seb128> pitti, ^ do you know?
<ttx> cjwatson: yes. Adding a static file service webthing to the HTTP-based service on the CLC would probably require some change in upstream code itself
<pitti> JontheEchidna: pong
<ttx> cjwatson: and dropping that servlet xml in /etc is so much more elegant :)
<JontheEchidna> pitti: Hi, I have a few revisions to jockey I would like to get merged: https://code.launchpad.net/~echidnaman/jockey/work
<JontheEchidna> Also, I was wondering if the ~kubuntu-dev group could get added to ~jockey-hackers
<tkamppeter> pitti, have you seen my longer message about a possibly broken CUPS in alpha-1 some lines above?
<pitti> tkamppeter: yes, I did; haven't tested it (no printer right now, and busy with release stuff)
<pitti> seb128: hm, I wonder what keeps it in main; checkrdepends doesn't have anything, but it's not on component-mismatches
<pitti> ./ubuntu.lucid/dvd: * abiword-gnome
<pitti> there we go
<tkamppeter> pitti, this can get tested without printer, simply running '/usr/lib/cups/filter/pdftopdf 1 1 1 1 "" in.pdf > out.pdf'.
<pitti> seb128: and edubuntu has it as well
<seb128> pitti, does edubuntu requires main?
<seb128> pitti, or can it use universe packages?
<pitti> tkamppeter: seems we have it then
<ScottK> seb128: Requires Main, I believe.
<pitti> tkamppeter: i.  e. the problem; ok, I'll do an upload
<seb128> who cares about edubuntu nowadays?
<pitti> seb128: abiword-gnome doesn't exist at all any more, so the seeds need to be updated either way
<ogra> seb128, highvoltage stgraber and sbalneav
<pitti> stgraber: would you mind updating the edubuntu seeds for abiword? abiword-gnome doesn't exist any more; (or just drop it entirely, then it can go to universe and doesn't require a MIR)
<seb128> ^ who is wanting to do the psiconv mir for abiword then?
<seb128> or move it to universe
<seb128> ogra, pitti: thanks
<seb128> ups, focus with multi screen is confusing
<pitti> stgraber: nevermind, did it for you; I can commit to the edubuntu seeds (fixed package names now)
<tkamppeter> pitti, thanks, your new CUPS upload should clode bug 489791.
<ubottu> Launchpad bug 489791 in cups "Compilation fails because of changed interface in libpoppler" [Critical,Fix committed] https://launchpad.net/bugs/489791
<maxb> mvo, others: Any time a package being updated under update-manager fires off a debconf interaction, I get an error popup about "Cannot contact the configuration server". I see this on multiple machines, but there's no bug filed. Is there anything I could do to debug a bit more before I file one?
<pitti> tkamppeter: uploaded to Debian now; test-building on lucid
<pitti> tkamppeter: fails for me
<mvo> maxb: lucid or karmic? is this the ubuntu update-manager? or do you use something like kubuntu?
<pitti> tkamppeter: http://paste.ubuntu.com/338028/
<maxb> mvo: Plain Ubuntu update-manager. I have observed this in jaunty, karmic, lucid.
<pitti> tkamppeter: was this added recently? perhaps you forgot to bzr add it or so?
<tkamppeter> No, CUPS shipped all the time with pdftops.c.
<mvo> maxb: interessting, did you do any modifications to /etc/debconf.conf ? like putting a ldap there or something?
<maxb> No
<maxb> I am guessing that the "configuration server" is gconf
<maxb> ORBit is mentioned in the error message
<tkamppeter> pitti, there is no pdftops.c in the debian/ directory tree. pdftops.c is part of upstream CUPS.
<pitti> tkamppeter: does "bzr st" show any modifications for you? does "bzr bd -- -b" build for you?
<maxb> It's perhaps worth noting that the debconf prompts do appear (in GTK dialogs) underneath the error popup
<maxb> dpkg-reconfigure says my debconf frontend is 'dialog'
<tkamppeter> bzr st does not show any output, the other command I am running now.
<tkamppeter> pitti ^^
<tkamppeter> pitti: The PDF filters are compiled now ...
<mvo> maxb: ohh, right. that is quite possible a side-effect of the perl-gtk2 bindings
<maxb> perl!?
<maxb> What do I install/uninstall/tweak to verify this?
<tkamppeter> pitti, ... now it started testing, so everything seems to be compiled ...
<pitti> tkamppeter: weird
<tkamppeter> pitti, I have the current Lucid package and its -dev of Poppler installed.
<tkamppeter> pitti, now it runs the debhelpers to complete the packaging.
<pitti> tkamppeter: let me try again; I think I did a source build in parallel
 * pitti does too much stuff in parallel today
<tkamppeter> pitti, "rm -rf ../build-area/
<tkamppeter> "
<JontheEchidna> pitti: heh, mind if I ping you about jockey later then? You seem quite busy.
<pitti> JontheEchidna: I have a tab open with the branch, so I'll merge it ASAP
<JontheEchidna> thanks
<tkamppeter> pitti, now the build ended successfully.
<tkamppeter> pitti, I am trying with pbuilder now.
<pitti> tkamppeter: let me finish my second build first; seems it's working now
<pitti> JontheEchidna: merged, pushed
<pitti> thanks!
<JontheEchidna> pitti: thank amichair too if you see him around
<pitti> JontheEchidna: I added you to ~jockey-hackers, so feel free to commit such fixes directly
<tkamppeter> pitti, a Lucid pbuilder with the newest Poppler 0.12.2-2.1ubuntu1 builds CUPS 1.4.2-5 correctly for me.
<JontheEchidna> pitti: ok, thanks
<pitti> tkamppeter: uploaded -5 to lucid
<tkamppeter> pitti, OK, Thanks.
<syn-ack> 'mornin' pitti
 * syn-ack hugs pitti 
<tkamppeter> pitti, I got a "rejected" message of your upload: Unable to find distroseries: unstable
<tkamppeter> pitti, seems that the config of LP in terms of accepting uploads of synced packages has changed or your need to conmfirm the upload somehow.
<cjwatson> nothing to do with that, pitti just got the .changes file wrong it seems
<cjwatson> synced .changes files always have the Distribution: field specially munged
<iuso> hi, is there a standard way to manipulate /etc/network/interfaces in deb packages?
<iuso> or is it just scripting in (pre|post)(inst|rm)?
<cjwatson> I think packages are forbidden from manipulating /etc/network/interfaces, generally; it's a configuration file belonging to another package that doesn't provide an interface to manipulate it
<cjwatson> if you do it, you'd have to (a) just use standard text editing tools (b) not upload it to the Ubuntu archive
<iuso> cjwatson: thanks, that seems to answer the formal side. i'm writing a config package for my employer's internal systems which are running on ubuntu. i have free hands to do $whatever within the deb but i prefer to go by the book whenever possible
<iuso> cjwatson: i guess it's careful use of grep and sed mainly from now on :)
<cjwatson> sounds like it, yes
<iuso> thanks again and bye
<cjwatson> fortunately it's not *that* complex a file format
<lamont> wtf does cups(presumably..) think it should be using snmp to talk to the host a printer spools to?
<tkamppeter> Someone of the Alpha 1 release gurus around? pitti? slangasek? There is a problem with bug 489791, pitti has uploaded the fix but the upload gets rejected due to some LP problem. Can someone fix this or should I simply work around by uploading the same package with a 1.4.2-5ubuntu1 debian/changelog entry added?
<ubottu> Launchpad bug 489791 in cups "Compilation fails because of changed interface in libpoppler" [Critical,Fix committed] https://launchpad.net/bugs/489791
<cjwatson> tkamppeter: it's really easiest for pitti to fix this when he returns
<cjwatson> tkamppeter: I didn't think he was going to be that long
<pitti> tkamppeter: don't panic
<pitti> I uploaded it again
<pitti> cjwatson: ^
<pitti> (also, it won't be on the alpha-1 images anyway)
<pitti> people can just upgrade
<ion> keybuk: Each graph at http://people.canonical.com/~scott/daily-bootcharts/ could have the (SSD) budget for that part as a constant line. :-)
<Keybuk> I did put that on
<Keybuk> but found it distracting
<ion> Ok
<Keybuk> started to become too much noise
<dholbach> pitti: I'm sorry, but do you think you can restart the community team chart? we have a spike in there again :)
<dholbach> (due to straggling)
<pitti> dholbach: done
<dholbach> thanks a lot pitti
<robbiew> cjwatson: guess we forgot to choose a chair for next week :/
<Keybuk> I don't mind doing it
<robbiew> done!
 * ScottK predicts a short meeting.
<ion> keybuk: Do you happen to have time for reviewing <https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/parallel-checks>? :-)
<Keybuk> no
<ion> Aye
<Keybuk> I'm not even sure it's the right idea ;)
<Keybuk> do you have graphs to show it works?
 * ion installs bootchart to the VM, letâs see.
<Keybuk> blktrace would probably be good too
<ueu001> I have a question about the default inclusion of software in karmic
<ueu001> Why doesn't karmic come with python3 by default ?
<ScottK> Because very few applications and almost no third party modules support it yet.
<ueu001> is python 3 a major change of python 2 then  ?
<ScottK> Yes.
<ueu001> Thank you :  )
<ScottK> It's useful for developers so we provide it, but it will be a long time before enough has transitioned to it to be a suitable default
<ueu001> So for example if someone  is just now beginning python, which of the two would be the better choice ?
<ScottK> It depends.  If you are learning it in school now to use later, probably Python 3.  If you need to deliver production code next month, Python 2.
 * pitti can't believe that people seriously discuss a hurd port
<cyberix> pitti: Ubuntu GNU/HURD then?
<ogra> pitti, i think Keybuk trashed their hopes already :)
<ScottK> ogra: They didn't give up.
<ScottK> If not Hurd, how about Minix?
<ogra> they will eventually ...
<ogra> or BSD :P
<ScottK> We already have an opensolaris downstream, so why not?
<slangasek> james_w: pristine-tar reconstitution seems to fail for quilt
<slangasek> (lp:ubuntu/quilt, after merge-package)
<james_w> ok, thanks
<james_w> that's a problem at creation time, rather than when you get the error
<cyberix> I don't think a HURD edition of Ubuntu would be a bad idea once we first have an official Debian release with HURD
<cyberix> But I don't think it should be marketed trought Ubuntu.com
<cyberix> we should just have the packages available so someone can derive a Hurdubuntu from Ubuntu package repository
<cyberix> but I guess HURD is still far from being officially supported by Debian
<cyberix> atleast that comes closer as Debian starts to ship BSD
<cyberix> and we have multi-arch in place
<cyberix> talking of which, are we going to have multi-arch in Lunatic Lynx?
<cyberix> Lucid
<cyberix> -Lunatic
<cyberix> This is still outdated https://wiki.ubuntu.com/MultiarchSpec
<cyberix> it says "Ubuntu 9.10 introduces support for installing packages from multiple architectures on a single system"
<cyberix> and obviously it didn't
<kirkland> james_w: hi, i'm having trouble finding an imported package branch ... how do you search these?
<kirkland> james_w: or is the url well-defined enough for me to just guess it?
<kirkland> james_w: specifically, i'm looking for "screen"
<tdomhan> why can't I currently create bugs in launchpad? https://bugs.launchpad.net/ubuntu/+filebug will redirect me to the wiki. is this intended?
<beuno> tdomhan, yes, read the wiki
<james_w> kirkland: code.launchpad.net/ubuntu/+source/screen
<james_w> kirkland: or go to the package page and click the "Branches" tab
<james_w> to just branch it with bzr "bzr branch lp:ubuntu/screen" for lucid
<james_w> lp:ubuntu/<series>/screen for an arbitrary series
<kirkland> james_w: perfect, thanks
<LaserJock> is dholbach on vacation?
<geser> LaserJock: at least he wasn't today
<LaserJock> hmm, I never seem to find him
<jcastro> LaserJock: he usually signs off about -2 hours ago every day
<geser> LaserJock: try around between 8 UTC and 17 UTC
<ion> keybuk: http://heh.fi/tmp/mountall/ Bootcharts from current mountall behavior and two methods to inhibit low-priority instances: ioprio_set+setpriority and SIGSTOP.
<ion> keybuk: I have trouble distinguishing the two fsck instances from blktraceâs output.
<Keybuk> ioprio one looks quite reasonable
<Keybuk> it's simpler in the code too, right?
<ion> As opposed to mountallâs current behavior?
<Keybuk> yeah
<ion> keybuk: Hmm. The number of lines of code didnât change much, because it still needs determine which instances to inhibit based on which physical devices theyâre operating on. It no longer needs to maintain a global fsck queue and device locks. Instead it maintains a list of running checks sorted by their priorities. When checks start or finish, it updates the list and then updates the process priorities.
<Keybuk> right
<learner001> Hi
<Keybuk> which seems simpiler
<Keybuk> less prone to forgetting to run fsck
<learner001> i need help please
<Keybuk> learner001: #ubuntu for help
<ion> Yeah, iâd say itâs conceptually simpler.
<learner001> i did upgrade from 9.10 to 10.4
<learner001> then i can not run xserver
<learner001> how can i do undo upgrade
<ion> Basically, reinstall. You upgraded to a development version. When running one, you should *expect* it to break periodically. Now, please, #ubuntu for help.
<learner001> ok thank u
<ajmitch> actually #ubuntu+1 for lucid help, I think
<Keybuk> ajmitch: #ubuntu-wddtt ?
<ajmitch> Keybuk: I won't even try & figure out what that one means :)
<Keybuk> Well Don't Do That Then
<barry> hi all.  i have a complete n00b question.  i'm learning how to be an ubuntu developer (working w/cjwatson) and am trying to fix a particular bug.  the bug had a patch, which i applied, and built a new package.  what is the best way to test the fix?  by that i mean, is it better to install the new deb and try it then?  what about when i'm done and want to restore the original package?  note that i'm working in a vm so not too concerned
<barry> about hosing the system.  i'm just trying to understand best practices
<lamont> barry: generally I wind up installing the package and going from there.
<lamont> though downgrading, while covered in the developer spec, is "not exactly the most robustly tested piece" to gloss over the ugliness that it can be - exactly how well, or even if, it works to go back to the old package with just a downgrade, depends on the packagea
<slangasek> james_w: "when you merge-package outside a shared repo" - what does "shared repo" mean, here?  Is there something I should have done differently on my side?
<barry> lamont: ah.  so does that mean over time, you end up with an environment that can have many in-development packages?  i guess as your changes get reviewed and accepted, they get uploaded and everything evens out
<slangasek> barry: pretty much, yeah
<barry> lamont: although it does make a good case for something even more lightweight than virtual machines (i.e. chroots)
<slangasek> once I've tested a package, the next step is to throw it at the archive :)
<james_w> slangasek: what you get with "bzr init-repo". It's not required, but it's an optimisation that can give big wins
<james_w> and also in this case means you sidestep the bug
<barry> slangasek: that makes sense!  one other question: what if my initial patch is not good enough and i need to revise it?  is it just: re-patch, rebuild, dpkg -i new.deb, rinse, repeat?
<slangasek> james_w: oh, hmm; does it have other benefits for one-off package merges?
<slangasek> barry: yes
<slangasek> james_w: rephrase: does it actually optimize anything for one-off package merges?
<james_w> slangasek: if you never move outside the one branch on your filesystem then it's an overhead of one command
<barry> slangasek: alright!  thanks!
<slangasek> barry: enjoy :)
<james_w> if you put multiple branches to your filesystem, then it's a win
<barry> :)
<slangasek> james_w: right; so for this kind of thing where my workflow is "bzr co lp:ubuntu/$pkg; cd $pkg; bzr merge-package lp:debian/$pkg; bzr resolve; bzr commit; bzr bd --source; cd ..; dput; rm -r $pkg", not actually an optimization :)
<james_w> correct
<slangasek> ok
<james_w> well, saying that, it avoids the bug
<slangasek> yeah
<james_w> and that's because it will be an optimisation to "merge-package"
<slangasek> in the present instance, I'm avoiding the bug by having done a MoM merge in the meantime :/
<james_w> I'll look in to making it not be needed for that optimisation
<james_w> I'll have to ask a bzr person the best way to that though
<lamont> slangasek: I've been quoted as to my sometimes-practice of fixing bugs
<slangasek> lamont: ?
<lamont> barry: if it's one of my packages, I tend to leave on my machines.  if it's not,  I downgrade the package after testing
<lamont> slangasek: something to the effect of "I frequently don't care about packages I uploaded 5 minutes ago" or some such
<slangasek> heh
<lamont> and well, sometimes my testing is a bit, um, sparse.
<barry> lamont: gotcha
<ccheney> http://www.phoronix.com/scan.php?page=article&item=ubuntu_1004_alpha1&num=1 <- ouch
<slangasek> ccheney: hmm, interesting postgresql benchmark results, does that imply that postgresql is calling fsync() too much?
<ccheney> slangasek: maybe, i'm not sure if phoronix has investigated it
<ccheney> slangasek: he did track down it was caused by the barriers code but not whether it was postgresql or something else running at the same time
<slangasek> well, presumably for a proper benchmark he wasn't running other stuff at the same time :)
<ccheney> but iirc tytso was wanting everyone to call fsync on every write a few months back
<slangasek> eh
<ccheney> yea hopefully not ;)
<ccheney> the don't fear the fsync blog entry
<ccheney> this seems to be a obvious case of yes fear the fsync
<slangasek> yes, didn't everyone reply to that blog entry and tell him he was on crack?
<directhex> what's the status of source format 3.0?
<ccheney> if it works the way the article says every fsync call flushes the full physical disk buffer
<directhex> ccheney, phoronix's benchmarking methodology is inherently flawed IME, and shows a deep understanding of how to make valid benchmarks
<directhex> i.e. heart in right place, execution not so hot
<slangasek> directhex: LP is supposed to get support for it next week; MoM shrieks whenever it sees it but we don't know why
<slangasek> (yet)
<ccheney> what i hope is that these changes fixed the problem where heavy disk io causes ubuntu to completely stop responding until it is done
<directhex> slangasek, so i should be reasonably comfortable uploading 3.0(quilt) to debian for somethign i want in lucid?
<ccheney> i don't care about a little lost performance if i can do disk io and something else at the same time, heh
<slangasek> directhex: it's imperative that we have support for 3.0 in lucid; whether that means you want to bet on the support landing when it's /supposed/ to is up to you
<slangasek> ajmitch: hi, what was the status of fixing boost1.40?
#ubuntu-devel 2009-12-10
<joens> does a repository with a debug kernel of 2.6.31-16 (latest karmic) exist, or is it necessary to build it your self?
<jpds> joens: http://ddebs.ubuntu.com/pool/main/l/linux/
<joens> thanks
<kirkland> nixternal: hey
<kirkland> nixternal: yo, you bolted before i answered your question ;-)
<kirkland> nixternal: figured it out?
<nixternal> kirkland: yeah, I added 'gcal_agenda=1' to $HOME/.byobu/status
<kirkland> nixternal: you're playing with the custom scripts?
<nixternal> now my next meeting shows up in my status :)
<nixternal> kirkland: yes I am
<kirkland> nixternal: building from source?
<nixternal> no, running karmic package on this machine
<kirkland> nixternal: hmm, oh, interesting
<kirkland> nixternal: well, i have that feature coming in 2.40, actually
<kirkland> nixternal: you'll be able to just put your own status scripts in ~/.byobu/bin
<nixternal> ya, I added it to /usr/lib/byobu, which I don't like with updates and what not, modified the common to add a backtick for it
<kirkland> nixternal: name them NN_NAME
<nixternal> ooh, now that is the hotness!
<kirkland> nixternal: where NN is the frequency in seconds to run
<kirkland> nixternal: and NAME is whatever you want to call it
<kirkland> nixternal: any executable script
<kirkland> nixternal: will be there very soon ;-)
<nixternal> definitely can't wait and will be following that one
<jml> hello
<nixternal> I like my Google Calendar Fridge feed for all of the meetings, and then it shows up in the status...yummy :)
<kirkland> nixternal: cool ;-)
<nixternal> ooh, Ubuntu Java Meeting tomorrow morning :)
<jml> who's the best person to talk to about https://dev.launchpad.net/Ubuntu/InfrastructureNeeds ?
<nixternal> jml: there is a 'contact us' link up top...that would be my first place to check
<jml> nixternal, that's about contacting the Launchpad developers
<jml> nixternal, I already know how to do that :)
<nixternal> kind of figured that, but I felt like being a bit of an ass :)
<jml> nixternal, :D
<Amaranth> jml: Who else would you need to contact for those?
<Amaranth> Looks like a launchpad wishlist from Ubuntu folks to me
<slangasek> james_w: bzr init-repo didn't help
<james_w> slangasek: oh, odd
<james_w> I tested the fix, the init-repo thing was just a guess
<slangasek> james_w: ah, ok
<IkoniaISaBITCH> IkoniaISaBITCH:
<IkoniaISaBITCH> [04:56] [474] IkoniaISaBITCH #xubuntu You're banned from that channel
<IkoniaISaBITCH> [04:56] [Notice] -ChanServ- [#kubuntu] Welcome to #kubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there. This channel is publicly logged. The official Ubuntu logs are at http://irclogs.ubuntu.com/
<IkoniaISaBITCH> [04:58] [474] IkoniaISaBITCH #kubuntu You're banned from that channel
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH V
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH
<IkoniaISaBITCH> IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH 
<IkoniaISaBITCH> BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A 
<IkoniaISaBITCH> IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA IS A BITCH IKONIA 
<jdong> heh...
<jdong> full moon?
<slangasek> no, that was last week
<netdur1> who to talk to in case I got (found?) security problem?
<RoAkSoAx> doko_, are there any plans of Ubuntu to participate in the GSoC 2010.
<RoAkSoAx> ?
<JanC> RoAkSoAx: maybe they will if you can convince them you can do something useful  ;)
<JanC> (IIRC there were some not-so-good experiences with GSoC in the past)
<RoAkSoAx> yeah probably. However I was just wondering since they were accepted for GSoC 2009 and after that they decided not to participate... so I just wondered if they time they were willing to go for it...
<dnivra_> I'm looking at the logs of Ubuntu Open Week's bug fixing session(https://wiki.ubuntu.com/MeetingLogs/openweekKarmic/BugFixing)
<dnivra_> I've successfully made all changes as per the logs in the source file. But when I run debuild -S, I get "gpg error occurred. debsign failed". how do i actually specify the gpg key while building the package?
<dtchen> -k . And, you may want to idle in #ubuntu-motu for these sorts of questions.
<dnivra_> oh right sorry :)
<pitti> Good morning
<dholbach> good morning
<mvo> hey dholbach!
<dholbach> hi mvo
<pitti> tjaalton: xserver-xorg-input-keyboard wants to go to universe, is that okay? -evdev for the win?
<davmor2> pitti: I came across a couple of issues yesterday jockey and fglrx didn't want to play and the other is in oem mode you lose the keyboard between setting up the end user and the end user gdm screen
<pitti> davmor2: fglrx> wasn't shown, or doesn't install?
<pitti> davmor2: losing keyboard sounds weird, do you happen to have an Xorg.0.log?
<davmor2> pitti: didn't install bug 494699
<ubottu> Launchpad bug 494699 in jockey "Ati binary driver failed to install using jockey" [Undecided,New] https://launchpad.net/bugs/494699
<davmor2> pitti: no once I restart the keyborad was fine again
<superm1> i dont think the driver in the archive yet supports 2.6.32
<davmor2> pitti: I think it is because when oem end user setup runs it's on the oem users account, however the keyboard is then set backup for the end user before you get to gdm and that I think is the bit that is breaking
<pitti> ok, fglrx bug changed accordingly
<tjaalton> pitti: yes, evdev replaces -keyboard/mouse
<pitti> davmor2: so you do oem-config-prepare, and then it stops working?
<pitti> tjaalton: should we just remove the package entirely perhaps?
<pitti> davmor2: but after a reboot you get the setup screen just fine?
<tjaalton> pitti: debian still has them, but we only have Linux, so.. maybe
<pitti> tjaalton: /me is in ~ubuntu-cruft-busters :)
<tjaalton> pitti: you rock :)
<tjaalton> and in the same boat
<davmor2> pitti: No you run oem-config-prepare and the keyboard is working.  You setup the new user.  It then pops up a window that says configure user...keyboard...etc.  You are then presented with the new user gdm but no keyboard so you can't log in.  However after a reboot the keyboard then works fine.
<pitti> ah, ok
<pitti> davmor2: I recently changed oem-config to do a proper input device triggering; that might have caused it
<pitti> davmor2: did you already report a bug? I think it belongs to me
<azteech> anyone know how long the ubuntu forums will be down - keep getting a database error page when I try to go there. been that way for couple hours now.
<davmor2> pitti: no wasn't sure what to drop it under
<pitti> davmor2: ubiquity (binary oem-config)
<pitti> davmor2: at least that's a likely candidate; I'll replicate it here and check
<davmor2> no probs I'll assign it to you :)
<pitti> tjaalton: removed and blacklisted
<tjaalton> pitti: thanks
<davmor2> is anyone else having issues with lp timing out when reporting bugs?
<cody-somerville> davmor2, at what stage?
<davmor2> I type in a description hit continue and it times out
<cody-somerville> try a shorter description
<cody-somerville> you can change it back after its done the dupe search
<davmor2> cody-somerville: nope timing out with just the word keyboard
<pitti> bah, it should time out on too short descriptions :)
<StevenK> pitti: gnome-mount used to be the way to check if stuff didn't mount, what's the new way?
<pitti> StevenK: devkit-disks --mount /dev/foo
<arthur_> doko: around?
<pitti> StevenK: or gvfs-mount, depending on what level you are debugging on
<arthur_> doko: when you update the svn-updates.diff patch, please use the command line in the top of the file (or tell me which one you're using so I can merge it)
<arthur_> +++ b/src/gcc/testsuite/gfortran.dg/recursive_check_15.f90 (.../branches/gcc-4_4-branch)
<arthur_> +++ gcc/testsuite/gfortran.dg/recursive_check_15.f90 (.../branches/gcc-4_4-branch) (revision 155122)
<arthur_> doko: ^ then the diff wouldn't be full of those...
<davmor2> pitti: zzzzzzzz worked as a description.  but more import bug 494942 for your browsing pleasure :)
<ubottu> Launchpad bug 494942 in ubiquity "keyboard fails at end user gdm" [Undecided,New] https://launchpad.net/bugs/494942
<StevenK> pitti: Hm. That works, but it doesn't mount automagically when I plug the key in
<pitti> StevenK: easiest is probably "ubuntu-bug storage" and let it figure out all the logging automatically
<pitti> StevenK: can you run "gvfs-mount -oi", then plug in the key, and then pastebin the output?
<pitti> davmor2: thank you!
<tseliot> pitti, cjwatson, kees: I've just noticed (from irclogs) that you started discussing my core-dev application. How and when shall we proceed?
<pitti> tseliot: can you make it to the next DMB meeting in two weeks? this Tuesday you had a national holiday and thus weren't online
<tseliot> pitti: is it somewhere on a google calendar?
<StevenK> pitti: Hmmm. What's supposed to make gvfs-mount spawn? Cause it ain't running.
<pitti> tseliot: yes, "DMB meeting"
<pitti> StevenK: it shouldn't be running; it's just a CLI for manual operations/debugging
<pitti> StevenK: the thing that automounts is nautilus
<pitti> through gvfs library calls
<tseliot> pitti: ok, I'll be there then
<arthur_> $ ls build/buildd-gcc-4.4_4.4.2-4-alpha-sKR6CD/gcc-4.4-4.4.2/testsuite
<arthur_> 21_strings  29_atomics  c-c++-common  gcc.c-torture  gcc.dg  gcc.target  g++.dg  gfortran.dg  libgomp.c  libgomp.fortran
<arthur_> doko: ^ in fact, you really screw up the upload :-(
<persia> pitti: Would you mind subscribing the fridge to that event?  ( http://fridge.ubuntu.com/calendar )  It doesn't show in the calendar there.
<pitti> persia: done
<persia> pitti: Thanks :)
<slangasek> smoser: have reviewed the publish-release commands now on https://wiki.ubuntu.com/UEC/Images/Publishing, and proposed a slightly different syntax; I fear the syntax actually has to be different for the devel release vs. past releases, given the current directory structure used for publishing (differing from how it's laid out on cdimage)
<slangasek> smoser: for publishing to hardy, your commands were correct - so perhaps you want to keep both commands on the page
<slangasek> cjwatson: is /etc/network/if-up.d/openssh-server still needed? ... because it doesn't work with NetworkManager.
<cjwatson> slangasek: I think it is; is this Debian #475188 perhaps?
<ubottu> Debian bug 475188 in network-manager "Uses ADDRFAM NetworkManager in 01ifupdown dispatcher script" [Normal,Open] http://bugs.debian.org/475188
<slangasek> cjwatson: heh, yes
<cjwatson> (which I maintain is an NM bug, using ADDRFAM for this is silly)
<slangasek> absolutely
<slangasek> but I stumbled upon it because it broke my samba SRU fix; I guess we don't want to fix NM's behavior in SRU
<cjwatson> mm, I certainly don't know what fixing this would break
<cjwatson> how did it break samba?
<slangasek> the samba SRU was to add an if-up.d script, copy-pasted from the openssh one ;)
<cjwatson> oh :-)
<cjwatson> depends how stubborn you want to be about getting the NM bug fixed, I guess
<cjwatson> I think it's probably actually relatively harmless to trigger a restart on ADDRFAM=NetworkManager as well - I just didn't want to give in without a fight and thus perpetuate the bug
<slangasek> I'm going to go with revving the samba SRU for now, Just In Case something relies on NM's goofy behavior here
<slangasek> and then I'm going to fix NM in lucid
 * cjwatson cheers
<slangasek> now if only I had a good way to fix NM to not bypass /etc/dhcp3/dhclient-enter-hooks.d :P
<sabdfl> mdz: DMB bit looks fine to me
<mdz> sabdfl, thanks, posted yesterday
<Tm_T> sabdfl: mdz: have to admit that combining -dev and -motu in that way is good start (:
<pitti> cjwatson: would you mind making me an admin of https://launchpad.net/~ubuntu-sru ?
<pitti> cjwatson: so that I can start doing the motu-sru merging?
<cjwatson> pitti: makes sense, done
<pitti> thanks
<mdz> pitti, can you explain the rationale for APPORT_FILES? (cf. 444975)
<mdz> I'm happy to provide a patch to get rid of it, but I assume you put it there for a reason
<mdz> ah, I think I see, it's used for more than just bugpattern matching
<mdz> it is less than ideal for bugpatterns though
<pitti> mdz, sabdfl: do you know what https://edge.launchpad.net/~registry is for, and why it is a member of ~ubuntu-sru?
<pitti> mdz: the primary intention was to limit what download() has to grab; often there are tons of other attachments on a bug which aren't necessary for dup checking, etc.
<sabdfl> no idea
<pitti> mdz: with the advent of free-form hooks and pattern matches it's tricky indeed; we could just drop it altogether and live with the overhead, I guess
<mdz> pitti, that team is magic; it is the owner for a whole bunch of projects
<sabdfl> i *thought* it was a team which owned a lot of "homeless, ownerless" projects
<pitti> can we make TB the owner of ubuntu-sru?
<mdz> pitti, no idea why it would be a member of ubuntu-sru
<mdz> pitti, who is the current owner?
<pitti> it feels weird to have 60 unrelated people being a member of SRU
<pitti> mdz: cjwatson
<mdz> pitti, yes, TB would be better
 * pitti changes then, thanks
<cjwatson> agreed
<pitti> "6  active members"
<pitti> now, that sounds much better than 67
<pitti> cjwatson: I can't change the owner, that probably needs to be done by you
<mdz> james_w,     SMTP error from remote mail server after RCPT TO:<ubuntu-distributed-development@lists.ubuntu.com>:
<mdz>     host lists.ubuntu.com [91.189.94.204]: 550 unknown user
<james_w> oops, ubuntu-distributed-devel
<cjwatson> pitti: done
<mdz> cjwatson, do you know whether d-i will detect and use a USB ethernet dongle?
<cjwatson> mdz: depends whether the module is available to it; AFAIK there is nothing especially special about them
<cjwatson> it's normally just like loading the module for a PCI network card, is it not?
<cjwatson> mdz: there is a 'nic-usb-modules' udeb with some appropriate-looking stuff in it
<mdz> cjwatson, yes, they're just usbnet I believe
<Daviey> mdz: I have one conencted now, and it depends on the usbnet kernel module.
<slangasek> luisbg: are you guys shooting for inclusion in alpha 1, or are you going to give it a pass?  images are posted to the tracker if you want them, but you only have a few hours left to test to be included in the announcement
<pitti> dholbach: grand unification: http://people.canonical.com/~ubuntu-archive/pending-sru.html
 * cjwatson rebinds "close window" to something other than Alt-F4 - deeply fed up of losing work because I tried to look at d-i's syslog and forgot to make kvm grab the keyboard first
<dholbach> pitti: neat :)
<cjwatson> pitti: how come ubiquity 2.0.10 isn't showing up as green? the bug has the verification-done tag
<pitti> hm, curious
<pitti> cjwatson: I'll debug that after lunch
<slangasek> superm1: what's the outlook for mythbuntu/amd64 testing for alpha1?
<jdstrand> pitti: hi! I am using the postgresql-common testsuite, and it is mostly working, but have a couple questions-- do you have time to help me?
<pitti> jdstrand: I'm off to lunch now, but just shoot; back in ~ 30 mins
<jdstrand> pitti: ok thanks
<jdstrand> pitti: I'll get you when you come back
<blackxored>  I'm about to upload an azureus revision for new upstream into ubuntu, but I had to diverge since 3.0 format isn't in lucid yet, so you think is ok to upload this merge, otherwise it would be a sync eventually
<Laney> 3.0 will be available soon
<Laney> you could wait a few days
<blackxored> all right, I can wait a week more or so, what do you think? 4.3.0.0-1 is on sid since dec-2
<cjwatson> I *believe* that it's due for Launchpad 3.1.12, https://dev.launchpad.net/Releases/2009Calendar
<ScottK> Laney: For a lartge value of few, I think that's true.  Given it's already slipped once, I wouldn't make assumptions about when it will land.
 * cjwatson goes to check LP bzr
<Laney> ScottK: Oh, someone gave me a date, but I don't know if it was authoratative
<ttx> mdz: installer doesn't seem to pick up the USB NIC when run from "kvm -usb -usbdevice net:"
<mdz> cjwatson, ^ FYI
<mdz> ttx, did you check that it shows up as a device correctly inside the vm?
<mdz> ttx, is usbnet loaded?
<ttx> mdz, cjwatson: it shows up in lsusb. usbnet module doesn't get autoloaded.
<mdz> ttx, maybe we need to specify some options to kvm to get the right flavour of device?
 * ttx looks
<mdz> ttx, it looks like the default is for an RNDIS device. we need it to act like a CDC device
<mdz> (maybe)
 * ttx looks for some usbdevice net:options doc
<pitti> jdstrand: re
<cjwatson> mdz,ttx: I think the problem is simply that cdc_subset is missing from nic-usb-modules
<cjwatson> -> kernel bug
<cjwatson> mdz,ttx: lsusb lists 0525:a4a2, which is matched by cdc_subset
<mdz> cjwatson, I just got there myself ;-)
<wgrant> ScottK, Laney, cjwatson: We're right now testing out 3.0 support on dogfood. Landing the branch is currently blocked on getting the new dpkg into all of the test images. That should happen on Monday, immediately after which things can land, in time for the release on Wednesday.
<pitti> yay!
<wgrant> But possible holdups after that are with the buildds. I don't know how they're going.
<cjwatson> mdz,ttx: actually, I think cdc_ether would be better
<jdstrand> pitti: hey, first for all releases I generate the following locales using locale-gen: 'en_US', 'en_US.UTF-8', 'ru_RU', 'ru_RU.UTF-8', but 050_encodings.t fails two tests in hardy and later (dapper fails more, but we'll take about that later)
<pitti> jdstrand: oh, which?
<jdstrand> pitti: well, the numbers are different depending on the release, but for karmic:
<jdstrand> not ok 18 - Server error message has correct language and encoding
<jdstrand> not ok 39 - Server error message has correct language and encoding
<ttx> cjwatson: if you can tell me which model should be currently matched by nic-usb-modules, I can buy those
<cjwatson> mdz,ttx: it's less limited, and matches more devices. Plus Debian's nic-usb-modules includes it.
<pitti> jdstrand: oh, did you install the russian language packs?
<cjwatson> ttx: cdc_ether should match a wide range of stuff
<pitti> jdstrand: you need those to get error messages actually translated
<cjwatson> oh, currently?
<pitti> jdstrand: (sorry, I usually test with local builds)
<jdstrand> pitti: no-- which do I need?
<pitti> jdstrand: language-pack-ru shoul ddo
<jdstrand> pitti: cool, that is a big help
<jdstrand> pitti: couple other things:
<ttx> cjwatson: if cdc_ether should be fixed anyway, let's go for that fix. If it looks specific, then I should shop an already-supported one
<pitti> jdstrand: I picked Russian back then because I still moderately understand it, and it uses a highly nondefault legacy encoding, and non-latin glyphs
<jdstrand> pitti: has another failure: not ok 20 - pg_maintenance works as user postgres with appropriate directory permissions
<cjwatson> ttx: nic-usb-modules currently includes: catc kaweth pegasus prism2_usb rt2500usb rt2570 rt73usb rtl8150 usbnet zd1201 zd1211rw. But we should just fix nic-usb-modules to include cdc_ether too.
<cjwatson> ttx: could you file a bug on linux (or reassign, as appropriate)? it's a one-line fix
<jdstrand> pitti: using russian is an excellent idea, I just missed the langpack :)
<ttx> cjwatson: thanks (and agreed)
<jdstrand> pitti: oh, that failure was on in 8.10
<cjwatson> ttx: http://paste.ubuntu.com/338682/
<ttx> bug filing in progress
<jdstrand> pitti: (the pg_maintenance one)
<pitti> jdstrand: oh, hm, that code has gone entirely
 * jdstrand thought he typed it but realized he only thought it
<pitti> jdstrand: getting the intrepid version
<jdstrand> pitti: well, it is 8.10-- I don't mind listing that as an expected failure. no biggie really
<pitti> jdstrand: it should give you a diff of expected vs. actual output, does it?
<jdstrand> pitti: what this is all about is I have written a qa-regression-testing script that can be run in an automated fashion for the server team
<jdstrand> pitti: it does, but I don't have it atm-- let me get it
<pitti> jdstrand: I remember that there was a bug that it tests "grp" vs. "own" in a particular order, but sometimes the order is reverse
<pitti> jdstrand: so it was really a test suite bug
<jdstrand> pitti: I am pretty sure that is the issue
<pitti> it's fixed now, since pg_maintenance went away completely
 * jdstrand will double check and get back to you though
 * jdstrand nods
<jdstrand> 9.04 and later don't have it
<pitti> jdstrand: cool, thanks for caring about this
<jdstrand> pitti: lastly (and I have the error output), lucid has three failures
 * jdstrand goes to paste it
<jdstrand> pitti: it's been long on my todo list, and I have pygresql update that I am going to toss into the qrt script anyway, so we all win :)
<ttx> cjwatson: filed as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/495060
<ubottu> Ubuntu bug 495060 in linux "nic-usb-modules should include cdc_ether" [Undecided,New]
<jdstrand> pitti: http://paste.ubuntu.com/338683/
<cjwatson> ttx: thanks, signed-off
<pitti> jdstrand: hm, it looks like you have existing clusters somewhere?
<pitti> jdstrand: hm, no
<pitti> jdstrand: let me run it here and see whether I can reproduce
<jdstrand> pitti: this is in a schroot, and I did the following apt-get: http://paste.ubuntu.com/338685/
<jdstrand> (I don't have postgresql running on the host, or in any other schroots)
<pitti> jdstrand: test suite running
<mdz> ttx, confirmed that when cdc_ether is loaded, the kvm device gets connected to eth1. the installer should be perfectly happy with this
<ttx> mdz: great!
<mdz> ttx, I also pinged rtg on #-kernel and asked him to make sure the fix gets applied in lucid
<jdstrand> pitti: lastly, and I'm not sure how important this is cause I can whitelist the failures in the qrt script, but Dapper's 8.1 has the following issues: http://paste.ubuntu.com/338688/
<pitti> cjwatson: oh, I know -- bug 473241 is private
<ubottu> Bug 473241 on http://launchpad.net/bugs/473241 is private
<jdstrand> pitti: (the 'failed_ok.append' stuff is part of the qrt script
<pitti> cjwatson: that's why sru-report can't figure it out
<cjwatson> mdz: I missed the background; not that I'm arguing this should be fixed, but why is this of right-now importance? :)
<pitti> cjwatson: moving to -updates then
<cjwatson> pitti: ah, thank you
<apw> cjwatson, the fix in bug #495060 which you have added a s-o-b were you the author there?
<ubottu> Launchpad bug 495060 in linux "nic-usb-modules should include cdc_ether" [Undecided,New] https://launchpad.net/bugs/495060
<jdstrand> pitti: are there any additional things I need to get dapper going?
<cjwatson> apw: yes
<apw> thanks
<jdstrand> pitti: or is Dapper known to fail some tests?
<pitti> jdstrand: 020_create_sql_remove.t just succeeded here, hm (current lucid alpha-2, install from yesterday)
<pitti> jdstrand: dapper's tests are a bit brittle
<pitti> jdstrand: but the first few should succeed
<pitti> jdstrand: that's strange, though, it should not fail that badly
<mdz> pitti, argh, TB is getting spammed with SRU bug email now
<jdstrand> pitti: I'll update the schroot (and add the langpack) and try lucid again
<jdstrand> pitti: are you doing this in a chroot or vm?
<pitti> jdstrand: in my normal production system
<pitti> mdz: I disabled TB as a member (it's still the owner)
<mdz> pitti, hopefully that will fix it
<pitti> mdz: it landed in the moderation queue?
<superm1> slangasek, i think we're gonna have to skip it.  major issue right now with mysql not being able to be spawned in the chroot with no good solution
<pitti> jdstrand: oh, hang on
<slangasek> superm1: ah; is that a blocker for alpha1 altogether for you?  It looked like the frontend install went ok?
<pitti> jdstrand: can it be that your chroot does not have a default locale set?
<pitti> jdstrand: it expects to have a default UTF-8 system locale
<mdz> pitti, moderation queue?
<pitti> mdz: oh, TB doesn't have the ML set as contact point? Ignore me then
<pitti> jdstrand: I ought to check that in t/001_packages.t
<jdstrand> pitti: ah!
<superm1> slangasek, yeah, it's a blocker
<jdstrand> pitti: that should fix 020_create_sql_remove.t and 130_nonroot_admin.t, but would it also fix 090_multicluster.t?
<slangasek> superm1: ok
<mdz> pitti, no, it got emailed to me directly
<pitti> jdstrand: no, the 090 one is a bit of a mystery to me; it should try ports in order
<superm1> slangasek, i'd say its okay to skip a1 for mythbuntu and we'll have something figured out by a2
<jdstrand> pitti: if you are going to update t/001_packages.t, can you also add the following: libpq-dev libpqxx-dev?
<pitti> jdstrand: btw, 050_encodings still fails in lucid, since the Russian translations were removed due to being too incomplete
<pitti> jdstrand: seems I need to use another language for the tests now :-(
<jdstrand> :(
<jdstrand> pitti: re libpq-dev libpqxx-dev I noticed they were needed for the pg_config tests
<pitti> jdstrand: I'll add a test for -server-dev, which implies libpq-dev
<pitti> jdstrand: but the tests don't need libpqxx
<pitti> it's a totally separate project
<jdstrand> pitti: hmm-- I installed libpq-dev only, and something failed until I installed libpqxx-dev
<pitti> that'd be strange
<jdstrand> well, I can track it down
<jdstrand> give me a few minutes :)
<jdstrand> pitti: ok, really lastly: and this is purely fyi, I noticed that 8.3 testsuite looks for /usr/lib/postgresql/8.3/bin/pg_config, but pg_config is in /usr/bin. Lucid had the some issue, but with /usr/lib/postgresql/8.4/bin/pg_config (though oddly, karmic didn't)
<jdstrand> pitti: I just create a symlink in the qrt script to work around it, and it works fine that way
<jdstrand> s/some/same/
<pitti> bzr commit -m 't/001_packages.t: Check that the system default locale is an UTF-8 one.'
<pitti> jdstrand: ^
<pitti> jdstrand: I also added a check for -server-dev
<pitti> jdstrand: that's deliberate
<pitti> jdstrand: and which is why -server-dev is required
<mdz> zsync is my new favourite thing
<pitti> jdstrand: client-side packages should use /usr/bin/pg_config (latest version)
<jdstrand> pitti: the pg_config is deliberate?
<pitti> jdstrand: server-side extensions need the per-version pg_config in /usr/lib/
<jdstrand> ah, ok
 * jdstrand will adjust the scripts accordingly
<mdz> ionice -c3 zsync -i karmic-dvd-i386.iso -i lucid-desktop-i386.iso -i lucid-server-i386.iso -o lucid-dvd-i386.iso -k lucid-dvd-i386.iso.zsync http://cdimage.ubuntu.com/dvd/current/lucid-dvd-i386.iso.zsync
<jdstrand> pitti: you've been a huge help, thanks! :)
<pitti> jdstrand: I usually test with having two or three major versions installed, so that I can test upgrades/migration/conffile argument rewriting
<barry> ls
<pitti> jdstrand: so, I'm still puzzled about the 090 breakage
<pitti> barry: rm -rf ~
<jdstrand> pitti: are you seeing it too?
<barry> pitti: ;)
<pitti> trying (it stopped at 050)
 * jdstrand nods
<pitti> jdstrand: no, went through
<cjwatson> mdz: oh, that's nice
<jdstrand> pitti: ok, let me get all the packages installed and the locale setup and try again
<mdz> cjwatson, especially for those of us who don't maintain a local mirror
<ttx> cjwatson: just had a look at ~cjwatson/eucalyptus/cloud-preseed, nothing stands out as obviously wrong :) More feedback when you'll land it and we'll be able to test it :)
<cjwatson> ttx: thanks
<ttx> cjwatson: I will land lp:~ttx/eucalyptus/autoregistration shortly after you. It adds non-destructive support for the uec-component-listener, with action scripts that just log what was detected. That should allow us to validate the annouces before switching from local-registration to auto-registration.
<cjwatson> ttx: right
<WeazelON> Hey guys, i've re-install karmic a few days ago, and did it from an external cdrom via USB,  now for some reason, i've noticed, that ubuntu doesn't recognize my internal cdrom-- when i reboot and at the POST/bios  cdrom can eject and it seems to work.
<mdz> cjwatson, FYI, the result of that command was Target 77.8% complete.
<mdz> (zsync)
<mdz> robbiew, proposal that the chair select an order at the start of the meeting and we proceed according to that ;-)
<robbiew> mdz: who's the chair? me or randa?
<mdz> robbiew, I defer to the chair to answer
<robbiew> heh
<mdz> who is it making this announcement at CES?
<robbiew> mdz: you realize your in ubuntu-devel?
<mdz> robbiew, heh
<robbiew> ;)
<smoser> i'm trying to test server install , and on reboot i don't come all the way up.  I get a flashing '.'  aparently consoles are set up (alt-f2, alt-f3 change the position of the .).
<smoser> this is after screen changes mode. i took off quite and splash.
<smoser> any clues?
<smoser> ttx, see above, blocking my node controller test.
<slangasek> smoser: check tty8 for messages
<slangasek> ?
<ttx> smoser: is network up ? ssh up ?
<jdstrand> pitti: ah, I didn't have to do the symlink on karmic cause I already had postgresql-server-dev-8.4 installed :)
<smoser> no change of '.' location for alt-f8, as if its not there. for all other f1-f7 it moves back and forth (1 is at bottom, others at top)
<smoser> ttx, no network
<slangasek> smoser: boot with nomodeset option? (what video chipset?)
<smoser> nbono idea. dell inspiron 531. i have to google.
<smoser> s/nbono/no/
<smoser> slangasek, nomodeset brought it up
<slangasek> smoser: ok - now you can check the chipset and file a bug on the kernel :)
<smoser> it was confusing to me that the screen still does flash on 'nomodeset', but then after being a bit patient the login prompt just appeared.
<smoser> being new to grub2, where can i put 'nomodeset' so i dont have to walk down to my basement if i want to reboot this thing?
<cjwatson> /etc/default/grub GRUB_CMDLINE_LINUX
<cjwatson> and see instructions on first two lines
<smoser> thank you cjwatson .
<mdz> smoser, hmm, I wonder if we shouldn't disable that by default for servers?
<ion> I like to have modesetting on my server. When i need to stab it with a keyboard and a monitor, itâs nice to have a good resolution.
<mdz> ion, yes, I agree it's nice to have as an option, but I'm not keen to see regressions like smoser has where the console is unusable
<ion> Itâs a bug and it should be fixed. If one âfixesâ it by disabling KMS on servers, a desktop user will sooner or later have the same problem when trying to do something in a virtual console.
<dholbach> did anybody see anything like this on karmic: http://people.canonical.com/~dholbach/IMG_5925.JPG ?
<dholbach> this is after booting
<slangasek> I also can't think of a good way to have different kernel module defaults on server vs. desktop sysems (only a series of ugly ones...)
<mdz> ion, I didn't say "don't report that bug" or "don't fix it".  I wondered aloud if we should change the default setting.
<mdz> slangasek, /etc/modprobe.d/ubuntu-server.conf
<slangasek> dholbach: not me
<dholbach> anything I should have a look at?
<slangasek> mdz: and if the admin installs gdm (which I understand some folks like to do), it will fail to run?
<mdz> slangasek, Conflicts: ubuntu-server-default-settings
<slangasek> dholbach: find a set of boot options that lets you get to a console?
<slangasek> mdz: hum, that's not so bad then, yeah
<mdz> slangasek, I can imagine some other parameters which might be worth tweaking
<dholbach> slangasek: ctrl-alt-f1 and back to ctrl-alt-f7 and I got the regular login window
<slangasek> mdz: though, Conflicts: doesn't force removal of conffiles
<dholbach> tseliot: http://people.canonical.com/~dholbach/IMG_5925.JPG <- ever seen anything like this on machine startup?
<slangasek> dholbach: Kubuntu or Ubuntu?
<seb128> got a similar screen on boot on karmic yesterday
<seb128> ubuntu
<Riddell> I havn't
<dholbach> slangasek: ubuntu
<slangasek> seb128: Kubuntu or Ubuntu? ;)
<slangasek> mmk
<tseliot> dholbach: ouch, no, what card card/os version are you using?
<seb128> slangasek, ubuntu on ati card with open source driver
<dholbach> tseliot: karmic, nvidia something, using nv driver
<seb128> but that was a one time thing, ie next boot was fine again
<maco> unhappy drm? when i tried using 2.6.32 on karmic, the kubuntu logo was drawn but in funny colors like that
<slangasek> if it were kubuntu, there's the just-fixed regression where gdm + kdm + failsafe-x == two X servers running
<dholbach> as I said: ctrl-alt-f1 and back to ctrl-alt-f7 and I got the regular login window
<slangasek> dholbach: what about ctrl-alt-f8?
<dholbach> slangasek: that's some funny colours too
<tseliot> dholbach: maybe a /var/log/Xorg.0.log (after reproducing the bug) can help
<ogra> we call that art over here
<slangasek> dholbach: check if you have more than one X server running..
<slangasek> dholbach: maybe failsafe-x is running in parallel for some reason
<dholbach> slangasek: just one
<slangasek> hmm
<slangasek> usplash?
<dholbach> no failsafe
<dholbach> no usplash
<slangasek> wonder what's on vt8 then
<dholbach> tseliot: I'll get you a fresh Xorg log when it happens again
<slangasek> dholbach: sudo fuser -v /dev/tty8?
<tseliot> dholbach: ok, thanks
<dholbach> slangasek: says nothing
<slangasek> strange
<pitti> mdz: still got sru spam? I sent some 30 mails by now, I think
<pitti> (after deleting techboard as a member)
<pitti> free: rejecting your intrepid smart upload, there's no bug link
<mdz> pitti, no, looks good now, thanks
<jdstrand> pitti: fyi 090_multicluster.t works after setting the default locale to UTF-8
<jdstrand> pitti: so lucid is now clean, excepting the russion removal issue (which also affects karmic, btw)
<jdstrand> russian
<pitti> right
<pitti> I'll fix the test case for this soon
<jdstrand> pitti: no rush, but if you can ping me when you do, that would be great
<slangasek> smoser, zul: I see two UEC/EC2 images with results outstanding (EU amd64 EC2, UEC amd64) - is testing in progress on those?
<smoser> UEC amd64 i'm about finished with.
<smoser> and i tested single of EU amd64 EC2 yesterday
<slangasek> ah, refresh shows results now, ok
<cody-somerville> cjwatson, is that frame buffer issue still affecting lucid GTK d-i images?
<cjwatson> cody-somerville: which issue is that?
<cody-somerville> cjwatson, you have the GTK d-i images disabled from building
<cody-somerville> you quoted a framebuffer issue
<cjwatson> I know it's completely broken in Debian right now
<cjwatson> I asked bratsche if he could have a look at it and gave him a reproduction recipe, but he hasn't got back to me yet
<cjwatson> I did attempt to fix it but it's a GTK bug that's well beyond me
<slangasek> plars: can bug #494787 be un-privatized?
<ubottu> Bug 494787 on http://launchpad.net/bugs/494787 is private
<plars> slangasek: I'd love to, but unfortunately I can't access it anymore
<highvoltage> ooh, is lucid getting gtk d-i?
<cjwatson> unlikely at the current rate, and it wouldn't be the default anyway
<plars> slangasek: in my attempt to subscribe someone else, I accidentally hit the unsubscribe button instead
<slangasek> plars: blink - were you the submitter?
<slangasek> stgraber: ^^
<plars> slangasek: yep
<slangasek> plars: what package was it filed on?
<plars> slangasek: it was a segfault with firefox-3.5
<slangasek> ok
<slangasek> asac: ^^ do you have access to make bug #494787 public?
<ubottu> Bug 494787 on http://launchpad.net/bugs/494787 is private
<plars> slangasek: He didn't have access to it either, which was why I was originally trying to subscribe someone else
<slangasek> ah
<JordiGH> Is there a channel for discussing app development in Ubuntu?
<slangasek> pitti: do /you/ have access to make that bug public? :)
<JordiGH> #ubuntu is too noisy to chat about libs and headers and stuffs.
<pitti> slangasek: not as me, let me try as apport
 * stgraber didn't know one can loose access to his own bugs ;)
<plars> pitti: it was file indirectly through apport-cli, then using the provided url on another machine.  It hasn't been retraced yet
<jmarsden> JordiGH: App development would usually not be distro-specific, so maybe go to a language-related channel instead?
<plars> stgraber: filed a bug about that on lp last night after doing it :)
<pitti> plars: no, can't; there are no retracers for lucid yet; incidentially I'm just setting up chroots
<pitti> plars: can there be anything private in this crash?
<pitti> plars: like, is this a "production" firefox profile
<pitti> ?
<plars> pitti: it was purely a test machine, should be plenty safe
<JordiGH> jmarsden: Okay, how about a discussion on how to setup boost in Ubuntu order to compile old code?
<pitti> slangasek: public now
<pitti> plars: thanks for confirming
<slangasek> yay
<plars> pitti: thanks!
<jmarsden> JordiGH: Unless Boost is "special" in Ubuntu, which I somewhat doubt, wouldn't a C++ related channel work for that?
<JordiGH> jmarsden: Its packaging is special.
<jmarsden> JordiGH: I'm not sure there's enough interest in distro-specific app development issues, but you could try starting #ubuntu-application-development (or #ubuntu-app-dev) and see if others join it... I'd just ask in a C++ channel, where many people will be familiar with Boost, and explain anything that is truly Ubuntu-specific.
<JordiGH> jmarsden: ##c++ is only about standard C++, not about how Boost is packaged in Ubuntu. :-/ Oh well, I guess we can start a new channel to talk about Ubuntu-specific matters more interesting than how to setup a network or video card.
<jmarsden> JordiGH: OK.  I've packaged software for Ubuntu that uses Boost with no issues, just Depends: on the relevant liboost package... seems to work for me, but maybe I was lucky.
<slangasek> the boost packaging isn't Ubuntu-specific, btw, it's inherited from Debian
<JordiGH> Yeah, I'm never sure if Ubuntu modifies Debian packages or not (I guess I could look at changelogs every time), so best to just assume an Ubuntu framework overall.
<ScottK> JordiGH: There are generally some minor modifications.  The most common ones are for when we have different Python versions than Debian.   We also don't ship the mpi bits for any boost in Main because no package uses it and we don't want to drag all of MPI into main.
<ScottK> So unless you're using MPI, it shouldn't matter between Debian/Ubuntu
<knandan> Hi ..
<knandan> can i discuss red-hat packaging here?
<slangasek> ... no
<JordiGH> That seems like a strange question... why would you think you could? Unless you're converting an .rpm, to Ubuntu, perhaps?
<knandan> slagasek: thanks for your reply..
<syn-ack> well, there are RPM dev tools in the repos. :P
<knandan> can anyone plz suggest me some appropriate channel for that
<syn-ack> Don't know why anyone would want them though
<syn-ack> knandan, #rpm
<slangasek> syn-ack: there are many things in the repos that are off-topic for this channel :)
<syn-ack> hehehe
<pitti> #fedora-devel perhaps, too
 * syn-ack hrms
<syn-ack> I can't figure out why this aa profile is making my ld avg skyrocket
<knandan> thanks guys..i will give it a try on these channels
<cody-somerville> If there a virtual package provided by only one package will apt install it?
<persia> cody-somerville: Depending on how it is called, quite possibly.
<persia> cody-somerville: For example, try `apt-get install ssh-client` which works.  This doesn't always work in all automated situations.
<james_w> lool, maxb: rich history branches of python-defaults up, please let me know of any issues
<maxb> nice, thanks.
<maxb> I'll have to work out how best to rebase/replay some stuff
<cwickert> ping jono
<ScottK> james_w: Where?  I'm interested for the same reasons lool is.
<james_w> ScottK: in the usual place
<ScottK> Thanks
<james_w> lp:<distro>/<series>/python-defaults
<cwickert> jono: any chance you release tarballs of lernid?
<jono> cwickert, there should be the tarballs in Launchpad
<jono> cwickert, I am kicking out a new release today in fact :)
<jono> cwickert, about to write up a blog post :)
<jono> well, after some breakfast
<jono> :)
<jono> cwickert, the next version will have much of the distro specific bits removed
<cwickert> jono: that was the reason for me to ask, thanks ;)
<cwickert> great!
<jono> :)
<jono> cwickert, see https://edge.launchpad.net/~jonobacon/+archive/ppa/+packages
<jono> click on Lernid
<jono> the tgz is linked in there
<jono> it is not yet built in the PPA
<cwickert> thanks jono
<jdstrand> pitti: so I think I was on crack when I said libpqxx-dev was needed
<jdstrand> pitti: the qrt script works without it in a fresh lucid schroot snapshot
<jdstrand> pitti: so it is all working well now (though I need to double check the intrepid failure still)
<jdstrand> pitti: big thanks for your help :)
<jdstrand> pitti: on a totally unrelated note, I noticed that in http://piware.de/workitems/qa/lucid/report.html I am listed under soren's name for qa-lucid-automated-server-testing
<jdstrand> oh, I see qa-lucid-automated-server-testing has '*' prepended to all the work items...
<pitti> jdstrand: right, that's misformatted
<jdstrand> soren: ^ that should probably be fixed so the reporting work's right
<james_w> pitti: where's the code that dupes python tracebacks? I can't see it in lp:apport
<jdstrand> s/probably/needs to be/
<jdstrand> :)
<pitti> james_w: no, it's in the ubuntu branch (lp:~ubuntu-core-dev/ubuntu/lucid/apport/ubuntu)
<pitti> james_w: hang on, I lie; bin/crash-digger is in trunk, too
<pitti> james_w: def dupcheck_next()
<james_w> thanks pitti
<jdstrand> soren: I updated that one
<cjwatson> bdmurray: would ubuntu-patch-reviews be materially different from ubuntu-reviews?
<pitti> smoser: I have a question for you in https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-desktop-cloud, when you have a minute (see whiteboard)
<smoser> pitti, ok
<smoser> pitti, regarding nx server in main...
<smoser> in karmic we pruned our -server images of non-main software
<persia> cjwatson: I have opinions about semantic differences there, if you're looking for exposition.  If you're looking for a specific answer to a specific reference, I'll refrain.
<smoser> but rickspencer3 says that for -desktop, a nx server outside of main (even ppa) would be OK.
<rickspencer3> yes
<pitti> smoser: so that would be an addon package for just this image? sounds fine
<rickspencer3> these images are not official distros
<smoser> i would suggest against nx server in main for lts
<smoser> so then thats settled.
<bdmurray> cjwatson: ubuntu-patch-reviews would be subscribed to bugs w/ patches and dholbach had concerns regarding the volume of mail and possible off-topicness of messages
<jdstrand> pitti: fyi (last one!)-- finally got to the intrepid failure: http://paste.ubuntu.com/338813/. looks like the reverse order of "grp" and "own" like you said. I'll continue to ignore that failure
<pitti> jdstrand: right, seems fine to exfail that
<pitti> well, not really "exfail", it can very well succeed
<pitti> "ignore" is a better one
<mjr> if there're upstart people around, it seems that there's fun stuff like if /home is luks-encrypted, things stop as they should to prompt for passphrase, but at the same time some other component gets pissed that /home isn't properly mounted and prompts for root maintenance. Apparently the two compete for keypresses such that it's rather difficult to get it into a state where you can actually input the passphrase to make it happy. Whassup?
<jdstrand> pitti: I ignore the failure. if it passes, it's still ok
 * jdstrand moves on to actually test pygresql now
* slangasek changed the topic of #ubuntu-devel to: Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> slangasek: congratulations!
<pitti> and sleep well :)
<cjwatson> bdmurray: hmm. it just seems like slightly odd duplication to me but if it's already been discussed then I'm happy to defer
<ebroder> pitti: When I verify SRUs, is it OK to add the verification-done tag, or should I wait for you to do that?
<flower> which file determines which groups a user belongs to in Ubuntu and how to add another group for an customized ubuntu installation cd?
<persia> flower: You may find section 10.9 useful.
<CarlFK1> does "fix committed" mean there is a patch file included in the ubuntu packaging, or that the gtk devs fixed what lucid will build from?  https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/491732
<persia> Err, section 10.9 of Debian Policy
<ubottu> Ubuntu bug 491732 in gtk+2.0 "GDK_BUTTON_MOTION_MASK appears to be broken" [Medium,Fix committed]
<Laney> CarlFK1: the comment explains
<RoAkSoAx> doko, by any chance do you know if there's a plan to participate in the GSoC2010?
<persia> (or maybe section 9.2)
<CarlFK1> Laney: the comment does not tell me how ubuntu is making use of the upstream fix
<cjwatson> pitti: the endpoint of the foundations alpha-2 burndown chart is wrong
<pitti> cjwatson: fixed
<pecisk> gnome-settings-daemon eats up all memory very fast in Alpha1 Live CD env.
<chrisccoulson> pecisk - please try disabling plugins and re-enabling them one-by-one
<chrisccoulson> gnome-settings-daemon hasn't really changed yet in lucid, so it's likely to be some library it's using
<pecisk> chrisccoulson, which plugins exactly you mean?
<chrisccoulson> the g-s-d plugins. it's basically based around a load of random plugins
<chrisccoulson> you can disable them in /apps/gnome_settings_daemon/plugins
<pecisk> nice
<pecisk> will try
<chrisccoulson> thanks
<ScottK> cjwatson: Is it intended that kubuntu-dev would have access to Kubuntu seeds?
<ScottK> Apparently they (he, there's only one who isn't also core-dev at the moment) doesnt.
<cjwatson> ScottK: we probably ought to move them - although unfortunately that requires a Launchpad code change
<ScottK> cjwatson: OK.  So I guess that qualifies as it's desirable, but not immediately possible.
<smoser> general question... does anyone think it would be beneficial to use have ec2 root filesystems as ext4? currently they're ext3.  kees maybe you have a thought (per your adding ext4 to vmbuilder patch)
<cjwatson> ScottK: a transition period will be desirable anyway, so we could have ~kubuntu-dev branches which somebody regularly re-pushes to ~ubuntu-core-dev
<cjwatson> but yes, it's definitely intended that seed commit privileges match upload privileges, in general
<persia> Is a LP code change required for each separation of a team, as in a hardcoded definition per-seed?
<ScottK> cjwatson: I'm starting to feel like there ought to be a project for archive reorg to file bugs against so things like this and package permission adjustments get tracked.
<cjwatson> persia,ScottK: actually, now that I look at it, I'm mistaken
<cjwatson> Launchpad runs germinate with default parameters which point to the seed mirrors on http://people.canonical.com/~ubuntu-archive/seeds/, and those can be redirected straightforwardly by us
<persia> So it's just a change to ${FLAVOUR}-meta/update.cfg ?
<cjwatson> that and a bit of work by somebody in the ubuntu-archive team
<cjwatson> I'm on leave tomorrow, but if somebody in ~kubuntu-dev wants to coordinate with me on Monday, I'd be happy to sort it out
<kees> smoser: it more closely matches all other Ubuntu installs -- I would recommend it.
<kees> smoser: in theory, it's also faster.
<ScottK> cjwatson: Thanks.
<cjwatson> ScottK: I agree - I'll set that up on Monday, unless somebody wants to beat me to it
<Riddell> ScottK, cjwatson: do we know why ~kubuntu-dev can't upload kde4libs?
<cjwatson> because kde4libs is in the middle of all sorts of (build-)dependencies in core
<cjwatson> WARNING: foundations-lucid-non-applications-in-software-center: assignee "mvo" is not a valid Launchpad account
 * cjwatson stares at launchpad-work-items-tracker
<cjwatson> Riddell: I think this is basically covered by my comments in https://lists.ubuntu.com/archives/ubuntu-devel/2009-November/029623.html
<cr3> if I want to test bringing the network interface up and down again multiple times, should I use the network manager dbus interface, /etc/init.d/networking, or perhaps something else?
<Keybuk> cr3: depends on what's managing the network interface, surely?
<cr3> Keybuk: what I don't understand is if I run /etc/init.d/networking or ifdown eth0 even, then network-manager still seems to be able to manage the interface
<Keybuk> yes
<Keybuk> why do you expect otherwise?
<cr3> Keybuk: I thought that if the interface was down, it couldn't be used anymore until it was up again
<Keybuk> no
<Keybuk> I think you're confusing yourself
<Keybuk> if NM is managing an interface, it'll bring it up and down whenever it likes
<Keybuk> if you bring it down (or up!) yourself
<Keybuk> NM will fiddle with it again later
<Keybuk> if ifup is managing an interface (ie. its listed in /etc/network/interfaces) then NM won't get involved
<cr3> Keybuk: might there be a better way to determine who is managing an interface other than parsing /etc/network/interfaces?
<Keybuk> no
<cr3> cool, I think I could get pretty far assuming a vanilla interfaces file generated automatically
<smoser> rickspencer3, i started a -desktop build, the i386 vmbuilder portion finished successfully, we'll see if the amd64 and then publish do as well .  http://paste.ubuntu.com/338963/ has package list of i386-desktop "cloud edition"
<rickspencer3> smoser, sweet!
<doko> Rocket2DMn: please ask dholbach or jcastro
<nixternal> pitti: your workitem reports stuff....the script...what is it looking for in reference to the wiki? example, for Kubuntu stuff, it is reading the raw version of Kubuntu/Todo/Lucid, and I am guessing your script parses the stuff...the only ones showing up with someones name is ScottK's, whose actions are both DONE...the ones that are WIP show up on the report assigned to 'nobody'
<nixternal> want to help get this fixed so we can follow along
#ubuntu-devel 2009-12-11
<cjwatson> -                if 'DONE' in f or 'POSTPONED' in f or 'TODO' in f or 'INPROGRESS' in f:
<cjwatson> +                if 'DONE' in f or 'POSTPONED' in f or 'TODO' in f or 'INPROGRESS' in f or 'WIP' in f:
<cjwatson> nixternal: ^- committed, should fix that
<nixternal> cjwatson: rock on! thanks!
<cjwatson> it'll probably take an hour or two before pitti's cron job picks that up
<nixternal> that's cool...really appreciate that...I was just going to change them all on the wiki page, but you made that easier :)
<maxb> I don't suppose there is any way to convince update-manager that a *specific* third-party repo should not be disabled on distro upgrade, is there?
<james_w> maxb: the feature was just added I think
<james_w> there's some config somewhere
<maxb> I shall go grepping then
<maxb> Of course, if it has just been added, it'll be several years before all my colleagues are using a suitable version of Ubuntu :-)
<cjwatson> maxb: add it to /usr/share/update-manager/mirrors.cfg?
<cjwatson> I think that works
<james_w> maxb: there's bug 147080 for coarse-grained
<ubottu> Launchpad bug 147080 in update-manager-core "do-release-upgrade should make disabling third party repositories optional" [Wishlist,Fix released] https://launchpad.net/bugs/147080
<yoasif> i have a possible bug, but i don't know where to file it
<yoasif> basically, all of the alpha-1 cds have the same name (ubuntu, xubuntu, kubuntu), which makes it a chore to seed all of them on bittorrent (or even to store them).... any ideas where to file this?
<cjwatson> yoasif: already filed as bug 199660
<ubottu> Launchpad bug 199660 in ubuntu-meta "CD-image naming scheme" [Undecided,Invalid] https://launchpad.net/bugs/199660
<cjwatson> (Invalid because it was moved to ubuntu-cdimage; but I do suggest you find a workaround anyway, it's painful to change because it would break everyone's scripts)
<yoasif> cjwatson, thanks, still kinda lame
<cjwatson> how polite
<yoasif> hmm?
<maxb> Is notify-osd broken in lucid, or is the funky grid of orange lines some sort of debug aid?
<maxb> cjwatson: Thanks for the mirrors.cfg pointer. I think you are right about the filename, but I think the copy that is actually used is shipped in the release-upgrader tarball. Hmm. But now I have ideas about overriding it using /etc/update-manager/release-upgrades.d/
<Rocket2DMn> doko, what?
<ebroder> lies
<ebroder> Sorry - wrong window
<kees> james_w: is the documentation out of date or am I doing something wrong with these merges?
<kees> $ bzr mark-uploaded
<kees> bzr: ERROR: Unknown target distribution: lucid
<james_w> is a bug
<james_w> you can ignore it for now
<james_w> so I guess the documentation is out of date :-)
<kees> heh
<kees> james_w: it would be nice to have changelog merging working better and something that does the dpkg-genchanges -S -v... stuff.  Is that on the list?
<kees> james_w: it's currently harder to do merges with bzr, since MoM does this stuff for you automatically.
<james_w> the changelog merging is on the list
<kees> I'm worried we're going to start losing merged changelog history if people aren't helped to do the dpkg-genchanges call.
<kees> anyway, must run away to dinner...
<james_w> we could add a --merge flag to "bzr bd"
<james_w> that can look at the changelog and do the right thing
<james_w> it's not possible to do it automatically
<Keybuk> all mark-uploaded does is tag, right?
<james_w> yeah
<Keybuk> so debcommit -r DTRT for now :p
<james_w> indeed :-)
 * maxb wonders if anyone is interested in sponsoring a merge of Subversion?
<sam_> Hi,After I finish a dpkg-buildpackage I modify some .conf files but no .c source files, I want to update the modified .conf files into the .deb file, how can I use dpkg-buildpackage command to avoid re-compile all the .c source files:
<Amaranth> If you're just building it for yourself you can use debuild binary
<DNS777> hey guys, do you have a simple guide for me how to make a proper ubuntu/debian package? :-)
<fabrice_sp> !packagingguide
<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
<fabrice_sp> DNS777, ^
<DNS777> ty :)
<fabrice_sp> yw ;-)
<YokoZar> jcastro: I want to make a wiki page link to "upstreaming bugs" to describe the process, which page should I point it at?
 * YokoZar is modifying the Testing Team pages to mention how important upstreaming bugs is when they're found in the development release
<jcastro> YokoZar: https://wiki.ubuntu.com/Bugs/Upstream
<jcastro> YokoZar: feel free to grab an existing subpage and make a wine-specific one if you want
<YokoZar> not wine related ;)
<YokoZar> jcastro: that was my thought, but that page doesn't seem too friendly in its current form.
<YokoZar> https://wiki.ubuntu.com/Bugs/HowToTriage at "Forwarding upstream" links to that page too, but it doesn't seem to have the promised content
<YokoZar> namely "details on how ot report bugs in various upstream bug trackers"
<jcastro> yeah
<jcastro> the idea is that each of those sections is specific to that project
<jcastro> as you can see we only have the major ones
<YokoZar> I guess I was expecting a brief paragraph or two on why we upstream in general and what it is on that page
<jcastro> but anyone is welcome to add anything, like the Listen folks did
<jcastro> I suppose I could add something like that.
<jcastro> can you send me a mail and I'll todo it?
 * jcastro is only half-way working right now. :p
<YokoZar> Will do.  Thanks :)
<ebroder> If you hit 'c' at the aptitude [Y/n/?] prompt, you might get something useful
<ebroder> Oof - wrong window
<kees> james_w: it's possible to do it automatically -- just lookup the version in LP for that suite
<pitti> Good morning
<geser> good morning pitti
<dholbach> good morning
<tbielawa> morning
 * ruffus910 waves hello
<slangasek> Keybuk: dropping the "starting-dm" event - wasn't ubiquity integration also dependent on this?  and will gdm declare a Breaks: on usplash, to help users avoid getting wedged if there's a reboot mid-upgrade?
<ttx> cjwatson: testing the eucalyptus update, it appears that the SC cannot announce itself on a CC+SC setup (local name conflict because SC_NAME = CC_NAME)
<lool> james_w: Cool, thanks a lot!
<ttx> cjwatson: maybe we should place the information about "target cluster" in a TXT record as well
<ttx> -s doesn't seem to scale :)
<zheng> Hi, I'm new to use dpkg-buildpackage for .deb, how can I add a user after I install a ????.deb?
<zheng> Is there a scipt to add user in the .deb? how can I call it?\
<jiboumans> zheng: lots of existing packages do it already (mysql and apache come to mind), you could take a look at those and follow their lead
<zheng> jiboumans, hi, thx in advance,
<zheng> I test it with postgresql, when I install postgres from internet with "apt-get isntall postgresql", it will add a user: postgres;
<zheng> but when I download the postgresql's source with "apt-get source", then I dpkg-buildpackage it, but I dont add user for me this time.
<zheng> but when I download the postgresql's source with "apt-get source", then I dpkg-buildpackage it into the .deb, then I install these .deb file, but It dont add user for me this time.
<zheng> hi, jiboumans, I get it, I add some script in debian/postinst.ex
<DNS777> did any1 tried to compile the mumble-1.2.0 ?
<DNS777> i have a lot of errors with that :-(
<Keybuk> slangasek: I put a breaks on usplash
<Keybuk> if ubiquity was depending on it, then that was definitely a bug ;)
<Keybuk> cjwatson: if you were using starting-dm, use starting gdm instead
<james_w> kees: true, but I would like to work offline where possible
<Lure> pitti: have time to discuss one karmic sru?
<pitti> Lure: just ask :)
<Lure> karmic shipped with beta5 version of digikam (as upstream release schedule slipped twice)
<Lure> we have one highly visible crasher - bug 454113
<ubottu> Launchpad bug 454113 in digikam "digikam crashes when click on download selected" [High,Triaged] https://launchpad.net/bugs/454113
<Lure> so I suspect the only way for sru is to backport individual fixes (one-by-one)?
<Lure> no way to bend rule to go with final in such case?
 * Lure has done backports, but seems many do not have them enabled and not get fixes
<Lure> pitti: ^^^
<pitti> Lure: depends if _all_ changes between beta5 and final conform to SRU requirements
<pitti> if they do, shipping the entire upstream release is okay
<pitti> but the default mode is "backport that one patch"
<dholbach> if anybody could moderate ubuntu-devel-announce I'd appreciate it :)
<Lure> pitti: they don't - problem I see that there are also string changes (due to string freeze on rc)
<chrisccoulson> hello dholbach
<dholbach> hey chrisccoulson
<chrisccoulson> how are you?
<Lure> pitti: ok, can I at least prepare multiple bugfixes in one sru upload?
<pitti> Lure: seems like backporting would be safer then
<dholbach> chrisccoulson: good good - how about you?
<pitti> Lure: sure, just make sure to attribute the individual patches to their bug reports
<chrisccoulson> dholbach - i'm quite tired, but i finish work for the week in an hour :)
<dholbach> yeeehaw :)
 * dholbach hugs chrisccoulson
 * chrisccoulson hugs dholbach
<directhex> no hugs for me? :(
 * dholbach hugs directhex too
<directhex> yays
<pitti> doko_, robbiew_: for bug 417757, would it be ok to just upload the reapplied patch and thus unfix the two other bugs again? I have to agree to the folks there that it's indeed urgent
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/417757)
 * chrisccoulson hugs directhex too
<directhex> \o/
<sebner> poor directhex :P
 * sebner hugs directhex too
<doko_> pitti: please let's check this in lucid first (will upload after the gcc-4.4 builds are in the archive)
<emgent> cjwatson: around?
<superm1> pitti, would it be feasible to specify flags and commands that upstream wants gdb ran with in apport  hooks?
<pitti> superm1: not currently, but of course you could change the code to append a field GdbFlags: to the gdb options
<superm1> pitti, okay. well i'll need to see exactly what's missing and look into doing that then
<pitti> superm1: what would be an example option you'd be interested in?
<superm1> pitti, so here's exactly what upstream asks for: http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2
<superm1> i haven't compared exactly what is different with the commands applied to gdb on all traces, but upstream was saying that with our (newly functional!) traces that we're submitting upstream, they weren't exactly that
<pitti> superm1: hm, most of the gdb options there just seem to affect the gdb CLI, not the trace output?
<superm1> pitti, ah yeah i think your right
<superm1> pitti, so when working with a coredump they're N/A.  I'll punt this question back at upstream then to get a specific for what they're not liking about the new traces, they should be useful, although just not the exact same format they're used to seeing
<lool> kirkland: Hey
<lool> kirkland: I see you made the transitional qemu depend on qemu-kvm
<lool> kirkland: Why not -extras?
<lool> kirkland: e.g. qemubuilder depends on qemu | kvm, we could transition it to the new packages and/or have the transitional packages point at the corresponding new places for the binaries
<kees> james_w: well, you can't "bzr branch" or "bzr push" or "dput" when offline, so it doesn't seem to bad that you can't do your final upload prep (dpkg-genchanges) until you're online too.
<james_w> but if I have the branch prepared and I want to test build then I do a dpkg-genchanges
<james_w> perhaps we could do something with a marker set by merge-package
<james_w> I'm a bit nervous about that though
<james_w> plus, when sponsoring it's not the person that does the merge that usually does the dpkg-genchanges
<james_w> and MoM doesn't currently help with that anyway
<geser> jdstrand: do you know why there are so many unprocessed sync requests? (like e.g. 489631)
<jdstrand> geser: two thoughts: a) resources and b) source format 3.0 (quilt)
<jdstrand> geser: I'm on today, but haven't started processing them
<geser> does b) also stop syncs from format 1.0 packages?
<slangasek> it means that archive admins' time is taken up playing whack-a-mole with the 3.0 stuff for the autosyncs
<geser> ah
<hyperair> has anyone here heard of an issue regarding pulseaudio and usb headsets?
<hyperair> lag in audio, or something like that
<hyperair> dtchen: ^^ ?
<micahg> pitti: can I chat with you about ubuntu-bug?
<slangasek> pitti: where does the code for this new pm-utils-powersave-policy package live?  And is this package being installed by default?
<slangasek> pitti: (the SATA link power management stuff still concerns me, due to the impact for anyone who's hitting swap)
<jdong> slangasek: out of curiousity, how bad is the latency when SATA goes into ALPM?
<slangasek> jdong: I never measured it except holistically
<slangasek> and by that measurement, it was "pretty bad"
<jdong> slangasek: ouch. Heh I've only done the same also, and surprisingly I didn't feel the hit. Maybe I'm spoiled with RAM and don't hit swap
<slangasek> I knew I was memory-constrained already, at the time; I've since solved that underlying bug
<jdong> *nods*
<jdong> well honestly Linux interactivity (ahem) sucks whenever hitting swap in any form...
<jdong> but yeah, I can totally see how a couple ms of a sleeping SATA link could exacerbate things
 * jdong wonders what happened to Con Koliva's work with swap prefetching
<Trewas> jdong: it wasn't accepted to the mainline kernel because no-one could provide hard numbers how/when it helps, and then con pretty much gave up
<jdong> *nods*
<jdong> it's annoyingly challenging to find ways to quantify desktop interactivity, unfortunately
<Trewas> agreed
<jdong> Phoronix does it by... umm... measuring 10000 SQLite inserts with a BFS kernel
<jdong> (WTF?)
<fta> doko_, pitti: are you still working on the ipv6 resolver bug?
<fbond> Hi.  When the update-notifier window is popped up and then sent to the background it briefly steals my keyboard focus.  Does anyone know if this has been reported as a bug?
<slangasek> ScottK: thanks for getting boost1.40 on its feet - fwiw, boost-graph-parallel fails to build because it depends on mpi, so I'm culling it entirely from the package now (there was still one reference in debian/control)
<ScottK> slangasek: OK.  Thanks.  I thought I saw some reference upstream to graph and graph-parallels being merged.
<ScottK> slangasek: Also ajmitch has a patch for the boost-python problem he's been on the verge of uploading for some time.  You probably ought to get that from him.
<slangasek> ajmitch: ping?
<slangasek> what's currently broken wrt boost-python?
<ScottK> I don't remember, but it affects Karmic too.
<ScottK> It doens't hit many packages, but the ones it does it hits hard is all I remember
<kees> pitti: still around?
<ajmitch> slangasek: pong
<slangasek> ajmitch: hey - ScottK says there's a boost-python fix I should be talking to you about
<ajmitch> slangasek: yes I talked to ScottK yesterday, thanked him for getting the merge in, I have free time today to upload again
<slangasek> ajmitch: ok - not knowing when you'd be around, I went ahead and uploaded my boost fix separately; I guess those builds are now far enough along that it doesn't matter whether the next upload happens now vs. later
<ajmitch> or if you prefer to upload, patch is in boost1.40 in https://edge.launchpad.net/~ajmitch/+archive/ppa
<ajmitch> ok
<ScottK> Either way, I no longer TIL Boost, so it's a win.
<ajmitch> heh
<slangasek> :-)
<smoser> kirkland, around ?
<maxb> I have a merge of Subversion pending sponsorship. Should I just continue to wait and hope? Or should I contact anyone in particular?
<ScottK> maxb: Wait and hope.  You didn't happen to fix the lack of kwallet integration did you?
<maxb> I didn't test it, being firmly in gnome land, but the Debian changes being merged included turning that on
<maxb> Although I'm now having a sudden wondering whether it'll still build in a main-only environment
<ScottK> maxb: If it builds, that's better than it did before.
<ScottK> There's a bug on that you can take credit for fixing in debian/changelog then.
<maxb> Ah, kdelibs5-dev is in main, I'm safe
<ScottK> All of Kubuntu is in Main, so kdelibs is a safe bet.
<ScottK> maxb: Since you fixed kwallet, I'll have a look at it.  What bug?
<maxb> bug 483953
<ubottu> Launchpad bug 483953 in subversion "Merge subversion 1.6.6dfsg-2 (main) from Debian unstable (main)." [Undecided,In progress] https://launchpad.net/bugs/483953
<ScottK> Looking
<ScottK> maxb: Explicitly listing the supported versions is preferred over 'all' in the new Debian Python policy that's in draft.  If that's the only change i have, I'll adjust that and upload.
<maxb> Hm
<maxb> That is a shame, because it's a cause of debian/ubuntu delta
 * maxb hunts the text of the draft
<ScottK> maxb: http://lists.debian.org/debian-python/2009/12/msg00009.html
<ScottK> maxb: We were originally going to explicitly deprecate all, but since it's unfortunately quite common in the archive we thought it would be too soon for that.
<maxb> Install of "all", we could make it say ">= 2.something" instead, and that would be OK ?
<ScottK> Yes.
<ScottK> maxb: What does it say in Debian right now?
<maxb> It says individual versions
<maxb> I changed it so the Ubuntu delta didn't itself have to be adjusted when Ubuntu changed its own default Python version, with a view to feeding that back to Debian
<maxb> uh, s/default version/set of supported versions/
<ScottK> Let me look
<ScottK> maxb: What Debian has is OK.
<ScottK> That it covers more Python versions than we have is not a problem.
<ScottK> That's meant to be a list of versions it could support, not just the ones used in the current release.
<ScottK> If that's the only diff, this should be a sync.
<maxb> Oh, no, that's far from the only diff
<ScottK> maxb: Would you please do up a debdiff for me then?
<maxb> ScottK: Sorry, did I miss anything in the netsplit?
<ScottK> maxb: I asked you to make a debdiff for me.
<ScottK> This new fangled bzr stuff I'm still working on learning.
<maxb> Heh
<maxb> We didn't reach a conclusion (that I saw) on what the XS-Python-Version: should look like
<maxb> Also, owing to how part of the work I did with this merge was stitching up some weirdness that the bzr importer created, it really needs to actually be bzr pushed, rather than letting the importer re-derive it from an upload
<ScottK> maxb: Oh, here's what I said on that:
<ScottK> That it covers more Python versions than we have is not a problem.
<ScottK> That's meant to be a list of versions it could support, not just the ones used in the current release.
<ScottK> So it's fine as is from Debian.
<maxb> In that case, I guess I'll just uncommit the last revision from the bzr branch
<maxb> Or should I re-add 2.4, which we previously dropped, as an Ubuntu delta?
<maxb> The latter, I guess
<ScottK> It does no harm, so don't diverge over it.
<maxb> Is there any convention on where in the changelog I should write LP bugnumbers closed by merge of Debian changes?
<ebroder> Probably on the "Merge from Debian" line?
<slangasek> I find all the available options unsatisfactory, personally :)
<ScottK> slangasek: For which point?
<slangasek> ScottK: for LP bugnumber convention on fixes merged from Debian
<ScottK> Ah.  Right.
<maxb>   * Merge from debian unstable (LP: #483953).
<maxb>     Includes enabling kwallet support (LP: #481792, #466078).
<maxb>     Remaining changes:
<maxb> ^ Acceptable ?
<ScottK> I'd go for that.
<cody-somerville> lmao
<cody-somerville> Due to a bug in Debian's infrastructure a ton of stuff migrated to testing from unstable when it shouldn't have.
<ebroder> "Whoops"
<cody-somerville> So much for the little experiment of syncing from testing instead of unstable, lol.
<ScottK> maxb: I have to run out for a while, so just shove your debdiff in the bug and i'll look at it later.
<ScottK> cody-somerville: It'll be more important later anyway.
<ebroder> Hmm...I'm waiting for a package to hit testing. I wonder if it was affected
<maxb> ScottK: Thanks - did you see my comment about needing the branch pushed too, even if you upload by the debdiff?
<ScottK> maxb: I did, but I didn't understand it.
<ScottK> We can chat later as I really need to run.
<maxb> I shall elaborate upon it in the bug
<ScottK> OK.  Good
<Czesiu> Hello
<Czesiu> Could you tell me what's wrong with call: requestsync -d unstable rrdcollect 10.04?
<Czesiu> Replacing 10.04 with lucid also doesn't work as expected
<maxb> Nothing obviously wrong, what breaks?
<Czesiu> I'm using ubuntu-dev-too 0.83debian1 from
<Czesiu> E: The versions in Debian and Ubuntu are the same already (0.2.4-2). Aborting.
<maxb> lucid is correct here, 10.04 is not, I would say
<Czesiu> But there is new release in unstable at the moment
<maxb> How recently uploaded?
<Czesiu> 4 days ago
<maxb> Hmm
<Czesiu> hm, I checked 6 days ago
<maxb> Ok, it breaks for me too, this seems like a bug
<Czesiu> Thanks, I'll report it.
<maxb> Czesiu: Wait 5 minutes please, I'm just investigating
<Czesiu> ok
<maxb> Hmm, LP itself knows about the new version
<Czesiu> May I check it too?
<maxb> What do you mean?
<Czesiu> maxb: what LP knows about the latest release from Debian
<maxb> You may see it here: https://launchpad.net/debian/sid/+source/rrdcollect
<Czesiu> maxb: oops, I've never look carefully on that page :)
<maxb> Czesiu: I'm completely confused as to why requestsync is getting it wrong, but I can't find anything wrong with what I get if I manually drive the Launchpad API, so I think a bug on requestsync is the right way to go
<Czesiu> maxb: I see there is new version on Debian. I'll upgrade it and if the bug persists I'll report it
<maxb> Czesiu: Oh. bah. It's apparently hitting some php script instead of launchpad :-/
<maxb> I didn't know about that
<maxb> Czesiu: It's apparently getting confused because the new version has not build on all architectures in Debian
<maxb> You can check it yourself with rmadison -u debian -a source -s unstable rrdcollect
<Czesiu> maxb: hm, it's not build only on hurd-i386, which is not release critical IIRC
<maxb> Indeed. But it's enough to accidentally confuse requestsync
<Czesiu> maxb: thanks, I will add this suggestion to bugreport too
<michalski-bj> is Cody Somerville in by chance? (online, avail.)
<michalski-bj> need to ask him a few questions
<maxb> Czesiu: Please add the actual current output of "rmadison -u debian -a source -s unstable rrdcollect" to the bug report as well
<maxb> Hmm. What is ScottK likely to have wanted a debdiff *against*, given this is a new upstream version?
<ScottK> maxb: The current Debian version.
<maxb> Aha
<ScottK> I've already pulled that from Debian.
<mun24> how to get the error code for connect socket error -1
<Czesiu> maxb: thanks for support. #560758 has been submitted to Debian BTS.
<maxb> errr, the *debian* bts?
<maxb> requestsync is an ubuntu program
<Czesiu> maxb: right. I'm developing on Debian, but I also try to take care of ubuntu bugs reported for my packages. And I am using ubuntu-dev-tools available in Debian
<maxb> Ah. It would probably be best to have filed the bug "upstream" in Launchpad
<ccheney> does linux just work out of the box with 4k sectors?
<ccheney> http://www.engadget.com/2009/12/11/western-digital-advanced-format-promises-slight-boost-in-usabl/ <- saw this a few min ago
<Czesiu> maxb: hm, let me check that, I'm still not accustomed to launchpad :)
<directhe`> ccheney, man mkfs.ext2
<ccheney> ah found this thread too http://www.gossamer-threads.com/lists/linux/kernel/1039141
<directhe`> oh, hardware drivers need support too? hadn't thought of that
<ccheney> oh ugh this is another one of those we need uefi immediately things
<ccheney> "Most likely, the universe will explode at this time..." ;-)
<maxb> ScottK: I'm afraid your advice about it being OK to include versions of Python we don't have in XS-Python-Version is apparently not correct.
<maxb> The build is FTBFS in my PPA
<directhe`> ccheney, what's wrong with regular EFI? all the cool kids have EFI
<Czesiu> maxb: I see that developer of Debian package for ubuntu-dev-tools is also a member of the same team on LP, so I left it as it.
<ccheney> directhe`: hmm i thought it was all uefi now, i haven't actually ever seen a system with it other than macs (and on those never seen what theirs looks like)
<ccheney> we should be seeing a lot of *efi soon though as 2TiB is limit for bios aiui
<ccheney> directhe`: as best as i can tell current efi is called uefi
<directhe`> ccheney, i have itanium kit with EFI, and a mac with EFI
<directhe`> ccheney, iirc the only "normal" systems with EFI are a limited number of motherboards from MSI
<directhe`> plus you need Vista x64 SP1, or Windows 7, to boot EFI in "native" mode, so that's hindered adoption somewhat
<ccheney> directhe`: yep, but the limit of 2TiB drives should force more deployment of EFI soon
<directhe`> ccheney, you'd think so
<directhe`> ccheney, 32-bit windows is still popular amongst people with 4 gig of ram...
<ccheney> directhe`: heh yea
<ScottK> maxb: Weird.  OK.
<ScottK> maxb: Where's the build log?
<maxb> https://launchpad.net/~maxb/+archive/ppa/+build/1391193/+files/buildlog_ubuntu-lucid-amd64.subversion_1.6.6dfsg-2ubuntu1~~testbuild1_FAILEDTOBUILD.txt.gz
<maxb> I've just done a local cowbuilder build with XS-Python-Version: >= 2.4, and that works. I'd like to go with that, if it's acceptable to you
<ScottK> maxb: That's good.
<maxb> peterS will likely take that into Debian, I would imagine
<ScottK> maxb: That's, IIRC, explicitly preferred in the new draft Python policy, so I would hope so.
<ScottK> maxb: I think that's a Python support bug, btw (your build failure).
<maxb> I can believe that
<ScottK> Would you please file an Ubuntu python-support bug on that?
<maxb> It'll take more research than I have time for tonight, but I'll scribble myself a note
<ScottK> Thanks.
<maxb> ScottK: Do you mean python-support? pyversions is contained in the 'python' source
<ScottK> maxb: I do because I think it's python-support that is interpreting the field.  Subscribe me to the bug and I'll move it if need be.
 * ScottK has to run again.
#ubuntu-devel 2009-12-12
<dtchen> hyperair: jaunty? karmic? lucid? what hardware?
<hyperair> dtchen: jaunty. i don't actually have a usb headset to try it out with, but all the problems i've heard of audio delay with skype seem to stem from pulseadio + usb headset.
<ScottK> maxb: Do I have a debdiff from you?
<ScottK> I see it now.
<ScottK> I thought I'd subscribed to the bug, but I guess I hadn't.
<jdong> kees: *grins* A friend and I are actually making good headway on a clone of sandbox exec using AppArmor, as we previously discussed
<jdong> (i.e. allowing users to voluntarily opt into AA restrictions)
<kees> jdong: Nice!
<kees> jdong: I was playing a little bit with lxc to a similar end.  It was fun having bash be pid 1.  :)
<jdong> yeah, that sounds cool :)
<ion> kees: Boot Linux with init=/bin/bash and youâll have bash as pid 1. ;-)
<kees> ion: well, yeah.  :P
<kees> ion: I guess I meant it was fun to have two pid 1s.  :)
<ion> :-)
<smoser> anyone able to help... i know its late.
<smoser> i have a known key that i want to feed to : apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ${key}
<smoser> i'm trying to automate something and that is timing out.
<smoser> it could be timing out because the server is just slow (as I've seen before) or because networking is blocking me.
<smoser> either way, i know the 'key' that i want to get, and can pre-get it ... i just want the same effect
<smoser> anyone know how i can do the same thing that apt-key does above without the network operation /
<wgrant> smoser: sudo apt-key add $somekeyfile
<smoser> righ..i just was realizing that...
<smoser> how do i get 'somekeyfile' ?
<smoser> sudo apt-key export key
<slangasek> GNUPGHOME=./mytmpdir gpg --keyserver keyserver.ubuntu.com --recv-keys ${key}; GNUPGHOME=./mytmpdir gpg --export ${key} --output $somkeyfile
<smoser> thank you slangasek wgrant .
<dtchen> hyperair: certainly possible, though lucid's is better, and I haven't been able to reproduce the symptom in karmic or lucid
<hyperair> dtchen: i see. it'll be good to request details about the hardware they're using. there appears to be a lot of hate for pulseaudio
<pecisk> hi people, what kernel Lucid will have in the end? It is already decided?
<pecisk> I mean what version
<tjaalton> pecisk: 2.6.32
<geser> tkamppeter: re bug 495548: it's usually enough to subscribe ~ubuntu-archive to such bugs (which I've done), no need to assign it to them
<ubottu> Launchpad bug 495548 in hal-cups-utils "Remove hal-cups-utils from lucid" [Undecided,New] https://launchpad.net/bugs/495548
<pecisk> tjaalton, I just interested will nouveau driver will be used as geforce default 2d driver in Lucid? Or it is just too risky yet?
<tjaalton> pecisk: it will be tried, and after alpha2 decided if it's go/no-go
<pecisk> cool :)
<pecisk> tjaalton, thanks for info
<ogra> hrm
<ogra> is pybootchartgui supposed to work in lucid atm ?
<tjaalton> pecisk: https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-driver-selection-for-nvidia-hardware
<gnomefreak> tjaalton: the nvidia discussion above related to bug 495779? is there a work around atm?
<ubottu> Launchpad bug 495779 in nvidia-graphics-drivers-180 "when doing X updates it wants to remove nvidia-glx-185" [Undecided,New] https://launchpad.net/bugs/495779
<tjaalton> gnomefreak: no. it needs a newer version built against the current xserver-xorg-dev
<gnomefreak> tjaalton: ah ok thanks
<Mamarok> hi all
<Mamarok> about this bug: https://bugs.edge.launchpad.net/ubuntu/+source/eglibc/+bug/425723, is there a chance to get a newer glibc version in Karmic soon? It causes quite a few problems in KDE apps
<ubottu> Ubuntu bug 425723 in glibc "kdevelop assert failure: *** glibc detected *** kdevelop: free(): invalid pointer: 0xbfc22c44 ***" [Unknown,Fix released]
<apachelogger> doko_: ^
<Mamarok> thx apachelogger:)
<Tm_T> Mamarok: brrrh, that's why I have kdelibs(?) with small patch
<Tm_T> using malloc 2 instead of 3 (IIRC)
<apachelogger> doko_: Mamarok is poking around for weeks now and preventing me from doing useful things by making me read duplicates of that particular bug, so pretty please do something about it :)
<Mamarok> Tm_T: well, it's not in Karmic AFAICS, don't expect users to apply patches
<Tm_T> Mamarok: I know, just saying that this isn't new issue at all
<Mamarok> all other ditstros have either patched their glibc or use a newer version, I only get reports from Ubuntu users now
<Mamarok> distros*
<Tm_T> so yes, please fix (:)
<Mamarok> see also http://www.purinchu.net/wp/2009/11/16/malloc_check_-crashes/
<cjwatson> Mamarok: I think we should - I've targeted the bug for karmic and will try to remember to follow up with whoever's available on Monday
<Mamarok> cjwatson: thanks a lot :)
<cjwatson> doesn't help that sourceware.org is down from here right now, but I've got the general idea
<apachelogger> cjwatson: thanks ... google cache is your friend http://www.google.com/search?hl=en&q=cache:http://sourceware.org/bugzilla/show_bug.cgi%3Fid%3D10282
<apachelogger> not that it helps with the patch, but with information :)
<cjwatson> apachelogger: yes, already been there
<apachelogger> k :)
<David-T> cjwatson: hi. you might want to look at bug #493772 at some point (as i think it was introduced by your latest change to mdadm)
<ubottu> Launchpad bug 493772 in mdadm "mdadm + initramfs-tools fail to boot" [Medium,Triaged] https://launchpad.net/bugs/493772
<oussama> hi guys
<oussama> how to upload a package in the universe or multiverse
<maxb> Could someone (who is a core-dev) push lp:~maxb/ubuntu/lucid/subversion/merge into lp:ubuntu/subversion? It's already been uploaded to the archive, but bzr hasn't been updated accordingly. Thanks.
<maxb> I've committed a final revision to the branch fixing it up to exactly what was uploaded, and have `bzr mark-uploaded` it
<Laibsch> ArneGoetje: I have a question for you if I may.  I see you maintain scim upstream development is dead.  Yet, when I look at upstream svn I see lots of activity.  Do you know more than me?  Please explain.  I'm not questioning the scim->ibus move.  I'm just curious.
<ArneGoetje> Laibsch: scim has some serious design issues which noone is working on.
<Laibsch> that may be true, but it's different from "upstream development has stopped".  It's a quality issue.
<ArneGoetje> Laibsch: there has been no progress upstream to fix those long standing issues.
<Laibsch> I don't dispute that
<Laibsch> Do you have an example?
<ArneGoetje> Laibsch: development upstream is not going forward, they only maintain the status quo
<ArneGoetje> Laibsch: for example teh Locale issue. Scim has been designed for zh_* and en_US locales in the first place. If you use any other locale than that, you need to hack the scim config file to get scim working.
<ArneGoetje> Laibsch: instead, scim could have just accepted any UTF-8 locale by default.
<Laibsch> I'm not familiar with "the locale issue".  Do you have a bug number?  I'm surprised to hear that scim is China-centric.  That was a mild concern I had with ibus, given that both devs are Chinese.
<ArneGoetje> Laibsch: no, I don't have a bug number. But it's common knowledge with Chinese users and IM developers. IBus does the right thing. It accepts any UTF-8 locale by default.
<Laibsch> good
<ArneGoetje> Laibsch: IBus has been developed because of the design issues SCIM has.
<Laibsch> I never questioned the many problems present in scim.  And as mentioned initially am not questioning the move from scim to ibus.  But I do think "scim upstream is dead" is not a correct statement.  If you disagree, that's something I can't change.
<Laibsch> scim svn has activity and I think there is an influx of devs, too
<Laibsch> But I'm not watching very closely
<cjwatson> David-T: doesn't seem to have anything to do with the source changes I made.
<cjwatson> David-T: I think it would be more correct to figure out why the rules file got renamed; my suspicion is that it was an accident due perhaps to a change in dh_installudev, and the old name was better
<ArneGoetje> Laibsch: svn activity has nothing to do with progress being made to fix those long standing issues. As far as I can tell from the scim-devel mailing list, most activity is about adding new input methods.
<Laibsch> ArneGoetje: "scim is not progressing in the direction we see as necessary" -> OK
<Laibsch> "scim upstream development is dead" -> factually wrong IMHO
<Laibsch> that is what I'm saying
<Laibsch> but we may agree to disagree
<cjwatson> David-T: see the changelog for debhelper 7.4.2
<cjwatson> David-T: I'll sort it out, anyway; thanks for the note
<joaopinto> any ideas on what could cause an ureadahead-other main process (18103) terminated with status 4 endless loop ?
<joaopinto> I hate cryptic log messages
<David-T> cjwatson: ah, that makes more sense. thanks.
<joaopinto> Dec 12 14:16:25 pt001424-laptop init: ureadahead-other main process (18121) terminated with status 4
<joaopinto> is this an upstart message ?
<cjwatson> yes
<cjwatson> it's harmless anyway
<cjwatson> # Don't treat a normal exit after reading finishes as a failure, and
<cjwatson> # don't treat a missing pack file as an error either
<cjwatson> normal exit 0 4
<cjwatson> (/etc/init/ureadahead-other.conf)
<joaopinto> cjwatson, on my case it's associated with another problem, udev and friends using excessive cpu
<cjwatson> I'm not volunteering to debug it, I just answered your question
<joaopinto> restarting udev fixes both, the cpu and stops the message
<joaopinto> nothing is harmless when it's endelessly logged :)
<cjwatson> I shouldn't have said anything, I suppose :P
<cjwatson> you should file a bug on ureadahead
<cjwatson> David-T: fixed
<joaopinto> the symptom is the same described on bug 379780 , except that no one noted ureadahead  messages
<ubottu> Launchpad bug 379780 in linux "High cpu usage after upgrade to 141-1.1" [Unknown,Confirmed] https://launchpad.net/bugs/379780
<cjwatson> that symptom is very vague so it doesn't mean it's the same bug
<joaopinto> ok, I will file a bug for ureadahead
<ArneGoetje> Laibsch: well, if it makes you happy, I can rephrase the statement to "scim upstream is not progressing in fixing long standing software design issues"
<joaopinto> hum, probably I should comment the ntfs partition from nfstab, it's causing the already reported mountall loop from the hibernate status, I guess it could be related to the later sreadahead issues
<joaopinto> hum, apport reports an error when trying to do the PackDump, I guess it requires root
<directhex> is the plan for ff3.5 or ff3.6 in lucid?
<joaopinto> uff, found that both the cpu & errror msg are related to the mountall endless loop bug
<joaopinto> bug open, bug close
<jdstrand> slangasek, james_w, Riddell, cjwatson, kirkland, StevenK, al-maisan: fyi, I got 'sync-source.py -a' to work again by identifying source format 3.0 packages and adding them to /srv/launchpad.net/dak/sync-blacklist.txt (temporarily). When bug #293106 is fixed, we need to remove these from the blacklist.
<ubottu> Launchpad bug 293106 in soyuz "does not support debian v3 source formats" [High,In progress] https://launchpad.net/bugs/293106
<jdstrand> slangasek, james_w, Riddell, cjwatson, kirkland, StevenK, al-maisan: some 154 packages just sync'd \o/
<jdstrand> slangasek, james_w, Riddell, cjwatson, kirkland, StevenK, al-maisan: see r214 for the update to the blacklist. of course, something else could float into testing that breaks it again, but it should be easy enough to see and add to the temporary blacklist
<joaopinto> When I plugin a vodafone pcmcia card I get 4 ttyUSB devices, network manager randomly connects, I have found that it only connects when it selects /dev/ttyUSB0, what is responsible to identify the modem device, networkmanager or modemmanager ?
<jdstrand> geser: fyi ^
<joaopinto> I may have the bug reported into the wrong package
<Riddell> jdstrand: great
<Riddell> that'll be fun for whoever has an archive admin day next :)
<jdstrand> heh
<dtchen> hyperair: yes, details about lower parts of the audio are always required for debugging. Misplaced hate is often seen.
 * geser hugs jdstrand
<Tm_T> packages.ubuntu.com is not available today?
<jpds> Tm_T: It likes doing that on weekends.
<Tm_T> ah, didn't know, thanks
<jpds> jdstrand: I think the branch which adds v3 support to soyuz landed in devel today, and should hopefully be available in production from the 16th (I believe).
<jpds> jdstrand: Reading http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/10048 that is.
<geser> as far as I know there are final test runs for the format 3.0 branch scheduled for the beginning of next week
<geser> could a core-dev please give-back: indicator-applet indicator-messages indicator-session. Thanks
<geser> please also give-back: nautilus-sento libpam-mount. Thanks.
<mmoya> any news on unavailability of packages.ubuntu.com ?
<geser> it's weekend, so most people aren't available
<oussama> hi guys
<oussama> how to upload a package ??
<oussama> in the universe or multicerse
<oussama> multiverse
<oussama> ???
<oussama> !package
<ubottu> You can browse and search for Ubuntu packages using !Synaptic, !Adept, "apt-cache search <keywords or regex>", or online at http://packages.ubuntu.com - Ubuntu has about 20000 packages available, so please *search* for an official package before installing things in awkward ways!
<slangasek> jdstrand: well, it certainly will break again; if you check the blacklist file, you'll find other blacklisted v3 packages, including some 110 of them at the top of the file
<oussama> what is dfsg
<oussama> !dfsg
<azeem> oussama: you asked that already in #ubuntu-motu
<oussama> i want just more explications
<azeem> then ask more specific questions, in #ubuntu-motu
<diwic> I'm packaging a small utility which contains a .py file and a wrapper script. Both are installed into /usr/bin. Lintian complains about the .py file having .py extension in /usr/bin. Should I move it to install somewhere else?
<geser> is the file expected to be used/called by a user?
<diwic> geser: difficult to know really. At least 99% of the cases would be calls to the wrapper script, which is the only one to have a man page.
<geser> if it's not expected to be used by the user then it shouldn't be in /usr/bin but instead something like /usr/share/$pkgname/
<diwic> And modify the wrapper script to reflect that
<geser> yes
<diwic> thanks!
<PovAddict> http://packages.ubuntu.com/ <- down?
<diwic> PovAddict: confirmed
<PovAddict> I'm on debian, I was trying to help someone with ubuntu but couldn't check if a package name on ubuntu was what I expected it to be...
<diwic> PovAddict: what's the package name and Ubuntu version?
<PovAddict> don't worry, that's solved :)
<diwic> ok
<oussama> what does patch do ?
<dtchen> ARGH
<dtchen> dpkg-buildpackage is clobbering CFLAGS
<dtchen> this completely breaks alsa-lib :(
<dtchen> bad! dpkg-buildpackage: set CFLAGS to default value: -g -O2
<dtchen> now I get to hack upstream configure*
<Ryan52> dtchen: change CFLAGS in debian/rules.
<dtchen> Ryan52: we already do.
<dtchen> it gets RESET
<Ryan52> by what?
<Ryan52> dpkg-buildpackage can't change the CFLAGS you set in debian/rules..
<Ryan52> it just sets the default.
<dtchen> this had better not be another local schroot problem :(
<dtchen> bah, it was libtoolise screwage
<wgrant> geser: It landed earlier than I expected. It is definitely in for the release.
<evolio> hello, does anyone know if there is a proposal to put graphical volume monitors in sound properties
<dtchen> evolio: check with upstream gnome-media
<jdstrand> slangasek: sure-- moved the ones I added to the top of the file. I didn't notice them
<tormod> evolio, there are already for inputs, very handy
<jdstrand> slangasek: we're now up to 160!
<slangasek> yeah
 * jdstrand is looking forward to that bug being fixed
<slangasek> the LP release this Wednesday is due to fix it
 * jdstrand nods
<wgrant> It has landed, so the LP code will be there.
<wgrant> But I'm not sure about the buildds, and I suspect your sync scripts will need some small fixes (they're not part of LP, so I can't test them).
<slangasek> the sync scripts are part of LP
<slangasek> scripts/ftpmaster-tools/sync-source.py
<wgrant> sync-source.py itself is.
<wgrant> But the rest of it is not.
<slangasek> that's the script that's breaking :)
<slangasek> if you mean mass-sync.py, that doesn't look at the source package, it just hands off to sync-source.py
<wgrant> I know, and that will be fixed once cocoplum's dpkg is upgraded. But the flush scripts do filename globbing of some variety, and last I checked it didn't do .bz2.
<slangasek> ah; it does now
<wgrant> OK. So hopefully it won't break like that.
<joaopinto> anyone experienced with NM troubleshooting and editing 10-modem.fdi ?
<cyphermox> joaopinto, NM troubleshooting, a little.. what kind of trouble?
<joaopinto> cyphermox, with Vodafone 3G PCMCIA card I can only randomly connect
<joaopinto> I have found that NM is using a random device from the 4 advertised ttyUSB ports
<cyphermox> never the same?
<joaopinto> well, maybe it's sequential, but yes, not the same
<joaopinto> I have reported it, bug 434275
<ubottu> Launchpad bug 434275 in network-manager "Vodafone 3G PCMCIA Card ramdonly fails to connect" [Undecided,New] https://launchpad.net/bugs/434275
<joaopinto> looking at lshal, only the ttyUSB0 device advertises the "modem" capability
<cyphermox> ok
<joaopinto> now I just need to know if there is a way to define that the "modem" capable device should be used, I guess this would be defined at 10-modem.fdi
<joaopinto> or, it's a NM bug, and it should prefer the "modem" device when available
<cyphermox> joaopinto, trying to find out what it is now :)
#ubuntu-devel 2009-12-13
<chaotikcore> hello all
<chaotikcore> ive got a ? for anyone who can answer it
<ion> !
<cody-somerville> chaotikcore, Just ask.
<ion> Itâs ok, my exclamation mark already answered his question mark.
<chaotikcore> was talking to someone sorry..i need to know how to edit the pass prompt gui if possible in 9.10
<m4t> is there a way to get at Hal via dbus, given the default 9.10 setup?
<m4t> erm nm
<m4t> i was on the session bus
<jdong> [jdong@hideout:aa-tools/sudont]$ sudont-exec sudont_0b1bda83-e83c-41f6-bfad-8a0c49196ef8 bash
<jdong> bash: /etc/bash.bashrc: Permission denied
<jdong> bash: /etc/bash_completion: Permission denied
<jdong> I have no name!@hideout:~/code/aa-tools/sudont$
<jdong> kees: ^^ *grins* the pieces are getting somewhere!
<kees> jdong: *rofl* sudont
<jdong> LOL I thought it was an amusing working name!
<jdong> [183484.258291] BUG: unable to handle kernel NULL pointer dereference at (null)
<jdong> [183484.258291] IP: [<ffffffff8125ee7d>] aa_unpack+0xdd/0x2d0
<jdong> [183484.258291] PGD 2e379067 PUD 5cabf067 PMD 0
<jdong> [183484.258291] Oops: 0000 [#6] SMP
<jdong> kees: ^^ did you know 2.6.32 seems to blow up when apparmor_parser --add is given a empty profile?
<jdong> i.e. profile foo {}
<jdong> I SUPPOSE technically  by apparmor.d(5) a empty profile IS a syntax error...
<jdong> but... this is an awfully mean way of telling me!
<ScottK> jdong: You enage in undefined behavior and anything can happing.  Just be glad it didn't eat your hard drive as a way of notification.
<jdong> :)
<kees> jdong: ewww
<kees> jdong: can you open a bug for that so it doesn't get lost?
<jdong> hahaha sure thing!
<kees> cute.  gdm will FTBFS if there is a ~ in its version string.
<jdong> ok kees, bug 496110 reported
<ubottu> Launchpad bug 496110 in linux "AppArmor oops when loading an empty profile" [Undecided,New] https://launchpad.net/bugs/496110
<kees> jdong: thx
<maxb> Could someone (who is a core-dev) push lp:~maxb/ubuntu/lucid/subversion/merge into lp:ubuntu/subversion? It's already been uploaded to the archive, but bzr hasn't been updated accordingly. Thanks.
<maxb> I've committed a final revision to the branch fixing it up to exactly what was uploaded, and have `bzr mark-uploaded` it
<ari-tczew> hello devs, please take look at lucid's bug #494166
<ubottu> Launchpad bug 494166 in nvidia-graphics-drivers-180 "[lucid] nvidia-glx can't work with new xorg 7.5" [Undecided,Confirmed] https://launchpad.net/bugs/494166
<squirrelpimp> hi. i just noticed the following behaviour in thunar, the xubuntu/xfce filemanager, so please interrupt me, if i'm supposed to ask in #xubuntu-devel:
<squirrelpimp> if i copy a large file to an usbstick, it proceeds in about 1 second for a 300 MB file (which comes from a tmpfs). Of course it ends up in the dirty buffers, so it still has to be actually written to the disk.
<squirrelpimp> i the file is sufficiently large, the writeback exceeds the timeout when ejecting the volume right after the copy finished.
<squirrelpimp> therefor i copy the file, open a terminal, type "sync" and wait for it to return before the umount
<squirrelpimp> now the question: Is the behaviour in ubuntu/gnome the same? and would it make sense to have a kind of countdown in the "data is still being written" popup depicting the amount of data to be flushed to disk?
<squirrelpimp> also is there a command to flush only buffers for a single disk?
<RiotingPacifist> I've installed libs to /usr/local how do i get the system to use them instead of the defaults (globally,  e.g not for just a program as i launch it)?
<RiotingPacifist> sorry to repeat this but i lost all logs for the last 30mins so if i got a reply i lost it I've installed libs to /usr/local how do i get the system to use them instead of the defaults (globally,  e.g not for just a program as i launch it)?
<geser> they should be picked up before the ones from /usr/lib automatically (beware: having libs in /usr/local which are also packaged might cause upgrade problems later)
<RiotingPacifist> geser: when i run lsof | grep <name of lib> it shows programs still using the old ones :S
<RiotingPacifist> geser: never mind i've rebooted and now everything is using the new versions, not sure what i did earlier
<geser> did you restart the program?
<RiotingPacifist> crashed and restarted everything (but i swear i had restarted everything before, meh it works now :D)
<geser> if it's a long running program (like a server process) you need to restart it to use the new libs
<Gh0sty> anyone can help debugging printer driver issues? my network printer -epson alc1100- works on ubuntu 32 bit but not on 64 bit and cups does not provide me with any errors ... :(
<RiotingPacifist> why does ubuntu dd /proc/kmsg to /var/run/kmsg instead of just changing the rights on /proc/kmsg so syslog can read it?
<dtchen> any archive admins: what else is necessary for JACK to be promoted back into main? e.g., Does a main source package simply need to build-dep against libjack-dev?
<dtchen> (JACK -> jack-audio-connection-kit)
<ScottK> dtchen: Is there an approved MIR?
<ScottK> dtchen: When you say "back into Main", I gather it was there before?  In these cases a full MIR is not always required.
<dtchen> ScottK: discussion seems to have stalled (bug 416778 from https://wiki.ubuntu.org/MainInclusionReport/libffado)
<ubottu> Launchpad bug 416778 in libffado "[MIR] libffado" [Undecided,Confirmed] https://launchpad.net/bugs/416778
<ScottK> Looking
<dtchen> also, yes, j-a-c-k was in main many releases ago. Perhaps 5.04/Hoary?
<ScottK> dtchen: In the last comment in the bug, it seems to me that pitti says you need a MIR for jack and freebob either needs a MIR or dropped from depends.
<ScottK> dtchen: What's the status on those things?
<dtchen> (using pull-lp-source now)
<dtchen> ScottK: ok, so the process for j-a-c-k appears to be blocked on the freebob build-dep, which I'll clear up
<dtchen> ScottK: how about for libffado?
<ScottK> dtchen: It looks like it just needs a Main dep/build-dep (which it will get when jack is promoted)
<dtchen> ScottK: ok, thanks
<ScottK> dtchen: Is there another bug for the jack MIR?  It appears one is needed.
<dtchen> ScottK: will get it ironed out via ubuntustudio-devel
<ScottK> dtchen: OK.  Good luck.
<jdong> kees: apparmor question... Maybe PEBKAC maybe a parser bug...
<jdong> suppose I have profile foo{ profile /bin/bar{ ... } }
<jdong> i.e. a nested named subprofile
<jdong> I can add this file with apparmor_parser --add and everything is happy
<jdong> but if I pass the same file into apparmor_parser --remove, I get a "failed: profile /bin/bar doesn't exist"
<jdong> however, profile foo and foo//bin/bar are indeed correctly unloaded.
<jdong> Is this a bug with the parser not knowing how to handle subprofiles?
<jdong> in my case of letting users insert and remove subprofiles, I'm concerned if I ACTUALLY have a profile called /bin/bar system-wide, apparmor would proceed to unload that.
<jdong> scratch the latter -- it's not stupid enough to remove a same-named global profile, though it won't print out the error otherwise
<jdong> I think it is a "cosmetic bug" -- I'll file it later
<jdong> http://paste.ubuntu.com/340760/
<jdong> but just as a progress update ^^ now you can pass in snippets of an AA policy file to be loaded
<jdong> next, we'll work on --auto(magically) generating reasonable rulesets and other useful helpers that should be useful outside this project as well :)
<nixternal> ogra: is it true, that karmic will not work on my sheevaplug?
<wgrant> nixternal: Yes :(
<nixternal> argh
<nixternal> wget debian.iso
<tormod> why is that?
<nixternal> >= karmic is compiling armel packages with the armv6 flag it seems, whereas debian is still using armv5
<wgrant> tormod: SheevaPlugs are only ARMv5, whereas Karmic needs ARMv6
<nixternal> I think I have that correct
<wgrant> And Lucid needs ARMv7+thumb2
<nixternal> lovely
<nixternal> i was going to go pick up 5 of the sheevaplugs for $60/ea
<tormod> nixternal, where do you get them?
<nixternal> rethinking that now, and looking at a few mini-itx dual-core atom boards
<nixternal> tormod: online, but my dad told me about a local place that was showing them off to him...he just told me about them 30 minutes ago
<wgrant> Hopefully there will be ARMv7 SheevaPlugs/OpenRDs at some point soon :/
<nixternal> wgrant: same here...i couldn't find anything solid though
<wgrant> nixternal: Me neither.
<tormod> hmm they are more like 170$ here, one way or another
 * wgrant disappears to work.
<nixternal> wow, I have found them online for $79
<nixternal> ebay is like $150
<tormod> link? :)
<nixternal> google had a link on the side when googling "sheevaplug"
<nixternal> it might be though when you purchase more than 1, maybe if you purchase like 2 or more then they are $79/ea
<tormod> I don't get any ads on google, I don't know if I am sad or glad
<nixternal> lol
<tormod> the thing is if these shops ship to europe they only use parcel services which here is 50+ then customs ??++
<nixternal> yeah, I just noticed that as well
<nixternal> Globalscale, $99 for the plug, $30 for the cheapest ground shipping
<nixternal> for $60 more I can fly to their location, pick it up, and fly back home :)
<Trewas> pricing between US and europe is sometimes ridiculous, a while ago I was planning to buy a dell monitor but then I noticed that it would have been cheaper to fly to new york (from finland) and buy it there... so I did not buy it
<syn-ack> Trewas, Thats VAT for ya...
<Trewas> syn-ack: that's only part of it
<syn-ack> I'm sure. heh
<tormod> usually they take the price in $ and uses it in â¬, that's the first 50%+
<syn-ack> yikes
<tormod> as in the example above a 100$ product imported from US can cost 200$ altogether, the shops here know this and go as high as they can
<tormod> that's capitalism for you
<tormod> uh, free market I mean
#ubuntu-devel 2010-12-13
<ebroder> bdrung: Have you released a version of ubuntu-dev-tools with SPONSOR_PATCH_BUILDER yet? Because I want to factor that code into a library that sponsor-patch and backportpackage share, at which point it should probably be UBUNTU_TOOLS_BUILDER or something
<ebroder> (If you've released it already, I can just leave some backwards compatibility code lying around)
<hychen_> freeflying, I added https://launchpad.net/~ubuntu-sru to the bug I reported, is this right?
<freeflying> hychen_: subscribed?
<hychen_> freeflying, yes
<freeflying> hychen_: is the package in universe or main?
<hychen_> freeflying, universe
<hychen_> freeflying, it is from debian
<micahg> in most cases subscribing ubuntu-sru isn't correct anymore as the SRU team reviews in teh upload queue
<hychen_> freeflying, I also have a question, when pkg in proposed goes to update archive?
<freeflying> hychen_: after ftp-master check and approve it
<freeflying> micahg: so, in hychen_'s case, he gonna seek for a sponsor to upload it into maverick-proposed?
<hychen_> freeflying, so the issue also need to be fix in next release?
<micahg> freeflying: so, ubuntu-sponsors should be subscribed, not ubuntu-sru
<micahg> also, Ubuntu doesn't have ftpmasters, the archive admins will move an update from -proposed to -updates after the test case has been verified and it's been in -proposed for a week
<krishna_m28> how can i contribute ? I am a experienced C,c++ programmer
<hychen_> micahg, is any wiki page mentioned this?
<freeflying> micahg: same job, different titles
<micahg> hychen_: which thing?
<freeflying> hychen_: you can send me debdiff, I will upload it for you :)
<micahg> hychen_: should all be here: https://wiki.ubuntu.com/StableReleaseUpdates
<hychen_> micahg, thanks , I think I miss some important sections, I'll reviewed it again
<hychen_> freeflying, the debdiff is http://tinyurl.com/28ylvl7, but I don't know how to version the package correctly
<hychen_> freeflying, should I change the series to maverick-proposed?
<freeflying> hychen_: in which version did you find it?
<hychen_> freeflying, 1.3.7.20100910-1 in debian
<hychen_> freeflying, and is already sync to Natty
<micahg> actually, 1.3.9.2-1 is in sid and natty
<hychen_> micahg, it is ibus-chewing not ibus
<freeflying> hychen_: the one in maverick is ibus-chewing-1.3.6.20100730?
<hychen_> freeflying, yes
<micahg> ibus is at 1.3.8-1
<hychen_> micahg, you are right, my information is old, sorry
<freeflying> hychen_: A minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first.
<freeflying> hychen_: maybe you shall consider of backport it from natty
<hychen_> freeflying, follow https://help.ubuntu.com/community/UbuntuBackports . right?
<freeflying> hychen_: I think so
<xnox> There isn't a lp:ubuntu/libtool
<xnox> libtool doesn't show up on merges.ubuntu.com (although it should?)
<freeflying> hychen_: btw, ibus-chewing is in main
<xnox> and it's outdated
 * xnox libtool is wonderful
<micahg> xnox: no, it's only newer in experimental (that doesn't mean it can't be merged though)
<xnox> micahg, will be a bit of pain without lp:ubuntu/libtool and lp:debian/libtool
<micahg> xnox: you should have bzr branches available
<xnox> micahg, http://package-import.ubuntu.com/status/libtool.html
<xnox> AssertionError: Can't find the needed upstream part for version 2.2.6a-4
<micahg> xnox: oh well, I guess not
<micahg> xnox: just diff natty against sid and apply to experimental
<xnox> that's my plan =)
<xnox> Anyone ever used pull-debian-debdiff?
<micahg> hmm, fascinating
<xnox> micahg, I'll use import-dsc to import the three packages - base, mine, other, just to use merge-package
<xnox> =)
<micahg> xnox: ok, but that seems like a lot harder
<xnox> micahg, but I will be able to diff without pain =) push to lp and use a recipe for test builds :-P
<xnox> or $ bzr bd-p
<xnox> bzr alias bd-p='bd --builder="pdebuild"'
<micahg> xnox: there's no Ubuntu branch from what I can tell
<xnox> So? =) I can still push to lp:~/libtool/udd-fail
<micahg> xnox: if you like :)
<micahg> xnox: you can also check for a bug on teh udd project
<xnox> micahg,
<xnox> $ bzr merge-package ../experimental/Text conflict in debian/patches/series
<xnox> 1 conflicts encountered.
<xnox> The merge resulted in 1 conflicts. Please resolve these and commit the changes with "bzr commit".
 * xnox loves bzr-bd =)))))
<didrocks> good morning
<dholbach> good morning!
<pitti> Good morning
<micahg> pitti: good morning, can you take a quick look at a response for me to a bug before I send it?  http://pastebin.ubuntu.com/542951/ for bug 688781
<ubottu> Launchpad bug 688781 in sqlite3 (Ubuntu) "Please update to 3.7.3 or 3.7.4 in Maverick" [Undecided,Confirmed] https://launchpad.net/bugs/688781
<pitti> micahg: it's certainly an answer I can agree to :) we did put new upstream microversions into stables in the past, and sqlite has tons and tons of tests, but if people want to go ahead with that, we need to review the upstream changelog
<pitti> micahg: if .2 -> .3 is just three bug fixes, we might as well take it as it is
<pitti> if it has 50 changes, then backporting is better
<pitti> (IMHO)
<micahg> pitti: I can only find one instance of an update of sqlite3 and it was for a single patch in jaunty
<pitti> micahg: I mean for other packages, not for sqlite
<micahg> pitti: ah, ok
<micahg> pitti: .3 adds 2 interfaces, not just bug fixes
<micahg> http://www.sqlite.org/releaselog/3_7_3.html
<pitti> micahg: I guess it's then worth looking at a diff, and checking if that just adds new code (that should be rather harmless, as existing sw doesn't use it)
<pitti> micahg: anyway, this kind of research should be done by the requestor of the SRU
<tumbleweed> anyone know what's happening in bug 689345? (ancient amd64 deb still published in natty, arch:any package only seems to get built on i386 these days)
<ubottu> Launchpad bug 689345 in python-kinterbasdb (Ubuntu) "3.2-3ubuntu3 still in natty/amd64" [Undecided,New] https://launchpad.net/bugs/689345
<micahg> pitti: ok, I watch the bugs because xulrunner depends on it, also, this started because of a OMGBuntu post, so I'm guessing the users on the bug are less technical
<pitti> micahg: I guess in this case your response is just fine :)
<micahg> pitti: if you think it's worthwhile, I can review the upstream changes
<pitti> micahg: it's a lot of testing and risk involved (sqlite is used by a lot of software), so I'd still like the requestor to at least do a more through analysis of the changes
<micahg> pitti: I definitely agree with that, I'll post my comment, thanks
<pitti> micahg: "I" wouldn't go ahead with it on my own personally
<micahg> pitti: I'm also adding a line about a lot of apps using it and the burden of testing
<micahg> pitti: thanks, I have trouble sometimes deciding how much work the reporter should do
<pitti> micahg: of course, if you would like to do that, please do
<micahg> pitti: not really, I just wanted to make sure I wasn't asking too much
<smb> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smb
 * smb has little clue yet how to go on...
<dholbach> hey seb128!
<seb128> dholbach, hey! how are you?
<dholbach> great - thanks - how are you?
<seb128> I'm fine thanks
<seb128> we was nice
<seb128> I just have to catch up on 3 days backlog now ;-)
<cjwatson> doko: is the pastewebkit sync in cocoplum:~lp_archive/syncs/ yours?  perhaps you meant to flush it?
<doko> cjwatson: yes, forgot to sync
<cjwatson> doko: shall I flush it now?
<doko> cjwatson: sorry, otp. done now
<cjwatson> ok, thanks
<Keybuk> jhunt: maw-neeng
<smb> doko, moin, should I be able to dist-upgrade a maverick chroot to natty by now or is that still known to be broken (it seems one I started last week still does not get ahead, but maybe I should start over)?
<doko> smb: which package version of python is currently on your system>
<doko> ?
<smb> doko, Well it is python2.7-minimal that fails with pycompile:240: requested versions not installed. But python2.6 seems still installed
<doko> smb: that was not my question. what does dpkg -l python show
<doko> ?
<smb> python 2.6.6-2ubuntu1
<smb> (ii)
<doko> and dpkg -l python-dev python-dbg ? (start the lines with ii?)
<smb> no
<smb> both un
<smb> As noted, I started that upgrade last week. Probably some upgrade path was not right then. And now it won't get out. But I can easily just start over
<doko> smb: please get the packages python-minimal and python from https://launchpad.net/ubuntu/+source/python-defaults/2.7.1-0ubuntu3/+build/2094391
<doko> then do install these two deb's with sudo dpkg --unpack python*deb
<doko> and run sudo dpkg --configure --pending
<doko> then run an apt-get update && apt-get dist-upgrade
<smb> doko, python depends on python2.7 which is not installed
<doko> smb: ok, then get this too from the archive, and dpkg --unpack that too
<janimo> pitti: hello. Did my previous upload to libgphoto2 introduce a langpack related regression or was that always there (the one you just fixed) ?
<pitti> janimo: langpack?
<pitti> janimo: the one I fixed came from Debian
<smb> doko on the lp page you pointed me to, is that a special name? Cause I do not see a python2.7_...
<pitti> I sent the fix there, too
<janimo> pitti: ok,, I got some mail related to Chinese .po
<janimo> a few days after uploading
<pitti> janimo: ah, ignore those
<pitti> well, they are bugs in the .po files
<pitti> but we don't touch them in Ubuntu
<janimo> pitti: ok, thanks
<pitti> frankly these are mostly spamn
<doko> smb: dpkg -l python2.7-minimal python2.7 ?
<smb> ii  python2.7-mini 2.7.1-1ubuntu1 A minimal subset of the Python language (ver
<smb> No packages found matching python-2.7.
<smb> But I guess I need to follow https://launchpad.net/ubuntu/+source/python2.7
<smb> not python-default
<smb> doko, Ok, with manually installing python2.7, python (2.7) and python-minimal (2.7), the installation seems to sort itself out
<doko> smb: ok, thanks for confirming
<smb> doko, sure. thanks for sorting it out.
<janimo> Laney: hello
<janimo> Laney: ghc6 ftbfs on armel again, but this time it looks like a hung build after 18h+ and not package specific problems.
<Keybuk> the funny thing about that exim security notice is that I'd given up with exim and purged it from my mail server about one minute before kees' mail arrived
<bdrung> ebroder: i released it already, but we can change it
<ebroder> bdrung: I went ahead and wrote up the compatibility code, but whatever you prefer
<bdrung> ebroder: it's up to you to drop the compatibility code
<ebroder> bdrung: Fine. If you're going to make me make the call, I'll leave it since it's already written
<bdrung> ok
<smb> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
 * smb -> lunch
<ebroder> Keybuk: OOC, are you planning to have Upstart create implicit jobs from .service files for D-Bus activation, or make people that want to use it write proper Upstart jobs?
<Keybuk> implicit jobs?
<ebroder> I'm not sure what exactly I'd call them. "Use /usr/share/dbus-1 as a configuration source"
<Keybuk> you mean jobs that are based on different configuration parsers?
<ebroder> Why yes, that's exactly what I was fumbling to say
<Keybuk> the main use case for that is parsing /etc/init.d - which is already done by someone else
<Keybuk> so es
<Keybuk> yes
<Keybuk> I'm not sure there'd be a benefit to parsing /usr/share/dbus-1 as long as there's a dbus-daemon
<Keybuk> since that's parsing it anyway
<Keybuk> you'd need to somehow tell dbus-daemon to ignore its own configuration and send upstart events instead
<Laney> janimo: really? looks built to me
<ebroder> Keybuk: I had sort of figured that's what you would do. Otherwise what's the point of D-Bus activation?
<janimo> Laney: I'll check again, I looked on Saturday and it said it waskilled fter a timeout of 15 minutes
<Laney> janimo: don't know if it works though
<janimo> Laney: I'll check, thanks
<Keybuk> ebroder: the end goal of having init do is that it means dbus-daemon doesn't have to any longer
<Keybuk> and means we could get rid of dbus daemon in the future
<Keybuk> plus you can combine it with other things only init knows about, e.g. init can know that it can't activate that job right now, because its other requirements aren't met
<ebroder> Keybuk: Sure. It seems like a useful intermediate state would be to do exactly what you described, and have D-Bus use Upstart for service supervision
<ebroder> Keybuk: It doesn't seem like replacing the service starter with an Upstart event emitter should be that bad. Presumably dbus-daemon already has to separate service activation from actually delivering the message that spawned the service, since the message doesn't get delivered until the service finishes initializing itself
<Keybuk> right indeed
<Keybuk> I have that bit on my work items for this release
<ebroder> Keybuk: I know, I've been following. I was just seeing if I understood the plan correctly
<Keybuk> not expecting it to take more than a week to get working
<Keybuk> yeah initially the plan is to just have dbus emit the event though
<Keybuk> not for upstart to also parse dbus's config for it
<bdrung> ebroder: the builder class needs an "update" function
<Keybuk> if that turns out to be necessary
<Keybuk> then it's not hard
<ebroder> bdrung: "update" as in "run apt-get update; apt-get dist-upgrade in this chroot"?
<ebroder> Keybuk: Got it. Thanks
<bdrung> ebroder: yes. for pbuilder "sudo pbuilder update"
<bdrung> ebroder: and then a command line parameter for updating the builder before building
<ebroder> bdrung: I'm happy to do that, but can I do it as a separate branch? The backportpackage branch is already starting to become sort of massive
<ebroder> bdrung: I can open a ticket about it and assign it to myself
<bdrung> ebroder: yes
<Laney> janimo: looks broken: see bug 689496, trying the patch there now
<ubottu> Launchpad bug 689496 in ghc6 (Ubuntu) "ghci canât load unix package (/usr/lib/libpthread.so: invalid ELF header)" [Undecided,New] https://launchpad.net/bugs/689496
<janimo> Laney: hmm so it builds packages but does not make them correct?
<Laney> right
<janimo> ok
<janimo> Laney: at least Setup.hs built, since some of the packages progressed on retry
<Laney> janimo: It's in the RTS, so I hope the next version will fix it
<janimo> great
<pitti> cjwatson: would you mind if I test/apply the patch in bug 415038 before you consider it for Debian?
<ubottu> Launchpad bug 415038 in debconf (Ubuntu) "port GNOME frontend to GtkAssistant" [Medium,Triaged] https://launchpad.net/bugs/415038
<cjwatson> pitti: it's on my queue to review today-ish
<cjwatson> pitti: I'd prefer if I reviewed it before we applied it
<cjwatson> there are all sorts of amusing things that could go wrong with a broken frontend
<pitti> cjwatson: ok; it needs some porting to the current version, so I'll do that and attach the patch
<cjwatson> non-trivial porting?
<pitti> yes
<cjwatson> hm, ok
<pitti> the current version disables some window functions (close button, etc); should be "easy", but not just simple fuzz
<pitti> and I generally want to test it with synaptic and s-c before we roll this out
<cjwatson> I want to test some of the more obscure features of debconf
<pitti> cjwatson: right; so it sounds we'll work on different things then
<cjwatson> I'll wait 'til you attach your current version before starting
<bdrung> ebroder: the "# TODO: Add "retry" and "update" option" was for adding a option to ask_for_manual_fixing() to update the builder from there
<pitti> cjwatson: is there a quick method to use "test_debconf.pl" or similar with the gnome frontend? (quicker than rebuild/install/synaptic install xdm)
<pitti> aah
<pitti> DEBIAN_FRONTEND=gnome samples/demo
<cjwatson> yes
<asac> pitti: whats the status of the kernel SRU for bug 651370 ?
<ubottu> Launchpad bug 651370 in linux (Ubuntu Maverick) "ec2 kernel crash invalid opcode 0000 [#1]" [Medium,Fix committed] https://launchpad.net/bugs/651370
<pitti> asac: it awaits regression testing from our QA team
<asac> pitti: thanks. is that happening automatically? or should we send a reminder?
<pitti> asac: reminder already happened
<asac> kk
<pitti> cjwatson: I ported janimo's patch, but it apparently doesn't return correct values now; I'll investigate further after lunch
<smb> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smb
<smb> Hm, for requests that ask for merging newer debian versions into ubuntu and there is a debdiff. Is there a simple way to get the new orig.tar.gz or do I have to search?
<cjwatson> you can set up chdist to have a configuration pointing to Debian unstable, and then use 'chdist apt-get unstable -d source <packagename>'
<cjwatson> man chdist
<pitti> smb: I usually download it from the PTS (http://packages.qa.debian.org/pkgname) or my unstable chroot
<smb> pitti, Ah thanks. Dumb follow up: what does PTS stand for?
<pitti> smb: Package Tracking System
<Keybuk> Package Tracking System
<smb> Heh, ok. Thanks
<Keybuk> cjwatson: I have a C/POSIX-ish query for you
<cjwatson> I always love those
<Keybuk> need a competant lawyer to validate my idae
<Keybuk> (and my spelling)
<Keybuk> would this be wrong?
<Keybuk> union {
<Keybuk>     struct tm tm;
<Keybuk>   int bits[7];
<Keybuk> };
<cjwatson> what were you then planning to do with that union?
<Keybuk> well, the idea is that bits[0] is then directly equivalent to tm.tm_sec
<Keybuk> bits[3] is tm.tm_mday
<elmo> in the library with the revolver
<Keybuk> bits[6] is tm.tm_wday
<Keybuk> and use the array as a way of indexing the components of the struct
<cjwatson> my gut feel is that that's the sort of thing where strict-aliasing trips you up
<cjwatson> which would be likely to cause optimisation difficulties aside from anything else
<cjwatson> though are you asking if the alignment is guaranteed to be identical?
<Keybuk> ah, but it's a union
<Keybuk> strict-aliasing doesn't apply to unions
<Keybuk> (that's kinda the point of them)
<cjwatson> um
<cjwatson> sort of
<penguin42> is the ordering of that even vaguely guaranteed to be portable?
<Keybuk> penguin42: that's kinda my question really
<Keybuk> I'm pretty sure that a struct of 7 ints is directly equivalent to an array of 7 ints
<Keybuk> and have put the book down
<cjwatson> http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html points out that using unions for that is technically undefined unless one of the punned elements is a char *
<cjwatson> (although widely supported anyway)
<cjwatson> (best explanation I've found of strict-aliasing and related issues)
<Keybuk> yeah I was reading that
<Keybuk> the idea of my hack above is that by putting the tm and int array into the union
<Keybuk> you're declaring to the compiler that they *do* share the same memory location
<Keybuk> it's not a pointer to the tm, it's the tm itself that's in the union
<cjwatson> OK, so.  structs are memory-ordered in declaration order (6.2.7.1(5,13)).  There may be unnamed padding within a struct (6.2.7.1(13)).  Arrays are "contiguously allocated" (6.2.5(20)), while structs are merely "sequentially allocated".
<cjwatson> I think you're in an area that in practice will always work but is not technically defined thus
<cjwatson> (because for it not to work, you'd have to need alignment for ints, which would be a strange implementation choice)
<Keybuk> even if you had alignment for ints, both the array and struct would have to align on that boundary, no?
<Keybuk> it'd only not work if the struct as a whole was aligned to something far wider than the int alignment
<cjwatson> that's not how I read "contiguously allocated"
<Keybuk> e.g. each member of the struct was on an 8-byte boundary
<Keybuk> on a platform with a 2-byte boundary
<Keybuk> which I guess the compiler is allowing for
<cjwatson> arrays don't get to have internal alignment, even if that's what the platform would normally want
<Keybuk> cjwatson: sure they do, otherwise &(a[2]) wouldn't be valid
<Keybuk> you can't take the address of an unaligned object
<Keybuk> s/compiling is allowing for/standard is allowing for/
<cjwatson> err.  char a[16]; &(a[3]) is permitted on any platform, AIUI.
<Keybuk> sure because the alignment rules of char * are 1
<smoser> pitti, is there any thing blocking moving cloud-init into lucid-updates.  (0.5.10-0ubuntu1.5  bug 683890)
<ubottu> Launchpad bug 683890 in cloud-init (Ubuntu Lucid) "config-grub does not run" [High,Fix committed] https://launchpad.net/bugs/683890
<cjwatson> none of this means that arrays ever have internal alignment
<cjwatson> show me an example where they ever do
<Keybuk> ok, hypothetical platform
<cjwatson> my understanding is that that's explicitly forbidden by "contiguous allocation"
<Keybuk> this platform has 8-byte alignment for int
<Keybuk> but 4-byte ints
<cjwatson> otherwise, what does the difference between "contiguous" and "sequential" mean?
<Keybuk> if you had an array of two ints that was 4-byte aligned rather than 8-byte aligned
<Keybuk> then:
<Keybuk>   int *a = &(a[1]);
<Keybuk> would be useless
<Keybuk> you couldn't retrieve *a or assign to *a without breaking the platform's alignment rules
<smb> pitti, Another of my stupid questions: in the maintainers section is a change from "Ubuntu Core Developers" to "Ubuntu Developers" correct?
<Keybuk> I was suggesting that the standard is allowing the struct to use a wider alignment if it needs to
<Keybuk> e.g. even if the int was 4-byte aligned, it could choose to 8-byte align the struct members
<Keybuk> (perhaps it aligns them to the largest alignment of any member)
<cjwatson> that works as a reductio ad absurdum, but only if the alignment of ints is the only reason why the platform might insert internal padding into a struct
<cjwatson> right, and *that* would break your model.  but in practice I doubt it will happen ...
<Keybuk> yeah, it'd be an odd thing to do :p
<dholbach> smb, we changed to "Ubuntu Developers" (https://wiki.ubuntu.com/DebianMaintainerField)
<Keybuk> deliberately inserting space into structs would be curious
<Keybuk> but maybe the standard isn't disallowing it
<Keybuk> thus the difference in terminology
<dholbach> smb, so we don't distinguish between packages that are in main or in universe
<cjwatson> the standard doesn't forbid it, that's all.  and since you were asking for standards lawyering :)
<smb> dholbach, Ok, thanks. Then it is correct as it is
<Keybuk> (likewise in practice, no platform I've ever heard of uses anything other than word or int-sized alignment for int types)
<cjwatson> right
<Keybuk> so I guess it's a decision of whether to err on the side of "this works, and gcc doesn't even complain" or not
<cjwatson> wait, one other question
<cjwatson> POSIX doesn't, AFAICS, guarantee the *ordering* of struct tm members
<cjwatson> it says "The <time.h> header shall declare the tm structure, which shall include at least the following members:"
<cjwatson> but nothing about what order they come in, whether extra things can be inserted in between, ...
<Keybuk> ah
<Keybuk> good catch
<cjwatson> I imagine most new platforms copy and paste the sequence from POSIX, but I'm not sure about legacy platforms
<Keybuk> so glibc could randomly move that around between releases
<doko> Laney: how did you find out about the missing -lpthread in ghc6?
<Keybuk> well, I don't really care about legacy platforms
<Keybuk> but I do care about Drepper having a brain-wave and breaking code
<cjwatson> where "legacy" means "anything that was initially created before POSIX"
<Keybuk> though that'd be an ABI break I guess
<cjwatson> (er, yeah, slightly eccentric meaning of "legacy" there)
<smb> dholbach, Hm, reading the link you posted. Should then, instead of XSBC-Original-Maintainer", the "Debian-Maintainer" be used?
<Keybuk> Linux's documentation explicitly declares the order of the fields, of course
<dholbach> smb, no XSBC-Original-Maintainer should be fine (update-maintainer from ubuntu-dev-tools usually does that for me :-))
<cjwatson> smb: the poll said Debian-Maintainer, but we never used that in practice
<smb> Ah, ok.
 * smb is just looking at the changes from a debdiff
<cjwatson> Keybuk: right, and it would indeed be pretty hard (impossible?) to change without breaking existing binaries
<Keybuk> impossible, certainly
<cjwatson> Keybuk: again, not sanctioned by standards but probably OK in practice
<Keybuk> yaeh, hmm
<Keybuk> likewise you couldn't actually change the alignment of the struct :p
<Keybuk> so if it works now, it'll work forever
<Keybuk> and break when we roll out a new architecture
<cjwatson> yeah, nothing to stop a new arch having whatever field ordering it feels like - in theory
<Keybuk>    * `A member of a union object is accessed using a member of a
<Keybuk>      different type (C90 6.3.2.3).'
<Keybuk>      The relevant bytes of the representation of the object are treated
<Keybuk>      as an object of the type used for the access.  *Note
<Keybuk>      Type-punning::.  This may be a trap representation.
<Keybuk> ..
<Keybuk> It's a Trap!
<pitti> smoser: bug 683379 hasn't been verified yet, but otherwise it looks ok
<ubottu> Launchpad bug 683379 in grub2 (Ubuntu Natty) "user prompted twice on ec2 grub-pc upgrade from 1.98-1ubuntu7 to 1.98-1ubuntu8" [High,Confirmed] https://launchpad.net/bugs/683379
<Keybuk> cjwatson: hmm, reading a bit more
<Keybuk> apparently it's *recommended practice* for a compiler to align struct members by the most restrictive member
<Keybuk> rather than the individual member's own alignment
<Keybuk> (c-faq)
<Keybuk> ok
<Keybuk> I think I've persuaded myself out of doing that now
<smoser> pitti, i had verified that last week, just forgot to mark the tag on that bug (since really the 3 bugs fixed were the same bug)
<smoser> i'll go ahead and put a quick verify in though.
<kirkland> stock natty + unity, dist-upgraded this morning;  everything across the top bar disappeared (ie, no netwok manager, no sound indicator, no messaging menu)
<kirkland> suggestions?
<kirkland> (besides "reboot into classic desktop")
<penguin42> kirkland: Do you see a seg of unity-panel-ser in your dmesg?
<kirkland> penguin42: yeah, there is a video related segfault
<penguin42> kirkland: I'm trying to file abug against unity-panel-ser but apport is refusing most annyoyingly
<kirkland> penguin42: cool, thanks, subscribe me (kirkland) when you do
<didrocks> kirkland: uninstall indicator-datetime
<didrocks> kirkland: and restart compiz
<smb> Ok, so that debdiff looks mostly ok. What would be the usual mode to go on. Ask the person that has provided the debdiff to bzr pull request? Do it ourselves?
<kirkland> didrocks: okay, thanks, will do in a few minutes
<doko> cjwatson: ping about bug #688839
<ubottu> Launchpad bug 688839 in dpkg (Ubuntu Natty) "proposal to turn dh_shlibdeps warning into an error" [High,New] https://launchpad.net/bugs/688839
<cjwatson> doko: I'm not confident with that - please bring it up with the Debian dpkg folks
<cjwatson> doko: I suspect that the proposed change would break plugins
<cjwatson> but buxy will know more
<doko> cjwatson: yes, it would. but making this an error for anything in /usr/lib would be a good thing
<doko> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=unresolved-symbols-so;users=peter.fritzsche@gmx.de
<seb128> doko, it seems it would bring extra work for no real reason
<seb128> can't we just set it as a soft goal for natty?
<seb128> rather than forcing people to have to deal with builds breaking now
<doko> seb128: I don't consider unresolvable symbols at runtime a soft reason
<cjwatson> doko: I'm not going to take responsibility for making this change - please discuss it with buxy et al, they have more facts than I do
<doko> cjwatson: I'll do
<cjwatson> doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558872 is listed there and I happen to know that that library would break if you didn't allow that unresolved symbol
<cjwatson> it's a slightly weird library that requires the application to supply that symbol
<Laney> doko: misbuilds on armel
<Laney> geser reported it to me
<doko> cjwatson: however I know buxy's reply. debian doesn't build with --no-add-needed, so why do you report it here ...
<Laney> sorry, ftbfs not misbuilds
<cjwatson> doko: why not let buxy reply rather than putting words in his mouth?
<cjwatson> anyway, for me, Debian bug 558872 is an example of why this shouldn't be an error across the board - there has to be a way to override it
<ubottu> Debian bug 558872 in src:libcgic "Resolve unresolved symbols in shared libraries" [Wishlist,Open] http://bugs.debian.org/558872
<doko> well, I got similiar replies from him on dpkg-gensymbols ...
<Laney> doko: Anyway, I think I can revert the explicit linking on -lpthread as it was only needed for the bootstrap afaics
<Laney> the real fix was a patch I grabbed from the upstream tracker together with the one in ubuntu3
<doko> Laney: ahh, ok. just wanted to understand why it was needed
<Laney> http://hackage.haskell.org/trac/ghc/ticket/4523
<Laney> that ticket
<RoAkSoAx> doko: I have a question that you might help me with :). I have a package that FTBFS because of the --no-add-needed thingy... So I modify Makefile.am, but the changes don't apply in build time. So, do I also have to manually modify the Makefile.in or should I run autoreconf to recreate the .in file?
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smb, sconklin
<doko> cjwatson: could you outline why libcgic needs it?
 * JFo waves at the friendly neighborhood patch pilots
<cjwatson> doko: I followed up to the Debian bug
<cjwatson> doko: it's just how the library is designed, it expects the application to provide that symbol.  I wouldn't have done it that way myself, but it is how it is
<cjwatson> (just one I happened to recognise off the list since I maintained the Debian package for it at some point in the past)
<doko> ok, thanks for the feedback
<Keybuk> Ugh, WHY is this necessary?!  http://paste.ubuntu.com/543086/
<Keybuk> *cry*
<cjwatson> I think the way it works is that libcgic provides main() itself and you provide cgiMain() which it calls after initialisation
<cjwatson> bit weird
<geser> RoAkSoAx: I prefer to also patch the Makefile.in if the change is simple and the package doesn't already use autoreconf as I don't know exactly how to autoreconf it properly and not break it
<doko> RoAkSoAx: depends on the build system ...
<RoAkSoAx> geser: ok thanks ;)
<RoAkSoAx> doko: debhelper, package is openhpi
<hallyn_> mvo: looking to do a vmbuilder upload.  soren points out you recently did an upload.  What was your process? Did you just make the changes to lp:vmbuilder, drop in a copy of debian/ from the package, and then dput the results?
<mvo> hallyn_: hello! I used the "packaging" brnach of vmbuilder for the build
<mvo> hallyn_: and in there just "bzr-buildpackage --merge"
<mvo> hallyn_: well "bzr-buildpackage --merge -S" to be exact :)
<kenvandine> kirkland, did you get a chance to test unity with removing indicator-datetime?
<hallyn_> mvo: so you didn't touch lp:vmbuilder at all?
<mvo> hallyn_: if you do another bzr snapshot, make sure to use the updated bzr revno in the change, bzr-buildpackage will checkout the right one based on this number (I love bzr-buildpackage)
<mvo> hallyn_: initially I didn't, I applied some patches into trunk now though, let me quickly check
<hallyn_> mvo: i don't know what that means :)  if i do 'bzr co lp:ubuntu/natty/vm-builder', am  'doing a bzr snapshot'?
<mvo> hallyn_: oh, sorry. hold on a sec, I will try to express it better
<mvo> hallyn_: I did "bzr co lp:~vmbuilder-dev/vmbuilder/packaging" and then in there "bzr-buildpackage -S" to get the source upload (and without -S to get the deb of course)
<hallyn_> interesting, trying
<kirkland> didrocks: that worked, thanks
<kirkland> kenvandine: worked, thanks!
<mvo> hallyn_: the version number is current "0.12.4+bzr459-0ubuntu1" in packaging/changelog, if you want to create a upoad from revno480 just add a new version with revno480 in it
<mvo> hallyn_: its magic :)
<kenvandine> humm
<kenvandine> kirkland, thx
<mvo> hallyn_: but note that I'm not really attached to this workflow, you are the maintainer, pick the one that you like best
<mvo> hallyn_: it was just what soren used (or at least it looked likt it, the branch was later a bit out-of-sync)
<hallyn_> mvo: well on the one hand i don't want to decide until i try this way :)  OTOH i'm afraid i'll totally mess up the archive like i did with kvm
<hallyn_> wait, now *why* is version # 0.12.4+bzr459-0ubuntu1 ?
<mvo> hallyn_: I'm happy to help and check before uploading etc
<hallyn_> mvo: so the rationale is that you have multiple small packaging branches (one per distro), with one shared real source branch?
<mvo> hallyn_: I used this version because I did not want to make a new upstream release, afterall I'm not maintianer of the upstream branch
<highvoltage> Riddell: hey, as an archive admin you probably noticed a bunch of zope and schooltool related packages uploaded to NEW the last week
<mvo> hallyn_: yeah, its frowned upon by some people (hey james_w ;) but its nice in the sense that its tiny
<hallyn_> so is debian/watch ignored?
<james_w> hi mvo :-)
<hallyn_> i'm trying to find a reference to lp:vmbuilder for the main source
<highvoltage> Riddell: they are a bit of an exception to the usual process since they do not have needs-packaging bugs
<Riddell> highvoltage: I don't really care about needs-packaging bugs
<Riddell> I'll process new tomorrow
<soren> hallyn_: What do you mean?
<mvo> hallyn_: no, its used if there is a upstream release
<highvoltage> Riddell: ok, great! if there's anything you need with them, feel free to poke me or dholbach
<mvo> hallyn_: again, magic, if you put 1.2.23 there and that is a released version, it will automatically download the right file for you
<mvo> hallyn_: I love it
<mvo> hallyn_: aha, sorry. that one if in .bzr-builddeb/default.conf
<hallyn_> oh, i see, so we do have to create a new release tarball of the lp:vmbuilder source in order to get a new release?
<mvo> hallyn_: there is a ref to the right branch
<hallyn_> oh
<mvo> hallyn_: both works
<hallyn_> ok
<mvo> hallyn_: for releases, just put a release version number and run bzr-builddeb and it will fetch the tarball from LP
<mvo> hallyn_: for bzr versions, it will checkout the right branch
<hallyn_> yeah,'put a release number' into the packaging changelog?
 * hallyn_ likes magic, but onlymagic he can control
 * smb wonders how just some additional upload done by pitti to e2fsprogs helps to reduce the cd size. There did not seem to be a change to the package
<pitti> smb: I set debian/build_pressure to 10 kPa :)
<mvo> hallyn_: ok, so if there is 0.12.5-0ubuntu1 in the changelog, it will look at the debian/watch location
<smb> pitti, archive magic...
<pitti> smb: seriously, natty's pkgbinarymangler removes upstream changelogs, trims debian changelogs, and optimizes PNG files now
<mvo> hallyn_: for a upstream version like this, I think the bzrXXX triggers the magic
<pitti> smb: so I made a list of all packages which we have on the CD, haven't been rebuilt in natty, and carry large changelogs or PNG files
<smoser> pitti, so apologies for both nagging and being unfamiliar with process, but after I've verified a bug in -proposed , and its sat in -proposed for a week, what then happens ?
<pitti> smoser: it can go to -updates
<smoser> so you (or someone else on SRU team) then pushes a button ?
<smb> smoser, is that in the kernel?
<pitti> smb: rightg
<pitti> smb: no, cloud-init
<smoser> smb, i'm that one, no.
<smoser> https://launchpad.net/bugs/651370 would be nice to see pop into -updates sometime this week though
<pitti> oh, smoser is a kernel :)
<ubottu> Ubuntu bug 651370 in linux (Ubuntu Maverick) "ec2 kernel crash invalid opcode 0000 [#1]" [Medium,Fix committed]
<smoser> smb, that should have said "not that one, no".
<doko> mterry: cluster MIR ping
<smoser> anyone with more familiar wth recent changes in the python stack able to suggest what might have caused bug 688773
<ubottu> Launchpad bug 688773 in euca2ools (Ubuntu) "euca2ools give 'SignatureDoesNotMatch' error" [Undecided,New] https://launchpad.net/bugs/688773
<mterry> doko, hi
<smoser> (euca2ools and boto -- the relevant packages have not recently changed)
<pitti> cjwatson: do you want me to commit http://launchpadlibrarian.net/60009278/debconf_1.5.36ubuntu1_1.5.36ubuntu2.diff.gz to the packaging branch? or did you abandon this branch now and use lp:ubuntu/debconf?
<pitti> (this just caused some confusion here)
<doko> mterry: what do you want me to look at?
<mterry> doko, oh, nothing anymore.  I had a question about a library correctness thing, but it got answered by others.  thanks
<cjwatson> pitti: I want to use something based on the bzr import of upstream svn, but that's currently failing so I can't
<cjwatson> pitti: right now I'm just not using revision control for debconf at all
<ari-tczew> cjwatson: could you sponsor lilo merge?
<cjwatson> pitti: I'd rather you just attached it to the bug for now
<cjwatson> ari-tczew: yes, let me drop everything and do that
<pitti> cjwatson: ok
<ari-tczew> cjwatson: you've my ACK
<doko> mterry: so ok to promote pacemaker, cluster-glue, cluster-agents, heartbeat, libasyncns, libesmtp, libnet, openhpi?
<mterry> doko, no, actually.
<mterry> doko, there was a licensing issue with pacemaker at least.  waiting on upstream.  I don't know about all those bugs
<mterry> doko, but bug status is up to date for my bugs anyway
<doko> mterry: so we need to promote these all at once, and it's needed to build for python2.7 ...
<mterry> doko, sorry, I don't follow.  You're saying the cluster stack is needed for python2.7 or that the cluster stack hasn't yet been rebuilt for python2.7?
<doko> mterry: the latter. ocfs2-tools needs to be rebuilt
<mterry> doko, OK.  So what's the issue?
<doko> mterry: compoment mismatches
<RoAkSoAx> mterry: im working on the licensing thing alreayd. patches have been accepted upstream
<mterry> RoAkSoAx, awesome
<mterry> doko, I'm just not understanding how the rebuild and the MIR are connected is all
<doko> seb128, didrocks: any chance to look at the libgda4 build failure?
<doko> mterry: $ apt-cache show ocfs2console|grep Depends
<doko> Depends: libblkid1 (>= 2.15~rc2-1ubuntu1), libc6 (>= 2.7), libcomerr2 (>= 1.01), libglib2.0-0 (>= 2.12.0), libuuid1 (>= 2.16), python (<< 2.7), python (>= 2.6), python-support (>= 0.90.0), ocfs2-tools (= 1.4.3-2), python-gtk2
<doko> mterry: uninstallable and cannot be rebuilt: https://launchpad.net/ubuntu/+source/ocfs2-tools/1.4.4-3build1
<seb128> kenvandine, mterry: ^ how busy are you? could you look at the gda build issue?
<seb128> it's gir related and you know those issues the best atm I think
<mterry> seb128, I'm doing unity stuff right now, but nothing important
<mterry> seb128, can look
<kenvandine> seb128, i really want to get to the bottom of this unity/indicator-datetime problem
<seb128> kenvandine, mterry: ok thanks, let's say mterry can do it, thanks!
<seb128> doko, ^
<mterry> doko, ah, I see.  So someone promoted ocfs2-tools too soon?
<doko> saw it, thanks
<kenvandine> thx mterry
<doko> mterry: no, it always was in main, just gained new dependencies
<mterry> doko, well we can either depromote it, promote the cluster stack, or wait.  Sounds like you don't want to wait.  I can't speak for how ready the rest of the cluster stack is.  I'd have to look at other MIR bugs
<mterry> doko, fine, then gained new dependencies too soon.  :)
<seb128> doko, can we promote geoclue? it's blocking an indicator build which is breaking unity...
<doko> seb128: mterry did the review, I did ask kees / security at the daemons too
<doko> on Friday he said to do it on Monday (today)
<seb128> doko, right, what I'm asking is if we really need to wait on security
<seb128> unity is broken until we sort that situation
<seb128> so we either need to roll back to old versions not using geoclue in some way
<seb128> ot to get geoclue promoted
<doko> please can we wait until tonight? I think I should write something about pre-promotions ...
<seb128> doko, well we can, unity is just broken for everybody running natty while we wait
<seb128> no indicator is loading at all
<pitti> I thought we could rollback to the previous version for now?
<seb128> kenvandine, can you upload a new.is.old version then?
<kenvandine> yup
<seb128> pitti, well geoclue and ofono got mir review acks from mterry
<seb128> pitti, so promoting seemed the easier way forward
<seb128> but seems we need a security team review as well before
<pitti> seb128: ah, ok; didn't know the full story
<kenvandine> seb128, how do i handle that in the bzr branch considering the branch is also merged from the upstream source?
<seb128> kenvandine, don't use the vcs
<kenvandine> ok
<seb128> just take the old version from launchpad, rename it and upload
<kenvandine> figured
<kenvandine> and with the next upload, i'll just include the changelog entry?
<seb128> or not as you want
<seb128> but yeah you can
<kenvandine> ok
<kenvandine> will do
<mterry> doko, at least cluster-agents seems unreviewed
<mterry> doko, and libasyncns doesn't have a MIR filed?  Is it part of the cluster stack?  So pacemaker has an easily-fixable license oddity change coming, I can review cluster-agents today.  That would leave libasyncns
<doko> mterry: heartbeat, libnet and openhpi were already in main, do you want the dh_makeshlibs -V thing happen before the promotion?
<doko> mterry: ok, preparing a MIR for libasyncns. can you review it later?
<mterry> doko, for cluster-glue?  That change already happened
<mterry> doko, sure
<doko> ohh, right
<kenvandine> kirkland, could you please get me a full package list?
<kirkland> kenvandine: on my system?
<kenvandine> kirkland, i am trying to narrow down the root cause of the unity panel not loading
<kirkland> kenvandine: k
<kenvandine> the one with the indicator-datetime problem
<kenvandine> thx
<kenvandine> kirkland, today's live image works
<kenvandine> so something installed is causing the problem
<kirkland> kenvandine: https://pastebin.canonical.com/40874/
<kenvandine> thx
<kirkland> np
<smb> pitti, cjwatson Question about style and process:
<smb> bug 681418
<ubottu> Launchpad bug 681418 in e2fsprogs (Ubuntu) "Please merge e2fsprogs 1.41.12-2 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/681418
<pitti> looking
<pitti> smb: if you mean my extra changelog, feel free to ignore it; it was just a no-change rebuild
<smb> The debdif was mostly ok. The guide says sort of "ask for a merge request"
<smb> For training I created a branch (with your null change)
<smb> but Ted says he has the next version ready soonish
<ari-tczew> smb: could you have a look on bug 669363 ?
<ubottu> Launchpad bug 669363 in lilo (Ubuntu) "Please merge lilo 1:22.8-8.3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/669363
<smb> So would we want to upload the current version anyway? Or wait? And if taking the current version, offer my bzr branch although it is just reflecting the other guys merge work.
<smb> ari-tczew, I can, but bear with that I am not too familiar with the process yet and thus slow. :)
<pitti> smb: if your branch is not more than just the attached debdiff applied, I don't think it buys much
<ari-tczew> smb: not good
<benste> hi, no one in #ubunut and #ubuntu-de could yet answer me how to mount smb shares in 10.10 unity
<pitti> smb: I don't think there's anything wrong with uploading it now, if it works and was tested
<benste> i did it back in 10.4 via gvfs and nautilus cklicking the places menu
<pitti> smb: there was no definitive "tomorrow" for the new releasey
<smb> pitti, The only small change would be to drop the vcs-git from the control.in as well
<benste> someone here who knwos more about how unity works ?
<BlackZ> smb: I was about to update the debdiff but I seen you have been more fast than me :) thanks
<smb> BlackZ, Hi, well actually I have not done a separate debdiff file (thought that would be quick). I was interested in learning how the bzr merge request would work
<smb> As I was neither sure whether the right way is just a debdiff or have that merge request way
<BlackZ> smb: yeah, I noted that you haven't update the debdiff but I seen you linked a bzr branch to the bug report (if it contains the corrections it is fine)
<BlackZ> smb: either way are fine
<smb> pitti, Which happens if you let kernel devs be patch pilots without mandatory training sessions before. ;)
<smb> BlackZ, I did?
<smb> Must be something magic going on...
<cjwatson> ari-tczew: stoppit, I'm doing it.
<cjwatson> smb: no need to deal with lilo
<smb> cjwatson, Ok, cheers
<BlackZ> smb: maybe it's because you close that bug in your bzr revision?
<smb> BlackZ, Oh I see. Just having done the debcommit to the bzr branch and then pushing it, created the link. :)
<smb> BlackZ, Actually I wanted to ask whether that is a bit rude before doing the link, but automatic things decided that for me.
<BlackZ> heh
<cjwatson> ari-tczew: in future, please don't bother to ask me to do something if you're just going to ask somebody else about an hour afterwards even when I've said yes.
<cjwatson> it's a waste of everyone's time ...
<smb> pitti, So the only difference between the attached debdiff and my branch is your changelog entry and the removed vcs-git in control.in
<cjwatson> (it's done now)
<ari-tczew> cjwatson: I got you response as sarcasm
<ari-tczew> (and I re-reply as the same)
<cjwatson> well, I *was* doing other things, but nevertheless I did it
<tumbleweed> can an archive-admin please reject the googleearth-package maverick-proposed upload?
<smb> BlackZ, Ok, as it is actually the same code with just minor changes I just made a merge request for it to get the process ahead
<BlackZ> thanks for you work, smb ! :)
<smb> BlackZ, NP. Actually you did most of it.
<doko> mterry: hmm, libasyncns is unrelated
<mterry> doko, k, cool
<doko> mterry: well, noticed too late, already updated ...
 * smb believes to have done enough chaos for one day
<smb> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: sconklin
<kees> doko, seb128: lost to backscroll... which thing did you want me to look at?
<seb128> kees, geoclue
<seb128> or ofono
<seb128> kees, I think it's ofono (whichis a dep of geoclue)
<kees> okay, give me a bit, and I'll look it over.
<doko> kees: the daemons in ofono and gypsy, ohh and maybe a security for each unity upstream version? ;p
<doko> s review even
<SpamapS> Keybuk: around? I'm wondering about abstraction of events in upstart .. seems like 'stop on runlevel [016]' isn't exactly doing what we want (see bug 688541)
<ubottu> Launchpad bug 688541 in mysql-5.1 (Ubuntu) "race condition on shutdown (leads to corrupted fs)" [High,Triaged] https://launchpad.net/bugs/688541
<Keybuk> hey
<Keybuk> abstraction of events?
<SpamapS> Yes, like, instead of having people put 'stop on runleve [016]' they'd put 'stop on stopping-network-services'
<RoAkSoAx> mterry: would you like to review pacemaker's diff before I upload?
<SpamapS> Keybuk: I'm just concerned that by being so explicit in the events of regular services, we are making a lot of work for ourselves later on.
<Keybuk> I don't understand, sorry
<Keybuk> could you expand a little?
<doko> mterry: #689766
<SpamapS> Keybuk: I'm suggesting hiding common stop on / start on scenarios behind other events or other jobs... so an example would be mysql .. which does 'start on (local-filesystems and net-device-up IFACE!=lo)' and 'stop on runlevel [016]' .. squid also works this way. But it may be that we need to actually have them stop on something else that commonly happens.. like have them stop *before* unmounting all filesystems .. it would be easier to make th
<Keybuk> that's what you're supposed to do
<Keybuk> you're supposed to make jobs that encapsulate a comon start on/stop on combination
<Keybuk> and then use other jobs off that
<Keybuk> rather than copy/pasting lines between jobs
<SpamapS> I'm so glad you said that. :) I thought maybe I was crazy thinking this way. ;)
<Keybuk> one solution to the rc0/6 race is to have the umountfs job start with
<Keybuk>   initctl emit unmounting-filesystems
<Keybuk> then if you had any job (or state) wiht stop on unmounting-filesystems
<Keybuk> it'd wiat
<SpamapS> heh.. GMTA https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/688541/comments/5
<ubottu> Ubuntu bug 688541 in mysql-5.1 (Ubuntu) "race condition on shutdown (leads to corrupted fs)" [High,Triaged]
<SpamapS> Keybuk: basically, local-filesystems needs a mirror event.
<Keybuk> yes
<mterry> RoAkSoAx, uh, if it fixes the license issue, I can just review after the fact
<mterry> RoAkSoAx, should be fine after that is fixed
<mterry> doko, so do you want me to review libasyncns after all?  I thought you said we didn't need it?
<doko> mterry: no, not now
<RoAkSoAx> mterry: there's one file that hasn't been changed given that upstream wasn't unsure to do that because they didn't write that code in particular
<RoAkSoAx> mterry: other than that, everything was changed
<RoAkSoAx> s/changed/fixed
<seb128> who is doing syncs?
<seb128> whoever that is it would be nice to -S experimental pyclutter
<seb128> -S experimental telepathy-glib
<dholbach> ok my friends
<dholbach> I call it a day
<dholbach> see you
<pitti> mdke: here by chance?
<bryceh> heya pitti
<pitti> hi bryceh
<bryceh> pitti, question on bug #680811, which is in maverick-proposed for sruing...
<ubottu> Launchpad bug 680811 in xorg-server (Ubuntu) "incorrect maximise behaviour with twinview" [Undecided,Incomplete] https://launchpad.net/bugs/680811
<bryceh> pitti, cnd has another xserver patch in the hopper, and we're wondering if it should be numbered 7.2, or if the above sru is not going to go through soon in which case it should be 7.1 ?
<ScottK> bryceh: If it's in -proposed already you'll have to bump the version number since soyuz already has marked 7.1 used.
<cnd> I'd also like to know why it's 7.1 and not 8?
<bryceh> ScottK, ok
<ScottK> cnd: We ~always do that for post-release updates
<bryceh> cnd, the 8 would presumably be in natty
<pitti> bryceh: you always have to bump the version number
<cnd> ahh
<cnd> ok
<pitti> bryceh: the only difference is that you'd build with -v<version_in_updates> if you stack multiple -proposed uploads on top of each other
<bryceh> cnd, so if someone upgraded, they can safely upgrade 7.1 -> 8, whereas if both natty and maverick had 8 it wouldn't upgrade them
<bryceh> pitti, ok thanks
<Daviey> slangasek: Hi... Are you doing Archive Admin stuff today?
<c_korn> when do the nvidia drivers in the repository get updated? there is a race condition bug which has been fixed in 260.19.21. it causes some games to crash: http://www.nvidia.com/object/linux-display-amd64-260.19.21-driver.html
<SpamapS> c_korn: lots of bug reports here, but I'd guess it would need to be reported and triaged if it hasn't already:  https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers
<ari-tczew> c_korn: ask tseliot
<c_korn> hm, just filed bug 689832
<ubottu> Launchpad bug 689832 in nvidia-graphics-drivers (Ubuntu) "[package request] Version 260.19.21 fixes race condition" [Undecided,New] https://launchpad.net/bugs/689832
<RoAkSoAx> mterry: uploaded!
<RoAkSoAx> (pacemaker)
<mterry> RoAkSoAx, oh nice, I'll recheck it
<RoAkSoAx> mterry: awesome! Thanks... ;) Btw.. there's only one single file under lib/ without the change given that upstream was not confortable changing that file license header due to that it was not written by them
<mterry> RoAkSoAx, but they are comfortable shipping it without knowing the license?
<sabdfl> RoAkSoAx: congrats on the graduation
<RoAkSoAx> sabdfl: thank you! :)
<slangasek> Daviey: I can do some, but haven't been diligent about doing so routinely; anything in particular that you need?
<Daviey> slangasek: I'm just wondering why the libvirt lucid SRU has been baking for some time now..   I guessed that perhaps the AA's were uneasy, or had questions about it.
<RoAkSoAx> mterry: upstream is. I mean it is not a license change per se but typo on the header. That file used to be in heartbeat afaik (before the split).
<Daviey> slangasek: to -proposed, currently in Unapproved
<mterry> RoAkSoAx, but do they know what license it should be?
<slangasek> Daviey: that's a separate question from AA duty
<Daviey> slangasek: I thought these days it was largely one and the same.
<slangasek> Daviey: the SRU team decides on SRU acceptance, that's not at all the same as archive admin
<RoAkSoAx> mterry: yes, it is GPL 2.1+, when should be LGPL 2.1+, but upstream doesn't feel confortable doing the change given that the code wasn't written by them
<mterry> RoAkSoAx, !?  That doesn't make any sense, but OK.  As long as we note that in debian/copyright
<slangasek> Daviey: some of us are on both teams, but SRU accepts are definitely not part of the regularly scheduled AA duties
<RoAkSoAx> mterry: it is this file: lib/plugins/lrm/raexecstonith.c
<RoAkSoAx> mterry: and it has the same error as other files. It says it is GPL2.1+ when should say LGPL2.1+
<RoAkSoAx> and as I said, upstream is aware but he said "i don"
<Daviey> slangasek: Oh aye... based on what i've been seeing, the divide has become murky.
<RoAkSoAx> and as I said, upstream is aware but he said "i didn't write that file so I don't feel confortable doing the license change"
<RoAkSoAx> anyway, bbl
<slangasek> Daviey: ehm, there's really no reason that should be the case.  Only a minority of the AAs are on the SRU team, and other members of the archive team aren't *authorized* to make decisions about accepting packages into -proposed...
<slangasek> anyway, looking at libvirt now with my ubuntu-sru hat on ;)
<Daviey> \o/
<Daviey> slangasek: you rock :)
<slangasek> Daviey: yeesh, someone take the parentheses gun away from that upstream
<slangasek> Daviey: accepted
<Daviey> slangasek: heh, great - thanks!
<kees> slangasek: can I borrow you for upstart debugging for a moment? does a "task" go through "starting" like for "services" ?
<kees> slangasek: and how I can get a dump of the emitted events during startup?
<slangasek> kees: yes, there's a 'starting' phase, whether it's a task or a service
<slangasek> kees: dump of the emitted events - boot with --verbose, grab the log and postprocess
<kees> slangasek: really? because nothing seems to be triggering my job
<kees> okay, will try
<kees> wait, boot with "verbose" not --verbose? kernel cmdline?
<slangasek> no, --verbose
<slangasek> on the kernel commandline
<slangasek> what's the job look like?
<kees> /etc/init/networking.conf (the task) and /etc/init/network-interface-security.conf (the prereq)
<kees> the latter isn't actually running :(
<kees> (testing for apparmor in lucid -proposed uncovered this existing race)
<slangasek> odd
<kees> yeah, building log...
<kees> which log does it spew to?
<slangasek> /var/log/syslog, IIRC
<kees> oh yes
<kees> slangasek: utterly no mentio of /etc/init/network-interface-security.conf
<kees> :(
<slangasek> kees: but you do see 'network-interface' or 'networking' or something in there?
<kees> slangasek: yeah, I watch both network-manager and networking make their way through their entire lifecycles
<bigon> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/665768 do you have a list of these pkg?
<ubottu> Ubuntu bug 665768 in gdk-pixbuf (Ubuntu) "libgdk_pixbuf-2.0.la missing from packages" [Undecided,Confirmed]
<kees> and n-i-s is shown as "start/running" O_o
<kees> slangasek: wait, I liked. I think I was accidentally searching for networkING-inter...
<kees> one moment...
<kees> slangasek: I'm totally baffled. http://paste.ubuntu.com/543279/ is upstart just not logging events in early boot?
<kees> slangasek: it seems like jobs aren't waiting for pre-start stanzas to finish before unblocking.
<kees> slangasek: i.e. n-i-s runs when I expect it to, but the jobs it has listed aren't waiting for its pre-start to finish
<slangasek> kees: IIRC, upstart is supposed to have a ring buffer internally for logging, which it dumps once syslog comes up; that, or Keybuk and I *talked* about having such a thing and it never got implemented, not sure
<kees> slangasek: looks like it was never implemented :(
<slangasek> kees: since I don't see any jobs on my system that trigger a dump on rsyslog start, yeah, I guess so
<kees> slangasek: if jobB starts on starting jobA, and jobB has a pre-start script, isn't jobA supposed to wait until jobB's pre-start has finished before jobA can move to its own pre-start?
<slangasek> er, I'm not sure
<kees> this design was predicated on that, based on what Keybuk told me. :(
<slangasek> I'd have to check the code; it might be jobB prestart, jobA prestart, job A script, job B script
<kees> Oh! nevermind. I think I see the problem.
<Keybuk> This is one of the many things that scares me about systemd
<Keybuk> http://cgit.freedesktop.org/systemd/tree/src/modules-load.c
<kees> I have    start jobX on (starting job1 or starting job2 or starting job3).  job1 -> starting, jobX -> starting, job2 -> starting & runs. jobX -> finishes, job1 -> finishes
<kees> Keybuk: just the person I was looking for!
<Keybuk> kees: hah
<Keybuk> I felt a disturbance in the force
<kees> Keybuk: heh. I'm trying to debug a race. it's /etc/init/network-interface-security.conf
<kees> Keybuk: it seems like if any 1 of those 3 jobs it waits for start, it will start, but if it takes a while, the other two might start and get to running before n-i-s finishes.
<Keybuk> yeah
<Keybuk> only the first of the jobs in the "or" to start gets held up
<kees> what are my options for making them all wait for it to finish?
<Keybuk> huh, doesn't look like there's a bug for that one
<Keybuk> don't use starting, instead use started network-interface-security in the named jobs?
<Keybuk> https://bugs.launchpad.net/upstart/+bug/568860
<Keybuk> ah there it is
<ubottu> Ubuntu bug 568860 in upstart "init: "before" functionality should block all services mentioned, not just the first" [Wishlist,Triaged]
<Keybuk> I knew it was filed somewhere
<kees> Keybuk: so I need to modify each of the jobs I want to block?
<Keybuk> yes :-/
<kees> and they will trigger the spawning?
<Keybuk> "the spawning" ?
<kees> ah, nevermind. n-i-s would just become "start on virtual-filesystems"
<Keybuk> is n-i-s indemponent and atomic?
<Keybuk> ie. could you cope with it being run *again* if the second event happened?
<kees> it can, but it's a waste of time
<Keybuk> because in that case you could stick instance $JOB in
<Keybuk> you'd get a copy for each of the start on clauses
<kees> I just want the one.
<Keybuk> yeah
<Keybuk> just thinking of solutions for you for the time being
<slangasek> kees, Keybuk: or since network-interface-security is idempotent, you could 'instance' it?
<Keybuk> slangasek: ah, we appear to have reached the middle of this conversation
<slangasek> ah
<Keybuk> I just suggested that
 * slangasek whistles
<kees> how does instances help this, exactly?
<Keybuk> but I feel really quiet warm, comfortable and fluffy knowing that a signficant portion of my brain has been backed up into yours
<slangasek> kees: you get a separate n-i-s job for each of the triggering jobs
<Keybuk> just be caseful, I may need my katra back one day
<slangasek> heh
<Keybuk> caseful? careful!
<kees> slangasek: hm. that's the least intrusive change, but it's a small waste of time.
<Keybuk> waste of time > bad security
<kees> could skip later runs by examining something in /var/run ...
<Keybuk> yeah
<ebroder> kees: By the way, I think Upstart's output from before rsyslog is up will go to /var/log/boot.log
<Keybuk> kees: but this bug is definitely being fixed
<Keybuk> the trouble is it isn't a bug so much as a missing feature
<Keybuk> start on .. or .. was never designed to block both :p
 * kees nods
<kees> this race only happens rarely, but I still want to fix it.
<kees> so... just add the line "instance $JOB" ?
<slangasek> not quite
<slangasek> because network-interface itself can have multiple instances
<Keybuk> that has $INTERFACE right?
<Keybuk> you could do instance $JOB$INTERFACE
<Keybuk> :p
<slangasek> right
<slangasek> I was just looking up the variable :)
<ebroder> Will instance $JOB/$INTERFACE work? Because that looks slightly less dumb
<Keybuk> if you prefer
<Keybuk> it's just an arbitrary string
<kees> but it's only to use $INTERFACE when some jobs don't use it? (i.e. network-manager.conf)
<Keybuk> it's "" if not
<geser> cjwatson: can you please also add "lapack" to Sylvestre Ledru's (sylvestre) PPU (see his recent mail to devel-permission).
<kees> ebroder: ah-ha! yes, it is in boot.log. that'll make this easier to debug. :)
<ebroder> kees: Though I think there might be a race between when plymouth dumps its log and when rsyslog starts, so there might be a window where you don't get logs
<kees> init: Failed to obtain network-interface-security instance: Unknown parameter: INTERFACE
<kees> Keybuk, slangasek: adding "instance $JOB/$INTERFACE" failed as above, and reducing it to "instance $JOB" had no change in behavior.
<kees> I take it back, it does work, just not with the "network-interface" job due to the lack of $INTERFACE
<kees> is there some way to access it?
<kees> Keybuk: so, how do I access $INTERFACE? it seems like it's isolated to inside the job, and I can't see it from $JOB.
<Keybuk> kees: ?
<Keybuk> oh, unknown parameter
<Keybuk> what's that shell thing
<Keybuk> instance ${JOB:}${INTERFACE:}
<Keybuk> or something
<Keybuk> use other value if unset
<Keybuk> ${JOB:-}${INTERFACE:-}
<Keybuk> that one
 * kees tries it
<kees> Keybuk: it still doesn't see it.
<kees> init: network-interface-security (network-interface/) goal changed from stop to start
<Keybuk> right
<Keybuk> hmm
<Keybuk> what was the event again?
<kees> init: network-interface (eth0) state changed from waiting to starting
<kees> I need $JOB_WITH_INSTANCE
<Keybuk> no, no
<kees> ?
<Keybuk> you're starting on what terms?
<Keybuk> can you paste the start on line
<Keybuk> oh
<Keybuk> wait
<Keybuk> it's not using net-device-added is it?
<kees> start on (starting network-interface
<kees>           or starting network-manager
<kees>           or starting networking)
<kees> nope
<Keybuk> yeah
<Keybuk> d'oh
<Keybuk> ok
<Keybuk> you need to change /etc/init/network-interface.conf
<Keybuk> add
<Keybuk> export INSTANCE
<kees> ah-ha
<Keybuk> sorry, had it in my head that your job worked directly off net-device-added
<Keybuk> so yeah, network-interface needs to export the INSTANCE thingy
<Keybuk> which really begs the question why export isn't the default
<Keybuk> that might be useful, or something
<Keybuk> (I know why it isn't, but meh)
 * kees tries again
<kees> \o/
<kees> init: network-interface-security (network-interface/eth0) state changed from waiting to starting
<Keybuk> ok, now try starting something like network manager
<Keybuk> you should see
<Keybuk> (network-manager/)
<kees> Dec 13 22:02:01 sec-lucid-amd64 init: network-interface-security (network-manager/) goal changed from stop to start
<kees> yup
<Keybuk> sweet
<kees> excellent!
<kees> Keybuk, slangasek: thank you! :)
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<RoAkSoAx> kirkland: just made an upload for TestDrive. Apparently just needed a rebuild for python 2.7. Please give a try if you can and let me know!
<kirkland> RoAkSoAx: cool, will do
<SpamapS> anyone know why lp:ubuntu/sysvinit is so far behind the actual package?
<micahg> SpamapS: http://package-import.ubuntu.com/status/sysvinit.html#2010-06-16%2012:21:03.212483
<SpamapS> micahg: weird, who can resolve this?
<micahg> SpamapS: you can file a bug against the udd project I think (lp.net/udd)
<SpamapS> micahg: thanks, bug 513277 seems to be an older one. ;)
<ubottu> Launchpad bug 513277 in Ubuntu Distributed Development "bzrlib.errors.DivergedBranches: These branches have diverged when importing" [High,Triaged] https://launchpad.net/bugs/513277
<hallyn_> anyone deal a lot with debirf?
<hallyn_> i'm curious about the fact that it uses debootstrap, which must be run as root, but complains when run as root...
#ubuntu-devel 2010-12-14
<geser> cjwatson: as you seem to be pretty knowledgeable about package sets: do you know or have an idea why the "xubuntu" package set isn't included in the packagesets collection of the LP API?
<cody-somerville> geser, I don't think one exists.
<geser> it can be queried with edit-acl.py
<netadmin> hi
<netadmin> j #ubuntu-network
<netadmin> ah sorry, i'm typo /
<ScottK> Riddell: https://launchpad.net/ubuntu/natty/powerpc/libpackagekit-qt14/0.6.10-1 landed in Universe by mistake which is why kpackagekit won't build on powerpc.  Would you please promote it.
<handmaster> hello. i made a client and a server. i have a break point in my server code, but how do i run my client?  my client is in bin/debug but double click on it does nothing.
<handmaster> system monitor also does not show it even starting
<dholbach> good morning!
<Simira> morning Daniel
<ebroder> Morning, dholbach
<dholbach> hey Simira, hey ebroder
<dholbach> Simira, long time no see - how are you doing?
<dholbach> RoAkSoAx, congratulations!
<pitti> Good morning
<\sh> good morning pitti
<RoAkSoAx> dholbach thank ypou!!
<dholbach> :-)
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, for bug 690040 you are looking for returning CUPS back to init scripts? For me such a step looks like that Upstart is a completely broken concept.
<ubottu> Launchpad bug 690040 in cups (Ubuntu Natty) "no longer confined by AppArmor" [Undecided,Triaged] https://launchpad.net/bugs/690040
<tkamppeter> pitti, is there no possibility to get the sequence: start apparmor -> start cups -> wait for cups being ready -> start samba with upstart?
<pitti> tkamppeter: it would make things a bit easier (share package/script with Debian again, avoid apparmor race condition)
<pitti> tkamppeter: as I wrote in the bug, it'd be even better if apparmor could move to an upstart script
<pitti> although, hmm
<pitti> but yes, I think there's some trick how to do state based conditions, with environment variables
<tkamppeter> pitti, I think this would really better, when using Upstart, everything should get moved to Upstart.
<pitti> so, would require some tinkering, but with an apparmor upstart script it'd work better
<pitti> tkamppeter: we just need to drop thaht silly "restart samba" bit from cups' job, and update the samba upstart job to wait on cups if cups is available
<tkamppeter> The CUPS/Samba problem looks for me like that Samba already starts when the CUPS daemon is not yet ready.
<pitti> I don't know how to do this currently, but we have some experts here :)
<pitti> my other worry is that cups now starts a lot earlier
<pitti> (but it doesn't need to really)
<pitti> in terms of boot speed, and keeping the CPU free for the really urgent things
<tkamppeter> pitti, if all startup dependencies are well defined, there should be no daemon starting too early or too late.
<maco> pitti: would it be possible to make the apparmor start script emit an event?
<tkamppeter> pitti, if you want CUPS to start after the gdm is up, make a dependency between CUPS and gdm.
<maco> if making it fully upstartified is too much work...
<pitti> maco: ah, "initctl emit"?
<hyperair> what's wrong with blocking on "started samba"?
<pitti> maco: yes, but event based waiting conditions don't work with optional components
<maco> pitti: uhh...if that's the command keybuk put in his blog post the other day, then sure ;-)
<hyperair> ahh
<maco> oh
<pitti> maco: as you can uninstall, or separately upgrade apparmor
<pitti> hyperair: samba isn't installed by default, and optional
<hyperair> pitti: yeah, i just realized.
<pitti> hyperair: or actually the other way around
<pitti> samba "start on started cups" doesn't work if you uninstall cups
<pitti> or you upgrade the samba package
<hyperair> right.
<tkamppeter> pitti, one should add a feature to Upstart, like "wait for XXX if XXX is available".
<pitti> tkamppeter: that's called "weak dependency", like the "Should-Start:" in the LSB init.d headers, FYI
<pitti> tkamppeter: but it's hard to express in terms of events, I think
<hyperair> pitti: how about.. start on local-filesystems or (local-filesystems and cups)
<hyperair> pitti: and then add a pre-start hook to check if cups exists.
<hyperair> pitti: would that work?
<pitti> a || (a and b) -> that's just "a"?
<pitti> hyperair: pre-start hook could work, yes
<hyperair> pitti: er i was hoping it could end up starting twice, where the first time fails the check, and the second time starts it for real?
<pitti> hyperair: bit expensive to write, though (as you need to poll for a process)
<hyperair> pitti: make use of a rather large sleep?
<pitti> hyperair: I don't know how upstart implements that
<pitti> hyperair: that'd feel cheesy
<hyperair> pitti: i know, but we have a lot of long sleeps in the bootchart and ureadahead scripts.
<pitti> hyperair: my truly preferred option would be to add socket activation to upstart :)
<hyperair> pitti: which feel cheesy as well. perhaps it's time to give upstart more power
<hyperair> pitti: er socket activation? like xinetd?
<pitti> like systemd
<hyperair> hmm i haven't actually looked into systemd before
<pitti> mdz: argh, the merge proposals are back at the TB moderation queue
<diwic> doko_ or barry, since you wrote I should ping you with a python 2.7 error, we have bug #688535 which makes it impossible to report (some?) bugs with apport
<ubottu> Launchpad bug 688535 in apport (Ubuntu) "apport-gtk crashed with ValueError in format()" [Medium,Confirmed] https://launchpad.net/bugs/688535
<diwic> doko_ or barry, seems like locale.format does not accept the same type of format strings anymore
<hyperair> pitti: i have a solution for the cups/samba issue.
<tkamppeter> hyperair, great. Please tell us.
<hyperair> tkamppeter: in cups.conf, put: start on (starting NEED_CUPS=1 or ..... )
<hyperair> tkamppeter: and in smbd.conf, put env NEED_CUPS=1\nexport NEED_CUPS
<tkamppeter> hyperair, and what happens if samba is not installed.
<pitti> hyperair: interesting
<hyperair> tkamppeter: it's an "or" condition. cups will get started anyway.
<hyperair> tkamppeter: just that order doesn't matter so much now.
<hyperair> pitti: i got it from here: http://www.netsplit.com/2010/12/03/event-matching-in-upstart/
<hyperair> i never knew you could put starting without any service name
<tkamppeter> hyperair, but there are the following problems:
<hyperair> tkamppeter: ?
<tkamppeter> hyperair, 1. If Samba triggers the start of CUPS via setting NEED_CUPS, CUPS starts, regardless whether the requirements of CUPS, especially a running AppArmor and the loopback device lo are present.
<hyperair> tkamppeter: that sucks.
<hyperair> tkamppeter: if we put "and" would that help?
<tkamppeter> hyperair, 2. If Samba triggers the start of CUPS it must still wait until the CUPS daemon is listening. Usually the daemon take a second or so until being ready.
<tkamppeter> hyperair, if we put "and" and Samba is not installed, CUPS will never start.
<hyperair> tkamppeter: okay, maybe we need to poke scott. =p
<tkamppeter> hyperair, I think that would be the best.
<hyperair> yeah
 * hyperair thinks events and boolean operators don't really go well together =\
<tkamppeter> hyperair, he could also do fixes or add features on Upstart.
<hyperair> yeah
<Keybuk> what's the thing that's not screen that does unicode
<maco> tmux?
<Keybuk> that's the one I was thinking of, thanks
<ion> Iâm using it. Iâve been quite happy with it.
<maco> Keybuk: things i osmosis off of crimsun :P
<hyperair> tkamppeter: oh hey look Keybuk's here.
<maco> haha
<hyperair> =p
<maco> you're not gonna grab pitti too?
<hyperair> looks like you did that. =)
<maco> wait dangit.. if the english are all online, that means i really really really should go to bed
<hyperair> Keybuk: so anyway, there was an issue with cups and samba, where samba needs to start after cups, but still be able to start if cups isn't installed. how does one design upstart jobs for this?
<mok0> Hm, my sbuilder fails with "installing python2.7-minimal would break existing software"
<Keybuk> hyperair: the problem with that is that samba is done with Upstart
<Keybuk> whereas cups is done with sysvinit
<hyperair> Keybuk: no, cups has an upstart job.
<mok0> Don't understand why it wants to install python2.7-minimal...
<maco> mok0: natty?
<mok0> maco: yes
<Keybuk> hyperair: oh, it didn't used to have
<hyperair> Keybuk: yeah, but it does in maverick.
<maco> mok0: python minimal isnt part of a base install?
<hyperair> Keybuk: the current solution is to kill -HUP samba if cups is started after samba.
<mok0> maco: I'll look
<Keybuk> hyperair: the best fix for that is for cups to insert itself into samba's starting event
<maco> mok0: i thought there was an email about python being in a very umm fun... state for a while as the 2.7 transitin happens
<Keybuk> so when samba is started, it blocks until cups is running
<hyperair> Keybuk: i proposed that, but then cups would not start if samba doesn't exist.
<pitti> Keybuk: we had that, but that breaks upgrades of cups
<pitti> Keybuk: as cups then waits forever if samba is already running
<Keybuk> hmm
<Keybuk> so you have two jobs that both depend each other if the other is installed
<pitti> (or samba isn't installed at all)
<Keybuk> otherwise don't?
<pitti> Keybuk: not on each other, cups doesn't need samba
<mok0> maco: it has python-2.6-minimal
<mok0> maco: the package I want to build doesn't depend on python
<pitti> Keybuk: we basically have samba should-start: cups
<Keybuk> in samba.conf:
<Keybuk> pre-start exec start cups ?
<pitti> with an || true?
<hyperair> but cups depends on things.
<Keybuk> yeah
<Keybuk> hyperair: the start cups can be
<Keybuk> pre-start exec initctl emit need-cups
<Keybuk> where cups.conf has on need-cups
<Keybuk> if there's no cups.conf, need-cups will just finish straight away
<Keybuk> if there's a cups.conf, need-cups gets picked up and blocked by it
<hyperair> Keybuk: but what if samba isn't installed, and nothing emits needs-cups?
<pitti> Keybuk: so do we need the needs-cups var, or should "pre-start exec start cups" suffice?
<Keybuk> pitti: well, I was just looking at cups and samba
<Keybuk> and it looks like they start on the same condition anyway
<Keybuk> so pre-start exec start cups would work
<Keybuk> probably best option
<pitti> ah, that's much simpler indeed
<pitti> thans
<pitti> thanks, too
<cjwatson> geser: lapack done.  (I don't seem to be getting these devel-permissions mails; odd)
 * Keybuk makes sure this one is in the use cases for 2
<Keybuk> I think it should just work, but I'll make sure there's a test case for it
<cjwatson> geser: xubuntu in lp.packagesets> um, no idea, sorry
<tkamppeter> Keybuk, pitti, do we take into account that CUPS has some delay? It takes a second or so after being started until the CUPS daemon is actually listening.
<maco> mok0: but the 2.6 to 2.7 transition is going on now. dependies are probably broken somewhere in the chain
<Keybuk> tkamppeter: you can do that in cups.conf with a post-start script that waits for it
<cjwatson> ScottK: libpackagekit-qt14 promoted
<Keybuk> upstart doesn't consider a job running until the post-start finishes
<mok0> maco: I guess. But how do I get my sbuilder to work? :-(
<tkamppeter> Keybuk, then this is solved for CUPS.
<mok0> maco: the schroot has a kept-back update of python-minimal. Perhaps I can pin it
<cjwatson> pitti: socket activation is on the upstart plan for natty, FYI
<cjwatson> since you asked
<pitti> cjwatson: cool!
<Keybuk> cjwatson, pitti: lp:~scott/upstart/bridges
<Keybuk> where "on the plan" includes "took scott 2 hours one night to implement"
<cjwatson> well, yes :)
<Keybuk> though it obviously needs testing and a few bug fixes
<mvo> woah!
<mdz> pitti: yeah, I noticed that too (merge proposals in moderation)
<mdz> pitti: are you already talking to a Launchpad dev about it, or should I?
<pitti> mdz: I'm not even sure what changed again; I haven't contacted LP folks yet
<mdz> pitti: maybe nothing changed, and it was coincidence that the queue was empty (someone else cleared it out?)
<Keybuk> mdz: oh, while you're here
<Keybuk> you may notice some funny business going on with my LP account
<AnAnt> Hello, I am getting this build failure on natty: http://launchpadlibrarian.net/60640251/buildlog_ubuntu-natty-i386.drawtiming_0.7.1-2_FAILEDTOBUILD.txt.gz  , yet it builds fine in maverick. Note that both natty & maverick have the save version of graphicsmagick. Build fails during linking, any clues ? Could it be related to doko's email about "gcc in natty now passes --as-needed by default to the linker" ?
<mdz> Keybuk: are you in the office today? I thought I saw you walk by
<Keybuk> LOOK OVER THERE!  A THREE HEADED MONKEY!
<Keybuk> mdz: I am
<doko_> pitti: could you have a look at #688535 (what diwic reported before)
<AnAnt> doko_: ^
<doko_> AnAnt: g++ -I/usr/include/GraphicsMagick   -DYYDEBUG=1 -g -O2  -Wl,-Bsymbolic-functions -o drawtiming -lGraphicsMagick++ -lGraphicsMagick   main.o parser.o scanner.o timing.o
<doko_> move the objects before the libs
<AnAnt> ok
<AnAnt> doko_: is that a binutils-gold thing ?
<mok0> Bah, pinning doesn't work, the python transition just screws everything up
<mdz> pitti: I read http://raphaelhertzog.com/2010/11/15/save-disk-space-by-excluding-useless-files-with-dpkg/ and my first thought was "what about the bug reports we'll get when people break their systems this way?"
<mdz> maybe apport should check for that before filing a bug?
<mdz> Keybuk: what sort of funny business?
<pitti> mdz: right, that was one of the things I was working on with Raphael during my OEM cycle
<doko_> AnAnt: no, it is needed for the --as-needed default
<Keybuk> mdz: I've now got two launchpad accounts
<Keybuk> one with my canonical address and all the old bug subscriptions
<Keybuk> and a new one with my home address and team memberships
<pitti> mdz: we could, but if it's only used for filtering out /usr/share/doc/, things should still work
<pitti> doko_: on my list
<doko_> now that is intersting ...
<doko_> checking for corosync/cpg.h... yes
<doko_> Session terminated, killing shell...checking for cpg_initialize in -lcpg... make: *** [debian/stamp-autotools] Terminated
<doko_> Terminated
<doko_>  ...killed.
<doko_> Build killed with signal 15 after 150 minutes of inactivity
<pitti> doko_: ah, that worked in 2.6 still, apparently locale.format() got much stricter in 2.7
<mdz> Keybuk: declaring launchpad bankruptcy?
<mdz> I've thought about just getting myself unsubscribed from all bugs older than a certain date
<pitti> doko_: fixing
<Keybuk> mdz: well, with leaving
<Keybuk> I don't want the 142,000 bug subscriptions
<Keybuk> and blueprint subscriptions
<Keybuk> and things I added to the launchpad registry when was on the bzr team and still get mails about
<Keybuk> etc.
<mdz> Keybuk: sure, but is it really easier to set up a whole new account than to get that cruft removed?
<mdz> I'd rather not have to change LP accounts just to cut down on the amount of spam I receive
<Keybuk> mdz: apparently so
<Keybuk> we looked into the problem of just purging the data
<doko_> pitti: thanks ... preparing for a flood of bug reports
<Keybuk> and apparently it's so hard, nobody wants to contemplate
<Keybuk> e.g. you could purge all the bug associations
<Keybuk> but then the karma system would assert because you have more karma than you should have
<Keybuk> etc.
<Keybuk> whereas renaming accounts is an understood problem
<cjwatson> launchpadlib to go through and unsubscribe everything? :)
<cjwatson> (I realise it's too late)
<Keybuk> cjwatson: you can't unassign yourself from bugs that have been marked as dups of things
<Keybuk> not without un-dupping and re-dupping
<Keybuk> and that wouldn't take into account all the ownerships I had in LP
<maco> seriously?
<maco> that's a stupid limitation
<cjwatson> I thought that had been fixed ages ago ...
<cjwatson> I guess not
<mok0> dpkg: considering deconfiguration of python-minimal, which would be broken by installation of python2.7-minimal ...
<mok0> ?
<mok0> catch 22
<pitti> mok0: is this a normal dist-upgrade?
<pitti> it should upgrade python-minimal
<mok0> pitti: it's my schroot environment
<mok0> pitti: for natty
<pitti> mok0: I mean, did you see this during dist-upgrade?
<pitti> or what did you try?
<mok0> pitti, in my natty builder, I did apt-get upgrade
<pitti> right, upgrade won't suffice
<pitti> you need dist-upgrade
<mok0> pitti: and then apt-get install python2.7-minimal
<Keybuk> cjwatson: yeah, the whole stack of things that stacked on top of stacks got scary
<pitti> mok0: right, you can't install python2.7-minimal with python-minimal 2.6, that wreaks havoc; that's why we added the Breaks:
<pitti> mok0: do a dist-upgrade, or install python-minimal instead
<mok0> pitti: thx will try dist-upgrade
<pitti> mok0: please let me know if that works properly
<mok0> pitti, nope, same error
<mok0> pitti, http://pastebin.com/6q5fgvGb
<pitti> mvo: ^ any idea why apt just doesn't do that?
<pitti> if you upgrade p-minimal to 2.7, then the breaks: is solved
<pitti> mvo: instead of "Breaks: python-minimal (<< 2.7.1~)
<pitti> mvo: .. should we add "Depends: python-minimal (>= 2.7.1~)" instead?
<pitti> mvo: the thing that we need to avoid is to configure any python2.7* stuff with python-minimal 2.6 still installed
<mvo> pitti: hm, is that reproducable in a chroot? I can look after lunch
<pitti> mvo: I guess a maverick chroot (or a natty system with 2.6 installed) and dist-upgrading?
<mok0> mvo, what I have is a natty sbuilder
<mvo> pitti, mok0: thanks, let me check it
<Riddell> bryceh: bug 690122
<ubottu> Launchpad bug 690122 in libxkbcommon (Ubuntu) "no-shlibs-control-file" [Undecided,New] https://launchpad.net/bugs/690122
<mvo> pitti: hm, I don't think the depends will work either (instead of the break) - that needs a closer look. why do we want to avoid 2.7* stuff with 2.6 minimal? (I will read scrollback, gtg for lunch now)
<pitti> mvo: python2.7 mustn't call the 2.6 version of pycompile from the python-minimal package
<pitti> mvo: (in its postinst)
<pitti> mvo: why wouldn't a depends: work? because it's circular?
<pitti> mvo: (that's why I suggested using breaks: to the older version)
<mdz> cjwatson: you're chairing TB today, right?
<cjwatson> mdz: yes
<mdz> cjwatson: ok, thanks
<doko> kenvandine: libdesktop-agnostic is another gir-repository issue. could you have a look?
<ScottK> cjwatson: Thanks (libpackagekit-qt14) - kpackagekit built on powerpc now, so one more FTBFS down.
<pitti> cjwatson: *phew*, I'm finally done with bug 415038, FYI; all fixed up now
<ubottu> Launchpad bug 415038 in debconf (Ubuntu) "port GNOME frontend to GtkAssistant" [Medium,Triaged] https://launchpad.net/bugs/415038
<cjwatson> ok, thanks, will have a look once I'm finished with current task
<Riddell> kirkland: is jplayer useful as a local package?
<sabdfl> hi folks, hotel network isn't allowing connections to port 587, or normal smtp, of smtp.canonical.com
<sabdfl> any suggestions?
<sabdfl> blech, wrong window!
<cdbs> :)
<cdbs> *:(
<kenvandine> doko, i can look at that
<smoser`> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smoser`
 * dholbach hugs smoser
<Simira> dholbach: I was right off to work this morning. How are you? We just filled up the house with another dog!
<dholbach> Simira, oh wow! what kind?
<Simira> dholbach: Rhodesian Ridgeback :D
<dholbach> Simira, just this second I was about to take my dog out for a walk and get lunch
<dholbach> Simira, wow - that's a bit bigger than your other dog, right? :)
<Simira> http://www.simira.net/gallery/Hund/2010-11-24-Bergen-Hemsedal-div/slides/P1000883.html
<Simira> slightly
<Simira> 6 months and 35 kg now
<dholbach> wow :)
<Simira> dholbach: have a nice lunch! Make sure your dog gets his part!
<dholbach> Simira, the dog will make sure - no problems :-P
<dholbach> see you :)
<doko> is Bilal Akhtar here in the channel?
<cjwatson> doko: meet cdbs
<mvo> pitti: hey, soory for the delay. the depends is circular, dpkg/apt do not like that for essential packages
<mvo> pitti: I look at it again to see what can be done
<doko> cdbs: ping
<cdbs> doko: yes?
<cdbs> I got your mail, but the other way to link the library wasn't working
<cdbs> I tried many many times, including the way you mentioned in your mail to ubuntu-devel last month
<jdstrand> pitti: haven't read all the backscroll, but the cups thing is known (as of a couple weeks). you just need to start it like mysql, with something like this in the upstart job file: http://paste.ubuntu.com/543589/
<doko> cdbs: then please just file a bug.
<doko> cdbs: are there other uploads like this one?
<cdbs> doko: looking at your uploads, I don't see any such of them
<cdbs> doko: the problem is, the package links agianst a library it itself builds
<cdbs> and adding  --no-as-needed -lcourier-authlib doesn't seem to work --as-needed
<doko> cdbs: right, then the build system has to be fixed
<doko> I'll look at it
<cdbs> doko: thanks, I 'll re-open bug
<cdbs> oh, you already did that
<pitti> mvo: how do you mean?
<pitti> mvo: we currently have p-minimal depends: p27-minimal, and p27-minimal breaks: p-minimal (< 2.7)
<pitti> mvo: and apparently that causes apt to hold back both, instead of upgrading both
<pitti> jdstrand: right, i've seen it in avahi
<pitti> jdstrand: but I really don't like it
<jdstrand> I see that now after having read the bug
<kirkland> Riddell: it's something that web applications could depend on and use
<kirkland> Riddell: currently, there is a snapshot of jplayer embedded in the 'musica' application
<kirkland> Riddell: but it would be better if 'musica' just depended on jplayer
<jdstrand> pitti: it might be enough to test for /sys/kernel/security/apparmor/profiles, but a) we want to double check that with jj-afk and b) that is going to have to be updated once we lose the compatibility patch
<kirkland> Riddell: other web apps could use it too
<jdstrand> pitti: (that is instead of 'aa-status')
<seb128> cjwatson, hey, could the desktop set get access to vte?
<pitti> jdstrand: I actually meant calling apparmor_parser to force-start it
<jdstrand> apparmor_parser is an ELF
<kirkland> Riddell: or you could make your own homepage or blog or whatever and just 'apt-get install jplayer' and then embed music there
<pitti> jdstrand: IMHO cups should just wait on apparmor to start
<kirkland> Riddell: it's very HTML5-y ;-)
<pitti> instead of a lot of programs having to manually call apparmor bits
<jdstrand> pitti: right. we've talked about an apparmor upstart script, but it is fraught with peril. kees is way more up on it than I though, so he can get into that more
<pitti> jdstrand: so, it's obviously the right solution for a maverick update
<jdstrand> pitti: we've also considered an apparmor helper doodad that upstart could use (that would ship with upstart) that would do this as well. that hasn't happened yet
<Riddell> kirkland: ok, accepted
<jdstrand> pitti: but yes, the current situation is not ideal and not the long term plan, but it does work
<kirkland> Riddell: cheers, thanks
<kirkland> Riddell: hey, question for you ...
<kirkland> Riddell: did I handle the debian/copyright file correctly?
<kirkland> Riddell: the project says that it's dual licensed, MIT/GPL
<kirkland> Riddell: in that case, as distributor, do we just pick one?  or do we put both licenses there, and let the end user pick one?
<Riddell> kirkland: we don't tend to pick one, we tend to put both into the copyright file
<doko> pitti, mvo: while you discuss this, please could you accept the python-defaults for -proposed?
<kirkland> Riddell: ah, okay, i'll upload again adding the MIT license too
<kirkland> Riddell: thanks
<Riddell> kirkland: famfamfam-silk likewise needs a copyright change, ping me when you reupload it if you want a quick review
<cjwatson> seb128: done
<seb128> cjwatson, thanks
<kirkland> Riddell: i'm adding that now
<kirkland> Riddell: the license is in full in the file LICENSE in the root directory of the orig.tarball
<kirkland> Riddell: that's the only reason i didn't embed it in debian/copyright
<kirkland> Riddell: but i'm copying it there now
<jdstrand> didrocks: I'm confused by your response to bug #690011
<ubottu> Launchpad bug 690011 in compiz (Ubuntu) "unity panel and launcher do not start with latest update" [Undecided,Incomplete] https://launchpad.net/bugs/690011
<jdstrand> didrocks: you implied that I either did something wrong or didn't do something that I had no idea I would need to do (and surely other people wouldn't either)
<seb128> didrocks, is everybody supposed to run unity --reset?
<didrocks> jdstrand: unity --reset and ensure to have latest compiz
<didrocks> seb128: I think it will impact everybody yes
<seb128> didrocks, shouldn't add a session snippet doing that?
<seb128> shouldn't we add...
<jdstrand> didrocks: I understand that part. I don't understand why I need to do that or why that wasn't done for me or why I should know about it :)
<seb128> it seems suboptimal to break everybody's session and tell them to run --reset
<didrocks> seb128: that will be nice, but I didn't have the time to come with that solution, we don't have a script starting, right?
<didrocks> seb128: right, but as long as upstream doesn't support migration path, and there was a rename this time
<seb128> well we could add an autostart desktop in /usr/share/autostart
<seb128> just for one day or two
<jdstrand> I'll let seb128 take it from here...
<didrocks> jdstrand: it's just upstream didn't rename every gconf path
<didrocks> jdstrand: and they fix one after another
<didrocks> (compiz upstream)
<seb128> didrocks, what is gnome-session starting? compiz?
<seb128> didrocks, is there any wayt to have the unity --reset in the session for a day?
<jdstrand> 'Sorry, Compiz closed unexpectedly'
<didrocks> seb128: can add that
<seb128> jdstrand, that seems a crash, see if apport cna report it
<jdstrand> oh, it is definitely a crash. I have no window manager :)
<seb128> didrocks, that would be nice, that would avoid having to deal with people on IRC, bug reports, and to confuse users
<didrocks> seb128: I can do taht now
<seb128> didrocks, thanks
<didrocks> seb128: hum
<seb128> didrocks, you rock ;-)
<jdstrand> I can't click the button-- my irc is in the foreground
<didrocks> seb128: no, I need to put that in a script
<seb128> jdstrand, yeah, go to a vt and DISPLAY=:0 compiz
<seb128> then compiz --replace in your session
<seb128> so it uses the right profile
<didrocks> seb128: hum, we should be clever enough for that and let it until alpha2
<seb128> I've workarounded those issues by adding a desktop launcher to start compiz
<kirkland> Riddell: done; famfamfam-silk uploaded
<didrocks> seb128: let's see if I can come up with something
<seb128> so when it crashes I can double click on it :p
<seb128> didrocks, then you need to set a gconf key I guess
<didrocks> seb128: no, just check for the old one :)
<seb128> didrocks, that would work ;-)
<didrocks> seb128: let's see, 5 minutes :)
<didrocks> seb128: you still have an old config, right?
<seb128> yes
<didrocks> (in a word, would you put your config in danger for the sake of it? :))
<seb128> I didn't upgrade today yet
<seb128> sure ;-)
<jdstrand> whee, apport crashed too
<didrocks> seb128: excellent, thanks \o/
<seb128> jdstrand, welcome to natty :p
<jdstrand> hehe
<pitti> jdstrand: I fixed apport a few hours ago
<jdstrand> of course, I've been here awhile ;)
<seb128> jdstrand, the apport issue might be fixed already, pitti did a python2.7 upload
 * jdstrand nods
<pitti> but indeed, it's fun to see how all your applets and indicators crash differently every morning :)
<kenvandine> doko, looks like there are a number of issues with libdesktop-agnostic, which might all be fixed in the upstream project, including some pretty big packaging changes
<kenvandine> doko, i am going to ping the upstream guys to see if they are ready for a release
<kenvandine> or if i should just grab a snapshot
<doko> kenvandine: is an upstream release expected in the natty time frame?
<kenvandine> i am going to find out
<kenvandine> i don't know any of them
<jdstrand> didrocks, seb128: thanks! I seem to have a desktop again now :)
<seb128> jdstrand, great ;-)
<didrocks> seb128: jdstrand nice :)
<Riddell> siretart: what's the status of bug 581805 ?
<ubottu> Launchpad bug 581805 in srtp (Ubuntu) "libsrp1-dev srtp-utils srtp-docs missing from lucid" [Medium,Triaged] https://launchpad.net/bugs/581805
<kirkland> Riddell: thanks
<dholbach> smoser, for example if we wait for upstream input before uploading we could say "Please subscribe sponsors once you had feedback", and/or subscribe ourselves to the bug
<smoser> dholbach, yeah, but then it sits in that state.
<smoser> right ?
<smoser> an example (with your comments) is at https://code.launchpad.net/~dmitrij.ledkov/ubuntu/natty/htmldoc/fix-ftbfs/+merge/43393
<dholbach> smoser, I think it's fair to say "I looked at it, it's good AFAICS, tested it, but I defer judgement to upstream"
<dholbach> if we can't find anyone of us to make that judgement, we shouldn't all be looking at the patch all over again
<dholbach> ^ are there other opinions on it?
<smoser> on that one in particular, we should fix the ftbs right away and open a bug to track the upstream, right ?
<dholbach> I just had a look at the changelog - it doesn't seem like any of the ubuntu developers touched it before
<dholbach> I think dmitrij opened an upstream bug already
<dholbach> hang on
<dholbach> http://www.htmldoc.org/str.php?L235
<dholbach> smoser, personally I think it's alright as a temporary measure to just fix the ftbfs and compile without optimisation for now as long as the upstream bug gets tended to
<mdeslaur> pitti: could I get your opinion on bug 614717, please?
<ubottu> Launchpad bug 614717 in udisks (Ubuntu) "Security risk in mounting hard disks" [Medium,Confirmed] https://launchpad.net/bugs/614717
<siretart> Riddell: what about it? 6 months I've asked how to proceed.
<siretart> +ago
<cjwatson> mdz: is sabdfl unable to attend as well as unable to chair?
<cjwatson> mdz,Keybuk,pitti,kees: TB meeting in three minutes
<cjwatson> (by my calendar anyway)
<pitti> mdeslaur: commented in the bug
<pitti> mdeslaur: well, it was me who introduced the change in the first place..
<pitti> cjwatson: thanks; I'm in
<mdeslaur> thanks pitti
<pitti> mdeslaur: followed up agin
<mdz> cjwatson: correct
<mdeslaur> pitti: ah! it's only for the admin user?
<pitti> mdeslaur: yes
<mdeslaur> pitti: ah, perfect. WONTFIX
<pitti> mdeslaur: and we don't install p-desktop-privs on servers either
<mdeslaur> thanks pitti
<siretart> Riddell: oh, that's not what I've written, I see. sorry for the confusion
<pitti> mdeslaur: updated again
<mdeslaur> thanks pitti :)
<dholbach> smoser, was there another bug that should probably get off the list?
<smoser> i dont really know how something makes the list
<smoser> but, for instance, https://launchpad.net/bugs/613662
<ubottu> Ubuntu bug 613662 in eglibc (Ubuntu) "nscd doesn't cache host entries" [Undecided,New]
<dholbach> smoser, ah, ok - it get the list of bugs that 'ubuntu-sponsors' is subscribed too and the ubuntu merge proposals that have their status set as "needs review"
<smoser> we either need to decide to carry that patch , or say "no".  given RHEL and Suse carrying it, i'd be apt to carry.
<siretart> Riddell: I was clearly confused. anyway, uploaded.
<smoser> but I don't feel informed enough to make a decision.
<dholbach> that's something I personally can't make a judgement on, but somebody like doko can probably help (#613662)
<dholbach> smoser, I'd even feel less informed than you :-)
<doko> smoser: do you volunteer to maintain the networking stack in eglibc?
<doko> robbiew: ^^^
<smoser> doko, i can do that in my sleep :)
<smoser> or wait,
<smoser> maybe that is why i said i don't feel informed enough to make a decision
<dholbach> doko, AFAICS smoser was asking for advice, not saying "I'll go and upload it now" :)
<doko> smoser: I'm fine to apply such a patch if you want to maintain it
<robbiew> so we don't really have a "networking stack" person in either Foundations or Server....with that said, networking is a core, foundational component
<smoser> doko, yeah, i would think you're capable of making a decision, but in order to get it off the list, we have to make said decision.
<robbiew> doko: maybe it's something barry could maintain :P
<robbiew> he used to work in Launchpad...they run on the network, right...heh
<barry>  robbiew: ? :)
<smoser> i'm not trying to make trouble. i promise.
<doko> but you do ;P
<robbiew> fwiw, I have an opening in foundations and I'm looking for networking skill...so we could just take it into foundations and  dump it on the poor sap....uh, I mean lucky person who gets the job :)
<barry> robbiew: we should see if any of the twisted guys need a job :)
<doko> smoser: ^^^ so best thing to delay that one
<robbiew> smoser: or apply it and temporarily "maintain" it until I fill my opening
<doko> smoser: apply in bzr, please don't upload
<smoser> launchpad wouldn't let me anyway
<cjwatson> robbiew: difficult to maintain just the networking part of eglibc (at the package level) without the rest of it too
<robbiew> cjwatson: ah...good point...and doko is clearly dancing around it ;)
<doko> robbiew, cjwatson: you know what I mean ...
<robbiew> I do
<robbiew> I do
<Simira_> dholbach: is it a sign we don't feed the puppy enough when he starts chewing on Odin?
<dholbach> Simira_, I guess not :-)
<Simira_> hm, why do I have that _
<jdstrand> kees: hey, so looking at your ifupdown change, I like how it is minimal, but it is not an obvious change to me. can you explain the 'instance' thing?
<hmca> hello , i'm having some problems upgrading my system to python 2.7 under ubuntu, it's a server.... http://pastebin.com/KVbjW8Bt
<kees> jdstrand: sure! basically, by defining an instance, a job is run multiple times for each of it's possible "or" conditions (among other things), with $JOB being set to the name of that condition.
<kees> jdstrand: in the case of network-interface.conf, it also adds its $INTERFACE to fully describe each of those instances.
<kees> jdstrand: it's a work-around, since we shouldn't have to run multiple times, but it works in that it blocks every case until it finishes. (and I added a stamp file so that later runs are as fast as possible)
<jdstrand> kees: thanks, between that and 'man 5 init', I understand now
<kees> okay, cool.
<jdstrand> kees: it isn't totally clear why network-interface-security.conf needs to be declared an instance too, but I guess that may be part of the nature of the bug
<kees> jdstrand: making it an instance-able job means the job is included in the dependency resolution for all of its conditions.
<kees> jdstrand: it results in a number of side-effects. ultimately, the "always run before the thing it waits for" is the critical bit.
<jdstrand> kees: ok. that seems to be an undocumented side-effect
<kees> sudo initctl list
<kees> network-interface-security (network-interface/br0) start/running
<kees> network-interface-security (network-manager) start/running
<kees> network-interface-security (network-interface/vnet0) start/running
<kees> network-interface-security (network-interface/eth0) start/running
<kees> etc
<kees> instead of just the 1
<jdstrand> (the dependency resolution bit)
<kees> yeah, which is why I tried to describe it in the n-i-s.conf job itself.
<jdstrand> yes, the comment is clear. the 'why' it works that way is not
<jdstrand> kees: ok cool, thanks
<bdrung> smoser: the debian changelog for bug #681012 is not verbose enough. please state the remaining changes
<ubottu> Launchpad bug 681012 in netbase (Ubuntu) "Sync netbase 4.44 from debian sid/Add mysql proxy port (6446) to /etc/services" [Undecided,Confirmed] https://launchpad.net/bugs/681012
<bdrung> smoser: and call it merge, not sync
<smoser> bdrung, ok. i didn't think i should recopy those, but i will.
<smoser> thanks for input.
<hmca> hello doko,  i'm having a problem doing an upgrade of python o my server , "ScottK> hmca: Ask doko on #ubuntu-devel about that."  , can u help me ?http://pastebin.com/KVbjW8Bt
<doko> pitti, mvo: any update? ^^^
<pitti> I'm afraid I don't know how else to tell apt to upgrade the packages in the right order
<mvo> doko: sorry, not yet, I got hold up
<doko> pitti: so I'll revert the Beaks in python2.7-minimal? please could you accept the sru?
<pitti> doko: well, *shrug*, it won't help these upgraders, and there are still tons of unresolved questions there
<bdrung> smoser: let me know once you have done that
<pitti> I just read the diff again, and it seemed plausible to me until you seemed to imply that the code I pointed out wasn't the fix
<smoser> what did you mean "call it merge" (in the bug subject)?
<doko> pitti: why do you object to that upload?
<pitti> doko: so if you don't want to backport the particular fix, and there's no real solution available, I'll accept it, but as it's still unclear what the fix is, and you don't want to explain either, I can't take responsibility for this
<doko> pitti: the fix for this issue is the version range change, the other changes
<doko> - test the return status of the py_compile processes
<doko> - properly byte-compile even if .pyc files are present
<pitti> doko: "did I say that?" sounded like "no" to me; so that _is_ the code fix theN?
<doko> - properly byte-compile .pyo files
<pitti> right (but that wasn't my question); what actually specifies the vrange option? is that the call of pycompile in package postinst?
<bdrung> smoser: yes, the title
<smoser> bdrung, branch change is pushed
<ari-tczew> could any archive admin accept NEW binaries of clementine?
<smoser> and title updated
<bdrung> smoser: uploaded
<ari-tczew> does any Canonical guy know where can I find dyfet (David Sugar)?
<dholbach> ari-tczew, https://launchpad.net/~dyfet lists a few mail addresses
<kees> is there a versioning convention to indicate "please just sync this in the future" once an ubuntuN has happened? i.e. if I have foo-1.2-3, it got a 1.2-3ubuntu1, and now the need for that changes has gone away, will something like 1.2-3ubuntu2build1 trigger a sync when 1.2-4 comes around?
<ScottK> kees: Nope.  You'll need to request the sync when the time comes.
<kees> ScottK: okay, fair enough. I guess I'll upload an ubuntu2 with the change reverted so it's clear it's okay to sync.
<ScottK> kees: When I've done this in the past I've explicitly said that in debian/changelog.
<kees> ScottK: perfect :)
<smoser> anyone able to sponsor a hardy backport ? https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/244233 is *very* straightforward and I believe the bug is in good state for sponsoring.
<ubottu> Ubuntu bug 244233 in mailman (Ubuntu Hardy) "Logrotate is noisy with: Re-opening all log files" [Undecided,New]
<ScottK> smoser: backport or update?
<smoser> update.. but, don't bother just yet, i have something else to look at on it.
<hallyn_> mvo: so to add a changelog entry in the packaging tree, is there a bzr command to do it?
<jdstrand> pitti: I just went through all the apparmor SRU bugs and verified the fixes. Some of the bugs listed in pending-sru.html either didn't affect lucid or we didn't fix it in this update
<jdstrand> pitti: for those bugs, I marked as 'verification-done' and closed the task appropriately
<jdstrand> pitti: and added a comment and verified it didn't regress
<jdstrand> pitti: I did that because to avoid confusion since pending-sru.html listed too many bugs
<jdstrand> pitti: would it be helpful if I changed the tag to 'verification-done' on the remainder of those bugs or shall I leave that for you?
<seb128> jdstrand, he left for today I think
<seb128> he will probably read the backlog though
<jdstrand> ah, so he did
<jdstrand> I guess I'll stop talking to myself then :)
<jdstrand> seb128: thanks
<seb128> those bugs where in the .changes uploaded?
<seb128> how come they are listed if they don't concern the version uploaded?
<jdstrand> seb128: was a full version update and I used -v
<jdstrand> seb128: it was a significant upload
<seb128> ok
<jdstrand> seb128: basically, we SRUd what is in maverick-updates into lucid-proposed, backing out certain patches (commented in the changelog)
<jdstrand> there were also a few maverick only ones that never hit lucid
<seb128> jdstrand, ok, I was rather curious, I think pitti knows the detail so no need to spend time going through that again ;-)
<seb128> I was just curious if there was a bug in the sru script that builds the page
<jdstrand> oh yes, he most certainly does :)
<jdstrand> no
<jdstrand> well, yes, but not worth fixing
<seb128> k, thanks ;-)
<bencc1> where can I ask questions about apt package dev?
<ebroder> ScottK: By the way, have you had a chance to look at my backportpackage script? I want to make sure it handles all of the cases you care about
<ScottK> ebroder: I have not.  I still have it on my TODO.
<ebroder> Cool
<hallyn_> kirkland: could you take a look at people.c.c:~serge/public_html/vmbuilder-460.tgz and consider sponsoring it, pretty please?
<mvo> hey hallyn_ - sorry for the delay, I was at dinner
<mvo> hallyn_: I use emacs and debian-changelogs-mode, when using dch I think you can use "CHANGELOG=changelog dch"
<hallyn_> mvo: hm, i'll try that nxt time, thanks.  (i just did it by hand)
<mvo> hallyn_: ok
<hallyn_> mvo: and so from there, you create the source package (bzr-buildpackage -S) and then dput that right?
<mvo> hallyn_: yeah, bzr-buildpackage -S (might need --merge, but that should not be needed as there is a .bzr-builddeb/defaults.conf)
<mvo> hallyn_: and it will provide the .changes file in ../build-area/
<mvo> hallyn_: if you are unsure I'm happy to have a look before oyu upload
<mvo> hallyn_: I always do a debdiff before uploading, just in case (old habit)
<hallyn_> mvo: thanks.  i just did a dpkg-source -x and looked at the result.  looks good
<mvo> hallyn_: excellent !
<bdrung> BlackZ: bug #690330 is a duplicate of bug #689025
<ubottu> Launchpad bug 690330 in sudo (Ubuntu) "Please merge sudo 1.7.4p4-5 (main) from debian unstable (main) (dup-of: 689025)" [Wishlist,In progress] https://launchpad.net/bugs/690330
<ubottu> Launchpad bug 689025 in sudo (Ubuntu) "Please merge sudo 1.7.4p4-5 (main) from Debian unstable (main)" [Undecided,Incomplete] https://launchpad.net/bugs/689025
<BlackZ> bdrung: well, when I checked for bug containing the "merge" title, I didn't find anything..
<BlackZ> bdrung: I assume the bug title has been changed or it was invalid or its status was "Fix released", "Invalid" or "Expired" ?
<bdrung> BlackZ: look at the mailing list - it was a user request for "syncing" the debian version
<bdrung> BlackZ: i fixed the title to be a proper merge request
<BlackZ> bdrung: ah, I seen now. I was planning to merge it (today I talked to jdstrand)
<BlackZ> bdrung: I will reply in the mailing list, then
<SpamapS> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: SpamapS, smoser`
<bdrung> BlackZ: can you please check the six patches for sudo if they should be applied, forwarded, or dropped?
<BlackZ> bdrung: *six patches* ?
<BlackZ> bdrung: seems like to me there are just 2 patches currently applied in the Ubuntu package
<bdrung> BlackZ: yes, look at https://bugs.launchpad.net/ubuntu/+source/sudo
<bdrung> BlackZ: six patches attached to bug reports
<BlackZ> bdrung: ah, I see what you mean
<BlackZ> bdrung: sure, will give a look at them
<smoser> @pilot out
<pasteeater> siretart: http://pastebin.com/x6LgnDBE
<pitti> jdstrand: please feel free to use v-done yourself; I thin I caught them all now
<pasteeater> siretart: related to LP #690296.
<ubottu> Launchpad bug 690296 in x264 (Ubuntu) "libx264 2:0.98.1653+git88b90d9-3ubuntu1 messes up bitrate when encoding (at least using mencoder)" [Undecided,New] https://launchpad.net/bugs/690296
<pasteeater> i think...
<jdstrand> pitti: ack, thanks!
<kirkland> hallyn_: hey
<kirkland> hallyn_: okay, vmbuilder ...
<hallyn_> kirkland: yeah?
<kirkland> hallyn_: i'm surprised you pointed me to a tarball, rather than a branch?
<kirkland> hallyn_: any particular reason?
<hallyn_> yes.  there is no 'branch'
<kirkland> hallyn_: interesting ....
<hallyn_> there is ap ackaging branch, and a source branch
<kirkland> hallyn_: ah, and they're separate?
<hallyn_> yup
<kirkland> hallyn_: interesting
<hallyn_> yup :)
<soren> It's an upstream project.
<hallyn_> not sure where in the sphere of UDD that fits in, but i'm sure it's somewhere
<kirkland> (that's not how i handle any of my projects, but meh)
<hallyn_> kirkland: we can change it if we want,
<hallyn_> kirkland: but i don't want ot make a rash decision until i've tried it
<kirkland> hallyn_: right, sure
<kirkland> hallyn_: i'm not particular, just curious
<hallyn_> frankly, this may actually be nicer for having one source tree for lots of releases
<hallyn_> but, it's awkward in having to send over tarballs :(
<ebroder> hallyn_: I thought you could bzr merge-upstream a branch
<kirkland> hallyn_: uploaded ;-)
<hallyn_> kirkland: thanks!
<hallyn_> ebroder: out of the packaing branch?
<hallyn_> packaging
<hallyn_> mind you, i don't have archive upload rights, so *i* couldn't
<kirkland> hallyn_: you can do the merge, but just push to a branch you own, in lp:~hallyn
<kirkland> hallyn_: and then point me at that, and i'd branch yours and sponsor/upload/push
<hallyn_> kirkland: ebroder: i'll try that for the next one, thanks.
<kirkland> hallyn_: sure
<kirkland> hallyn_: this one was easy enough
<kirkland> hallyn_: perhaps for one that involves a lot more changes, it's nice to peruse bzr log, etc.
<bdrung> ebroder: around?
<ebroder> bdrung: Yeah
<bdrung> ebroder: i like to improve u-d-t by adding test to it. there should be local test that will be run on building the package and internet requiring test that can be run from time to time manually (and before release)
<ebroder> bdrung: Makes sense. I was considering adding an option to backportpackage take a .dsc file as an argument instead of a source package name. I think that would let you write tests for it
<ebroder> *to take a .dsc file, obviously
<bdrung> ebroder: you made the wrong assumption. i would like to see tests for backportpackage ;)
<ebroder> bdrung: Like unit tests?
<bdrung> ebroder: yes (i didn't used unit tests before)
<ebroder> bdrung: I could probably write unit tests for some of it, but I don't think you can really do tests for, like, the launchpadlib stuff usefully
<ebroder> Even if I had an object that mocked the lp API, it would just be feeding back the information that the functions were programmed to expect.
<bdrung> ebroder: for the launchpadlib stuff we could write test that work on edge
<ebroder> bdrung: Sure, or staging, but that doesn't get us offline tests
<bdrung> ebroder: yes, but having online test is a gain - i would run the online test before uploading the package
<ebroder> bdrung: Sure. Do you have infrastructure for doing unit testing already?
<bdrung> ebroder: no and i don't know what kind of infrastructure is required
<bdrung> ebroder: the offline tests should be run on package build time and the online test should be run with calling one command
<ebroder> bdrung: Sure, I'm willing to setup infrastructure, but I'd prefer if it didn't block review of my branch
<ebroder> Feel free to open a bug and assign it to me, though I likely wouldn't have time to work on it until this weekend
<bdrung> ebroder: you can do it in a separate branch
<ebroder> bdrung: Sure, and I would
<bdrung> ebroder: your backportpackage branch is ready for merging?
<ebroder> bdrung: I'd like ScottK to make sure the interface does everything he needs, but other than that, I'm happy with it
<bdrung> ebroder: ok, i will look at it and merge it if there is nothing blocking
<ScottK> I should be able to look at it tonight or in the morning.
<ebroder> ScottK: Awesome, thanks
<SpamapS> ugh.. the us archive servers are goingg... slllwooooowww today....
<barry> SpamapS: are you sure?  they seem quick to me
<SpamapS> barry: its something with Los Angeles I think
<SpamapS> happens about once a month
<SpamapS> I get like, 256kbit for a day or two
<SpamapS> I'm sure its AT&T's fault
<SpamapS> they're huge here.. and I'm on U-verse.. so sitting right on their backbone
<barry> SpamapS: no doubt :)  i do see occasional problems with my isp (rcn cable) but i usually track it down to their dns being f'd
<SpamapS> I've been using google's dns for a while now
<barry> yeah, i really should switch, but in general they're pretty good.  sometimes it's easier just to live through the pain for day
<SpamapS> They're about 0.5s faster than any name server AT&T has ;)
<SpamapS> I love the idea of just pre-caching everything
<SpamapS> flipping ttl on its ear and trying to actually keep everything in RAM
#ubuntu-devel 2010-12-15
<SpamapS> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smoser`
<ari-tczew> doko: is python-django on your todo ftbfs fix?
<jfer> Hi. I am having trouble using bzr to get involved in unity
<jfer> can someone please give me a hand?
<achiang> jfer: what is your question?
<kees> james_w: say, why is this 6 months behind? https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/kde4libs/natty
<kees> Riddell: do you know anyone from upstream KDE that will commit my patch in https://bugs.kde.org/show_bug.cgi?id=245529 ?
<ubottu> KDE bug 245529 in general "drkonqi fails when PTRACE restrictions are active" [Normal,Unconfirmed]
<james_w> kees, bug 653301
<ubottu> Launchpad bug 653301 in Ubuntu Distributed Development "Packages failing due to pristine-tar not being able to reconstruct their tarball" [High,Triaged] https://launchpad.net/bugs/653301
<james_w> which could actually progress now
 * james_w leaves that for tomorrow
<mark_> test
<kees> james_w: ah-ha, thanks
<mark_> any progress on the memory leaking nm-applet?
<mark_> any progress on the memory leaking nm-applet?
<pitti> Good morning
<dholbach> good morning
<akshatj> good morning dholbach
<dholbach> hi akshatj
 * ebroder wants Upstart managing his user session instead gnome-session
<seb128> hey
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smoser`, seb128
 * dholbach hugs seb128
 * seb128 hugs dholbach
<mvo> seb128: happy flying
<seb128> mvo, thanks ;-)
<mok0> mvo, I see you fixed the python-minimal problem, THANKS!
<pitti> mvo: oh, did you?
<mvo> not really :/
<mvo> doko just added workaround for now
 * mvo is off for lunch
<mok0> pitti: there was an upgrade of python2.6-minimal, after which I could install python-minimal
<pitti> mok0: in natty? no, that was python2.7-minimal dropping the Breaks:
<doko> it would be a workaround if the fixed python-defaults arrives in -updates
<mok0> pitti: That's what it seemed like when apt-get did its thing
<mok0> yes in natty
<mok0> anyway my natty sbuilder is now happily compiling again :-)
<ScottK> kees: Riddell, apachelogger, and JontheEchidna all have commit rights in KDE svn, so one of them.
<ScottK> Oh, or agateau if you can catch him.
<pitti> seb128: can you please reupload bug     688781
<ubottu> Launchpad bug 688781 in sqlite3 (Ubuntu Maverick) "Fix performance regression affecting Banshee" [Low,Fix committed] https://launchpad.net/bugs/688781
<pitti> seb128: with a fixed LP# ref in the changelog?
<seb128> pitti, urg, yeah sorry about that
<seb128> pitti, done
<pitti> seb128: merci
<seb128> de rien, sorry for not being careful
<seb128> the bug number was listed twice but not with the right format ;-)
<ScottK> NCommander: When you have a moment, I'd like to talk to you about sip4-qt3 (looking for help understanding it, not asking you to do work).
<doko> seb128: who best to ask about vala? bug #618809
<ubottu> Launchpad bug 618809 in gtask (Ubuntu) "libvala-dev -> libvala-0.10-dev transition" [High,Confirmed] https://launchpad.net/bugs/618809
<seb128> doko, do they fail to build or...?
<doko> seb128: yes, b-d on libvala-dev, now we seem to target vala 0.12
<seb128> doko, did they fail to build if you rename the build-depends?
<doko> seb128: yes
<seb128> kenvandine, ^ do you have time to try to see what's wrong with gtask?
<doko> cyphermox and slomo are not online. will subscribe them
<seb128> doko, or wait for kenvandine to reply
<doko> ok
<ari-tczew> WiÄcej osÃ³b chce CiÄ poznaÄ na Badoo!
<ari-tczew> ups, not this copy
<ari-tczew> doko: is python-django on your todo ftbfs fix?
<doko> ari-tczew: no. what is wrong with it?
<ari-tczew> doko: no longer build with python. it's to sync, but it can be synced because it's ftbfs on natty chroot.
<doko> ari-tczew: bug number?
<ari-tczew> doko: not reported, report it?
<doko> ari-tczew: ftbfs is not that much info ...
<ari-tczew> doko: as sync request or rather ftbfs?
<doko> ari-tczew: is it safe ti sync, do packages b-d on it, build? you have more information than me. please make it available. bug report seems to be fine
<kenvandine> seb128, i can look at gtask
<ari-tczew> doko: hmmm, I can't attack buildlog ATM, so I'm sending pastebin: http://paste.ubuntu.com/544044/
<ari-tczew> bug 690646
<ubottu> Launchpad bug 690646 in python-django (Ubuntu) "FTBFS with python" [Undecided,New] https://launchpad.net/bugs/690646
<Daviey> doko: Have you been seeing, http://pb.daviey.com/cRcx/raw/ ?
<doko> ari-tczew: does the package b-d on python-all*?
<doko> Daviey: dpkg -l python python-minimal ?
<ari-tczew> doko: nope
<Daviey> doko: version 2.6.6-2ubuntu1, want a full paste?
<doko> ari-tczew: but it tries to build for it.
<Daviey> doko:  http://pb.daviey.com/ZJew/raw/
<doko> Daviey: see my last comment in https://bugs.edge.launchpad.net/ubuntu/+source/python2.7/+bug/689306
<ari-tczew> doko: Build-Depends: debhelper (>= 7.0.50), python-support, python (>= 2.5) | python-sqlite, language-pack-en-base Build-Depends-Indep: python-sphinx, libjs-jquery
<ubottu> Ubuntu bug 689306 in python2.7 (Ubuntu) "package python2.7-minimal 2.7.1-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 3" [Medium,Confirmed]
 * Daviey reads
<apw> jhunt, hey, you had a bug for initramfs-tools for the fixes for the new linhib0001 stuff, can you point me at it
<jhunt> apw: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/683605
<ubottu> Ubuntu bug 683605 in util-linux (Ubuntu) "kernel hibernate signature has changed from S1SUSPEND to LINHIB0001" [Undecided,New]
<apw> jhunt, how is that one going, i am starting to see duplicates of it
<Daviey> doko: thanks!
<apw> jhunt, oh yeah it was waiting for something to invalidate a pending linhib0001 image in swap when it was first installed ... else bad poop (tm) could occur
<NCommander> ScottK: I'm here
<ScottK> NCommander: Hello.
<NCommander> ScottK: how are you doing this morning?
<ScottK> NCommander: I looked at dh_sip and it seems simple enough.  The one big question I have is where does the API version come from?
<ScottK> NCommander: Pretty good.  Pleanty to do.
<NCommander> ScottK: ah, that's a new feature added by the co-maintainer. I would have to look
<ScottK> NCommander: OK.  I thought you had been involved in it.
<NCommander> give me a sec, I'll grab the source
<ScottK> Thanks.
<jhunt> apw: sorry, been busy on upstart. So the scenario is that if a user boots a kernel older than 2.6.37 (having hibernated in the 2.6.37 kernel), we need to invalidate the swap signature right?
<NCommander> ScottK: I did some design discussions, but then I went to China and it got implemented without me
<ScottK> I see.
<NCommander> ScottK: looks like we're quizing dpkg for the python-sip version
<apw> jhunt, no actually the issue is if we have natty and hibernate, reboot, hibernate is not detected and swap is lost.  we then fix the tools and reboot and it finds and resume from the image and the filesystem no longer matches the memory image and BLAMMO bad corruption of /
<NCommander> ScottK: which is sane because we don't know if the sip ABI has changed (there's no promise by upstream that it will remain stable)
<apw> jhunt, so if you install your fixes to the tools, we need to invalidate the swap marker as the contents are definatly BAD to use
<apw> cjwatson, ^^
<NCommander> cjwatson: did you get around to putting archdetect in userspace BTW? (per UDS)
<ScottK> NCommander: Right, but dh_sip uses whatever API version the package provides.
<ScottK> I'm trying to figure out where that comes from (see the provides in debian/control)
<NCommander> ScottK: it would be the version of the source package then
 * NCommander looks a little more indepth
<cjwatson> NCommander: see recent debian-boot@
<ScottK> That doesn't match what's there currently.
<NCommander> cjwatson: checking
<NCommander> ScottK: what's there currently?
<ScottK> NCommander: Provides: ${python:Provides}, sip-api-7.0, sip-api-7.1
<NCommander> cjwatson: thread title?
 * NCommander is not seeing it in the archive list
<cjwatson> NCommander: http://lists.debian.org/debian-boot/2010/12/msg00481.html
<NCommander> cjwatson: interesting. I'll be watching what develops in this thread (dpkg-subarchitecture or extending dpkg-architecture is an interesting idea TBH)
<cjwatson> NCommander: I can't say I approve myself - stuff that isn't maintained by the dpkg team shouldn't be in the dpkg-* namespace
<cjwatson> (dpkg-reconfigure is a historical mistake that shouldn't be repeated)
<cjwatson> I followed up to the thread to say that
<ari-tczew> doko: so, are B-D fine or not?
<doko> ari-tczew: is the package meant for all supported python versions, or just for the current one?
<ari-tczew> doko: dunno, really
<doko> ari-tczew: where is the merged package?
<ari-tczew> doko: merged?
<doko> ari-tczew: I thought you wanted to merge from unstable?
<ari-tczew> doko: it's ready to sync
<NCommander> cjwatson: thanks for being on top of this
<ari-tczew> doko: but it's ftbfs - the same with current package and from unstable, so I'm getting in touch with you
<doko> ari-tczew: $ cat debian/pyversions
<doko> 2.3-
<cjwatson> dholbach: does http://merges.ubuntu.com/main.json (and restricted, universe, multiverse, and main-manual etc.) fit the form you need for harvest?
<ari-tczew> doko: I see. what does it mean for me?
<dholbach> cjwatson, that should be fine - I might write a script that goes and merges them (as Harvest does packagesets/etc. on its own) - let me quickly try it out
<doko> so it wants to build for all python versions. uninstall python26-minimal and try again
<cjwatson> dholbach: right, it's just easiest to spit them out that way
<dholbach> cjwatson, don't worry - that's totally fine - should be easy to do :)
<cjwatson> dholbach: I also just committed a grep-merges tool to ubuntu-dev-tools that uses that output
<dholbach> awesome
<dholbach> I'll report back in a few
<dholbach> thanks in any case
<cjwatson> so should at least be valid json ;-)
<doko> ari-tczew: and it will fail later ...
<ari-tczew> doko: could you fix it?
<ari-tczew> (I can't)
<dholbach> cjwatson, looking good :)
<dholbach> (locally)
<cjwatson> excellent
<apw> cjwatson, where do the unity peeps hang out ?
<dholbach> #ayatana probably
<cjwatson> yeah
<NCommander> ScottK: are you still interested in updating your +1 on my core dev app
<ScottK> NCommander: I don't think we've worked on anything together recently?
<hallyn_> hm, debootstrapping a lucid image on natty is giving me troubles
<NCommander> ScottK: I poked you on that earlier lsat month, and I thought you wanted to revise what you said; are   you still confortable +1ing me?
<ScottK> You did?
 * ScottK lost those brain cells apparently.
<ScottK> NCommander: Give me a link and I'll look.
<NCommander> ScottK: I thought I did, or at elast said something at UDS. Granted, its been a long month
<NCommander> ScottK: https://wiki.ubuntu.com/MichaelCasadevall/CoreDevApplication
<ari-tczew> doko: I prefer to not uninstall python2.6-minimal - it will remove 50% of important packages.
<ari-tczew> doko: I guess that you're talking about remove python2.6-minimal from B-D?
<doko> ari-tczew: you should do development in a chroot where you can do stuff like this
<ScottK> NCommander: I think it's still correct.
<ari-tczew> doko: I use pbuilder. python2.6-minimal doesn't exist in debian/control
<mok0> How to deal with a package distributed by svn only, and where upstream does not provide a .tar.gz file?
<azeem> mok0: do they tag releases?
<mok0> azeem: nope
<pitti> mok0: do they have version numbers at all?
<mok0> pitti: yes, svn revision numbers
<pitti> I  mean "eleases"
<azeem> then I'd just use 0.0.0~r<svn-revision> as version number
<mok0> azeem: oh, they do have a version number yes
<pitti> mok0: right, use 0.r1234 as fake version numbers and use make dist
<mok0> pitti: ok... just seems going a detour, when everything is in LP
<mok0> :-)
<ion> Perhaps 0~r1234. That should accommodate any kind of future version number. :-)
<pitti> mok0: well, you could use bzr-svn to import upstream's trunk, and create a branch with the packaging in it
<pitti> ion: mathematically that's a really fun number
<mok0> pitti: right, but I still need a tar.gz file for the source package
<pitti> a non-negative number smaller than 0
<ion> hehe
<pitti> mok0: why?
<pitti> mok0: you can call autoreconf in debian/rules, if you are worried about that
<mok0> pitti, errh that was what I thought you said: "make dist"
<pitti> mok0: right, you'd use that _if_ you want to create an orig.tar.gz
<pitti> if you want to branch off trunk for a packaging branch, you don't have to
<pitti> but your choice really
<mok0> pitti: I see. I've never done packaging directly from a bzr before, so it's new territory for me.
<pitti> it's not that different; you just need to ensure that you build the autoconfiscation
<pitti> (if they use autotools)
<mok0> pitti: they do
<mok0> pitti, do you have a reference for a package I could study, that does not use an orig.tar.gz file?
<pitti> hm, not off-hand
<Keybuk> jdstrand: when somebody files four separate SEGV reports in the space of a minute, I'm afraid I begin to suspect something else wrong
<Keybuk> jdstrand: so could you run memcheck86 on your machine please
<jdstrand> Keybuk: they aren't mine
<jdstrand> Keybuk: they are old and private. I just noticed them since I had access
<Keybuk> are they not?  LP's make them sound like they are
<Keybuk> ahh
<Keybuk> LP fail then
<jdstrand> Keybuk: so I subscribed you and james since I thought someone might be interested in seeing them :)
<Keybuk> thanks
<Keybuk> jdstrand: in general, subscribe james from now on
<jdstrand> sure
<Keybuk> he's the ubuntu maintainer now
<jdstrand> Keybuk: ok, I did both of you this time, but noted
<Keybuk> but I never mind being subscribed
<Keybuk> I just mean avoid only subscribing me by accident, since I won't be here :p
 * jdstrand nods
<Keybuk> thanks :p
<Keybuk> will take a quick look at these now
<jdstrand> cool, thanks
<doko> kenvandine: gtask, thanks for the upload, but better re-upload as ubuntu1 instead of buildN
<kenvandine> doko, will do
<kenvandine> doko, done
<dholbach> cjwatson, it's on there! http://harvest.ubuntu.com/opportunities/ :)
<cjwatson> neat!
 * dholbach hugs cjwatson
<dholbach> good work!
<lamont> I wish that my system wouldn't randomly decide that a window should have the cursor grabbed when the window believes that it does not...  clearing that makes for some fun exploritory poking
<seb128> cjwatson, could you review or merge https://code.launchpad.net/~smoser/ubuntu/natty/openssh/lp688574/+merge/43366 when you have some time?
<cjwatson> I really wish that ssh-import-id weren't in openssh.  it's such a bad idea for it to be integrated there
<cjwatson> it belongs in a separate package
<cjwatson> seb128: Dustin's assigned it to himself, he can do it
<cjwatson> (the bug)
<kirkland> cjwatson: ?
<cjwatson> kirkland: 16:39 <seb128> cjwatson, could you review or merge https://code.launchpad.net/~smoser/ubuntu/natty/openssh/lp688574/+merge/43366 when you have some time?
<cjwatson> you assigned the bug to you so as far as I'm concerned you're taking care of that
<kirkland> cjwatson: it was a separate package, we reviewed it in belgium, and i got the go ahead from you to drop it in openssh-server
<cjwatson> over my protests
<seb128> ups sorry, I was reviewing from the queue and just read the merge request, not the bug
<cjwatson> I thought it was wrong but you wouldn't let up :(
<cjwatson> bug 690436 is a great demonstration of why it should be separate
<ubottu> Launchpad bug 690436 in openssh (Ubuntu) "ssh-import-id requires wget and ca-certificates to function properly" [Undecided,New] https://launchpad.net/bugs/690436
<kirkland> cjwatson: ?  i'm sorry, i didn't under you protested it
<cjwatson> it's bizarre that we have this thing that upstream doesn't care about, that's maintained totally separately from openssh to all intents and purposes, and yet it's in the openssh-server package
<cjwatson> it's basically an Ubuntu server add-on
<kirkland> cjwatson: are you asking for this in a separate source package, or a separate binary package under openssh ?
<cjwatson> normally, source packages are divided along maintenance lines
<cjwatson> I really don't know what I'm asking for any more, though, I just want not to have to worry about ssh-import-id TBH
<kirkland> cjwatson: okay; i'm in the process of getting it upstream
<cjwatson> you seriously think upstream will take it?
<cjwatson> I am extremely doubtful
<kirkland> cjwatson: to do that, smoser wanted to re-write it in the way that that merge request does
<kirkland> cjwatson: i honestly have no idea;  i have never dealt with that upstream
<kirkland> cjwatson: is ssh-copy-id upstream?
<cjwatson> I think you're onto a loser
<cjwatson> ssh-copy-id is, yes
<cjwatson> but from ages and ages back
<cjwatson> openssh upstream are extremely conservative, and rarely include anything significant that they didn't write themselves
<cjwatson> maybe I'm wrong, but it would astonish me if they took ssh-import-id
<kirkland> cjwatson: i see it in a contrib/
<kirkland> cjwatson: i see this as ssh-copy-id, from the other direction
<kirkland> cjwatson: ssh-copy-id securely pushes a public key;  ssh-import-id securely pulls a public key
<kirkland> cjwatson: i mean, i can make a new source/binary package;  but it's one shell script and one manpage
<cjwatson> you may see it that way, but I think it's unlikely that upstream will
<cjwatson> pulling keys has much more interesting cryptographic properties
<kirkland> cjwatson: right;  i don't know that upstream well enough to have any idea what they would say
<cjwatson> pulling keys over SSL even more sos
<cjwatson> *so
<cjwatson> because that means SSL is now within their security boundary
<cjwatson> not to mention the hardcoding of LP, etc.
<cjwatson> (sure, that's fixable, although the hardcoding is a desirable part of the UI from Ubuntu server's point of view)
<kirkland> cjwatson: it's configurable now
<kirkland> cjwatson: the URL;  defaults to LP
<cjwatson> bear in mind that even of patches I think are a good idea, or even blindingly obvious, I only have a 50% success rate or so at getting them upstream
<cjwatson> when they do take them, they often rewrite them
<kirkland> cjwatson: okay, well, i plan on dropping the script on that list out of courtesy
<kirkland> cjwatson: if they have constructive criticism that I can address, I will
<cjwatson> I'm pretty confident we're stuck with it forever
<kirkland> cjwatson: if they tell me to go f myself, fine;  i've done my duty
<cjwatson> but that's an ongoing maintenance problem
<kirkland> cjwatson: now, what I really want to know is how you want this script to be packaged in Ubuntu, in the mean time
<cjwatson> IMO the dependency issues are a good reason why at the very least it needs to be a separate binary package again
<kirkland> cjwatson: it shouldn't be a maintenance problem;  it should just work; shouldn't need a lot of attention; it should do one thing and do it well
<smoser> its very little on going maintenance, and a fairly high amount of "man that was easy"
<cjwatson> there's a bunch of mail I have to ignore
<cjwatson> any bunch of mail I have to ignore is a problem :)
<cjwatson> look, I can procmail out anything with ssh-import-id in the subject if you really want, but I'm not sure that's constructive.  What I want is for it not to show up as part of openssh maintenance, because really, it's being maintained separately
<kirkland> cjwatson: i'm subscribed to all bugs in openssh
<cjwatson> I know, but so am I
<cjwatson> things like this happen, where the patch pilot asks me about something and I honestly don't have a clue
<kirkland> cjwatson: "don't have a clue" -- dude, you probably the smartest person I know ;-)
<kirkland> cjwatson: but I understand, I don't want this to be your problem
<cjwatson> I don't have a clue about the correctness or otherwise of this merge request
<cjwatson> I view that as a problem, given that I maintain the package
<cjwatson> whether it's my problem ... I'm not sure
<kirkland> cjwatson: well, for the record, I would be happy for you to pass any and all ssh-import-id issues to me, and I'll deal with them at a high degree of urgency
<cjwatson> but it seems to me that having these two disparately-maintained things in the same source tree is just creating extra work
<kirkland> cjwatson: that said, i'll split this out to a separate package
<Riddell> kees: I committed that patch to KDE thanks
<kirkland> cjwatson: fine, i'll split it out;  can openssh-server recommend this package?
<cjwatson> sure
 * kirkland gets to work
<cjwatson> thank you, my mailbox will appreciate it
<jhunt> cjwatson: I've tweaked busybox for bug 683605, but am getting quilt errors on the 'dpkg-buildpackage -S'
<ubottu> Launchpad bug 683605 in util-linux (Ubuntu) "kernel hibernate signature has changed from S1SUSPEND to LINHIB0001" [High,Confirmed] https://launchpad.net/bugs/683605
<cjwatson> jhunt: what's the text of the error?
<jhunt> cjwatson: error is, "dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found"
<cjwatson> ah, ok, that's easy - cd to the parent directory, 'apt-get -d source busybox'
<cjwatson> just so it has the upstream source available
<cjwatson> I take it you generated a quilt patch for your change?
<jhunt> ok - the parent dir does have the bzr upstream src, but clearly that ain't good enough :-)
<jhunt> cjwatson: no - never used quilt.
<cjwatson> aha, well you need to :)
<cjwatson> back out your changes to start with
<cjwatson> quilt new name-of-your-change.patch # look in debian/patches/ for examples
<cjwatson> quilt edit util-linux/volume_id/linux_swap.c # or whatever
<cjwatson> make your changes
<cjwatson> quilt refresh
<cjwatson> then edit debian/patches/name-of-your-change.patch according to http://dep.debian.net/deps/dep3/ so that we know why it's there in future
<cjwatson> then you can build
<cjwatson> the main thing to watch out for is just that quilt needs to know about any file you change before you edit it, so that it has a pristine copy - 'quilt edit' is basically 'quilt add; $EDITOR'
<cjwatson> you can use the 'what-patch' tool in ubuntu-dev-tools to find out whether a package uses a patch system before you start editing it
<kees> Riddell: great! thanks. :)
<jhunt> cjwatson: thx! Re the apt-get src, I'm running maverick, but this bug is in natty, so a wget or similar instead presumably?
<cjwatson> oh, yeah
<cjwatson> dget http://archive.ubuntu.com/ubuntu/pool/main/b/busybox/busybox_1.17.1-7ubuntu4.dsc
<cjwatson> sorry, dget -d
<cjwatson> or I have http://paste.ubuntu.com/544096/ lying around in ~/bin/get-lp-package - 'get-lp-package ubuntu busybox 1:1.17.1-7ubuntu4'
<ev> jhunt: or just put the natty deb-src in your sources.list
<jhunt> ev: thx
<seb128> kirkland, did you guys agree to use a new source? should the sponsors be unsubscribed from this bug for now then?
<seb128> kirkland, the openssh one
<kirkland> seb128: sure, just assign the bug to me
<seb128> ok thanks
<kirkland> cjwatson: presumably you're subscribed to  openssh-unix-dev@mindrot.org?
<kirkland> cjwatson: and presumably you won't want me to explicitly CC you on my note to them?
<cjwatson> kirkland: right
<cjwatson> (well, I read it via a news gateway)0
<jhunt> cjwatson: I'm confused by the Forwarded quilt field. I'm fixing this bug in lp:ubuntu/busybox, so to generate the upstream git patch, do I use the bzr-git to patch "lp:busybox" and export a git patch, mail to the busyboxy mailing list and then ref. *that* patch in my lp:ubuntu/busybox quilt patch?
<cjwatson> jhunt: upstream will probably respond best if you just generate a patch using git format-patch for them
<cjwatson> based on whatever their current tip of development is
<cjwatson> jhunt: so normally, TBH, I just copy the patch around between two trees :)
<juliank> Who does not love git format-patch?
<cjwatson> though I mean a patch is a patch is a patch, so if you generate it with bzr-git I shouldn't imagine it would go too badly wrong
<cjwatson> anyway, Forwarded just wants a URL so that you can show you've sent the patch somewhere
<juliank> cjwatson: git patches can be applied directly and have a commit message; so it's a bit easier (just git am 0001-my-patch.patch)
<jelmer> cjwatson, jhunt: "bzr send --format=git" generates git-format-patch-like patch files
<juliank> jelmer: Cool
<jhunt> cjwatson: thx, so I *think* I fix the bug in lp:busybox, bzr send it upstream, then pull that into lp:ubuntu/busybox as a quilt patch, build it, upload to ppa and request sponsorship. This bug is turning into a four-act epic... :)
<jelmer> There's also "bzr diff --format=git". I'm not sure if anybody other than myself is using either at the moment though.
<cjwatson> jhunt: it gets quicker as you build up habits
<juliank> jelmer: I get bzr: ERROR: Bad value "git" for option "format". - am I missing something?
<jhunt> cjwatson: whoever said this isn't easy? :)
 * jhunt goes for a strong drink and a lie down...
<jelmer> juliank: do you have bzr-git installed?
<cjwatson> jhunt: I don't really think about it any more
<juliank> jelmer: I thought I had it installed, but I didn't.
<cjwatson> you get used to lobbing patches around into the right places
<bdrung> ebroder: around?
<smoser> pedro_, hggdh has implicated you. suggesting that you may have been running some lp:qa-regression-testing on lucid-proposed kernel (2.6.32-311.23)
 * hggdh hides, fast
<pedro_> smoser, yes, for this kernel cycle i've running test-kernel.py and test-kernel-root-ops.py
<smoser> so do you have results ? i'm completely unaware of how long that takes or what it entails
<pedro_> i do, one sec
<pedro_> smoser, http://people.canonical.com/~pedro/kernel/
<pedro_> smoser, in there you can find the results and as well from autotest and ltp for maverick, lucid and karmic proposed kernels
<smoser> pedro_, so, that represents "PASS" ?
<pedro_> yes
<smoser> pedro_, so, based on that, i'm going to mark changelog mentioned bugs as "verification-done"
<ebroder> bdrung: Here now; will be caught up on backlog momentarily
<smoser> and i'll point at your results. do you have any issue with that?
<pedro_> smoser, ok nice, i'm commenting on the tracking bugs right now
<smoser> oh.
<smoser> well, then you can do the 'verification-done' also
<smoser> or maybe just let that up to an SRU person, but in the past pitti told me that i could change the tag if i'd done it.
<pedro_> smoser, the tests were done by Monday but we were waiting for HW cert team to provide their results first, just following the https://wiki.ubuntu.com/Kernel/StableReleaseCadence#Tracking%20Bug%20Procedure
<pedro_> smoser, but just a few minutes ago marjo said it's ok to comment on it and that the procedure is going to be fixed
<marjo> pedro, smoser: according to sconklin, qa team can post results, but we shouldn't be changing any tags until both hw cert & qa team are done
<pedro_> marjo, smoser ok our part is done (qa team) now we have to wait for hw cert
<pedro_> for maverick, lucid and karmic kernels
<marjo> pedro: ack
<marjo> pedro: nice job!
<pedro_> hggdh, ^ that goes for you too ;-)
<pedro_> thanks a lot marjo
<hggdh> pedro_: this is relative to kernel updates, right?
<pedro_> hggdh, yes SeÃ±or
<hggdh> pedro_: muchas gracias
<bdrung> ebroder: i reviewed your backportpackage branch and i have some requests
<smoser> ok, so someone from QA is going to mark the relavant bugs as "verification-done" ?
<doko> I didn't like cmake that much in the past, but looking at the alternatives like handcrafted build systems and cmake, ... I do like it better
<smoser> and we're waiting on some hw cert tests, is that right ?
<pedro_> smoser, yes
<smoser> any idea on how long that is going to be ?
<smoser> (not nagging, asking)
<pedro_> cr3, ^ ?
<bdrung> ebroder: you probably have to unquote the dsc url from launchpad (to convert "%2b" -> "+")
<bdrung> ebroder: you should evaluate if the package build process failed
<ebroder> Keybuk, jhunt: I forget - why did you guys decide to do /etc/init/foo.override instead of a separate directory? Separate directories seems to me like it would enable more things easily down the road (e.g. using /etc/init.user + ~/.init for user sessions)
<ebroder> bdrung: What do you mean by evaluate if the build failed? Right now it throws an error, doesn't it?
<bdrung> ebroder: biulder.build(...) returns the return code of the build command (should be 0 on success)
<bdrung> ebroder: example package for unquoting: qemu-kvm and abraca
<ebroder> bdrung: Sure, the unquoting is easy. What do you think it should do if the build fails?
<bdrung> ebroder: print an error and abort (if you don't like that, then change the default for the upload question to no)
<ebroder> bdrung: Nope, I like bailing. It's nice and simple
<bdrung> ebroder: i don't like global variables. you could pass lp to the function that require it.
<ebroder> bdrung: :(, but ok
<bdrung> ebroder: 4) instead of passing opts to the subfunction you could pass the needed opts.foo instead
<bdrung> ebroder: optional 1) allow specifying the workdir (and then don't purge it)
<bdrung> ebroder: optional 2) allow a dsc as input
<bdrung> ebroder: optional 3) i want the workdir in /tmp for sponsor-patch too
<bdrung> ebroder: 5) give examples in the man page of backportpackage
<bdrung> cjwatson: should grep-merges be installed? then you have to add it to setup.py. and please add some examples to the man page of grep-merges
<ebroder> bdrung: Ok, I can do all of those. Can I do the same thing - default to mkdtemp() and clean it up afterwards, unless you specify a working dir?
<bdrung> ebroder: yes
<ebroder> bdrung: Great
<bdrung> ebroder: you can do the optional things in separate branches
<bdrung> - i want to get your backportpackage branch merged
<ebroder> bdrung: The optional things are generally easier than the non-optional ones, so I'll probably do them all at once :-P
<ScottK> ebroder: I finally took a look at your merge request.  I have a couple of comments.
<ScottK> 1.  -f tends to be kind of hard wired in people's brains as "force" (at least mine anyway).  Can we use something else?
<ScottK> Maybe -s/--source -d/--destination?
<ScottK> 2. Could to/destination default to whatever release the target system is running.  I suspect that will be by far the common case.
<ebroder> Yeah, I described them like that at first, but I was worried that people would conflate --source and the source package name
<ebroder> Yes, that's a reasonable default. I'll put that on my TODO
<bdrung> ebroder: i like the -s/--source -d/--destination idea
<ebroder> Ok. I have no objections to --source/--destination
<ScottK> ebroder: Also it'd be nice if there were a way to specify a standard destination in a config file so you didn't have to specify it each time.
<bdrung> i suggest to have a environment variable for that
<bdrung> same for upload destination
<ScottK> config file or environment variable are fine, but I think that might be a bit magical for non-experienced users.
<ScottK> (where that == environment variable)
<ebroder> ScottK: We already use environment variables in things like sponsor-patch, so this would be consistent. Also in backportpackage for things like UBUNTUTOOLS_BUILDER
<ScottK> ebroder: Yes, but sponsor patch is aimed at a developer user and this targets a broader audience.
<ScottK> Whichever you prefer though, I'm OK with it.
<bdrung> ScottK: we could use the devscripts config file for setting the environment variables
<bdrung> then we have both
<ScottK> Sounds reasonable as long as it's documented.
<ebroder> Whatever I do will end up in the manpage
<bdrung> ScottK: bug #681693
<ubottu> Launchpad bug 681693 in ubuntu-dev-tools (Ubuntu) "[wishlist] u-d-t config file" [Wishlist,New] https://launchpad.net/bugs/681693
<ScottK> OK.
<ebroder> bdrung: I'm thinking of supporting both an UBUNTUTOOLS_UPLOAD and BACKPORTPACKAGE_UPLOAD, and would probably also add a SPONSOR_PATCH_UPLOAD. Personally, I have separate PPAs for backports vs. non-backport tests, since the archive dependencies are different, so I want to be able to set that default separately. Seem reasonable?
<bdrung> ebroder: yes
<bdrung> ebroder: go ahead :)
<ebroder> bdrung: Awesome. I'll try to get an update to my branch ready for you in the next day or two
<bdrung> ebroder: ok
<bdrung> ebroder: i would like to get a current version of backportpackage merged and then merge improvement (like upload env variables, workdir chnange, ...) merged separately (= easier to review)
<bdrung> s/merged//
<bdrung> ebroder: do you have the time to do the "required" task now and the optional ones later?
<cr3> pedro_: which bug do you speak of, with smoser?
<smoser> the current -proposed kernel update
<cr3> smoser: I believe brendan updated the lucid one with something like in progress and it will be extended approprietaly when done, I believe
<smoser> cr3, so, i'm just wondering what the time frame is
<smoser> bugs referenced are bug 613381, bug 628776, bug 643891, bug 668380, bug 681132, bug 683257
<ubottu> Launchpad bug 613381 in linux (Ubuntu) "S3 resume hang when PCI Express wakeups don't clear the PM1 PCI_WAKE_DISABLE bit" [Medium,Fix committed] https://launchpad.net/bugs/613381
<ubottu> Launchpad bug 628776 in linux (Ubuntu Lucid) "HP NC511i Driver (be2net and be2scsi) is missing in kernel module udebs" [Low,Fix committed] https://launchpad.net/bugs/628776
<ubottu> Launchpad bug 643891 in linux (Ubuntu) "[IDT 92HD71B7X] ALSA test tone not correctly played back" [Undecided,In progress] https://launchpad.net/bugs/643891
<ubottu> Launchpad bug 668380 in linux (Ubuntu Lucid) "Lucid update to 2.6.32.25 stable release" [Medium,Fix committed] https://launchpad.net/bugs/668380
<ubottu> Launchpad bug 681132 in linux (Ubuntu Lucid) "Lucid update to 2.6.32.26+drm33.11 stable release" [Medium,Fix committed] https://launchpad.net/bugs/681132
<cr3> smoser: my understanding is that certification only tests that systems can still install and boot the new kernel, whereas qa tests for specific regressions
<smoser> well, yes. and they've run that test suite, so i'm just wondering when you would expect that the certification tests would be done
<cr3> smoser: Friday
<cr3> smoser: please be patient with us, we're training new folks so that we can reduce the timeframe over time
<smoser> cr3, i promise, i'm just asking
<cr3> smoser: cool, just thought I'd take this opportunity to reassure you we'll be getting awesomer :)
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smoser`
<bdrung> great work seb128 - we are down to 32 task waiting for sponsoring
<seb128> bdrung, thanks
<bdrung> seb128: now i can see the whole sponsoring table without scrolling :)
<seb128> ;-)
<ebroder> bdrung: Probably not until this evening - I should probably at least pretend to do work while I'm at work :)
<bdrung> ebroder: you are doing work - work for ubuntu :P
<bdrung> ebroder: in which time zone do you live?
<ari-tczew> bdrung: which resolution do you use?
<bdrung> ari-tczew: fullhd - 1920x1080
<bdrung> ups - 1920x1200
<ari-tczew> bdrung: aaa, then you can use look on SQ without scrolling :P
<ari-tczew> bdrung: btw. could you sponsor BlackZ's merges for main? some of them are lying so long
<bdrung> ari-tczew: which one?
<ari-tczew> bdrung: bug 685860 and bug 681418
<ubottu> Launchpad bug 685860 in nfs-utils (Ubuntu) "Please merge nfs-utils 1:1.2.2-4 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/685860
<ubottu> Launchpad bug 681418 in e2fsprogs (Ubuntu) "Please merge e2fsprogs 1.41.12-2 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/681418
<ebroder> bdrung: US/Pacific
<bdrung> ebroder: that explains a lot
<aantn> beuno: are you martin albisetti?
<beuno> aantn, yes I am
<cjwatson> bdrung: I *did* add it to setup.py, didn't I?
<cjwatson> oh, blast, forgot to commit that bit
<cjwatson> bdrung: do you think it needs examples?  it's really simple :)
<bdrung> cjwatson: no, you didn't. :P
<bdrung> cjwatson: yes, what kind of regexp are commonly used?
<cjwatson> I had the diff locally, honest
<cjwatson> it's just a substring match
<cjwatson> anyway, have to go for dinner, I'll do that part later
<apw> cjwatson, it feels like linux-headers package installs are taking a long time on natty again ... has something changed ?
<hallyn_> hm.  'bzr: ERROR: Merge upstream in merge mode is not yet supported.
<hallyn_> kirkland: ^  that's what i get when i do 'bzr merge-upstream' from the vmbuilder-packaging tree
<cjwatson> apw: dunno, but things are *going* to change again in dpkg so not worth debugging right now
<cjwatson> apw: you can put force-unsafe-io in /etc/dpkg/dpkg.cfg now to turn off fsyncs across the board (at your own risk)
<apw> cjwatson, ok thanks, i'll just leave it be, and keep an eye on it
<cjwatson> we did go back to fsync(2) because sync(2) caused other problems - but there's a dpkg 1.15.8.7 on its way soon
<cjwatson> which uses sync_file_range(2) at tytso's suggestion
<apw> cjwatson, sounds interesting
<apw> cjwatson, we ended up needing to do a quick upload for something else so that vt numbering change is in with it ... should be built by the morning
<cjwatson> cool, thanks
<cjwatson> bdrung: example added no
<cjwatson> now
<barry> can someone with perms please retry this build: https://launchpad.net/ubuntu/+source/pymvpa/0.4.5~dev23-2build1/+build/2076605
<barry> i think the underlying bug that caused this has been fixed (iow, it wfm locally)
<ebroder> barry: Sure, just a sec
<barry> ebroder: thanks
<ebroder> Done
 * barry watches and crosses his fingers
<kirkland> any idea why right clicking is not working in Natty?
<crimsun> lool: while cleaning BTS, I noticed #460197. Are you experiencing this in Ubuntu as well?
<geser> I hope we don't optimize for mice with one button :)
<kirkland> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/690873
<ubottu> Ubuntu bug 690873 in sudo (Ubuntu) "latest natty sudo upgrade removes admin from /etc/sudoers" [Critical,Triaged]
<kirkland> be very careful if you upgrade sudo right now in natty ....
<kirkland> kees: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/690873
<ubottu> Ubuntu bug 690873 in sudo (Ubuntu) "latest natty sudo upgrade removes admin from /etc/sudoers" [Critical,Triaged]
<kirkland> kees: looks like blackz did the merge earlier today
<micahg> bdrung: ^^
<kirkland> kees: debian has changed /etc/sudoers to be a conffile, and wants to use a /etc/sudoers.d dir
<kees> yeah, looks like sudo made /etc/sudoers a conffile when it wasn't one before.
<kees> I can't find what added %admin originally...
<StevenK> d-i?
<kees> StevenK: not sure, but we need to fix sudo quickly and hard!
<kirkland> kees: possibly installer magic?
<StevenK> Do we want to block the sudo update on the mirror?
<kees> I don't see it in any maintainer scripts I have installed, so yeah, must be installer.
<wgrant> Has someone told ubuntustatus on identi.ca and twitter?
<kees> slangasek: do you know this area at all?
<ebroder> kees: Any chance it's user-setup or something like that?
<Laney> can you still block updates after they have been mirrored?
<wgrant> Laney: Sort of.
<kees> kirkland: can you pastebin the resulting sudoers file from sudo?
<wgrant> Laney: We can chmod -r
<kirkland> kees: sure
<wgrant> And then force a mirror push.
<Laney> yeah, like that
<kirkland> kees: before or after?
<kees> elmo: awake?
<kees> kirkland: after
<kirkland> kees: http://pastebin.com/g1ghJNaX
<kirkland> kees: that's straight out of debian/sudoers in the current sudo source
<kees> Ugh. Yeah, it even removes the ticket defaults.
<kirkland> StevenK: I think it would be a good idea
<wgrant> Who has access to identi.ca/ubuntustatus?
<kirkland> StevenK: the conffile conflict defaults to "N" (keep my local copy), which is "something";  but I still breezed over the diff without noticing the -%admin the first time
<wgrant> It is for precisely this purpose.
<kirkland> wgrant: not sure ... rickspencer3 ?
<kirkland> robbiew: ?
<JackyAlcine> Evening, guys.
<kirkland> kees: http://pastebin.com/Sze9Yk3H
<kirkland> kees: that's the unbroken one
<kirkland> kees: as a quickie, we could put the contents of that into the sudo package's debian/sudoers file
<ebroder> kees: Ticket defaults? I don't remember there ever being ticket defaults...
<kirkland> kees: so at least there's no diff when upgrading
<ebroder> kirkland: We probably shouldn't if we were adding it as part of the installer before. That'd be a change in behavior for...people who do screwy things not involving the installer
<kirkland> kees: for those who haven't modified their /etc/sudoers
<ebroder> kees, kirkland: The snippet is added by user-setup-apply in user-setup
<kees> ebroder: ah, good find.
<ebroder> Don't know if there's separate code somewhere in ubiquity
<ebroder> cjwatson or ev would have a better idea
<kees> kirkland: everyone has modified their /etc/sudoers because it's going from non-conffile to conffile, iiuc.
<kirkland> kees: yes, but the delta could be zero
<ebroder> kees: Yeah, looks like there's a copy of the user-setup source package in d-i/source/user-setup in ubiquity
<kirkland> kees: anyway, that would just be quick and dirty to keep this from breaking in the near term
<ebroder> So you'd need to be sure to update that as well
<StevenK> ebroder: There's a script in ubiquity that will sync new code from d-i into it
<kees> so, it looks like this will only break people if they say "Y" to the prompt
<kirkland> kees: correct
<ebroder> How hard would it be for sudo's postinst to take everything in /etc/sudoers that didn't ship there and throw it in /etc/sudoers.d/50-custom? (Conditionalized on dpkg --compare-versions "$2" -lt "whatever", or whatever)
<StevenK> kirkland, kees: If DEBIAN_FRONTEND is noninteractive, the default is N, right?
<kirkland> StevenK: yes
<kees> StevenK: right
<kees> so, I thought the defaults were Defaults!lecture,tty_tickets,!fqdn for sudoers?
<kees> did that go away?
<ebroder> kees: I don't remember ever seeing that in any of my sudoers files
<kirkland> kees: from where I was sitting, though, I knew that I hadn't modified my own local /etc/sudoers, so I figured, meh, whatever Ubuntu recommends is good 'nough for me
<kees> hunh
<ebroder> kees: Looks like we compile those defaults in
<ebroder>   * Merge from debian unstable.  Remaining changes:
<ebroder>    - debian/rules:
<kees> ebroder: yup, this is an oooold sudoers file :)
<ebroder>      - compile with --without-lecture --with-tty-tickets (Ubuntu specific)
<kirkland> kees: hmm, so what do you think we should do with this?
<StevenK> kirkland: Do you think we should block the update and upload a revert?
<kees> kirkland: get the foundations folks to look at it. it'll only get people into trouble if they answer "Y", so I don't think this exactly qualifies for an archive block.
<wgrant> kees: I would Y, since I know I haven't modified it myself.
<kees> wgrant: it'll _always_ prompt, though, since it wasn't a conffile before. it'll prompt _everyone_.
<StevenK> So perhaps an ubuntustatus and u-d-a mail warning?
<kirkland> wgrant: right, that's more or less what I did
<kees> wgrant: ah, I see what you mean now
<wgrant> (I personally wouldn't, but I know lots of people who would)
<ebroder> We should definitely change user-setup to use sudoers.d. That seems like it should be uncontroversial and will at least unbreak new installs
<kees> StevenK: what about an upload that doesn't ship the sudoers file for now?
<kees> I really don't know the best way to approach this.
<kirkland> kees: yeah, i basically have that here now
<StevenK> I'm not sure either
<kirkland> kees: it's just a couple of lines to comment out of debian/rules
<ebroder> The upgrade path is annoying because the change was made by a package that doesn't get installed on the real system
<micahg> BTW, conffile change is debian 605130 FWIW
<ubottu> Debian bug 605130 in sudo "sudo: unowned files after purge (policy 6.8)" [Important,Fixed] http://bugs.debian.org/605130
<StevenK> lamont: If you're around, ^
 * kees ponders a preinst that detects %admin and writes a file into /etc/sudoers.d for it.
<kees> gah, what a mess.
<wgrant> Block and revert the update for now, I think.
<StevenK> Going from no conffile to conffile is always going to suck. Rocks.
<wgrant> Then a proper fix can be devised at our leisure.
<kees> wgrant: yeah, probably true.
<kirkland> kees: actually, the easiest solution would be to just put the necessary %admin bit in the new /etc/sudoers.d
<ebroder> kees: What about detecting if sha1sum /etc/sudoers == "some known value" (or alternatively in [list, of, known, values]), and if it does (is), writes the %admin line to /etc/sudoers.d and resets /etc/sudoers?
<ebroder> kirkland: I don't think the sudo package should unconditionally put the %admin line in. That's not what it's done previously
<kirkland> kees: people who answer "N" will continue working as normal
<micahg> ebroder: that won't help if people add select sudo rights
<kees> ebroder: right, I think that'll likely be the solution, but gathering that list of known values, or the stuff around it is what'll take time to test right
<ebroder> micahg: Yes, but if they know they've modified the conffile, they'll look more closely
<kirkland> kees: ah, i just saw your ponderance
<kirkland> kees: yeah, that's fine
<slangasek> kees: ugh; not deeply familiar, no
<kees> slangasek: okay, no worries.
<ebroder> kees: I don't know about older releases, but Maverick's sudo.postinst doesn't change /etc/sudoers on upgrades. If that's true going back, then there shouldn't be many cases to test for
<kees> ebroder: right, it should be finite, but I don't want to gather that list in a rush.
<ebroder> kees: Yeah, that's reasonable
<Laney> everyone is going to get a conffile prompt regardless, right?
<slangasek> shouldn't, if it's fixed right
<ebroder> Laney: Not if we reset /etc/sudoers to match the conffile in a preinst :)
<Laney> what conffile? it wasn't one before
<ebroder> Oh, hmm. Maybe you just remove the old file?
<slangasek> why wouldn't we just add the %admin line into the conffile as shipped?
<kees> Laney: right, a well-written preinst will handle the existing /etc/sudoers and potentially remove it completely
<Laney> right
<slangasek> instead of trying to match what Debian is doing here
<kees> slangasek: hunh, yeah, I guess that would be reasonable as a crisis-workaround.
<kirkland> kees: they have a %sudo line in theres
<kees> slangasek: the prompt needs to be fixed regardless, but that would stop people from having unsudoable systems
<Laney> that's a reasonable immediate fix
<slangasek> kees: fwiw I think it might even be the correct long-term solution
<ebroder> slangasek: I kind of figured someone made a deliberate choice to put the %admin line in user-setup instead of in sudo
<kees> ebroder: yeah, that was my thinking too
<slangasek> kees: if it's done correctly to where the conffile now matches the default generated file, then the conffile prompt goes out anyway
<Laney> even if this is becoming a conffile for the first time?
<Laney> if so, then +1
<slangasek> yes
<kees> slangasek: it's different at least due to the change of uncommenting the "include" directive
<slangasek> ah
<slangasek> in that case you'd have to do the preinst md5sum && rm trick
<Laney> seems like something that would be reasonable for dpkg-maintscript-helper
<kees> yeah, there's a non-trivial number of possible contents for the default /etc/sudoers, depending on which release you first installed. :(
<slangasek> but still, I think it's simpler for the conffile to include everything we expect to be there on upgrade
<hallyn_> all rightg whoever just uploaded sudo with cldeaned ut conffile is on mhy naughty list :)
<kirkland> hallyn_: yup
<ebroder> hallyn_: Read the scrollback. It never had the %admin line, so this is a non-obvious multi-package interaction
<kirkland> hallyn_: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/690873
<ubottu> Ubuntu bug 690873 in sudo (Ubuntu) "latest natty sudo upgrade removes admin from /etc/sudoers" [Critical,Triaged]
<kirkland> hallyn_: that's quite possibly the worst typo'd sentence I've ever seen from you :-)
<Laney> drunk with no-more-sudo rage
<kees> haha
<hallyn_> :)
<hallyn_> on n900
<kirkland> :-)
<kirkland> hallyn_: sudo locked you out of your system then?
<hallyn_> yeah, but i was walking ojut the door
<kirkland> hallyn_: boot a live cd, mount your root disk and:
<kirkland> echo "%admin ALL=(ALL) ALL" >> /etc/sudoers
<kirkland> well, to /etc/sudoers on your root disk, of course
<hallyn_> kirkland: no worries i have reswcue mode
<ebroder> kirkland, hallyn_: If you put it in /etc/sudoers.d/admin instead, you won't run into this problem in the future
<ebroder> So it looks like user-setup has been adding the %admin line since more or less time immemorial. r1 of user-setup in UDD :)
#ubuntu-devel 2010-12-16
<kees> okay, ubuntu2 uploaded, and I've added a note to the bug.
<kirkland> kees: thanks for uploading
<MTecknology> I'm so happy I caught that sudo bug being mentioned in here :P
<rickspencer3> kirkland, did you figure out your status.net thing?
<rickspencer3> I think it's robbiew, btw
<lool> crimsun: pulseaudio works across resumes on Ubuntu, yes
<mwhudson> someone please explain pinning to me :-)
<mwhudson> i'm writing this software that assembles debs from a bunch of archives
<mwhudson> (it fetches them using python-apt)
<mwhudson> i want it to very much prefer one archive, even if another archive has a later version
<mwhudson> i have a feeling this involves editing /etc/apt/preferences (in the kinda fake chroot the code uses)
<RAOF> I believe âapt pinningâ is the search term you're after; I need to look it up every time I try to touch it, so I'm not going to say anything more than that :)
<mwhudson> yeah
<mwhudson> it's what goes on the Pin: line that's a bit confusing to me
<Pici> !pinning
<ubottu> pinning is an advanced feature that APT can use to prefer particular packages over others. See https://help.ubuntu.com/community/PinningHowto
<Pici> Thats all I know about it too ;)
<kees> mwhudson: it's what to pin, so like:  Pin: release a=$RELEASE
<kees> where $RELEASE is natty, maverick, etc
<mwhudson> ah hah, the end of http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html seems to be what i want
<mwhudson> $RELESE comes from where? a Release file in the archive?
<kees> it's just a name, so   Pin: release a=natty
<kees> I've only ever using pinning for this crazy script: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head%3A/utilities/downgrade-all
<kees> that'll remove everything not in the primary archives.
<mwhudson> hm, looks like i'll need to make a Release file then
<mwhudson> (the archive i want to prefer is created from scratch)
<kees> mwhudson: I think you can put other thing on the Pin line, I've just never used any others
<mwhudson> kees: they all seem to come from the Release file
<kees> in that case, see this tool http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head%3A/repo-tools/update_repo
<ebroder> For what it's worth, there is an apt_preferences(5), but I've never found it to be that useful
<ebroder> apt-cache policy <package> is also useful for seeing how your pinning rules interact
<mwhudson> well, according to this documentation from 2005
<mwhudson> hmm
<mwhudson> about ubuntu on my maverick system seems to think i'm running natty....
<mwhudson> oh https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/690248
<ubottu> Ubuntu bug 690248 in ubuntu-docs (Ubuntu) "In Maverick 'About Ubuntu' displays Natty info" [Undecided,Confirmed]
<kees> hah, whoops
<hyperair> how do i get apport to unignore crashes?
<ScottK> export CRASHALLTHETIME=True
<hyperair> ScottK: er where?
<ScottK> hyperair: Sorry.  Bad joke.
<hyperair> oh
<hyperair> haha
<hyperair> i'm beginning to really hate glib's memory management
<ScottK> hyperair: How about "sudo service apport start force_start=1"
<hyperair> ScottK: no, that's different.
<hyperair> ScottK: i clicked that checkbox "ignore future crashes for this version"
<hyperair> it's not like i completely disabled apport
<ScottK> hyperair: OK.  Is it in /etc/apport/blacklist.d/apport?
<ScottK> Or that vicinity ...
<hyperair> ScottK: nah, it's not there =\
<hyperair> i'm trying to debug this dbusmenu crasher i just created by mistake
<hyperair> did you know glib's memory management sucks?
<hyperair> really really hard?
<hyperair> i'm actually amazed at how little people are complaining about dbusmenu and indicator memory leaks
<hyperair> because if dbusmenu is leaking, pretty much every indicator-using application is leaking
<ScottK> Much of the target audience for Ubuntu desktop is used to the idea that having to reboot to fix a computer is normal.
<hyperair> heh
<hyperair> i mean even among devels.
<ScottK> Dunno.  You're using a different dbusmenu implementation than I am.
<hyperair> ScottK: KDE uses a different one?
<ScottK> Sure.  It's a standard part of KDE.
<ebroder> hyperair: My guess for that would be /var/lib/apport or the like, but I don't actually know
<hyperair> ebroder: hmm it's not there either
<ebroder> hyperair: How about ~/.config/apport?
<hyperair> ebroder: doesn't exist
<ebroder> Ok, I give up
<hyperair> haha
<hyperair> nevermind, i've figured out where it was crashing
 * hyperair forgot to g_value_init before g_value_copy
<crimsun> lool: thanks, will see about pushing it into git.
<dholbach> good morning!
<dholbach> what's the magic runes in grub so I can boot natty with nvidia drivers? is that gfxpayloadsomethinsomething? :)
<ebroder> dholbach: edit /etc/default/grub, uncomment the GRUB_GFXPAYLOAD_LINUX line and set it to text
<dholbach> aha! thanks a lot ebroder
<ebroder> Then run update-grub
<dholbach> sweet
<dholbach> I'll try that
<dholbach> ebroder, I don't have that line - I guess I just add it and set to text, right?
<ebroder> dholbach: Yeah
<dholbach> alright, let's see what happens :)
 * dholbach hugs ebroder
<dholbach> thanks
<ebroder> No problem
<cjwatson> dholbach: you've filed a kernel bug, right?
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
<dholbach> cjwatson, will do when I get back to the machine
<ebroder> cjwatson: For what it's worth it's starting to sound like nvidia-current can't handle this across the board
<ebroder> cjwatson: Oh wait, I take that back. I had heard of it working in one case
<cjwatson> ebroder: I've definitely had at least one positive report from a user of nvidia-current
<cjwatson> and of course I guess it differs between nouveau and nvidia so we'll need to figure out how to handle that
<ebroder> cjwatson: Yeah, I've been trying to come up with something for that that doesn't involve putting the blacklists in the nvidia-* and fglrx packages
<ebroder> And for what it's worth, I haven't forgotten that I owe you a C module
<cjwatson> heh
<cjwatson> ebroder: we could have a .d directory for the blacklists </ugh>
<ebroder> cjwatson: Sure, it would be a lot nicer if the blacklist files were all kept in one package separate from either grub or the driver packages
<cjwatson> ebroder: I dunno, I was thinking about that and wondering if it was overengineering to keep it separate from grub2
<cjwatson> it would mean we'll have to have breaks each way when the format changes, etc. ...
<cjwatson> but it does mean we don't have to change the bootloader to change the blacklist.  meh
<ebroder> cjwatson: Yeah, but I suspect we're going to want to rev this increasingly frequently as we get closer to release
<cjwatson> there is one tricky bit though
<cjwatson> it's in $prefix, which means it really ought to be dealt with by grub-install
<cjwatson> that means (say) grub-gfxblacklist would have to deal with running grub-install on upgrade
<cjwatson> that's a REALLY hairy bit of code
<cjwatson> see grub-pc.postinst for the horror
<cjwatson> I'd kind of prefer to keep the invariant that only grub-$platform runs grub-install
<ebroder> That thought had crossed my mind. Unless I'm forgetting what I wrote, I intentionally didn't name the file foo.lst to avoid the grub-install wiping it out, so we can have update-grub drop it into place
<cjwatson> you named it gfxblacklist.lst, actually :)
<ebroder> Ah, curses
<cjwatson> grub-install doesn't remove foreign .lst files though
<ebroder> I'm pretty sure it has a rm $prefix/*.{lst,mod,a few others}
<cjwatson> I don't see that
<cjwatson> oh, wait, you're right
<ebroder> It's a bit obtuse. But it's focused enough that we can name our files around it
<cjwatson> however: we could have grub-gfxblacklist install it in /usr/lib/grub/i386-pc/ so that grub-install will copy it, and additionally refresh it at update-grub time
<cjwatson> that seems reasonable if slightly twisty to me
<ebroder> refresh it> as in refresh the one in $prefix?
<cjwatson> or actually not even update-grub, just refresh it in grub-gfxblacklist.postinst
<cjwatson> yeah
<ebroder> Yeah, that doesn't seem too horrid
<cjwatson> saves having to write a grub.d hook with no output or whatever
<dholbach> smoser, you're still listed in the topic as patch pilot :)
<dholbach> (I guess you need to change nick to smoser` and "@pilot out" again)
<seb128> dholbach, hey
<dholbach> hey seb128 - good work yesterday!
<seb128> dholbach, thanks!
<dholbach> down to 30!
<seb128> ;-)
<dholbach> we're getting there :)
<seb128> in fact less
<seb128> we should filter out the incomplete
<seb128> or the merge requests that are "need fixing"
<seb128> half of the list are things that need work
<dholbach> hmhmhm
<seb128> see the status column
<ebroder> One problem I've noticed is that UDD branches are by default reviewed by ~ubuntu-branches, so nobody can get them out of the queue
<seb128> (Needs fixing)
<seb128> (Needs fixing)
<seb128> etc
<seb128> ebroder, right
<ebroder> Some people set them to ~ubuntu-sponsors or ~ubuntu-dev, which is great, but most don't
<dholbach> ebroder, that's no problem - the script that generates http://reqorts.qa.ubuntu.com/reports/sponsoring/ takes care of that
<seb128> there is also some "Disapprove" in the list
<dholbach> seb128, aha!
<ebroder> dholbach: Look at http://bit.ly/fFlmak for instance. I wanted to reject that and take it out of the queue, but I couldn't
<seb128> the logilab one for example
<dholbach> seb128, we should set the status of the merge proposal to "work in progress" then
<seb128> dholbach, why?
<seb128> the correct status is "Needs work"
<dholbach> because work is required?
<seb128> work in progress would suggest someone is doing the work
<dholbach> seb128, not comment status, but merge proposal status
<seb128> right
<dholbach> right now I only check for "Needs Review" because LP can give me that easily
<seb128> but I take "Work in progress"  as "is being worked"
<dholbach> well
<dholbach> there's only "WIP", "merged", "needs review"
<ebroder> dholbach: What about removing a MP from the sponsor queue if there's a negative review from someone on ~ubuntu-dev? (Assuming you can look at just comments starting from the last time the MP was resubmitted)
<seb128> dholbach, no there is not
<seb128> there is "Needs Work"
<seb128> but the status is not available for some reason
<dholbach> seb128, I'm talking about the status right at the start of the page
<ebroder> seb128: It's at the very top of the page
<dholbach> that's what I call "merge proposal status"
<repete> persia, What is the default browser for Ubuntu on ARM?
<seb128> dholbach, right sorry, I'm being confused
<dholbach> ebroder, the problem is that subsequent reviews (maybe in a resubmitted proposal) might approve it again - it's a bit tricky
<seb128> that's "rejected" which is missing
<seb128> on https://code.launchpad.net/~dobey/ubuntu/natty/logilab-common/namespace-packages/+merge/43841 for example
<seb128> dholbach, I'm fine using wip to filter things out if you want
<seb128> we should just make clear it's the way to do it
<ebroder> dholbach: It might be useful to send mail to u-d or something so that people know that in general
<apw> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: apw, smoser`
<dholbach> if you think there's a better way (like find a way to parse if one of the last comments disapproves/needs-fixing, etc.), you could file a bug on https://launchpad.net/ubuntu-sponsoring/+filebug
<dholbach> or if we think that "Needs information" in terms of sponsoring bugs should be filtered out too, we can discuss that in the bug
<dholbach> (if that's intuitive enough)
<ebroder> No, I agree - I can't come up with a scheme that doesn't break down with multiple valid reviews
<seb128> dholbach, what about filtering out "Incomplete"?
<seb128> does that requires discussion?
<ebroder> seb128: Uh, I think the queue might need better detection of what the relevant bugtask is before we start doing that
<dholbach> ugh, yeah, ebroder's right
<ebroder> (It frequently picks the wrong one right now)
<dholbach> we should stop using bugs with patches altogether :)
<seb128> ok, so we should unsubscribe the sponsor and ask to subscribe them again when the issue are adressed?
<dholbach> but if it's just one ubuntu task it should be easy
<dholbach> I'll file a bug about that one
<ebroder> seb128: Yes, for bugs definitely unsub sponsors if you ask them to fix something, and tell them to resub when they're done
<ebroder> dholbach: LP doesn't always get the right bug component for linked branches, either :-P
<dholbach> and for the merge proposals we could do something like define a bunch of bad_statuses (disapprove, needs work, needs info, etc.) and see if those are the last comments that were added
<dholbach> ebroder, then we can drop the code for bugs and just do merge proposals ;-)
<ebroder> dholbach: Check out the bugtask LP chose for https://code.launchpad.net/~broder/ubuntu/lucid/update-inetd/fix-601732/+merge/40737, though
<seb128> one other issues is that some merge proposed are not listed
<seb128> but I'm not sure how to fix that
<dholbach> seb128, which one?
<seb128> like desktop ones
<seb128> because we don'tuse lp:ubuntu
<seb128> but a team vcs
<seb128> so the mp are for the ubuntu archive
<seb128> but it's not trivial to make the difference between those and a random vcs merge proposal
<seb128> I guess that's what we get for using a team vcs :p
<dholbach> yeah, shame on you
<dholbach> bug 690998
<ubottu> Launchpad bug 690998 in ubuntu-sponsoring "if bug has one Ubuntu task and its status is "Incomplete", filter out" [Undecided,New] https://launchpad.net/bugs/690998
<seb128> we would need a way to say "if the merge proposal is against the official vcs"
<dholbach> bug 691000
<ubottu> Launchpad bug 691000 in ubuntu-sponsoring "if last comment on merge proposal is a review statement, filter out" [Undecided,New] https://launchpad.net/bugs/691000
<dholbach> that's at least bug reports - I can't promise I'll get to it soon :)
<ebroder> dholbach: Looks good. Thanks
<repete> davidm, you still working?
<repete> davidm, or just not signed out?
<seb128> dholbach, so set the status to wip would filter things out already?
<seb128> or is that something that need to be added to the code?
<dholbach> seb128, no, it should do the trick
<seb128> dholbach, thanks
<dholbach> seb128, de rien mon ami
<tkamppeter> I want to overtake a package from Debian without any Ubuntu changes, how do I do a new package introduction and sync at the same time? It is http://packages.debian.org/source/sid/pyppd.
<seb128> tkamppeter, new sources are regularly synced from debian
<tkamppeter> seb128, how long will that take? Some weeks ago the pyppd package was added to Debian unstable and now I need it to be able to build foomatic-db in sync with Debian.
<tkamppeter> pitti, hi
<seb128> tkamppeter, he's on holidays until end of year
<seb128> tkamppeter, not sure about syncs, cjwatson used to do those almost daily
<bdrung> kees: thanks for taking care of the sudo issue
<tkamppeter> seb128, thanks.
<tkamppeter> cjwatson, hi
<seb128> tkamppeter, you can open a sync request bug if you are blocked on it
<seb128> tkamppeter, I can sync that one for you now
<AnAnt> would someone sponsor this merge: LP #691009 ?
<ubottu> Launchpad bug 691009 in texlive-extra (Ubuntu) "Candidate revision texlive-extra 2009-10ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/691009
<seb128> AnAnt, you can try pinging the current patch pilot, see topic
<AnAnt> apw: ping ^
<AnAnt> smoser: ping ^
<AnAnt> seb128: thanks
<seb128> you're welcome
<apw> AnAnt, hiya
<AnAnt> apw: would you sponsor this merge: LP #691009 ?
<ubottu> Launchpad bug 691009 in texlive-extra (Ubuntu) "Candidate revision texlive-extra 2009-10ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/691009
<apw> AnAnt, i will look it over in a sec ... thanks for the pointer
<AnAnt> apw: thanks
<AnAnt> be back in few mins
<tkamppeter> seb128, would be great if you could sync pyppd for me. I do not find any instructions for importing from Debian or for sync requests in the Wiki.
<seb128> tkamppeter, https://wiki.ubuntu.com/SyncRequestProcess
<AnAnt> back
<tkamppeter> seb128, thanks for the link. When the package is not yet in Ubuntu, to which package assign the sync request? Or can you simply sync pyppd for me?
<seb128> tkamppeter, in those case assign to no package
<seb128> I can but I would like to check with cjwatson if he's going to do a new-source run before
<tkamppeter> seb128, OK, thanks.
<cdbs> BlackZ: Just saw your mail, so this means that we should avoid upgrading to *ubuntu1 of sudo?
<BlackZ> cdbs: there's another version with the workaround, so yeah. But I think you will upgrade to the version with the workaround instead as it's in the archive now
<sebner> BlackZ: ehm, how should I apply the workaround as I can't open the file with root rights? Â¬_Â¬
<BlackZ> sebner: you might try with a live CD?
<sebner> BlackZ: well, I guessed so far. No easier solution?
<DrKranz> sebner: try passing single to grub
<sebner> DrKranz: \o/
<DrKranz> don't know whether it works or not, though
<DrKranz> sebner: if everything fails, format C:\^W^Wreinstall :)
<sebner> DrKranz: pfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff :P
<BlackZ> sebner: or with rescue mode or something like that (if you have that available)
 * sebner reboots and sees if the magic happens
 * sebner hugs DrKranz 
<DrKranz> worked?
<sebner> DrKranz: yeah
<DrKranz> nice
<DrKranz> maybe adding that as a workaround could help
<cjwatson> tkamppeter: I'll sort it out
<cjwatson> sebner: ^-
<cjwatson> oops
<cjwatson> seb128: ^-
<sebner> np
<cjwatson> tkamppeter: if by "some weeks ago" you mean "ten days", I suppose ...
<cjwatson> but yeah, I seem to have been slacking there ...
<seb128> cjwatson, thanks
<udienz> seb128: i choose to merge into natty
<udienz> seb128: but source branch already updated
<BlackZ> cjwatson: could you approve my e-mail sent to ubuntu-devel-announce@l.u.c ?
<udienz> seb128: i use bzr merge-package but last commit from lp:ubuntu/checkbox doesn't appear
<cjwatson> BlackZ: done.  Does user-setup need to change to put that bit somewhere else in future?
<BlackZ> cjwatson: thanks. I did some tests and I noted that. Is there a separate part for that on ubiquity?
<cjwatson> no.
<BlackZ> cjwatson: ok, then I'd say yes; AFAIK that's done by user-setup-apply
<cjwatson> BlackZ: please file a bug / add a bug task
<cjwatson> I can take care of the details, I just need to know where the configuration should go
<cjwatson> and I want a record of it in a bug so that I have it later
<BlackZ> cjwatson: I will add a bug task ASAP
<BlackZ> cjwatson: should I subscribe you to the bug report?
<apw> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smoser`
<cjwatson> BlackZ: no need
<cjwatson> thanks
<cjwatson> tkamppeter: sorted now, binaries will be available after the next full publisher run (so a bit over 1.5 hours)
<ScottK> Does anyone know if pitti is expected to be around today?
<seb128> ScottK, he's away until the end of the year
<seb128> he might still read emails though he said to drop him an email if required
<ScottK> seb128: Thanks.  Do you know who's taking his place on SRU approvals?
<seb128> I don't think there is anything formal
<seb128> he did SRUs yesterday and he's not the only one in the team
<seb128> you can probably ping someone from ~ubuntu-sru if required
<ScottK> Thanks.  I will.
<seb128> jdong or slangasek or cjwatson
<ScottK> cjwatson: I've just filed Bug #691068 in preparation for exercising the point microversion update exception for KDE for the first time.  I'm going to be reviewing and uploading them starting shortly.  I was wondering if I could have permission to also do the accept once they are all uploaded.  KDE packages have a sequence they build in and I'd like to dribble them in in such a way as they don't flood the buildds.
<ubottu> Launchpad bug 691068 in oxygen-icons (Ubuntu Lucid) "SRU tracking bug for KDE 4.4.5/8 update in Lucid" [Undecided,New] https://launchpad.net/bugs/691068
<tkamppeter> cjwatson, thank you very much.
<cjwatson> ScottK: hm, I never accept my own uploads as a matter of policy - do they not have suitable build-depends?
<cjwatson> if you give me the sequence I would be happy to follow it
<ScottK> cjwatson: They do, but due to soyuz funkyness uploading all at once results in a lot of FTBFS that have to be retried.
<ScottK> OK.
<cjwatson> wow, that's crazy
<cjwatson> OK then ...
<ScottK> For lucid we can probably upload them in reverse order and not accept kde4libs until everything is depwait.  Then it should ~work.
<cjwatson> well, I'll be around for maybe seven hours yet
<ScottK> Unfortunately the wiki doesn't version attachements.  The current order for Natty is https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph.
<ScottK> OK.
<cjwatson> (except that I need to go and resupply on rewritable DVDs)
<ScottK> With the exception of meta-kde not being relevant for Lucid that should be approximately correct for Lucid.
 * cjwatson fails to understand the positioning of meta-kde in that graph
<cjwatson> (also it's kde4libs rather than kdelibs, right?)
<ScottK> Yes.
<ScottK> That hasn't changed, we just tend to know that one (the bzr packaging branches are under kdelibs)
<ScottK> cjwatson: I've started uploading, so you can start accepting.  As long as we don't get kde4libs in before everything hits depwait, order isn't terribly significant (we lost this feature later when we improved the packaging and I'd forgotten about it)
<cjwatson> ScottK: so I do the lot but kde4libs *last*?  seems counter-intuitive, but OK ...
<ScottK> cjwatson: There's an oddity of soyuz that it will fail a build if a build-dep is uninstallable (or something close to that), but if it isn't present in sufficent version will depwait.  Once it's in depwait, if the build-dep is uninstallable it just goes back to depwait.
<cjwatson> ah, gotcha
 * cjwatson accepts kdeplasma-addons to see how that goes
<cjwatson> tseliot: would something like http://paste.ubuntu.com/544440/ be OK for you?
<cjwatson> as a rough structure for a way to blacklist things from gfxpayload=keep based on whether they have the proprietary drivers installed
<mdeslaur> cyphermox: sorry for yesterday...do you still need my gconf file?
<cyphermox> mdeslaur, well, mostly just to know which one, but if you can tell me what it looked like when it failed it would help me test failure and resolution
<mdeslaur> cyphermox: I'll email it to you, hold on a sec
 * tseliot has a look at the patch
<cyphermox> mdeslaur, however, I do have the updated evolution-data-server ready in my PPA now, just want to test that your migration issue is really fixed... for the calendar stuff it is, I checked :)
<mdeslaur> cyphermox: well, I can't migrate a second time :(
<cyphermox> nah, that's fine, I'll try to reproduce the issue and force migration again
<cyphermox> I may still have a pre-migration backup
<mdeslaur> cyphermox: I don't know what old version of evo added the URI to gconf...it may have been older than maverick
<cyphermox> ok
<tseliot> cjwatson: it looks fine to me. I've noticed that you put a "v" at the beginning of the pci id (v10ded0298.*). Maybe I should have a look at your update-grub-gfxpayload script to see how it parses expressions in the blacklist file
<mdeslaur> cyphermox: have you managed to reproduce not being able to mark the junk folder as read?
<cyphermox> mdeslaur, can you remind me the bug number? I don't recall that one
<cjwatson> tseliot: it's vVENDORdDEVICEsvSUBVENDORsdSUBDEVICEbcBASECLASSscSUBCLASS
<cjwatson> with regex-matching
<cjwatson> ebroder did that bit
<mdeslaur> cyphermox: bug 690036
<ubottu> Launchpad bug 690036 in evolution (Ubuntu) "[natty] Cannot mark Junk folders as read anymore" [Low,Triaged] https://launchpad.net/bugs/690036
<tseliot> cjwatson: ok, I can definitely include your patch in my git branch and do the same for other drivers (nvidia-96, nvidia-173 and fglrx). Thanks
<cjwatson> tseliot: http://paste.ubuntu.com/544450/ is the core grub-gfxpayload-lists package
<cjwatson> tseliot: let's only blacklist cards when we know it's necessary though
<tseliot> cjwatson: it's good to see that it's documented in the code :)
<cjwatson> do you think this structure will meet our needs?
<cyphermox> mdeslaur, right now, I'm not successfully marking any folder as read
<tseliot> cjwatson: yes, of course but still it's good to know that, as our last resort, we can use a regex to blacklist all of the cards from the same vendor
<cjwatson> tseliot: oh, I missed a bit, you need to run update-grub-gfxpayload (if it exists) on removal as well
<cjwatson> prerm probably
<mdeslaur> cyphermox: oh! my other folders work
<cjwatson> are we right in the basic assumption that problems are often hardware-specific?
<cjwatson> it's very hard to say what the scope of the bugs are
<tseliot> cjwatson: right, whenever I update the initramfs would be fine. Maybe I should do it in Jockey too (in case the package is already installed but disabled)
<cyphermox> mdeslaur, wait, it works, but evo is not playing nice.
<cjwatson> tseliot: mm, in that case you'll need to move the blacklist file around ...
<cjwatson> update-grub-gfxpayload currently just picks up anything in /usr/share/grub-gfxpayload-lists/blacklist/
<cjwatson> do I need to be more selective there or something?
<tseliot> cjwatson: I can make it a slave link to an already existing alternative, as I already do with the module blacklist
<kirkland> kenvandine: howdy;  right clicks and menus are invisible for me in natty/unity ... ideas?
<kirkland> kenvandine: been that way for ~2 days now
<kirkland> kenvandine: works okay in gnome
<kenvandine> seb128, ^^
<kenvandine> i saw you guys talked about that, but i didn't follow it closely :)
<seb128> kirkland, there was several discussions about that since yesterday
<seb128> kirkland, do you know when it started exactly and what you upgraded before?
<seb128> we are trying to get a clue what happens
<seb128> neither unity or compiz changed recently
<kirkland> seb128: i think it started yesterday morning very early
<kirkland> seb128: i was without menus all day yesterday for sure
<seb128> can you check what was in your upgrade run before the issue started?
<dholbach> cjwatson, I filed bug 691102
<ubottu> Launchpad bug 691102 in linux (Ubuntu) "[kernel-key-gfxpayload] Boot leaves me with no means to login, etc.: black screen" [Undecided,New] https://launchpad.net/bugs/691102
<seb128> like copy your dpkg.log online?
<kirkland> seb128: might have started yesterday morning, or possibly late the night before
<cjwatson> dholbach: thanks
<kirkland> seb128: okay: pbget http://pastebin.com/chazt1e6 > /tmp/dpkg.log
<kirkland> seb128: it's very large (2M) so I used pbput/pbget, which compresses and uuencodes it before pastebin'ing it
<seb128> kirkland, hum ok, thanks
<tseliot> cjwatson: to answer your question, I think that would be flexible enough to do what we need
<cjwatson> tseliot: ok, good
<seb128> ok
<seb128> so people having menu issues
<seb128> could you try to downgrade to https://launchpad.net/ubuntu/+source/compiz/1:0.9.2.1+glibmainloop3-0ubuntu1
<seb128> and see if that fix those after a session restart?
<kirkland> seb128: okay, sure
<kirkland> seb128: btw, that same logfile ... http://paste.ubuntu.com/544454/
<kirkland> seb128: in case you didn't use pbget
<seb128> kirkland, thanks, I think we are ok with update logs, we got some
<seb128> including yours ;-)
<kirkland> seb128: okay, downgraded, logging out now
<seb128> ok
<kirkland> seb128: uh oh, that's way worse
<kirkland> seb128: now i don't have any launcher or anything
<seb128> unity --reset?
<hallyn_> kirkland: interesting, i think the pattern for me was that with the -9 kernel i got menus, and with -7 i didn't...
<hallyn_> maybe that was purely spurious :)
<kirkland_> seb128: ah, okay, unity --reset restored sanity
<kirkland_> seb128: and yes, now i have menus
<kirkland_> hallyn_: interesting;  what versions of compiz are you running?
<kirkland_> hallyn_: as downgrading that has improved matters for me
<hallyn_> kirkland_: whatever the latest was after the sudo upload last night :)
<kirkland_> hallyn_: heh, okay, me too
<hallyn_> kirkland_: btw, when you have a moment, opinion q on kvm
<kirkland_> hallyn_: hit me
<hallyn_> well, someone begged today to backport 0.12.5 to lucid.  Now, I'm pretty sure mahmoh has been pounding 0.12.5 on lucid for a month or two now, so while normally i'd say no, i'm wondering whether we should just do it
<kirkland_> hallyn_: where do they want it to land?
<kirkland_> hallyn_: i'd recommend ~ubuntu-virt's PPA for starters
<seb128> kirkland: thanks, you are the second to confirm that downgrading compiz fix it
<kirkland_> seb128: np;  thanks for the help
<kirkland_> hallyn_: that has long been the destination for mostly-stable backports of kvm
<kirkland_> hallyn_: see the kvm-84 backport for hardy
<kirkland_> hallyn_: we could also pursue lucid-backports
<hallyn_> kirkland_: i'll take a look at ~ubuntu-virt, thanks
<kirkland_> hallyn_: which has only a *slightly* wider audience, but involves significantly more work to push it there
<hallyn_> that does feel more comfortable
<kirkland_> hallyn_: yeah, i kinda like that ~ubuntu-virt is typically only found by people who really need/want it
<kirkland_> hallyn_: -backports is stumbled upon by all sorts of random users
<kirkland_> hallyn_: is there a known bug or feature in particular that people want out of 0.12.5?
<kirkland_> hallyn_: or just general stability?
<kirkland_> hallyn_: (like mahmoh and yourself, I'm pretty happy with 0.12.5)
<psusi> cjwatson: I noticed last night on natty that the plymouth screen looks terrible.  I think this is because of the gfx_keep_payload change in grub leaving plymouth running the screen in 640x480.  Any ideas on fixing that?  Seems like grub needs to use the correct resolution or not keep_payload.
<cjwatson> psusi: already improved in grub2 1.99~20101210-1ubuntu1
<cjwatson> (which should have been in the archive already, but failed to be because of launchpad librarian downtime - sorting that out now)
<psusi> oh goody... how? ;)
<cjwatson> grub now does vbe resolution autodetection as best it can
<psusi> ohh... nifty
<cjwatson> you should get the closest mode that's no larger than the preferred mode claimed by your vesa bios
<cjwatson> (sometimes the preferred mode is not in fact in the vbe mode list.  blame your bios manufacturers for that piece of genius)
<psusi> heh
<hallyn_> kirkland_: there were specific bugs he cited
<kirkland_> hallyn_: okay
<psusi> here's to hoping my bios correctly reads the edid info and reports that as the preferrred mode
<cjwatson> so it might still not look brilliant - my laptop has a 1280x800 panel but the closest resolution in vbe is 1024x768
<kirkland_> hallyn_: well for specific bugs with specific commits, we can obviously cherry pick and get an SRU out
<cjwatson> but it should be better than 640x480
<kirkland_> hallyn_: otherwise, just upload to ~ubuntu-virt
<cjwatson> some bioses don't manage to report decent edid, some do :-/
<kirkland_> hallyn_: i think that would be a real good idea, actually
<hallyn_> like virtio corrupting >1Tb disks
<kirkland_> hallyn_: oh.  well that's SRU material
<cjwatson> grub tries edid followed by the vbe flat panel extension, which is roughly the same logic used by xserver-xorg-video-vesa
<hallyn_> i beg to disagree about 'obviously cherry pick'  :)
<psusi> so since it isn't in the vbe mode table at all, it just isn't possible for grub to go to 1280x1024 right?  even if you set the config file up to use that resolution?
<cjwatson> correct, unfortunately
<hallyn_> when the code bse totally changes underneath you ...
<cjwatson> at least not without importing something equivalent to kernel modesetting
<hallyn_> yeah ill upload to ~ubuntu-virt
<psusi> blast
<kirkland_> hallyn_: okay, you're on ~ubuntu-virt now
<hallyn_> cool, thanks.  i'll see what i can do with that
<cjwatson> however, it would be fixable by a bios rev
<psusi> now... a side effect of the higher resolution is making the font used on the boot menu smaller isn't it?
<cjwatson> probably, I haven't looked much at that yet
<cjwatson> up to a certain point that's an improvement of course
<kirkland_> hallyn_: how many git commits are there between 0.12.3 and 0.12.5?
<cjwatson> it's a bit big and chunky on 640x480
<psusi> I think the last time I tried using the higher resolutions that happened because grub uses raster fonts, so it needs to load a larger raster font for higher resolutions or it is hard to read
<kirkland_> hallyn_: (you don't have to answer that question now, unless you have git in front of you)
<cjwatson> I'm not too desperately worried about that for the meantime
<kirkland_> hallyn_: you know, if it's a handful (maybe 10 or less?  i don't know ...)  we could consider grabbing the set and adding them to lucid's
<kirkland_> hallyn_: i suspect its a lot more than that
<psusi> for the meantime meaning testing during the development cycle?  or you would be ok going to release with hard to read boot menu?
<kirkland_> hallyn_: aliguori takes a lot of "stabilization" patches :-)
<cjwatson> the latter, TBH
<cjwatson> it doesn't seem hard to read on any hardware I have
<cjwatson> maybe if you have a 1920x1280 panel or something
<psusi> 1280x1024 makes the default font quite small ;)
<cjwatson> (or whatever it is)
<smb> cjwatson, Is it possible to have the "daily" lucid install images rebuild with the current updates kernel? There is bug 546091 which depends on the updated kernel being in the installer and the last build seems to have been Nov-24.
<ubottu> Launchpad bug 546091 in linux (Ubuntu) "10.04 Installer doesn't properly detect 9240 MegaRaid SAS Controlers " [Undecided,In progress] https://launchpad.net/bugs/546091
<psusi> but I suppose that is better than flickering or ugly plymouth screen
<hallyn_> kirkland_: unfortunately i don't have the tree in front of me, but i remember looking at what it would take to cherrypick some of those, and it was huge
<psusi> maybe I'll take a look at having grub switch to a larger font when it is using a higher resolution
<hallyn_> definately not LTS material - that is, cherry-picking would be more dangerous than taking the maveick version, imo
<cjwatson> psusi: if you want to, sure
<kirkland_> hallyn_: yeah, it was more a thought exercise
<cjwatson> smb: sure, give me a minute
<kirkland_> hallyn_: right, agreed
<kirkland_> hallyn_: "data corruption" though, is LTS material
<smb> cjwatson, no worries. thanks.
<kirkland_> hallyn_: even if it means asking aliguori for some assistance selecting the patches that need to be in the cherry pick
<hallyn_> kirkland_: > 1tb disk though
<hallyn_> hm
<hallyn_> kirkland_: maybe we shouldadd a 'wantSRU' tag to the ones we want to find some way to apply to lucid
<hallyn_> (so i can find them again all at once and amke notes)
<nemo> Anyone noticed unusually high memory usage in Xorg over time?  Seems to have become more severe with 10.10.   Trying to think of ways to debug it.
<psusi> now if I could find someone who knows about pulseaudio and how it is initialized to shed some light on why the login sound can start to play before pulseaudio is ready so it is cut off or not heard at all...
<nemo> Stays high if I quit all apps and killall nautilus.  I'm about to try binding in gdb again.
<nemo> Last time I tried this it locked up my machine hard (yes, completely).  Wondering if anyone might have any other ideas
<hallyn_> kirkland_: well, 95 commits between 0.12.3 and 0.12.5
<nemo> (my theory is that I can try dumping memory in gdb and examining contents for clues)
<kirkland_> hallyn_: yeah, that's huge;  too much for an SRU
<hallyn_> it's less than i thought it was :)
<nemo> top line after a killall of nautilus.   1239 root      20   0 1625m 893m  86m S    3 23.3   2115:22 Xorg
<kirkland_> hallyn_: tags are good, yeah
<hallyn_> all right, back in a flash - i need to sync my U1 befor my trip, or i'm in bad shape next week
<kirkland_> hallyn_: at least when aliguori was running ubuntu a lot, he'd poke me when he saw a mission critical stable commit come across, that he thought we'd want to SRU
<kirkland_> hallyn_: word, thanks.
<kirkland_> hallyn_: you can probably just take mahmoh's 0.12.5, update the version appending a ~ppa1 on it, and dput to the ~ubuntu-virt ppa
<hallyn_> kirkland_: ok, cool.  so first i'll do the ppa, then i'll just try to cherrypick the critical ones and talk to aliguori if i must.  (tbh my impression had been that he really was not interested in helping with that, but i'll see)
<cjwatson> smb: wait.  that bug is claimed to be fixed in linux 2.6.32-26.47.  the installer on the current lucid CDs was built against linux 2.6.32-26.47.  what difference would rebuilding make?
<kirkland_> hallyn_: let's take him out for a beer :-)
<hallyn_> some vodka diplomacy
<seb128> could someone binNEW gdk-pixbuf girs to main for me? it's blocking the gtk rebuilds for the gir transition
<seb128> (I don't want to NEW my own upload but it should be trivial)
<smb> cjwatson, Hm in that case none. I assumed they were build before. I'll need to check closer then. Sorry for the noise
<tkamppeter> cjwatson, seb128, I have posted a MIR for pyppd now (bug #691133). Should I already modify foomatic-db to build-depend on pyppd? Or have I to wait for the MIR being approved?
<ubottu> Launchpad bug 691133 in pyppd (Ubuntu) "[MIR] pyppd" [Undecided,New] https://launchpad.net/bugs/691133
<seb128> tkamppeter, better to wait for the mir to be approved or you will break installations
<seb128> jdstrand, there?
<jdstrand> seb128: ?
<seb128> "could someone binNEW gdk-pixbuf girs to main for me? it's blocking the gtk rebuilds for the gir transition
<seb128>  (I don't want to NEW my own upload but it should be trivial)"
<jdstrand> seb128: sure, I'll take care of it
<seb128> jdstrand, ^ sorry to direct ping, I just would like to catch the next publisher run
<jdstrand> np
<seb128> I want to get that transition through today and we still need to build gtk and then other things after gkt
<seb128> gtk
<seb128> jdstrand, thanks!
<kibibyte> hi
<kibibyte> why ubuntu package maintainers doesnt create any libreoffice package
<seb128> kibibyte, hey
<seb128> because it's quite some work and nobody had time for it
<ion> kibibyte: Feel free to contribute.
<seb128> but if you want to work on that you are welcome to do it
<jdstrand> seb128: I see a gir gconf and gir json-glib too. also needed?
<seb128> jdstrand, yes
<seb128> jdstrand, to main please
<seb128> jdstrand, thanks ;-)
<jdstrand> sure
<jdstrand> working on it now
<kibibyte> but seb128 then whu you fixing shitty openoffice instead of drop it and take care of libreoffice
<seb128> kibibyte, there is nobody working on openoffice either
<seb128> kibibyte, there is an open position at Canonical for it though
<seb128> kibibyte, you are welcome to apply if you are interested
<kibibyte> is it remote?
<kibibyte> based
<seb128> yes
<kibibyte> hm
<cjwatson> I'd recommend a more constructive approach than "shitty" though!
<jdstrand> heh
 * jdstrand is still chuckling
<zul> can someone accept tftp-hpa into proposed for me?
<ScottK> cjwatson: There's another 7 in the queue when you have a moment.
<cjwatson> oh yeah, sorry, too many things going on at once
<jdstrand> seb128: accepted json-glib, gconf, and gdk-pixbuf to main
<seb128> jdstrand, thanks a bunch
<seb128> on time for the publisher run ;-)
<jdstrand> seb128: sure! :)
<kibibyte> is it har to create package for libreoffice?
<kibibyte> hard
<kibibyte> i just did once simple package
<jdstrand> I think that Canonical having a dedicated position for packaging and maintaining openoffice.org is an indication it is non-trivial
<jdstrand> put another way. yes
<highvoltage> kibibyte: doing any kind of decent libreoffice packages is a lot of work
<cjwatson> without wishing to disparage any other package, openoffice.org is probably the single most complex package in the archive
 * jdstrand unfondly remembers oo.o security updates :)
<cjwatson> how much that simplifies with libreoffice, I'm not certain; there are packages in Debian experimental
<joaopinto> hey, that teasing someone to quit a job to package oo :P
<cjwatson> ScottK: FAILED: kdepim (The source kdepim - 4:4.4.8-0ubuntu1 is already accepted in ubuntu/natty and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.)
<ScottK> cjwatson: Thanks. Sorry about that.  Please reject kdepim-runtime as well.
<cjwatson> done
<ScottK> cjwatson: Both reuploaded.  Those should be the only ones at risk for that kind of problem.
<hallyn_> kirkland: hye, i tried pushing vmbiulder using 'bzr merge-upstream' like you suggested, but got:
<hallyn_> bzr: ERROR: Merge upstream in merge mode is not yet supported.
<kirkland> hallyn_: doh
<kirkland> hallyn_: might need to chat with james_w, jelmer, or #bzr
<hallyn_> i'll try #bzr, thanks
<glicks> hi
<dholbach> apw, seems like the texlive-extra build failed
<dholbach> http://launchpadlibrarian.net/60746119/buildlog_ubuntu-natty-i386.texlive-extra_2009-10ubuntu1_FAILEDTOBUILD.txt.gz
<dholbach> (something to do with pkgstripfiles)
<glicks> hi, i was wondering, is there something like YaST2 available for Ubuntu that allows easy starting, stoping, configuration, and scheduling of services from a easy GUI?
<glicks> and if not is that something that might be in the works
<glicks> or is that a suggestin i can make
<hallyn_> kirkland: all right, seems what we wanted is not quite possible
<kirkland> hallyn_: vmbuilder, you mean?
<hallyn_> dholbach: james_w: hi, I was wondering what exactly woudl be involved in my geting upload rights for the vmbuilder project?  :)
<hallyn_> kirkland: yeah
<glicks> anyone?
<hallyn_> kirkland: final answer was that all I can do is build te source package and upload it (like we did last time)
<dholbach> hallyn_, https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage
<hallyn_> dholbach: thanks
<dholbach> de nada
<hallyn_> (i thought iw as looking at that page yesterday, but somehow missed the per-package section)
<kirkland> hallyn_: alrighty then ... bummer.  we'll play by thems rules
<hallyn_> zul: would you mind sponsoring people.c.c/~serge/vm-builder-461.tgz ?  (contains the source package)
<glicks> are there any plans for an ubuntu GUI based services manager/configurator?
<glicks> sort of like yast2 on suse?
<zul> hallyn_: sure as soon as lunch is done
<hallyn_> zul: thanks!  i'll owe you a red bull in dallas :)
<charlie-tca__> glicks: I don't know yast2, but as a suggested improvement, that might be better presented on brainstorm - http://brainstorm.ubuntu.com/
<glicks> i see charlie-tca__ thanks.  I think a yast2 like interface would add alot of polish to ubuntu, basically its a interface to configure, schedule, start and stop system services and firewalls from a nice easy GUI
<charlie-tca__> um, that might be ufw
<james_w> glicks, there was a GSoC project for the services part this summer
<glicks> GSoC?
<jelmer> Google Summer of Code
<glicks> oh google
<glicks> yeah
<glicks> hmm
<james_w> https://launchpad.net/jobsadmin
<james_w> apt-get install jobs-admin
<maxb> mvo: Hi, around? I just tried a maverick->natty update-manager upgrade, and it died because it didn't disable ppa.launchpad.net sources in my sources.list
<mvo> maxb: I'm about to leave for dinner, but could you please mail me the logs in /var/log/dist-upgrade/* ? I have a look then
<maxb> mvo: Actually, I suck, I'd forgotten about an /etc/update-manager/release-upgrades.d/allow-third-party.cfg left over from lucid->maverick
<mvo> maxb: ok, no worries
<lool> Is there a place where ddebs.ubuntu.com issues are typically tracked?
<lool> e.g. missing packages, or bugs
<ScottK> cjwatson: Everything execpt kde4libs and oxygen-icons (which doesn't depend on anything else and can be accepted anytime) is done.  I'd appreciate it if you could take another pass at accepting.
<hallyn_> kirkland: ok, so the menu thing is just random.  i just rebooted, and now have no menus
<micahg> ari-tczew: re webkit merge, does the version currently in natty still build?  If so, try disabling the new Debian patches to see if it builds then
<hallyn_> cjwatson: ^
<ari-tczew> micahg: current also ftbfs
<zul> hallyn_: done
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<cjwatson> hallyn_: hmm?  I haven't been following this.  (also, off to dinner now)
<kirkland> hallyn_: you're looking for seb128
<kirkland> hallyn_: he's gone, though
<hallyn_> zul: thanks!
<hallyn_> cjwatson: oops, sorry
<hallyn_> i scrolled up and apparently misread :)
<micahg> ari-tczew: re: webkit, looks like there's a gir transition in progress, can you attach a branch to that bug with what you have from the merge, I can try to take a look later if no one else gets to it first
<ari-tczew> micahg: branch attached a few minutes ago. it looks like I'm reading in your brain but my reaction is faster ;-)
<micahg> ari-tczew: heh, ok, thanks
<kees> cjwatson: say, any thoughts on bug 690030 ? I don't even know where to begin to debug it.
<ubottu> Launchpad bug 690030 in grub2 (Ubuntu) "fails to read disk partitions" [Undecided,New] https://launchpad.net/bugs/690030
<smoser> @pilot out smoser`
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<smoser`> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<kirkland> hallyn_: i just dist-upgraded to natty, held my breath, rebooted, and i'm up and running with a functional unity desktop again
<dwalker> hi everyone, not sure if this is the right chan to post this question, but I'm looking into preseeding a server install from (https://help.ubuntu.com/10.04/installation-guide/hppa/preseed-using.html) and the first paragraph says to look at the developers' documentation for debian-installer.  I've scoured for a while not able to find it.  Anyone know where the docs for it are located?
<ScottK> cjwatson: I had to reupload kdebindings and kdebase due to forgetting to include the tarball.  They are waiting for you ....
<hallyn_> kirkland: jinkeys!  you were having that trouble in maverick?
<kirkland> hallyn_: no ...
<kirkland> hallyn_: natty
<hallyn_> 'dist-upgraded to natty' ?
<kirkland> hallyn_: dist-upgraded to latest natty
<hallyn_> oh :)
<kirkland> hallyn_: from slightly less than latest natty
<hallyn_> well, give it a few reboots :)
<hallyn_> i thought i was past the menu thinguntil this lastest boot
<cjwatson> dwalker: apt-get install debian-installer
<cjwatson> kees: ok, I'll look in a bit
<dwalker> cjwatson: i'm really looking for a guide on what all the d-i options are for preseeding
<cjwatson> dwalker: the useful ones should all be in the installation-guide
<cjwatson> there are lots of internal ones - a full dump would confuse more than help
<dwalker> the installation-guide seems a bit sparse when it comes to all the partman-auto settings, is there a more drilled down guide on those?  I've been scouring the net for examples and got most of what I need, but the partman recipes are a bruiser
<cjwatson> dwalker: yes, /usr/share/doc/debian-installer/devel/partman-auto-recipe.txt.gz in the debian-installer package
<cjwatson> ScottK: done all but kde4libs - let me know when it's safe to accept that?
<dwalker> score
<cjwatson> kees: tell me (or the bug) about the disk layout on this system?
<ScottK> cjwatson: Thanks.  If you'd please rescore kdebase and kdebindings so they can jump the queue on get to depwait on powerpc, that would move things along (sorry about the need for the double upload).
<cjwatson> sorry, being called away to deal with toddler
<cjwatson> in an urgent tone of voice
<ScottK> Understand.  Good luck.
<ScottK> doko or NCommander: Would you please rescore kdebindings and kdebase since cjwatson's been called away (this is on Lucid).
<ScottK> Nevermind.
<ScottK> They're coming up faster than I thought.
<ScottK> cjwatson: I found one more that I'd missed the orig.tar.gz on and had to re-upload (kdeutils).  Please accept that one when the toddler situation permits.
<micahg> ScottK: are there any plans to SRU KDE point releases in maverick as well?
<ScottK> micahg: Yes.
<micahg> ScottK: cool
<ScottK> Probably not until after the last one though.
<micahg> ScottK: you mean until 4.5.x is EOL?
<ScottK> micahg: Normally KDE does 4 or 5 point updates and moves on.
<micahg> ScottK: so, not incremental updates, just one final update
<ScottK> IIRC 4.5.4 just come out.
<ScottK> We'll package all the intermin versions in ~kubuntu-ppa for testing.
<ScottK> interim ....
<micahg> ScottK: I assume that PPA is fairly stable then?
<ScottK> Mostly.
<micahg> ok, maybe I'll just add that then
<ScottK> We at least smoke test them before putting them in the PPAs.
<ScottK> Testing feedback is useful.
<dwalker_> cjwatson: not sure if your good with the partman stuff in the debian-installer but is there a way to create a recipe for it that defines partitions on different disks?  All the examples in the documentation are really suited for 1 drive, or doing RAID over multiple disks.  Not much of a use /dev/sda for /, and /boot, but /dev/sdb for /home
<Shayon> Hi I am wondering what programming laguages are required or one should know in order to start developing . I know it depends on personal preference and interest . But right now I am just a student (freshmen) and looking for some guidance :P
<nemo> Shayon: personally I think people learning to develop should start with a high level intepreted language or a low level language like C
<Shayon> nemo, i see. thanks :)
<Shayon> i started with c++
<nemo> ah
<nemo> IMO that's a rough place to start
<nemo> C++ is rather complex
<Shayon> then you mean c /?
<dwalker_> though it seems like many colleges are teaching either java or c++ as the intro languages
<Shayon> i guess java is def. hig end
<nemo> dwalker_: I'd say java is a better intro language
<nemo> dwalker_: fewer surprises
<Shayon> not*
<nemo> dwalker_: we started with C at my college. although I understand they have switched to java now
<dwalker_> nemo: meh, I'm self taught C when I was 12, I figure if you can't learn it yourself it's a long uphill battle.
<nemo> but I think just for learning, oh, data structures and whatnot, hell, you could start with javasciprt
<nemo> now that javascript has types
<Shayon> dwalker_, 12 ? Well thats sweet :)
<nemo> dwalker_: mm. my first language was pascal - mom shipped me off to local community college when my bro was 9 and I was 10
<nemo> we struggled
<nemo> dwalker_: I self-taught visual basic
<nemo> er
<nemo> basic
<nemo> there was no visual back then :)
<nemo> I still have some of my programs from when I was a kid :)
<dwalker_> ummm pascal
<nemo> dwalker_: I use it a lot today, amusingly
<nemo> on Hedgewars
<dwalker_> I've recently gotten a haskell fettish developing.
 * xnox javascript self-taught grasshops at 11
 * xnox later pascal at a CS after-school club at 16
<xnox> dwalker[afk], hmmmm I want to try Haskell one day  =) my last fettish was ObjC
<ScottK> nemo: For Ubuntu development C, Python, and C++ are probably the most useful.
<nemo> dwalker[afk]: hedgewars also uses haskell :)
<nemo> dwalker[afk]: server is haskell, engine is pascal
<nemo> ScottK: well. Python satisfies "high level" and C "low level"  - I just would not suggest people start with C++
<nemo> they might get some odd ideas
<ScottK> Depends.  If you want to develop for KDE, the C ideas are the odd ones.
<nemo> Qt is not exactly C++ either :)
<nemo> ScottK: I'm just saying the advantage of C is you learn 'sactly what is doing what in a computer
<nemo> and high level, you get to focus on language concepts
<nemo> but C++ is just an odd mix
<udienz> doco: i send review request at bugs 514401
<ubottu> Launchpad bug 514401 in Ubuntu Translations "Translations are not loaded for the test descriptions in Checkbox" [High,Triaged] https://launchpad.net/bugs/514401
<udienz> thankss before
<hallyn_> kirkuh,yeah.  so i updated my natty netbook, and now have no termcap entries :)  i have to ctrl-m instead of return
<hallyn_> kirkland: ^ and no tab apparently either :)
<hallyn_> neat thing is byobu can't update the status line the right way, so status keeps jumping another line up every second
<hallyn_> well this just won't do
<kees> cjwatson: bug updated. thanks!
<kirkland> hallyn_: wait, what?  huh?
<hallyn_> kirkland: http://pastebin.com/jepjqs0B
<hallyn_> seems to be *** VTE ***: Failed to load terminal capabilities from '/etc/termcap'
<hallyn_> thta is, seems to show up once in awhile in launchpad
<hallyn_> kirkland: you've still got menus?
<hallyn_> dist-upgrade+reboot, but still no menus here
<tumbleweed> seb128: bug 685584, can you enumerate the tweaks required? (The patch since your comment looks fine to me)
<ubottu> Launchpad bug 685584 in amule (Ubuntu) "amule FTBFS with gcc 4.5" [Low,In progress] https://launchpad.net/bugs/685584
<seb128> tumbleweed, it is, you can sponsor if you want
<seb128> the update just came after the end of my work day
<tumbleweed> seb128: aah, you weren't subscribed so I assumed you weren't following it
<tumbleweed> uploaded
<seb128> tumbleweed, thanks
<ari-tczew> tumbleweed: I guess that you have less to do in SQ this cycle :>
<tumbleweed> ari-tczew: the queue is in fantastic shape :)
<ScottK> cjwatson: Whenever you can take another pass at lucid-proposed, just go ahead and accept kde4libs and kdeutils at the same time.  Worst case I'll have a couple of retries to do.  Most likely it'll be just fine.  Thanks again.
<ari-tczew> tumbleweed: the most contributing people in maverick have been joined to motu in one time - bhavi, bilal and me :P
<ari-tczew> so you have nothing to do for us
<ari-tczew> ah, debfx also joined motu
<ari-tczew> and angelabad is coming
<cjwatson> dwalker_: unfortunately partman really isn't especially good at that yet.  I personally just use LVM in those situations - makes things much easier anyway.
<cjwatson> ScottK: meh, I should only have to wait a couple of minutes for kdeutils now so I might as well wait
<achiang> hello, i know that there are known issues with using usb-creator to create a Lucid USB stick while hosted on Maverick; are there issues in the other direction too?
<ScottK> cjwatson: OK.  Thanks.
<achiang> hosted on Lucid, and trying to create a maverick USB key?
<cjwatson> ScottK: (I assume you've seen the sparc failures)
<ScottK> cjwatson: Yes.  Those are expected.  KDE was totally broken on sparc at release and so this isn't a regression.
 * cjwatson nods
<dwalker_> cjwatson: yeah I caught that in some site 8000 searches later that partman can't do multiple disks for preseed
<cjwatson> I do kind of intend to fix that at some point, but ...
<PetrHH> Hello, I'd like to use mysql embedded in my app and want to store database to user's directory but apparmor privets me in it. Strange is, that ~/tmp is accessible but when I create directory e.g. ~/abc, it is not. Where could be a problem, please?
<ScottK> PetrHH: You might look at what the amarok package does.  AFAIK it uses mysqle.
<cjwatson> ScottK: build dominoes should be starting now.  (only amd64+i386 have so far dep-waited kdeutils, but the rest should finish well before kde4libs builds and publishes and renders stuff uninstallable.  besides, I'm bored of waiting. :-) )
<ScottK> cjwatson: Excellent.  Thank very much for taking care of it.
<PetrHH> ScottK, I'm sorry I don't understand. Strange is that mysqld command works if I run it from ~/tmp and doesn't work when I run it from ~/abc. I double checked, directories has the same permission but apparmon won't allow mysqld to wok at ~/abc
<PetrHH> I don't know why. I didn't change anything in apparmor configuration. Even I don't know where and how.
<PetrHH> I have ubuntu 10.04
<jdstrand> PetrHH: what do you mean 'run from tmp'? you put it's database there?
<jdstrand> s/it's/its/
<PetrHH> jdstrand, Yes, just for testing
<jdstrand> PetrHH: yes, it will work in /tmp and not from $HOME. you can see the denied messages in dmesg
<jdstrand> PetrHH: you have to adjust the profile
<PetrHH> Here is the command: mysqld --defaults-file=`pwd`/my.cnf --default-storage-engine=MyISAM --datadir=`pwd` --socket=`pwd`/sock --skip-grant-tables --port=3334
<jdstrand> PetrHH: the apparmor profile that is
<PetrHH> jdstrand, but it works from ~/tmp
<PetrHH> but not from ~/abc
<jdstrand> PetrHH: yes
<jdstrand> that is consistent with the apparmor policy
<jdstrand> look at /etc/apparmor.d/usr.sbin.mysqld
<PetrHH> thank you
<PetrHH> ScottK, where I can find out it?
<ScottK> PetrHH: apt-get source akonadi.
<PetrHH> ScottK, thank you
<YokoZar> slangasek: any multiarch updates?
<YokoZar> slangasek: I'm getting asked to merge/update natty ia32-libs...
<xnox> No patch pilot.....  I'm failing to find info on how to request a package rebuild?!
<StevenK> xnox: Which package?
<xnox> anjuta-extras
<xnox> depends on older binutils that is already in natty. Rebuild makes it work.
<xnox> s / that / than /
<micahg> xnox: file a bug and attach a debdiff or create a branch is how to request one
<xnox> micahg, ok, i'll do that then.
<micahg> xnox: dch -R and describe the reason
<StevenK> I was just going to fix it
<StevenK> TBH :-)
<micahg> well, that works too
<micahg> xnox: ^^
<xnox> StevenK, please do that. I thought there was a script to generate $version+b1 and upload it
<xnox> but I'm not ubuntu-dev so it will be PITA to create branch, find sponsor, upload that.... =)
<StevenK> I can't think of one, of the top of my head
<micahg> xnox: dch -R is the scripts and a simple debdiff works
<micahg> oh, won't upload :-/
<xnox> StevenK, anjuta-extras is "synced from debian" although I think it should be managed by ~desktop-team, because anjuta is managed there.
<PetrHH> ScottK, I added rule to apparmor and it works. Thank you. I looked at akonadi and found out that mysqld binary is copied to mysqld-akonadi. I'm not sure that it is good idea. What happened when original mysqld is updated? But don;t know what is better. Copying mysqld or adding my own rule to usr.sbin.mysqld file.
<xnox> micahg, --bin-nmu is better =)
<micahg> xnox: we don't do those :P
<ScottK> PetrHH: jdstrand would be the one to discuss it with.
<ScottK> jdstrand: If we could get rid of mysql-akonadi that would be marvelous.
<jdstrand> mysqld-akonadi is currently configured to run unconfined
 * xnox recalls a vague discussion to use +b1 version string on "ubuntu-style 'binnmu' source upload, no change, just rebuild uploads"
<jdstrand> ScottK: I agree
<jdstrand> don't currently have the cycles
<jdstrand> PetrHH: ^
<micahg> xnox: nope, build1 for native/Debian or increment Ubuntu version
<xnox> micahg, that way it doesn't end up in the merge-o-matic next time around and continues to sync.
 * xnox might be wrong
<StevenK> It should continue to sync
<StevenK> It's just a changelog entry, and it doesn't matter if it dies in a fire
<jdstrand> PetrHH: in terms of security updates, should be fine because mysqld-akonadi would get updated
<jdstrand> PetrHH: bottom line-- if you can add the line to your apparmor profile, that is best
<xnox> StevenK, micahg =) ok learned something new.
<micahg> xnox: that's why it's better to use dch -R and not worry about what it should be
<xnox> So StevenK when can I $ sudo aptitude update && sudo aptitude install anjuta-extras from my preffered mirror from Estonia?
<xnox> =))))))
<StevenK> A few hours, at least
<xnox> =(
<PetrHH> jdstrand, thank you very much, I'll do it. My app was designed to run from $HOME and now I'm working to package it so I must do a lot of changed. Thank you for patience.
<itachi> hello
<itachi> can you help me??
<d_ed> !ask | itachi
<ubottu> itachi: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<itachi> i wanna to install beowulf clustering without hard disk. but i dont know what services i chould install
<micahg> itachi: that's probably a question for #ubuntu-server
<bdrung> \o/ sponsor queue is down to 25 items
<xnox> bdrung, https://code.launchpad.net/~dmitrij.ledkov/ubuntu/natty/htmldoc/fix-ftbfs/+merge/43393 sponsor comments fixed. Please review and upload? =)
<bdrung> xnox: from d/changelog "Trying to fix"?
<xnox> hmmmmm
<xnox> bzr revert did too much =)
 * xnox damn it
<bdrung> xnox: enough reviewed for today. :P
<xnox> =))))
<micahg> xnox: why are you adding autoreconf, is that required with your change?
<xnox> micahg, yes
<xnox> micahg, New proposal https://code.launchpad.net/~dmitrij.ledkov/ubuntu/natty/htmldoc/fix-ftbfs/+merge/43994
<xnox> cleaned-up version =)
<xnox> diff is being generated.
<micahg> xnox: sorry, I can't upload though :)
<xnox> micahg, =)))) if you understand firefox you should be granted full upload rights ;-)
<xnox> to *everything*
<xnox> =)
<micahg> xnox: I highly disagree :)
<xnox> alright then =)
<xnox> micahg, + AC_CHECK_LIB(X11,XCreateBitmapFromData) in configure.in needs regenerating configure scripts =) meh
<micahg> xnox: ah, but why is that needed?
<xnox> Fix FTBFS because of --as-needed
<xnox> all three issues cause FTBFS
<xnox> (well make subdir makes fail was "hiding" one of the FTBFS by not erroring out)
<micahg> xnox: right, but adding to build-dep isn't enough, the build system needs to be patched (in Ubuntu)?
<xnox> micahg, yes! See doko announcing on -devel "Natty toolchain changes"
<micahg> nm, I'm still green WRT autoconf-foo
<xnox> libtool will now only link as-needed from what is supplied on the link line.
<xnox> if there is no -lX11 on the link line libtool will no longer "add it for you" in natty based on dependencies from dependencies.
<micahg> xnox: ah, and the AC_CHECK_LIB is the clean way to do that
<xnox> micahg, Consider libA <- libB <- libC. If app links against libA should it be automatically linked against libB and libC? If it uses symbols from libC but not from libB? That's what the change is about =) you have to ask to get libC.
<xnox> micahg, yes AC_CHECK_LIB is clean way to do that. But it is not the only way to do it.
<xnox> upstream seems to preffer AC_CHECK_LIB, I on the other hand preffer pkg-config.
<micahg> xnox: ok, yeah, I know about the linking requirements WRT needing to be explicit, but still unsure about where/how those fixes go
<xnox> micahg, easy =) ld tells you
<xnox> Linking htmldoc...
<xnox> /usr/bin/ld: gui.o: undefined reference to symbol 'XCreateBitmapFromData'
<xnox> /usr/bin/ld: note: 'XCreateBitmapFromData' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line
<xnox> /usr/lib/libX11.so.6: could not read symbols: Invalid operation
<xnox> collect2: ld returned 1 exit status
<micahg> xnox: right, I get that, but how to add the dependency is where I run into issues, I just need to read a little more I think
<xnox> micahg, http://bit.ly/eHLcbx <---- I read this every night before going to bed =)
<xnox> good night all
#ubuntu-devel 2010-12-17
<psusi> mdeslaur: I see you got lvm2 merged... do you have any idea what the hell upstream-2.02.72.patch is?  the debian devs don't seem to bother ever documenting their quilt patches and the bzr commit that introduced it is rather terse.  It sounds like it is a diff to go from upstream .66 to .72, but then why is it  a patch rather than a new .orig.tar.gz, and why is the rev of the package still .66 instead of .72?
<mdeslaur> psusi: let me take a look, hold on
<mdeslaur> psusi: yes, that's what it looks like to me too
<psusi> I've been trying to get that package updated for some time now and it's been a real pain trying to figure out these undocumented patches
<mdeslaur> psusi: I don't know why they didn't just update to .72...
<mdeslaur> oh, actually
<mdeslaur> psusi: it may just be a diff between .71 and .72
<mdeslaur> because that was a security fix
<psusi> ahhh
<mdeslaur> psusi: yeah, that's it...it's just the security fixes that were added for .72
<psusi> I had updated to .76 and have been running that locally for a few months, testing out the snapshot merge support, but pitti wanted to avoid further divergence from debian
<mdeslaur> psusi: maybe you could convince debian to go to .76 (or at least package that in experimental), then we could merge it
<floam> for a package like zoneminder where it seems like it's mostly from debian unstable, should I report enhancement-ey bugs to ubuntu or to debian or both?
<floam> (kinda late, already did it https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/691375 , but I'm trying to figure out the right way)
<ubottu> Ubuntu bug 691375 in zoneminder (Ubuntu) "Please compile with --enable--mmap=yes" [Undecided,New]
<RAOF> floam: From the bug title it sounds like it also affects Debian, so filing a Debian bug (and linking it to the Launchpad bug) is a good idea.
<floam> RAOF: thanks, will do
<gs> i am a computer undergraduate and i want to contribute for ubuntu
<gs> i need some guidance regarding how to start working for ubuntu development
<RAOF> gs: So, what sort of thing are you interested in doing?
<gs> i am interested in working on projects using c/c++
<gs> i am also familiar with python
<RAOF> So, almost all of the work involved in Ubuntu is done upstream; if you want to code, then picking a project and fixing something you find annoying that it doesn't do correctly is a good way to start.
<gs> so i should work for debugging ??
<RAOF> There are also a bunch of Debian/Ubuntu projects, many of which use Python (software-centre, apport, etc) or C/C++ (unity, upstart, apt)
<RAOF> There's a huge amount to do; you can do whatever you want âº
<achiang> gs: the idea is to "scratch your own itch" -- find something in existing software today that makes you unhappy and fix it.
<gs> actually sir i am interested in participating in gsoc so i wanted to be familiar with open source development procedure.
<gs> RAOF : ok. so the idea is to take a source code and modify it according to my requirements
<RAOF> Pretty much, yeah.
<RAOF> If it's a simple change you do it first and then send a patch to the associated project (generally this is handled on mailing lists).
<RAOF> If it's a more complex change it can often be worth sending a message to the mailing list outlining what you propose to do.
<RAOF> Precisely what happens depends greatly on how the specific project is run.
<gs> RAOF: ok. that sounds pretty interesting
<gs> ok.
<RAOF> Of course, there's *also* the option of wandering through bug reports on Launchpad and fixing them :)
<gs> ok i will try that also
<RAOF> But for gsoc you'll (probably) be working with an upstream project, so that's what I'd pick.
<gs> ok ya i wanted to do something for that
<gs> sorry but what do you mean by an upstream project?
<RAOF> Almost all of the programs that make up Ubuntu aren't developed by us; they're developed by other people, each as their own separate project, and we do the integration work.
<RAOF> So, projects like the linux kernel, X.org, GNOME, etc are âupstreamâ of us.
<gs> ok so whats ubuntu ?
<RAOF> We do the integration work; we take the code that upstreams release, optionally make some Ubuntu-specific changes, and build packages which conform to the various Debian policies.
<gs> ok so i should start working for upstream projects rather than ubuntu
<rigved> gs: ubuntu is much easier to work with than debian
<gs> ok.
<RAOF> rigved: That depends; and it's pretty much moot if you want to do upstream coding anyway.
<gs> rigved : ok ya and i am ubuntu user so its a bit comfortable for me to work with ubuntu
<rigved> RAOF: what i meant was that it's easier to use it. but yes ubuntu has made many things easier and safer to customise, like grub2 for example
 * RAOF notes that our grub2 package is largely worked on *in* Debian :)
<RAOF> I'll agree that Ubuntu is easier to use, though :)
<rigved> RAOF: ok. well it's not there in lenny. maybe in squeeze. thanx for the info :)
<RAOF> rigved: Oh, yeah.  You don't get the shiny new toys in Debian stable!
<fargiolas> cjwatson: ping
<cdbs> Package wmii depends on  suckless-tools | dwm-tools. Package dwm-tools is NBS and replacement is suckless-tools. However, I still get http://people.canonical.com/~ubuntu-archive/NBS/dwm-tools . IMHO if a package has choice depends (|) and one of them if available, then the other should be considered free of reverse-depends
<cdbs> isn't it?
<micahg> cdbs: it was dropped in the latest update
<cdbs> micahg: In the latest update of what?
<micahg> cdbs: latest sync of suckless-tools from Debian
<cdbs> micahg: I know that. I am currectly talking about multiple possible depends, like: foo | bar | baz
<micahg> cdbs: I'm saying, that's why you get the NBS and yes, it's rdepends free if it's an alternative
<cdbs> micahg: package wmii depends on suckless-tools | dwm-tools , the former is a replacement of the latter, but still, it appears, that the script on people.canonical.com/~ubuntu-archive/NBS is taking it the wrong way
<cdbs> micahg: yes, that's what I mean
<micahg> cdbs: does that answer it sufficiently?
<cdbs> yes
<ebroder> cjwatson, tseliot: Apparently my IRC client has actually been bitbucketting traffic all day for me, so I missed the blacklist discussion until now. Please feel free to ping me if there's anything I can do to make the blacklists easier to manage
<jibel> JamesPage, ping
<JamesPage> jibel: pong
<jibel> JamesPage, Hey, I've made some good progress on desktop iso smoke test using the server team work.
<JamesPage> jibel: excellent; glad its been of use;
<JamesPage> jibel: any issues or nuances you need a had with?
<JamesPage> /had/hand/
<jibel> JamesPage, Not really, I've done a small set of changes to the main script to adapt it to the desktop
<jibel> JamesPage, and duplicated the templates directory.
<JamesPage> jibel: makes sense; it would be good if we could consolidate the code base into a single project
<JamesPage> jibel: maybe that would be a good objective to achieve during the platform rally in Jan
<jibel> JamesPage, I use a casper hook instead of a preseed to install ldtp and download a script from couchdb which I autostart when the Live session user log in
<jibel> JamesPage, I also had to increase memory and disk size, but basically that's all that needed to be changed.
<bdrung> ebroder: do we really need the complicated chroots detection for sbuild.update() ?
<JamesPage> jibel: sounds like we could easily consolidate then; I'd also like to abstract the tests from the rest of the code base;
<ebroder> bdrung: We don't if we assume mk-sbuild, but I'd prefer not to make that assumption
<JamesPage> jibel: so we can distribute a package for the code; but the test still come from a bzr branch
<JamesPage> jibel: means they can be updated every time the tests are run using Hudson
<ebroder> bdrung: sbuild-update and friends are really more schroot tools than sbuild. They take a chroot name. sbuild translates information about a target distribution and release into a chroot name using that logic (it's documented in sbuild(1))
<jibel> JamesPage, sure, it can be easily done.
<bdrung> ebroder: then i like to see the same translation logic in the sbuild-update and friends tools
<ebroder> bdrung: mk-sbuild always uses %(distribution)-%(arch), but I've inherited configurations in the past that use %(distribution)-%(arch)-sbuild
<jibel> JamesPage, I still have few bits to fix and I'll push my changes next week, then I'll need your review and help to integrate to hudson.
<ebroder> bdrung: I'll make a note to open a bug with the sbuild maintainer. He's usually friendly
<JamesPage> jibel: no problem
<bdrung> ebroder: thanks
<bdrung> ebroder: i'll fix sponsor-patch and merge your update-builder branch
<ebroder> bdrung: Fix sponsor-patch?
<ebroder> bdrung: Oh, that reminds me that I wanted to thank you for merging backportpackage, and also for pushing me on making the interface more flexible. I think that script has now completely replaced the functionality of 3+ simpler ones I've written in the past, not to mention innumerable hand-crafted shell loops
<bdrung> ebroder: the update logic in sponsor-patch doesn't work correctly - i'll fix that
<ebroder> bdrung: Ok, cool
<bdrung> ebroder: one feature request left for backportpackage: an environment variable for the upload destination (e.g. BACKPORTPACKAGE_UPLOAD)
<ebroder> bdrung: Oh, huh, that didn't make it to the todo list I was keeping. I'll add it back
 * tumbleweed really must get around to the environment variable / connfille thing
<tumbleweed> I thought I'd do that yesterday...
<bdrung> tumbleweed: my idea, add the environment variable to devscripts config file - and then parse the files too
<tumbleweed> bdrung: yeah, I like that idea
<tumbleweed> it'll mean some central config parsing code for the whole of u-d-t, which will make it harder for people to just stick one of the scripts in ~/bin
<ebroder> bdrung, tumbleweed: It would be kind of awesome if I could say something like ubuntutools.config.get_config('BUILDER') and it would check all of the permutations of os.environ[sys.argv[0].upper() + '_' + 'BUILDER'] and 'UBUNTUTOOLS_' + 'BUILDER' and so forth
<tumbleweed> ebroder: yes, that's my plan
<bdrung> tumbleweed: yes, and then putting the found variable into the environment
<ebroder> tumbleweed: We're already moving in that direction. There's a *lot* of duplicated code right now, and I don't think it's a bad thing if that duplicated code consolidated into Python modules, even if it costs us the ability to drop things into ~/bin
<tumbleweed> bdrung: yes and no, because you want the command line options to take precedence
<bdrung> tumbleweed: look at our code - we use the env variable as default and override it with command line options
<tumbleweed> bdrung: yes
 * bdrung have to go  to university now.
<bdrung> it's time to develop a compiler. :)
<tumbleweed> sounds like you found a more interesting thesis topic than I ended up with :P
<cdbs> heh
<cdbs> BTW, should I go ahead with adding a command-line arg --pbuilder-dist in sponsor-patch to force usage of pbuilder-dist DISTRIBUTIONHERE rather than DIST=DISTHERE pbuilder whatever ?
<tumbleweed> cdbs: no, I'd say pbuilder-dist should be supported as a Builder for u-d-t
<cdbs> tumbleweed: hmmm?
<cdbs> tumbleweed: so you mean all tools should support it?
<ebroder> cdbs: Check out the ubuntutools/builder.py module bdrung just merged in from me
<tumbleweed> cdbs: yes, there's a common builder abstraction in the ubuntutools package (in u-d-t)
<cdbs> I have a slightly older version
 * cdbs bzr pulls
<cdbs> ebroder: so it doesn't have pbuilder-dist support yet
<ebroder> cdbs: Correct, but it should be pretty trivial to add
<cdbs> ebroder: yup, should I add? or you are adding?
<ebroder> cdbs: I am not
 * cdbs gets working :D
<Keybuk> Admiral!  There be whales here!
<Keybuk> deathspank calendar% ./nexttime2 "MDAY=-1"
<Keybuk> Friday, 31 December 2010 00:00:00 GMT (+0000)
<Keybuk> deathspank calendar% ./nexttime2 "MWDAY=-1THU"
<Keybuk> Thursday, 30 December 2010 00:00:00 GMT (+0000)
<Keybuk> (time_t of the last day in the month, and last Thursday of the month, respectively)
<ev> \o/ well done
<cjwatson> fargiolas: yes?
<jhunt> apw: just so you know, my ppa rebuild for bug 683605 is due to start apparently in 7 hrs (!!! and will probably fail! :( )
<ubottu> Launchpad bug 683605 in util-linux (Ubuntu) "kernel hibernate signature has changed from S1SUSPEND to LINHIB0001" [High,Confirmed] https://launchpad.net/bugs/683605
<jhunt> apw: annoying since there appear to be 4x idle i386 disto build machines.
<apw> jhunt, can't you build it locally to test ?
<apw> jhunt, but yes mine are in the morass too
<StevenK> jhunt: The distro build machines are nothing like the ppa build machines ...
<jhunt> apw: I've built it on maverick, but will need to spend some time getting a local natty build env setup. lp guys thought the failures I was seeing might be natty related. I'll find out...
<jhunt> StevenK: we don't have xenmotion-type capabilities then?
<StevenK> jhunt: The distro buildds are real hardware. So, it doesn't work that way.
 * StevenK -> bed
<jhunt> ah, I thought on the ppa boxes atleast VMs were being used.
<cjwatson> yes, the PPA builds are in Xen
<cjwatson> they're deliberately isolated so that a malicious PPA can't break the distro buildds
<cjwatson> (or each other, for that matter)
<cjwatson> jhunt: you may have trouble anyway since the earlier version you had failed to upgrade
<jhunt> cjwatson: yeah, I'm struggling with this.
<cjwatson> jhunt: which means that if you try to build a later version of util-linux in the same archive, it'll try to upgrade itself first and fail
<cjwatson> jhunt: I'd recommend deleting the broken version from the archive first (you'll still need to use a later version number)
<cjwatson> this strategy doesn't work for the distro itself - if this sort of thing happens there, we need to recover manually.  it's happened a few times
<cjwatson> yeah, looks like that's what's happening.  deleting it then reuploading should help.
<jhunt> cjwatson: thx!
<cjwatson> (transitively) essential packages are such fun
<cjwatson> actually not even transitively in this case, it's just plain Essential
<AnAnt> Hello, please sponsor those merges: LP #691512 , LP #691448
<ubottu> Launchpad bug 691512 in mutt (Ubuntu) "Candidate revision mutt 1.5.21-1ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/691512
<ubottu> Launchpad bug 691448 in irssi (Ubuntu) "Candidate revision irssi 0.8.15-2ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/691448
<diwic> Not knowing bazaar enough is one of my weaknesses, so excuse me for a (probably) newbie question.
<diwic> If I do "apt-src install pulseaudio", it says:
<diwic> NOTICE: 'pulseaudio' packaging is maintained in the 'Bzr' version control system at:
<diwic> http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.natty
<diwic> Please use:
<diwic> bzr get http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.natty
<diwic> to retrieve the latest (possibly unreleased) updates to the package.
<diwic> But if I do that, I only get a "debian" subdirectory and not the upstream source.
<diwic> Given that workflow, how do I get original source?
<apw> diwic, does the packaging actually know how to get the source for you, sometimes you can debian/rules patch (or something similar)
<diwic> apw, hmm, I think I solved the problem as it seems like bzr-buildpackage seems to go get the source for me; although I don't know from where it got that pointer
<diwic> apw, but while you're listening, I'm not trying to push my branch with "bzr push bzr+ssh://bazaar..." but it asks for my canonical ssh key instead of a password
<apw> diwic, have you logged in ?
<apw> diwic, via bzr launchpad-login ?
<diwic> apw, "bzr launchpad-login diwic" just returns after a moment, I'm assuming it does what it should
<diwic> hmm
<diwic> maybe I need to add the ssh key to the launchpad account?
<apw> diwic, you need to have your ssh key in your account i think, the public part
<apw> diwic, but i thought you needed that in there for our internal infrastructure too
<diwic> apw, seems to have done it, thanks
<jdstrand> seb128: hi! with the patch you backed out of compiz, my login hangs...
<jdstrand> seb128: I think we can confirm this bug now ;)
<seb128> jdstrand, :-(
<seb128> jdstrand, can't win
<jdstrand> seb128: fwiw, I did see the menu bug too, but oddly only after a few hours
<seb128> njpatel, ^
<seb128> it's going to be no fun, either way we are screwed
<jdstrand> seb128: it there a bug for the stalled login?
<jdstrand> (I don't have a usable desktop atm)
<seb128> jdstrand, https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/690239
<ubottu> Ubuntu bug 690239 in glib2.0 (Ubuntu) "hang in g_spawn_sync and select()" [Undecided,New]
<njpatel> seb128, urgh :/
<seb128> jdstrand, starting the classic session doesn't work?
<jdstrand> seb128: thanks. and finally-- is there something I can poke from a vt to get things going again?
<seb128> jdstrand, are you sure compiz hangs?
<seb128> like the process is running but hanging?
<seb128> does ctrl-alt-right or left works?
<jdstrand> I don't know what is hanging-- I login and I get a spinning cursor
<apw> jdstrand, waht do you see? the background ?
<jdstrand> apw: I see the background
 * apw always recommends a windows-E to see if you get expose
<jdstrand> ctrl+alt+right and left does nothing
<apw> (likely not then)
<jdstrand> windows+E does nothing
<seb128> njpatel, is sam working today?
<apw> i think rtg was seeing that failure mode too ...
<seb128> jdstrand, here the classic session works
<jdstrand> all I have in ps related to compiz is compiz-decorator
<seb128> I had issue with the default one
<seb128> jdstrand, seems similar to what I was having yesterday
<jdstrand> seb128: well, right, I am kinda committed to the unity one since I blew away my gnome-panel gconf settings to run a small panel in unity
<jdstrand> I do have a backup of those though...
<seb128> jdstrand, well I can start the classic one, alt-f2, ccsm and activate unity
<seb128> then I've a working unity session
<seb128> the unity session in gdm is buggy in a way similar to what you get though
<jdstrand> I thought didrocks expressly told me to *not* use ccsm to activate unity :)
<seb128> I though that was maybe a local issue
<seb128> jdstrand, well didrocks is away until eoy
<seb128> I'm telling you what I did there
<seb128> if you want a workaround to get back a working desktop...
<jdstrand> hmm
<jdstrand> seb128: I am not being testy, just thought it funny I got different info
<jdstrand> :)
<seb128> jdstrand, oh I didn't take it wrongly don't worry ;-)
<seb128> I'm a bit annoyed by that compiz bug though
<jdstrand> yes, me too ;)
<seb128> it's being between a rock and an hard place
<seb128> we have no compiz guy around today
<seb128> then I'm on holiday as well until eoy
<seb128> sucks if that stay this way for the next 2 weeks
<jdstrand> well, I can downgrade compiz and live with the menus then
<seb128> well it's not only you
<seb128> but yeah, better menu issues than no desktop
<seb128> jdstrand, can you try to downgrade to -0ubuntu1
<jdstrand> that is way less painful than logging into classic, fiddling with my panel, starting unity, fiddling with my panel, etc
<seb128> see if you get the issue as well?
<seb128> jdstrand, why would you have to fiddle with those?
<seb128> the panel config should be the same
<seb128> ccsm and activate unity in your classic compiz config
<seb128> you can alt-f2 to run it
<jdstrand> I guess that's true
<seb128> that's what I did there
<seb128> the only difference between the sessions is the compiz plugin in use
<apw> jdstrand, is that the no menus appearing on right click and stuff dissappearing issue ?
<seb128> no
<seb128> that's the side effect of rolling back the patch which created the menu issue
<jdstrand> apw: I have nothing but a background. compiz didn't start
<jdstrand> though compiz-decorator did
<seb128> jdstrand, it's likely that compiz crashes
<seb128> it does there
<jdstrand> I suppose that's true about the gnome-panel-- I was thinking I need a working classic desktop. I do not
<jdstrand> s/working/fully functional/
<jdstrand> ok, going the classic route worked fine
<seb128> jdstrand, ok, thanks, same issue than me then
<jdstrand> seb128: I'm guessing since there are no compiz specialists around that there isn't a lot I can provide to help atm?
<jdstrand> I also wonder if the next time I login to classic, if unity will try to start and then crash again...
<jdstrand> seb128: do you still want me to try ubuntu1?
<seb128> jdstrand, can you clean /var/crash, log in an unity session and see if it crashes?
<jdstrand> yes
 * jdstrand goes to try
<mdeslaur> huh, indicator-sound isn't showing rhythmbox anymore
<jdstrand> seb128: ok. I accidently logged into classic desktop and was pleased to see compiz did *not* crash even though I had the unity plugin checked
<jdstrand> seb128: put to the point of your question
<seb128> jdstrand, ok, I've the same issue there then
<seb128> mdeslaur, try starting it once?
<jdstrand> seb128: I logged in, I saw the unity launcher for half a second, it went away and compiz did crash, leaving a crash file in /var/crash
<mdeslaur> seb128: nope, still not showing up
<jdstrand> mdeslaur: weird, but it did before? I know yesterday or possibly the day before it was still there
<mdeslaur> jdstrand: it worked fine until this morning updates and reboot
<jdstrand> s/put/but/
<jdstrand> seb128: that may not have all been clear. I accidentally logged into the classic desktop and it worked fine with unity (good). I then logged out, and back in with the unity desktop, saw the unity launcher for a moment, then compiz crashed with a crash file in /var/crash
<seb128> jdstrand, can you upload the .crash to launchpad?
<seb128> jdstrand, no, same than here, what I told you before
<jdstrand> seb128: k
<seb128> jdstrand, the unity session crashes but unity in a normal session works
<seb128> I'm not sure why
<jdstrand> seb128: apport-collect to a bug number or a new bug?
<seb128> mdeslaur, try asking ronoc on #ayatana
<mdeslaur> seb128: tanks
<mdeslaur> s/tanks/thanks
<seb128> jdstrand, new one, I couldn't submit mine because I've some other upgraded not done
<seb128> jdstrand, so if your box is uptodate...
<jdstrand> will do
<jdstrand> it is
<seb128> cjwatson (and pitti), thanks for the debconf libgnome cleaning ;-)
<cjwatson> no problem, that's 660KB or so cleared
<cjwatson> it's still not entirely free of deprecated interfaces, so may need further attention in future
<bdrung> ebroder: merged
<cjwatson> seb128: incidentally, do you read all of natty-changes or something? :)
<seb128> cjwatson, I do go through the titles at least
<seb128> ;-)
<seb128> I stopped on debconf because I was waiting on that part of the stack to be able to go away
<cjwatson> seb128: mvo's cleaning up the two remaining Recommends on it
<mvo> seb128: uploaded
<seb128> cjwatson, mvo: thanks ;-)
<mvo> yw
<doko> cjwatson: looking at http://launchpadlibrarian.net/60797448/buildlog_ubuntu-natty-i386.apturl_0.4.2ubuntu2_FAILEDTOBUILD.txt.gz
<cjwatson> huh, didn't change anything in that area
<cjwatson> ah, ok, python default change
<cjwatson> doko: I can fix it if you like
<doko> already doing
<cjwatson> ok
<jdstrand> seb128: bug #691561
<ubottu> Launchpad bug 691561 in compiz (Ubuntu) "compiz crash on login" [Undecided,New] https://launchpad.net/bugs/691561
<jdstrand> seb128: I had to do my own apport-retrace since the crash report wasn't formatted correctly (lacked 'Package: compiz')
<seb128> jdstrand, thanks
<seb128> njpatel, ^
<jdstrand> seb128: but it should be ok
<njpatel> looking
<seb128>  #1  0x00007f94bc80391d in UnityScreen::getWindowPaintList (this=<value optimized out>) at /build/buildd/unity-3.2.6/src/unity.cpp:246
<seb128>          pl = @0x12b8d50
<seb128>          xwns = @0x7fff5f672120
<seb128> njpatel, ^ is unity bog
<njpatel> well, it's a bad pointer
<njpatel> from nux!
<mvo> hm, how can it happen that we have a cups in maverick-updates that depends on "cups-ppdc" when the later is in universe?
<njpatel>  :)
<njpatel> mvo, !
<njpatel> mvo, how are you :
<njpatel> ?
<njpatel> even
 * njpatel can't type
<mvo> hey njpatel - good, thanks!
<mvo> and you?
<njpatel> good thanks, looking forward to the break :)
<mvo> me too :)
<njpatel> jej
<mvo> we have perfect winter weather, I will undust the sledge !
<njpatel> heh*
<mvo> lol
<mvo> you really can't type today ;)
<njpatel> mvo, no, which doesn't bode well for the unity release ;)
<mvo> lol !
<cjwatson> mvo: reminder about bug 671016, alpha-2-milestoned bug left over from last week's release meeting
<ubottu> Launchpad bug 671016 in update-manager (Ubuntu Natty) "EOL needs to be handled more elegantly" [High,In progress] https://launchpad.net/bugs/671016
<mvo> cjwatson: cups in maverick-updates depends on cups-ppdc but that is in universe for maverick. is it possible to promote it in maverick-updates? if not I think I should uplodate a new version with cups-ppdc as a recommends instead a depends
<mvo> cjwatson: EOL reminder> thanks
<Keybuk> jhunt: you're good at coming up with random calendar schedules, can you think of a few tests?
<jdstrand> mdeslaur: I can confirm rb is not in the sound indicator menu
<jdstrand> mdeslaur: do you have a bug?
<jhunt> Keybuk: how complex can we go here? Have we got knowledge of boot/resume times?
<bdrung> geser, Laney, jpds: requestsync owns 13 of 45 ubuntu-dev-tools bugs. you touched the script. can you have a look at the bugs? https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools?field.searchtext=requestsync
<Keybuk> jhunt: I think I've covered every reasonable complexity
<Keybuk> durations are easy - this is more of the "last sunday of the year" variety
<mdeslaur> jdstrand: bug 691556
<ubottu> Launchpad bug 691556 in rhythmbox (Ubuntu) "[natty] rhythmbox doesn't appear in indicator-sound menu anymore" [Undecided,New] https://launchpad.net/bugs/691556
<cjwatson> mvo: normally we wouldn't, but since it's changed in -updates anyway, and since it's in main in natty, I think it's safe enough to promote
<cjwatson> mvo: promoted, unless somebody screams at me really loudly
<Keybuk> deathspank calendar% ./nexttime2 -c 3 "WDAY=SUN;HOUR=4;MIN=30;INTERVAL=2"
<Keybuk> Sunday, 19 December 2010 04:30:00 GMT (+0000)
<Keybuk> Sunday,  2 January 2011 04:30:00 GMT (+0000)
<Keybuk> Sunday, 16 January 2011 04:30:00 GMT (+0000)
<Keybuk> --
<Keybuk> jhunt: e.g. every second sunday at 4:30am
<jhunt> Keybuk: how about... last weekday of this year / 2nd tuesday after easter / first friday 2 months + 3 days from now.
<Keybuk> can't do that first one
<jdstrand> mdeslaur: thanks
<mvo> thanks cjwatson
<Keybuk> jhunt: I can do last day of the year, or last friday of the year, etc.
<jhunt> Keybuk: oh - another nasty one: "Monday closest to 29th January" (aka "Auckland Anniversary Day")
<Keybuk> nope, you can have last monday of jan or 1st monday of feb though ;-)
<jhunt> Keybuk: can you discriminate between "every hour on the hour" vs. "every hour since boot/resume time"?
<Keybuk> all of the rules I support are of the form "nth n in n"
<Keybuk> jhunt: yes
<jhunt> Keybuk: *awesome*
<geser> bdrung: will try to triage them during the weekend. I've to think what I should do about the crashes somewhere down the chain towards LP API (mostly likely caused by timeouts)
<Keybuk> can do things like "the day you get for xmas"
<Keybuk> deathspank calendar% ./nexttime2 -b "25/12/2010" "WDAY=MON"
<Keybuk> Monday, 27 December 2010 00:00:00 GMT (+0000)
<jhunt> Keybuk: fwiw I think "remind" would handle the "last weekday of this year" scenario as "(first Friday of *next* year) - 7 days"
<Keybuk> that doesn't necessarily give you the last weekday ;-)
<jhunt> Keybuk: no, it also has to use scanning to slide back/forwards around a date looking for a goal.
<Keybuk> yeah
<Keybuk> we don't want upstart to be remind or calendar(1)
<Keybuk> it's worth pointing out that as far as I could tell, remind works on the principle of "what time is it => do I have anything that I can run now?"
<Keybuk> ie. same as cron
<ari-tczew> after last updating natty, my pbuilder is broken
<ari-tczew> E: File /root/pbuilder/natty-base.tgz does not exist
<ari-tczew> pbuilder is installed
<ari-tczew> and why it looks for natty-base.tgz in root instead in ~/pbuilder?
<ari-tczew> yesterday pbuilder worked fine
<seb128> could someone binNEW libzeigeist and dee?
<seb128> they need promotion as well
<seb128> the new unity will need those
<mr_pouit> doko: thanks, hopefully, it should be the last abicheck.sh :p
<doko> mr_pouit: please forward these upstream
<doko> and debian
<mr_pouit> yep, done already for upstream
<seb128> hum
<seb128> jdstrand, cjwatson, Riddell: ^ someone to do the 2 binNEW reviews?
 * cjwatson needs to focus on release meeting just now ...
<jdstrand> seb128: I am working on them today
<jdstrand> cjwatson: ^
<jdstrand> Riddell: ^
<jdstrand> seb128: which 2 do you need right now?
 * jdstrand was going oldest to newest
<seb128> thanks
<seb128> jdstrand, libzeitgeist and dee
<jdstrand> k
<mvo> doko: hm, maverick-updates has a newer glibc than natty, that makes the auto-upgrader unhappy
<doko> mvo: I asked to copy it to natty
<doko> cjwatson: ^^^
<mvo> aha, thanks
<cjwatson> doko: done
<mvo> thanks cjwatson
<jdstrand> seb128: done. I threw in vte for giggles
<seb128> jdstrand, thanks
<jdstrand> sure
<rickspencer3> mvo, are you waiting for someone to provide you text for bug #671016
<ubottu> Launchpad bug 671016 in update-manager (Ubuntu Natty) "EOL needs to be handled more elegantly" [High,In progress] https://launchpad.net/bugs/671016
<rickspencer3> ?
<mvo> rickspencer3: I can write a page up, but someone (a native speaker) should have a look once its ready
<mvo> rickspencer3: sorry, that its not done yet, I put it high on my list
<rickspencer3> mvo, let me see if I can find someone to just write it for you
<rickspencer3> mvo, no apologies necessary
<rickspencer3> I'm just trying to make sure you have what you need
<mvo> thanks rickspencer3
<seb128> doko, or some other buildd admin?
<seb128> can you get those score to build now?
<seb128> https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2101832
<seb128> https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2101831
<seb128> that's a test build of the new unity
<seb128> cjwatson, ^?
<seb128> lamont, ^?
<seb128> sorry but unity needs to land today
<seb128> and I'm having issue building it
<seb128> having that ppa build in less than 7 hours would be useful
<cjwatson> I've scored both up
<seb128> cjwatson, thanks a lot!
<jdstrand> seb128: so, looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, it seems (at least some) of the gir promotions are unseeded or not depended on. did I do too much or have you not finished your gir work yet?
<seb128> jdstrand, this page seems buggy
<seb128> jdstrand, apt-cache rdepends gir1.2-gconf-2.0
<seb128> jdstrand, gir1.2-gtk-3.0 is a rdepends of apport and language-selector
<seb128> not sure what's going on
<marjo> hi folks
<marjo> anybody else experiencing a startup problem after today's update to natty?
<marjo> i do not get to a login screen, only a blank screen after initial ubuntu splash screen
<marjo> this is with kernel-2.6.37-9 and kernel-2.6.37-7 behaves same
<marjo> last message (text mode, removed quiet and splash) states " running /scripts/init-bottom done
<marjo>  at the top, it says "loading, please wait"
<marjo>  then it goes into that blank screen"
<ebroder> marjo: Sounds like https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
<ebroder> Well, maybe, depending on what you mean by "initial splash"
<marjo> ebroder: yes, thx for the pointer
<mterry> jdstrand, ping about libmono-system-data-linq2.0-cil needing to be in main
<porthose> hey guys is there a list somewhere of companies that use ubuntu in an enterprise setting? I have a friend (a teacher) who is trying to convince the schools superintendent that FOSS is a good thing
<charlie-tca> jcastro: Do you know where the list of enterprise users is?
<jdstrand> mterry: is there a bug? (I have no context)
<jcastro> is there such a list?
<charlie-tca> I thought there was, but my memory fails me
<mterry> jdstrand, I was going to fill out context if you were around  :)
 * charlie-tca thinks it could be wrong again, too
<mterry> jdstrand, so we got a new mono from debian auto-sync
<jdstrand> mterry: I am around :)
<mterry> jdstrand, it has a new binary package libmono-system-data-linq2.0-cil
<mterry> jdstrand, and some main packages are failing to build because a lot of mono stuff depends on that package (for example, launchpad-integration fails)
<cyphermox> slangasek, ping?
<mterry> jdstrand, so I think it needs to be moved to main.  Changelog indicates some files from a previous package just got moved to a separate one
<charlie-tca> porthose: ask in #edubuntu about schools
<charlie-tca> That is made for them
<porthose> charlie-tca, will do thx
<jcastro> charlie-tca: yeah the only list I remember was one of schools
<jdstrand> mterry: do you know off hand where System.Data.Linq was before?
<charlie-tca> Thanks, jcastro
<mterry> jdstrand, not off hand, let me find out
<slangasek> cyphermox: hey there
<seb128> Laney, ^
<seb128> directhex, ^
<seb128> jcastro, hey
<cyphermox> slangasek, hey, so removing the /etc/hosts changing stuff in NM has just landed upstream. we'll rely on nss-myhostname at worst to always have a resolvable hostname
<jcastro> seb128: hi
<slangasek> cyphermox: yay :)
<mterry> jdstrand, libmono-system-data2.0-cil
<cyphermox> I'll upload NM with those bits soon, and file a MIR for libnss-myhostname
<seb128> jcastro, new unity upload btw
<slangasek> cyphermox: why do we need libnss-myhostname?
<slangasek> cyphermox: Ubuntu *already* sets up /etc/hosts by default
<cyphermox> slangasek, not necessarily needed, but it makes sure the hostname is resolvable in case it changes through DHCP or something
<cyphermox> slangasek, I was still going to upload NM without recommending it yet, see if it ends up being necessary. I'd like to do some testing of that, I just need to find a way to setup a good testing rig
<slangasek> "changes through DHCP" - does that mean NM will change the hostname if DHCP provides it with one?
<slangasek> I would hope that's disabled by default
<jdstrand> mterry: too easy. that was already in main. promoted. thanks for checking! :)
<cyphermox> slangasek, that hasn't been removed
<slangasek> cyphermox: "removed"?  Sorry, I was unaware that NM ever did anything of the sort
<cyphermox> slangasek, unless we already disable that from dhcp's config, I can't recall
<slangasek> I would scream bloody murder if NM ever changed my hostname :)
<mterry> jdstrand, awesome, thnks
<cyphermox> slangasek, so would I, but in some cases people may want it -- see office users in some very restrictive environments (like my former workplace)
<slangasek> cyphermox: sure, but I would expect that to be a non-default option that gets explicitly enabled on the client
<slangasek> so that's a special case, no need for libnss-myhostname to be installed in the common case
<cyphermox> alright
<cyphermox> did you file the bug about changing /etc/hosts yet? :)
<cody-somerville> Is there any metrics on how long packages take to install to identify packages that might have performance issues in their maintainer scripts or what not?
<slangasek> cyphermox: no....
<ScottK> How slow is arm ...  It's sooo slow that two ia64 builders can build KDE faster than 8 arm builders.
<JontheEchidna> ScottK: at least you could run the compiles off of a battery due to lower power consumption :P
<micahg> should teh langpacks be much larger?
<directhex> my scrollback is too small to see what seb128 wanted
<ScottK> relevant backscroll delivered via PM
<directhex> mterry: the assembly in libmono-system-data-linq2.0-cil used to be in libmono-system-data2.0-cil - that one assembly was moved out into a distinct package to avoid pulling in a ~6 meg dep chain when using system.data. we didn't see anything in debian that the move broke, but obviously launchpad-integration isn't debianish
<directhex> although it shouldn't ftbfs, since mono-devel should pull it in...
<mterry> directhex, right, but it builds in a main-only chroot, whereas linq2.0-cil was a new package and hadn't yet been promoted to main
<directhex> i see
<mterry> directhex, it was a good and correct change, just we had to fix stuff because of main/univers
<directhex> i forgot that new packages on main source packages go to universe first
<directhex> mterry: but at least now you know! :)
<mterry> :)
<directhex> mterry: dunno how meebey got a NEW package past debian-release, but he seems to have just the right way of fluttering his eyelashes
<mterry> heh
<barry> james_w: hi.  there are four pkgme branches waiting to be merged.  do you want me to take care of those?  would you do a quick review of my envar branch?  i want to do a bit more pkgme hacking but would like to get the existing mp's dealt with first
<james_w> barry, merge them, and I'll review the env one in a short while
<barry> james_w: cool
<cjwatson> seb128: I figured out why component-mismatches was hopelessly wrong - should be fixed shortly
<seb128> cjwatson, oh great, thanks
<cjwatson> was related to a recent Launchpad change I made, and forgot about a transitional requirement to remove some old files
<cjwatson> so effectively it was referring to Sources files from the 14th
<seb128> ok
<cjwatson> hmm, or maybe not!  what's going on
<cjwatson> oh, more files to remove maybe
<cjwatson> might need another LP change at some point then :-/
<cjwatson> should at worst be able to tide it over manually until then
<ScottK> barry: Looks like we'll want a newer cdbs (4.90) for python3-distutils.mk
<barry> ScottK: earlier versions don't support py3?
<ScottK> They don't have python3-distutils.mk (see POX's commits just now in #debian-python)
<ScottK> Last I heard he was waiting for someone to do the CDBS stuff.  I guess he found someone.
 * ScottK hasn't tried any Python3 stuff with CDBS, so no idea.
<barry> ScottK: today is my last official work day of the year, so i likely won't get to it until 2011 ;)
<sistpoty> you lucky one, I'll have to work until Dec 23.
<ScottK> barry: OK.  Please mark it on your list for 2011 then.
<barry> sistpoty: that's what you get for not taking vacation earlier in the year ;)
<ScottK> Unless I hit a package that uses CDBS and I care about it having Python3 support, I'm unlikely to do it.
<barry> ScottK: putting it on my todo
<sistpoty> haha
<sistpoty> buxy: btw, the new dpkg (as in 1.15.8.6ubuntu1, though I've seen it on unstable as well) is very bad wrt. perfomance on ext4, my feeling is that it's even worse than previous versions which called sync directly
<sistpoty> s/ext4/ext4 on my sluggish system *g*/
<cjwatson> sistpoty: 1.15.8.7 is coming soon with some important changes there
<cjwatson> they're already in git
<cjwatson> I'll merge it into natty as soon as I see it in unstable
<sistpoty> cjwatson: oh, nice... :) are that the ones that have been proposed on debian-devel?
<cjwatson> I have no idea
<cjwatson> they were suggested by tytso in the relevant Debian dpkg bug
<sistpoty> cjwatson: then I assume so, yes... thought these were already in, sorry
<ebroder> bdrung: I wonder if update-maintainer (or possibly a successor) should also be expanded to handle things like Vcs-Bzr -> X-Debian-Vcs-Bzr
<sistpoty> (oh, and sorry for the highlight/getting on your nerves buxy)
<ebroder> bdrung: Or rather, I wonder if this is a good opportunity to have a discussion about policy-ifying that
<bdrung> ebroder: yes, that's a good idea (there is a bug report for it)
<bdrung> ebroder: i want to rewrite update-maintainer to fix bug #666504 and #688872
<ubottu> Launchpad bug 666504 in ubuntu-dev-tools (Ubuntu) "[update-maintainer] can't update if XSBC-Original- has got @ubuntu.com" [Medium,Triaged] https://launchpad.net/bugs/666504
<ubottu> Launchpad bug 688872 in ubuntu-dev-tools (Ubuntu) "[sponsor-patch] Don't update the maintainer for no-change rebuilds" [Medium,New] https://launchpad.net/bugs/688872
<ebroder> bdrung: Yeah, that sounds good
<bdrung> ebroder: we can fix bug #567629
<ubottu> Launchpad bug 567629 in ubuntu-dev-tools (Ubuntu) "[update-maintainer] should adjust Vcs-foo fields too" [Wishlist,New] https://launchpad.net/bugs/567629
<bdrung> mdz: you wrote ubuntu-iso. can you please have a look at bug #637020
<ubottu> Launchpad bug 637020 in ubuntu-dev-tools (Ubuntu) "ubuntu-iso crashed with isoinfo in extract()" [Undecided,Confirmed] https://launchpad.net/bugs/637020
<sistpoty> bdrung: it would be cool, if update-maintainer would use the same criteria that is taken into account for building a source package
<bdrung> sistpoty: the source tarball creation will fail if "ubuntu" is in the debian version and that's what i was proposing.
<sistpoty> bdrung: cool... I thought there was a slight difference between your proposal and source tarball creation in that anything that ends in ubuntu.com is accepted (but I've forgotten the details)
<bdrung> sistpoty: i am not sure about that point
 * sistpoty is neither, and can't find the source right now
<bdrung> sistpoty: dpkg-dev
<sistpoty> bdrung: actually it's' version contains ubuntu' and 'maintainer doesn't contain ubuntu' and 'env(DEBEMAIL), if set, contains @ubuntu.com' that makes the src-pkg build fail (Ubuntu.pm)
<sistpoty> (at least from my reading right now)
<bdrung> sistpoty: then my proposal is a valid subset
<sistpoty> bdrung: no, it's not: changed-by: sistpoty@ubuntu.com; maintainer: ubuntu-motu@lists.ubuntu.com
<sistpoty> bdrung: thought that's probably nitpicking ;)
<sistpoty> -t
<bdrung> sistpoty: the src-pkg build wont fail in your example
<bdrung> sistpoty: what are you picking about?
<sistpoty> bdrung: true, I guess if maintainer is someone@subdomain.ubuntu.com? (which shouldn't happen in the first place thought)
<sistpoty> bdrung: it's really only nitpicking. I thought it would make an actual difference, and I was wrong, sorry
<bdrung> sistpoty: if you want a different behaviour of update-maintainer, please respond to the mailinglist mail
<sistpoty> bdrung: no, I don't... I just wanted to make sure right here that it matches dpkg-dev. Thanks for taking the time and explaining me that I was wrong ;)
<bdrung> sistpoty: we just have to make sure that update-maintainer isn't less strict than the src-pkg build
<xnox> bdrung, why can't we hook this thing into Ubuntu's dh_clean which checks for DEB_VENDOR and updates the maintainer automagically behind your back it is -ubuntu1 upload?
<xnox> I really hate src-pkg build errors =) pointless and 100% automatable.
<ebroder> xnox: That sounds really sketchy. I don't like my clean targets actually doing things
<xnox> s/DEB_VENDOR/dpkg-vendor -qname/
<bdrung> xnox: dh_clean is the wrong place
 * xnox or whatever the call to dpkg-vendor was
<xnox> bzr-bd pre-build hook?
<ebroder> Better, but not sufficient so long as we're not exclusively using UDD
<bdrung> xnox: sponsor-patch runs update-maintainer
<xnox> bdrung, what about us non-uploading contributors?
<bdrung> xnox: update-maintainer is only one command away
#ubuntu-devel 2010-12-18
<kees> isn't apport supposed to be enabled in natty?
<crimsun> AFAIK, yes
<barry> james_w: i just pushed another branch (test-fixes) which fixes all the tests for me.  there might be some conflict between that and the envar branch, but if you review then separately, and approve them, i'll resolve any conflicts and merge them to trunk.
<james_w> barry, this feels wrong to me somewhat. Shouldn't we just change things such that install installs the backends too?
<james_w> barry, the __file__ stuff was to support running uninstalled, but that's now not possible, correct?
<james_w> ah "develop" is possible
<james_w> barry, reviewed, thanks
<achiang> hm, how do i update the sources.list inside of a pbuilder?
<DasEi> I've got Aurorax on my back in #ubuntu who seems to be up in writing a devicedriver as novice, , wee just installed build-essential and he seems concerned, I'll send him over, couldn't tell him he need more experience
<DasEi> seems either I've been pulled forward, or trolled, nvm, quite now :)
<mdz> bdrung: bug 637020 looks pretty straightforward; ubuntu-iso is a trivial wrapper around isoinfo and doesn't attempt to parse any command line options
<ubottu> Launchpad bug 637020 in ubuntu-dev-tools (Ubuntu) "ubuntu-iso crashed with isoinfo in extract()" [Undecided,Confirmed] https://launchpad.net/bugs/637020
<mdz> it should just exit nonzero rather than crash
<mdz> a --help option could be added, but it would be minimal (there is already a man page which explains the lack of options)
<bdrung> mdz: just exit nonzero or should it print an error message? if yes, what should it print?
<mdz> bdrung: currently it raises an exception with the error output from isoinfo. I think it should just print that to stderr (or let isoinfo do it if it will behave), and exit nonzero, instead of raising an exception
<mdz> should be a two-liner, replace the "raise Exception, stderr" with "sys.stderr.write(stderr)\nsys.exit(pipe.returncode)"
<bdrung> mdz: done
<mdz> bdrung: awesome, thanks!
<bdrung> mdz: trivial :)
<mdz> if I have some time I'll add a simple option parser which responds to --help
<mdz> it's not implausible that one day it will grow more functionality
<mdz> it would be nice to be able to extract the filesystem manifest, for example
<bdrung> mdz: optparse is your friend - look at sponsor-patch for example
<mdz> bdrung: yeah, it should be simple enough. I'm just trying to spend my weekend responding to all of the person emails I haven't replied to during the week ;-)
<cjwatson> mdz: sounds thrilling ...
 * cjwatson has an exciting weekend of housework lined up, and so far today has been procrastinating it by cleaning house in the archive instead
<ari-tczew> does anybody know why pbuilder-dist doesn't work longer with ~/pbuilder?
<tumbleweed> ari-tczew: do you have the latest version? (You're not running into the sudo -E issue?)
<ebroder> bdrung: I'll check out those bugs
<bdrung> ebroder: i am on bug #691893
<ebroder> bdrung: Though I'm not sure I think it's a good idea to have a -y option
<ubottu> Launchpad bug 691893 in ubuntu-dev-tools (Ubuntu) "[backportpackage] global name 'opts' is not defined" [Undecided,New] https://launchpad.net/bugs/691893
<bdrung> ebroder: i am not sure about the other bug reports.
<bdrung> ebroder: what sponsor-patch does: it ask to confirm the upload if the upload target is "ubuntu"
<bdrung> otherwise it doesn't ask
<ebroder> bdrung: Hmm, ok
<bdrung> ebroder: i think we don't need to ask if we build the package before uploading
<ebroder> bdrung: I also think I'm going to add a -S/--suffix option for the version number suffix (after the ~maverick1 bit or whatever), so you can do ~ppa2 uploads
<bdrung> ebroder: good idea
<ebroder> Because right now I have a backport in a PPA that I want to submit a rebuild for
<ebroder> bdrung: For bug #691897, the .orig.tar.gz has to be in the destination release already, right? Is there any way I can test for that?
<ubottu> Launchpad bug 691897 in ubuntu-dev-tools (Ubuntu) "[backportpackage] add diff option" [Undecided,New] https://launchpad.net/bugs/691897
<ebroder> Like, PPAs won't pull the orig source from other pockets in the PPA or something, right?
<bdrung> ebroder: look at sponsor-patch
<bdrung> ebroder: yes
<ebroder> bdrung: Oh, really? Huh
<ebroder> bdrung: Right, sponsor-patch does the standard check - does the last changelog version and this one have the same version, but I can't do that with backportpackage, because the last changelog entry was from a different release than the one I'm about to upload to
<ebroder> *same upstream version component
<bdrung> ebroder: ok, you have to look at the dsc file and check if these files are available in launchpad
<bdrung> ebroder: make this check reusable by sponsor-patch
<ebroder> bdrung: Sure
<ebroder> bdrung: Do you mind if I push a fix for the bug in 691862 comment 8 (the "global name opts is not defined") directly back to lp:ubuntu-dev-tools, since the fix is simple and obvious?
<bdrung> ebroder: i wouldn't mind, but i have already pushed the fix :P
<ebroder> bdrung: Oh, good. Thanks
<bdrung> ebroder: should i release the current state of u-d-t?
<ebroder> bdrung: If you don't mind holding up until tomorrow, I was planning to spend a few hours today working through my todo list
<bdrung> ebroder: ok, i'll wait then
<ebroder> bdrung: To deal with bug #691896, I'm thinking of changing that to erroring out "if not opts.workdir and not opts.upload". If you're uploading, it doesn't matter that workdir isn't set and it's going to delete the workdir when it's done. If you've set workdir, then you're not going to lose your build products
<ubottu> Launchpad bug 691896 in ubuntu-dev-tools (Ubuntu) "[backportpackage] only gen packages" [Undecided,New] https://launchpad.net/bugs/691896
<ebroder> bdrung: This will also solve the issue that right now if you run with -b and not -u or -w, you never get a chance to see the results of the build
<ebroder> (which ari-tczew complained about last weekend)
<bdrung> ebroder: yes, good idea
<ari-tczew> ebroder: last weekend? huh, time is hurry up
<ebroder> I'm pretty sure that was when you last tested it
<ari-tczew> I don't doubt it, just afraid how quickly is time. (:
<ebroder> bdrung: Does it seem reasonable to change the arguments to -u -U ppa:broder/ppa instead of just -u ppa:broder/ppa? That way BACKPORTPACKAGE_UPLOAD -> -U argument, and setting BACKPORTPACKAGE_UPLOAD doesn't force you to always upload when you run backportpackage
<bdrung> ebroder: you want "-u" for upload and "-U" for upload target?
<ebroder> bdrung: Yes
<bdrung> ebroder: and --update?
<ebroder> bdrung: Oh, whoops. Too many 'u' options
<ebroder> How about -u for upload and -t for upload target?
<bdrung> ebroder: better :)
<bdrung> ebroder: i have a better idea.
<bdrung> "-u foobar" for uploading to foobar. "-u" for uploading to BACKPORTPACKAGE_UPLOAD
<ebroder> bdrung: Can't do that with optparse
<ebroder> bdrung: (And rightfully so, because short options with optional arguments theoretically can't be parsed consistently. If I pass -u -s, is that -u=-s or two different options?)
<bdrung> it should be consistent with sponsor-patch
<ebroder> bdrung: So I guess -u for the target and...something else for "upload to BACKPORTPACKAGE_UPLOAD"?
<bdrung> ebroder: what speaks against always uploading to BACKPORTPACKAGE_UPLOAD?
<ari-tczew> tumbleweed: I have latest pbuilder. I don't know about sudo -E issue.
<ebroder> bdrung: The logic is that the "upload to BACKPORTPACKAGE_UPLOAD" option is actually a "go and *do* the upload" option, and gets set automatically if you specify a target on the command line
<bdrung> ebroder: i don't get it.
<ebroder> bdrung: There's --upload-target and --do-upload. If you just say --do-upload it uploads to BACKPORTPACKAGE_UPLOAD. If you say --upload-target it sets --do-upload automatically
<bdrung> ebroder: is there a usecase for not uploading the package if BACKPORTPACKAGE_UPLOAD is set?
<ebroder> bdrung: If I do a local build?
<bdrung> ebroder: ok
<bdrung> ebroder: what about a negative option. "-d, --dry-run" for not doing an upload
<ebroder> bdrung: Maybe
<bdrung> ebroder: what do you think if i would change the question from "Do you want to upload this to ppa:bdrung/backports? [Y/n]" to "Do you want to upload adblock-plus 1.3.2-1~maverick1~ppa1 to ppa:bdrung/backports [Y|n]?"?
<ebroder> That's fine, although I was going to drop the prompt if the upload target isn't ubuntu
<bdrung> ebroder: or do you prefer "Do you want to upload adblock-plus_1.3.2-1~maverick1~ppa1_source.changes to ppa:bdrung/backports [Y|n]?"?
<bdrung> ebroder: but having the prompt is nice (to check if the backported version is the right one and the target is correct)
<ebroder> bdrung: Ok, I guess I can do a -y option instead
<ebroder> Anyway, I have no preference for the form of the prompt
<bdrung> ebroder: and the -y options should have no affect if you upload to ubuntu
<bdrung> ebroder: pushed r845
<bdrung> ebroder: shouldn't "Please check the package in file://%s carefully" be before the upload?
<ebroder> It is, isn't it?
<bdrung> ebroder: nope. it's before building the package
<bdrung> ebroder: idea: change "Please check the package in file://%s carefully! Do you want to upload <package> <version> to %s" to "Please check <package> <version> in file://%s carefully! Do you want to upload the package to %s"
<ebroder> bdrung: Yes, that's fine
<bdrung> ebroder: pushed
<tumbleweed> ari-tczew: I was asking about th elatest ubuntu-dev-tools
<tumbleweed> ari-tczew: the issue I'm talking about is that sudo used to allow environment through, but recently changed behavior, so -E had to be added in pbuilder-dist
<ari-tczew> tumbleweed: ubuntu-dev-tools also up-to-dated
<tumbleweed> ari-tczew: so what actually is the problem?
<ari-tczew> tumbleweed: pbuilder-dist doesn't look for base in ~/pbuilder
<ari-tczew> this is my problem
<ari-tczew> I'm asking whether is there a known problem? if not, probably I have to report a bug
<tumbleweed> I suspect the problem is with yoru local configuration, but if you can't find it, please report a bug, yes
<ari-tczew> tumbleweed: I didn't change anything.
<ari-tczew> anyway, where can I fix config?
<tumbleweed> I mean .pbuilderrc
<tumbleweed> oh, and check the permissions of ~/pbuilder
<ScottK> tumbleweed:  If sudo stopped letting the environment through, that would explain exactly the result that ari-tczew is seeing.
<tumbleweed> ScottK: that should have been dealt with in the last u-d-t upload
<ScottK> OK
<tumbleweed> ScottK: btw, the postgrey issue is that the DD can't seem to get his orig.tar.gz to match the one in th edebian archive, so his uploads get rejected. Prodded him.
<ScottK> tumbleweed: OK.  This looks like something then that we ought to just fix in Natty so we can SRU Lucid/Maverick ASAP.
<ScottK> As is it's breaking uprades from Hardy.
<tumbleweed> aah, right. shall I do it?
<tumbleweed> ebroder: backportpackage isn't listed in debian/copyright
<ari-tczew> tumbleweed: ok, what have I to do to get pbuilder working?
<tumbleweed> ari-tczew: are you on maverick?
<ari-tczew> tumbleweed: nope, natty
<tumbleweed> ari-tczew: please pastebin output, .pbuilderrc, and ls -l ~/pbuilder
<bdrung> tumbleweed: are you volunteering to update and convert d/copyright to DEP-5? ;)
<ScottK> tumbleweed: Yes.  Please do it (postgrey).
<tumbleweed> bdrung: I just considered doing that :P
<ari-tczew> tumbleweed: http://paste.ubuntu.com/545367/
<tumbleweed> but backportpackage doesn't contain a copyright notice, only a GPL-2
<ari-tczew> tumbleweed: http://paste.ubuntu.com/545369/
<bdrung> ebroder: do you allow later versions of GPL?
<tumbleweed> ari-tczew: that .pbuildrrc is (hopefully) redundant, if you use pbuilder-dist
<ari-tczew> tumbleweed: yes, I prefer to use pbuilder-dist. what's next?
<tumbleweed> ari-tczew: the actual errors you are seeing
<ari-tczew> tumbleweed: sorry, probably I'm blind
<ari-tczew> (dunno what's wrong, I didn't change anything)
<tumbleweed> I hate those bugs
<bdrung> tumbleweed: pbuilder-dist shouldn't be negatively impacted by an pbuilderrc config
<bdrung> instead everything should be passed as command line parameter to pbuilder
<tumbleweed> bdrung: no, it shouldn't, the command line options should trump the config file
 * bdrung nods
<bdrung> therefore ari-tczew's problem should be considered as bug
<ari-tczew> bdrung, tumbleweed: so, until problem is not fixed, can't I use pbuilder?
<ari-tczew> so merges have to wait longer
<tumbleweed> ari-tczew: please file a bug, and include the command you are running and output
<bdrung> ari-tczew: doesn't moving (or deleting) your pbuilder config file help?
<ari-tczew> bdrung: .pbuilderrc?
<bdrung> ari-tczew: yes
<ari-tczew> bdrung: the same error
<bdrung> ari-tczew: then the problem is independent from the pbuilder config file.
<bdrung> ari-tczew: file a bug!
<ari-tczew> bdrung: target?
<tumbleweed> ari-tczew: ubuntu-dev-tools in ubuntu
<ari-tczew> bdrung, tumbleweed: what a specific number! bug 691999
<ubottu> Launchpad bug 691999 in ubuntu-dev-tools (Ubuntu) "[pbuilder-dist] Does not work on natty" [Undecided,New] https://launchpad.net/bugs/691999
<tumbleweed> ari-tczew: run it without sudo :)
<bdrung> ari-tczew: does it work without sudo?
<ari-tczew> tumbleweed, bdrung: hmm... working. trying to build a package
<ari-tczew> I gave you a output command! ;)
<ari-tczew> ah, not, sorry :P
<tumbleweed> no that's a definite usability bug that should be fixed
<ari-tczew> please don't hang dogs on me, I always have these aliases with sudo
<ebroder> bdrung: I'd prefer to leave backportpackage GPLv2, not v2+
<tumbleweed> ebroder: noted, I'll do a dep5ification (bug 692003)
<ubottu> Launchpad bug 692003 in ubuntu-dev-tools (Ubuntu) "DEP5 copyright file" [Wishlist,In progress] https://launchpad.net/bugs/692003
<TheLE> Hey I'm having a bit of an issue. Every time I create an About Dialog (built from GLADE->GtkBuilder) from an event on my main window I also get another instance of my main window for no reason.
<TheLE> it originates from the gtk_builder_add_from_file(..) function call inside of my About Dialog (the one responsible for retrieving the dialog's UI from the XML file
<TheLE> is there a restriction on the number of times that I can call this function during execution? or after the gtk_main() function has been called?
<ebroder> TheLE: This channel is more for development of Ubuntu itself than development of apps on Ubuntu. You might have better luck in #ubuntu-app-devel
<TheLE> ebroder: thanks
<ebroder> tumbleweed: What did I do wrong in backportpackage's header? Oh, I guess I forgot a copyright statement?
<tumbleweed> yes
<ebroder> tumbleweed: Ok, I'll add one in my next MP
<bdrung> ebroder: what do you have against v2+?
<ebroder> bdrung: I'm not wild about v3. And regardless of what v3 itself says, I don't like the idea of giving another organization the ability to change the rules of my code
<bdrung> ebroder: then "v2 or v3" would be fine?
<ebroder> bdrung: Yeah, I'd be OK with that
<ebroder> bdrung: I can upgrade it to 2 or 3, but for what it's worth that'd be a new license for dev-tools (right now there's v2, v3, v2+, v3+, but no v2orv3)
<bdrung> ebroder: what a mess with v2, v3, v2+, v3+
<bdrung> let's move to ISC ;)
<tumbleweed> indeed, it's make the dep5 task rather nasty
<tumbleweed> I'll have to work out who has touched each file
<ebroder> I respect the need for open-source licenses, but I tend to find everything about licensing annoying
<bdrung> ebroder: that's why i prefer ISC - it's simple, short and isn't versioned
<bdrung> and it's compatible to everything
<ebroder> bdrung: Yeah, I license a lot of things MIT because I can fit it all on a screen
<bdrung> ebroder: ISC is a little bit shorter than MIT
<ebroder> bdrung: Ugh, I'm trying to code up the heuristic for whether to use -sa or -sd. It looks like it's going to be complicated
<ebroder> I guess I need to sort the files in the source package into .dsc, debian diff, orig files
<ebroder> And I need to deal with source format 3 which can have multiple orig files, and they're not always .orig.tar.gz anymore
<ebroder> On the plus side, there will probably be several useful library functions for ubuntutools that fall out of this
<bdrung> ebroder: look at my download logic
<ebroder> bdrung: Where?
<bdrung> mom
<ebroder> bdrung: Where do I find the source for mom?
<bdrung> mom = give me a moment
<ebroder> Ah, ok
<bdrung> ebroder: it's in syncpackage
<bdrung> line 242
<bdrung> ebroder: you might want do use dsc_getfiles(dscurl)
<bdrung> ebroder: 'if answer != "yes":' -> 'if answer == "no":'
<ebroder> bdrung: Ok, sure
<bdrung> ebroder: you shouldn't mention features implemented in the not yet released backportpackage
<ebroder> bdrung: I was mostly doing it for the LP closers. Should I drop the closers entirely?
<bdrung> ebroder: yes (just bzr ci --fixes lp:123456) and i'll close the bugs manually once merged
<ebroder> Ok
<ebroder> bdrung: Since the --fixes is already in the branch history, I don't actually need to do anything, right? Just drop the changelog entries?
<bdrung> yes
<bdrung> (if you used debcommit)
<ebroder> bdrung: Fixed
<bdrung> is that philosophical? "You say goodbye, and I say hello."
<ebroder> bdrung: Beatles reference :)
<ebroder> bdrung: http://www.youtube.com/watch?v=Qf2S7kKLtEQ
 * bdrung is already watching on youtube.
<bdrung> ebroder: is your branch ready for the merge?
<ebroder> bdrung: Sure
<bdrung> ebroder: merged and pushed
<ebroder> bdrung: Cool, thanks
<bdrung> ebroder: is there anything left that you want to do?
<ebroder> bdrung: Not particularly urgently. If you want to release, that's OK with me
<ebroder> bdrung: Though I can't promise I won't have new features for you by tomorrow
<bdrung> ebroder: i vote for "release early, release often"
<ebroder> So let's say I have an empty PPA. I create a new Debian revision of a package currently in the Ubuntu archive, and I build my source package with debuild -sd. Will soyuz copy the orig.tar.gz from the archive to my PPA, or will it error out?
<ebroder> bdrung: Works for me
<bdrung> ebroder: it will error out
<ebroder> bdrung: Cool. That makes the -sa/-sd detection much simpler
<bdrung> ebroder: yes, if target = ubuntu ==> check if it's in the official archive
<bdrung> if target = ppa: check if in specific ppa
<ebroder> bdrung: I was going to get an lplib object for the archive and then I can use the same code
<bdrung> ebroder: what should the lplib object do?
<ebroder> bdrung: Something roughly like http://pastebin.com/ALGi0DtX
<bdrung> ebroder: "orig = set(['all', 'orig', 'files']"?
<ebroder> bdrung: It's pseudocode
<ebroder> bdrung: ...but it's Python, so it's almost-functional pseudocode :-P
<bdrung> ebroder: what should that do?
<ebroder> bdrung: It will get the list of every source file currently in the archive for the source package "whatever"
<bdrung> orig = get_orig_files_from_dsc(dsc_filename)
<ebroder> Yeah, basically
<bdrung> ebroder: i think it should work that way. go ahead :)
<ebroder> bdrung: Here's what it actually looks like: http://pastebin.com/D4GZQdm8
<bdrung> tumbleweed: how long will it take for you to fix bug #692003? should i wait for it or should i upload 0.108?
<ubottu> Launchpad bug 692003 in ubuntu-dev-tools (Ubuntu) "DEP5 copyright file" [Wishlist,In progress] https://launchpad.net/bugs/692003
<tumbleweed> bdrung: hoping to finish it tonight. I went down the rabbithole of scripting licensecheck + bzr output > dep5
<bdrung> ebroder: great. can we have an object that have a function for that? one object for the ubuntu archive and one for each ppa?
<ebroder> bdrung: Yeah, that's what I'm planning to do
<ebroder> bdrung: But don't block the release for it - I'm not sure I'll finish it today
<bdrung> tumbleweed: tonight in which timezone?
<tumbleweed> same as you, GMT+2
<bdrung> tumbleweed: ok, i will do the release before i go to bed. either you make it or it will end up in the next release.
<tumbleweed> fine with me
<bdrung> ebroder: "Package failed to build; aborting" is a bad error message.
<bdrung> ebroder: should the sentences ends with fullstops or exclamation marks?
<ebroder> bdrung: I have no preference; whichever you prefer
<bdrung> ebroder: please review r851
<ebroder> bdrung: ACK
<bdrung> ebroder: and r852
<bdrung> ebroder: re r851: do you have a better idea for having a common error message in builder.py?
<ebroder> bdrung: ACK r852
<ebroder> bdrung: I think what you did is fine
<bdrung> tumbleweed: re bug #691999: i think you should abort instead of just printing a warning. running pbuilder-dist as root will create files owned by root in your home directory.
<ubottu> Launchpad bug 691999 in ubuntu-dev-tools (Ubuntu) "[pbuilder-dist] Shouldn't be run with sudo" [Wishlist,Fix committed] https://launchpad.net/bugs/691999
<tumbleweed> bdrung: no it won't create them in your home directory, it'll use /root/pbuilder
<tumbleweed> that's why I went for a warning, it is valid to run it as root, just probably not what you want
<bdrung> tumbleweed: nope. "sudo pbuilder-dist natty update" will create a ~/pbuilder directory owned by root
<ebroder> tumbleweed: sudo doesn't change $HOME unless you pass -H
<ebroder> Maybe error out if os.stat(os.environ['HOME']).st_uid != os.getuid() ?
<tumbleweed> err, http://paste.ubuntu.com/545401/
<tumbleweed> aah, depends on whether or not you have env_reset
<mawst> So what's the deal, why is gstreamer fscking retarded, choking etc all the time on common formats (xvid, mkv) but xine works flawlessly with them, and now there's no option to usethe xine backend on totem?
<bdrung> tumbleweed: status?
<tumbleweed> bdrung: almost there
<bdrung> tumbleweed: did you implement the "os.stat(os.environ['HOME']).st_uid != os.getuid()" check?
<tumbleweed> err no, I'll do that and make it fail if true, otherwise just warn
<bdrung> tumbleweed: no, it's the other way around
<bdrung> ups
<tumbleweed> yeah, that's what I mean :)
<bdrung> if unequal, fail. if equal, warn
<bdrung> i oversaw the '!='
<bdrung> tumbleweed: look at your commit message :D
<tumbleweed> grr, one sec
<bdrung> tumbleweed: your commit message is still broken. :D use '' insead of "" if you don't want $HOME replaced.
<tumbleweed> hehe
<bdrung> tumbleweed: debian/copyright isn't DEP-5
<tumbleweed> bdrung: yeah, something got mixed up due to my branch juggling (that's why I screwed up changeleg entries too)
<bdrung> tumbleweed: and long indentation is preferred (look at the dep5 examples)
<tumbleweed> bdrung: I can't find my final version, it got lost in the juggling, if you still want to upload tonight, don't wait for it
<bdrung> tumbleweed: ok, i will release the current version. let's get the copyright update into the next upload (probably this year).
 * tumbleweed curses himself for trying to work fast on more than one thing
#ubuntu-devel 2010-12-19
 * ScottK doesn't see the point in investing a lot of effort in reworking a policy compliant copyright file into a different, more complex policy compliant copyright file.
<ScottK> Surely there are actual bugs that it'd be more important to fix.
<bdrung> ebroder, tumbleweed: u-d-t 0.108 is released!
<bdrung> good night
<tumbleweed> ScottK: you're not wrong, but that file was unmaintainable and unmaintained
<ScottK> Making it policy compliant is a great idea.  I'm unconvinced DEP-5 helps at all with maintainability.
<ScottK> It's mostly more stuff to get wrong, AFAICT.
<tumbleweed> I find it helps one to be clear, and tends to make complex packages a little easier to describe. But in this case it was a bit of a pain :)
<ggeorgy> hi
<bdrung> tumbleweed: you can't combine the copyright for all files. you have to split it.
<ggeorgy> can you help me? i want to convert a video to ffmpeg
<ggeorgy>  :)
<ggeorgy> for my phone
<akshatj> !support|ggeorgy
<ubottu> ggeorgy: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<ggeorgy> ok
<mueddib> hi
<mueddib> I created new software .deb package
<mueddib> How do I get into the Ubuntu repositories?
<akshatj> mueddib, is the software yours or someone else's ?
<mueddib> akshatj, I'm beta tester, bug tracker :)
<mueddib> I send software mentors debia
<mueddib> http://code.google.com/p/vmps/downloads/list
<mueddib> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=vmpsd
<mueddib> software is gpl licensed, managing cisco routers and switches vlan's
<mueddib> this daemon: /usr/bin/vmpsd
<mueddib> I checked and is not problem :)
<mueddib> I created vmps launchpad project page: https://launchpad.net/vmps
<mueddib> How can I install the package launchpad?
<mueddib> using bazaar?
<ari-tczew> does anybody run maverick? I need a test of clementine package to backport. bug 690297
<ubottu> Launchpad bug 690297 in maverick-backports "Backport clementine to maverick" [Undecided,New] https://launchpad.net/bugs/690297
<nemo> Hey guys. is there a version of bash-completion package that lets me keep the neat ssh/scp completion but removes that file extension insanity that continually ruins my life on command prompt?
<nemo> it is perpetually unaware that app A supports file extension X and of course doesn't complete if there is no file extension
<psusi> cjwatson, the new vesa mode auto detection works great for me, grub goes to 1280x1024 and smoothly hands off to plymouth and X, but for some reason, the plymouth Ubuntu logo still looks bad, like it has been bilinearly scaled
<nemo> eh https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/692275  - here's hoping :)
<ubottu> Ubuntu bug 692275 in bash-completion (Ubuntu) "Request bash completion complete for application when file param has no extension, complete to unrecognised extension if only match." [Undecided,New]
<pinche2643> anybody know of any ubuntu tools to notice a machine going down
<penguin42> pinche2643: Something like nagios?
<Nafallo> landscape ;-)
#ubuntu-devel 2011-12-12
<pitti> Good morning
<pitti> SpamapS: did you copy with -s? mdeslaur pinged me about the linux-meta ABI mismatch in -security
<pitti> SpamapS, slangasek: I usually copy the kernel and lbm, then check https://launchpad.net/ubuntu/+source/linux/+publishinghistory that it really worked, and then copy -meta, and check its publishing-history again
<pitti> SpamapS: if you do copies, please always look up the tracking bug (seems to be bug 893213 in this case), to check for "updates only" vs. "updates and security", and closing the tasks
<ubottu> Launchpad bug 893213 in Kernel SRU Workflow "linux: 3.0.0-14.23 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/893213
<pitti> SpamapS: we need to copy the whole thing or nothing
<pitti> SpamapS: also, please no kernels or other major SRUs on a Friday evening :)
<pitti> SpamapS, mdeslaur: I copied the remaining kernel bits to -security and updated the tracking bug
<pitti> doko: yes, I'm the other DB (psql), not mysql :)
<ScottK> pitti: Good morning.  It turns out that there's a regression in libmsn that prevented the kdenetwork part of the post-release update from building.  The proposed SRU for libmsn to fix the regression is waiting for approval, so it'd be nice to get that in so that I can get the set completed and a call for testing out the door on Monday.
<pitti> ScottK: ah, will do
<ScottK> pitti: Thanks.
<pitti> ScottK: accepted; do you want to retry the affected packages yourself, or want me to watch for it?
<ScottK> pitti: It'd be great if you watch for it since I'm about to go to sleep.  It's just kdenetwork.
<ScottK> If you don't get to it though, I'll just to it in my morning.
<pitti> ScottK: roger, can do; sleep well!
<ScottK> Thanks.
<pitti> zul, Daviey: can you please drop the python-coverage dependency from python-nova? this is rendering it uninstallable
<pitti> jibel, jamespage: so https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=lts-ubuntu,label=upgrade-test/lastBuild/console -> the upgrade succeeded now, and it rebooted, but it complains about some extra old conffiles and X not starting?
<pitti> jibel, jamespage: and similarly for lts-server, it just complains about conffiles? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=lts-server,label=upgrade-test/lastBuild/console
<pitti> jibel, jamespage: what does this test do exactly? having .dpkg-dist files is pretty normal after an upgrade
<slangasek> pitti: -s?
<slangasek> pitti: I certainly used a -s argument for target suite; I'm not sure how that relates to your comment
<pitti> slangasek: sru-release -s -> also copies to -security
<slangasek> er, source suite rather
<slangasek> no, I didn't use sru-release
<pitti> that's the tool SpamapS used
<slangasek> he said it timed out
<pitti> 05:56:16      SpamapS | [00:44:45] bjf: thats more like it!!
<pitti> that sounded like a second try succeeded?
<pitti> ah, so it didn't then, misunderstood
<pitti> slangasek: ok, so when the kernel team says "linux" they really mean "linux, lbm, -meta, and whichever else is attached to it", and the tracking bug says whther or not to also copy to -security
<slangasek> ah
<pitti> kirkland: eww, your sysvinit upload causes a conflict
<pitti> kirkland: /etc/bash_completion.d/service is already in bash-completion
<pitti> I'll revert it
 * micahg was wondering about that
<pitti> kirkland: b-c is in standard, so everyone should already have it?
<pitti> slangasek: I debugged bug 901638 somewhat and added a proposal
<ubottu> Launchpad bug 901638 in update-manager (Ubuntu Precise) "tdsodbc failed to upgrade from Oneiric to Precise" [High,Triaged] https://launchpad.net/bugs/901638
<pitti> slangasek: but I'm not sure whether it would be semantically correct to add that conflicts
<pitti> slangasek: I tried raising tdsodbc's Breaks: libiodbc2 to a Conflicts, but that's not enough
<pitti> (as unversioned Breaks: are discouraged)
<slangasek> pitti: having odbcinst1debian Conflict: with libiodbc2 is not semantically accurate, but given that libiodbc2 is intended to be obsoleted, that's probably not sufficient reason not to do that
<pitti> slangasek: is there another package which is a better "replacement" for libiodbc2?
<pitti> slangasek: I'm happy to move to conflicts: around a bit and try
<SpamapS> pitti: I haven't done the kernel copies myself since the API times out. I respectfully refuse to attempt any such things again until the procedure is recorded somewhere. :)
 * SpamapS hopes it actually is already recorded, and he can be pointed to it
 * SpamapS is also ashamed at how little SRU approval work he has done in the last 7 days
<pitti> I tried to keep up, but didn't manage to clean up all the queues
<pitti> but RAOF is back now as well, so perhaps we can share the load again
<slangasek> pitti: I guess the conflicts could be added to libodbc1 instead, but logically it's all Breaks, not Conflicts
<pitti> slangasek: testing..
<pitti> hm, that doesn't do it
<pitti> neither a Conflicts:
<pitti> slangasek: adding a Breaks: libiodbc2 instead of a Conflicts: to odbcinst1debian2 _does_ work, though
<SpamapS> pitti: when my Monday starts officially (in 9 hours or so) I promise I'll crank through anything left in the queue. :)
<pitti> SpamapS: thanks! I'll also try to catch up a little today
<pitti> slangasek: noted so in the bug
<slangasek> ok, cool
<pitti> slangasek: want me to upload that to Ubuntu and let it go through the mail-all upgrade test, or do you want to handle this yourself/in Debian?
<slangasek> pitti: feel free to upload it and I'll pull it back into Debian from there
<pitti> slangasek: I can only suppose it's also an issue for squeeze->wheezy upgrades?
<slangasek> I expect so, yes
<pitti> squeeze has 0.82-7
<pitti> exactly like oneiric
<pitti> slangasek: ok, doing that then, thanks!
<pitti> . o O { must .. have ... more ... green ... dots! }
<pitti> jamespage, jibel: the precise-server tests failed; not much output, but I bet it was due to the file conflict in sysvinit-utils, which is fixed now; the other is that nova is uninstallable, I pinged the server team about it
<pitti> Daviey: ^ I'm also happy to fix this (i. e. drop python-coverage from the pips requirements)
<pitti> Daviey: I can push to the branch, but not sure you guys want me to
<pitti> ScottK: kdenetwork seems happy now, FTR
<broder> could somebody on ubuntu-branches mark https://code.launchpad.net/~marcelstimberg/ubuntu/oneiric/labyrinth/fix-for-872756/+merge/84856 as merged?
<pitti> broder: done
<broder> thanks
<slangasek> pitti: did you want to reassign bug #901638 to unixodbc, though?  odbcinst1debian isn't from freetds
<ubottu> Launchpad bug 901638 in unixodbc (Ubuntu Precise) "tdsodbc failed to upgrade from Oneiric to Precise" [High,Fix released] https://launchpad.net/bugs/901638
<geser> pitti: could you please dupe and close bugs #903048, #903068, #903049 and #903050 (the sysvinit upgrade issue you fixed half an hour ago). Thx
<ubottu> Launchpad bug 903068 in sysvinit (Ubuntu) "package sysvinit-utils 2.88dsf-13.10ubuntu5 failed to install/upgrade: tentative de remplacement de Â« /etc/bash_completion.d/service Â», qui appartient aussi au paquet bash-completion 1:1.3-1ubuntu6" [Undecided,New] https://launchpad.net/bugs/903068
<ubottu> Launchpad bug 903050 in sysvinit (Ubuntu) "package sysvinit-utils 2.88dsf-13.10ubuntu5 failed to install/upgrade: trying to overwrite '/etc/bash_completion.d/service', which is also in package bash-completion 1:1.3-1ubuntu6" [Undecided,Confirmed] https://launchpad.net/bugs/903050
<ubottu> Launchpad bug 903048 in sysvinit (Ubuntu) "[12.04] sysvinit-utils conflicts bash-completion (/etc/bash_completion.d/service)" [Undecided,New] https://launchpad.net/bugs/903048
<ubottu> Launchpad bug 903049 in sysvinit (Ubuntu) "package sysvinit-utils 2.88dsf-13.10ubuntu5 failed to install/upgrade: trying to overwrite '/etc/bash_completion.d/service', which is also in package bash-completion 1:1.3-1ubuntu6" [Undecided,Confirmed] https://launchpad.net/bugs/903049
<geser> LP doesn't let me log in to do it myself
<pitti> slangasek: yes, I did
<pitti> geser: oh, thanks; I looked for bugs when I uploaded, and there weren't any
<pitti> geser: done
<pitti> jibel, jamespage: respinning ubuntu-server to pick up fixed sysvutil
<micahg> tjaalton: we don't merge nspr from Debian, it's a totally different package and there was a warning on MoM
<tjaalton> micahg: i've asked chrisccoulson about it
<micahg> well, that's news to me...
<tjaalton> it's not "totally" different, doesn't use sonames but mergeable anyway
<tjaalton> same goes to nss
<micahg> tjaalton: please don't upload 3.13
<tjaalton> micahg: why?
<micahg> it seems broke
<tjaalton> in which way? works fine on my laptop
<tjaalton> uploaded already
<tjaalton> used it for two weeks
<micahg> well, I guess we'll see what breaks
<tjaalton> if you already know something please do tell
 * micahg sees if he can find the bug
<micahg> tjaalton: mozilla 702111
<ubottu> Mozilla bug 702111 in Libraries "Servers intolerant to 1/n-1 record splitting. "The connection was reset"" [Normal,New: ] http://bugzilla.mozilla.org/show_bug.cgi?id=702111
<micahg> tjaalton: FTR, I'm actually in favor of being able to merge from Debian, I just thought there was something WRT to the upstream tarball that was keeping us from doing it
<tjaalton> micahg: i did it very carefully, checked every diff on launchpad to make sure I didn't miss anything, but in the end it turned out to be mostly just the soname change in them, so the diff is actually pretty small (and some bugs fixed due to the merge..)
<micahg> tjaalton: right, that's the packaging side, what about the upstream tarball :)
<tjaalton> micahg: also, that bug seems fixed upstream now, so should be ok once firefox is updated, though I'm ok if an archive admin can hold off nss for now
<tjaalton> micahg: don't see changes made directly ther
<tjaalton> e
<micahg> tjaalton: how is that fixed upstream, it's New?
<tjaalton> unaffected on 8, fixed for 9
<tjaalton> or is 10 already on precise?
<micahg> tjaalton: yes, they disabled the feature, that's only in the firefox branch, not NSS :)
<micahg> and it shouldn't hit NEW of any type since there are no new packages/soname bumps
<tjaalton> ahah, didn't check the product..
<raphink> Hello there
<tjaalton> micahg: it build-depends on the new nspr, so there might be enough time..
<tjaalton> pitti: ^ can you still drop an update from entering when it's in depwait?
<raphink> https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/881673 is blocking for GNOME3 users in oneiric
<ubottu> Ubuntu bug 881673 in synergy (Ubuntu) "Synergy doesn't work properly under GNOME 3" [Undecided,Confirmed]
<pitti> tjaalton: entering what?
<micahg> tjaalton: do you want to revert based on that bug?  you said you've been using it for 2 weeks :), Firefox won't be affected since we use internal libs
<tjaalton> pitti: the archive (precise)
<raphink> can we port the patch to oneiric-updates?
<tjaalton> micahg: oh
<pitti> tjaalton: you can upload a newer version which reverts to a previous version
<pitti> tjaalton: then the previous builds will be discarded
<micahg> chromium might be affected once I get it to build, but meh
<pitti> tjaalton: if it's a new package, it can also be removed
<tjaalton> micahg: well turns out I didn't use it <blush>, but sounds like it's not that big an issue afterall?
<micahg> tjaalton: evolution and pidgin are consumers, have you used either of those?  empathy probably as well
<micahg> raphink: You'll want to follow the procedures documented here: https://wiki.ubuntu.com/StableReleaseUpdates, I'm happy to create an oneiric task for you if you want to work on this
<tjaalton> pitti: no it's just an update. I'll check if anything breaks with the new one first before doing anything drastic
<tjaalton> micahg: I'll test pidgin
<raphink> micahg: thanks, it's presily the process that I'm wondering about ;-)
<micahg> tjaalton: GTALK would probably be a common one
<micahg> tjaalton: epiphany could be a good test as well
<micahg> raphink: do you have any specific questions?
<tjaalton> micahg: hum, shouldn't it be installed by default?
<micahg> tjaalton: which?
<tjaalton> epiphany
<micahg> no, epiphany is the GNOME browser
<tjaalton> oh, haha
<tjaalton> so i installed the boulder dash clone
<tjaalton> mixed it with empathy
<micahg> chromium would be fine also to test with
<raphink> micahg: what is the process these days to request a sync from Debian for precise?
<micahg> raphink: requestsync, we sync automatically from Debian testing right now if there's not an Ubuntu diff
<raphink> synergy is in version 1.3.7-1build1 in precise
<raphink> ah right, testing
<raphink> is it possible to sync from sid if it fixes a known bug?
<raphink> or do we have to wait for the package to enter testing?
<micahg> raphink: if it's not likely to break anything else, yes, just state the reasoning for the jump in the sync request
<raphink> that, or I just wait for the package to migrate to testing
<micahg> raphink: right
<raphink> since it was uploaded to sid on the 4th of december
<micahg> raphink: should migrate in 3 days
<raphink> yes
<raphink> and I confirm that it fixes the problem
<raphink> for now, I'll just upload it to my PPA :-)
<broder> pitti: is the pkgbinarymangler test suite supposed to work outside of the archive builder setup?
<pitti> broder: yes, it is
<broder> pitti: i'm getting http://paste.ubuntu.com/767674/
<pitti> broder: I'm running it locally
<tjaalton> micahg: chromium seems to work, other than the url from that bug
<pitti> broder: interesting; I suppose that's with the current version?
<broder> hmm...interesting question. my checkout might be old <_< >_>
<broder> no, it's currnet
<micahg> tjaalton: check the site in comment 15
<broder> pitti: (i decided that trying to write a fix for bug #899520 was a better option than sleeping)
<ubottu> Launchpad bug 899520 in pkgbinarymangler (Ubuntu) "pkgstriptranslations creates policy-incompliant symlinks" [Undecided,New] https://launchpad.net/bugs/899520
<pitti> broder: ah, sweet; generating correct relative symlinks in shell is really hard, so I didn't get to that so far
<pitti> broder: hang on
<broder> i'm working on a slightly hilarious port of dh_link to shell. i'm simultaneously proud of and repulsed by it :)
<tjaalton> micahg: works, nordea too
<pitti> broder: could you locally apply http://paste.ubuntu.com/767679/ and then run: test/run -v T.test_doc_symlink
<micahg> tjaalton: alright, I think chromium might have their own fix for this bug though now that I think about it
<pitti> broder: this will output the full build log and just run this one test
<pitti> broder: do you get that failure with pristine trunk or did you already do modifications?
<tjaalton> micahg: ok, so the impact is pretty low then
<pitti> broder: it's still succeeding here
<broder> pitti: i got it with pristine trunk
<pitti> broder: ok, let's see what your build log says
<broder> pitti: http://paste.ubuntu.com/767682/
<Daviey> pitti: Don't worry, it'll get resolved today.. (unless you already have a branch ready.)
<pitti> Daviey: I don't have a branch yet, wanted to wait for the server team's pong before duping work
<pitti> (not that it would be much work, but still)
<pitti> Daviey: great, thank you
<ntr0py> When building a package from an install tree in "debian/dest" with dh_install -a --sourcedir=debian/dest do i need any special treatment for shared object files in /usr/lib/xorg/modules/extensions?
<pitti> broder: is that really really a current checkout?
<pitti> broder: lp:ubuntu/pkgbinarymangler
<pitti> broder: we used to have a different branch in the past
<broder> pitti: oh, no, i have lp:pkgbinarymangler
<pitti> broder: becuase line 865 is something completely differnt
<ntr0py> IM just confused about the shared object not included into my .deb
<pitti> broder: ah, then you re-discovered the race condition fixed in 107 :)
<broder> pitti: haha, ok. i'll switch to the newer branch then
<pitti> broder: let me kill the old branch more properly
<broder> much appreciated
<pitti> This branch cannot be deleted as it has 5 branches sharing revisions.
<pitti> bah
<pitti> I'll remove all files in it and just add a README pointing to the new one
<broder> can you mark it as...abandoned?
<broder> i think that might make it fall off the active list
<broder> i guess your approach sounds good too
<pitti> did that, too
<broder> yeah, that at least keeps it off of https://code.launchpad.net/pkgbinarymangler
<pitti> broder: also committed deprecation
<pitti> broder: sorry for the confusion
<broder> no problem
<broder> pitti: err, please disregard that merge proposal. i think i may have off-by-one errors
<apw> cjwatson, had any reports of grub getting into a tailspin when installing kernels on oneiric ?
<ScottK> pitti: Thanks for taking care of it.
<pitti> broder: which one, I've got two now?
<pitti> tjaalton: on upgrade I now get a multi-arch conflict on libnspr4 for ./usr/share/lintian/overrides/libnspr4, known?
<tjaalton> pitti: hrm.. I'll check
<pitti> tjaalton: i. e. you can't currently install libnspr4 and libnspr4:i386 together
<tjaalton> pitti: ok, I didn't have 32bit version myself so didn't bump into this. debian was multiarched too but maybe something is missing
<pitti> tjaalton: just weird why the lintian overrides should be different on i386 and amd64?
<pitti> oh, of course
<pitti> file paths
<pitti> libnspr4: shlib-without-versioned-soname usr/lib/i386-linux-gnu/libnspr4.so libnspr4.so
<pitti> that would be /x86_64-linux-gnu/ on amd64
<tjaalton> ah, duh
<pitti> so we either need a glob in the override (not sure whether they support that) or drop them, or rename them
<tjaalton> well, i don'
<tjaalton> uh
<tjaalton> i don't mind having lintian warn about the sonames
<tjaalton> chrisccoulson: ^
<doko> pitti: just add the warning, not the library name
<tjaalton> oh that's enough?
<doko> yes, but then you won't see other warnings of this type. which probably is fine
<tjaalton> indeed, should be fine
<doko> for all three libs in this package
<broder> pitti: the second proposal is fine. the first one was also, it turns out - i just misunderstood a perl-ism in the code i was copying
<pitti> broder: ok, thanks muchly; will review ASAP
<tjaalton> pitti: uploaded a fixed nspr, but nss needs a similar fix (debian too)
<pitti> tjaalton: cheers
<doko> tjaalton, could you file a bug report for lintian, for the expansion stuff?
<tjaalton> doko: sure
<pitti> broder: looks fine, thanks! merged
<pitti> broder: I'll fix something else now for doko, then do an upload
<doko> ohh, the -doc png opts? that would help armhf with the whole scientific packages ...
<pitti> doko: yes, what we just talked about in /msg
<doko> thanks
<pitti> doko: so they have arch: any -doc packages? that sounds quite weird
<pitti> I'd expect most -doc packages to be arch: all and only built on i386 where it's quite fast
<tjaalton> doko: i filed bug 903146, probably should do the same for debian
<ubottu> Launchpad bug 903146 in lintian (Ubuntu) "please add support for globbing" [Undecided,New] https://launchpad.net/bugs/903146
<doko> tjaalton, yeah, having it in debian would be better, I assume
<pitti> jamespage: so what was the latest word on the libcegui-mk2-1 NBS stuff?
<pitti> jamespage: (about rollback/package dropping/porting)
<jamespage> pitt: so; 2 packages; both have non-trivial fixes; bug are/have been raised in debian
<jamespage> I also raised bugs in LP for tracking
<pitti> jamespage: ok, so we keep the new version then?
<jamespage> pitti: for the time being - I suggest that we leave it a few weeks
<jamespage> appreciate it clutters NBS a bit
<pitti> jamespage: WFM
<jamespage> but gives upstream/debian maintainers a change to response
<pitti> jamespage: so, libnautilus-extension1a is complete now; need to catch up with wendar about the magic++ FTBFS for libgrib-api-0d-1
<pitti> jamespage: I talked to gilir last Friday, he's looking into awn-extras
<pitti> jamespage: so that leaves indi, fgfs-atlas, and the poppler stuff to us
<jamespage> pitti: I am looking at fgfs-atlas
<jamespage> pitti: indi can be dropped now BTW
<pitti> jamespage: the Debian poppler maintainer wrote that he has already looked into 0.18 patches and sent them to various upstreams, BTW; so it might make sense to check upstream gits for patches first
<pitti> jamespage: oh, NBS just updated
<pitti> lp-remove-package.py -u $SUDO_USER -m NBS -b -y indi libnautilus-extension1
<pitti> \o/
<pitti> (done)
<jamespage> pitti: great
<pitti> jamespage: I also fixed some more upgrade bugs, so the lts->ubuntu tests now actually seem to succeed
<pitti> jamespage: did you see my question about the failed tests in scrollback?
<jamespage> pitti: ah - I had not scrolled far enough back
 * jamespage reads
<pitti> eh, WTH: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> I'll investigate
<pitti> nothing changed there, and it's not the new format with build links and apt output
<pitti> . o O { wow -- keeping queues to a small number is rather easy -- keeping them at 0 is incredibly much work.. }
<jamespage> pitti: 10x the work for the last 1% of issues :-)
<pitti> yeah, as always
<pitti> quite natural to to the easy stuff first, to get a better overview and throughput
<pitti> ScottK, Riddell: koffice-l10n wants to go to universe all of a sudden; did something change there? is that on purpose?
<tjaalton> doko: heh, so 2.5.0~rc4 got full support for wildcards :)
<pitti> jamespage: hah, better: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> I created more chdists with only the "main" component
<pitti> this would also have told us about the kubuntu-full failure some days ago
<pitti> ok, fixed the overrides for libindi-data
<pitti> should be good in anhour
<cjwatson> micahg: reiser4progs> go ahead
<cjwatson> micahg: my attempts to upload it got rejected for one reason or another; feel free to figure it out :-)
<cjwatson> apw: not that I recall
<apw> cjwatson, looking like an osprober issue currently
<cjwatson> os-prober usually just exposes somebody else's problems :)
<ScottK> pitti: It's probably because of the switch from koffice to calligra packages.  I'd guess it's not on purpose, but Riddell was handling that, so let's wait for him.
<Riddell> what what?
<akher0n> ScottK: have you seen https://bugs.launchpad.net/pydkim/+bug/901591
<ubottu> Ubuntu bug 901591 in pydkim "Better signing performance" [Undecided,New]
<ScottK> akher0n: No.  I hadn't (and I'm not sure why as I'm subscribed for bugs like that).  Thanks.
<ScottK> Riddell: <pitti> ScottK, Riddell: koffice-l10n wants to go to universe all of a sudden; did something change there? is that on purpose?
<Riddell> ScottK, pitti:yeah the seeds changed here, calligra is in New now waiting for an archive admin
<smoser> jamesh, ping
<pitti> Riddell: ah, so koffice-l10n should be demoted or removed?
<Riddell> pitti: it'll be removed but I'd like to test that apt correctly installs calligra first
<pitti> Riddell: ok, so I'll keep it in component-mismatches as a reminder
<ogra_> argh, Laney owns -changes once again
<Laney> muhahaha (and NEW)
<ogra_> :)
<smoser> jamesh, well, if you see this, see bug 886439
<ubottu> Launchpad bug 886439 in upstart (Ubuntu) "upgrade to upstart 1.3-0ubuntu11 causes unclean shutdown" [High,Confirmed] https://launchpad.net/bugs/886439
<smoser> upgrade of upstart to oneiric -updates causes dirty filesystem on reboot.
<stgraber> smoser: something tells me you may want jodh instead :)
<doko> mvo, did you break rapt?
<mvo> doko: I hope not, what error do you see?
<smoser> hm... something tells me you're right stgraber
<smoser> what was i thinking.
<doko> mvo, sea query
<doko> see even
<mvo> thx
<tkamppeter> pitti, hi
<pitti> tkamppeter: hello
<tkamppeter> pitti, it is about your message of replacing the python-gobject dependencies by python-gi. This would be the case for system-config-printer. Do I simply need to replace the dependency or are there API changes?
<pitti> tkamppeter: no, it doesn't apply there, s-c-printer doesn't use GI but the old static stuff
<pitti> tkamppeter: so you don't need to change anything there
<tkamppeter> pitti, thanks.
<pitti> jibel: mythes-de> argh, another one? I'll fix it ASAP, tahnks
<jibel> pitti, yw. I hope it's the last one :)
<pitti> jibel: I was quite happy to see that a lot of the upgrade tests actually finish now, and "just" fail in the post-upgrade tests
<pitti> jibel: I fixed the freetds one this morning, which broke main-all
<pitti> so looking forward to tomorrow's
<pitti> jibel: did you see my question from this morning about the failing tests?
<jibel> pitti, me too, and they fail with /minor/ bugs
<pitti> in particular, the complaints about .dpkg-dist?
<jibel> pitti, no, I didn't
<jibel> pitti, what was the question ?
<pitti> pitti   jibel, jamespage: so https://jenkins.qa.ubuntu.com/view/Precise/job/precise-up
<pitti> grade/PROFILE=lts-ubuntu,label=upgrade-test/lastBuild/console -> the upgrade succeeded now, and it rebooted, b
<pitti> ut it complains about some extra old conffiles and X not starting?
<pitti> pitti   jibel, jamespage: and similarly for lts-server, it just complains about conffi
<pitti> les? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=lts-server,label=upgrade-test/last
<pitti> Build/console
<pitti> pitti   jibel, jamespage: what does this test do exactly? having .dpkg-dist files is p
<pitti> retty normal after an upgrade
<pitti> sorry for the broken line endings
<pitti> X not starting does sound serious, of course
<jibel> pitti, the post-install test check for any .dpkg-dist after upgrade which means there was a debconf prompt during upgrade
<pitti> jibel: oh, I see; so these ought to be investigated then
<jibel> pitti, I reported 3 bugs this morning about it. There shouldn't be any prompt since the original file was not modified.
<pitti> jibel: are they tagged in a particular way, or how can I find them?
<jibel> pitti, bug 903131,  bug 903137 and bug 903143
<ubottu> Launchpad bug 903131 in ifupdown (Ubuntu Precise) "lucid->precise upgrade - prompt to update unmodified conf files: /etc/init/networking.conf /etc/init/network-interface.conf , /etc/network/if-up.d/upstart" [Medium,New] https://launchpad.net/bugs/903131
<ubottu> Launchpad bug 903137 in base-files (Ubuntu Precise) "lucid->precise upgrade - prompt to update unmodified conf files in /etc/update-motd.d: 00-header, 10-help-text, 99-footer" [Medium,New] https://launchpad.net/bugs/903137
<ubottu> Launchpad bug 903143 in xdiagnose (Ubuntu Precise) "lucid->precise upgrade - prompt to update unmodified conf file: /etc/init/failsafe-x.conf " [Medium,New] https://launchpad.net/bugs/903143
<pitti> jibel: ah, they are already rls-mgr-p'ed, great
<jibel> pitti, and tagged qa-daily-testing
<jibel> pitti, I run main-all and now the upgrade starts but fail with a failure in openoffice
<jibel> I'll file a bug for this one as well.
<pitti> at least it can figure out the upgrade path now
<pitti> jibel: merci
<jibel> pitti, talking about upgrades, I found bug 902553 which was fixed with perl 5.14.2-6 but still reported with this version.
<ubottu> Launchpad bug 902553 in perl (Ubuntu Precise) "package doc-base 0.10.3 failed to install/upgrade: ErrorMessage: /usr/bin/perl: symbol lookup error: /usr/lib/perl5/auto/UUID/UUID.so: undefined symbol: Perl_xs_apiversion_bootcheck" [High,Triaged] https://launchpad.net/bugs/902553
<pitti> jibel: ok, thanks; putting on my stack of things to look at
<pitti> zul: thahnks
<pitti> zul: can you also drop python-coverage from keystone's b-deps?
<pitti> (see http://people.canonical.com/~ubuntu-archive/component-mismatches.svg)
<zul> pitti: yeah its dh_python2 adding them
<pitti> zul: no, this is a build dependency for keystone
<zul> pitti: ah ok
<pitti> seb128: did you sync vte3?
<zul> pitti: but yes i can drop it
<seb128> pitti, no, mterry was working on that it seems
<pitti> mterry: did you sync/upload vte3?
<pitti> it conflicts with our vte package, and now the world is broken (http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html)
<pitti> so I suppose it should go to main, and replaces the GTK 3 parts of our vte source?
 * pitti promotes it
<seb128> pitti, there is a mir bug from mterry yes
<seb128> not sure why he opened one though, I just read it on the ubuntu-archive list today
<pitti> it was mainly the -common package which was missing
<pitti> nothing on https://launchpad.net/ubuntu/+source/vte3/+bugs
<pitti> but anyway, now we need to change our vte source to drop the -2.90 parts
<seb128> pitti, right, the bug was opened before the upload and is on vte
<seb128> there was no vte3 source in launchpad yet
<seb128> well I'm sure mterry is on it
<mterry> pitti, I uploaded a new vte yesterday, still haven't gotten an ACK from the archive
<pitti> mterry, seb128: ah, found and closed the MIR bug, thanks
<seb128> mterry, your upload probably got rejected for some reason
<pitti> mterry: it's inhttps://launchpad.net/ubuntu/+source/vte3/1:0.30.1-2
<pitti> imagine a ": " there
<mterry> seb128, didn't get a rejection notice...
<seb128> mterry, well I mean if you uploaded and it didn't make it in
<mterry> pitti, I'm talking about new vte that drops the 2.90 bit
<pitti> anyway, need to run, time for Taekwondo
<mterry> :)
<seb128> mterry, try again just to be sure?
<pitti> mterry: ah
<mterry> seb128, yar
<seb128> pitti, 'night
<pitti> anyway, archive should be happier in an hour; I'll check later tonight when I'll be at the TB meeting
<pitti> cu later
<seb128> mterry_sprinting, oh, sprinting this week?
<mterry_sprinting> seb128, yeah, not much time for pure desktop stuff i'm afraid
<seb128> mterry_sprinting, have fun I guess ;-) (what is the sprint about?)
<mterry_sprinting> seb128, static analysis of unity
<seb128> mterry_sprinting, one day we will get you back in desktop, trust me ;-)
<mterry_sprinting> :)
<mterry_sprinting> seb128, I'm here just to provide help with packaging
<seb128> ok ;-)
<james_w> pitti, hi, looks like you might have had a bit of a fight with yourself? https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/apvlv/precise-201112121632/+merge/85359
<smoser> is ia32-libs-multiarch known broken at the moment?
<smoser> (seems broken to me, uninstallable, but is that known ?)
<tumbleweed> smoser: https://lists.ubuntu.com/archives/ubuntu-devel/2011-October/034279.html
<smoser> tumbleweed, i dont think that is relevant.
<smoser> unless i'm reading something wrong, i still expect : 'apt-get install ia32-libs-multiarch:i386' to work
<tumbleweed> ah, I've just had no expectation of it being usable in precise, so haven't beeen paying attention to it
<smoser> tumbleweed, its been close to usable..
<smoser> the use case is google+ :-(
<tumbleweed> smoser: looks to me like a fair number of its dependencies aren't multi-arched yet, as I expected
<smoser> hm.. well up until last week or so, i was functional
<ogra_> and you shouldnt need that complex apt line above
<ogra_> apt-get install ia32-libs should just DTRT as i read that mail
<smoser> yes
<smoser> and that has issues :)
<ogra_> yeah, help porting the remaining bit sto speed up the fixing ;)
<tumbleweed> it's not that far off, by the look of it
<slangasek> smoser: that certainly is relevant - ia32-libs-multiarch is broken until all the libs are converted
<smoser> slangasek, so how was i getting by previously
<slangasek> previously you presumably were not running precise? :)
<micahg> cjwatson: re reiser4progs> thanks, will work on it later tonight
<slangasek> ia32-libs has not been installable in precise since I sent that mail
<tumbleweed> slangasek: I'm impressed how close it is, though. I only spotted two blocking packages in a quick look now
<smoser> slangasek, i've been on precise since probably 3 weeks.
<smoser> and its been working..
<tumbleweed> (but I bet they have dependencies of their own)
<slangasek> tumbleweed: there are quite a few more than that, but nothing too unmanagable
<slangasek> smoser: then you had the oneiric version of ia32-libs-multiarch:i386 installed
<smoser> i'm not sure how.
<cjwatson> if you upgraded from oneiric it might still have been there, and then perhaps some upgrade caused it to be removed
<micahg> do -meta package updates need to be run on precise now with the new germinate or can we still use oneiric?
<jdstrand> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh, jdstrand
<apw> slangasek, i think i need to do some poking on this udev thing on the machine which is affected, i have been testing the theory and its not stacking up quite right
<apw> slangasek, and i think i am only going to make any progress if i can put some kernels out for test, to find out what udev is really doing
<smoser> bug 886439, Sp4rKy
<ubottu> Launchpad bug 886439 in upstart (Ubuntu) "upgrade to upstart 1.3-0ubuntu11 causes unclean shutdown" [High,Confirmed] https://launchpad.net/bugs/886439
<smoser> oops
<smoser> SpamapS, ^
<SpamapS> smoser: how do I boot a halted instance from euca tools?
<smoser> start-instances
<smoser> euca-start-instances (should work). thats a new command to euca (long time in ec2-start-intsances)
<SpamapS> smoser: I think this is caused by /var/run being a symlink somehow
<SpamapS> Or even more sinister actually
<SpamapS> looks like /var/run is *removed* and unmounted before this point
<SpamapS> DOH
<smoser> or /run gets mounted
<smoser> yeah
<smoser> :)
<SpamapS> Hah yeah, RIGHT before
<SpamapS> as part of the transition/upgrade process
<SpamapS> fix, I think, is to move the check for it right before we torch the whole thing
<SpamapS> http://paste.ubuntu.com/768202/
<SpamapS> smoser: ^^ happens just before we check the contents of /var/run ... WHOOPS
<SpamapS> trouble with that
<SpamapS> -d returns true on a *symlink* to a directory
<SpamapS> so we're clearing out /var/run even when we don't need to
<stgraber> sounds like we want "[ -d /var/run ] && [ ! -L /var/run ]" then
<stgraber> or actually the other way around if we want to optimize it a bit
<SpamapS> Not sure yet
<SpamapS> More importantly, we have to check for things inside this dir before deleting all the contents. ;)
<SpamapS> yeah, simply re-ordering the operation works flawlessly
<slangasek> SpamapS: where is that code from?
<SpamapS> slangasek: umountroot
<SpamapS> slangasek: right before the check for init.upgraded
<slangasek> SpamapS: oh, hah
<smoser> SpamapS, [ -d symlink-to-directory ] && echo yes
<smoser> will echo yes
<smoser> $ rm -f foo ; ln -s /etc foo && [ -d foo ] && echo yes || echo no
<smoser> yes
<slangasek> SpamapS: yes, we should both check that it's not a symlink there, and check for the sentinel file *before* removing it ;)
<smoser> so i dont see why you'd test if it was a link, or why you'd care.
<slangasek> smoser: because this code is here *solely* to migrate it *to* a symlink
<slangasek> if it's already a symlink, there's nothing to migrate
<slangasek> actually
<slangasek> no, because we immediately recreate it with the same target
<slangasek> so we don't need to check for it being a symlink, but we *do* need to check the sentinel first
<slangasek> since in the upgrade case, rm -rf /var/run isn't removing a symlink, but real contents
<ajmitch> SpamapS: are you still considering php 5.4 for precise?
<SpamapS> slangasek: yeah, just moving the sentinel block before all those checks fixes bug 886439
<ubottu> Launchpad bug 886439 in upstart (Ubuntu) "upgrade to upstart 1.3-0ubuntu11 causes unclean shutdown" [High,Triaged] https://launchpad.net/bugs/886439
 * slangasek nods
<SpamapS> ajmitch: I'm almost convinced it won't be ready in time.
<ajmitch> SpamapS: given that they're still releasing RCs, I'd tend to agree
 * ajmitch has RC3 built in a PPA now to test
<SpamapS> ajmitch: been watching the churn on the ML.. regular bugs.. but still.. not ready I think.
<ajmitch> it'll be a typical .0 release then
<SpamapS> slangasek: Ok, so I was thinking I'd upload the "wait for stop/killed" change and this change to precise together. Any objections, or do you want to hold off on the stop/killed change a bit longer?
<slangasek> SpamapS: did you happen to catch my comment on here about thinking stop/killed pids should also be included in omitpids, so we don't kill the processes twice?
<slangasek> it may not be worth it because every process has a sensible signal handler that copes with multiple -HUP... but then again...
<SpamapS> slangasek: I didn't, but that does make a lot of sense.
<slangasek> SpamapS: do you think it's worth doing?  I'm not sure it should block the upload anyway
<SpamapS> slangasek: I think its worth doing yes... we *know* it has already been killed.
<slangasek> ok
<SpamapS> slangasek: and its fairly easy
<SpamapS> slangasek: I'll update the MP
<slangasek> ok
<SpamapS> slangasek: is there any issue with using grep -E in initscripts ?
<slangasek> SpamapS: nope
<SpamapS> alright sweet then its really easy
<SpamapS> slangasek: one thought, though I don't think this is really important.. with the way it is now, the processes keep getting killed over and over during those 10 seconds ..
<SpamapS> slangasek: whereas upstart just kills once, then waits for kill timeout
<slangasek> hmm, really?  that seems buggy
<slangasek> there's certainly no good reason to re-kill processes while waiting for the timeout
<slangasek> OTOH, it may be prohibitive to track which processes have already been killed and which haven't, for the general case... since there may be new pids being started during that window
<slangasek> and we need to make sure we kill them all
<SpamapS> exactly
<SpamapS> I think upstart just does this more elegantly
<pitti> james_w: fight with myself> yes, and I won :)
<james_w> good for you :-)
<pitti> james_w: I started with 3.0 (quilt), then noticed that the source already had inline changes, but only at the final step of building the source; then I gave up and just built it the classic way
<pitti> james_w: I rejected the MP
<cjwatson> micahg: oneiric is fine; germinate 2.x shouldn't change the behaviour of germinate-update-metapackage, even though the code has changed around a fair bit for other reasons
<micahg> ok, thanks
 * pitti groans at http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -- so much damage in 4 hours :(
<james_w> pitti, thanks
<pitti> ok, cleared up some problems, most of the rest is just buildd lag
<soren> What's the name of that gui tool that lets you enable a whole bunch of graphics logging?
<slangasek> pitti: heh, right - odbcinst1debian2 Breaks: libiodbc2 is going to render kubuntu uninstallable until soprano gets fixed
<micahg> soren: xdiagnose
<micahg> soren: that was meant to be a question :)
<soren> micahg: Excellent. Yes, thanks. :)
<pitti> slangasek: oh, argh; so I guess I need to revert that breaks for the time being? I figure the packages aren't similar enough to warrant a Provides:
<slangasek> they most certainly are not, they're libraries
<slangasek> so yeah, revert is better
<slangasek> pitti: ^^
<pitti> slangasek: curiously enough, soprano isn't even on precise_probs
<JLuc> hello
<JLuc> On scribus, on ubuntu, texts in hint bubbles over buttons have white fonts on white background. It seems to be ubuntu's fault. Any chance it to be corrected soon ?
<slangasek> pitti: it'll be some set of packages that are seeded together, rather than a direct conflict, fwiw
<slangasek> pitti: and seemingly only on kubuntu dvd, also
<psusi> if package C is only useful if both package A and package B are installed, there's no way to get package C to be recommended if you choose to install both A and B is there?
<tumbleweed> no
<psusi> blast
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<lardman> any tips on debugging upstart problems? I had a load of unconfigured packages in my ARM chroot image, but it would boot to a login prompt, but since fixing that and running "dpkg --configure -a" it stalls and never gets to a login
<beuno> does anyone know where the announcement for keeping Precise stable throught the release cycle went to?
 * beuno stares at pitti 
<slangasek> lardman: I don't quite understand what you mean; you can't exactly boot a chroot.  Was this a chroot you were using to prepare a disk for booting?
 * beuno assumes http://www.piware.de/2011/11/12-04-testing-ftw/ is enough
<broder> beuno: i don't know that there was an announcement of the plan. if you give me a sec i can probalby find the uds blueprint
<beuno> thanks broder
 * beuno is blogging to encourage more people to upgrade to Precise _today_
<broder> beuno: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-always-works-daily-iso is the blueprint but doesn't actually seem to have been updated post-uds
<broder> http://pad.ubuntu.com/uds-p-foundations-p-always-works-daily-iso is the notes from the session
<broder> there's also https://wiki.ubuntu.com/PlusOneMaintenanceTeam
<beuno> broder, sweet, thank you
<broder> np
<SpamapS> slangasek: just pushed up an update to https://code.launchpad.net/~clint-fewbar/ubuntu/precise/sysvinit/wait-for-long-shutdown-jobs/+merge/85208 that fixes bug #886439 .. pretty straight forward, and tested on oneiric.. testing on precise now...
<ubottu> Launchpad bug 886439 in upstart (Ubuntu) "upgrade to upstart 1.3-0ubuntu11 causes unclean shutdown" [High,Triaged] https://launchpad.net/bugs/886439
 * doko curses Laney or haskell builds even failing on i386 ;p
<doko> even for
<Laney> heh
<Laney> it all comes out in the wash
<micahg> Laney: is there any hope for haskell on non-x86 archs?
<Laney> it at least works somewhat
<ScottK> slangasek: It looks like boost-defaults making 1.48 default may land in Testing before autosync ends.  We ought to think about if we want to try to transition to 1.48 as default or not.
<Laney> nobody really does porting upstream though
<doko> so you already did give up for haskell on ix86 archs? ;-P
<Laney> no, that is just best effort as per upstream
<ScottK> slangasek: I don't have time to drive a boost transition, so I thought I'd mention it to someone before it was too late.
<doko> Laney, there are a few "key" packages which are just build for x86. can't these ported, or is it just missing?
<doko> ScottK, did it even start in debian?
<ScottK> doko: No, but there was a warning it's coming sent to debian-devel.
<micahg> doko: http://lists.debian.org/debian-devel/2011/12/msg00281.html
<ScottK> There's certainly a benefit to using the newer boost, but it's hard to say how hard a transition it'll be.
<doko> like db5.2
<ScottK> Since boost-defaults is sync'ed from Debian, we'll get it if it makes it to Testing unless we stop it.
<micahg> you could add it to the sync-blacklist to block it
<ScottK> One could.
<doko> how many packages do use explicit boost versions?
<ScottK> Mentioning it is as far as I've got time.  "someone" should decide what the best course is.
<ScottK> Most of the ones in Main I think.
<ScottK> All the KDE ones do.
<ScottK> My theory being switching boost versions isn't something you want to do by accident.
<micahg> doko: the last transition was ~270 packages
<micahg> http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html
<doko> well, most of these use the boost defaults
<Laney> doko: the main thing that is missing is template haskell, that impacts a serious number of packages
<Laney> well, the interpreter too and data parallel haskell, and performance improvements
<Laney> there's been some work done implementing the ghc calling convention in llvm for armel though, so maybe that will enable a registerised build there
 * Laney has to go, night
<doko> still curious why packages like haskell-src-exts ftbfs
<doko> but succeed on i386
<Laney> that's the timeout isn't it? not sure about that particular one. perhaps someone could do a manual verbose build and see what happens
<doko> no, memory exhausted. still waiting for the kernel mmap bug being fix to recheck this one ...
<doko> apw, ^^^ \o/
<doko> apw, before Christmas?
<lardman> slangasek: sorry for the slow response, yeah a chroot used for setup to be booted on a Galaxy Tab
#ubuntu-devel 2011-12-13
<SpamapS> argggh
<SpamapS> Packaging branch version: 2.88dsf-13.10ubuntu5
<SpamapS> Packaging branch status: OUT-OF-DATE
<SpamapS> >:
<slangasek> jibel: ping
<slangasek> SpamapS: thanks - would you like me to go ahead and merge / upload that branch, provided I'm happy with it?
<SpamapS> slangasek: I just finished testing it out on a local VM and an EC2 instance.. any objection to me just uploading it?
 * SpamapS is fixing up the bzr tree .. I think
<slangasek> ScottK: what do you think about the 1.48 transition question?  And how much time does it usually end up taking to manage one of these?
<slangasek> SpamapS: no objections provided it's correct ;)
<SpamapS> slangasek: Its just that branch, merged into the actual current packaging branch, including the two uploads from the last 24 hours that the package importer failed on..
<SpamapS> I imported them w/ import-dsc .. is that sufficient?
<slangasek> SpamapS: I don't see it failed here
<slangasek> SpamapS: you might want to bzr pull
<SpamapS> http://package-import.ubuntu.com/status/sysvinit.html#2011-11-30 14:42:44.885244
<slangasek> oh, no, those are your commits ;)
<slangasek> yeah, that's perfect then
<SpamapS> slangasek: I just fixed it already ;)
<SpamapS> slangasek: like my namesake, Mr. Eastwood, I feel lucky.. ;)
<slangasek> heh
<SpamapS> http://paste.ubuntu.com/768502/
<SpamapS> Thats the output of debdiff sysvinit_2.88dsf-13.10ubuntu7.dsc sysvinit_2.88dsf-13.10ubuntu8.dsc
<SpamapS> slangasek: I'd also like to backport that debdiff to oneiric-proposed as I believe both bugs need fixing in oneiric
<slangasek> SpamapS: diff looks good to me, aside from my sudden itching to replace grep | sed with a better sed; and yes, I agree these look like SRU candidates
<micahg> SpamapS: can I ask you an upstart question regarding when to start a certain app?
<SpamapS> micahg: sure.. can I make a bet that it will be "start on runlevel [2345]" ? ;-)
<micahg> SpamapS: no, it's about pppconfig starting on gdm
<SpamapS> slangasek: ok, uploading in couple minutes
<micahg> I think keybuk was trying to speed up boot, but I'm wondering if we need something like that anymore
<slangasek> we still care about boot speed
<SpamapS> micahg: pppconfig would seem to me to be in the realm of NetworkManager.. or do I misunderstand what it does?
<micahg> slangasek: obviously or I wouldn't be asking at all :)
<slangasek> heh :)
<slangasek> micahg: and we still define boot speed as "time to boot to an interactive desktop", so there's still value in deferred startup of non-essential services
<micahg> SpamapS: well, I could defer it until the login manager, but it seems to be a console app, so that seems wrong
<slangasek> but I don't know anything about pppconfig in particular
<micahg> slangasek: it seems to be a console app, so depending on the GUI to start seems wrong
<micahg> but I'm not aware of any other way to defer startup
<micahg> any ideas?
<SpamapS> micahg: why do you want to defer its startup?
<slangasek> micahg: hmmm, it looks like this isn't even an upstart job?
<micahg> SpamapS: I don't personally, the goal was to improve boot speed though
<slangasek> that's weird
<slangasek> are you trying to convert it to one?
<micahg> slangasek: oh, is it not?
<slangasek> micahg: it's an init script with 'Required-Start: gdm'
<slangasek> that change is a no-op currently in Ubuntu
<micahg> slangasek: is Required-Start ignored or specifically the gdm part?
<slangasek> micahg: required-start is hinting for insserv, which we don't use
<slangasek> oh wow, the pppconfig package contains no changelo
<slangasek> g
<micahg> then I'm confused about bug 671308
<ubottu> Launchpad bug 671308 in pppconfig (Ubuntu) "unnecessary init script dependency upon gdm" [Undecided,New] https://launchpad.net/bugs/671308
<slangasek> that's special
<slangasek> micahg: we don't use insserv; Q-FUNK may be using it at his peril. :)
<micahg> slangasek: since it's a diff with Debian, I can drop it then I guess, right :)
<slangasek> (in fact, I'm pretty sure I've seen other bugs on his systems caused by use of insserv)
<slangasek> sure
<micahg> great, solves my problem
 * micahg isn't sure why he assumed it was upstart
<SpamapS> slangasek: at this point, would it make sense to make running insserv a noop/warning ?
<slangasek> SpamapS: yes, we very much need to
<SpamapS> It really does seem to bugger the system
<micahg> slangasek: before I remove a po update rule on clean, I just wanted to check, we don't need this for anything in main specifically, do we?
<slangasek> micahg: it could very well be related to language pack handling
<slangasek> it depends
<micahg> :(, ok, I'll wait for pitti then
<micahg> it's not a diff we have, but dropping it lowers our diff
 * micahg is trying hard not to break precise :)
 * SpamapS is appreciating micahg's trying
<broder> bdrung, tumbleweed, Laney: can i sponsor syncs with syncpackage yet? possibly from the dailies?
<ScottK> slangasek: I would wait and see how the binNMUs go in Debian.  Most of the crufty won't build with a newer boost stuff is removed already, but each release is an adventure.
<pitti> beuno: there hasn't been a written announcement, but it was discussed/decided at UDS and made it into the blogosphere; also, there is https://wiki.ubuntu.com/PlusOneMaintenanceTeam whose mission that is
<pitti> micahg: what's up?
<pitti> micahg: po update rules on clean are indeed evil and should be removed, yes
<pitti> (evil because of pointless VCS noise)
<pitti> erkh, the new vte is missing some more patches apparently
<RAOF> Orly?  gnome-terminals now actually start for me :)
<pitti> RAOF: bug 903401; dist-upgrade again
<ubottu> Launchpad bug 903401 in vte3 (Ubuntu Precise) "symbol lookup error: gnome-terminal: undefined symbol: vte_terminal_set_alternate_screen_scrol" [Critical,Fix released] https://launchpad.net/bugs/903401
<pitti> RAOF: hit me this morning as well, pretty big WTF
<pitti> but apparently we are still missing the patch for unbreaking Alt
<RAOF> Ah, I might just have not noticed it.
<pitti> or it is because we had a different workaround
<TheMuso> pitti: Just update and all is fine, I got the same symbol look up error.
<pitti> TheMuso: yes, so I discovered; I updated above bug accordingly
<TheMuso> And alt stuff is still working ok for me.
<pitti> TheMuso: yes, I remember that I had to update my weechat keybindings a few weeks ago, and now they are back to normal
<micahg> pitti: thanks, I managed to drop 50 lines of po diff with a 2 line debian/rules change :)
<pitti> apparently our workaoround was slightly broken, the current one is better
<TheMuso> Yeah, I am still subscirbed to the bug, nothing committed upstream as of yet.
<pitti> micahg: the only important thing is that the package either has, or even better builds a current *.pot file during package build
<micahg> pitti: I don't think it does that, but it does seem to generate .mo files
<pitti> that's fine of course; these are the ones that are actually being used at runtime
<pitti> TheMuso: yeah, just lots of CCs :) (I'm subbed as well)
<micahg> pitti: got a minute to discuss Firefox Lucid and Maverick rapid release WRT langpacks?
<pitti> micahg: sure
<micahg> pitti: so how much time do you need before the new packages are in -proposed (I guess before the langpacks are built)
<pitti> micahg: for maverick, about 24 h; for lucid, I'd appreciate having a bit longer to get a current export (while we are at it anyway)
<pitti> micahg: hm, but on second thought we should perhaps not update to a new LP export
<micahg> pitti: ok, can you start an export and I'll make sure the packages are in -proposed by next Wed?
<pitti> micahg: as I suppose we need to release _all_ of the langpacks in a timely manner, not just the ones we got verification for
<micahg> pitti: ok, whichever you like, I just want to create a timetable of sorts for this
<pitti> yes, I'd like a timetable, too
<micahg> pitti: yes, that would be preferable
<pitti> micahg: ok, would this work:
<pitti> micahg: I'll see to preparing both by Friday, so that they can build in -proposed over the weekend?
<pitti> micahg: it's about 1200 packages or so
<micahg> pitti: you need firefox in there first, right?
<pitti> micahg: if we want to avoid breaking translations for users of -proposed, then yes
<pitti> micahg: if we want to do it over the week, we have to cross fingers that we don't get another haskell transition etc. in the meantime
<pitti> the buildds are still catching up on those, although i386 is done
<micahg> pitti: ok, weekend sounds fine, I'd like to have everything done before we all go on vacation (including a call for testing), that should give us ~2.5 weeks bake time in -proposed
<pitti> micahg: you mean you can have firefox in -proposed by Friday, too?
<pitti> that would be ideal buildd wise
<micahg> pitti: wait, you want Firefox by Monday or Friday in -proposeD?
<pitti> micahg: it doesn't matter much, but of course <= time of langpack upload would be nicer
<micahg> I should be getting a final tag around Thursday, so it'll be tight
<pitti> micahg: anyway, I'll prepare the packs by Friday, and then wait for your "go"
<pitti> micahg: I can also do the actual upload/firefox accepting on Sat
<micahg> pitti: sounds good thanks, I was actually going to pre-build everything in ubuntu-security-proposed if that's ok (we might need to pocket copy some of these packages come Jan 31)
<pitti> micahg: if firefox is not in -proposed, I need a PPA with it in order to build the langpacks
<pitti> u-s-p sounds fine
<pitti> as the langpack builder needs to check which languages have a firefox-l10n-XX
<micahg> either way, there should be a version of firefox in ubuntu-security-proposed by then, it might not be fina;
<micahg> *fina;
<micahg> *final
 * micahg is using ubuntu-mozilla-security for the 3.6 updates :)
<pitti> micahg: that's fine; as long as the set of translations doesn't change, it doesn't matter
<pitti> micahg: and if it really does, I can just add the recommends: manually before upload
<micahg> cjwatson: BTW, the problem with reiser4progs was that it ended up being uploaded as a native package at some point so syncpackage isn't smart enough to know it needs a fakesync since we had a mismatched tarball previously, I did a manual fakesync and LP seemed happy to accept
<pitti> micahg: https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages ?
<micahg> pitti: no, that'll have 3.6
<micahg> pitti: https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages
<pitti> ack
<micahg> pitti: let me check with chrisccoulson about that later, I know there are sometimes differences between the number of languages translated for beta and final
<pitti> infinity: can we borrow some armhf builders to help out with the severe armel backlog?
<micahg> pitti: there's an RT to restart the 2 stalled armel builders this morning
<pitti> slangasek: uploaded unixodbc revert now (sorry, just fell to bed after last night's TB meeting)
<pitti> slangasek: what is the newer version of libiodbc2? odbcinst1debian2?
<pitti> i. e. unixodbc-dev?
<micahg> pitti: one question, we need yasm 1.1.0 for Firefox 9, chrisccoulson prepared a yasm-1 package for lucid that's coinstallable with the current version, are we ok with that as well?
<pitti> micahg: sure; it's hardly a question of "if", just "how" :)
<pitti> micahg: parallel installable sounds fine, and it's not the kind of package which gets lots of security vulns
<tumbleweed> broder: yes, latest version in precise
<broder> just pass -s?
<tumbleweed> yes
<micahg> tumbleweed: I almost got it to work on a fakesync, but syncpackage wasn't smart enough to look past the current record for a mismatched tarball
 * micahg should probably file a bug
<tumbleweed> micahg: I don't quite understand that, so yes please :)
<tumbleweed> oh right
<tumbleweed> why would you need to?
<micahg> tumbleweed: if for some silly reason people upload a subsequent Ubuntu revision as native
<tumbleweed> i didn't think people were that crazy :P
<infinity> pitti: I already gave armel a few of the armhf builders.  Should settle shortly.
<pitti> infinity: ah, thanks
<pitti> well, where "shortly" is 10 hours
<infinity> Well, where "shortly" is .... Yeah.
<micahg> tumbleweed: I'm still not sure if it happened in Debian or Ubuntu, but someone did it :)
<pitti> armhf is going to finish earlier than armel :)
<pitti> but I guess at some point armhf becomes the preferred arch anyway
<infinity> pitti: The armhf estimate is a blatant lie. :P
<micahg> yes, it was 16 hours Friday afternoon :)
<pitti> infinity: ... based clearly on previous build times of packages on armhf? :-)
<infinity> pitti: But once they both reach 0 (which should be before I leave on vacation), I'll redistrubite the CPU time more evenly between the two.
<micahg> also hopefully at some point the old armel builders will go away and be replaced with the faster machines that hopefully have a chance of keeping up
<infinity> micahg: The babbages will go away when we get more Pandas or QuickStarts or something to replace them.  For now, we have to live with them a bit longer.
<infinity> (The whole mess could be replaced with a single 4U box from HP/Calxeda...)
<infinity> pitti: I'll give armel one more Panda for overnight and steal if back in the morning.
<micahg> pitti: the langpacks don't build against anything (packagewise), do they?  will we be able to pocket copy them to -security with Firefox 10?
<pitti> micahg: yes
<micahg> ok, hoping that was yes to the second question :)
<pitti> micahg: whoops :) it is perfectly fine to copy them from -proposed to -updates, yes
<pitti> it's just a bunch of data files
<micahg> pitti: well, I'm wondering about -security :)
<pitti> micahg: same thing
<micahg> ok
<lardman> morning, I'd like to disable the alsa-restore upstart script, so have commented out the start on line, but it still starts. Has my commenting out this line made it autostart or is something depending on it and starting it?
<lardman> and any ideas how I could find out in the latter case what might be starting it?
 * lardman goes to look at the upstart docs for the former case
<lardman> I wonder if I'd be better just replacing the exec line's binary to do something that will work, like echo?
<pitti> I don't see how it would get auto-started without the "start" line
<pitti> lardman: I believe there's something like touch /etc/init/alsa-restore.conf.disable or similar
<pitti> i. e. a tag file to ignore a job file, without having to touch the job file itself
<pitti> I just don't remember the actual naming convention
<slangasek> pitti: there is no "newer version" of libiodbc2.  There's libodbc1, which is the UnixODBC version instead of the iODBC version
<slangasek> pitti: so it's a question of consolidation
<infinity> pitti: That PNG optimising business seems to take longer than the actual build in some/many cases. :/
<infinity> pitti: (See the mrpt build on kitalpha that's been in optimisation land all day)
<infinity> pitti: Can we optimise the optimiser? :P
<pitti> infinity: doko_ already pinged me about that yesterday; we disabled it now for -doc packages (although it's weird that armhf touches/builds -doc packages in the first place)
<pitti> other than that, you could just disable it entirely with globally exporting NO_PNG_PKG_MANGLE=1
<infinity> Yeah, that's a non-option to do on the buildd as a whole. :P
<pitti> but it still sounds wrong for non-i386 builds to build -doc .debs
<infinity> pitti: When was the disabling of touching -doc bits?
<pitti> infinity: around 20 hours ago
<infinity> pitti: Ahh, kay, so after this build started.
<pitti> https://launchpad.net/ubuntu/+source/pkgbinarymangler/110
<infinity> pitti: As for wrong or right, talk to the mrpt maintainer.
<cjwatson> micahg: OK, I guess you're luckier than me as I think I'd tried a manual fakesync and failed :-)
<pitti> Package: mrpt-doc
<pitti> Architecture: all
<pitti> *shrug*
<infinity> pitti: It's not uncommon for people to build arch-indep stuff on all arches, and then only package it in binary-arch.
<cjwatson> micahg: but that's great, thanks
<pitti> infinity: it's nothing to do with building stuff
<infinity> pitti: It's operating on ./usr/share/doc/mrpt-doc/html/inherit_graph_1030.png right now.
<pitti> infinity: it's about calling dpkg-deb to really _build_ the -doc .deb
<pitti> which is what triggers optipng
<micahg> cjwatson: it took a lot of hacking to get the tarball to line up and make a source package
<infinity> pitti: ... that can't possibly be happening here...
 * infinity looks.
<pitti> infinity: so I figure this build did call dh_builddeb on mrpt-doc?
<micahg> cjwatson: and I just successfully sync'd a package through LP for someone else, so another thing to save you some time with :)
<infinity> pitti: FFS.  Yeah, it looks like mrpt has no binary-arch/-indep split.  They're living a decade in the past.
<pitti> will the buildd just discard any built _all debs?
<infinity> pitti: And it took 6 hours (!) to build on amd64, most of which was PNG optimising.
<pitti> trying to upload them will be ... not funny
<pitti> infinity: pkgbinarymangler 110 will greatly help there
<pitti> infinity: it might actually be faster to cancel the build and build it again?
<infinity> pitti: Yeah, dpkg-buildpackages calls dpkg-genchanges -B, so any arch:all stuff just gets dumped.
<infinity> buildpackage, even.
<speakman> When installing dev packages using "apt-get builddep package", how do I remove them after finished build?
<infinity> speakman: Copy and paste the apt output and feed it back to "apt-get purge"? :)
<pitti> speakman: my approach is to copy&paste the "newly installed packages:" output from apt-get into a file
<pitti> and then ... yes, what infinity says
<speakman> oh, I'll just keep doing it that way :p
<pitti> sudo dpkg -P $(< purge.txt)
<micahg> speakman: you might want to use mk-build-deps -i -r instead so you get a single package to remove everything
<speakman> micahg: didn't know of that
<micahg> you can run it in a source dir to get the new build-deps as well
<pitti> kees: FYI: https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview
<infinity> pitti: Also, I'm giggling at anything that takes 7 hours to build on roseapple.
<infinity> pitti: Is there a way you can leverage DEB_BUILD_OPTIONS="parallel=N" to parallelize your optipng stuff?
<micahg> infinity: I had a build fail on roseapple and build fine a few minutes later on vernadsky, I think roseapple is troubled
<pitti> infinity: yes, should be possible; care to file a bug for this?
<pitti> infinity: (can't get to it right now, have lots of OMGurgent stuff on my plate today)
<infinity> micahg: In this case, not troubled.  Same build was over 6 hours on allspice.  Both crazy fast machines.
<speakman> micahg: hm, how do I install that .deb file using apt? dpkg won't download any dependencies by itself.
<infinity> pitti: Yeah, my plate's similarly scary, plus a need for sleep.  I'll keep these build records open as a reminder to care later.
<cjwatson> micahg: yay.  next thing is to implement mass-sync that way ...
<micahg> speakman: if you run it with sudo, it should install it as well I thought
<pitti> infinity: is "implement cancel button for builds" on that plate by any chance? :-)
<speakman> micahg: sorry, adding --install to mk-build-deps did the trick :) Very nice thing!
<micahg> pitti: PPAs have cancel buttons already :)
<pitti> right, I know
<micahg> speakman: -i is install
<infinity> pitti: It is.
<pitti> \o/
<infinity> micahg: And by "PPAs", you mean "Xen machines".
<micahg> infinity: umm, yes, that's what I mean :)
<infinity> micahg: And it's an awful hack.
<infinity> (Since it generates no build log, etc)
<micahg> infinity: same think with killing a native build
<micahg> *thing
<infinity> micahg: Err, lolwut?
<infinity> micahg: If you kill a process in a native build, you definitely get a log.
<micahg> infinity: ah, well, then someone should document how to do that for the people who do the killing :)
<infinity> micahg: But, anyway.  Going to fix it the way it should have been fixed years ago.
<infinity> micahg: Then we can stop with the madness.
 * micahg always gets the rug pulled out way of killing 
<infinity> Man, that ubiquity "checking if your hostname's taken" thing is great on a slow machine.
<infinity> I get a couple of seconds of red "YOU CAN'T USE THAT HOSTNAME!!" before it realises "oh wait, that's us."
<speakman> how do I tell debuild how many jobs it should pass to "make"?
<speakman> oh, -j13... surprising.. sorry for not checking first :)
<infinity> speakman: export DEB_BUILD_OPTIONS="parallel=3" (where "3" is the number you want)
<infinity> (Oh, that would be if using dpkg-buildpackage, you're probably right about debuild wrapping it more pleasantly)
<broder> -j is a dpkg-buildpackage option, but i think it only parallelizes the debian/rules file, not the actual build
<speakman> ok, I'll go with the env var option
<infinity> And hey, look at that.  Our first successful armhf+omap4 install from official images.
<speakman> how do I do a complete "make distclean" with debuild?
<speakman> armhf?
<speakman> hard float?
<infinity> speakman: debuild just calls debian/rules clean, it's up to the package if that does anything useful.
<infinity> speakman: (And usually distclean isn't the right option in a package build...)
<infinity> And yeah, armhf = hard float.
<speakman> ok, I'm trying to compile unity-2d but it's stuck complaining about a binary file has changed
<infinity> Because you changed a binary file?
<speakman> dpkg-source: error: cannot represent change to unity-2d-4.12.0/data/gschemas.compiled: binary file contents changed
<infinity> And you're trying to build a new source package?
<speakman> infinity: nope, apt-get source libunity-2d-private0 and then trying to build it
<infinity> If you're just building locally, you don't need to make a source package.
<broder> i think you can still just delete the file and it'll get cleaned up
<infinity> -B or -b will prevent building source.
<infinity> broder: That works if the goal was to build a source package, fails miserably if the goal was to build binaries. ;)
<infinity> broder: Since the original won't "come back" until the new source package is unpacked again.
<speakman> I interrupted the build at first time since it used only one of 12 cores. Now, dispite the env var "parallel=13" it still uses only one.
<broder> infinity: hmm..for some reason i had it in my head that dpkg-source will clean that up
<infinity> speakman: The package itself may not be set up for parallel building.  Can't magically change that.
<infinity> broder: Err.  It just ignores the deletion of the file.  So, on the next unpack, it's there again.
<pitti> debuild -j4 usually helps, though
<infinity> broder: But it won't magically restore things to your working tree.
<pitti> it exports MAKEVARS=-j4 or so which at least speeds up the compilation stage
<broder> infinity: ok. i believe you. certainly makes more sense than my theory
<infinity> pitti: Eww, does it really?
<infinity> pitti: It doesn't export DEB_BUILD_OPTIONS=parallel?
<pitti> -jjobs Number  of jobs allowed to be run simultaneously, equivalent to the make(1) option of the same
<pitti>               name. Will add itself to the MAKEFLAGS environment variable, which should cause all subsequent
<pitti>               make invocations to inherit the option.
<infinity> pitti: Cause the whole reason for the latter was because universally forcing the former can break a lot of things.  And having a dpkg-specific option meant people had to think about it.
<pitti> infinity: yes, it also does that
<infinity> pitti: Yeah, okay.  That's just icky.
<pitti> but it means that you can locally build all packages with make -j4 easily
<pitti> but having the dh_* stuff done serially
<speakman> wasn't there a helper script for adding new entries in changelog?
<seb128> speakman, dch?
<speakman> Are there any "conventions" regarding which version to set when just testing patches?
 * apw tends to append ~lpNNNNvN to the end of the 'next' version
<speakman> where NNNN is revno and N is patch no?
<infinity> lpNNN would imply a bug number, I'm guessing.
<infinity> speakman: But for local testing, it really doesn't matter.  It's local. :P
<apw> yeah bug number and build number sort of thing, just anything ~ so that when you get the next official package it gets replaced
<infinity> speakman: I get such wonderful versions as 1.2.3-1arghfuckkill, and such.
<speakman> lol :)
<infinity> arghfuckkill >> arghfuck >> argh, obviously.  The more iterations through a bug fix, the more entertaining my changelogs.
<pitti> I usually use 1pitti1, 1pitti2, etc. until release, as "pitti" << "ubuntu"
<pitti> or ubuntu3pitti1 etc.
<pitti> just to stay in the habit of always staying below the next official version number
<infinity> (In other words, it doesn't matter, just don't upload a local revision)
<infinity> Really, the key here (and dch has options to do this automagically) is to make sure the target in the changelog isn't valid.  Then the version doesn't matter. :P
<infinity> (Common convention is "UNRELEASED")
<speakman> do you use dch or do you edit manually? Do you add another entry for each re-build or just increment the latest one?
<pitti> speakman: you don't need to touch it at all for local rebuilds
<cjwatson> doesn't matter; adding another entry only matters if you're uploading it somewhere
<pitti> just keep fixing stuff, then do the changelog
<infinity> Both dch and manually.  And what Colin said.
<infinity> (I do my changelog as I go so I don't lose track of what I changed, but whatever)
<speakman> oh - I could just use the entries already in there?
<pitti> bzr FTW :)
<micahg> speakman: backportpackage can help with a suffix for a local rebuild
<infinity> pitti: In a sufficiently long hacking session, 'bzr diff' without a changelog can be opaque to me by the time I'm done. :P
<pitti> infinity: right, I do commit for every separate fix
<infinity> pitti: Unless I was committing every few tweaks, which is about the same documentation as a changelog.
<pitti> but I tend to fix first, and then write teh changelog and commit
 * apw wishes bzr had a good 'squash all these commits into the fix please'
<pitti> "debcommit" also FTW
<infinity> Yeah, debcommit's nice.
<infinity> debcommit being completely VCS agnostic is even nicer.
<speakman> micahg: reading the man of packportpackage, I don't really see how it will help me :/
<pitti> jibel: do you know why bug 902947 doesn't appear on http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html ?
<ubottu> Launchpad bug 902947 in openthesaurus (Ubuntu Precise) "package mythes-de 20110119-2ubuntu2 failed to install/upgrade: update-openoffice-dicts: not found" [High,In progress] https://launchpad.net/bugs/902947
<pitti> jibel: the desktop bugs haven't changed in ages, I'm afraid something might be wrong there
<micahg> speakman: ah, sorry, nevermind :)
 * micahg needs sleep anyways
<speakman> micahg: :D
<jibel> pitti, lat update of this page "Tuesday, 06. December 2011 18:03 UTC "
<jibel> pitti, I'll ping skaet
<pitti> oh, that'd be it
<jibel> s/lat/last
<pitti> skaet: ^ is that cronned?
<pitti> actually, it's under /kernel-bugs/
<pitti> apw: do you know who maintains this? ^
<apw> pitti, almost cirtainly going to be one of bjf's, it has his options droppy
<jibel> pitti, right it's bjf
<speakman> no matter if both "parallel=13" and "-j13" is used, debuild still doesn't utilize more than one core :p
 * apw wonders when the last update to launchpad was ...
<pitti> speakman: debian/rules might overwrite MAKEVARS?
<apw> speakman, make can only parallelise things which are parallelisable too
<apw> speakman, if it has linear dependancy you lose
<speakman> on the other hand; unity2d seems to be build with Qt, hence using qmake which maybe isn't handled correctly(?) by dpkg_buildpackage?
<pitti> qmake might not look at MAKEVARS indeed
<infinity> speakman: You're worrying far too much about it.  The build would have been done by now if you didn't keep cancelling it. :P
<speakman> YES!! The patch works perfectly! :) (bug 880698)
<ubottu> Launchpad bug 880698 in unity-2d "panel 2D uses wrong width on multi monitor setup (Xinerama)" [High,New] https://launchpad.net/bugs/880698
<pitti> so debian/rules needs to be fixed to respect parallel=n and translate that into whatever qmake understands
<speakman> the debian/rules seems to use "default" or something. it "override_dh_install" and "override_dh_auto_test", else it's just passed with "%: \n  dh $@ --with translations"
 * speakman is probably too much of a newb to fix it. 
<cjwatson> 'man dh', follow references from there; a good habit is doing lots of reading :)
<infinity> cjwatson: Oh, hey.  Did you still have "check grub2 with gcc-4.6" on your TODO for the vaguely nearish future?
<infinity> cjwatson: We're down to MySQL, grub, and u-boot being the only things keeping 4.5 in main.
<cjwatson> yeah
<speakman> cjwatson: I'm actually pretty used to RTFineM but I don't have the time right now :(
<ogra_> why u-boot ?
<cjwatson> I'll give it a try this week
<ogra_> that should seriously be ported to 4.6, shouldnt it ?
<infinity> ogra_: Cause bootloaders are stupid touchy about what gets spit out of the other end of a compiler, so it needs validation.  jcrigby is on it.
<ogra_> ah,k
<ogra_> as long as he's aware all is fine :)
<infinity> He is.
<infinity> And I might spend some time with MySQL later.
<cjwatson> GCC 4.6 did break GRUB Legacy until I worked around it, so it's not implausible
<cjwatson> (had to build with -fno-reorder-functions to stop unlikely-to-be-executed functions being reordered before _start which is supposed to have a fixed entry point)
<speakman> Another meta question; how do I tell I've tested a good patch on a bug? It's submitted in the comments but I don't see it's getting any attention. I've just changed the bug from "New" to "Confirmed" since we're at least two with different environments both having issues with the bug.
<speakman> And looking at the original source, there's no way this bug won't affect anyone with >1 monitors with different resolutions.
<speakman> In other words; what can I do to help get this patch applied officially and released?
<speakman> bug 880698 if you missed it above
<ubottu> Launchpad bug 880698 in unity-2d "panel 2D uses wrong width on multi monitor setup (Xinerama)" [High,Confirmed] https://launchpad.net/bugs/880698
<pitti> debfx, ScottK, Riddell: so turns out bug 901638 is now a pretty major blocker
<ubottu> Launchpad bug 901638 in unixodbc (Ubuntu Precise) "Remove iodbc2 (causes upgrade failure from Oneiric to Precise)" [High,Triaged] https://launchpad.net/bugs/901638
<pitti> debfx, ScottK, Riddell: do you happen to know if it's possible to build soprano without ODBC support (virtuoso) or against unixodbc instead of the obsolete iodbc2?
<pitti> debfx, ScottK, Riddell: failing that, I'm making some experiments now, but I'll need some hints how to test soprano
 * pitti remembers the good old days when data was still stored in files and sqlite databases instead of DB frameworks on top of DB frameworks on top of MySQL
<iceroot> !info unity-2d
<ubottu> unity-2d (source: unity-2d): Unity interface for non-accelerated graphics cards. In component main, is optional. Version 4.12.0-0ubuntu1.1 (oneiric), package size 4 kB, installed size 140 kB
<speakman> iceroot: are you looking at the bug/patch?
<iceroot> speakman: yes
<jibel> pitti, mvo , FYI I modified the auto-upgrade-tester and the jenkins job to report results in junit format. https://jenkins.qa.ubuntu.com/job/precise-upgrade/
 * speakman wishes Launchpad was getting a code review system one day :)
<iceroot> speakman: ubuntu-devel-discuss@lists.ubuntu.com
<jibel> now we have: green=pass, red=failed to upgrade, yellow=post-upgrade tests failed
<speakman> iceroot: great! :)
<iceroot> speakman: that is the maintainer-adress of that package
<pitti> jibel: ah, nice! less red there
<iceroot> speakman: i also added the tag "patch" to that bug
<cjwatson> iceroot: that's a placeholder and unlikely to be useful
<pitti> jibel: so main-all is broken by bug 901638, the rest are now conffile prompts?
<ubottu> Launchpad bug 901638 in unixodbc (Ubuntu Precise) "Remove iodbc2 (causes upgrade failure from Oneiric to Precise)" [High,Triaged] https://launchpad.net/bugs/901638
<speakman> iceroot: hm, ok? not really sure what that means (maintainer-address)...
<iceroot> speakman: olivier.tilloy@canonical.com
<iceroot> speakman: that is the unity-2d maintainer
<speakman> ok, great :)
<cjwatson> http://unity.ubuntu.com/getinvolved/ has a collection of links which might be more useful
<cjwatson> assuming this is an upstream bug
<pitti> jibel: test-xserver_test.py.FAIL sounds scary
<iceroot> cjwatson: i dont think that unity-bug are upstream-bugs :)
<jibel> pitti, right. main-all-amd64 failed to build a base image and there is another bug on server which the upgrade tester doesn't show. There is a 2 minute timeout on network start after upgrade
<cjwatson> iceroot: upstream for unity
<speakman> cjwatson: thanks! :)
<cjwatson> iceroot: as in the unity developers
<iceroot> cjwatson: hm ok
<jibel> pitti, I'll look at the "xserver failed to start" error today
<iceroot> speakman: i would suggest to contact olivier.tilloy@canonical.com by putting him on cc on launchpad or write directly a mail with an info about that bug and patch
 * speakman just found Canonical looking for passionate C/C++ coder. Maybe one should do this on full time... :P
<pitti> jibel: I suppose you have access to the machine after the upgrade is done, and we can collect package status and Xorg.log?
<speakman> iceroot: great, I fix that!
<jibel> pitti, yes, we keep the upgraded image until next run.
<mvo> jibel: yeah, thanks a bunch for this! I saw the merge request, but did not manage yet to process it
 * mvo hugs jibel - the new page looks *much* better
 * jibel hugs mvo back
<jibel> mvo, did you had a fix or know how to fix main-all-amd64 ? basically it installs both amd64 and i386 on the image. Is it just a matter of blacklisting the right packages ?
<mvo> jibel: I think I fixed this in the install_all.py - does the server carry the latest u-m bzr revision?
<pitti> jibel: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/ doesn't have main-all-amd64?
<pitti> jibel: is that bug 850264, or somethign different?
<ubottu> Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Triaged] https://launchpad.net/bugs/850264
<pitti> mvo: ^ speaking of which, do you need a hand with backporting a fix there?
<apw> pitti, does that report look any better
<pitti> apw: yay, thanks!
<pitti> apw: what was it?
<iceroot> speakman: great
<jibel> pitti, I removed the profile because it runs for hours and fails
<jibel> mvo, yes it does, I'll double-check
<apw> pitti, there is some deeper bug in the the report that some cached data is missing a field, i've made it ignore that for now, brad will have to figure out how it got in there; looks impossible
<jibel> pitti, it's different. the test tools doesn't even build the base image
<mvo> pitti: unfortunately the changes are pretty invasive, but I expect a new apt in precise soon
<apw> pitti, are you aware of the per team breakout on that page, for example: http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-desktop-bugs.html
<pitti> apw: not of that html page, but as the main page is already sectioned, that's good enough
<speakman> pitti: apw: Just adding "dh $@ --parallel" to the "%"-rule with do the trick... :)
<pitti> speakman: but not to convince cmake, I suppose? that'll only run the dh_* stuff in parallel?
<pitti> debfx, ScottK, Riddell: hm, soprano FTBFSes even with iodbc ATM
 * pitti looks into this
<speakman> pitti: It's compiling at 100% CPU ;)
<pitti> nice
<speakman> It's running dh_* stuff serially afaict. Will it even work doing it in parallel?
<speakman> pitti: However; can I make a "commit" with this change and push it to my local lp repo and then post a merge request?
<pitti> sure
<pitti> ScottK, Riddell, debfx: filed as bug 903638 FYI
<ubottu> Launchpad bug 903638 in soprano (Ubuntu Precise) "FTBFS: cannot find backends/sesame2/openrdf-sesame-2.2.4-onejar.jar" [High,Triaged] https://launchpad.net/bugs/903638
<pitti> not sure how to fix that
<debfx> pitti: probably by merging http://packages.qa.debian.org/s/soprano/news/20111204T164452Z.html
<debfx> pitti: virtuoso is the backend that KDE actually uses so I don't think we can drop it
<pitti>    * Pass -DSOPRANO_DISABLE_SESAME2_BACKEND=ON to cmake. (Closes: #649443)
<pitti> ah, that sounds promising
<pitti> debfx: ok
<pitti> debfx: that upstream bug report was from 2009, so it might be worth another try to build it against unixodbc and test it, I think
<pitti> debfx: thanks, that helped; I'll commit that to ubuntu:soprano
<pitti> debfx: I have a test package now which builds soprano against unixodbc; do you know how to test soprano?
<pitti> debfx: it's building in my PPA now
<debfx> pitti: not really. maybe enable indexing and see if it throws any error messages.
<pitti> debfx: so that thing is used for indexing files and finding contents?
 * pitti has absolutely no idea about what virtuoso, soprano, or nepomuk are, sorry
<debfx> pitti: yes, it's used for indexing and tagging files/mails
<debfx> though Riddell is probably better qualified to answer nepomuk questions
<debfx> nepomuk is the first thing I turn off on a new kubuntu installation :)
<Riddell> pitti: where is the build failure for soprano?
<pitti> Riddell: that's already fixed; well, it's "in precise"
<pitti> Riddell: but I committed the patch to lp:ubuntu/soprano
<pitti> s/patch/fix/ (it's just a debian/rules option, mirroring what Debian did)
<pitti> Riddell: I'm currently downloading teh current kubuntu desktop to give some testing to soprano in https://launchpad.net/~pitti/+archive/ppa, but I'd appreciate some guidance there
<pitti> Riddell: in short, we need to drop the old libiodbc and move to unixodbc
<pitti> in theory these are just implementations for the very same thing, but iodbc is dead and unixodbc is maintained upstream
<pitti> Riddell: so, I have kubuntu live system running in kvm now; I guess I need to enable indexing now? (first want to test with the current soprano)
<Riddell> pitti: it's disabled by default on a live system, I think that enabling it will work but not sure
<pitti> Riddell: is that "desktop search" in control center? it says nepomuk is active, but strigi disabled
<Riddell> right, so that should be fine
<Riddell> tagging and rating in dolphin should work
<pitti> Riddell: I created a hello.txt, but I don't see how to tag/rate it
<Riddell> pitti: do you have /usr/share/autostart/nepomukserver.desktop ?
<pitti> no, just nepomukcontroller.desktop
<Riddell> so it's disabled for the live session
<pitti> "nepomukcontroller" is running
<Riddell> maybe try running nepomukserver
<jibel> pitti, mvo the test-xserver_test.py.FAIL error is a false positive
<pitti> jibel: *phew*
<jibel> pitti, the test starts too fast
<jibel> pitti, and X is not started when it runs
<pitti> Riddell: hm, the "nepomukcontroller" package isn't installed, otherwise I don't find nepomukserver anywhere
<Riddell> pitti: you should have kde-runtime: /usr/bin/nepomukserver ?
<pitti> Riddell: I have the package isntalled, but it's not in there
<pitti> oh, ignore me
<pitti> apparently I typoed
<mvo> jibel: aha, thnaks for this, I will add a delay then - or did you do that already?
<pitti> Riddell: ok, tagging works now, thanks; testing that with my soprano package now
<jibel> mvo, go for it. I think we also need another post-upgrade test if the upgraded system fails to start in less than 60s (TBD). That would catch services timeout.
<pitti> Riddell: ok, so that doesn't work :(
<mvo> jibel: I made it wait up to 100s now
<pitti> Riddell: I updated the bug with the error message
<debfx> I wrote a script for kubuntu that shows the package differences between the image of the last release and the current daily image: http://felix.fobos.de/kubuntu/kubuntu-precise-cd-amd64-diff.htm
<debfx> it might be interesting for other flavors as well so maybe it should be moved to ubuntuwire? who should I talk to about that?
<pitti> jibel: so, I'm afraid that main-all failure will stay around for a bit; I'm out of ideas how else to fix it, the soprano package isn't that easy to convert to unixodbc apparently
<pitti> Daviey: would it be ok to comment out keystone from the server seeds until bug 881464 and its dependencies are sorted out?
<ubottu> Launchpad bug 881464 in keystone (Ubuntu) "[MIR] keystone" [High,New] https://launchpad.net/bugs/881464
<pitti> Daviey: well, it doesn't actually break images right now, so I guess it's ok to leave it there as a reminder
<Daviey> pitti: yeah, would rather leave it in place, if that is ok.
<pitti> sladen: the "fonts-ubuntu-font-family-console" binary package wants to go to universe; is that ok, or should that be seeded somewhere?
<pitti> sladen: the description sounds a bit misleading; I don't have that package installed, but I do have Ubuntu Mono in active use
<pitti> oh, for *that* console
<pitti> sladen: so I figure we should seed it into some "supported", so that it's in main for people to install?
<lool> Sweetshark: Hey, I couldn't find a branch for precise in the pkg-openoffice/libreoffice.git Vcs; perhaps you didn't push it explicitly?
<Sweetshark> lool: its not there yet. I have been mostly working on fixing up the debian 3.5 branch so that ubuntu can be easily based on it/
<lool> Sweetshark: Ok
<lool> Sweetshark: I am looking at armhf support and have a debdiff and one question
<lool> Sweetshark: http://paste.ubuntu.com/768900/ but I suspect the platform_id thing wont work; would you think we could use the same as armel?  ISTR oo.o/lo have bridges which might break with the new sub-ABI  :-/
<jibel> pitti, ok, I'll blacklist this package and its rdepends to unblock the test.
<Sweetshark> lool: I have pushed the patch on my todo list. loic.minier@ubuntu.com <- thats the correct author entry ?
<doko_> infinity, so you did decide against killing mrpt?
<ogra_> hmm, where is $(RM) defined if thats used in debian/rules ?
<lool> Sweetshark: Sure
<lool> ogra_: make sets it by default
<ogra_> lool, well, then it sets it wrong :P
<ogra_> defaulting to -d
<lool> ogra_: it's set to rm -f by default
<lool> See Implicit Variables in make.info
<ogra_> not for the package i look at atm
<lool> ogra_: I'm just speaking from the context you gave  :-)
<ogra_> rm: invalid option -- 'd'
<ogra_> Try `rm --help' for more information.
<ogra_> thats the ftbfs of emelfm2
<ogra_> and rules just uses $(RM)
<lool> this makefile http://paste.ubuntu.com/768925/ if run gives "echo rm -f"
<lool> rm -f
<lool> ogra_: this is not in rules, it's in Makefile
<lool> clean: in Makefile has:         @rm -rfd $(OBJECTS_DIR)
<ogra_> aaah
<ogra_> thanks
<ogra_> grepping for rm didnt revel that somehow ... weird
<ogra_> grepping for rm -r does now though
<lool> that's because grep rm -r is a recursive grep  ;-)
<ogra_> well, properly quoted indeed :P
<ogra_> fun, no patch system or anything in this package
<ScottK> debfx: For Ubuntuwire, try on #ubuntuwire.
<geser> pitti: do you remember how the gnome-shell SRU in oneiric was done? onkarshinde found out that gnome-shell on powerpc got copied from precise to oneiric (see https://launchpad.net/ubuntu/oneiric/powerpc/gnome-shell/ ; bug #903382)
<ubottu> Launchpad bug 903382 in gnome-shell (Ubuntu) "[powerpc] Unsatisfiable dependency in oneiric" [Undecided,New] https://launchpad.net/bugs/903382
<pitti> geser: uh? no, we don't normally do that direction, and I don't remember that we ever had a case where this was justified
<pitti> geser: we did have some cases where oneiric was copied to precise, and powerpc only got built in precise
<pitti> geser: but perhaps LP grabbed that precise build into oneiric somehow then
<tumbleweed> this is one of those cases
<pitti> geser: so I guess we'll need a no-change upload
<pitti> powerpc had been broken in oneiric-proposed for quite a long time
<geser> "Copied from ubuntu precise-release powerpc in Primary Archive for Ubuntu" from the binary publishing entry for gnome-shell on powerpc for oneiric-updates
<Laney> so it was copied to precise before ppc built? and then somehow the ppc binaries were copied back
<pitti> ppc failed to build there, but I noticed too late
<debfx> ScottK: thanks
<onkarshinde> Just to add one point to discussion, powerpc FTBFS was just temporary. I retried the build yesterday and it built but failed to upload (because of same existing version).
<Laney> the down-copying is the bigger problem - could the tools catch this?
<geser> onkarshinde: upload a new version to oneiric-proposed and a new version to precise to get the versions and the debs right
<geser> and thanks for spotting this
<pitti> yes, powerpc builds work again
<onkarshinde> geser: Do I need to make upload to 'precise'? Or will the source be coped from 'oneiric-proposed/updates'
<pitti> please do upload to precise
<pitti> no, we can't copy the source only
<pitti> not uploading to dev release first was the reason which caused this kind of trouble in the first place :)
<pitti> well, I guess in that particular case precise is actually fine, isn't it?
<onkarshinde> yes
<onkarshinde> that is why I am wondering how exactly to approach the issue.
<pitti> ah, but we still need a precise upload
<pitti> as precise never got a gnome-shell upload
<pitti> onkarshinde: upload 3.2.1-0ubuntu2 into precise, so that it gets a precise build
<pitti> and then 3.2.1-0ubuntu1.1 into o-proposed
<onkarshinde> Fine.
<onkarshinde> pitti: oh wait. Isn't that wrong order? I will need to upload 1.1 first and then 2
<pitti> well, it doesn't matter much
<Laney> doesn't matter
<pitti> technically
<pitti> but policy wise, "precise first" is always correct :)
<onkarshinde> ok
<pitti> these days we don't even accept SRUs unless they are already fixed in the dev release
<onkarshinde> and in this case, there is nothing to fix in dev release. :-)
<pitti> except the rebuild, yes
<tkamppeter> pitti, hi
<pitti> tkamppeter: o/
<pitti> mysql-common | 5.1.58-1ubuntu3 |       precise | all
<pitti> mysql-common | 5.5.17-4ubuntu6 |       precise | all
<pitti> mysql-common | 5.5.17-4ubuntu6 | precise/universe | all
<pitti> how the heck could that happen?
<pitti> cjwatson: ^ did you ever happen to see this? it's causing all the madness in http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> apparently triggered by the mysql-5.1 upload from an hour or two ago
<pitti> wgrant: ^ perhaps you have an idea
<tkamppeter> pitti, it is about the USB backend of CUPS. See bug 902535.
<ubottu> Launchpad bug 902535 in cups (Ubuntu) "Unable to print to Lexmark S405 since upgrade to 11.10" [Undecided,Incomplete] https://launchpad.net/bugs/902535
 * onkarshinde leaves
<cjwatson> pitti: the BPPHs will be arch-specific even if the actual .deb isn't; so if somebody processed the binary uploads through NEW with the overrides that way, it would cause that duplication
<cjwatson> pitti: change-override.py -c main should fix it, anyway
<pitti> cjwatson: I promoted it back to main now, it just seemed like a bug
<cjwatson> kindasorta
<pitti> tkamppeter: hm, it doesn't seem to say it's a regression from the recent -proposed, is it?
<tkamppeter> Some manufacturer drivers need bi-directional communication with the printer. Formerly we had a USB backend which worked with both libusb and usblp and I wanted to get it upstream (http://www.cups.org/str.php?L3357) but Mike Sweet did not accept it, he told me I should better deprecate the usblp kernel module and compile the upstream backend in libusb mode. Now after several SRUs this works at least for uni-directional printing but bi-d
<tkamppeter> irectional is not implemented at all in it (http://www.cups.org/str.php?L2890).
<geser> https://launchpad.net/ubuntu/precise/i386/mysql-common shows the main version as superseded by the universe one (demotion?) for 5.5.17-4ubuntu6 and also 5.1.58-1ubuntu3 as published?
<tkamppeter> pitti, I do not want to say that we have a regression caused by an SRU but we have a regression against Natty, as bi-directional USB printer access stopped working for all non-HP printers due to the new CUPS USB backend not supporting it. The SRUs did only fixes for unidirectional printing and have no influence on this.
<geser> cjwatson: will the change-override also "fix" the published state for 5.1.58-1ubuntu3? (see https://launchpad.net/ubuntu/precise/i386/mysql-common)
 * ogra_ glares at the eukleides ftbfs and wonders how geser got it to build in natty ... it has -lncurses set in LIBS but no build dep on anything that includes ncurses
<pitti> geser: I can only hope so
<geser> ogra_: it looks like one of the build-deps pulled it in, at least the buildlog mentions that libncurses5-dev go also installed
<ogra_> geser, hmm, funny, that doesnt seem to be the case in precise anymore ... at least on armhf ... i'll just add it then, thanks
<geser> ogra_: libreadline-dev (direct build-dep) -> libreadline6-dev -> libncurses5-dev (at least in natty)
<ogra_> hmm, yeah, its the same in precise here
<ogra_> weird
<ogra_> probably a buildd hiccup, i also see its using unauthenticated packages
<cjwatson> pitti,slangasek: I've added uninstallable output for -updates now - see e.g. http://people.canonical.com/~ubuntu-archive/testing/lucid-updates_probs.html
<ogra_> i'll just give back and will see if it survives
<cjwatson> geser: should do
<pitti> cjwatson: oh, great! thanks
<pitti> cjwatson: I'll fix the langpack stuff
<ogra_> fun !
<ogra_> same issue on the next package in the ftbfs list
<geser> ogra_: in precise libreadline6-dev depends on libtinfo-dev instead of libncurses5-dev
<ogra_> not here
<ogra_> ogra@horus:~/devel$ apt-cache show libreadline6-dev|grep ncurses
<ogra_> Depends: libreadline6 (= 6.2-2ubuntu1), libncurses5-dev, dpkg (>= 1.15.4) | install-info
<ogra_> argh
<ogra_> crap, i shoudl use my precise chroot instead of checking on the oneiric host ... ignore me
<ScottK>  /ignore ogra_
<ogra_> heh
 * ogra_ digs a hole and hides in it
<tkamppeter> pitti, should we return with our USB CUPS backend until upstream make the libusb-based backend bi-directional?
<pitti> tkamppeter: I don't have a strong opinion, but it seems we already reverted half of cups 1.5 back to 1.4 at that point?
<psusi> say, doesn't the pae kernel run on a non pae cpu?  just disables pae if it isn't supported doesn't it?
<pitti> psusi: as far as I heared yesterday, no
<pitti> it will just immediately fail to boot
<pitti> if it did that, we wouldn't need to have an extra flavour
<psusi> I was wondering... odd... I could have sworn it would just disable pae
<psusi> or did at one point... maybe it broke?
<tkamppeter> pitti, not with the USB backend. We reverted the IPP backend. The SRUs on the USB backend are small patches to fix some problems but not reverting to 1.4.x.
<tkamppeter> pitti, and the USB backend we will not actually revert but re-apply a dropped distro patch.
<pitti> tkamppeter: ah, that sounds fine
<mterry> pitti, what code looks to see if pkgbinarymangler is installed and runs it if so?
<pitti> mterry: how do you mean?
<pitti> mterry: oh -- it diverts dpkg-deb
<pitti> and replaces it with a wrapper
<mterry> pitti, oh! interesting.  that doesn't show up in a dpkg -L natch, didn't think of it
<tkamppeter> pitti, problem of the patch is that upstream does not accept it and suggested me to go libusb-only instead. With the lack of bi-directional support of the libusb-based USB backend it seems to be pre-mature to deprecate usblp.
<pitti> tkamppeter: is it so important to have a bidir communication?
<tkamppeter> pitti, it seems only to be needed by some proprietary drivers like Lexmark's.
<tkamppeter> pitti, I got only aware of that via bug 902535.
<ubottu> Launchpad bug 902535 in cups (Ubuntu) "Unable to print to Lexmark S405 since upgrade to 11.10" [Undecided,Incomplete] https://launchpad.net/bugs/902535
<tkamppeter> pitti, one problem is also that Mike Sweet concentrates on the stuff which is needed by Mac OS X and drops everything which is not needed by Mac OS X. The Linux/Unix parts of the USB backends are formally continued in CUPS 1.6, but the feature request for bi-di support in the libusb-based part of the backend is not worked on for years.
<pitti> tkamppeter: so even if we have a patch he doesn't apply it, even though he doesn't want to maintain it by himself any more?
<tkamppeter> pitti, yes, http://www.cups.org/str.php?L3357 stays untouched and in personal mail he told me to drop usblp support and http://www.cups.org/str.php?L2890 also stays untouched, Mike has reported this one by himself but probably before he got to Apple.
<geser> pitti: the reason for the two mysql-common versions is that armhf is still waiting on building mysql-5.1 (which build mysql-common in the past (and still list it))
<tkamppeter> pitti, perhaps one must also look into the "hp" backend from HPLIP whether one could perhaps get some bi-di libusb code out of it into the standard CUPS USB backend.
<kees> pitti: cool, thanks!
<apw> is there a simple way to ask if it is possible to install a .deb without installing it.  ie if the deps it requires are installed
<pitti> apw: apt-get install foo --simulate
<apw> pitti, and if it is a local .deb ?
<pitti> apw: or say "no" if it does have dependencies, then apt will ask (but not if it's only a single package)
<pitti> apw: sudo dpkg -i --simulate foo.deb ?
<cjwatson> something with gdebi --apt-line maybe
<apw> pitti, :)
<cjwatson> or DIY with python-apt
 * pitti waves good night, have to run
<pitti> apw: this works for me with a local deb
<sladen> pitti: f-u-f-f-console.  That wants to be seeded for the server + UEC images
<sladen> pitti: so that the setfont stuff can be tied into it
<infinity> doko_: I got distracted by illness, and forgot to get it killed. :P
<bdmurray> pitti: is this a new feature of the retrace? https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/898756/comments/5
<ubottu> Ubuntu bug 898756 in aptdaemon (Ubuntu) "<type 'exceptions.NameError'>: global name 'resolver' is not defined" [High,Fix committed]
<broder> i have to run, but if somebody on ubuntu-branches could mark https://code.launchpad.net/~veger/ubuntu/oneiric/xvba-video/fix-for-871615/+merge/85452 as merged, i'd appreciate it
<SpamapS> hmmm
<SpamapS> https://launchpadlibrarian.net/87383267/buildlog_ubuntu-precise-i386.charm-tools_0.3%2B91-0ubuntu1_FAILEDTOBUILD.txt.gz .. I just realized this tries to listen on 0.0.0.0:8999 ... might buildds prevent that?
<janimo> ev, do you know which parts of ubiquity stack should I look at if I do not get an external disk as a viable install target alternative?
<janimo> on an arm pandaboard I only get the option of the MMC I booted from but not the USB external drive
<cjwatson> janimo: partman-base, probably
<janimo> cjwatson, thanks
<cjwatson> janimo: specifically parted_devices would be a good start
<cjwatson> then init.d/partman and work up from there
<apw> i have just had a report of a machine ending up a ton of package being deleted during update
<apw> is there anything bad known about right now ?
<apw> and /me has just asked for an upgrade and its threatening to remove a ton of packages including gnome-*
<apw> is this just transistional or did the world just end
<seb128> apw, do you have details on what got uninstalled? I did a new gtk serie upload, those can create installability issues on !i386 during a publisher cycle because -common is built on i386
<infinity> apw: Just that one should read the output of dist-upgrade when running a devel release.
<infinity> apw: And don't do it when it says scary things.
<infinity> apw: (It's transitional)
<apw> infinity, oh indeed.  i have said no :)
<seb128> apw, does it want to remove a libgtk-3-<something>?
<infinity> apw: "upgrade" will work fine.
<seb128> apw, what arch are you on?
<apw> t
<apw> this is amd64
<infinity> seb128: It wants to upgrade -3-common, and pull out, well.  Everything.  Not an uncommon scenario for GTK skew.
<infinity> It'll pass in a few hours.
<seb128> apw, ok, wait the next publisher run (i.e ~1h)
<apw> yes it is asking to remove gtk3 yes
<seb128> it just built on amd64 so it will catch the next run
<apw> ok will do
<ogra_> glade will also need a give back on armhf
<ogra_> seems it ran directly into that issue
<seb128> ogra_, on all !i386 yes
<infinity> ogra_: I know.  Watching it.
<ogra_> with wide open eyes :)
<apw> as long as it is transitional, life is good
<seb128> yeah, it should be fixed in one hour
<seb128> if not please tell me
<ogra_> yeah, its the usual gtk upload freeze
<seb128> be aware that I just uploaded a new gtk2 and new glib as well
<ogra_> yay
<seb128> so those might hit next and take another publisher run to sort
<ogra_> double the fun :)
<seb128> ogra_, indeed ;-)
<seb128> well, I will be nice until holidays now :p
<infinity> Heh.
<apw> infinity, so i have been told that apt-get update is bad as it doesn't install depends
<seb128> that was the non trivial stuff I had left to do
<ogra_> :)
<infinity> apw: It won't pull in new packages.  But it also refuses to remove anything.
<infinity> apw: Also, s/update/upgrade/ :P
<apw> seb128, so why don't we build this kind of exploding thingy in a PPA and copy it out when its complete
<ogra_> its the safer way to keep your system up to date
<seb128> can we do that?
<infinity> seb128: Yup.
<seb128> well nobody told me we can
<apw> seb128, we do our kernels that way for SRUs so i'd say so
<ScottK> It's technically possible.  I'm not sure it's allowed by policy.
<ogra_> that will need an upload to the archive for ppc, no ?
<infinity> ScottK: It's definitely allowed, we do it for toolchain stuff.
<ogra_> ordo we have any ppc PPAs
<infinity> ogra_: non-virt PPA.
<apw> ogra_, a de-virt PPA
<ScottK> infinity: I think toolchain and kernel SRUs are an exception.
<ogra_> so there are some
 * ogra_ didnt know
<infinity> ScottK: It was discussed at UDS as a more general solution for disruptive uploads, and I'm pretty sure the plan was to go ahead with using PPAs as staging.
<infinity> But maybe it never made it from talk to real-world use. :P
<ScottK> infinity: OK.  It would be nice then to have this documented so people would know when it's appropriate.
<tgardner> I just managed to toast a laptop, which makes me kind of cranky.
<ogra_> there are surely UDS notes somewhere
<infinity> tgardner: Well done?
<ogra_> if it was actually discussed in a session
<ScottK> ogra_: Yes, but random UDS notes really don't help for people that weren't in the room.
<ogra_> no, someone who was should surely write them up properly :)
<seb128> well they agreed at UDS in settings a staging ppa that anyone could use
<ogra_> (i wasnt mind you)
<seb128> or maybe use -proposed for that during the unstable cycle
<seb128> but I don't think anyone worked on actually moving that forward yet
<infinity> Obviously, this needs more effort.  Yeah.
<seb128> so I guess it will be discussed,announced when that happens
<SpamapS> is there somewhere that the limits of what you can do on a buildd are documented?
<SpamapS> the unit tests for what I uploaded to the charm-tools package work fine in my local sbuild.. but fail on the buildds for seemlingly unknown reasons. :-/
<ogra_> you can do everything it allows :)
<SpamapS> ogra_: your succinct explanation is perfectly cromulent
<infinity> SpamapS: Without looking, I'm going to assume it tried to talk to teh interwebs.
<ogra_> which it wouldnt allow :)
<infinity> SpamapS: Buildds have no external routing (or even forwarding DNS) outside their little world.
<SpamapS> infinity: I took steps to prevent that, but I'll try tcpdumping during my sbuild..
<SpamapS> Hmm, I wonder
<infinity> SpamapS: Lemme look at your log and see if something jumps out.
<SpamapS> infinity: you'll want to look at the test script really.. the log isn't super helpful w/o it
<ScottK> FSVO 'want'
<infinity> SpamapS: Yeah, I just saw that.  That's one super-uninformative log.
<SpamapS> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/charm-tools/precise/files/head:/tests/helpers/
<SpamapS> infinity: I think I may need to favor output over beauty in that test script..
<SpamapS> suppressing too many things has caused it to be unhelpful
<elmo> *blink*
<elmo> SpamapS: you're doing all sorts of DNS + internet access attempts in there?
<infinity> Yeah, I'm assuming it's the ch_is_ip or ch_is_url stuff attempting to whack the outside world.
<elmo> like infinity said, other than selective in-DC resources, the buildds can't see *anything* including doing DNS resolution
<ogra_> you even run a webserver
<SpamapS> elmo: I aliased host/dig to my own little functions which mock them.. but its possible that just didn't work
<elmo> ogra_: that part is fine, it's local
<infinity> ogra_: Running a server is fine.
<ogra_> sure
<infinity> SpamapS: Well, it build fast, abuse a PPA to test iterations.  Or set your nameserver in resolv.conf to something you can't route, and test harder. ;)
<infinity> (The latter is how I tend to track down external-DNS/access oopses in builds)
<SpamapS> yeah i think I'll re-run with -x if there are failures too
<SpamapS> well tcpdump didn't pick anything up.. but caching could be preventing that
<infinity> SpamapS: Seriously, just set nameserver to 192.168.33.33 (ie: something both non-routable and not actually running a nameserver) in resolv.conf in your chroot and try again.
<SpamapS> Yeah I'm actually doing that right now while I also try something in a PPA. :)
<infinity> Heh.
<broder> infinity: i thought we actually decided that we should use -proposed for staging invasive changes
<infinity> broder: I may have missed the last discussion on the matter, but that also sounds sane.
 * broder looks for the blueprint/etherpad
<infinity> broder: Implementation details are less important to me than having it done.  But yeah, we obviously need to publicise this wider, if no one's aware of it (and some of us are aware of it, but potentially incorrectly).
<broder> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-intermediary and http://pad.ubuntu.com/uds-p-foundations-p-upload-intermediary
<broder> ev was more interested in how we could hook testing into the migration path, but we definitely talked about using -proposed to stage things that might create skew/uninstallability/etc
<SpamapS> infinity: works fine w/ an unroutable DNS server
 * infinity blinks.
<infinity> Okay, I'm now interested enough to try.
<SpamapS> PPA builds are 2 hours wait right now.. so I'm stracing. ;)
<SpamapS> Actually
<SpamapS> could it be as simple as it taking the server more than 1 second to listen() ?
<infinity> It could be.  You don't give it more time?
 * SpamapS could be more correct and loop netstat till it listens. :p
<SpamapS> no. I should actually loop wget until it responds once rather than just being lazy and doing sleep 1
<SpamapS> I think doing that, and also exposing the server's log rather than throwing it into /dev/null should help
<infinity> I'm going to grab a quick bite to eat.  Do I get a prize if I can reproduce this locally?
<SpamapS> infinity: satisfaction is its own prize. :)
<kirkland> tyhicks: jjohansen: hey guys...what did y'all decide on the ecryptfs long-filename work for 12.04?
<jtaylor> SpamapS: I probably have similar problems with a package I just synced, pyzmq can't bind to 127.0.0.1
<jtaylor> works fine locally
<SpamapS> this binds to 0.0.0.0:8999
<SpamapS> but yeah maybe similar issue
<tyhicks> kirkland: I'm going to fix ecryptfs_statfs() to return an appropriate f_namelen and then lean on applications to properly check that
<kirkland> tyhicks: and we'll file and fix bugs against each broken app?
<tyhicks> kirkland: The patch should go upstream sometime this week. I'm trying to work out a way to get as close to the maximum allowed filename length as possible, but it isn't straightforward due to the encrypting and encoding that the filename goes through.
<tyhicks> kirkland: Right, I'll file bugs
<kirkland> tyhicks: coolio
<ScottK> kirkland: Congratulations on your new gig.
<kirkland> ScottK: thanks!
<tgardner> tyhicks, how about picking a constant to begin with? keep it simple. there has to be  a valid floor value.
<tyhicks> tgardner: It can change based upon cipher block size
<tyhicks> tgardner: What I'm about to do is pre-calculate a small lookup table
<tgardner> tyhicks, so figure out what the largest cipher block size is, subtract that from the underlying FS name length, and advertise taht.
<tyhicks> tgardner: There's quite a bit of metadata that gets stuffed in the filename, along with an encoding process (to make the ciphertext printable) that has a somewhat variable expansion size
<tyhicks> tgardner: I'm going to take one more look at coming up with an accurate equation and then probably do the lookup table
<tyhicks> One of the metadata fields can vary between 1 and 3 bytes
<tyhicks> It is a pain...
<tgardner> tyhicks, I think I'm a bit confused. you can only return one name length per underlying FS type, right ?
<tyhicks> tgardner: right
<tgardner> one *maximum* name length
<tyhicks> right
<tyhicks> tgardner: You're suggesting to hardcode a set of maximum eCryptfs filename lengths based on what the underlying FS is?
<tgardner> tyhicks, so, you're trying to calculate that value based on the FS type. a static table does seem simpler.
<tgardner> its not like its gonna change.
<tyhicks> tgardner: Actually, I'm trying to calculate that value based on what the lower filesystem reports its max filename size is
<tgardner> do any of the FS types have variable max lengths ?
<tyhicks> tgardner: But, a static table still works the same
<tgardner> I'm just thinking expediency. it'll be a lot easier to debug.
<tgardner> one could always optimize later
<tyhicks> tgardner: I think that ntfs (or is it fat?) does have a variable length. Also, who knows what we'll see when stacked on top of a FUSE filesystem
<tyhicks> tgardner: But I'm with you, optimize for the common case and worry about the corner cases later
<tgardner> tyhicks, yeah, we need to start finding which apps are gonna croak
<infinity> SpamapS: FTR, exactly the same failure locally, using an upgraded buildd chroot and an invalid resolv.conf.
<SpamapS> infinity: hrm
<infinity> SpamapS: And fails with a valid resolv.conf too.
<infinity> SpamapS: So, it's probably the timeout thing.
<SpamapS> infinity: I think its the 1 second pause
<infinity> (Or something)
<SpamapS> I have a new version of helper.sh that loops wgetting / until it succeds or reaches 5 fails
<SpamapS> I've noticed PPA builds have been really really delayed the last 3 weeks.. are we just hammering the buildds w/ distro stuff?
<SpamapS> like, 2 hours is the shortest I've had in a while
<infinity> SpamapS: Changing the sleep 1 to a sleep 5, it still fails.
<infinity> SpamapS: So, it's something a bit wonkier than macihne speed...
<infinity> (This is a 2.6G Core2...)
<iceroot> SpamapS: for my last build i had 13 hours
<infinity> SpamapS: PPA and distro don't (often) relate.  Just looks like a lot of people doing daily recipe builds and such. :/
<SpamapS> infinity: I was thinking it was trying to do a reverse lookup then failing.
<SpamapS> or something like that
<SpamapS> haven't dug through SimpleHTTPServer yet to see how it does its magic
<infinity> SpamapS: Give me a command line to run just the testserver?
<JanC> SpamapS: I have had my PPA builds start in 10-30 minutes I think?
<SpamapS> infinity: is there something different about a buildd chroot than one made with 'mk-sbuild' ?
<infinity> SpamapS: Probably.
<infinity> http://launchpadlibrarian.net/85129991/chroot-ubuntu-precise-i386.tar.bz2
<infinity> Grab the real thing and try?
<JanC> SpamapS: but you are probably building for precise?
<SpamapS> JanC: I am
<JanC> I guess that might be the difference then
<SpamapS> heh and now my build went up to 3 hours. :-/
<infinity> /usr/bin/python: No module named SimpleHTTPServer
<infinity> SpamapS: Missing build-dep? :P
<SpamapS> infinity: I was afraid of that. IIRC, its part of python2.7-minimal .. :-/
<SpamapS> but that doesn't sound right at all
<infinity> Why would minimap have an HTTP server?
<infinity> minimal...
<SpamapS> I know
<SpamapS> bigger question, why does sbuild bring in python2.7 where buildd does not?
<infinity> SpamapS: Boom.  Installing python, and it works.
<SpamapS> yeah
<infinity> SpamapS: And I have no idea why your chroot had python, but it shouldn't.
<SpamapS> all my precise chroots do
<seb128> lamont, is there any way to get a stacktrace of an hanging build on the buildds?
<lamont> seb128: ppa or otherwise?
<seb128> lamont, well, main archive in that case but ppa have the same issue
<seb128> upstream blames it on our old kernel
<lamont> seb128: archive is easier
<seb128> lamont, https://launchpad.net/ubuntu/precise/+source/glib2.0/2.31.4.tested-0ubuntu1
<seb128> the i386 or amd64 builds
<lamont> just grab the victim of the shift and have him do that for you...
 * lamont just EODed and needs to run
<seb128> they are stucked again
<seb128> ok
<SpamapS> infinity: thanks for finding that. I'm adding stuff to print out the server's logs/errors now
<seb128> who is in the victims' club? ;-)
<seb128> infinity, ?
 * jtaylor is
<seb128> jtaylor, hey!
<jtaylor> I mean i too have a hanging build ._.
<infinity> seb128: deej.
<seb128> infinity, thanks
<SpamapS> hmmm.. so mk-sbuild installs devscripts
<SpamapS> that seems to be the issue
<tumbleweed> hrm, we probably shouldn't do that in mk-sbuild. People can configure to to do that if they want devscripts in their chroots
<SpamapS> its helpful when you need it, but so is vim, and we don't put that in..
<tumbleweed> yeah, I add vim-tiny in my own config
<doko> seb128, the `tested' in the glibc2.0 version didn't prevent the package failing to build ;-P
<seb128> doko, right, I hate the builders, it doesn't happen on non-buildds environment, desrt and other upstreams think it might be a kernel bug on the old buildds kernels
<seb128> doko, I'm about to do an update with a second testcase commented...
<hallyn> hey - i notice the autosync daemon synced spice-protocol 12 hours ago.  is it likely just a matter of time before it does spice, or can something be done to kick it?
<slangasek> hallyn: according to https://launchpad.net/ubuntu/+source/spice-protocol/0.10.0-1, it already built
<slangasek> oh, you're asking about a separate package
<slangasek> no, it's not a matter of time :)
<slangasek> that is, any given autosync run should be complete
<slangasek> hallyn: spice 0.10.0-1 isn't in Debian testing yet - if you need it sooner, you should probably run syncpackage for it
<doko> wendar, your magics++ patch looks very strange (and ftbfs on arm* which doesn't have quadmath)
<bdrung> broder: and sponsor-patch uses the new syncpackage sponsoring feature in the latest dailies version.
<hallyn> slangasek: i see, thx - didn't realize autosync came from testing
<hallyn> alas i don't have upload rights to syncpackage
<broder> is there any way to get precise-{security,updates} pockets created on ddebs.ubuntu.com so that update-manager isn't as whiny?
<infinity> pitti: ^
<broder> ok, i wasn't sure if that was a pitti thing or a canonical IS thing or something else entirely thing
<infinity> broder: It's mostly pitti's baby right now.
 * broder nods
<mdeslaur> slangasek: is it normal that ia32-libs is uninstallable on precise?
<slangasek> mdeslaur: until the conversion is done, yes
<mdeslaur> slangasek: ok, thanks
<slangasek> hallyn: testing> usually it's from unstable; LTSes tend to be a special case
<mdeslaur> slangasek: conversion to what, btw?
<slangasek> mdeslaur: all the previous contents have been moved to be dependencies of ia32-libs-multiarch:i386; those libs all need to be fixed up for multiarch coinstallability
<slangasek> we're getting closer, but it's a deep hole
<mdeslaur> slangasek: ah! I see, thanks for the explanation
<slangasek> it's very likely that I will feel compelled to plow through the remainder between now and the end of the year
<broder> slangasek: is there a comprehensive list of the ones that still need help somewhere?
<infinity> broder: "apt-get install ia32-libs-multiarch" should probably give a fine list of complaints. ;)
<broder> indeed it does
<slangasek> broder: better is this:
<slangasek> $ for pkg in $(apt-cache show ia32-libs-multiarch \                                                                    |sed -n -e'/^Depends: / { s/Depends://; s/, /\n/g; p }');   do       echo $pkg $pkg:i386;   done | xargs sudo apt-get install -y | sed -n -e'/The following packages have unmet dependencies/,$p'
<doko> barry, are you familiar with nosetests? they seem to hang on armhf at least, see https://launchpad.net/ubuntu/+source/mpi4py/1.2.2-3/+build/3003368
<broder> slangasek: man, there aren't any fun ones left, are there?
<ScottK> doko: I think lifeless knows a lot about those.
<slangasek> broder: what kind of fun were you looking for, exactly? :)  there's libpam-ldap... :)
<broder> that's certainly one some kind of fun :)
<infinity> doko: The build's only been going for 20 minutes, are you sure it's hung?
<doko> infinity, yes, killed the last one after 20h
<infinity> doko: Oh.  Special. :/
<doko> sorry, 12h
<doko> see https://launchpad.net/ubuntu/precise/+source/mpi4py/1.2.2-2
<infinity> doko: Ahh, not armhf-specific.  Same hang on armel.
<infinity> doko: That's mildly comforting, at least.
<slangasek> broder: alternatively, gconf2 unblocks gstreamer-plugins-good?
<slangasek> and has some fun interdependencies :)
<broder> i can take a look at that
#ubuntu-devel 2011-12-14
<broder> slangasek: ok, my initial analysis is that /usr/lib/libconf2-4/gconfd-2 needs to be moved to a new multi-arch: foreign package that libgconf2-4 depends on, but gconfd-2 also links libgconf, so you'd have a circular dependency. so i'm stuck
<slangasek> broder: oh.  well, maybe we could have gstreamer-good not depend on gstreamer-gconf, which is a just-merged change anyway
<SpamapS> hmm, https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/893420 .. with this bug.. libpst was accidentally demoted to universe in oneiric. How do we re-promote it ?
<ubottu> Ubuntu bug 893420 in evolution (Ubuntu Oneiric) "PST import no longer available after update to Oneiric" [Medium,In progress]
<broder> slangasek: also, i *think* that corba is intended to be cross-arch safe, but i don't know whether gconf's implementation is or not
<slangasek> if it isn't, we can assume that's somebody else's problem
<slangasek> it was shipped in ia32-libs for a long while IIRC
<broder> it's not in oneiric's ia32-libs
<mdeslaur> I don't believe gconf uses corba anymore
<broder> is it all dbus now?
<mdeslaur> I think so, yes
<broder> i thought it used dbus to negotiate a corba...thing. but i could be out of date
<mdeslaur> oh, hrm
<infinity> SpamapS: How do we re-promote it in oneiric or in precise?
<infinity> SpamapS: In oneiric, it would require a new version in updates that we could then promote to main, which is a moderately icky thing to do in a released distro, but we've done it in the past in extreme cases.
<infinity> SpamapS: In precise, you just need to make sure it's pulled in by something in main (or seeded), and we'll fix.  Shouldn't need an MIR if it was in main before.
<SpamapS> infinity: I believe its already back in main in precise
<SpamapS> infinity: the SRU is trying to re-enable the libpst functionality in evolution.. which somehow disappeared. I haven't dug into the issue tho.
<infinity> SpamapS: Kay.  So, yeah, fixing is in oneiric requires a new upload.  Because we don't change dists/ in a release pocket.
<SpamapS> infinity: makes sense, so allow the no change rebuild into -proposed and then subscribe ubuntu-archive ?
<infinity> SpamapS: (ie: we won't ever promote the version that shipped with oneiric, but we could promote one in oneiric-updates, if it's really dire)
<micahg> SpamapS: was it done by accident or since Thunderbird is the new mail default?
<SpamapS> micahg: I don't know.
<infinity> There's also that...
<SpamapS> evolution is still in main
<SpamapS> whether or not that is intentional, I do not know
<micahg> maybe talk to the desktop team?
<infinity> It might only still be in main because people ran out of time to hunt down all the rdeps and kick it out.
<infinity> So, yeah, possibly worth a talk with the desktop team.
<micahg> I think the plan was to keep evo in main at least for oneiric
<infinity> Well, there are cute comments on evo-related things in the seeds like:
<infinity> ubuntu.oneiric/supported: * libreoffice-evolution # no rdepends any more, noticed too late
<infinity> Which makes me wonder if there was an effort to get it out, and time just ran out. :P
<infinity> SpamapS: Anyhow.  Assuming it has the blessing of the desktop team to fix it, my above outlined solution would be the answer.
<TheMuso> broder: mdeslaur, I am sure gconf can be built with either CORBA, or dbus support, and we use dbus now.
<broder> TheMuso: ok, cool. so theoretically it should be multiarch safe, other than the cyclic dependency issue
<TheMuso> broder: As one can see from the build deps of gconf, it depends on dbus, and no bonobo stuff.
<SpamapS> infinity: i'll punt to pitti
<SpamapS> there's plenty more to fix in the SRU queues at the moment. :-P
<infinity> Heh.
<slangasek> broder: would it work to simply install gconfd-2 to /usr/lib/$arch/libgconf2-4/gconfd-2?  It only gets launched by the lib if it's not already running and we don't care which one gets started, right?
<slangasek> this is not ideal, but it would work without a circular dep
<broder> i haven't checked, but i assume it gets launched by dbus autospawn
<slangasek> I don't think it does
<broder> so the full path would have to be in /usr/share/dbus-1/services/blah
<broder> gconf2-common ships a /usr/share/dbus-1/services/org.gnome.GConf.service
<slangasek> ah, ok
<slangasek> you're right
<infinity> And, it looks libe libglib2.0-dev has grown an undeclared dependency on libpcre3-dev
<broder> i was just about to file a bug on that
<infinity> Or just reupload glib2.0 with that added to control?
<infinity> libglib2.0-0 has depended on libpcre3 for ages, if anything, it's a bug that the -dev package didn't require pcre-dev until now.
<broder> i can't upload it - i'm still just motu
<infinity> Oh.
<infinity> I'll take the proactive approach and do so.
<infinity> broder: Fixed.
<pitti> Good morning
<pitti> bdmurray: yes, it's from apport/crashdb/pitti.py
<pitti> bdmurray: seriously, I was working on some retracer bug cleanup before and forgot to switch back to my normal LP account
<pitti> sladen: seed3ed f-u-f-f-c to server
<pitti> broder: generating precise-* pockets on ddebs now
<pitti> infinity, SpamapS: "I'll punt to pitti" -> that's for the re-promotion of the accidentally dropped libpst in oneiric? yes, I already told cyphermox that we'll need a no-change rebuild in -proposed in order to promote it
<pitti> broder: there now
<infinity> pitti: The punting wasn't about that process, but about whether the dropping of pst support may have been intentional due to evolution being demoted as the default mail app.
<pitti> infinity: no, it was entirely accidental; evolution is meant to be in main still
<infinity> Kay.
<pitti> infinity: can you please commit your glib2.0 change to bzr?
<infinity> pitti: To a bzr other than ubuntu/glib2.0?
<pitti> yes, to lp:~ubuntu-desktop/glib/ubuntu
<pitti> what Vcs-Bzr: says
<infinity> (We need to stop having all these mismatched ways of doing this...)
<pitti> we don't use ubuntu/glib2.0
<pitti> it shouldn't even exist
<infinity> Yes, why use the branch that auto-imports and stays synced with uploads? :)
<pitti> but our requests of not having UDD branches for packages with an explicit Vcs-Bzr: weren't considered
<infinity> (And there's no Vcs-Bzr in the package)
<infinity> Just the Debian Vcs-Svn.
<pitti> keek, who dropped that..
<pitti> I'll add it back
<pitti> infinity: so, want me to grab the diff from LP and commit it then?
<infinity> pitti: Just did.
<pitti> infinity: ah, tahnks
<infinity> Still, I wonder why people resist the UDD thing.
<infinity> It makes life so much simpler for people like me who prefer to just fix source packages. :P
<infinity> Cause it keeps the two in sync.
<pitti> many reasons
<pitti> we actually did try UDD
<pitti> but pre-applied quilt patches in bzr are horrific, evil, bad, and wrong
<pitti> and everyone gets them wrong
<infinity> Yeah, full source + 3.0(quilt) is pretty ugly.
<infinity> There used to be an elegant solution for that.
<infinity> Many years ago. :P
<pitti> you end up with patches auto-reversed with debian/patches/debian-changed, patches not unapplying, etc.
<pitti> merge-upstream fails over horribly with pre-applied patches
<infinity> Didn't Scott have clever tools, like, in Sydney, that did branch-per-patch magic?
<pitti> also, it's a bit pathetic that UDD gets exactly those things in proper revision control which we _don't_ ever want to touch (the upstream bits)
<infinity> Would make a lot more sense now with 3.0
<pitti> right, that would be a sensible step
<infinity> And yeah, I'm not saying UDD is perfect (in fact, I don't use it), I just like the idea of my source uploads being auto-merged into other people's VCS workflows.
<pitti> so right now UDD just makes things a whole lot harder than it needs to be
<pitti> the debian/ only branches and bzr bd -S is pretty much perfect
<infinity> Instead of things getting lost because I didn't learn the VCS flavour of the week, and no one debdiffs against old source before they upload.
<pitti> yeah, the dropped Vcs-Bzr: is totally our fault
<pitti> it's back now in bzr (but won't upload just for that, the buildds are busy enough already)
<pitti> infinity: the irony is, it's still much cheaper for us to deal with the occasional de-sync than routinely using UDD for everything
<infinity> pitti: I don't suppose you've tried to convince people to do debian-only in UDD?
<pitti> infinity: at first, but I quickly gave that up
<pitti> I don't mind having full source trees, they are reasonably fast these days
<infinity> The syncing magic is really the only thing I like, I don't really care about the rest. :P
<pitti> infinity: but I whined uncountable times to poolie and other guys to pretty please drop teh pre-applied patches insanity
<diwic> Having debian/ only branches often leads to stuff like "could not find the upstream tarball", when somebody is working on packaging a new version, but have not yet uploaded that to the archive.
<infinity> diwic: Er.
<infinity> diwic: If they don't have the orig lying around, then they're going to accidentally build native.
<pitti> bzr bd -S gets that all for you
<infinity> diwic: I don't see how that's any better.
<pitti> it downloads it through debian/watch
<diwic> pitti, in the best of worlds, yes
<diwic> but maybe one should fixup debian/watch in case it's wrong then
<infinity> diwic: Having no tarball is better than accidentally flipping to native.  One's an error message people can learn to deal with, the other is irritating to fix.
<pitti> yes, we do that in ~ubuntu-desktop, but they don't tend to change often
<diwic> infinity, Eh, I'm not suggesting we do something completely wrong just to remove the error message.
<micahg> pitti: the langpacks are built in a PPA and then copied to -proposed, right?
<pitti> micahg: no, we'll build them directly in -proposed
<micahg> pitti: ah, ok, nevermind then :)
<pitti> micahg: we can't do binary copies from normal PPAs to -proposed unfortunately
<diwic> I think pitti is right, we should make sure debian/watch is always able to download the orig source
<pitti> that would require one of these "blessed" ppas
<diwic> (or point to the orig source)
<pitti> for debian/ only branches anyway
<pitti> that makes them utterly convenient
<pitti> debcheckout -a mysrc, bzr bd, there it is
<diwic> But that is, unless somebody works with a git snapshot
<pitti> yes, of course
<diwic> rather than a source tarball
<pitti> well, _and_ it isn't in the archive yet
<diwic> yep
<pitti> bzr bd will first try to download from archive, then from watch, then from get-orig-source
<ScottK> Does it look in Debian too?
<pitti> no, not right now
<pitti> there's no reason why it couldn't, I guess it just didn't come up yet
<infinity> Would make some sense.
<pitti> in our GNOME world at least, downloading from upstream usually is what we want anyway
<infinity> In fact, it would make sense to check Debian right after Ubuntu, to make sure there's no orig skew.
<pitti> (for new versions)
<infinity> (Cause skew sucks)
<slangasek> bdmurray: does your "package already installed and configured" check speak Polish yet? (bug #904082)
<ubottu> Launchpad bug 904082 in krb5 (Ubuntu) "package libkrb5support0 1.8.3+dfsg-5ubuntu2.2 failed to install/upgrade: pakiet libkrb5support0 jest juÅ¼ zainstalowany i skonfigurowany" [Undecided,New] https://launchpad.net/bugs/904082
<ScottK> I think I filed a bug about that (checking Debian), but I don't recall for sure.
<bdmurray> slangasek: no but it will
<slangasek> hurray :)
<pitti> zul, Daviey: do we want nova-console seeded anywhere? it currently wants to go to universe
<jibel> pitti, another 'missing openoffice-dicts' bug 903869
<ubottu> Launchpad bug 903869 in openthesaurus (Ubuntu Precise) "mythes-it failed to install: /usr/sbin/update-openoffice-dicts: not found" [High,Triaged] https://launchpad.net/bugs/903869
<pitti> bonjour jibel
<jibel> pitti, good morning :)
<pitti> jibel: thanks, will fix
<pitti> darn, I thought I already caught all rdependencies
<jibel> pitti, oh, it's not part of openthesaurus
<jfi> Hello, actually, for precise should package sync from debian be requested or it is still automatically done?
<pitti> jfi: Debian import freeze is Jan 12, so still automatic
<jfi> pitti, ok, thanks
<pitti> jibel: oh, I know why -- it doesn't depend on dictionaries-common
<pitti> jibel: I'll try and start a complete archive grep then; I was hoping I could avoid it
<jibel> pitti, I tried the other mythes-* and they install correctly.
<doko_> TheMuso, pulseaudio ftbfs on any arch execpt amd64
<pitti> jibel: bug 903869 is a hard nut to crack.. could I ask you or jamespage to re-run the main-all test once I did the two changes I mentioned in the bug?
<ubottu> Launchpad bug 903869 in mythes-it (Ubuntu Precise) "mythes-it failed to install: /usr/sbin/update-openoffice-dicts: not found" [High,Triaged] https://launchpad.net/bugs/903869
<pitti> jibel: how long does that take?
<jibel> pitti, sure, it takes 2 hours or so
<pitti> jibel: mythes-it fixed, updated dictionaries-common for the new Breaks:
<pitti> jibel: ok, I think it's worth trying the main-all upgrade again
<pitti> jibel: if it still fails, it should fail differently, but I have high hopes that it won't fail with this particular bug any more
<jibel> pitti, I'll try as soon the lab is back.
<pitti> jibel: oh, did it go out for lunch?
<jibel> pitti, it rather didn't woke up this morning, so it missed breakfast too.
<ppisati> why some libraries don't have the corresponding -dbg version? (e.g. libfuse2)
<pitti> ppisati: we have -dbgsym packages for pretty much everything
<pitti> https://wiki.ubuntu.com/DebuggingProgramCrash
<ppisati> pitti: ok, let me try again
<pitti> ppisati: in particular, we do have libfuse2-dbgsym
<ppisati> pitti: i can't find it, where is it?
<pitti> ppisati: you need to add the http://ddebs.ubuntu.com apt sources for it, as in above wiki page
<ppisati> pitti: did
<pitti> hm, did you run apt-get update?
<ppisati> yes
<ppisati> i'm in oneiric amd64
<pitti> ppisati: does apt-cache search dbgsym give any results at all?
<ppisati> [flag@newluxor ~]$ apt-cache search dbgsym | wc -l
<ppisati> 8149
<ppisati> pitti: ^^
<pitti> ok, good
<ppisati> pitti: can you point where the file is?
<pitti> ppisati: sorry, just checked; we are indeed missing the libfuse2 dbgsym in oneiric
<pitti> it's there in precise and older versions
<ppisati> pitti: doh :(
<pitti> http://ddebs.u.c. is a rather brittle makeshift solution, which was never meant to run for so many years
<pitti> we are waiting for Launchpad to get real ddeb support
<pitti> ppisati: so if you want to debug something, I'm afraid you'll need to rebuild the oneiric source locally with DEB_BUILD_OPTIONS=nostrip,noopt
<ppisati> pitti: that was the plan, thanks for the support
<pitti> ppisati: sorry, bad luck :/
<pitti> jibel: so, good luck with the CPR!
<wendar> doko: it's temporary while the maintainer of magics++ and libemos works out what he wants to do. more correct would be adding the linking flags for -lquadmath and -lgfortran in libemos (or farther up the chain, if that's where they're needed),  but  weighing between the options it seemed better to minimise the number of packages touched in the meantime.
<wendar> doko: but, I'll fix up powerpc in a few hours (it's 3am at the moment)
<zul> pitti: universe is fine
<pitti> ugh, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg just turned ... interesting
<pitti> I suppose I revert libcommons-lang-java
<pitti> (looks like an autosync)
<ScottK> pitti: It is a really good case for that tool though.  I skimmed the component mismatches email and it's far easier to see the source of the problem in the picture.
<scott-work> not sure this is the correct channel, if it isn't please point me in the right direction:
<pitti> ScottK: even there it's a challenge to follow the line from the green bubble :)
<pitti> but yes, quite easy to see the root of the problem
<scott-work> ubuntu studio would like to be able to install .deb files, we used to use gdebi but it seems that software-center can do it now
<doko> well, that's maven as its best
<scott-work> do we need to include an extra package for software-center for it to install .deb files or will it do it natively?
<scott-work> i meant local .deb files
<ScottK> scott-work: mvo can answer that, I'm sure.
<mvo> scott-work, ScottK: software-center will do it natively
<scott-work> sweet, thanks mvo
<mvo> yw
<scott-work> we had a user having a problem but it might have been with a release where we didn't include software-center due to package name change
<mvo> thats possible, I would welcome more info if its a real problem, but they should share the same backend code (debfile.py from python-apt)
<scott-work> mvo: i'll see if i can find that email or question and do a quick check on it
<ogra_> hmpf software-center is seriously broked here
<mvo> scott-work: thanks
<pitti> jibel, jamespage: any luck with reviving the QA lab?
<scott-work> there is good talk on the jack-devel ML about dropping current jack1/jack2 and developing a new implementation...that's bloody exciting news!
<scott-work> oh, crap...wrong channel, sorry
<pitti> SpamapS: thanks for handling the kernel -proposed upload
<pitti> SpamapS: I closed the task on the tracking bug, can you please do this next time, too?
<pitti> SpamapS: btw, we don't usually run sru-accept.py on kernels, the kernel bot already covers this
<pitti> SpamapS: (it doesn't hurt, of course)
<rbasak> is there a channel for udd discussion? I'm trying to figure out where I can branch the current lucid-updates openldap from. That's at 2.4.21-0ubuntu5.6 but the bzr branches seem to be behind - lucid at 2.4.21-0ubuntu5, lucid-proposed at 2.4.21-0ubuntu5.5, lucid-updates at 2.4.21-0ubuntu5.4 and lucid-security at 2.4.21-0ubuntu5.4
<rbasak> is lp:ubuntu/lucid-updates/openldap stuck in some way or is this expected?
<geser> it got stuck by bug #653320 (see http://package-import.ubuntu.com/status/openldap.html)
<ubottu> Launchpad bug 653320 in Ubuntu Distributed Development "Import fails with "marked but not imported"" [High,Triaged] https://launchpad.net/bugs/653320
<rbasak> thanks geser, I'll go back to !udd for this one I guess
<pitti> slangasek, mvo: bug 902603 is an interesting dpkg multi-arch bug; is that known to you already? WDYT about the proposed workaround to unbreak upgrades?
<ubottu> Launchpad bug 902603 in gst-plugins-good0.10 (Ubuntu Precise) "oneiric to precise - gstreamer0.10-plugins-good failed to configure due to dependency on libtag1c2a" [High,Triaged] https://launchpad.net/bugs/902603
<pitti> slangasek, mvo: tl;dr: if you have an empty metapackage and install the :i386 version of it, dpkg will consider the amd64 package entirely "replaced" and mark it as not installed
<pitti> slangasek, mvo: but I can't mark it as M-A: foreign, as its dependencies are M-A: same (right?)
<cjwatson> pitti: Sounds like the problem slangasek noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632555#20, although I can't find an actual dpkg bug report for it
<ubottu> Debian bug 632555 in libpthread-stubs0 "libpthread-stubs0: Multiarch support" [Normal,Fixed]
<cjwatson> Shipping a fake file to make the file lists distinct isn't a totally awful workaround
<pitti> cjwatson: ah, thanks for the pointer
<pitti> cjwatson: right, and harmless and easy to revert; I'd just have a better feeling once I get confirmation from Steve that it's an actual bug, not a mis-use of Multi-Arch:
<mugwort13> anyone know the name of the ubuntu installer?   Like what I would search for in synaptic?
<pitti> (and then making sure that's filed)
<pitti> mugwort13: ubiquity, but you don't usually install that in an already installed system
<mugwort13> pitti:  yes, I understand, this box has no cdrom & no usb , so I am going to install via wubi --> install via ubiquity --> uninstall wubi ... I hate doing it this way but the bios won't even allow pxe boot
<mugwort13> thanks
<pitti> mugwort13: you almost certainly want ubiquity-frontend-gtk then
<mugwort13> kk
<cjwatson> pitti: It is an actual bug
<cjwatson> dpkg shouldn't be doing disappearance on all-files-common between two different architectures
<pitti> cjwatson: can't find it either -- I guess I'll file it then
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh, kenvandine
<barry> doko: no idea why that would hang but i'll look at it
<mvo> pitti: sorry for the delay, I was in a call. indeed, putting in a stuf file to keep it on the system sounds sensible to me
<pitti> mvo: ok, thanks; I'm typing a Debian bug report for it, then I have less guilt applying a workaround
<pitti> mvo: want me to CC: you, or not? (I'm CCing slangasek)
<mvo> pitti: please do, thanks!
<SpamapS> pitti: ... please.. can we write this all down?
<SpamapS> pitti: I'm sorry if its already written down and I just forgot where it is.
<pitti> SpamapS: https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed
<SpamapS> pitti: bookmarked. Thanks. :)
<pitti> SpamapS: FYI, I'm using https://bugs.launchpad.net/~ubuntu-sru/+assignedbugs?field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED
<pitti> SpamapS: as a TODO list for what we need to do for kernels
<SpamapS> it helps me to see it there in my bookmarks toolbar as "kernel->proposed" :)
<SpamapS> pitti: ok, I've just been responding to pings fro skaet
<cjwatson> pitti: I gather that multiarch bugs are better filed in Ubuntu at the moment
<pitti> cjwatson: filed as Debian bug 652063 FYI (with some preemtive apology if that was too early, as that dpkg branch isn't in Debian yet)
<ubottu> Debian bug 652063 in dpkg "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [Normal,Open] http://bugs.debian.org/652063
<cjwatson> oh well
<pitti> cjwatson: bug 902603 is now the corresponding Ubuntu bug
<ubottu> Launchpad bug 902603 in taglib (Ubuntu Precise) "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Triaged] https://launchpad.net/bugs/902603
<pitti> cjwatson: at least now I'm comfortable with filing a workaround
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html \o/
<pitti> after only four days
<pitti> jamespage: ^ FYI
<pitti> and the http://people.canonical.com/~ubuntu-archive/component-mismatches.txt madness is gone, too
<Daviey> no precise_probs?!  Can we ship now? :)
<jamespage> ship ship ship ship!
<jamespage> OH - not yet :-)
<pitti> *cough* NBS, component-mismatches, FTBFS, etc :)
<jamespage> pitti: w00t - its be a dry four days!
<pitti> well, to be honest most of it was buildd lag
<pitti> there were only a few real fixes there
<pitti> but I helped it a bit with bumping some build scores
<pitti> jamespage: and no jenkins to turn green :(
<pitti> jamespage: still no response to CPR?
<ogra> could an archive admin let the linux-ac100 package out of NEW ?
<slangasek> pitti: 902603> I was sure I had filed a bug on dpkg for this in LP already, but I don't see it now
<pitti> ogra: yes, can do
<ogra> (needs to go to universe)
<pitti> slangasek: I checked debian and ubuntu bugs, didn't find somethign with a searchable name ("disappear", "Multi-arch", "multiarch")
<mvo> broder: silly question about backports - you do not have a "apt-show-backports" tools right? if not, do you want one?
<mvo> (or maybe someone else from the ubuntu-backports team can help me with that question)
<ScottK> mvo: What would such a tool do?  (It's not obvious to me from the name)
<mvo> ScottK: it would show on the commandline what packages are available as backports (and also what packages that you have installed on your system have a backport)
<ScottK> mvo: No.  I don't think we have such a thing and yes, I think it would be very nice.
<mvo> ScottK: cool, now I just need to find a pkg to place it in and a good name (maybe the name is already good enough)
<Daviey> barry (or anyone else)): should debian/pydist-overrides be used to state, i DON'T want a depends?
<nemo> So. Just FYI for y'all
<nemo> I did an "upgrade" of ubuntu 10.10 to 11.10
<nemo> 3 times the install over existing one crashed. the 3rd time I noticed in the log an error on writing to /usr/local/man
<nemo> said that there was already something there
<nemo> so I blew away everything in /usr/local, which was all stuff I didn't really need anymore anyway
<nemo> aaaaand, install worked the 4th time
<ScottK> Direct upgrade from 10.10 to 11.10 isn't supported.  You need to do 10.10 -> 11.04 -> 11.10.
<nemo> ScottK: I meant I popped in an 11.10 disc
<nemo> and used the option in the disc to upgrade an existing install
<nemo> ScottK: anyway. seems the installer has some bug WRT /usr/local/man - thought I'd toss it out there
<nemo> ScottK: it was from 10.10 32bit to 11.10 64bit, so no form of normal upgrade would have worked.
<ScottK> More likely software from outside the archive.  Ubuntu packages should never install anything there.
<nemo> ScottK: sure. but. the installer shouldn't crash either
<cjwatson> I agree, but please file a bug in LP rather than on IRC
<ScottK> If you're trying to cross-grade between architectures I think the expected behavior is completely undefined.
<cjwatson> no, this is defined
<cjwatson> it's not a regular upgrade, it's more like save off everything not part of the system, blat new system in place, restore
<nemo> cjwatson: eh. I file stuff there in detail, it languishes, then someone urges I retest 4 months later when my entire system is gone or a completely different config
<cjwatson> nemo: stuff filed on IRC is *certain* to languish
<nemo> cjwatson: I'm fed up w/ LP - it is basically a bug auto-expiring mechanism
<cjwatson> I fix bugs in LP, not from IRC
<nemo> cjwatson: yeah, but at least I don't get the heartbreak of the autoexpire :)
<nemo> cjwatson: well. you now know as much about it as I do :-p
<slangasek> bugs only autoexpire if requests for information from developers have gone unanswered
<cjwatson> for the ten minutes until I forget, given that I'm in a meeting
<ScottK> nemo: I understand you're frustration, but he's right.  Even if the odds are low, they are better in LP than here.
<cjwatson> I agree the percentage of bugs fixed from LP is not as good as it should be, but IRC is AWFUL as a bug-reporting mechanism
<nemo> ScottK: hm. I see that the upgrade put a symlink in - perhaps it was blowing up on trying to symlink something that was not a symlink
<cjwatson> and worse as a bug-remembering mechanism
<nemo> cjwatson: the worst thing is I file the bugs so other users can learn
<nemo> cjwatson: and then someone closes it so my workarounds vanish
<cjwatson> I suppose you can hope somebody else has already filed it, if you won't file it yourself
<skaet> pitti, Spamaps - http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/kernel-sru-workflow.html is also useful to get an overview.
<cjwatson> nemo: no, this is me asking you to file it and give me the number so that I can keep track of it
<barry> Daviey: sorry, i don't know the answer to that
<cjwatson> nemo: I'm one of the two or three people who can fix this bug so maybe it might be a good idea to listen :-)
<ScottK> nemo: He's also the guy that fixes installer bugs, so I'd listen
<ScottK> :-)
<nemo> cjwatson: yeah, yeah. I'll get to it if I remember. in order to use launchpad from here I still have to integrate those <button> patches into my w3m
<nemo> due to the login mechanism
<Laney> mvo: yeah, that would be nice â is it something that apt could have a command for itself? More general than backports, for any NotAutomatic source
<cjwatson> which I was able to find for you because they were tracked in LP ...
<nemo> :-p
<nemo> cjwatson: someone must have not autoexpired them like they do all my hardware bugs :)
<cjwatson> what you're complaining about isn't fundamentally LP, it's that we don't have enough resource to fix all the bugs that get fixled
<cjwatson> er, filed
<cjwatson> refusing to file bugs doesn't particularly help that
<nemo> cjwatson: sure. I just wish they were left open so other people would know. oh. hey. that laptop model has this problem. here is a workaround
<nemo> what you guys need is a hardware database I could record this stuff in
<cjwatson> oh, I agree with you and have been banging that drum for years; but refusing to file bugs doesn't help matters
<ScottK> I think it's also the reasonable complaint that triagers do too much "is this still a problem" -> Incomplete triaging.
<nemo> ubuntu version, hardware component, support, workaround
<ScottK> nemo: You're talking with one of the Ubuntu devs that has been most outspoken about it and it still happens.
<nemo> cjwatson: anyway. either I'll get setup on the external network, or I'll apply the w3m patch. I'll get to it eventually
<nemo> but fundamental problem is /usr/local/man was a physical dir and installer apparently wanted to symlink to /usr/local/share/man  - it panicked and exploded
<nemo> probably correct behaviour would have been mv /usr/local/man /usr/local/share/man
<nemo> then symlink
<cjwatson> sure, that is probably fixable.  but I want an audit trail for this
<cjwatson> because otherwise it's hard for me to keep track of what bits of the code are there for
<cjwatson> it's unfortunately rather complex
<cjwatson> (I don't think we can decide how to move things around in /usr/local; we should just not fail)
<tgall_foo> doko, ping - where are we at with libjpeg-turbo8 hitting the archive ?
<nemo> cjwatson: hm. symlinks should work functionally the same, so you'd think moving would be harmless.  of course, the interesting thing is that the new /usr/local/share/man is empty anyway :)
<nemo> cjwatson: so it blew up on trying to create an empty dir :D
<nemo> guess it was some standard disc layout
<cjwatson> complexity leads to failures; I'd rather keep it as simple as possible
<nemo> it also made a bunch of other dirs - so maybe my blowing away all of /usr/local was important too
<nemo> all empty btw :D
<nemo> local$ find | xargs
<nemo> . ./etc ./src ./man ./lib ./lib/site_ruby ./lib/site_ruby/1.8 ./lib/site_ruby/1.8/x86_64-linux ./lib/python2.7 ./lib/python2.7/dist-packages ./lib/python2.7/site-packages ./sbin ./bin ./share ./share/fonts ./share/man ./share/ca-certificates ./share/xml ./share/xml/misc ./share/xml/entities ./share/xml/schema ./share/xml/declaration ./share/ppd ./share/sgml ./share/sgml/dtd ./share/sgml/misc ./share/sgml/entities ./share/sgml/declaration 
<cjwatson> *please put this in a bug*
<cjwatson> I am NOT going to remember this when I next have a chance to fix this
<cjwatson> the above is very likely enough for me to set up a reproduction environment, and that's great
<nemo> oh. one interesting side effect of this (bug blah blah blah)  was that on later attempts to install it decided it was upgrading from 11.10 to 11.10
<nemo> instead of 10.10 to 10.10
<cjwatson> yes, it had already overwritten the bit that said it was 10.10
<cjwatson> notabug
<nemo> I have no idea if this impacted its ability to ID existing packages, but I was missing a lot of packages
<cjwatson> except insofar as the previous run failed
<cjwatson> yes, it would have done
<nemo> cjwatson: sure. I was just thinking it might have screwed up the upgrade
<nemo> cjwatson: only way to avoid that would be if there was some sort of incomplete upgrade log
<cjwatson> it probably would have done a bit
<nemo> including enumeration of prior packages
<nemo> that you could blow away once successful
<nemo> cjwatson: it is a mild bug in that you could keep track of that if you wanted to. but certainly the circumstance shouldn't happen anyway
<nemo> not like a user would be able to do much once they hit the crash anyway
<nemo> yeah, reason I could blow away /usr/local/ is it just contained cuda (which I needed to update anyway) and Aventail (which workplace abandoned for something w/ even less linux support)
<nemo> cjwatson: oh. one more thing. reason I didn't submit a crash report at the time, even though I had internet, was that it said it would include my password (!) in the crash report.
<nemo> cjwatson: why is the installer keeping that in its memory so late in the install? or is that a just-in-case because it might have crashed in the hopefully tiny action to put it in a password file as soon as it is collected
<nemo> heck. you'd think the first thing you'd do would be to hash it, wipe the original's memory location, then only use the hash until you can ditch it :)
<nemo> you could probably even determine whether it was still in the installer's memory by a checkpoint on how far the installer got :)
<nemo> anyway. scary message = no crash report from me ;)
<nemo> I'm sure I'm not the only one
<cjwatson> were you running the installer in debug mode?
<nemo> I guess had I known that could happen I would have used a throwaway password and changed it after install
<nemo> cjwatson: nope. just poppped in a standard disc
<cjwatson> otherwise I don't recognise that message
<cjwatson> oh, maybe:
<cjwatson>     if os.path.exists('/var/log/installer/debug'):
<cjwatson>         response = ui.yesno("The debug log file from your installation would help us a lot but includes the password you used for your user when installing Ubuntu.  Do you want to include this log file?")
<nemo> yep
<cjwatson> so (a) you have the option to submit a crash report without that debug log file
<cjwatson> (b) I *think* it only includes that when in debug mode, but haven't checked
<nemo> mm
<nemo> well. apparently the installer did not know this :)
<cjwatson> debug mode traces all debconf transactions without caring what it is, it's like strace
<nemo> I assumed it was submitting some core file w/ installer's memory
<cjwatson> anyway, you could have said no and filed the bug.
<nemo> it made me all paranoid :-p
<nemo> didn't want to accidentally send my password to a public server
<nemo> heck. it had already crashed, I didn't trust it :)
<mvo> Laney: yeah, good idea
<Laney> :-)
<cjwatson> slangasek: should bug 800561 be on rls-p-tracking, given that I don't think we can commit to fixing this until GI-friendly xklavier bindings are available?
<ubottu> Launchpad bug 800561 in ubiquity (Ubuntu Precise) "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561
<slangasek> cjwatson: probably only if the xklavier GI dependency is also tracked... or if we want to commit to doing that ourselves
<slangasek> pitti: ^^ do you know if we're going to get GI xklavier bindings this cycle, and when?
<stgraber> cjwatson: looking at bug 219260, is that something you think we should try to solve this cycle (calling console-setup directly)
<ubottu> Launchpad bug 219260 in casper (Ubuntu) "clone-and-hack keyboard setup code needs to be replaced by calling console-setup" [High,Triaged] https://launchpad.net/bugs/219260
<dobey> is there an easy way to install the amd64 kernel, but keep a 32bit userspace?
<broder> dobey: i think linux-image-generic is multiarch cross-installable
<broder> so apt-get install linux-image-generic:amd64
<dobey> E: Unable to locate package linux-image-generic:amd64
<broder> uh, echo foreign-architecture amd64 | sudo tee /etc/dpkg/dpkg.cfg.d/multiarch
<broder> apt-get update, etc., etc.
<broder> dobey: hmm...looks like that only works on precise, not oneiric, fyi
<dobey> yeah, the packages seem to be broken
<broder> it also may not willingly uninstall your current kernel before grabbing the foreign arch one - you may have to do that yourself
<hallyn> mdeslaur: my gift to you is bug 903307.  As I don't have upload rights, i'll just leave it there with debdiff attached?
<ubottu> Launchpad bug 903307 in virt-manager (Ubuntu) "Virtual Machine Manager unable to view GUI console" [Medium,Confirmed] https://launchpad.net/bugs/903307
<dobey> broder: ideally i'd like to have both installed, in case the amd64 one doesn't work
<dobey> so i can at least boot my system again if it fails
<mdeslaur> hallyn: is that my xmas gift? :)
<hallyn> sorry there's no bow
<hallyn> i was afraid it might still be due to some delta in our libvirt, but no, same thing on f16
<mdeslaur> hallyn: does virt-manager reuse the same ssh tunnel if you have two consoles opened to the same server?
<mdeslaur> my other question was if it could be because of the nc madness
<hallyn> well it could be, but as i say it's also in f16
<mdeslaur> hallyn: you tried with an ubuntu server, or ith a f16 server?
<hallyn> i don't know how to pen two consoles to the same server
<hallyn> both
<mdeslaur> hallyn: ok, I'll take a look and upload it
<hallyn> mdeslaur: thanks!
<mdeslaur> hallyn: thanks!
<hallyn> (i did send it upstream, we'll see what they say)
<tgall_foo> doko, ping - where are we at with libjpeg-turbo8 hitting the archive ?
<doko> tgall_foo, I know, on my todo list. did want to wait until armhf was bootstrapped
<tgall_foo> ok thanks
<micahg> doko: sorry about trillinos, I thought I had tried that build-dep switch
<doko> micahg, well, the R build system is broken
<doko> barry, see bug #904248 and bug #904249, python-central isn't a big issue anymore, python-support requires some more effort
<ubottu> Launchpad bug 904248 in python-central (Ubuntu Precise) "python-central build-dependencies in main" [High,Triaged] https://launchpad.net/bugs/904248
<ubottu> Launchpad bug 904249 in python-support (Ubuntu Precise) "python-support build dependencies in main" [High,Triaged] https://launchpad.net/bugs/904249
<barry> doko: ack, thanks
<iceroot> can someone tell me why libgnome-control-center1 has a "1" at the end? in changelog its just called libgnome-control-center
<iceroot> apt-cache search libgnome-control-center
<micahg> iceroot: binary vs source naming?
<iceroot> micahg: ah its some of these "one source-package but many binary-packages" in debian/control there is libgnome-control-center and libgnome-control-center1
<micahg> iceroot: source is gnome-control-center, libgnome-control-center1 is the binary package
<iceroot> micahg: but why libgnome-control-center1 and not libgnome-control-center as binary
<micahg> iceroot: SONAME versioning probably
<iceroot> micahg: ok, thanks for the info
<infinity> iceroot: library package names have the SOVER in the package name.
<infinity> iceroot: So that if there's ever a libgnome-control-center.so.2, it will be co-installable as libgnome-control-center2
<iceroot> infinity: ah ok, thanks for the example now i get it
<jtaylor> lamont: can you give some insight on whats going wrong here: https://launchpadlibrarian.net/87386428/buildlog_ubuntu-precise-i386.pyzmq_2.1.10-2_FAILEDTOBUILD.txt.gz
<jtaylor> lamont: it seems to fail binding to 127.0.0.1 on i386 and amd64 but not on arm, local and on debians i386 and amd64 buildd's
<jtaylor> the testsuite does not require internet access
<debfx> slangasek: do you have a moment to review my phonon multiarch changes?
<cjwatson> stgraber: it's a technical debt item, but it has a substantial chance of regressions; I don't think it would be a good candidate for this cycle
<cjwatson> dobey: it does work on precise, FWIW, although you can only (easily) have one or the other, I think
<cjwatson> dobey: I'm running an amd64 kernel with an i386 userspace on this system, having put some effort in at the start of the cycle to get this working
<slangasek> debfx: not this moment; I would in an hour or so
<stgraber> cjwatson: ok, won't touch that one then :)
<dobey> cjwatson: ok, maybe i'll upgrade this system; i'll try it on another machine first
<debfx> ok
<broder> cjwatson: i don't suppose there's any chance you took measurements of memory savings in that setup vs. all i386? i'm curious how it compares to cking's numbers
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
* broder changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> broder: no, sorry
<broder> i'm assuming bryceh isn't still piloting at this point
<barry> tumbleweed: will you sync precise python-virtualenv to 1.7-1 when it lands, or do you want me to?
<bryceh> broder, yeah sorry forgot to log out
<TheMuso> doko: Yes I know, I gave it back on amd64, but had to leave before I could give back on other arches.
<slangasek> TheMuso: ah, so a give-back should fix it? Are you doing that now?  I was about to come pestering about that myself :-)
<doko> qcontrol only built for armel??? https://launchpad.net/ubuntu/precise/+source/qcontrol/0.4.2-7
<infinity> doko: Architecture: armel
<infinity> doko: Right in the .dsc
<doko> infinity, ok, building for armhf too
<TheMuso> slangasek: yes gave them all back.
<slangasek> TheMuso: great, thanks
#ubuntu-devel 2011-12-15
<int_ua> zyga: ping
<doko> \o/ it's done: https://launchpad.net/builders:  armhf	11	empty
<SpamapS> woot
<micahg> Do we prefer P-A-S to hacking debian/control to allow/disallow archs?
<RAOF> micahg: They're for different jobs, aren't they?  p-a-s is for... um... :)
<micahg> exactly :), well, it makes it easier if there's a downstream distro with support for other archs
<micahg> RAOF: just found this: https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027076.html
<infinity> micahg: P-a-s is for arch decisions that shouldn't be made by the source.
<infinity> micahg: For instance.  If you have a package that's obviously x86-specific (like, it's all i386 ASM), then "Architecture: amd64 i386" in the .dsc is appropriate.
<micahg> infinity: so, if it can be made by the source, the source is the correct place?  i.e. I know chromium won't build on powerpc, so marking it !powerpc is appropriate
<infinity> micahg: But wvdial (to pick a completely different example) works everywhere but arm*, and the reason it breaks on arm is a failing in arm kernel interfaces, which may some day be fixed.  linux-any is the right answer in the package, and !armel !armhf in P-a-s.
<infinity> micahg: chromium not building on PPC sounds more like "too lazy to port". :P
<micahg> infinity: indeed :)
<infinity> micahg: Neither P-a-s nor Arch lines are meant to be used for that.
<infinity> I'd honestly rather see the failure as a reminder.
<micahg> ok
<infinity> It's not something that can't be ported, just something no one's bothered to port.
<micahg> wow, Debian's not even trying chromium on ![i386,amd64,armel]
<infinity> Indeed.
<infinity> That may be an indication of some knowlede of upstream's intent there.
<infinity> Meh.
<infinity> I should talk to jbailey.
<infinity> I know he does chrome(ium) build mangling internally.
<micahg> well, their targets are x86 desktops and android, so it makes sense
<micahg> it would be nice just to have armel work consistently :)
<infinity> And have it work for armhf too.
<infinity> (hint, hint)
<micahg> yeah, that'll probably happen during my vacation :), I don't see much time before then to play with cross-compiling chromium on arm
<StevenK> infinity: jbailey is probably trying to port chromium to hppa.
<infinity> StevenK: That seems unlikely. :P
<micahg> 17 months until no more hppa in Ubuntu :)
 * infinity sheds a tear.
<micahg> oh, and no more lpia as well
<StevenK> No tears for hppa
<StevenK> I will not miss lpia
<infinity> lpia, I don't care about.
<infinity> I do actually still use my J6750, though.
<infinity> I guess it's time to move it to a Debian base.
<infinity> Or turn it into a stylish coffee table.
<pitti> Good morning
<pitti> slangasek: they aren't upstream apparently, so if we need them, we need to do it ourselves
<pitti> Riddell, ScottK: so I hear koffice is being replaced with something newer -- koffice-l10n has zero rdepends left, ok to remove/blacklist that package?
<YokoZar> Can someone answer a multi-arch question?  https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages  says that " This means that for an Architecture:Â all package to satisfy the dependencies of a foreign-architecture package, it must be marked Multi-Arch:Â foreign or Multi-Arch:Â allowed. "  -- Does this mean the dependency needs to be Multi-Arch: allowed, or the depending package?
<pitti> YokoZar: the arch: all package itself needs to be M-A: foreign
<YokoZar> pitti: or M-A allowed
<broder> i thought dpkg didn't actually support m-a allowed yet
<pitti> presumably (I've never seen "allowed" in practice so far)
<YokoZar> pitti: annoyingly, then, our fonts package don't appear to be M-A: allowed...
<pitti> just not sure why they need to be explicitly declared so
<YokoZar> I've got an i386 app that depends on a font and it's not letting me install it on amd64 with dpkg because it wants to insist on i386 version of font package :/
<pitti> I'd expect an Arch: all package to be "M-A: foreign" pretty much by design
<pitti> slangasek: ^ I guess there are corner cases where this wouldn't work?
<YokoZar> pitti: That was my thought, I naively assumed we'd treat all arch:all packages as M-A: foreign, but then I ran into my font issue
<broder> wait..."i386 version of font package"
<broder> ...are you *sure* it's arch: all?
<YokoZar> ttf-mscorefonts-installer
<YokoZar> yes
<broder> because "i386 version" of an arch: all package sounds meaningless to me
<broder> ah, wait. /me re-reads the spec
<broder> anyway, it sounds like you want multi-arch: foreign
<YokoZar> http://paste.ubuntu.com/770848/
<YokoZar> broder: my question was do I want that on the font itself then, or can I just put it on my package?
<broder> on the font
<infinity> I'm sure there was a reason for non-MA arch:all packages being treated that way, but damned if I can remember what the reason was...
<broder> infinity: see the link that YokoZar posted at the beginning of this :)
<broder> "architecture-dependent packages may depend on Architecture: all packages and assume that the transitive dependencies will be resolved using packages of the same architecture or other packages that are Architecture: all"
 * YokoZar isn't liking the idea of pushing an SRU to ttf-mscorefonts-installer that doesn't do anything other than let my package install....
<YokoZar> Someone should clean up that specific paragraph I linked to though, it is an ambiguous "it", hence my question
 * infinity goes to bed and hopes he doesn't wake up to a bunch of eglibc build failures and/or critical bugs.
<micahg> infinity: you are brave :)
 * YokoZar changed "it" to "the dependency" on the multi-arch page
<infinity> micahg: If it breaks, I'm sure pitti will fix it for me.  He's magical when I'm asleep.
<infinity> That sounded dirty.
<infinity> Hrm.
 * micahg guesses he's almost as crazy with a bzip2 sync a few hours before bed
<infinity> micahg: I dunno.  Did your sync involve a 4MB diff in debian/* ?
<micahg> infinity: heh, no :)
<micahg> I strangely feel better now
<YokoZar> Ok, next multi-arch question: can I work around my issue by depending on ttf-mscorefonts-installer:any ?
<YokoZar> answer: no
<pitti> I don't think ':any' works
<YokoZar> Yeah, just tested that experimentally
<YokoZar> Well this sucks
<broder> YokoZar: :any is a m-a: allowed thing, and you're using m-a: foreign
<broder> also i still don't think m-a: allowed works
<YokoZar> broder: I'm trying to not modify the font at all at the moment, and just my package depending on it (an i386-only binary package that otherwise installs and runs fine on amd64 on oneiric)
<broder> i don't believe that's possible
<YokoZar> Right, which is why I have declared this sucks
<YokoZar> Fixable with an SRU to ttf-mscorefonts-installer though (ugh)
<broder> packages can't force other packages to be m-a
<pitti> armhf 11 empty
<pitti> err, wow!
<pitti> doko, infinity: ^ congrats :)
<YokoZar> broder: actually maybe ttf-mscorefonts-installer isn't fixable this way, since it's an odd font that depends on binaries that aren't M-A like wget
<pitti> infinity: is it possible to steal some armhf builders for armel? we accepted a bunch of SRUs, and there's eglibc, webkit, etc.
<broder> YokoZar: wget should be m-a: foreign
<pitti> infinity: I know how to switch them in the web ui, I just don't know which builders will actually work
<infinity> pitti: Yeah, some don't. ;)
<infinity> pitti: I'll toss a few over.
<pitti> cf. the recent genip debacle
<pitti> infinity: cheers
<YokoZar> broder: in Oneiric?
<broder> YokoZar: i don't know about oneiric. i'm just saying conceptually it should be
<pitti> infinity: so it seems LibO is indeed still the only offender for http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html
<YokoZar> broder: it's non-MA in oneiric (/usr/bin/wget), and I'm pretty sure it should be M-A: allowed since you can install it on its native arch :)
<infinity> pitti: Hopefully, that gets fixed soonish.
 * pitti tries to pronounce liboktetakastencontrollers4 without getting a knot in his tongue
<broder> YokoZar: no, you're thinking about it wrong. it should be m-a: foreign because anything that *depends on it* has to be shelling out
<broder> so it doesn't matter if they're the same arch
<YokoZar> Oh, right, foreign means not coinstallable, but still installable on build arch
<infinity> pitti: There.  You have buildds.
<YokoZar> for a moment I thought M-A foreign meant that it could _only_ be foreign
<YokoZar> (eg ia32-libs-multiarch is M-A:foreign as it only made sense to install it on amd64, but I suppose it is installable on i386)
<micahg> YokoZar: arch all only being built on i386 is a bug ATM
<micahg> Debian has no such restriction
<YokoZar> micahg: I suppose that's related yeah
<broder> micahg: huh? i don't see how that's relevant here
<YokoZar> micahg: but my specific problem isn't where it's actually built, it's that dpkg thinks it can't install my i386 package because it depends on an arch:all package that I already have
<micahg> broder: I thought I saw something that implied it's i386
<YokoZar> micahg: broder: well it means that if we relax the assumption that's causing me issues we're unlikely to have new bugs since every arch:all package was the same anyway (ie, the built on i386 one)
<broder> YokoZar: no, it's not confused because the package was built on i386
<broder> it's confused because it's treating the arch: all package as only satisfying amd64 dependencies, so it tries to get and i386 version which is just nonsense
<YokoZar> broder: I know, it's confused because it thinks it needs font:i386 but I have font:all and they're not m-a
<broder> right. but where the package was built has nothing to do with that
<micahg> broder: rereading, I don't see why I thought that was relevant anymore :)
<YokoZar> broder: well if arch:all packages were built on different arches then hypothetically they might differ somehow and this restriction requiring explicit M-A allows might not be so nonsensical
<broder> but they'd still only be built once
<broder> and differences wouldn't actually matter, because all arches would still get the same specific build
<YokoZar> fair enough
<YokoZar> methinks a tech board proposal might be prudent here
<YokoZar> since the alternative is 1) leaving it broken to things like this and 2) manually M-Aing all the arch:all packages, which would be the same effect anyway
<micahg> YokoZar: you need to get consensus in Debian first or this will cause a lot more pain
<broder> YokoZar: you want to drop the requirement that arch: all packages be explicitly marked m-a: foreign?
<broder> the wiki outlines a fairly compelling reason why that needs to be the case
<YokoZar> broder: Well, I want to relax it in the case that the transitive dependencies are all either MA allowed or themselves all.  If a binary depends on an MA: all package that in turn depends on a non MA package then we can leave it as it is.  This would get the fonts, for instance, which have no dependencies at all.
<YokoZar> *except ttf-mscorefonts-installer, of course which properly should require multiarching of its dependencies
<broder> my instinct is that the number of arch: all packages that depend only on arch: all packages all the way down is going to be small enough to not be worth re-policy-ing over
<YokoZar> broder: this would also prevent the ridiculous need of M-Aing arch:all packages (instead we would just MA their dependencies if they have them)
<broder> (and more importantly, reimplementing)
<broder> oh, m-a; foreign too
<broder> (seriously, stop talking about m-a allowed because it's confusing and, more importantly, not real)
<YokoZar> broder: what about arch: all packages that depend on M-A'ed packages though?
<YokoZar> As we continue MAing things that's going to be more and more the case
<micahg> pitti: can I target some stuff as -security and some stuff as -proposed for the Firefox migration for Lucid/Maverick?  Just trying to be intellectually honest about what might actually migrate to -security FWIW
<broder> YokoZar: fwiw, i appear to be spreading misinformation. m-a allowed is implemented
<YokoZar> Fair enough :)
<broder> anyway, if you wanted to propose something like this, the TB is the wrong place to do it. you'd want to talk to the multiarch implementors, who are for the large part in #multiarch on OFTC
<broder> without thinking exceptionally hard about it, i would guess their response will be that the implementation is nasty
<broder> or alternatively http://alioth.debian.org/mail/?group_id=30462
<YokoZar> broder: alternatively, I can talk to slangasek and hope he takes up the issue :P
<broder> well, you know, that's basically equivalent to what i proposed
<YokoZar> True
<broder> :)
<cjwatson> pitti: corner case where Arch: all M-A: foreign doesn't work: python
<cjwatson> (basically the canonical corner case)
<pitti> infinity: cheers!
<pitti> micahg: what would be the -proposed part?
<dholbach> good morning
<micahg> pitti: firefox and maybe mozvoikko I think
<pitti> micahg: ah, so the new langpacks are enough in -updates for now as well then
<pitti> micahg: but as soon as we'll do the first firefox -security we need to remember to copy the langpacks, too
<micahg> pitti: right, so maybe the langpacks should target -security or is that not necessary?
<pitti> micahg: no, we can just copy them once needed
<pitti> they usually target -proposed, and should
<micahg> ok, but my selective targetting is ok then?
<pitti> micahg: sure
<micahg> pitti: thanks
<infinity> micahg: Oh, are you doing firefox uploads tonight?
<micahg> infinity: I wanted to :-/
<micahg> it'll be later today though
<micahg> infinity: you've got at least 8 hours i think
<infinity> micahg: Oh, I was just wondering if I should give some buildds back to armel again.  But there seem to be enough idle ones.  Carry on.
<pitti> micahg: hm, if firefox goes to -updates, will it still be in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages ? I don't see it there
<micahg> pitti: I haven't uploaded it yet
<micahg> was waiting for beta 6, if it's not uploaded by morning, I'll just grab beta 5, I should only need ~17 hrs I think
<pitti> micahg: ah, ok; so I'll only prepare the tarballs right now, to have everything ready which doesn't depend on firefox
<pitti> micahg: but that's the correct PPA?
<micahg> pitti: yes, but I thought you weren't using the PPA
<pitti> micahg: just for pointing langpack-o-matic against it, to see which languages have a firefox-l10n-* package
<pitti> I can use the PPA or -proposed, whichever hits first
<micahg> pitti: ok, that should for sure be ready by tomorrow when you come online (at least the i386 one)
<pitti> cool
<pitti> janimo: good morning
<pitti> janimo: I suppose you saw the linux-ac100 FTBFS on armel?
<pitti> (armhf worked fine)
<pitti> cjwatson: https://launchpad.net/ubuntu/+source/gnutls26/2.12.14-4 NBSed gnutls-bin
<pitti> cjwatson: it moved to gnutls28; do you have an opinion whether or not we should pull that into precise and to the transition?
<pitti> if not, we can just revert the previous upload (I'm happy to do that)
<pitti> jamespage: ^ FYI (it's on NBS)
<pitti> $ apt-cache rdepends libgnutls26|wc -l
<pitti> 148
<pitti> it's not exactly small
<jamespage> pitti: yes - spotted that late yesterday - was going to ask the same question
<jamespage> gnutls28 is in testing now I think
<pitti> the recent haskell transition is done buildd-wise now, so if we want to do it, we should do it over the weekend
<pitti> we still have gnutls26, so it wouldn't immediately result in lots of NBS
<pitti> but we certainly don't want to ship precise with two versions
<pitti> hm, libgnutls-dev is still for 26
<pitti> so we'd actually need to change the source
<pitti> jibel, jamespage: are the precise-upgrade jobs running ATM, or can we poke them?
<jibel> pitti, they didn't start for some reason. I just started them manually.
<pitti> jibel: presumably because the lab was still offline at their regular start time?
<pitti> jibel: merci
<pitti> jibel: let's see how far they get this time :)
<jibel> pitti, no, the lab was ok but I think jenkins didn't like the network incident at all.
<pitti> right, that's what I meant
<mhr3> hey guys, is there a common envvar where i can find tmp dir location?
<seb128> mhr3, check is $TMDIR is set and if not fallback to /tmp as the default location?
<seb128> check i*f*
<seb128> mhr3, or g_get_tmp_dir() if you use glib
<seb128> "Gets the directory to use for temporary files. This is found from inspecting the environment variables TMPDIR, TMP, and TEMP in that order. If none of those are defined "/tmp" is returned on UNIX and "C:\" on Windows"
<seb128> mhr3, that's what the glib function does
<jibel> pitti, main-all upgrade failed but it was expected. iodbc2 is not blacklisted yet.
<mhr3> of course glib has something for that... why didn't i check first :)
<pitti> jibel: ah, ok; that's tdsodbc which needs blacklisting, I think
<mhr3> thx seb128
<seb128> mhr3, yw
<jibel> pitti, ok.
<jibel> pitti, 6 jobs are still queued, I'll do that right after.
<pitti> jibel: cool, thanks
<pitti> jibel: let's see how far they get now :)
<jibel> pitti, mvo fixed main-all-amd64, I'll run it as well
<pitti> jibel: I don't even see that on https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/
<jibel> pitti, it will be published to the public instance on the first run.
<pitti> infinity, ogra: do you know which of the armel buildds are still babbages? I'll need to rebuild the postgresql stable updates on those, as they fail on the pandas (still on my list to debug this)
<ogra> pitti, not off the top of my head, but since you will likely need lamont anyway to assign the builds (or can you do that yourself?), he knows which are which
<pitti> ogra: I can assign them
<pitti> ogra: I think actinidiaceae is still an old one, does that ring a bell?
<pitti> ogra: and araceae; both are armhf buildds now, but I can temporarily switch them over
<ogra> i think the aeae ones are, yep
<ogra> pitti, iirc buttercup is a babbage
<pitti> ogra: ah, thanks
<ogra> and crabapple
<Riddell> pitti: I'd rather you wait until I test the upgradees work, which needs an archive admin to let the replacement into the archive
<pitti> ogra: ok, started a build on buttercup
<ogra> good luck :)
<pitti> Riddell: ack
<cjwatson> pitti: sounds to me like we should probably move forward to gnutls28, unless you have a reason not to
<YokoZar> Is it a bug if the icon that appears in the unity side panel isn't the same as the icon that was in the .desktop file that launched it?
<YokoZar> Also why that happens is a bit of a mystery to me...
<pitti> cjwatson: I'm only afraid of ending up with two gnutls in main because the third-last package doesn't port to 28 or so
<pitti> cjwatson: but in general I agree
<cjwatson> I think we probably have enough time to sort that kind of thing out still
<sladen> cjwatson: fresh install on an X220.  installer/window manager have crashed twice so far.  Is there anything I can get you before I reboot/try other stuff?
<sladen> cjwatson: (precise daily)
<ogra> pitti, i uploaded the nvidia-tegra driver to NEW yesterday, it will land in multiverse since we dont support it officially, is there a way to tell jockey to look for such stuff or does it do main only ?
<cjwatson> sladen: does it leave a crash report such that you can file a bug with apport?
<cjwatson> sladen: if the WM has crashed it may well not be my problem though.
<cjwatson> depending exactly what crashed ...
<sladen> cjwatson: yes, after I restarted the WM, I've filed the installer crash
<pitti> ogra: jockey doesn't care about components; if they are enabled in apt, they'll be available
<pitti> ogra: well, there's no handler for it, of course
<ogra> cool, thanks
<ogra> i'll take a look once the package is accepted
<sladen> cjwatson: sorry, I don't have the bug number (it should arrive in a moment).  The WM crashed again, so I'm on the console
<cjwatson> sladen: don't need any more information, it's a dup of something I'll find in a bit
<cjwatson> sladen: to get past it, deselect "third-party software"
<cjwatson> alternatively it will go away by itself once eglibc is back in sync between amd64 and i386
<cjwatson> which it should be now, actually
<sladen> cjwatson: I ticked that ages earlier.  It crashed during the slideshow
<cjwatson> sladen: sure, but nevertheless
<cjwatson> (actually, it may not go away by itself until the next CD build)
<debfx> is there a way around pulling in gtk3 on the kubuntu image? gstreamer0.10-plugins-good -> gstreamer0.10-gconf -> gconf2 -> libgtk-3-0
<cjwatson> duped now
<debfx> in oneiric the gstreamer0.10-gconf dependency wasn't there but it is now: "Let gstreamer0.10-plugins-good depend on gstreamer0.10-gconf for wheezy to guarantee correct upgrades to wheezy (Closes: #625567)."
<seb128> debfx, we can probably drop the gconf->gtk3 recommends
<seb128> debfx, or you would like to not get gconf either?
<debfx> seb128: I don't want gconf on the cd but since it's relatively small it wouldn't be a big issue
<seb128> debfx, let me read that debian bug that made them add the depends
<seb128> debfx, not sure how problematic dropping that depends would be for upgrades
<seb128> but we have at least gnome-media which depends on gstreamer0.10-gconf in Ubuntu
<seb128> debfx, so I would say feel free to drop the added Depends
<debfx> we already shipped oneiric without that dependency so theoretically we'd have at least bug reports about packages that need to depend on gstreamer0.10-gconf
<soren> Are we aware that the cd build logs on http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/precise/ have been useless for a month and a half?
<soren> cjwatson: ^
<soren> Sorry, not hte cd build logs.
<soren> The wubi ones.
<cjwatson> soren: that's all the logging that the CD build side of it produces.  The filesystem build is http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-wubi/
<soren> cjwatson: Oh, sorry. I thought the failed ssh attempts at the end meant that it had failde to grab the fs build log.
<cjwatson> soren: no, that's one of the cdimage/releases mirrors failing, probably unimportantly (it's usually because the machine has been reassigned; that pool is rather fluid)
<cjwatson> s/one/some/
<infinity> pitti: The Pandas are helpfully marked as (arm panda) instead of just (arm), so you should be able to differentiate that way. :)
<dholbach> slangasek, hiya - do you know if there's a TODO list of packages that need to be converted so ia32-libs-multiarch:i386 becomes installable again? :)
<debfx> cjwatson: could you please add polkit-kde-1 to the kubuntu packageset?
<cjwatson> debfx: please mail me
<debfx> just our of curiosity, are only build-dependencies (and not dependencies/recommends) of seeded packages considered for the packageset?
<debfx> cjwatson: I already have some months ago
<cjwatson> no; all of deps, recommends, build-deps
<cjwatson> ah, let me have a look then
<cjwatson> when my external disk gives me some I/O to read mail with ...
<debfx> I wonder why it's not pulled in, maybe because kde-workspace-bin recommends polkit-kde-1 | policykit-1-gnome
<cjwatson> because it's in core
<cjwatson> presumably because something fairly central wants it
<cjwatson> debfx: done
<debfx> cjwatson: thanks
<cjwatson> (lp:~cjwatson/+junk/packageset has the code for determining this, if you don't mind going blind)
<barry> slangasek: is it possible to *un*multiarch a precise system? ;)
<infinity> barry: Define un-multiarch...
<barry> infinity: i want to get rid of all the i386 packages and not be prompted to install or upgrade them anymore.
<infinity> barry: apt-get purge `dpkg -l \*:i386 | grep ^i | awk '{print $2}'` && rm /etc/dpkg/dpkg.cfg.d/multiarch
<pitti> barry: dpkg -l *:i386 | awk '{print $2}' | xargs sudo dpkg -P
<infinity> pitti: Snap.
<pitti> ah, and what infinity said about removing that conffile
<pitti> infinity: ok, you beat me :)
<barry> infinity, pitti thanks.  the biggest problem right now (for this machine) is that multiarch is incompatible with landscape.
<cjwatson> && apt-get update
<infinity> pitti: Mine also won't try to purge a package called Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
<infinity> pitti: :P
<pitti> *shrug* easy to ignore :)
<barry> pitti: fwiw:
<barry> dpkg: error: package name in specifier 'Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend' is illegal: character `=' not allowed (only letters, digits and characters `-+._')
<barry>  
 * infinity giggles.
<pitti> barry: so, add the "grep ^i" :)
<barry> :)
<cjwatson> dpkg-query -W \*:i386 | cut -f1  :-P
<cjwatson> machine-readable output FTW
<infinity> cjwatson: dpkg-query -W lists packages that aren't installed but once were.  Not that that matters for feeding to apt/dpkg, I suppose.  They'll just skip over them.
<cjwatson> true
<infinity> (And dpkg -l is totally machine-readable, you just need the right machine!)
<infinity> One with grep. :P
<slangasek> pitti: the lack of xklavier bindings is blocking us for fixing an installer usability issue, so it would be nice if we could get that this cycle... does someone on desktop have time to implement that?
<stgraber> cjwatson: hey, I'm trying to merge edubuntu-fonts into edubuntu-meta (moving it form its own source to being part of our seeds), the problem I have is its version number (11.02.4) being quite a bit higher than that of our meta package (1.96), so I see two easy way out, either bump the epoch in edubuntu-meta or switch edubuntu-meta to using the same <year>.<month>.<revision> version number. Is there anything wrong with either of these option
<pitti> slangasek: I might get to it in January when I'm off the hook for stable+1; is there a bug for it already (against ubiquity or so)?
<slangasek> broder, pitti, YokoZar: dpkg does support M-A: allowed, but the Debian archive doesn't support :any dependencies yet AFAIK so it's disallowed there currently; and the reason for Arch: all packages not being implicitly M-A: foreign is that this fails for things like Arch: all metapackages for language interpreters (e.g.: 'python')
<slangasek> pitti: the bug for that is bug #800561 on ubiquity, yes
<ubottu> Launchpad bug 800561 in ubiquity (Ubuntu Precise) "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561
<cjwatson> stgraber: neither will cause a problem; do whatever feels most natural
<pitti> slangasek: added an xklavier task and assigned it to me, thanks
<barry> actually, that purging doesn't work completely.  i'm still left with a handful of i386 libraries that can't be removed: http://pastebin.ubuntu.com/771328/
<cjwatson> pitti: would you like to reply to comments #22 etc. on bug 556293?  They seem to be in reply to you
<ubottu> Launchpad bug 556293 in apt (Ubuntu) "apt/aptitude need to take global proxy settings into account" [Undecided,Confirmed] https://launchpad.net/bugs/556293
<pitti> cjwatson: queued, will do (currently having some /msg discussions)
<pitti> cjwatson: I responded, but not quite sure what the complaint is about -- people insisting that sudo must take user's proxy configuration into account (-> wontfix) or that our package management tools don't get along with the proxy settings (that'd be a bug we need to fix indeed)
<barry> pitti, infinity, cjwatson so it seems there's still some mix of i386 that can't be purged
<infinity> barry: ?
<infinity> barry: Shouldn't be.
<barry> infinity: http://pastebin.ubuntu.com/771328/
<infinity> barry: Use apt instead of dpkg.
<infinity> barry: (ie: use my line)
<infinity> apt-get purge `dpkg -l \*:i386 | grep ^i | awk '{print $2}'`
<infinity> It'll actually do proper depedency resolution...
<pitti> perhaps he has some M-A: foreign i386 packages installed
<infinity> Perhaps.
<infinity> apt might sort that sanely.
<pitti> bug 850264 might cause that
<ubottu> Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Triaged] https://launchpad.net/bugs/850264
<cjwatson> pitti: I have to say I'm not really comfortable with your proposed resolution either, and have a lot of sympathy for the people replying; sudo may be wontfix from our point of view but I can see why they're asking for it
<pitti> cjwatson: well, it's not a "proposed" resolution -- it's meant to be working like that for several years already
<pitti> (and once was -- it might have regressed, of course)
<cjwatson> and surely /etc/environment is nonsense, that's system-wide!
<barry> infinity: no, unfortunately, apt doesn't help: http://pastebin.ubuntu.com/771355/
<cjwatson> ITYM PAM environment
<pitti> cjwatson: if you apply the proxy settings globally, that goes into /etc/environment or something similar
 * pitti checks ubuntu-system-service
<cjwatson> when running in a user session we want what the user has configured
<cjwatson> and I suspect a lot of people are working with scripts that set http_proxy in older ways, anyway
<cjwatson> in fact some people even say as much in the bug
<infinity> barry: Looks like you got in a curious situation.
<pitti> well, sudo is not meant to take all your user settings with it, and even if it does, it still wouldn't work with software-center and everything else using aptdaemon
<cjwatson> #28 probably has a point, architecturally, but that's a fairly giant change
<cjwatson> pitti: I'm not convinced that we can fix everything in a single place
<cjwatson> we know quite well that lots of people use sudo apt-get, not aptdaemon
<pitti> right, it writes it into /etc/environment
<infinity> barry: apt-get install gvfs-daemons:amd64 libsane-common:amd64 gvfs-daemons:i386- libsane-common:i386-
<infinity> barry: ?
<barry> infinity: worth a shot... ;)
<pitti> cjwatson: right, and our fault was to ever allow that hack to get into sudo :(
<infinity> barry: (ie: remove the i386 ones and replace with amd64 ones)
<pitti> cjwatson: anyway, if you really want it back in sudo, I won't start a flamewar over it, I'm just convinced that it is both wrong and also insufficient
<cjwatson> the whole environment variable thing in sudo is a disaster, largely because it keeps changing
<pitti> if you set a proxy and apply it system-wide, _both_ sudo apt-get and software-center and whatnot should just work
<cjwatson> and developers often configure it differently for themselves and then forget what the defaults are like ...
<barry> infinity: how weird is this:
<barry> E: Unable to locate package gvfs-daemons:i386
<barry> E: Unable to locate package libsane-common:i386
<barry>  
<infinity> barry: Did you already delete the multiarch conffile and update?  Cause those packages would be hard to find in that state.
<barry> infinity: :(  yes
<infinity> barry: If not, well.  apt is a sad panda.  And we need a better way to deal with multiarch upgrading in devel releases.
<infinity> barry: echo "foreign-architecture i386" > /etc/dpkg/dpkg.cfg.d/multiarch && apt-get update
<infinity> barry: And then try again?
<barry> infinity: thanks.  trying...
<pitti> cjwatson: btw, if you want it back in sudo, you'd also need to add https_proxy, ftp_proxy, and the blacklist; I think back then we only added http_proxy
<cjwatson> I guess I don't see why *_proxy are security-critical
<pitti> but again, that would only aggravate the problem
<cjwatson> I don't see why, really
<pitti> because you teach people that this actually works
<cjwatson> if the process is receiving data from the network, it needs to treat that as untrusted *anyway*
<cjwatson> why shouldn't it actually work?
<pitti> i. e. that system-level software would take into account some user setting
<pitti> because it _only_ works with sudo
<cjwatson> untrusted> so adding a proxy doesn't change things
<doko> cjwatson, you did write the dh_installdocs --link-doc patch; how is this supposed to work with dh7 and up?
<cjwatson> I don't think of it as system/user, it's environment passthrough
<dobey> hey guys
<pitti> a cron job, d-bus spawned program or anything else won't
<pitti> if you want system-level operations to use a proxy, you need to set it system-wide
<pitti> that's my fairly strong opinion
<cjwatson> pitti: so?  those aren't typically subprocesses of the terminal window in which you run things after export http_proxy=
<dobey> what is the general view on maintaining backward compat for package building (in debian/foo), inside source package branches in ubuntu/debian proper?
<pitti> cjwatson: exactly
<cjwatson> doko: groff uses it with dh7
<pitti> cjwatson: so they won't see the user's $http_proxy
<cjwatson> pitti: and so I simply don't see that as a problem
<cjwatson> the sort of people who want sudo to pass through these variables very often don't care about that stuff
<pitti> cjwatson: hm, perhaps we are talking about two different things here then?
<cjwatson> no, we're talking about the same things, we just disagree :)
<pitti> cjwatson: I'm talking about the complaint that apt doesn't use the user's proxy settings
<cjwatson> pitti: yes, I know
<pitti> so, crowbaring it into sudo will not do anything to actually fix it in software-center, aptdaemon, jockey, and whatnot
<cjwatson> DISPLAY is a user setting too, and 'sudo sudo -V' tells me that's preserved
<pitti> sure, but that's unrelated to apt not using your proxy?
<cjwatson> it is related in that it's a user setting that sudo preserves despite this supposed policy that sudo doesn't pass through user settings
<cjwatson> I'm not saying aptdaemon shouldn't do what it can *as well*
<cjwatson> and it may not be able to pick up http_proxy from the environment of the process that caused it to be d-bus-autolaunched; fine
<barry> infinity: that looks like it finally purged all i386 packages from the system, and apt/dpkg appears happy again.  thanks for your help!
<cjwatson> but I don't see why that means users of 'sudo apt-get' shouldn't get what they expect
<infinity> barry: \o/
<pitti> I'm saying that if this is fixed properly (and it might actually work), then we don't _need_ to change sudo, because "sudo apt-get ..." will just work because apt knows the system-wide proxy
<cjwatson> and it's very clear, IMO, what they expect
<pitti> hm, not to me
<cjwatson> the people who say they have scripts that set http_proxy and then try to run sudo apt-get won't be covered by desktop fixes
<pitti> it doesn't seem very obvious that sudo apt-get should use a different proxy than aptdcon/aptdaemon/s-c
<pitti> cjwatson: well, I'm not trying to fix each and every broken script out there
<cjwatson> nor will people who don't even run an Ubuntu desktop at all who set http_proxy in their ordinary-user server environment shell and then try to run sudo apt-get
<cjwatson> neither sudo nor apt is a desktop component; I don't see why they should rely on desktop behaviour
<pitti> in a script you can just call sudo http_proxy=... apt-get
<doko> cjwatson, thanks
<cjwatson> sure, but it's clear from the bug that people don't find that natural; and I'm not sure I can blame them
<cjwatson> again: why is *_proxy security-critical, such that sudo should filter it out?
<cjwatson> I do think this is an important question
<pitti> I don't think it's that security critical
<pitti> you need to defend against spoofing etc. by other ways
<pitti> but it's causing unexpected behaviour, is different from other systems/platforms (as it's an ubuntu specific hack), and we never implemented it properly
<cjwatson> exactly; so what is filtering them achieving, in isolation?
<cjwatson> lots of things in Ubuntu are different from other systems :-)
<pitti> it's achieving consistency in apt's behavioru
<cjwatson> consistency with what people don't want, sure
<pitti> in that it always usees the same proxy, whether it's being called from the daily cron job or from a d-bus backend or from sudo
<cjwatson> if you've set http_proxy in your exported shell environment, that is a blindingly clear signal that you want the proxy to be used for anything you start from that terminal
<pitti> well, for your own user account, yes
<pitti> I set lots of things in my environment which I don't want to impose to other users or admin operations
<cjwatson> *_proxy feels like a totally sensible one to pass through
<pitti> $EMAIL, $EDITOR, GPG_AGENT, etc.
<cjwatson> requiring things to be set in files is clumsy, too
<cjwatson> take the situation in the Canonical datacentre
<cjwatson> you need to use a proxy to access things outside of your network segment
<cjwatson> but in some cases, if you try to use a proxy, it will actually break stuff
<pitti> so we actually expect every user to set that on their own?
<cjwatson> wait
<pitti> shouldn't we set the proxy in /etc/environment to fix it for everyone?
<cjwatson> if you are in this kind of environment, which is *totally outside Ubuntu's control*, you may well quite reasonably occasionally export http_proxy in a shell while doing something
<cjwatson> and corporate networks are weird, they're full of this kind of nonsense
<cjwatson> quite often
<cjwatson> I just feel we're needlessly getting in people's way
<cjwatson> anyway, it sounds like we're at a stalemate
<pitti> yeah, I guess so
<cjwatson> I don't particularly want to force my point of view if there's no consensus, and it does sound as though there's something to be fixed in apt/ubuntu-system-service/whatever
<pitti> cjwatson: as I said, if you prefer to change sudo to pass through the environment, I won't start an upload war over it
<cjwatson> but I think we have totally failed to articulate our reasoning to users
<cjwatson> at the very least
<cjwatson> and explain to them why they're better off this way
<pitti> I just personally find it unexpected and also won't actually fix the problem in many of these kind of bug reports, but at least it doesn't make the latter any worse
<pitti> a proxy which should apply to everythign in the system should simply not be set in an user's .profile IMHO; that will always lead to unexpected things
<pitti> (that applies to any configuration setting, not just proxy)
<cjwatson> but that's a different argument from what we should do given that we have found that it *is* set in a user's .profile or similar
<pitti> cjwatson: anyway, thanks for sharing your POV; I think I at least see now more clearly why some people might expect it to work that way
<cjwatson> I think we're onto a loser trying to tell users what they can and can't put in their dotfiles :-)
<infinity> cjwatson: BTW, I reverted your revert of the C.UTF-8 collating issue before merging to the latest Debian eglibc that should fix your concerns (it now follows POSIX for collation of old skool C symbols, and then strict numerical order for everything after that)
<pitti> (also, welcome distraction from armel panda __test_and_set FUBAR :) )
<cjwatson> infinity: yeah, I was expecting that patch to be superseded, thanks
<infinity> cjwatson: But since you were the one who was actively involved in both debugging and reverting, I'd appreciate if you could give it a once-over and make sure it's sane now? :)
<cjwatson> infinity: I looked at youpi's patch for that at the time, I think
 * infinity nods.
<cjwatson> and I was happy with it
<cjwatson> POSIX then numerical is exactly right
<cjwatson> (in fact that's just numerical all the way through, isn't it?
<cjwatson> )
<infinity> It might be.  Does C not do any reordering for non-alphabet chars?
 * infinity never remembers, he just knows that the subtle differences between locales drive him batty.
<cjwatson> I don't *think* so
<slangasek> dholbach: the TODO list of packages to be converted is roughly the output of this command on amd64: for pkg in $(apt-cache show ia32-libs-multiarch |sed -n -e'/^Depends: / { s/Depends://; s/, /\n/g; p }');   do       echo $pkg $pkg:i386;   done | xargs sudo apt-get install -y | sed -n -e'/The following packages have unmet dependencies/,$p' | less
<dholbach> slangasek, great, I'll take a look
<dholbach> slangasek, should bugs be filed or it be made a bit more obvious that work needs to be done there? :)
<slangasek> barry, pitti, infinity: dpkg -l '*:i386' | awk '/^i/ { print $2 }' | xargs sudo apt-get -y purge, anyway - enough with the useless use of grep ;)
<kees> (strickly speaking, shouldn't the awk be /^.i/ ?
<kees> )
<slangasek> dholbach: eh, filing bugs for it would just be paperwork, and it wouldn't even give a comprehensive overview
<slangasek> kees: no, because you want to get packages you've asked to install but are currently half-installed
<slangasek> fsvo "you've asked"
<kees> slangasek: oh! right
<dholbach> slangasek, ok :)
<slangasek> dholbach: I generally just start again from the top of that command's output each time I get a chance to poke at it
<dholbach> ok :)
<kees> slangasek: the list is getting short!
<slangasek> broder: did you decide what the right thing to do was with gstreamer0.10-gconf / gconf?  Should gstreamer0.10-plugins-good revert the dep?
<slangasek> kees: yep - a couple of days' work should get us down to the last handful of issues
<kees> slangasek: yeah. and ibus was uploaded in debian last night, so that's one to just sync
<kees> slangasek: have you heard back from the other folks that signed up for stuff at the BSP? I was thinking I was going to grind through those today if possible.
<slangasek> kees: no, nor have I had a chance to chase them down
<slangasek> I guess at this point we should assume their patches disappeared in a puff of cloud smoke
 * kees agrees
<kees> slangasek: oh, btw, you said to stay away from the libpam/libnss bits at the BSP, but I forgot why. I've done a pam module M-Aing already, is there something more evil in libpam-ldap?
<slangasek> kees: pam and nss aren't really shared libs so don't follow the recipe, I didn't want anyone to be confused
<slangasek> pam modules also technically need to have a versioned dependency on the libpam that looks in the multiarch dir
<slangasek> (I think Russ filed a bug on pam in Debian about this)
<dobey> can one do "Depends: foo | (bar & baz)" ?
<slangasek> kees: *and*, the maintainer scripts don't DTRT on removal of the package for only one of the archs
<slangasek> dobey: sure, expands to Depends: foo | bar, foo | baz
<kees> slangasek: versioned dep and maint scripts. heh. I suspect I did my pam module incorrectly. /me will go examine it before continuing.
<dobey> hmm
<slangasek> kees: the nss is easy though, provided you understand it's not really a shared lib
 * kees nods
<broder> slangasek: i couldn't come up with any way to multiarchify gconf, so dropping the dep may be the best option
<pitti> good night everyone
<slangasek> broder: ok
<slangasek> pitti: 'night!
<l3on> doko, around? could you explain me why in package tagsoup you set ant1.7 ?
<doko> l3on, likely because it didn't build. have a look at the publishing history
<l3on> ah ok :)
<YokoZar> slangasek: Should I file a massive bug linked against every font and tag it multiarch then? :/
<YokoZar> (and perhaps other arch: all packages that are ok in all circumstances)
<slangasek> YokoZar: huh?  why would we care about doing this for "every font"?
<slangasek> it's only worth doing for Arch: all packages that have reverse-dependencies that are interesting under multiarch
<YokoZar> slangasek: Right, this all started cause I'm packing up commercial i386 binary packages for the app store and came across one that has a hard dependency on a font
<slangasek> yeah - the number of font packages that are going to have such reverse-dependencies is pretty small
<YokoZar> And I expect I'll run into more of them
<slangasek> in fact, msttcorefonts might be the only one
<slangasek> (there are other font packages that have been marked M-A: foreign already due to revdeps on the Ubuntu desktop, but I don't expect third-party commercial packages to be specifying dependencies on odd fonts)
<YokoZar> I'm not sure we can categorically say that.  I'll admit the non default, non-MS fonts are a bit less likely though
<YokoZar> (except the ones I need for Wine...)
<slangasek> they're sufficiently unlikely that I think it's a misuse of time to go tagging other font packages before we find packages that need them
<slangasek> I certainly wouldn't want to carry an Ubuntu delta for them
<debfx> slangasek: the phonon (binary) package is used to pull in a phonon backend. When building phonon for multiarch I need to change it from arch:all to arch:any/multi-arch:same so the backend is pulled in from the correct arch, right?
<YokoZar> Yeah the idea would be to get this into debian.  I'm just worried I'll have some commercial app packed up 2 years from now and I'll have to deal with this headache for some stupid font that we could have fixed now
<slangasek> debfx: that looks like the right thing to do, yes
<debfx> ok thanks, will do that
<nemo> cjwatson: damn. forgot to file that bug when I got home. I'll try to remember again today. unless you already filed one somewhere of course :)
<cjwatson> I didn't
<cjwatson> thanks
<infinity> pitti: I thought you wanted/needed your postgres builds on non-pandas?
<dobey> is there an easy way to tell pbuilder to also pull packages from a certain PPA for a single build?
<dobey> more specifically, with pbuilder-dist
<slangasek> cking: don't keep us hanging in suspense!  what's causing the disk wakeups? :)
<cking> slangasek, that's for my format report :-)
<slangasek> aww
<cking> s/format/formal
<cking> dang typos
<kees> format c:/
<kees> hah, I can't even get that right
<kees> format c:\
<kees> there!
<slangasek> format c:\\ of course
<kees> heh
<mdeslaur> that would be format c:
<mdeslaur> (at least, that's what my muscle memory tell me...)
<mdeslaur> s/tell/tells/
<slangasek> yeah ;)
<slangasek> because you're specifying a drive, not a directory
<mdeslaur> kees: as punishment, you need to modify config.sys with edlin
<kees> echo "jmp f000:ffff" | debug.com
<kees> that was a well-timed exit and quick msg by cking
<kees> s/quick/quit/
<mdeslaur> kees: hehe :P
<cr3> if I want to dynamically generate a version file in a project by using bzr version-info --format=python, would it preferable to have the output directly to a file imported by the rest of the project or symlink another file to the output and commit the symlink?
<micahg> stgraber: since Bug #876829 has now been fixed in Debian, would it be possible to get it in precise/SRUd to oneiric?
<ubottu> Launchpad bug 876829 in ifupdown (Ubuntu Precise) "Oneiric's ifupdown breaks ip aliases" [High,Triaged] https://launchpad.net/bugs/876829
<stgraber> micahg: is that you volunteering for the ifupdown merge in Precise? :)
<micahg> stgraber: I could do that if smoser doesn't want it
 * micahg figures beta will be more stable than alpha
<stgraber> ifupdown has been on my to-merge list because of that bug and possibly a few others (dhcpv6 support, making sure dhclient uses /var/lib/dhcp and not /var/lib/dhcp3, ...)
<smoser> micahg, feel free. i'm not going to do it today.
<stgraber> I was planning on getting to it in January (at the sprint), but if you have time to do the initial merge, I definitely won't stop you :)
<micahg> smoser: I'm not going to do it today either :), weekend at earliest, most likely next week sometime though
<micahg> stgraber: ah, so if I get the merge done over vacation, you can do the SRU at the sprint?
<stgraber> micahg: yep, can definitely do that
<micahg> stgraber: cool, thanks
<SpamapS> hm, when using 'bzr merge' on packaging branches, how does one turn off the merge-changelogs step? apache2's changelog is horribly broken and can't survive such a step. :-/
<SpamapS> aha, BZR_DISABLE_PLUGINS
<cjwatson> SpamapS: I just do the merge, 'bzr shelve --destroy debian/changelog', and hunt-and-destroy the diff hunks I don't want :)
<SpamapS> cjwatson: I have forgotten about bzr shelve about 6 times now. :-P
 * SpamapS is starting to think all those years playing hockey may have had more negative impact than he thought
#ubuntu-devel 2011-12-16
<astraljava> SpamapS: All the recent talk about concussions surely isn't for nothing. But not saying anything about you, specifically. ;)
<YokoZar> Merry christmas slangasek :) https://bugs.launchpad.net/ubuntu/+source/defoma/+bug/905055
<ubottu> Ubuntu bug 905055 in xfonts-utils (Ubuntu) "Package needs to be Multi-Arch enabled so Multi-Arch packages can depend on it" [Undecided,New]
<slangasek> YokoZar: er, there's no reason those packages need to be marked Multi-Arch: foreign for this
<slangasek> *only* the immediate dependency of your package does
<slangasek> does need to be, I mean
<YokoZar> slangasek: I may have confused the issue from reading the M-A spec then :/
<YokoZar> Yeah, this bit: https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages  -- I thought that meant the transitive dependencies would matter too
<YokoZar> slangasek: but thanks for the correction then
<slangasek> "foreign-architecture package" here is the binary-only i386 package you're working on
<slangasek> to satisfy that package's dependency on ttf-mscorefonts-installer, ttf-mscorefonts-installer needs to be marked Multi-Arch: foreign
<slangasek> that's all
<YokoZar> ok so it's nice it doesn't recurse
<pitti> good morning
<pitti> infinity: I had to wait for the others to time out, which took like 12 hours
<pitti> infinity: but I finally debugged/fixed it last night, so I'll just do another -propoosed upload
<micahg> hi pitti, sorry, I'm still waiting for a final release tag, chrisccoulson told me there are l10n differences between beta and release
<pitti> micahg: ack; I can start the langpack build tomorrow morning, no problem
<micahg> pitti: last release the tag didn't come until midnight UTC Sat morning
<micahg> ah, is that what you meant?
<pitti> yes, I meant I can start it on saturday morning
<micahg> pitti: ok, well, there's a caveat, if I don't get it before around 21:00 UTC, I won't be able to upload until midnight Sun morning UTC
<pitti> micahg: if we want to speed it up, I could also temporarily hack the code to have a hardcoded language list
<pitti> micahg: if you can just send me the list of firefox-l10n-* packs that will be built, that's sufficient
<micahg> pitti: I don't really need to inherently rush as long as it's ready sometime next week
<pitti> then I can do the actual work today, and then on Sunday just hit the "upload" button
<pitti> micahg: ok
<micahg> pitti: ok, let me see if I have that already
<micahg> pitti: I think this is it: http://bazaar.launchpad.net/~mozillateam/firefox/firefox.maverick/view/head:/debian/config/locales.all
<pitti> micahg: perfect, thanks!
<dholbach> good morning
 * soren is very confused this morning
<soren> http://paste.ubuntu.com/771954/  <--- Why does it try to apply those patches twice?
<micahg> soren: quilt rule + source format 3?
<soren> micahg: Nope.
<soren> http://paste.ubuntu.com/771955/
<soren> It also seems that it's dpkg-source doing it both times.
<soren> micahg: Oh..
<soren> I think I may know why.
<soren> micahg: Apparently the orig.tar.gz accidentally had the patches applied. Weird.
<micahg> soren: ah, I think I've seen that before
<pitti> apw, smb`: FYI, -5 kernel binNEWed, ready for -meta upload
<pitti> I'll update seeds and d-i
<pitti> micahg: oh, I figure it's the same list for lucid?
<micahg> pitti: should be I think
<pitti> cjwatson: do you want to move d-i to 3.2.0-5, or want me to? (already updated the seeds, this time also including s-kernel-common)
<cjwatson> pitti: go ahead
<pitti> cjwatson: waiting for the metapackage to land, though
<cjwatson> you don't need to wait for that before doing d-
<cjwatson> i
<pitti> cjwatson: wouldn't that make alternate builds uninstallable?
<cjwatson> pitti: no
<pitti> because d-i builds against -5, but the altearnate image has -4 in /pool ?
<cjwatson> Who cares
<pitti> ok
<cjwatson> Worst case it installs an older kernel than it ran with
<cjwatson> But the ABIs don't need to be in sync there
<jml> Hi
<jml> I was in the middle of reporting a crash bug, when about a third of the way through a lengthy upload I got this error:
<jml> 'Cannot connect to crash database, please check your Internet connection.
<jml> <urlopen error [Errno 32] Broken pipe>'
<jml> Clicking OK then cancels the upload
<jml> is this a bug? where should I report it?
<pitti> jml: how big is that report?
<pitti> jml: LP has an unfortunate habit of resetting the connection once you try to upload more than 50 or 100 MB
<jml> pitti: it said 33MB
<jml> pitti: but I have a lousy internet connection.
<jml> also, now I don't know how to actually report this crasher bug in Qt Creator :)
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
 * pitti hugs dholbach
<buxy> pitti: 10 minutes before your mail I sent an updated dpkg patch
<buxy> did you saw it?
<pitti> buxy: right, I noticed too late, sorry
<pitti> buxy: many thanks, you rock
<pitti> buxy: I updated the bug, too; new dpkg uploaded, and I'm unable to break it now
<pitti> tried with different packages, installing in one or two steps, multiple times, etc.
<buxy> ah ok, LP mails tend to lag a bit apparently
<buxy> (at least LP mails through the PTS)
<pitti> buxy: they lag for about 5 minutes, so that you can do several bug state changes without triggering one mail for each
<pitti> buxy: but it was mostly my lag, I just saw Steve's response in my mailbox and then re-uploaded the workaround
<pitti> then saw you'rs
<pitti> your's (argh typing is hard)
<rbasak> I'm trying to do an upgrade test from oneiric->precise, but do-release-upgrade is failing with various "Encountered a section with no Package: header" errors. Is this expected?
<pitti> rbasak: not expected, in fact we also get it in the automatic dist-upgrader
<pitti> ... tester
<pitti> no idea what's causing it, though
<pitti> apparently that started happening a few days ago only
 * ajmitch gets that in pbuilder, it's always to do with TranslationIndex
<ajmitch> so I disabled apt fetching translations to get around it
<pitti> jibel: ^ FYI
<rbasak> thanks pitti, ajmitch. Is it possible to use that workaround in do-release-upgrade? I tried Acquire::Languages { "none"; }; in apt.conf but that doesn't seem to have any effect
<ajmitch> rbasak: unsure, I did have to delete the translation files in /var/lib/apt/lists as well - afaik apt tries to fetch languages that it already has, ignoring the config option in those cases
<ajmitch> it was a bit of an ugly hack I was only using for the chroot, I don't think it's suitable for upgrade testing
<rbasak> ajmitch: yeah, doesn't seem to work. I tried clearing out /var/lib/apt/lists but it still seems to be fetching TranslationIndex files if that's a suitable indiciation? Perhaps do-release-upgrade causes apt to ignore some of its config? It was always a bit of a mysterious black box to me
<dholbach> seb128, I 'ate the desktop team branches
<dholbach> just saying :)
<seb128> dholbach, *hug* ;-)
<seb128> dholbach, you hate things that are light to checkout and easy to use? ;-)
<dholbach> not quite how I'd put it :)
<rbasak> OK, it seems dist-upgrade is sufficient for my testing needs today, so my workaround was just to run dist-upgrade instead of do-release-upgrade ignoring the apt-get update warnings before it
<seb128> dholbach, you are just old and grumpy :p
<pitti> perl patch for broken doc-base trigger, take III *sigh*
<pitti> jibel: ^ that's for bug 902553, hopefully *really* fixed now
<ubottu> Launchpad bug 902553 in perl (Ubuntu Precise) "package doc-base 0.10.3 failed to install/upgrade: ErrorMessage: /usr/bin/perl: symbol lookup error: /usr/lib/perl5/auto/UUID/UUID.so: undefined symbol: Perl_xs_apiversion_bootcheck" [High,Triaged] https://launchpad.net/bugs/902553
<dholbach> can somebody reject https://code.launchpad.net/~snicksie/ubuntu/precise/libgda4/fix-for-typo/+merge/86025 for me?
<dholbach> (fix forwarded to upstream instead)
<Snicksie> ah, sorry dholbach, didnt know it had to be somewhere else :$
<dholbach> hey Snicksie
<dholbach> thanks for your work on this
<pitti> dholbach: done
<dholbach> thanks pitti
<dholbach> Snicksie, no worries - good work on the fix - I hope the fix can get into upstream soon
<dholbach> and then we'll get it for free :)
<Snicksie> where should I put it next time? :)
<dholbach> (I linked to the upstream bug in the merge proposal)
<dholbach> Snicksie, if it's a fix we should immediately get into Ubuntu it's totally fine to file a merge proposal just like you did
<Snicksie> okay, and if its just a typo? :)
<dholbach> in any case it makes sense that if you modify code (and not just the packaging in ./debian/), you send the fix upstream
<dholbach> Snicksie, in that case we usually send it to upstream (the software authors) and get the fix for free with the next version update
<Snicksie> okay, should I send it upstream myself next time or...? :)
<dholbach> I wouldn't want to impose it on you, we're grateful for all the fixes we get - but if you have the time and don't mind doing it, then that's cool
<dholbach> and if you run into any issues, feel free to just ask in here, or #ubuntu-motu
<Snicksie> will do :)
<Snicksie> thanks for explaining :)
<dholbach> no worries :)
<dholbach> ev, do you think you can have a look at the patch in bug 897933 and apply it upstream (the merge proposal gives me "bzr: ERROR: None 0.2 was not found in <PristineTarSource at....")?
<ubottu> Launchpad bug 897933 in libtimezonemap (Ubuntu) "FTBFS: undefined reference to `{tan,log,pow}'" [High,Triaged] https://launchpad.net/bugs/897933
<debfx> could we lower the required dpkg Pre-Depends for xz-compressed packages to 1.15.6~? at least 2 Debian packages use that version.
<dholbach> oh, 0.2.1 in precise seems to have fixed the issue - it seems the fix just needs to go upstream as well
<Snicksie> dholbach, sorry for the incorrect email... seems like I had a small mistake in my bashrc. thanks for notifying :)
<dholbach> :-)
<apw> i wonder if someone could stroke the new linux-ti-omap4 binaries, then i can get the meta up
<cjwatson> debfx: sure, file a Launchpad bug please and I'll take care of it
<cjwatson> (unless somebody beats me to it)
<cjwatson> debfx: preferably include an example package name (for QA)
<jml> "Your computer does not have enough free memory to automatically analyse the problem and send a report to the developers."!
<philpem> Hi all. I'm trying to build a CVS release of Gutenprint in as a .deb package. I'm having a few problems with this, mainly with paths... can anyone help out?
<philpem> These are the last few lines from my buildlog: http://paste.ubuntu.com/772169/
<philpem> It seems to be looking for '../../../src/xml/xmli18n-tmp.h' from a CSD of 'gutenprint-5.2.7cvs20111216/debian/build/po'. This file is actually in the build directory -- gutenprint-5.2.7cvs20111216/debian/build/src/xml/xmli18n-tmp.h
<debfx> cjwatson: thanks, I've filed bug #905322
<ubottu> Launchpad bug 905322 in Launchpad itself "Lower required dpkg version for xz-compressed packages" [Undecided,New] https://launchpad.net/bugs/905322
<philpem> basically, I want a version of gutenprint which works with the Canon CP-800 mini photo printer... the current ubuntu release does not, but CVS does.
<pitti> apw: done
<apw> pitti, thanks :)
<l3on> Laney, ping
<Laney> hello
<l3on> hey :).. I saw your answer at bug #905304
<ubottu> Launchpad bug 905304 in Oneiric Backports "Please backport ruby-rack 1.3.1-1 (universe) from precise" [Undecided,New] https://launchpad.net/bugs/905304
<l3on> problem is ruby-rack does not exist in oneiric
<l3on> what do you suggest ?
<l3on> I would introduce transitional package... what do you think ?
<Laney> it was renamed from libruby-rack
<l3on> Laney, â http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-rack.git;a=commitdiff;h=885afe575fb0b04505c64f908dd364180cbd5bb4
<Laney> which we do have in oneiric
<l3on> yep, you 're right :(
<Laney> so somehow fix that or the depending (broken) package
<Laney> i mean librack-ruby, not libruby-rack
<tumbleweed> oh, I missed that it was a rename, sorry l3on
<l3on> tumbleweed, np :) I'm here to learn :P
<Laney> and at any rate it is always fishy to fix bugs via backports
<tumbleweed> I was tihnking of it as a new package, not a bug fix
<Laney> but the purpose of it is to fix an uninstallability in the main archive
<Laney> anyway, no harm done
<l3on> Laney, I'm trying to build ruby-sinatra depending on librack-ruby instead of rack-ruby
<l3on> we'll see
<Laney> cool, thanks for your work
<l3on> Laney, ok, seems works fine.. installs and runs
<l3on> is it a -proposed ?
<l3on> +ruby-sinatra (1.2.6-1ubuntu1) oneiric; urgency=low
<l3on> No, it does not work properly because:
<l3on> $ apt-file search /usr/lib/ruby/vendor_ruby/rack
<l3on> returns nothing in oneiric
<ManDay> Hello, may someone give a one-line summary of how the LiveCD makes itsself persistent through the casper-rw partition? Is it just a matter of rsyncing shellscripts that syncronize the FS upon shutdown or is it something more complicated like a sort of Union-FS?
<cjwatson> ManDay: it's a union filesystem, specifically (at the moment) overlayfs
<ManDay> Ah okay
<ManDay> Thank you
<cjwatson> you're welcome
<mterry> stgraber, hello!  I have a work item to talk to you about whether ARB still uses /opt/extras.ubuntu.com/?  Last I heard it did, but just confirming for Quickly support
<stgraber> mterry: yes, we still use /opt/extras.ubuntu.com
<mterry> stgraber, cool, thanks
<mterry> stgraber, and it's still useful to the ARB for quickly to create a package that puts things there (i.e. you don't have some other preferred solution to help developers with that)?
<dholbach> broder, I had a look at the atkmm multiarch update - it seems debian/compat needs to be updated to 9. I can add that if you like
<dholbach> (still reviewing it)
<stgraber> mterry: we have some scripts to force a package to put everything in /opt/extras.ubuntu.com but we still prefer if the source package we receive is right to begin with
<mterry> stgraber, awesome, OK
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> debfx: OK, branch for that up for review.  It won't be deployed until at least Monday now, though
<cjwatson> assuming that we can still manage further deployments this year
<seb128> could somebody set https://code.launchpad.net/~jconti/ubuntu/oneiric/webkit/fix_doc_path/+merge/85054 to merge?
<seb128> it was uploaded but the merge request targetted oneiric rather than oneiric-proposed
<pitti> seb128: done
<seb128> pitti, danke
<seb128> (how come you have access to that and not me? ;-)
<pitti> seb128: presumably through ~techboard as the owner of ubuntu branches or somethign like that
<seb128> (or said differently, where do I need to apply to be able to do it?)
<seb128> ok
<pitti> and yes, it's a bug
<cjwatson> it's a bug but maybe you could be added to ~ubuntu-branches or something as a workaround?
<cjwatson> actually, why don't I do that.  TB people, any objections?
<seb128> would that make me receive emails for every merge request? ;-)
<cjwatson> yes
<seb128> so please don't
<cjwatson> I delete a lot of mail
<cjwatson> OK
<seb128> I will maybe ask you after the holidays, but I'm away starting tonight and I don't want to subscribe to some new spamming while i'm not around to set filters etc if needed ;-)
<cjwatson> actually, I think I'll deactivate myself from that team; I'm already a member via techboard, and that way all the mail should land in techboard's moderation trap rather than my inbox where I don't want it
<seb128> could we subscribe like ubuntu-dev or something to do?
<seb128> to *it*
<cjwatson> maybe but it would need to have a contact address that discarded mail
<cjwatson> (and I'd prefer if the UDD folks signed off on something like that)
<seb128> ok, seems like ~ubuntu-core-dev would be a good fit
<seb128> contact email is ubuntu-core-review@luc
<pitti> cjwatson: right, tb@ has tons of merge proposals, always fun to listadmin them away
<Laney> ubuntu-dev would be good
<apw> pitti, any idea where upstream udev repos are, the links we have in the package point to dead web pages (since the kernel.org debackle)
<pitti> apw: http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary works quite fine?
<pitti> apw: I also commit to it  every now and then
<apw> i have some fixes i want to upstream, so thought i'd better base on that
<pitti> cjwatson: of course ti-omap got an abi bump an hour after I uploaded d-i; guess I'll upload another one?
<cjwatson> pitti: if you like
<cjwatson> version numbers are cheap ... ish
<pitti> huge NBS and current images and all that
<Daviey> How many people will be upset if they cannot use d-i with ti-omap until the next upload happend to happen?
<pitti> Daviey: well, it's an update I can do while the meeting and it eases my mind to see http://people.canonical.com/~ubuntu-archive/nbs.html get smaller again :)
<Daviey> lol, ok. :)
<pitti> cjwatson: cheap> at ubuntu94 now -- soon we'll need another byte for it!
<pitti> Daviey: at least I like to do that for the "normal" kernel -- we then get timely feedback through the QA autotests
<cjwatson> I would have merged a while back but upstream moved to git; while I've managed to rewrite most of the other d-i component branches on git imports, that one has defeated me so far
<cjwatson> not urgent, though
<pitti> Daviey: now we don't have that (yet?) for arm images, but I think it's still better to not drag it for too long
<pitti> cjwatson: (I was just kidding)
<cjwatson> yeah :)
<Daviey> pitti: yet is correct :)
<pitti> Daviey: oh, are there concrete plans to auto-test them?
<Daviey> pitti: not concrete, but a /want/.
<pitti> Daviey: ah, ok; well, I /want/ a whole lot of things :)
<Daviey> The trouble is, the current testing is tied to libvirt and using ISO's.
<Daviey> we could port it to use qemu arm virtulisation, so still use libvirt.. but the ISO requirement refactoring might require some love.
<pitti> I guess virtualization in ARM land is still a bit on the experimental/nonexisting side?
<pitti> lxc perhaps?
<pitti> ah no, that's not for image testing, just running test suites
<Daviey> which is a bandwidth issue.
<ogra_> lxc should be good
<Daviey> pitti: what tests are you interested in?
<pitti> Daviey: they are preinstalled, so no installer testing, but e. g. the OEM setup tests apply, as well as simply "does that thing boot into a desktop"
<Daviey> well i'm leaning towards server testing :)
<pitti> jibel and I were also discussign opening all /usr/share/applications/*.desktop files and see if the program starts or immediately crashes
<pitti> Daviey: right; anythign other than 0 helps :)
<Daviey> pitti: I'm still wondering if the server-iso testing method makes sense, but suck in the tarball and boot that in qemu.
<Daviey> Gets around hardware limitations, and is a pretty well tested formula.
<Daviey> jamespage: thoughts? ^^
<SpamapS> hm..
 * jamespage thinks hard
<SpamapS> so the mdadm debian maintainer has forcibly turned off -Werror .. suggesting that its bad because a toolchain update would break the build
<jamespage> yikes
<SpamapS> thats sort of backward..
<jamespage> Daviey, pitti: I agree that virtual arm testing is not a starter ATM
<SpamapS> I think I'll disable that patch during the merge. :-P
<pitti> good night everyone, have a nice weekend!
<SpamapS> pitti: cheers!
<pitti> micahg: lucid langpacks prepared, maverick langpacks are being created; so I'll check for a ping from you over the weekend when to upload them
<Daviey> pitti: o/
<jamespage> Daviey: for server we could setup something with hardware
<jamespage> that uses network preseed installs
<Daviey> jamespage: you don't think it is worth pushing, or won't work currently?
<jamespage> Daviey: TBH my mind is a bit blown and I've not had time to think about it to hard
<jamespage> Daviey: it might work OK for the image testing I guess
<Daviey> jamespage: ah, ok - probably best not blow your mind on a Friday evening :)
<jamespage> Daviey: well at least I get the weekend to recover it :-)
<Daviey> The mess alone, would take all weekend to clean up.
<jamespage> lol
<juliank> SpamapS: Yes, -Werror is not recommended, as it can break with new GCC's because the new GCC adds a warning more.
<doko> gnome broken to install :-/
<juliank> Software releases should never be build with -Werror
<juliank> You don't want to break a build because a new GCC version suddenly thinks you forgot to initialize a variable.
<broder> dholbach: ah, sorry for not being explicit about that. debian/compat => 9 isn't necessary for non dh(1) packages; for multiarch stuff it only affects dh_auto_configure
<broder> slangasek: ^ is there anything i'm missing there? would you mind if i updated the wiki to not bump debian/compat on classic debhelper and cdbs packages?
<dholbach> broder, thanks for letting me know - rereading debhelper(7) what you say makes sense :)
<broder> dholbach: i didn't bump it to minimize the diff, but it's a noop
<dholbach> broder, if the fix lands in Debian, we should be able to just sync and adopt whatever the debian maintainers decided on having
<dholbach> thanks broder for your work on them
<broder> thanks for sponsoring :)
<dholbach> de nada
<cjwatson> SpamapS: I agree with juliank - use -Werror when developing but it simply doesn't scale to 10000 packages in a distribution which some poor sod has to try to fix in bulk
<SpamapS> Ah I thought we had it on by default or something.
<cjwatson> we do not
 * SpamapS makes a note to wait 10 minutes for the espresso to kick in before thinking.
<doko> we do have -Werror=format-security only
<SpamapS> Right thats the one I was thinking of
 * SpamapS turns patch back on. :)
<juliank> Enabling -Werror for implicit declarations might make sense as well, though; if not already using C99
<slangasek> broder: maybe you should check with the cdbs maintainer, which is who put that there :)
<broder> slangasek: ...really? i don't think cdbs even acknowledges the existence of compat 9 yet
<slangasek> cdbs shouldn't in general touch or care about debian/compat
<slangasek> so maybe it's cut'n'waste
<broder> it does at least know about it for its auto-generated build-dep feature
<broder> and to switch between dh_clean -k and dh_prep as appropriate
<broder> and how dh_strip works
<broder> but that appears to be it
<micahg> pitti: thanks, will let you know when stuff is ready
<broder> slangasek: i'll go ahead and edit the wiki, then
<onkarshinde> Can any of the core developers please give back cups in oneiric-proposed on powerpc?
<micahg> onkarshinde: I already told you that won't work, you need a new upload
<micahg> we lost armel also in that build
<infinity> micahg: Eh?  Why wouldn't giving it back work?
<onkarshinde> micahg: I am talking about cups, not gnome-shell.
<micahg> infinity: already in -updates :)
<infinity> (I mean, assuming the ghostscript issue is worked out)
<micahg> onkarshinde: ah, same issue though :)
<infinity> micahg: Yes, so?
<micahg> infinity: I thought you can't publish the same source record twice
<infinity> micahg: ...?
<onkarshinde> Oh. I didn't know that if some binaries are moved to updates you can't give back those who FTBFS.
<infinity> micahg: I'm not sure what you mean by that.
<micahg> infinity: once a source has been published to a pocket, you can't recopy new binaries (at least that's what I was told before0
<infinity> micahg: It's published in both proposed and updates.  And it can certainly still be built and the new binaries copied.
<micahg> infinity: I was told that's not possible yet
<infinity> micahg: We couldn't re-build and re-copy the i396 binaries (and wouldn't want to), but there's no technical reason the ppc/arm ones can't build.
<infinity> micahg: Unless someone broke something when I wasn't looking, it used to be possible...
<Daviey> infinity: I've never seen an i396 build succeed TBH
<infinity> Daviey: Typing is hard.
<Daviey> :)
<micahg> infinity: I've had a few conversations with wgrant about this situation WRT copying from a native PPA to -security or -proposed, is -proposed to -updates different?
<infinity> micahg: I could be misremembering soyuz brokenness.  That's also possible.
<micahg> infinity: it needs a rebuild anyways or different archs will be built against different versions of libgs9
<infinity> I'm okay with "soyuz is broken", but the libgs9 argument is meaningless.
<infinity> If building against different versions breaks things, then we have HUGE problems with how we develop, well, the entire distribution.
<micahg> I guess that might not be a problem in this case
<infinity> It better not be. :P
<infinity> If libgs9 broke ABI without an SOVER bump, we have slightly bigger concerns.
<infinity> (Which I'm sure it didn't, just sayin'....)
<micahg> infinity: eh, I guess 1 for 2 isn't too bad this "early" :)
<infinity> micahg: So, the more curious question, if both these builds failed due to obvious archive skew, why was the copy to -updates done without retrying them first? :/
<micahg> infinity: indeed, was thinking the same thing
<micahg> infinity: are you retrying the powerpc build just to see if it works?
<infinity> Kinda curious what Soyuz will do. :P
<infinity> I can actually create build records for that source in -updates, which would work around the issue as-described.
<micahg> I'm wondering if in-archive is different
<infinity> But the whole thing sounds just plain wrong.
<micahg> since it's the same shared pool
<onkarshinde> While we are discussing this, I just build cups in oneiric chroot on my machine.
<onkarshinde> If you want I can try hplip as well.
 * micahg wonders why it was allowed to get this broke
<infinity> Dunno.  And I can't find any obvious indication of who did the copy.
<slangasek> audit trails are for sissypanst
<slangasek> ts
<infinity> Apparentyl.
<infinity> That's hard to type on purpoes.
<slangasek> I know, rigth?
<micahg> do the SRU copy scripts check for arch skew?
<infinity> micahg: No, though they do tell you what they plan to do before you commit.
<infinity> micahg: But at that point, it's too late, if someone's decided "ports don't matter".
<infinity> micahg: But I'd like to think people aren't doing that.  Security certainly don't.
<micahg> infinity: our copy scripts warn if you're missing an arch :)
<onkarshinde> if 'ports don't matter', specifically powerpc then all the packages on this port should be in universe. So that people like me can take care of it. :-)
<infinity> onkarshinde: Ports matter.
<micahg> onkarshinde: and the archive doesn't work like that :)
<onkarshinde> I know. Just kidding. :-)
<infinity> micahg: Actually...
<infinity> micahg: Per-arch overrides are a fantastic soyuz misfeature.
<micahg> infinity: the binaries could be, but we build from source, so I guess a better way to put it is Ubuntu doesn't work like that
<infinity> Well, yes.
<infinity> Either way.  This sort of thing annoys me.  I can understand people punting on terribly painful porting bugs in an SRU, but not "giving back builds is hard".
<infinity> Or, perhaps, just "counting to four is hard".  I dunno. ;)
<micahg> maybe SpamapS can add a safeguard to check for that in the SRU scripts (we have that in our unembargo script)
<infinity> There are fancy scripts other than copy-package.py on ftpmaster?
<infinity> Am I living in the past again?
<onkarshinde> Me leaving now friends. Will bug again tomorrow for more give backs.
<micahg> infinity: I have no idea, I just know he's been tweaking stuff to warn about possible issues
<micahg> onkarshinde: thanks
<slangasek> infinity: there's an sru-accept script in ubuntu-archive-tools?
<slangasek> but I guess micahg's referring to the security-specific ones
<micahg> infinity: maybe it can warn on the report page that it's not ready to be copied and why
<infinity> slangasek: Ahh, never used it.  Though I haven't been on the SRU team for years.
<james_w> great work cjwatson, thanks
<cjwatson> I doubt I'll ever personally reclaim the time spent
<cjwatson> but maybe collectively we will :)
<cjwatson> sru-release too
<cjwatson> infinity,slangasek: ^-
<slangasek> right, that's the one that times out on kernels :)
<cjwatson> heh, yeah
<cjwatson> that's because it's using syncSource
<SpamapS> micahg: can you summarize what I might be protecting against? The backscroll is dizzying
<infinity> SpamapS: proposed->updates copies when not all arches are built.
<SpamapS> That should be easy enough to build into sru-release
<micahg> SpamapS: I'd suggest warning on the SRU report about it as well
<infinity> SpamapS: It needs to be an annoying, flashing, over-the-top, Mardi Gras warning that tells people that they're Very Bad People for not looking at the failure logs.
<infinity> SpamapS: Instead of a simple "You're about to shaft some users of !x86, do you care? [N/y]"
<SpamapS> micahg: yes, thats a good plan.. no "green light" until all arches are built
<SpamapS> infinity: we can make it just stop, dead.
<SpamapS> I'm not against adding --ignore-unbuilt-arches for the urgent case
<infinity> SpamapS: The problem with that is that it's sometimes valid to release without all arches (say, something that was never built correctly on armel).
<micahg> SpamapS: well, if it's not a regression (i.e. the arch didn't build before), then it could be green, sometimes it's worth overriding though, i'd suggest a warning next to it, maybe yellow vs green or red
<infinity> SpamapS: And if there's a force flag, people just add that to their workflow.
<infinity> (Oh, how I wish the above weren't true)
<SpamapS> infinity: in this case, there are 3 - 5 of us, all of which can be held to a lot higher standard than "people".. we're at least "SRU people"
<infinity> But look at how often people type "rm -rf" instead of "rm -r" (when the latter would clearly work for 99% of your recursive deletion needs)
<micahg> SpamapS: well, hplip and cups managed to migrate from -proposed to -updates w/out armel or powerpc
<infinity> SpamapS: Well, yes.  I do hold you to a higher standard, which is kinda why I wonder that warnings from tools are even necessary to avoid this sort of thing. :P
<infinity> SpamapS: But, meh.  Mistakes happen.  Mitigating them is nice.
<SpamapS> micahg: right, this seems serious enough and simple enough that it should be solved now, before we forget this atrocity. ;)
<SpamapS> I like to think that the tools should not be expected to enforce the standards, but justs to remind us of our high standards
<SpamapS> which is why the tool also puts up a big warning "HEY THERE IS ALREADY AN UNAPPROVED UPLOAD IN PROPOSED"
<SpamapS> It reduces the steps necessary to do the job.. I don't have to go check, I just expect that the warning will tell me when I need to do that step.
<infinity> I suspect ubuntu-archive-tools needs to grow a dependency on cowsay for all our warnings.
<micahg> SpamapS: that's the problem with these checks though, they train us to rely on the tools
<SpamapS> me resists the urge to run /exec -o cowsay +1 in #ubuntu-devel
 * SpamapS also resisted the urge to type /me
<SpamapS> micahg: um, if we cannot rely on deterministic tools , what can we rely on?
<SpamapS> micahg: I mean, I'm asking the tool to do, via the API, the same check I'd do manually via the web interface...
<micahg> SpamapS: well, it's shouldn't be an excuse to not think about these things at all, i.e. you know what steps you need to take, the tool is helping you streamline
<infinity> The tool could ask a remote machine to take a picture of the web UI via a mindstorms-controlled camera, and then email you the resulting jpeg.
<SpamapS> infinity: christmas holiday project selected, thank you
<infinity> Use some pattern detection software to find the little "failed" icons, and circle them in crayon.
 * SpamapS starts working on connecting a kinect to his mindstorms
<SpamapS> micahg: who is making excuses? I can use my browser and my eyes, or a script. Honestly, I trust the script to be more consistent than me. :)
<SpamapS> There's another problem which is that the verification-done is never arch specific
<SpamapS> I suppose we just wave our hands over that..
<Daviey> The tool should make it harder to go against the recommendation IMO.
<Daviey> I trust tools more than my own eyes, lointian catches MUCH more stuff that i ever would.
<Daviey> dput checking that *.changes are signed before tey upload... sure i can ork around it, but it's noce to have the check.
<SpamapS> Daviey: less IRC, more whiskey. ;) srrsly, shouldn't you actually take the holiday you're on? ;-)
 * SpamapS just went over his emoticon quota for the day, #$!@
<micahg> SpamapS: I'm saying, that you shouldn't be replaced with a cron that checks what the script checks and if all the tests pass, copy, there should be some human sanity check that happens as well
<micahg> SpamapS: that human sanity check is understanding the process and verifying that the requirements are met (even with the help of the scripts)
<infinity> Daviey: lointian?  Do I even want to know what checks that's performing?
<slangasek> I: codpiece-not-recommended
<SpamapS> micahg: of course. So you agree then, the release script should tell me what arches are, and aren't, built, and if they're not all built, it should error out. :) likewise, the report should show the same level of built/unbuilt. :)
<micahg> Daviey: sure, I'm not saying not to use the tools :), just saying that you shouldn't blindly trust lintian either (that's why we have overrides, scripts can be wrong)
<micahg> SpamapS: oh, definitely, but I think you still need to be aware of the check :)
<raphink> Is it normal that /etc/ld.so.conf.d/zz_i386-biarch-compat.conf as distributed by libc6-i386 doesn't contain /usr/lib32/mesa ?
<slangasek> yes
<slangasek> just as /usr/lib/mesa isn't put on the path by libc6
<raphink> google-earth failed to load for me
<Daviey> *glug*
<raphink> but it works after I add /usr/lib32/mesa to the path
<raphink> or is it another inclusion path that's missing?
<raphink> for example, it couldn't find libGL.so.1
<slangasek> install libgl1-mesa-dri:i386 instead?
<raphink> well, ia32-libs already provides it in /usr/lib32/mesa
<raphink> and it works
<raphink> so why should we install a package from another arch (unless that's the new way and ia32-libs is not supposed to be used anymore?)
<micahg> raphink: https://lists.ubuntu.com/archives/ubuntu-devel/2011-October/034279.html
<raphink> ok
<raphink> so that's the way in precise, thanks
<raphink> the machine I couldn't get it to work on runs oneiric, and I hadn't considered this might have changed in precise
<slangasek> raphink: ia32-libs has *never* had correct handling of libGL; it's always worked only for one libGL implementation at a time because it didn't implement the alternatives handling used for the native libs, and it's not the responsibility of libc6-i386 to fix this
<slangasek> it needs to be fixed by having the packages you're installing to get 32-bit libGL do the same alternatives handling as the native ones... which we address by having you actually install the 32-bit libGL packages
<arges> Hello. Is there an easy way to 'apt-get source' a package from an older version of ubuntu. i'm running oneiric, but want to get the sources to a lucid package. i'm guessing I should be using a separate chroot? thanks
<broder> arges: pull-lp-source from ubuntu-dev-tools
<broder> there's also chdist in devscripts, but it's harder to setup
<arges> broder, cool thanks. downloading the ubuntu-dev-tools now
#ubuntu-devel 2011-12-17
<barry> slangasek: are you still around?
<slangasek> barry: yep!
<barry> slangasek: i am seeing something very weird with dbus-python tests, which i think i've tracked down to a bug in oneiric's dbus.  i'm looking for a little sanity check if you have a few minutes
<slangasek> barry: ok, what are you seeing?
<barry> slangasek: it starts with this: https://bugs.freedesktop.org/show_bug.cgi?id=43303
<ubottu> Freedesktop bug 43303 in python "dbus-python test suite failures" [Normal,New: ]
<barry> so the upshot is that this fails on oneiric but not wheezy
<barry> slangasek: turning on DBUS_VERBOSE=1 gives some more information about what's happening
<slangasek> interesting
<barry> slangasek: what i think is going on is that dbus is finding the dbus-python's .service file *and* correctly parsing it/adding it, but then the function in dbus which does this is returning a FALSE status unconditionally, even though it should return a TRUE status
<barry> slangasek: now, grab oneiric's source for dbus
<slangasek> does the problem occur or not with precise/
<barry> slangasek: that's a great question.  i haven't been able to set up an environment to test that yet
<barry> slangasek: but, by looking at the code, i think the bug is obvious ;)
<slangasek> oh
<slangasek> well, let's just fix it then :)
<barry> :)
<slangasek> is it worth an SRU?  i.e., does it break things in practice besides the python-dbus test suite?
<barry> slangasek: i'm still trolling through source package bugs, but i don't see a matcher yet.
<barry> slangasek: but i think it only affects .service files in non-standard locations, so it's unlikely to affect normal operation
<barry> slangasek: fwiw, the bug is in bus/activation.c, update_desktop_file_entry().  if you look at the bottom of the function, it turns FALSE unconditionally, but it should return retval (which would be set to TRUE in this case).
<barry> slangasek: and in fact, on sid and precise, that's exactly what it does
<barry> slangasek: i have verified that it works on sid, but i will definitely test precise next!
<slangasek> ok
<barry> slangasek: i don't know if the bug was upstream but i don't see any debian/patches that would affect it
 * slangasek nods
<slangasek> so provided that it's fixed now in precise, it probably makes more sense to just get you using precise and not bother with an SRU for this
<barry> slangasek: agreed. unless there's a open bug on oneiric that could be caused by this
<slangasek> not one that I've heard of... I guess the desktop team might've heard more
<barry> i guess i know one thing i'll be doing on xmas break (upgrading my main desktop to precise :)
<slangasek> :-)
<barry> slangasek: ok cool.  anyway, thanks for letting me talk this out.
<slangasek> no problem!
<barry> have a good weekend!
<slangasek> you too
<barry> slangasek: well, i don't think that's the whole story, but i'm giving up for now :)
<rubyplusplus> Anyone ever use the twitter bootstrap modal?  I was using it successfully, now I'm not sure what changed, but now it's showing onload
<dnewkirk> #ubuntu-app-devel
<ManDay> I guess you are a better audience for this question:
<ManDay> Starting off from a debootstrap oneiric minimal chroot, I installed things like xfce4 and lightdm (and of course, all their dependencies) and also linux-generic and CASPER into that chroot and burned it onto an USB stick (not squashfs'ed). Now when I boot that USB stick, using the initrd of the linux-generic I get dropped into busybox with the prompt "(initramfs)". Why does it not boot normally? Is
<ManDay> it because of casper?
<ManDay> Judging from the init in the initrd, it provides $REASON which claims "No init found".
<ManDay> Anyone?
<ManDay> I think I might be missing a kernel parameter, but I wouldn't know which!
<ManDay> Unless... of course...
<ManDay> Yes, that must be it: If I don't casper-boot, I need to specify the root= explicity!
<ManDay> Yes, that works.
<yogi> I'm trying to load Precise Pangolin on a Dell 10 Mini (with the infamous Poulsbo chipset).  Both the alpha 1 and the daily are crashing on boot
<yogi> the machine is locked stiff - there is a IRQ in the middle, native_smp_send_reschedule
<penguin42> yogi: Report it then, I guess a screenshot of the oops is probably the most useful info from the crashed machine
<yogi> UGH - attaching the screenshot crashed my Chrome with 25 tabs!
<yogi> https://help.ubuntu.com/community/ReportingBugs is not helpful
<penguin42> yogi: File it against linux, and attach the screenshot, also if you can boot something older on it then run apport-collect   and the bug number just to collect info about the hardware
<yogi> Timeout error
<yogi> Sorry, something just went wrong in Launchpad.
<yogi> penguin42: I'm on https://bugs.launchpad.net/
<yogi> what is the quickest way to submit a bug?
<yogi> I understand the need to filter the incoming bugs somewhat
<yogi> but there is not 'Submit a bug' button on the main page
<yogi> I guess I should submit a ...   Nevermind!
<penguin42> yogi: Just run ubuntu-bug linux     from something that boots
<yogi> it asks me for admin password, on my other box
<yogi> why wasn't I given the option to not attach all those log files?
<Riddell> ScottK: who care about boost now?  libboost-graph1.46-dev doesn't depend on libboost-graph1.46.1
 * Riddell reports bug 905772
<ubottu> Launchpad bug 905772 in boost1.46 (Ubuntu) "libboost-graph1.46-dev does not depend on library" [Undecided,New] https://launchpad.net/bugs/905772
<debfx> Riddell: http://bugs.debian.org/651337
<ubottu> Debian bug 651337 in libboost-graph1.46-dev "libboost-graph1.46-dev: Dangling symlink" [Normal,Open]
<Riddell> that's the one
<debfx> Riddell: does it cause a build failure?
<Riddell> debfx: it did cause rocs to fail in the ninjas PPA until I added it
<ScottK> Riddell: No one, really.  ajmitch pretends he doesn't care, but deep down inside, he does.
<ajmitch> ScottK: trying to pin blame on me?
 * Frostbite pins a tail on ajmitch 
<ManDay> Casper hangs for more than a minute after it says "Running init-bottom". It then says  "* Stopping configure virtual network devices      Waiting for network configuration...         Waiting up to 60 more seconds for network configuration"      I've got no idea where this is coming from, GREPing through the scripts returned nothing. Any idea what to do?
<broder> ManDay: check your /etc/network/interfaces file - it should only have a block for the lo interface
<penguin42> ManDay: I could swear I saw a bug in the list for stuff to fix on PP along the lines of 'waiting to configure already configured network devices'
<ManDay> broder: Has   auto lo    iface lo inet loopback
<broder> ManDay: and nothing else? ok, i don't know then. but the waiting messages are coming from /etc/init/failsafe.conf
<ManDay> penguin42: I'm not certain it's actually a bug in Casper. Could be that I negelected to give it somethign that it wants
<ManDay> broder: Thanks, that's greatly helping me!
<broder> ManDay: it's not capser. by the time you get to "Stopping configure virtual network devices", you're past casper code
<ManDay> broder: It works without casper (meaning unsquashed, boot=local) though.
<ManDay> broder: Weird script... It just has sleeps in it...
<broder> ManDay: it's designed to delay the boot until manually configured interfaces in /etc/network/interfaces finish initializing
<ManDay> I spot "initctl" in there. I did NOT follow the instructions of "CustomizedLiveCDFromScratch" which said something about replacing initctl
<ManDay> These here:
<ManDay> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch#Make_the_ChRoot_Environment
<ManDay> A bit further down
<ManDay> Could it be related?
<broder> no. you only need to move initctl out of the way while you're building the chroot; you should undo it before you squash the fs
<ManDay> I wasn't planning on becoming an Upstart expert :-/
<ManDay> I guess I'll just delete those sleeps and let it fall right through
<ManDay> I have no clue what I'm actually doing, though
<ManDay> I did not install any of casper-lupin, discover, laptop-detect, os-prober either, as the CustomizeLiveCDFromScratch Tutorial suggests. I guess that's not a problem, either?!
<broder> those shouldn't matter. when you say you didn't follow the instructions about initctl, does that mean you didn't do the dpkg-divert step, or you didn't undo the dpkg-divert in the "Cleanup the ChRoot Environment" section?
<ManDay> Neither, broder
<ManDay> Since everything seemed to work and it wasn't really clear what those steps were good for (and the tutorial is a little aged, anyway) I didn't deem them necessary
<broder> they are necessary to prevent random programs from the chroot getting left behind on your system
<broder> but they shouldn't affect the output
<ManDay> on MY system!? outside of the chroot?
<broder> yes
<ManDay> **** sake
<ManDay> you mean running or actually persistent on disk?!
<broder> http://upstart.ubuntu.com/cookbook/#run-upstart-in-a-chroot-environment
<broder> running
<ManDay> ok, not a problem them
<ManDay> for a second I was dreaded ubuntu had shat into my perfect gentoo setup
<ManDay> :P
<broder> oh, if you're not using upstart outside of your chroot then yeah, it probably wouldn't matter
<ManDay> nvm anyway, i just rememberd that i only did that on the first few tries. later on I always did that from a livecd enviroment
<broder> and your live environment comes up once the wait in failsafe times out
<broder> ?
<ManDay> broder: Yeah. Goes straight into console with the "ubuntu" user that I set up, as casper should
<ManDay> From thereon I can startx and everything and it works without an issue
<broder> is the lo interface up when you get to the console?
<ManDay> any more questions?
<ManDay> cos I'll have to boot back into it to check
<ManDay> so I'd rather check several things at once, if you require more info
<ManDay> or wait,
<broder> i guess...what's the status of the lo interface
<ManDay> no, dont wait. For a second I thought I could use another computer, but that would complicate things
<broder> and what does "sudo ifquery --list --allow auto" print out
<ManDay> "ifquery" - never heard of
<ManDay> ok, ill check that
<ManDay> see you in a bit
<ManDay> broder: ping
<broder> ?
<doko> damn libubuntuone
<ManDay> That command returns   lo  eth0 eth1 eth2 ath0 wlan0    - suprisingly though, I only got ath0 and wlan0 - I don't have ethernet adapters.
<ManDay> broder: ^
<broder> well, that would be the problem. for some reason it's deciding that you need to be bringing up all of those interfaces before your networking is initialized
<broder> you're really sure that your livecd's /etc/network/interfaces doesn't list any of those?
<ManDay> another strange thing is that when I boot the FS with casper WICD (XFCE wlan client) only finds 2 networks - as opposed to a dozen when I boot "normally"
<ManDay> that's all a little strange with casper
<ManDay> it better should not mess so much with my system!
<ManDay> broder: hold on I check again
<ManDay> broder: positive
<ManDay> it says here, verbatim
<ManDay> # interfaces(5) file used by ifup(8) and ifdown(8)
<ManDay> auto lo
<ManDay> iface lo inet loopback
<ManDay> (in the squashfs' etc/network/interfaces)
<ManDay> let me check the initrd, too
<broder> initrd shouldn't matter
<ManDay> thought so. I'll check nonetheless
<ManDay> yep. It's not even there in the initrd
<broder> are /run and /var/run in the squashfs empty?
<ManDay> latter has a symlink to former, and former is by far not empty
<ManDay> dbus  do-not-hibernate  init.upgraded  lock  motd  network  utmp  wicd
<broder> what's in /run/network?
<ManDay> just let me understand what it's happing: It's after the point where Casper has invoked the native init, right? That init is Upstart which walks the /etc/init and brings up services as configured.
<ManDay> Right?
<broder> yes
<ManDay> empty.
<broder> hmm
<ManDay> So and ONE of the services causes that delay. Which service is it?
<broder> /etc/init/failsafe.conf is blocking the boot because it thinks you still have more network interfaces that need to be brought up
<ManDay> "Failsafe" is the name of the service?!
<broder> well, it's the name of the job
<broder> it's intended to solve a problem on servers where the system was booting fast enough that old-style /etc/init.d/ scripts would get run before the network devices were initialized -  bug #580319
<ubottu> Launchpad bug 580319 in upstart (Ubuntu Natty) "init.d controlled services launch before all interfaces are up, thus failing to start" [Medium,Triaged] https://launchpad.net/bugs/580319
<broder> and you're triggering this logic because ifquery is concluding that it eth0, eth1, eth2, ath0, and wlan0 are all statically configured interfaces
<ManDay> I'm looking at that job's config and it seems rather unconditionally waiting  - there is no IF check whatsoever. It just has those couple of sleeps in there and the config of being started upon filesystem and "net-device-up" events...
<broder> yes, but there's the "stop on static-network-up" at the top
<ManDay> I'm wondering how things would have to work out so that Upstart does *not* stumble across those sleep's
<ManDay> broder: Ah!
<broder> when static-network-up gets emitted, upstart kills the job
<ManDay> Understood
<ManDay> so the problem is actually in static-network-up which does not get fired!
<broder> right. static-network-up is fired off by /etc/network/if-up.d/upstart
<ManDay> unhuh... I'm grep'ing like crazy ;)
<broder> /etc/network/if-up.d/upstart is run by ifup, which is run by either /etc/init/network-interface.conf or /etc/init/networking.conf
<ManDay> But the real question is why Casper affects this...
<broder> it absolutely should not
<broder> casper should be totally out of play at this point
<SpamapS> ugh
<SpamapS> I think I' about 10 minutes late from saving you guys .. well.. 10 minutes. ;)
<broder> oh look! SpamapS! :)
<SpamapS> You have, in fact, discovered the secret of static-network-up. Well done. ;)
<broder> SpamapS: i knew that. my current question is why ifquery --list --allow auto is printing out 5 interfaces that aren't in /etc/network/interfaces
<ManDay> broder: I'll unsquash again just to be absolutly sure I'm not telling you nonsense
<SpamapS> the key is really not what /etc/network/interfaces says, but what ifquery says.
<SpamapS> broder: something is likely messing with the ifstate file
<broder> SpamapS: i was deliberately delaying fetching up the ifupdown source for as long as i could get away with :)
<SpamapS> ManDay: whats in /run/network/ifstate ?
<SpamapS> should be nothing but lo=lo
<ManDay> SpamapS: Second. I'm currently trying this on another machine to see whether the results differ
<ManDay> Same results there.
<ManDay> SpamapS: You mean in the squashfs, or after I booted?
<SpamapS> ManDay: at the point where ifquery --list --allow auto is printing 5 interefaces
<ManDay> SpamapS: That would be after boot. I'll have to leave you again to check this.
<ManDay> Be back in a second, I'll go online on another machine
<ManDay> Which file did you want to know again?!
<SpamapS> ManDay: /run/network/ifstate
<ManDay> Has lo=lo wlan0=wlan0
<ManDay> ifconfig only has lo and lwan0, too, if that matters
<SpamapS> but does ifquery --list --allow auto show more?
<ManDay> yes, it shows those 5 I mentioned
<ManDay> eth0 to eth2, wlan0, lo, and ath0
<ManDay> wlan0 and ath0 being two physically existance devices (wlan and bluetooth)
<SpamapS> ok, can you do 'strace -e trace=open,stat ifquery --list --allow auto' and pastebin it?
<ManDay> i don't have strace. I would have to install that which may take a while,
<SpamapS> its pretty small
<ManDay> in fact, it should take so long that i'd rather do it tomorrow
<SpamapS> and its worth it to figure out where ifquery is getting its faulty information
<ManDay> yes but i need to integrate it into the squashfs or something
<SpamapS> Oh you're not able to write?
<ManDay> SpamapS: Like what?
<ManDay> well, i could get strace from my host system
<SpamapS> sudo apt-get install strace
<SpamapS> no?
<ManDay> SpamapS: no, somehow, when I boot with casper my wireless doesn't pick up my home network
<SpamapS> AH
<ManDay> (it picks up other networks, but only 2)
<SpamapS> can you hang on a second I'll try and dig through the code and see what else it might be consulting than ifstate and /etc/network/interfaces
<ManDay> let me see whether the local strace of my gentoo host is compativle
<SpamapS> what version is this btw?
<ManDay> oneiric
<SpamapS> ManDay: can you look at /etc/NetworkManager/nm-system-settings.conf ? Are those other 3 interfaces listed there?
<ManDay> strace worked
<ManDay> it opens:
<broder> i think that's spelled /etc/NetworkManager/NetworkManager.conf these days, unless ifupdown is specifically looking at the old path
<ManDay> /etc/ld.so.cache   /lib/x86_64-linux-gnu/libc.so.6   /etc/network/interfaces   and /var/run/network/ifstate
<ManDay> SpamapS: I don't have NetworkManager
<SpamapS> char *nm_system_settings = "/etc/NetworkManager/nm-system-settings.conf";
<SpamapS> broder: from ifupdown. :p
<broder> eww
<SpamapS> ManDay: weird, so thats very confusing.
<SpamapS> anyway, I have family stuff to attend to
<ManDay> SpamapS: well, at least we have seen where ifquery got the faulty info from
<SpamapS> but this may be a helpful clue as to why there are a few people out there with inexplicable waiting.
<ManDay> /etc/network/interfaces
<SpamapS> ManDay: are all 5 interfaces listed there?
<ManDay> yes
<SpamapS> OH
<SpamapS> thats the problem
<SpamapS> how did they get there?!
<ManDay> casper
<ManDay> what else :-/
<ManDay> they are not in the squashfs
<ManDay> or...
<ManDay> ill just double and triple check
<SpamapS> that does make sense I suppose
<ManDay> dont want to pass out wrong info
<SpamapS> but yes, that is the problem
<SpamapS> I don't know anything about casper
<SpamapS> but if it is generating an interfaces file that brings up *all* interfaces, then it will result in a long wait unless they all are up instantly
<SpamapS> I'm starting to think that we need a 'nowait' group to put interfaces in for systems that don't use NetworkManager
<SpamapS> so they can be brought up, but not waited on
<SpamapS> anyway, I have to run
<broder> SpamapS: might be able to abuse the "allow" syntax for that
<Bert_2> Hi, I would like to ask some questions concerning possible incorrect dependencies of a package, is this the right channel ?
<SpamapS> ManDay: definitely need to stop casper from making them 'auto', or the system will wait for them to come up, by design.
<SpamapS> broder: I intend to actually
<ManDay> according to broder casper is harmless...
<ManDay> "wouldn't do such a thing"
<ManDay> eh, broder ;P
<SpamapS> It makes since that casper would do that, if it wasn't going to use NetworkManager
<broder> .......oh god
<ManDay> i can confirm that the file does not look like that on the squashfs
<broder> where did /usr/share/initramfs-tools/init-bottom/23networking come from
<SpamapS> But really all we've done is reinstate the old behavior of ifup in Debian past where it would wait until 'ifup -a' finished
<SpamapS> anyway, I have to go
<SpamapS> good luck!
<ManDay> good bye SpamapS
<ManDay> see you around
<broder> ManDay: http://paste.ubuntu.com/773836/
<broder> from /usr/share/initramfs-tools/init-bottom/23networking
<ManDay> broder: Is that in the initrd?
<broder> yeah
<broder> i've never noticed that code before, but it is absolutely most definitely responsible for your problem
<broder> and it's probably a bug that it's there
<Bert_2> anyone ?
<ManDay> broder: Looks like that's it.
<ManDay> Curious how that has worked in the first place...
<ManDay> Doesn't seem to happen with the "normal" LiveCD
<broder> ManDay: installing NM is the easy solution. ln -s /bin/true /usr/sbin/NetworkManager might work as a substitute but i can't make any promises
<broder> because the normal livecd has NM installed
<ManDay> Meaning what? Does NM undo that?
<ManDay> (Remove the IFs again)
<broder> "[ ! -x /root/usr/sbin/NetworkManager ]"
<broder> that code only runs if NM isn't there
<ManDay> Oh, sorry, didn't look
<ManDay> closely enough
<ManDay> Okay. Want me to file a bug on it?
<broder> probably. looks like that code dates back to dapper
<Bert_2> Hi, I would like to ask some questions concerning possible incorrect dependencies of a package, is this the right channel ?
<broder> !ask | Bert_2
<ubottu> Bert_2: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<Bert_2> Alright, so I get constant question about the Belgian ID application at the local computerclub
<ManDay> Jeez broder , I'm sorry but I guess you will have to do this. Launchpad sends me arround in circles.
<Bert_2> the BeID package that people install from softwarecenter doesn't install the requered smartcard-deamon and the driver for the smartcard-reader
<broder> ManDay: there's a link at the bottom of the wiki page it bounces you to
<Bert_2> therefor they can plug in their readers, install the app and sit there with the app open, claiming there is not smartcard-reader connected
<Bert_2> that's why I think that beid-gui should have dependencies on pcscd and libacr38u and a few other packages
<Bert_2> now is this a valid argument that I should file a bug about or is this just against the "rules" of dependencies ?
<ManDay> broder: Got it
<ManDay> broder: initramfs-scripts is an integral part of casper, is it not?
<broder> ManDay: yes, but the bug here is in casper
<ManDay> Ubuntu's pastebin is a pain in the ass, just by the way...
<ManDay> Don't use it, please
<ManDay> bug #905828
<ubottu> Launchpad bug 905828 in casper (Ubuntu) "init-bottom/23networking causes 2 minute delay" [Undecided,New] https://launchpad.net/bugs/905828
<ManDay> Thank you broder
<Bert_2> people, can someone please answer my question cause I'm going to bed soon...
<Bert_2> oh well, I'll try again tomorrow
 * doko demoted python-central, one more to go for python-support ...
#ubuntu-devel 2011-12-18
<Tuxiscool1> Hello. Since Unity started to be used by default in 11.10, I noticed that my application's menus are showing without their icons when the app uses the global menu. However, I've noticed that by using icons that are loaded from a system icon theme, they show correctly in the unity global application menus. So, in order to work around this, I figure I'll add Icons temporarily to a theme, but I need a few suggestions as to how I can go
<micahg> pitti: sorry, but I don't think I'll be able to get Firefox up tonight, will try to get it up later today so when you start tomorrow it should be ready (hopefully)
<ManDay> Do I see this right that casper has no means for autologin unless running a Display Manager?
<ogra> hmm, whoever approved nvidia-tegra into the archive, a BIG THANK YOU ! ... but it somehow ended up in universe ... should be multiverse (unsupported binary drivers)
 * ogra would really like to see who accepted a package in the accepted message
<niels_> Hello im Niels and im new to ubuntu development
<sagaci> hi niels_
<Ampelbein> Riddell: Hi! Was the removal of kalgebra-dev in https://launchpad.net/ubuntu/+source/kalgebra/4:4.7.90-0ubuntu2 by accident or is it gone forever?
<niels_> hi Id like to join the ubuntu development but im really new at this
<Ampelbein> !development | niels_
<ubottu> niels_: Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<niels_> ok i have already configured launchpad and stuff
<niels_> but how do i join a project
<niels_> whats a good project to start on?
<sagaci> what are you interested in
<Riddell> Ampelbein: it's mostly now in analitz-dev
<Riddell> Ampelbein: which I'll upload tomorrow
<Riddell> Ampelbein: what do you need it for?
<Ampelbein> Riddell: I was looking at the NBS list, cantor lists it as a build-dep.
<Riddell> oh there's a new cantor to go with it
<Riddell> it's all in the PPA, kalgebra was uploaded a bit early by accident
<Ampelbein> I see, thanks!
<ManDay> Do you see a way which does not require hacking squashfsroot/etc/init/... to make casper auto-startx with the $USERNAME?
<ManDay> Casper could need quite some updates. Looks like most of the code dates back to 8.04 and has a lot of "extremely ugly hacks" as the comments put it
<Cheery> first time after I started using unity I consider stopping using ubuntu alltogether. it reminded me from one very nasty.
<Cheery> the problem existed before gui change as well.
<Cheery> but in different setting.
<Cheery> Say there comes a need to configure something in ubuntu. so okay you quickly find the setting you have to change because you have search engines and help files and whatnot.
<Cheery> the setting is layed into a graphical interface.. that's rather okay even if unnecessary
<Cheery> now then say you have 'Open With' and you'd like to use ~/software/newest-blender for it.
<Cheery> the actual feature you think should do this will bring you an 'assistance' menu that doesn't contain your blender in it!
<Cheery> but that's not bad still.
<Cheery> now comes the most deterring part.
<Cheery> when you search for solution, you get instructions for using that gui setting and nothing else.
<Cheery> I even found a forum post:
<Cheery> http://ubuntuforums.org/showthread.php?s=04e9c7d6b9d25bdf1a8def4d722a6cab&p=11545913#post11545913
<Cheery> hey that's a good answer! except that the poster DID knew it already. :D
<Cheery> and it fucks everyone off.
<Cheery> you could overall help the user best by pushing the settings into single same place conceptually, yet keeping them physically separate.
<Cheery> global configuration doesn't always work though.
<Cheery> I'll think up something.
<Cheery> about every config in linux is a textfile anyway. but some actually require gui to get them properly configured. :)
<Cheery> '-
<Cheery> alright. now I found it. with some more effort.
<dobey> Cheery: i don't quite understand what point you were trying to make :)
<Cheery> dobey: you have guis for changing settings and occassionally there happens that gui doesn't help you at all.
<Cheery> dobey: but it doesn't end there
<dobey> what do you mean by "help you" there?
<Cheery> normally you'd change setting by typing config lines into a file.
<Cheery> it's supposed to help you if you make a gui for changing those settings without opening the file.
<dobey> i don't think a gui is supposed to necessarily help with that
<Cheery> dobey: anyway. when you search for setting that gui app which was supposed to do what you wanted harms you because all your searches route to that app.
<dobey> and i don't think users snould normally be changing configuration like that
<dobey> were you complaining about unity, or configuraiton in general?
<Cheery> dobey: ubuntu. though this appears in windows, which is why I don't use windows
<Cheery> it may appear elsewhere as well.
<dobey> changing things you shouldn't be changing, may break things, yes
<dobey> that's not limited to software :)
<Cheery> as 'open this file with a specific software I downloaded myself to a local file?'
<Cheery> you may consider that's not a common thing to do. but you just screw yourself there because that's just plain ignorancy.
<dobey> open the application, go to File->Open, find the file, click "Open"
<Cheery> dobey: and what do you do with the nautilus app you've got?
<Cheery> dobey: or auto-open in your browser? :)
<dobey> i think everyone wants to get rid of file browsers in general
<Cheery> because you can mutilate your way through doesn't mean things should be broken.
<dobey> but all the necessary underlying pieces aren't quite there yet to enable that
<Cheery> how do you get rid of file browser?
<Cheery> you can replace it with a better app, yes.
<Cheery> that'd be preferred actually
<dobey> meaningful and useful search and indexing of files
<JanC> dobey: I see no reason to get rid of file browsers, although they could become somewhat more intelligent sometimes...  ;)
<dobey> JanC: because browsing files is pretty much never what you want to do
<Cheery> dobey: and what do you do when you want to create a directory?
<dobey> file browsers are just very tedious and manual search interfaces
<dobey> Cheery: you don't, because directories are meaningless
<Cheery> dobey: if they are, why are they there from the start?
<dobey> meaningless to users, not to computers
<JanC> directories are more meaningless to computers than to users
<ManDay> broder: Specifying   ip=frommedia on commandline works even better than symlinking true from NetworkManager
<dobey> i've never logged into my computer and thought "you know, today i'll make a directory"
<ManDay> Does anyone know why, after I boot with casper, I got the CD added to my sources.list ?
<dobey> JanC: not according to ls -d "~/.*"
<Cheery> dobey: yeah. but you've probably thought today you're starting something, and create a directory for all work files you need for that thing.
<Cheery> dobey: directories solve a *very hard* problem in somewhat sensible way.
<dobey> Cheery: only because there is no better way to do it currently, because IDEs pretty much all suck.
<JanC> dobey: those directories are there for the users, not for the computer (a computer doesn't care whether those files are in directories)
<dobey> directories are easy because they're what everyone has used for the past 20 years
<dobey> it doesn't make them the best solution
<dobey> JanC: users don't care aabout the stuff in there
<Cheery> dobey: this far I haven't seen better even if I have searched for one.
<dobey> JanC: except for maybe .porn or something :P
<JanC> dobey: but they care they are not visible when looking for their own files, which is why they are in hidden files/directories  ;)
<JanC> so directories were invented so that users could file away documents in logical places
<dobey> JanC: not really, no
<penguin42> dobey: File browsers for stuff  in .* blah you're probably right, but for organising there own files I think directories still make some sense
<JanC> it might not be perfect, but it was better than what was there before  ;)
<dobey> directories were invented because there were no GUIs at the time
<dobey> penguin42: not really
<Cheery> dobey: directories persisted for long after there were GUIs
<dobey> penguin42: organizing things is work. why should i have to do that work, when i have this super fast computer that can do it all for me?
<penguin42> dobey: How would you organise the files with a GUI in a way that was different underneath from directories?
<dobey> penguin42: you don't. the computer does it. users shouldn't have to do that work
<JanC> and when I say I still want a file browser, I certainly want it to be more advanced than what we have now (static categories of files)
<dobey> Cheery: yes, because humans are lazy
<JanC> BeOS had "dynamic categories" in its original file system  ;)
<penguin42> dobey: hmm but what do you do with all those files you've got - I don't search for data a lot of the time, I know where I put it - it's the same with real paper
<dobey> Cheery: and change is hard. cf. unity/gnome3
<dobey> penguin42: i don't have files. i have content, most of which happens to be encapsulated in files, because that's how computers have worked for 60 years
<JanC> (or "dynamic directories" if you want)
<Cheery> dobey: oh bend over with that. you said you'd want to index all your files and use search every time to get on your files.
<JanC> dobey: data is stored in "files" in the real world too  ;)
<penguin42> dobey: That's OK, but with your content would you want to organise that content in some way?
<dobey> penguin42: don't assume that because i said search and indexing is the answer, that users are the ones doing the searching.
<Cheery> dobey: or lets even forget the concept of 'file'.
<Cheery> dobey: now. what do you got in there?
<penguin42> dobey: But I don't think in all cases the users or even the computer has to do search - I have an organisation and I know where I put some stuff (admittedly not everything)
<dobey> Cheery: in where?
<Cheery> dobey: say if you had thing you're fantasizing about, how would it perform?
<dobey> penguin42: why do you care *where* it is on the hard disk? it is irrelevant. all you care to do is use the data.
<dobey> Cheery: pretty much the same way my phone does.
<penguin42> dobey: Agreed, but I have a lot of data - I have the note about what I was doing with my bills, I have some notes about web pages I'm going to visit
<Cheery> dobey: well you care about the location for backup purposes.
<penguin42> Cheery: That's avoidable
<Cheery> dobey: also, you care that all the data is in consistent place so you can use it.
<dobey> Cheery: not really; the backup software cares about location. all it has to do is back it up, and restore it, if need be
<dobey> i don't care where on disk it is
<penguin42> dobey: I mean I have to separate some of my information into categories about different things I'm doing; I'm not sure I'd be able to give it information that a computer would be able to arrange any better
<dobey> penguin42: you mean you want to tag your data?
<Cheery> dobey: for example sometimes this fails because person sends a document file but not images he has linked into document.
<dobey> Cheery: it doesn't fail. broken applications are still broken
<JanC> as said before: the original BeOS filesystem worked that way, ages ago...  ;)
<dobey> a document should be self-contained
<penguin42> dobey: Yes, and I'm happy with directories effectively being places where all the things with the same tag are listed; but the interesting questions are what happens as you rearrange and delete things with a tag - it's not always obvious
<Cheery> dobey: which you can do by wrapping your doc into a directory.
<penguin42> dobey: I mean 'directories' are after all a card-file analogue
<dobey> penguin42: i don't understand your question. if you delete something, it gets deleted.
<penguin42> dobey: Or does it just remove the tag from some subset of the items that were so tagged?
<dobey> Cheery: then it's not a document, it's a zip file full of crap
<penguin42> dobey: OK, if you just had tags what would you do to arrange a set of information in time order ?
<dobey> search for that tag, and sort results by date?
<Cheery> dobey: except if .zip file also contains an extra file which makes it appear as something else.
<penguin42> dobey: date of what - when you wrote it? When the stuff in the file talked about?
<ManDay> Does anyone know why, after I boot with casper, I got the CD added to my sources.list ?
<dobey> Cheery: stop making up hacky solutions to very rare problems, as some excuse as to why you need a file browser
<penguin42> dobey: IMHO what you end up with is a hierarchy of tags - which is OK, but a flat tag cloud is pretty useless
<dobey> penguin42: whatever date you wish to sort buy
<dobey> by
<penguin42> dobey: OK, so you've got a set of stuff tagged and with a date, and a friend comes along and gives you a copy of a similar thing that he's worked on - how do you differentiate the two sets ?
<dobey> penguin42: directories are hierarchies of tags, but only one tag per N items
<dobey> you don't tag it with a date; dates are inherent properties
<JanC> dobey: even with your metadata-based document store, you will need a "file browser" (or "document browser", or whatever you want to call it)
<penguin42> dobey: Well I include the filename as well as the directories I guess
<penguin42> dobey: But a directory is not one tag - it's the hierarchy of how you got there - dave/photos/2011/december
<dobey> JanC: no i won't
<penguin42> dobey: That's very different from dave/errors/2011/december
<penguin42> dobey: It's interesting gmail used tags initially instead of folders, but have now made them hierarchical and ended up with something closer to folders
<Cheery> penguin42: I don't like that sort of sorting directories.
<dobey> penguin42: and again, you don't actually care about the directories at that point. you care about the 'tags' as you call them
<penguin42> Cheery: It's sometimes useful though
<Cheery> penguin42: I generally do not care about when it's created. :)
<Cheery> penguin42: and it's stored by the file system already
<penguin42> dobey: I agree but I'm saying hierarchical linked directories and files are very similar to hierarchical tags anyway
<broder> ManDay: that's done by one of the scripts in casper-bottom - if you're digging into what casper is doing, it's worth skimming all of them
<penguin42> (and I don't agree directories are a computer thing - we've stored things in books in organised libraries for centuries)
<dobey> penguin42: this isn't a similarity contest though
<ManDay> broder: I tried, haven't found it.
<dobey> it's about improving UX, and reducing workload for the user
<ManDay> I grepped for everything sensible but nothing came up
<penguin42> dobey: I'm OK with reducing workload for the user and improving the user experience, and I think a tagged approach can help - but I think as soon as you have more than a little bit of information you need something a bit more powerful than a flat tag cloud
<broder> ManDay: ./scripts/casper-bottom/41apt_cdrom
<dobey> penguin42: this also isn't about libraries; and they've only been that way, because we're only at the point of replacing them with electronics now.
<dobey> penguin42: i don't know why you're assuming some sort of flat tag cloud
<dobey> tags are a single piece of data
<penguin42> dobey: OK, can you explain what you mean by a tag just so we understand
<JanC> I would say all forms of metadata is what you want
<dobey> a tag is a user-defined piece of metadata they add to something; like tagging some recipes as breakfast, lunch, dinner, brunch, or dessert or something
<dobey> JanC: which is why i said indexing, not tagging
<JanC> and if you like to add directory=dave/errors/2011/december as metadata, that's fine  ;)
<Cheery> hmm found a way to add .desktop, but did not find how to get the 'open with' work properly
<dobey> Cheery: what are you trying to open with, with? it works perfectly fine here
<penguin42> dobey: I just found that tags work well for small amounts of data/files - like the few you might have on a phone, but when you have thousands of tag matches life gets harder
<JanC> but even with all that meta-data, I want to be able to "browse" my files (even if it doesn't involve a hierarchical tree)
<Cheery> dobey: I have application binary in /home/software/ which I want to use when opening a certain kind of file.
<dobey> JanC: why?
<Cheery> dobey: that binary doesn't show up in 'open with' -menu, and I can't see a button which adds it.
<JanC> dobey: what's the alternative?
<JanC> how do I find files/documents/data otherwise?
<penguin42> dobey: I find myself wanting to do things like restrict matches to only things with a particular tag, but not in the confidential set or etc etc and you start having to remember which tags you have
<dobey> Cheery: the .desktop needs to have the mime type listed for the file you want to open
<dobey> Cheery: and you need to run update-desktop-database on the directory where the .desktop file is, to update the cache
<dobey> JanC: WHY do you want to browse files? your music should show up in your music player, documents in editor/viewer, videos in video player, etcâ¦
<penguin42> dobey: Why do you want to separate the types of media?
<dobey> penguin42: making your life complicated with directories or tags is still making your life complicated; but that is a choice you made
<JanC> dobey: what if I want all files related to some topic/project, but don't know what the types of files are?
<penguin42> dobey: No, I believe it's a necessity when you have a lot of data
<dobey> penguin42: i disagree
<penguin42> dobey: And that's why I like directories :-)
<dobey> JanC: what is a topic/project?
<JanC> dobey: it could be anything
<JanC> that's the point exactly
<penguin42> dobey: No, but tags are good - I just don't think they can be used to remove directories completely, only to partially arrange stuff
<dobey> JanC: then how do you know it is a topic/project if you don't know what a topic/project is?
<JanC> dobey: I could give an example, but not exactly a definition (outside of "about everything")
<JanC> say i want to find everything I have about Ubuntu
<dobey> search -> "Ubuntu"
<Cheery> now it suddenly just figured it out :o
<Cheery> oh well
<JanC> dobey: search where?
<dobey> JanC: in the search application
<Cheery> enough! I'm frustrated enough it with. >:/
<Cheery> now going to do the actual stuff I was planning.
<JanC> so what's the difference between a "file search application" and a "file browser"?  ;)
<penguin42> dobey: Hopefully that search application will have remembered all the things tagged with Ubuntu and organised them into a cache that will let it find all the things labelled with ubuntu quickly - lets call it a directory
<dobey> it's not a file search application; it's a search application
<dobey> penguin42: it's called an index
<penguin42> dobey: I think you'll find the thesaurus has those as the same thing
<Cheery> JanC: idk. but it's sort of silly thing to think different if your filesystem is directory based.
<JanC> I suppose that all depends on your definition of "file"
<dobey> directories don't work here, without having N copies of the file, for every tag you want it to have
<dobey> or N directories for all tags
<penguin42> dobey: No, we've got hard links - they do work
<dobey> which are wastes of disk space
<penguin42> (or at least links of some type)
<dobey> penguin42: and it's a complete hack solution
<dobey> and a waste of disk space
<penguin42> dobey: As opposed to the waste of CPU time in searching for stuff you've previously organised?
<JanC> and it works, which the alternatives don't (yet) ;)
<dobey> JanC: local content are what people generally mean by 'file'
<dobey> alternatives work fine
<dobey> they just only exist on phones/tablets
<dobey> penguin42: you clearly don't understand how optimizations work i guess :)
<JanC> dobey: they don't work for the simple reason that most data lacks the required metadata
<dobey> JanC: they work perfectly fine
<dobey> there is no required metadata
<dobey> i have never needed/wanted a file browser on my phone
<ManDay> broder: Can I delete the concents of /run in the squashfs?
<JanC> dobey: neither have I, but then again, I use my phone as a phone...  ;)
<broder> ManDay: yes, it will be shadowed by a tmpfs very early in the boot
<ManDay> thanks
<penguin42> dobey: Well, not on my phone, but I do access google docs from my phone - albeit only with 2 or 3 files
<penguin42> <dinner>
<ManDay> Any other directories which I may purge for the liveCD image?
<ManDay> (besides the usual tmp ones)
<broder> ManDay: probably, but i don't konw what they are off the top of my head
<ManDay> ok, i guess /run is good neough
<tehuser_u> Hello, I am trying to set up a PPA, and I do not know if I have correctly published my key to the keyserver, is there some way to determine this?
<tehuser_u> launchpad won't accept my key fingerprint, and I think I published directly to the ubuntu keyserver about 20 minutes ago.
<Ampelbein> tehuser_u: Go to http://keyserver.ubuntu.com/ and search for the user id to see if it is published correctly.
<tehuser_u> ok. Cheers.
<tehuser_u> ok, no it hadnt. thanks.
<ManDay> Thanks broder
<micahg> slangasek: I syncd libverto which is a new build-dep of krb5, but it'll need a push through NEW and an MIR before krb5 can build unless you want to temporarily switch to the in source version
#ubuntu-devel 2012-12-10
<britt__> hey guys
<StFS> Hi. I'm wondering if somebody can help me figure out whether a fix to a bug will be made available on quantal or whether it's just going to be released for raring
<StFS> this is the bug: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1038781
<ubottu> Ubuntu bug 1038781 in libav (Ubuntu) "-dev packages are missing alternate depends on -extra packages" [Low,Fix released]
<infinity> siretart: ^
<infinity> StFS: As it stands, the bug isn't targetted for an SRU, no.
<StFS> infinity: thanks... how would I have seen this myself? just for the future... and what is the process, I mean, who takes these SRU decisions?
<StFS> can I request somewhere that it is?
<infinity> If it had a quantal task, that would be a pretty good indication.
<StFS> ok
<infinity> The part where this also appears to be a problem in precise as well leads me to think it should, perhaps, be nominated.  But I'm not about to create work for others, either.
<infinity> siretart: You have any objections about backporting that fix to Q and P?
<StFS> infinity: well... thanks for your help, I hope siretart notices this at some point and takes it under consideration.
<StFS> afk
<pitti> Good morning
<TheMuso> pitti: GOod morning.
<TheMuso> Damn capslock.
<pitti> TheMuso: nah; it makes a fine escape key :)
<TheMuso> lol
<TheMuso> Well with my setup, it doubles as my KVM control key, and sometimes the KVM sticks capslock on.
<pitti> TheMuso: I have swapped Esc and Caps Lock ages ago; vim is so much nicer with that
<TheMuso> Sounds fair.
<siretart> infinity: I have no problems with that, if you feel that this does qualify as an SRU
<dholbach> good morning
<pitti> dholbach: guten Morgen
<dholbach> hey pitti
<tkamppeter> pitti, hi
<pitti> hello tkamppeter, how are you?
<mlankhorst> any sru admins on that can accept nvidia-graphics-drivers-experimental-310,  nvidia-graphics-drivers-173-updates, jockey, and xorg ?
<tkamppeter> pitti, you have assigned bug 808829 to me. What do I have to do with it now?
<ubottu> Launchpad bug 808829 in cups-pk-helper (Ubuntu) "[MIR] cups-pk-helper" [Low,In progress] https://launchpad.net/bugs/808829
<pitti> tkamppeter: jdstrand had some additional requirements for acking the MIR
<tkamppeter> pitti, you need that someone has to test it for Oneiric and Precise?
 * pitti doesn't understand
<pitti> tkamppeter: that's for raring only
<tkamppeter> pitti, you mean that it is built with PIE and BIND_NOW and that the test suite gets running on every build?
<tkamppeter> pitti, comment #21.
<pitti> right
<freedomrun> gsettings set org.gnome.nautilus.window-state start-with-status-bar true is impossible in 13.04 ??!
<pitti> seb128, ev, ogra_, slangasek: bug 1088428 *grin*
<ubottu> Launchpad bug 1088428 in d-conf (Ubuntu) "[Apport test bug armhf] dconf-service crashed with SIGSEGV in __libc_do_syscall()" [Medium,New] https://launchpad.net/bugs/1088428
<seb128> pitti, nice!
<pitti> seb128: FYI, I updated the configuration on osageorange accordingly
<seb128> k
<pitti> seb128: crashdb.conf now has ubuntu-{i386,amd64,armhf} databases, and the cronjobs use --crash-db to select which arch they run for
<ogra_> pitti, neat !
<seb128> great
<pitti> seb128: and added config/Ubuntu*/armhf/sources.list for getting the packages from ports.u.c. for armhf
<pitti> seb128: FYI, LP retracer config is now in lp:~ubuntu-archive/apport/lp-retracer-config (also rolled out to porter box)
<pitti> tseliot: do you think you'll have time for bug 1054458 today? it has been breaking _all_ nvidia installations since quantal for everyone
<ubottu> Launchpad bug 1054458 in ubuntu-drivers-common (Ubuntu Quantal) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: 'experimental-304'" [High,Triaged] https://launchpad.net/bugs/1054458
<tseliot> pitti: isn't it fixed in raring? https://code.launchpad.net/~ted/ubuntu/raring/ubuntu-drivers-common/nvidia-experimental-number/+merge/137754
<tseliot> pitti: in 1:0.2.71.1 ?
<rbasak> Does anyone know if ogra_ is around today?
<pitti> tseliot: ah, the MP is still open and the bug for raring as well
<pitti> tseliot: so I guess we mostly need the fix for nvidia-common for quantal
<pitti> tseliot: also, current git still doesn't have that particular fix; it might not be strictly necessary due to ignoring 'experimental', though
<tseliot> pitti: let me check...
<tseliot> pitti: commit ee6fb0234e1fbc21d8e8092022d631b5e7a8fb2b in u-d-c should do it
<tseliot> pitti: without the patch in the merge request
<pitti> tseliot: ah, thanks
<tseliot> pitti: let me check nvidia-common in precise
<tseliot> pitti: my upload in precise-proposed was rejected. Let me reupload...
<pitti> seb128: I guess it is time to re-enable LP crashes for raring, if we still want to do it; WDYT?
<tseliot> pitti: so my fix is in precise-updates too. It shouldn't really be an issue any more
<pitti> tseliot: great, thanks for checking!
<tseliot> np
<tsdgeos> everytime i update my raring VM compiz crashes
<tsdgeos> are you guys aware of that?
<pitti> tseliot: so I wonder why this is still the top crasher in https://errors.ubuntu.com/
<pitti> tseliot: (which link to bug 825350)
<ubottu> Launchpad bug 825350 in nvidia-common (Ubuntu Oneiric) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: '173-updates'" [Medium,Confirmed] https://launchpad.net/bugs/825350
<pitti> tseliot: oh, that's -experimental vs. -updates
<pitti> tsdgeos: i. e. we got ~ 740 reports for this yesterday alone
<tsdgeos> i see
<pitti> tsdgeos: sorry, tab error; that was meant for tseliot
<tsdgeos> pitti: oh, i unsee then :D
<seb128> pitti, @raring: not sure how much use we will have of those reports during end of year break time
<seb128> pitti, early next year my avoiding collecting launchpad noise while we are not there
<pitti> seb128: WFM
<smoser> slangasek, the reason bug 978127 would not be fixed by running is that that would require an ntp service on the network (and some configuration of the ephemeral image to use it) or access to ntp.ubuntu.com.  we want/need maas to run "completely offline".
<ubottu> Launchpad bug 978127 in cloud-init (Ubuntu Precise) "incorrect time on node causes failed oauth" [High,Triaged] https://launchpad.net/bugs/978127
<ScottK> jamespage: We're one FTBFS away from getting opencv and friends out of raring-proposed.  I gave you a ping about sivp/armhf late on Friday, but just in case you missed it ...  It looks like another Java'ish thing and it'd be nice if you could have a look at it.
<xnox> smoser: if you are running "completely offline" you'd still want all nodes to agree on common time. So in your "mini-offline" world you'd still want to have a local ntp. (sure it will be incorrect, but at least time should be the same for all parties involved).
<tseliot> pitti: right but errors.ubuntu.com mention jockey and there's no way to know if they are using the latest nvidia-common
<xnox> smoser: the proposed change seems to use oauth authentication reject messages as a "faked" ntp server.
<xnox> smoser: can the maas server start and advertise ntp on the network?
<smoser> xnox, you are correct in your assesment.
<xnox> smoser: but I take it you still want SRU instead of starting ntp server?! =)
<smoser> in order to insert ntp, we'd have to do one of 2 things: have the local maas mount and modify the ephemeral amage (it does not do that at this point). pass the ntp image into the image someway, kernel cmdline could be used.
<smoser> xnox, yes.
<smoser> the code in question will not be negatively affected if the system has a reasonable clock.
<xnox> smoser: /me thought that dhcp advertises ntp and all well-behaved ubuntu's should pick that up on boot with no special changes.
<smoser> how is it advertised? avahi? i'm not sure.
<xnox> smoser: good point. /me goes to check my facts.
<smoser> personally, when i went looking at that path, it seemed to me that ntp on ifup seems problematic.
<smoser> as there are things possibly running at that point that get pissed off by jump forward or back of system clock.
<smoser> one such thing is other dhcp/ifup events.
<smoser> especially in the jump backwards case, it seems that this scenario is a problem:
<smoser>  * system up with eth0 and eth1 devices
<smoser>  * eth1 and eth2 come up and start dhcp
<smoser>   sed s,eth1,eth0, s,eth2,eth1,
<smoser>  * eth0 comes up, calls ntp, sets clock backwards 3 hours
<smoser>  * eth1's dhcp never gets a dhcp response, but sits waiting 3 hours + its expected wait of 120 seconds.
<pitti> tseliot: oh, there is, the individual reports have dependency versions
<smoser>  * this blocks 'static-networking-up'
<smoser> well, the cae of static-netw0rking-up is probalby incorrect, as you shouldn't have had eth1 configured for dhcp if it asn't going to get an address. but it seems like a broken path to me.
<smoser> and other things are actually running when ntpdate is run.
<smoser> xnox, have i evaluated that incorrectly (its entirely possible)
<tseliot> pitti: is it just me who can't see nvidia-common here? https://errors.ubuntu.com/oops/00023a60-24c9-11e2-b817-e4115b0f8a4a
<xnox> smoser: =/ yeah. Internets tell me that in your dhcp server it should be possible to specify the ip of the ntp-server that clients subsequently should use.
<xnox> smoser: not sure which dhcp server you are using though.
<smoser> xnox, we could add a kernel cmdline parameter for this. and have ntp* just respect it.
<pitti> tseliot: hm, it seems nvidia-common isn't a dependency of jockey-common
<xnox> smoser: so my proposed "advertising" method is via dhcp, which worked good enough for my network setup (synchronising dmz modems with internal network)
<smoser> but again, the work around we have actually works, requires no additional services, and still plays well with others.
<xnox> smoser: well, with dhcp advertising you shouldn't need a kernel cmdline option & it should already be supported out of the box.
<smoser> i'm confused.
<xnox> smoser: sure. i think SRU is a good quick fix for this. But there will be other services wanting synchronised clock across nodes.
<xnox> smoser: ok, maybe I am confused how MAAS works.
<smoser> xnox, this is only a problem in "ephemeral" environment. its used for "boot and enlist" or "commission" of a node.
<smoser> its iscsi read-only root.
<xnox> smoser: you have an offline node boot -> get dhcp ip address -> talk to maas server <-> enlist with each other.
<smoser> when the system is actually installed, the installer sets the correct clock to hardware and can install ntp properly then.
<xnox> ah.
<smoser> enlist with maas server.
<xnox> use any hacks you want at that time then =)))))
<smoser> xnox, and i'm pretty sure there is no auto-discovery of ntpdate setting on ifup
<xnox> since it literary does not matter =)
<smoser> i'm looking at /etc/network/if-up.d/ntpdate
<xnox> smoser: ok. I'll go and test ntpdate update. Cause i was certain it used to work....
<smoser> xnox, it may work for ntpd, but i'm talking about ntpdate
<smoser> and generally, i do think that lots of things are going to fall apart on an ifup that sets the clock backwards.
<smoser> (separate issue entirely)
<xnox> ack.
<smoser> xnox, but thank you for looking at my SRU
<smoser> and spending enough time to understand the problem on it.
<xnox> smoser: it seems like something is suppose to autogenerate /var/lib/ntp/ntp.conf.dhcp (which should probably live in /run) to pick up & try ntp servers from local network..... lp suggests there are bugs about this.
<smoser> right.
<smoser> that was my suspicion also.
<xnox> *sad times* =/
<smoser> but it seems racy
<smoser> ie, how long do you wait?
<smoser> for the finding of the advertised thing.
<xnox> well, ofcourse it's racy since we are changing the time reference :P
<smoser> waiting longer time blocks this ntpdate till later in the boot when it is more detrimental
<smoser> waiting shorter means you may miss it.
<smoser> in addition to possibly setting the clock backwards :)
<xnox> =/ while 1; do ntupdate && try-enlist-maas && break; done; loz
<xnox> lolz =)
<tseliot> pitti: would it be ok if I wrote a small test for nvidia-common where I only faked an nvidia card which requires nvidia-experimental-304 and look for that ValueError exception? I can't think of any other way to prove that my code works other than running it myself
<pitti> tseliot: oh, sure; /usr/share/ubuntu-drivers-common/fake-devices-wrapper already does something like that, feel free to add/modify that one
<tseliot> pitti but isn't the problem in precise?
<pitti> tseliot: that script ought to work in precise
<pitti> tseliot: I've also seen plenty of reports from oneiric and quantal
<pitti> I guess it was triggered by the new driver packages, we just didn't expect the new schema back then
<tseliot> pitti: I can add a test in both nvidia-common and ubuntu-drivers-common if you want. I only have to do something like this: http://paste.ubuntu.com/1423312/
<pitti> tseliot: I guess a faked /sys is more elegant, as otherwise you'd overwrite the very class you are testing
<pitti> tseliot: but anyway, if it was fixed very recently, it's probably okay; but I wondered why they were still so frequent
<mhall119> didrocks: I'll ask in here, for the Ubuntu Accomplishments daemon, it's currently using a cron script and PID file to keep itself alive.  Rafal was trying to get it to start on demand as a dbus service, but is having problems getting that working.  Would it be an issue submitting it to Universe using the cron method?
<didrocks> mhall119: it's a system-wide service?
<mhall119> no, user-session
<didrocks> should be just a dbus job with a .service file rather then :/
<mhall119> I know, but he's not been able to get it working that way yet
<didrocks> needing some help to look at what's wrong?
<tseliot> pitti: honestly I have no idea. I'll explore the fakesysfs way as it could be useful to add more tests in the future for both packages
<mhall119> didrocks: if you could, that would be fantastic
<didrocks> (I don't commit right now, but I would prefer we do it right ;))
<didrocks> yep
<didrocks> ping me EOW about it
<didrocks> I'll give it a look
<mhall119> didrocks: thanks, I suspect it's just an issue of not being familiar with dbus
<pitti> tseliot: so e. g. in quantal/raring you can run /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk, or f-d-w ubuntu-drivers debug, etc.
<didrocks> mhall119: probably :)
<mhall119> it's very easy to not be familiar with dbus :)
<didrocks> heh
<tseliot> pitti: right but that's not something I can include in u-d-c's tests directory, is it?
<pitti> tseliot: it's shipped by u-d-c
<pitti> tseliot: tests/ubuntu_drivers.py also uses fakesys.py (the same module)
<pitti> tseliot: same for the autopkgtest in debian/tests/system
<tseliot> pitti: right, I'll use fakesys.py in u-d-c and include fakesys.py in n-c
<pitti> ScottK: hey, how are you?
<ScottK> Hey pitti.  Not bad.
<pitti> ScottK: would you want to review the new round of psql microreleases? (just standard MRE)
<ScottK> Possibly later today.
<pitti> ScottK: thanks
<pitti> (it seems we need to ping around for SRUs these days)
<ScottK> Yeah.
<jamespage> ScottK, promise to look at that problem in the next 30 mins
<ScottK> jamespage: Great.  Thanks.
<bdmurray> ev: your whoopsie-daisy ppa does not have pycassa for quantal
<ev> bdmurray: I'm moving everything over to daisy-pluckers' PPA
<ev> which has the latest and greatest pycassa
<bdmurray> okay, great
<ev> let me know if you have issues with it - I want to get that deployed on production very soon
<pitti> hey ev, how are you
<ev> hi pitti!
<ev> I'm good, how's you?
<pitti> I'm great, thanks
<pitti> ev: quite happy that apport likes arm now :)
<ev> yay
<pitti> ev: I'll soon work on getting that into daisy, too
<ev> pitti: excellent! Thank you
<pitti> ev: but that needs a newer apport version; I believe you have packages for that instead of running from trunk, right?
<ev> yes
<pitti> ev: OOI, do the packages carry anything that isn't in trunk which we'd need?
<ev> there's one in my whoopsie-daisy ppa, but I'm trying to move all that stuff over to daisy-pluckers/daisy-seeds
<ev> I'll have a quick look
<ev> one moment
<pitti> (like the generic hooks from the ubuntu branch, but they sholdn't be necessary for retracing)
<pitti> ev: i. e. could we potentially move this from using the packages to checking out the latest tagged release from bzr?
<ev> pitti: probably, yes. The code change would need to be made in the daisy-retracer charm and in lp:canonical-memento modules/whoopsiedaisy
<ev> pitti: no, the version in my ppa doesn't carry anything special
<pitti> ev: ok; I haven't looked at the memento bits yet, but I'll test all this in Juju first
<ev> okay
<ev> thanks
<jamespage> ScottK, it looks like it ran out of heap space - have you already tried rebuilding?
<ScottK> jamespage: Yes.
<ScottK> It built before though.
<jamespage> ScottK, OK _ I'm just creating a raring schroot to test this in
<ScottK> Thanks.
<ev> the U1 guys pointed me at how to mock out SSO auth, so I'm trying to get that landed while I fix 1087361
<bdmurray> ev: on the tube you mentioned watching database load when querying it...
<ev> oh yes
<ev> nodetool tpstats
<ev> bdmurray: hit ctrl-R on jumbee and type nodetool
<ev> also watch top
<ev> bdmurray, pitti: fwiw, I'm working on formalising our discussions in https://wiki.ubuntu.com/ErrorTracker/ServerSideHooks and https://wiki.ubuntu.com/ErrorTracker/PhasedUpdates
<bdrung> dholbach: is there a timeframe for the hackfest?
<ev> bdmurray, pitti: I think cleaning up the stack traces is going to be as simple as: http://paste.ubuntu.com/1423516/ . Results in: http://paste.ubuntu.com/1423521/
<slangasek> pitti: 1088428> very nice :)
<slangasek> smoser: "completely offline"> yeah, I suspected that might have been the case.  I'm not altogether comfortable with piggy-backing on oauth for clock syncing, but that's no reason for me to block it
<smoser> slangasek, well, in this case, the clock that *matters* is the oauth clock
<slangasek> yes, I understand
<smoser> ie, if there were ntp and the client was good but the server was off, then this fixes that case too :)
<smoser> but yes, "have good clocks" makes more sense.
<jamespage> ScottK, not getting very far I'm afraid - the error is coming from somewhere in the depths of scilab
<ScottK> Ohh.  Fun.
<jtaylor> I think fftw3 needs to be kicked into raring
<jtaylor> excuses look fine but it doesn't migrate :(
<cjwatson> excuses is just the first stage
<cjwatson>     * i386: libaudiomask-dev, libaudiomask1, mffm-fftw-dev, mffm-fftw1
<cjwatson> ^- new uninstallables when attempting to promote fftw3
<cjwatson> that's from update_output
<jtaylor> arg
<jtaylor> why does apt-cache rdepends not work on provides ._.
<cjwatson> Looks like libfftw3-3 dropped its Provides: fftw3
<jtaylor> ayes I though nobody needs it
<cjwatson> grep-dctrl and friends are more reliable
<jtaylor> good that we have this proposed now
<jtaylor> very useful
<achiang> infinity: hi, you about? just wanted to followup re: valgrind
<infinity> achiang: I haven't poked valgrind yet.
<achiang> infinity: is it something i might take a shot at, both to learn and also to offload you?
<achiang> or is it best left to wizards as yourself? :)
<infinity> achiang: If all you want is your patches in, that could be trivially done.  It was the new upstream merge I was going to poke at, which could be a bit more effort, but if you want to, I won't stop you. :P
<infinity> achiang: I just didn't find "spare hacking time" on the weekend to care much.
<achiang> infinity: re: upstream merge, that would be grabbing valgrind out of unstable, seeing what ubuntu patches need either merging or dropping, then ... a debdiff?
<infinity> achiang: s/unstable/experimental/ but, yes.  Minus the debdiff part.  It'll be huge and unwieldly.  A full source package is saner.
<achiang> where can i upload that for review as a member of the ubuntu peon group? (aka not motu or coredev or anyone with upload rights to anywhere, really...)
<infinity> achiang: Officially, there's revu.
<infinity> achiang: Unofficially, you could just put it $somewhere, and point someone (like me) at it for review.
<achiang> infinity: ok, wfm. not sure if i can find spare hours today but i'll try
<freedomrun> hello. where is status bar on the bottom of nautilus in 13.04??!
<xnox> freedomrun: this is development channel. Support is at -> #ubuntu
<Laney> J
<xnox> ?
<Laney> typo
<xnox> ack
<Laney> 13.04 -> #ubuntu+1
<xnox> meh, nautilus did not change between the two =)
<freedomrun> xnox, yeah I know that was exactly why I asked here
<Laney> suuuure, not at all
<freedomrun> if someone know devs shurely does
<freedomrun> Laney, xnox thnx
<slangasek> smoser: I'm uncomfortable with the fix for bug #974509.  You're picking a random, 32-character alphanum string; looking it up *with* the DNS search path; and if it's resolvable, adding that address to the blacklist.  While the odds of this ever actually biting you due to a collision with a real hostname that resolves to a real IP that you care about, AFAICS this is a wrong change
<ubottu> Launchpad bug 974509 in cloud-init (Ubuntu Precise) "cloud-init selects wrong mirror with dns server redirection" [Medium,Triaged] https://launchpad.net/bugs/974509
<smoser> slangasek, looking
<slangasek> ok
<slangasek> er, also insert an "are quite small" in there somewhere
<slangasek> smoser: anyway, the risk here is so very small that I won't insist on the SRU being reuploaded; but I think this should be fixed right in the long term (and on trunk)
<smoser> slangasek, well, in addition to that 32 char random string being resolvable
<smoser> it also has to resolve to the same thing that the lookup was doing
<slangasek> smoser: yes.  so the chance of a collision with a real name that happens to point to the same IP is small, but real
<smoser> the users of 'is_resolvable' is really limited in this case (mostly to looking for mirrors)
<slangasek> smoser: is there a plausible scenario where $random resolves to a dns redirector, but neither does-not-exist.example.com. nor example.invalid. does?
<smoser> i played with a few different (publically available)  dns servers.
<smoser> many dns servers that do this are not available unless you're on their network.
<smoser> but i think that i decided for the 32 char randomness to work around one that i actually found.
<smoser> slangasek, so i dont have a really good answer to "why specifically search for random".
<slangasek> smoser: ok.  so I predict that at some point in the future, someone somewhere is going to have an inexplicable provisioning failure because of this. :)
<slangasek> smoser: cloud scaling + murphy's law
<slangasek> smoser: but if you don't know why it was added, I guess it's hard to argue that it can be safely removed
<smoser> slangasek, http://paste.ubuntu.com/1423782/
<smoser> hm.. so i guess that isn't complet info.
<slangasek> that looks like a server that would not require the $random
<smoser> right.
<smoser> so that earthlink dns server redirects those 2.
<smoser> opendns (at least when i wrote this) did not redirect example.invalid
<slangasek> sure, but as long as it redirects *either* of them, that gives you the info you need
<slangasek> smoser: anyway, this isn't a critical issue... I could file a bug report about it if you want, and leave it at that?
<smoser> right. so i dont have a definitive example, but i assume that i guessed that if some hosts give 404 for .invalid, then other scould give for both .invalid and .example.com.
<smoser> but clearly none of this is definitive as anyone can change their implementation server side at any point.
<smoser> please file a bug if you're ok with that, and i'll at least try to justify better why it is as it is.
<slangasek> smoser: will do, thanks
<slangasek> smoser: bug #1088611
<ubottu> Launchpad bug 1088611 in cloud-init (Ubuntu) "using random hostnames to detect dns proxies allows for false positives" [Undecided,New] https://launchpad.net/bugs/1088611
<ricotz> infinity, hi, are you "responsible" for the armhf ppa chroots? there is a problem while setting up libgtk2.0-0:armhf/libgtk-3-0:armhf as you can see here https://launchpad.net/~ajf/+archive/trg/+build/4053496
<gladk> Hi all, will the packages be automatically synced from Debian for Raring, or not?
<infinity> ricotz: That has nothing to do with the chroot.
<infinity> ricotz: Anyhow, bouncing the build to see if it happens again.  If it does, what you have there is a qemu bug, and not much I can do about it.
<infinity> ricotz: Nope, looks like the same issue.
<infinity> slangasek: qemu sucks, it's all your fault somehow: https://launchpad.net/~ajf/+archive/trg/+build/4053496
<tumbleweed> gladk: they are, unless Ubuntu has modified them. Why do you ask?
<mterry> zul, hello!  I see your steveador mir.  You just uploaded a version that uses tests but doesn't fail on them?
<zul> mterry: yeah still working on them
<mterry> zul, OK.  I'll leave that MIR alone for now
<mterry> thanks
<ricotz> infinity, ok, it works locally here with the raring qemu version
<ricotz> infinity, so maybe there is a way to update it since as the error messages says qemu is a bit older there
<ricotz> meaning the actual server which those builders run on
<slangasek> infinity: are we sure that the setting to make qemu be happy with address spacing didn't come unstuck?
<infinity> slangasek: I have no idea.  I've had zero involvement with the qemu PPAs, except for reviewing Spads' patches to lp-buildd long ago.
<slangasek> ok, let's blame Spads then :)
<infinity> slangasek: I'd concur that perhaps backporting raring's qemu to precise-cat might be an awful plan, though.  I've seen a lot fewer random and weird crashes with it.
<infinity> elmo: Any opinions on a qemu backport to precise-cat for the "virtual" ARM buildds?
<slangasek> ricotz, infinity: fwiw I can confirm that this isn't reproducible with the raring qemu, but is with the precise version
<slangasek> (slightly different output, I get a segfault rather than the shown error message; but same issue)
<infinity> I figured as much.
<infinity> I think I'll go kill that build to free up the buildd now.
<elmo> infinity: precise; funny guy
<infinity> elmo: Well, the version it's reporting appears to be the precise one.
<infinity> elmo: Is that already a backport of precise's qemu to hardy? :P
<elmo> yes
<infinity> Check.
<infinity> Then more backporting seems simple enough. :)
<ricotz> infinity, this "lock up" is/will get pretty common now with more ppas using armhf
<ricotz> if it is easy to backport that would be great
<infinity> ricotz: Yeah, I know.
<elmo> infinity: hmm
<elmo> lamont: ^-- sanity check?
<infinity> Those three words are slightly odd together on that line.
<lamont> looking
<slangasek> infinity: only the punctuation is odd
<infinity> slangasek: Zing.
<slangasek> a "lamont sanity check" sounds like something that probably has its own medical billing code
<lamont> our current version is 1.0.50-2012.03-0ubuntu1~ppa10.04.1~0.IS.8.04.0
<elmo> (because I don't see a modern qemu in hardy-cat, but the xen guests are definitely hardy (not sure why, they could be anything)
<lamont> if that sheds any light
<infinity> elmo: Would be qemu-linaro.
<xnox> slangasek: smoser: the way we do this with ubiquity is wget http://start.ubuntu.com/connectivity-check.html and check that checksum matches.
<elmo> infinity: aha, that's why
<lamont> elmo: hardy-cat-buildd
<gladk> tumbleweed: geant321 was uploaded to Debian, which fixes also bug in Ubuntu
<xnox> slangasek: smoser: this way we detect dhcp redirection, but still can resolve & find out if we can reach internetz.
<infinity> lamont: Right, so, backporting the quantal version would be ideal.  (The raring version is identical, but won't build).
<infinity> lamont: Well, identical, but won't build, and enables some useless x86 feature you don't care about.
<xnox> slangasek: smoser: similar approach is done by Windows with it's "limited connectivity check", they go one step further and allow to specify alternative servers/IPs to check against.
<tumbleweed> gladk: looks like it already synced
<infinity> elmo: Speaking of "the guests could be anything"... How many cookies do I need to mail to whom to make the Xen guests be precisey?
<lamont> slangasek: I'm still trying to parse that to decide whether to thank, or lob. :-p
<infinity> elmo: (Not really related to this qemu thing, where we'd still want the backport, but I'm still on the "I'd like a 3.2 kernel baseline on all buildds" warpath)
<ricotz> infinity, even an update to lucid would be a nice step ;)
<infinity> ricotz: Would be a pointless endeavor.
<ricotz> there are quite some issues with those old hardy kernels building glib
<slangasek> lamont: ;)
<ricotz> infinity, ok, just thinking if this greate bump would be too risky
<infinity> ricotz: All the distro buildds are precise, no risk in making the PPAs match.
<infinity> (Well, all but adare...)
<ricotz> infinity, ah, if that is so then this should really be done
<lamont> infinity: care to propose the backport via a ppa-by-reference?
<elmo> infinity: I don't think it's a big deal, most of them are airlocked, and those that aren't, it's only a ppa-create change - feel free to RT it
<elmo> infinity: speaking of which
<infinity> lamont: As in, you want me to do the backport and give it to you?  Can do.
<infinity> elmo: If the ppa-xen stuff is in a repo I can get at, I'll even write the code. :P
<ricotz> infinity, btw, is the filesystem-size of the ppa builders adjustable?
<infinity> ricotz: No.
<infinity> ricotz: That'll be solved when the PPAs eventuall move to something more cloudy, but for now, you're stuck with what you get.
<ricotz> so it is not possible to increase them in that process :\
<infinity> ricotz: It's a physical limitation on a lot of the hosts.
<ricotz> i see
<elmo> infinity: if it's not on LP, I'm happy that we fix that for you
<infinity> elmo: I would have imagined it was cleverly hidden on adelie or some such, but happy to be proven wrong.  I haven't looked at that code since I worked for you.
<elmo> infinity: most of our new stuff is on LP, albeit under canonical-$(grep -v "'" /usr/share/dict/words  | shuf -n1) type names
<hrw> is upload to ppa broken at the moment?
<infinity> hrw: Shouldn't be.
<hrw>   Uploading chromium-mali-opengles_0.0+20121110-0ubuntu3.dsc: 550 Requested action not taken: internal server error
<hrw> next try: Directory to upload to does not exist.
<hrw> and all next attempts just got stuck at "Uploading to ppa (via ftp to ppa.launchpad.net):"
<infinity> hrw: Oh, fun.
<infinity> elmo: RT filed, feel free to bounce it back to me with a "here's the source, hippie, fix it yourself and let us know".
<infinity> elmo: #57971
<infinity> hrw: thedac is looking into your upload woes.
<hrw> infinity: thanks a lot
<hrw> Successfully uploaded packages.
<hrw> ;)
<infinity> hrw: \o/
<hrw> and armhf build started
<ricotz> infinity, i hope i didnt distract you from the glibc issue i mentioned ;)
<infinity> ricotz: What's the urgency on the glibc issue?  I'm going to rev to 2.17 over the holidays (which includes the fix), do you desperately need a fixed 2.16 before that?>
<infinity> ricotz: If so, I'll whip something up this afternoovening.
<ricotz> infinity, actually i really need
<infinity> ricotz: Alright.  I already had a local branch for a new 2.16 upload, just need to put it through some testing.
<ricotz> infinity, so if you get to it this would be great
<ricotz> infinity, thanks!
<hrw> infinity: it here any announced eta for 2.17?
<infinity> hrw: Should land before New Year, if nothing goes horribly wrong.
<hrw> cool
<infinity> hrw: davidm froze it on Nov 28 (a week earlier than I expected), so release in December seems pretty likely.
<infinity> hrw: And by davidm, I mean davem.  Silly tab completion.
<hrw> cool
<hrw> hm. build in ppa failed. but 'debuild -B -aarmhf' locally works. have to reinstall chromebook and check there
<gladk1> tumbleweed: yes, really synced.
<pitti> ev: very nice! as a special case, could we write if a pointer is NULL or not? that should already help in a lot of cases
<slangasek> xnox: so the problem with using the start.ubuntu.com connectivity check is that in this context we want the "local mirror" handling to work even when there isn't a connection to the public Internet
<xnox> slangasek: I see. In that case, I don't understand what the dns check is for. If there mirror is in place and good (e.g. Release.gpg verifies) use it, if not -> don't use it.
 * xnox goes to re-read bug & code
<slangasek> xnox: yeah, good question :)
<xnox> slangasek: as far as I can see cloud-init is after a usable mirror, and not the game of spot the broken dhcp server.
<xnox> slangasek: of course verifying release.gpg is apt-hash-mismatch racy.
<slangasek> smoser: 1066115> what are the chances that someone has a "generic" cloud config that they're passing around, and they're expecting it to be a no-op for landscape when used with an image that doesn't include landscape-client/
<slangasek> xnox: InRelease
<xnox> slangasek: ack ;-)
<smoser> slangasek, i woudl say it is pro bably very slim. i suspect not many people are actually using the landscape config stuff.
<smoser> especially since it was competely broken in 12.04 until the previous SRU
<smoser> (ie, broken in lts unknown for months.)
<cjwatson> slangasek: which reminds me, we could probably actually do InRelease now, for quantal and newer
<cjwatson> it was blocked on the new key
<smoser> whoowhoo for InRelease!
<cjwatson> and it might not even be all that complicated since it should all be in ubuntu-archive-publishing now, not LP ... though I'll need to verify that
<slangasek> smoser: do you agree however that this is a possible regression for users when applying this SRU?
<rbasak> cjwatson: \o/
<rbasak> cjwatson: I'm hoping to finish the by-hash stuff this cycle too
<smoser> you're saying in the case where they had were using a cloud-config that had landscape content in it, and they expected it not to install the landscape package.
<smoser> is that right?
<rbasak> Not sure how much of it we will be able to get live though, but at least it'll be possible to run a race-free mirror without resigning with InRelease in place
<smoser> slangasek, ^
<slangasek> smoser: yeah
<slangasek> smoser: such that the user assumes the landscape config will be a no-op on images that don't include landscape, and might be surprised if it suddenly causes landscape to be installed
<smoser> slangasek, i will agree that it would change behavior in that case.
<ajmitch> stgraber: bother, I missed the TB meeting due to work stuff, did the TB comment on the new ARB voting at some point? I saw it mentioned in a previous meeting that it'd be discussed on the list
<stgraber> ajmitch: nope, it wasn't brought up, can you maybe send a reminder to our mailing-list?
<ajmitch> sure
<ajmitch> followed up in the thread about it from last month
<stgraber> thanks
<arges> stgraber, hi. I believe bug 991360 is causing regressions in quantal. What's the best way to file a bug to get this fixed? Should i create a new bug or re-open the old one?
<ubottu> Launchpad bug 991360 in isc-dhcp (Ubuntu) "isc-dhcp-client does not send hostnames in DHCPv6 by default" [Low,Fix released] https://launchpad.net/bugs/991360
<stgraber> arges: new one
<arges> stgraber, ok
<micahg> tkamppeter: are you test building before you upload?  (a few of your upload with problems today could've been caught with a test build in a clean env)
<tkamppeter> micahg, I did test build cups-pk-helper but without pbuilder, and it needed two new build deps.
<tkamppeter> micahg, now there is a version which has built.
<micahg> tkamppeter: right, so pbuilder helps for that stuff, should be the same for the missing python with xbmc
<tkamppeter> micahg, strange is that the previous version of xbmc built and that xbmc built on the Nexus 7 running Raring.
<micahg> tkamppeter: sure, the question is will it build in a clean env
<tkamppeter> micahg, the change is small and has nothing to do with Python, it cannot have introduced a dependency on Python.
<micahg> tkamppeter: raring changed to require a certain python build dependency that wasn't needed before for some packages (idr specifics)
<slangasek> tkamppeter: the difference may be that python is no longer part of the minimal package set in raring
<slangasek> (instead, python3 is)
<slangasek> so it's possible you've hit a pre-existing build failure
<achiang> infinity: ouch. last time we appear to have sync'ed valgrind from debian was july 2011 :-/
<infinity> achiang: Meh.  It doesn't look like a monumental task.
<infinity> achiang: Just needs a round tuit.
<achiang> infinity: yeah, i'm still looking for one of those :)
<cjwatson> slangasek: Even python3 is not Build-Essential nowadays
<infinity> tkamppeter: I removed python from the chroots where it was (mistakenly) installed, despite not being build-essential.
<slangasek> cjwatson: ah - good :)
<cjwatson> Hmm, although python3-minimal is Priority: required for some reason still
<cjwatson> Anyway, dishwasher more urgent than priority-fettling
<infinity> cjwatson: Required != Build-Essential, though, unless it gets transitively yanked into the set.
<cjwatson> Depends whom you ask.  debootstrap includes required in all its sets.
 * slangasek nods
<infinity> Yes, but debootstrap's demonstrably not policy compliant. :/
<cjwatson> (and has forever)
<infinity> I'd really like to fix that.
<cjwatson> Sure, but we could make it closer by dropping python3-minimal from required, since it isn't.
<infinity> But it'll take some debian-devel bikeshedding probably.
<infinity> Though, Debian's variant=buildd is lighter than ours anyway.
<cjwatson> (It won't change any real Ubuntu installation, since python3 is in minimal)
<infinity> So theirs is slightly closer to compliant.
<slangasek> infinity: "not policy compliant" - as in, you're asserting that packages should still be required to declare build-dependencies on packages of priority: required that are not pulled in by build-essential?
<slangasek> I think it'd be better to fix policy, in that case
<infinity> slangasek: Policy says anything that isn't either Essential or Build-Essential isn't build-essential.
<slangasek> rather than making maintainers chase bugs that are in no way reproducible outside of an artificially-constructed build environment
<infinity> slangasek: To be fair, most packages follow this quite well.
<infinity> slangasek: And if debootstrap --variant=buildd were policy compliant, then it wouldn't be any more artificially constructed than the environment we ask them to test in today.
<slangasek> I'm just saying that if there are things of Prio: required that we think *should* be at that priority, and build-essential doesn't pull them in, we should fix it so that build-essential *does* pull them in
<infinity> (Most of required ends up being pulled in transitively by Essential or Build-Essential anyway)
<slangasek> instead of fixating on making hyper-minimal chroots that make it harder for maintainers to get it right
<slangasek> (but python, which will almost certainly never be Prio: required in Debian, would be good to have out of that set)
<infinity> slangasek: The canonical example of this is locales.  It exists in some Debian chroots, but not all, and it's definitely a bug to not build-depend on it.  I pulled it out of our chroots to catch those bugs.
<slangasek> sure
<infinity> slangasek: And it's not so much a fixation for me.  I dunno.  The BE set isn't ridiculous, by any stretch.  It's unfortunate that debootstrap's gotten it wrong for so long, but I don't see why that shouldn't just be fixed.
<ScottK> FWIW, python*-minimal is not Required in Debian, so no d-devel fettling required to get rid of that.
<infinity> slangasek: (And, as I said, ours is more bloated than Debian's, so cutting ours back would be a good first step)
<infinity> ScottK: Yes, we've well established that. :)
<slangasek> How about getting rid of the python*-minimal packages altogether?  That'd be nice
<ScottK> OK.
 * ScottK is in favor.
<infinity> I'm all for it.  Upstream hates them anyway.
<ScottK> Send doko on vacation for a week ...
<ScottK> I don't see the point of them anymore.
<slangasek> I've gotten the impression that doko is attached to them, but I don't understand why... their raison d'Ãªtre never came to pass
<ScottK> He is.  I don't understand it either.
<infinity> Honestly, "We never did anything with them" and "upstream can't stand the split and refuses to even acknowlegde it's 'python' until you install the full package" seem like good enough reasons.
<slangasek> right, my recollection of the compromise included "we promise to never install python-minimal without python, this split is just there so we have something that meets the early-configuration requirements for Essential"
<ScottK> Which is now OBE.
<ScottK> (AIUI)
<slangasek> which means no one can depend on python-minimal without us being in violation of that promise; and it's not essential; so it's a meaningless split
<infinity> Well, it's one seed change to punt it out of required.  All in favor? :P
<achiang> is python-minimal something that can actually run interesting python programs?
<jtaylor> define interesting
<achiang> dunno, how about ubiquity?
<jtaylor> probably not, but you have most of the stdlib
<jtaylor> at least the important parts
<achiang> i mean... if you could get away with just python-minimal for the installation process, then i could see it making sense (just talking what's possible, ignoring the promise for now)
<infinity> ubiquity wouldn't come close to running with just -minimal.
<achiang> my team regularly moans about trying to trim 3MB here and there, but we've never tested -minimal to see if we could actually use it for anything
<lifeless> achiang: -minimal isn't useful for anyting :)
<achiang> yeah, the seed comments always talk about how you can't use it by itself, so that's one we've never really understood. :)
<lifeless> there was an idea
<lifeless> back in 2005
<lifeless> to use python in early boot
<lifeless> -minimal was that, just enough python to be able to write python syntax code and have it execute
<slangasek> lifeless: my understanding was that it was for Essential, not for early boot
<slangasek> lifeless: if it was for early boot, then that was *completely* the wrong way to do it ;P
<lifeless> slangasek: it was a long time ago, with anthony baxter in the room in the first UDS in spain.
<lifeless> I don't think anyone has ever taken advantage of it.
#ubuntu-devel 2012-12-11
<mlankhorst> ah so its just a coverup for a bet
<mlankhorst> made while drunk ;P
<slangasek> Mirv: I'm confused by the SRU for bug #1056743.  Why is this done as a new upstream version instead of just a distro patch... and why did the version number jump from 5.12.0 to 5.18.0?
<ubottu> Launchpad bug 1056743 in unity-lens-applications (Ubuntu Precise) "Searches fail across changes in case" [Undecided,In progress] https://launchpad.net/bugs/1056743
<infinity> Packages to change from priority required to important
<infinity> ------------------------------------------------------
<infinity> libexpat1
<infinity> libpython3.3-minimal
<infinity> python3-minimal
<infinity> python3.3-minimal
<infinity> I win.
<slangasek> bryce: the xorg-server in the precise-proposed queue was uploaded with the wrong -v option, so is missing refs to bugs #1070481 and #1010794.  Could I trouble you to reupload with the -v option?
<ubottu> Launchpad bug 1070481 in xorg-server (Ubuntu Raring) "memory corruption in xorg-server when closing acpid" [Undecided,Fix released] https://launchpad.net/bugs/1070481
<ubottu> Launchpad bug 1010794 in xserver-xorg-video-nouveau (Ubuntu Quantal) "Graphics/text corruptions in some applications with nouveau drivers" [High,Triaged] https://launchpad.net/bugs/1010794
<bryce> slangasek, done.
<slangasek> bryce: ta
<robert_ancell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #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
<mspencer> I've recently started working on a launchpad project called Ubuntu Contributor Console, based off a spec on wiki.ubuntu.com. Is the ubuntu-devel-announce mailing list a good place to announce it and to get people interested in contributing to it?
<micahg> no, maybe ubuntu-devel if it's related to Ubuntu Development
<mspencer> Here's the wiki page: https://wiki.ubuntu.com/ContributorConsole
<mspencer> micahg: So is it okay to announce it on that mailing list and list some things I don't know how to do and would like others to help on?
<micahg> depends what you're asking for help wiht
<micahg> *with
 * micahg isn't sure....maybe someone else can answer this
<mspencer> I don't really mean asking for help, I mean more like listing things that people could contribute if they are interested. Some things that I'm not good at/don't know how to do are designing an icon, coding the Updates panel (the ability to install and test SRUs).
<pitti> Good morning
<highvoltage> hello pitti
<Mirv> slangasek: it's just a habit of that multi-personality of acting as a normal upstream project, making a new release when there are worthy commit(s). version bump because the idea of releasing eg. all "SRU-3" stack components at the same time with the same version number
<Mirv> but for lenses, there are usually only single commits so distro patching would make sense as well
<Mirv> but thanks for approving it already
<slangasek> Mirv: you're welcome :)
<doko> what's the state of the -compat package?
<doko> infinity, ^^^
<abogdan> I'm developing my first ubuntu app usig Quickly (python + gtk). I want to use some files and folders in my app. Do you know how to pack them together?
<ScottK> abogdan: I think you want #ubuntu-app-devel.
<dholbach> good morning
<pitti> ev: WDYT about http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/509 ?
<ev> pitti: looking
<pitti> ev: with this, make check succeeds for me
<ev> pitti: yeah, that looks entirely reasonable
<ev> thanks for that!
<ev> feel free to merge
<pitti> ev: pushed
<ev> thanks
<pitti> ev: I didn't get much further with the test suite as I don't want to require root for it; but I need to figure out the system identifier
<ev> ah, right
<pitti> ev: so my idea was to finish the whoopsie branch to be able to start as normal user if you set a custom report dir and id
<pitti> ev: such as
<pitti> $ CRASH_DB_URL=http://localhost:8080 CRASH_DB_IDENTIFIER=TESTSUITE APPORT_REPORT_DIR=/tmp/x src/whoopsie -f
<pitti> which I have working already, just cleaning up a bit
<pitti> ev: does that sound ok to you?
<ev> yes, as it also means we could someday use that to generate a known identifier that we could filter out server-side
<pitti> ev: it would also allow us to drop the "sudo stop whoopsie" bits from run-from-juju
<ev> woo
<ev> I was initially startled by that second password prompt :)
<pitti> ev: hm, do you know that locking is broken without -f?
<ev> I did not know that, no
<pitti> ev: the foreground process closes the lock fd as soon as it terminates
<ev> eep
<pitti> no biggie, it just caught my eye; works fine with -f
<pitti> ah, very good; all working now
<ev> awesome
<pitti> ev: I tested this now with both the default "run as root" case, as well as running as user: http://paste.ubuntu.com/1425021/
<pitti> ev: some cleanups and commit msg: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/510
<pitti> ev: oh, this includes the packaging, sorry; I'll re-do the commit to update debian/changelog
<ev> thanks
<ev> ah excellent on opportunistically fixing the APPORT_REPORT_DIR bug
<pitti> ev: changelog pushed for previous commit
<ev> yay
<pitti> ev: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/511
<pitti> ev: while I was at it, I also fixed all compiler warnings in http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/512
<pitti> ev: I'll push that once 511 gets reviewed and can land
<ev> wow, you're on a roll!
<ev> fwiw, I'm making it so that we can mock out the openid provider in lp:errors and adding decent error pages for authentication failures, so it doesn't just confusingly loop back to the openid login page
<pitti> ev: my goal for the day is to get the ARM retracing running; prerequisite for this is a working test suite, which again depends on being able to get reports out of the API, which in turn depends on predictable system IDs, which depend on those whoopsie changes :)
<ev> oh, I'll also chase up that ticket for getting openstack credentials
<ev> so we can get tarmac in place
<ev> :D
<ev> turtles all the way down
<pitti> ev: do you want to give this some deeper eyeballing, want an MP, etc?
<ev> I'm looking over it now - no need for an MP
<ev> looks excellent
<ev> this reminds me that I want to get the gcov stuff in the Makefile working again
<ev> feel free to merge
<pitti> ev: pushed (for cleaner history); mind if I send this raring-wards? or do you want to do further changes?
<ev> https://bugs.launchpad.net/whoopsie/+bug/1088847
<ubottu> Ubuntu bug 1088847 in Whoopsie "We should generate a gcov report with each commit" [Undecided,New]
<ev> please do
<pitti> yeah, that sounds useful indeed
<pitti> with pygobject I was really surprised how easy that was to set up, and how useful it its
<pitti> s/its/is/
<ev> pitti: by the way, if you have good ideas on how to do mocking in C, I'm all ears. There's obviously a few options: function pointer arguments, splitting code more into libraries where you drop in a testing version, etc.
<pitti> ev: the standard way known to me is to overwrite functions with an LD_PRELOAD library
<ev> pitti: so define all the mock functions with the same function signatures as their non-mock counterparts in a library, then use LD_PRELOAD?
<ev> makes sense
<pitti> right
<pitti> not very elegant for sure, but unless you design the code in the way you mentioned I don't know another way
<cjwatson> And indirecting everything through function pointer arguments is pretty un-C-like; I suspect it also has performance penalties
<pitti> or you use GObject more, and thus get the function pointes that way (through the vtable)
<ev> cjwatson: yeah, that was very much a strawman
<pitti> ev: what do you want to mock in whoopsie?
<ev> I don't like having to bust out cdecl to understand a function prototype
<pitti> ev: (I guess you are talking about whoopsie, as all the other bits are py)
<cjwatson> typedefs help a lot, but yes ...
<ev> pitti: for example, if we wanted to test handle_response
<ev> pitti: when we start getting a number of different potential responses from the server
<ev> it either needs to take a function argument to delegate to, or we need to mock out upload_core and friends
<pitti> ev: wouldn't it be better to whip up a mock server in python and have whoopsie talk against that?
<ev> hm, I suppose. I come from two conflicting schools of thought. The "test things in isolation" (previous python projects) and "test all the way down the stack" (lifeless' test harness for oops-repository, which requires a running cassandra)
<ev> but I guess the later is going to give far more interesting results
<lifeless> ev: I'm actually a mix of both
<pitti> if you want to test for responding to server answers, this is already an integration test
<lifeless> for my current thinking, see the ServiceRequirements stuff on dev.launchpad.net
<lifeless> where I suggest having a python mock server that supports error injection, starts up in a jiffy etc.
<pitti> so I think a mock server and running the actual whoopsie thing is better, as it avoids mocking over test code that you actually want to test
<lifeless> the reason oops-repository runs all of cassandra is simple; the low level api wasn't stable when I did it, and mocking unstable APIs is a terrible idea.
<ev> understood, to both of your points
<pitti> ev: hm, if I make use of this feature in integration-test and run-juju-daisy, we depend on a raring-only version of whoopsie; would that be ok?
<pitti> ev: not much trouble for a developer, but I guess we might want to run this for nagios at some point? we could run whoopsie out of bzr for that, of course
<ev> pitti: I believe so. We can always stick it in a PPA for other releases if it becomes necessary.
<ev> pitti: indeed we do want to run it for nagios
<pitti> ev: oops, the kill command in run-juju-daisy doesn't kill the test whoopsie daemon (so it doesn't restore to sending to errors.u.c); fixing that along
<ev> cheers
<vibhav> win 18
<vibhav> oops
<vibhav> Sorry people
<Laney> kirkland: do you still maintain manpages.ubuntu.com?
<xnox> Laney: are you also longing for recent releases?
<xnox> Laney: I think we just should fork the config: add/remove releases and file RT to get it redeployed.
<xnox> https://code.launchpad.net/ubuntu-manpage-repository
<Laney> sure, that was the secret intent behind the ping
<siretart> RAOF: do you have a second to discuss bug #985202 with me?
<ubottu> Launchpad bug 985202 in libxfixes (Ubuntu) "libx11 causes kwin to crash on login (over NX protocol)" [Undecided,Confirmed] https://launchpad.net/bugs/985202
<Laney> xnox: making it dynamic would be even better ;-)
<xnox> Laney: true.... not sure if IS will like dynamism =) anyway, not sure if it will let me push back due to acient bzr repo format.
<Laney> well, using distro-info
<xnox> Laney: is that installed?
 * xnox goes to talk to webops/is.
<Laney> i'm sure it could be
<xnox> Laney: why is distro-info --supported listing raring as supported release?
<xnox> Laney: should I filter out --devel from --supported, or do we want manpages early?
<Laney> does it always take the latest as the default?
<Laney> and I dunno, sounds like a bug
<Laney> bdrung: is that a bug?
<Laney> debian-distro-info --supported looks similarly fishy
<Laney> xnox: note there is python-distro-info for the python part
<xnox> Laney: sure, but manpages.ubuntu.com is a pile of shell & perl scripts with config file sourced as shell.
<xnox> Laney: so... DISTROS=`distro-info --supported` works just fine =)
<Laney> there's at least search.py with a list of versions
<Laney> dict
<xnox> Laney: and some javascript as well =(
<Laney> unlucky
<xnox> Laney: do we SRU distro-info or does it fetch data over the interwebz?
<Laney> the former
<Laney> distro-info-data
<Laney> (so IS has to take that SRU for the site to know about new releases, which is still easier than a full deployment)
<bdrung> Laney: that depends how you define supported.
<Laney>        --supported
<Laney>               list of all supported stable versions
<bdrung> "stable" is the issue here.
<bdrung> maybe it should be able to retrieve all supported stable version and all supported (not released) versions
<xnox> bdrung: well --devel says raring, maybe it should somehow exclude devel from --supported.
<xnox> Laney: filed RT, just a static update.
<Laney> alright
<Laney> ty
<xnox> Laney: we have ~ a year to port this webapp to distro-info-data.
<hrw> how to debug system where dbus is running but all dbus related tools say that it is not? where networkmanager is running (as a process) but there is no dbus so all tools say that NM is not running...
<israeldahl> anyone know much about using imagemagick in the debian/rules file to draw the icon?  is it possible?
<OdyX> israeldahl: what do you want to achieve ?
<OdyX> israeldahl: create an icon from an upstream image ?
<israeldahl> OdyX: the icon looks awful when it gets installed and I want it to look correct. this is for lmms
<sil2100> doko: ping!
<israeldahl> I have had to resort to linking to a different file in the lmms.desktop, but I want to fix it the right way
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #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, Laney
<robert_ancell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<Laney> :-)
<micahg> Laney: how did you cross that continent so fast :)
<xnox> Laney: cheat.
<Laney> collapsars
<didrocks> barry: hey, around?
<barry> didrocks: hi!
<didrocks> sil2100: maybe sum up what the issue you discovered to barry (which is making compiz and a lot of other build-deps failing) ^
<sil2100> barry: hi!
<barry> sil2100: hi :)
<sil2100> barry: ok, so, compiz builds are failing on raring due to missing pyconfig.h in the python2.7 packages - in the past it was installed by python2.7-minimal
<sil2100> But since the latest version (uploaded yesterday?) the file is missing from all the python packages
<sil2100> I traced down the problem, and found which revision of the packaging branch removed it
<sil2100> Maybe by accident? SInce I'm not sure if it's intended
<sil2100> http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/revision/93
<sil2100> Here in the diff of debian/rules, around line 732 in that file
<sil2100> I saw some debian/rules cleanup there, so I though that maybe this one line got removed by accident
<sil2100> barry: do you know anything about this ;) ?
<didrocks> cyphermox: I think the indicator issue you got yesterday is maybe linked to that as well ^
<barry> sil2100: yes.
<barry> sil2100: this change is for multiarch, and it's really a bug in your builds :)  you should be using `python-config --includes` to find the include paths to things (and --libs, etc.)
<xnox> sil2100: it's the same change as with python3.3 - there are now two include locations.
<sil2100> barry: but hm, then which package installs pyconfig.h then?
<sil2100> Since it's not in python2.7-minimal anymore, neither is it in -dev and libpython2.7-dev
<xnox> sil2100: one of dependencies of python-dev
<seb128> sil2100, dpkg -S pyconfig.h
<xnox> sil2100: i still should be libpython2.7-dev
<seb128> sil2100, it's installed, just in /usr/include/<arch>/...
<xnox> sil2100: the point is that python multi-arch now uses 2 include locations /usr/include/python2.7 and /usr/include/<arch>/python2.7 and you need both includes.
<sil2100> xnox: ah, indeed, it's in libpython2.7-dev
<barry> libpython2.7-dev
<sil2100> xnox: thanks! See it now
<barry> oops, yeah
<barry> :)
<sil2100> We'll update the dependencies then!
<sil2100> I couldn't find it due to multiarch ;)
<barry> it's a brave new world
<sil2100> seb128: thanks as well!
<xnox> sil2100: can I see your build-log? as I did patch ~20 packages to find both include locations, when I was transitioning packages to python3.3 (which also uses multiarch locations)
<sil2100> didrocks: I'll make a merge request for that
<sil2100> xnox: https://launchpadlibrarian.net/125437610/buildlog_ubuntu-raring-i386.compiz_1%3A0.9.9~daily12.12.05bzr3522pkg0raring0_FAILEDTOBUILD.txt.gz
<didrocks> sil2100: excellent! Thanks a lot for digging in :)
<xnox> sil2100: thanks. well the build-record, such that I can grab source? e.g. which ppa is this for? =)
<seb128> xnox, get compiz from raring I guess it will have the same issue
<xnox> nevermind see it: unity-team/staging
<sil2100> xnox: https://launchpad.net/~unity-team/+archive/staging/+build/4055447
<xnox> sil2100: thanks.
<sil2100> xnox: just pull lp:compiz and you're done ;)
<sil2100> But I'm preparing a merge request for the change right now anyway, so we'll have it fixed soon
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<xnox> sil2100: ok, can you pastebin a patch such that I can review it?
<xnox> sil2100: or point to merge proposal?
<didrocks> xnox: we do merge proposal for everything in our world :)
<didrocks> (with peer reviews)
<xnox> ok =)
<xnox> didrocks: bzr diff | pastbin & comments on irc is also "peer review" =)))))
<sil2100> xnox: I'll post the link to the merge proposal here ;)
<didrocks> xnox: right, but the merger won't care about your comment on IRC :)
<xnox> sil2100: it's just CMake's FindPython is broken, and instead I was using PkgConfig which will find python2.7 libs & includes correctly.
<seb128> xnox, shouldn't cmake by fixed in that case?
<sil2100> didrocks, xnox: I'll just test-build it quickly
<didrocks> sil2100: "quickly"? aren't you talking about building compiz? :p
<sil2100> ...;p
<xnox> seb128: that would be lovely, but FindPython cmake module is a bit over-engineered and I didn't manage to find an easy way to hook a second include directory check in it.
<seb128> xnox, compiz uses cmake so it's likely going to be the same cmake bug? we will need to fix cmake anyway rather than workaround in each component...
<xnox> seb128: yes, and now. FindPython returns a single include path, this change requires that it now returns a list & uses an include list, so unsuspecting CMakeLists will still be broken =/ for python3.3 i fixed something like 3 packages which used CMake python detection incorrectly. Only one of them used CMake's module, the others had "embedded copies with changes".
<xnox> seb128: e.g. even compiz kind of overrides and does stuff to the cmake's findpython module. so although fixing cmake would help, but is not guaranteed to fix all cmake packages....
<xnox> e.g. I don't understand why so many packages use "custom" python detectors instead of using pkg-config.
<xnox> same story applies to all the autoconf stuff which also missdetects python in different ways.
 * xnox finished ranting about build systems.
<seb128> xnox, yeah, I don't know, people tend to just copy build tools snippet around so errors and weird stuff got copied as well
<xnox> =`(((((
<xnox> clearly everyone should switch to waf build system.
 * xnox hides =)
<seb128> lol
<doko> barry, xnox: maybe I'll just include a fake header for all know multiarch tuples
<barry> doko: not sure what that means
<xnox> doko: please don't. we should just fix stuff. When are we having a rebuilt to spot all of these? Or shall we upload into py2.7 ppa.
<xnox> doko: also I think I finally did figure out & CMake has knoweledge of debian's multiarch triplets. I just need to find time to dig into cmake again.
<xnox> doko: plus it's probably my fault, in some packages e.g. boost/blender I only applied python haz multiarch locations for py3 builds only. I didn't know we will have py2.7 multiarch in raring as well later on.
<barry> didrocks: how do you maintain the packaging branch for oneconf?  i think i can do a quick update of debian/ if the latest trunk is merged in (but i don't want to break things)
<doko> xnox, barry: something like http://paste.ubuntu.com/1425505/
<barry> doko: oh wow, yeah.  maybe put that in a new python2.7-your-build-is-broken binary package? :)
<didrocks> barry: it's a native package, just a quick update of debian/changelog, I'll push to trunk for you and please upload :)
<xnox> doko: is that going into "multiarch-support" package? :P
<barry> didrocks: some changes will be needed for d/control d/rules
<barry> didrocks: shall we bump the version to 0.3? :)
<didrocks> barry: I'm fine with that :)
<barry> didrocks: cool :)  i'll push an mp after some local testing
<didrocks> barry: sounds perfect! :)
<doko> seb128, what was the source package for the python autoconf test. there was one, but I can't remember which one ...
<mfisch> mhall119: FYI, singlet has some warnings about deprecated methods when run in raring
<mfisch> mhall119: I think the fix is safe in Q as well: PyGIDeprecationWarning: MainLoop is deprecated; use GLib.MainLoop instead
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<xnox> doko: autoconf archive?
<doko> no, autoconf doesn't have such kind of macro themself
 * dholbach hugs Laney
<xnox> doko: I meant autoconf-archive package, a package of extra autoconf macros, e.g. it has a broken /usr/share/aclocal/ax_python_devel.m4
<rbasak> ogra_: around? I'm having trouble reproducing bug 1079185 for SRU verification.
<ubottu> Launchpad bug 1079185 in flash-kernel (Ubuntu Quantal) "Wrong bootarg for disk with label" [High,Fix committed] https://launchpad.net/bugs/1079185
<rbasak> ogra_: it's holding up landing the fix for bug 1084106
<ubottu> Launchpad bug 1084106 in The Eilt project "highbank installer broken" [Undecided,Triaged] https://launchpad.net/bugs/1084106
<xnox> doko: python-2.7.pc file has "-I${includedir}/x86_64-linux-gnu/python2.7m" while the include dir shipped is just -I${includedir}/x86_64-linux-gnu/python2.7 (no abiflag m)
<xnox> doko: it's inconsistent, and which way should it be? shipping 2.7m includedir as well or declare 2.7 includedir as "/before/"?
<mvo> didrocks: I get a error when trying to build compiz (trunk) on raring, it python3.3m/Python.h complains that pyconfig.h is not found - is that a known issue? it looks like fallout from the include moving from /usr/include/python3.3m to /usr/include/x86_64-linux-gnu/python3.3m
<didrocks> mvo: see the discussion we had here 1h30 ago ^
<didrocks> mvo: new python changed and is multiarch, sil2100 works on a fix
<mvo> didrocks: aha, nice. then I will not duplicate this effort
<didrocks> no need! :)
<sil2100> mvo, didrocks: we're working on it, but the fix hm, doesn't work, since (if I understand xnox's analysis correct) there might be a bug in the new python packaging
<xnox> yes.
<arges> is there a wiki on how to setup sbuild to build ddebs? I've looked through this: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment but am not sure if I need to add certain DEB_BUILD_OPTIONS to get it working.
<xnox> arges: if you create sbuild with mk-sbuild, you auto-get ddebs.
<seb128> doko, dunno for python autoconf test...
<arges> xnox, in precise? or does it need to be a newer sbuild host?
<xnox> arges: alternatively you need to install pkg-create-dbgsym inside the sbuild. Note a package can override & skip building ddebs (e.g. e2fsprogs)
<xnox> sil2100: filed bug 1088988
<ubottu> Launchpad bug 1088988 in python2.7 (Ubuntu) "inconsistent python2.7 include multiarch paths" [High,Confirmed] https://launchpad.net/bugs/1088988
<xnox> arges: I don't run precise, but I thought that feature was around forever. Did you create chroots with mk-sbuild or manually / some other way?
<arges> xnox, with mk-sbuild...
<arges> xnox, mk-sbuild --arch=amd64 --distro=ubuntu lucid
<arges> xnox, not sure if there si something special I need to add to .mk-sbuild.rc
<xnox> arges: schroot into it and check if pkg-create-dbgsym package is installed, if not install it in the golden / source image and you should start generating ddebs.
<arges> xnox, ok and those ddebs will get placed in the same location as the .debs  then after a build?
<xnox> arges: which you can reconfirm by reading the buildlog - it will announce redirecting dh_strip / generation of ddebs.
<xnox> arges: yes.
<arges> xnox, ok i'll investigate, I looked at the buildlogs and I saw it was installing pkg-create-dbgsym
<sil2100> didrocks, mvo, xnox: after this would get fixed, I think this merge request could be considered?
<sil2100> https://code.launchpad.net/~sil2100/compiz/fix_python_find_package/+merge/139256
<sil2100> hmm, strangely, I can't link a branch to a bug
<sil2100> https://bugs.launchpad.net/compiz/+bug/1088996
<ubottu> Ubuntu bug 1088996 in Compiz "FTBFS after python2.7 upgrade - missing pyconfig.h" [High,In progress]
<sil2100> Here's the FTBFS bug, but I'm unable to link my branch to it ;p
<sil2100> Ok, finally I was able
<arges> xnox, so I rebuild the schroot with no special .mk-sbuild.rc . I tried to sbuild with no options (no ddebs andI see dh_strip), I tried DEB_BUILD_OPTIONS=debug,nostrip,noopt and still doesn't build the ddeb
<arges> and I also still see the dh_strip ... so not sure if its particular to the package... I tried using 'hello' then 'ispell' (just to see if it works)
<xnox> arges: well, it works for me on quantal/raring. i'll try against on precise and will let you know.
<arges> xnox, ok, I'll try on raring here as well... trying to target precise
<xnox> arges: have you tried installing pkg-create-dbgsym in the golden/source image as I suggested earlier?
<arges> xnox, so I see it pulled in the buildlog
<xnox> arges: 1 second - what does your machine run & what do you build for?
<xnox> arges: can you pastebin the buildlog?
<arges> xnox, running precise amd64, schroot is lucid amd64
<arges> xnox, sure one second
<arges> xnox, pastebin.ubuntu.com/1425766
<xnox> arges: i don't think ddebs existed in lucid.
<xnox> arges: but I might be wrong.
<arges> xnox, there is a release directory in ddebs.ubuntu.com
<arges> xnox, for lucid
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> xnox, you are wrong ;-)
<xnox> arges: in that particular case pastbined 2322-2328 it says that it didn't create ddeb, because all binaries were already stripped: no debug symbols - no ddeb for you.
<xnox> arges: apart from that it is working "correctly"
<seb128> xnox, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-November/000355.html
<seb128> xnox, it was well before lucid ;-)
<arges> xnox, ok so I need to pick another package that has ddebs...
<xnox> seb128: ok =0)))
<arges> xnox, i picked that one because it was small and I did find the -dbgsym in the ddebs archive
<arges> for lucid though
<arges> xnox, also pkg-create-dbgsym is in the golden master image
<arges> it was already created by default
<arges> s/created/installed
<xnox> arges: pitti is probably the best person to ask about dbgsym. but he might be offline already.
<xnox> it recent releases "it just works" & i never did dbgsym packages for lucid.
<arges> xnox, ok i'll hack on it
<arges> xnox, i'll try a precise schroot next . thanks a ton for your help!
<xnox> arges: no worries, but it's not like i solve the problem for you =/
 * arges lunches
<mhall119> mfisch: did you file a bug and submit a patch?
<mdeslaur_> barry: is there a mailman command to get a list of the lists I'm subscribed to?
<barry> mdeslaur_: from the command line, or email command (or via web)?
<mdeslaur_> barry: from the web
<mdeslaur_> barry: or email
<mdeslaur_> barry: ie: I don,t have access to the command line
<mfisch> mhall119: will do so
<barry> mdeslaur_: the way to do it from the web is to log in to any list you know you're a member of, then on the options page look for "List my other subscriptions"
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<arges> xnox, ok precise schroot on precise behaves as expected building the .ddebs properly , but lucid schroot on precise doesnt' build ddebs.
<mdeslaur_> barry: ah, cool...thanks!
<barry> np!
<micahg> arges: are you doing xz debs?
<arges> micahg, hi. there isn't xz compression in the debian/rules file for the package I am building. essentially I want to be able to get ddebs from a package in general when building in a lucid schroot
<micahg> arges: ok, sorry, was missing some context, I know xnox was trying to get xz ddebs...
<arges> micahg, I was following the security build environment wiki on setting this up actually.  But out of the box, precise schroot builds the ddebs, while lucid schroots do not
<micahg> let me see if I have an ddebs from lucid builds locally
<micahg> arges: which package are you trying?
<arges> micahg, at this point I'm trying any package... I tried 'hello' then I tried 'ispell' since I saw that it had dbgsyms generated in ddebs.ubuntu.com for lucid
<arges> micahg, i'd like to build a kernel with ddebs in a schroot, but rebuild/test cycle is pretty lengthy
<micahg> TBH, idr if I get them or not
<micahg> just kicked off a build to see if I do
<arges> micahg, ok . did you add any DEB_BUILD_OPTIONS or add anything when you called mk-sbuild?
<mfisch> mhall119: here you go: https://code.launchpad.net/~mfisch/singlet/fix_deprecation_warning/+merge/139301
<mhall119> thanks mfisch
<micahg> arges: nope, and I don't get them on lucid, even with pkgbinarymangler installed
<arges> micahg, hmm ok.  is this a bug I should file? or am I missing something
<infinity> micahg: pkg-create-dbgsym, you mean.
<infinity> micahg: pkgbinarymangler doesn't make ddebs.
<micahg> infinity: right..
<arges>  infinity yea and I confirmed pkg-create-dbgsym is in the golden master lucid schroot by default
<infinity> This reminds me that I need to recreate all my schroots after my great hard drive crash.  What a pain.
<micahg> actually, with pkg-create-dbgsym I do get the ddeb :)
<barry> mfisch: what's the deal w/cracklib2 2.8.20?  your branch is status merged into lp:ubuntu/cracklib2 but the source branch doesn't reflect that.
<micahg> arges: want a build log?
<mfisch> barry: I thought someone merged it this morning, let me look
<arges> micahg, did you add it somehow? I entered the chroot and it said pkg-create-dbgsym was installed
<micahg> arges: it wasn't in my chroot for some reason, I added it with --add-depends
<mfisch> barry: looks like someone merged it to me: https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/cracklib2/raring
<arges> micahg, ok --add-depends , you are adding that to sbuild or mk-sbuild?
<infinity> arges: pkg-create-dbgsym is pretty vocal about disabling itself.  Do you have a build log?
<micahg> arges: sbuild
<arges> micahg, ok i'll try that
<arges> infinity, yea, I have a pastebin somewhere
<infinity> "somewhere". :P
<arges> infinity,  pastebin.ubuntu.com/1425766
<infinity> arges: Right, so it's clearly installed and being triggered.
<barry> mfisch: ah, bzr bd info is out of date
<mfisch> barry: so In the bug I also added a debdiff and the bug still shows in the sponsor queue, whats the right change there?
<infinity> arges: The binaries in all those packages are already stripped, there's nothing pkg-create-dbgsym can do there.
<arges> infinity, ok so i need to choose another package then
<SpamapS> jml: would you ever consider making undistract-me Expat licensed rather than PD?
<SpamapS> jml: I'm packaging it for Debian and PD is.. less than desirable since it is a non-license.
<barry> mfisch: looks like the bug was not closed by the changelog entry.  that's why adding (LP: # 1088110) is useful.  at this point, i think just manually closing the bug as fixed released is the way to go
<micahg> arges: DEB_BUILD_OPTIONS=parallel=4 debug nostrip noopt
<mfisch> barry: oh, sorry I forgot the LP in the changelog
<arges> micahg, yea that's what I added
<infinity> nostrip would likely do it.
<barry> mfisch: no worries, i closed the bug
<mfisch> thanks
<arges> micahg, infinity : ok i figured it out... needed to use a package that actually build debug symbols properly. thanks for the help
<jtaylor> doko: have you forwarded the scipy m-a patches?
<jtaylor> doesn't look like it ..
<jtaylor> doko: I hope you don't mind, I made a pull request to scipys git
<doko> jtaylor, thanks!
<GunnarHj> Riddell: ping
<Riddell> hi GunnarHj
<GunnarHj> Riddell: Hello!
<GunnarHj> Riddell: Saw your comment on bug 1041126. Does it mean that you prefer that we keep language-selector-kde for the time being?
<ubottu> Launchpad bug 1041126 in language-selector (Ubuntu) "Language-selector indicates Adept instead of Muon" [Undecided,Won't fix] https://launchpad.net/bugs/1041126
<Riddell> GunnarHj: isn't ubuntu desktop dropping language selector as well?
<slangasek> why would it?
<GunnarHj> Riddell: Yes, but it will probably be postponed yet another dev. cycler
<Riddell> it's been on the wish list to replace it with the gnome module for cycles
<slangasek> ah
<GunnarHj> Riddell: And other derivatives, Xubuntu and Lubuntu, want to keep using it.
<Riddell> GunnarHj: mm well we've no plans to pick it back up again currently so you can quietly let it bit rot if needed
<Riddell> s/derivatives/flavours/
<GunnarHj> Riddell: Ok, that may be a better word. :)
<GunnarHj> Riddell: Thanks for giving me free hands as regards l-s.
<jml> SpamapS: the license is whatever the hell makes it easy to distribute as open source
<jml> SpamapS: expat is fine
<ricotz> cjwatson, hi :), is it possible to get something like this into raring? http://paste.debian.net/plain/215675
<GunnarHj> slangasek: Hi Steve, will you have time soon to take a look at https://code.launchpad.net/~gunnarhj/ubuntu/raring/pam/encrypted-home/+merge/135021 ?
<slangasek> GunnarHj: I'm expecting to get to it next week
<GunnarHj> slangasek: Great, thanks for letting me know.
<ricotz> cjohnston, sorry for the typos :\ http://paste.debian.net/plain/215676
<ricotz> cjwatson, ^
<Laney> the most incorrectly tab completed nickname in the universe
<slangasek> LanaTurner: yeah, sucks to be them
<infinity> slank: :P
<ricotz> Laney, oh, if you insist you can take a look too ;P
<Laney> you probably want sla<tab> to look at that :-)
<infinity> ricotz: I assume this magical new libpango doesn't exist yet?
<ricotz> Laney, ok ;)
<infinity> (I still have 1.6.0 here...)
<ricotz> infinity, it is a new upstream release which is available for quite some time, but probably won't find its way into raring
<ricotz> https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2835187/+listing-archive-extra
<infinity> ricotz: Kay, so just prepping plymouth for the future?
<ricotz> exactly, and for ppa users of course ;)
<ricotz> this newer pango is a hard-dep for the current gtk+3.0 dev releases
<infinity> I assume it's still libpango1.0-0?
<infinity> ie: not coinstallable with the previous version?
<ricotz> yes it is
<infinity> Kay, maybe this can autodetect a bit more sanely, then.
<ricotz> probably, either way i would be happy to get it supported
<infinity> for i in $(find /usr/lib/x86_64-linux-gnu/pango/ /usr/lib/pango/ -name libpango1.0-0.modules 2>/dev/null); do if [ -e $i ]; then echo ${i%%/module-files.d*}; fi; done
<infinity> Gives me /usr/lib/x86_64-linux-gnu/pango/1.6.0 here.
<infinity> Does it give you what you'd expect there?
<ricotz> /usr/lib/x86_64-linux-gnu/pango/1.8.0
<ricotz> here ;)
<infinity> Right, I'll clean that up and use something like that, then.  Hardcoding the versioned path seems suboptimal.
<ricotz> that is fine, thanks!
<infinity> We can probably ditch the pre-MA path too, depending on when that was introduced.  Let me check.
<ricotz> it is in precise for sure, so i guess it can be dropped
<infinity> Oh, is this code also in Debian's plymouth?  Might be better to change it there.
<infinity> slangasek: *pokity*
<slangasek> mm?
<slangasek> infinity: oh, is this why there's a bug report about text not rendering in the initramfs in raring? :P
<infinity> No, this should be fine in raring.
<slangasek> oh
<infinity> Unless someone's using ricotz's PPA.
<infinity> Then, not so much.
<slangasek> probably not, since it's an ISO tester
<slangasek> infinity: please file a bug report then
<infinity> slangasek: Sure.  I was going to JFDI in Ubuntu, but if this exists in Debian too, may as well tidy it up a bit.
<slangasek> infinity: er, then please file a bug report against the Debian package too? :)
<infinity> A nick hilight wasn't enough? :P
<slangasek> rumors to the contrary notwithstanding, I am not Daniel Baumann
<infinity> I could have sworn I'd seen your name in the Debian plymouth changelog before.
<infinity> Could be that it's Crack Tuesday.
<slangasek> you could well have!  My name is in lots of changelogs
<slangasek> I like to change things
<slangasek> but I don't maintain plymouth in Debian ;)
<hallyn> is there a debhelper way to add a /etc/sysctl.d/ file from a package?
<infinity> hallyn: echo foo /etc/sysctl.d > debian/package.install
<infinity> hallyn: HTH.
<ricotz> infinity, oh, btw did you get my pm?
<hallyn> infinity: ok, thanks :)
<infinity> hallyn: (In other words, no, I don't think there's a helper for it)
<slangasek> hallyn: you might want >> though :)
<infinity> slangasek: Nah, the rest of the package's files were crap anyway.
<slangasek> but yes, there's no specific helper for sysctl
<infinity> ricotz: Maybe.
<hallyn> screw the rest of the pkg.  sysctl will do it all
<infinity> ricotz: Was is ASCII porn?
<infinity> s/is/it/
<ricotz> infinity, heh, let me try again
<infinity> ricotz: If it was glibc-related, I haven't forgotten you.
<ricotz> infinity, yeah, that too, if you have a ppa to check feel free to share ;)
<infinity> ricotz: No, I have a hard drive to recover, and an experimental upload to prepare after that.
<ricotz> alright
<infinity> slangasek: Of course, it could be that this initramfs hook is Ubuntu-specific anyway (it is), so nevermind.  I'll just fix it here and carry on
<xnox> micahg: we have xz ddebs  for raring, not anything earlier.
<xnox> arges: ping pitti about ddebs on lucid-sbuild with precise host.
<arges> xnox, so I figured out how to get ddebs for some packages
<arges> xnox, trying to figure out how to get ddebs for linux kernel now
<infinity> arges: The kernel build is "special".
<infinity> arges: And has nothing to do with pkg-create-dbgsym (at all).
<infinity> arges: It does it all by hand in rules.
<arges> infinity, is there a wiki that explains how to do this via dpkg-buildpackage and sbuild?
<infinity> The kernel team doesn't use sbuild for kernel testbuilds, so unlikely.
<arges> infinity, so how to PPAs accomplish building the ddebs?
<arges> i thought they used buildd which used sbuild?
<infinity> Different sbuild.
<infinity> But also, not the same thing at all, since you want your ddebs to end up in .changes, which they don't on the buildds.
<arges> infinity, ok
<infinity> arges: See debian/rules.d/2-binary-arch.mk
<infinity> arges: Basically, it checks a magic buildd-only file, and does magic things based on it.  Which won't work for you. :P
<arges> infinity, yea i see hmm
<infinity> arges: So, either fix the source to unconditionally do what it normally does in that Build-Debug-Symbols case, or don't auto-clean your sbuild chroots, so you can fish the ddebs out of chroot/build/
<infinity> (And by "fix", I mean "fix locally", cause it's doing the right thing in the archive right now)
<arges> infinity, ahh I think there was a hook to do that somewhere
<infinity> arges: You mean an sbuild hook to set up CurrentlyBuilding to look kinda like a buildd?
<infinity> arges: That would work too.
<arges> infinity, https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Setting_up_and_using_Sbuild_with_ddebs
<arges> infinity, which had the  /etc/schroot/script-get-ddebs script. I'll give that a shot and see if it works
<infinity> That would do the trick.
<arges> infinity, cool... i'll give that a shot.
 * arges heads out
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #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-12-12
<ScottK> jelmer: When do we get Samba 4.0 packages.  Congratulations on the release.
<ScottK> pitti: I went through and accepted the postgresql SRUs, but I didn't see 9.1.7 updates for precise/quantal.  Is that intentional?
<achiang> when merging a package from debian, do people have a favorite strategy?
<achiang> about to tackle merging valgrind from experimental
<achiang> and it's been a while since we synced
<achiang> ah, wisdom - https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<ScottK> For a merge from experimental, pay particular care to why the package is in experimental and not unstable.
<ScottK> We may not want it at all.
<infinity> achiang: Take the base debian version we're based on (pull-debian-source valgrind 1.2.3-4), debdiff against ours, then attempt to apply said diff to new version, resolve conflicts, make sure it all makes some sort of sense, drop useless patches we don't need anymore, profit.
<infinity> ScottK: I think case, I think it's just staging a new upstream due to the freeze, but I haven't looked closely yet, since achiang wanted to cut his teeth on it.
<infinity> s/I think case/In this case/
<infinity> Typing's not my strong suit tonight.
<ScottK> Right.  I didn't look at this case either.
<StevenK> s/ tonight//
<infinity> StevenK: Shut it, vegemite boy.
<achiang> infinity: "attempt to apply diff to new version", you mean apply diff to *old* version, right? (since you have a diff of old vs. new...)
<infinity> achiang: No, you diff old_debian and ubuntu_current to get our delta, then apply to new_debian[C.
<achiang> oic
<infinity> achiang: Which is, essentially, what merge-o-matic does, but it doesn't track experimental.
<achiang> hm, i actually don't see valgrind in experimental, just unstable
<achiang> http://packages.debian.org/search?keywords=valgrind
<achiang> and that explains why we have m-o-m output https://merges.ubuntu.com/v/valgrind/REPORT
<achiang> merging d/control and pondering the Architecture: line, shall i drop the archs we do not support in ubuntu, such as mips and s390x?
<StevenK> No
<achiang> interesting. ok
<pitti> Good morning
<pitti> ScottK: hm, they are supposed to be there, I uploaded them all; I'll check
<snkt> hello
<ScottK> pitti: I think I know what I did wrong.
<snkt> can anyone help me how to install splash screen on ubuntu 11.10  for ARM .... I have used ubuntucore image for ARM...
<pitti> arges: hello, what's up?
<ScottK> I found quantal.
<pitti> ScottK: what happened?
<ScottK> I was looking in New, not Unapproved.
<pitti> ah :)
<ScottK> pitti: I still don't know where precise is though.
<pitti> ScottK: right, I see accepts for hardy, lucid, oneiric, and precise/8.4, missing precise/9.1 and quantal
<ScottK> That matches what I have.
<pitti> odd; I don't see them in rejected either; I'll reupload them
<ScottK> them/it, right?
<ScottK> You should have gotten an accept for quantal just now.
<pitti> ScottK: no, also 9.1 for precise
<pitti> so "them"
<pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=postgresql-9.1 -> there now, too
<ScottK> Right.  That's the one I thought was missing.  Just accepted it.
<pitti> ScottK: thanks!
 * achiang tentatively tries to build valgrind after doing his merge
<RAOF> didrocks: Sure.
<didrocks> hey infinity! It seems that -dbgsym packages for daily-build didn't migrate to the dbgsym repo in the end
<didrocks> thanks RAOF for noticing it
<didrocks> so, if I remember correctly, we disabled -dbgsym publishing in the ppa so that they can migrate correctly?
<didrocks> because when they were published, the copyPackages method failed
<didrocks> it seems something is blocked in the pipe :)
<RAOF> didrocks, infinity: Argh, false alarm. PEBKAC
<dholbach> good morning
<doko> xnox, you did the last python-defaults merge, any reason for keeping the diff in the tests?
<xnox> doko: the other dmitry did last python-defaults merge =) >> mitya57 but he is not online.
<doko> ahh, ok
 * xnox knew the day will come of multiple dmitry. Back in school there were three in my class, so nothing new.
<smb> Every "family" should have their Dmitry... Oh wait that was Igor...
<pitti> would anyone know what "juju debug-log" is good for? It never shows anything for me, not even with -r
<pitti> it would be useful to have it tail /var/lib/juju/charms/*/charm.log on all machines
<rbasak> didrocks: hey, are you about? Do you remember sponsoring bug 1014732 for me around four weeks ago? It got trumped by a security update while sitting in the SRU queue. Would you mind re-uploading my rebased debdiff for me please? It's exactly the same patch with a bumped version number, and I've checked that it still build and works. I've been trying to land this since October :-(
<ubottu> Launchpad bug 1014732 in mysql-5.5 (Ubuntu Precise) "log_error not set in my.cnf, errors not written anywhere" [High,Triaged] https://launchpad.net/bugs/1014732
<didrocks> rbasak: not sure I've time to rebuild mysql today and sponsoring this before holidays :) maybe see with the security team as you got a bad luck due to them? micahg can help I guess :)
<rbasak> OK, well thanks for sponsoring it last time, anyway!
<didrocks> rbasak: no worry :) sorry for not being able to do it again, not sure who was supposed to be the patch pilot today :)
<tkamppeter> pitti, hi
<rbasak> ogra_: ping
<pitti> hello tkamppeter
<arges> pitti, hi. I was trying to figure out how to setup an sbuild environment that builds ddebs for a kernel build. not sure if there is an easy way to accomplish this
<pitti> arges: I thought our kernel package would build the ddebs by itself, without any special magic?
<arges> pitti, i'm also doing this with a precise host, and a lucid amd64 schroot
<arges> pitti, no special magic is required. I tried the default method and no ddebs were found
<ppisati> any cups/printer/scanner guy around?
<micahg> rbasak: maybe mdeslaur_ will sponsor for you if you ask him nicely
<hallyn> stgraber: is there a way to tell from https://launchpad.net/ubuntu/precise/+queue?queue_state=4&queue_text=lxc why )
<hallyn> huh
<hallyn> by whom 0.7.5-3ubuntu66 was rejected
<hallyn> (sorry, bad cut)
<rbasak> mdeslaur_: please would you consider sponsoring bug 1014732 for me? You've trumped me for a security update twice now :-/
<ubottu> Launchpad bug 1014732 in mysql-5.5 (Ubuntu Precise) "log_error not set in my.cnf, errors not written anywhere" [High,Triaged] https://launchpad.net/bugs/1014732
<mdeslaur_> rbasak: sure, I'll take a look a little later
<rbasak> thank you!
<mdeslaur_> rbasak: sorry about that :)
<rbasak> It's OK, I understand. Just a bit frustrating when it happens after sitting in a queue for a month!
<stgraber> hallyn: no, we're still missing the auditing feature in LP
 * rbasak wonders when the next security update for mysql will arrive
<stgraber> hallyn: though there appears to be a 9 days newer version of lxc in the unapproved queue, so that's probably why someone rejected the older one
<hallyn> oh!  i thought i looked for on e there.  ok, makes sense then.
<stgraber> hallyn: people with queue access fairly often go and reject the older of two duplicate entries
<rbasak> infinity: I've not managed to reproduce 1079185 for SRU verification. The installer seems to set UUID= in fstab even though I had a label on the filesystem before, blkid listed that label and I reused the existing partition. The label remains after the install, too (and blkid still prints it). Thoughts? This is blocking bug 1084106 now :-(
<ubottu> Launchpad bug 1084106 in The Eilt project "highbank installer broken" [Undecided,Triaged] https://launchpad.net/bugs/1084106
<rbasak> (I'm trying to reproduce on quantal and then verify that it's gone in quantal-proposed, but I can't reproduce on quantal)
<barry> doko: is virtualenv still working for you on raring?
<doko> barry, 2.7 or 3.3?
<barry> doko: 2.7
<barry> $ virtualenv /tmp/foo
<doko> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=python2.7
<doko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695707
<barry> works w/3.3
<ubottu> Debian bug 695707 in libpython2.7-stdlib "[libpython2.7-stdlib] Breaks python-virtualenv" [Normal,Open]
<barry> doko: that's it
 * barry sees a yak needing a shave
<tkamppeter> pitti, hi
<ScottK> pitti: You're going to fix up your Hardy postgresql SRU, right?
<pitti> ScottK: yes; a bit puzzled what went wrong there
<ScottK> OK.  Thanks.
<pitti> stgraber, cjwatson, xnox: I'm currently reviewing the top ten brainstorm items; two of them are installer issues: http://brainstorm.ubuntu.com/idea/29909/ and http://brainstorm.ubuntu.com/idea/29984/; would you like to respond to either of those?
<cjwatson> I can take the former, although I don't know if I can commit to doing so in what remains of this year
<cjwatson> Send me mail or I'll forget :)
<zul> can someone help me out here, according to http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html xen is blocked because xen-utils-common' has no installation candidate but im not sure why
<pitti> cjwatson: yes, I was planning to, I just wanted to ask around who would like to respond to which
<pitti> cjwatson: thanks!
<pitti> cjwatson: mid-January is fine
<pitti> stgraber, xnox: so would either of you like to respond to http://brainstorm.ubuntu.com/idea/29984/ ?
<pitti> stgraber, xnox: target is a response mid-january, with a time commitment < 1 h
<cjwatson> zul: note that that isn't the place to look for what's blocking migration from -proposed to release
<zul> cjwatson: what is the place then?
<cjwatson> zul: that error's because xen-utils-4.2 should be in universe rather than main - corrected that
<zul> ah i understand
<cjwatson> zul: http://people.canonical.com/~ubuntu-archive/proposed-migration/
<zul> cjwatson: ok thanks
<cjwatson>     * i386: nova-xcp-network, nova-xcp-plugins, xcp-guest-templates, xcp-squeezed, xcp-xapi, xcp-xapi-debug
<cjwatson> i.e. trying to promote the new xen renders those packages uninstallable
<tkamppeter> pitti, is http://brainstorm.ubuntu.com/ not included in the Ubuntu/Canonical/Launchpad SSO?
<cjwatson> zul: at least some of this is because the new xen-api failed to build
<zul> cjwatson: yeah im working on that
<zul> cjwatson: xen-api hard codes xen-4.1 everywhere
<pitti> tkamppeter: it seems not indeed; at least it has its own user/password field
<cjwatson> zul: ok - well, proposed-migration won't let xen in until it's all ready at onc
<cjwatson> e
<zul> cjwatson: so fix xen-api first?
<stgraber> pitti: this sounds like a xnox kind of thing as I've not looked at that part of ubiquity in a while and so can't remember exactly what the current behaviour is. However if xnox doesn't have time for the review, I guess I can do it.
<cjwatson> if you want xen 4.2 in raring then you have to fix xen-api, yes
<pitti> stgraber: ack, merci; I'll see whether xnox can
<smb> cjwatson, The message about installation candidate sounds a bit weird. Though I may not understand the terms there. xen-utils-common is produced by xen...
<cjwatson> smb: I've already debugged and fixed that, so you don't need to try to :)
<xnox> pitti: stgraber: well I can respond, but it will be a decline. Inherently installer is there to wipe your data and install ubuntu. Adding extra warnings "warning we wipe your data to install ubuntu" will not help. And as stgraber found out many USB drives report as internal drives....
<cjwatson> smb: testing/raring-proposed_probs.html only considers main
<cjwatson> (well, and restricted, I think)
<cjwatson> xnox: we don't necessarily have to respond to brainstorm requests as written; one approach would be to clarify the way in which drives are presented
<pitti> xnox: fair enough; note that this is about responding by a qualified person, not an obligation to actually fix it in exactly the proposed manner; there are often better implementations which achieve the same result
<cjwatson> which isn't necessarily in terms of their hardware interface
<smb> cjwatson, Ah ok. Fair enough. :)
<pitti> xnox: e. g. there coudl also be something like the device list showing an USB symbol, etc.
<didrocks> barry: hey did you test with software-center that the python3 related-changes didn't clash? (we don't import everything, just 3 modules, but something to ensure)
<barry> didrocks: i didn't.  what's a good test?  should i just try to install both in a chroot?  and then what? ;)
<pitti> xnox: so, I'll send you an official question by mail with the details
<didrocks> barry: oh no, just start software-center: File -> Sync between computers, set it up with your ubuntu one account
<didrocks> barry: do the same with another computer, and you should see the diff view and all the data after 5 minutes
<didrocks> barry: this is what oneconf is for btw ;)
<barry> didrocks: :)  okay, i can try that in a little bit
<didrocks> thanks!
<xnox> pitti: cjwatson: sounds like mpt might actually be a better person to respond. It's more about usability than code.
<pitti> mpt: ^ would you like to respond to http://brainstorm.ubuntu.com/idea/29984/ wrt. how to present internal vs. external drives in a better way?
<pitti> mpt: target is mid-january with a time investment of < 1 h
<tkamppeter> pitti, thanks. I created an account now, with the same user name as I have in LP.
<achiang> infinity: hi, you awake yet? :)
<infinity> achiang: In meetings.
<infinity> (But yes)
<achiang> infinity: ok, i'll stop bugging you. :)
<tkamppeter> pitti, I have another quuestion: the cups-pk-helper MIR is ACKed now, how should we pull cups-pk-helper into Raring? Recommends from system-config-printer or direct call from ubuntu-meta?
<seb128> tkamppeter, gnome-control-center already recommends it so nothing to do
<tkamppeter> seb128, thanks.
<mitya57> doko: do you know that your python3-defaults upload re-added python3.2 to supported versions?
<mitya57> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/python3-defaults/raring/revision/57/debian/debian_defaults
<doko> $ apt-cache show python3-all
<doko> Source: python3-defaults
<doko> Version: 3.3.0-2ubuntu2
<doko> Depends: python3 (= 3.3.0-2ubuntu2), python3.3
<doko> mitya57, ^^^
<mitya57> doko: but it still needs to be removed from debian/debian_defaults
<mitya57> or it will cause FTBFSes like this one: https://launchpadlibrarian.net/125618205/buildlog_ubuntu-raring-i386.unity-mail_1.2.4~ppa1_FAILEDTOBUILD.txt.gz
<doko> ohh crap
<smoser> cjwatson, around ?
<smoser> i'm wanting to mount a iamage, add proposed, apt-get update && apt-get upgrade.
<cjwatson> Only slightly.  Dinnertime soon.
<smoser> there is a grub update in proposed, and that is giving me grief.
<cjwatson> Put it on hold then?
<smoser> well, the gurb update and the linux-iage update together
<smoser> that would work around
<Riddell> is there a way to do a substitution variable for Depends: ${upstream-version} ?
<cjwatson> ${source:Upstream-Version}
<cjwatson> see 'man deb-substvars'
<smoser> but is there a way i could tell it to just not worry about running grub-probe
<cjwatson> I'm sorry, I don't have time to look into that now
<Riddell> lovely thanks cjwatson
<smoser> cjwatson, ok. it is something i'd like to have a solution for at some point though.  generally i'd like to be able to just 'apt-get dist-upgrade' and tell grub to just leave things as they are.
<cjwatson> in general grub cannot just "leave things as they are" on upgrade without running grub-probe
<cjwatson> any workarounds for that will have to be exceptions
<smoser> cjwatson, i'm ok with needing to supply some  environment variable or something.
<zul> mterry: so stevedore, the tests run fine when its not in a buildd
<adam_g> how does the LP Janitor map new package releases containing bug fixes to bugs that get updated with to Fix Released? does it scrape the changelog? rely on some metadata in the source package? or on bzr branch metadata?
<mterry> stev
<mterry> whoops
<bdmurray> adam_g: the changelog
<mterry> zul, I don't remember the failures exactly, but are they not simply missing dependencies or something?
<zul> mterry:  http://pastebin.ubuntu.com/1428165/
<mterry> zul, when it works locally, do you have the package installed?  Maybe it's not looking in the build tree for what it needs
<zul> mterry: yeah i think i need to set the PYTHONPATH
<zul> mterry:  yeah that works
<robru> adam_g, I believe it does scrape the changelog looking for something like (LP: #nnnnnnnn)
<jono> stgraber, hey
<stgraber> jono: hey
<jono> stgraber, where can I find the current edubuntu logo?
<jono> preferably as an svg?
<stgraber> jono: http://www.edubuntu.org/edubuntu-text.svg
<jono> thanks stgraber :-0
<stgraber> np
<highvoltage> stgraber: hmm, that doesn't seem to be the right logo
<ScottK> Shhh.  You're spoiling stgraber's fun.
<highvoltage> jono: could you use this one instead please? http://upload.wikimedia.org/wikipedia/commons/4/41/EdubuntuLogo.svg
<jono> highvoltage, sure!
<jono> just adding the logos to the ADK
<highvoltage> okdk
<stgraber> highvoltage: hmm, they look pretty much identical to me, besides the default size set in the svg :)
<stgraber> though the actual .svg content is quite different
<highvoltage> stgraber: the latter has the correct typeface colour
<highvoltage> stgraber: (the circle of friends icon is also differently positioned, not that I care about that much, but might as well keep it consistant as we did so far)
<stgraber> highvoltage: ok, updated the copy on humboldt to match that from wikipedia
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<cjwatson> adam_g: technically, it doesn't scrape the changelog.  dpkg-genchanges does that on the uploader side and puts the results into the Launchpad-Bugs-Fixed field of the .changes file.
<tkamppeter> Someone of the Ubuntu SRU team here? For bug 1054495 cups 1.5.3-0ubuntu6 is waiting for approval in the -proposed queue and users are complaining that the package does not get available for testing.
<ubottu> Launchpad bug 1054495 in cups (Ubuntu Precise) "AirPrint doesn't work on iOS 6 device" [High,In progress] https://launchpad.net/bugs/1054495
<bdmurray> tkamppeter: I'll look at it tomorrow
<tkamppeter> bdmurray, thanks.
<infinity> tkamppeter: Accepted (again).
<tkamppeter> infinity, thank you very much.
<bdmurray> stgraber: can you mark https://code.launchpad.net/~straemer/ubuntu/quantal/update-manager/fix-for-1058070/+merge/136551 as merged?
<stgraber> bdmurray: done
<bdmurray> thanks
#ubuntu-devel 2012-12-13
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<chilicuil> hi, I'm trying to add a patch to package without a patch system, what should I do?, add a patch system? (quilt) or modify the upstream files?
<mdeslaur_> chilicuil: if it's for a stable release, modify the files. If it's for the dev release, it depends. If some files are already modified, please modify the files. If no files are already modified outside of the debian directory, then yeah, use quilt ie: source format 3.0
<mdeslaur_> chilicuil: what package?
<chilicuil> mdeslaur_: rcconf it only have 1 change, but it was made on /debian so, no patch system was necessary
<chilicuil> mdeslaur_: and it's to go to the dev release and then if possible request sru for quantal / precise
<mdeslaur_> if it's in the debian directory, then your problem is solved, no patch system necessary
<chilicuil> mdeslaur_: the change I'm going to do is on upstream files, but then AFAIK no other changes where made to upstream files.., so I suppose I'll go with the quilt format
<mdeslaur_> chilicuil: actually, looks like it's a native package, so you're better off just changing the files
<chilicuil> mdeslaur_: ohh, how did u know it was a native package?, I'm gonna change just the files
<mdeslaur_> it only has a single source tarball, and the version number doesn't have a '-' in it
<mdeslaur_> is 2.5ubuntu1 instead of something like 2.5-0ubuntu1
<chilicuil> I'll remember that, thanks for your time
 * achiang pokes infinity during non-work hours re: valgrind :)
<scientes> what happened to #debian-multiarch?
<micahg> scientes: you mean #multiarch on OFTC?
<scientes> micahg, yep, i just got it wrong, my bad
<pitti> Good morning
<pitti> tkamppeter_: no, cups-pk-helper doesn't sound like something which should be seeded; it should be a dependency of all packages that talk to it, such as gnome-control-center and/or s-c-p (if that uses it)
<pitti> ah, what seb128 said
<dholbach> good morning
<mitya57> guten morgen dholbach
<dholbach> hey mitya57
<dholbach> mitya57, did you see that Russian get lots of translations updates in the packaging guide? :)
<mitya57> wow, it's 61%!
<didrocks> hey dholbach!
<dholbach> mitya57, exactly :)
<dholbach> salut didrocks :)
<mitya57> dholbach: can you please investigate what happens with http://developer.ubuntu.com/packaging/es/singlehtml/_static/translations.js?
<mitya57> it is installed by the package, I've just verified
<dholbach> mitya57, will do
<mitya57> thanks
<mitya57> btw:
<mitya57> -rw-r--r-- 1 root root 357 ÐÐµÐº  7 17:05 /usr/share/doc/ubuntu-packaging-guide-html-es/_static/translations.js
<mitya57> $ dpkg-query -S /usr/share/doc/ubuntu-packaging-guide-html-es/_static/translations.js
<mitya57> ubuntu-packaging-guide-html-es: /usr/share/doc/ubuntu-packaging-guide-html-es/_static/translations.js
<pitti> apw: how annoying -- our tests find crashes in the kernel!
<apw> pitti, heh nice
<pitti> apw: I filed bug 1089818 with a minimal CLI test case
<ubottu> Launchpad bug 1089818 in linux (Ubuntu) "kernel crash when mounting encrypted (device mapped) ext4 partition" [Undecided,Confirmed] https://launchpad.net/bugs/1089818
<pitti> fortunately this works in kvm, so no need to crash my workstation all the time
<pitti> apw: I attached a screenshot of the oops, but unfortuantely it cuts off the upper end (and as it's a hard crash there is no Shift+PageUp)
<pitti> is there a trick to see the full one? like configuring the console to be bigger or so?
<apw> yeah... thats too normal
<apw> you used to be able to go to a higher resolution, but not so much now i think
<pitti> yeah, those days with real svga modes
<Sweetshark> doko, pitti: fyi, I enabled the libmerged configury and there seem to be no issues. I havent tried if is speeds things up on slow hardware, but it does save ~8MB in package size for libreoffice-core and up to 150MB on libreoffice-dbg (unless something else essential changed between alpha/beta and quantal/raring there)
<pitti> \o/
<apw> pitti, on this luks bug, as it reproduces in KVM you ought to be able to configure a serial console and get the full dump i recon
<chrisccoulson> where does python get its search paths from when you don't import site.py (ie, with -S)?
<chrisccoulson> nm, figured it out
<tkamppeter> pitti, hi
<bdrung_> dholbach: please don't forget to unsubscribe the sponsors team
<Laney> how do I find out the UUID whoopsie is using?
<ev> Laney: printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
<Laney> ev: that doesn't exist on this system
<ev> Laney: then it's the sha512 sum of your mac address
<Laney> ah ok
<Laney> hm, nothing showing
<Laney> I was hoping whoopsie could tell me itself to reduce the chance of me calculating it differently
<Laney> I suppose there is probably some lag after submission
<ev> Laney: lag?
<Laney> before it would show up on errors.u.c - time to be retraced and such?
<xnox> Laney: did you just submit your first ever crash from that machine?
<Laney> yeah
<ev> Laney: it doesn't retrace every crash. All your reports should be instantly available off errors.ubuntu.com/user/$your_id
<ev> the whoopsie binary doesn't print out the identifier it users (yet - feel free to file a bug against the upstream project for that)
<Laney> ev: Is there a log file that shows whether submissions were successfully made?
<ev> Laney: do make sure you're not including a newline in whatever you're feeding into sha512sum
<Laney> oh, yeah, that could be it
<ev> Laney: a successful submission will result in a .uploaded file being written to /var/crash
<Laney> OK good, I see two of those there
<Laney> Still can't get the UUID right, but the presence of those files reassures me somewhat
<Laney> context is that I enabled core dumps on the nexus 7 and want to see if they are making it up to errors.u.c correctly
<ev> Laney: do you have an eth0 device?
<Laney> no, just wlan0
<ev> hm, it should still use that
<ev> it only avoids the loopback device
<ev> Laney: so as a quick workaround, you could build whoopsie from source with a printf("ident: %s\n", whoopsie_identifier); on line 895
<ev> then make and sudo LD_LIBRARY_PATH=src CRASH_DB_URL=https://daisy.ubuntu.com ./src/whoopsie -f
<ev> err line 895 in src/whoopsie.c
<Laney> ev: http://paste.ubuntu.com/1429511/ - that's how I'm getting the UUID
<Laney> let me try that
<ev> ah, that wont work
<ev> err nevermind. It should do
<Laney> yeah that's the same one whoopsie tells me it gets
<Laney> hmm
<pitti> ev: reviewed https://code.launchpad.net/~ev/daisy/optional_s3/+merge/139532
<ev> pitti: thanks; I'll fix those :)
<bdrung_> tumbleweed: can we get #1088565 fixed in Debian testing?
<tumbleweed> bdrung_: yeah that was on my radar somewhere...
<bdrung_> tumbleweed: do you know what causes that crash?
<pitti> tseliot: ah, the u-d-common autopkgtest fails, it seems bcmwl-kernel-source has lost its Modaliases: header; I'm looking into this
<tseliot> pitti: oh, I hadn't noticed
<pitti> tseliot: yeah, and the debdiff doesn't show an obvious bug
<pitti> tseliot: but thanks to having tests :)
<tseliot> pitti: yes, it's great to have them :)
<tumbleweed> bdrung_: well "Not permitted to upload directly to raring; try raring-proposed instead." is kind of self explanatory
<tumbleweed> as to python-keyring and dbus, NAFC
<tseliot> pitti: it seems that they have removed struct pci_device_id wl_id_table[] from wl_linux.c
<apachelogger> tkamppeter: is there a way to set a custom printer test page at runtime?
<pitti> tseliot: or rather, replaced it with { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID}
<pitti> which is quite pointless
<tseliot> pitti: right
<pitti> I'm keeping notes in bug 1089943 FYI
<ubottu> Launchpad bug 1089943 in bcmwl (Ubuntu Raring) "Lost its Modalises: package header" [High,In progress] https://launchpad.net/bugs/1089943
<pitti> so if that effing module itself doesn't know which devices it can talk to, how is userspace supposed to know?
<pitti> thanks broadcom. not.
<tseliot> pitti: heh, right...
<tseliot> pitti: here's the output of modinfo: http://paste.ubuntu.com/1429785/
<tseliot> pitti: we should probably use that as the alias
<pitti> tseliot: ok, so I guess I'll drop the parsing script, and just add a static alias for vendor == broadcom and class == network
<tseliot> pitti: right
<pitti> tseliot: that's too wide, though; we don't want it to match on all vendors
<pitti> tseliot: thanks
<tseliot> pitti: thanks to you
<pitti> hmm, I wonder if that's actually right
<pitti> unfortunately my mini 10 is away for the week
<pitti> seb128: you still have your mini 10, right?
<seb128> pitti, I do
<seb128> pitti, do you need anything tested on it?
<pitti> seb128: yes, if you could
<seb128> pitti, sure can
<seb128> tell me
<pitti> seb128: I need the output of "ubuntu-drivers debug" on that thing
<seb128> what ubuntu version?
<pitti> seb128: or, if it's running precise, run jockey and give me the log
<pitti> seb128: doesn't matter
<pitti> seb128: I'm just interested in the vendor/product/device class/device subclass of the broadcom wifi
<seb128> ok, let me boot it, I'm unsure what version is on it, I use it as a testbox mainly nowadays so that keeps changing :p
<pitti> seb128: or, regardless of the ubuntu version: cat /sys/class/net/*/device/uevent
<pitti> seb128: ^ that'll work everywhere and is enough
<ScottK> lamont: Can haz postfix 2.9.5?  Raring or experimental as you prefer.
<seb128> pitti, http://paste.ubuntu.com/1429801/
<seb128> pitti, that's the cat output
<pitti> hah!
<pitti> tseliot: ^ so current wl is broken
<pitti> tseliot: as it only matches on sc80, while a real card uses sc00
<tseliot> pitti: oh, we should report that to broadcom then
<pitti> oh, ignore me
<pitti> seb128: weird, that doesn't look like a broadcom card
<tseliot> false positive?
<pitti> vendor 10EC
<pitti> DRIVER=r8169
<tseliot> oh
<pitti> seb128: is that not using the bcmwl driver then?
<pitti> seb128: my mini 10 has a broadcom wifi chip
<seb128> pitti, it is, but I think that's a stock install of precise without the driver enabled (wifi seems to not be working)
<seb128> pitti, let me run jockey
<smoser> slangasek, bug 1070345 failed verification, what is the path to getting that fixed in proposed?
<ubottu> Launchpad bug 1070345 in cloud-init (Ubuntu Quantal) "need to restart landscape after updating config" [Medium,In progress] https://launchpad.net/bugs/1070345
<smoser> i upload a 0.6.3-0ubuntu1.3 (previous was 1.2) ?
<seb128> tseliot, pitti: http://paste.ubuntu.com/1429819/
<seb128> better
<pitti> seb128: ah, trÃ¨s bien, merci pour ton aide!
<pitti> "ta aide"
<seb128> pitti, de rien !
<seb128> "ton aide"
<pitti> aide c'est masculine?
<pitti> bah
<pitti> seb128: ISTR "ton aide", then twiched because that looks feminine
<tseliot> :)
<pitti> tseliot: anyway, that alias looks right
<seb128> pitti, it is fÃ©minin
<tseliot> pitti: the one from modinfo?
<pitti> tseliot: from http://paste.ubuntu.com/1429819/
<pitti> tseliot: no, the one from modinfo is definitvely broken
<pitti> tseliot: as it matches far too liberally, i. e. on _any_ network card
<tseliot> pitti: ok
<pitti> tseliot: I'll upload "pci:v000014E4d*sv*sd*bc02sc80i*", that should do
<tseliot> pitti: right, thanks
<tseliot> pitti: also, if you can reject my upload from precise-proposed I can integrate your change
<pitti> tseliot: oh, then I'll add the package name, too (this was only necessary for jockey)
<tseliot> ah, good
<pitti> actually, I don't think so, but I'll add it anyway
<smoser> looking for an answer...
<smoser> i uploaded cloud-init 0.6.3-0ubuntu1.2 to precise-proposed, got accepted. bug 1070345 failed verification.
<ubottu> Launchpad bug 1070345 in cloud-init (Ubuntu Quantal) "need to restart landscape after updating config" [Medium,In progress] https://launchpad.net/bugs/1070345
<smoser> is it ok to upload to -proposed a fix? do i need to open a new bug ? or just re-reference that in changelog.
<cjwatson> upload incremented version to -proposed, use -v<version in -updates or failing that in release pocket> when generating source package, just re-reference the same bug
<pitti> tseliot: oh, and rejected your bcmwl precise upload
<tseliot> pitti: thanks again
<cyphermox> who looks at SRUs today?
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, it is about CUPS in Quantal. It crashes for me like once in two days, not related to jobs.
<tkamppeter> pitti, it seems to be caused by the forward port of the CUPS Broadcasting/Browsing. If I remove the mega patch CUPS gets stable.
<tkamppeter> pitti, I have tried to fix it but with the fix applied CUPS gets stuck instead of crashing.
<lamont> ScottK: I'll toss it at sid, if that works for you?  prolly this weekend, unless there's a pressing need...
<tkamppeter> pitti, this is even worse as if CUPS crashes, Upstart restarts it and so for most users there is no problem.
<ScottK> lamont: This weekend is fine.
<ScottK> Thanks.
<tkamppeter> pitti, as the forward port is intended to be removed in Raring I am thinking about not to try to fix the crash but simply to suppress the Apport pop-up, then users will not perceive it and Quantal will work well for them.
<tkamppeter> pitti, how can I suppress the Apport pop-ups for CUPS.
<pitti> tkamppeter: well, we certainly don't want to suppress all crashes, just this one
<tkamppeter> pitti, is there a way to do so?
<pitti> tkamppeter: not that easy to completely avoid the popup
<tkamppeter> pitti, any suggestion what to do?
<pitti> tkamppeter: sorry, busy with the testing hackfest
<pitti> tkamppeter: not immediately, I'm afraid; I need to think about this
<tkamppeter> pitti, I do not need a solution urgently today, but it would be great if I could make a CUPS SRU to stop user complaints about this problem. So think about it and tell me in the next days.
<pitti> tkamppeter: do you already know where the crash happens in the code?
<tkamppeter> pitti, yes, there are bug reports with an appropriate backtrace. Unfortunately, trhe actual crash happens somewhere in Avahi/D-Bus and not in CUPS itself.
<tkamppeter> pitti, it is an Avahi threaded poll.
<pitti> xnox: did you notice the upstart autopkgtest failure? it fails a test, and has some stuff on stderr
<xnox> pitti: yes, bug 1089159
<ubottu> Launchpad bug 1089159 in upstart (Ubuntu) "ADT test-suite failure" [Medium,Confirmed] https://launchpad.net/bugs/1089159
<pitti> ah, thanks
 * pitti subscribes
<xnox> pitti: basically want to consult with jodh about it, but didn't get around to doing so yet.
<tkamppeter> pitti, see bug 1086019
<ubottu> Launchpad bug 1086019 in cups (Ubuntu) "cupsd crashes regularly (daily)" [Undecided,Confirmed] https://launchpad.net/bugs/1086019
<cjwatson> bdmurray,StevenK: uh, I'm not sure I buy bug 1085844.  subprocess.Popen honours PATH
<ubottu> Launchpad bug 1085844 in ubuntu-release-upgrader (Ubuntu) "update-manager uses subprocess.Popen incorrectly when calling dpkg" [High,Triaged] https://launchpad.net/bugs/1085844
<cjwatson> it doesn't make sense that dpkg would need to be invoked with its full path there
<cjwatson> if it does, it seems to me that something else must be wrong which might cause other failures, and it would be better to find that than play incorrect whack-a-mole adding full paths to things (which is often a problematic route later)
<christoffer> Does launchpad have any Jenkins or Hudson running that will automatically run full test suite on new commits?
<christoffer> runt unit tests for python code that is
<christoffer> *run
<cjwatson> christoffer: probably better asked on #launchpad
<christoffer> ok
<christoffer> thanks cjwatson
<tkamppeter> pitti, I have added a comment to bug 1086019.
<ubottu> Launchpad bug 1086019 in cups (Ubuntu) "cupsd crashes regularly (daily)" [High,Triaged] https://launchpad.net/bugs/1086019
<pitti> barry, doko: /usr/bin/python2.7-config now being a shell script instead of a python script breaks waf (and thus e. g. the samba4 build); in Debian it is still a python script, so we'll need to introduce deltas
<pitti> barry, doko: was that intended; will that be changed in Debian as well, so that the patches can be forwarded?
<barry> pitti: doko changed that, i'm not sure why
<barry> pitti: how does it break?
<doko> barry, to run it for a cross build
<pitti> barry: waf tries to call $PYTHON /usr/bin/python2.7-config
<pitti> which now fails wiht a syntax error
<doko> neat
<pitti> barry: see current samba4 build log
<smoser> slangasek, i just uploaded another cloud-init to precise-proposed. i'd appreciate your review of the delta from cloud-init_0.6.3-0ubuntu1.2 to cloud-init_0.6.3-0ubuntu1.3
<pitti> admittedly that looks wrong, but if upstream's python-config is python it might be harder to argue
<doko> pitti, I was going to change that upstream
<pitti> doko: ah, good
<barry> pitti: awesome :)
<pitti> -               for incstr in Utils.cmd_output("%s %s --includes" % (python, python_config)).strip().split():
<pitti> +               for incstr in Utils.cmd_output("%s --includes" % python_config).strip().split():
<pitti> that ought to do
<barry> doko: well, you might not be able to change that in upstream 2.7 or 3.3 stable releases
<doko> barry, I know ...
<doko> pitti, which package needs the fixing?
<pitti> doko: I'm currently doing samba4
<pitti> I don't know which others break (i. e. how many use waf)
<doko> pitti, ugh, do you know about more?
<pitti> no, I don't
<pitti> I just happened to see the samba4 FTBFS, which I didn't get with my slightly older raring yet
<pitti> good night everyone
<didrocks> good night pitti!
<xnox> pitti: doko: well samba's waf is special - it's almost a fork / a build system based on top of waf.
<pitti> ah, so hopefully it's not that widespread then :)
<xnox> I wouldn't worry that much. Since by default waf executes *-config scripts as executables found on path, without making assumptions whether it's interpreted or not.
<jelmer> pitti: patches to upstream this issue welcome :-)
<jelmer> ehm, the *fix* for the issue
<pitti> jelmer: yep, will send tomorrow; I need to run now
<jelmer> pitti: thanks :)
<blami_> hi, what's the ubuntu decision on merged /usr?
<bobweaver> what ? blami
<bobweaver> can you give us more details blami_
<bobweaver> maybe I missed something sorry
<superm1> bobweaver: probably http://fedoraproject.org/wiki/Features/UsrMove
<blami_> bobweaver: I mean merging /bin /sbin /lib to /usr. It is considered 'upstream' and invented by Fedora :)
<blami_> bobweaver: I found some resources on doing so in Ubuntu as well: https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge
<infinity> blami_: It's not really up to us, to be fair.  We've decided to be pragmatic and support mounting /usr from the initramfs, so that software that breaks due to the assumption that all systems are Fedora/RH will continue working.
<infinity> Which reminds me, I should do something about that initramfs-tools bug upstream this month.
<slangasek> smoser: a reupload to -proposed is the right thing to do; did you build your upload with -v$(last_version_in_updates)?
<blami_> infinity: sounds reasonable to me ... so there's no need to fix possible conflicts in packages (dupes in symlinked /bin vs /usr/bin) like fedora did, right?
<infinity> blami_: There's a need to do that at anyway (it's a bug regardless), but we're not merging them tomorrow or anything, no.
<infinity> s/that at/that/
<infinity> blami_: Err, that is, it's a bug if two packages ship a conflict on PATH.  Arguably not a bug if it's one package shipping migration symlinks, but those should all go away some day anywhow.
<blami_> infinity: ah, thanks
<smoser> slangasek, i did.
<slangasek> smoser: perfect, thanks
<dobey> why does do-release-upgrade on quantal tell me "No new releases found" still?
<slangasek> because raring isn't released
<slangasek> 'do-release-upgrade -d'?
<dobey> oh right. update-manager -d wasn't working; just gave me normal q updates
<dobey> thanks
<SpamapS> slangasek: Note that I just commented on but 1089771
<SpamapS> slangasek: I'm pretty sure that is not in network-manager.. I changed it to ifupdown
<SpamapS> stgraber: ^^
<stgraber> bug 1089771
<ubottu> Launchpad bug 1089771 in ifupdown (Ubuntu) "umount of /var partition fails during shutdown, due to lingering dhclient" [Undecided,New] https://launchpad.net/bugs/1089771
<slangasek> SpamapS: ok.  I knew it wasn't upstart, anyway :)
<SpamapS> slangasek: yeah for sure not upstart's fault
<slangasek> SpamapS: interestingly enough, only after we've gotten upstart in unstable have I gotten a report about dhclient writing to /var/lib; I would've thought someone would have noticed this in Ubuntu before now: Debian bug #694963
<ubottu> Debian bug 694963 in upstart "upstart: Upstart canÂ´t handle auto entry in network/interfaces" [Important,Open] http://bugs.debian.org/694963
<SpamapS> slangasek: separate var partitions are sooooo 1999
 * slangasek shrugs :)
<blami> why telepathy development package is called -devel and not -dev which seems to be sort of standard on .deb based systems?
<RAOF> blami: Because it's a meta-package (ie: it doesn't contain anything itself, it just depends on other packages)
<bdrung> blami: meta-telepathy is the source package. It seems that the package name is there since the beginning.
<bdrung> blami: i suggest to ask dholbach when he comes online in around eight hours (UTC+1 buddy)
<blami> RAOF: aha
<RAOF> All of the *actual* development packages are named $FOO-dev, as is policy.
<blami> bdrung: thanks, will do. Unfortunately I am UTC+1 too :>
<RAOF> See also: gnome-devel
<bdrung> blami: where do you come from?
<blami> RAOF: I got the point, it does not hold any headers nor development tools, just pulls other -dev packages, right?
<blami> bdrung: Praha PRG,CZ
<bdrung> RAOF: I called packaging-dev packaging-dev even though it is a meta package
<RAOF> blami: Right. And some development tools which aren't headers - telepathy-inspector, for example.
<RAOF> bdrung: Which is not wrong either âº
<bdrung> blami: Praha is a nice city (i visited it 10 years ago)
<bdrung> good night
<infinity> Laney: What did you do to webkit to make it take twice as long to build?  Is it accidentally relinking during make install now?
#ubuntu-devel 2012-12-14
<xnox> xz?
<infinity> xnox: *blink*
<infinity> xnox: Oh, my webkit question?  No, it really is relinking.
<infinity> xnox: Adds about 11h on ARM.  Totally unfun.
<xnox> although it has separate -dbg packages.
<xnox> infinity: 0_0
 * xnox noticed a checky -Zxz in cdbs/gnome.mk
<infinity> It's the whole libtool relink-on-install business.
<xnox> s/checky/$(whatever proper way to spell it)/
<infinity> Cheeky?
<xnox> yes.
<micahg> webkit doesn't use cdbs
<xnox> micahg: sure. it was a slightly vaguely on-xz-topic references. considering that a few things in desktop seed do use cdbs/gnome.mk.
<infinity> xnox: I don't mind if things are sneakily switching.  udebs have been xz for ages.
<micahg> switching to xz debs is a good thing for things that are frequently updated
<infinity> Over time, I think it's the right answer for almost everything, the only thing I've been pushing back on is us doing it on our own without coordination with Debian.
<micahg> so, Debian's main goal right now was to try to get everything that's supposed to be on CD #1 back on CD #1, so that probably explains the GNOME usage
 * micahg is telling people what they already know again...
<xnox> infinity: micahg: should we switch langpacks from bz2 to xz?
<xnox> frequent && !debian-upstream
<xnox> =))))
<infinity> xnox: Probably, yes.  Anything we're forcing to bz2 right now should probably switch.
<infinity> xnox: Need to be careful, though, since that's all autogenerated, and we don't want to accidentally switch, say, lucid langpacks.
<xnox> that would be all emacsen & texlive.
<xnox> infinity: is lucid still getting langpack updates?!
<infinity> Oh, probably not, since we're not doing point releases anymore.
<xnox> yeah, that's what i thought - surely it must be past it's point releases.
<infinity> But there's always the chance someone may decide that we should.
<infinity> *shrug*
<micahg> wait till april?
<infinity> Anyhow, I wouldn't be against changing langpacks.  It's not really as meaningful as it was when we were trying to stuff them on alternate CDs, mind you.
<infinity> Which was why they were bz2.
<xnox> infinity: but these days we download them on-demand & the smaller they are the faster we download them.... not sure about the unpack time penalty vs bz2
<infinity> It was never about mirror space or download time, just trying to stuff a ton of packages on a CD.
<xnox> on-demand = during the install that is.
<infinity> Download time versus unpack is hard to benchmark, since we first have to decide what an "average user" has for both bandwidth and CPU/RAM.
<micahg> unpack should be faster than bz2
<infinity> My gut feeling, though, is that almost any unpack time impact will negate bandwidth concerns almost immediately for all but people on dialup.
<micahg> it's compression that might be a tad slower
<infinity> micahg: Oh, for bz2, yes.  Which is why I said we should just switch bz2 stuff to xz.
<infinity> This sort of turned into a generic xz discussion for me halfway through. :P
 * xnox the 21st centure term for dial-up  is 3G or metered/expensive 4G
<infinity> In general xz will almost always be a win over bz2.
<infinity> But it can often be a loss over gzip.
<StevenK> infinity: In terms of CPU time, file size or both?
<infinity> StevenK: Both, usually.  bzip2 is pretty awful.
<infinity> Which reminds me, I should drag our buildd chroots kicking and screaming into the current century and stop using bz2.
<StevenK> Haha
<StevenK> Does lp-buildd depend on them being bz2?
<infinity> StevenK: Yeah, but that's easily solved.
<StevenK> What about dak?
<infinity> StevenK: What I need to double-check is that there are no server-side assumptions there.
<infinity> StevenK: ...dak?
<StevenK> infinity: Yeah, I've been trying to think about the chroot handling in LP, and I'm not sure.
<infinity> StevenK: Preeeeetty sure we have no dak instances with a buildd/sbuild setup backed by the librarian's chroot tarballs. :P
<StevenK> Heh
<xnox> there is always first time for everything =)
<infinity> Anyhow, if there are any soyuz assumptions, they'd just be filename assumptions.
<infinity> Which isn't actually a big deal.
<infinity> Cause I can check file(1) magic when I grab the librarian blob and work with that.  Filenames are meaningless.
<infinity> (And given that they're stored as filcache/$HASH on the buildd anyway, filenames are already meaningless)
<xnox> infinity: also tar knows how to auto-guess all supported compression formats by default....
<StevenK> infinity: Oh, so it just assumes filecache/$HASH is bzip2? Orsum ...
<infinity> StevenK: It's a bit weirder than that.  Since the $HASH is the hash of the tar.bz2, but after the first unpack, the contents are actually just the .tar
<infinity> (To avoid unzipping over and over)
<StevenK> Hah
<infinity> Not sure what Daniel was smoking that day.
<StevenK> Right, I was wondering if we were paying the bzip2 penalty over and over.
<infinity> Nah, the bz2 hit is only on first unpack of a new chroot, so it's not a big deal.
<infinity> Which is why I never cared deeply about changing format.
<StevenK> infinity: And yet you seem to care a little now? :-)
<infinity> I'll stop caring soon.
<infinity> But I'm touching lp-buildd for some other fixes over the holidays, some compression magic could accidentally slip in.
<pitti> Good morning
<mlankhorst> could one of the sru admins accept xorg so that I can retire the backports ppa? :-)
<dholbach> good morning
<blami_> what's a ubuntu developer usual workflow? When I decide to patch something should I do my changes to upstream first and then have them propagated to package or fix package first and then contribute to upstream?
<persia> For ease of testing, I generally fix the package first, make sure it runs in the current development environment, and then see how the patch could go upstream.
<dholbach> blami_, getting fixes as upstream as possible is usually the best idea, but depending on how urgent the fix is, it might make sense to get it into Ubuntu first
<persia> That said, it is usually a good idea to check upstream to see if the issue is already solved beforehand (and perhaps cherrypick, if the new upstream version isn't looking likely to land in the current release), which may mean that the first solution is against upstream.
<persia> dholbach: In terms of committing the patch, I couldn't agree more, but in terms of initial testing, do you usually pull the upstream source (repackaging if necessary), and patch it for issues?
<dholbach> persia, no - I was merely commenting on where to contribute the fix to
<persia> Oh, indeed.  Once the patch works, sending upstream is best, and sometimes it's not even worth an Ubuntu upload.
<blami_> persia: so you usually do something like bzr branch something or apt-get source something, apply your changes, build the package, test it and then, if it works you decide how to integrate your changes?
<persia> blami_: Precisely.  Generally it's apt-get source, edit-patch ${SOMETHING}, debuild -S -us -uc, sbuild -d -A ${PACKAGE}, dpkg -i ${PACKAGE}, test
 * xnox with edit-patch hopefully dieing with fire =)
<persia> If I'm testing something that only works in a low-performance environment, a headless environment, or an environment with limited flash-only storage, there might be some scps involved.
<persia> xnox: Why?
<xnox> "just edit in place & dpkg-source --commit" instead
<xnox> persia: note "ing" as in process of, not 'dead' as in no longer used =)
<persia> Ah, yeah, perhaps we'll reach that point someday.  Since we still have some packages not updated since warty (because they have no known issues that updates would solve), I suspect it will be a long time.
<persia> Mind you, someone could teach dpkg-source --commit about the various format:1.0 patch systems :)
<blami_> persia: thing is I was asked to evaluate possibility of adding location profiles to NetworkManager. As it seems I will need to integrate a larger body of code for prototype (not one or two line fix), I would appreciate some sort of version control in process of patching.
<jtaylor> blami: you can write your patch in a clone of upstreams vcs
<persia> If you're doing something complex like that, it's probably better to do the work upstream, wearing a "NetworkManager developer" hat, rather than an "Ubuntu Developer" hat.
<jtaylor> most vcs have methods to dump your changes into a single patch for the package
<persia> Big changes done downstream tend to be hard to push upstream, as they tend to lag trunk.
<xnox> blami_: bzr branch is good for that as well =)
<pitti> sbeattie: it seems the last hardy glibc update broke postgresql; I put some analysis to bug 1088393
<ubottu> Launchpad bug 1088393 in postgresql-8.3 (Ubuntu Hardy) "New bug fix releases: 9.1.7, 8.4.15, 8.3.22" [Undecided,In progress] https://launchpad.net/bugs/1088393
<pitti> doko, jelmer: FYI, sent the samba4 patch to https://bugzilla.samba.org/show_bug.cgi?id=9503
<ubottu> bugzilla.samba.org bug 9503 in build "waf assumes that pythonX.Y-config is a Python script" [Normal,New]
<seb128> pitti, oh, thanks for that bug reference, I got bitten by that recently in another upload as well
<seb128> I wonder how many source will have the issue
<xnox> seb128: interesting. what package was that?
<seb128> xnox, py3cairo
<seb128> xnox, http://launchpadlibrarian.net/125114732/py3cairo_1.10.0%2Bdfsg-3~exp3_1.10.0%2Bdfsg-3~exp3ubuntu1.diff.gz is the quick diff I didn't when the sync failed to build
<seb128> xnox, I was a bit puzzled by why it was working before, but after reading pitti's comment that it's doko who changed the python script by a shell one things start making sense ;-)
<xnox> *sigh*
<xnox> seb128: upstream git history doesn't have pre-git history in it. but at least since Sep 2011 waf simply calls the python-config (without prepending interpreter)
<xnox> weird.
<pitti> seb128: oh, so that does affect more packages then?
<seb128> pitti, yes
<seb128> pitti, cf the url I just posted
<pitti> *nod*
<ev> xnox: you were saying last night that the hadoop charm relates to gunicorn multiple times. I can't seem to find this though - could you point me in the right direction?
<xnox> ev: ....ehm not to gunicorn. within itself only.
<ev> oh
<xnox> ev: it has e.g. worker-role, data-node-role or worker-and-data-node-role.
<xnox> ev: sorry, i probably missunderstood what you need.
<xnox> ev: and depending on what is the name of relationship it configures one or other or both "roles.
<xnox> ev: and depending on what is the name of relationship it configures one or other or both "roles".
<ev> ahh
<ev> that is indeed slightly different
<xnox> ev: you could write your own subordinate charm/relationship to gunicorn. connect to gunicorn via normal relationship & via subordinate relationship.
<xnox> ev: since you can deploy subordinate onto your whoopsie charm.
<ev> xnox: Gnuicorn is already a subordinate
<ev> gunicorn*
<xnox> I see....
<xnox> =((((
<doko> seb128, does pycairo have it's own copy of waflib?
<xnox> doko: thanks to debian ftp-masters all waf packages must be unpacked & ship their own copy of waflib. but it seems like there has been broken piece of code cargo-culted outside of waf upstream.
<StevenK> cjwatson_: In terms of that bug, I reported what I saw in terms of the traceback. Sadly, I didn't save a copy.
<seb128> doko, yes
<mdeslaur> pitti: thanks for figuring out the glibc issue, we'll look into it
<pitti> mdeslaur: cheers
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<stgraber> (missed my shift last Monday)
 * dholbach hugs stgraber
<pitti> stgraber: FYI, I'm looking at the autopkgtest one
<pitti> (sponsor queue item, I mena)
<pitti> "mean" -- TGIF!
<stgraber> pitti: ok
<rbasak> Is there any difference between a source debdiff and a run of diff against two source directories? Can I just attach a suitable diff that can be applied to a debian source tree and claim it's a debdiff, or would that be wrong?
<rbasak> (with an implied necessary -p1 the same as debdiff does)
<infinity> rbasak: Why claim it's a "debdiff" at all?  Just call it a "patch", which is what it is. :P
<pitti> rbasak: a debdiff between two .dsc is more reliable
<pitti> rbasak: but in general, no; as long as your diff doesn't have junk in it it should be fine either way
<infinity> (And I have no issues with people submitting source patches, and letting the sponsor sort out how best to apply it to the package)
<rbasak> LP (or more likely some bots) treats a debdiff slightly differently in some cases
<rbasak> infinity: thanks. Because you're getting this one :-)
<rbasak> And thank you pitti
<rbasak> (this is because I wanted to revert half of a previous commit and I used git to achieve it)
<infinity> rbasak: Oh, I am?  Lucky my.  Should I point out that I've been on vacation since yesterday? :)
<infinity> (Happy to look at whatever your patch is when I'm bored, though)
<ScottK> If you're really bored, you could look at pitti's libc6 regression in Hardy.
<infinity> ScottK: Yeah, I have a firefox tab open for that.
<pitti> infinity: or enable ddebs :) what better time to enable them than a Friday afternoon before holidays?
<pitti> *duck*
<infinity> ScottK: I suspect I know which of the sketchy security patches is the problem, but it'll take a rebuild to test.
<mdeslaur> ScottK, infinity: I'm currently looking at the libc regression
<infinity> mdeslaur: Oh, shiny.  If you find the offending patch but see no way out other than reverting it (which may be the right answer, depending on the severity of the CVE), let me know, and I can help look.
<mdeslaur> infinity: ok, cool. thanks.
<jodh> Is there a standard idiom for detecting if a library has bumped its ABI from that same libraries maintainer script? Or is it inferred from the changing version number?
<infinity> jodh: If the SOVER hasn't changed, the ABI hasn't changed, or that's a grave bug in the packaging.
<infinity> jodh: That's what SOVERs are for.
<infinity> jodh: Is there context for this, though?  Why is this something a maintainer script should need to know?
<rbasak> infinity: so this is in relation to bug 1084106 and bug 1079185. I've explained everything in those bugs. I'd appreciate you looking at it for the obvious reasons, but also that I'd like to get this resolved and landed before the holidays if possible. I think it's bad that we've not managed to land a fix sooner.
<infinity> jodh: Generally, this is something you should be detecting (and hard-failing on) during the build, not during install.
<ubottu> Launchpad bug 1084106 in The Eilt project "ARM server netboot installers broken" [Undecided,Triaged] https://launchpad.net/bugs/1084106
<ubottu> Launchpad bug 1079185 in flash-kernel (Ubuntu Quantal) "Wrong bootarg for disk with label" [High,Fix committed] https://launchpad.net/bugs/1079185
<jodh> infinity: Now we have stateful re-exec in Upstart, we can change the maint scripts for the libs it uses to say "restart upstart if our ABI version hasn't changed".
<rbasak> infinity: (and I've attached suitable debdiffs^Wpatches)
<rbasak> infinity: one final question. I noticed that your changelog entry named quantal rather than quantal-proposed. Does that mean that it's not necessary to use quantal-proposed, that we don't care, that it doesn't matter if you're specific where you dput or something else?
<infinity> jodh: You're overthinking it.  You can just have it be "telinit u" unconditionally.
<infinity> jodh: If upstart depends on libfoo5, it won't be removed because you install a new libfoo6, so the "if my ABI changed" test is meaningless.
<infinity> rbasak: The archive auto-rewrites $series to $series-proposed.
<infinity> rbasak: Or, rather, the upload processor does.
<rbasak> infinity: so should I submit SRU proposals with -proposed or without? Or don't care?
<jodh> infinity: right - thanks! ;-)
<infinity> rbasak: I think without looks nicer, but it doesn't matter, both are valid.
<rbasak> OK, thanks!
<infinity> jodh: As a side note, this should be a trigger.
<infinity> jodh: Cause restarting init several times on upgrade is silly.
<jodh> infinity: agreed. thanks for pointer.
<infinity> rbasak: I'm not sure reverting is necessary.  Let me give reproduction a whirl here, I have a pretty good idea how this should blow up.
<rbasak> infinity: thank you! I appreciate it, especially on your holidya.
<rbasak> FWIW, I've been trying on armadaxp, not panda (as I don't have my pandas set up since I moved my office). I didn't see before how that would matter, but perhaps it does.
<infinity> rbasak: Could matter a lot, if the bug only manifests when installing with ubiquity.
<infinity> rbasak: Which would be hard to reproduce on anything but omap/omap4. :P
<rbasak> Ah. I assumed d-i!
<rbasak> And that would explain it
<ricotz> infinity, hi :), i hate to bother you again, but do you have any news on the eglibc cherry-pick?
<infinity> ricotz: It's in progress.  It's pending fixing an ARM bug at the same time.
<soren> infinity: You suck at vacation.
<soren> infinity: Just sayin'.
<ricotz> infinity, do you mind to put a "preview" packages somewhere? i can build it locally too
<jpds> soren: He works until infinity.
<infinity> soren: I've noticed.
<soren> jpds: And beyond?
<soren> jpds: Or would that be overdoing it=
<soren> ?
<infinity> ricotz: When I'm done the other bits, sure.  The current source isn't buildable. :P
<ricotz> infinity, ok, thanks, feel free to ping me
<ricotz> this is really an annoying issue here causing lock-ups :\
<barry> mvo: so, xapian :)
<mvo> barry: eh
<barry> mvo: what about whoosh?
<mvo> http://whoosh.org/ - Birthplace of the International Association of Xena Studies  ?
<barry> http://pypi.python.org/pypi/Whoosh/
<barry> mvo: but your link looks like more fun :)
<mvo> barry: is it available for py3 ;) the package I have here is py2
<mvo> barry: I don't know about it, it looks interessting, I have a look. but it would be nice to know the py3 state
<infinity> barry: Pure python doesn't sound like it would be performant.
<barry> mvo: upstream claims to support py3, and yeah i see it's only py2 in raring.  shouldn't be too difficult to whip up py3 packaging
<barry> infinity: there's fast, and then there's fast enough :)
<infinity> barry: If we're replacing xapian, surely we want to replace it with something that doesn't suck on ARM.
<mvo> infinity: !python I guess
<mvo> (at all!)
<infinity> mvo: C/C++ would be nice...
<infinity> But you know how I feel about that. :P
<mvo> :)
<barry> infinity: maybe you'd like to take a crack at http://trac.xapian.org/ticket/346  -- i failed ;)
<stgraber> sounds like a good holiday project for infinity ;)
<infinity> I saw the word "swig" and was scared away.
<barry> infinity: wise
<seb128> slangasek, bdmurray, ScottK, infinity, SRU team: I would appreciate if somebody could review the nautilus fix from ritz that I just uploaded to precise quantal (https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1090344)
<ubottu> Ubuntu bug 1090344 in nautilus (Ubuntu Quantal) "Nautilus creates broken symbolic links to files located on GVFS mounts " [High,In progress]
<bdmurray> seb128: oh hey, yesterday I noticed there are two popplers in the quantal queue with different fixes
<seb128> slangasek, bdmurray, ScottK, infinity: it's a small patch and some people have been waiting on it to be rolled out for a while (but it got blocked due to organizational issues ... anyway it would be good to get it out before holidays if we can)
<infinity> seb128: I'll look at it.
<seb128> infinity, thanks
<infinity> seb128: On the condition that you talk to bdmurray about the poppler collision. ;)
<seb128> bdmurray, shrug, the queues don't make those errors visible ... I've rejected mine, please accept the old one if you can, I will reupload mine after the holidays
<seb128> infinity, ^
<infinity> seb128: Better if you reupload yours incorporating the other one, IMO.
<infinity> seb128: No point dragging it out into two SRU releases.
<seb128> infinity, right, I'm not sure I will get to that today though ... but I will try
 * infinity nods.
<barry> mvo: at the very least, i'll put together a py3 packaging of whoosh, and maybe we can give it a try and see how well/poorly it works?
<mvo> barry: yeah, indexing the app-install-data and indexing software-center agents data would be good
<infinity> Indexing, and then some sort of mock testsuite to see how well the indexes perform.
<infinity> And do it on the slowest device you can find. :P
 * stgraber looks at his beagleboard C4
<barry> infinity: i have an mx53 :)
<infinity> barry: stgraber wins.
<barry> fsvo "wins"
<infinity> Yeah.  I have a "winning" C4 too.  It's going to learn to fly any day now.
<barry> infinity: out the window at high velocity?
<infinity> barry: Something like that, yes.
<mvo> I have a rapberry pi, where does that stand in the ordering of fast<->slow?
<infinity> mvo: Right around the C4.
<stgraber> except that the C4 can actually boot Ubuntu )
<stgraber> (well, for some definition of boot that doesn't involve anything more complex than a shell)
<infinity> Except that, yes.  I believe mvo runs Raspbian on his Pi.
<mvo> yeah, its the debian thing running on it with some "crossports" from ubuntu
<infinity> seb128: Accepted.
<xnox> stgraber: i totally saw a lab of rasbianpis running mythbuntu, does that count as "can actually boot ubuntu" or not?
<infinity> xnox: It can't have been mythbuntu.
<infinity> xnox: It could have been some mythbuntu stuff recompiled, but not mythbuntu as it exists in our archives.
<stgraber> infinity: well, actually, wouldn't quantal armel sort-of vaguely work on the raspberry pi?
<stgraber> (at least for the part of main we rebuilt)
<infinity> stgraber: Yes, assuming all the packages you wanted were recompiled during the quantal cycle.
<infinity> We rebuilt all of main.
<infinity> And possibly most of mythbuntu was rebuilt in that timeframe.
<infinity> So, I suppose it's concievable that quantal/mtyhbuntu could run on v5/v6 devices.  Maybe.
 * xnox saw it running, but didn't have chance to tinker with it much they were display units.
<infinity> I wouldn't hold my breath.
<seb128> infinity, thanks
<jono> Sweetshark, are you an ubuntu member?
<jamespage> jodh, still around?
<jodh> yup
<Sweetshark> jono: hmm? no, doesnt seem so.
<jono> Sweetshark, you should apply, and then we can get your blog posts on planet
<jono> Sweetshark, ping Daniel Holbach, he will help you through the process
<Sweetshark> jono: yep.
<jamespage> jodh, am I correct in thinking that an upstart configuration that is a task
<jamespage> really has no concept of 'stop on'
<jamespage> i.e. its not long running....
<jodh> yes
<jamespage> jodh, great - thats what I though
<jono> Sweetshark, cool :-)
<Sweetshark> dholbach actually asked me to reapply for upload rights, which IIRC would make me qualify ~automatically, but it fell over the cliff. inbox zero is on the horizon, but its run quickly away from me :/
<stgraber> jodh: did you see my pm from earlier today?
<jodh> stgraber: ?
<stgraber> jodh: I sent you a private message around 14:00 UTC regarding the dbus events branch
<jodh> stgraber: too many splits - on sec...
<stgraber> ok :)
<xnox> slangasek: half of language-pack packages are actually in fact empty.
<xnox> (binary that is)
<slangasek> huh
<slangasek> seems like we should fix things to stop generating those
<slangasek> unless they're needed as dependencies of other langpacks that aren't empty?
<xnox> slangasek: i guess we need to have ability to generate 'language-pack-none' which provides 'langauge-pack-<countrycode>'
<slangasek> I don't think we should need to do that at all if they're empty
<xnox> slangasek: otherwise things like ubiquity/presseeeding/languages checks might break. Or do we have locales that don't have language packs?
<slangasek> I would expect this to be handled in language-selector
<slangasek> I'm pretty sure that from time to time we've had supported locales with no language packs
<xnox> slangasek: it's even bigger number of packages that provide <<10% of the template translation.
<slangasek> sure
<slangasek> we still want to provide those, though
<xnox> ok.
<slangasek> incomplete translation is better than none if it's the only language you speak :)
<xnox> slangasek: some are funny, the only string translated is "continue" - i guess that's all that user will be clicking =)
<slangasek> heh
 * xnox ponders to launch juju spin up hadoop cluster to tell me the most translated string. Will it be "quit" or "continue" ?
<stokachu> stgraber: when you get a chance could you review bug 633109?
<ubottu> Launchpad bug 633109 in dput (Ubuntu) "No progress bar for sftp uploads" [Wishlist,Fix released] https://launchpad.net/bugs/633109
<stgraber> stokachu: nomination approved, I'll review and upload in a minute
<stokachu> stgraber: sweet thanks man
<stgraber> np
<hrw> hi
<hrw> I have bug 1085392 which is about adding Samsung Chromebook UCM profiles into alsa-{lib,utils} in order to protect users from frying speakers (if they will try to get sound working on their own). Changes landed in Raring and I made SRU for both quantal and precise. Official procedure requires uploading SRU packages to -proposed but as alsa is in main I am unable to do that. Can someone review patches/packages and upload them for me?
<ubottu> Launchpad bug 1085392 in Cross distro support for Samsung Chromebook (ARM based) "Merge Chromebook UCM profiles into ALSA packages" [Critical,Triaged] https://launchpad.net/bugs/1085392
<hrw> http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/chromebook/SRU/ contains SRU packages
<mdeslaur> infinity: it's CVE-2012-3480.patch...still trying to figure out why though
<ubottu> Multiple integer overflows in the (1) strtod, (2) strtof, (3) strtold, (4) strtod_l, and other unspecified "related functions" in stdlib in GNU C Library (aka glibc or libc6) 2.16 allow local users to cause a denial of service (application crash) and possibly execute arbitrary code via a long string, which triggers a stack-based buffer overflow. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3480)
<mdeslaur> infinity: oh, and only on i386
<stgraber> stokachu: ah, oneiric and precise are the exact same release...
<stgraber> stokachu: so your version number is wrong as you can't upload the same version to the archive twice
<stgraber> stokachu: but I'll fix that for you
<stokachu> ah..
<stokachu> even for different releases?
<stgraber> stokachu: yeah because http://archive.ubuntu.com/ubuntu/pool is shared for all releases
<stokachu> ah ok
<stokachu> so i needed to mark precise .2 i presume?
<xnox> hrw: please update the bug report details. it's currently not in the state fit for SRU.
<stgraber> so the first one will be 0.9.6.2ubuntu1.11.10.1 and the other one will be 0.9.6.2ubuntu1.12.04.1
<stokachu> stgraber: is the 11.10.1 12.04.1 something I  need to continue to use?
<stgraber> stokachu: in such case we usually embed the release in the version, that avoids clashes if another SRU is needed later
<stgraber> stokachu: in cases where the exact same version exists in more than one release you're SRUing to, yes
<stokachu> ah ok gotcha
<stgraber> stokachu: the security team has an handy guide at: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
<stokachu> sweet /me bookmarks
<stokachu> ah i see the version examples have it listed nicely
<stgraber> stokachu: oh, another note, the package is 3.0 (native), so you can't use debian/patches
<stgraber> stokachu: I'll just apply the patch inline
<stokachu> stgraber: ah damn.. ok thanks :D
<stokachu> is it not worth doing patches for a package like this then?
<stokachu> its pretty small
<stgraber> uploaded
<stokachu> awesome! :D
<stgraber> native packages are usually just patched inline. Using quilt would require some more changes to debian/rules
<stokachu> cool, understood
<stgraber> (I vaguely wish dput wasn't a native package, but there's no point in divering from Debian for that...)
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<stokachu> micahg: i was able to get a new package pushed to my ppa for bug 1068399
<ubottu> Launchpad bug 1068399 in Precise Backports "Please backport parallel 20120422-1 (universe) from quantal" [Undecided,New] https://launchpad.net/bugs/1068399
<hrw> xnox: ok
<micahg> stokachu: ok, so, the backport from raring needs to go through quantal, as soon as you can confirm that the new version builds/installs/runs on quantal and precise, I"ll push it for you
<stokachu> micahg: cool can i just use the backport tool for quantal and test it myself?
<micahg> stokachu: wait, how was the issue I mention addressed?
<stokachu> the latest parallel doesn't exhibit the issue filed in the debian bug
<stokachu> at least from my testing
<micahg> well, unless the two were made cli compatible, it still shares a binary with another package, but doesn't conflict
<micahg> though, it's not any worse than the distro version
<stokachu> would we want to do a one-off for Ubuntu where it conflicts then?
<micahg> well, I'd like someone to talk to the Debian maintainer first about it, there might be an easy solution
<stokachu> ok
<jtaylor> there is no easy solution ._.
<hrw> xnox: I hope that new description will be fine
<hrw> s/description/comment/
<xnox> hrw: so it's still possible to fry speakers =/ oh well
<hrw> xnox: thats kernel stuff which may get fixed later
<hrw> xnox: but less users will play with mixer once they get working audio == less fried speakers
<xnox> sure.
<hrw> xnox: thanks for help
<xnox> hrw: np.
<arges> how do I get a package in the upload queue to be dequeued?
<marga> dput
<marga> dcut
<bdmurray> pitti: I've a _usr_lib_indicator-session_indicator-session-service.1000.crash file wihtout a StacktraceAddressSignature with the latest apport in quantal if that is interesting to you
<dobey> oh that reminds me
<dobey> in raring at least, it seems apport gets launched under python3, even when python2-only apps crash, and it will crash if the apport source.py file for the app tries to import stuff that's only in python2
<arges> marga, even if didn't upload it?
<Laney> the ubuntu archive doesn't support dcut
<Laney> arges: which queue?
<arges> Laney, precise queue, duplicity
<arges> Laney, i'm doing a fixed debdiff right now
<Laney> arges: so an UNAPPROVED queue. The answer is to ask an archive admin to delete it.
<Laney> s/delete/reject/
<Laney> if it's not your upload you better also explain why
<arges> Laney, ok... who should i ask at this hour on a Friday
<arges> Laney, it is my upload
<arges> but it was sponsored by somebody else
<Laney> https://launchpad.net/~ubuntu-archive/+members#active
<Laney> Someone will probably look here soon enough though, I'd imagine.
<arges> infinity, hey if you get a chance can you delete an upload for duplicity/precise ?
<NCommander> Any MIR team members awake? I have a bit of an unusual situation
<infinity> arges: You want me to reject duplicity_0.6.18-0ubuntu4 from the precise queue?
<arges> infinity, yes I have a fixed debdiff on that bug
<arges> bug  1013446 btw
<ubottu> Launchpad bug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/1013446
<infinity> arges: Rejected.
<arges> thanks
#ubuntu-devel 2012-12-15
<blami> hi, I decided to spent some time reading the new packaging guide to get familiar with bugfixing process and probably help a little making ubuntu better. I found very easy bug to fix and tried to follow steps in packaging guide. Is it normal that when I exit edit-patch it invokes dch -i automatically for me as well as local branch commit?
<vibhav> Apparently a /j #ubuntu-offtopic
<vibhav> oops
<melodie> hello
<melodie> I a working on a remix project, and I am seeking for the right method to add 2 launchers in the Desktop directory for the users. Is there a specific file in casper or a post-install script where I could insert my command ? I am using Ubuntu Mini Remix for this project.
<melodie> the question has been asked here too but no answer was provided : https://help.ubuntu.com/community/LiveCDCustomization
<melodie> here is what the project looks like once installed:
<melodie> http://meets.free.fr/debian/images/BoxBuntu.png
<melodie> this is the French version, there is also a version in English
<melodie> do someone know about making a remix ?
<melodie> I would want to discover how to do a post-install configuration
<melodie> of course looking in the web in all Ubuntu websites
<rbasak> infinity: hey, did you get anywhere with verification for bug 1079185?
<ubottu> Launchpad bug 1079185 in flash-kernel (Ubuntu Quantal) "Wrong bootarg for disk with label" [High,Fix committed] https://launchpad.net/bugs/1079185
<infinity> rbasak: I will.  Mostly cause I don't want to revert it. :P
<rbasak> infinity: thanks. I'll poke you again on Monday if you don't round to it by then. In fact, would it be reasonable to ask that we agree that if you don't get there by Monday then you will revert it? :)
<infinity> rbasak: Yep, that seems fair.
<rbasak> Thank you!
#ubuntu-devel 2012-12-16
<psusi> is there some info I can read somewhere on the procedure for managing debian packages in git?
<trijntje> Hi all, I'm trying to build localised iso images for dutch for Quantal, but for some reason all builds on amd64 fail because of an error configuring the kernel:http://pastebin.com/DUCv8j4h
<trijntje> The full build log can be found here (https://launchpadlibrarian.net/122238857/binary.log), can somebody provide me some pointers on how to resolve this?
<infinity> pitti: Is apport meant to ignore crashes until I log out and back in, or is that a bug/misfeature?
<infinity> pitti: (And how can I force it to re-scan /var/crash/ and report everything that hasn't been reported yet without logging out?)
<penguin42> infinity: Well you can give it one explicitly, i.e. apport-cli /var/crash/whatever
<infinity> penguin42: Not quite what I was hoping for, with a backlog of a dozen or so.
<penguin42> infinity: well, that's trivial in shell
<infinity> penguin42: Not the point, but thanks.
<infinity> achiang: So, that new valgrind from unstable will require some MIRs for openmpi stuff, or some removal of build-deps and (presumably) features.
<infinity> achiang: mpi-default-dev is in universe, as is its direct dep (libopenmpi-dev)
<infinity> achiang: Doing a logical revert of this bit could be the path of least resistance:
<infinity>   * Enable mpiwrap module (Closes: #565139)
<infinity>     - Add new valgrind-mpi package
<infinity>     - valgrind Suggests valgrind-mpi
<infinity> achiang: In fact, I've just done that on your behalf, and will sponsor this with your name attached to it, so you get the merge nags. :P
<infinity> achiang: Uploaded, with the following diff on top of yours: http://paste.ubuntu.com/1443561/
<infinity> achiang: Oh, and FTBFS on arm because of retaining the dh_autoreconf delta.  Oops.
<achiang> infinity: the FTBFS is why it was rejected?
<infinity> achiang: I uploaded a fixed version.
<achiang> infinity: oh, thanks!
<achiang> infinity: so no action needed from me? (i got the rejected emails so not entirely clear to me what i need to do)
<infinity> achiang: https://launchpad.net/ubuntu/+source/valgrind <-- All good now.
<achiang> derp. thank you
 * achiang only built on x86, will definitely build on armhf next time
<achiang> <= ashamed
<infinity> S'ok, I didn't test on ARM either. :P
<infinity> And, arguably, it's a bug in the Debian patches that he patches configure without patching configure.in to match.
<infinity> But not autoreconfing fixes it, so whatever.  Keeps the delta lower.
<jtaylor> valgrind upgrade closes 1077014 and 1041117
<infinity> Close away, then.
<jtaylor> we should probably backport 3.8 to precise
<jtaylor> the avx support makes it useful longer
<cjwatson> I've been gradually converting all my autotoolsy packages to dh-autoreconf after realising *just how much easier* it makes it to apply build system patches
<cjwatson> admittedly in one case this required a giant patch to upgrade from 2.13
<cjwatson> (And yeah, I realise it breaks if somebody has foolishly patched generated files - wants to be done as far upstream as possible, really)
<infinity> cjwatson: Oh, I'm all for attempts to autoreconf sanely with one's own Debian packages, just noting that it can fail miserably if Ubuntu deviates from Debian on that score.
<infinity> cjwatson: (Because, yes, as noted, we may not notice if Debian introduces a patch to the generated files)
<infinity> In this case, I noticed because the build actually failed when said patch go regenerated into oblivion, but that was just luck, really.
<infinity> s/go/got/
<achiang> jtaylor: would a valgrind backport to precise be an SRU candidate or just go into -backports ?
<jtaylor> achiang: backports
<jtaylor> probably a quite simple one
<jtaylor> no rdepends and builds unmodified
<jtaylor> wait it has rdepends o_O
<jtaylor> but probably all not problematic
<achiang> what rdepends does it have? (in the middle of eating a meal now ;)
<jtaylor> looks like programs to display its results
<jtaylor> kcackegrind eclipse codeblocks stuff
<jtaylor> I'll let it settle a bit in raring and file a request
<jtaylor> you are welcome to help testing :)
<achiang> heh
<achiang> ok
<jtaylor> thx for the update
<achiang> it would be nice for another thing i'm working on to see a newer valgrind in -backports, but now i'm weighing the effort of the rdepends too
<achiang> that probably pushes it out into the "nice to have if someone else did it" territory for my own personal bandwidth. :-/
<achiang> but yeah, i could help test
<penguin42> has something changed with X ABI over the last week ? I've just rebuilt a package with some debug added and it's complaining about ABI version mismatch, doing that last week was fine
<jtaylor> which package?
<penguin42> jtaylor: It's xserver-xorg-video-cirrus I've been debugging
<penguin42>  (EE) module ABI minor version (1) is newer than the server's version (0)
<penguin42> ah right, yes it has
<penguin42> got bumped last week
<psusi> cjwatson, why is libparted packaged in libparted0-debian1 with a dummy libparted0 depending on it?
<_abbe> Hola!
<_abbe> I've a fix for a bug report for which I've patched the sources, and generated quilt patches (courtesy: dpkg-source --commit)
<_abbe> I'm wondering how to go about submitting it
<_abbe> should i just upload the quilt patch ? or is there something else i need to follow?
<jtaylor> _abbe: which bug?
<_abbe> https://bugs.launchpad.net/ubuntu/+source/libnfsidmap/+bug/1088154
<ubottu> Ubuntu bug 1088154 in libnfsidmap (Ubuntu) "LDAP support broken in rpc.idmapd" [Undecided,Confirmed]
<jtaylor> _abbe: the usual process is to attach a debdiff and subscribe ubuntu-sponsors
<jtaylor> _abbe: for stable release update follow https://wiki.ubuntu.com/StableReleaseUpdates
<_abbe> jtaylor: debdiff ? is that a package i need to install
<jtaylor> _abbe: a debdiff is a package-patch
<jtaylor> it can be generated with the debdiff program, debdiff old.dsc new.dsc
<_abbe> oh, devscripts
<_abbe> i didn't have that installed, installing it then posting to the bugreport
<jtaylor> for a proper debdiff use dch -i, describe your changes and then build source the package
<jtaylor> with debuild -us -uc -S
<jtaylor> that will give you the new dsc
<jtaylor> you may need to install build dependencies, most conviniently that is done with mk-build-deps -ir
<_abbe> I'm actually running new .deb in production, i've done anything to control file, just fixed the bug, generate the quilt patch, and built .deb
<jtaylor> the quilt patch can be sufficient, depends on who sponsors it in the end
<jtaylor> if possible please check if it applies to debian to and submit your patch there too
<_abbe> okay, i guess i'll go with quilt then
<jtaylor> we also need to know to which release it applies to
<_abbe> it's for precise, but looking at changelog i don't see anything in quantal which fixes it
<jtaylor> please follow the wiki for an update in precise
<jtaylor> but it first needs to be fixed in raring
<jtaylor> and quantal
<jtaylor> _abbe: could it be a duplicate of bug 939232?
<ubottu> Launchpad bug 939232 in libnfsidmap (Ubuntu) "nfs mount fails and rpc.idmapd fails" [Medium,Fix released] https://launchpad.net/bugs/939232
<jtaylor> no thats fixed in precise
<_abbe> jtaylor: i searched for my bug already, and didn't find in tracker a week ago, and the one you pasted is different from what i'm experiencing
<_abbe> posted. thanks for the help jtaylor
<jtaylor> hm making functions static is problematic
<cjwatson> psusi: who knows, maybe I explained it in the changelog?  see 2.2-4
<cjwatson> archaeology (changelog or otherwise) is a fundamental skill in package maintenance :)
<psusi> cjwatson, does that mean that this was done because upstream broke abi without changing sonamever?
<psusi> cjwatson, and since upstream has moved to a new sonamever, this can be dropped now?
<cjwatson> please read the changelog and the contained bug reference, and say that you've done so, before asking further questions?
<cjwatson> (if you had, you wouldn't be asking that question)
 * cjwatson -> bed
<_abbe> yes needs proper testing, but from what i see in my setup, it didn't break anything
<cjwatson> BTW I am more than happy to deal with parted 3.x packaging once d-i is migrated away from the relevant obsolete functions
<cjwatson> and when I do that I know how to do the appropriate things with its versioning
<cjwatson> I just don't see the point of doing it knowing that it will break the installer
<jtaylor> _abbe: nfs-utils does not contain libraries, so it might be ok
<jtaylor> _abbe: but I think that change should be done upstream first
<_abbe> yes, definitely
<_abbe> but only if someone else tests it as well
<_abbe> this needs a bit of time!
<jtaylor> _abbe: it would be good if you could contact upstream about it, maybe the debian maintainers too
<jtaylor> this is unfortunately far outside my area of knowledge
<_abbe> Okay, I'll post it to upstream as well, and if they accept then file a bug report against Debian
<jtaylor> thx
<TheLordOfTime> i'd file against Debian anyways
<TheLordOfTime> but that's just me ;)
<jtaylor> I must leave now, bye
<psusi> cjwatson, the fs resize functions have been put back, but in a separate lib, so I think it just needs packaged properly, and d-i and gparted and whatever else patched to link to the new lib
<cjwatson> Not that simple.
<cjwatson> I'm sure I've explained this at some length before.
<cjwatson> I'm currently filing a Debian bug on partman-base with the details of what needs to be done.
#ubuntu-devel 2013-12-09
<lfaraone> mhall119: I submitted a merge proposal to django-openid-auth a few weeks ago. Is the project still active, slash where should I poke on that branch?
<TheMuso> c/
<apachelogger> pitti: apport uses core_pattern, getting the core dump from the kernel as argument?
<pitti> Good morning
<pitti> apachelogger: not as argument, the core dump gets fed into stdin; there are some macros like %p (pid)
<apachelogger> ah
<pitti> %s (signal number), %c (core limit)
<apachelogger> I see
<apachelogger> pitti: after poking around a bit I think that we'll end up having the core dump handled by apport anyway. the kde crash handler acts on the in-process signal of the crashing application so we don't have access to a core dump at that point. what I imagine right now is triggering a core dump after kde's crash handler (currently we exit()) and have apport itself handle the report business.
<pitti> apachelogger: ah, if you do that you should just re-raise() the signal in the sighandler
<pitti> apachelogger: that's the usual way that we do with firefox or LibO
<apachelogger> raise(sig);
<apachelogger> yeah, testing that right now
<pitti> apachelogger: but I guess you want the KDE crash handler UI, right?
<pitti> apachelogger: from that, can you somehow see (in the coredump or whereever) if the user agreed to report the issue?
<apachelogger> that's the plan
<pitti> apachelogger: oh, I guess you can conditionally re-raise() only if the user agreed to
<apachelogger> oh, that's a good idea
<pitti> apachelogger: then you can call /usr/share/apport/whoopsie-upload-all from an upstart job to process the initial .crash and create the .upload stamp
<pitti> apachelogger: we do that in our CI machinery to auto-upload crashes during testing
<pitti> apachelogger: we can discuss the details of that, but I think these are  the ready-made building blocks which ought to work for you
<pitti> apachelogger: then we'll only report to whoopsie for reports that the user agreed to send, and you don't get a second UI
<pitti> apachelogger: do you have a plan what to do for non-signal crashes? (package installation failures, python, etc.)
<apachelogger> they go through apport, kde's kcrash handler only applies to actual kde applications
<pitti> apachelogger: right, I meant in terms of UI
<apachelogger> apport-kde
<apachelogger> for UI consistency reasons I will probably have to fiddle with that a bit as well
<penghuan> cjwatson: ping
<penghuan> cjwatson: Can you take some time to have a look at my merge proposal about  https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/195712
<dholbach> good morning
<OdyX> tkamppeter_: Hi. Did you see http://bugs.debian.org/731658 ? It would be nice to avoid using PATH_MAX globally. Your advice on the patch would be nice too...
<ubottu> Debian bug 731658 in cups-filters "cups-filters FTBFS on kfreebsd, varying values of PATH_MAX" [Serious,Open]
<brendand> does anyone know why my qt plugin (with suffix .so) might have cpython-33m-x86_64-linux-gnu inserted into its name?
<apachelogger> pitti: to not discriminate against !kapplications I think we shouldn't simply assume that every report was actually accepted by the user. instead I am thinking about having specific stamps set by the kde crash handler with the suffixes .drkonqi-accept or .drkonqi-reject. former would lead to UI-less upload, latter would discard the entire report as the user didn't want an automatic report. reports without either will bring up the apport UI. any
<apachelogger>  opinion on possibly supporting this by apport in general? or should I simply limit support for ui-less accept/reject to kubuntu tools?
<pitti> apachelogger: no, you shouldn't assume it; my thought was that the signal handler would know whether drkonqui accepted the crash or not, and only re-raise if it was accepted
<apachelogger> hm
<apachelogger> pitti: and write a .upload file immediately I guess?
<pitti> apachelogger: no, that won't work; you need to add package and other information to it, i. e. call sr/share/apport/whoopsie-upload-all or do the equivalent steps
<pitti> "usr/..."
<apachelogger> right, that's why I was thinking about those additional stamps
<apachelogger> as we need to set the reports apart as already-approved or already-rejected
<pitti> apachelogger: where would you create the stamps, if not in the signal handler?
<apachelogger> pitti: in the signal handler :P
<pitti> apachelogger: then skip the stamps and just don't raise() if  the user doesn't want to report
<pitti> apachelogger: that saves you needlessly calling apport and creating the .crash (which is quite CPU intense), and the stamp handling
<apachelogger> true, we'd still need and approved/accept stamp though
<pitti> why?
<pitti> oh, for non-KDE crashes
<apachelogger> aye
<pitti> well, that stamp is .upload
<apachelogger> -> [11:00:18] <apachelogger> pitti: and write a .upload file immediately I guess?
<apachelogger> that's what I meant there ;)
<pitti> apachelogger: for that, can you teach drkonqui to either call a few python functions or call a script which adds the necessary information to the .crash?
<pitti> argh no, at that point the .crash doesn't even exist yet
<pitti> meh
<apachelogger> I know, it's headache material ^^
<pitti> we might put that into whoopsie itself, it could do the information collection when needed
<pitti> w/when/if/
<apachelogger> pitti: that'd be cool
<ev> pitti, apachelogger: branches welcome :)
<apachelogger> ev: oh, btw, how does the metrics stuff work?
<ev> apachelogger: which metrics stuff is this?
<apachelogger> ev: com.ubuntu.WhoopsiePreferences.SetReportMetrics
<seb128> xnox, https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1259111 is probably yours (new since your uploaded on friday according to e.u.c)
<ubottu> Ubuntu bug 1259111 in usb-creator (Ubuntu) "/usr/bin/usb-creator-gtk:UnboundLocalError:<lambda>:_device_changed:_udisks_obj_added:_udisks_partition_added" [Undecided,New]
<xnox> seb128: argh =) thanks.
<seb128> yw ;-)
<ev> apachelogger: that's not wired up to anything yet
<apachelogger> I see
<xnox> seb128: i wonder how come i am not subscribed to usb-creator bugs.... now subscribed
<ev> apachelogger: https://wiki.ubuntu.com/ErrorTracker#Invitation_for_metrics_collection
<seb128> ev, we have been consistently tackling highest reports for 13.10 since release, and they are dropping off the list, it's weird that the curve doesn't reflect more that...
<apachelogger> ev: I'll hide the UI option for the time being then
<seb128> xnox, seems like a good idea if you are the maintainer nowadays ;-)
<Laney> some cool guy wrote a script to automatically subscribe you to packages you upload
<seb128> does it unsubscribe you have <n> days?
<Laney> yep
<seb128> cool
<seb128> how is that called/where is it?
<Laney> cron
 * Laney tries to remember where it is
<xnox> Laney: i found that it would randomany unsubscribe my custom subscriptions....
<ev> seb128: we need to re-run the calculation to generate that graph, I suspect. Adding something into Asana to track this
<seb128> ev, thanks
<Laney> you didn't report the bug?!?!?!
<xnox> Laney: well, i didn't backup my existing subscriptions, now did I?! =)
<Laney> it's supposed to not subscribe you if you already are
<Laney> ho hum
<xnox> Laney: where was that script again? i clearly haven't used it since the incident....
<Laney> lp:~laney/+junk/lp-subscribe-uploads
<Laney> it was fairly fire and forget, but I'd still merge patches / fix bugs
<Laney> bah
<Laney> screen has started segfaulting
<cjwatson> penghuan: done
<penghuan> cjwatson:thx
<seb128> Laney, let's maybe ask here?
<seb128> doko_, what's the rational for changes like
<seb128> -	dh $@ --with autotools_dev
<seb128> +	dh $@ --with autoreconf
<seb128> (Laney was trying to get that harfbuzz diff to Debian but pochu wants to understand what it's fixing/the rational)
<cjwatson> seb128: does a better job of handling new ports - there's a libtool fix that that picks up
<seb128> cjwatson, do we have a description of "better job" for those who want to understand want issue it fixes in practice?
<seb128> e.g a link to an email/wiki/bug reference?
<cjwatson> man dh_autoreconf ? :-)
<Laney> mmm, that fix doesn't appear to be in Debian
<cjwatson> seb128: dh_autotools-dev_* only updates config.guess/config.sub
<seb128> cjwatson, fair enough, thanks ;-)
<cjwatson> seb128: dh_autoreconf does a full update of all the autotools output - so it also picks up bug-fixes in other parts of that toolchain
<seb128> cjwatson, thanks, that's the sort of explanation I was after, and it makes sense ;-)
<cjwatson> seb128: dh_autoreconf is more complete, but it also requires more care, because it's often the case that packages' autotools source requires some massaging before it can be regenerated
<seb128> yeah, I know about that :p
<Laney> We were more after the specific rationale for this batch of changes; the libtool hint was enough
<cjwatson> seb128: dh_autoreconf is a superset of dh_autotools-dev_* only if libtool is used (I think that's right) - there are some edge cases that are more complicated, so it's definitely not a "drop it in automatically" kind of thing
<seb128> cjwatson, thanks
<seb128> we have been using dh-autoreconf for all the desktop stuff for a while
 * cjwatson nods
<seb128> (especially when we had launchpad integration changes that needed to update configure and other stuff)
<seb128> I was just unsure how to "sell" it to others/not familiar enough with dh_autotools-dev to explain the difference
<seb128> as Laney said, we have what we need to forward that fix to Debian ;-)
<xnox> cjwatson: slangasek: any updates re https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006 branches ?
<ubottu> Ubuntu bug 1184006 in sysvinit (Ubuntu Saucy) "wrong conffile prompt for /etc/default/rcS when UTC=no" [High,In progress]
<Laney> it was more "why specifically is this interesting for this package now"
<Laney> not "why is dh-autoreconf good in general?"
<xnox> Laney: to get libtool goodness =)
<Laney> got it
<Laney> ta
<cjwatson> xnox: not something I've had time to look at for some time
<cjwatson> (nor expect to before EOY)
<xnox> cjwatson: in that case no outstanding merge proposals for ubiquity, upload time? (it has quite a few changes staged)
<Laney> xnox: want to review the remaining libtimezonemap changes? :-)
<cjwatson> xnox: up to you, I wasn't touching that due to the note at the top of the changelog ...
<xnox> cjwatson: yeah, that's all fixed now.
<xnox> Laney: =)
<Laney> I did a chunk but there's still a few left
<Laney> changes what are more relevant to ubiquity's use of it
<xnox> doing a package merge "cross-cross merge encountered" => please work it all out =)))
<xnox> cjwatson: do you mind if I do a debhelper merge, or would you rather do it? (i have a dep-wait on 9.20131104 for debian bug #728620)
<ubottu> Debian bug 728620 in debhelper "Update dh_installemacsen etc. for emacsen policy as of emacsen-common 2.0.5" [Normal,Fixed] http://bugs.debian.org/728620
 * xnox goes to check if emacsen-common is merged.
<xnox> yeap, we do have the new enough emacsen.
<cjwatson> xnox: go for it
<xnox> ack.
<tkamppeter> OdyX, this with PATH_MAX was simply overlooked when merging foomatic-rip into cups-filters. I will take your patch upstream. Thanks for the patch.
<tkamppeter> OdyX, fixed upstream, BZR rev. 7140.
<mlankhorst> how often do packages move from NEW to DONE?
<cjwatson> no fixed schedule, depends on human attention
<cjwatson> assuming you're asking about mesa, accepted now
<mlankhorst> ah
<mlankhorst> i was curious since arm64 was accepted
<cjwatson> mlankhorst: I assume it was just the first one in place
<cjwatson> mlankhorst: oh, no, it's because arm64 doesn't build libxatracker*
<cjwatson> and those were the new binaries
<mlankhorst> ah right, ofc :)
<cjwatson> wait, what?  sbuild is seriously in universe?
<cjwatson> that I did not expect
<tseliot> didrocks: hey, bbswitch is now ready for promotion (bug 1255583)
<ubottu> bug 1255583 in bbswitch (Ubuntu) " [MIR] Main inclusion request for bbswitch" [Medium,Incomplete] https://launchpad.net/bugs/1255583
<didrocks> tseliot: thanks, please just reassign to me, on other stuff, will do later on
<tseliot> didrocks: sure, thanks
<mlankhorst> doko: hey, can you check if needing to suppress building gallium and egl is still needed? We're no longer carrying the patches in 10.0 that broke things
<doko> mlankhorst, I'd like to wait for a fast reliable native system. don't want to setup my cross hacks again to build this
<mlankhorst> ok
<mlankhorst> doko: but we already build arm64 right? you could just test the package from debian-experimental on arm64
<OdyX> tkamppeter: great, thanks. I hope it won't break anything then. Uses of PATH_MAX should be replaced though, see http://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html ...
<alkisg> highvoltage: /etc/xdg/menus/applications.menu is a mess in Trusty, the gnome-session-flashback is ruined with that. If I replace it with the version from Precise, then it's fine.
<alkisg> ...is that also used in gnome-shell? Can we ship the version from Precise in order to have sane menus?
<alkisg> I could create a wrapper package e.g. gnome-session-flashback-oldmenus that dpkg-diverts it, but wouldn't it be better to solve it upstream, or at least in debian?
<alkisg> (or stgraber ^)
<seb128> alkisg, what's the issue exactly? and no you can't put the old content back, open an upstream bug if GNOME screwed it up for other desktops, they did some tweaking for gnome-shell I think
<alkisg> seb128: the new menu structure splits the menus in a non-sensible way, half of the things that were in accessories have now gone to utilities,
<seb128> mardy, hey, did you see bug #1258578? seems a new issue in trusty with the signon update, it's one of the most reports errors there
<ubottu> bug 1258578 in signon (Ubuntu) "/usr/bin/signond:4:QListData::shared_null:qDeleteAll:qDeleteAll:SignonDaemonNS::SignonSessionCore::destroy:SignonDaemonNS::SignonDisposable::destroyUnused" [Undecided,New] https://launchpad.net/bugs/1258578
<alkisg> there's a sundry submenu, a full "others" menu... and some translations are the same, so e.g. in greek I see two same entries for "Accessories" and "Utilities", "ÎÎ¿Î·Î¸Î®Î¼Î±ÏÎ±" for both of them
<alkisg> The settings submenus are all wrong.. too many things are wrong to list them in order
<alkisg> I tried to find the logic behind the new organization, but I couldn't find any, and I don't use gnome-shell nor unity, so I don't know if those entries make more sense there...
<alkisg> (logic ==> I meant the rationale, via googling...)
<alkisg> The .desktop files in /usr/share/applications are more or less unchanged, it's just that /etc/xdg/menus/applications.menu file that messes up everything...
<seb128> alkisg, you are using trusty? https://git.gnome.org/browse/gnome-menus/commit/?h=gnome-3-8&id=b89833d78a9ab43f1fea1d01cd233551d47f08a7 was supposed to fix the "others" category issue
<alkisg> Yup I'm using trusty, let me check the bug report, but the "others" submenu is only 5% of the problems there
<seb128> alkisg, you should open upstream gnome-menus bugs reports for each of the specific issues you have, you might want to open launchpad bugs corresponding to those as well
<seb128> but we are not going to revert upstream work randomly
<alkisg> seb128: thanks, will do, but could you help me a bit to understand the rationale? Are those menus used for gnome-shell nowadays?
<seb128> we need to understand the changes, why they are there and what we can do that accomodate gnome-shell uses and other desktops as well
<seb128> alkisg, https://git.gnome.org/browse/gnome-menus/commit/?h=gnome-3-8&id=36d5d699d7d4193a1b3d84777566466326f78b19
<seb128> read https://bugzilla.gnome.org/show_bug.cgi?id=694131 I guess
<ubottu> Gnome bug 694131 in layout "New directories for use in app pickers" [Normal,Resolved: fixed]
<alkisg> Thanks, I think that last one contains most of the changes
<alkisg> Hehe, "Uhm, except for the first patch, the series was not actually meant to be committed literally."
 * alkisg wonders if there's any way to dump the effective menu layout to attach it to bug reports
<JordiGH> How do I get the debian/control of this package? https://launchpad.net/~octave/+archive/unstable/+packages
<alkisg> Is mate-desktop going to be available in Trusty? Maybe they've already solved this problem there...
<JordiGH> I mean, other than adding it to my apt.sources and doing apt-get source.
<pitti> jibel: download and unpack https://launchpad.net/~octave/+archive/unstable/+files/octave_3.7.7-0%7Eppa1%7Eraring1.debian.tar.gz
<pitti> sorry
<pitti> JordiGH: ^
<pitti> jibel: wrong nick, sorry
<JordiGH> Man, I wish there was a web interface to it like packages.debian.org :-/
<JordiGH> pitti: Okay, thanks.
<sladen> alkisg: /usr/lib/libdbusmenu/dbusmenu-dumper
<pitti> JordiGH: there (kind of) is for ubuntu packages, but not for PPAs
<alkisg> sladen: thanks, I installed libdbusmenu-tools, will check that in a while.
 * alkisg waves...
<seb128> sladen, he was asking about xdg .desktop menus, I doubt that's the right tool...
<JordiGH> pitti: Alright, thanks for your help.
<mhall119> lfaraone: I think jamesh is still running that project, but I can take a look at the mp
<lfaraone> mhall119: awesome, thanks!
<mhall119> lfaraone: have a link to the MP?
<lfaraone> mhall119: https://code.launchpad.net/~lfaraone/django-openid-auth/custom_response/+merge/195845
<mhall119> lfaraone: can you add tests that check the value of openid_response in render_failure?
<lfaraone> mhall119: sure.
<mhall119> thanks lfaraone
<bdmurray> seb128: were you going to do the merging / upload of the apturl fix for bug 1050826?
<ubottu> bug 1050826 in apturl (Ubuntu) "apturl-gtk crashed with AttributeError in parseArgs(): 'str' object has no attribute 'decode'" [High,Triaged] https://launchpad.net/bugs/1050826
<seb128> bdmurray, hey, yes, I just got a busy monday and didn't get to do it yet ;-)
<seb128> bdmurray, thanks for the review!
<hallyn_> is there a simple way to get do-release-upgrade (for a test) to ignore the fact that some packages are unauthenticated?
<bdmurray> hallyn_: I don't think so
<hallyn_> drat
<bdmurray> hallyn_: what exactly are you trying to do?
<hallyn_> test whether a candidate qemu for trusty woudl cleanly upgrade in lts-to-lts
<xnox> hallyn_: i do schroot into precise & add sources as appropriate and do a dist-upgrade.
<rbasak> hallyn_: you can just update sources.list and dist-upgrade I think
<xnox> hallyn_: also you can run piuparts to do automated lts->lts upgrades/downgrades/install/remove/reinstall and a bunch of other tests.
<xnox> hallyn_: piuparts can work with pbuilder tarballs or schroots, if I remember correctly.
<hallyn_> rbasak: no, but i can ctrl-z and re-insert my custom entries.  that bit is fine :)
<hallyn_> piuparts?  i've heard of it...
<hallyn_> sounds like maybe what i need
<hallyn_> xnox: is there a good wiki link showing simple usage?
<xnox> hallyn_: it's running automatically against the whole debian archive and reports problems to PTS.
<xnox> hallyn_: https://piuparts.debian.org/
<xnox> hallyn_: and links from there https://piuparts.debian.org/doc/README_1st.html https://piuparts.debian.org/doc/piuparts.1.html
<hallyn_> well, it does seem to be workign ok though (just drops to complaints about trusty packages not installed)
<hallyn_> xnox: ok, thanks.  i'll definately have to add that to my repertoire
<hallyn_> xnox: how do you run it for lts-to-lts upgrades?
<xnox> hallyn_: i can't remember for sure, but the semantics was to specify the base release (e.g. precise) and the target releases, or even a just compiled binaries.
<xnox> hallyn_: it was a long time since i used it last =) i know I am bad.
<hallyn_> xnox: oh - np, i just figured you used it daily.  thanks!  i'll figure it out
<slangasek> xnox: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006> none, sorry; haven't had time to straighten out the bugs cjwatson pointed out
<ubottu> Ubuntu bug 1184006 in sysvinit (Ubuntu Saucy) "wrong conffile prompt for /etc/default/rcS when UTC=no" [High,In progress]
<slangasek> xnox: if you're merging debhelper, please take care to preserve the versioned dep on sysv-rc that joeyh dropped recently, as it still applies for precise upgrades in Ubuntu
<xnox> slangasek: thanks.....
 * xnox goes to reupload debhelper i think.
<mlankhorst> hm, why is mesa still in -proposed ? (it has a new binary libxatracker2)
<xnox> slangasek: looks good? http://paste.ubuntu.com/6546703/
<xnox> darn, wrong DEB_NAME
<slangasek> xnox: it looks familiar, and if it's a straight revert I trust that it's fine :)
<xnox> ack.
<cjwatson> trying: mesa
<cjwatson> skipped: mesa (68 <- 160)
<cjwatson>     got: 26+0: i-26
<cjwatson>     * i386: kubuntu-active, xserver-xorg-video-all, xserver-xorg-video-vmware
<cjwatson> mlankhorst: ^-
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<mlankhorst> oh right
<mlankhorst> fixed :p
<jibel> slangasek, could you review the MP attached to bug 1257305 ? I think it is the only change between the version in the distro and upstream so it is probably better to directly release latest upstream revision.
<ubottu> bug 1257305 in sbsigntool (Ubuntu) "Wrong efivars magic in sbkeysync" [High,Triaged] https://launchpad.net/bugs/1257305
<slangasek> jibel: I've seen it, and the change is obviously correct; but I'm more concerned about getting sbsigntool upstream sorted out so we can get proper releases
<slangasek> jibel: if you want to upload it be my guest
<jibel> slangasek, thanks but I cannot upload :)
<brendand> hi, i'm trying to build a package containing a qt plugin whose target is 'libgui-engine'
<brendand> this builds as 'libgui-engine.so'
<brendand> but when i install the package, it turns into 'libgui-engine.cpython-33m-x86_64-linux-gnu.so'
<brendand> i can't figure out how python comes into it
<xnox> brendand: did you install the .so into /usr/lib/python* ?
<slangasek> jibel: ok.  are you ok to have this wait until I have a chance to get a poper upstream release sorted?
<slangasek> jibel: (which will be a couple weeks at least)
<brendand> xnox, no it's installed to /usr/lib/checkbox-gui/plugins
<brendand> xnox, i think i just realised :/
<brendand> xnox, for some reason i put ${python3:Depends} in the binary packages Depends
<xnox> brendand: don't do that =) or do override_dh_python3 and use exclude to exclude that path and/or that package
<xnox> such that they are untouched.
<brendand> xnox, well having it serves no purpose so i remove it :)
<brendand> xnox, dumb stuff that creeps in thanks to the evils of Ctrl+C/V
<slangasek> Laney: I hear you may know something about libwebkitgtk being broken; once it's fixed, can you let me know and/or give back gnome-online-accounts for building?
<cjwatson> slangasek: I notice that seb128 has an update building at the moment
<Laney> slangasek: I expect it's just du
<Laney> that
<slangasek> ok
<Laney> uninstallable due to transition etc
<slangasek> xnox: do you know anything about the jquery/flot stuff on http://package-import.ubuntu.com/status/ ?  It is not well-behaved and makes my browser angry
<xnox> slangasek: with my limited W3C skillz, it appears to me entirely unused?!
<slangasek> hmm
<slangasek> isn't it used to create the graphs at the bottom of the page?
<xnox> slangasek: also it looks fine in my web-browser.
 * xnox uses Google Chrome
<slangasek> I didn't say it doesn't /look/ ok :)
<slangasek> but it gets itself into some stupid busy loop (in firefox) that eventually causes firefox to kill it as a runaway js process
<xnox> slangasek: ouch, that graph is sure a good way to generate..... every client does it, instead of server side.
<slangasek> xnox: and it is used, <div id="queue_graph" style="width:600px;height:300px"></div>[...]$.plot($("#queue_graph"), [[ [...]
 * xnox ponders to write a javascript bitcoin miner and infect parked domains with it.
<xnox> slangasek: yeah spotted it now.
<xnox> slangasek: i can look into splitting a graph into a separate page, would that work?
<slangasek> xnox: bitcoin miner> hahaha
<slangasek> xnox: sure, splitting it would work
<shadeslayer> I'm curious as to what's the long term plan with logind
<shadeslayer> will Ubuntu maintain logind with upstart integration? ( I'm mostly interested in the dbus interfaces )
<shadeslayer> or will upstart have it's own user session namespace ?
<xnox> shadeslayer: what do you mean? logind as a daemon is here to stay, as is with compatible dbus API as everywhere else.
<shadeslayer> xnox: well, that's my question, will logind be dropped in the future or is it going to stay
<xnox> shadeslayer: we do have a shim in place, but that should be mostly opaque. If there bugs, file them on launchpad as usual.
<xnox> shadeslayer: lennart didn't write a replacement for logind yet, until that happens it's here to stay.
<shadeslayer> xnox: there's just a minor bug, some KDE applications ask systemd for the systemd version, which isn't implemented on the dbus interface in ubuntu
<xnox> shadeslayer: (remember that logind is rewrite of consolekit)
<xnox> shadeslayer: those applications are wrong, they should be checking for presence of the _logind_ not of _systemd_.
<xnox> shadeslayer: loads of packages were fixed by pitti, and the upstrem "sd_*" static files were updated as well.
<shadeslayer> xnox: the idea I got was to check if the version is greater than a certain version to check if the interface was implemented
<xnox> shadeslayer: at the time all applications were doing a check " if systemd; then do logind stuff; fi" instead of "if logind; then do logind stuff; fi"
<xnox> shadeslayer: one should check the interface presence, rather than version numbers.
<shadeslayer> *nod*
<xnox> shadeslayer: i believe all compatible interfaces are implemented, check with e.g. d-feet if the needed interfaces are implemented.
<shadeslayer> I'll try and refactor the code that way
<xnox> shadeslayer: do you have example / package? you could ask pitti as he did write/upstream a lot of patches where bad assumptions were made upstream.
<slangasek> introducing, duck typing for dbus
<shadeslayer> xnox: sure, kde-workspace, powerdevil checks for systemd version
<xnox> shadeslayer: or he can better consult which interfaces are available.
<xnox> shadeslayer: please open a bug about it & subscribe myself and pitti to it. I'm getting annoyed with this "logind is not a freedesktop specification"
<shadeslayer> xnox: actually I'm already fixing it :)
<xnox> shadeslayer: good, please upstream it as well =)
<slangasek> Laney, cjwatson: the update being built is for which package?
<shadeslayer> ofcourse, already had a discussion with upstream, and the question that came out was "Will ubuntu be sticking to logind or will they be implementing something of their own, in which case it makes sense to write a ubuntu specific backend"
<shadeslayer> well, s/ubuntu specific/upstart specific/
<slangasek> shadeslayer: writing a different interface would be silly; we deliberately made logind work on upstart
<slangasek> and even if the logind code base became unmaintainable on top of upstart, there's no reason to implement a distinct API
<shadeslayer> *nod*, thanks for that
<mcpierce> Hi, all. Looking for some guidance on becoming a Ubuntu packager. I've got experience with packaging on Fedora.
<Noskcaj> When can i expect http://qa.ubuntuwire.com/bugs/rcbugs/ to have trusty listed? Is there anything i can do to speed it up?
<mlankhorst> mesa 10 in trusty soon, enjoy
<Laney> slangasek: webkitgtk
<slangasek> Laney: ah, thanks; somehow I thought the problem was in webkit itself
<Laney> hrm, that should be removed
<Laney> I thought Seb took care of that; will sort it out in the morning
<Laney> (webkitgtk supersedes it)
<slangasek> ok
<hallyn_> could someone push the sru fix for https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1243403 into saucy's qemu?
<ubottu> Ubuntu bug 1243403 in qemu (Ubuntu Saucy) "Upgrade from qemu 1.0+noroms-0ubuntu14.11 fails" [High,Fix committed]
<stgraber> hallyn_: I'll do an SRU round in a few minutes. (unless infinity is planning one, I believe it's his SRU day)
<hallyn_> stgraber: thx
<slangasek> xnox: so alternatively, we could axe the 'refresh' at the top of http://package-import.ubuntu.com/status/, which would stop the script from trying to graph n million data points every 10 minutes
<slangasek> utlemming: hmm, your mail suggests that UEFI support comes in the form of a separate disk image - how come?
<utlemming> slangasek: UEFI and BIOS/GPT come together
<slangasek> why is that an additional image, instead of changes to the existing image?
<slangasek> an image can have both a GPT and an MBR partition table on it
<utlemming> a couple of reasons
<utlemming> the biggest is that we wanted to preseve root being the first partition. Hybrid images make the difficult
<utlemming> the second reason is that there is the question of supporting a hybrid mbr/gpt image
<utlemming> after consulting with cjwatson, he strongly advised against going that route
<slangasek> hmm, ok
<utlemming> for 14.10, we are going to talk about making the UEFI image the cloud image default and droping the BIOS/MBR disk image
<slangasek> xnox: the straightforward proposal: https://code.launchpad.net/~vorlon/udd/no-auto-refresh/+merge/198320
<xnox> slangasek: ack. will pull and deploy it tomorrow. afk at the moment. =)
<slangasek> ;)
<infinity> awe_: Why are we adding -dbg packages in Ubuntu deltas when we prefer ddebs? (urfkill, in this case)
<infinity> cyphermox: ^
<cyphermox> infinity: useful in a ppa
<cyphermox> if you feel we really shouldn't ...
<cyphermox> I'm sending that to debian too btw
<infinity> cyphermox: If it's going to end up in Debian too, fine.  But it seems like a silly delta for us to carry when we'd really rather get rid of all -dbg packages, not have more. :)
<cyphermox> infinity: sure :)
<cyphermox> I don't feel strongly for it, though it does tend to be useful when you build things in a PPA
<infinity> You can get PPAs with ddebs.
<cyphermox> you can?
<infinity> (To be fair, not a default option, cause we don't want all PPAs having massive ddebs in them)
<cyphermox> ah
<cyphermox> a matter of asking the right magician
<awe_> cyphermox, we probably should fix ofono too
<infinity> Anyhow, if you're pushing this delta to Debian and it will, thus, no longer be a delta, I'm fine with processing these from binNEW.
<cyphermox> awe_: you mean re: dbg packages?
<awe_> yes
<cyphermox> infinity: I'll strongly suggest it to the debian maintainer.
<cyphermox> (for what my opinion really matters)
<cyphermox> awe_: you mean removing them?
<infinity> This does remind me that I need to revisit the Debian ddeb proposal, apply some sanity to it, and get them moving in the right direction.
<infinity> So we can make -dbg a thing of the past everywhere.
<cyphermox> infinity: happy to help. I need more work in Debian to eventually do NM process.
<awe_> cyphermox, I actually don't know enough about the problem to speak intelligently about it.  However if getting rid of -dbg packages is a goal, then we should probably do so for ofono too
<geofft> infinity: out of curiosity, is that doable without discarding binary uploads, which seems to be a political quagmire?
<awe_> right now I'm neck deep in modem power code
<cyphermox> awe_: just pull the plug when you feel like it
<infinity> awe_: Getting rid of them is a long-term goal, not something we should carry a delta against Debian for, it's not worth the merging effort.
<cyphermox> awe_: or I'll fix the debian side of things for ofono
<infinity> awe_: Some day, we want them gone from both Debian and Ubuntu, and ddebs to rule the world.
<awe_> ok
<cyphermox> I think it might already be a delta from us
<awe_> yea, pretty sure it is
<infinity> geofft: It's doable with binary uploads.
<awe_> ( ie. we added the -dbg package for ofono )
<infinity> geofft: Though I'm firmly on the "source uploads forever" side of that debate too. :P
<geofft> By asking folks to upload ddebs too?
<cyphermox> I'll look, and apply the right thing if needed
<infinity> geofft: They'd be an artifact of the build process and referenced in .changes, so nothing extra to do.  No different than a package that produces both debs and udebs today.
<geofft> Neat.
#ubuntu-devel 2013-12-10
<smoser`> anyone else having trouble using offlineimap or alpine with imap recently ?
<smoser> i'm using both of those, configured with imapssl (alpine: mail.brickies.net/user=smoser@brickies.net/ssl/novalidate-cert)
<smoser> offlineimap is similar configured (i have it actually expects a configured cert)
<smoser> but i think something in the past 4 days caused issue
<smoser> here is my recent apt history.log http://paste.ubuntu.com/6548782/
<smoser> both gnutls and libssl wer updated in the queestionalbe time frame.
<smoser> infinity, or mdeslaur ? you 2 are recently touched on those two (with doku) having a change also to libssl
<sarnold> smoser: mdeslaur recently turned tls 1.2 back on in our openssl packages
<sarnold> smoser: not everything is prepared to negotiate tls 1.2 and fail to handshake entirely
<smoser> well it would appear that i have 2 things that fail. i'm getting connection reset by peer.
<smoser> sarnold, do you have a suggestion ?
<smoser> shal i file a bug on openssl ?
<smoser> (i think i might be having deja vu on this)
<sarnold> smoser: does offlineimap or alpine let you ask for tls1.1 or tls1.0 in their configs? that'd be my first shot..
<smoser> i dont think so.
<smoser> maybe though. i'll lok
<smoser> http://docs.offlineimap.org/en/latest/MANUAL.html
<sarnold> smoser: openssl's s_client also supports -tls1_2 -tls1 etc., it might be handy to debug if the clients don't support it easily...
<smoser> sarnold, i dont know that i would have time to devote to debugging that. its not something i have any experience in.
<sarnold> smoser: here's the bug tracking turning tls 1.2 back on: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1257877
<ubottu> Ubuntu bug 1257877 in openssl (Ubuntu) "TLSv1.2 enabling tracker bug" [Undecided,Fix released]
<sarnold> smoser: I tried to run: openssl s_client -host mail.brickies.net -port 443     to dump a pile of debugging information; try it out, add -tls1_2 or -tls1_1 or -tls1 to the command line and see if the output changes from run to run
<smoser> sarnold, unless you object i'll at least comment in that bug to my issues
<sarnold> smoser: no, please do, it'd be nice to collect experiences. (I don't know if that's the best place, but I can't nominate anything better. :)
<smoser> sarnold, commented. fwiw, i'm pretty sure it is using port 993
<smoser> not 443
<smoser> yeah, duh :)
<smoser> silly me. 993 makes sense in that /etc/services says 'imaps' but you made me question myself.
<smoser> hope that did'nt sound rude. i iddn't mean to be.
<smoser> thanks for your help.
<sarnold> smoser: haha, no, not at all, chalk that up to my just being happy the offline imap folks had the port listed to "save me the time" from looking it up myself. :) heh.
<sarnold> smoser: thanks
<mdeslaur> smoser: yep, looks like your mail server dies when something tries to connect using tlsv1.2
<mdeslaur> smoser: looks like xnox has a patch available to be able to set the ssl version for broken servers...see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707252
<ubottu> Debian bug 707252 in offlineimap "Unable to connect to certain IMAPS servers requiring SSL3" [Normal,Open]
<pitti> good morning
<pitti> shadeslayer: I remember some bug about adding the "version" thing to -shim, but it's tricky either way -- if we provide too much, upstream projects might be tricked into thinking that they are actually speaking to systemd pid 1?
<hyperair> looks like gst1.0's bpmdetect element is hanging, while it works fine in gst0.10. does anyone know how to debug this issue?
<dholbach> good morning
<xnox> mdeslaur: smoser: honestly use git master from https://github.com/OfflineIMAP/offlineimap the release was pushed out but not uploaded into debian yet.
<xnox> infinity: \o/ \o/ \o/ =))))
<Laney> O_O
<xnox> Laney: eglibc 2.18 uploaded into experimental =))))))
<Laney> oh right
<Laney> what's in that that's worthy of such joy? :P
<xnox> Laney: thus unblocking libnih & upstart on kfreebsd among with many other things.
<Laney> neat
<xnox> and i totally thought i'm on #debian-devel =))))
<RAOF> Oooh, neat.
 * xnox is being gravitated to the coffee machine
<Laney> are you a regular office goer now?
<xnox> Laney: i don't know =) i am yesterday & today. better heating + lighting. Plus i have the new microfost ergonomic keyboard that fits into a standard laptop bag, so i feel good out here =)
<seb128> xnox, but there is like people in there...
<seb128> ;-)
<xnox> seb128: i just put my headphones in, don't play music and eavesdrop =)
<seb128> haha
<xnox> seb128: Laney: https://plus.google.com/109160032876474505377/posts/Y3zk1Etqexu
<Laney> :D
<ogra_> xnox, don't we have to call you xnox_john now ?
<ogra_> (and congrats !!!)
<Laney> wait
<Laney> no more ganja?
<xnox> Laney: no more ganja, bought Lenovo Yoga in Clementine Orange color shortly after smokin abuse at Debconf.
<xnox> it's metalic orange, and is very similar to ubuntu orage. i love it =) it's an "ideapad" instead of "thinkpad", so i still get light abuse about that.
<Laney> :D
<xnox> ogra_: haha =) I was thinking to add "Xnox" as a middle name, but i have settled for - Dimitri John Ledkov in the end.
<ogra_> :D
 * xnox should send a wider email about it.
<ogra_> thats a beautiful thing you bought there
<seb128> ogra_, hey, how is life out of work? ;-)
<ogra_> seb128, so,so ... i cracked my back on my first vacation day ... slowly able to walk upright again today
<seb128> ogra_, :-(
<ogra_> beyond that sooo boring ... (i was planning to do a lot on the house ... without being able to move that is kind of delayed by a week now)
<Laney> on the plus side, your s-c pet bug should be fixed
<ogra_> hah, cool
<Laney> (soon)
<ogra_> yeah, i see the changelog entry
<brendand> xnox, you got an ideapad too? nice hardware, requires a lot of hackery though
<seb128> ogra_, I've a working fix in the desktop team ppa, but amd64 fails to build on the ppa builders so it's i386 only
<seb128> ogra_, it seems to work for me (but it was not happening reliably before so I'm not sure), I'm going to upload to trusty once Laney manages to move the harfbuzz transition out of trusty-proposed
<ogra_> cool, i'll test it then
<ogra_> (only amd64 here ...)
<xnox> brendand: yeah I should start writing about it, i have scripts to totate _both_ screen & touch screen, plus I want to push upstream patches to udev for it's custom keycodes that indicate orientation.
<brendand> xnox, oh i'd love to get those
<xnox> brendand: not sure what to do about wifi, i currently pull dkms module from github. Not sure if i should package it or not.
<xnox> brendand: didn't get bluetooth to work.
<brendand> xnox, i'm building the wifi module from source
<xnox> brendand: do have fixed brightness keys, via xorg override.
<brendand> xnox, are you suffering from losing the mouse pointer sometimes?
<xnox> brendand: and the extra buttons do nothing (the one on the right which is "screen lock" and "the one-touch recovery" key
<xnox> brendand: mouse pointer - not that i have noticed, then again I mostly use ergonomic wireless / usb mouse.
<xnox> brendand: i do want touch apps to auto-appear and on-board to get auto-enabled.
<brendand> xnox, yeah using a mouse might make it go away
<seb128> oh, seems like webkit migrated
<seb128> Laney, right?
<seb128> just got email
<Laney> oh man, you spoiled the surprise!
<seb128> :-(
<Laney> :P
<Laney> yeah, looks good
<brendand> xnox, btw what you said yesterday about dh_python3. how to use that properly - is --exclude expecting the name of the binary package, or a path? if it's a path, relative to what?
<brendand> xnox, i can see in the logs that dh_python3 is renaming my .so file
<xnox> brendand: man debhelper; common options -        -Xitem, --exclude=item
<xnox>            Exclude an item from processing. This option may be used multiple times, to exclude more than one thing. The item is typically part of a filename, and any file containing the specified text will be excluded.
<brendand> xnox, so --exclude='libgui-engine.so' should work
<xnox> brendand: yeap.
<xnox> brendand: or, i tend to call dh_python3 only on the python3 package, e.g. override_dh_python3: dh_python3 -ppython3-foo
<xnox> brendand: such that it doesn't do anything to any other !python packages that I may have.
<brendand> xnox, in this instance all the packages are python3 except this one
<xnox> (obviously not always possible)
<xnox> ah
<brendand> xnox, would have been good to be able to exclude a whole package
<brendand> xnox, btw is exclude available in the precise version of debhelper?
<xnox> brendand: it's been available forever.
<brendand> xnox, yeah. just someone mentioned the precise version of dh_python3 has fewer options
<xnox> brendand: this is a debhelper common option, all dh_* must support it.
<xnox> Laney: lovely gnome-terminal, when can we have it in trusty? =)
<xnox> Laney: also does it work with e.g. emacs & byobu?
<Laney> xnox: channel hopping?
<Laney> also, larsu posted that :P
<xnox> =)
<Laney> see the bug I referenced and talk to M. Klose
<Laney> or you can decide to do what Debian did and take the heat yourself :-)
<infinity> brendand: You can exclude packages.
<infinity> brendand: Same syntax as xnox showed, but -N instead of -p.  ie: dh_foo -Nnot-this-package
<brendand> infinity, excellent
 * infinity is not okay with this fire alarm at 3am business and wonder if he should put on pants.
 * Laney goes blind, and then decides to stop reading that in British English
<infinity> Laney: Trousers? :P
<Laney> Much better ;-)
<brendand> Laney, is it much better? :/
<Laney> Whatever floats your boat
<pitti> infinity: WDYT, should we release bug 1257211 now-ish? it's been less than 7 days (4 only), but people are nervous and keep prodding me
<ubottu> bug 1257211 in postgresql-9.1 (Ubuntu Saucy) "New upstream microreleases 9.1.11, 8.4.19" [High,Fix committed] https://launchpad.net/bugs/1257211
<xnox> Laney: =)))))))
<pitti> infinity: eek, I read that you are probably not really "here"; not that urgent
<seb128> mardy, hey, did you see bug #1258578?
<ubottu> bug 1258578 in signon (Ubuntu) "/usr/bin/signond:4:QListData::shared_null:qDeleteAll:qDeleteAll:SignonDaemonNS::SignonSessionCore::destroy:SignonDaemonNS::SignonDisposable::destroyUnused" [Undecided,New] https://launchpad.net/bugs/1258578
<infinity> pitti: I'm okay with releasing it early if it has a comprehensive testsuite that passed on all arches and there's been some general testing and kicking the tires.
<pitti> infinity: yes to both
<pitti> infinity: upstream tests are run during package build (on all arches), and postgresql-common testsuite/autopkgtest has over 2000 system integration test cases, so I'm fairly confident
<infinity> pitti: run, and build failed when they fail? :P
<pitti> infinity: yes, of course; the only way to run them :)
<infinity> pitti: (You'd think I wouldn't have to ask that, but... GCC)
<pitti> I'm happy to do the actual button pushing, but I wanted to hear an SRU team member opinion
<infinity> pitti: If you want to drive sru-release, you've got my approval to release the lot.
<pitti> infinity: ack, thanks
<infinity> pitti: Just remember the weird syntax, if it's been a while.
<infinity> ("sru-release lucid postgresql-8.4", no -s, like every other archive tool...)
<pitti> right
<pitti> seems to have worked fine for saucy
<pitti> https://launchpad.net/ubuntu/+source/postgresql-9.1/+publishinghistory and the bug followup
<pitti> and another firefox tab gone, yay
<pkern> Is there a page that shows mirror churn (bonus points for per-architecture) for Ubuntu?
<infinity> pkern: Other than new arches, per-arch churn is the same on all arches anyway, since we don't do binNMUs.
<infinity> pkern: But not sure if we have a nice graph that shows it regardless...
<xnox> mhall119: dholbach: pitti: who is / are translation co-ordinators? I got an angry email from upstream that received a typo fix in translations they don't have, ubuntu langpack provided it.
<xnox> and they are demanding for translations to be forwarded upstream, or some such.
<pkern> infinity: Fair point. There might be size differences but small enough to not matter, I guess. I wouldn't even need a graph. A figure per month and distro would already be sufficient. ;)
<infinity> wgrant / elmo: Does either of you know if we have mirror churn stats, or an easy way to generate some based on history?
<pitti> xnox: we don't really have a coordinator any more
<xnox> pitti: =/ a wiki page or some such. I've replied this: http://article.gmane.org/gmane.comp.version-control.git/239133
<pitti> xnox: very considerate, thanks!
<dholbach> xnox, https://launchpad.net/~ubuntu-translations-coordinators
<xnox> dholbach: thanks.
<infinity> pkern: Out of curiosity, if we were to try to artificially create churn stats from publishing history, what are you actually interested in?
<infinity> pkern: Our actual ftpmaster, and its slaves (archive.ubuntu.com, security, archive.us, ports) update as often as every 5-15 minutes.
<wgrant> infinity, pkern: I have no stats for that, but could quickly generate some from the DB.
<infinity> pkern: While our downstream mirrors are rate-limited to 4h.
<infinity> pkern: And that difference actually is quite a lot right there.
<infinity> pkern: And, of course, churn gets less scary the wider your time granularity.  If you want to know the difference between snapshots in time between Jan1 and Feb1, that's a tiny number compared to the churn if you were updating every 24h, 4h, or 5m.
<shadeslayer> pitti: I agree, which is why I was trying to figure out a way to solve this on Kubuntu
<shadeslayer> talked a bit more with upstream, they use version numbers because they've personally guranteed that that a particular feature is working with that version
<infinity> pkern: And, of course, every-six-months churn is the least scary (and easiest to calculate) of all, as you're then just calculating the size of a stable release. ;)
<infinity> (Well, and all the updates/security to past releases in that time period)
<infinity> wgrant: And suddenly, for no good reason at all, I actually want to see a graph of every-publisher-cycle versus 4h-trigger-throttling versus 24h versus 1w versus 1m versus 6m churn.  Just cause.
<infinity> wgrant: I'm not sure this has any practical use for more than a handful of mirrors trying to pick the optimal update pattern, perhaps, but it would still be a pretty graph.
<mardy> seb128: yep, I have a tentative fix ready, I'll ask Ken to review it
<seb128> mardy, thanks, I just wanted to check, dunno if you read ubuntu bugs
<xnox> infinity:  is the non-rate limitted mirror directly accessible?
<infinity> xnox: I'm not sure I get what you're asking.
<infinity> xnox: All of our downstream mirrors that are SSH triggered are only triggered once ever four hours.  That's what I meant by rate-limited.
<xnox> ah, i see. so archive.ubuntu.com does update as-soon as.
<infinity> xnox: All the Canonical hosted mirrors (gb.archive, us.archive, ports, security, us.ports) update every time ftpmaster does.
<xnox> cool.
<xnox> infinity: i have git archive of mostly all per 5min granularity of dists/ for most of trusty and some of raring. do you want that?
<xnox> infinity: together with dctrl-grep one should be able to establish the throughput.
<infinity> Nah, if we want to recreate history, we have much more accurate publishing history in psql.
<xnox> infinity: cool.
<xnox> infinity: it doesn't cache Releases.gpg does it?
<infinity> "It"?
<infinity> The database has no concept of on-disk formats at all.
<infinity> It just knows when things were published and deleted.
<xnox> infinity: postgres database... right.
<infinity> So, no, we don't have a facility for a proper signed snapshot.ubuntu.com, if that was your followup. :)
<infinity> We could write a thin librarian proxy that could produce an unsigned snapshot of just about anything, but we can't give you an ACTUAL snapshot because, as you point out, we don't have the exact Packages/Release files, nor the sigs.
<xnox> infinity: i have a snapshotter, that does redirect to archive.u.c / ports / release or librarian, but apt-get freaks out when you do http (snapshoter) -> https redirect (launchpad librarian)
<xnox> is launchpad librarian accessible over http at all?
<wgrant> Yes
<infinity> Yeah, the only reason the links in the LP UI are https is trusty path.
<infinity> Since they're not coming from a signed repo.
<infinity> GAH.
<infinity> TRUST.
<infinity> NOT TRUSTY.
<infinity> Editing changelogs for this release has ruined me.
<xnox> wgrant: i actually need https://launchpad.net/ubuntu/+archive/primary/+files/ I guess i should hit that path and get the launchpadlibrarian url.
<wgrant> xnox: Or fix apt to not be terrible :)
 * xnox ponders if there is API to query http url from that.
<wgrant> https -> http redirects might be valid to complain about, but not http -> https...
<xnox> well the full chain is http -> https -> http
<xnox> so it does appear as a man-in-the-middle.
<infinity> xnox: If you can get the https URL for something, you have the http URL...
 * xnox ponders how to query 302 redirect without downloading the thing.
<xnox> in python3.
<xnox> aha follow_redirects=False.
<infinity> ... why do I get a 200 on HEAD ...primary/+files/foo.deb?
<infinity> Dear god, tell me this 302 isn't in the body.
<infinity> This is 2013.
<infinity> And not geocities.
<wgrant> infinity: Where did you see that?
<infinity> Oh, nevermind.  HEAD is lying to me.
<wgrant> $ curl -I https://launchpad.net/ubuntu/+archive/primary/+files/dpkg_1.17.1ubuntu1_amd64.deb
<wgrant> HTTP/1.1 302 Moved Temporarily
<infinity> It's following the 302 and giving me the header of the ultimate location.
<infinity> That's not at all what I want.
<infinity> It's things like this that make me stop trusting fancy tools and I fall back to "telnet $host 80" for another decade.
<infinity> Except that doesn't work too well if you don't speak fluent SSL/TLS binary goop.
<infinity> In this case, anyway.
<rbasak> infinity: "openssl s_client -connect launchpad.net:443 -CApath /usr/share/ca-certificates/mozilla" or something like that may help you here. Then you can speak HTTP yourself if you wish, with the SSL/TLS done for you.
<xnox> muahaha, got it.
<rbasak> Probably -verify 0 as well.
<infinity> rbasak: Or, less typing, "apt-get install telnet-ssl && telnet -z ssl launchpad.net 443"
<rbasak> Oh, thanks. I didn't know that existed.
<infinity> Works a treat, just tried here. :)
<infinity> You need to type fast, though, our squids drop your connection annoyingly quickly.
<rbasak> Incidentally, wget always seems to do more sensible things in edge cases like this than curl does.
<infinity> I resorted to copying and pasting my GET. :P
<rbasak> (by default; I'm sure curl has options)
<RAOF> Bah. Why don't we serve mirrors.ubuntu.com/mirrors.txt over https?
<mcpierce> Morning, all. I'm looking for some guidance on becoming a package maintainer for Ubuntu. I've read a bit online about the contributor program, but would like a little guidance if possible.
<rbasak> mcpierce: can you be more specific? Ubuntu doesn't really have package maintainers exactly, but if your focus is on one particular package you can build up a track record and then get upload rights to just that package.
<rbasak> s/get/apply for/ I guess.
<mcpierce> rbasak: Well, what I'm hoping to do is help to package up a few things from my projects (Qpid and Proton). I'm the package maintainer for them in Fedora and wanted to give the same assistance to Ubuntu as well.
<rbasak> mcpierce: I see. Are these packaged up already, or would they be new packages? If new, have you read: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages? If having Debian packages would also make sense, then we prefer to add new packages to Debian, and then Ubuntu will auto-import them.
<mcpierce> rbasak: I see that what Ubuntu ships is way out of date from what we provide currently (we're releasing 0.26, but Ubuntu is still carrying 0.16 of Qpid, and no Proton that I saw).
<mcpierce> rbasak: So, Ubuntu mostly works with Debian packages?
<mcpierce> rbasak: What I mean is, Ubuntu only adds onto Debian as opposed to repackaging the Debian bits?
<rbasak> mcpierce: correct. We only modify Debian packages if we have good reason for Ubuntu to need it. Sometimes it is time (to release ahead of Debian), and sometimes it is because we have some kind of specific reason to do something different. But in general, we try keep the delta against Debian small - ideally zero. So if you have no need for Ubuntu to carry a delta on the packages that you care about, the best first point of call is to get the packages a
<rbasak> mcpierce: also see https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule and https://wiki.ubuntu.com/DebianImportFreeze to understand the automatic Debian import and the Ubuntu release schedule.
<mcpierce> rbasak: kk - thanks for the info!
<rbasak> mcpierce: np. We appreciate you caring for Ubuntu packages. Ask if you need any help.
<apachelogger> pitti: got it all figured out now I think  ... kapplication crashes -> crash handler -> invokes drkonqi (GUI) -> drkonqi has checkbox to automagically submit crash report -> when ticked /var/crash/foo.drkonqi-accept is written on exit -> crash handler checks for file after drkonqi terminated -> if present it re-raises to apport -> if not it exists without forwarding to apport ... apport collects information -> kubuntu-notification-helper
<apachelogger> (invokes apport-kde usually) looks for .drkonqi-accept for each pending crash -> if found custom script dervied from whoopsie-upload-all is executed to batch upload -> otherwise apport-kde notification is shown
<apachelogger> long-term goal to get rid of the drkonqi file and use .upload with aggregation done inside whoopsie if something is missing from the report
<mcpierce> rbasak: Will do. :D
<pkern> infinity: We're pulling development every 20 minutes at the moment and archive for eternity. That's slightly inefficient, of course. But I'm more interested in LTS per month churn once it's stable.
<mcpierce> y
<tseliot> pitti: if I make a package recommend another and the user has the former already installed, will the user get the recommended package through the updates?
<pitti> tseliot: yes
<tseliot> pitti: ok, the problem is that I'd like to make nvidia-331 recommend nvidia-prime but I would also like to give users the chance to remove nvidia-prime and install bumblebee instead. This would work only if they don't update
<pitti> tseliot: so perhaps recommends: prime | bumblebee ?
<tseliot> pitti: I don't think bumblebee is in main
<pitti> tseliot: that's ok, only the primary (preferred) alternative needs to be as it's the one which is installed by default
<pitti> tseliot: with that, if an user already has bumblebee installed, it wouldn't additionally install prime for him
<tseliot> pitti: ah, that would work. Thanks!
<pitti> tseliot: I'm not saying that this is what you want (you know better what shoudl happen on upgrades), just that it's a possibility
<tseliot> pitti: yes, it should be enough
<tseliot> pitti: so, to double check, something like this would work, right? Recommends: nvidia-prime (>= 0.5) | bumblebee-nvidia
<pitti> tseliot: users which have either installed won't get any package change on upgrades; users which have neither installed will get nvidia-prime
<pitti> tseliot: if that's the semantics you want?
<tseliot> pitti: yes, that's exactly what I need. Thanks :)
<pitti> tseliot: great
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<pkern> xnox: Why don't you use https for the snapshotter?
<pkern> No reason not to, these days. At least if APT knows SNI. (No clue if it does.)
<mvo> pkern: libcurl is used by apt for the https so SNI should be fine
<pkern> Yeah, well. Still unhappy with curl as the https provider. |;
<mvo> pkern: oh? what do you suggest instead?
<pkern> If I knew. I wanted to look at this stuff this quarter but didn't get to it. neon at least states that it does PKCS#11, but then apt is I think GPL without an OpenSSL exception and hence it still wouldn't be useful for distro purposes.
<mvo> pkern: the status is a bit unclear, if we can reach jgg for a formal statement then it would be much easier
<xnox> pkern: mvo: my problem was that I don't have an SSL sertificate on my domain, therefore my nginx redirector was causing http -> https (launchpad) -> 302 -> https launchpadlibrarian. This is all fine for wget, but not for apt-get it compliant that it couldn't verify something or that certs were changing.
<xnox> pkern: mvo: i could get an ssl cert on my domain, but i'm not sure if that would have helped. and I really don't want to pay for traffic to fetch it on my server, just to stream it to the client. I want clients to connect / download from the upstream /pool/, and only fetch /dists/ from me.
<xnox> pkern: mvo: i will set it up again and let you know.
<pkern> mvo: http://search.gmane.org/?author=Jason+Gunthorpe&sort=date seems to list an email address.
<pkern> xnox: redir shouldn't switch transport methods (but no, I didn't check if it works, we still serve everything directly)
<pkern> From https to https I mean.
<xnox> pkern: well, it will have to, to optimise bandwidth. So i'm continuously snapshotting /dists/ (such that I have real Releases.gpg), but /pool/ URLs are fallthrough provided by archive.ubuntu.com, ports.ubuntu.com, old-releases.ubuntu.com, and finally launchpadlibrarian.
<xnox> pkern: all but librarian are http.
<xnox> pkern: but now i worked out a way to make librarian urls also http.
<xnox> pkern: there is no need for https, because one verifies archive gpg signatures
<xnox> pkern: but I do understand that many people want to use https nonetheless to hide which packages are fetched / conseal the traffic.
<xnox> pkern: that's why i will be making my data public, as a git repository such that one can set up their own redirector behind https / firewalled or as needed.
<pkern> xnox: Or because they need authentication. Hence the problem of missing PKCS#11 support.
<pkern> ;)
<xnox> ;-) touche
<zul> doko:  ping
<zul> doko:  can you promote python-webtest please?
<dholbach> cjwatson, robru: nice bug fixes in the newest click :)
<doko> zul, promoted the dependencies
<zul> doko:  cool thanks
<doko> zul, re migrate: we won't promote sqlite again
<doko> and nose needs some mir's
<zul> doko:  yeah im not worried about migrate yet
<Munchor> Guys, thank you for the GTK+ 3.10 on 14.04, it's great, great news, good job
<shadeslayer> anyone have a clue why querying the version via python doesn't work but via the terminal works : http://pastebin.kde.org/pf3kgvn7u
<Riddell> shadeslayer: system vs session bus?
<shadeslayer> http://pastebin.kde.org/p0brmjotq
<jodh> shadeslayer: http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/scripts/pyupstart.py#L327
<Riddell> shadeslayer: if I use qdbus I get Rejected send message,
<shadeslayer> Riddell: 0.o
<shadeslayer> jodh: I /have/ to use Qt :)
<stgraber> pitti: bug 1197395 and bug 1245189 appear to be missing the usual SRU paperwork (systemd sru)
<ubottu> bug 1197395 in systemd (Ubuntu Saucy) "/run/user/$ID/pulse owned by root and not by the user" [Undecided,In progress] https://launchpad.net/bugs/1197395
<ubottu> bug 1245189 in systemd (Ubuntu Saucy) "[keymap] Lenovo Z370 multimedia keys do not work because force-release in hwdb.d is missing" [Undecided,In progress] https://launchpad.net/bugs/1245189
<jodh> shadeslayer: that's not what I referring to. FREEDESKTOP_PROPERTIES='org.freedesktop.DBus.Properties', so you've specified the wrong interface in your python example I think?
<shadeslayer> >>> upstartinterface = QtDBus.QDBusInterface("com.ubuntu.Upstart", "/com/ubuntu/Upstart", "org.freedesktop.DBus.Properties",QtDBus.QDBusConnection.systemBus())
<shadeslayer> >>> print(upstartinterface.property("version").toString())
<shadeslayer> gives me nothing
<shadeslayer> jodh: plus,QDBusInterface has a special function to read properties
<pitti> stgraber: ah, keymaps have an SRU exception; I thought diwic made the SRU prep for the other one, hang on
<pitti> stgraber: 1197395 has an SRU test case; you want a regression potential?
<stgraber> pitti: oh, didn't know about the keymaps exception (I really need to learn the list by heart ;)), for the other one, I must have missed it. I think between the testcase and the comments, it's fine. I'll accept the upload then.
<pitti> stgraber: the bug description is quite long indeed; I'm currently adding a pointer to the fix and a regression potential
<stgraber> pitti: thanks!
<pitti> stgraber: added; it actually makes some sense for this bug as the regression potential is nonzero (even though it's a bit academic) and there is an actual behaviour change
<mterry> mvo, hello!  I was looking at command-not-found, and it's update-from-web.sh script is giving a 404 on http://ports.ubuntu.com/~mvo/command-not-found/scan.data-latest
<pitti> stgraber: thanks for processing (nice to see SRUs not having large delays any more!)
<stgraber> pitti: well, we didn't do so well the past few weeks because of the massive KDE SC SRUs in the saucy queue, but yeah, I think we're mostly keeping up for the past few months, that's good to see!
<shadeslayer> could someone help me with the upstart dbus bug that I'm experiencing?
<mvo> hey mterry! I can't unfortunately access this host anymore, but there used to be a script running there that extracts the command-not-found data from the local archive
<mvo> mterry: I would love to fix it, not sure if (temporary?) access could be granted for this
<mterry> mvo, or maybe we need to put it in some team account
<mterry>  long-term
<mvo> mterry: YES, definitely
<seb128> mvo, hey, how are you?
<mvo> seb128: good, thanks!
<mvo> seb128: and you?
<seb128> mvo, I'm good thanks
<seb128> mvo, not sure if you saw my Cc on https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1258112
<ubottu> Ubuntu bug 1258112 in update-manager (Ubuntu) "Try calling unexisting functions on GtkDialog" [High,Confirmed]
 * mvo looks
<seb128> mvo, it would be nice if you could comment, seems like Dylan is wanting to fix the issue but needs some guidance/background on why the code is this way
<mvo> seb128: yeah, I need to look at the bzr log to remember :)
<seb128> mvo, ;-)
<mvo> seb128: I'm currently working on a apt bug - once that is done I check this one out
<seb128> mvo, no hurry, I was just unsure if you noticed launchpad Ccs or if that would go to spam box
<seb128> mvo, thanks ;-)
<seb128> mvo, speaking about apt bug, that's not bug #957231 by any chance? ;-)
<ubottu> bug 957231 in apt (Ubuntu Trusty) "update-manager crashed with SIGSEGV in debListParser::LoadReleaseInfo()" [Medium,Triaged] https://launchpad.net/bugs/957231
<mvo> seb128: no :P - are you trying to trick me into fixing this one too ;)
<seb128> mvo, lol, I wouldn't say no, just having a clean e.u.c obsession recently ;-)
<seb128> mvo, joke aside, we got most of the top issues, including the webkit/software-center one that hits quite some users since saucy, just a few remaining (well on the high ranked ones)
<seb128> mvo, that one being of those
<mvo> seb128: nice!
<mvo_> seb128: hrm, X crashed :/
<mdeslaur> mvo_: watch out, or seb128 will trick you into fixing X too :)
<mvo_> mdeslaur: lol - we should replace it with something better I guess :P -
<mdeslaur> heh
<seb128> hum, me or X?
<seb128> ;-)
<mdeslaur> lol
<mvo_> seb128: there is nothing better you know
 * seb128 hugs mvo
 * mvo_ hugs seb128
<comjf> can anyone help me resolve this isue when trying to apt-get update --fix-missing
<comjf> W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://us-east-1.ec2.archive.ubuntu.com precise-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<sarnold> comjf: are you by any chance using apt-cacher-ng?
<comjf> sarnold: not that I am aware of, just spun up a brand new AWS EC2 12.04.03 instance
<comjf> and my automation tools run an apt-get install command
<comjf> then it errored, when trying to manaully fix it, I get that error
<sarnold> comjf: drat. try rm -rf /var/lib/apt/lists/  and then apt-get update && apt-get install ... again.
<comjf> sarnold: giving it a whirl, thanks
<comjf> sarnold: same error :( I ran W: GPG error: http://us-east-1.ec2.archive.ubuntu.com precise-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<comjf> woops, I ran: sudo rm -rf /var/lib/apt/lists/ && sudo apt-get update
<comjf> is there a way I can use a different mirror then the ec2 one... maybe they messed something up
<sarnold> comjf: I don't know how the billing works out to use a different datacenter, just be aware of that...  edit /etc/apt/sources.list to use a different mirror
<comjf> sarnold: hm good point. It couldn't cost that much to install a few packages.. at least I hope
<comjf> are there any other debugging steps I should preform before trying that though?
<comjf> sarnold: thanks for your help, I saw your post in the other channel, I'll monitor that chan now. I appreciate your quick response
<d4c7> anyone familiar with default apache ciphersuite/ssl settings in precise that changed from previous releases?
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #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: Ubuntu 13.10 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<mterry> barry, sorry for leaving all those syncs for you to close...  I was waiting for emails from Launchpad that never seemed to have come
<barry> mterry: no worries at all!
<barry> mterry: thanks for actually doing the syncs :)
<doko> infinity, any update on the state of glibc-2.18?
<infinity> doko: I have the Ubuntu merge changelog written up, just going to give it one more test-build with the latest Debian changes and JFUI, I think.
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #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 2013-12-11
<Riddell> mdeslaur: new qt security debdiffs on bug 1259577
<ubottu> bug 1259577 in qtbase-opensource-src (Ubuntu Saucy) "Security: XML Entity Expansion Denial of Service" [Undecided,New] https://launchpad.net/bugs/1259577
<mdeslaur> Riddell: awesome, thanks, I'll take a look tomorrow
<pitti> Good morning
<dholbach> good morning
<xnox> is there a way to query all mailing list subscriptions for lists.ubuntu.com of a given email address?
<xnox> maybe barry ^
<rbasak> xnox: it is possible to change the settings for all subscriptions all at once, if that's what you're after. You can do that from any single control page.
<xnox> rbasak: ok, thanks.
<tseliot> didrocks: just FYI the new nvidia-prime is trusty
<didrocks> tseliot: ok, so we have a mismatch with bbswit*
<tseliot> didrocks: mismatch?
<didrocks> tseliot: bbswitch needs to be promoted, right?
<tseliot> didrocks: yep
<tseliot> ok, so that kind of mismatch
<didrocks> tseliot: I'll do it once I have a second
<didrocks> yep ;)
<tseliot> didrocks: ok, thanks a lot :)
<didrocks> yw!
<didrocks> tseliot: promoted btw :)
<tseliot> didrocks: thanks again :)
<didrocks> yw!
<psivaa> pitti: cjwatson: I remember you were discussing the fix for bug 1256695 in terms of permissions etc..
<ubottu> bug 1256695 in rsyslog (Ubuntu Trusty) "cannot create log files in /var/log" [Critical,Fix released] https://launchpad.net/bugs/1256695
<psivaa> We now have an issue as stated in bug #1258245 impacting the VM provisioning in the smoke tests
<ubottu> bug 1258245 in rsyslog (Ubuntu) "syslog user can't write to /dev/ttyS0" [Undecided,New] https://launchpad.net/bugs/1258245
<psivaa> Would help if you could have a look when you have some time
<pitti> psivaa: that doesn't sound like a regression, though?
<pitti> the syslog user has never been meant to be in the dialout group
<psivaa> pitti: but i guess rsyslogd was not run as syslog in the past? (before the big upgrade of rsyslog in trusty)
<pitti> psivaa: ah, right
<lifeless> cjwatson: btw, I probably won't be able to follow through and test that grub2 recogniser test; due to running out of space I've had to replace the system with one with more drive bays and migrate everything over
<lifeless> cjwatson: I'll see if I can give it a spin before I complete the migration, but keeping home systems up is likely going to take priority
<cjwatson> lifeless: which one is that, sorry?
<cjwatson> the dmraid striping thing?
<lifeless> cjwatson: failing to recognise mdadm when the end of the partition isn't accessible (but none of the needed data is above the 2TB mark)
<lifeless> so the layers don't come in and the kernel etc aren't accessible
<cjwatson> oh, right, that
<lifeless> yeah, 'that' :)
<lifeless> aka robert likes finding corner cases
<doko> cjwatson, about lockdev. not sure if I should care about a symbols file, hardening defaults, things like cross buildability, if we demote it anyway in the future?
<cjwatson> Oh, I didn't see Roger's comment
<cjwatson> Yeah, probably not a big deal then
<Riddell> tseliot: ping
<tseliot> Riddell: pong
<Riddell> tseliot: I'm looking at nvidia-persistenced  in New which seems to have been overlooked for over a month, were there problems with it?
<Riddell> tseliot: how come it's Section: contrib/x11 ?
<Riddell> tseliot: there is a COPYING file which says GPL but all the individual files give an MIT type licence, any idea why?
<tseliot> Riddell: not really, I made the changes requested by the review but nobody reviewed it again
<tseliot> Riddell: let me check...
<tseliot> Riddell: ok, I can fix the licence and the section (it's really a tool as much as nvidia-settings)
<Riddell> tseliot: I take it the COPYING file was added by upstream?
<tseliot> Riddell: yep https://github.com/NVIDIA/nvidia-persistenced
<Riddell> tseliot: stuff in common-utils/ is GPL so I guess you need two blocks in debian/copyright  one for Files: * as GPL  and one for Files: list-each-file  as MIT
<Riddell> tseliot: lovely, I'll reject this, fix those and I'll accept
<tseliot> Riddell: ok, thanks
<tseliot> Riddell: oh, and shall I keep the COPYING file?
<Riddell> tseliot: yes it realates to any file which doesn't list itself as MIT I guess
<tseliot> Riddell: ok, thanks
<doko> pitti, jibel: I hear that the debian buildds use ekeyd-egd-linux for some entropy. not sure if we use it on our buildds. but maybe you want to use it for the autopkgtests, instead of disabling all failing tests ...
<pitti> doko: I already tried with haveged, I don't think it's missing entropy; I think it's because the VM doesn't have a fine enough clock resolution to guarantee that 1.000 UUID1 generated in a row are actually unique
<pitti> doko: (I wrote some details a few days ago)
<doko> ok
<doko> zul, your neutron upload waits for a MIR for python-psutil
<KoalaYeung> Hello
<KoalaYeung> Anybody here  knows how to make an Ubuntu Software Center with an image icon?
<infinity> jamespage: Yo.  Two days ago, you mangled libusbx to wiggle build-deps around.  The bug you referenced was bogus.  Can you remember what the actual issue was?
<infinity> jamespage: Oh, I'm guessing because older dpkg-buildpackage called "build" instead of "build-arch".  But do you really need to backport libusbx?
<jamespage> infinity: sorry - I had to many bug windows open that day
<jamespage> infinity: yes that was the issue
<infinity> jamespage: So, more to the point, WHY is it an issue?  Why do you care if the source can be backported unmodified to a previous release?
<infinity> jamespage: (I'm asking because I just ran into that build-dep being wrong during a bootstrap and it annoyed me :P)
<infinity> So, I fixed it, and when I went to document it in the changelog, I realised it was a delta you'd added only two days earlier...
<jamespage> infinity: urgh - sorry
<xnox> infinity: cloud-archive? but then again why would it be using libusbx....
<jamespage> have to duck out for a bit; lets discuss when I get back
<jamespage> but yes cloud archive
<jamespage> xnox, qemu I suspect
<infinity> Surely, cloud archive has modified backports in it.  Trying to support crusty old build tools forever isn't fun.
<infinity> Anyhow, I've worked around it locally for now anyway, it's just irritating. :P
<zul> doko:  ping python-psutil had a MIR previously but its universe now, i filed a new one https://bugs.launchpad.net/ubuntu/+source/python-psutil/+bug/1259928
<ubottu> Ubuntu bug 1259928 in python-psutil (Ubuntu) "[MIR] python-psutil" [High,New]
<sergiusens> jamespage, this is just speculation, but I can't seem to build packages that use dh_golang with the latest go
<sergiusens> saw you uploaded 1.2
<smoser> hey.
<mdeslaur> xnox, zul: can one of you please merge samba 4.0.13?
<smoser> can someone verify for me  https://launchpad.net/ubuntu/+source/euca2ools/3.0.2-1/+build/5321133
<smoser> i think that is dependency wait because python-requestbuilder is not in main ?
<smoser> in the past i would have thought that would still build and go in and then appear in component-mismatches.
<xnox> mdeslaur: please, not me.
<mdeslaur> xnox: sure. zul, you're it! :)
<xnox> mdeslaur: and did you mean 4.0.13, or 4.1.3?
<zul> mdeslaur:  sure
<xnox> mdeslaur: zul: there is 4.1.3 in NEW
<xnox> zul: mdeslaur: important packaging fixes, I see.
<xnox> and CVEs....
<cjwatson> smoser: no, in the past it would have done just the same thing
<zul> xnox:  ill either get to it today or tomorrow but its on my todo list
<xnox> cool.
<cjwatson> smoser: you're thinking of run-time dependencies, not build-dependencies
<mdeslaur> yeah, I'm good with either 4.1.3 or 4.0.13
<smoser> cjwatson, ok. so i need to request MIR for python-requestbuilder ?
<mdeslaur> zul: cool, thanks.
<cjwatson> smoser: yes
<smoser> cjwatson, thanks.
<barry> xnox: yes.  looks like rbasak answered your question!
<xnox> barry: cheers ;-)
<jamespage> infinity: unmodified backports == 0 work; which is why we have been trying to push un-intrusive changes back into trusty; this is probably not one of those - that was my bad
<jamespage> sergiusens, hmm - I'd hope not - that was a merge from Debian
<jamespage> but its quite possible
<jamespage> infinity: I'll revert my delta and hold it in the cloud-archive instead if that makes your life easier
<sergiusens> ok, I'll dig into it
<jamespage> sergiusens, do you have a build log?
<jamespage> for a failuer
<seb128> slangasek, cjwatson: bug #1185092 ... should we still do what Steve suggested ("the new libgtksourceview-3.0-common to Conflicts/Replaces libgtksourceview-3.0-0, to hint the upgrade.")?
<ubottu> bug 1185092 in gtksourceview3 (Ubuntu) "partial upgrade dialog in saucy due to versioned -common dependency" [Medium,Triaged] https://launchpad.net/bugs/1185092
<seb128> e.g is that useful for LTS upgrades, or was that only a saucy thing?
<cjwatson> TBH I can't quite remember the differences between within-release upgrades with update-manager and full between-release upgrades
<cjwatson> I would default to assuming it's useful across the board
<seb128> ok, it doesn't hurt to have it in any case
<seb128> I'm going to add that to the upload I'm about to do
<cjwatson> ok, thanks
<seb128> yw
<sergiusens> jamespage, http://paste.ubuntu.com/6556395/
<Cimi> seb128, cannot reproduce https://bugs.launchpad.net/ubuntu/+source/overlay-scrollbar/+bug/1086494
<ubottu> Ubuntu bug 1086494 in overlay-scrollbar "GtkScrolledWindow is mapped but visible child GtkScrollbar is not mapped" [Undecided,In progress]
<seb128> Cimi, it happens to me 1 every few times I do "gedit something" where something is a document with enough content to scroll
<Cimi> ok
<Cimi> let me try
<seb128> like start/close it in loop for a few times
<Cimi> seb128, not happening :-\
<seb128> that's a timing thing, it might not happen often for you
<Cimi> seb128, ok now after 4th time
<Cimi> seb128, thx
<seb128> yw
<sergiusens> jamespage, just tried to sbuild on sid; same results
<Cimi> seb128, I think the patch breaks another thing
<Cimi> seb128, if you change overlay mode
<seb128> Cimi, like?
<Cimi> from overlay-auto to normal
<Cimi> in dconf
<seb128> oh, I didn't test that
<Cimi> the scrollbar does not work anymore
<seb128> Cimi, well, you are welcome to find a better fix for the warnings ;-)
<Cimi> seb128, that branch does not fix the warning
<Cimi> what it does it hiding the widget when the scrollbar mode changes
<Cimi> so might have just been good luck
<seb128> Cimi, well, I get those warning 15 times a day and I didn't get any in 10 days since I'm running it, so whatever it's doing makes the warning goes away as well
<Cimi> seb128, try reverting overlay scrollbars
<Cimi> seb128, it does not make sense this branch
<seb128> Cimi, well, I did that yesterday and got my command line spammed with warnings again so I reinstalled it
<Cimi> no idea why
<Cimi> the scrollbar mode does not chsnge
<Cimi> this function does not get called
<seb128> well, you managed to trigger the warning as well no?
<seb128> Cimi, well, it seems it happens at init?
<seb128> Cimi, what function?
<Cimi> seb128, scrollbar_mode_changed_unload_gfunc
<Cimi> seb128, the function touched by the patch
<Cimi> seb128, add printf ("hello world");
<Cimi> seb128, nothing is printed, the function is not called, it cannot fix the bug
<seb128> Cimi,
<seb128> ** (gedit:8552): WARNING **: scrollbar_mode_changed_unload_gfunc has been called
<seb128> Cimi, it's called (had to try 6 times, it's like the warnings)
<Cimi> seb128, not here, weird
<seb128> did you get the warnings?
<Cimi> might be dconf
<Cimi> I get the warning without the print :-\
<seb128> I used a g_warning
<seb128> let me try a printf
<seb128> maybe your code eats stdout?
<Cimi> Â°_Â°
<Cimi> maybe
<seb128> Cimi, right, printf doesn't work, g_warning does
<Cimi> seb128, ok
<Cimi> good
<seb128> Cimi, I added both, only the g_warning is displayed
<seb128> $ gedit overlay-scrollbar_0.2.16+r359+14.04.20131129-0ubuntu1_i386.build
<seb128> ** (gedit:14485): WARNING **: scrollbar_mode_changed_unload_gfunc
<seb128> (gedit:14485): Gtk-WARNING **: GtkScrolledWindow 0x8d012a8 is mapped but visible child GtkScrollbar 0x8d03480 is not mapped
<seb128> oh
<Cimi> seb128, I'll dig into it
<seb128> Cimi, shrug, it's me being stupid and not having a \n in the printf
<seb128> Cimi, your fault for giving me a line to copy without it as well
<Cimi> ahah
<Cimi> seb128, qml does not need \n
<Cimi> seb128, I forgot all that
<seb128> g_warning neither
<Cimi> my fault
<seb128> ;-)
<seb128> Cimi, if you do "com.canonical.desktop.interface scrollbar-mode" this function is called/the warnings are displayed
<seb128> ups
<seb128> Cimi, $  gsettings reset com.canonical.desktop.interface scrollbar-mode
<seb128> Cimi, that's an easy way to trigger it
<seb128> it might make debugging easier
<Cimi> seb128, it does
<seb128> Cimi, gdb says scrollbar_mode_changed_cb calls it
<Cimi> seb128, yep got that
<Cimi> seb128, I think we should maintain another list with scrollbars that need to be set visible true or false
<seb128> Cimi, list of what?
<Cimi> seb128, we cannot call hide() like in the branch
<Cimi> seb128, we need to keep track
<seb128> of what?
<Cimi> if you see lars branch
<seb128> well, I don't know what that code is doing
<Cimi> ok
<seb128> but I trust you to find a solution ;-)
<Cimi> seb128, ok I'll tell lars tomorrow, I forgot a little of those C stuff data types :)
<Cimi> seb128, but I knw how to fix it
<seb128> Cimi, great, thanks
<seb128> Cimi, btw gtk 3.10 landed to trusty, we might need some theme tweak/the hack from larsu on https://code.launchpad.net/~larsu/ubuntu-themes/dont-set-all-bgs/+merge/197234 to be merged in
<seb128> Cimi, without that stuff like infobar (e.g trash location in nautilus) don't have a background (or right click on an icon in nautilus)
<Noskcaj> Can someone take a look at https://code.google.com/p/prpltwtr/issues/detail?id=88 and tell he how much more work needs doing for this to be release worthy in ubuntu?
<xnox> Noskcaj: what do you mean by "release worthy" ?
<Noskcaj> xnox, We could include it, since we used to have pidgin-microblogger, but a twitter update killed it
<xnox> Noskcaj: as far as I can see that library is not packaged at all https://launchpad.net/ubuntu/+search?text=prpltwtr and if it's broken well no point in re-introducing it.
<xnox> Noskcaj: pidgin is not default in most flavours, and furthermore most have other default microblogging clients.
<Noskcaj> xnox, I would package it as a replacement, even if just in the archives, it would be nice to have a working version
<Noskcaj> ok
<xnox> Noskcaj: if you want to package / maintain it, please do it via Debian ITP
<Noskcaj> of course
<xnox> Noskcaj: then why do you ask here?! =)
 * xnox is still confused by "release worthy" =)))))) but meh, if it's auto-synced it's auto-synced.
<slangasek> Laney: harfbuzz> I know this problem is actually courtesy of Debian, and not your merge, but please take care that libraries in Ubuntu that rename without changing the soname use Conflicts, not unversioned Breaks (which are wrong)
<Noskcaj> to see what would be needed to include it on the cd, like pidgin-microblogger was for my flavors
<slangasek> Laney: update-manager can't automatically figure out what to do with such a lib... and I see this happening several times a cycle.  I'm not picking on you, just trying to spread the word bit by bit :)
<dobey> Noskcaj: i guess you'd need to get pidgin back on the cd first :)
<Noskcaj> dobey, I wasn't sure if ubuntu still had it, i know other flavors still do
<xnox> Noskcaj: to be included on the cds, it needs to be available in the archive first. otherwise it's a very hypothetical discussion =)
<xnox> Noskcaj: $ seeded-in-ubuntu pidgin
<xnox> Noskcaj: says that pidgin is on lubuntu, ubuntustudio and xubuntu.
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #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> jamespage: I've reverted it for you. :)
<jamespage> infinity: thankyou!
 * jamespage goes to make a branch
<infinity> jamespage: Is the cloud archive for precise going to keep being updated for the full 5y LTS, or is the plan to move focus entirely to 14.04 (except for security fixes, of course) once it's out?
<jamespage> infinity: this one is the last one for 12.04
<infinity> jamespage: Cause if the latter, I guess this isn't a problem you need to worry about much longer.
<jamespage> its gets support until the end of 12.04 (by virtue of being based on the same packages that are in 14.04)
<jamespage> for u-series we start the dance all over again for 14.04
<infinity> jamespage: Right, but at least 14.04's dpkg has the arch/indep split sorted out, so no one will be moving BDI to BD to "fix" things. ;)
<hallyn_> infinity: mvo: hi, do you guys know how sandbox-upgrader is being used (if it all) these days?
<infinity> hallyn_: No idea.
<hallyn_> hm
<hallyn_> it has no rdeps...
<hallyn_> kirkland: soren: ^ do you know where sandbox-ugprader may be in use?
<hallyn_> guess i should jsut wait for mvo :)
<bdmurray> hallyn_: you might ask jibel as he is looking at auto upgrade testing
<hallyn_> rbasak: could you look at auto-upgrade-tester and sandbox-upgrader - there should be no reason why they couldn't switch from vmbuilder to your uvt right?
<hallyn_> jibel: (please ping me if you do in fact use sandbox-upgrader or auto-upgrade-testing)
<kirkland> hallyn_: I've never heard of it
<xnox> Laney: looks like unity7 ftbfs with new gtk? https://launchpadlibrarian.net/159516409/buildlog_ubuntu-trusty-amd64.unity_7.1.2%2B14.04.20131106.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<xnox> or is this already being looked at.
<xnox> ?
#ubuntu-devel 2013-12-12
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<Noskcaj> pitti, Would you mind giving me a motu testimony? https://wiki.ubuntu.com/Noskcaj#MOTU
<pitti> barry: https://jenkins.qa.ubuntu.com/job/trusty-adt-system-image/16/? \o/
<pitti> barry: the new test looks great, just what a package/integration test should be
<pitti> barry: i. e. let the unit test handle the fine details during package build, and at integration time just make sure that your packages ship everything that they need and the main use case works
<dholbach> good morning
<soren> hallyn_: No clue, sorry.
<evfool> hey seb128
<seb128> evfool, hey
<evfool> seb128: glad to see that GTK 3.10 will land in 14.04, and that some app updates might also land, wanted to know whether there's any other criteria for an app to be updated beside NOT HAVING headerbars
<seb128> evfool, well, no real defined criteria, just "it's a LTS cycle, please be careful/don't get crazy"
<seb128> do you have anything specific in mind?
<evfool> seb128: in the context of system monitor we had minor UI tweaks+headerbar support, but I would be trying to add a compile option to compile without headerbar support (with standard menubar), and would like to know whether that'd be fine
<seb128> evfool, yes, that would be great
<Laney> you can detect it at runtime
<seb128> we just need the app to not look so different from everything else
<seb128> evfool, right, runtime might be better
<Laney> https://wiki.gnome.org/HowDoI/AlternateMenubarLayout
<seb128> so gnome-shell user can get the headerbar
<evfool> seb128: ok, right then, I'll go with Laney's advice and do that
<seb128> and the app still looking 'normal' under other desktops
<seb128> evfool, excellent, thanks!
<Laney> rocking, nice one
<sergiusens> wgrant, hey, ubuntu:lxc-android-config seems to be out of sync, I've been forwarded to you; is there anything we can do about it?
<sergiusens> jamespage, hey, in case you were wondering. wrt to my golang issue yesterday; it was actually a bug in dh-golang; I've logged a bug and a simple patch upstream
<wgrant> sergiusens: http://package-import.ubuntu.com/status/lxc-android-config.html#2013-10-24%2002:27:29.212426 suggests that the changelog is corrupt
<wgrant> It could probably ignore that, except it crashes because the warning code can't handle non-ASCII characters...
<wgrant> It would possibly work if I hacked udd to just suppress all warnings from debian.changelog, but I'm not sure if that would have unforeseen consequences.
<hallyn_> hm, a boot with !quiet !splash seemed to show 2 precious seconds in a 8 (now 10) second boot were spent 'scanning for btrfs filesystems'
<sergiusens> wgrant, we can get barry to port that to python3 :-)
<sergiusens> wgrant, let me see if I can fix that warning in the changelog whatever it is
<wgrant> sergiusens: Possibly, but it might be looking at a changelog in an old version of the package
<wgrant> I don't have time to look right now, I'm afraid.
<sergiusens> ack, I'll just use plain sources for now then
<sergiusens> thanks anyways
<xnox> hallyn_: right, at the moment if you have btrfs-tools installed, it gets copied into initramfs unconditionally (even if there are no btrfs pools attached to the system / it boots off non-btrfs)
<hallyn_> xnox: yuck.  if i'm not booting from btrfs, seems like something that could get pushed back to mountall...
<xnox> hallyn_: override / purge / dpkg-divert the btrfs-tools initramfs hooks.
<jamespage> sergiusens, excellent
<jamespage> sergiusens, have you done any from scratch packaging using dh-golang yet? I have some stuff to work on this cycle but in the new year
<sergiusens> jamespage, yes actually,I've packaged gocheck; it's in debian new; I also have a packaging branch for usensord (our sensors interface for touch) under review
<jamespage> sergiusens, excellent!
<jamespage> sergiusens, I'm due to break out some of the bundled source dependencies from juju
<sergiusens> jamespage, well, the good thing is that it's not that hard to package :-)
<jamespage> sergiusens, does dh-golang actually build anything? or does it just package up the source code
 * jamespage has not looked in detail yet
<sergiusens> jamespage, it builds main packages
<sergiusens> jamespage, for packages it just sets up a by convention /usr/share/gocode GOPATH and installs there
<jamespage> right
<sergiusens> convention is, for those packages just append the -dev
<hallyn_> xnox: well that box (the only one that boots fast anyway) doesn't actually have any btrfs, so i had just wantd the manpages once :)
<xnox> hallyn_: purge it & use manpages from manpages.ubuntu.com (there  is even a command line utility to fetch / read manpages from there)
<xnox> ... with added bonus of choosing which release to read the manpage for.
<sergiusens> jamespage, there's already a couple of packaging branches you can use to inspire yourself http://anonscm.debian.org/gitweb/?a=project_list;pf=pkg-go/packages
<sergiusens> jamespage, and the general convention which is a light read: https://wiki.debian.org/MichaelStapelberg/GoPackaging
<pitti> slangasek, stgraber, xnox: I updated https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming with cking's summaries
<pitti> slangasek, stgraber, xnox: so I think on the phone we all agree that "discard" is the way to go
<pitti> slangasek, stgraber, xnox: what's your feeling on the desktop? I still tend towards the cron job, but I'm happy to see that "discard" is not as bad a performance eater as I feared
<stgraber> pitti: yep. I think I already have a branch for it somewhere, just need to push it I guess :)
<pitti> stgraber: a branch for what?
<stgraber> pitti: discard on phone
<pitti> stgraber: oh, right, nevermind
<pitti> [stgraber] modify phone initramfs-tools to apply discard option: TODO
<xnox> stgraber:  pitti: ok, i have a branch for mountall that fixes remounting if options are different, but it needs fixing. so if you want to enable it on touch now, do it in the initramfs-tools-ubuntu-touch by manually specifying that option.
<pitti> xnox: it's not urgent enough to warrant temporary workarounds on the phone which will be obsolete soon, IMHO
<stgraber> xnox: yeah, my plan was to do it directly at initial mount in the initrd
<xnox> stgraber: good.
<hallyn_> xnox: i don't like using a browser when i don't have to :)
<hallyn_> is there a scope for manpages.u.c?
<pitti> stgraber, xnox, slangasek: so I guess I'll go write that cron job now, as we want that either way
<xnox> hallyn_: there is a cli util to fetch & man -l the manpage.
<xnox> hallyn_: no idea about scopes.
<pitti> slangasek: oh, and once we have a decision, BP approval would be nice (or some comment what's still missing); TIA!
<stgraber> pitti: so my main concern about using fstrim is small SSDs but I guess if we run it daily it may be fine
<stgraber> pitti: I actually had the case yesterday where I accidently filled my mediacenter's SSD twice when copying some stuff around (32GB SSD but playing with 1080p movies...)
<pitti> wgrant: oh! https://translations.launchpad.net/ubuntu/trusty/+language-packs
<pitti> wgrant: thanks
<pitti> seb128: ^ FYI
<infinity> pitti: Didn't cking have all sorts of benchmarks and numbers about trim and discard?
<seb128> pitti, great!
<pitti> infinity: right; as I said I just put his conclusions into the BP
<infinity> pitti: Oh, heh, I didn't read far enough back. ;)
<davidcalle> hallyn: not sure if it's what you are looking for, but if you have the manpages package installed, try searching the Dash for "manpages:dpkg"
<infinity> pitti: If discard is the right answer on phones, why wouldn't it be on desktops?  What's the reasoning there?
<pitti> infinity: desktops usually have much bigger hard drives, and you are much more likely to create and remove lots of files there
<hallyn_> davidcalle: ah, interesting, thanks.  now, it would be better if it also searched manpages.ubuntu.com :)
<hallyn_> (and if 'man:' was a shortcut :)
<infinity> davidcalle: That really needs... What hallyn_ just said.
<infinity> davidcalle: The "man: as a shortcut" bit, not the remote search bit.
<infinity> (Though the latter might also be neat)
<infinity> Then again, "Ctrl-Alt-T ; man dpkg" is actually faster, since the silly GUI man reader is slow.
<hallyn_> rbasak: is your next uvtool upload also going to fix launching apport every time an xception is raised bc you use a bad cmdline arg?
<hallyn_> infinity: agreed
<davidcalle> I know... hallyn_, infinity, the keyword issue can be fixed manually in the config file (/usr/share/unity/scopes/code/manpages.scope)
<hallyn_> infinity: the conv started because i said i installed btrfs-tools to ge tthe manpages, so i thought the scope might search manpages.u.c...  *there* the scope woudl e faster than launching a browser or installing the pkg :)
<infinity> hallyn_: Yeahp, indeed.  The remote search would be handy.
<hallyn_> infinity: except, of course, for the fact that you have to hit ctrl-alt-t 2 or 3 times to get it to work :)
<infinity> hallyn_: I... Do?
<rbasak> hallyn_: I'd love to know how to fix that.
<infinity> Works fine here.
<davidcalle> hallyn_, good point. Now, waiting for someone to provide an API for manpages.u.c ;)
<hallyn_> infinity: not on any of my laptops
<infinity> hallyn_: Weird.  It's my most typed sequence of keys here, I'd know if it was goofy for me.
<infinity> hallyn_: Your laptops hate you.
<hallyn_> infinity: true.  all hw hates me.
<infinity> hallyn_: Oh.  But do you still have Alt bound to the HUD?
<hallyn_> no, windows
<hallyn_> rbasak: i bet stgraber knows how
<rbasak> hallyn_: bug 1245641. Perhaps s/whoopsie/apport/.
<infinity> hallyn_: That's one of the few non-stock things I do, I relocate the HUD shortcut to something I never use (F12, I think?), so it doesn't abuse my Alt.
<ubottu> bug 1245641 in uvtool "CLI syntax errors should not trigger whoopsie" [Undecided,New] https://launchpad.net/bugs/1245641
<hallyn_> oh, hud
<hallyn_> right
<hallyn_> infinity: lemme try that, thanks!
<hallyn_> yup, that's definately better
<hallyn_> course my laptops still hate me, now they'll just catch on fire to spite me
<hallyn_> rbasak: BUT, i'm creating and desroying vms with uvt-kvm.  this is a good start :)  now i need to get it running on precise.
<wgrant> pitti: Oh, that finally worked. A pleasant surprise.
<rbasak> hallyn_: it's in the cloud-tools pocket. My latest upload fails the test suite because the test I'm using is too new for Precise. I need to fix it. But you could disable tests, I suppose. I probably should make nocheck work as well :-/
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<hallyn_> rbasak: i'd recommend making '-l ubuntu' the default for uvt-kvm ssh
<rbasak> hallyn_: I'd never considered that, but it sounds reasonable - thanks.
<mitya57> barry: re jquery-* packages that coverage depends on: I think it may make sense to file a MIR for them.
<mitya57> barry: nose now also dep-waits on them, and fails to build without them (debian #726695)
<ubottu> Debian bug 726695 in src:nose "nose: FTBFS: CoverageException: Couldn't find static file 'pyfile.html'" [Serious,Fixed] http://bugs.debian.org/726695
<mitya57> what do you think?
<barry> mitya57: yeah, looks like that probably makes sense.  would you be able to do that?
<barry> (file the MIR that is)
<mitya57> barry: can't file it right now, but will do
<mitya57> in fact, those jquery plugins are already in main as part of our current coverage tarball
<barry> mitya57: awesome, thanks.  are you planning to do a sync for python-coverage from sid also?
<mitya57> barry: I'm not sure if we can drop the Breaks:
<barry> mitya57: s/sync/merge/ ? :)
<mitya57> Yes :)
<mitya57> But it'll be in sync again after trusty release
 * barry nods
<barry> mitya57: if you're planning on doing it, i'll just wait for the mp :)
<mitya57> barry: actually, I looked again at the changelog and it seems we don't need the breaks
<mitya57> it was added because python-coverage used to ship python3 module
<mitya57> but the precise version is python2-only
<mitya57> ... and we don't support upgrades from q/r to t
<barry> mitya57: is that the only delta we carry?
 * barry is in a meeting and can't look right
<barry> now
<mitya57> barry: last time I checked I decided that jquery stuff and breaks: were the only delta
<mitya57> But I'll check that again before filing a sync request
<barry> mitya57: thanks!
<mitya57> you are welcome :)
<brendand> i'm having a weird issue with tagging bugs via launchpadlib
<brendand> if i get a bug via one of its subtasks then i can't update its tags and save it
<brendand> if i get it directly via lp.bugs then it works
<doko> barry, reportlab is ready for 3.x upstream. needs a bit of messaging, and maybe packaging from a separate source for now. but should be ready later this year or in January
<cjwatson> brendand: Sounds like bug 254901.
<ubottu> bug 254901 in launchpadlib "appending tags to bug.tags is not supported properly on lp_save()" [Low,Triaged] https://launchpad.net/bugs/254901
<barry> doko: fantastic news, thanks!
<brendand> cjwatson, i saw that one before :) but this isn't it
<brendand> cjwatson, lets say i have a task
<brendand> cjwatson, that task has a .bug attribute
<brendand> cjwatson, that is the parent bug
<cjwatson> if it isn't that bug then I don't know sorry
<brendand> cjwatson, if i update the tags like 'bug = task.bug; bug.tags = bug.tags + ['new']; bug.lp_save()' then it doesn't add that tag in launchpad
<cjwatson> sometimes foo = lp.load(foo.self_link) is needed for odd reasons I generally don't bother to track down :)
<brendand> cjwatson, maybe
<brendand> cjwatson, i think i have a workaround anyway. but i'll try that
<tedg> jodh, Is there any way to set multiple environment variables at once using the Upstart DBus interface?
<tedg> Seems that setenv can only do one at a time.
<jodh> tedg: limited to 1 at a time atm, but feel free to raise a bug request :)
<tedg> jodh, Heh, okay.  Let me see if switching from shelling out initctl to using DBus saves me enough time.
<seb128> bdmurray, hey, I just uploaded https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=webkit, I would appreciate a review if you can get it in today ... that should fix s-c being very unstable/hitting Xerrors
<bdmurray> seb128: okay.  I was looking at your software-properties-gtk merge proposal yesterday and commented on it
<seb128> bdmurray, I saw, thanks for that
<seb128> I think mvo still wanted to understand how those packages could have no candidate
<seb128> I didn't manage to end up in that situation
<seb128> e.g I tried installing a driver from restricted and drop the source
<bdmurray> What I was suggesting was that with a fresh install all packages will have no candidate.
<seb128> but you still get a candidate for the locally installed version in those cases
<bdmurray> As apt-get update hasn't been run.  Well a fresh install with no internet connectivity.
<seb128> well, you have no candidate but you wouldn't have drivers listed in the Ui either then
<seb128> that bug happens when a driver is listed and has no candidate
<seb128> didrocks suggested it might be people e.g installing nvidia drivers from the nvidia run install script
<seb128> e.g out of the packaging system
<seb128> but I couldn't test that, they installer checks for hardware and bails out if you have an nvidia card matching the driver
<mdeslaur> xnox: mind if I steal your php5 merge?
<bdmurray> seb128: I could query the crashdb to see if all of the instances have an origin of unknown if that would help
<bdmurray> hmm, those four instances I've looked at have wl in NonfreeKernelModules
<seb128> bdmurray, they don't, I've been through a few on https://errors.ubuntu.com/problem/55c1babf9ec1556365267f9ae7de740aec64d777 ... a good part have, but that doesn't seem the only case where it happens
<seb128> bdmurray, see e.g https://errors.ubuntu.com/oops/5a0f326a-62e4-11e3-86e6-e4115b0f8a4a
<bdmurray> well okay, if you need more information just let me know
<xnox> mdeslaur: yes please, go ahead.
<seb128> bdmurray, will do, thanks
<seb128> bdmurray, if you have any idea what might happen to trigger the issue/manage to reproduce it, it would be useful
<seb128> bdmurray, mvo wanted a sources.list and apt info from somebody having the bug to understand it
<seb128> the patch I made should stop the reports but wouldn't fix the underlining reasons
<pitti> stgraber, xnox: I think http://people.canonical.com/~pitti/scripts/fstrim now checks everything we agreed to in the discussion, and I tested it with various scenarios
<pitti> review/comments appreciated!
<xnox> pitti: what's the plan for lvm/mdadm? should i be enabling trim on those by default as well? but then fstrim script above will ignore them?
<pitti> xnox: why will it ignore them?
<pitti> xnox: ah right, due to hdparm
<pitti> xnox: I'll investigate this tomorrow; if fstrim can "look through" them, then all is well (but we need to ignore "not supported" errors from it); otherwise I wouldn't know how to call fstrim on those
<pitti> xnox: I certainly hope that fstrim works on those
<pitti> (or discard)
<pitti> so, experimenting with this is interesting indeed
<xnox> pitti: i believe there is lvm2.conf option to enable trim support and then one can trim volumes and it propagates, or some such.
<xnox> pitti: why libgirepository1.0-dev depends on gobject-introspection package? and why is libgirepository1.0-dev is not multiarch-arch same?
<pitti> xnox: GI is currnetly not multiarch capable
<pitti> to make that, /usr/lib/girepository-1.0/ would need to be moved to the <arch> directory, and libgirepository be taught about that
<pitti> xnox: as for the dependency, I'm not sure
<pitti> xnox: doesn't look immediately necessary, I just don't know how many packages rely on having the g-ir-compiler etc. being pulled in through it
<pitti> xnox: as usually you need the tools as well
<xnox> pitti: right, but at the moment i can install libgirepository-dev (and or compile/link against it) for a single arch at the time, sans installing gojbect-introspection (or installing it for other architectures)
<xnox> pitti: or have it installed when I don't require / planning to run gobject-introspection at all.
<xnox> this is blocking cross-building & bootstrapping. I'll look into what fallout this may cause, and look into transitioning.
<xnox> pitti: as usually if something is using tools from gobject-introspection, it should be directly depending on it (per policy) instead of relying on transitive dependencies.
<pitti> xnox: i. e. gobject-introspection should be M-A: foreign
<xnox> pitti: that is also true.
<xnox> pitti: (despite not yet being able to do cross-arch introspection, but it's ok)
<xnox> we know it's broken, but at least it should be installable.
<pitti> xnox: well, the tools ought to work for a foreign architecture
<pitti> it's the library which needs its lookup paths adjusted to multiarch
<xnox> i believe last time cjwatson was looking into this, they didn't.
<pitti> xnox: oh, because they wouldn't find the right libgirepository-1.0-1
<xnox> pitti: for now, i've dropped bogus dependency on libgirepository-dev and i'm unblocked =) this can be revisitted later.
<pitti> xnox: ack
<seb128> xnox, do you plan to fwd those accounttservice changes to Debian?
<xnox> seb128: yes
<seb128> good
<seb128> xnox, thanks
<xnox> seb128: btw why are we at -0ubuntuX ?
<pitti> xnox: actually, if we drop the static lib, the only thing which is arch specific in -dev is the pkgconfig
<pitti> xnox: and multi-arching that ought to be rather easy
<seb128> xnox, because our upstream version is newer than the one in debian?
<xnox> seb128: ah, horum. yeah i see.
<cjwatson> pitti: AFAIK gobject-introspection needs to (a) be converted to use AC_COMPUTE_INT and friends to get type sizes on the target architecture (b) be treated somewhat like pkg-config - that is, you need a version of g-i built for your host arch but aimed at a different target arch
<cjwatson> or like a cross-compiler I suppose
<cjwatson> it's not at all trivial sadly
<cjwatson> the tools will produce wrong answers for a foreign architecture right now, or at least would last time I looked
<dobey> cjwatson: hey! are you a reasonable person to poke about extras.ubuntu.com? it doesn't have trusty archives yet, and so do-release-upgrade bails on the index files not being available from what i can tell
<cjwatson> no
<cjwatson> IIRC it's managed by the app review board
<dobey> ah ok
<tarpman> dobey: bug 1244050 (and bdmurray's comment there)
<ubottu> bug 1244050 in ubuntu-release-upgrader (Ubuntu) "upgrade to trusty fails because of failure to fetch from extras.ubuntu.com" [Medium,Triaged] https://launchpad.net/bugs/1244050
<dobey> right
<dobey> tarpman: which doesn't help me immediately. and there are still two separate issues
<slangasek> the ARB is defunct in practice; I don't believe we're going to see extras.u.c in trusty, which reduces the number of issues to 1
<slangasek> (i.e., having do-release-upgrade not care)
<xnox> slangasek: i think last time we've tricked highvoltage into copying a package into a new pocket and removing, to get the indexes generated for the new codename, but obviously not have any packages published.
<slangasek> yes; but there's no reason we should do that if it's defunct
<xnox> cjwatson: the linaro anaylysis seems to say that output can be made architecture agnostic, and that it is the same if the register widths are the same (sans couple of issues e.g. gl vs gles)
<xnox> cjwatson: https://wiki.linaro.org/PeterPearse/GobjectIntrospection
<xnox> cjwatson: i'd rather introspection data become arch:all then building cross-gir-scanners
<slangasek> "if the register widths are the same"?
<xnox> slangasek: between HOST and BUILD arches.
<slangasek> what madness is masked by that innocent conditional?
<slangasek> ok, but what's a "register width"?
<xnox> slangasek: i'm quoting https://wiki.linaro.org/PeterPearse/GobjectIntrospection
<slangasek> so I would assume that means word size
<xnox> slangasek: i'm guessing that i386 gir/types files happened to be same as on armel, sans gl/gles.
<cjwatson> xnox: I'm not sure I was ever convinced by Peter's analysis, and I did mine after his
<slangasek> which means we can't usefully build arch: all typelibs
<xnox> slangasek: i would think word size was meant as well.
<cjwatson> xnox: I'm pretty sure he analysed one specific pairing and got reasonably lucky, rather than analysing the underlying issues.
<slangasek> since arch: all builds on i386, and nowadays most of what we're crossing is for 64-bit (e.g., arm64)
<xnox> slangasek: if we could push the size out of typelib and define it for target architecture elasewhere.
<cjwatson> xnox: So, no, sorry, I don't credit the Linaro analysis here.
<xnox> surely we do know the sizes for default types and G types for glib and thus we don't need to encode it everywhere, and instead use a symantic value.
<cjwatson> This is what AC_COMPUTE_INT etc. is for.
<cjwatson> Let us not get into the insanity of hardcoding type sizes ...
<cjwatson> girparser.c appears to intentionally flatten the integer types (gint, glong, etc.) into the basic types (gint32, gint64, etc.).  I don't know why and it would seem worth looking into before doing anything about it
<cjwatson> I agree it would be better if typelibs could be arch-indep, but I don't know how difficult it is to get there from here, and I'm also concerned about architecture-dependent code in the thing being analysed
<shadeslayer> backportpackage seems to be broken?
<shadeslayer> http://paste.ubuntu.com/6562770/
<tarpman> shadeslayer: should it be -u telepathy-kde/ppa ?
<shadeslayer> huh
<shadeslayer> ppa: used to work before
<tarpman> er, ppa:telepathy-kde/ppa
<wookey> what magic /win 18
<wookey> doh
<Noskcaj> Can someone take a look at the new version of  libhugetlbfs? It adds fully arm (inc. arm64) support
<Noskcaj> doko, I think you where the last uploader
<bdmurray> hallyn_: I think you typoed the bug number (1235649) in your cgroup-lite upload to precise's proposed queue
<hallyn_> do
<hallyn_> h
<hallyn_> bdmurray: that was meant to be bug 1257857
<ubottu> bug 1257857 in cgroup-lite (Ubuntu Precise) "cgroup-lite fails to install in container in precise" [High,In progress] https://launchpad.net/bugs/1257857
<hallyn_> bdmurray: shall i re-upload, or can you fix that in-stream?
<bdmurray> hallyn_: no, I can't at least as far as I know.
<hallyn_> ok, will re-push, thanks
<hallyn_> (pushed)
<stgraber> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tarpman> hi, would some kind sru person let me know the status of accountsservice in precise-proposed? it's been there (and verified) for a while. just wondering whether it's "keep waiting" or needs attention from anyone
<dobey> "a while" is < 7 days?
<tarpman> that short? I must have misread something, my apologies
<xnox> tarpman: it's stuck because only one of the two bugs is verified.
<xnox> tarpman: from http://people.canonical.com/~ubuntu-archive/pending-sru.html
<xnox> tarpman: it's sru for bug #1004515 and bug #1067414
<ubottu> bug 1004515 in accountsservice (Ubuntu Precise) "segfault in accounts-daemon when logging in / gdm crash if user account is added or deleted" [Low,Fix committed] https://launchpad.net/bugs/1004515
<ubottu> bug 1004515 in accountsservice (Ubuntu Precise) "duplicate for #1067414 segfault in accounts-daemon when logging in / gdm crash if user account is added or deleted" [Low,Fix committed] https://launchpad.net/bugs/1004515
<xnox> tarpman: while first one is verify the second one is not.
<xnox> ah, they are duplicates.
<xnox> tarpman: right, i've marked the duplicate bug as verification-done
<tarpman> xnox: thank you!
<xnox> bdmurray: is that correct behaviour that duplicate bugs are considered by pending-sru report? (one duplicate of the other, yet one was verification done and the other one was still needed)
<xnox> tarpman: it should become green and good to go, after next report regeneration.
<tarpman> xnox: much appreciated :)
<bdmurray> xnox: pending-sru looks at the changelog to see which bugs are fixed and I'd expect duplicate consolidation to be done before a package was uploaded to -proposed
<xnox> bdmurray: ok.
<bdmurray> xnox: well I guess something should be done to the report to identify SRU bugs that have been marked as a duplicate as people do crazy things
<xnox> bdmurray: well, i don't think it happens that often, does it?
<bdmurray> xnox: no, so I'll make it a wishlist thing
<xnox> bdmurray: it could print #102 (#99, #83), #83, #79. where in the brackets are bug numbers of duplicates.
<xnox> bdmurray: since e.g. regression comment might be on the duplicate, instead of master bug.... then also it would be easier to spot if changelog has listed duplicate bugs.
<bdmurray> xnox: that'd be a crazy long list
<xnox> =/
<xnox> yeah, for crazy bugs it would be.
<xnox> bdmurray: then #bug (#masterbug), if #bug happens to be marked as duplicate? that would be at most double the bug references.
<xnox> (if all changelog mentioned bugs became dupes)
<bdmurray> xnox: I was thinking about just changing the color if it is a duplicate becasue that is wrong
<xnox> oh, nice. that would be lovely.
<bdmurray> but then we'll have some angry fruit salad
<xnox> bdmurray: i pick 50 shades of gray
#ubuntu-devel 2013-12-13
<pitti> Good morning
<pitti> cjwatson: g-i> thanks for the heads-up
<lucidfox> Question
<lucidfox> Where and how do I ask for my Ubuntu Member status to be revoked?
<pitti> lucidfox: you can launch any LP team (like https://launchpad.net/~ubuntumembers) with the "Leave this team" button
<pitti> lucidfox: err, "launch" â  "leave", sorry
<pitti> in leavepad :)
<lucidfox> heh
<pitti> infinity: wow! https://launchpad.net/builders
<pitti> infinity: we have multi-arch builders now?
<pitti> infinity: so if I was to throw 823948239 langpacks at them, they'd  all build them in no time? :-)
<StevenK> pitti: We have for a little while. wgrant is who you want to buy a fair bit of beer.
<pitti> wgrant: woo! many thanks for this
<pitti> lftp wgrant
<pitti> lcd /cellar/beer-rack/
<pitti> mput *
<StevenK> And now wgrant is suffering alcohol poisioning?
<StevenK> :-P
<wgrant> pitti: Yeah, you can now drown the amd64 buildds as well :D
<pitti> first trusty langpacks built and tested, throwing buildd-wards then
<pitti> wgrant: I guess https://dev.launchpad.net/Translations/LanguagePackSchedule is not current, right?
<pitti> wgrant: do we build trusty langpacks on Tue and Thu now (in LP)?
 * pitti watches all his little minions on https://launchpad.net/builders
<wgrant> pitti: I've updated that page
<wgrant> At least the export column
<pitti> thanks
 * pitti desperately looks for an "Edit" link
<wgrant> You need to log in first
<pitti> Logged in as   pitti
<wgrant> Ah, you probably need to be a member of ~launchpad-doc
<wgrant> What should the PPA schedule look like?
<pitti> wed, fri: trusty, thu: saucy, tue: precise (currently disabled)
<pitti> wgrant: i. e. export day + 1
<wgrant> Right
<pitti> wgrant: thanks!
<wgrant> np
<dholbach> good morning
<pitti> xnox, stgraber: FYI, it seems fstrim doesn't support LVM (I created a LUKS and an LVM from two PVs), too bad
<pitti> xnox, stgraber: and neither does discard
<pitti> curiously, hdparm -I /dev/mapper/testlvm-fivem works (it "looks through" the mapper)
 * pitti does some RTFM, "fstrim lvm" has plenty of google juice
<pitti> ah, /etc/lvm/lvm.conf needs to have issue_discards = 1
<zyga> hi
<zyga> running trusty daily, I cannot log in, while mouse works okay in lightdm keyboard seems to just be ignored (apart from being able to switch to other vt)
<zyga> has anyone seen this issue?
<zyga> currently on lighdm 1.9.5-0ubuntu1
<pitti> stgraber: so we'll need to add the "allow-discards" option to crypttab in partman; is that something you feel up to? (I added an unowned WI)
<pitti> stgraber: the option isn't enabled by default in cryptsetup because it exposes additional information on the raw device (according to the manpage), but for a "full disk encryption" setup we certainly want it
<RAOF> I'm not sure that we do want it for full disk encryption? It leaks filesystem details.
<pitti> the alternative is "your SSD sucks after a few weeks of usage"
<pitti> "For  example,  information leaking filesystem
<pitti>               type, used space, etc. may  be  extractable  from  the  physical
<pitti>               device  if  the  discarded  blocks  can  be located later."
<pitti> that sounds a bit fuzzy, not sure how big the impact is?
<pitti> i. e. if you get the raw SSD, look for discarded/non-discarded blocks, and from their pattern make assumptions about the state of the disk
<RAOF> Yeah, probably not much.
<pitti> but IMHO that's an acceptable compromise to do to keep your SSD in a working state in the first place
<pitti> if you are concerned with that, the first thing you'd need to do is to completely fill your drive once
<pitti> and then live with getting 1/50th of its normal write performance
<xnox> pitti: those that want privacy with ssd, would use self-encrypting drives. in which case one cannot analyze / infer anything from the filesystem, since block devices are not expose until after ATA unlock.
<pitti> xnox: ah, good point
<xnox> pitti: thus imho, trim should be enabled.
<xnox> pitti: then again why use cryptsetup with self-encrypting drive.... is beyond me =)
<pitti> hm, issue_discards doesn't seem to work for me (LVM); there's debian bug 717313, but it didn't get an answer
<ubottu> Debian bug 717313 in lvm2 "lvm2: Enable issue_discards = 1 automatically on non-rotational (SSD) disks?" [Wishlist,Open] http://bugs.debian.org/717313
<xnox> pitti: hm =( last time i looked into this, i thought that it is safe enough these days to enable "issue_discards" unconditionally, it just wouldn't do anything on spinny drives.
<xnox> pitti: i can test it harder here on an ssd. as well.
<pitti> xnox: yes, it says it's only having an effect if kernel and drive support it
<pitti> xnox: but I enabled it, update-initramfs, reboot, and still fstrim says "invalid ioctl"
<pitti> (IOW, not supported)
<pitti> xnox: oh, perhaps I need to do this before pvcreate/vgcreate/lvcreate, /me tries
<pitti> xnox: oh, nevermind; I formatted it with ext2, that's the bit which breaks it
<zyga> running trusty daily, I cannot log in, while mouse works okay in lightdm keyboard seems to just be ignored (apart from being able to switch to other vt)
<zyga> is this a known issue, any way to work around it to do stuff?
<pitti> xnox: so, issue_discards isn't necessary for fstrim, only if you modify the LVM structure; we should enable it anyway, though
<xnox> pitti: excellent \o/
<pitti> xnox: so, for "normal" partitions I do an hdparm -I check and fstrim; for devmapper I do fstrim 2>/dev/null || true
<pitti> as decomposing the LVM to its PVs and running hdparm on them is probably way more costly than just tryign to call fstrim
<pitti> xnox: does that seem ok to you?
<xnox> yeap.
<pitti> xnox: now my fstrim cron job works for normal partitions, cryptsteup, and LVM
<xnox> which package is it going to live in?
<pitti> xnox: http://people.canonical.com/~pitti/scripts/fstrim
<pitti> xnox: hm, how about util-linux?
<pitti> (that ships fstrim)
<pitti> xnox: ideas appreciated
<xnox> sounds good, if util-linux maintainer would be ok with that. lamont infinity ^
<GunnarHj> xnox: Hi Dimitri!
<xnox> GunnarHj: holla! =)
<GunnarHj> xnox: Have you noticed bug 1260604?
<ubottu> bug 1260604 in accountsservice (Ubuntu) "GDM does not work with new accountsservice 0.6.35-0ubuntu5" [High,Triaged] https://launchpad.net/bugs/1260604
<xnox> GunnarHj: yes, i have. and asked for logs on it.
<GunnarHj> xnox: Aha, see that now. ;-)
<Laney> xnox: http://paste.debian.net/plain/70639
<Laney> from ricotz, haven't looked into it
<GunnarHj> xnox: It's easy to install and switch to GDM for test purposes.
<xnox> Laney: that seems right.
<xnox> Laney: will upload, or can ricotz upload it?
<Laney> nope
<Laney> you do it if you confirm it fixes the problem
<xnox> Laney: ack.
<pitti> xnox, lamont, infinity: filed debian bug 732054 FTR
<ubottu> Debian bug 732054 in util-linux "util-linux: Add cron job for regular SSD trimming" [Wishlist,Open] http://bugs.debian.org/732054
<seb128> dpm, pitti: can one of you approve https://translations.launchpad.net/ubuntu/trusty/+source/evolution/+imports ?
<seb128> the 3.10 template
<seb128> the new langpacks still have 3.8 which means no translation since we are on 3.10 :/
<seb128> same for https://translations.launchpad.net/ubuntu/trusty/+source/evolution-data-server/+imports
<pitti> seb128: I can't approve :/
<seb128> :-(
<seb128> let's see if dpm can
<seb128> we might need wgrant or somebody with lp powers?
<pitti> meh, BP WI diff emails are broken, they only show the removals
<seb128> pitti, since when? I got some correct ones yesterday
<pitti> for several months already
<seb128> are you sure it's not your email client?
<pitti> also, it seems if you change WIs with the Ajaxy bits, when saving it back it shows the old one
<pitti> you need a page reload to update
<pitti> seb128: yes
<pitti> its LP
<seb128> wfm
<pitti> i. e. when changing them twice, you need to reload, otherwise you'll destroy your first changes
<pitti> gema had it as well, I'm not alone
<Laney> FF?
<pitti> Laney: yes
<pitti> (our default browser, I might point out :) )
<Laney> yeah, just checking
<Laney> I use it too (and haven't seen that)
<pitti> but as the mails reflect that, it doesn't seem browser specific?
<Laney> seems like you were describing two issues
<seb128> pitti, wfm
<seb128> I just editing https://blueprints.launchpad.net/ubuntu/+spec/client-s-system-settings-panels in firefox
<seb128> changed charles in charlesk
<seb128> and the page had the correct content without reload
<seb128> or refresh
<Laney> http://paste.ubuntu.com/6565987/
<Laney> I did that yesterday
<seb128> right, that's the email I got
<seb128> correct diff
<brendand> pitti, fstrim script. handy
<seb128> pitti, maybe QA blueprints have something special that confuses lp?
<Laney> the diff does look a bit weird actually
<GunnarHj> xnox: ricotz's suggestion is not sufficient to fix bug 1260604. I added my ~/.xsession-errors to the bug.
<ubottu> bug 1260604 in accountsservice (Ubuntu) "GDM does not work with new accountsservice 0.6.35-0ubuntu5" [High,Triaged] https://launchpad.net/bugs/1260604
<Laney> why are there all those Work items: sections?
<Laney> unless I did actually break that
<pitti> seb128: no idea what the difference is; they are ubuntu specs like everything else
<seb128> pitti, yeah, me neither, needs some lp debugging I guess :/
<seb128> pitti, I just wanted to point out that the feature is not broken across the board
<pitti> seb128: good to know
<seb128> Laney, but yeah, that diff of yours is buggy as well, it has several "+ Work items for ubuntu-14.01:"
<Laney> so I can believe some parser is going wrong
<seb128> pitti, did you file a lp bug about that yet?
<pitti> seb128: gema said she was going to back then, I'll have a look
<caribou> where is the best place (i.e. irc room) to ask debian packaging specific questions ?
<seb128> caribou, you can ask here I guess
<caribou> seb128: thanks, but I may have found the answer myself
<seb128> caribou, if you need confirmation you can still ask here ;-)
<caribou> seb128: I need to run a script only at build time & needed to know where it would fit best
<seb128> debian/rules?
<caribou> seb128: thought of it, but it's a bunch of subshell cmds so it doesn't fit the Makefile format
<caribou> seb128: I created a script in debian/ & used 'override dh_auto_build" to cal lit
<seb128> caribou, well, you can always write a shell script in debian/ and call that from the rules
<seb128> caribou, +1 ;-)
<caribou> seb128: then all good then ;) thanks
<seb128> yw!
<dpm> seb128, pitti, I was on the phone, let me have a look at it now (re: Evo translations)
<seb128> dpm, hey, thanks
<dpm> np, evolution is a bit of an annoying template, as they version the .pot file and we have to be careful we don't mess up LP's translation sharing and template names
<seb128> right
<seb128> we screwed in saucy
<seb128> we didn't approve the 3.8 template, so the langpack shipped with 3.6
<seb128> which means no translation
<dpm> ah, let me fix saucy too, then
<dpm> it seems someone fixed the domain and .pot import path in saucy already, let me have a look whether the 3.8 imports worked there
<tseliot> pitti: I think I'm going to enable hybrid graphics in ubuntu-drivers-common (in 14.04) following the logic of bug #1260683 (which is really about Jockey in Precise). Any thoughts?
<ubottu> bug 1260683 in jockey (Ubuntu Precise) "Jockey should not make NVIDIA Optimus available on the desktop" [High,In progress] https://launchpad.net/bugs/1260683
<dpm> seb128, pitti, so - saucy: everything seems fixed now, we need a full language pack export and release to get Evo translations shipped; - trusty: imports for the 3.10 .pot files should work now, will need to watch the imports queue for the next hour or so if they really get imported
<seb128> dpm, ok, thanks for fixing those!
<pitti> tseliot: I thought we already don't offer the nvidia driver on hybrid systems in u-c-commmon? or did you change that as we can properly support hybrid now?
<pitti> tseliot: so, what do you want to change, offer nvidia only if there is no battery, or something such?
<dpm> seb128, np, if I'm away happyaron can probably help with templates, as he's got permissions as part of the ubuntu-translations-coordinators team. I'm happy to add anyone else to the team in LP if they want to help. They'd simply need to have read https://wiki.ubuntu.com/UbuntuTranslationsCoordinators and be familiar with LP
<seb128> dpm, ok, great
<tseliot> pitti: in u-d-c I plan to check if it's a laptop. The logic is already in nvidia-prime, so I think I can reuse that code
<tseliot> pitti: so, yes, we can look for /sys/class/power_supply/ and  /proc/acpi/button/lid
<cjwatson> pitti: multi-arch builders - isn't it glorious
<pitti> cjwatson: *sheds a tear*
<pitti> it's a joy to look at
<davmor2> cjwatson: you seem overly overjoyed by this comment.  So I guess it's hugely important :)  So congratulations :)
<xnox> pitti: seb128: i also noticed that email diffs for blueprints, do not match reality.
<seb128> xnox, do you have any idea when that started?
<seb128> infinity, wgrant, cjwatson: do you know if the code on launchpad that generates diff for blueprints changed?
<cjwatson> don't know sorry
<seb128> ok, thanks
<xnox> seb128: no, i got first notification last night. Where a change of the workitem, arried as "- workitem" without matching "+ workitem new description" and thus I got a ping "why did you drop that workitem" on irc.
<seb128> k
<seb128> diwic, hey, is https://bugs.launchpad.net/bugs/1131220 still on your todolist?
<ubottu> Ubuntu bug 1131220 in gnome-control-center (Ubuntu) "[soundnua]: gnome-control-center crashed with SIGSEGV in gvc_mixer_control_lookup_device_from_stream()" [Medium,Incomplete]
<wgrant> xnox, seb128: I came upon a potential issue in the caching of workitems a few months ago, but I didn't get to the bottom of it
<wgrant> I didn't think it was affecting emails too
<wgrant> Do you have some idea of when it started?
<xnox> wgrant: the ajax behaviour is weird. click edit button; change workitem; confirm. and on display the workitem is gone (and email is sent with workitem gone), yet on page refresh it shows the updated workitem description.
<xnox> wgrant: to be honest the cache/ajax behaviour we can live with. But, wrong diff sent in emails is sad. Can email diffs be generated from force updated cache?
<seb128> xnox, the ajax issue is a problem because if you click edit again, you undo your previous changed
<xnox> wgrant: well, we only started using workitems since last vUDS..... i think previous vUDS was ok. so a window of 3 months?
<seb128> changes
<wgrant> They're probably the same bug.
<xnox> seb128: oh, that's bad =(
<seb128> wgrant, pitti mentioned it today, xnox saw it recently
<seb128> wgrant, I would say it's fairly recent, but I don't think we have too much details
 * seb128 checks his blueprint emails
<pitti> wgrant: I think I heard it first from gema during the QA team sprint in Boston, hang on
<pitti> wgrant: so around september 12
<wgrant> Right, thanks.
<wgrant> I don't see a bug. Could someone please file one?
<pitti> I'll do
<pitti> seb128, xnox, wgrant: bug 1260714
<seb128> wgrant, pitti: looking in my blueprint inbox the first "weird diff" is from 11/28, but we don't use blueprint that much recently and the ones I had in the previous weeks before that are mostly simple edit where a couple of lines were changed (and those seem less likely to hit the issue)
<ubottu> bug 1260714 in Launchpad itself "Does not properly update when editing work items" [Undecided,New] https://launchpad.net/bugs/1260714
<seb128> pitti, danke
<pitti> feel free to adjust the title to something better, of course
<diwic> seb128, yes. I was sprinting in Taipei entire last week, and been mostly on sick leave this week.
<seb128> diwic, ok, get better!
<wgrant> seb128, pitti, xnox: Thanks for pointing that out, fixed.
<pitti> wgrant: nice, thanks!
<seb128> wgrant, oh, nice that you figure it out, thanks!
<wgrant> (the notification and display bugs were indeed the same thing)
<dholbach> cjwatson, thanks a lot! :)
<ricotz> GunnarHj, please test https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+sourcepub/3726442/+listing-archive-extra and make sure you restart gdm after
<plars> pitti: did you happen to see my comments on bug #1258245 - any chance of getting that group added for syslog, or does it create too many concerns?
<ubottu> bug 1258245 in rsyslog (Ubuntu) "syslog user can't write to /dev/ttyS0" [Undecided,New] https://launchpad.net/bugs/1258245
<pitti> plars: seems acceptable to me
<seb128> dpm, wgrant: do you know where is launchpad importing the translation templates from?
<wgrant> seb128: What do you mean?
<seb128> wgrant, https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports
<wgrant> Ubuntu templates are imported from source packages, as alway
<wgrant> s
<seb128> wgrant, the recent gtk 3.10 update didn't make it there
<seb128> the pot is in https://launchpad.net/ubuntu/trusty/+upload/6587684/+files/gtk%2B3.0_3.10.6-0ubuntu2_i386_translations.tar.gz
<seb128> which is the translation file from the build
<seb128> it's also in the srcdir
<seb128> that's from https://launchpadlibrarian.net/159463876/buildlog_ubuntu-trusty-i386.gtk%2B3.0_3.10.6-0ubuntu2_UPLOADING.txt.gz
<seb128> wgrant, any idea how to debug that?
<wgrant> seb128: Hm, weird
<dpm> seb128, wgrant, it might be that LP did not import the pot file because the path in the source package changed
<seb128> dpm, I doubt it did
<seb128> it should still be po/gtk30.pot
<wgrant> Also it should have still appeared in the queue.
<seb128> dpm, wgrant: https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports also doesn't list any .po which is weird
<seb128> since the tarball I downloaded has those
<dpm> wgrant, but it is in the queue, is it not? -> https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports
<seb128> dpm, no, those are from 2013-11-01
<wgrant> dpm: There should be something from December, I thought
<seb128> that's old gtk 3.8
<wgrant> There was an upload two days ago
<seb128> gtk 3.10 was this week
<dpm> ok, I see
<wgrant> And I see that the jobs were run
<dpm> in any case, it's also strange that the old templates in that queue were not imported, either
<seb128> dpm, wgrant: can I upload the template by hand or do you prefer to keep the buggy state for debugging?
<dpm> seb128, I'll defer to wgrant to comment on that, as I wouldn't know how to debug LP, but from my side, it's fine to manually upload
<wgrant> seb128: I think it's fine to upload manually.
<wgrant> I can't easily debug it tonight.
<seb128> wgrant, no hurry, do you want a bug report for it?
<wgrant> seb128: That'd be good
<arun__> guys, the new language has been added to the debian ; now what should I do to obtain the language in the Ubiquity ?
<xnox> arun__: as of when new language / translations are uploaded into d-i components in Debian, and as of then those translations are merged into ubuntu d-i components and then finally ubiquity reuploaded.
<xnox> arun__: so it's automatic, but it does depend on uploads of d-i components in debian & ubuntu
<xnox> arun__: there are some ubiquity specific strings, those would need to be translated on launchpad. but those are not the majority of installer used strings.
<xnox> (although usually more visible)
<arun__> xnox: the language option must be available in the ubiquity thats all ; will that remained to ubiquity from debian ?
<xnox> arun__: define "available" ? cd boot-splash language selection, or ubiquity greeter list of languages, or keyboard selection list of languages?
<xnox> i don't understand this sentence "will that remained to ubiquity from debian ?" can you say it in another way?
<seb128> dpm, wgrant: https://bugs.launchpad.net/launchpad/+bug/1260754
<ubottu> Ubuntu bug 1260754 in Launchpad itself "Translation not imported from source to launchpad" [Undecided,New]
<arun__> xnox: I mean that, if the language selection is available in debian installer, will that remain the same in  the ubiquity installer ??
<dpm> thanks seb128, subscribing
<xnox> arun__: after a delay, it will eventually.
<arun__> xnox: oh ok thanks !!!
<xnox> arun__: it depends when ubiquity and d-i was last rebuild.
<arun__> xnox: ok
<wgrant> seb128: Hum, I think I see why. I'm not sure if the manual upload will work.
<wgrant> The whole import system is pretty much a total mess.
<wgrant> It tries to eliminate duplicates
<wgrant> An upload from a package will helpfully ignore any files where duplicates can't be resolved.
<seb128> :/
<wgrant> seb128: It probably isn't normally a problem, because there won't be dupes once import processing is enabled and the queue clears
<seb128> wgrant, what happened there? we uploaded before the imported was on?
<wgrant> seb128: I think the imports were only switched on a few hours ago when dpm poked things
<wgrant> The initial vim etc. upload went through just recently
<seb128> k
<seb128> not sure when "duplicates can't be resolved", but in doubt it seems it should import rather than bail out?
<wgrant> I don't know Translations well, I'm afraid
<wgrant> But there are frequently duplicates that should be ignored/merged/something
<wgrant> Because each arch produces a tarball
<wgrant> And they would usually all be effectively identical.
<seb128> right
<seb128> do you have an idea how to force/fix the current situation then?
<stgraber> pitti: should be reasonably straight forward to implement, so sure i can do that
<pitti> stgraber: thanks, handed to you
<pitti> stgraber: I think we cover all the bases now
<wgrant> seb128: The next package or manual upload after the queue clears in a few days should work
<seb128> wgrant, thanks
<seb128> wgrant, btw while we are speaking about gtk, I just opened https://bugs.launchpad.net/launchpad/+bug/1260760 ... that one is annoying as well ;-)
<ubottu> Ubuntu bug 1260760 in Launchpad itself "editing an Ubuntu (gtk+3.0) but unsets the source" [Undecided,New]
<seb128> but->bug
<seb128> wgrant, basically doing any change to a gtk+3.0 bug (without using ajax) unset the source silently
<wgrant> wat
<seb128> wgrant, try yourself, just go to e.g https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1252112 and click "Save Changes" in the bug table
<ubottu> Ubuntu bug 1252112 in gtk+3.0 (Ubuntu) "save as PDF does not use file title" [Low,Incomplete]
<seb128> without doing anything
<seb128> it's "fun" :p
<asac> doko: the hostname upload, can you give us some confidence that it wont regress our touch image?
<attente> hi, i'm only getting square glyphs in plymouth
<attente> is it because of the dependency change from ttf-dejavu-core to fonts-dejavu-core?
<seb128> attente, do you have any debug info in /var/log/plymouth-debug.log ?
<seb128> hum
<seb128> that log is old here
<seb128> I've the feeling you need to turn on debug to get that :p
<attente> yeah. i don't even have that file
<seb128> attente, https://wiki.ubuntu.com/Plymouth#Debugging
<seb128> seems like you need "plymouth:debug" on your grub options
<seb128> follow the instructions there and see if the log has something useful?
<seb128> slangasek, ^ hey, do you know if that's a known issue?
<seb128> attente, when did that start?
<seb128> xnox did some changes recently, wonder if we can blame him :p
<attente> i only just noticed it now
<xnox> hm?! =)
<xnox> i did not change the fonts though =)
<seb128> right
<xnox> attente: what theme / plugin are you using?
<xnox> (screen or photograph of the problem?)
<seb128> xnox, you recent change reminds me I meant to file a bug, when it's checking discuss I don't get progress % indicated anymore
<seb128> (since saucy I think)
<seb128> attente, I guess you should reboot in debug and get log/photo and open a bug ;-)
<attente> xnox, ok, i'll get you a screen
<seb128> xnox, slangasek: btw, I set https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1165522 to high, it's the most reported plymouth issue on e.u.c and with a non trivial number of reports
<ubottu> Ubuntu bug 1165522 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in script_obj_deref_direct()" [High,Confirmed]
<seb128> could be a "nice to fix" for the lts ;-)
<xnox> seb128: also please attach a photo / screenshot of the problem were there is no % indication of fsck.
<seb128> xnox, I guess it's working for you?
<seb128> I wonder if that could be a problem in the french translation
<xnox> seb128: there is progress in *-logo and details plugins. That is server  & KMS enabled machines.
 * seb128 checks translation
<seb128> I've an intel machine
<seb128> so KMS I guess
<seb128> it was working until some point in saucy
<xnox> seb128: there is no progress on "ubuntu-text" aka "Ubuntu 13.10/ . . . . ." splash.
<xnox> seb128: please check if you get progress upon pressing Esc
<seb128> I've the graphical one
<seb128> ok
<attente> xnox, https://www.dropbox.com/s/3tspo4u05zlr9x7/2013-12-13 10.47.14.jpg
<attente> er
<xnox> attente: right, do you use full disk encryption? and what locale is set as the system locale?
<attente> https://www.dropbox.com/s/3tspo4u05zlr9x7/2013-12-13%2010.47.14.jpg
<xnox> attente: please file a bug with that screenshot, and comments about locale / full-disk encryption.
<attente> xnox, yes
<seb128> the debug.log might be useful there as well
<attente> xnox, using full disk encryption, not sure what the system locale is
<attente> is ttf-dejavu-core installed on your systems?
<seb128> attente, no, it's transitional
<seb128> attente, http://paste.ubuntu.com/6567307/
<attente>  /etc/default/locale is en_CA.UTF-8
<attente> seb128, i don't have the metapackage, but i guess that's not necessary
<seb128> attente, likely not
<attente> i'll get a debug log for you
<GunnarHj> ricotz: ping?
<GunnarHj> ricotz: I built a-s locally earlier today with your patch. Still no success with GDM. See bug 1260604
<ubottu> bug 1260604 in accountsservice (Ubuntu) "GDM does not work with new accountsservice 0.6.35-0ubuntu5" [High,Triaged] https://launchpad.net/bugs/1260604
<ricotz> GunnarHj, please test the patch which i attached or https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+sourcepub/3727470/+listing-archive-extra
<ricotz> GunnarHj, 0.6.35-0ubuntu6~trusty2 works despite harry33's comment
<ricotz> GunnarHj, the pastebin contained a typo
<GunnarHj> ricotz: ?? Actually I diff'ed them and found them to be identical.
<ricotz> they are not identical
<GunnarHj> ricotz: Ok, I'll try with the debs in the PPA then. Getting back to you in 30 min or so.
<ricotz> GunnarHj, alright
<attente> xnox, seb128, LANG="en_CA.UTF-8"
<attente> LANGUAGE="en_CA:en"
<attente> er,
<attente> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1260792
<ubottu> Ubuntu bug 1260792 in plymouth (Ubuntu) "Plymouth font shows only square/rectangle glyphs" [Undecided,New]
<attente> i didn't see anything related to the font in the debug log
<seb128> yeah, me neither
<GunnarHj> ricotz: Success with ~trusty2! :)
<slangasek> seb128: the remaining plymouth crashes are all things we've never been able to reproduce locally
<seb128> slangasek, k
<roadmr> hello, the ubuntu-sdk package seems to be uninstallable, is this a good place to ask about that or is there a better place?
<beuno> roadmr, #sdk is probably better, although I'm not sure there will be anyone around
<roadmr> beuno: just #sdk or #ubuntu-sdk? there's only one other person in the latter (xnox)
<beuno> roadmr, oh, I think I made that up
<beuno> not sure then  :)
<xnox> roadmr: what do you mean "ubuntu-sdk" package is not uninstallable?
<roadmr> beuno: hehe it happens :)
<xnox> roadmr: where did you install it from, and on to which release?
<roadmr> xnox: 12.04.3, I added this ppa: https://launchpad.net/~ubuntu-sdk-team/+archive/ppa
<roadmr> xnox: ubuntu-sdk wants qtcreator-plugin-ubuntu-cordova which in turn wants qtcreator-plugin-ubuntu (= 2.8.1bzr56precise0) but only 2.8.1bzr57precise0 is available in that ppa
<xnox> roadmr: well then, open a bug report against that ppa.
<roadmr> xnox: ok, just wanted to ensure I wasn't doing things wrong. I'll file a bug then, thanks!
<xnox> roadmr: it's best to use sdk on trusty ;-) and from the archive, not the PPAs =)
<roadmr> xnox: I know, but we have an application that uses the sdk and we need it building and running on precise
<xnox> roadmr: cool. ok.
<roadmr> xnox: saucy and trusty have no problems :) it's that "legacy" need for precise that makes us suffer
<hallyn_> Hi - if a package installs an upstart job, and that upstart job may do {stop; exit 0;}, that seems to cause package install to fail.
<hallyn_> is there a clean way to make that 'ok'?
<hallyn_> dh_installinit --errorhandler?  seems more work than should be needed
<Noskcaj> Can someone please test debian's version of opemmpi on ubuntu armhf? It appears all out diff is fixed, but i need someone to test we don't need any arm support patch
<xnox> hallyn_: if there is an example, i can look into that. it shouldn't fail.
<hallyn_> xnox: the cgroup-lite package in precise-proposed
<hallyn_> at least that's what i think is happening.  i may be misunderstanding...
<hallyn_> (install that in a precise container, and apt-get install fails)
<xnox> install cgroup-lite in the container.... which already is using cgroup-lite?!
 * xnox will try a VM instead.
<hallyn_> xnox: just a fresh container
<hallyn_> shouldn't have cgroup-lite, if you just 'lxc-create -t ubuntu -n p1 -- -r precise'
<xnox> ah ok.
<hallyn_> (idea being 'start cgroup-lite' will fail because of the apparmor profile)
<Noskcaj> when is the next DMB 19UTC meeting? I'm wanting to apply for MOTU and PPA (xubuntu packages), but cannot attend 15UTC and can only reliably attend 19UTC times before the end of January
<darkxst> Accountsservice gir1.2 package is broken. it killed gnome-shell ;(
<darkxst> ^xnox
<darkxst> is anyone around that can sponsor this? Its pretty urgent given gnome-shell is 100% broken in trusty for the moment. Bug 1260880
<ubottu> bug 1260880 in accountsservice (Ubuntu) "typelib file is installed to the incorrect location" [Undecided,New] https://launchpad.net/bugs/1260880
<ricotz> darkxst, fyi, https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1260604
<ubottu> Ubuntu bug 1260604 in accountsservice (Ubuntu) "GDM does not work with new accountsservice 0.6.35-0ubuntu5" [High,Triaged]
<Noskcaj> Is there an ETA for glew 1.9.0 in ubuntu?
<tjaalton> darkxst: i can do that
<darkxst> tjaalton, may as well take ricotz patch from bug 1260604
<ubottu> bug 1260604 in accountsservice (Ubuntu) "GDM does not work with new accountsservice 0.6.35-0ubuntu5" [High,Triaged] https://launchpad.net/bugs/1260604
<tjaalton> darkxst: next time finalize the changelog and add the bug# ;)
<tjaalton> ricotz: why does the -dev package need that dep?
<ricotz> tjaalton, it is a convention that the -dev packages pulls in the gir1.2- for a proper build environment
<ricotz> not related to this breakage, but still needed
<tjaalton> well i'm not adding it here
<ricotz> still leaving it is wrong
<tjaalton> oh it's a forked package, then I don't care
<ricotz> how do you mean "forked"
<tjaalton> since raring
<ricotz> you mean not "synced from debian" then
<tjaalton> right, and I'll add a changelog entry credited to you so you can explain it to the next one :)
<ricotz> tjaalton, alright
<tjaalton> uploaded
<darkxst> tjaalton, thanks
<tjaalton> np
<ricotz> tjaalton, thx
<tjaalton> Noskcaj: you probably need to ask the unity folks if 1.10 would be good for them
<Noskcaj> tjaalton, ok, will do
<tjaalton> since 1.9 broke the builds or such
<tjaalton> as mentioned on the changelog
<Noskcaj> yeah
<Noskcaj> roaksoax, kirkland: Would you mind putting a testdrive update out? Vbox 4.3 is now in proposed. Could we use this as an excuse to put testdrive in debian?
<Noskcaj> roaksoax, kirkland: Please add "Upload to debian. Closes: #718365" to the changelog, and release as just 3.25
#ubuntu-devel 2013-12-14
<Logan_> Noskcaj: For Bug 1259459, have you considered the armhf thing in our delta?
<ubottu> bug 1259459 in openmpi (Ubuntu) "Sync openmpi 1.6.5-6 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1259459
<Logan_> I'm not sure if building "using blcr" is fixing an FTBFS or just optimizing...
<Noskcaj> Logan_, yep, I've asked here for someone to confirm it's fixed, but both debian and upstream now support armhf
<Noskcaj> or did i missed something.
<Logan_> Okay, I'm not sure if it was just a "does it support it" issue.
<Logan_> I'll sync. If it fails to build, I'll try to reinstate that part of the delta.
<Noskcaj> thanks
<Noskcaj> any chance you could give me a testimonial for MOTU or xubuntu packageset? https://wiki.ubuntu.com/Noskcaj
<Noskcaj> You seem to see everything i ever do wrong though
<Logan_> Noskcaj: Haha, just looking out for you. :) I'm a bit concerned about the Internet issues and not testing before building - you would do that before uploading, right?
<Noskcaj> Logan_, definitely. When requesting syncs, i'd found it a bit easier to go for quantity, but since i'd actually be uploading i'll check better. Plus my devel pc get's here this week so build time is less of an issue
<Logan_> Okay. I want to see more quality sync requests first before I endorse, as I think that it's important (especially if you want to become a MOTU) to be able to check for issues before requesting a sync or a merge.
<Noskcaj> ok
<Logan_> Being a MOTU gives you a lot of power, and it is very easy to slip up. I want to make sure you're ready and contributing enough quality syncs/merges.
<Noskcaj> makes sense
<Noskcaj> Is there any chance you could sponsor some xfce stuff for me since both our devs are really busy?
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-terminal/0.6.2-4ubuntu1/+merge/197447 and https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/merge/+merge/198515
<Logan_> Noskcaj: One sec, lemme take a look.
<Noskcaj> ty
<Logan_> cjwatson: Mind creating a transition for me on the tracker? :)
<Logan_> (Or giving me access? :O )
<Logan_> Noskcaj: I feel like I did an xfce4-terminal merge recently.
 * Logan_ checks the change log.
<Logan_> ...yep, I'm not crazy. :P
<Logan_> Noskcaj: Uploaded xfce4-terminal. Hope I didn't fuck it up.
<Logan_> bar merges are hard, bro. :P
<Logan_> Okay.
<Noskcaj> How can i make http://qa.ubuntuwire.com/bugs/rcbugs/ realise trusty is now the devel release?
<Noskcaj> Can someone please look at http://mentors.debian.net/package/qgis since it fixes the ubuntu delta and (should) fix the current ftbfs
<maxiaojun> reading http://manpages.ubuntu.com/manpages/precise/en/man1/patch.1.html , the bullet points are presented as "+o"?
<Noskcaj> tumbleweed, you mind taking a look at http://mentors.debian.net/package/qgis since it fixes the ubuntu delta and (should) fix the current ftbfs
<pvl1> hello everyone! where/how does ubuntu store the apps menu
<Logan_> xnox: Would you mind creating a transition for me? (Or adding me to the team? ;P )
<Logan_> Actually, just the former, since you're not an admin on the team. I want to track the openmpi transition that I just created.
<Logan_> libopenmpi1.3 -> libopenmpi1.6
<infinity> Logan_: When you synced openmpi from Debian, you should have checked for Ubuntu patches on opemmpi1.6 and ported them over.
<infinity> Logan_: Specifically the arm64 port, but there may be other bits.
<Logan_> There wasn't an arm64 port of openmpi.
<Logan_> There's an open bug against a Linaro team for porting 1.6.x to arm64, though, if that's what you're referring to.
<Logan_> infinity: ^
<infinity> Logan_: look at the openmpi1.6 source package.
<infinity> Logan_: We had the port in the archive already.
<Logan_> ...oh, wasn't aware of that source package. I looked at Bug 1134820 before syncing, which seemed to indicate that an arm64 port was still in progress.
<ubottu> bug 1134820 in Linaro AArch64 cross-distro work "openmpi 1.6.x needs porting" [High,Triaged] https://launchpad.net/bugs/1134820
<infinity> Logan_: http://launchpadlibrarian.net/153910913/openmpi1.6_1.6.4-2ubuntu1_1.6.4-2ubuntu2.diff.gz
<Logan_> Okay, I see that now.
<Logan_> Should I bring over doko's changes to the openmpi source package so that we can drop openmpi1.6?
<infinity> Logan_: Yeahp.
<Logan_> Do we have any other openmpi source packages, while I'm at it? :P
<Logan_> Looks like that's the only one. Alright, I'll do that after dinner.
<Logan_> My apologies. I'll be more careful next time with checking for versioned source packages before creating transitions. :P
<infinity> There may have been a delta there from me for how dh_shlibdeps is called too.
<Logan_> I'll make sure everything is carried over.
<infinity> Logan_: Well, in that case, it was somewhat obvious from the changelog of openmpi, which used to be openmpi1.6 :)
<infinity> Logan_: Anyhow, no harm done if we fix it.
 * Logan_ hides.
<Logan_> Haha, there go my ambitions for core-dev for the time being. ;P
<xnox> Logan_: there are plenty of core-devs unaware of the transition-tracker ;-) so don't worry about it.
<xnox> Logan_: added opnempi tracker, copied from debian. do check if it looks ok, once it's generated.
<Logan_> Thanks. :)
#ubuntu-devel 2013-12-15
<Logan_> infinity: I just uploaded a new openmpi with the changes from openmpi1.6 in Ubuntu (except for one that was already applied).
<infinity> Logan_: You applied the dh_shlibdeps one a bit wrong.
<Logan_> Well, I adapted it to the new path...
<infinity> Logan_: The whole point of calling dh_shlibdeps properly is to avoid needing to specify the path to fakeroot on the command line.
<Logan_> ...oh.
<Logan_> Would you mind fixing it? I guess I didn't understand properly. :(
<infinity> Yeah.  Shouldn't hurt anyway as-is, but I'll fix it to be more correct, so I can bug the Debian maintainer (again) to take the proper fix instead of his hack. :P
<Logan_> Sounds good! Also, can we get rid of the openmpi1.6 source package now?
<infinity> We can if it no longer produces any binaries we care about.  I'll look.
<Logan_> No rbdeps.
<infinity> Might have been nice to provide some upgrade paths from 1.6 -> unversioned, but meh.
<Logan_> infinity: Actually, do we have to wait until everything depends on libopenmpi1.6 first?
<infinity> Logan_: No.  Since nothing depends on it currently except itself.
<Logan_> rdeps isn't giving accurate output right now.
<infinity> (Already removed)
<infinity> I checked the binary packages, seemed sane.
<infinity> The source check did indeed seem wonky.
<Logan_> Okay. If there are any temporary dependency issues, they'll be sorted out shortly after I transition everything over so that openmpi 1.6 goes from proposed to release.
<alkisg> apt:// links no longer work in firefox 26/trusty, is that by choice or a bug?
<alkisg> E.g. try https://apps.ubuntu.com/cat/applications/htop/ and then click on "available on the software center"
<Noskcaj> xnox, Mind if i merge gtk2-engines? debian appear to have fixed the automake issue
<ari-tczew> robert_ancell: ping
<robert_ancell> ari-tczew, hello
<ari-tczew> robert_ancell: hi Robert, according to merge of seahorse. debian bug 732168 is relate to drop gnome-doc-utils. I added this one as an information about forwarded delta.
<ubottu> Debian bug 732168 in seahorse "seahorse: drop gnome-doc-utils from Build-Depends" [Normal,Open] http://bugs.debian.org/732168
<ari-tczew> you wrote it's not related, but it is
<robert_ancell> ari-tczew, np, when they merge that in it will appear in the changelog
<ari-tczew> robert_ancell: I'll add info about dropped libgnome-keyring-dev from B-D at the same bug, as well
<ari-tczew> robert_ancell: about merge of cheese: you mean I don't need to mention removing patches which are applied upstream as far they weren't in Debian - why?
<robert_ancell> ari-tczew, because when you write a changelog entry after a merge, write it like you had just taken the Debian version and made the Ubuntu changes. There's always loads of small Ubuntu changes that are removed in a merge, not worth listing them all
<robert_ancell> Since Debian didn't have these patches they don't need to be mentioned
<StevenK> I always mention Ubuntu changes that have been dropped in a merge
<ari-tczew> robert_ancell: so it's enough if I write the reasons of dropped changes in bzr-merge or launchpad bug?
<robert_ancell> Oh, well I see there is differing opinions. It's not a major point anyway
<ari-tczew> Well, it depends on sponsor what he/she expect to have in d/changelog.
<ari-tczew> robert_ancell: I just wanted to figure out that it wasn't my fault, as said - differing opinions.
<robert_ancell> sure, not your fault
<ari-tczew> robert_ancell: next, we didn't bump Standard-Version and 99_ltmain_as-needed.patch wasn't removed by me - they are Debian changes. Look version 3.8.3-1
<robert_ancell> ari-tczew, no, my point was we should bump standards-version
<robert_ancell> ari-tczew, which package for 3.8.3-1?
<ari-tczew> robert_ancell: cheese
<robert_ancell> ari-tczew, don't you mean 3.10.1-1sid1 then?
<ari-tczew> robert_ancell: I mean 99_ltmain_as-needed.patch was removed in Debian @version 3.8.3-1
<ari-tczew> not by me
<robert_ancell> ari-tczew, right, but they were still in your branch, but not in the debian package
<robert_ancell> so they hadn't been bzr rm'd
<ari-tczew> robert_ancell: ok, I got it.
<ari-tczew> next time I won't forget (hopefully)
<ari-tczew> robert_ancell: could you sponsor bug 1259871 as well? Unfortunately I didn't find a bzr on ~ubuntu-desktop for
<ubottu> bug 1259871 in gnome-shell-extensions (Ubuntu) "Merge gnome-shell-extensions 3.8.4-2 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1259871
<robert_ancell> ari-tczew, it's better to ask the ubuntu-gnome people for packages like that - I haven't been maintaining them
<ari-tczew> robert_ancell: ok
<cjwatson> robert_ancell: "we should bump standards-version" - in general Ubuntu uploads should not bump Standards-Version beyond what's in Debian, as it has negligible benefit.  http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-controlfields.html#s-f-Standards-Version
#ubuntu-devel 2014-12-08
<mwhudson> is there an easy way for me to install the kernel and libc headers for another architecture?
<pitti> Good morning
<dholbach> good morning
<pitti> wgrant, dpm: odd, latest utopic (and vivid) translation export lost "libc"; I just approved the template on https://translations.launchpad.net/ubuntu/utopic/+source/glibc/+imports?field.filter_status=all&field.filter_extension=pot but I wonder how we lost that in the first place
<xnox> brainwash: sigh, thanks.
<xnox> Noskcaj: i don't know about abiword - test it make sure it doesn't regress do the merge if you wish. I do not have time, nor interest to merge abiword. Thus i gave the merge up for adoption.
<xnox> Noskcaj: encfs -> synced, let's see if it builds everywhere.
<xnox> hm, i ponder how to ping tseliot on irc =)
<xnox> is he by any chance on the other IRC network?
<xnox> Noskcaj: encfs built fine. all good.
<netdef> build stated :) naaha
<netdef> does ideviceinstaller works  on ios 8.1.1?
<netdef> i installed from ubuntu repository which i don't know exact version. I'm new to this libimobile
<netdef> but it does not work and says can't start installer or someting
<netdef> /usr/bin/ld: /usr/local/lib/libxml2.a(encoding.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
<netdef> /usr/local/lib/libxml2.a: error adding symbols: Bad value
<netdef> collect2: error: ld returned 1 exit status
<netdef> what is this error
<maxb> An error instructing you to recompile with -fPIC
<netdef> I'm so sorry but I dont know how to
<netdef> can u teach me?
<netdef> how to put -fPIC?
<mgedmin> I think #ubuntu might be a better channel for this, netdef
<netdef> but i soved by my self
<netdef> the problem happens when ubuntu try to compile application in 32 bit using 64bit libaray on 64 bit os machine.
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<netdef> just keep reference when you try to compile
<netdef> ye!!!! compiled my expectaion was collect
<netdef> libplist was not good
<dholbach> xnox, can you take a look at https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1291827?
<ubottu> Launchpad bug 1291827 in ntfs-3g (Ubuntu) "Merge ntfs-3g 1:2014.2.15AR.2-1 (main) from Debian unstable (main)" [High,Confirmed]
<dholbach> it looks like there was a small bit of delta between ubuntu and debian - can the patch be dropped?
<smb> apw, could you accept my nominations on bug 790558, please. It is quite old but I found we still did it wrong when I did the merge from Debian.
<ubottu> bug 790558 in dahdi-linux (Ubuntu) "dahdi kernel module built for wrong kernel version" [High,Fix released] https://launchpad.net/bugs/790558
<pitti> cjwatson: did you do the systemd integration into openssh? if so, is there a reason why we have both a .service which is started in multi-user.target *and* a .socket? wouldn't the .socket be sufficient and more efficient?
<apw> smb, done
<smb> apw, thanks
<xnox> dholbach: that package is in sync in vivid.
<xnox> https://launchpad.net/ubuntu/+source/ntfs-3g
<dholbach> xnox, right
<dholbach> xnox, Ari thought there was a patch worth keeping in Ubuntu
<dholbach> and since you synced, I thought you might have an opinion on the bug report :9
<xnox> dholbach: i've changed with colin here and we decided it's not worth keeping the compat with pre-2011 wubi installs or something like that.
<dholbach> thanks, I'll follow up on the bug report
<xnox> dholbach: well the bug can be closed now, no?
<dholbach> yes
<dholbach> that's what I was going to do
<dholbach> ... with some explanation
<cyphermox> good morning!
<cyphermox> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, dholbach
<cyphermox> rbasak: hey!
<rbasak> cyphermox: hi!
<cyphermox> rbasak: just curious what exactly there was to do atm with bug 1257082? :)
<ubottu> bug 1257082 in ntp (Ubuntu Trusty) "MAAS does not use NTP servers specified in DHCPD options" [Undecided,In progress] https://launchpad.net/bugs/1257082
<rbasak> cyphermox: I wanted a conversation around my comments 21-23, to work out the best way to do this so we don't diverge from Debian.
<cyphermox> k
<rbasak> cyphermox: Debian have said that they'd accept patches.
<cyphermox> right
<rbasak> So no reason to introduce an Ubuntu delta here if we can help it.
<cyphermox> then it seems like your idea to just have the small change in the script sounds like a good way to address this, and something that can be easily upstreamed
<rbasak> cyphermox: yeah - provided that it works for all stakeholders, which assumes I've understood the multiple problems here correctly.
<cyphermox> if you're still looking after it, I'll just let that bug be for now :)
<rbasak> cyphermox: I'm happy to look after it, but I need a response from Jorge here really.
<rbasak> niedbalski: ^^
<cyphermox> cool :)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
 * dholbach hugs cyphermox
<rbasak> Is there a tmpfs that we can use in package builds and dep8 tests? Looking to speed up mysql tests, and they can make use of a tmpfs if there is one mounted somewhere.
<rbasak> There's /run/shm, which is presumably evil to use thisi way but might be available.
<rbasak> Is there a better place or mechanism to get this?
<bdmurray> tjaalton: in bug 1386620, which you verified, there is mention of a potential regression regarding modesetting. Can you comment on your testing of that?
<ubottu> bug 1386620 in xorg-server (Ubuntu Vivid) "re-enable rotation for the intel driver in optimus mode" [Critical,New] https://launchpad.net/bugs/1386620
<mlankhorst> bdmurray: basically I had to backport an awful lot of patches for that
<tjaalton> bdmurray: I've unverified that one, will double-check tomorrow but iirc there wasn't anything
<bdmurray> tjaalton: okay, thanks!
<bdmurray> tkamppeter: Could you have a look at bug 1348384? It seems to be related to an SRU you did.
<ubottu> bug 1348384 in okular (Ubuntu) "evince and okular do not render eps files correctly resulting in a black background" [Undecided,Confirmed] https://launchpad.net/bugs/1348384
<infinity> tjaalton: Hey, who's doing the lts-utopic X stack this time around?
<infinity> mlankhorst: ^
 * dobey can't wait for new kernel/x/intel
<infinity> dobey: New kernel is there.  Someone seems to be slacking on the new X bit, though. :)
<dobey> infinity: there == in proposed, or in updates?
<infinity> dobey: updates.
<dobey> ooh
 * dobey makes a note to install it
<dobey> infinity: i guess new intel drivers aren't in yet though?
<infinity> dobey: Not any userspace component of such.
<dobey> i wonder if those will come with the updated xorg
<infinity> dobey: Usually seems to work that way.
 * dobey goes to order a displayport 1.2 cable
<mlankhorst> infinity: oh I've had x-stack in canonical-x/x-staging for ages
<infinity> mlankhorst: Perhaps that's not the best place for it if we want it to actually make the point release? ;)
<mlankhorst> https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
<mlankhorst> yeah, I guess it's SRU time
<mlankhorst> I need xtrans, x11proto-core, x11proto-fonts, and libdrm updated
<mlankhorst> llvm-toolchain-3.5 should be new
<dobey> mlankhorst: are you updating intel-gup-tools, libdrm-intel and xserver-xorg-video-intel too?
<tjaalton> infinity: right, it's been on that ppa for a while, now would be the time to get them to the archive
<infinity> tjaalton: A few weeks ago might have been the time, but now's really the time. :)
<tjaalton> heh, indeed
<ricotz> Trevinho, hi, mesa-git-builds in xedgers should support mir now
<Logan_> infinity: wanna do me a favor? :D
<Logan_> it's not much of a favor
<Logan_> I just need a no-change rebuild of a package in main
<infinity> Logan_: Sure.
<Logan_> one sec, doing a test build
<Logan_> infinity: please do a no-change rebuild of gst0.10-python with the following changelog entry:
<Logan_> No-change rebuild against new binutils to fix istanbul FTBFS on ppc64el.
<ari-tczew> "Generated at 2014-12-06 20:13:15 UTC."
<infinity> Logan_: That... Might need some explaining.
<ari-tczew> cjwatson: MoM seems to be broken. ^
<Logan_> infinity: sure - so you know the change that was made to binutils to properly support ppc64el in Debian?
<Logan_> the one we talked about a few weeks ago
<Logan_> it turns out that is does more than just fix FTBFS without autoreconf; it also fixes some shared libraries
<infinity> Logan_: I feel like either you had this conversation with someone else, or I'm losing my mind. ;)
<Logan_> oops, well, in any case
<Logan_> istanbul currently FTBFS on ppc64el because it can't find the gst0.10-python library
<Logan_> and that was shown in the build log on Debian
<Logan_> but, after rebuilding gst0.10-python against the new binutils and then rebuilding istanbul in Debian, it found the library properly
<Logan_> so we should do the same
<infinity> Logan_: Right, so istanbul has nothing to do with this.  gst0.10-python just plain doesn't have a shared library in it, and it should have FTBFS because of it but didn't.
<infinity> checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
<infinity> The usual suspect.
<Logan_> right, but rebuilding it should produce the shared library
<Logan_> because of the binutils change
<infinity> Let me verify that.
<infinity> And also, still not happy with that binutils change.
<infinity> Seems too magic to me.
<Logan_> seems to work, though
<Logan_> it definitely produces the shared libraries properly, without an autoreconf in most cases
<Logan_> I've been dropping our autoreconf delta when it builds properly in Debian on ppc64el
 * infinity taps his foot waiting on build-deps to install.
<Logan_> you need apt-fast
<Logan_> or something.
<infinity> checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... yes
<infinity> Looks promising.
<Logan_> you have a ppc64el porter box?
<infinity> Yeah.
<Logan_> like, physical?
<infinity> It's not imaginary.
<Logan_> :)
<infinity> -rw-r--r-- root/root     18336 2014-12-08 23:11 ./usr/lib/gstreamer-0.10/libgstpython.so
<infinity> Handy.
<Logan_> oh cool, you can get a ppc64el VM for free here: http://openpower.ic.unicamp.br/minicloud/
<Logan_> I might just do that
<infinity> Uploaded.
<Logan_> sweet, thanks
<tkamppeter> bdmurray, thanks. I have CCed the author of the SRU patch for bug 1242678, Marek, Kasik.
<ubottu> bug 1242678 in evince (Ubuntu Trusty) "evince cannot render some EPS files" [Undecided,Triaged] https://launchpad.net/bugs/1242678
#ubuntu-devel 2014-12-09
<mikodo> Can feature requests be made here
<mikodo> I would like to see Mir be developed with it's own feature of inversing the color display. (Independant of X or Xmir with "Xcalib" or by using compositors like Compiz and Kwin).
<cyphermox> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cyphermox> mikodo: you might want to ask that in #ubuntu-mir; but if you know exactly what needs to be done and can develop the patches yourself, it's likely it would get done faster :)
<mikodo> cyphermox, Thanks, no I can't do it. I will ask there.
<cyphermox> np
<LocutusOfBorg1> good morning developerz :)
<rbasak> bdmurray: is ~ubuntu-reviewers actually active? I've never seen anything come out of an automatic bug subscription. Are we setting false expectations with the automatic comment?
<sil2100> didrocks: hey! :) Could I use your archive admin powers and ask for removal of 2 packages from 14.09-proposed in ubuntu-rtm?
<sil2100> didrocks: they're part of an invalid transition that we need to re-do
<didrocks> sil2100: hum, I can try, but I'm unsure how this work for ubuntu-rtm
<sil2100> didrocks: ubuntu-system-settings and upower
<sil2100> didrocks: thanks o/
<didrocks> sil2100: why don't you push new packages with new versions rather?
<sil2100> didrocks: that's the plan, but in the meantime I don't want those to cause chaos in other packages building against -proposed
<didrocks> sil2100: do you know the suite name for ubuntu-rtm?
<sil2100> didrocks: suite name?
<sil2100> didrocks: the distro is ubuntu-rtm and series 14.09, not sure about the other names
<didrocks> sil2100: 14.09 is -proposed?
<didrocks> hum, no, there is a 14.09-proposed apparently
<sil2100> didrocks: there's 14.09-proposed as well
<didrocks> sil2100: fine with you? http://paste.ubuntu.com/9439167/
 * sil2100 looks at the list while sweating
<willcooke> cking, howdy!  Do you know about BGRT?
<sil2100> didrocks: I think yes :)
 * didrocks flushes
<didrocks> sil2100: done
<cking> willcooke, the ACPI table for logos?
<willcooke> cking, AIUI, yes
<willcooke> cking, do you know if Grub(?) can support getting it and displaying it during boot?
<sil2100> didrocks: thanks again!
<cking> willcooke, afraid I don't know about that
<willcooke> cking, no worries.
<didrocks> sil2100: yw ;)
<cking> willcooke, maybe worth asking the grub mailing list
<willcooke> cking, plan - thx
<mlankhorst> infinity: I've uploaded the pre-requisites, bug 1400626
<ubottu> bug 1400626 in xtrans (Ubuntu) "Please backport xtrans, libdrm, x11proto-{fonts,core} packages for 14.04.2" [High,In progress] https://launchpad.net/bugs/1400626
<sil2100> pitti: ping o/
<seb128> sil2100, he's one of the people travelling that might not be on IRC, maybe better to give some context/others might be able to help you?
<seb128> willcooke, cjwatson might know about that
<cjwatson> pitti: Yes, I did the systemd integration for openssh.  Please see the end of README.Debian, which explains various caveats with it.
<cjwatson> seb128,willcooke: GRUB knows how to parse ACPI tables for things like figuring out how to shut down properly, but as far as I know it doesn't use it for anything graphical.  You'd have to ask upstream.
<cjwatson> seb128,willcooke: I mean, if you want anything implemented.  Upstream will also tell you that the answer to the question you actually asked is no :-)
<rbasak> Do I need do declare Depends on packages that have Priority: required? Eg. passwd.
<cjwatson> rbasak: Yes.  You may only omit dependencies on packages that are Essential: yes.
<rbasak> I don't see anything relevant in policy. I get the feeling there's something that says I don't need to do it, but I don't see where.
<rbasak> Aha. Thanks :)
<cjwatson> Nothing tells you that you may omit them, therefore you must include them. :-)
<rbasak> :)
<willcooke> cjwatson, thanks
<cjwatson> But people get confused because a lot of required packages are essential.  (Counterexample: libc6.)
<cjwatson> Obviously libc6 is transitively essential, but it's not Essential: yes in its own right.
<seb128> cjwatson, thanks
<seb128> hallyn, hey, why are cgmanager systemd job disabled by default?
<seb128> cjwatson, do you know what set up the console keyboard layout? it looks like console-setup used to ship an upstart job to do that but that it doesn't do it anymore, what that replaced by something else?
<ogra_> there is a hool in the initrd as well ... in case you have fs encryption it is executed
<ogra_> *hook
<seb128> ogra_, context is that my test laptop has the correct keymap when init is upstart but not when init is systemd, trying to figure out why
<ogra_> ah
<seb128> /etc/default/keyboard has the correct "fr" config
<cjwatson> seb128: It has to be done before plymouth starts, so the way it works is that there's an initramfs script that does it if it can, and otherwise /etc/init.d/console-setup should take care of it if plymouth isn't running.
<cjwatson> seb128: My guess would be that systemd is doing some keyboard handling itself and needs to be adjusted to match up, but I haven't looked.
<seb128> cjwatson, k, thanks, I'm going to have a look to console-setup
<seb128> cjwatson, systemd is built without vconsole which is the job that handle that
<seb128> one #debian-systemd comment suggests that console-common does the config on a Debian systems
<ogra_> seb128, i *think* the real thing is not handled by upstart but by udev
<seb128> ogra_, udev doesn't change depending of what is pid1 though...
<alexbligh1> https://security-tracker.debian.org/tracker/CVE-2014-8106 was I think previously restricted but is now in the open. Reasonably serious qemu vulnerability. I can't find an equivalent LP bug. Would it be appropriate to open one or is there likely a restricted one that I can't see? It's a one line fix.
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8106)
<seb128> but could be that something in systemd override the value
<seb128> though that should be vconsole which is disabled
<cjwatson> ogra_: No, that's the font.
<cjwatson> seb128: Well, yeah, it's probably some other similar component in Debian but that shouldn't matter ...
<cjwatson> seb128: Maybe check "systemctl status console-setup"?
<seb128> cjwatson, that job is loaded/activated with status=0/SUCCESS
<cjwatson> seb128: Maybe stick strace -f in there and see what it actually ends up doing ... naturally this stuff is an utter pain to debug
<didrocks> seb128: ok, I'm available now, it seems you want to enable this keyboard thing yourself? (I'm happy to, I'll finish/upload xdiagnose then)
<flexiondotorg> How do I go about merging the Ubuntu MATE seeds to the official location?
<flexiondotorg> cjwatson, Can you point me in the right direction?
<seb128> cjwatson, ok, I'm going to have a look to that, thanks for the hint
<seb128> didrocks, yeah, I started looking at it, doesn't seem really systemd itself
<seb128> but lunch first, then back to that
<cjwatson> flexiondotorg: No, sorry.
<cjwatson> Hopefully somebody else can help.
<didrocks> seb128: enjoy!
<flexiondotorg> Got a name I can contact? I realise your role has changed.
<cjwatson> flexiondotorg: No, but this is the right channel to ask.
<cjwatson> flexiondotorg: I'd advise starting by being more specific.
<rbasak> Is there any mounted tmpfs on a buildd that I can rely on to be present for faster tests during the mysql build?
<rbasak> It'd be too hacky to use /dev/shm I presume?
<mitya57> sil2100: hi, have you seen my three appmenu-qt5 fixes? Please review them, as I am also going to submit two more :)
<mitya57> (two more will be new features, rather than fixes, and that will be later, maybe next week)
<flexiondotorg> dholbach, Are you available for a quick chat via PM?
<dholbach> flexiondotorg, sure
<dholbach> hey seb128, who could take a look at https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116 and https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-sound-gtk2/+merge/244120?
<seb128> dholbach, not sure, anyone in the xubuntu or mate teams I guess?
<seb128> ochosi might know who to recommend
<dholbach> ah... so it's them who maintain indicators-gtk2?
<seb128> dholbach, well, see https://launchpad.net/ubuntu/+source/indicator-application-gtk2/+changelog
<seb128> dholbach, basically it's for xubuntu/lubuntu and it seems mate
<seb128> dholbach, the sound one is fine to upload
<seb128> the indicator-application one looks fine to me as well
<dholbach> mr_pouit, ^ are you fine with me uploading them?
<seb128> in fact maybe not
<ochosi> right, well actually in xubuntu we don't use the gtk2 indicators anymore
<ochosi> we use gtk3 since 14.04
<seb128> great
<seb128> dholbach, I'm unsure about the indicator-application one
<ochosi> so i don't think any of our devs would really want to maintain that
<dholbach> seb128, why unsure?
<seb128> dholbach, because I wonder if having the dbus activation put it back could lead to have the gtk2 service loading under e.g unity when you don't want it, because it uses the same name on the bus
<seb128> ideally the service would be renamed
<seb128> let me comment on the mp to ask about that
<seb128> dholbach, the other one is fine to upload
<dholbach> flexiondotorg, ^
<flexiondotorg> dholbach, Thanks.
<flexiondotorg> seb128, The indicator-application-gtk2 has been tested. There are no conflicts.
<Unit193> dholbach, seb128: Xubuntu uses GTK3 indicators.
<Unit193> Oh, dowh.
<seb128> flexiondotorg, how tested? are you sure it's never ever going to start under e.g xfce or unity?
<flexiondotorg> seb128, Yes. See the reference bug reports. It was tested with MATE installed over Xubuntu.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/indicator-application-gtk2/+bug/1319352
<ubottu> Launchpad bug 1319352 in indicator-application-gtk2 (Ubuntu) "indicator-application does not work in MATE 1.8" [Undecided,Confirmed]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/indicator-application-gtk2/+bug/1319352/comments/10
<flexiondotorg> seb128, Also see https://bugs.launchpad.net/ubuntu/+source/indicator-sound-gtk2/+bug/1208204
<ubottu> Launchpad bug 1208204 in Ubuntu Studio "[SRU]Update indicator-sound-gtk2 with patch" [Undecided,New]
<flexiondotorg> seb128, That patch made the Gtk2 indicator use a different DBus name, so that the indicator-sound-service from this package is loaded instead of the Gtk3 one which is incompatible.
<seb128> flexiondotorg, what patch makes it use a different dbus name?
<seb128> flexiondotorg, https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116 doesn't for sure
<flexiondotorg> seb128, indicator-application-gtk2 (which the changes I've proposed) has been tested on Xubuntu which which use GTK3 indicators. No conflicts were encountered,
<seb128> flexiondotorg, how do you define conflict? if indicator-application-gtk3 is not installed and some client try to use the dbus name it's not going to activate the gtk2 version?
<flexiondotorg> I'll install stock Ubuntu and Xubuntu and install my patched version of indicator-application-gtk2 and indicator-sound-gtk2 on both to be double sure.
<seb128> flexiondotorg, thanks, but as said the case might be more "if indicators are not running and something call to the dbus name"
<seb128> but I guess it's a corner case
<seb128> in any case I was just pointing it out as a potential issue, feel free to upload as it is as far as I'm concerned
<flexiondotorg> seb128, I understand your concern. I'll test it now.
<seb128> thanks
<flexiondotorg> seb128, I don't have upload rights.
<flexiondotorg> dholbach is my sponsor.
<seb128> flexiondotorg, well, "you" being your sponsor then
<flexiondotorg> dholbach, ^^^^
<dholbach> flexiondotorg, "sponsor" means somebody who uploads packages for you
<dholbach> I'd really like to keep sponsorship "free for all"
<dholbach> that's why we have this approach where folks who need patches or packages uploaded can subscribe a team to bug reports, so a number of folks can go and help out
<dholbach> and things don't get blocked on a single person
<dholbach> but yes, I (as many others) am happy to help out :)
<sil2100> mitya57: thanks! :) Will look into those tomorrow probably
<sil2100> mitya57: today I'm trying to have a take on a bigger package transition in ubuntu-rtm
<sil2100> So I won't have time for this probably
<caribou> I have a question regarding bug #1387594
<ubottu> bug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/1387594
<caribou> this bug is critical only if the package is rebuilt; the libnss-ldap packages in Utopic and Trusty do work atm
<caribou> but they will fail if it is rebuilt against the current source. Is it possible to upload a fixed source only to the archive ?
<xnox> caribou: no, in launchpad we have a strict sources->binaries 1:1 relationship.
<xnox> caribou: well, you can upload a source which forces a FTBFS if it detects that the built binary has particular problem.
<caribou> xnox: well, not at the moment, as the binary for libnss-ldap for Utopic and Trusty have not been rebuilt since 2012
<xnox> caribou: it seems that fixing that bug is important.
<xnox> caribou: what do you mean "not at the moment"?
<caribou> xnox: rebuilding libnss-ldap for Utopic and Trusty will make it fail. The version in the archive works
<xnox> caribou: each new release forks the previous one, but it's a matching set of binaries for each source, as they were built at the initial upload.
<xnox> caribou: given that ppc64el binaries were built much later, I presume that bug is in the archive for ppc64el and arm64.
<xnox> caribou: because those binaries where built much later than regular i386/amd64/etc.
<caribou> xnox: nope; look at the [TEST] section of the SRU template for that bug
<caribou> xnox: I understand that it should not be the case, but it is
<xnox> caribou: can you explain what you believe is currently the case?
 * xnox sees no inconsistencies at the moment.
<xnox> there may ever be a single binary for a given source package on one arch, through the life-time of ubuntu. Thus amd64/i386 were built in 2012, ppc64el in 2014, etc.
<caribou> xnox: the archive package has libnss_ldap-2.15.so and this version uses _pthread_mutex_lock symbol
<xnox> the same i386 binary from 2012 is in preice, trusty, utopic, vivid etc.
<caribou> xnox: rebuilding with the current source will bring libnss-ldap to libnss_ldap-2.19.so and this one uses __libc_lock_lock which is no longer in glibc
<caribou> xnox: look at the SRU test case for the bug, I ran this a few minutes ago
<xnox> ... yes, becuase in 2012 we used eglibc 2.15 and didn't rebuild libnss-ldap against eglibc 2.19, yet.
<xnox> caribou: "Is it possible to upload a fixed source only to the archive ?" the answer is no.
<xnox> caribou: the source upload, will rebuild and publish updated binaries.
<xnox> in the SRU.
<caribou> xnox: ok, I was just wondering if it was possible
<caribou> xnox: I was just worried of unexpected regressions cause by such a rebuild
<xnox> caribou: i'm not sure why you started talking about inconsistencies and pointing to the bug test case.... when my answer was only about your question alone.
<caribou> xnox: because you talk about a 1:1 relationship b/w source & binary which is clearly _not_ the case in this situation
<xnox> caribou: there should be no regressions as nothing directly links with libnss plugins, they are dlopened at runtime. Thus if a basic test $ getent passwd root works with libnss-ldap installed and configured
<xnox> you should know that things works.
<caribou> xnox: and the bug clearly shows that
<xnox> caribou: there is a 1:1 relationship /in the archive/ between source .dsc & binary .deb.
<xnox> caribou: it's not possible to publish a new .dsc / .deb with a different checksum for the same version number for the same arch.
<caribou> xnox: ok, I see what you mean : archive != src pkg in LP; my mistake
<xnox> caribou: yeah, one has to bump the version number (sru version number) which is a new source + new set of binaries that superseed the previous one.
<xnox> caribou: you can experiment in a PPA e.g. generate two different packages with the same name and version number, only first one will be accepted.
<caribou> xnox: I was wrong to assume that pulling the source from LP would give me the same source as what is in the archive
<xnox> caribou: it does give you the same source...
<caribou> xnox:s already
<xnox> caribou: but to get the same binary you need a chroot from 2012 of the release used to build the original binary.
<xnox> which subsequently was copied from one release to the next.
<xnox> caribou: we do not rebuild all binaries when we open new series, we keep them.
<cjwatson> xnox: that's a one-to-many relationship, not a one-to-one relationship :-)
<xnox> look: https://launchpad.net/ubuntu/+source/libnss-ldap/264-2.2ubuntu4
<cjwatson> </twitchy maths geek>
<xnox> caribou: https://launchpad.net/ubuntu/+source/libnss-ldap/264-2.2ubuntu4 from here amd64, armel, armhf, i386, powerpc were built on quantal to produce _i386.deb etc. and those are copied and were published in quantal, raring, saucy, trusty, utopic.
<caribou> xnox: ok, I'm going to run a new set of tests just to be safer (even if I already did test each one)
<xnox> caribou: arm64 deb was build in published in saucy and up.
<xnox> caribou: ppc64el deb was build & published in trusty and up.
<xnox> cjwatson: well, my defence is that i said 1:1 per arch, which is 1 to many.
<xnox> caribou: now, you are claiming that identical source produces a differen tresult when built in trusty chroot.
<xnox> caribou: that is correct because the comparison is with a binary build in quantal's chroot.
<caribou> xnox: I'm not too bothered about what I claim, just about the fact that if, for some reason gets rebuilt, it will trigger segfaults & unbootable systems
<xnox> caribou: cjwatson can tell you a story of unbootable ISOs with an icon changed from one picture to another.
<xnox> caribou: i'm certain if you rebuild that source in quantal's chroot it will remain bootable without segfaults.
<rbasak> Is there any mounted tmpfs on a buildd that I can rely on to be present for faster tests during the mysql build?
<rbasak> It'd be too hacky to use /dev/shm I presume?
<rbasak> We're wondering about /run
<xnox> rbasak: is that for out of archive rebuilds, or the official builds for archive.ubuntu.com?
<xnox> rbasak: tmpfs can cause miscompiles, thus should not be used for official builds.
<cjwatson> xnox: It's still not one-to-one per arch, since one source produces one *or more* binaries per architecture.
<xnox> cjwatson: true.
<caribou> xnox: Am I correct to think that if some other SRU for this library comes in, libnss-ldap will not be rebuilt in a quantal's chroot but a more recent one ?
<rbasak> xnox: it's for running a test suite quicker, both in official builds and developers test building locally
<rbasak> xnox: I don't see why it'd cause any miscompiles. It's true use of a RAM-based filesystem for stuff that needs to use a filesystem quickly. No overlayfs or anything like that.
<caribou> xnox: TL;DR : I don't want to break things that are not broken atm
<cjwatson> caribou: I'd stop agonising about it and just release a build fix if I were you :-)
<xnox> caribou: correct. it will be rebuild in the target's chroot and thus a harmless typo fix SRU will cause "crashes & segfaults"
<caribou> cjwatson: :-D correct.
<cjwatson> A package that can't be rebuilt safely is bad news
<caribou> cjwatson: I know, that why slangasek asked me to mark the bug  critical & fix it
<cjwatson> Right, so JFDI rather than worrying about all this :-)
<cjwatson> You'll get rebuilt binaries, verify that they still work, mark bug accordingly, move on
<caribou> cjwatson: oh, the SRU is done; just need a sponsor. I only had afterthoughts
<cjwatson> ok :)
<caribou> cjwatson: it'll be even worse when I get to upload it myself :-)
<caribou> xnox: thanks for the clarifications; was good learning
<bdmurray> pitti: Could you have a look at https://code.launchpad.net/~brian-murray/apport/check-contents-server-age/+merge/244071?
<xnox> caribou: it would have been even scarier to "upload a fixed source only to the archive ?" cause then you add an extra hop of possible exploadadge which has not been sru verified, sru+2 will not have common/known previous version of neither source or binaries.
<xnox> s/will not have/ would not have had/
<caribou> xnox: yes, indeed
<xnox> caribou: at lest with this fix, we can verify new binaries and either accept them as good, or fall back to known binaries - which we know are precious, since we can't rebuild them.
<xnox> caribou: and they will be frozen / accessible if one forces installation from release pocket, without -updates/-proposed/-security enabled.
<xnox> caribou: oh, and you do want this fix to be published in security pocket and copied into -updates probably.
<xnox> jdstrand: could you sponsor bug #1387594 into -security? any no-change rebuild of that package will explode at runtime into glitter
<ubottu> bug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/1387594
<jdstrand> mdeslaur, sarnold: can one of you help xnox with ^
<mdeslaur> jdstrand: sure
<cjwatson> xnox: That's not necessary; the next -security upload, if any, will be based on what's in -updates.  https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
<xnox> cjwatson: i did not know that.
<mdeslaur> xnox: yeah, we always rebase on -updates
 * xnox though -updates are rebased on top of -security
<cjwatson> xnox: That is also true.  https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories
<jdstrand> oh yeah, I didn't read that closely enough
<mdeslaur> both ways :)
<jdstrand> yeah, we're good already
<xnox> caribou: right, so just need normal SRU into -updates.
<mitya57> sil2100: no problem
<roadmr> hello folks, anybody from the ~xorg-edgers team in here?
<caribou> xnox: ok, thanks for checking
<caribou> now anyone can sponsor :)
<pitti> slangasek, mdeslaur, kees, infinity: hi! I try to attend the TB meeting today, but I'm at the snappy sprint so I might get pulled away on short notice
<mdeslaur> pitti: ack!
<pitti> kees, infinity, slangasek: TB meeting poke?
<mitya57> sil2100: can I reuse LGPL code written by mgraesslin (KDE guy) in appmenu-qt5 code, or it is not possible because he hasn't signed the CLA?
 * mitya57 wanted to steal QPlatformMenu{,Item} implementations from KDE
<stm> Hi there. I have two problems I want to discuss with some experts about building Ubuntu packages on launchpad.
<stm> It is especially about 64 bit packages.
<stm> First thing is that most of the time the compiler hangs on the server  - maybe due to limited memory. I had the same problem with by virtulized Ubuntu.
<stm> Ist there any "switch" to force launchpad to use a server with 2 GB memory?
<teward> stm: "building Ubuntu packages on launchpad" with respect to PPAs, or the main repository builders?
<stm> I have a PPA on launchpad.
<stm> What do you mean by main repository builders? Though these are any way the same computers - just a pool for the Ubuntu distro and "private" projects.
<teward> i meant the builders in the build farm (https://launchpad.net/builders)
<teward> just clarifying so the true experts can know what you're specifically referring to :)
<stm> Yes it is packed there - looks someone offers his private computer to do the packaging
<stm> My problem is that compiling the projects needs a real big memory - also the final program is just 20 MB.
<stm> Do not ask me why - I am just the package maintainer!
<teward> stm: i might be willing to dump your stuff into sbuild locally after i update my chroots, and then dump the built binaries onto one of my servers so you can then download them and use them via manual dpkg install, but the ppa builders, I think, are identical and take time to compile large projects
<stm> I tried to compile the program (gxsm.sf.net) on my virtual machine with 1 GB ram but did not succeed.
<teward> (you'd also have to define 'hangs' in better detail, because 'hangs' is ambiguous)
<teward> first, lunch.  *disappears for foods*
<cjwatson> stm: All the virtualised build nodes used for PPAs on Launchpad have a uniform setup with 4GiB of RAM.
<stm> \query cjwatson
<stm> I figured out that there are certain differences while building a package on my computer and via launchpad.
<cjwatson> stm: I'd need to see an example of the build that's hanging.  When you use debuild locally, though, you aren't working in a clean environment, so there could be any number of subtle differences.
<cjwatson> sbuild is a much better test.
<stm> One problem is also the path to the plugins being /usr/lib/gxsm-plugins on my computer and /usr/lib/x86-64-gnu/gxsm-plugins if compiled and packed on launchpad.
<cjwatson> stm: You're building on a different Ubuntu release, then, I expect.
<cjwatson> Launchpad is not doing anything special there itself.
<cjwatson> I'm pretty confident you'd see the same thing in sbuild locally, if you pointed it at the correct Ubuntu release.
<stm> I have Ubuntu 14.04 LTS running - 64 bit on a virtual machine
<cjwatson> The fix is likely to pass an appropriate plugin directory to the upstream configure script.
<cjwatson> (in debian/rules)
<stm> The upstream configure sets it to /usr/share/gxsm-plugins for both i386 and AMD64.
<cjwatson> /usr/lib/x86_64-gnu/ almost certainly comes from debhelper's standard behaviour of passing --libdir=${prefix}/lib/$(DEB_HOST_MULTIARCH) to configure.
<cjwatson> You can and should override that.
<stm> I did not want to maintain even different configure scripts.
<cjwatson> (Possibly --libexecdir.)
<cjwatson> You don't have to.
<cjwatson> But you still haven't told us where to find the offending build ...
<stm> Sorry - not as a quick writer than you: https://launchpad.net/~totto/+archive/ubuntu/gxsm/+build/6628573/+files/buildlog_ubuntu-trusty-amd64.gxsm_3.10.4-0ubuntu11_FAILEDTOBUILD.txt.gz
<cjwatson> That build appears to be failing with a compiler error, not hanging?
<stm> It is not hanging with I386 and not an my computer!
<cjwatson> But it's not a hang.
<cjwatson> It's just failing to compile.
<cjwatson> pyremote.C: In function 'PyObject* remote_move_delta_xyz(PyObject*, PyObject*)':
<stm> I had this on my computer as the memory (1GB) was too low.
<cjwatson> pyremote.C:766:23: error: 'class XSM_Hardware' has no member named 'Move_delta_XYZ'
<cjwatson>   gapp->xsm->hardware->Move_delta_XYZ (dx, dy, dz, NULL);
<cjwatson>                        ^
<cjwatson> I do not believe that that is a problem with insufficient memory.
<stm> The "search path" for the plugins is the in configure.ac as AC_DEFINE_UNQUOTED(PACKAGE_PLUGIN_DIR, "${ac_default_prefix}/lib/gxsm-plugins" or AC_DEFINE_UNQUOTED(PACKAGE_PLUGIN_DIR, "${prefix}/lib/gxsm-plugins", depending if "prefix" exists or not.
<cjwatson> There are two definitions of "class XSM_Hardware" in this project, and only one of them has a "Move_delta_XYZ" member.
<cjwatson> stm: debian/rules is constructed very strangely and really ought to be rewritten entirely or else you're going to get very confused in other ways.
<stm> There is an abstract class XSM_hardware and the final implementation.
<cjwatson> stm: Specifically it is extremely strange to use a %: dh $@ rule and then also manually write out clean, install, build, binary-indep, binary-arch.
<cjwatson> And DEB_BUILD_OPTIONS should not be set there.
<stm> I was happy to get it running any way. I know you can have the packaging just by a one line rule file but that did not work here.
<cjwatson> Oh, and DEB_CONFIGURE_EXTRA_FLAGS is ineffective.  That comes from cdbs, which you are not using here.
<cjwatson> None of this is a problem with Launchpad - you could reproduce the exact same problem with sbuild.  https://wiki.ubuntu.com/SimpleSbuild
<cjwatson> I recommend investing time in setting that up
<cjwatson> But let me see if I can give you a sketch of a better-constructed rules file
<cjwatson> I see no evidence of the /usr/lib/$(DEB_HOST_MULTIARCH)/gsxm-plugins/ problem you mention in the working i386 build, by the way ...
<cjwatson> Anyway, since this package doesn't install any libraries of its own, it's safe to override dh_auto_configure and pass --libdir; though the upstream should really be modified to use libexecdir for that.
<stm> The sbuild looks a little like the pebuilder enviroment, doesn't it?
<cjwatson> More or less, yes.
<cjwatson> (You mean pbuilder, I think.)
<stm> yes
<cjwatson> The upstream configure.ac is inconsistent in other ways.  It defines PACKAGE_PLUGIN_DIR, but then defines plugindir differently.  It should be revised upstream.
<stm> okay - guess that part was introduced 10 years ago. Certainly one would do better. Everyone is learning!
<cjwatson> stm: I would start by reducing debian/rules to http://paste.ubuntu.com/9444836/, with an added Build-Depends on dh-autoreconf (in debian/control).
<stm> see the point about the two definitions - thanks for pointing this out.
<cjwatson> stm: And then it will be much easier to follow if you put an upstream tarball in the parent directory as gxsm_3.10.4.orig.tar.gz, so that the source package is constructed with all the packaging bits in a separate file.
<cjwatson> stm: I see that you have a build rule that copies src to gxsm.  I suspect that what's happening here is that the conflict between your catch-all % rule and the manual "build" rule is resolved differently on amd64 vs. i386 - on trusty, i386 will go via "build" and all other architectures will go via "build-arch".  That's why you'll have a better time sticking to one syntax.
<cjwatson> stm: So the effect of that is that you end up with a stale copy of src used for other architectures.
<cjwatson> stm: You should make sure to clean up the gxsm directory at some point, if you need to do it that way at all (it's an odd way to do things, though occasionally necessary); in my rewritten rules file you'd use an override_dh_auto_clean rule to do that.
<cjwatson> stm: (Oh, you do clean it up at the start of build, I see.  Still, I'd recommend doing that in clean instead.)
<stm> @cjwatson - let me try that shortened rules files and have a look.
<udevbot> Error: "cjwatson" is not a valid command.
<stm> I will try tonight to modify - right now I have just a hand on a windows machine - need my laptop at home.
<cjwatson> So to explain it a little differently, the conflict between two entirely different styles in debian/rules meant that, without realising it, you had one build rule which was run on i386 and one build rule which was run on all other architectures (for your PPA, that's just amd64).
<cjwatson> And those two build rules had nothing in common ...
<stm> see the problem now a little by more clear.
<cjwatson> I haven't actually tested my rewritten file, of course :)
<stm> Now problem - I will do that!
<stm> You mind if I contact you again - for some progress report?
<stm> I will have to go home now - I am for 12 h at the university and need urgently food and my girl friend.
<stm> I have also the alias stm at sourceforge.net - so in case you have another briliant idea.
<stm> But your input was already helping me to get a new view on may problem.
<stm> So thank you very much, cj
<cjwatson> stm: I don't mind, but in general I'm only around in UK working hours.
<cjwatson> stm: No need to contact me if it works.
<stm> Thanks and bye.
<dannf> what's the appropriate list to discuss enabling 64K pages on arm64? ubuntu-devel-discuss?
<stm> <cjwatson> Are you stil online?
<stm> Got it mostly working, but now it hangs during the install.
<stm> 	cp -a debian/tmp/usr/bin/gxsm2 debian/gxsm//usr/bin/ cp: cannot stat âdebian/tmp/usr/bin/gxsm2â: No such file or directory
<stm> Guess the error is in the gxsm.install
<stm> Here I have just the line "usr/bin/gxsm2"
<TheNumb> o/
<sarnold> doko: are you sure intel-microcode can go to main? it does include intel-provided binary blobs.  https://bugs.launchpad.net/bugs/1388889
<ubottu> Launchpad bug 1388889 in intel "[MIR] intel-microcode & iucode-tool (multiverse -> restricted)" [Undecided,New]
<doko> sarnold, my mistake, now fixed
<sarnold> doko: thanks
<brainwash> pitti: will you package systemd 218 (once available) or will 15.04 ship with 217?
<brainwash> I'm not sure if I should request to pick a commit from git
<brainwash> http://cgit.freedesktop.org/systemd/systemd/commit/src/libudev/libudev-hwdb.c?id=8232e39e7cf32071e11b3b04839e6c98fbc81d0f
<brainwash> :)
<shadeslayer> kirkland: do you know where I can get the source for the snappy tool?
<shadeslayer> or maybe even design docs or whatever to get a idea of what magic is going on underneath
<kirkland> shadeslayer: https://code.launchpad.net/~snappy-dev
<shadeslayer> cheers
<kirkland> shadeslayer: snappy is built on click (the package system for the ubuntu phone)
<shadeslayer> ah ok
#ubuntu-devel 2014-12-10
<shadeslayer> out of curiousity, is there a smarter way to deal with problems like apt-get update failing on jenkins because of a hash mismatch error? or do I just keep retrying the command
<shadeslayer> *jenkins job
<peacememories> hm, i'm not really sure how frameworks are supposed to work on snappy
<hallyn> pitti: i wasn't planning o nmerging samba - i hate to take zul's fun away from him :)  but i'm finally back tomorrow so can take a look soon if needed
<hallyn> bdmurray: smb has fixed the kvm-spice bug in qemu
<hallyn> seb128: cgmanager is disabled by default in systemd bc systemd prefers to own all the cgroup management
<pitti> brainwash: I'll most certainly package 218
<pitti> Good morning
<pitti> hallyn: welcome back! did you enjoy your holidays?
<dholbach> good morning
<ari-tczew> hello
<doko_> Riddell, ScottK: please could you build opengtl with the default llvm/clang? This one prevents removal of llvm-3.3
<cjwatson> shadeslayer: launchpad-buildd has a thing where if apt-get update fails then it waits a short period of time and immediately tries again (only once); this seems enough to dispose of the vast majority of problems
<shadeslayer> cjwatson: I see
<cjwatson> infinity: You synced libpoe-component-client-dns-perl from unstable, but apparently it still fails with the same test failure that caused there previously to be a delta (see 1:1.051-1ubuntu1).  Fancy reintroducing that delta?
<mitya57> sil2100, nevermind the previous question, I have (re-)written that myself.
<hallyn> pitti: had its upsides, had huge downsides sadly.
<hallyn> but now back to work :)
<cjwatson> doko_: missing build-dep on expect for gcc-*-cross, maybe?
<doko_> cjwatson, no, dpkg introducing DEB_TARGET architectures
<cjwatson> ah ...
<doko_> these should build after the current gcc-4.9 upload
<doko_> dpkg-archoitecture introducing DEB_TARGET_* variables even
<smb> hallyn, while I see you... I wanted to do a small update to qemu in U and T for allow it to be used by Xen dom0 (bug 1394327). For U there still seems an upload in proposed, which I am not sure about getting verified as the reporter verified Trusty.
<ubottu> bug 1394327 in qemu (Ubuntu Trusty) "unmapping of persistent grants in qemu" [Medium,In progress] https://launchpad.net/bugs/1394327
<smb> Is there anything else we can do?
<hallyn> smb: i'm confused
<hallyn> smb: noone has verified that near as i can tell
<hallyn> oh i see.
<smb> comment #17
<hallyn> there are 2 comments
<hallyn> smb: which bug needs verification
<smb> bug 1368815
<ubottu> bug 1368815 in OpenStack Compute (nova) "qemu-img convert intermittently corrupts output images" [High,In progress] https://launchpad.net/bugs/1368815
<hallyn> smb: sorry for hte delay, for some reason launcpad isn't loading for me.  (weird internet issues)
<smb> hallyn, Heh yeah, some days are just painful
<hallyn> but seriously, i've tried two different connections and two browsers, and the bug just won't load all the way
<hallyn> smb	ok, so issmb	did you try reproducing on utopic?
<hallyn> yikes
<hallyn> smb: unless you get to it in the next few hours, i'll complete the verification this afternoon for that bug
<smb> hallyn, No, well that bug was nothing I was observing. Its something that someone else had, you uploaded the fixes and it only got verified for T
<smb> hallyn, Ok, wfm. Then I can base on that version for what I prepare for upload
<hallyn> understood, but someone needs to reproduce wit hthe testcase, or else at least run the qa-regression-testing qemu testcase on it :)
<hallyn> ok - i'll do it this afternoon then - ttyl
<smb> hallyn, ack. thanks
<FunnyLookinHat> Anyone know what IRC channel would be appropriate for snappy related stuff?
<popey> #snappy
 * FunnyLookinHat should have figured....
<FunnyLookinHat> :D
<popey> â»
<FunnyLookinHat> thx!
<infinity> cjwatson: I did?  Pretty sure that was bhavi, according to LP.
<cjwatson> infinity: Oh, right, you moved it to vivid-proposed from utopic-proposed, that explains my confusion
<cjwatson> (and indeed from trusty-proposed)
<cjwatson> OK, I'll reintroduce that delta
<infinity> cjwatson: I could do it anyway, was just correcting your blame. :P
<cjwatson> infinity: Might be more sensible for you to end up with the future merge than me, if you don't mind
<infinity> cjwatson: Fine by me, it's 2 lines.  Will do.
<cjwatson> ta
<bdmurray> pitti: py3cairo ddebs are missing for the latest version only arm64 has appeared
<bdmurray> tseliot: are you working on bug 1376966?
<ubottu> bug 1376966 in ubuntu-drivers-common (Ubuntu) "gpu-manager treats all files in /etc/modprobe.d as config files" [High,In progress] https://launchpad.net/bugs/1376966
<tseliot> bdmurray: the fix is in utopic (in 1:0.2.98.4) but apparently I forgot to backport it
<bdmurray> tseliot: I'd be happy to review it when you get it in the proposed queue - just let me know.
<tseliot> bdmurray: I've just uploaded ubuntu-drivers-common 0.2.91.8 in trusty-proposed. Thanks for your help, and for reminding me
<hallyn> arges: would you mind looking at the last comment in bug 1368815 and ack/nacking?
<ubottu> bug 1368815 in OpenStack Compute (nova) "qemu-img convert intermittently corrupts output images" [High,In progress] https://launchpad.net/bugs/1368815
<arges> hallyn: looking
<hallyn> arges: thanks.  (smb needs that cleared one way or the other, so if nacked that's fine - i'll just request thta we drop the package so smb cna proceed)
<arges> hallyn: seems like an important fix; and interestingly enough they have to reproduce on ext3 or ext4 without extent filesystems
<arges> hallyn: which is what i'm seeing on the other corruption bug...
<arges> hallyn: i think we should ACK it if someone is reporting it as fixing issues in trusty at least
<arges> for utopoic
<smb> It also would feel a little silly to reject something when it did verify on Trusty. But ok. I probably should have had a deeper look and tried to reproduce/verify it
<smb> But somehow there is many loose ends and seemingly so few days in this year left
<arges> smb: hmm... maybe i'm hitting the same corruption bug because i createdd my qcow2 image _before_ applying this patch. I'll try it out
<arges> then maybe I can verify this bug too. I tested with latest mainline, but created the qcow2 image with the unpatched version
<smb> ah ok. at least something worth trying
<arges> smb: so i'll try verifying it for now if that's alright
<smb> yeah sure... I am rather close to "go away" for today anyway
<arges> smb: yea, i still need to review your other package
<smb> arges, you can take your time with that. if we can get qemu released thats probably worth a bit more to me right now
<arges> smb: ok
<arges> smb: where is the new qemu fix? in unapproved?
<smb> arges, right now as in get me proceeding tomorrow
<smb> arges, no not uploaded yet
<smb> I am preparing them but wanted the path clear before I upload and be sure I base on the right thing
<arges> hallyn: do you have a decent reproduce for bug 1368815 ? I tried using the other reproduce i had for bug 1292234 and I still get issues with non-extents filesystems. I'm not sure what SRC_PATH is supposed to point at
<ubottu> bug 1368815 in OpenStack Compute (nova) "qemu-img convert intermittently corrupts output images" [High,In progress] https://launchpad.net/bugs/1368815
<ubottu> bug 1292234 in qemu (Ubuntu) "qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)" [High,Confirmed] https://launchpad.net/bugs/1292234
<hallyn> arges: i don't,
<arges> hallyn: also there is this patch http://git.qemu.org/?p=qemu.git;a=commit;h=c4875e5b2216cf5427459e619b10f75083565792 where they remove FIEMAP
<arges> and d1f06fe665acdd7aa7a46a5ef88172c3d7d3028e, but not sure if that side steps the original issues (in case we hit this again)
<hallyn> arges: so yes i did consider that those two bugs might be related :)  but i'm kina lost in it
<hallyn> my position would be the fix was verified o ntrusty, it still passes qrt, so ship it an dmov eon
<arges> hallyn: i'll keep digging, i'm inclined to still ack that fix for the time being while ic ontinue to dig at the other one
<arges> hallyn: agree
<hallyn> arges: agreed, and if someone runs into it again, we could try the other two commits.  do you mind noting those in that bug just for posterity?
<arges> hallyn: sure
<mdeslaur> arges, hallyn: so, I want to release security updates for qemu
<mdeslaur> arges, hallyn: do I supersede the one in utopic, or will one of you mark it as verification-done, so I can use it
<arges> mdeslaur: i'll mark it verification done
<mdeslaur> arges: ok, I'll base my update on -proposed then, thanks
<arges> mdeslaur: ok done : ) thanks for letting us know
<hallyn> smb: ^ you may as well wait a few days :)
<bdmurray> stgraber: should bug 924511 still be assigned to you?
<ubottu> bug 924511 in ubiquity (Ubuntu) "ubiquity tells me my computer name already exists on the network - hostname lookup can be slow" [Low,Triaged] https://launchpad.net/bugs/924511
<stgraber> bdmurray: probably not, installer bugs are very very far down my list at the moment
<sil2100> pitti: hey! Are you around by any chance?
<Unit193> sil2100: You could poke him about the new cryptsetup in Debian too, has much better support for systemd. :P
#ubuntu-devel 2014-12-11
<FourDollars> It seems no patch pilot now. Is anyone willing to review and sponsor my patch on https://bugs.launchpad.net/ubuntu/+source/clutter-gtk/+bug/1401376?
<ubottu> Launchpad bug 1401376 in clutter-gtk (Ubuntu) "Totem video playback doesn't support scale factor well." [Undecided,New]
<smb> hallyn, mdeslaur, Stomped by security... the sad story of my life... :-P
<dholbach> good morning
<cjwatson> Laney: Did you notice that your libsoup2.4 sync FTBFS on powerpc and ppc64el?
<Laney> cjwatson: Yes - I fixed the immediate failure and then reported an upstream bug about a hanging testcase
<Laney> Waiting to hear back now
<cjwatson> Laney: ok, thanks
<Laney> I'll skip the test or something by the end of the day
<xnox> stgraber: mvo: it looks cool, well done! =)
<mdeslaur> smb: sorry about that, I'll probably release the updates today :P
<smb> mdeslaur, Heh yeah. Thats a hope :)
<cjwatson> Noskcaj: I think if you wanted to merge dhelp that it would actually manage to migrate to vivid now; I fixed up ruby-bdb
<cjwatson> (by way of a sync and some NBS removals)
<Riddell> pitti: this seems to be a problem with the jenkins server not with the package? https://jenkins.qa.ubuntu.com/job/vivid-adt-kate/lastBuild/console
<cjwatson> Riddell: there's already a retry in the queue
<Riddell> groovy
<cjwatson> running, in fact
<cjwatson> queue's a bit long because there were some infrastructure problems over the last couple of days so lots of retries last night / this morning
<Riddell> I'll be patient :)
<mdeslaur> pitti, kees, infinity, stgraber, slangasek: next tech board meeting is scheduled for dec 23rd, shall we skip it and have it jan 6th instead?
<pitti> mdeslaur: sounds good to me; I'm still on vac on jan 6, but I'll make it
<pitti> Riddell: yeah, I'm afraid the whole CI infrastructure got broken due to the data center move; things should move back into place soon
<peacememories> heya, any ubuntu-core people here?
<bdmurray> tseliot: can you have a look at bug 1401390?
<ubottu> bug 1401390 in nvidia-graphics-drivers-331 (Ubuntu) "apt-get install nvidia-331 triggers 691 packages to be installed" [High,Confirmed] https://launchpad.net/bugs/1401390
<tseliot> bdmurray: looking
<tseliot> bdmurray: nvidia provides libopencl and apparently that is being picked up before ocl-icd-libopencl1 (alphabetical order seems to be the criterion)
<tseliot> bdmurray: ok, I know what happened. nvidia-libopencl1-331 now depends on nvidia-331-uvm, which, in turn, depends on nvidia-331. The dependency is correct but nvidia-libopencl1-331 shouldn't have been installed in the first place (since it only works with nvidia)
<slangasek> mdeslaur: sounds good to me
<bdmurray> mvo: Could you have a look at bug 1399455?
<ubottu> bug 1399455 in ubuntu-release-upgrader (Ubuntu Vivid) "distribution upgrade from utopic uses DistUpgradeViewText" [High,Triaged] https://launchpad.net/bugs/1399455
<bdmurray> pitti: did you see my ping about the py3cairo debugy packages missing?
<tseliot> doko: ping
<doko> tsdgeos, ?
<tsdgeos> me what?
<tsdgeos> ah, wrong autocomplete
<tseliot> doko: libhwloc-plugins seems to pull in the libopencl1 virtual package, which, in turn, pulls in nvidia-libopencl1-331 instead of ocl-icd-libopencl1, and results in LP: #1401390
<ubottu> Launchpad bug 1401390 in nvidia-graphics-drivers-331 (Ubuntu) "apt-get install nvidia-331 triggers 691 packages to be installed" [High,Confirmed] https://launchpad.net/bugs/1401390
<sil2100> mitya57: oh! I see your PlatformSystemTrayIcon branch for appmenu-qt5!
<rbasak> pitti: some help with apport please? In mysql, we currently intentionally fail an attempted downgrade from eg. 5.6 to 5.5 in the preinst, causing the maintainer script to exit non-zero with a message.
<rbasak> pitti: this triggers apport. But in this case it isn't a bug, so is there some way to tell apport it's OK?
<rbasak> An alternative we're considering is to succeed but then let mysql be broken for manual fixing.
<rbasak> We've decided to let the maintainer script succeed but disable daemon startup.
<rbasak> (with a debconf note explaining)
<rbasak> That's maybe better. So never mind.
<roadmr> hello folks! Is there a way to update lxc cache (/var/cache/lxc/$RELEASE)? The apt data is out of date so I always have to do apt-get update in every lxc container I create :/
<roadmr> (I could clearly just delete the cache so lxc-create rebuilds it from newest sources, but that'd be quite slow)
<tseliot> bdmurray, doko: apparently, we only need to rebuild hwloc so as to get the correct dependencies: Depends: libc6 (>= 2.4), libltdl7 (>= 2.4.2), libopencl-1.1-1, libpciaccess0, libxml2 (>= 2.7.4), ocl-icd-libopencl1 (>= 1.0) | libopencl1, libhwloc5
<bdmurray> rbasak: for future reference not really to prevent the crash notification from appearing, but to stop it from being submitted you could write a bug pattern.
<tseliot> bdmurray: do I still need an SRU for a simple rebuild?
<tseliot> (a no-change rebuild
<tseliot> )
<bdmurray> tseliot: I think so. slangasek?
<slangasek> tseliot, bdmurray: yes; if you're rebuilding from source, there's plenty of room for something else to go wrong
<tseliot> slangasek, bdmurray: ok, it makes sense. Speaking of which, I have just uploaded the change for hwloc
<bdmurray> slangasek: we'd want a bug for tracking that too then right?
<slangasek> yes
<tseliot> bdmurray, slangasek: I reassigned the bug to hwloc, requested an SRU and uploaded the sources. It should all be ready
<bdmurray> tseliot: okay, I'll review it today
<tseliot> bdmurray: thanks
<rbasak> bdmurray: thanks. I did suggest that but we thought it was bad for the user to get the crash notification too.
<bdmurray> tseliot: what about utopic?
<tseliot> bdmurray: same problem :/ let me fix that one too
<bdmurray> tseliot: thanks!
<tseliot> bdmurray: what version shall I use?
<bdmurray> tseliot: 14.04.1 and 14.10.1 would have been ideal
<tseliot> bdmurray: I uploaded 1.8-1ubuntu1.1 in trusty-proposed but the one in utopic is still at 1.8-1ubuntu1
<tseliot> bdmurray: if you want to reject the one in trusty-proposed, I'll reupload
<bdmurray> tseliot: right so instead 1.8-1ubuntu1.14.04.1 would be better
<tseliot> bdmurray: ok, please reject the one in the queue then
<bdmurray> tseliot: done
<tseliot> thanks
<cjwatson> mvo: I just noticed that https://launchpad.net/ubuntu/+source/apt/1.0.1ubuntu2.2 was shadowed by a security update and so never released to trusty-updates.  Is it easy for you to rebase that on top of the current trusty-updates (maybe in git), or should I just go ahead and do it?
<tseliot> bdmurray: ok, uploaded
<bdmurray> arges: to be clear bug 1368815 is v-done for utopic?
<ubottu> bug 1368815 in OpenStack Compute (nova) "qemu-img convert intermittently corrupts output images" [High,In progress] https://launchpad.net/bugs/1368815
<arges> bdmurray: yes, sorry to confuse the bug comments; I was also trying to hunt another qcow2 corruption bug, but it is a separate issue
<bdmurray> arges: no problem, just wanted to err on the side of caution
<kkirsche> Hey guys, I've been looking around but I haven't been able to identify this, what package is used to create the graphical installer used by ubuntu or where can I find the source code for the graphic installer?
<bdmurray> kkirsche: ubiquity
<kkirsche> thank you bdmurray I'll look at that. Thank you
<bdmurray> smb: do you want this new dahdi-linux accepted before the other upload is verified?
<smb> bdmurray, Yeah, it actually fixes the first at least in Precise
<smb> changes contains both so verification of both should be carrying on
<bdmurray> smb: got it, thanks
<bdmurray> Riddell: it looks like there is a typo in your lixext upload. https://launchpadlibrarian.net/192182678/libxext_2%3A1.3.2-1_2%3A1.3.2-1ubuntu0.1.diff.gz
<_Groo_> hi/2 all
<mdeslaur> smb: ok, qemu updates for stable releases done.
<MasterPiece> Hello all :)
<MasterPiece> https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1401646
<ubottu> Launchpad bug 1401646 in gsettings-desktop-schemas (Ubuntu) "Shortcuts bug ( When press the "Ctrl + Alt", window Minimized )" [Undecided,New]
<timrc> kirkland, So none of the snappy commands to update the system and install packages requires sudo... at least on that KVM image you linked too in your blog
<timrc> s/too/to/ (still have 33 years I cannot get that one right :))
<smoser> infinity, is there some official thing / test that needs to happen to make the utopic-* things (hwe updates) in http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/ able to move to -updates ?
<smoser> i can do a quick sniff of them.
<timrc> kirkland, Ah I took a look at the code... calling sudo from inside snappy
<mwhudson> is there a cross toolchain targetting ppc64le in the archive?
<mwhudson> ah, yes
<smoser> timrc, you're not the first person  to notice that. :)
<smoser> it will change to your expectation
<timrc> smoser, Nice.  Yeah... it seems a little... un-ubuntu-y
<infinity> smoser: If you can test i386 generic and utopic-generic for me and make sure they both boot and install the expected kernel, that would be great.
<infinity> smoser: I've tested amd64, ppc64el, and powerpc64, and I've had arm64 tested.  That just leaves armhf.
<smoser> infinity, someone going to do that ? thats not one i can easily test.
<infinity> smoser: My house in a bit of a pre-move mess, so finding bits to test with has been challenging, but if I can't put together what I need, I'll get someone else to test.
<infinity> Actually, I could probably test it in qemu, if we build the right DTB for vexpress...
 * infinity checks.
<infinity> Yeah, I can probably fudge something together to test armhf on my laptop.
<smoser> infinity, i'd be interested in knowing how  you do that .
<smoser> if you dont mind writing it donw
<infinity> Well, the only annoying bit is going to be extracting (or building) the right DTBs, since I don't ship them with d-i, apparently.
<infinity> I should fix that.
<infinity> smoser: This seems to be doing the trick:
<infinity> qemu-system-arm -M vexpress-a9 -m 1G -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca9.dtb -serial stdio -nographic -no-reboot -append "console=ttyAMA0" -sd armhf.img
<infinity> smoser: Will know more once I've installed.
<infinity> smoser: Oh, ditch the -nographic, qemu's I/O multiplexer seems to go insane without the graphics console being up.
<infinity> smoser: Yeah, nevermind.  That all ended very poorly.  I'm going to hunt down an SD card and my Panda.
<infinity> ... and fix d-i on qemu another day.
#ubuntu-devel 2014-12-12
<dholbach> good morning
<tsdgeos> any idea what's wrong with linux-firmware in vivid?
<tsdgeos> it doesn't want to be installed
<tsdgeos> ah
<tsdgeos>  s'estÃ  intentant sobreescriure Â«/lib/firmware/sms1xxx-hcw-55xxx-dvbt-02.fwÂ», que tambÃ© estÃ  en el paquet linux-firmware-nonfree 1.16
<seb128> hey there
<seb128> console-setup init's script does
<seb128> 	if expr "$(fgconsole 2>/dev/null || true)" : '[1-6]$' >/dev/null && \
<seb128> 	   (! type plymouth >/dev/null || ! plymouth --ping); then
<seb128> 	    log_action_begin_msg "Setting up console font and keymap"
<seb128> does anyone know why the fgconsole [1-6] check?
<brendand> seb128, i probably shouldn't be guessing but isn't 7 normally X?
<brendand> seb128, looks like a dodgy heuristic to me. but i'm probably not qualified to say. just a guess
<seb128> brendand, yeah, seems to prevent accidentally running that init script under X
<seb128> but init systems run things on vt7 so that seems a buggy check
<didrocks> cjwatson: I'm trying to push my patch to add an upstart additional entry if case there is another default init system
<didrocks> cjwatson: I was wondering why quilt push -a (and so gpb import) doesn't work on the git branch (master)
<didrocks> gbp-pq import*
<didrocks> there is probably some magic that I'm missing?
<cjwatson> didrocks: (a) no idea what package you're talking about (b) on holiday
<cjwatson> grub2?  if so you want git-dpm
<didrocks> cjwatson: oupsss sorry, grub2 yeah
<didrocks> ah, git-dpm, never used that one, /me looks
<didrocks> cjwatson: sorry, enjoy your holidays :)
<cjwatson> didrocks: http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html
<cjwatson> though I would ask that you PLEASE not fork grub2 in Ubuntu
<cjwatson> I put massive amounts of effort into resyncing it
<didrocks> cjwatson: perfect, thanks for the reference :)
<didrocks> cjwatson: yeah, that's why I'm using master and will attach the fix to a debian bug
<cjwatson> right, great
<didrocks> cjwatson: will probably poke you (so next year) for a review if possible
<cjwatson> well, I expect that at some point over the holidays I'll be doing the same kind of thing for sysvinit in Debian
<cjwatson> so ideally roughly the same thing would be reusable for both
<didrocks> cjwatson: I can add sysvinit as well if you wish
<cjwatson> there's a Debian bug for that already, you could follow up to that and see if it can be adapted
<didrocks> ok :)
<cjwatson> no point in adding sysvinit for Ubuntu, but I'd just like to avoid too much spaghetti
<cjwatson> I don't recall the bug# right now, hopefully it's not too hard to find though :)
<cjwatson> thanks
<soren> What's "ubuntu-rtm"?
<didrocks> cjwatson: will, do, no worry, enjoy your holidays :)
<cjwatson> ta :)
<cjwatson> 5.5 days, yay
<soren> It shows up in rmadison output.
<infinity> soren: A derived distro, frozen in time and space, used for cleaning things up for Release To Manufacturing for phone stuff.
<cjwatson> soren: https://lists.ubuntu.com/archives/ubuntu-release/2014-June/002878.html and thread
<infinity> soren: Safely ignorable for anyone not working on that.
<infinity> soren: Alternately, let Colin be your Google.
<cjwatson> s/Colin/Colin's Firefox history/
<cjwatson> that thing is sentient
<infinity> Yeah, I get very frustrated when I'm on a machine that doesn't have my profile.
<soren> cjwatson, infinity: Ah, ok. Thanks :)
<infinity> The best part, though, is when I start typing a URL and it's all "yeah, you've have that open in a tab for the last seven months, no really, lemme show you."
<infinity> I really need to kill this session off.
<doko> cjwatson, I assume isl should be ready to migrate, minus pending autopkg runs
<seb128> sforshee, hey, did you see bug #1401711 ?
<ubottu> bug 1401711 in linux-firmware (Ubuntu) "package linux-firmware 1.138 failed to install/upgrade: Versuch, Â»/lib/firmware/sms1xxx-hcw-55xxx-dvbt-02.fwÂ« zu Ã¼berschreiben, welches auch in Paket linux-firmware-nonfree 1.16 ist" [Undecided,New] https://launchpad.net/bugs/1401711
<seb128> seems like a missing conflicts/replace
<sforshee> seb128: ack, I'll take a look
<seb128> sforshee, thanks
<bdmurray> pitti: are you about?
<tkamppeter> Anyone around in the SRU team to take care of bug 1386241? I want to put this SRU on hold to do another SRU on system-config-printer first, as this SRU still needs some fixing.
<ubottu> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Fix committed] https://launchpad.net/bugs/1386241
<teward> anyone know what i should do if i have a PPU application i want to file but none of the meeting times work in my schedule of availability for the DMB meetings?
<cjwatson> teward: I believe it can be done by mail if you explain the problem in your mail to devel-permissions
<cjwatson> (caveat: not a DMB member)
<teward> cjwatson: okay, i did, just waiting for any kind of response :)
<smoser> cjwatson, did i make it up that d-i copies parms after '--' over to the installed system ?
<roadmr> smoser: not made up, that's what happens (ubiquity does it too, IIRC)
<smoser> roadmr, yeah, thats what i thought.
<smoser> https://bugs.launchpad.net/maas/+bug/1402042
<ubottu> Launchpad bug 1402042 in MAAS trunk "console= parameters need to be added before -- on kernel cmdline" [Undecided,New]
<smoser> makes that fun.
<brainwash> arges: this report may interest you https://bugs.freedesktop.org/show_bug.cgi?id=76935
<ubottu> Freedesktop bug 76935 in general "Do not parse "debug" command line parameter" [Normal,Resolved: fixed]
#ubuntu-devel 2014-12-13
<israel> Hi I am trying to build a minimal Ubuntu in a chroot and tar it and then copy it to another machine as the OS.  I can do all that... however I am having a few issues.  One being that network-manager claims it isn't running.  I have similar issues using wicd.  I do install ubuntu-minimal and ubuntu-standard with its recommends.  Anyone have any suggestions where to get more help?
<israel> Hi I am trying to build a minimal Ubuntu in a chroot and tar it and then copy it to another machine as the OS.  I can do all that... however I am having a few issues.  One being that network-manager claims it isn't running.  I have similar issues using wicd.  I do install ubuntu-minimal and ubuntu-standard with its recommends.  Anyone have any suggestions where to get more help?
<Noskcaj> doko_, Is there any reason you maintain python-service-identity separately in debian and ubuntu?
<soren> I have an amd64 server which attempts to fetch i386 Package lists from my mirror which is amd64 only. How do I disable that? Didn't there used to be a file in /etc/dpkg telling it to look for i386 so that I could just disable that?
<Noskcaj> soren, What ubuntu release? It might be the arch: all packages, which are built on i386
<soren> Noskcaj: No, this is about apt fetching the Package lists, not about specific packages.
<Noskcaj> ok, ignore me then
<soren> Hm. dpkg --remove-architecture i386
<soren> ...solved it, apparently.
<soren> I swear that didn't used to be how this was done.
<teward> is there a way to nuke all sbuild schroots and rebuild them manually?
<teward> (not sure where else to ask)
<soren> teward: Assuming they're in the standard location, you can delete them from /var/lib/schroot/ and /etc/schroot.d/
<teward> soren: thanks, that seems to have worked - ended up having to reboot into a root prompt (recovery mode) in order to burn them into dust, but that's not too difficult
<teward> the shm-overlays apparently were breaking things so i had to nuke them AND the chroots, and start afresh...
<soren> teward: Ah, yeah, if you had active sessions you should have nuked those first.
<teward> soren: y'know what I had noticed?  They wouldn't shut off
<soren> teward: Something like "schroot -e -a"
<soren> teward: Maybe you were being too polite.
<teward> soren: `sudo umount --force`, `sudo rm -rf /path/*`, `I will burn you unto dust!` was being too polite?
<teward> soren: to be fair i would rather have nuked them BEFORE they're loaded at all, rather than messing with manual deactivation - root recovery prompt has its uses :P
<teward> i think I'll just not use shm overlays this time and see what evils may happen
<doko_> Noskcaj, there was a packaging issue with some of the dependencies
#ubuntu-devel 2014-12-14
<Noskcaj> ok
<aixnr> Question about Ubuntu Core here. Does anyone know whether it has adopted the rolling release model instead of software versioning like Ubuntu currently does?
<Noskcaj> jpds_, There's a new upstream release of efi-tools. Could you please package it and make the package amd64-any only
<Noskcaj> Is anyone working on the openjpeg2 transition?
#ubuntu-devel 2015-12-07
<pitti> Good morning
<pitti> cjwatson: in that case these are usuall "temporary testbed failures", I'll sort them out
<pitti> cjwatson: we had gazillions of failures and retrys over the weekends due to some cloud trouble again, sorry
<pitti> Mirv: filing a bug and overriding WFM
<Mirv> pitti: ok
<Mirv> pitti: bug #1523364 filed
<ubottu> bug 1523364 in kwin (Ubuntu) "Workarounding screen edge test breaks xrandr test" [Undecided,New] https://launchpad.net/bugs/1523364
<pitti> Mirv: thanks! hinted kwin
<highvoltage>  /win 38
<dholbach> good morning
<sladen> likewise
<Mirv> pitti: thanks! what's up by the way with all the "Test in progress" ones that don't seem to happen? for example I see akonadi-calendar, frameworkintegration etc for armhf at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src but not in http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-armhf
<seb128> hey dholbach
<dholbach> hey seb128
<Mirv> or ubuntuone-credentials for all archs
<Trevinho> Hi folks
<robert2> Hi
<robert2> when I using wily in armhf,but dash and left bar miss
<robert2> dconf reset -f /org/compiz/ && setsid unity
<robert2> compiz (opengl) - Fatal: GL_OES_EGL_image is missing  is output
<Mirv> xnox: I prefer having qt uploads through CI Train so that I know what's landing - I was preparing ubuntu2 for now but I will import your changes to the packaging git and switch to ubuntu3 instead
<pitti> Mirv: I'll take care of that
<alkisg> pitti: good morning, I'm seeing a regression for LP: #1492546 in 228-2ubuntu1, is it by design or should I try to find out what exactly caused it?
<ubottu> Launchpad bug 1492546 in systemd (Ubuntu) "Systemd runs ifdown on shutdown even when it shouldn't" [Medium,Triaged] https://launchpad.net/bugs/1492546
<pitti> alkisg: that surely doesn't sound like it's by design; maybe indeed some unintended change
<smb> Logan, I probably should (dahdi) as time allows. There were a few things more pressing before.
<pitti> didrocks, tseliot, apw: so wrt. plymouth and vga16gb: last time I saw a computer with an nvidia card, it looked pretty much like a text plymouth interface
<pitti> is there really much difference between the vga16fb renderer and the text one?
<pitti> i. e. could we drop the former?
<robert2> https://bugs.launchpad.net/compiz/+bug/1086736 is sloved?
<ubottu> Launchpad bug 1086736 in mesa (Ubuntu) "[quantal] [regression] compiz (opengl) - Fatal: GL_OES_EGL_image is missing" [Undecided,Confirmed]
<robert2> ubottu> I find that bug,but I don't know how to fix it
<ubottu> robert2: I am only a bot, please don't think I'm intelligent :)
<apw> pitti, i cirtainily only care it works in that situation it is such a short period of time
<Mirv> pitti: sorry to ping so much but the hinting is not seen on excuses page although it was updated 25min ago
<pitti> Mirv: odd indeed; the hint is there, I'll check closer in a bit
<xnox> Mirv, sure, however s390x builds are not done for landings yet, as far as i know.
<Mirv> xnox: ah, true that, they'd be nice to have soonish as s390x progresses. anyway, I'm nearing the now ubuntu3 testing so if you have anything new for that, send the to me and I can combine.
<tseliot> pitti, didrocks: right, I had to disable that for nvidia but it should no longer be an issue to re-enable it (I simply forgot to do it).
<pitti> tseliot: do we have to?
<didrocks> yeah, it's been like that for cycles, isn't it?
<pitti> tseliot: if so, I guess it has been disabled for a long time alreddy?
<Mirv> xnox: the packaging btw is at http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/log/?h=ubuntu
<xnox> Mirv, well, that my upload still failed tests on s390x, i have made the tests run with -k now, to see all failures.
<tseliot> pitti: as a matter of fact, we probably don't. I haven't tested the KMS module that nvidia provides now
<pitti> tseliot: wow, did I hear "nvidia" and "KMS" in one sentenc? :-)
<xnox> Mirv, using `make -k` for tests is one thing to add, and make the good/bad arches do fail or e.g. || true -> such that we still run tests, but see how good/bad they are.
<xnox> Mirv, that's nice, but i don't have commit access there, now do i =) how do you want patches for that repo?
<xnox>  /o\
<tseliot> pitti: right :) that's part of a release that we don't have in the archive yet
<Mirv> xnox: anything is fine - git repo somewhere, LP bug with attachments, debdiff..
<xnox> Mirv, if you want to upload now, you should mark s390x as `bad' arch for the tests.
<xnox> but i will work to enable test suite for it, cause i don't want it to regress.
<Mirv> xnox: alright, let's re-enable it once the test suite passes
<alkisg> pitti: is there somewhere that I could see the systemd history in ubuntu, along with its debian/ folder? In http://bazaar.launchpad.net/~registry/systemd/master/files I don't see debian/ ...
<alkisg> (so that I could do some bisection...)
<pitti> alkisg: it's maintained here: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git
<alkisg> Thank you!
<pitti> alkisg: I keep the ubuntu delta in the ubuntu branch, but it just keeps getting rebased
<pitti> so not much to bisect there
<alkisg> OK, checking...
<xnox> pitti, can acpid please be waived through autopkgtest, or rather nvidia-graphics-drivers-340[-updates] to be marked as bad on armhf. I'm not quite sure why armhf tests are failing for nvidia-graphics-drivers.
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#acpid
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<cjwatson> pitti: well, it's not just temp failures, it's that the excuses output doesn't appear to accurately reflect the most recent runs
<cjwatson> pitti: and when I looked, the queues were empty
<cjwatson> pitti: still, I guess we'll see if they clear now
<LocutusOfBorg1> hi Unit193 the service file for vboxweb is in place
<LocutusOfBorg1> let me know if it works or not
<Laney> slangasek: Do you know who the right person to look at bug #1465386 might be?
<ubottu> bug 1465386 in upstart (Ubuntu) "Default values for WAIT_STATE are wrong in the upstart wait-for-state job" [Medium,Confirmed] https://launchpad.net/bugs/1465386
<Laney> xnox: bug #1472314 looks like it is waiting for you
<ubottu> bug 1472314 in cmake (Ubuntu) "Fix subsequent cmake runs when using multi-arch" [Medium,New] https://launchpad.net/bugs/1472314
<xnox> Laney, i disagree with is =) ./debian/rules clean must be run between built steps =)
<xnox> *it
<Laney> the comment #3 doesn't involve packaging
<Laney> but take it to the bug please :P
<xnox> Laney, =D
<xnox> Mirv, does Qt at all work on big-endian platforms? I sense there are legit test suite failures on big-endian.
<Laney> doko: can you comment on sruing bug #1501300 please?
<ubottu> bug 1501300 in llvm-toolchain-3.4 (Ubuntu) "Wily (15.10) this package got not compiled with __cxx11 support" [Medium,In progress] https://launchpad.net/bugs/1501300
<Laney> (in the bug)
<stevenm_> Hey, anyone here familiar with the ubiquity installer?  i'm looking at the bottom of the ubiquity/plugins/ubi-prepare.py file
<xnox> stevenm_, #ubuntu-installer is a better channel for things like that.
<doko> Laney, done
<stevenm_> ah ok thanks xnox
<Laney> doko: ty
<Mirv> xnox: not sure about working, but it builds and upstream accepts patches. upstream does not run any of their tests on big endian archs afaik (last time I checked their test configurations it was arm/x86 only)
<xnox> Mirv, e.g. they don't use "gcc atomics" and have per arch, atomics, there are no atomics committed for s390x, and then it fallback to bitshifts... little endian way...
<xnox> src/corelib/io/qloggingcategory.h
<Mirv> xnox: arm64 enablement was contributed to upstream from us if I remember correctly. feel free to submit commits https://codereview.qt-project.org/#/q/project:qt/qtbase,n,z and I can also add you to the Canonical CLA group in Qt upstream
<xnox> hm, well there is Q_BIG_ENDIAN defined with reverse shifts.... =/
<xnox> Mirv, hm... something is really odd.
<pitti> cjwatson: right, I did some admin and upgrades with clearing the queues in between; armhf is still sick, the others are catching up now
<seb128> doko, do you plan to submit your pep8 changes to Debian?
<seb128> doko, or do we need an Ubuntu delta know to fix build issues for things like https://launchpadlibrarian.net/222742791/buildlog_ubuntu-xenial-amd64.prospector_0.10.1%2Bgit20150706.a00e191-1_BUILDING.txt.gz ?
<seb128> e.g do we need to change things build-depending on pep8 to use python-pep8?
<xnox> Mirv, so, i'd like to upload qtbase with s390x set to bad architectures for now.
<xnox> Mirv, shall i upload it, or do you want to do that via debian/git/landing ?
<xnox> it's blocking a lot of s390x bootstrap, and i think the problems are real, and i'd need more time fixing them, but i'm not yet sure of the priority on those.
<xnox> e.g. it's not critical for the next milestone as far as i can see.
<Mirv> xnox: I've it in my next upload, so no need to upload. I just wish the migration of Qt 5.5 to release pocket could happen before triggering another 1000 of tests with a new upload.
<Mirv> xnox: it'd sound like pitti has unblocked something in the queue so maybe there's hope for the migration later today. meanwhile, I have my part of the next qtbase upload seemingly done so I will pre-build a version of that in a landing PPA to copy over once the migration has happened.
<xnox> Mirv, it will not, because of lack of s390x build, and lack of poppler.
<xnox> but let me double check that.
<xnox> or maybe it will.
<pitti> Mirv, xnox: I'm done with infra rescuing, and armhf are back; I'm looking at excuses.html now to see what's stuck
<Mirv> xnox: well qtbase surely never built on s390x so it couldn't be blocking
<xnox> if we ignore outstanding tests to do.
<xnox> Mirv, ok, and does it ignore failures on s390x for now?
<Mirv> xnox: the new upload yes, I've only opted-in amd64 armhf i386 for the test runs. if you have some more additions than what you had in ubuntu2 upload (there was -k added at the end of xvfb line at least), I can add those
<Mirv> xnox: what I'm going to upload is there in the git
<xnox> Mirv, true. and looking at qtbase.git tree it looks good.
<xnox> in terms of s390x build should pass, once you copy it over into the archive proper.
<xnox> if you could do that, it would be wonderful.
<Mirv> that's what I believe too
<xnox> Mirv, i'd be happy with git uploaded soon.
<xnox> i will work on these things more, later.
<Mirv> xnox: I will do that but as said I'd like to see the migration happen first, since a new qtbase would trigger lots of autopkgtests again which are already struggling. but I'd say tomorrow morning (16h) I'd do it if the migration has finally happened
<xnox> why ubuntu-minimal is not installable does worry me more on s390x at the moment.
<cjwatson> procps
<cjwatson> if that ever migrates then I believe it'd fix it
<xnox> cool.
<cjwatson> currently blocked on systemd/{armhf,i386}, openafs/armhf, and sysdig/armhf autopkgtest regressions, and clamav/armhf autopkgtest in progress
<xnox> cjwatson, and how did you work that out, so quickly =)
<cjwatson> sounded like pitti was looking into that kind of thing
<cjwatson> xnox: I looked into something else the other day with chdist and ended up there
<cjwatson> xnox: don't actually know it's the only blocker for ubuntu-minimal, but it's certainly a significant one
<xnox> ok.
 * xnox ponders if pitti is in ~ubuntu-release or not.
<pitti> formally I am, for pushing hints
<xnox> Laney, looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#procps could systemd tests be ignored, or e.g. procps hinted to ignore autopkgtests?
<xnox> ah cool.
<pitti> xnox: I'll hint it
<xnox> pitti, i'm looking into procps and ncurses. and whether ncurses will be needed too, to get procps migratable.
<cjwatson> xnox: it clearly is, excuses says so
<pitti> xnox: already is
<pitti> as I said, I'm currently walking over excuses.html and see what's stuck, updating some hints
<pitti> like pyx
<pitti> and the two sytemd failures were due to infra bugs, not procps etc.
<pitti> while the queues catch up we can speed up the landing of those
<xnox> right. thanks, ok.
<pitti> (yay for having multiple staggered infra disasters :( )
<Laney> thanks
 * Laney eats own arm
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Mirv> pitti: did you figure out why the kwin being hinted is not showing?
<Mirv> hmm now it seems autopkgtests are failing because apt would get uninstalled o_O
<pitti> Mirv: not yet, but as I wrote above, I'm currently doing -proposed cleanup, getting there
<Mirv> pitti: ok
<gQuigs> hi there, do I need to do anything else for the SRU of https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1505328 ?
<ubottu> Launchpad bug 1505328 in cups (Ubuntu Trusty) "Cups SSL is vulernable to POODLE" [High,Triaged]
<gQuigs> is "get a sponsor" and Â subscribeÂ ubuntu-sponsors the same thing?  (https://wiki.ubuntu.com/StableReleaseUpdates#Procedure)
<seb128> Laney, cyphermox, hey, any idea why network-manager-gnome is missing for xenial desktop isos? it's a recommends from n-m so it should be either, I though that maybe it was uninstallable for some reason but I don't see why it would (and can't get an error by pbuilder testing)
<cyphermox> looking
<gQuigs> seb128: well, the versions seem off to me -gnome is on 1.0.6 and nm is on 1.0.4
<seb128> gQuigs, why would that be an issue?
<cyphermox> gQuigs: that shouldn't matter
<cyphermox> well, as long as it remains installable anyway
<cyphermox> seb128: was the package missing altogether or just no indicator in the panel?
<seb128> gQuigs, 15.10 has 1.0.4 and 0.9.10
<seb128> cyphermox, it's not on http://cdimage.ubuntu.com/daily-live/current/xenial-desktop-amd64.manifest
<cyphermox> wow
<seb128> right
<cyphermox> ah, perhaps it's indeed from the merge
<cyphermox> https://launchpadlibrarian.net/228999342/buildlog_ubuntu_xenial_amd64_ubuntu_BUILDING.txt.gz
<cyphermox> ^ mentions it just once as a Recommends, but never after tht
<cyphermox> *that
<gQuigs> hmm.. I thought they were the same source package.. oops
<seb128> gQuigs, oh, about your "find a sponsors", subscribing the team is a good way to do that yes
<seb128> though for a security fix you might want the ubuntu-security-sponsors
<gQuigs> seb128: yea, I'm guessing that's why it seems in limbo, security team said they want it to go throught the normal SRU process
<seb128> oh ok, then ubuntu-sponsors is right
<mdeslaur> gQuigs: sorry, I'll look at your cups bug today
<mdeslaur> gQuigs: you erased the previous debdiff, so now I have to review it all over again :P
<gQuigs> mdeslaur: oh, you can also do normal SRUs? :)
<mdeslaur> gQuigs: I can ack it and upload it, then the SRU team will handle it
<gQuigs> 'doh, the name of the old one kept confusing, it was final patch or something.. bad choice on my part
<gQuigs> thanks both
<seb128> cyphermox, was reported as bug #1522955 for reference
<ubottu> bug 1522955 in network-manager (Ubuntu) "nm-applet not installed with xenial daily iso" [High,New] https://launchpad.net/bugs/1522955
<cyphermox> seb128: ok
<seb128> cyphermox, I'm a bit puzzled at why, I tried to install ubuntu-desktop and the other plugins in a pbuilder and no error
<cyphermox> yep
<seb128> cyphermox, k, found the issue
<cyphermox> ah?
<seb128> cyphermox, that change got dropped in the n-m-applet merge
<seb128>  network-manager-applet (0.9.8.8-0ubuntu9) vivid; urgency=medium
<seb128>  
<seb128>    * Switch gnome-icon-theme to adwaita-icon-theme, which is its
<seb128> or g-i-t is in universe
<seb128> so it makes n-m-gnome uninstallable
<cyphermox> oh, of course
<cyphermox> *sigh*
<cyphermox> you or I fix?
<seb128> as you want
<seb128> is there a vcs for it?
<cyphermox> yeah
<seb128> if so you probably have that set up so please do
<seb128> thanks :-)
<cyphermox> ok ;)
<cyphermox> lp:~network-manager/network-manager-applet/ubuntu
<seb128> yeah, I'm basically being lazy :p
<seb128> but I can do it if you prefer
<cyphermox> no I'm on it :)
<seb128> cool, thanks
<cyphermox> just sharing the vcs for posterity.
<seb128> :-)
<Laney> seb128: good find
<seb128> Laney, thanks!
<xnox> mvo, what is this _apt user business?
<xnox> i've seen this failing, and like sbuild and/or apt complaints about it.
<mvo> xnox: in a meeting right now so a bit short: its the drop privs user that we use when downloading debs
<xnox> mvo, cool, ok. who should create it? cause e.g. sbuild autopkgtest is failing at the moment because of this.
<mvo> xnox: hm, I thought we fixed that in the latest apt build
<mvo> xnox: its created via postinst
<Laney> Is it failing on stderr output?
<seb128> yes
<seb128> mvo, there is a warning written and the autopkgtest considers that as wrong and nack it
<xnox> mvo, well, and old apt is used to start the chroot, then a newer apt is upgraded to, which is too late by that time.
<xnox> pitti, could you mark sbuild as a bad test for now, or like allow apt to go through please?
<xnox> mvo, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/sbuild/20151207_114240@/log.gz
<pitti> xnox: done
<xnox> pitti, thank you.
<Laney> What if you make the test depend on apt 1.1?
<Laney> ...or skip it...
<xnox> and then once apt migrates, the next time it should work fine.
<xnox> Laney, well, i'm not sure, so sbuild first downloads source, then upgrades things. maybe if the test does $ apt-get source procenv; sbuild procenv*.dsc it would work better.
<xnox> Laney, instead of what i gather from logs it's doing $ sbuild procenv_version
<xnox> meh, once in a life time "bootstrap" bug.
<pitti> I don't think it's transient
<xnox> and the test log still says that all is good, and packages have built.
<pitti> sbuild usually copies the host's passwd into the chroot
<pitti> and apt loudly complains if it doesn't find that _apt sys user (which isn't static)
<pitti> so this conceptually collides
<xnox> pitti, iff the chroot is created with apt 1.1.3 there should be a warning, i would have through.....
<xnox> ... hm =/
<pitti> xnox: ah, that way around; yes
<pitti> apw: I filed bug 1523586 with the kernel panic now
<ubottu> bug 1523586 in linux (Ubuntu) "[PPA] 4.4 regression: kernel panic on reboot" [Undecided,New] https://launchpad.net/bugs/1523586
<apw> oh nice thanks
<apw> pitti, and shove at rtg as that is actually his very latest shiney whihc is imploding
<apw> and shoved (past tense)
<xnox> hallyn, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1523593
<ubottu> Launchpad bug 1523593 in qemu (Ubuntu) "enable pie for s390x" [Undecided,Confirmed]
<dholbach> slangasek, do you know what the problem might be with https://bugs.launchpad.net/ubuntu/+source/skype/+bug/1523060?
<ubottu> Launchpad bug 1523060 in skype (Ubuntu) "skype is not installable on trusty" [Undecided,New]
<hallyn> xnox: yeah i saw the build failiure, it's on my list, thx
<hallyn> ooh a patch, thanks :)
<xnox> hallyn, that one makes it built =) i'm not yet able to run that, but at least it will compile for now.
<hallyn> xnox: will push that ina few mins (after bfast0
<xnox> hallyn, cool thanks. upload to ubuntu would be appreciated too.
<xnox> pitti, there is a bogus hint from riddell, that overrides your hint in britney.
<xnox> from http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2015-12-07/16:35:26.log
<xnox> W: [Mon Dec  7 16:35:52 2015] - Overriding force-badtest[kwin] = ('4:5.4.3-0ubuntu2', 'pitti', 'None') with ('4:5.4.3-0ubuntu3', 'pitti', 'None')
<xnox> W: [Mon Dec  7 16:35:52 2015] - Overriding force-badtest[kwin] = ('4:5.4.3-0ubuntu3', 'pitti', 'None') with ('4:5.4.2-0ubuntu1', 'jriddell', 'None')
<xnox> could you drop jriddell's hint, and just keep latest hint of yours?
<pitti> ooh
<pitti> well, not bogus, just old :)
 * xnox ponders if comments like that qualify me for ~ubuntu-release team ;-)
<xnox> pitti, on this 7th day of christmas it's now bogus =)))) i'm not agist ;-)
<pitti> xnox: hinted harder
<pitti> xnox: thanks for spotting!
<brendand> is this 404 anything to worry about? ports.ubuntu.com/ubuntu-ports/dists/xenial-security/restricted/binary-armhf/Packages
 * xnox sings we can go hard, or we can go home
<cjwatson> xnox: errr very much not the 7th day of Christmas.  try that in 24 days :)
<xnox> cjwatson, #fail
<xnox> brendand, no, that's normal. there are compressed files only. and it's empty anyway, as nothing is published there yet.
 * xnox ponders if it's 7th advent, already?! i had tree up since november, so i don't care much. And had turkey dinner yesterday.
<cjwatson> xnox: (well, or 12-ish days later in the eastern churches ...)
<cjwatson> xnox: ninth day of Advent today
<cjwatson> we did our tree yesterday.  and chanukah candles, so if any neighbours were paying attention I bet they were confused.
<xnox> >_< =)
<xnox> cjwatson, keep them guessing =)
<xnox> Mirv, kwin hint will be fixed, in the next britney run
<xnox> cjwatson, i tend to keep tree until the 13th of January and celebrate Soviet Old New Year - that confuses people, cause generally there isn't chritstmas tree collection service from council by that time (if we have real tree that year)
<cjwatson> pitti: cinnamon-control-center looks like another testbed failure
<cjwatson> pitti: (armhf)
<pitti> cjwatson: right, thanks, retrying again
<pitti> and apparently there's a bug with sometimes not seeing new test results in swift
<doko> hmm, binutils-static wants to demote?  does this mean we won't need it anymore?
<doko> cjwatson, and binutils-udeb?
<cjwatson> doko: binutils-static-udeb (assuming that's what you mean) has been explicitly seeded in the installed seed since breezy; I think it's been obsolete for quite a while but am not certain
<cjwatson> xnox: looks like https://launchpad.net/ubuntu/+source/libindicator/12.10.2+14.10.20140922-0ubuntu1/+build/8377385 is the current blocker for ubuntu-desktop/s390x
<xnox> cjwatson, ack, thanks. will look into it.
<cjwatson> definitely gradually improving though ...
<cyphermox> bdmurray: will you be around for the DMB meeting shortly?
<bdmurray> cyphermox: yep
<mdeslaur> slangasek: no new edk2 yet?
<slangasek> mdeslaur: hmm, new relative to what?  the one that had been in the Debian new queue is in xenial today
<slangasek> Laney: bug #1465386> I would not consider this a priority to fix in SRU and it's of course not something we would prioritize for xenial because we don't support upstart as system init in xenial
<ubottu> bug 1465386 in upstart (Ubuntu) "Default values for WAIT_STATE are wrong in the upstart wait-for-state job" [Medium,Confirmed] https://launchpad.net/bugs/1465386
<mdeslaur> slangasek: ah crud, sorry about that, I was expecting a newer date in the version number for some reason
<mdeslaur> slangasek: thanks
<pitti> Mirv: can you have a quick look at http://autopkgtest.ubuntu.com/packages/o/okteta/xenial/amd64/ ?
<pitti> Mirv: error: âQIODeviceâ has not been declared
<pitti> Mirv: is that an API change which okteta needs to get adjusted to?
<chiluk> hey pitti... you had mentioned that you might do a merge of findutils from debian-unstable for xenial for https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788
<ubottu> Launchpad bug 1347788 in findutils (Ubuntu Xenial) "find crashed when current working directory is not readable and -exec or -execdir used" [Low,Confirmed]
<chiluk> pitti: can I assign you the case?
#ubuntu-devel 2015-12-08
<newb123> I'm playing around with an experimental driver I wrote and at boot it keeps on dumping me into initramfs saying that /dev/disk/by-uuid/XXX.... does not exist. I've checked that the uuid is correct and blockdev --rereadpt /dev/vda displays the correct partitions. Any idea how I might go figuring out why /dev/disk/by-uuid doesn't exist
<Mirv> pitti: should not be, but looking
<Mirv> maybe some #include problem in the qca-qt5 that has not seen updates in ages
<Mirv> hmm, Debian does not have qca-qt5 and builds okteta without it
<Mirv> aha, nope, they have 'qca2' ie different source name but same binary names
<Mirv> and the newer version they have fix FTBFS with 5.5...
<Mirv> (and looks like ubuntu also has qca2, but Kubuntu people have split of the qt5 part to its own source instead of having everything come from single source)
<pitti> Good morning
<pitti> chiluk: it's not so much a merge (we have no modifications), but the newer version should rather be tested thoroughly
<chiluk> I completely agree.
<chiluk> that's why I'd rather see it go in xenail while in development than something else.
<chiluk> pitti ^^
<pitti> cjwatson: I found out last night why so many tests were stuck "in progress" -- it was those which included a package build that failed
<chiluk> sometimes I wish IRC would just add the highlights accordingly
<pitti> cjwatson: fixed, and I reran all the tests over night, it's okay now
<pitti> chiluk: right
<chiluk> pitti, I think the "user" understands the issue of this not being SRU-able.
<pitti> chiluk: heuristic content based notifications -- just wait until freenode connects to the big google brain
<chiluk> but I really think we need to bite the bullet and do it before xenial lands
<pitti> chiluk: the crash fix is for sure, but certainly only that backport, not the wholly new version
<dholbach> good morning
<pitti> chiluk: did you already give that version some testing, with some basic use cases? or need me to do that?
<seb128> hey dholbach ;-)
<chiluk> pitti I have not, and unfortunately I'm headed on another vacation here till monday.
 * dholbach hugs seb128
<chiluk> also I should probably be sleeping... infinity must be rubbing off on me.
 * seb128 hugs dholbach back
<chiluk> and i don't want infinity rubbing anything on me.
<pitti> chiluk: ok, seems to work reasonably well here and it has a good test suite too
<chiluk> yeah it does have a reasonably good test suite.
<chiluk> wow that would be super awesome pitti.
<pitti> (I synced it)
<pitti> Mirv: so five failures are overridden, what's left are okteta (see above), step (which looks unrelated, I'll hint it), and unity-scope-click (which looks flaky, I'll retry)
<pitti> step is debian bug 786351, so someone needs to merge it
<ubottu> Debian bug 786351 in step "Eigen2 support is deprecated in Eigen 3.2.x and will be removed in Eigen 3.3" [Wishlist,Fixed] http://bugs.debian.org/786351
<Mirv> pitti: can you retry okteta, I uploaded a new qca-qt5 and it was published in proposed 38 minutes ago?
<pitti> Mirv: oh cool, thanks! triggered
<Mirv> pitti: hmm not sure if the 2.1.1 is in archive indexes yet, I can't update my xenial(-proposed) lxc for some reason yet even though it was that many minutes ago
<Mirv> usually that amount of time is enough, but no, not seeing https://launchpad.net/ubuntu/+source/qca-qt5/2.1.1-0ubuntu1 contents in Packages.gz yet
<pitti> Mirv: maybe ftpmaster already has it; but anyway, if it still fails we retry later
<pitti> Mirv: I'm looking into the step merge btw; but I'll ignore qt's tests once step is the only remaining regression
<pitti> (I don't want to ignore it for other packages as they cause the step regression)
<Laney> slangasek: It has a patch to review and is in the sponsor queue, so I'm wondering who should review or otherwise deal with it
<ginggs> thanks seb128 for the rebuilds :)
<seb128> ginggs, yw, thanks for debdiffs and sorry for taking some extra days
<pitti> Mirv: uploaded step, that works on xenial release now
<cjwatson> pitti: aha, thanks!
<Mirv> pitti: got now updated libqca-qt5-2-dev proposed and compiled okteta successfully with that
<Mirv> looking good on the autopkgtest infra too, I guess they got it from ftpmaster
<Mirv> still running though
<pitti> Mirv: but it still fails on the infra
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/o/okteta/20151208_094327@/log.gz
<Mirv> pitti: hmm, amd64 is still running at http://autopkgtest.ubuntu.com/running.shtml#pkg-okteta and armhf + i386 + ppc64el show success at eg http://autopkgtest.ubuntu.com/packages/o/okteta/xenial/armhf/
<pitti> Mirv: ah ok, so that was just an auto-triggered previous run
<pitti> Mirv: right, in the above log it still was 2.1.0.3-0ubuntu4
<Mirv> so once amd64 finishes it should be all green
<pitti> http://autopkgtest.ubuntu.com/packages/o/okteta/
<pitti> indeed, nicely green on the others
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src hasn't caught up yet, but it should soon
<Mirv> xnox: did you get anywhere with the checkbox, or are you familiar with it so that you could get somewhere?
<Mirv> xnox: I can't even build it locally for some reason, complies about some patching of vendorized_packages_removal.patch .. but as I linked yesterday, it did start to compile in the PPA but failing later in udev related tests
<xnox> Mirv, not yet, i was at end of my day, and i simply added it to my todo list
<xnox> okteta still runing, ok.
<xnox> pitti, okteta ftbfs
<xnox> pitti, can we skip it? and get qtbase in. It is good enough.
<xnox> Mirv, ^
<xnox> also okteta propbably needs a merge with debian experimental
<pitti> xnox: sure we can skip it, but it'll keep breaking other stuff if the new qt makes it ftbfs
<pitti> but I thought the new qca-qt5 fixed that
<pitti> xnox: no, it's good, it passed
<pitti> xnox: results got published 10 s ago
<xnox> oh
<pitti> http://autopkgtest.ubuntu.com/packages/o/okteta/
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #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> pitti, it was gone from currently running, but it was not yet up on the package board.
<xnox> i guess there is a delay between the two
<xnox> ok awesome
<pitti> xnox: right, autopkgtest.u.c. pulls every 5 mins
<pitti> still waiting on http://autopkgtest.ubuntu.com/running.shtml#pkg-step
<pitti> that should build again now too
<xnox> pitti, and does kwayland regression on ppc64el affect migration?
<pitti> oh, step succeeded too
<pitti> so britney should stop complaining about qt the next run
<pitti> xnox: oh crap, yes; I'll hint over that
<xnox> pitti, and unity-scope-click?
 * xnox ponders why it failed
<pitti> I reran that one, looked flaky
<xnox> pitti, unity-scope-click clearly had a network problem.
<xnox> but can be peppered over, no?
<pitti> ah, so the rerun failed too
<pitti> xnox: ack, hinted, qt etc. will be a valid candidate on the next run
<pitti> Mirv: ^
<pitti> (could still be some ABI transitions etc. on update_output, of course)
<pitti> xnox: FYI, ubuntu-meta is stuck on ubuntu-desktop uninstallability on s390x; perhaps add some [!s390] there?
<pitti> there == to the seeds?
<xnox> i could do that, or i could get things building
<xnox> so i need qt5 on s390x next =)
<xnox> and to do that, we need current one migrated
<xnox> to upload next one ;-)
<Laney> wasn't that caught up with poppler?
<rbasak> I'm tempted to s/nagios-plugins/monitoring-plugins/ in the seeds since nagios-plugins-* are now transitional packages that will disappear after Xenial, and if I forget to change the seeds next cycle they will fall into universe.
<rbasak> OTOH that will put nagios-plugins-basic/-standard transitonal packages into universe in Xenial.
<rbasak> Which may not be good I suppose if someone upgrading has main disabled maybe?
<rbasak> I just answered my own question perhaps then - don't do until next cycle?
<cjwatson> We normally seed transitionals with a comment saying to drop them after the next LTS
<cjwatson> important ones anyway
<cjwatson> But changing to monitoring-plugins makes sense
<xnox> =) Should wait for tests relating to qtbase-opensource-src 5.5.1+dfsg-6ubuntu2, but forced by pitti
<rbasak> I meant if someone upgrading has universe disabled, sorry
<rbasak> cjwatson: so should I change now and ignore the transitionals, or add the new ones and keep the transitionals for the transition in main with a comment to remove next cycle, or do nothing until next cycle?
<xnox> Laney, pitti, Mirv looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt i say it's foobar to transition =)
<cjwatson> rbasak: I would s/nagios-plugins/monitoring-plugins/ and add the transitionals with a comment
<rbasak> cjwatson: OK, I'll do that. Thanks!
<Laney> xnox: A lot of those are because the other qt* aren't candidates yet
<Laney> (I think)
<xnox> Mirv, can you throw next qtbase in, which will build on s390x, cause there are binaries that are built with old poppler and they do become uninstallable with new qtbase and thus hold things up.
<xnox> Mirv, and yes we do have qt 5.4 & old poppler based binaries in launchpad s390x xenial release pocket.
<xnox> and qtbase-opensource-src-gles  is still borked
<Laney> qtdeclarative, qtscript, maybe others
<xnox> and then it would still block on popler and blocked on s390x old popler, hence i do need another qtbase upload
<xnox> which we knew anyway, should have done it days ago.
<xnox> Mirv, are you gonna make the next qtbase upload please?
<Mirv> xnox: ok, sounds like there's still some things to fix or at least override, so I guess I can put your s390x enablement in
<xnox> Mirv, yeap.
<xnox> Mirv, and s390x are part of the blockers via poppler.
<Mirv> pitti: I think kwin+rocs would need hinting for the other Qt packages too
<seb128> doko, hey, did you see my question about pep8 yesterday?
<Mirv> Laney: pretty much all qtdeclr* qtscript etc are the same that are overridden for qtbase already (kwin, rocs) or already fixed but status not updated (marble, okteta)
<pitti> Mirv: didn't I already?
<pitti> Mirv: oh yes, it's currently landing
<Mirv> pitti: what's currently landing?
<pitti> Mirv: qtbase-opensource-src and friends
<Mirv> xnox: I think the checkbox with qt3d5-dev removed should be fixed because of the main <-> universe
<Mirv> pitti: I thought qtmir-gles failure prevented that, plus xnox just convinced me to copy over ubuntu3 of qtbase which I did since the migration was supposed to take ages still :)
<pitti> oh, or it's that -- https://launchpad.net/ubuntu/+source/qtbase-opensource-src/+publishinghistory
<pitti> it's a valid candidate, and https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-6ubuntu2 had no publication, which is usually teh case in between ubuntu2 and ubuntu3
<pitti> Mirv: uh, so that will trigger everything again
<xnox> pitti, valid candidate.... yet piles of unisntallable packages and thus will not migrate.
<xnox> pitti, autopkgtest is not the only thing blocking qtbase migration.
<pitti> ok, I didn't check that yet
<Mirv> pitti: yeah, xnox wants the s390x to proceed and apparently update_output has more work to be done
<xnox> pitti, 5th ctrl-f hit of 'qtbase' on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<xnox> in there there are a bunch of todos
<xnox> including s390x packages
<xnox> * s390x: 4ti2, aweather, foxtrotgps, ....... and so on
<pitti> ok; hopefully this round of tests will be much quicker, with the infrastructure currently working and the eternal "test in progress" bug fixed
<xnox> Mirv, awww, sybmols. do you want a patch for that?
<Mirv> xnox: foxtrotgps is gtk, I wonder if there's an easy root problem
<Mirv> xnox: yes please
<Mirv> to the installability things
<xnox> it builds real quick without the tests =)
<Mirv> anyway, I welcome any help on the migration at this point where things already start to be quite complex
<Mirv> plus the dragging of the migration making train a bit more cumbersome
<Laney> pitti: might want to skiptest if all that's changed is s390x conditionals
 * Laney goes to lunch
<pitti> it's quite a bit more
<xnox> Mirv, http://paste.ubuntu.com/13823021/ test building on s390x at the moment at https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8410204
<pitti> we don't need to wait for everything again though, let's just run a few to check that not everything is totally broken
<pitti> Laney: but doesn't help if the necessary rdepends rebuilds haven't been done yet
<xnox> pitti, we shall have ubuntu4 in a second =)
<xnox> pmcgowan, rocking ipv6 =)
 * xnox likes ipv6
<doko> seb128, do you remember packages other than prospector?
<seb128> doko, I don't remember them but I fixed a few
<seb128> it just seems suboptimal to carry ubuntu delta there
<seb128> is there any reason the change doesn't make sense for Debian?
<seb128> doko, http://launchpadlibrarian.net/222749166/shortuuid_0.4.2-4_0.4.2-4ubuntu1.diff.gz is another one you did
<seb128> doko, http://launchpadlibrarian.net/222797987/actdiag_0.5.3-5_0.5.3-5ubuntu1.diff.gz as well
<doko> ta
<doko> seb128, I'm currently compiling the list of affected packages
<Mirv> xnox: I'm also prebuilding in a landing PPA
<seb128> doko, k, thanks
<doko> cjwatson, https://bugs.debian.org/807366 this requires gcc-5-5.3, or else the options will be unknown
<ubottu> Debian bug 807366 in ghc "ghc: disable PIE on Ubuntu/s390x" [Normal,Open]
<cjwatson> doko: ok, not sure that's a problem for ghc though?
<doko> cjwatson, don't know, just in case it wants to pass this to the compiler
<cjwatson> doko: it will do, but backporting ghc is somebody else's problem :-)
<doko> =)
<doko> seb128, http://bugs.debian.org/807409  feel free to comment on the issue when you find more. prospector now fixed too
<ubottu> Debian bug 807409 in src:pep8 "using python3 to run the pep8 binary" [Wishlist,Open]
<seb128> doko, thanks
<xnox> Mirv, succeeds on s390x.
<xnox> Mirv, so once it's ready copy it over please.
<Saviq> tvoss, hey, u8 is crashing on me on exit http://pastebin.ubuntu.com/13824663/
<Laney> xnox: It helps it get to the next stage, which lets you see what needs updating still
<Saviq> looks like a dbus-cpp issue, or a media-hub one, wdyt?
<pete-woods> pitti: hey! I still have this PR for python-dbusmock if you have some time (https://github.com/martinpitt/python-dbusmock/pull/17)
<pete-woods> I've tried to do all the NEWS / commit messages correctly
<pete-woods> and add tests, etc
<pete-woods> dammit, pep8 fail, fixing now
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/ark/20151208_141408@/log.gz
<Laney> looks like that pkg-kde-tools upload was bad
<pitti> pete-woods: right, sorry, last days were a bit crazy with infra firefighting
<pete-woods> pitti: no worries. figured you were just on holiday or something
<pitti> pete-woods: no, pretty much the opposite :)
<pete-woods> I've had floods / no power here for the last 4 days
<pitti> urgh
<pete-woods> so I've not done much either
<pete-woods> FYI, one of the changes is non-trivial (the one that makes it support having 'secrets' properly)
<pete-woods> it intentionally removes some properties from the settings interface that should never have been present
<pete-woods> (i.e. they don't exist on the real interface)
<pete-woods> I've tried to add a passable level of testing for it all
<xnox> Mirv, what other change you need to land in checkbox?
<xnox> i fixed it's build.
<xnox> barry, unittest is confused by a submodule named dbus, which import system dbus =(
<xnox> e.g. i have checkbox.dbus which does 'from dbus import SystemBus' and when running test it trips up on that.
<xnox> is there a way to instruct pytest to not "discover" that one?
<Mirv> xnox: will do before I go to sleep
<xnox> Mirv, well i need to upload my fix, i could upload it with whatever changes you had to land.
<xnox> otherwise i'll just upload a straight FTBFS fix.
<barry> xnox: python 2?
<xnox> barry, python3.5 special =)
<barry> xnox: hmm.  absolute imports are the default in 3.  can you pastebin the traceback?
<xnox> barry, http://paste.ubuntu.com/13825910/
<xnox> barry, so ./setup.py test fails, yet python3.5 -m unittest -v -> succeeds correctly. i blame setuptools-foobarage.
<infinity> apw: Hey, uhm.  There's no linux-meta for s390x.
<apw> infinity, oh oops, did we forget to add that?
<infinity> apw: Yep.
<apw> infinity, we just need a -generic for that i presume ... will get that sorted
<infinity> apw: And virtual.
<infinity> apw: Since you did the split.
<apw> now that feel familiar ... why
<tvoss> Saviq, looking
<xnox> infinity, apw - did you do the split?
<xnox> so far everything expects generic.....
<xnox> as i thought we don't have a virtual flavour yet.
<apw> xnox, it is -generic, -generic gets split
<infinity> xnox: Everything should be generic, except the MP I just rejected. :)
<barry> xnox: yeah, it's suspicious, but i'm already suspicious of other setuptools foobarisms: LP: #1523806
<ubottu> Launchpad bug 1523806 in system-image (Ubuntu) "/usr/sbin/system-image-dbus:UnicodeDecodeError:/usr/sbin/system-image-dbus@5:/usr/lib/python3/dist-packages/pkg_resources/__init__.py@3143:_call_aside:_initialize_master_working_set:_build_master:__init__:add_entry:find_on_path:from_location:_version_from_metadata:_version_from_file:decode" [Undecided,New] https://launchpad.net/bugs/1523806
<xnox> infinity, ack.
<Mirv> xnox: what your fix, did you have something more than the symbols? the idea is that the armhf build is pre-done so it doesn't take time in the archives.
<barry> xnox: is there a branch i can play with?
<xnox> Mirv, checkbox, i fixed checkbox to not be crazy.
<Mirv> xnox: the reason I'm doing the landing is your fix, I don't have anything else
<Mirv> xnox: ah, sorry! I mixed to qtbase
<xnox> Mirv, i thought you had something to be changed for checkbox - dependencies?
<Mirv> xnox: excellent! so, remove the qt53d-dev from build-deps
<xnox> barry, sbuild -A -d xenial checkbox_0.18-0ubuntu4 -> fails at the moment.
<Mirv> xnox: so that qt3d-opensource-src can be demoted to universe... otherwise qt3d can't build (or couldn't in archives, but yes when binary-copied from landingn PPA) and I assume it'd block migration too
<xnox> barry, it does crazy things, but in essence -> $ cd checkbox-old, in that package is borked. (./setup.py test does not work)
<xnox> barry, or well pull-lp-source checkbox 0.18-0ubuntu4
<tvoss> Saviq, that's rc-proposed?
<xnox> Mirv, right, and checkbox doesn't need it? why it depends on it. Ok will drop
<Mirv> xnox: well it didn't seem to require it (and it shouldn't, qt3d wasn't usable really before Qt 5.5), the debian/control looked like copy-paste from somewhere else
 * Mirv needs to go now, back to copy the qtbase from landing PPA in a 2-3h
<xnox> barry, is that enough for you to play with checkbox? =))))
<xnox> Mirv, checkbox fix is python brain-damage and 3 one-liners ;-)
<infinity> Odd_Bloke: Looking at the [ "$PROJECT" = "ubuntu-cpc" ] in live-build, why do three arches 'add_task install server', and the rest don't?
<infinity> Odd_Bloke: That feels rather broken in one direction or the other.
<xnox> infinity, i guess on amd64 -virtual flavour is used which is the default.
<infinity> xnox: Yes.
<xnox> oh, you are asking about server bits
<xnox> it is weird
<infinity> xnox: Yes. :P
<xnox> yes Odd_Bloke what's up with that =)
<Odd_Bloke> That's what we were already doing, so I was aiming to retain parity between what we produced before and what we produced in the buildds.
<infinity> Feels like only armhf and arm64 need special-casing there for kernel flavour and flash-kernel, and then the server task should move down to all arches.
<infinity> Odd_Bloke: As in, the arches were always mismatched?
<tvoss> Saviq, let me see if I can come up with a distilled test case
<infinity> Odd_Bloke: Can we aim for that to not be true, since we're doing an LTS? :P
<Odd_Bloke> infinity: Oh, you.
<Odd_Bloke> :p
<infinity> Odd_Bloke: Either the server task should be on all or none, up to you guys which is correct, but the mismatch clearly isn't.
<tvoss> Saviq, do you see the crash on regular shutdowns?
<Odd_Bloke> infinity: Yeah, I'll bring it up with the others.
<infinity> xnox: So, in your MP, I'd drop the s390x stanza from that chunk entirely, since whatever Odd_Bloke decides, it'll wipe out ppc64el and s390x because they'll be the same as the default.
<barry> xnox: i see 0.18-0ubuntu4 is building in -proposed.  i can pull down that srcpkg and build locally
<xnox> barry, yeah, that one is "fixed" the packaging calls python3 -m unittest, instead of python3 setup.py test.
<xnox> barry, but yeah, it should still fail if you do: cd checkbox-old; ./setup.py test
<barry> xnox: ack
<infinity> Odd_Bloke: Also, did you ever figure out why your powerpc images weren't bootable?  Cause the lack of a powerpc case in that switch could explain it. :P
<xnox> plars, i'm not sure where checkbox upstream is for "packaging" of "checkbox-old" but i have made changes to it - https://bugs.launchpad.net/checkbox/+bug/1523969
<ubottu> Launchpad bug 1523969 in Checkbox "FTBFS on python3.5 in xenial" [Undecided,New]
<infinity> Odd_Bloke: (needs KERNEL_FLAVOURS=powerpc64-smp and probably a manual install of whichever bootloader you're using, yaboot or grub2)
<Odd_Bloke> infinity: There is a stanza in my PPA version which I'm using. :)
<infinity> Odd_Bloke: Ahh.
<infinity> Odd_Bloke: So, first half of the question then, did you ever figure it out?
<plars> xnox: I'm probably not a good person to ask about that - talk to spineau probably
<infinity> Odd_Bloke: Cause I might be able to find an hour or two to look at it.  We're getting to the point where we really want to move PPC into scalingstack.
<xnox> infinity, so whilst that case shouldn't be there, it is correct, no?! =)
<xnox> i.e. does no harm ;-) until Odd_Bloke fixes the world to be a beautiful place to be in ;-)
<infinity> xnox: Minus the KERNEL_FLAVOURS, it's "correct", but just adds noise, since he'll delete it shortly. :P
<infinity> (And I suspect it's not correct, I tihnk cloud images aren't meant to have the server task)
<xnox> infinity, as far as i can see we don't have virtual flavour yet, and default is virtual.
<infinity> Given that 99% of our cloud image users are x86, I'd expect that to be the template.
<infinity> xnox: We don't have a virtual or generic yet.
<infinity> xnox: That operates on metapackages.
<infinity> xnox: We have no linux-meta.
 * xnox facepalms
<infinity> xnox: One we have meta, we'll have both.
<xnox> infinity, anyway, i'm not even building ubuntu-cpc, i only care about server at this point =)
 * infinity nods.
<xnox> i should stop touching nasty things
<infinity> So just drop that stanza and merge away, IMO.
<Odd_Bloke> xnox: I thought you cared. ;.;
<xnox> Odd_Bloke, that was 4 years ago and cross the road to say hello from the other side =)
 * xnox chuckles at his Adele reference
<xnox> *I crossed
<xnox> i bet ogra_ is confused.com =)
<Odd_Bloke> xnox: Is it me you're looking for?
<xnox> >_<
<Odd_Bloke> ^_^
<ogra_> xnox, ??
<xnox> ogra_, check irclogs.ubuntu.com in an hour ;-)
<mterry> pitti, how do I retest a package's autopkgtests?  (without uploading a rebuild, if possible)  cpl-plugin-fors (and similar) got in a weird state when testing against latest gsl upload (ppc64el built against proposed, tested against release)
<ogra_> :P
<spineau> xnox: Thanks for you fix. We'll remove the checkbox-old very soon from xenial (replaced with the QML checkbox-converged). I'm just waiting on a few RFS to be processed for packages we're maintaining in debian. After a sync with ubuntu we'll update the xenial branch and those FTBFS will be auto solved.
<pitti> mterry: for now, ask me, Laney, slangasek, or infinity
<xnox> spineau, cool. well we need that bit now, to unblock 5.5 hence i uploaded minimal fix. i hope that's ok with you.
<pitti> mterry: does this look reasonable? http://paste.ubuntu.com/13826667/
<pitti> mterry: (from "retry-autopkgtest-regressions |grep cpl-plug")
<spineau> xnox: it's ok, many thanks for your fix
<mterry> pitti, and add astrometry.net
<mterry> pitti, thanks!
<xnox> spineau, then just close the bug or whatever. no problem.
<pitti> mterry: kicked
<pitti> mterry: FTR, I'm off for 2 or 3 hours, checking IRC tonight again
<spineau> xnox: ok
<mterry> pitti, ack thanks
<barry> xnox: it's a bug in checkbox: LP: #1523979 has a patch
<ubottu> Launchpad bug 1523979 in Next Generation Checkbox (GUI) "checkbox calls unittest.discover with an incorrect start_dir" [Undecided,New] https://launchpad.net/bugs/1523979
<xnox> barry, yeah, i was expecting something like this. your digging and explanation make sense =)
<barry> xnox: cool.  can you take it from here?
<xnox> barry, yes, thank you.
<barry> xnox: thanks!
<xnox> barry, at least it's not setuptools which are broken.
<xnox> and that's good.
<barry> xnox: not in this case at least :)
<sil2100> pitti, Mirv: hey guys! Any luck on the qt5 migration issues?
<doko> barry, for the python 2.7 testsuite I disabled the test_cpickle test, and everything is fine. it's now run as part of the "failing" tests in autopkg test, and should succeed
<Odd_Bloke> infinity: I did work out the bootability issue; we weren't doing a grub-install.
<Odd_Bloke> infinity: Which is actually _quite_ important.
<Odd_Bloke> (This just in, etc.)
<Odd_Bloke> infinity: I've been sprinting two of the last three weeks, so I haven't actually looked at it since I fixed that; a quick check of whether or not that fixes powerpc booting as well as ppc64el booting would be good.
<Odd_Bloke> (I confirmed the latter, but don't know if the lack of the former was due to my not really knowing which qemu flags to use :p)
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<xnox> sil2100, it's in progress.
<xnox> sil2100, and there is a lot more to do.
<xnox> sil2100, there should be a new qtbase to copy into archive done in one of the landings that mirv is maintaining.
<xnox> sil2100, how can i find all landing ppas that have qtbase-opensource-src?
<sil2100> xnox: https://requests.ci-train.ubuntu.com/#/tickets?search=qtbase-opensource-src
<sil2100> xnox: look for those that are not Landed or Abandoned
<sil2100> xnox: thanks for the info!
<xnox> sil2100, i don't see it, there should be a ppa with ubuntu4 built i believe somewhere, which Mirv uploaded. if it is fully built, it will need a copy to the archive. let me find it via build records.
<xnox> sil2100, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032
<xnox> sil2100, qtbase-opensource-src	5.5.1+dfsg-6ubuntu4 is ready, can you copy that into xenial-proposed please?
<xnox> a better and fixed checkbox, is already in xenial-proposed.
<xnox> sil2100, ah, no, armhf is still building.
<xnox> sil2100, waiting on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032/+build/8410224 to finish.
<xnox> 1.5h to go.
<sil2100> xnox: ok, but once that's done, just the qtbase packages, right?
<slangasek> mdeslaur, kees, stgraber: so is today's TB meeting cancelled by popular acclaim?  Not sure if there's something we should do to take it off calendars (fridge?) in that case
<xnox> sil2100, no, loads more too. we will need to unwind the popler abi transition in -proposed too, and whitelist through a few autopkgtests. I don't think we'll get it done today. But e.g. I need it to migrate as soon as possible, so will be working on unwinding proposed to get it done tonight/tomorrow.
<xnox> but for now i'll be afk, until qtbase builds.
<sil2100> xnox: was asking since the silo had many packages in it, didn't know if I was supposed to copy all of them or just qtbase from there
<mdeslaur> slangasek: perhaps just update the wiki page stating that the meeting was cancelled?
<sil2100> Anyway, thanks and let's see in some hours
<mdeslaur> slangasek: and the mailing list
<xnox> sil2100, just qtbase, others have been copied before already as far as I understand things.
<stgraber> slangasek: I'm fine with skipping it. I'm around but there's little point with nothing on the agenda
<sil2100> xnox: ACK
<cjwatson> oh, bah, I clearly uploaded texlive-bin too early
<cjwatson> didn't notice poppler/s390x hadn't actually built
<Laney> yeah
<Laney> Could we remove the old poppler binaries from the bootstrap archive, maybe?
<xnox> Laney, queried, no.
<xnox> Laney, once we have qtbase in, i'll spend some time binNMU the lots until -proposed is happy.
<xnox> Laney, i'm afk until qtbase builds.
<Laney> xnox: If you did that you could start libreoffice building now
<Laney> but 'kay
<xnox> Laney, well Mirv insisted building in ppa, rather than -proposed. so we could have had s390x build in -proposed already.
<xnox> i could stage things in my non-virt ppa, meh. I'll go have dinner and sort things later.
<smoser> cjwatson, have you followed grub-emu + kexec at all ?
<smoser> https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-s390x-02-kexec-module-added-to-emu.patch?expand=1
<Mirv> xnox: the benefit is the armhf build time that was cut by doing it
<Mirv> still some 20 mins to go, then copy
<smoser> hm.. i see http://people.ubuntu.com/~alanbell/uds-r/uds-r-foundations-r-powerpc-bootloaders-latest.txt . and the limited context there is almost the same as i'm after.  kernel + initrd as a loader.
<Mirv> xnox: sil2100: I sometimes use the train in my own ways ;) since I'm not "publishing" it but copying, it's building in 032
<cjwatson> smoser: I had a very brief look over it and asked the suse folks if they were going to upstream it; they indicated probably not since it wasn't really a proper architecture port, just an initramfs hack
<Mirv> sil2100: so the autopkgtests were fixed but some new qtbase uploads to get s390x building (not available in landing PPA:s yet). a new look again tomorrow morning... (or during the night by US timezone people)
<smoser> cjwatson, so... the context is almost identical to what it was previously... except for s/ppc64el/s390/
<smoser> we need netboot like functionality on z series.
<Mirv> xnox: hehe @ the checkbox, I'd have had zero idea about that..
<cjwatson> smoser: yes, I'm aware of the context.  I'm not entirely opposed to integrating that, just haven't fully thought it through
<cjwatson> (I think there are several more patches as well)
<smoser> probably.
<cjwatson> yeah, five in all
<smoser> having "real grub" be the thing that parses a grub config file seems more desireable than having petitboot do it.
<cjwatson> certainly
<smoser> but only if you can reasonably call the thing "real grub"
<cjwatson> 02 is non-upstreamable in its current form of course
<cjwatson> (hardcodes systemctl, etc.)
<cjwatson> not that that's necessarily an impediment
<Mirv> xnox: ah now I finally understood that there's a poppler transition intertwined. thanks for the explanation.
<cjwatson> my main concern is having to rebase all this stuff in future :-/
<smoser> yeah.
 * Mirv sees lots of happening while visiting a christmas party.
<smoser> bummer to see that they just call kexec.
<sil2100> Mirv: ok, so leaving it in your hands then ;)
<Mirv> sil2100: yes, I'll handle it before going to sleep
<smoser> i'd hoped they'd written a kexec loader themselves. one without https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1297316
<ubottu> Launchpad bug 1297316 in kexec-tools (Ubuntu) "kexec doesn't load non-elf multiboot images" [Medium,Confirmed]
<cjwatson> anyway, by all means file a bug and we can tear our collective hair out about it.
<cjwatson> oh and also this patch set includes a zipl.conf parser ...
<cjwatson> and dracut hardcoding
<smoser> :)
<cjwatson> and some weird stuff to do with hotkeys that I don't currently understand
<smoser> well, i assume that there is some work in petitboot too. i can file a bug. I wasn't really at the point where i woudl favor grub.
<smoser> petitboot has desire in that i know it works, and we already basically have to support it (powerNV).
<cjwatson> having more consistency across Ubuntu architectures would be good too
<smoser> which is more consistency ?  we really can't get rid of ppc64+petitboot
<cjwatson> grub2 could at least in principle work on powerNV, no?
<cjwatson> even if it doesn't today
<smoser> in principal yes, but it'd be firmware change to remove petitboot
<cjwatson> sure
<cjwatson> I'm not pushing urgently for it, just that I'd rather pick something that can at least in principle do everything
<cjwatson> (ok, petitboot sort of could as well, but it would be fairly daft to inject that for x86)
<smoser> although if we wanted, we could kernel1+initrd1+petitboot (firmware) kexec -> kernel2+initrd2+grub-emu kexec -> real kernel+initrd
<smoser> :)
<Mirv> sil2100: xnox: ubuntu4 copied. also qt3d demoted and I did a qtmir-gles upload earlier based on the looks of what its autopkgtests complained (even though I couldn't reproduce any problem in just building it myself). finger crossed again, although I don't know about the poppler status etc and whatever else lurks in update-output.txt after these.
<smoser> cjwatson, filed bug 1524029
<ubottu> bug 1524029 in grub2 (Ubuntu) "support grub-emu and kexec" [Undecided,New] https://launchpad.net/bugs/1524029
<cjwatson> ta
<xnox> Mirv, thanks will be sorting things out shortly.
<barry> doko: ack.  if/when the upstream issue is resolved we can reenable it
<mterry> Laney, can you help me with getting some autopkgtests restested?  I would like the system to reconsider libpdl-stats-perl, pyxplot, theseus, and visp (to help gsl get through)
<teward> this may sound insane, but is it possible in a package build to extract the current 'tag' from `git tags` (since the source directory also has the .git from upstream) to define a variable for use during building/compiling of the package?  Trying to do it now but failing (only getting the build args and not what is wanted)
<zaytsev> laney: it took me awhile, but there we go: https://bugs.launchpad.net/ubuntu/+source/scons/+bug/1524058 <--- hopefully this time formatted according to the guidelines
<ubottu> Launchpad bug 1524058 in scons (Ubuntu) "Fix SConf.Streamer to work with non-unicode input on Python 2.x " [Undecided,New]
<cjwatson> teward: if it's in the source then you can do whatever you like as long as you declare the necessary build-deps
<BlackFate> Hello ppl, I try to bisect some kernel versions and one of the commits seems to fail during the build. What's the best approach at this point? Should I try and "git bisect skip" the problematic commit?
<teward> cjwatson: right, that's what's being done, but for some reason instead of extracting the tag data we want (the git command will only output the git tag we're on, not all of them), it's failing, and catching instead compiler args
<teward> cjwatson: and I have no idea how to fix that
<teward> cjwatson: or rather, it's being passed as part of compiler rules so... :/  (in the debian/rules)
<cjwatson> teward: Can you link to an example?
<teward> if i can find the 2FA key for my github, yes :P
<teward> (though i'll pull it out of the code and put it into a paste, because codebase is 'not public' yet)
<cjwatson> teward: I suspect something like dodgy escaping in some bit of make/shell/whatever.
<teward> cjwatson: i would to, 'cept it's a go application, and there's no makefile (it's compiled by overriding dh_autoinstall)
<teward> though it is a 'make' file (debian/rules), so maybe variable substitution is failing
<teward> that's... odd... paste.ubuntu.com == lagging
<teward> cjwatson: this is essentially what is being attempted... http://paste.ubuntu.com/13839102/
<teward> cjwatson: can't figure out why it's failing, though if it's 'make' and it doesn't process Bash-style variable substitution...
<teward> maybe that's why...
 * teward shrugs
<teward> cjwatson: i kind of inherited this thing, it's not my code :/
<teward> cjwatson: note that link is the 'slightly stripped' make rules, but it gives you the gist of what's being done in debian/rules at least :/
<sarnold> teward: make spawns a different shell for every line in a recipe. I think the export DAEMON_VERSION and umask lines are probably no-ops as a result
<teward> mmm
<teward> sarnold: well, there *is* something passed to the thing via the ldflags, it's setting the version string to '-extld=gcc' internally when it reaches these steps.
<teward> which makes me scratch my head
<teward> sarnold: so how would you suggest this be done, then, given that the version has to be 'dynamically updateable automatically via the git tags'
<sarnold> teward: I'd try 'go build -ldflags "-X main.Version $(git describe --tags)" -o ...'
<teward> sarnold: that's a headache given that the copy you see here is stripped - there's 16 individual `go build` lines :/
<teward> i'll test though
<sarnold> ahh
<teward> and if that works, you get the gold star medal
<cjwatson> teward: $$(...)
<cjwatson> teward: $(...) does not do what you think there
<teward> cjwatson: $$(...) will do what we need?  (at the 'export' line?)
<teward> or do we have to do that for all variable sub?
<cjwatson> teward: also, each line is run in a separate shell
<sarnold> teward: then perhaps this is the starting point http://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html#Variables-in-Recipes
<teward> cjwatson: which is what sarnold said.
<cjwatson> right, you have at least two bugs :)
<teward> aahhhhhhhh
<teward> okay...
<cjwatson> teward: you would probably be better off splitting the content of that out to a separate script
<sarnold> cjwatson: hehe, nice :)
<sarnold> mmm. nice thinking outside of boxes :)
<cjwatson> teward: it's certainly possible to fix this up in make - $$(...), and convert the whole thing to a single shell command with ; or && separators - but it probably won't feel very natural
<teward> mmm
<cjwatson> teward: also the mentions of debian/PACKAGE/ smell like a template gone wrong
<teward> cjwatson: as i said i didn't write it :/
<cjwatson> but I assume that's you obfuscating it
<teward> cjwatson: and yes
<teward> works like a charm except for the version string so bleh
<teward> i'll stab this a little more :)
<teward> thanks for the pointers, cjwatson and sarnold
<cjwatson> coo, ghc transition caused me to find a bug in LP's dep-wait handling
 * cjwatson declines to retry that one by hand
#ubuntu-devel 2015-12-09
<psusi> cjwatson, pitti, and anyone else interested:  I'm finally putting together my application to upgrade to full core-dev, if you could sponsor me, I would appreciate it: https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
<sarnold> psusi: no stackexchange / askubuntu mention?
<psusi> I guess I could add that now ;)
<psusi> don't think it was around back when I applied for contrib ;)
<sarnold> hehe I think I stumbled on one of your answers from 2011 or something the other day. at least that's my vague memory :)
<psusi> Scott James Remnant was one of my sponsors for contrib and he's been gone for how long now?  hehe...
<sarnold> iirc he left before I joined up, so > three years :)
 * psusi is *finally* getting around to converting update-grub to use dpkg-triggers so no more dozens of several minutes long update-grubs during a dist-upgrade...
<psusi> just had to get annoyed at it for the millionth time
<sarnold> psusi: oooh will that also fix the case when removing six kernels that the grub config is updated six times?
<psusi> sarnold, bingo
<sarnold> psusi: yay! :)
<psusi> which is *really* annoying for me because I have a dozen different logical volumes with different releases in them and probing them all takes *forever*
<psusi> I filed a bug asking for it to be done a few years back when triggers were added hoping someone else would have time to do it before I did... finally got fed up enough with the waiting to just do it
<TheMuso> psusi: All the best, but I'm sure you'll have no problem getting plus votes, given how long you've been involved.
<psusi> TheMuso, thanks... surprised it has taken me this long to get off my arse and apply ;)
<psusi> I guess I was complacent for a while there since pushing a bzr branch and requesting a merge worked fine... but UDD seems to be dieing
<psusi> now if only it were being replaced with a similar system built on git-dpm... cjwatson really had a stroke of genius on that one
<TheMuso> Back in the day, I enjoyed bzr... Now I find myself finding the experience unpleasant...
<psusi> I found bzr tolerable.  git is great... as long as you have a high pain tolerance.   GNU still uses CVS to manage their project web pages and I just can't force myself to use CVS ever again
<Unit193> barry: I suppose at this point no interest in fastimport? :P
<pitti> Good morning
<Mirv> pitti: it'd look like a faulty pkg-kde-tools exploded half of autopkgtests, but there'd seem to be a fixed version now in there
<pitti> Mirv: good morning
<pitti> Mirv: ah, I was about to ask, this looked horrible
<Mirv> thanks to yofel for the fix
<pitti> Mirv: still upgrading base images, will mass-retry after that
<Mirv> pitti: thank you (and good morning)
<ginggs> good morning - i'm looking at update excuses... what needs to happen for petsc? does it need to be decrufted?
<dholbach> good morning
 * pitti does a mass-retry of all failed autopkgtests, with the fixed pkg-kde-tools
<pitti> hey dholbach!
<dholbach> hey pitti
<seb128> hey there ;-)
<Saviq> tvoss, bug #1524130 just got filed, btw
<ubottu> bug 1524130 in unity8 (Ubuntu) "/usr/bin/unity8:11:__memcpy_neon:std::char_traits:std::basic_streambuf:std::basic_streambuf:std::__ostream_write" [Undecided,New] https://launchpad.net/bugs/1524130
<tvoss> Saviq, yeah, just saw that
<tvoss> Saviq, it's a race on shutdown, but only finding time today to look into it in more detail
<Saviq> tvoss, ack, nw
<pete-woods> pitti: hey again. any chance of a backport of that dbusmock revision into the stable overlay again? (we're still making dual landings for everything in the convergence world)
 * xnox is annoyed i got kicked out of my irc proxy
<Laney> hi xnox!
<Laney> looks like the woes are cleaning up a bit
<xnox> Laney, a bit, but there are a tonnes of autopkgtest regression on qtbase with really something weird and broken.
<Mirv> pitti: have you noticed these random systemd errors https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/q/qtmir/20151209_101924@/log.gz ?
<Laney> they got retried
<Laney> if you mean the kdebase thing
<Laney> erm pkg-kde-tools
<Mirv> xnox: a faulty pkg-kde-tools was uploaded which broke all kde tests
<Mirv> so some time wasted and now again back on track
<xnox> Mirv, cool.
<Saviq> tvoss, is platform-api dual-landable? I can see there's a different package in xenial and overlay, and there's a separate /15.04 series, I hope it's just that it was never dual-landed yet?
<tvoss> Saviq, it is dual-landable again
<tvoss> Saviq, I will close down the 15.04 branch soon'ish
<Saviq> tvoss, ack, tx
<xnox> Laney, libreoffice is still building...
<xnox> cjwatson, did i break the world - http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20151209.log ?
<xnox> IOError: [Errno 2] No such file or directory: '/srv/cdimage.ubuntu.com/ftp/dists/xenial/main/debian-installer/binary-s390x/Packages.gz'
<xnox> not sure who is responsible for these sort of things... Laney ^ ?
<Laney> xnox: yeah, I tried to give you a way to upload it earlier to get ahead on the armhf build
<Laney> xnox: it's true that this doesn't exist but also I don't know how that mirror gets there
<xnox> ok. horum ok. cjwatson infinity slangasek - could you please look at, maybe it makes some sense for you http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20151209.log
<xnox> Laney, i bet something somewhere, needs to be taught that s390x is a split arch on ports, or some such.
<Laney> The machine has a mirror which doesn't contain s390x
<xnox> Laney, are there any more "cdimagy" branches i can modify? i did ubuntu-cdimage, live-build, livefs-rootfs. Are there more?
<Laney> xnox: AFAICS this mirror is updated by anonftpsync in cdimage, but I don't see any arch-specific bits here
<xnox> Laney, i remember is did adjust things, to mirror things, for ppc64el when we brought that up. mkay.
<Laney> xnox: Looks like the mirror hasn't been updated since Nov 13
<Laney> But build.py is supposed to do that, so I wonder why that isn't happening
<xnox> Laney, unless the lock is held.
<Laney> Doesn't seem to be
<xnox> Laney, or e.g. mirnyy.ubuntu.com doesn't have s390x.
<xnox> no, that's just an example.
<xnox> Laney, is there a "production/anonftpsync" somewhere?
<Laney> yes, it points to ftpmaster.internal
<xnox> Laney, and that, clearly, does have s390x et.al.
<Laney> even the rsync.log file is from Nov 13
<Laney> I feel out of my depth :)
<xnox> Laney, i blame that Nov 13 was a Friday, hence the world broke =)
<cjwatson> xnox: I'll sort it out
<xnox> cjwatson, thanks.
<xnox> doko, i'm thinking to teach hardening-wrapper about -no-pie
<doko> xnox, hardening-wrapper should die
<xnox> $ reverse-depends -b src:hardening-wrapper --list | wc -l
<xnox> 119
<cjwatson> cleared the lock, trying again
<Laney> which lock was it?
<cjwatson> (Nov 13 is too long ago to realistically investigate why it was held)
<doko> xnox, see the rc issue in Debian. kees isn't replying :-/
<cjwatson> cdimage/etc/.sem-build-image-set
<Laney> ah
<cjwatson> but important to check that there are no builds running before nuking it
<Laney> I was looking for the anonftpsync one
<cjwatson> if cdimage thinks that another build is running, it won't sync the mirror
<cjwatson> note the "Parallel build" indicator in the log file
<cjwatson> but there is a lurking bug somewhere that doesn't always clear the lock when it should
<cjwatson> infinity: You were right all that time ago when you guessed that Python try/finally doesn't cope with the case where cdimage is killed with certain signals.  This should at long last fix our occasional woes: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1557
<cjwatson> xnox,Laney: ^-
<xnox> \o/
<Laney> nice, thanks
<cjwatson> Only taken me about seventeen failed attempts of staring at that before realising the obvious
<cjwatson> Was clinging onto beliefs about try/finally which weren't true
<cjwatson> (Obviously lots of other signals *could* happen, but those are the likely ones - aside from SIGINT, which already turns into KeyboardInterrupt)
<xnox> ... so images had old stuff on them since 13th of november? i guess the debs, not the livefs things, cause livefs are built in launchpad and were all up to date.
<cjwatson> I investigated what happened on 13 Nov - there were two ubuntu-core builds that were abruptly terminated before proceeding
<mdeslaur> cyphermox: are you looking at installer stuff? might want to look at bug 1523199
<ubottu> bug 1523199 in debian-installer (Ubuntu) "Wily installer uses wrong seed location for systemd-random-seed.service" [Undecided,New] https://launchpad.net/bugs/1523199
<cjwatson> My guess is that somebody either killed them from another terminal, or used Ctrl-\ (SIGQUIT)
<cjwatson> Because Ctrl-C wouldn't have caused this problem
<cjwatson> xnox: Only the pool, indeed
<cjwatson> Took cdimage an hour and a half to sync the archive after all that, but it's making progress now
<cjwatson> UnknownArchitecture: No live filesystem builder known for s390x
<cjwatson> Sigh, I wondered if that would happen
<xnox> cjwatson, i thought i fixed things like that before.
<cjwatson> No, this is weird legacy stuff
<xnox> e.g. live-build livefs does succeed in launchpad.
<cjwatson> I thought about it when reviewing your branch but decided it wouldn't happen :)
<cjwatson> Yeah, the problem is that it tries to look for an old-style builder anyway
 * xnox eye rolls -> i didn't do those buildd name tests
<cjwatson> Fixing
<Mirv> pitti: still some systemd timed out errors on some of the tests, will you rerun those?
<xnox> Mirv, pitti: can you give examples? i believe that in the maintainer scripts systemctl commands should use --root=/ that way most of the things happen without talking/connecting to systemd
<xnox> and instead done by the systemctl itself on the filesystem.
<xnox> is it still the policykit-1 or some such?
<xnox> (with --root=/ systemctl just fiddles with files in /run /etc, instead of trying to talk to systemd and ask that to do stuff)
<Laney> Mirv: I retried all the regressions for ease, let's see
<infinity> cjwatson: See, logically, I was fairly sure I was right (since it matched the symptoms), but proving it was harder, especially with my crap python skills. :P
<infinity> cjwatson: Thanks for the fix!
<Mirv> xnox: pitti: http://is.gd/nMqBSz + http://is.gd/6pXahh + http://is.gd/BOvAm8 - armhf only?
<Mirv> thanks Iain
<cjwatson> pitti: No script to make CDs bootable for s390x ...
<cjwatson> err
<cjwatson> pitti: sorry
<cjwatson> xnox: No script to make CDs bootable for s390x ...
<cjwatson> xnox: looks like we need some debian-cd backports; lp:~ubuntu-cdimage/debian-cd/ubuntu
<xnox> cjwatson, well zipl should be run on the image. i shall look into that.
<xnox> This branch is an import of the Bazaar branch at http://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu.
<xnox> interesting
<xnox> cjwatson, i'll look into that.
<cjwatson> xnox: it'll probably involve backporting from https://anonscm.debian.org/cgit/debian-cd/debian-cd.git, though the branches are very very very very very diverged
<cjwatson> xnox: I think still not a totally implausible backport though
<cjwatson> xnox: that doesn't run zipl (which might not be possible bearing in mind that nusakan is x86?), but does stuff by hand
<xnox> cjwatson, it could do nothing at all as well.
<xnox> as there generally is no way to "boot iso"
<xnox> let me finish poking qt* things
<xnox> and then i'll look into debian-cd.
<infinity> Yeah, what I was hearing was that the ISO is meant to just be mounted as an ftp/http mirror and you use the d-i build on the ISO to netboot.
<infinity> Would be nice if we could do better than that, but not sure if that's possible.
<cjwatson> that script has to do something, because it's what puts the installer bits onto the image
<mdeslaur> infinity: can you make me a member of the ubuntu installer team, please?
<cjwatson> and Debian seems to have bothered to make it at least semi-bootable in some way, I assume they wouldn't just have done that for fun
<xnox> mdeslaur, why? =)
<mdeslaur> infinity: oh wait, you're not an admin
<mdeslaur> xnox: can you? I have a fix to push
<infinity> mdeslaur: Though, "why" is still a valid question.
<xnox> mdeslaur, and the mandatory question - do you know how to filter tonnes of bug mail spam?
<xnox> mdeslaur, merge proposals are welcome ;-)
<mdeslaur> xnox: ah crud, good point
 * mdeslaur doesn't want more email
<xnox> mdeslaur, it's a LOT of email
<infinity> mdeslaur: Just give us an MP, or point at a debdiff and I'll commit for you?>
<mdeslaur> yeah, I guess :)
<xnox> mdeslaur, make a merge proposal and like ping cyphermox about it.
<mdeslaur> infinity: sure, one ec
<xnox> mdeslaur, bzr diff | pastebin works too ;-)
<cjwatson> jamespage: just noticed that https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/xz-indexes/+merge/277880 failed again but I didn't notice in time for the build artifacts to still exist
<cjwatson> jamespage: is this automated testing really going to be useful for this particular MP?
<pitti> Mirv: yes, I saw; Laney, can you please mass-retry the armhf tests?
<pitti> Laney: oh, you already did, thanks
<pitti> Laney: seems we currently have a mass-killing from both plymouth and the new lxd..
<pitti> Laney: I'll see to turning those into normal failures, but not here
<mdeslaur> infinity: https://code.launchpad.net/~mdeslaur/ubiquity/fix-random-seed/+merge/280018
<cyphermox> morning
<infinity> cyphermox: ^
<mdeslaur> hi cyphermox
<infinity> (Timing!)
<cyphermox> yeah, I'm looking
<infinity> mdeslaur: Oh, curious.  I have both paths on this system, but the /var/lib/urandom one hasn't been touched since July.  Should we be migrating/cleaning on upgrade if that's obsolete somehow?
<infinity> mdeslaur: Or hardlinking them?
<mdeslaur> infinity: the old path belongs to the initscripts package
<infinity> PS: Why does systemd need to "standardize" by randomly moving stuff around?
<infinity> mdeslaur: Well, "belongs"... It doesn't belong to any package, from dpkg's POV.
<pitti> update-alternatives: error: no alternatives for default.plymouth
<pitti> sed: can't read /usr/share/plymouth/themes/.plymouth/.plymouth.plymouth: No such file or directory
<pitti> E: /usr/share/initramfs-tools/hooks/plymouth failed with return 2.
<pitti> didrocks: ^ any idea?
<pitti> didrocks: that happens on autopkgtests (and serial-kills workers, but that's my problem)
<mdeslaur> infinity: well, the directory does. You want to remove the file?
<infinity> init.d/urandom:SAVEDFILE=/var/lib/urandom/random-seed
<infinity> Hrm.
<cyphermox> do we still need /var/lib/urandom/random-seed for anything, like in the initramfs or something?
<didrocks> pitti: it's fixed already
<mdeslaur> cyphermox: I hope not, because it's not being updated
<didrocks> pitti: -3ubuntu2 FTW ;)
<cyphermox> mdeslaur: I know ;_
<didrocks> pitti: happened when you install the text theme without the logo oneâ¦
<infinity> mdeslaur: Well, it's only updated if you're running sysvinit, which we don't support.
<pitti> didrocks: ah, trÃ¨s bien; merci !
<infinity> Still feels like those should have just been the same location, though.
<mdeslaur> yeah
<infinity> Which would be fixable in /lib/systemd/system/systemd-random-seed.service
<didrocks> pitti: dsl d'avoir cassÃ© ton testbed ;)
<infinity> And /lib/systemd/systemd-random-seed ...
<xnox> mdeslaur, isn't it deprecated with 4.2 or 4.3 kernels anyway, and random-seed does nothing anymore.
<infinity> xnox: Why would it do nothing?
<mdeslaur> infinity: I'm sure pitti won't mind more debian-specific stuff in systemd
<infinity> xnox: Sure looks like it does something here.
<xnox> infinity, because kernel no longer uses seeds.
<mdeslaur> xnox: hrm?
 * xnox is looking for references
<mdeslaur> xnox: "kernel no longer uses seeds" sounds scary :)
<infinity> mdeslaur: Either a hardlink or symlink between locations feels like the more correctly Debian-upstreamable thing to me.
<infinity> mdeslaur: Since it's theoretically possible to flip-flop between systemd and sysv between boots.
<ondrej> Any current Ubuntu PHP maintainers around?
<infinity> ondrej: We don't have anyone dedicated to PHP.
<LocutusOfBorg1> hi folks, nobody available for a quick backport?
<infinity> ondrej: Closest you'd find is rbasak, perhaps.
<LocutusOfBorg1> [12:04:30] <mfv> valhalla_: cosa intendi per "disco morto"?
<LocutusOfBorg1> oops
<xnox> mdeslaur, infinity: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033297.html
<infinity> ondrej: Or, if there's something you want to argue about, I'm always up for telling people they're wrong.
<rbasak> ondrej: o/
<LocutusOfBorg1> https://bugs.launchpad.net/wily-backports/+bug/1512982
<ubottu> Launchpad bug 1512982 in wily-backports "Please backport hedgewars 0.9.22-dfsg-2 (universe) from xenial" [Undecided,New]
<xnox> which points to http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Crypto-Akcipher-PKE
<xnox> and http://marc.info/?l=linux-kernel&m=143496272614455&w=2
<mdeslaur> xnox: huh, interesting
<rbasak> ondrej: so I've been following php7.0 but haven't looked into it yet.
<rbasak> ondrej: your advice would be much appreciated.
<infinity> xnox: Curious.
<ondrej> rbasak: just wanted to ask what are your plans for next LTS?  PHP 7.0 or not?  And if yes, there's a lot work to be done yet, and I could use some help polishing the new packaging :)
<xnox> mdeslaur, infinity: basically it does crazy cpu jitter deltas to "seed" things on boot.
<ondrej> rbasak: my advice would be to go for PHP 7.0 and help me prepare transition path :-P
<ondrej> but honestly I don't think you can release without it
<rbasak> ondrej: I've not decided yet. My concern is how stable it will be at release.
<infinity> xnox: So perhaps we can just drop those hunks from the installer entirely, rather than changing the path.
<infinity> mdeslaur: ^
<xnox> infinity, yes.
<rbasak> ondrej: I don't want to release something that is horribly broken or extremely painful to fix after release due to SRU policy, that's all.
<rbasak> ondrej: if it's good, then I'd love to have 7.0 replace 5.6 and be in main in Xenial.
<rbasak> ondrej: do you have a list of what is outstanding?
<ondrej> rbasak: there's an option of keeping both (the old src:php5 and new src:php7.0), but it will need some work (there are some conflicts, mainly phar)
<jamespage> cjwatson, no I'm just going to land it
<rbasak> I'm not very keen on having both. It doubles maintenance work. Even though in theory 7.0 would be in universe and thus off my plate, in practice that doesn't happen.
<cyphermox> infinity: mdeslaur: I'll all for removing code
<rbasak> We did it with MySQL 5.5 and 5.6 in Trusty, and even though 5.6 was in universe I think users had expectations about it.
<infinity> rbasak: Yeah, concur, please don't ship two versions of PHP, it's insanity.
<infinity> rbasak: Take it from someone who had to support both php3 and php4, and then both php4 and php5, it's hell.
<infinity> ondrej: ^
<cjwatson> jamespage: ah, excellent, thanks
<infinity> ondrej: Surely, you still remember the bad old days. :P
<ondrej> rbasak: I still can't build PECL extensions for multiple versions of PHP that could be coinstalled now (although I understand it's not high priority for Ubuntu stable release); PEAR got recently splitted out, so it might be broken
<ondrej> infinity: I remember only php4+php5 :) fortunately
<infinity> ondrej: I'd rather just see php7 in experimental ASAP, and then slowly work out all rdeps until they all seem to more or less work, then just transition.  Shipping both sucks.
<infinity> ondrej: But that's just advice, since I washed my hands of PHP years ago, I get no real vote. :P
<infinity> (I do, however, get some very strong votes about what's acceptable in Ubuntu)
<ondrej> infinity: the main php7 upload already made it to unstable, but I am missing other pieces and bits still in NEW (f.e. dh-php)
<rbasak> I see only two options. 1) Continue shipping php5 5.6 in main in Xenial, delete php7.0 from Xenial universe and blacklist it from autosync for this cycle.
<rbasak> 2) Move to php7.0 in main in Xenial.
<xnox> rbasak, ondrej: it doesn't have to be default. php7 was uploaded into debian, so presumibly it is co-installable with 5, hence we will have it available, at least in universe.
<rbasak> 3) [ruled out] Ship 5.6 in main and 7.0 in universe.
<infinity> rbasak: With my TB and release hats on, I concur.
<infinity> xnox: As pointed out, that never works out for us in practice.
<cjwatson> infinity: speaking of php (codecoverage specifically) - chroots with bootstrap archive pls?
<infinity> xnox: Users love shiny.  If we give them old in main and shiny in universe, they'll run shiny and complain when it sucks.
<ondrej> rbasak: I would advice start with checking what's in ppa:ondrej/php right now, I think it's manageable to polish it into Xenial if I have some help with testing and bit of patches
<mdeslaur> infinity, cyphermox, xnox: I'm uncomfortable making the call to drop the random seed for now
<cjwatson> infinity: and if we give them old in main and nothing in universe, they'll still fetch shiny from somewhere and complain when it sukcs :)
<cjwatson> *sucks
<ondrej> rbasak: from what I hear from people they are all keep on moving to php7 since the breakage is not so horrible
<infinity> cjwatson: Yes, but they complain less directly to us. :P
<ondrej> cjwatson: fortunately, most of those grab the new and shiny from me :)
<ondrej> so not that bad
<rbasak> ondrej: off-topic, I think you have a MySQL PPA that is causing some breakage amongst users.
<xnox> mdeslaur, i shall check the kernel source code again, i believe they left the seed writing there, but it's a no-op that does nothing.
<xnox> mdeslaur, if that is the case, then i'll drop it for xenial and up.
<mdeslaur> xnox: if it is a no-op, then that's fine
<ondrej> rbasak: I have a issue tracker on github and I have only one bugreport about MySQL (something about process hanging on installation), haven't got time to look at it.
<cyphermox> xnox: if you want to drop it, might want to review my merge again if you still want to test boot my changes
<cyphermox> :D
<infinity> ondrej: And yes, if 7.x isn't "production-ready" for xenial, I'd rather we don't ship it in universe at all, and let users get the shiny from your PPA.  Cause we won't commit to supporting it very well (or at all), so we'd just be leading people down the garden path.
<ondrej> infinity: I concur and I have much easier job, since I just blame upstream when something breaks :)
<infinity> ondrej: So, I'll let you and rbasak sort out how to get to "production-ready" and how long that will take, but with my various hats on, I think exclusively 5 or exclusively 7 are the only reasonable options for Ubuntu.
<rbasak> ondrej: I'm looking for a bug reference for you. It looks like users using your PPA ended up with some bits from the Ubuntu archive which are now (or were for a while) a higher version.
<infinity> ondrej: And as a mostly uninterested bystander, I think only 7 should be a goal for Debian too.
<rbasak> mysql-common from one place and mysql-server-5.x from the other
<ondrej> infinity: rbasak: if you stay with php5 we should definitely make php5-fpm and php7.0-fpm coinstallable
<rbasak> ondrej: what I'd really like to see right now is a list of everything you think needs doing to make 7 ready.
<ondrej> infinity: Definitely, the only side-goal I have is to have an option to support multiple versions installed from third-party (mine) repository
<rbasak> ondrej: then we can inform an interim decision about which of the two options to aim for.
<mdeslaur> xnox: it says "DRBG is now seeded with both /dev/random and Jitter RNG.", but the random seed file is to seed /dev/random
<mdeslaur> xnox: random.c still mentions seeding being necessary
 * mdeslaur isn't convinced yet
<ondrej> rbasak: everything that B-D on php5-dev needs to manually converted to php-all-dev (also s/dh-php5/dh-php/), checked and recompiled, same goes for everything that Depends on "php5" and variants
<ondrej> I only upgraded PECL exts that people care about
 * rbasak looks
<rbasak> ondrej: any known bugs or shortcomings in the packaging that might bite us?
<ondrej> rbasak: debbugs#805222 - pkg-php-tools can't build PECL extensions now
<ondrej> rbasak: one more thing you should add to your consideration -> If you go with PHP 7.0.n where n is a small number you will probably end up with more security patches than if you stay with 5.6.m where m is a high number;  on the other hand security support for PHP 5.6 ends on 28 Aug 2017 and it will be much harder to backport security patches from 7.0 tree because of changed internals
<rbasak> ondrej: thanks.
<ondrej> ondrej: re #805222 it's because of broken PEAR 1.10.1
<rbasak> Security update are a factor for mdeslaur or sarnold to consider: ^^
<rbasak> I assume they're OK to move to something newer though. Less backporting work for them I think.
<ondrej> rbasak: so perhaps the biggest help you could do is to look at php5 and php7.0 and come with a way how to make most of the packages live side by side
<rbasak> ondrej: why focus on making them live side by side?
<rbasak> ondrej: can we not just go for it and get everything migrated if we decide to get it done?
<mdeslaur> Something newer is preferable, but the fact that it's a .0 release is a bit problematic
<ondrej> rbasak: because that would help the users who want to stay with the old PHP 5.6 (yes, I still have inquiries about PHP 5.3) if you go with PHP 7, but also users who want new&shiny if you stay with PHP5
<mdeslaur> that's when all the new features are introduced and quickly get rewritten/fixed
<mdeslaur> so there's usually a lot of code churn between a .0 and the next couple of point releases
<mdeslaur> which makes our job harder
<rbasak> ondrej: IMHO, Ubuntu users who want to stay on a previous PHP version can stay on a previous Ubuntu release.
<rbasak> (unless we decide to stick to 5.6 in Xenial)
<ondrej> mdeslaur: rbasak: right, the amount of security patches that go to 5.5.x is smaller than for 5.6.x
<mdeslaur> If it was something like 7.0.2, it would be a no-brainer
<rbasak> mdeslaur: so where are you on the balance of 5.6 vs. 7.0 in Xenial?
<rbasak> Maybe there's a chance that there will be a 7.0.2 before Xenial is released?
<ondrej> rbasak: well, it shouldn't be a huge amount of work acording to this user, who tried to tackle this: #807165
<mdeslaur> for 7.0.0, there are pros and cons from a security point of view, so I don't have a stong opinion
<mdeslaur> rbasak: it would probably be easier to support 7.0.x in the LTS release
<rbasak> OTOH, if we ship 7 in Xenial then presumably that will increase the number of users of PHP 7.0 significantly over the next year, so we'll have created the problem ourselves, IYSWIM.
<mdeslaur> rbasak: as long as the big code churn changes are done in the first couple of point releases
<rbasak> mdeslaur: OK, thanks.
<mdeslaur> that's from a security point of vue
<mdeslaur> view
<mdeslaur> what users want in an LTS at this point in time, I don't know
<rbasak> I've been thinking about "what users want in an LTS at this point in time"
<rbasak> I've come to the conclusion that 7.0 would be better than 5.6 for Xenial from this perspective.
<mdeslaur> ok
<rbasak> Just because users who want to stay on 5.x can just stay on Trusty.
<mdeslaur> that's true
<rbasak> And they can move to Xenial and 7.0 at their own pace.
<mdeslaur> good point
<mdeslaur> but yeah, please don't ship two in the archive
<rbasak> ondrej: I think from both my Ubuntu and Canonical hats I can't justify spending time on co-installability.
<rbasak> ondrej: since that's not a goal at all for Ubuntu - in fact we specifically don't want it.
<ondrej> rbasak: I would be happy to add you to pkg-php alioth group if you want making changes directly in the main repo (or in the branch)
<rbasak> Thanks
<rbasak> I'm rbasak-guest on alioth.
<ondrej> rbasak: then please take care of all dependencies down the tree
<rbasak> That's something more palatable for me in principle I think.
<rbasak> I need to consider whether it's feasible to get this all done in time for Xenial feature freeze.
<rbasak> Given my other responsibilities too.
<rbasak> infinity: what do you think about leaving some reverse deps in universe behind if I run out of time?
<rbasak> infinity: suboptimal I know, but is it completely unacceptable?
<rbasak> If I focus on reverse deps in main I think that's probably feasible (though I haven't looked)
<ondrej> rbasak: alioth done
<rbasak> Thank you!
<ondrej> I have to go now, thanks for the chat and conclusion
<mdeslaur> xnox, infinity, cyphermox: I believe the comment on the systemd list is wrong and the random seed is still necessary.
<xnox> mdeslaur, can you email systemd-devel about it please?
<rbasak> ondrej: thank you for bringing the discussion to us!
<xnox> mdeslaur, and/or present your finding? i am a bit lost in the kernel code and i see that jitter is used to seed a lot of things, but i can't tell if everything uses it.
<mdeslaur> xnox: you're looking at the crypto stuff, the random devices don't use that at all AFAIK
<xnox>                                                                                                                                      wow
<xnox> oh, i have a lot of whitespace.
<Laney> haha
<xnox> Laney, i thought i got switched to a RTL mode for a second, as it seemed like i'm typing RTL.
<xnox> Does anybody develop ubuntu on a Windows Laptop?
<sladen> xnox: I did have some short-term Wubi installs a long time ago.
<sladen> xnox: however the lesson learnt from that is that relying Windows NTFS underneath wasn't such a great idea
<Mirv> Laney: I'm not sure if it's about hinting you sometimes do, but okteta on all archs would need to run its tests with the proposed version of qca-qt5 included - see the one pass here http://autopkgtest.ubuntu.com/packages/o/okteta/xenial/amd64/
<Mirv> the newer runs are with the older qca
<Laney> Mirv: hmm, I wonder how to do that
<Laney> it tries to minimise the things used from proposed
<Laney> let me try it with multiple --trigger
<Mirv> and qtmir-gles would also need hinting to run with updated qtbase-opensource-src (not just qtbase-opensource-src-gles) sources included so that libqt5test5 gets to its updated version so that the autopkgtest finds the version of libqt5test5 it expects to find
<Mirv> http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/xenial/amd64/
<Mirv> or of course if wanting to just migrate one can check that both did succeed earlier and force migration _if_ everything else just happens to be in order - xnox, have you decrypted update_output lately on what needs to be done?
<xnox> Mirv, no, cause there is no full update_output, when things are "not considered" due to autopkgtests. I believe i have unwound all the poppler changes.
<Mirv> I don't even find qtbase there at the moment, so I guess there's nothing to read yet
<Mirv> xnox: right, exactly
<Mirv> the issues I mentioned above are the ones remaining afaik
<Mirv> and they are kind of non-issues
<xnox> Mirv, well, i'm gonna do another declarative upload with fixed symbols for s390x, which will trigger builds of the rest of the qt5.5 things.
 * xnox ponders if i'm allowed to copy builds into the archive from a nonvirt ppa, instead of rebuilding things.
<Mirv> xnox: are you sure it's worth the delay at this point in case we could migrate everything to release pocket within a few hours? I mean, it seems every time we're near migration, something "happens" somewhere like pkg-kde-tools yesterday.
<Mirv> xnox: anyway, if you do consider please build with -v parameter so that 5.5.1-2ubuntu1 gets included in the .changes file so that LP hopefully gets full updates to all of the bug reports
<cjwatson> xnox: that's OK if it's exactly correctly configured - needs to have debug symbol settings matching the archive, etc.
<Mirv> when they're finally fix released
<cjwatson> xnox: which archive so I can check?
<cjwatson> Mirv: that shouldn't matter
<xnox> cjwatson, i think it's not -> https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages
<cjwatson> Mirv: we need that for the SRU reports, but otherwise, LP should work it out for itself nowadays
<Mirv> cjwatson: I was thinking about the texts that get automatically put to the LP reports. ah, nice if there have been fixes.
<xnox> cjwatson, uses proposed, but all components instead of matching to start with.
<xnox> cjwatson, and doesn't build debug symbols, nor publishes them.
<cjwatson> well yeah all PPAs use all components, that doesn't necessarily stop us copying from them
<cjwatson> Mirv: those should be calculated from the copy ancestry
<cjwatson> but debug symbols would be an impediment
<Mirv> xnox: furthermore, I don't think you necessarily get that much further with just qtdeclarative. next stop might be qtwebkit/qttools and only after those it starts to be a breeze. but as before, I'd really like to have these all migrate to release pocket as soon as possible as it's causing all kinds of trouble on the phone to have silos stuck.
<cjwatson> xnox: for the future, you can flip the debug symbol settings yourself on +edit
<xnox> cjwatson, yeap.
<xnox> Mirv, i'm not convinced thigs will migrate, even if we mark all of them to skip all of autopkgtests.
<Mirv> xnox: it'd be nice to find out before causing more autopkgtests to be run. then if it seems it's something that again takes more time than a little, it wouldn't hurt to have qtdeclarative restarting jobs again.
<Mirv> every day I'm getting questions from almost every time that if the migration is happening or not...
<Mirv> s/time/team/
<xnox> Mirv, well that's easy to answer "no" =) it's only a "yes" when it migrates =)
<xnox> pitti, Laney: there is a lot of green, can we mark remaining autopkgtests to be ingored and see if britney migrates things?
<Mirv> xnox: well, but it's not just a question but a plea to get it done asap to have landings work fluently again
<xnox> Mirv, all landings should be building against -proposed, what's the problem with them? you can totally release them into xenial-proposed.
<Mirv> xnox: meanwhile you could see if you can build qtwebkit + qttools + qtmultimedia (in that order) for s390x. when those work and no symbol updates are needed, the rest of the modules would work pretty well. but before qttools works (requires qtwebkit), the rest won't build
<cjwatson> silos aren't released until things migrate, which is deliberate so that people pay attention to migration
<xnox> Mirv, if you are telling me they build against xenial-release, without proposed..... that's where they are going wrong =)
<pitti> xnox, Mirv: can do; only the octeta issue holds it for now, so like last time I'll ignore that
<xnox> cjwatson, ok.
<xnox> cjwatson, can you give me disk space in https://launchpad.net/~xnox/+archive/ubuntu/nonvirt please =)
<Mirv> xnox: no, the problem is that landings don't merge to trunks, and people don't know what's the real status of their landings and if there's something blocking the migration other than Qt migration. so the train basically does not function as usual since everything is blocked in proposed.
<xnox> cjwatson, enough to built all of qt5. 30GB?
<Laney> pitti: I'm retrying okteta, assuming that adding --trigger causes a package to be used from proposed
<Laney> Mirv says it should be fixed
<Mirv> it already passed once
<pitti> Laney: correct; but it was "fixed" before ubunt4
<cjwatson> xnox: IIRC 20GiB is usually fine, bumped to that
<xnox> cjwatson, thanks.
<Mirv> and takes over 3h to rerun so it would be useful to ignore
<pitti> Laney: overriding anyway to unblock this, if it's ok for you?
<Laney> ok
<Mirv> pitti: kio seems to also randomly fail on armhf + ppc64el http://autopkgtest.ubuntu.com/packages/k/kio/
<xnox> Mirv, well, it's just i will go through pain of all of these autopkgtests independently when i do upload things for s390x....
 * xnox thinks windows10 is bonkers, looks nice on a 4k display - but "updating windows 5% present, it will restart multiple times is scary."
<xnox> pitti, looks like qtbase-opensource-src-gles will not be considered, but it should go at the same time (i think), ideally it would need a similar hammer as done to plain qtbase variant.
<xnox> Mirv, qt3d-oepnsource-src-gles depends on qt3d builds of matching versions which are no longer satisfiabled?!
<xnox> Mirv, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qt3d-opensource-src-gles
<xnox> pitti, ditto qtdeclarative-opensource-src
<xnox> and qtdeclarative-opensource-src-gles
 * xnox starts a pad with hints
<xnox> qtscript-opensource-src
<xnox> qtsensors-opensource-src
<xnox> qtx11extras-opensource-src
 * xnox ponders if http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libqapt will affect the transition
<pitti> xnox: so we need to ignore okteta and kio failures?
<xnox> pitti, yes please.
 * xnox retires ktexteditor/arm64
<xnox> missing build
<Mirv> xnox: ah it needs a no-change rebuild, sorry
<Mirv> (qt3d)
<Mirv> uploading
<xnox> britney is very good at generating excuses.
<pitti> (NB: these will come back with the next Qt update)
<xnox> pitti, qtmir-gles is confusing in the whole output it's sometimes listed as "amd64 pass, armhf always failed, i386 pass, ppc64el always failed" and sometimes as "amd64 pass, i386 regression"
<Mirv> uploaded the rebuild
<xnox> shouldn't all the results be the same?
<Mirv> xnox: the -gles packages only build for amd64 + i386
 * Mirv switches to low availability mode
<pitti> xnox: indeed, for qtmir-gles itself the tests aren't limited to the arches where it's actually available, so on arm/ppc it's always failed
<pitti> xnox: shouldn't block anything, but a cosmetical wart indeed
<Laney> can we make autopkgtest forget the kio/armhf kio/ppc64el passes?
<xnox> pitti, in qtbase-opensource-src-gles qtmir-gles is listed as regression, when i wouldn't think so... anyway, will wait for Mirv's no change rebuild and updated britney output.
<Laney> looks like they shouldn't have passed
<Laney> I retried gles and it passed now
<pitti> Laney: we can; but I have too crappy internet to do it from here
<pitti> +force-badtest okteta/4:15.08.2-0ubuntu2
<pitti> +force-badtest kio/5.15.0-0ubuntu3
<pitti> for now I pushed these
<pitti> Laney: i. e. we need to delete the passed results from swift and from britney's results.cache
<pitti> (feel free to, of course)
<Laney> pitti: let me try
<xnox> pitti, qtbase-opensourse-src-gles is still not considred. looks like we need
<xnox> force-badtest kdepimlibs/4:15.08.2-0ubuntu2
<pitti> xnox: I just hinted orce-badtest kaccounts-integration/4:15.08.2-0ubuntu1
<xnox> and kaccoutns-ingegration, yeap.
<pitti> test suite timed out
<pitti> xnox: committed
<Laney> hmm, apparently those swift deletes weren't enough
<pitti> Laney: did you also drop the successful results of that package from results.cache?
<pitti> Laney: (in principle you can also rm it, but then it'll take > 1 h hour to re-download)
<pitti> so better to just delete all results of that package, or at least the "true" ones
<Laney> pitti: oh right, I removed the bad arches
<Laney> is the web UI going to update?
<pitti> Laney: oh, and results.cache editing needs to happen while britney.py is not running (it's ok in --print-uninst mode, though)
<xnox> pitti, Laney: if i'm reading things right apt transition is entangled, and not currently considered hence e.g. at least on s390x qtbase transition causes a bunch of apt* things to become uninstallable.
<pitti> Laney: no, that won't magically see removed results
<pitti> Laney: but debci is irrelevant for britney
<Laney> yeah, just tidiness
<Laney> xnox: could be
<Laney> it'll look a lot better once the other qt* become candidates
<xnox> and now britney has a traceback http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2015-12-09/15:48:18.log
<xnox> ValueError: Expecting property name: line 34287 column 5 (char 631482)
<xnox> Laney, ^ did you make a typo? =)
 * xnox is watching http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2015-12-09/15:54:26.log
<Laney> weird
<xnox> pitti, Laney, i think britney doesn't like the edited cache.
<Laney> I thought i followed the pitti instructions, let me try deleting all kio
<pitti> does it crash? forgot a trailing comma somewhere?
<pitti> json is awfully sensitive against those
<xnox> Laney, one must not have trailing commas, this is not python json barfs at them.
<xnox> i.e. [foo,bar,baz,] will crash, but [foo, bar, baz] is good.
<Laney> it's all gone
<pitti> check with json_pp or similar
<xnox> ok, a bunch of them are valid candidates now.
<xnox> maybe we need to hint things together.
 * xnox digs
<Laney> xnox: I'm following amarok down
<pitti> update_output has a nice collection
<xnox> pitti, yeah, it does look rather complete.
<Laney> it seems to come down to qtdeclarative/s390x
<xnox> really?!
<xnox> on amd64
<pitti> oh, do we enforce britney on s390 already?
<xnox> pitti, yes, we always have.
<xnox> Laney, well qtdeclarative/s390x is easy - it builds in my ppa, will re-trigger the world, and then the rest of qt builds.
<pitti> ARCHITECTURES     = amd64 arm64 armhf i386 powerpc ppc64el
<pitti> not that I can see
<pitti> but there seem to be some hand-crafted s390 things in excuses
<xnox> Laney, but there is no qtdeclarative in xenial-release, why would it matter?
<xnox> pitti, http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/287 ?
<Laney> I'm looking on amd64
<pitti> xnox: err, sure there is?
<Laney> but wait, I got confused, let me check again
<xnox> Laney, how can anything on amd64 need a qtdeclarative/s390x. if you elaborate...
<pitti> xnox: ah, thanks
<xnox> it's a NEW_ARCH, but not a f##ked one
<pitti> xnox, Laney: seems it's hinging on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src-gles#libqapt
<xnox> pitti, yeah, i think so.
<Laney> xnox: Nah, it needs python-apt to be candidate
<caribou> Any reason why 'pull-debian-source' would fail indicating an invalid signature whereas dget correctly download & verify the source package ?
<xnox> Laney, well the fact that libqapt remove apt when trying to do autopkgtest is not good either.
<pitti> argh, apt isn't in yet either?
<pitti> probably that depends on qapt too, and that seems rather broken
<xnox> pitti, no, cause it wants new qt =)
<xnox> i think we should hint apt into the qt doom.
<pitti> this is like the entire wily -> xenial in one step
<Laney> haha
<pitti> given that the libqtapt tests want to remove a gazillion packages, it smells like the transition isn't complete there
<pitti> we can't possibly hint over that
<pitti> or it has been fixed since and the qapt tests just need a re-run
<Laney> apt is in the doom
<Laney> autohinter is good at that
<pitti> how do you mean?
<xnox> well, in a -proposed enabled chroot libqapt & new qt coinstall fine
<xnox> can we rerun libqapt test with qtbase as a trigger?
 * pitti just retries the qapt tests, they shold be reasonably quick
<xnox> pitti, and retrigger software-properties too?
<xnox> from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src-gles#libqapt
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libqapt
<pitti> I retriggered all retry-autopkgtest-regressions|grep apt
<xnox> ooo. fancy =)
<Laney> could probably do with a tracker for apt
<xnox> Laney, yeah.
<xnox> well, it's apt libqapt, packagekit, python-apt, synaptic and ubuntu-core-meta
<xnox> for some reason....
<xnox> which looks fishy
<xnox> ARGH! ubuntu-core-meta
<pitti> Depends: libapt-inst1.7, libapt-pkg4.16,
<pitti> WTF?
<pitti> since when do we see particular ABIs?
<pitti> oh, it's full of that
<xnox> pitti, we used to do that on the phone, back in phonedations days... mvo ? ^
<pitti> so that needs seed update and -meta rebuild
<xnox> pitti, i'm fixing that
<pitti> xnox: danke
<Laney> apt tracker pushed, copied from debian
<didrocks> ximion: hey! icon-format-unsupported
<didrocks> ximion: we got that for some .xpm
 * Laney hopes python-apt gets better
<pitti> xnox: well, on the phone it was a really nasty hack to break our own rules of producing click packages
<pitti> xnox: but on snappy we don't have that
<pitti> so I don't understand why we need to seed library sonames
<Laney> this not being candidate breaks kde-runtime
<Laney> which is presumably all the k*
<didrocks> ximion: is that expected or just a parser false positive? (as they shows up quite well in various software, didn't try in Gnome Software though)
<xnox> hopefully if we can get apt in, qt will follow and the doom will land =/
<pitti> Laney: yeah, same sorryness than libqapt and libapt-pkg-perl
 * xnox is redoing ubuntu-core
<xnox> pitti, what about libapt-pkg-perl?
<pitti> the tests all rip out half of the system
<xnox> oh.
<Laney> pitti: indeed, waiting for the retries to see if it's still bad
<pitti> i. e. same as the others
<pitti> meh, seems not
<xnox> and presumibly aptitude ftbfs on ppc64el is bad too
<xnox> collect2: error: ld returned 1 exit status -> thanks?!
<pitti> this might be a case where packages don't have tight enough dependencies and the apt pinning fails
<pitti> but actually these ought to fall back to unpinned automatically
<pitti> well, at least some of those seem to work now
 * pitti needs to teach autopkgtest to recover from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/apt-clone/20151209_163754@/log.gz and remove pinning
<xnox> pitti, well, it seems to me that given that i can co-install those, with new apt and qt, they should work fine....
<pitti> xnox, Laney: ok, cowboy solution: I temporarily disabled apt pinning in the worker
<Laney> yeehaw
<pitti> so another set of retries should work better
<pitti> and I'll work out how to fix apt pinning for this case
<pitti> my train staion is coming up, need to leave
<pitti> Laney: can you retry-auto-pkgtest-regressions|grep apt|sh again?
 * pitti runs
<ximion> didrocks: jup, that's expected - XPM is generally unsupported
 * xnox is still waiting for ubuntu core to update
<ximion> (and I wonder how an xpm icon even got in the loop, unless it's from installed software, which we have no influence on)
<didrocks> ximion: ok, I need to check what we display then, as we have a svg as well, thanks for confirming!
<ximion> svgs should be fine - some of our tools though give up on the first icon they find, and if that happens to be .xpm, the component gets skipped
<ximion> (usually only happens for software defining an absolute path to a .xpm icon though)
<ximion> didrocks: btw, full DEP-11 support in Debian is nearly finished - it will need AppStream 0.9 and the latest APT to work though, and the AppStream 0.9 release is what I am currently working on (contains some API changes, which unfortunately started already before I knew that I need to implement some Debian support there)
<xnox> Laney, ubuntu-core-meta is in, apperantly last apt transition i did similar replace....
<Laney> super
<infinity> pitti: Why did you sync the experimental findutils?
<xnox> infinity, because you were not on the phone call last thursday?! (mumble)
<infinity> xnox: The mumble meeting was about findutils? :P
<cjwatson> ximion: did Laney talk to you about the feasibility of running the dep-11 generator without a local mirror (i.e. having it fetch just the packages it determines that it needs based on Contents)?
<xnox> infinity, the foundations talking yeah. some of us thought it was a good idea.
<ximion> cjwatson: Jup, see https://github.com/ximion/appstream-dep11/issues/5 - basically I have nothing against populating the "ignored-packages" cache before running the actual extraction, but just using the Contents file might lead to inconsitencies
<ximion> (and us ignoring packages we should process)
<infinity> xnox: Fun.  Did anyone who thought it was a good idea also think to check if it builds everywhere first? :)
<ximion> what one could to is mirror packages based on the Contents file, and demote the warning about a missing .deb package to not-an-error, if some PartialArchive option is set...
<xnox> infinity, talk to pitti who ran away from a train station.
<xnox> infinity, i'd want it purged if it ftbfs.
<xnox> cause it is scary.
<infinity> I'm inclined to delete it from -proposed and let someone try again later if they're willing to commit.
<infinity> But that's just me.
<cjwatson> ximion: ah right, thanks
<xnox> infinity, it totally should use silo landing, yes ;-)
<cjwatson> ximion: we generate Contents daily, so maybe one option is to do timestamp fuzzing based on the date of Contents
<cjwatson> i.e. anything newer than Contents - fuzz-factor we might have to rescan when Contents info becomes available
<cjwatson> I agree that scanning things like binaries in PATH might mean it's not worth it though
<ximion> cjwatson: that feature is something some people want very much - I still need to figure out a smart way how to do this though, without exploding the size of the Components.gz file
<xnox> Laney, uploading packagekit
<xnox> Laney, and then will do the rest of s390x.
<Laney> cool
<xnox> Laney, pitti, is there a magic proxy one can set in autopkgtests to get internetz?
<Laney> xnox: Not that I know of, for http we use proxies which are set in the environment for you
<xnox> Laney, i guess it's something funny http_proxy: http://squid.internal:3128
<xnox> and autopkgtest related
<Laney> what is?
<xnox> Laney, nah, nothing, talking to myself.
<xnox> Laney, aptitude ppc64el FTBFS who wants to fix it? infinity - do you like aptitude FTBFS bug? =)
<pitti> infinity, xnox: fine for me to remove findutils from experimental; chiluk, do you want to backport that fix instead?
<pitti> xnox: proxy is already set
<pitti> Laney: did you already retry after removing apt pinning?
<xnox> pitti, so i'm now waiting on a bunch of arm64 builds for apt transition.
<Laney> yep
<xnox> pitti, and there is packagekit FTBFS all arches, and aptitude/ppc64el FTBFS which will hold up apt =(
<Laney> looks like aptdaemon has some new failures which are real
<pitti> seems not, I'll re-retry to see what fallout remains
<Laney> I did
<pitti> oh, ok
<pitti> it's a looot less now, though
<Laney> there's more green now
<Laney> for python-apt it might even turn out to just be aptdaemon that needs work
<ximion> xnox: packagekit won't build in this ancient version Ubuntu ships
<xnox> ximion, fun.
<ximion> the aptcc backend changed quite a lot between the Ubuntu version and what we currently ship upstream, so I am not sure if it is easier to backport patches or just to upgrade PK
<cjwatson> somebody needs to finish off https://code.launchpad.net/~mvo/click/native-dbus
<cjwatson> otherwise the phone breaks
<cjwatson> (not me, I'm not working on click at that level any more)
<xnox> at the moment aptitude/ppc64el FTBFS & packagekit FTBFS, against new apt block the world of things in xenial-proposed. So i'm looking at minimal patches to resolve the build failures.
<xnox> mvo, are you busy? =)
<mvo> xnox: we will need the new PK from debian
<mvo> xnox: no idea why aptitude fails, that should be ok :/
<cjwatson> mvo: which means we need click native-dbus
<ximion> mvo: btw, you could at least upgrade PK to 0.9.5-2
<ximion> that was the release before plugin support was dropped
<mvo> ximion: will it work with the latest apt :) ? if not that won't help us
<ximion> no, it won't work with the latest APT, but in theory backporting patches to that release might be easier
<ximion> the PK version in Ubuntu is pretty much dead
<ximion> (upstream)
<xnox> ximion, backport from where... if plugin support was dropped, i would assume nobody fixed deb-file.cpp to work with new apt...
<xnox> or wel fix libpk_backend_aptcc
 * xnox goes to look
<mvo> cjwatson: yeah, I hope the team around alecu can have a look at https://code.launchpad.net/~mvo/click/native-dbus I think its pretty much done except for final testing
<ximion> xnox: when looking for ancient Debian packages, http://snapshot.debian.org/package/packagekit/0.9.5-2/ is the place to go :)
<ximion> but fixing whatever is blocking PK 1.0.11 in Ubuntu would of course be even better :)
<xnox> mvo, i'll try to cherrypick https://github.com/hughsie/PackageKit/commit/30bfee4d41944bbfbd7a40c7f3fa1004fc6effa9
<alecu> mvo: with that branch, can we drop the usage of packagekit in click?
<alecu> mvo: I guess click scope/system updater can start using that new dbus interface instead of using packagekit to install apps.
<cjwatson> alecu: right, anything explicitly using the pk interface would have to switch over to the native one, and then we can drop the pk one
<cjwatson> alecu: it was intended as a graceful transition
<cjwatson> (would have been slightly more graceful if finished off a year ago, but there you go ...)
<alecu> yeah, shifting priorities :-)
<alecu> cjwatson: sounds great, thanks.
<cjwatson> and of course anyone in the habit of using pkcon needs to stop doing so, iirc that branch makes "click install" work more gracefully
<alecu> wonderful
<alecu> dobey: ^^^
 * xnox ponders why aptitude build downloads firefox
<dobey> hmm, ok
<xnox> alecu, dobey: it's just someone who still uses click should finish that native-dbus work. cause everyone else who used to do it, moved on to other things or snappy.
<alecu> xnox: agreed
<dobey> well, what will be the equivilent command line to run for "pkcon install-local" ?
<xnox> Laney, packagekit is in.... it builds....
<mvo> dobey: "click install" will do the right thing and act like pkcon install-local"
<dobey> mvo: so click install will no longer require root like it does now?
<mvo> dobey: yeah, it will call itself via pkexec iirc
<mvo> dobey: if run without root privs
<mvo> elopio: still all looking good?
<balrogg_cs> Brazilian here or channel ubuntu-devel from brazilian?
<elopio> mvo: yes. Do you want to release today or tomorrow?
<elopio> mvo: yes. Do you want to release today or tomorrow?
<xnox> slangasek, mvo, pitti, Laney, Mirv - so aptitude ppc64el build should work with -O2, uploaded now. Hopefully qt & apt will now migrate over....
 * gammax ciao
<dobey> mvo: does that mean it will request a password from the user to elevate privs? or it will talk to a system dbus service that's running as root, to unpack the files?
<mvo> elopio: I think I push to stable tonight and do the rest tomorrow
<mvo> dobey: asks for a password
<dobey> mvo: that won't be acceptable for installing packages from the scope then
<dobey> we need equivalent behavior to "pkcon install-local"
<mvo> dobey: it will use pkexec, is that not what pkcon is also doing?
<dobey> mvo: pkcon doesn't require entering a password
<dobey> i don't know the technical details of the implementation
<dobey> i just know it doesn't require asking for the pin/passwrod to elevate privileges to install packages
<mvo> dobey: yeah, I think that is because we whitelist it via policykit, its been ~1y since I worked on that branch, let me have a look to refresh my memory
<pitti> xnox: cool, thanks!
<mvo> dobey: I'm pretty sure we had the scope in mind when doing this
<xnox> pitti, just waiting on armhf aputpkgtest queue to drain.
<mvo> dobey: or at least we thought about it so that its easy to do passwordless installs via policykit
<pitti> xnox, Laney: I know what's going on with the failed package install under pinning; I have a fix now, currently running tests
<xnox> pitti, and aptitude/armhf to publish
<pitti> then I can remove the cowboying again
<dobey> mvo: ok, well i'm just expressing my concerns about how it might break, and stating what we need in terms of how the scope works
<pitti> "--apt-pocket=proposed=src:python-apt -U apt-clone" works now
<mvo> dobey: right, I agree, this needs to be approached carefully
<dobey> mvo: anyway, there's no need to rush this either, as phone images are going to stay on 15.04 until after at least 16.04 release.
<dobey> and at that point we may not have click on the phone anyway :)
<mvo> dobey: aha, great. that gives us some room then
<mvo> dobey: good point
<xnox> pitti, although we still have real looking aptdaemon failure https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/aptdaemon/20151209_192259@/log.gz
<pitti> indeed; 100 is apt's typical error code
<pitti> Laney, xnox: cowboy change removed, proper fix deployed
<pitti> xnox: it seems aptdaemon isn't totally broken, but I'd feel better if mvo could have a look before we hint it
<pitti> i. e. if it's harmless enough to fix it after apt lands
<Laney> pitti: it's a bit worrying to me if we let the aptdaemon regressions through since they seem caused by the new (python-)apt
<Laney> good work on the pinning fix
<pitti> right, hence I'm hesitant
<pitti> and it can't just be ignored for a longer time, at most to untangle this
<rharper> stgraber: do you know what triggers upstart net-device-added for interface aliases (eth1:0) ?
<xnox> rharper, upstart-udev-bridge no?
<rharper> xnox: for physical devs, but a device alias isn't physical
<stgraber> rharper: does it trigger? I wouldn't think it would
<rharper> stgraber: I'm guessing not because we do the 120second wait on interface dance, then eventually it shows up
<rharper> trying to understand how it's showing up at all then if nothing emits the signal to trigger upstart to touch the /run/network/$iface file
<xnox> rharper, try running udevadm monitor, or retrigger udevadm events. if things show up there, voila there is your answer - udev (or something) synthesized udev event, which upstart-udev-bridge noticed and emitted net-device-added.
<xnox> rharper, oh, and stuff in /run/network/ is also done without any upstart stuff in the initramfs and it's propagated across to the booted system too.
<xnox> (and installer)
<rharper> right
<rharper> I've looked that /var/log/udev  (which looks like a stream of events) ; nothing in there seems to be "virtual" ; all physical devices ;
<xnox> rharper, sure it is.
<xnox> $ sudo udevadm trigger -c add -s net -n -v
<xnox> rharper, try ^ that should print the net added events that udev emits, which upstart-udev-bridge sees and propagates. I have a few things. This way you can verify what's coming from udev & bridge side of things.
<xnox> i have all my tunnels and bridges there. and lo
<xnox> and that's it.
<rharper> cool
 * rharper collects some more data 
<xnox> everything listed in that output, at some point in the past, had upstart net-device-added event.
<rharper> but no timestamps to see in what order or when
<xnox> rharper, no. this is just a dump of current udev database. if you want to see that, increase udev verbosity (and initramfs as well) and then you'll have a fuller log.
<xnox> rharper, boot upstart with more detailed verbosity to have a log of events.
<rharper> ok
<rharper> is there a boot param to bump upstart verbosity ?
<xnox> rharper, yes, in the upstart cookbook
<xnox> rharper, http://upstart.ubuntu.com/cookbook/#add-verbose-or-debug-to-the-kernel-command-line
<rharper> thx
<cjwatson> dobey: right, as mvo says, whitelisting click native-dbus via policykit is just as easy as whitelisting the relevant bit of packagekit, if anything I think slightly easier
<cjwatson> dobey: oh, in fact, click native-dbus gets to be smarter because it knows it's doing things for a particular user, and it doesn't in fact need policykit auth at all, or didn't last time I touched the branch
<cjwatson> mvo^-
<cjwatson> dobey: so the system dbus service runs as root but it checks what user is calling it and does things on their behalf
<cjwatson> dobey: pkexec isn't involved, I think mvo is misremembering there
<cjwatson> http://bazaar.launchpad.net/~mvo/click/native-dbus/view/head:/click/install.py#L454
<cjwatson> http://bazaar.launchpad.net/~mvo/click/native-dbus/view/head:/lib/click/dbus-service.vala is the service code
<juliank> Something went wrong with the packagekit ubuntu numbering:  0.8.17-4ubuntu6~gcc5.4ubuntu1
<Saviq> doko, hey, Q about our toolchain... would you ever expect a "undefined reference to..." error to depend on build flags? we're looking at a situation in xenial where we can link fine against liblightdm-qt5-3 in Debug, but not in Release or RelWithDebInfo...
<juliank> Laney: (Just want to leave that here before I go to sleep) There should be no regressions caused by python-apt 1.0 -> 1.1~beta1, they are most likely caused by APT itself.
<doko> Saviq, sure, if the reference doesn't exist in an optimized build. I saw that in the past for template instantiations which were not explicit but just assumed
<doko> I think that was in one of the myriads of webkit
<Saviq> doko, ack, thanks
<Saviq> doko, hmm but wait, I'm talking about a situation where the reference "goes missing" in the released library, as packaged, it's the "downstream" project that links in debug but not in release, think that might still be optimizations?
<doko> Saviq, an example might help
<doko> please just file a bug report
<Saviq> doko, ok, we'll do
<Saviq> tx
<roaksoax> doko: howdy! any ideas when newer twisted-py3 will hit the archive? allenap did some python3 porting and pushed it upstream
<doko> roaksoax, hopefully never, see https://ftp-master.debian.org/new/twisted_15.5.0-3.html
<cjwatson> roaksoax: I don't think that porting work has been in an upstream release yet; from what I remember it was a bit late for 15.5.0
<doko> 15.5.3 is the current one
<cjwatson> err, no it's not - https://pypi.python.org/pypi/Twisted
<roaksoax> thanks for the updates
<roaksoax> doko: when do you think python3-twisted will be hitting the ubuntu archive?
<roaksoax> doko: we are curretnly working against python3-twisted-experimental
<roaksoax> doko: and we are blocked on it at the same time it not being in Main
<doko> roaksoax, not my priority. please ask free about it
<doko> he works for the maas team ...
<cjwatson> it'll auto-sync once it's through Debian NEW anyhoe
<cjwatson> *anyhow
<doko> sure, that was my intention too
<roaksoax> doko: free works for landscape :)
<doko> oops
<roaksoax> cjwatson: ack! thanks
<roaksoax> any ideas of when that might be ?
#ubuntu-devel 2015-12-10
<pitti> Good morning
<pitti> Laney: oh, one of the armhf nodes still had the regressing lxcfs installed which caused the timeouts with systemctl daemon-reload; downgraded now and retried everything
<Mirv> good morning
<Mirv> pitti: do you know what needs to be done for the transition still?
<pitti> hey Mirv
<pitti> Mirv: we made a lot of progress last night, but I think it now hinges on aptdaemon not working properly with apt 1.1
<Mirv> pitti: ah, the apt transition is still there, ok
<pitti> Mirv: and the whole Qt transition depends on the apt transition
<Mirv> I've kindly asked Kubuntu to not upload a new KDE since that could set as back for another week
<Mirv> right, now I saw the right parts of the backlog
<pitti> xnox: just stumbled over missing "git" on s390; impressive dependency chain :)
<pitti> git needs subversion needs ruby, wow
<pitti> although ruby-defaults and ruby2.2 ought to be there now
<pitti> hm, I can install ruby and ruby-dev on the autopkgtest system, but apparently the buildd can't
<xnox> pitti, Mirv we should have been building kde for s390x in the bootstrap archive.
 * pitti fixes apport for apt 1.1
<apw> doko, i am suddendly seeing build failures (for the kernel) on arm64, i am suspicious that i have a binutils issue: https://launchpadlibrarian.net/229533923/buildlog_ubuntu-xenial-arm64.linux_4.3.0-3.12_BUILDING.txt.gz
<apw> doko, the previous build was identicle souce in arm64 and built just fine
<Mirv> pitti: did mv_o have a chance to look at the aptdaemon failures?
<pitti> I haven't heard anything yet; mvo ^
<pitti> mvo: would be nice to know if that's ignorable for now, or serious enough to block propagation
<mvo> pitti: I did not had a chance, sorry
<mvo> pitti: can you please give me the link again
<pitti> mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/aptdaemon/20151209_192259@/log.gz is the log
<pitti> mvo: i. e. http://autopkgtest.ubuntu.com/packages/a/aptdaemon/xenial/amd64/
<mvo> pitti: its just the cdrom test, so go ahead and promote and we will figure out the reason once there is a bit of time
<pitti> mvo: test_archives_lock (tests.test_lock.LockTest)
<pitti> mvo: error code 100 is "apt error", that doesn't seem to be CD-ROM only?
<pitti> Err:4 copy:/tmp/adt-run.z6d472/build.z7b/aptdaemon-1.1.1+bzr982/tests/repo ./ Packages
<pitti>   Hash Sum mismatch
<pitti> oh, perhaps just that
<pitti> but that seems to happen consistently
<mvo> pitti: hm, right. need to look but in a meeting
<pitti> mvo: at least it looks likely to be a test-side problem
<mvo> pitti: I can reproduce I suspect a test issue because the new apt is stricted and its less easy to fake data
<pitti> mvo: right; ok, so are you ok with force-badtest'ing it and let the new apt land?
<mvo> yes
<pitti> mvo: ack, thanks for the review
 * pitti commits hint
<pitti> meh, this is also a regression: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/u/ubuntu-release-upgrader/20151210_062305@/log.gz
<pitti> apparently with new python-apt
<jamespage> any archive admins around? I need a binary only promotion of libboost-random-dev to main to get ceph 9.2.0 building...
<jamespage> that will pull in libboost-random1.58-dev libboost-random1.58.0
<pitti> jamespage: ah, so these two need to go to main too
<jamespage> pitti, yup
<pitti> jamespage: done
<jamespage> pitti, thankyou!
<pitti> Mirv, xnox: apt and friends are valid candidates now, but still installability errors :(
<Mirv> hmm
<Mirv> pitti: do I parse update_output correctly that it'd claim big installability problems on amd64 too? I don't see problems on my xenial lxc if I enable -proposed, it seems I can install pretty much install + upgrade all of Qt / KDE etc
<pitti> right, not arch specific
<pitti> something in that list is still not built against the new apt
<pitti> or this needs to be hinted, not entirely sure
<Laney> qtdeclarative is not a candidate
<pitti> ah, qtmir-gles tests?
<pitti> indeed, FTBFS against new Qt?
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/q/qtmir-gles/20151210_062159@/log.gz
<pitti> Mirv: ^ ?
<pitti> oh, but apparently against the whole stack, like in the third on http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/xenial/amd64/
<pitti> so, just insufficient build deps
<Mirv> pitti: yes, whole stack
<Laney> probably have the line from yesterday
<Mirv> I guess they should be tightened
<pitti> ok, hint it is, let's not reupload just to tighten build deps
<Mirv> meanwhile I'll file a bug for it
<pitti> hinted
<Mirv> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtdeclarative-opensource-src also shows non-hinted random timeouts with kaccounts-integration
<pitti> Should wait for kaccounts-integration 4:15.08.2-0ubuntu1 test, but forced by pitti
<pitti> Mirv: already hinted
 * Mirv re-learns to read
<pitti> a lot of tech debt when this lands :)
<pitti> Mirv: yeah, sorry, it's not immediately under that line, easy to miss
<LocutusOfBorg1> pitti, syncpackage pbuilder pretty please LP: #1524083
<ubottu> Launchpad bug 1524083 in pbuilder (Ubuntu) "Sync pbuilder 0.221.2 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/1524083
<LocutusOfBorg1> and if you can lp: #1524315
<ubottu> Launchpad bug 1524315 in boinc (Ubuntu) "Sync boinc 7.6.20+dfsg-4 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1524315
<Mirv> pitti: still some but a lot less uninstallable?
<Mirv> (or claimed as such)
<Mirv> apt seems pretty happy about installing those for me, so far
<Mirv> I found unbuilt arm64 plasma-workspace, rebuilding https://launchpad.net/ubuntu/+source/plasma-workspace/4:5.4.3-0ubuntu1/+build/8330580
<Mirv> I triggered a chain of ~30 KDE packages for arm64 before I landed Qt 5.5 since they had been stuck since beginning of November
<Mirv> calligra armhf FTBFS related to the poppler transition? xnox?
<Mirv> xnox: and gdcm not considered
<Mirv> pitti: related to apt, openscap ICE on ppc64el, rebuilding
<mterry> pitti, can I have some help deciphering update-excuses?  I'm trying to get the new gsl to land.  the update_output.txt file indicates there's something going on with cpl-plugin-naco and slgsl.  But I'm not sure what it is
<mterry> Granted, the naco plugin is also held in proposed, because autopkg isn't testing with the latest gsl...
<mterry> Is that a circular loop?  Or did it just test with the old gsl and hasn't been retested yet?
<Mirv> not sure how much it helps, but I managed to get successful builds for ppc64el: openscap lxqt-panel arm64: user-manager systemsettings plasma-framework (next: plasma-desktop) s390x: libqtxdg
<mterry> didrocks, thanks for looking at the s390x MIRs
<didrocks> mterry: yw! there are still 2 to be done
<didrocks> maybe doko or you have time for them?
<doko> yeah, I should have time ...
<didrocks> mterry: also look if they were pre-promoted. Some were without any message on the bug report
<didrocks> doko: ^
<mterry> didrocks, yeah I saw your comments
<didrocks> I trust thus xnox to fix things quickly then :)
<pitti> LocutusOfBorg1: pbuilder synced; for boinc, the debian changelog does not mention the ubuntu changes at all, so doesn't this need merging?
<mapreri> pitti: thanks for pbuilder! â¥
<pitti> mapreri: no worries, thanks to you for making the package syncable, that's fantastic!
<pitti> Mirv: hm, apt uninstallablity is still the same?
<pitti> Mirv: right, the KDE uploads failed on arm64 on several attempts, but why do they block apt?
<Mirv> pitti: I don't know if they block apt, I'm just flexibly interpreting problems on excuses or update_output page to be possibly related to the migration
<pitti> pete-woods: any idea about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-dbusmock/20151210_061403@/log.gz ? I didn't see that in my local test
<Mirv> the calligra armhf is actually an ICE https://launchpadlibrarian.net/229169305/buildlog_ubuntu-xenial-armhf.calligra_1%3A2.9.7-0ubuntu8_BUILDING.txt.gz so I guess it could be retried. calligra is among else listed in the trying easy from easyhinter portion of update_output.
<pitti> meh, and poppler is also part of that transition
<pitti> and rather old
<pitti> it seems folks have become very sloppy with actually finishing what they start :(
<pitti> mterry: so update_excuses says that the new gsl breaks cpl-plugin-naco indeed
<pitti> Mirv: so it seems it depends on the new gsl but doesn't declare that
<mterry> pitti, I think that's a lie?
<mterry> pitti, it's hard because they changed SONAME but not package name
<Laney> who's become sloppy?
<Laney> poppler got dragged back from almost finished by s390x
<Laney> and was entangled into the parallel qt and apt transitions
<mterry> pitti, right now gsl being stuck in proposed is making a lot of broken packages (because they build against proposed SONAME, land in release, and expect that same SONAME)
<pitti> mterry: no, not a lie, the new gsl is indeed not installable with the old naco
<mterry> pitti, right, but the naco in proposed that it does work with is being stuck for bogus reasons (it was tested against release pocket version of gsl)
<pitti> so, let's try to test the proposed naco against the proposed gsl
<mterry> pitti, exactly
<pitti> mterry: yes, as I said -- it doesn't depend on the -proposed gsl, so it doesn't get tested against it
<mterry> pitti, right I get that logic.  That's why I'm coming to you for manual futzing  :)
<pitti> mterry: started now; if that succeeds, it should unblock naco and thus gsl
<mterry> pitti, Ubuntu got a botched version of the debian transition for gsl
<mterry> pitti, awesome thanks
<pitti> ah, that's why
<pitti> mterry: so we aren't hiding a soname change without package rename with this, but we fix it?
<mterry> pitti, that's the idea (2.0 had package name transition, 2.1 bumped soname to match -- but in debian, 2.0 never hit testing / rdeps didn't seem to adjust for it until 2.1)
<mterry> pitti, but in Ubuntu, we had a delta for 2.0
<pete-woods> pitti: I've seen that before when you run the tests individually (e.g. ./tests/foo.py)
<mterry> pitti, so we didn't get 2.1 in a timely fashion, but we got all of Debian's rdep changes to require >=2.0
<pete-woods> I guess there's some magic setup in the main setup.py that registers a mainloop or something
<mterry> pitti, (we could fix this in Ubuntu by adding lots of deltas on >=2.1, but I figured it was easier to accept one time pain than that)
<pitti> mterry: passed now, that's better
<mterry> pitti, yay
<mterry> pitti, something seems weird about that migration logic though -- new naco passed its autopkg test with new gsl.  But we blocked both new packages because naco didn't pass with old gsl -- why would we care there?  (I get why it was tested with old gsl, but seems like we should ignore that specific test result when considering gsl promotion)
<pitti> mterry: because neither package can be promoted individually, and since the new naco doesn't dependd on the new gsl it's not attempted to be promoted as a group
<pitti> mterry: that "botched transition/missing dependency" is a case for manual promotion/review indeed; not sure if that can be formalized
<mterry> pitti, sure.  But the migration script has enough information here to know that it ought to treat them as a group.  But yeah, maybe this case doesn't come up except in broken cases
<pitti> mterry: right, it happens seldomly only; normally dependencies (particular for library transitions) DTRT
<mterry> pitti, well thanks for setting this one straight -- this was an annoying transition
<pitti> mterry: thanks for grinding through it :)
<mapreri> in ubuntu this worked, can somebody try a retry? https://launchpad.net/ubuntu/+source/cowdancer/0.75/+build/8254960
<mapreri> s/ubuntu/debian/, clearly....
<mapreri> pitti: â
<pitti> mapreri: kicked
<mapreri> thx
<Mirv> ok plasma-desktop is building for arm64 too now
<mapreri> the launchpad build farm is so scary nowadays, you upload a thing, 2 seconds later is already building
<pitti> mapreri: +1 :)
<pitti> and there's lots of capacity too (for most arches)
<mapreri> I recall the times where for a ppa build you had to wait nearly day in the worst case
<mapreri> a retry of a failed ppa build, that is
<mapreri> ok, failed again, anyway
<mapreri> "* '/' is not mounted, something is wrong with the system or the code" â meh
<flexiondotorg> didrocks, Thanks for updating plymouth for Ubuntu MATE. Much appreciated :-)
<dobey> pitti, Mirv: what's up with proposed migration btw? i see stuff as "valid candidate" on excuses for some time now, but still not migrated. is it just incredibly slow atm?
<pitti> dobey: no, but it still renders stuff uninstallable
<pitti> dobey: that's "phase 2" of p-m, on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<dobey> oh, hmm :-/
<pitti> apt+poppler+three dozen Qt packages, some KDE interspersed, yummy ;/
<pitti> mterry: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cpl-plugin-naco \o/
<pitti> mterry: it's  being promoted
<mterry> pitti, heh, great
<pitti> mterry: hm, but not http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsl itself yet
<mterry> pitti, update_output.txt also mentioned slang-gsl (from slgsl)
<mterry> pitti, but I wasn't sure why there
<pitti> mterry: that's already promoted
<pitti> mterry: so maybe that needs another rebuild against the new gsl?
<dobey> pitti: yeah, i'm mostly concerned about ubuntuone-credentials at the moment. i guess it's just in an unlucky position, dependency-wise
<mterry> pitti, no the promoted version should be built against new one (it snuck in because it didn't have autopkgtests and this was a silent transition)
<dobey> oh, and i guess it just made it through. whee :)
<mterry> pitti, wait...
<mterry> pitti, no..  it's building against some ancient gsl version (looking at build log)
<mterry> but this was a couple days ago
<LocutusOfBorg1> [15:12:23] <pitti> LocutusOfBorg1: pbuilder synced; for boinc, the debian changelog does not mention the ubuntu changes at all, so doesn't this need merging?
<LocutusOfBorg1> it does
<LocutusOfBorg1> http://metadata.ftp-master.debian.org/changelogs/main/b/boinc/unstable_changelog
<pitti> https://launchpad.net/ubuntu/+source/qtbase-opensource-src/+publishinghistory !
<pitti> Mirv, Laney, xnox ^
<LocutusOfBorg1> just on a older entry :)
<pitti> and apt too
<pitti> yippie!
<Laney> pitti: what changed?
<seb128> pitti, how did that happen?
<seb128> britney got slippering fingers? ;-)
 * pitti watches two metric tons of packages land in xenial
<pitti> finally enough ignored test regressions and the arm64 rebuilds from Mirv
<seb128> wasn't s390 blocking things as well?
<pitti> seb128: xnox was busy :)
<seb128> no
<seb128> he's sitting at the table doing "wth" with Laney
<pitti> now we just need to get out of the Haskhell and then -proposed should become halfway manageable again
<Laney> we thought it was still far off
<pitti> seb128: well, I wasn't aware of any remaining blockers, what was left?
<pitti> this morning we were at qtmir-gles and some leftover arm64 FTBFS
<LocutusOfBorg1> FWIW I uploaded ghc-testsuite a few hours ago
<seb128> xnox though that s390 had libreoffice depending on poppler triggered kde things
<cjwatson> I'm gradually working my way up the Haskell stack
<LocutusOfBorg1> seb128, can I ask you a really difficult question? the problem is your keyutils sync. it didn't went to -release, because it didn't build everywhere. Now a package depending on it, is failing to build from source where it is built, and building correctly where it failed (because the older one was picked). Since nothing in the code should have changed, I'm lost, maybe you can consider disabling again the testsuite?
<pitti> cjwatson: ah, thanks; is that mostly doing build retries in mostly the right order?
<seb128> LocutusOfBorg1, somebody should fix it
<cjwatson> pitti: partly, some manual rebuilds, and there are some bits still broken in Debian
<seb128> LocutusOfBorg1, that's not a difficult question
<LocutusOfBorg1> seb128, I lost half the day without any clue
<Mirv> pitti: !!!
<LocutusOfBorg1> but disabling the testsuite again should be the best fix
<LocutusOfBorg1> do you think you can sponsor it?
 * Mirv hugs pitti xnox Laney mterry + everyone
 * pitti hugs Mirv back
<mterry> :)
<LocutusOfBorg1> seb128, https://launchpadlibrarian.net/187477970/keyutils_1.5.9-5_1.5.9-5ubuntu1.diff.gz something like that
<pitti> mÃªme pas mal !
<Laney> britney traded uninstallables
<pitti> Laney: on s390?
<cjwatson> It'll do that
<Mirv> sil2100 ^
<sil2100> Is it DONE?
<sil2100> Did it happen?!
<cjwatson> In the sense that unity8 is about to be uninstallable on xenial/armhf, yes :P
<Laney> :)
<seb128> cross arch trading?
<cjwatson> Yes
<sil2100> \o/
<pitti> uh, the "Newly uninstallable packages in testing"?
<seb128> :-(
<pitti> that's a loot
<seb128> "fun"
<geofft> hey, would someone who can see private bugs mind summarizing #723515? it's mentioned in libhugetlbfs's debian/rules
<pitti> I didn't know that britney allowed that kind of trading
<geofft> and I'm wondering if that can be dropped
<seb128> is it supposed to?
<seb128> or is that a bug?
<cjwatson> it's a misfeature
<Mirv> hmm
<cjwatson> actually, it's *supposed* to check per-arch
<cjwatson>                 # if the uninstallability counter is worse than before, break the loop
<cjwatson>                 if ((item.architecture != 'source' and arch not in new_arches) or \
<cjwatson>                     (arch not in break_arches)) and len(nuninst[arch]) > len(nuninst_comp[arch]):
<cjwatson>                     better = False
<cjwatson>                     break
<cjwatson> maybe easy hints are different
<cjwatson> I think they may be :(
<cjwatson> see is_nuninst_asgood_generous
<Mirv> so ubuntu-ui-toolkit is stuck due to s390x issues, which makes the phone world not happy yet and which was the interesting trade done
<pitti> mdeslaur: playing notify bot, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5 causes a lot of regressions, so it's stuck; what's worse is that they all look different :(
<cjwatson> looks like https://launchpad.net/ubuntu/+source/ubuntu-app-launch/0.5+15.10.20150817-0ubuntu1/+build/8382760, but is that really just "fails when rebuilt with current glib" or similar?
<pitti> coreycb: FYI, new python-oslo.log needs a bunch of universe b-deps so it doesn't build: https://launchpad.net/ubuntu/+source/python-oslo.log/2.0.0-1ubuntu1/+build/8370838
<coreycb> pitti, those depends should be in main.  i've not been able to figure out why they're stuck in proposed though.
<cjwatson> I think u-a-l probably wants something like http://paste.ubuntu.com/13897054/
<Mirv> xnox: ubuntu-app-launch ftbfs on s390x due to warning treated as error. that's a pre-requirent for building autopilot which is one of the blockers keeping ubuntu-ui-toolkit in -proposed
<cjwatson> Mirv: ^-
<pitti> coreycb: uh, indeed
<Mirv> cjwatson: right, I read just after pressing enter
<coreycb> pitti, like this one, it builds ok but stuck in proposed: https://launchpad.net/ubuntu/+source/python-oslo.utils
<pitti> coreycb: sorry, they are uninstallable, not in universe
 * cjwatson tries it on amd64
<pitti> coreycb: https://launchpadlibrarian.net/228297733/buildlog_ubuntu-xenial-amd64.python-oslo.log_2.0.0-1ubuntu1_BUILDING.txt.gz
<pitti> # apt-get build-dep python-oslo.log
<pitti> : Build-Depends-Indep dependency for python-oslo.log cannot be satisfied because candidate version of package python-oslo.serialization can't satisfy version requirements
<pitti> coreycb: ah, it has python-oslo.serialization (>= 1.10.0), but only 1.9.0-2 is available
<pitti> coreycb: 1.9.02 is in debian unstable, 2.0.0-1 is in experimental
<pitti> coreycb: did you merge the others from experimental too? i. e. shoudl the exp version be synced?
<coreycb> pitti, I think the new oslo.serialization is stuck in proposed.  I think the real blocker starts with oslo.utils (see link above)
<coreycb> pitti, oslo.utils is building ok but stuck in proposed and I don't see any update excuses issues
<pitti> coreycb: hm, but builds are done against -proposed
<coreycb> pitti, odd
<pitti> coreycb: I'll just retry again, it seems they all interlock on each other then
<coreycb> pitti, yes they are, thanks
<pitti> ah right, o-serialization is also depwait
<pitti> coreycb: btw, please document ubuntu changes in changelogs; "upload to xenial" is empty contents
<pitti> (as that's quite clear from the other parts of the changelog already)
<pitti> and there have been no previous ubuntu changes
<coreycb> pitti, ok. yeah that was a weird situation where it could have been a sync but hadn't yet been uploaded to experimental.
<cjwatson> Mirv: yep, same failure on amd64
<pitti> this makes it hard to see what we changed, what bug refs are, etc.
<pitti> coreycb: oh, ok; please use ~fakesync or ~build1 or something then
<coreycb> pitti, ok
<pitti> hm, reubild didn't help
<didrocks> flexiondotorg: yw! :)
<pitti> coreycb: so https://launchpad.net/ubuntu/+source/python-oslo.utils/3.0.0-1ubuntu1/+build/8370376 builds python-oslo.utils, but apt-cache policy python-oslo.utils doesn't show it (in -proposed); WTH
<juliank> mvo and/or anyone who cares: I'm right that you'd like to have stars in gnome-software when switching to it, right? hughsie thought about removing star ratings, I wrote that I think you still want it
<pitti> it's like someone removed the binary
<pitti> it's not in the binNEW queue
<coreycb> pitti, hmm, fwiw I may be hitting the same issues with the cloud archive staging ppa
<juliank> Oh, APT 1.1 has passed proposed :)
<pitti> https://launchpad.net/ubuntu/xenial/amd64/python-oslo.utils/3.0.0-1ubuntu1 - Status: superseded
<pitti> cjwatson: ^ any idea about that?
<pitti> cjwatson: is that from binary package removal or so?
<pitti> the binaries clearly have been built, are not in binNEW, but are missing from the archive (http://paste.ubuntu.com/13897353/)
<cjwatson> I'll look in a minute, I just Ctrl-q'ed my browser by mistake :P
<pitti> cjwatson: uh, I hope you have tab restoration enabled
<cjwatson> sure do
<cjwatson> pitti: I think that was possibly double-override-bug - have copied back in
<pitti> cjwatson: cheers
<cjwatson> Mirv,tedg,mterry: any chance we could please get https://code.launchpad.net/~mterry/ubuntu-app-launch/fix-ftbfs/+merge/279322 landed, perhaps in isolation so that we can get past this cluster of problems?
<tedg> Oh, sure, I didn't realize it was blocking anything.
<tedg> Got a couple meetings and then I can do it after that.
<cjwatson> thanks
<seb128> juliank, thanks for the rating comment
<seb128> juliank, do they want to replace it with something else?
<juliank> seb128: I'm not sure what it was used for, I don't think they had rating data. But he'll keep the widget in now, and rely on plugins to do the right thing.
<seb128> k
<juliank> seb128: hughsie now added stuff like "available in your language" "integrated into your desktop" "has documentation"
<juliank> I still think stars may be useful, though
<seb128> yeah
<seb128> rating&reviews are useful
<seb128> and every other platform have those
<seb128> it's a bit weird they remove that
<mvo> juliank: yeah, I think we want ratings&reviews, there is even a git branch iirc by robert ancil
<juliank> Yes
<juliank> https://git.gnome.org/browse/gnome-software/log/?h=wip/rancell/ubuntu-ratings
<Mirv> tedg cjwatson: I can put it building into a silo
<cjwatson> Mirv: that sounds like a good plan
<seb128> LocutusOfBorg1, does https://launchpadlibrarian.net/187477970/keyutils_1.5.9-5_1.5.9-5ubuntu1.diff.gz still apply/would work?
<Mirv> tedg: mterry cjwatson: ok it's building and amd64 + ppc64el already successful, ticket https://requests.ci-train.ubuntu.com/#/ticket/771. please follow up since I'm in a bus already.
<LocutusOfBorg1> seb128, the testsuite is failing, so I presume it works
<LocutusOfBorg1> I can try
<seb128> LocutusOfBorg1, k, thanks
<seb128> those issues don't happen in Debian?
<LocutusOfBorg1> http://paste.ubuntu.com/13898370/
<LocutusOfBorg1> seb128, according to the changelogs between 5 and 8, many different debian kernels have issues
<LocutusOfBorg1> and debian disabled tests in those revisions
<LocutusOfBorg1> so I presume also Debian is broken with some kernel combos
<LocutusOfBorg1> Let's see how my costamagnagianfranco/costamagnagianfranco-ppa behaves in the build
<seb128> hum
<seb128> diff doesn't apply
<LocutusOfBorg1> the one above?
<seb128> I wonder if pastebin screwed new lines or something
<LocutusOfBorg1> damn yes
<LocutusOfBorg1> http://paste.ubuntu.com/13898496/
<LocutusOfBorg1> does this one work?
<LocutusOfBorg1> the problem wasn't pastebin, but that I copy-pasted from vim :)
<seb128> better
<Mirv> cjwatson: ah what I was hoping for before regarding multiple uploads in proposed was that LP would close the bug with the whole changelog leading to the fix, not just the last upload. but I went through the bugs now like bug #1502883 copy-pasting the relevant changelog manually.
<ubottu> bug 1502883 in qtdeclarative-opensource-src (Ubuntu) "Impossible to pull to refresh scopes with Qt 5.5" [Undecided,Fix released] https://launchpad.net/bugs/1502883
<Mirv> but I think I've tried that using -v when building doesn't help there either
<seb128> LocutusOfBorg1, sponsored
<LocutusOfBorg1> thanks!
<LocutusOfBorg1> I uploaded arrayfire a few seconds ago on debian
<LocutusOfBorg1> https://buildd.debian.org/status/package.php?p=arrayfire&suite=unstable
<LocutusOfBorg1> maybe on the next dinstall it will just work!
<LocutusOfBorg1> btw, I drafted a MOTU application https://wiki.ubuntu.com/CostamagnaGianfranco/MOTUApplication
<LocutusOfBorg1> I had many different sponsors ~10 and ~100 uploads sponsored
<LocutusOfBorg1> and they are low just because I maintain a no-delta policy from Debian for my packages :)
<Odd_Bloke> Is UDD being turned on for xenial at some point?
<slangasek> pitti: btw, don't know if you've seen LP: #1524480... the plymouth breaks: are tickling an extant bug in the lubuntu theme package
<ubottu> Launchpad bug 1524480 in lubuntu-artwork (Ubuntu) "package plymouth 0.9.2-3ubuntu2 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/1524480
<slangasek> Odd_Bloke: according to cjwatson's mail to ubuntu-devel, it seems not; I would really prefer to have it turned on, imperfect as it is, given that a git replacement is not on the horizon
<Odd_Bloke> Thanks; I thought that's what I'd read but I couldn't think where I'd seen it to go and check. :p
<seb128> slangasek, hey, do you have an opinion on samba versions for the LTS? or do you know who else might have?
<slangasek> seb128: I do not, sorry
<seb128> k :-/
<pitti> slangasek: ah, will look at that with didrocks tomorrow, thanks
<pitti> slangasek: (dealing with s390 ATM, and EOD, sorry)
<slangasek> pitti: no problem
<didrocks> same here, dealing with google code in student, will look at it tomorrow
<seb128> what's the right way to merge a git branch on launchpad?
<seb128> e.g equivalent of "bzr merge lp:~user/project/branch"
<cjwatson> git remote add CONTRIBUTOR lp:~CONTRIBUTOR/PROJECT; git remote update CONTRIBUTOR; git merge CONTRIBUTOR/BRANCH
<cjwatson> or something like that
<cjwatson> at some point we'd like to add a merge/ ref namespace for all the active merge proposals into your repository, which would make that easier
<cjwatson> (github has a pull/ namespace; similar idea)
<seb128> cjwatson, thanks
<seb128> cjwatson, are mps supposed to be closed if you pull your branch into master and push that?
<cjwatson> seb128: yes
<cjwatson> I did merge detection in ~June
<seb128> merge
<seb128> but not pull/push?
<seb128> https://code.launchpad.net/~seb128/geonames/+git/reviewchanges/+merge/280044
<cjwatson> whatever :)
<seb128> didn't close
<cjwatson> git merges are often fast-forward
<cjwatson> == pull
<seb128> I guess I pushed at the wrong place :-/
<cjwatson> let me check
<seb128> hum, no
<seb128> https://git.launchpad.net/~geonames-dev/geonames/+git/geonames/log/?h=debian
<seb128> has it
<cjwatson> let me check
<seb128> thanks
<cjwatson> BTW you should just use ~seb128/geonames - no need to add a repository name
<seb128> k
<cjwatson> the intent is that the per-user default is suitable for basic patch contribution
<cjwatson> seb128: so I don't know what you did but you didn't merge - I think you rebased or something
<cjwatson> seb128: the commit hashes don't match
<seb128> I did what Laney suggested :p
<seb128> which is basically "clone master, pull my branch, rebase, and push"
<cjwatson> well we can't detect rebases
<cjwatson> if you'd merged we'd have detected that
<seb128> k
<seb128> I need to learn git better
<seb128> thanks ;-)
<cjwatson> if you're going to rebase, push the rebase to your branch first
 * seb128 closes that one manually
<cjwatson> i.e. git push <whatever the name of the remote is> +debian
<cjwatson> (since this is the debian branch)
<cjwatson> if you do that then LP has the information to know that the MP is actually merged
<seb128> k
<doko> directhex, what's the story with the arm64 support in mono?
<xnox_> infinity: is lttng ust broken on arm64? it tries to use CLOCK_MONOTONIC which is not defined...
<xnox_> https://launchpadlibrarian.net/229616606/buildlog_ubuntu-xenial-arm64.ubuntu-app-launch_0.5%2B15.10.20150817-0ubuntu2_BUILDING.txt.gz
<infinity> xnox_: Certainly sounds broken to me.
<cjwatson> something needs to include the appropriate feature test macro in CPPFLAGS, I guess
<xnox_> infinity: cjwatson: https://git.lttng.org/?p=lttng-ust.git;a=commitdiff;h=ca4525b556680256149ead3746b566103e043d8e;hp=f7b16408b00ecce757bdde940853a48534b25edd
<xnox_> somebody things it's great everywhere.
<xnox_> i think i'll revert this check and make it conditional on actually ahving said clock available....
<cjwatson> what
<cjwatson> no
<cjwatson> it just needs the right feature test macro
<xnox_> hm?
<cjwatson> -D_WHATEVER
<cjwatson> TBH, a quick workaround is probably to just have ubuntu-app-launch compile with -D_GNU_SOURCE
<xnox_> oh
<cjwatson> or '#define _POSIX_C_SOURCE 199309L' (or newer)
<cjwatson> u-a-l defines _POSIX_C_SOURCE in a few places already
<cjwatson> so it may even be that's the correct fix - if you're using liburcu perhaps you should be defining FTMs declaring new enough standards
<infinity> Oh, quite.  But curious that the feature guards differ between arches...
<infinity> Perhaps hysterical raisins on older arches where it was always wrong and they didn't want to break backward compat by making it right?
<doko> directhex, looks like you reverted: https://github.com/directhex/mono-1/blob/master/mono/arch/arm64/arm64-codegen.h  pointing to an out-of-tree file. but where is this file supposed to live?
<infinity> xnox: mono 4.2 fails on s390x as well (was fine on Debian), perhaps a -pie thing?
<directhex> doko: the arm64 port is xamarin proprietary code, so it lives in a secret vault for such things Â¬_Â¬
<doko> argh ...
<directhex> doko: no i'm not happy about that state of affairs, i try to moan about it every now & again
<directhex> infinity, xnox for s390x, talk to neale ferguson, neale@sinenomine.net, for mono s390x issues
<infinity> directhex: I'm guessing the issue isn't s390x, but rather that we build with -pie by default on (currently) only s390x.
<infinity> directhex: Hence why it's happy in Debian but not Ubuntu.
<infinity> directhex: But just a guess right now, haven't experimented.
<rharper> cyphermox: did you have any plans to do a merge of tgt for xenial  (1.057 -> 1.0.61 from debian unstable?)
<cyphermox> rharper: it's on the list but not high on it. if you want to do the merge, feel free (and I'm happy to review and sponsor)
<rharper> cyphermox: thanks;  I've got a bug related to tgt under containers that I'm fixing, and noticed the delta;  I'll work a merge and apply a fix to the updated version as well
<cyphermox> for now I'm focusing on things that are either a) haven't been merged in > 365 days or b) blocking a)
<cyphermox> rharper: cool
<rharper> sure; just checking to avoid any duplicate work, sounds like we have a plan
<cyphermox> alright :)
 * mterry hugs pitti
<mterry> pitti, gsl got promoted!  ;)
<rharper> cyphermox: at your leisure, https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1524982
<ubottu> Launchpad bug 1524982 in tgt (Ubuntu) "Please merge tgt 1.0.61-1 (main) from Debian unstable (main)" [Wishlist,Confirmed]
<cyphermox> rharper: ok, reviewing now
<Unit193> LocutusOfBorg1: Sorry, haven't had time to really test vbox's vboxweb, but it looks like it's still missing something to pull the username from.
<smoser> infinity, https://bugs.launchpad.net/curtin/+bug/1524954
<ubottu> Launchpad bug 1524954 in curtin "Curtin error when deploying a maas/juju environment" [Undecided,New]
<smoser> i believe what that is is that grub2-signed needs moving to -updates as grub2 made it through
<smoser> dannf, maybe you can push on that ?
<dannf> slangasek: ^
<slangasek> dannf, smoser: whoops.  sorting
<slangasek> sorry :/
<Unit193> slangasek: Hi.  Did you get a chance to review merge proposals?
<cyphermox> rharper: sponsored
<slangasek> Unit193: I have not, sorry; it's in my queue to look at still
<Unit193> slangasek: There's a couple things that'll need to be updated, but that's broken since we last fixed it.  We've not fixed it due to it likely just getting broken again before approved.  We'll fix that when the time comes though.
<rharper> cyphermox: \o/
<rharper> awesome
<Unit193> sarnold: Welcome back!
<sarnold> thanks Unit193 :)
<xnox> cjwatson, infinity: re-prior conversation http://paste.ubuntu.com/13909472/
<xnox> Laney, ^
#ubuntu-devel 2015-12-11
<cjwatson> xnox: maybe -std=gnu99?
<cjwatson> xnox: i.e. C99 with GNU extensions
<cjwatson> xnox: that seems less likely to have undesirable side-effects here
<cjwatson> slangasek: sounds like https://bugs.launchpad.net/bugs/1524980 is for you
<ubottu> Launchpad bug 1524980 in grub2-signed (Ubuntu) "apt-get removed grub-efi-amd64-signed resulting in boot failure" [Undecided,New]
<xnox> cjwatson, so -stc=c99 was explicitely introduced when porting to new lttng, and at the time we were still on gcc4 and thus on pre-99 standards by default. imho a future self would prefer to not hard-code standards versions, as the default one is now sufficient.
<xnox> (and maybe doko will be less grumpy in the future "drop c99 transition")
<cjwatson> xnox: perhaps.
<cjwatson> xnox: remember dual-landings for vivid though.
<cjwatson> xnox: I think -std=gnu99 might be more practically helpful for that
<xnox> right, yes.
<cjwatson> or -std=gnu11 if that works for vivid
<cjwatson> probably not safe there though
<xnox> no no no no no
<cjwatson> yeah, ABI fun
<psusi> cjwatson, I've finally gotten around to putting together an application for core-devel, think you can endorse?  https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
<slangasek> cjwatson: :/  whatever happened to the idea of driving SRUs with p-m?
<pitti> Good morning
<Unit193> Howdy.
<pitti> robru: I got tons of autopkgtest worker failures because you try to run xenial tests against the overlay PPA, but that does not have xenial indexes
<pitti> robru: so that won't work for you -- can you please only use the overlay for stable releases where it publishes stuff?
<pitti> robru: it seems PPAs don't publish empty indexes in that case
<cody-somerville> mhall119 (or anyone else with necessary permissions): Hi there. My membership expired in ubuntumembers. I would have renewed my membership but I was having problems with SSO (RT #54895). Would you be able to re-enable my membership please? :)
<robru> pitti: hmmm, you can't just make it handle missing index files?
<pitti> robru: no, I don't want to silently hide apt errors
<pitti> robru: you'd get wrong test results for typos, or if the PPA does not have what you expect, etc.
<pitti> robru: I'll improve the error mode that it doesn't serial-kill workers (because they think that's a temporary failure and try again) but instead give you an error log
<robru> pitti: OK I'll have to think of a way to improve the template
<pitti> robru: that, or you actually upload something to the overlay PPA for xenial
<robru> pitti: Hmmmmmmm
<robru> pitti: can you check my emails? There's a weird traceback coming from vivid
<pitti> robru: I will, just need to put some fires out first
<robru> OK
<robru> pitti: let me know if the staging Britney is causing issues, it will trigger every 15 minutes, i can turn it off if you want
<pitti> robru: http://autopkgtest.ubuntu.com/running.shtml has some queued tests for xenial including the xenial overlay PPA; I'll need to delete them
<pitti> robru: and if it sends ongoing requests, they will keep being stuck in a loop
<pitti> robru: honestly, I think uploading a dummy package to the xenial overlay PPA is the nicest solution
<pitti> robru: I guess eventually it'll get real packages anyway, and thus you don't need to care about special cases
<robru> pitti: "eventually" i feel is years away ;-)
<pitti> robru: how about hello 2.10-1~xenial1
<robru> But yeah i would prefer the code not have special cases
<pitti> robru: uh? I had expected from roughly March
<robru> pitti: sure
<robru> pitti: i thought phone will be vivid forever and ever...
<pitti> then these test requests can even stay in the queue
<pitti> robru: no, it can't -- no security support for vivid from January on
<robru> pitti: i understood we had an exception for that.
<robru> pitti: anyway, no matter now. Thanks for copying that package in.
<pitti> robru: ok, so let's do that then? I'll backport hello and put it there, so that it's actually older than xenial and it's not going to get in the way?
<stgraber> pitti: the way we dealt with such things in the past (extras.ubuntu.com) was to binary-copy a package from series-1 to the new series, wait for the publisher to run, then remove it
<stgraber> pitti: that way nothing ever actually builds, you get your new index files and nothing is actually in the repo after it's cleaned up
<pitti> stgraber: oh, PPAs won't clean up the indexes after the series became emtpy?
<stgraber> pitti: nope, they won't
<pitti> ah, good
<pitti> I uploaded hello now
<pitti> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.status_filter=published&field.series_filter=xenial
<stgraber> hmm, what's odd is that xenial seems to have been created a few months ago according to timestamps in http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/dists/xenial/
<pitti> stgraber: well, I checked 10 mins ago and it wasn't there
<pitti> maybe it used to have a package, and it was then removed?
<pitti> as the new hello isn't even published yet
<robru> pitti: oh i was thinking it would be fine with the same version, just binary copy in. Hello isn't seeded so it wouldn't make a difference
<stgraber> well, even if that was the case, the structure seems valid, so not sure why apt would fail on it
<pitti> robru: yeah, true that; but *shrug*, doesn't matter much really
<pitti> stgraber: well, it will now
<pitti> stgraber: but as I said -- these weren't there 10 mins ago
<pitti> oh, wait!
<stgraber> weird, I don't get how fresh files can have timestamps going back a couple of months, unless the publisher is doing something very weird :)
<pitti> http://ppa.launchpad.net/ci-train-staging-area/stable-phone-overlay/ubuntu/dists/xenial/main/source/
<pitti> that was the URL it complained about
<pitti> it's staging-area, not service, sorry
<pitti> robru: so we just need to do that trick for the staging PPA
<stgraber> ah, that makes a lot more sense :)
<robru> Yeah
<pitti> and I'll delete hello again from the prod one
<pitti> Signer has no upload rights to this PPA.
<pitti> meh
<pitti> robru: ^ seems you need to do that for the staging PPA yourself?
<pitti> copy-package -s xenial --to=ppa:ci-train-staging-area/ubuntu/stable-phone-overlay -b hello
<pitti> is what I tried
<robru> Ooh hah, sorry.
<robru> One sec
<robru> pitti: ok, just did the copy, let me know if/when autopkgtest stops exploding
<pitti> robru: ah, at last -- http://ppa.launchpad.net/ci-train-staging-area/stable-phone-overlay/ubuntu/dists/xenial/ exists now
<pitti> infinity: thanks for subversion and git on s390!
<sam_yan> hi
<pitti> $ run-autopkgtest -s xenial -a s390x --trigger libpng/1.2.54-1 libpng  â http://autopkgtest.ubuntu.com/packages/libp/libpng/xenial/s390x/
<pitti> slangasek, xnox ^
<sam_yan> exit
<slangasek> pitti: \o/
<pitti> slangasek: next steps: configure enough workers, requests tests for all packages that are already built and have tests to prime it, and enable in britney
<sam_yan> d
<sam_yan> hi. Does ubuntu overwright the cups
<darkxst> sam_yan, I've not seen an ubuntu cup ;)
<darkxst> hey pitti
<sam_yan> are you sure ?
<sladen> darkxst: http://localhost:631/ on Ubuntu
<darkxst> should I have included /sarcasm/ tags
<darkxst> most likely there are ubuntu specific patches on cups
<sladen> darkxst: I just assumed it naturally...
<dholbach> good morning
<Mirv> pitti: do you know why https://code.launchpad.net/~xnox/click/lp1522608/+merge/279522 hasn't been published to archives yet to unblock the UITK?
<pitti> Mirv: no, I don't -- I suppose someone merged it into trunk, but didn't upload it?
<Mirv> pitti: oh, it seems they're landing to both xenial and vivid overlay so it's now waiting for QA https://requests.ci-train.ubuntu.com/#/ticket/772
<Mirv> hmm, technically cjwatson updated it being "ready for QA" which in train terminology would mean that the xenial part is ready for publishing (if necessary). however, we already missed the morning's image build opportunity so it probably doesn't hurt to wait until QA is up in roughly two hours.
<Unit193> pitti: Any update on the dbus/systemd/policykit problem?
<pitti> Unit193: "the" problem?
<Unit193> Pinged you a couple weeks ago about a major problem when dbus is restarted (yes, not stuff crashing.  One requiring a hard poweroff.)
<pitti> slangasek: FYI, http://autopkgtest.ubuntu.com/packages/a/ is now completely tested; I'm spoonfeeding some more batches
<pitti> (b to k now)
<pitti> Unit193: uh sorry, I don't remember; is there a bug report for this? (always better to keep stuff in a bug than on IRC)
<Unit193> pitti: Yeah, was going to but don't know which one would be the best one to file it for.
 * popey wonders why he's getting this on apt recently... "W: No sandbox user '_apt' on the system, can not drop privileges"
<popey> (on xenial)
<pitti> popey: that's new from apt 1.1; unfortunately it creates a new system user now and complains loudly if it's not there
<popey> ah
<popey> thanks
<pitti> popey: I mostly see it in schroots, as that copies the host's passwd
<pitti> popey: is that happening on your host system? because apt should have created that user on upgrade
<pitti> $ getent passwd _apt
<pitti> _apt:x:131:65534::/nonexistent:/bin/false
<popey> on my laptop, yes _apt:x:134:65534::/nonexistent:/bin/false
<darkxst> pitti, it just complains right? not breaks much?
<pitti> no, just the warning
<pitti> and you don't get teh privilege dropping
<popey> hm, now it doesn't complain
<popey> maybe I didn't update for a while
<popey> sorry for the noise
<darkxst> pitti, so long as it doesnt break all my schroots!
<ginggs> hi, could the s390x build of petsc be removed please? it was caught up with the suitesparse/qt transition - i think it will be uninstallable now because the new suitesparse is now through to release
<ginggs> LocutusOfBorg1: hi, are you planning to look at merging llvm-toolchain-3.7?
<juliank> pitti: It's not unfortunate, it's security :)
 * juliank also wanted to add seccomp sandboxing, but did not manage to do so (yet)
<juliank> I have some plans that might allow us to get rid of _apt for 1.2 or later, though
<pitti> juliank: oh, the "unfortunate" part that I meant was "relies on dynamic system user instead of using a static one"
<pitti> juliank: dropping privs is doubleplusgood for sure!
<juliank> pitti: Well, an existing static user would not be as safe, there are already other packages using them. That said, you can configure that, for example setting APT::Sandbox::User "daemon" in an apt.conf snippet
<juliank> systemd also uses dynamic users, though, and surprisingly nobody complained about that
<xnox> Mirv, pitti - re:click i believe cjwatson was landing it early hours this morning (e.g. merged things and prepared a silo)
<xnox> pitti, you rock!
<Mirv> xnox: yes, prepared a silo but it's not yet published
<Mirv> xnox: however as it'd dual landing and it's in QA queue, I asked QA to prioritize it
<Mirv> it seems it's under testing now
<rbasak> Getting reports of grub2-signed being removed because it was not SRU'd in sync with grub2.
<rbasak> Looks like there was a four hour window but fixed now.
<rbasak> s/Getting reports/Got two reports/
<__marco> Hello. Sorry to write here, but there is a bug report that I care that is stagnant. It would be a dream if it could be solved before the release of 16.04
<__marco> https://bugs.launchpad.net/ubuntu/+source/vde2/+bug/776818
<ubottu> Launchpad bug 776818 in vde2 (Ubuntu) "[MIR] vde2" [Undecided,Incomplete]
<mhall119> cody-somerville: do you still need me to re-add you to Members?
<rbasak> __marco: has any of the security issues raised been fixed upstream yet?
<LocutusOfBorg1> ginggs, https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.7/+bug/1525122
<ubottu> Launchpad bug 1525122 in llvm-toolchain-3.7 (Ubuntu) "please merge llvm-toolchain-3.7 from Debian" [Undecided,New]
<ginggs> LocutusOfBorg1: ah nice! i'll sponsor that for you :)  does i386 build now?
<LocutusOfBorg1> nope
<LocutusOfBorg1> the problem about i686 I guess
<LocutusOfBorg1> BTW FYI I drafted a MOTU application https://wiki.ubuntu.com/CostamagnaGianfranco/MOTUApplication
<LocutusOfBorg1> you, pitti laney, seb128 dholbach have been my sponsor since almost two years now :)
<seb128> LocutusOfBorg1, I can add something to the page for you
<dholbach> LocutusOfBorg1: will look into it :)
<dholbach> ... with pleasure
<LocutusOfBorg1> thanks! :)
<LocutusOfBorg1> actually I applied for DD just because it was easier to become an Ubuntu developer :)
<LocutusOfBorg1> seb128, for i686 I plan to have a look as soon as I fix virtualbox and something else
<seb128> k
<LocutusOfBorg1> oops s/seb128/ginggs
<seb128> I was wondering
<seb128> btw seems like keyutils built!
<LocutusOfBorg1> yes, and arrayfire built correctly almost everywhere, except for i386, where a similar issue is found
<LocutusOfBorg1> I have the same issue on both packages lol :)
 * LocutusOfBorg1 is wondering if there is a quick way to change the wiki page from https://wiki.ubuntu.com/CostamagnaGianfranco/MOTUApplication to https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication
<ginggs> LocutusOfBorg1: i686, great.  will gladly endorse your motu application
<LocutusOfBorg1> well, if possible please use this one https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication#preview
<seb128> k
<__marco> rbasak: please, read the comment #22. It is not necessary to include the whole vde to support it, a relative little library is enougth
<__marco> I am waiting for any objection to fix it
<cyphermox> good morning!
<mdeslaur> hi cyphermox
<cyphermox> hey mdeslaur
<cyphermox> I've just been merging your usb-creator code and I gave it a quick run ;)
<mdeslaur> cyphermox: ah, cool
<cyphermox> I'll upload 0.3.0 in a few minutes I think
<ximion> Laney: you should update your dep11-generator instance at Ubuntu to the latest Git master - I just landed some patches which have a really high impact on the amount of processed components
<pitti> LocutusOfBorg1: oh, my pleasure! will write a blurb
<pitti> didrocks: FYI, https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=30800f87
<pitti> didrocks: I'll do a full integration test on production and document it, but this should now have everything you need?
<tedg> xnox: Did you merge mterry's ftbfs branch into your branch?
<tedg> xnox: Seems like Jenkins thinks it's not there.
<tedg> xnox: Thanks BTW, it was on my TODO to figure out what was up with lttng this morning.
<xnox> tedg, i set the branch as pre-requisite....
<xnox> both of these things are in the ubuntu archive already, as they are blocking to have ubuntu-desktop & ubuntu-touch installable... please sort out branches/jenkinsii/landings.
<xnox> and e.g. have been contributing to the large delay in landing the lot of migrations which transitively entangled a lot of things.
<tedg> xnox: You need to merge it as well I think, I don't know that Jenkins pre-lands dependencies. Only helps in the diff view.
<tedg> xnox: Cool, if that's the case I'll delay some on the silo and get some other MRs in there.
<didrocks> pitti: looks good to me, I guess that will work with test-git="depot_url.git branch" from my tests, but I'll keep you posted :)
<pitti> 'myproj {"test-git": "git://anonscm.debian.org/collab-maint/python-dbusmock.git"}'
<pitti> didrocks: ^ that's what I'm currently running
<didrocks> pitti: yeah, that checkout master though, sometimes I'm checking some branch
<didrocks> but I'll give it a try with this
<didrocks> out*
<xnox> tedg, ok merged. and pushed. if it still doesn't work, then i don't know....
<pitti> didrocks: ah, good point; yes, that needs another argument indeed, I'll extend it accordingly
<didrocks> pitti: thx!
<pitti> didrocks: perhaps "git://anonscm.debian.org/collab-maint/python-dbusmock.git mybranchname" ?
<pitti> didrocks: meh, doesn't quite work yet, git clone is hanging on firewall issues; /me sees how to squeeze the proxy in there
<didrocks> pitti: yeah, that's what I mean, I think that works
<pitti> didrocks: so that will be split() and if there's a second argument it will become the --branch argument
<buxy> hi,
<buxy> any idea who handles Merge-o-matic?
<buxy> The mom@ubuntu.com email address bounces with   mail_mom@casey.canonical.com
<buxy>     Unrouteable address
<didrocks> pitti: yeah, and then, I'll add to me wrapper the github particular support (splitting from url, so that I can lazely copy/paste)
<buxy> cjwatson: ^ do you know?
<pitti> didrocks: blergh, the proxy also doesn't allow access to anonscm.debian.org  .. which branch do you need in particular?
<didrocks> pitti: something like git@github.com:ubuntu/ubuntu-make.git
<didrocks> or the https equivalent:
<didrocks> https://github.com/ubuntu/ubuntu-make.git
<pitti> Received HTTP code 403 from proxy after CONNECT
<didrocks> arghâ¦
<pitti> that smells like an RT now, not sure what else I can do :(
<pitti> didrocks: perhaps you can set up an automatic Launchpad mirror?
<didrocks> pitti: going to be difficult for contributors' branch
<didrocks> like everything != master
<didrocks> or any PR
<pitti> didrocks: aren't you running this in the data center too? do you use the proxy?
<didrocks> (there is already a launchpad mirror, but it's taking long sometimes to sync, and I'm talking about master)
<didrocks> pitti: yeah, I do use it, on s-jenkins
<didrocks> and have access to it
<pitti> didrocks: ok, perhaps squid.internal has different policies depending on who requests it
<didrocks> pitti: yeah, that's kind of weird. I do have access to dockerhub as well, do you from there?
<pitti> didrocks: so I suggest you put a clone on Launchpad for now for testing, and I'll file an RT for allowing github
<pitti> didrocks: git clone URL?
<didrocks> pitti: is there any git <-> git cloning in launchpad?
<didrocks> I was only knowing about a git <-> bzr one
<didrocks> like the one I set up moons ago: https://code.launchpad.net/~ubuntu-desktop/ubuntu-make/master
<pitti> well, we could start with that too :)
<didrocks> pitti: good for testing, indeed, (but not enough for switching though)
<pitti> didrocks: right, but would unblock you from dep8-ifying the tests
<didrocks> indeed
<didrocks> pitti: but do you mind testing access to dockerhub?
<pitti> didrocks: do you have a clone url?
<didrocks> pitti: if you want to pull via docker, you can try: docker pull didrocks/docker-umake-manual
<didrocks> (I think it's just using some https://hub.docker.com/â¦)
<pitti> ah, that's not git?
 * pitti doesn't have docker installed there
<didrocks> pitti: no, it's not using git for pulling images
<pitti> nope, same thing
<didrocks> pitti: I'm afraid then that all access to 3rd parties for real large tests would be the sameâ¦
<pitti> I'm a bit confused, this seems to work reasonably well from scalingstack
<pitti> but apparenlty not from prodstack
<didrocks> yeah, can be different fiwall rules?
<didrocks> firewall*
<pitti> perhaps I need to do the git clone on the testbed then, instead of the controller
<didrocks> ohâ¦
<pitti> didrocks: it all goes via proxy either way, so I rather suspect different policies on the squid side
<didrocks> yeah
<pitti> )#*$J#(J#*F(
<didrocks> so many not a problem from the testbed, which would be good :)
<pitti> so much for a small Friday afternoon hack
<didrocks> pitti: don't tell me, feeling the same with some plymouthingy
<Mirv> ok xenial should be now fixed, UITK + url-dispatcher + ubuntu-app-launch just migrated to release pocket thanks to fixed click
<pitti> didrocks: ok, http://autopkgtest.ubuntu.com/running.shtml#pkg-myproj is running against a branch on LP
<pitti> didrocks: but it seems I need to build this five times as complicated with a different approach now
<pitti> didrocks: so, should be good enough for developing your tests while that happens (or the RT gets done)
<pitti> didrocks: ok, confirmed that it all works fine from scalingstack
<pitti> didrocks: so, there's a solution which can be implemented quickly
<didrocks> pitti: sweet!
<didrocks> thanks pitti :)
<mdeslaur> infinity: hi! how do you suggest I fix the phpunit/php-codecoverage circular dependencies/build dependencies causing the php-codecoverage package to ftbfs?
<mdeslaur> infinity: I'm sure you have a better idea than any hack I'm about to try
<lamont> sometime 2-3 weeks ago, my xenial desktop stopped having audio in hangouts...  any clues?
<doko> LocutusOfBorg1, File "/Â«PKGBUILDDIRÂ»/lldb/test/lldbtest.py", line 868, in getPlatform
<doko>     platform = lldb.DBG.GetSelectedPlatform().GetTriple().split('-')[2]
<doko> AttributeError: 'NoneType' object has no attribute 'split'
<doko> Config=i686-gcc-5
<doko> I doubt that dropping the i686 fix had the expected result
<infinity> mdeslaur: We bootstrap it in the bootstrap repo.
<mdeslaur> infinity: oh. could you do that? or someone else in foundations?
<mdeslaur> infinity: pretty please?
<infinity> mdeslaur: It'll get done.  I need to update some chroots first.
<infinity> mdeslaur: Which I think I'll do this morning.
<mdeslaur> infinity: awesome, thanks
<mdeslaur> infinity: I think that's the first step in the massive php failures in -proposed
<LocutusOfBorg1> doko, even not dropping didn't have the expected result
<doko> LocutusOfBorg1, are you working on this?
<LocutusOfBorg1> doko, not now, it isn't a regression and I have more serious bugs to look at
<doko> LocutusOfBorg1, interesting understanding about a regression
<LocutusOfBorg1> well, llvm 3.7 was never built on i386
<LocutusOfBorg1> so my "not a regression" actually means, "it will migrate to release anyway"
<Saviq> can someone please restart http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/armhf/ with unity8 trigger
<Saviq> the failure there was actually caused by a packagekit install fail
<Saviq> s/packagekit/policykit/
<infinity> Saviq: Sure.
<Saviq> thanks, I'll ping the guys responsible to have a look at why is this unreliable
#ubuntu-devel 2015-12-12
<decci> Hello Guys
<decci> All I usually do is dh_make -f ../sa_source.tar.gz -p sas_8.2.0 && debian/rules clean && debian/rules build && debian/rules binary for creating packages for particular source code.
<decci> Now I am working on .DEB package which will install all these packages in sequence.Can anyone suggest
<decci> hi
<octoquad> Filed this for clementine: https://bugs.launchpad.net/ubuntu/+source/clementine/+bug/1525490
<ubottu> Launchpad bug 1525490 in clementine (Ubuntu) "Fails to start due to empty libechonest.2.1 package" [Undecided,New]
#ubuntu-devel 2015-12-13
<tsimonq2> just a note, doing a Kubuntu 14.04 install and I really like how the installer shows a progress bar on the bottom even while you are still selecting items.
<tsimonq2> just an idea
<transhuman_> prob #1: this is getting a little annoying. One major hassle has lead to discovery of two others. My ubuntu virtualized systems (happens on debian too) loose the passwords that I have assigned to accounts) recovery is necessary, it then works for a while and then it looses the passwords, seems to happen on boot. I know I have the passwords right (single finger typing with copying passwords from a paper works for a while then it "looses" them)
<transhuman_> problem 2: ubuntu keyboard assist is missing function keys (totally absent) Doesn't seem to be a work around
<transhuman_> problem 3: vmware's fling embedded console doesnt allow the passing of function keys from debian desktop to vmware guest console (fling is from vmware labs)
<dobey> have you filed bugs?
<transhuman_> not yet wondering if its already been reported somewhere( I have looked but haven't found anything similar
<transhuman_> )
<transhuman_> looking for a work around with the keyboard problem ( I will mirror the vm and cause it to happen see if i can recover source of bit error
<transhuman_> that make passwords not work
<dobey> you'd ahve to look at the appropriate bug trackers if you want to search.
<transhuman_> happens on multiple instances over many years by the way debian too I just finally got sick of it enough to report it
<dobey> th vmware issue at least you will likely have to report to vmware support
<dobey> well, irc is not a bug reporting site. please file bug reports :)
<tsimonq2> +1
<goddard> anyone familar with how to generate a linux-image-extra package for debian based systems from a mainline kernel?
<ari-tczew> Noskcaj: please fix a debdiff for bug 1524490 and I'm happy to upload it for you. I hope bluesabre is aware about that merge.
<ubottu> bug 1524490 in blueman (Ubuntu) "Merge 2.0.1-1 from debian" [Wishlist,Incomplete] https://launchpad.net/bugs/1524490
<amoghe> Could someone give me pointers on how to build a core rootfs (as seen here: https://wiki.ubuntu.com/Core) from scratch ?
<ari-tczew> flexiondotorg: did you consider ever to apply for Package Set @Mate? https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage
#ubuntu-devel 2016-12-12
<DarinMiller> any chance I can help package Remmina 1.2 in the Zesty release cycle?  I do not know much about packaging I usually only have time to learn on weekends.  But if someone wil guide me I will be happy to do the work.
<jbicha> DarinMiller: I believe you'd need a newer freerdp first
<jbicha> ooh, it's in Debian's new queue https://bugs.debian.org/814676
<ubottu> Debian bug 814676 in src:freerdp "freerdp: please update to latest upstream head(?)" [Important,Open]
<Son_Goku> it's not going to happen unless Debian is okay with breaking a few other packages
<Son_Goku> we had to make a rather difficult choice in Fedora and actually break guacamole because Remmina needs FreeRDP 2.0
<jbicha> Son_Goku: it looks like Debian is packaging it as 'freerdp2' in experimental
<Son_Goku> ah yes, because upstream finally made the paths not conflict
<Son_Goku> it's not in experimental yet, though
<pitti> Good morning
<pitti> mapreri: maintaining Testsuite-Triggers manually sounds fine -- dpkg just provides a  sane default
<pitti> tsimonq2: 1647031> ah, thanks
<cpaelzer> good morning pitti
<pitti> hey cpaelzer, wie gehts? gut heimgekommen?
<cpaelzer> pitti: a while ago you had good feedback on the sru review of bug 1546674
<ubottu> bug 1546674 in libvirt (Ubuntu Xenial) "virt-aa-helper Apparmor profile missing rules for name resolution" [Medium,Triaged] https://launchpad.net/bugs/1546674
<cpaelzer> pitti: the new version of the fix is in zesty and now waiting since 11 days for SRU - re-review - not sure how the process works to pick it up again - so *ping*
<cpaelzer> pitti: ja war ja der einfachste Flug fÃ¼r mich (direkt)
<cpaelzer> pitti: 30 Minuten parkhaussucherei, aber im VerhÃ¤ltnis zu den meisten Kollegen ist das ja nichts
<pitti> cpaelzer: ah, will review
<cpaelzer> pitti: thank you
<pitti> cpaelzer: indeed, this now looks so much better
<cpaelzer> pitti: was your way back smooth as well - or any travel-hickups on the way?
<pitti> cpaelzer: no, all worked fine, just took a long time due to 4:30h layover in Madrid
<pitti> but it was fine -- I hacked on apport, and almost forgot the time :)
<pitti> had to run to my gate and was the last one to go through
<cpaelzer> pitti: according to the messages I got US was a bit haunted by some storms and due to that delayed and cancelled connections - so in this case - happy EU trips
<pitti> \o/
<cpaelzer> pitti: work 'til you'll be left behind :-)
<caribou> pitti: let me know if you want me to run stuff on my laptop for LP: #1647031
<ubottu> Launchpad bug 1647031 in systemd (Ubuntu) "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Low,Triaged] https://launchpad.net/bugs/1647031
<pitti> caribou: are you sure you have the exact same problem? this bug has become a mush of "me toos" where everyone experiences something different
<pitti> caribou: like, Anders' bug is that he does not have systemd-resolved.service actually running (apparently)
<pitti> (will follow up on that shortly)
<caribou> pitti: I can de-dup my previous bug if you prefer
<pitti> caribou: yeah, might be better as long as it's unclera
<ginggs> pitti: do you know if there is a size limitation on autopkgtest artifacts?
<pitti> ginggs: not a technical one, but be reasonable; don't have tests spit out multi-megabyte artifacts all the time
<ginggs> pitti: ack
<bigon> are there plans to push libsnap-glib in debian?
<xnox> bigon, maybe willcooke can answer that.
<willcooke> bigon, no concrete plan of action more than "we should" at the moment.  Once it's settled down and matured a bit I think we'll do it then
<bigon> I had to disable the snap plugin in my last gnome-software upload in debian
<willcooke> bigon, best person to speak to is robert_ancell, you want his email address?
<bigon> I have his address somewhere :)
<willcooke> bigon, I might speak to him tonight, so I will find out for sure and let you know, but yeah, do direct to him if you like
<kmadac> Hello guys, I'm new to Ubuntu contribution. I found a bug in package isc-dhcp-client and I would like to propose a fix. I  have read Ubuntu contribution guides, but I'm stucked in pulling sources from bazzar. I'm getting error Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/isc-dhcp-client/". Any ideas what i'm doing wrong?
<Bluefoxicy> when is cmiller waking up :|
<sladen> kmadac: ideally first file a bug report saying what the but is, and how to reproduce it (ie. show that the bug exists)
<sladen> kmadac: then attach the fix as a diff to the bug report (so it doesn't get lost, and is findable by Google)
<sladen> kmadac: then propose the fix, showing that when trying to reproduce the bug using the original instruction, it is no longer possible
<kmadac> sladen: thanks for answer. What do you mean by propose the fix? Diff is the fix, isn't it?
<sladen> kmadac: the diff/patch is how implementation of the proposed fix
<sladen> kmadac: eg. the diff to apply the fix against different versions of the same software will often be slightly different, (eg. changes in line numbers)
<kmadac> sladen: great, should I then wait till someone from ubuntu devs implement the fix?
<kmadac> sladen: or can I send pull/merge request somewhere?
<sladen> kmadac: please file the bug first, so that then you can say $bug is fixed by $proposed_pull_request
<sladen> kmadac: ideally we try and get bug fixes applied by upstream first if possible, so that everyone benefits; not just Ubuntu or Debian users
<sladen> kmadac: the bug report also allows keeping track of what communication with upstreams
<kmadac> sladen: ok I will fill a bug, but can you please elaborate more about proposing pull request? Or can you point me to some documentation how to do it? Is it still done over bazaar as is stated in public documentation, or was it changed?
<sladen> kmadac: http://stackoverflow.com/a/20273376/839696
<sladen> kmadac: (you need the bug number, to link the metadata together for what the proposed fix is)
<kmadac> sladen: thanks :), I'm going to fill the bug report
<Bluefoxicy> I wish goa-daemon wouldn't time out and break evolution
<Bluefoxicy> requiring a manual killall goa-daemon and then a run of /usr/lib/x86_64-linux-gnu/gnome-online-accounts/goa-daemon
<Bluefoxicy> Bill Gates recommended rebooting frequently to avoid problems like this
<cjwatson> kmadac: The Bazaar importer has been mostly decommissioned since it was too unreliable.  There's a Git version in progress but it's not completely done.  In the meantime you're better off simply sending patches.
<cjwatson> I don't think sladen's link is going to help much nowadays.
<cjwatson> (Unless there is an obvious upstream repository that you can propose a merge into.)
<caribou> rbasak: when you have a minute, could you please review my last comment on LP: #1176046 ?
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu) "isc-dhcp dhclient listens on extra random ports" [High,In progress] https://launchpad.net/bugs/1176046
<rbasak> caribou: I don't understand your comment.
<rbasak> "...if isc-dhcp-ddns Breaks/Replaces isc-dhcp and Recommends isc-dhcp-ddns..."
<rbasak> It would Recommend itself?
<rbasak> I don't really follow what Breaks/Replaces would do here.
<rbasak> isc-dhcp-ddns in Xenial supplies /sbin/dhclient with a divert.
<mterry> slangasek: is Foundations willing to look after libsmbios in main?  And if so, can you subscribe ~foundations-bugs to its bugs?  (this is re: MIR bug 1603072)
<ubottu> bug 1603072 in libsmbios (Ubuntu) "[MIR] libsmbios" [Undecided,In progress] https://launchpad.net/bugs/1603072
<attente> hi, would it be possible to backport the bubblewrap package to xenial?
<seb128> attente, hey, backport or SRU? any of those should be possible I think, depending why you need it
<attente> seb128: i'm not sure the distinction tbh, it's needed so that the integration test for the snapcraft jhbuild plugin can pass there
<seb128> do they have a ppa they are using where it could be added?
<attente> seb128: the package doesn't seem to exist there atm, so it would be a new package in universe
<seb128> I guess it's a question for the snappy team
<seb128> like mvo should be able to guide you?
<seb128> or ogra
<attente> ok, thanks seb128, i'll ask there
<seb128> I sort of pinged them
<seb128> so maybe they reply here ;-)
<attente> oh, right :)
<mvo> attente: backport is trivial, just dput the package and target to xenial-backports in the changelog
<mvo> attente: well
<mvo> attente: or file a backport request, depends a little bit if it needs source changes or not
<mvo> attente: see https://wiki.ubuntu.com/UbuntuBackports
<mvo> attente: it should be pretty lightweight
<mvo> attente: sru is a bit more work, you know the drill for this already I think :)
<seb128> mvo, the question is rather from the snappy CI infra side
<seb128> mvo, what env is used for snapcraft integration tests? does that include some ppas or backports?
<mvo> seb128: snappy or snapcraft? snapcraft is a sergiusens question, I would assume they can easily use xenial-backports
<attente> it's snapcraft
<seb128> mvo, sorry, snapcraft indeed, should have bother sergiusens and not you ;-)
<mvo> seb128: np
<attente> i guess it's a backport since the package isn't there at all in xenial
<seb128> sergiusens, ^ can snapcraft integration tests use xenial-backport or a ppa?
<seb128> attente, well, you can SRU a package that was not there, we did it with snapd-xdg-open if you remember ;-)
<seb128> but backport is an easier process
<sergiusens> seb128 attente can adt? Maybe so, or maybe just disable the test for xenial and make your plugin query where it is running on
<seb128> sergiusens, it means you are not using backports or a ppa? would be better to have things working rather than disabled...
<attente> yeah, the integration tests seem to be passing on y and z already, so if we can just get the package on x too, that would be preferable
<sergiusens> seb128 yeah, we are not using backports or PPAs, just xenial-updates
<seb128> k
<attente> should we sru it then?
<seb128> sounds like it
<seb128> or talk to sergiusens about enabling backports
<seb128> or disable the test on xenial...
<seb128> well maybe do that to unblock the landing
<seb128> but then work on getting it SRUed
<seb128> or change to use a tech which is available in xenial ;-)
 * attente didn't hear the last one
<seb128> lol
<xnox> pitti, google-chrome does not like to die, upon logout, under systemd user session with unity7
<xnox> is there any trigger that kills chrome under upstart session? (e.g. does upstart use a bigger hammer, faster?)
<xnox> also nm-applet appears to be "slow" under systemd.
<xnox> it takes me good 10-15seconds for both indicator-network and nm-applet to appear.
<xnox> (fixing the fact that they are duplicates)
<dobey> xnox: chrome doesn't have an upstart job afaik. it's just gnome-session killing things i think, or maybe just when X dies
<dobey> xnox: if nm-applet and indicator-network are both slow to appear, maybe something lower level like communications with network-manager being slow
<xnox> dobey, upon logout everything dies but chrome stays alive, from tty2 i can see that chrome has become a child of the user systemd session and somehow is still alive.
<xnox> given all the rectangular bubbles I see, i think the chrome "extensions/apps" are simply respawning.
<xnox> so something somewhere is not given a chance to kill chrome "properly" e.g. gnome-session/bamf killed without it given a chance to kill chrome, or chrome catching signals and respawning.
<xnox> ack. will debug more.
<dobey> xnox: yeah, it's sounding like an issue with systemd stuff to me, i mean.
<xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649309
<ubottu> Launchpad bug 1649309 in systemd (Ubuntu) "google chrome, is slow to die, upon systemd user session logout" [High,Confirmed]
<slangasek> mterry: foundations-bugs subscribed to libsmbios
<mterry> slangasek: oh thanks!
<bregma> hey tjaalton is there an ETA for x.org 1.19 landing in Zesty?  I have some XMir bugfixes and I want to coordinate work
<tjaalton> bregma: xmir needs to be ported first, and nvidia blobs need to support the new abi before it can land
<tjaalton> bregma: so probably not before mid-january'ish
<tjaalton> bregma: tseliot is out until then, and I'm off for two weeks as well
<bregma> tjaalton, I have a 1.19 port for XMir already, but we need to land in 16.04 ASAP because it's blocking other stuff from landing
<bregma> I can just SRU the patch short-term if a 1.19 landing is not imminent
<xnox> dobey, tedg: what is unity-greeter-session-broadcast and is it needed in the all-snap world? and/or needs a rewrite for the all-snap world?
<tjaalton> bregma: yeah it's not imminent
<tedg> xnox: It handles sending messages from the greeter session to the user session.
<dobey> xnox: no idea
<tedg> xnox: Not sure it needs to be rewritten, but it should be in the U8 snap with the U8 greeter and U8 session.
<tedg> xnox: It'll have to be a system service.
<tjaalton> bregma: should git://git.launchpad.net/~xmir-team/xorg-server/+git/xmir have the latest? or haven't pushed there yet?
<dobey> tjaalton: btw, did the mesa causing gtk+ (aka everything) to crash in zesty-proposed get fixed btw?
<tedg> xnox: We're not entirely sure on the architecture there though, I imagine the greeter will be in the same snap as the session so we won't need any security stuff there.
<tjaalton> dobey: yes
<bregma> tjaalton, I haven't pushed there yet
<tjaalton> bregma: gotcha
<dobey> awesome
<xnox> tedg, the things it does, have no systemd equivalent. e.g. one cannot start a systemd unit on per message (aka equivalent of the upstart-dbus-bridge events)
<tjaalton> dobey: although it's still in proposed because of tests
<xnox> tedg, and all i can see, it triggers url-dispatcher event.
<tedg> xnox: Sure, it'll have to switch to be dbus-activation. So I guess it'll need refactoring, not rewriting.
<xnox> tedg, a system thing that store greeter events and send them to session url-dispatcher make sense. I think it just needs to be done outside of systemd, just over dbus.
<xnox> priviledged thing, that greeter talks to and stores "events" there, and then session which talks to priviledged thing to retrieve and action "events"
<xnox> tedg, ack.
<dobey> tjaalton: that's fine; it was blocking build of some stuff that runs binaries with gdk_init during tests
<tjaalton> ubiquity, yes
<dobey> tjaalton: so hopefully i can build now, and at least "land" a fix or two that we need for unity8 snap
<jbicha> bigon: https://irclogs.ubuntu.com/2016/11/21/%23ubuntu-devel.html#t20:28
<jbicha> (I'd rather not be the Debian maintainer for snapd-glib now)
<bigon> jbicha: ok
<seb128> bdmurray, hey, why did you assign bug #1647020 to our team? it seems a pretty random report without much details
<ubottu> bug 1647020 in gnome-power-manager (Ubuntu) "Brightness resets to full when on/off battery" [Undecided,New] https://launchpad.net/bugs/1647020
<bdmurray> seb128: because its from a canonical employee and seemed like a regression.
<seb128> bdmurray, ok, thanks, I'm going to comment on it but it's more likely a kernel issue than a desktop one
<bdmurray> seb128: okay, thanks for following up
<seb128> yw!
<caribou> rbasak: sorry, I missed your question and, indeed my comment is unclear
<caribou> rbasak: I'll clarify my comment in the bug
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<rbasak> Need one more for quorum.
<fossfreedom> Hi all - David Mohammed here - project lead for Ubuntu Budgie.  Just hoping that someone can have a look over our pull request for lp:ubuntu-cdimage ?
<fossfreedom> https://bugs.launchpad.net/ubuntu-cdimage/+bug/1647862
<ubottu> Launchpad bug 1647862 in Ubuntu CD Images "ubuntu-budgie proposal" [Undecided,New]
<xnox> fossfreedom, have you considered to name this flavour "Bubuntu"?
<xnox> =)
<xnox> ikey would like that =)
<fossfreedom> shudder
<fossfreedom> no thanks!!
<xnox> fossfreedom, hahaha =) fair enough! =)
<xnox> fossfreedom, do you need and will you test i386 image? (btw it does not have uefi support, and e.g. ubuntu.com only advertises amd64 images across the board by default)
<xnox> fossfreedom, official flavours should be teams by default, even if that team has a single person. As it's easier to manage ACL that way. E.g. said team will join ubuntu-devs and e.g. ubuntu core-devs will join the ubuntu-budgie-dev team etc.
<fossfreedom> yep - there seems to be very few testers now who concentrate on i386 - would welcome any help once the ISO's start to be created.
<fossfreedom> I've created a team here: https://launchpad.net/~ubuntubudgie-dev
<xnox> fossfreedom, my question is kind of a devil's advocate - why not go amd64-only?
<xnox> it's only 15 years old.
<fossfreedom> Question really for the Ubuntu community - I know it has been recently floated again to drop i386.
<jbicha> if Budgie goes amd64 only, Ubuntu GNOME might follow
<fossfreedom> mind you - just today I had two people wondering if its possible to install the 386 version.  Answer given was to "try and let me know"
<jbicha> I'm reluctant to have us do something like that if no other flavor is
<cjwatson> fossfreedom: That's partly true, but there are different considerations that apply to adding a new flavour vs. changing existing flavours
<cjwatson> They don't all have to be in sync
<jbicha> supporting both i386 and amd64 is to some extent twice the work when testing iso release milestones
<xnox> fossfreedom, removing an arch/image-type is pain; adding an arch/image-type if there is actual demand is trivial.
<xnox> (ripping band-aid off versus putting one on)
<fossfreedom> generally I soak in water first ... but yeah I know what you mean.
<xnox> cjwatson, is it me, or the ubuntu-cdimage code is littered with lexical order comparison with all the self.config["DIST"] >= "xenial"
<cjwatson> xnox: It's just you.
<xnox> infinity, too ^
<xnox> cjwatson, ok.
<cjwatson> I was cleverer than that :-)
<cjwatson> Look in lib/cdimage/config.py
<cjwatson> Series is a magic thing that can do comparisons by series name but they're actually compared using their index in all_series
<cjwatson> and self.config["DIST"] is a Series
<xnox> nice =) you map them to index first, then compare.
<cjwatson> Saves on a lot of verbiage
<infinity> It's elegant in its perversion.
<infinity> And best not examined too closely.
<fossfreedom> jbicha - thanks for your kind thoughts BTW on my application.
<jbicha> fossfreedom: I think lib/cdimage/tests/test_build.py shoudl be False, True
<fossfreedom> ah - yes - good spot "unsupported" let me update
<jbicha> honestly, I don't know what unsupported means
<fossfreedom> corrected.
<fossfreedom> hmm ... I don't remember "Ubuntu-Moblin-Remix" - what was that?
<fossfreedom> ah - yes - netbook thingy
<bdmurray> rbasak: Could you look at bug 1640823 again? Are you happy with what was most recently uploaded to -proposed?
<ubottu> bug 1640823 in util-linux (Ubuntu Trusty) "[trusty] mount -o loop is limited to 8 loop devices" [Undecided,Fix committed] https://launchpad.net/bugs/1640823
<fossfreedom> xnox re ~ubuntubudgie-dev - I have 'invited' ubuntu-devs to join
<fossfreedom> xnox: re ~ubuntubudgie-dev - I have 'invited' ubuntu-devs to join
<Bluefoxicy> Hooray, cmiller has arrived
<Bluefoxicy> what's the appropriate way to ask for a package upgrade in Zesty?
<Bluefoxicy> Monodevelop 6.1 supports Nuget 3 (finally) (6.2 supports Nuget 3.5, but it's not *stable* yet), and Zesty packages 5.10
#ubuntu-devel 2016-12-13
<jbicha> Bluefoxicy: you could file a bug and use the tag upgrade-software-version
<jbicha> since monodevelop is currently synced with Debian, you can also file a bug against the Debian package, severity wishlist
<pitti> Good morning
<ginggs> morning pitti!  are you up for looking at pandas LP: #1643151 ?  fewer removals needed now
<ubottu> Launchpad bug 1643151 in sunpy (Ubuntu) "Please remove sad pandas and friends" [Undecided,New] https://launchpad.net/bugs/1643151
<pitti> ginggs: I really don't like removing pandas, they are endangered and cute!!
<pitti> ginggs: (looking âº )
<didrocks> turning them into happy pandas is a way to remove sad pandas :)
<ginggs> pitti: true, but they have reproducibility problems
<pitti> ginggs: so maybe you should add a Depends: to sextractor?
<pitti> ginggs: hmm, do you have a list of all binaries that need to be removed?
 * pitti is piecing them together with reverse-depends, but you may already have it
<ginggs> pitti: sorry i don't have a single list with all of them handy
<pitti> ok, nevermind
<pitti> ginggs: http://paste.ubuntu.com/23622919/ â looks plausible?
<pitti> (took a bit, some binaries are weird)
<ginggs> pitti: looks way more than i expected, let me check
<ginggs> pitti: libsopt* shouldn't be on that list, it no longer depends on pandas
<pitti> ginggs: that's reverse-depends and binaries of reverse-build-depends, minus packages that are only in -proposed
<pitti> ginggs: ok, dropped
<ginggs> pitti: thanks very much
<pitti> ginggs: rest looks good?
<ginggs> oh wait
<ginggs> i misunderstood what you meant by dropped
<ginggs> pitti: glueviz (and others) only build arch:all packages
<pitti> ginggs: but these still need to be removed on these arches
<pitti> .. I think
<pitti> well, they would come back next time it gets built, but they would be uninstallable
<ginggs> but there is no such thing as glueviz 0.9.0+dfsg-1 arm64 binary, is there?
<pitti> it's published there
<pitti> I don't think it makes much of a difference -- it's either present and uninstallable, or not publshed there, but will come back with the next build
<ginggs> pitti: i don't understand.  where do you see glueviz is published for arm64?
<pitti>  glueviz      | 0.9.0+dfsg-1 | zesty/universe          | source, all
<pitti> ginggs: well, if you prefer I can remove them, if you have a list of arch:all packages from that list
<ginggs> i was just going to paste that
<pitti> but I'd rather remove it from these arches too
<ginggs> pitti: so rmadison says source,all - i don't see arm64, but i'm just not understanding, so please go ahead
<pitti> ack
<sil2100> fossfreedom: hey! Let me take a look at your cdimage merge in a bit :)
<fossfreedom> sil2100 - thanks!
<ginggs> pitti: thanks for dealing with those pandas, it was the humane thing to do
<pitti> heh
<jbicha> pitti: if you're doing removals, could you look at bug 1649163 ?
<ubottu> bug 1649163 in ubuntu-mobile-default-settings (Ubuntu) "Please remove ubuntu-mobile-default-settings from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1649163
<pitti> jbicha: done
<tjaalton> looks like plasma-framework is blocking mesa, test on s390x has failed since quite a time
<jbicha> thanks
<xnox> tjaalton, right. but i'm pretty sure plasma-framework does not care about s390x.
<xnox> infinity, could you please do the hints magic for plasma-framework s390x test? ^
<tjaalton> that too
<doko> xnox, cjwatson: does haskell defaults to -O0 on s390x?
<doko> hmm, haskell-xmlhtml builds in unstable
<xnox> doko, i didn't think so. i thought the "advanced" haskell was missing with some fancy features.
<xnox> whatever that thing was.
<xnox> maybe that's not true any more. ghc provides look the same and have ghc-dynamic and ghc-ghci
<xnox> doko, you are looking at rebuild results?
<doko> yes, but gcc-7 only for now
<xnox> https://launchpad.net/ubuntu/+source/haskell-xmlhtml/0.2.3.5-3
<xnox> did not build on s390x in release....
<doko> right, but the file succeeds to build when -O1 is used
<xnox> =(
<doko> I assume this is our limitation on memory/swap
<doko> $ wc -l ghc_12.i
<doko> 5146360 ghc_12.i
<doko> -rw-rw-r-- 1 ubuntu ubuntu 207693501 Dec 13 10:15 ghc_12.i
<ubottu> Error: Ubuntu bug 207693501 could not be found
<doko> try 207693502 ;p
<doko> try ubuntu 207693502 ;p
<ubottu> Error: Ubuntu bug 207693502 could not be found
<doko> heh
<cpaelzer> Hi, I'd have an MRE question
<cpaelzer> I know that for a totally new version one has to upload the new orig tarball, but I wondere how that works with an MRE
<cpaelzer> zesty already has the newer orig tarball - so one could say LP has it
<cpaelzer> but (so far) yakkety does not
<cpaelzer> now I want to properly upload this for MRE and wonder if I have to set -sa or not on buildpackage to include the orig tarball on the upload
<xnox> cpaelzer, largely irrelevant. either your upload will be rejected straight away, or will hit the unapproved queue.
<xnox> cpaelzer, you can use -sa alway... and launchpad will discard duplicate tarballs for you.
<cpaelzer> xnox: thank, the latter is interesting as I thought to read a warning that it might be rejected if it has one already
<cpaelzer> xnox: I cant find it but maybe that triggers only if it is different which might be a perfect case to reject it
<cpaelzer> xnox: ah here dput is what is telling me "Package includes an .orig.tar.gz file although the debian revision suggests that it might not be required. Multiple uploads of the .orig.tar.gz may be rejected by the upload queue management software."
<pitti> xnox: nice, apt full-upgrade on my VM marks libcgmanager0 and upstart for auto-removal
<pitti> xnox: thanks for landing unity-greeter!
<xnox> cpaelzer, be a rebel, ignore warnings.
<xnox> cpaelzer, launchpad enforces that checksum of the .orig.* in the .dsc remains the same. whether you upload one (again) or not is irrelevant, as long as there is at least one.
<xnox> at least one copy.
<pitti> xnox: I still have indicator-network running (from gnome-session), that's still outstanding or unexpected?
<xnox> pitti, still outstanding
 * cpaelzer is not so rebel-ish most of the time, but thanks for the quote xnox - I feel safer now!
<xnox> pitti, i have a branch somewhere for it, but not landed yet.
<fossfreedom> sil2100: thanks for the review.  Much appreciated.
<fossfreedom> sil2100: I presume the DMB needs to officially approve ~ubuntubudgie-dev ?
<sil2100> fossfreedom: I think so! I need to bring this up with them as enabling a new flavor is something new to me!
<fossfreedom> ah - makes sense.
<sil2100> fossfreedom: it looks good to me so far but I think the DMB would need to take ownership if it, but that might be the TB's responsibility
<fossfreedom> Quick question if I may?
<sil2100> Sure
<fossfreedom> The seed "owner" is me - I'm fuzzy how to upload a bzr branch as a team (ubuntubudgie-dev) rather than myself.  Any thoughts?
<sil2100> fossfreedom: if you go to the seed branch details, you can then go to 'Change branch details'
<sil2100> fossfreedom: there you should be able to change the owner
<fossfreedom> looking...
<sil2100> fossfreedom: once you do that you should still be able to bzr push to it as normal since you're a member of the team
<fossfreedom> sil2100: thanks - I think that worked. the branch is now called "lp:~ubuntubudgie-dev/ubuntu-cdimage/ubuntu-cdimage"
<sil2100> \o/
<sil2100> Same for the seeds?
<fossfreedom> sil2100: think that's done as well - lp:~ubuntubudgie-dev/ubuntu-seeds/ubuntu-budgie.zesty
<sil2100> fossfreedom: excellent, I'm poking around to see if we can get the team officially blessed
<sil2100> Need to find out who has the power to do that - is it the TB after creating the packageset or can it be us for now
<fossfreedom> sil2100: you sir are an officer and a gentleman.  Thanks!
<sil2100> yw! Sorry it looks a bit chaotic so far
<mitya57> pitti, hi, it is reported that docutils breaks sphinx autopkgtest, but is it possible to retry that with the proposed version of sphinx rather than the release one?
<mitya57> Also, I get 500 internal server errors when trying to retry the tests :(
<Laney> mitya57: add extra &trigger= to the URL
 * Laney just tried a retry and it worked, maybe transient
<mitya57> Laney, You submitted an invalid request: Malformed trigger, must be srcpackage/version
<Laney> URL?
<mitya57> I.e. it was https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=sphinx&trigger=python-docutils%2F0.13.1%2Bdfsg-1
<mitya57> And I changed it to https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=sphinx&trigger=
<Laney> oh
<Laney> &trigger=package/version
<mitya57> Laney, what should I replace python-docutils/0.13.1+dfsg-1 with?
<Laney> you should add &trigger=sphinx/theversioninproposed if you want it to get that too
<Laney> to the URL that you get from excuses.html, that is
<Laney> Just append it on the end
 * Laney . o O ( where else would you append it? )
 * mitya57 finally got it
<mitya57> Laney, thanks!
<Laney> mitya57: yw
<Laney> looks like sphinx itself has a few red tests, would be good to look at those
<mitya57> I've looked at most logs, they don't even mention sphinx â so something unrelated
<mitya57> But some packages definitely need fixing, like hovercraft which I'm looking at right now
<Laney> nod
<Bluefoxicy> ugh, this is the worst interface
 * Bluefoxicy just finds a way to file bugs, then modifies the URL in launchpad to not be stupid.
<Bluefoxicy> Okay, not sure if I did that right, but now Launchpad #1649580 also references Debian Bug #848038
<ubottu> Launchpad bug 1649580 in monodevelop (Ubuntu) "Update Monodevelop to 6.1" [Undecided,New] https://launchpad.net/bugs/1649580
<ubottu> Debian bug 848038 in monodevelop "Monodevelop upgrade to 6.1 in Sid" [Normal,Open] http://bugs.debian.org/848038
<Bluefoxicy> I'm not sure if Ubuntu even has a Mono team anymore
<ginggs> pitti, re: pandas we missed removing python3-feather-format arm64, will you do it please?
<pitti> ginggs: *flush*
<ginggs> pitti: thanks
<cpaelzer> robru: is there a way to splot the bileto associated autopkgtests in the queue to get an ETA feeling ?
<pitti> cpaelzer: PPA queues are zarro (http://autopkgtest.ubuntu.com/running)
<cpaelzer> pitti: ok, so I learned the source is the ppa queue
<cpaelzer> pitti: but I'm missing my automated sign-off, how would I get to logs or so
<cpaelzer> sorry, just too new to bileto in that regard
<pitti> url?
<cpaelzer> pitti: https://bileto.ubuntu.com/#/ticket/2290
<pitti> cpaelzer: actually, there's one unity8 run for ticket #2233 queued
<pitti> ... so not that
<cpaelzer> should be libvirt
<pitti> cpaelzer: hm, it didn't even start testing yet -- there is no link to an excuses page
<pitti> " No packages are being considered! If you are preparing sources manually, please upload them to the PPA now."
<pitti> I suppose you did that as the PPA has a libvirt
<cpaelzer> pitti: they are in the ppa
<cpaelzer> yes
<pitti> cpaelzer: sorry, can't say, deferring to roaksoax
<pitti> err, robru
<cpaelzer> pitti: and I checked the "Lander Signoff" which according to Bileto docu is the next to kick of britney
<cpaelzer> pitti: thanks for thinking through the basics with me, waiting for robru then
<cpaelzer> robru: ^^
<caribou> rbasak: Hi,got a minute to discuss the isc-dhcp / isc-dhcp-ddns issue ?
<pitti> cpaelzer: try to click the "diffs" button perhaps? that's the one it keeps complaining about, not sure
<robru> pitti: where are you seeing "no packages..."? That's quite an old status, not relevant
<pitti> robru: I just checked the audit log for anything that might stand out
<robru> cpaelzer: indeed, the"missing diff" status is why autopkgtests aren't running
<pitti> robru: I didn't expect you to be awake at this hour, jetlag FTW? :-(
<robru> pitti: yes quite jetlagged
<cpaelzer> ok, hitting regenerate diffs now - didn't know that was a blocking step
<robru> cpaelzer: yes, for tickets built from merges, it generates the diff at the same time it generates the source packages. When you upload manual sources though it doesn't get a chance to do that so you have to do it manually
<rbasak> caribou: yes. Would a hangout be easiest, maybe with slashd? I don't see him online though.
<robru> This is one of the pain points that makes MPs first class and source packages second class
<pitti> robru: ah, that actually makes sense -- there's no way of telling when the dev is done uploading bits to the PPA
<caribou> rbasak: yes he is, spoke to him earlier. Let me set it up
<cpaelzer> I'm fine to note it and press it into my muscle memory over time, just didn't know
<rbasak> caribou: ack
<pitti> robru: although the "build" button would be slightly less confusing than the diffs one, I suppose
<robru> pitti: for a while there was some code to auto diff but it was error prone, often triggering at inopportune times
<cpaelzer> robru: but now generating diff failed I think, is ended with Diff missing - is there something I could do about that?
<robru> pitti: build and diff buttons are indistinguishable if you don't have MPs
<robru> cpaelzer: sigh, that's a race condition. Can you file a bug against lp: bileto please? Just say "status at end of diff job fails to notice new diffs"
<cpaelzer> robru: sure I can file one
<cpaelzer> robru: what can I do now to trigger britney for me in the meanwhile?
<robru> cpaelzer: nothing. You need to wait  up to ~20 min for the status to correct itself, then you should see "successfully built" along with "automated signoff: queued"
<cpaelzer> robru: ok, thanks that is fine for me
<robru> You're welcome
<cpaelzer> as long as I know it will continue to stumble forward I'm fine - just don't want to know it blocked
<robru> cpaelzer: ping me again if it doesn't say "successfully built" within 20min but it should be good
<cpaelzer> robru: ok, will do so - until then you now have bug 1649595 to track
<ubottu> bug 1649595 in Bileto "status at end of diff job fails to notice new diffs" [Undecided,New] https://launchpad.net/bugs/1649595
<robru> Thanks
<doko> Laney: did you find out a system how to rebuild the gnat packages?
<Laney> doko: no, just finding ones which fail autopkgtests
<pete-woods> pitti: hi. sorry to hear you're leaving
<pete-woods> been good working with you
<pete-woods> had a question before you go, though
<pete-woods> how should I go about getting stuff into python-dbusmock from now on?
<dobey> pete-woods: what would you put into python-dbusmock?
<pete-woods> dobey: nothing this very second
<pitti> pete-woods: no change really; I keep maintaining this project on Github and debian
<pitti> pete-woods: I'll probably just stop worrying about the overlays, but I figure you can do that yourself
<pete-woods> pitti: hmm, probably not, but I can learn :)
<dobey> pete-woods: sure. just seems like if it's a new module to mock something it should go into the project it's mocking, not python-dbusmock :)
<pete-woods> pitti: thanks for the info :)
<pete-woods> dobey: this would be things like the NM template, and general fixes, though
<dobey> ah ok, though i'd say someone really needs to get the NM template upstreamed
<dobey> aww there isn't a cups template in dbusmock. doh
<pete-woods> but then I need to push updates to network-manager
<pete-woods> which would likely be super slow
<pitti> my gut feeling is that keeping the templates in dbusmock is easier all around
 * pete-woods still doesn't know where he'd be in Canonical without pitti's dbusmock
<pete-woods> probably having had a breakdown somewhere around the 1 year mark and quitting
<cpaelzer> robru: it kind of worked, I got a ping in ubuntu-ci-eng that it built, and automated signed off switched to queued - but I still can't find it anywhere on http://autopkgtest.ubuntu.com
<pitti> you might have written it yourself? :-)
<pete-woods> pitti: I'd have tried. but my python-fu isn't that strong
<cpaelzer> robru: neither queued, not failed/succeeded - if you spot it let me know where to look for it
<pete-woods> it'd probably have been a C++ project, and been very tough
<dobey> pete-woods: not that hard. i implemented something similar before dbusmock existed :)
<robru> cpaelzer: no you're confused. "Queued" in bileto doesn't mean "i triggered your autopkgtests", it means "this is in the queue of things to have autopkgtests triggered for"
<pete-woods> to make it as flexible as python-dbusmock I think it might have been
<dobey> mostly it's just busy work
<pete-woods> you can just stuff code in strings with python
<pitti> pete-woods: most of it isn't rocket science, but writing the generic method mocks and poking in dbus-python's innards was an interesting research exercise
<robru> Eg, eventually britney will see it and trigger autopkgtests
<dobey> yeah, writing it in C++ would have been limiting for sure
<cpaelzer> robru: very meta that is - thanks for un-con-fusing
<dobey> but i can't say that i enjoy writing python inside strings in c++ as a means of writing tests, either :P
<pitti> dobey: OOI, why would you?
<pitti> dobey: dbusmock's primary interface is, well, d-bus, not python
<pitti> well, the function bodies need to be python, sure (but usually they are trivial half-liners)
<robru> cpaelzer: it's unfortunately a limitation of britney. It doesn't just trigger autopkgtests, it also does silly things like "load entire Ubuntu archive into memory", so this means it can only inspect one ticket at a time (is impossible to run two in parallel, you get OOM), so it takes a while to churn through all the tickets
<robru> cpaelzer: eventually your ticket should say "running" and then at that point you can expect them to show up in autopkgtest infra
<pitti> robru: well, it does super-polynomial computations over the archive graph (although in almost all practical cases i's O(nÂ²), but you really don't want to do that on-disk :)
<robru> pitti: yes, but it is quite the bottleneck when all you want is to trigger autopkgtests
<pitti> robru: well, you still want installability tests too, no?
<dobey> robru: but how do you know what to trigger, without inspecting the archive graph?
<pitti> robru: you already disable second-stage installability, but at least the package itself should be installable in its own right
<pitti> and rdepends calculation needs the entire archive map too
<pitti> for britney's original intent (running once for every distro) that's quite fine
<robru> pitti: i suppose
<pitti> the thing to optimize for britney would be to only do that initial loading/map building once, instead of once per silo
<pitti> or maybe pickle it out
<robru> Ooooooooooh pickle
<pitti> or whatever the fastest serialization is these days :)
<robru> Poor cpaelzer just wants autopkgtests run and here he has to wait for britney to poke every other ticket before his. Autopkgtests can run in parallel but britney has to run each ticket in series before it even notices to trigger them
<pitti> robru: she's your's now, have fun teaching that rascal :)
<robru> pitti: if CI train is and indication, i suppose i will spend the next 4 years rewriting it from scratch, twice
<pitti> haha
<pitti> robru: once in Go, and the final version in Haskell :)
<robru> pitti: did you know m4 is Turing-complete? I once wrote a prime-number calculator using nothing but m4 macros
<pitti> nice
<pitti> robru: I do know that C++ templates are -- I've seen a crazy project which actually uses that in uni time
<robru> Heh.
<dims> cjwatson : wgrant : can you please help with lp bug 1609128? (i tried to find you a few days ago, here's some context https://irclogs.ubuntu.com/2016/12/07/%23ubuntu-devel.html#t16:24)
<ubottu> Launchpad bug 1609128 in lazr.authentication "PyPI metadata is wrong" [Undecided,New] https://launchpad.net/bugs/1609128
<cjwatson> yeah, rolling an updated release is on my to-do list, but I'm behind on a bunch of code I need to write first
<dims> cjwatson : i see thanks. waiting eagerly
<cjwatson> ~/wg 119
<cjwatson> oops
<chrisccoulson> pitti, I guess now's a bad time to ask you if you feel like maintaining a web browser? ;)
<pitti> chrisccoulson: slight grammar -- I'll be maintaining something that runs *in* a web browser :)
<chrisccoulson> heh
<chrisccoulson> pitti, it looks like it's going to be a lot of fun anyway :)
<seb128> chrisccoulson, hey, aren't you supposed to be on holidays? ;-)
<chrisccoulson> seb128, yep. I'm back temporarily, thanks to adobe and mozilla
<seb128> oh right
<seb128> the fun never stops for you, I almost forgot
<seb128> ;-)
<chrisccoulson> "fun" ;)
<seb128> didn't you have a release to get out on newyear or something last year?
 * seb128 doesn't remember the details
<chrisccoulson> seb128, last year it was flashplayer, 28th december
<seb128> well, dec 13th is better!
<chrisccoulson> I don't really understand how I ended up with flash tbh
<pitti> can we just leave it broken, and may it never come back?
<chrisccoulson> heh
<pitti> honest question: does anyone actually encounter flash on any non-pr0n web sites these days?
<seb128> chrisccoulson, hope your enjoy your holidays once that round of updates is done!
<pitti> I haven't had it installed for several years, but of course everyone uses different websites
<chrisccoulson> pitti, I don't know. I struggle to find sites to test it with now. BBC News still seems to require it too
<pitti> we can thank Android and phones, I think
<chrisccoulson> s/too/though/
<seb128> pitti, I think the website they use for the townhall calls does
<seb128> I couldn't use it on my firefox last time
<pitti> anything that doesn't work on a mobile browser basically ceased to exist, no?
<pitti> seb128: bluejeans?
<seb128> yes
<chrisccoulson> getting rid of flash and convincing seb128 to maintain firefox should be my new years resolution
<pitti> seb128: right, I had to use chromium for that one, not sure if it was a codec or flash issue
<seb128> chrisccoulson, let's see how convincing you can be ;-)
<chrisccoulson> seb128, beer?
<seb128> lol
<Laney> seb128 only responds to absinthe
<seb128> beer is a start
<pitti> ice cream has been observed to have a measurable effect too
<seb128> not sure it's going to enough to make me agree to maintain firefox though
<pitti> and stollen
<seb128> Laney, shusssh
 * seb128 is hungry now
<chrisccoulson> me too
<chrisccoulson> I've already over-eaten though and it's only dec 13
<cjwatson> pitti: flash is still commonplace on websites aimed at kids, I find
<dobey> flash is sadly still commonplace in way too many places :(
<pitti> ah -- I wasn't trying to troll (much), but genuinely interested
<dobey> pitti: i had to use flash yesterday to listen to a company video conf call :)
<pitti> I surely wouldn't look at kid's websites, so that's a good data point
<dobey> pitti: some banks use flash for certain features still
<pitti> TTFN -- time to start the EOY holidays, IRC-less; I wish you all some nice resting and time with your family, see you back in January!
<cjwatson> have fun!
<dholbach> pitti, all the best!
<roadmr> enjoy pitti !
<cking> all the best pitti
<popey> pitti: bluejeans - our company site for commuication from our great leaders...
<nacc> slangasek: so I got the zend* stuff mostly sorted in zesty. But I think it's currently stuck because there is one binary package that disappears in the transition from src:zend-framework to src:zendframework (libzend-framework-zendx-php). I documented this drop in the changelog, but perhaps I should have indicated in the control that zendframework Breaks libzend-framework-zendx-php? It doesn't provide
<nacc> or replace it, though. Just looking for some guidance on how to resolve the transition
<xnox> juliank, mvo: today i learned what "rc" status stands for. Finally apt search told me that it's for [residual-config]
<xnox> i always thought that it was strange to call leftover configs as "removed-configs"
<mvo> xnox: heh
<Laney> what does rc mean in /etc?
<juliank> xnox: It actually stands for remove config-files
<juliank> That is, the package is selected for removal in dpkg; but still has config-files on the system
<Laney> "run commands" apparently
 * Laney gets a history lesson
 * xnox thought rc stands for stable software
<rbasak> bdmurray: I hadn't looked at bug 1640823 again, no. Shall I review and release if appropriate during my SRU day tomorrow?
<ubottu> bug 1640823 in util-linux (Ubuntu Trusty) "[trusty] mount -o loop is limited to 8 loop devices" [Undecided,Fix committed] https://launchpad.net/bugs/1640823
<juliank> xnox: remote control
<bdmurray> rbasak: Since you had an opinion I think that's appropriate
<rbasak> bdmurray: OK will do, thanks.
<slangasek> nacc: libzend-framework-zendx-php, is this something that would have been a top-level package users would install?
<nacc> slangasek: yeah, it's a leaf package with no rdeps
<nacc> barry: fyi, i've refreshed my snap, i just need to verify it still works :)
<barry> nacc: nice
<nacc> slangasek: or is this a consequence of needing to also delete src:zend-framework from zesty (see: LP: #1593024 c#14)
<ubottu> Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593024
<slangasek> nacc: so, that means someone who has that package installed will have a somewhat rocky upgrade (basically, what trips update-output can also trip a user upgrade).  Should there be a libzend-framework-zendx-php dummy package that depends on something else in the new set?
<nacc> slangasek: right, i could do that, but there's nothing that is libzend-framework-zendx-php that is provied by zendframework, unfortunately
<nacc> slangasek: so the zend-framework orig tarball differs from zendframework. z-f used the 'full' tarball which included unsupported/experimental extensions, zf only ships the core
<nacc> slangasek: and so zf doesn't provide those extensions at all, or anything that replaces that functionality
<slangasek> nacc: ok. In that case, the current packages are probably fine as-is and we just need to mangle the archive a bit to let this in
<nacc> slangasek: ack, I wasn't finding anything in the debian manual that covered this case -- and the upgrade of the packages that are upgradeable does work (i tested that already earlier) -- it's just this one leaf package.
<juliank> So, now that the word is out about the apt security update: I also uploaded 1.2.18 to xenial-proposed to replace the 1.2.17 in the queue there, so the queue contaisn a fixed version too
<juliank> To prevent an accidental upload of 1.2.17, it would be wise to remove it from the unapproved queue, and only keep 1.2.18 in there
<juliank> s/upload/approval/
<juliank> That said, I might want to rebuild the changes file for 1.2.18 with all changes since 1.2.15
<infinity> juliank: Yeah, can you reupload 1.2.18 with the right -v?
<juliank> infinity: done
<infinity> juliank: Ta.
<juliank> Now I need to figure out when the next normal stable release updates will happen. My queues got a bit strange with the whole security business
<juliank> s/queues/patch queues/
<Laney> doko: For some reason libaws has built now, so maybe this ada stuff can move forward a bit
<juliank> That is, 1.3.3 and 1.2.19 will happen at some point. Not sure when, though.
 * Laney is off from today but might poke at it a bit if there's time
<Laney> otherwise please do
 * juliank is a constant bugfix cherry-picking machine
<infinity> juliank: Why did aclocal.m4 and configure disappear?
<juliank> infinity: What, that sounds weird.
<infinity> juliank: (I realise they probably come back on debian/rules clean, but that still seems like poor form for an upstream tarball to not ship them)
<juliank> Ah
<juliank> Right
<juliank> infinity: I accidentally passed -nc to gbp buildpackage.
<juliank> I'll reupload one without -nc
<juliank> Too many non-git uploads prepared the past week
<infinity> juliank: Ta.  I assume 1.2.18 doesn't actually "exist" in the wild outside of the xenial queue?
<juliank> Not in the tarball form :)
<infinity> Check.
<infinity> Then a fresh upload would be lovely.
<infinity> debian/copyright went byebye too.  Symptom of the same oops?
<juliank> infinity: Should be in now.
<infinity> juliank: That looks better.  Will give it a bit of a once-over for obvious breakage and accept today.
<juliank> neat
<juliank> This will make sarnold very happy :)
<infinity> He's never happy.
<sarnold> :)
<juliank> he smiled!
<infinity> It's a ruse.
<attente> hi, would anyone be able to sponsor a xenial sru for bubblewrap? https://bugs.launchpad.net/ubuntu/+source/bubblewrap/+bug/1649330
<ubottu> Launchpad bug 1649330 in bubblewrap (Ubuntu) "[SRU] bubblewrap unavailable on xenial" [Undecided,New]
<infinity> juliank: Unrelated to the quality of the SRU (which I'm about to accept), but I suspect your travis.yml referencing wily all over the place might explode when we remove wily from the mirrors.
<juliank> attente: In any case, the version number is wrong. Not sure about policy regarding adding new packages in an SRU.
<juliank> infinity: Yeah. I'm building a PPA picking the components I need, but I'm not done yet
<attente> juliank: what should the version number be?
<nacc> attente: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<nacc> is a good reference
<attente> nacc: thanks
<attente> i'll update that
<juliank> nacc: That does not mention anything about those ~ uploads though
<nacc> juliank: you mean, e.g. ~ppa1 etc?
<juliank> nacc: I meant, you basically would want 0.1.4-2~ubuntu0.1
<juliank> otherwise your version is higher than zesty
<juliank> zesty having 0.1.4-2
<infinity> attente: Two things.  Version should be "0.1.4-2~16.04.1" to indicate a no-change backport.
<infinity> attente: Second thing: can you see if 0.1.2-1 from yakkety works just as well for your purposes?
<infinity> attente: Cause xenial should *not* be higher than yakkety, so if you *need* the zesty verion, then it needs to be backported to both releases, with a really good reason why.
<nacc> juliank: ah yes, i hadn't looked at the details of this specific case
<attente> infinity: d'oh, of course
<infinity> attente: (note: I'll probably reject that reason unless it's stellar)
<infinity> attente: So, preferably, backport yakkety's version, so if it does the job, then let's do that.
<infinity> s/so if/see if/
<attente> infinity: thanks, i'll do that
<infinity> attente: Basic reasoning here from my side: There's pretty much 0 chance of regression in introducing a NEW package into an old release, but updating a package in a stable release is much more potentially dangerous.
<infinity> So, happy to handwave review and accept the yakkety version backported to xenial, once you verify it fits your needs.
<attente> infinity: thank you
<nacc> slangasek: infinity: do i also need AA help for the imagemagick migration? (two binaries being removed in the version change)
<infinity> nacc: Usually not.
<infinity> nacc: Binary removal is simulated by proposed-migration to do the installability checks, but they're not actually removed until after migration, when we get around to tidying up after you.
<infinity> nacc: Oh.  Except for those two NBS binaries that are *in proposed*.  I'll whack those.
<nacc> infinity: ah thanks!
<infinity> nacc: Cleaned up for you.
<nacc> infinity: thanks again!
<attente> infinity: hi, i've tried the yakkety version and it works fine too. the version is also fixed: https://launchpad.net/~attente/+archive/ubuntu/test?field.series_filter=xenial
<slangasek> nacc: yeah, when you see those kinds of messages in update_excuses, pointing the AAs at it is the right thing to do
<nacc> slangasek: thanks!
<locust__> Any ipmitool maintainers around?
<doko> Laney: you shouldn't use -feliminate-dwarf2-dups, I'm told that it is broken. Passing -gz to compile and linker flags should work now
<nacc> locust__: well, we're currently in sync with debian right now, afaict (post 16.04). What specifically do you need?
#ubuntu-devel 2016-12-14
<nacc> slangasek: so i think i'll also need an AA to manually delete src:zend-framework. As that sole binary package will continue to be built from zend-framework (so it iwll never show up as a binaryless source?)
<slangasek> nacc: ack; please file a bug against the zend-framework source package for this and subscribe ubuntu-archive
<nacc> slangasek: will do, thanks!
<slangasek> rharper: the SRU in LP: #1636912 seems somewhat muddled to me; AIUI the test case as written did pass for systemd, but there is a new bug task open now on resolvconf related to DNS timing, but no test case for the DNS part of this?
<ubottu> Launchpad bug 1636912 in resolvconf (Ubuntu Yakkety) "systemd-networkd runs too late for cloud-init.service (net)" [Undecided,In progress] https://launchpad.net/bugs/1636912
<slangasek> rharper: if the problem you describe is a regression with the new systemd package, then there should be a versioned Breaks: from the new systemd to the old resolvconf; if it's not a regression, then this ought to be a separate SRU to not block the systemd SRU on the resolvconf changes
<rharper> slangasek: it's only exposed in the case of UC16  + cloud-init; which doesn't exist anywhere AFAIK;  the case is that you're using networkd instead of ifupdown and you're using cloud-init with changes to allow networkd to run early ( the changes in the SRU)
<rharper> slangasek: the test-case is basically building cloud-init with an update to cloud-init.service which includes an After=systemd-networkd-wait-online.service (which it doesn't have now); this allows a UC16 image with cloud-init enabled to use networkd to bring up networking for cloud-init.service;  DNS was an issue as resolvconf wasn't running before networkd was; so the DNS update wasn't found and /etc/resolv.conf wasn
<rharper> 't updated either ; snap installs failed as we could reach assertions.ubuntu.com etc.
<rharper> slangasek: w.r.t separate, pitti thought they were all the same change, ie, allow networkd to run early enough for cloud-init.service to use it to bring up networking
<cpaelzer> good morning
 * alkisg just learned that pitti is no longer around here... :D Thanks for everything and wishing you all the best!
<smb> Is anybody else having problems with google spreadsheets in firefox (xenial and trusty) since recently? I am quite sure it was working last week and at least since yesterday I always get error/try reload messages. In Chromium it works.
<xnox> smb, use google chrome =)
<smb> xnox, well, I do that now as a work-around of course. :-P just wondering whether it is a generic problem with the backport path in old releases which we maybe cannot tell all users to just use chromium
<xnox> smb, well we did better than that, and pushed out latest firefox v52 to all stable users.
<xnox> i use google chrome, as it has Adobe based pdf renderer and Adobe based flash plugin, proprietary, built in, and sandboxed.
<xnox> and from security point of view, i am naive to think that google chrome is "secure" and updated "faster".
<smb> xnox, and there I thought this was 50.1 about a few hours ago :) So yeah, I just wait and meanwhile try to do a fresh xenial VM install to see whether it maybe is related to updating with older browser config
<smb> xnox, Mainly I user firefox because it was there before and I am too lazy to change
<smb> ;)
<xnox> smb, oh, the killer feature of google chrome is that it can track multiple google accounts and easily switch between them.
<xnox> because one can have a user/profile, per google account ChromeOS style.
<smb> xnox, yeah thats a bigger pain in ff. there is multiple active users but of course the feature of almost always picking the wrong one by default
<xnox> smb, huh, it is 50.1 everywhere. which is latest, no idea how i saw 52 given that it does not exist yet =)
<xnox> google chrome picks last active window one. So if i had canonical calendar open, clicking a link will open things in that profile.
<smb> xnox, heh, ok. It uses the right one when clicking links from anything related to a certain user. More of a problem using links from email or irc
<xnox> so yeah, if last active browser was of matching account things are good, otherwise there is popup to switch accounts but i usually switch to the right browser account, go back to email/irc, re-click the link.
<xnox> still pain =/
<smb> indeed, but to a certain degree we all love some pain... or we would not be working in open software... ;-P
<xnox> smb, 50 shades of aubergine.... =)
<juliank> xnox: The Chrome PDF plugin is not Adobe based, and not even proprietary anymore. PDFium is based on Foxit technology, and was open sourced in summer 2014. Here's the code: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/pdf/
<juliank> (excluding the pdfium library itself, which is at https://pdfium.googlesource.com/)
<xnox> juliank, i did not know that! used to be proprietary, and i recall seeing "contains code from adobe" but maybe it was a generic EULA and maybe that bit referred just to flash.
<mitya57> Can someone please mark libaws (ppc64el, s390x) as ignored failure? It blocks many packages from migrating, and for some of them it's the only blocker.
<xnox> error: ("/usr/lib/powerpc64le-linux-gnu/ada/adalib/aws/aws-exceptions.ali" is obsolete and read-only)
<xnox> looks odd
<xnox> mitya57, does it need to be recompiled again for some reason due to arch skew or some such?
<xnox> e.g. it is likely that ppc64el/s390x builds finished before other arches.
<mitya57> Maybe, should I try a new rebuild?
<xnox> mitya57, we can do that in a bileto silo, and it will run autopkgtest to verify that claim.
<xnox> however, maybe makes no difference to just use the archive direct. Upload no change rebuild of libaws again?
<mitya57> xnox, If there is a chance that it will fix the failure, I can do a rebuild in the archive
<xnox> with my limited knowledge, i would try to rebuild the source package which ships /usr/lib/powerpc64le-linux-gnu/ada/adalib/aws/aws-exceptions.ali
<mitya57> (sorry, got distracted by other work)
<mitya57> xnox, that file is from libaws3.3.2-dev, so the same source package
<slashd> rbasak, so since Proposal A won't work, I thought about this proposal : https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/comments/36  still missing if the upgrade from Trusty and Xenial will work as noddns will only exist in Trusty and no longer be there in Xenial
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Medium,In progress]
<rbasak> slashd: I like that approach.
<rbasak> I'll need to think about it some more though.
<slashd> rbasak, sure me too, it's just a draft, but I think it worth evaluating it
<slashd> caribou FYI ^
<mterry> tjaalton: hello!  Yesterday I noticed that the version of mesa in -proposed seems to be causing unity8's autopkg tests to fail, preventing it from migrating.  I see you uploaded mesa, wondered if you had any ideas on debugging it or guesses as to why
<tjaalton> mterry: haven't checked yet, will have a look
<mterry> It seems like mesa itself has been stuck in -proposed a while
<tjaalton> yes
<tjaalton> it should migrate but plasma-framework is holding it back
<tjaalton> mterry: what test is failing?
<xnox> tjaalton, unity8 adt tests segfault
<mterry> tjaalton: several tests segfault, about ten total I think.  For example, xvfbtestPreviewExpandable.  They only segfault with xvfb, in my testing
<tjaalton> mterry: then that's again caused by libepoxy, which was fixed
<tjaalton> last week
<mterry> I don't know if we're the only package affected, but I just happened to notice it with us
<tjaalton> or, new mesa triggers the bug in libepoxy, which got fixed there
<tjaalton> so, rerun the test
<mterry> tjaalton: unity8's upload was yesterday I believe
<xnox> tjaalton, we are rerunning the tests with all-proposed=1
<xnox> we should have fresh results soon.
<tjaalton> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/u/unity8/20161213_153305_7636d@/log.gz ?
<smb> so... just for reference, since I complained here... firefox 50.x + privacy badge + google spreadsheets == sad face (at least for me, had to disable it completely, just disable for docs.google.com did not help)
<tjaalton> mterry: do they segfault with latest libepoxy?
<smb> *privacy badger (extension)
<xnox> tjaalton, at http://autopkgtest.ubuntu.com/packages/unity8/zesty/amd64 there should be two more results from today. They are still running at http://autopkgtest.ubuntu.com/running#pkg-unity8
<mterry> tjaalton with version 1.3.1-1ubuntu1 in current zesty, yes they still segfault
<tjaalton> looks like libepoxy is latest
<tjaalton> dunno then what it is..
<tjaalton> get a bt?
<mterry> tjaalton: that is the log above yeah
<mterry> tjaalton: a bt?
<tjaalton> backtrace
<mterry> tjaalton: oh I did manage to catch it but the stacktrace looked abreviated.  It was just one frame, inside libgcc
<mterry> So I figured it had been corrupted
<mterry> Maybe I didn't have enough dbg packages either tho
<mterry> tjaalton: I can help get you to the point where you can reproduce and catch in gdb if we go down that route
<tjaalton> mterry: other option is that I bisect mesa to find out what caused the original bug, and then revert it
<mterry> I'll see if I can get a better stacktrace over here
<tjaalton> cool
<tjaalton> mterry: is there a (small) qt app to test with xvfb?
<tjaalton> on the default desktop
<mterry> tjaalton: probably one of the qt example apps? qtbase5-examples
<mterry> tjaalton: the segfault is seen when the test is finishing/closing
<tjaalton> thanks
<tjaalton> running "openglwindow" on xvfb results in "could not initialize opengl"
<tjaalton> and then it aborts
<tjaalton> hm, that happens with older mesa too, so it's not that
<mterry> tjaalton: with all the debug symbols I could think to install, I still just see one frame -- libgcc1's "classify_object_over_fdes" -- will see if other threads have anything suspicious
<fossfreedom> sil2100: Hi!  any news on the best way to recognise officially ~ubuntubudgie-dev ?
<mterry> nope, just the one threa
<mterry> d
<tjaalton> weird
<mterry> memory must just be trashed by this point
<mterry> tjaalton: I guess I'll try to catch it just before it crashes -- any luck on your side getting a reproduction?
<tjaalton> mterry: not yet
<tjaalton> but I'll just use the gtk case
<tjaalton> and revert libepoxy to an older release, then bisect mesa..
<tjaalton> reopened the upstream bug too
<mterry> tjaalton: if it's easier, I could get you set up to run the unity8 test.  But sounds like you have a known gtk crasher
<tjaalton> one thing I noticed is that with mesa 12 I get a libgl error failing to load swrast, while it's there
<tjaalton> with 13 I don't get that
<sil2100> fossfreedom: there was some discussion regarding that, need to get back to it after - let me poke you laterish (or tomorrow at latest)
<fossfreedom> much appreciated.
<krytarik> fossfreedom: Hi.  Not to interfere much, but I noticed earlier that you made an "ubuntubudgie" â "*-dev" typo here: http://bazaar.launchpad.net/~ubuntubudgie-dev/ubuntu-cdimage/ubuntu-cdimage/revision/1637#lib/cdimage/tests/test_germinate.py
<fossfreedom> krytarik: hi - and damn - you are correct!  will fix tonight when I can get back to my computer.
<krytarik> :)
<krytarik> fossfreedom: Also, just noticed, regarding ~ubuntubudgie-dev, I think you want to invite ~ubuntu-core-dev as a member, rather than ~ubuntu-dev.
<fossfreedom> looking ...
<mterry> Looks like someone pushed u8 into main anyway, despite the failing tests.  So tjaalton my immediate pressure for this problem is gone, but it will bite us again probably
<tjaalton> huh, ok :)
<mterry> tjaalton: and in fact, it might still prevent a lot of stuff from migrating, because they'll trigger our u8 tests
<fossfreedom> krytarik: hmm - not obvious how to "uninvite" a team on launchpad.  Any ideas?
<mterry> xnox: so unity8 landed, was that because of the  all-proposed=1 run?
<krytarik> fossfreedom: LP bug #656782. >_>
<ubottu> Launchpad bug 656782 in Launchpad itself "No way to cancel (retract) pending team invitation" [Low,Triaged] https://launchpad.net/bugs/656782
<fossfreedom> oh - outstanding since 2010 :(
<xnox> mterry, possibly. I see that one of the reruns did succeed -> http://autopkgtest.ubuntu.com/packages/unity8/zesty/amd64 & http://autopkgtest.ubuntu.com/packages/unity8/zesty/i386
<xnox> mterry, i'm not sure which rerun was good (e.g. with all-proposed or without)
<slangasek> rharper: at the moment, LP: #1636912 is blocking other SRU changes for systemd.  If the behavior with this SRU is not a regression, could you mark it verification-done, and we'll treat resolvconf separately (shortly)?
<ubottu> Launchpad bug 1636912 in resolvconf (Ubuntu Yakkety) "systemd-networkd runs too late for cloud-init.service (net)" [Undecided,In progress] https://launchpad.net/bugs/1636912
<mterry> xnox: I'm not sure I understand why that would fix it.  I was able to reproduce locally on a machine that had all of proposed installed.  But glad it went through anyway
<rharper> slangasek: sure;  I don't believe we're regressing anyone as nothing besides UC16 + cloud-init (using netword) is affected by the required changes to resolvconf
<xnox> mterry, i think other retriggers of unity8 will still continue to fail. looking at the log it seems unity8 tests passed with everything from release pocket, and just unity8 from proposed.
<rharper> slangasek: after I mark verification-done;  what's the next steps for queuing up the resolvconf SRU ?
<xnox> mterry, so e.g. mir, qtmir, mesa should still be stuck, and should still be reproducible.
<mterry> xnox: yeah
<slangasek> rharper: I'm going to chase the last remaining SRU bug in that systemd upload this morning, then publish it, then I'll approve the resolvconf SRU
<xnox> mterry, right. So the failed log has --apt-pocket=proposed
<slangasek> rharper: the SRU bug will still need adjusting so that the test case addresses the DNS part
<rharper> slangasek: ok, let me verify the latest systemd works as expected in UC16 image I'm testing cloud-init changes
<xnox> mterry, and passed one has --apt-pocket=proposed=src:unity8 -> so we know that unity8 itself is not broken, but other things break it (e.g. new mesa)
<xnox> tjaalton, i really wish to use bileto silos for mesa landings -> one can build all packages in a single silo, and it will run all autopkgtests from release pocket against that ppa, such that we can see what fails because of new mesa alone in isolation from the rest of stuff. Too late now =)
<sil2100> This is why Bileto has its merits
<mterry> We could drop mesa from proposed?
<mterry> (/ re-upload old version with later version)
<rharper> slangasek: so, to confirm, we want to release systemd 	229-4ubuntu13 which is currently in -proposed;    we'll then perform another SRU with an update to systemd to address running resolvconf earlier and having systemd-networkd-wait-online.service update with an change to ensure that resolvconf service completes before we reach network-online.target ?
<rharper> in the second SRU we'll have a systemd change and an updated resolvconf  paired
<slangasek> rharper: ah, it wasn't clear to me that a further update to systemd was needed.  Then yes to all of the above, but in that case please create a separate bug for the follow-on SRU
<rharper> slangasek: OK, marking done, filing new bug against systemd and resolvconf for DNS early with networkd
<tjaalton> xnox: never heard of that
<xnox> tjaalton, https://bileto.ubuntu.com/ -> create a ticket which creates a devirt ppa, which builds things, runs britney proposed migration, and all autopkgtests before doing a copy from ppa to release.
<xnox> tjaalton, aka ~= the kernel team workflow, as well as touch/phablet/personal.
<xnox> https://wiki.ubuntu.com/Bileto
<xnox> most of it w.r.t. branch management and merging is irrelevant, if one knows how to prepare .dsc and dput things into ppa
<tjaalton> ok
<rharper> slangasek: filed https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649931
<ubottu> Launchpad bug 1649931 in systemd (Ubuntu) "systemd-networkd needs to ensure DNS is up before network-online.target" [Undecided,New]
<rharper> slangasek: ok, verified
<slangasek> rharper: ta!
<slangasek> rharper: can you reupload resolvconf with the new bug # also?
<rharper> I cannot reupload, but I can attach the debdiffs to the new bug
<slangasek> rharper: ok, then I'll reupload
<slangasek> rharper: would accept resolvconf now, but there's no testcase in the SRU bug
<rharper> ok, I'll write up something
<xnox> [Testcase]
<xnox> something
<xnox> EOF
<clivejo> Hi, any experts be able to shed some light on why krita 3.1.0 fails on arm64 and armhf in zesty - https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-misc/+packages?field.name_filter=krita&field.status_filter=published&field.series_filter=zesty
<xnox> clivejo, because those architectures use gles and krita is not compatible with it?
<mterry> @pilot in
<mterry> hmm no bot
<hjd> Hello, looking at https://launchpad.net/ubuntu/+source/batik I see that it has an Ubuntu-delta to keep one of its dependencies in universe instead of main. However, it looks like batik has since been moved to universe as well. Am I right in assuming this means that the Ubuntu delta could be dropped and a newer version of the package synced from Debian?
<mterry> hjd: yeah probably -- I'll look at it
<hjd> mterry: Thanks :)
<mterry> hjd: just started sync
<hjd> \o/
<juliank> infinity: Can we manually accept apt 1.4~beta2 to zesty? The regressions in postgresql-debversion/1.0.8-2 tests can be ignored (-2 is not built, so it can't be installed), and the regression of apt on i386 is some weird timing issue (it's the test checking that download progress has a step between 0 and 100) - I retried it once, but it seems a bit pointless to try again.
<juliank> (or anyone else)
 * juliank just tags persons more or less randomly
<infinity> juliank: I'll have a look at it in a bit.
<juliank> :)
<juliank> The postgresql thing is a bit weird. I wonder why autopkgtest tries against the unbuilt zesty-proposed version rather than the one in zesty
<juliank> But that's really a problem to solve sometime else
<sarnold> man pitti has great timing doesn't he? :)
<mterry> cjwatson: no progress on bug 1648603 yet...  do you know the RT number?  Trying to find levers to put pressure on it
<ubottu> bug 1648603 in Canonical System Image "consistent timeouts of lp built snaps uploading to store" [High,Confirmed] https://launchpad.net/bugs/1648603
<juliank> mvo: Sort of thinking about prioritizing the fix for bug 1649959 - despite what https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841763 says, I think that's actually a regression in 1.3.y only, as I broke that when simplifying the build system
<ubottu> Debian bug 841763 in apt "unattended-upgrades: Breaks hard when apt is upgraded" [Grave,Fixed]
<ubottu> bug 1649959 in apt (Ubuntu Yakkety) "unattended upgrade of apt kills running apt-daily job" [High,Confirmed] https://launchpad.net/bugs/1649959
<juliank> Basically can SRU that as 1.3.3 this week, and push the other less important fixes from 1.4 betas into 1.3.4
<juliank> (The other stuff is mostly fixes for the whole installation ordering stuff introduced in 1.3)
<juliank> (For 1.3.4 I also want to pull in new translations from master, I'll figure out the workflow for that soon...)
<juliank> Ah, let's just do this.
<juliank> infinity: If it's not to much to ask, I just uploaded that 1.3.3 SRU to yakkety-proposed fixing bug 1649959, so if you accept the zesty one, it would be nice to get this approved for -proposed (it contains a tiny fix from 1.4~beta1)
<ubottu> bug 1649959 in apt (Ubuntu Yakkety) "unattended upgrade of apt kills running apt-daily job" [High,Confirmed] https://launchpad.net/bugs/1649959
<juliank> (because this depends on 1.4~beta2 being accepted to zesty first if we want to play nice)
<infinity> juliank: Ouch, that's an unfortunate bug.  xenial's unaffected?
<infinity> Oh, no, the report was on xenial.
<infinity> Or, the reporter can't spell "yakkety". :)
<juliank> infinity: It really only effects yakkety and zesty
<juliank> (zesty until 1.4~beta2 moves out of proposed :))
<infinity> juliank: Yeah.  The reporter said "my new xenial system", but the autogenerated bits of the bug report clearly said yakkety. :)
<juliank> I messed that up when I rewrote the packaging after the move to cmake in 1.3
<juliank> It might even be critical, not only high
<juliank> But I could not really decide
<infinity> It's critical, except also not, given it only happens on upgrade, so the damage is probably mostly done.
<juliank> infinity: In fact, it only ever happened once so far after release: For the security update.
<infinity> juliank: Right, because we configure unattended-upgrades to be on by default for security-only.
<infinity> juliank: So much wider exposure to u-a bugs in security than in updates. :/
<juliank> Yeah that, and because there was no other apt update yet anyway
<infinity> If the only fix in this is that, I might suggest we do it in the security pocket as a fixup for the previous upload, to mitigate the impact for people who haven't yet upgraded.
<infinity> Though, I guess the way u-a works, everyone who was going to be affected was affected in the first 24h.
<infinity> So meh.
<infinity> juliank: Congrats on using a new build system that still generates pointless noise in docs. ;)
<juliank> infinity: Actually, we update the timestamps in the manpages so it matches the day the update is released. and po4a updates the timestamp in the doc/po files
<infinity> juliank: Yeah, that's silly, IMO.  But, to each their own.
<juliank> Otherwise we'd have to manually update the timestamps when we change the files. We'd forget to do that.
<infinity> juliank: If the content hasn't changed, I see no reason to update the times.
<juliank> Right. We could add a check to CI to enforce date changes  on content changes instead
<juliank> Or even in the pre-build hook
<infinity> juliank: If you kept the generated files in your VCS, your generation script could just do "generate > file.new && diff old new && update-times" or whatever.
<infinity> juliank: Not that glibc is an example of the world's best git usage (it so isn't), but we keep generated files checked in for that (and other) reason.
<juliank> There are not really generated files anymore.
<infinity> If re-generating doesn't cause an actual change, no need to re-commit a new version.
<juliank> It just updates the existing files.
<infinity> Oh.  That's more problematic indeed.
<juliank> And for doc/po it's po4a doing the stuff. I guess I could ask there.
<infinity> juliank: Yeah.  There are two types of the bug/misfeature represented here.  doc/po updating POT-Creation-Date and Project-Id-Version pointlessly, and then doc/*xml having <date> bits updated.
<infinity> juliank: It's a LOT less noise than apt updates used to generate, so overall you seem to be winning. :P
<juliank> infinity: I guess if we see more unattended-upgrade issues in the next update, it would still be possible (for security team) to just copy 1.3.3 from -proposed to -security?
<infinity> juliank: We don't copy from updates to security, because you might have binary deps that only exist in updates.
<juliank> Ah, right.
<infinity> juliank: But they could do a no-change rebuild into security (or, we could manually examine the deps to determine the copy is safe)
<infinity> Given apt's deps, it's a fair chance it's safe.
<infinity> You don't exactly pull in the world.
<juliank> And there have not been many updates in yakkety anyway
<infinity> I need sugar.
<infinity> Well, food, which I will turn into sugar, because I'm a badass digesting MACHINE.
<sarnold> high-five!
<mwhudson> morning
<mwhudson> what's the voodoo to run an autopkgtest with two packages from -proposed?
<mwhudson> on the production infra, i mean
<infinity> mwhudson: Via the cgi?
<infinity> mwhudson: multiple trigger= arguments.
<mwhudson> infinity: yes
<mwhudson> ah ok
<mwhudson> thanks
<infinity> mwhudson: Triggers are given as package/version pairs, so if you give a few triggers, all those sets will be upgraded to said version before running the test.
<infinity> source_package/version, that is.  It sorts out the mapping.
<mwhudson> infinity: also, i thought that if the package in proposed depended on a (package, version) that was only in proposed, britney would do this for me
<infinity> mwhudson: If the deps are correct, yes, it'll Just Work.
<mwhudson> infinity: but that doesn't seem to be the case, was that just wishful thinking on my part?
<infinity> mwhudson: Example?
<mwhudson> infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#docker.io
<infinity> mwhudson: Which test?  The docker one?
<mwhudson> infinity: docker-in-lxd fails, but basic-smoke only passes because of the "autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed" thing
<mwhudson> confirmed locally that taking both docker.io and runc from proposed passes
<infinity> Ahh.  Yes, that would be a bug in your tests. ;)
<infinity> Or, a misfeature of the infra which causes your tests to be naively buggy.
<mwhudson> ?
<infinity> You copy our /etc/apt into the container, which has the pin which makes the installation fail.
<infinity> We have no way to detect that situation and try again.
<mwhudson> sure
<mwhudson> but as above, the deps on docker.io in proposed should make britney make autopkgtest use runc from proposed too, right?
<infinity> It's not that smart, no.
<infinity> We could make it be that smart, since britney had that info.
<infinity> s/had/has/
<infinity> ie: because of "Depends: docker.io runc (not considered)", we could force the trigger to always be docker.io + runc
<mwhudson> i see
<infinity> But currently, that's not how it works.
<mwhudson> so what did you mean by "<infinity> mwhudson: If the deps are correct, yes, it'll Just Work." then? :)
<infinity> Well, because of the auto-retry.
<mwhudson> i would offer to look into this, but unfortunately i've looked at the britney code before
<infinity> Which fails miserably for you because it's not autopkgtest doing your install. :P
<mwhudson> oh, right
<mwhudson> yeah
<infinity> The test triggering bit that needs mangling here might not be super scary.
<mwhudson> hooray for non insane autopkgtest queues, i might find out if that worked today
<mwhudson> uh
<mwhudson> where is the britney2-ubuntu branch now?
<mwhudson> lots of things link to https://code.launchpad.net/~ubuntu-release/+git/britney2-ubuntu but that doesn't exist
<infinity> I updated the link in the bzr branch just now. :P
<mwhudson> haha
<infinity> https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu
<mwhudson> thanks
<infinity> But, basically, if one greps for "not considered" in britney2/excuses.py, one sees the bits that need to be massaged down to the autopkgtest triggering bits.
<infinity> Doing so may prove painful.
<clivejo> Is anyone having network problems in zesty?  I had to boot into recovery to reinstall a nvidia driver for kernel 4.9 and there was no network connections.  It wiped out all the entries in /etc/network/interfaces except for lo0 and also resolv.config was wiped too
<infinity> mwhudson: Actually, might not be that bad.  Assuming this structure policy is fed is what I think it is.
<clivejo> I had to configure everything manually, install the new driver and booted back into Plasma (Kubuntu) which had all my network connections available as before
<clivejo> another colleague has noticed this behaviour in Lubuntu and Kubuntu
<infinity> clivejo: If all your networking has been delegated to network-manager, that's pretty much how it would work, yes.
<infinity> clivejo: Which has been true for, well, ever.
<infinity> (on desktop installs, anyway)
<clivejo> never noticed this before :/
<infinity> Recovery didn't "wipe out" anything, there just aren't interfaces entries on your machine.
<infinity> Because ifupdown isn't what's doing your networking.
<clivejo> this is an upgrade from yakkety and yakkety didnt do that
<infinity> It sure did.
<infinity> And so did xenial.
<infinity> And trusty.
<infinity> And precise. :P
<infinity> (I could keep listing)
<clivejo> nope, always had networking in recovery
<infinity> Do you configure with a static IP in the installer?
<infinity> That's the only case that might have changed.
<infinity> DHCP in the GUI installers has been network-manager for ages.
<clivejo> no idea, I cant remember installing it!
<clivejo> just upgrade from +1 to +1
<infinity> I could indeed see it as a bug that network-manager isn't invoked on entering recovery, but I don't think it ever was.
<clivejo> by recovery I mean via Grub and selecting the (Recovery) option
<infinity> Yeah, I know what you mean.
<bdmurray> flexiondotorg: What's the status of bug 1623856?
<ubottu> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
<cjwatson> mterry: I see Bret has replied.
<mterry> cjwatson: yes, looks like they are on it and listed the RT, thanks
<nacc> slangasek: i just noted that ubuntu-archive is already subscribed to LP: #1593024; I just put in a comment asking for the deletion of src:zend-framework. Do you think a new bug is necessary?
<ubottu> Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1593024
<mterry> @pilot out
<slangasek> nacc: adjust the bug title to mention that you want a thing deleted?
<slangasek> nacc: fwiw the binary package is not why it needs manually deleted; it needs manually deleted because it's a source package and not from Debian
<tjaalton> is filing a bileto ticket a one-time thing per package, or per upload?
<slangasek> and the binary package already got deleted to let things pass proposed-migration
<slangasek> tjaalton: per "landing"
<slangasek> you can iterate multiple uploads as part of a landing, but you only publish to the archive once for the ticket
<tjaalton> right
<nacc> slangasek: good point, will do
<tjaalton> ok
<tjaalton> I'll go read the wiki next :)
<Bluefoxicy> is #1641380 just a matter of bandwidth, or is there a problem getting a fixed package built?
<Bluefoxicy> I mean building a package for a web browser isn't rocket science, but when you have 16,000 packages to maintain in a distribution that's supposed to work as a whole I imagine things can queue up a little.
<nacc> Bluefoxicy: what versino of ubuntu?
<Bluefoxicy> nacc:  it's 16.10
<Bluefoxicy> I'm just curious whether the devs have 6000 other things to get to (like a 6-month release cycle distro to build) or if there's some sort of failure that everybody is scratching their heads over
<Bluefoxicy> it's kind of odd to see something fixed in the last release's package, then re-opened when it turns out broken in current, then no activity or explanation for 2 days
<sarnold> it's usually better to open new bugs rather than comment on existing, closed, bugs, when issues re-appear
<nacc> there seem to be two problems in this bug (my opinion): 1) people using the ppa mentioned by someone (not the uploader) and complaining -- when the ppa specifically says 'You shouldn't use this'; 2) it seems like the fix possibly never went out to 16.10? c#67 refers to an upload to the PPA, but that's past the version in yakkety acc'g to rmadison
 * nacc doesn't know how the chromium developers do things, but notices there are no per-release tasks, so it's hard to say where what has been fixed in that one bug
<Bluefoxicy> yeah
<nacc> and as sarnold mentioned, it's possible some things have been fixed in the context of that bug, but there are other fixes that are now needed
<Bluefoxicy> what I can see so far is that cmiller re-opened the bug after a bunch of user reports, but nobody posted anything referencing a new bug or mentioning e.g. that a package failed to build for an unknown reason
<Bluefoxicy> people will eventually perceive that they're being ignored
<Bluefoxicy> hence the point of making pointless status updates like "We have no idea why it's not working, trying to fix"
<Bluefoxicy> like okay, that doesn't get us any closer, but at least people don't wonder if you marked it as re-open and then went to watch anime
<Bluefoxicy> ...
<nacc> Bluefoxicy: right, but i think you want to talk to cmiller about that, presumably
<nacc> not 'devs' in general
<nacc> or ask explicitly in that bug
<Bluefoxicy> fair enough
<Bluefoxicy> I'm just taking a moment to reflect on how ... unpleasant ... it is that a large part of human communication is simply trying to prevent people from making shit up and assuming it's true.  :|
<Bluefoxicy> anyway I'll make a comment to that effect on the bug.
<nacc> as i said, i don't think a fix was *ever* rolled out for yakkety, based upon the changelog in yakkety (there's only been one version published in yakkety (well the released version, afaict))
<nacc> i'm guessing cmiller was focusing on getting the LTS fixed
<Bluefoxicy> yeah, it was only rolled out into LTS
<nacc> so could simply be oversight
<nacc> or as you said, overworked :)
<Bluefoxicy> I'm mostly being a pest trying to gather information and understand what's happening.  I don't get as distressed over stuff like that anymore, but I still like to have a full narrative.
<Bluefoxicy> Though, as I said, people in general will rage and then develop an imaginative narrative of what's happening, then take it to heart.
<nacc> people will always rage :)
<Bluefoxicy> I find that the scope and depth of rage can indicate whether to negotiate or to simply ignore them
<nacc> rbasak: so i found one gap in our 'process' -- at least afaict. In LP: #1644428 you helped foster through a revert of a SRU regression. However, the patch is still applied in yakkety-proposed (which was devel at the time, I think) and zesty (release). So we should revert it in both places, afaict? That is, 2:4.4.5+dfsg-2ubuntu5.2 should be uploaded for 16.10 and in the process of the merge, I should
<ubottu> Launchpad bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Fix released] https://launchpad.net/bugs/1644428
<nacc> drop these changes?
<nacc> caribou: mdeslaur: --^ you also may have context here
<nacc> iiuc, the conclusion is the uploaded fix was incorrect as it broke functional winbind configurations. So it has since been reverted and should also be reverted in zesty (and y-p). But then there is no actual fix for the original problem in LP: #1584485 ?
<ubottu> Launchpad bug 1584485 in samba (Ubuntu Trusty) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
#ubuntu-devel 2016-12-15
<nacc> niedbalski: --^ maybe you're already working on this, as well
<Umeaboy> Hi!
<Umeaboy> I forgot what package to translate for the installation process. Which one is it?
<Umeaboy> ubiquity is the name of the installer, right?=
<sarnold> yes; there's also debian-installer
<Umeaboy> OK.
<Umeaboy> There are some parts of it that's not translated into Swedish that I want to correct.
<krytarik> Umeaboy: More specifically, https://translations.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu
<Umeaboy> krytarik: Thank you very much. :)
<krytarik> You are welcome.
<Umeaboy> Hmmmmmmmmm. Swedish seems to be fully translated and still I see some things missing at the start of the installation when you click F3.
<Umeaboy> How can that be?
<sarnold> was it perhaps -in- an image? I'd be surprised if images are translated
<Umeaboy> Never mind.
<Umeaboy> What about the text in the window for Version facts?
<Umeaboy> When upgrading Ubuntu 16.04 to 16.10.
<fo0bar> [test public message for ubuntulog, please ignore the lurker]
<dholbach> hey hey
<me_irl> join #wordpress
<rbasak> nacc: good point, and yes please.
<caribou> nacc: yes, this is indeed the situation; we're working on identifying the root cause
<rbasak> nacc, caribou: ah, so was I wrong in marking bug 1644428 Invalid for the development release? If the regression also exists in Zesty?
<ubottu> bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Fix released] https://launchpad.net/bugs/1644428
<caribou> rbasak: I need to double-check on that
<caribou> rbasak: yes, it still affects Zesty as well, I'll change that
<rbasak> Thanks! Sorry, I didn't consider that case before.
<caribou> rbasak: I should also revert that fix before it causes grief
<rbasak> ack
<rbasak> cyphermox, lamont: in bug 1621507's test cases, we had previous reported regressions with ip="" and ip=:::::eth0:dhcp. Those should be in the test plan, IMHO.
<ubottu> bug 1621507 in open-iscsi (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
<rbasak> cyphermox: lamont: what are "jderose's use cases"?
<rbasak> cyphermox: lamont: also, under "Non-MAAS test cases", will it matter what the network responds with? In the IPv4 cases, we need to make sure that behaviour doesn't change whether or not IPv6 DHCP and/or radvd are present, so the status of the network should be part of the test case.
<rbasak> For ip6= I'm not so bothered, since existing users won't be using that.
<rbasak> cyphermox, lamont: final two points. 1) are the review fixes we landed in proposed in Xenial in Zesty yet? If not, they should be, and I expect to block release of the SRUs on this. I gave a pass at accepting into proposed only because we were so delayed already; we have time now.
<rbasak> cyphermox, lamont: 2) who's actually going to do all the verifications here? It seems to be that nobody is nominated right now, so I'm expecting it to run past the seven days right now, and I know lamont is in a hurry, so you should probably resolve that now.
<brendand> what exactly is the analog of --unbuilt-tree in latest versions of autopkgtest?
<brendand> is it just that i have to point to the debian directory itself rather than a directory that might contain one?
<tjaalton> mterry: could you test xvfb with bitdepth 16, if the qt tests would work then. proposed has xserver with modified xvfb-run, this fixed gtk apps at least
 * mterry tries
<mterry> tjaalton: I must be doing it wrong, I can't get -depth 16 to work with server-args -- what is the command line for xvfb-run?
<mterry> And should I upgrade to proposed xserver before testing?
<lamont> rbasak: from chatting with cyphermox yesterday, I was planning to do all the MAAS cases, and we were hoping to pick up some testing by some of the server team -- I expect I'll be doing some testing in those cases today, depending on all the various priorities.
<tjaalton> no need to upgrade
<tjaalton> mterry: -s "-screen 0 640x480x16"
<mterry> ah that last x
<mterry> Was x24 for me
<mterry> tjaalton: still segfaults if I switch it to x16 (from x24)
<tjaalton> hmm ok
<tjaalton> was 24 where?
<lamont> rbasak: radvd is kinda out-of-scope for the ipv4 testing, since (1) it's outside of the code we're changing, and (2) already changes behavior if present on an otherwise ipv4 network
<mterry> tjaalton: how we run the unity8 tests -- -screen 0 1024x768x24"
<tjaalton> alright
<tjaalton> i thought it used xvfb-run
<tjaalton> with it's defaults
<mterry> tjaalton: it does use xvfb-run but not with defaults
<mterry> tjaalton: I'm happy to set you up to run the failing test, if you want to reproduc
<lamont> rbasak: I'll be walking through the final (now in -proposed) changeset and making sure it's properly reflected in zesty, possibly via nagging :D
<tjaalton> mterry: there is a mesa commit bisected which is what made gtk apps fail, not sure if it'd help here. and i'm afk :)
<rbasak> lamont: I'm not aware of the server team having committed to doing any testing. We're all going on vacation over the next week or two.
<lamont> rbasak: it was more of a plea...
<rbasak> lamont: radvd> as long as it doesn't change behaviour differently in this SRU. If a user is using ipv4 but has radvd enabled, then does the SRU change that at all?
<mterry> tjaalton: ok then.  But maybe the segfault we're seeing now is a different bug than the gtk one?
<lamont> no change
<rbasak> lamont: zesty> thanks!
<rbasak> lamont: no change> have you tested that? :-)
<rbasak> lamont: you may alternatively convince me that it's not possible with this change. I'm open to that.
<lamont> if radvd is telling ipv6 to autoconf, then it autoconfs.  if it's not, and the machine has no non-link-local ipv6 address, then any side effect radvd may have is moot (ipv6 routes with no ipv6 source address is boring)
<tjaalton> mterry: yep, i believe it is
<lamont> that is, adding radvd to the network is a prereq for ipv6 netboot, but is otherwise completely orthogonal to the issues
<mterry> tjaalton: right, so when you're back at keyboard I can help you reproduce this specific, potentially new, issue
<lamont> having said that, the dual-stack (v4dhcponly) test has radvd running (and with autoconf) and the ipv4 test has no radvd and no dhcp6
<lamont> rbasak: if you insist, I'll do the test on the dual stack with dhcp4only and radvd not doing autoconf, but ...
<rbasak> lamont: sorry, otp
<lamont> np
<lamont> rbasak: (queuing things up again...) I'm not expecting testing to be complete today, and fridays seem to have a ban on SRUs hitting -updates, so it looks more like a monday landing, assuming the tests are all done, yes?
 * lamont laggy
<tjaalton> mterry: in about 6h, can write an email too
<rbasak> lamont: yes. If everything's done, then I can land first thing my time on Monday.
<chiluk> SRU Approval needed: arges, or any other SRU approver. it looks like my recent sru for virt-manager was applied to zesty and xenial, but forgetten yakkety. https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=virt-manager
<nacc> rbasak: caribou: thanks for the confirmation!
<caribou> nacc: rbasak: there is no work being queued on the zesty version so I think we should just revert it there too
<nacc> caribou: sounds good -- i was looking at the merge, will keep that in mind
<slashd> rbasak, I have share on the LP the work I have done so far, and here is the PPA "https://launchpad.net/~slashd/+archive/ubuntu/dhclientnoddns" if you are interested to test it... still looking at the release upgrade portion, again if you have any idea, let me know meanwhile I'm still looking
<rbasak> slashd: ack. otp right now. I have a note to look into this.
<slashd> rbasak, tks
<rbasak> slashd: and good job asking me on a public channel :-)
<lamont> rbasak: and confirmed that radvd interaction is as I stated
<lamont> rbasak: open-iscsi fix is present in x-p, and zesty... and waiting on an accept in y-p :p
<lamont> rbasak: it's a ways down the list, since it's 6 days old now.
<nacc> doko: are you planning on merging ldb? samba is going to depend on a newer version if we merge it, it seems
<fossfreedom> sil2100: Hi - I have fixed the failed ./run-tests on the merge request for lp:ubuntu-cdimage
<pdeee> RAOF, sorry it took a while, but we have proposed Xenial SRU packages for Certbot 0.9.3
<pdeee> https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978
<ubottu> Launchpad bug 1640978 in python-letsencrypt (Ubuntu) "letsencrypt 0.4.1 contains numerous bugs fixed upstream" [Undecided,Confirmed]
<tjaalton> mterry: hi, got your email, thanks. one question, have you tried with the old libgl somewhere and modifying LD_PRELOAD to match?
<mterry> tjaalton: no...
<tjaalton> mterry: maybe double-check that so that we're not chasing the wrong thing :)
<tjaalton> I haven't built it yet
<mterry> tjaalton: I'm not sure I understand how to do what you're asking
<tjaalton> grab the old pkg, unpack it in /tmp or something
<mterry> ah
<tjaalton> libgl1-mesa-glx
<mterry> tjaalton: I'm EOD in a minute, but I can try tomorrow
<tjaalton> ok, I can try it tomorrow
<foli> This it to notify the we are beginning maitenance on Canonical data centre firewalls.
* ChanServ changed the topic of #ubuntu-devel to: Canonical data centre firewall maintenance 23:00 - 00:00 | Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
#ubuntu-devel 2016-12-16
* ChanServ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<foli> The firewall maintenance is done now, all should be back.
<slangasek> rharper: LP: #1649931 - I note that the systemd unit being patched here is dropped in yakkety in favor of debian/extra/units/systemd-resolved.service.d/resolvconf.conf; did you consider whether we should do the same in xenial?
<ubottu> Launchpad bug 1649931 in systemd (Ubuntu Xenial) "systemd-networkd needs to ensure DNS is up before network-online.target" [Undecided,New] https://launchpad.net/bugs/1649931
<rharper> slangasek: if it's functionally equivalent, I'm fine with dropping the delta; looking at the systemd file in yakkety (232) it's not immeditately clear that this provides the ordering and dependencies that we're trying to achieve;
<slangasek> rharper: see my last comment wrt ordering
<slangasek> (last comment on bug)
<slangasek> but if this patch has already been sanity-checked, it's a smaller change; I'm happy to go with it
<jpleau> Hi. I maintain a package in debian, and someone asked for a newer version for Xenial. I'm going to setup a ppa for this, but I'm unsure what's the standard for versionning. If the version is 1.2.0-1 in debian, what would it be in my ppa for xenial?
<tumbleweed> another approach would be to backport the yakkety version to xenial
<tumbleweed> PPA versioning is up to you. I usually try to make backports I do in PPAs sort before official backports
<tumbleweed> ~ppa1 / ~yourppaname1 are reasonable suffixes
<sarnold> if it were going into the archive it'd probably something like 1.2.0-1ubuntu1.16.04.1  -- maybe instead of 'ubuntu' you'd use 'ppa' or something that'd still sort 'higher' than the debian version, lower than 'ubuntu' in case it were to be SRU'd back to xenial, and the 16.04 part lets you then push the same version to yakkety and on with 16.10 or 17.04 numbers later on...
<tumbleweed> that'll sort after an offical ubuntu backport
<sarnold> 1.2.0-1ppa1.16.04.1 would sort between the debian version 1.2.0-1 and an 'official ubuntu version' 1.2.0-1ubuntu1
<jpleau> okay, lots of good ideas here, thanks :)
<sarnold> I'm not sure if that's ideal or not :) your ~ppa proposal sorts the debian version higher. it might not matter. yours is certainly easier on the eyes. :)
<brendand> anyone ever seen the autopkgtest error:
<brendand> autopkgtest-virt-qemu: DBG: cleanup...
<brendand> qemu: terminating on signal 15 from pid 27417
<brendand> <VirtSubproc>: failure: timed out waiting for "login prompt on ttyS0"
<cpaelzer> brendand: yes I have seen that
<cpaelzer> brendand: in my case I was runnin on s390x where the default console is sclp
<cpaelzer> brendand: without special modification to the image after autopkgtest-buildvm I was not able to pass it
<cpaelzer> brendand: as it did not spawn anything on ttyS0 in its default config
<cpaelzer> brendand: now your case may be different, but it essentially means it doesn't spawn up a login on ttyS0 serial console
<cpaelzer> brendand: you might start the qemu image directly in qemu and see what might be going on
<brendand> cpaelzer, yeah actually it looks like it's shutting itself down. i'll have to debug it for sure
<mantiena-baltix> hi
<mantiena-baltix> Hi ricotz
<mantiena-baltix> Why Ubuntu LibreOffice packaging isn't in sync with Debian? I'm about bug #1635847 - only 2 lines in debian/rules
<ubottu> bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/1635847
<mantiena-baltix> ricotz: I see build errors with new LibreOffice 5.2.4 RC2 at ppa:ricotz/ppa , could you sync packaging code with Debian and fix bug #1635847 - only 2 lines in debian/rules ?
<ubottu> bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/1635847
<ricotz> mantiena-baltix, which ubuntu version are you using?
<ricotz> systray support is gtk2 only anyway, and gtk3 is used by default since 16.10/yakkety
<mantiena-baltix> ricotz: I'm using 16.04 LTS releases in all schools and other institutions which I support :)
<ricotz> mantiena-baltix, I see
<ricotz> mantiena-baltix, alright, noted
<mantiena-baltix> ricotz: and LibreOffice 5.1, which is by default in Ubuntu 16.04 LTS has critical bugs, like crash after table of contents is inserted, so, I installed LO 5.2.x from libreoffice PPA
<ricotz> mantiena-baltix, bugs which werent fixed with 5.1.6?
<ricotz> https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-5-1
<mantiena-baltix> ricotz: these bug wasn't fixed in 5.1.5, I didn't tested with 5.1.6, but users are happy with 5.2 except slow startup :)
<ricotz> mantiena-baltix, ok
<seb128> mantiena-baltix, hey, do you have a launchpad (or maybe upstream) bugreport about those LTS issues?
<ricotz> seb128, this is only ppa related, and systray support was dropped with 5.2.x
<seb128> ricotz, hey, I was speaking about "LTS has critical bugs, like crash after table of contents is inserted"
<seb128> which from my understand is about 5.1
<seb128> which is why mantiena-baltix installed 5.2
<seb128> which is fine, but I would still like to see the LTS bugs fixed :p
<ricotz> seb128, ah, yeah right, you know my opinion about bjÃ¶rn's update strategy ;)
<seb128> ricotz, yeah, he's on the conservative side, we should have got 5.1.6 by now, but it's not clear those issues are fixed in that version ... and updating a LTS to another major serie as 5.2 is a no go not only by Bjoern but by standard Ubuntu practice, users can get that from ppas or snaps if they want though
<ricotz> seb128, of course, I am only referring to the lack of 5.1.x updates which is 2 releases behind
<seb128> right, I'm not totally pleased with that as well :-/
<seb128> but now Bjoern is on holidays so it's going to have to wait for next year
<ricotz> snaps are simply circumventing the sru review process then to get updates ;)
<seb128> not really, it's rather a different option for users
<seb128> the Ubuntu releases and especially LTS versions focus on stability (in the sense of not creating regressions but also not changing the UI or workflow which would have an impact on a class of users)
<seb128> snaps make it easy for users to follow upstream updates if they want to
<ricotz> it will likely end up this way, when there are no updates for the archive packages
<seb128> they also make rollback easy in case of issues which deb don't do
<ricotz> right
<ricotz> alright, is story is getting old ;), g2g for now
<seb128> bye
<mantiena-baltix> seb128: Bug #1627874
<ubottu> bug 1627874 in libreoffice (Ubuntu) "Document crashes Libreoffice Writer" [Medium,Triaged] https://launchpad.net/bugs/1627874
<seb128> mantiena-baltix, thanks
<mantiena-baltix> seb128: I can't find reported bug about crashing when inserting table of content, because this bug appears not in all documents
<seb128> mantiena-baltix, ok, well if you find an example feel free to report it so we can try to SRU a fix to xenial
<mantiena-baltix> seb128: LO 5.1 is end of life since November 27, 2016, see https://wiki.documentfoundation.org/ReleasePlan/5.1
<mantiena-baltix> what is the reason to fix bugs in outdated release? I think it's better to backport LibreOffice 5.2.x to 16.04 LTS
<seb128> mantiena-baltix, not sure where you want to go with this info, 5.1 is the version in the LTS and we don't switch between major series so we need to maintain it even if upstream doesn't
<seb128> mantiena-baltix, there might be differences of functionalities/workflow/UI between major series and it's too much change for some of the corporate users (need to update company documentations, re-do training for staff etc)
<seb128> mantiena-baltix, we usually don't update to other series but fix issues, as an user you can opt it from 5.2 using e.g snaps (the snap is still new so might not be perfect but we are working on it and it should be a good way for users who want new versions to get those)
<mantiena-baltix> seb128: could you tell me if you plan sync LO packaging with Debian? at least 2 lines for bug 1635847 to be fixed?
<ubottu> bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/1635847
<seb128> mantiena-baltix, I don't know sorry but Sweet5hark should know, I'm going to ask him when he's around but I think he's on holidays since yesterday evening so that might be after the end of year now
<seb128> mantiena-baltix, I assigned him the bug with a comment
<mantiena-baltix> seb128: thanks
<seb128> yw!
<mantiena-baltix> seb128: I tought, that ricotz is responsible for building new LO releases in libreoffice PPA - I've noticed Rico name in changelog at https://launchpad.net/~ricotz/+archive/ubuntu/ppa/+packages
<mantiena-baltix> :)
<seb128> mantiena-baltix, Rico is working on the libreoffice ppa yes
<seb128> and contributing to the Ubuntu package I think
<seb128> but Bjoern is the maintainer of the Ubuntu version
<sil2100> hm, what are the criteria to consider an autopkgtest as 'Always failed'? Meaning: can I poke someone and convince them that the selected failure should be ignored?
<infinity> sil2100: Always failed means it's always failed. :)
<infinity> sil2100: (With the silly exception of linux-meta-triggered stuff, because handwavy reasons, and we track those elsewhere)
<infinity> sil2100: Regressions shouldn't be ignored without solid reason, but the release team are who you should poke if you think you have valid reasons.
<infinity> sil2100: Feel free to poke me and I'll look after I've found a bit of coffee/breakfast to fuel my day.
<infinity> sil2100: Nice timing on the ping timeout.  Are you actually here now? :)
<sil2100> Wow
<sil2100> eh, love those IP changes
<sil2100> Yeah, here now
<sil2100> infinity: I could potentially try to fix the package (or simply disable the failing tests), but not sure if it makes sense for a package that we'd likely just want to have removed?
<infinity> sil2100: Specifics are better than theory, here.  What package, what's wrong, why the argument for removal of package or ignoring of tests, etc.
<infinity> sil2100: You have unreleased changes on the xenial branch of livecd-rootfs.  Are you okay with those going out with the next SRU?
<infinity> cyphermox: ^--- And you didn't use the xenial bzr branch of livecd-rootfs with your last upload...
<infinity> cyphermox: Which might actually be okay in this case, because I suspect we want to punt that version from -proposed, given it was tied to the shim-signed update.  Concur?
 * sil2100 checks what changes those were
<sil2100> infinity: yeah, those are good to go
<sil2100> infinity: didn't release them as SRU yet as we had them on the -overlay already, but didn't want those to get missing
<infinity> sil2100: Ta.
<sil2100> infinity: as for the node-zmq thingy - so it seems the tests started failing after we uploaded the new zeromq3 (which shouldn't actually change anything), I looked at how Debian dealt with this and what they did is remove and deprecate the node-zmq package in overall in favor of the native zeromq3 bindings
<sil2100> infinity: at least that was what was written in the reason of removal: https://tracker.debian.org/news/822952
<infinity> sil2100: Oh.  "Removed from Debian" is all the reason we need for an Ubuntu removal, unless it has rdeps we're not willing to remove.
<sil2100> infinity: so I was opting for ignoring the test failure as I'm not sure if I should, in this case, invest time in trying to get the tests working again
<infinity> sil2100: So, that should have been your starting point on the conversation, not talking about tests. :)
<sil2100> Since the package is gone in Debian
<sil2100> Ah, ok, I was talking about tests as I didn't think deletion of a package is such an 'yeah, let's just do it. *done*' thing
<infinity> sil2100: "Ignoring the tests" is never the right answer.  But "remove the package entirely" can sometimes be, and very much is when it's removed from Debian and is a leaf package (both true in this case).
<infinity> sil2100: Bonus points that it's a leaf package that never shipped in an LTS, so I deeply don't care about upgrade paths either. :P
<infinity> sil2100: So, https://packages.qa.debian.org/n/node-zmq/news/20161210T172937Z.html would be the right thing to point at, and I'll JFDI the removal (doing now).
<sil2100> infinity: excellent, I guess package removal would fix my problem as well - do you know if when the node-zmq package gets removed, will britney notice that and just finally let the new zeromq3 out of -proposed?
<sil2100> Or does it need some manual tinkering for britney to forget about node-zmq?
<infinity> sil2100: britney might be a bit derpy about it, but I can massage it in.
<sil2100> infinity: thanks, for both ;)
<juliank> infinity: Didn't you say you want to look at unblocking apt 1.4~beta2 yesterday?
<infinity> juliank: Yeah, yesterday might be today.  It's on the list. :P
<infinity> juliank: Cleaning the pipes before the holidays for "important" packages (toolchain, kernel, apt, a few others) is on the very near TODO.
<juliank> infinity: You have to read it as said "[...]" yesterday :) - I just wanted to make sure it made it to your list :)
<juliank> infinity: A second report of the unattended-upgrade breakage came in today, I'm not sure if we should reconsider moving 1.3.3 from y-proposed to y-security (how often do unattended-upgrades run by default?)
<infinity> juliank: Ahh.  Today's English Lesson for German Speakers, then: "Didn't you say yesterday that [...]" is the usual way to ask that and get the linguistic order of operations correct. ;)
<juliank> Yeah, that makes more sense in German too :)
<infinity> juliank: Huh.  So, I'd expect all the unattended-upgrades fallout to have fallen out within 24h of the security update.  But I guess we didn't take into account people who turn off their computers (weirdos!) or people who aren't always connected to the internet (aliens?!).
<juliank> Right, it should do that daily
<juliank> But apt might delay that by 12 hours or so
<juliank> so 36 hours since the update came out seems reasonable
<infinity> juliank: Yeah, even with systemd jitter, everyone with 24/7 uptime should have hit the issue long ago.
<juliank> Right
<infinity> juliank: But those weirdos who turn on their computers twice a week or connect to the internet via strange whistling devices may be behind.
<juliank> heat is also low with 22/6
<juliank> yep
<juliank> And those are far more likely to run yakkety
<juliank> That is, yakkety users are probably mostly laptop users
<infinity> juliank: Probably still worth considering bouncing 1.3.3 to both updates and security, though.  Can you do a manual check on all binaries on all arches to make sure that's safe, so we don't have to rebuild in a hurry? :P
<infinity> juliank: I'm sure we can get the security team signoff to release it as a USN regression update if you deem it binary safe.
<juliank> Hmm, hwat I could do is do an installability test
<juliank> or rather, dependency satisfiability tests
<infinity> juliank: Yeah, given your deps (libstdc++, gnutls, etc), I trust that shlibs are sane and if it's installable, it's also not broken.
<juliank> Or I just compare deps against the 1.3.2ubuntu0.1 security upload
<juliank> They should be the same
<infinity> mdeslaur / sarnold : ^-- If juliank proves installability for apt 1.3.3 on all arches, any qualms about me releasing it to security as a USN regression fix?
<infinity> juliank: Yeahp, that would satisfy me.
<juliank> eww, lp does not show details for the binaries from the security release
<juliank> boo
<infinity> Downloading *ver*deb from pool/main/a/apt works. :P
<infinity> Then debdiff binaries.
<juliank> Diffing the build log works
<juliank> that includes all deps
<infinity> Diffing logs works too.  debdiffing debs is more readable, IMO, but also more bandwidth.
<sarnold> infinity: I missed the original problem..
<infinity> sarnold: Due to a bug in apt in yakkety, the security update in yakkety broke unattended-upgrades users.  The damage is done for those who are broken (and they needed a manual apt run to clean up), but there are still reports trickling in, which means some people still haven't upgraded (people with power or network cut off since the security update went out).
<juliank> sarnold: Installing the apt security update via unattended-upgrades kills u-a, breaking the upgrade, leaving system partially configured
<infinity> sarnold: To minimize future ick, the SRU should probably also be in security to eliminate the problem entirely.
<sarnold> ugh :/
<sarnold> yeah that sounds like a good candidate for a regression usn
<infinity> sarnold: So, the security update itself didn't technically have a regression, but it triggered a sleeper bug.
<infinity> sarnold: So, assuming installability is sane, any qualms about be releasing from -proposed, despite it not having been built in a security-only PPA?
<infinity> s/about be/about me/
<infinity> (ie: if it clearly has no deps from -updates, which it shouldn't)
<sarnold> infinity: that sounds fine -- granted, normally it's other people making the call, but I suspect "infinity says it's a good idea" would be sufficient :)
<infinity> juliank: Kay, do whatever diffing will satisfy us (on all arches), and make sure the bug itself is verified, and we'll push it as a asecurity update.
<infinity> juliank: And if said diffing fails, I'll quickly reupload it through a security PPA with a version bump.
<juliank> infinity: Actually not reproducing  it would be somewhat hard, but I checked the postinst only restarts the timer and not the service, I think that's enough
<juliank> 1.3.2: deb-systemd-invoke $_dh_action apt-daily.service apt-daily.timer >/dev/null || true
<juliank> 1.3.3: deb-systemd-invoke $_dh_action apt-daily.timer >/dev/null || true
<juliank> where _dh_action=try-restart
<juliank> The fix is old anyway, I just had not cherry-picked it yet :/
<yofel> what's the replacement for syslinux-themes-ubuntu in yakkety and above? Or are the images still using the xenial theme?
<slangasek> yofel: I would imagine we're just using the xenial theme; cyphermox or infinity might know more
<yofel> ok, thanks
<infinity> Yeah, looks like.
<juliank> infinity: I just wdiffed all the control file line in the build logs (greped for lines starting with " [A-Za-z_]:") and there were no changes apart from apt version numbers
<juliank> on all architectures
<infinity> juliank: Snazzy.
<infinity> juliank: Then Ima release that now.
<infinity> sarnold: I leave it up to you if you feel issuing a USN-2 is worth it to explain the new version popping into existence in the security pocket.
<sarnold> infinity: thanks
<infinity> juliank: Iz released (pending publication).
<juliank> infinity: neat
<sarnold> is this the best 'how to repair the damage' advice? "dpkg --configure --pending and apt-get -f install"
<infinity> sarnold: I tend to use dpkg --configure -a, but I suspect the end result is the samew.
<infinity> same, too.
<sarnold> infinity: thanks
<infinity> sarnold: Oh, and indeed, they're aliases now. :P
<infinity> sarnold: So, yeah, --pending is probably the better option as it's more verbosely obvious.
<infinity> sarnold: So, that tangent aside, yes, that sounds like the right advice to give people.  Perhaps add a sprinking of "sudo"s in there, if you feel your readers aren't super bright.
<sarnold> indeed
<infinity> sarnold: (And, because this bug manifests with a new default option for unattended-upgrades, you shouldn't expect people to be super bright :/)
<infinity> I wonder if unattended-upgrades or update-manager or both should also have a self-healing option that attempts to JFDI a --configure --pending and install retry.
<sarnold> that sounds like a good idea
<infinity> It's likely the one missing piece we have right now for flawless "my parents can do it" upgrades.
<infinity> Windows Update isn't much better here, mind you, I've been stuck in upgrade loops on Windows machines for weeks, but they do seem to have some way to force themselves out of it, and I'm pretty sure we don't.
<sarnold> will running the graphical updater fix things? it'd be nice to have instructions for hte folks unfamiliar with the terminal too
<sarnold> nod, I was thining of them, I think they released isos that just couldn't do unattended upgrades. ever. so people never upgraded...
<infinity> sarnold: Well, that's the "maybe update-manager should ..." bit.  Maybe it already does, and I'm not aware because I don't really use it.
<sarnold> it wouldn't take a big mistake to wind up in the same boat.
<infinity> slangasek: You use update-manager.  Do you know if it can force itself out of a broken configure by just trying again the next time it runs, or does it get stuck needing terminal love?
<infinity> I suspect this might be a "critical" bug we should have fixed 12 years ago. :P
<infinity> So, a curious definition of "critical".
<infinity> Oh, hey, look at that.
<infinity> update-manager (1:0.87.4) hardy; urgency=low
<infinity>   * DistUpgrade/DistUpgradeController.py, DistUpgradeCache.py:
<infinity>     - if dpkg was interrupted, run "dpkg --configure -a"
<infinity>  -- Michael Vogt <michael.vogt@ubuntu.com>  Fri, 25 Jan 2008 15:59:53 +0000
<infinity> Oh.  That might be the dist-upgrade bits, that moved to ubuntu-release-upgrader.
<slangasek> infinity: don't know; not sure I've seen it get into such a state locally
<pdeee> rbasak, any chance RAOF is out for the holidays?
<infinity> sarnold: Yeah.  update-manager doesn't do this.  Would be a valid wishcritical bug against u-m and u-a both, I think.
<infinity> critlist?
<slangasek> critlist.
<infinity> wishical.
<infinity> Really, if I had that 12 year time machine, I'd just have made Ubuntu require LVM on all installs and snapshotted all upgrades.
<infinity> Would have papered over so many bugs.
<infinity> Which is also the direction MS went when they realised they can never ship a perfect upgrade.
<infinity> (Though, they still retry the failed ones enough times to dive their users crazy)
<infinity> s/dive/drive/
<juliank> infinity: will 1.3.3 get deleted from proposed eventually, now that it's published in both updates and security, or do you need to nudge it first?
<infinity> juliank: It'll get deleted when our little scripty things tell us to.
<juliank> I see
<infinity> juliank: http://people.canonical.com/~ubuntu-archive/pending-sru.html -- See "proposed cleanup" at the end.
<infinity> (We don't do copy+delete in one operation because if the copy fails, it's entirely non-obvious... If we ever teach LP how to "move", then we'll be in business. :P)
<juliank> infinity: this page is really helpful
 * juliank has to remember that
<juliank> (I always wondered how to get a list of bugs that are not verified yet for an sru)
<rbasak> pdeee: he could be. Your guess is as good as mine.
<nacc> hrm, should we delete nagios3 from ubuntu? it's gone from debian unstable it seems (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845765)
<ubottu> Debian bug 845765 in wnpp "O: nagios3 -- host/service/network monitoring and management system" [Normal,Open]
#ubuntu-devel 2016-12-17
<dmj_s76> sgclark: It seems the Kdenlive has a missing critical dependency on 16.10.
<dmj_s76> Kdenlive crashes on startup unless the user manually installs the qml-module-qtquick-controls package.
<sgclark> due to work I have not packaged for Kubuntu in this release, will need to ping kubuntu-devel sorry
<dmj_s76> Could we get an updated package in the yakkety repo that includes the dependency.
<sgclark> xenial is the last release I packaged for. please ping kubuntu-devel
<dmj_s76> sgclark: Thanks
#ubuntu-devel 2016-12-18
<climber386> hi, i'm tring to rebuild ubuntu 14.04 LTS dvd-iso with new kernel 4.4.8 but when i boot i've got this error message "(initramfs) unable to find a medium containing a live file system". what's wrong?
#ubuntu-devel 2017-12-11
<Unit193> seb128: In regards to https://bugs.launchpad.net/ubuntu/+source/bittornado/+bug/1735346, http://torrent.ubuntu.com:6969/
<ubottu> Launchpad bug 1735346 in bittornado (Ubuntu) "bittornado: Python3 port needed, or demotion to universe" [Undecided,New]
<seb128> hey Unit193
<seb128> Unit193, I'm unsure what's your point there?
<Unit193> seb128: Mainly that bittornado is part of Ubuntu "infra", hence why it might be in main.  Best guess at least.
<seb128> Unit193, that might be an useful comment for the bug then, from my perspective it doesn't need to be on the iso, I don't know about IS use of it and what that means in support though
<Nafallo> pretty sure they use it.
<Unit193> I know they do, page says as much.
<seb128> the number of downloads/use is really low though, maybe they can close it :p
<Unit193> I never used the Py3 version of the tracker, by then I'd switched to opentracker (with udp support!), but I don't know if it does exactly what they want.
<Unit193> seb128: Not sure how much those numbers could be trusted, but having that tracker in there looks better than one that keeps changing and is used in all the latest pirated software. ;)
<Unit193> Anyway, FYI and all.
<seb128> Unit193, thanks, that's an useful info, can you comment on the bug about that?
<Unit193> If I must.
<Unit193> (I wasn't sure that was warranted.)
<seb128> Unit193, as you want, it might just help doko or others who care more than me about demoting python2
<Unit193> (I still have py2 only stuff, thus have a vested interest in keeping it around. :P )
<Unit193> (I posted a comment to the bug report.)
<seb128> (thanks)
<doko> Unit193: universe should be good enough for keeping it around
<doko> mwhudson: do you want a promotion for golang-1.9?
<doko> I assume same bug scubscribers as golang-1.8
<Unit193> I presume you are not addressing the Ubuntu torrent tracker with that statement, and in that case yes universe is (more or less) decent.
<doko> Unit193: but why not updating to the Python3 port?  exchanging a non-maintained package with a slightly maintained package sounds better
<Unit193> doko: Regarding bittornado specifically?  Yes I do use the py3 port, it's other stuff like Deluge and mini-dinstall which sadly aren't ready, or even started.
<cjwatson> I tried porting launchpad-buildd to Python 3 over the weekend.  It isn't quite workable on xenial (at least without some not entirely trivial backports), sadly.
<Unit193> Oh gah, https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1099537 too.
<ubottu> Launchpad bug 1099537 in ubuntu-dev-tools (Ubuntu) "ubuntu-dev-scripts should be ported to Python 3" [Medium,In progress]
<cjwatson> It's close, but twistd can't daemonise on Python 3 with twisted < 16.4.0.
<doko> is it worth thinking of a twisted backport, or update to 16.4 in xenial?
<Unit193> I suppose 'Convert Launchpad build system to pip' is still in progress.
<doko> or wait for bionic?
<doko> Unit193: I think the "in progress" might be out of date ;)
<cjwatson> In what sense is it out of date?
<Unit193> doko: I quite agree.
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/virtualenv-pip/+merge/331388
<cjwatson> doko: Yes, a backport might be an option
<Unit193> cjwatson: ubuntu-dev-tools port.
<cjwatson> Oh, right, there were multiple referents for "in progress".
<Unit193> Indeed.
<cjwatson> (Note that launchpad-buildd's use of Twisted is mostly independent from Launchpad's, and upgrading versions happens in entirely different ways.)
<Unit193> Speaking of, oh meh: https://github.com/twisted/twisted/pull/644 is still stalled.
<cjwatson> (Though not entirely; at least the bits of launchpad-buildd that are run from the LP test suite need to work with the version in the LP tree.)
<Unit193> That sounds fun to maintain..
<cjwatson> Unit193: Also I think we might need to fix https://twistedmatrix.com/trac/ticket/8831 in order to be able to upgrade further than Twisted 16.5.0.
<cjwatson> Unit193: Since https://twistedmatrix.com/trac/ticket/8079 will probably make ssh logins to codehosting and upload queues painfully slow otherwise.
<Unit193> Ouch.
<cjwatson> Unit193: I have a branch that mostly upgrades Launchpad itself to Twisted 16.5.0 now though; still some test failures to shake out but it's looking close.
<Unit193> cjwatson: Well that's great then!  The specific support I'm looking for isn't there yet, but in the meantime (apart from the chance of a slowdown), I'm sure that's good in and of itself, and makes future upgrades more possible, I'd wager.
<cjwatson> Indeed, I think we're close to being past the hideous upgrade hump.
<cjwatson> It's still all a bit "select exactly the right set of versions that works", but ...
<cjwatson> Since versions before 16.5.0 fail to install into LP's pip tree due to some setup.py oddities
<Unit193> Ah, that's the catch then.  OK.
<cjwatson> Well, I guess versions somewhere between 13.0.0 and 15.5.0.  Not exactly sure when it broke, but 16.5.0 fixed it.
<xnox> learned a new word today "facile"
<cyphermox> was it easy to learn?
<cyphermox> (sorry, I couldn't help it)
<xnox> cyphermox, i forgot it already =)
<cyphermox> ;)
<xnox> cyphermox, but Colin's email was interesting to read. I doubt i know how to pronounce "facile" correct or if I will ever use it myself, or remember what it means next time I encounter it (if ever)
<cjwatson> well to be fair it has several somewhat contradictory senses.  I meant sense 4 on wiktionary
<xnox> googling for "define facile" gave me the "ignoring the true complexities of an issue; superficial." definition, not sure which dictionaries/sources that uses.
<cjwatson> xnox: close enough
<cjwatson> (sometime in the last few years wiktionary got to the point where I'm happy to trust it as the dictionary of first resort, though.)
<rharper> is there a way to resolve virtual-packages from apt?  for example, linux-image-virtual, points to a specific package ?
<xnox> rharper, but linux-image-virtual is not a virtual package, but a real one.
<xnox> rharper, you can use dctrl-grep to inspect provides of the packages file?
<rharper> oh, huh
<rharper> I guess looking for the uname release string associated with the current version in the archive
<rharper> like 4.4.0-103-generic
 * rharper tries dctrl-grep
<cjwatson> (it's spelled grep-dctrl)
<rharper> thx
<mwhudson> doko: yes pls
<mwhudson> doko: golang-1.9-race-detector-runtime too
<doko> mwhudson: done
<mwhudson> doko: ta
<mwhudson> next step is demoting golang-1.8 i guess
<doko> once golang-1.9 moves to the release pocket
<mwhudson> (well immediate next step is waiting for britney)
<mwhudson> yeah
<mwhudson> rharper: some days i want to get business cards printed with "advanced grep-dctrl operator" on them
<rharper> mwhudson: lol
<jbicha> RAOF: ping
<RAOF> jbicha: Yo!
<RAOF> You might be wondering when I'll get to colord-gtk?
<jbicha> yes, I didn't know if you were around or not :)
<RAOF> Yup, I'm around.
<RAOF> I'll stop poking around the Mir build system to get ninja working and do my colord gardening now instead :)
<jbicha> ooh, meson is nice once someone does the work to get it working
<jbicha> I like how it helps make SRU diffs easier to read by getting rid of the autotools noise
<RAOF> It's still a bit annoying to set up.
<RAOF> Particularly - colord does a two-stage indep/arch-dep build, which is not well supported in debhelper at the moment.
<RAOF> Because meson differentiates between âinitial configurationâ and âchange configurationâ.
<juliank> jbicha: I always very carefully rebuilt apt stable updates with the same autotools version (well, in the target release) when they used autotools. glad I don't have to. not using meson yet, though, only cmake.
<juliank> Our build system was also directory order dependent, so if the directory entries were in a different order, the .po files were completely noisy.
<jbicha> RAOF: yeah, a lot of complicated GNOME modules haven't been ported yet https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
<juliank> I expect apt to switch to meson within the next 2 years too
<juliank> well, I hope.
<juliank> CMake is ugly.
 * RAOF wonders whether meson will be ugly when it's mature enough to support all of the complicated GNOME modulesâ¦
<juliank> RAOF: It will become the worst build system in existence eventually
<juliank> I don't like it using python.
<juliank> Adds more bootstrapping steps
<mwhudson> there is some competition there
<juliank> It's IMO better than autosetup, where everything is written in Tcl.
<juliank> neomutt uses that
<juliank> as does fossil, and jimtcl
<mwhudson> e.g. scons
<juliank> scons must be terrible
<juliank> I remember some projects using it, but I have not seen any recently
<mwhudson> i haven't used meson or autosetup or even cmake much
<mwhudson> but scons is pretty bad
<juliank> Oh, BTW: autosetup is just an autoconf replacement, it has no equivalent to libtool and automake
<juliank> CMake really sucks because (1) the syntax is crap and (2) you have all these Find<something>.cmake files
<juliank> Don't use pkg-config, write your own find code ...
<juliank> I don't understand at all why meson used if ... endif and not blocks like python. such a great chance to have readable code
<juliank> or a ? b : c instead of b if a else c
<juliank> That said, this is probably a terrible CMake script: https://anonscm.debian.org/cgit/apt/apt.git/tree/CMake/Documentation.cmake
<juliank> It's APT's docbook / po4a support.
<juliank> It's terrible.
<juliank> gettext integration is not much better.
#ubuntu-devel 2017-12-12
<dany197666666> hlp
<dany197666666> help
<dany197666666> pls~
<sladen> dany197666666: we would need to know the question first
<dany197666666> i have RTL8187SE
<dany197666666>  em wind its ok
<dany197666666>  but here im weak segnal
<sladen> dany197666666: is there a problem with the wifi connection?
<dany197666666> signal
<sladen> dany197666666: try moving slightly, or moving the machine closer to the access point
<sladen> dany197666666: or adjusting the antenna direction
<dany197666666> lol
<dany197666666> in wind e ok
<dany197666666> but here its weak
<sladen> dany197666666: wind doesn't normally affect wifi signals, just moisture in the air can, and so can other sources of interference ... like microwave ovens
<dany197666666> its de same place
<jamespage> pitti: scratching and itch - http://paste.ubuntu.com/26169731/ - does that look reasonable?
<jamespage> and what's the best way of getting that into the autopkgtest infra?
<jamespage> and/an
<jamespage> fingers ran away from me...
<pitti> jamespage: not sure any more, but I think we just run autodep8 from git; so best to file it as a Debian bug, Antonio is pretty quick in applying them
<pitti> then ask Laney to pull and re-deploy
<jamespage> pitti: ok will do
<jamespage> cjwatson: thanks for doing those allocations so quickly :)
<cjwatson> np
<TJ-> cjwatson: could you possibly provide some feedback (assuming you're still involved with the Debian package) at some point for my proposed patch for Bug #1737604
<ubottu> bug 1737604 in os-prober (Ubuntu) "30_os_prober: LINUXPROBED embedded spaces in kernel parameters generates false menuentry's" [Undecided,Confirmed] https://launchpad.net/bugs/1737604
<cjwatson> TJ-: wow, that's profoundly unpleasant, but perhaps it's required.  Could you also please handle escaping inside double quotes correctly?  The syntax docs are https://www.gnu.org/software/grub/manual/grub/grub.html#Quoting
<cjwatson> (we probably can't handle expansions there, but could at least manage escaping)
<cjwatson> TJ-: also it might be worth using   printf %s "$title_raw"   rather than   echo "$title_raw", for a bit more safety against e.g. titles that start with a "-" inside the delimiters
<juliank> Ugh: /var/lib/docker/nuke-graph-directory.sh: 64: /var/lib/docker/nuke-graph-directory.sh: shopt: not found
<juliank> ah bug 1724353
<ubottu> bug 1724353 in docker.io (Ubuntu) "cannot purge docker.io due to a bashism in nuke-graph-directory" [Medium,Triaged] https://launchpad.net/bugs/1724353
<cjwatson> TJ-: and ... I'm a bit confused by $1 being used in some places and $line in others, and it makes me wonder: I know that menuentry is documented such that the title is always the first arg, but is that actually required?  the old code seems to tolerate it coming later
<juliank> So, can I use sbuild with lxd via the autopkgtest stuff?
<TJ-> cjwatson: thanks, I'll look at that. I got slightly lost inside those sed expressions and focused on the single-quote one.  I used 'echo' because the original code did. I used $1 since the parent code had already shifted the arguments but it can use $line without issues too, I think.
<TJ-> cjwatson: re: menuentry 'title' order... I assumed from looking at both forms of the sed expressions that the unwritten assumption is that there will only be one pair of quote marks so it's OK to capture anything between first and last quote
<cjwatson> TJ-: Right, but you're using $1 and thus assuming that the title will come first.
<TJ-> cjwatson: Yes, based on the docs which show 'title' as a non-option first arg of menuentry.
<cjwatson> TJ-: Right.  As I said above, I know that the docs say that but it is not entirely clear to me that that's enforced; if it's not, then there may be config files in the wild with a different ordering.  Needs checking.
<TJ-> cjwatson: right, so it might be safer to locate the first ' or " ?
<cjwatson> TJ-: Yeah
<TJ-> cjwatson: but if it's out of order that wouldn't help either :s
<cjwatson> It'd be no worse than what's there now, at least?
<TJ-> cjwatson: currently " beats ' anyhow
<cjwatson> s/.*\(['"]\).*/\1/  or some such
<cjwatson> with the usual unpleasant quoting
<TJ-> cjwatson: I was trying to ensure both have an equal chance of being used first :)
<cjwatson> er except that first .* will be greedy
<cjwatson> s/[^'"]*\(['"]\).*/\1/
<TJ-> yes, the lack of a non-greedy operator for sed is often frustrating
<cjwatson> I don't think it's possible to do much better than that without a full parser
<TJ-> cjwatson: What I'll do is create some test-cases with all the permutations I can think of and modify it so it can deal with them all, hopefully without complicating it too much more!
<cjwatson> sounds good.  maybe at some point I'll have time to get further with my rewrite of os-prober
<TJ-> cjwatson: I think title has to be first: grub-core/commands/menuentry.c::grub_normal_add_menu_entry() => menu_title = grub_strdup (args[0]);
<cjwatson> TJ-: But that is after option parsing, which may rearrange things.
<TJ-> cjwatson: Glad you're the grub master, not me!
<cjwatson> Not really any more, but I remember a few things :-)
<TJ-> cjwatson: although I can't think of a way in which the title could be elsewhere and still get passed as the first arg to that function :) title has to come before {command;...}, and the --options are separated into their own pointers/arrays
<TJ-> cjwatson: thanks for the feedback; I'll get those tests created and then modify the code as required
<cjwatson> TJ-: I'm pretty sure that title could come after the options and still work.  The arg parser will parse out the options and remove them from the resulting args array.
<cjwatson> But you can try it.
<TJ-> cjwatson: I will :)
<tsimonq2> xnox: I'm currently prepping Qt 5.9.3 in Bileto, would you like me to grab Fedora's OpenSSL 1.1 support patch and include it with the transition?
<tsimonq2> xnox: I'd just need help with testing it works, as I'm not familiar with OpenSSL.
<juliank> I don't entirely understand why I should add root:1000:1 to /etc/subuid when I want to remap my uid to the same in an lxd container as https://insights.ubuntu.com/2016/12/08/mounting-your-home-directory-in-lxd/ says - it works fine without?
<xnox> tsimonq2, no, please don't.
<xnox> tsimonq2, we do not have openssl1.1 in the archive, and probably will not have it soon. Compared with others, we can consider qt done already, despite it being unpatched in the archive.
<teward> hmm... I think Quilt is fubar... somehow.  The system says that there's new unhandled changes in the source code... but it's as a result of Quilt patching.... not sure how to fix the issue.
<rbasak> jbicha: OOI, any particular reason you're syncing mongodb 3.4 from experimental? I'm looking at the mongodb package from a Juju perspective, so wanted to understand the current needs for that package before making any recommendations.
<jbicha> rbasak: I synced it from experimental for LP: #1595242, maybe you should ask the Debian maintainer what's keeping it from unstable
<ubottu> Launchpad bug 1595242 in MongoDB Charm "mongodb xenial s390x packages are needed (blocks ceilometer)" [Undecided,Confirmed] https://launchpad.net/bugs/1595242
<rbasak> Ah. THanks!
<rbasak> balloons: ^
<rbasak> jbicha: also, just to be clear, you have no other specific use case apart from general archive maintenance?
<jbicha> right, I don't use mongodb
<rbasak> Eg. there's a request for mongodb 3.6, which is released upstream but not in Debian.
<rbasak> OK, thanks. So I don't need to involve you in that conversation then?
<rbasak> I'll file in Debian BTS.
<jbicha> yeah, 3.6 looks like it would be good for 18.04 LTS: https://www.mongodb.com/support-policy
<balloons> rbasak, gotcha
<balloons> rbasak, note the upstream arch support is present in 3.4, so that version does work, assuming we can support it, etc
<rbasak> balloons: OK. So we don't actually need 3.6?
<balloons> rbasak, no, it's not a hard requirement; as John noted 3.4 actually had the arch support that was a driver. 3.6 is still a nice to have and may be easier to support, but not required
<balloons> it has more implications for juju as well; more changes
<rbasak> OK thanks
<balloons> rbasak, we spoke about having the js engine be enabled / disabled as part of the package, as well as having the service start or not. Do you have a handle on the work required to tweak the existing 3.4 package to do this?
<rbasak> balloons: JS engine tweak should be relatively easy, but I think that's unacceptable for the generic mongodb package.
<rbasak> balloons: not having the service start: ideally you'd split the package like we did in MySQL. Not much effort but it is a pain to maintain a delta. I don't know if the Debian maintainers would take it.
<rbasak> You could use policy-rc.d to override, but if Juju doesn't "own" the system and has other tenants, that might break some user expectations. But the policy-rc.d mechanism, assuming the package isn't buggy, should be quite straightforward to implement in Juju.
<mwhudson> morning
<tsimonq2> xnox: ack
<tsimonq2> Morning mwhudson :)
<dax> jbicha: i happened to be talking about xchat-gnome elsewhere and noticed your bug report from 10 minutes ago
<dax> jbicha: as someone without any dev insight at all... i don't know why ubuntu still has that package at all
<dax> afaict its main accomplishment seems to be confusing users into using an irc client with no bugfixes since 2014 instead of, say, hexchat
<jbicha> well, seb128 uses xchat-gnome ð¤·
<dax> oh is that who's keeping it alive
<jbicha> I don't think I would go that farâ¦
<jbicha> xchat-gnome at least uses gtk3 https://github.com/hexchat/hexchat/issues/2047
<dax> oh, i lie, it's getting bugfixes, the date part of the version string just isn't being changed
<dax> (i assume because changes are getting picked and backported)
<mdeslaur> I've been fixing it also, until it got removed and forcing me to switch to hexchat
<mdeslaur> but I'll probably be switching back since it's gtk3
<dax> does it have sasl or any of the other various important changes from hexchat?
<dax> 'cause it didn't last time i looked, and this was saddening
<mdeslaur> the codebase is pretty similar, so it should be relatively trivial to fix that if it doesn't
<RAOF> jbicha: If you would very kindly upload colord-gtk to Debian that would be a kindness.
<mdeslaur> I'd rather hexchat switch to gtk3 though
<dax> same
<jbicha> RAOF: can I bump its debhelper compat to 10 first?
<RAOF> jbicha: Sure. I was going to do that myself, but then decided that I didn't need any of the changes.
<RAOF> I guess with compat level 10 we could drop the autoreconf sequence from the `dh` invocation.
<jbicha> RAOF: all done
<RAOF> Rad.
<RAOF> I might see if I can trouble you to upload a new colord later, as well, but colord-gtk ended up taking longer than I thought :)
#ubuntu-devel 2017-12-13
<rbasak> bdmurray, xnox, klebers: I don't understand why we're SRUing bug 1734908. It seems to have no user impact?
<ubottu> bug 1734908 in systemd (Ubuntu Artful) "systemd-rfkill service times out when a new rfkill device is added" [High,Fix committed] https://launchpad.net/bugs/1734908
<rbasak> Additionally the Regression Potential and SRU verification process seems to have made no consideration for how to test or verify that rfkill hasn't otherwise regressed by this patch.
<rbasak> So I'm reluctant to release it.
<klebers> rbasak, hi. Sorry, I mentioned the network-manager testcase issue but didn't state what would be the issue for a user. The user impact is that network-manager can report the wrong status of the rfkill device.
<klebers> rbasak, regarding regression with rfkill, the rfkill doesn't have debian autopkgtests, but it's used on the same network-manager testcase so it's indirectly tested, at least on that scenario
<rbasak> klebers: thanks. That sounds like it should be SRU'd then. Can we verify that part of the fix though then please? That network-manager now does report the correct status of the rfkill device? Or is the autopkgtest already covering that?
<rbasak> klebers: and in your opinion then, are the autopkgtests sufficient to test general regressions in the area of rfkill, or is further manual testing needed?
<klebers> rbasak, that network-manager autopkgtest already covers these tests and I verified that with that fix it now reports the correct status.
<klebers> rbasak, regarding rfkill coverage, it has four commands: event, list, block and unblock. The last three are covered by that testcase, only event is not. I can run some manual tests to check if the behavior of this command is affected.
<rbasak> klebers: thanks. I'm happy to trust your judgement on whether that is needed in relation to this particular patch. But I'd prefer that your judgement be documented so that it's clear that the testing that is and isn't performed is an informed decision rather than an omission. That's what the Regression Potential section is for.
<klebers> rbasak, I will run some more manual tests and add all these additional information to the bug report. Thanks for the thorough review.
<xnox> rbasak, i was not at all involved in that sru. /me is out
<klebers> rbasak, I have run some manual tests with rfkill and added the information we discussed here to the bug description. Please let me know if anything else is needed.
<rbasak> klebers: thanks! That looks good and I'm satisfied with SRU verification. There are some autopkgtest failure still, including systemd amd64 which seems quite important as it's worked in the past. I've just retried that one.
<klebers> rbasak, thanks!
<doko> mwhudson: tracking the golang-defaults induced autopkg test failures?
<doko> jamespage: ujson needs a MIR (ceilometer)
<jamespage> doko: on my list
<jamespage> just digging into why ovs fails on i386 for artful and bionic...
<mdeslaur> cpaelzer: are you planning on merging virt-manager soon? Can I do it?
<cpaelzer> mdeslaur: you can do if you need, but due to the need to build against latter libvirt (which takes some more time) I planned to do it after libvirt
<cpaelzer> mdeslaur: but if you do a merge now you certainly will lower the amount of diff I have to cross when I get to it in ~Feb
<mdeslaur> cpaelzer: oh! I'll wait then, thanks
<cpaelzer> mdeslaur: if your only concern is "have it updated in 18.04" let it be mine
<mdeslaur> cpaelzer: I have a bug fix I want to SRU into artful...so either I merge bionic, or add the bugfix to bionic
<mdeslaur> cpaelzer: but now I'm confused...it requires a newer libvirt?
<cpaelzer> mdeslaur: ok, then add the bugfix for now if that is ok
<mdeslaur> cpaelzer: ok, thanks
<cpaelzer> mdeslaur: being not C but python it isn't that hard, but better to do the rebuild
<rbasak> infinity: missing SRU paperwork for bug 1730627, but also, do we really need to SRU this? Is being able to debootstrap Bionic from Trusty important?
<ubottu> bug 1730627 in dpkg (Ubuntu Trusty) "xz compressed control.tar files not supported" [Medium,Confirmed] https://launchpad.net/bugs/1730627
<rbasak> We don't support an upgrade from Trusty to Bionic directly, so why do we need to support a debootstrap?
<jamespage> doko: https://bugs.launchpad.net/ubuntu/+source/ujson/+bug/1737989
<ubottu> Launchpad bug 1737989 in ujson (Ubuntu) "[MIR] ujson" [Undecided,New]
<xnox> rbasak, oh yes we do need that; because we do have clients/deployments that use trusty in production still, and do need/want to create/debootstrap bionic based chroots and docker images.
<xnox> rbasak, kernel-wise, these trusty machines that do that, most often run the xenial-lts kernel; which also is expected to be able to execute things in bionic chroots after those have been debootstrapped.
<rbasak> OK
<rbasak> That should be in the SRU paperwork
<rbasak> Unrelated: what's the canonical Ubuntu way to detect the currently running init system?
<rbasak> roaksoax: in bug 1732703, I'm not sure that test for systemd is reliable. For example immediately after an upgrade from Trusty to Xenial, before a reboot, /sbin/init will be systemd but the running init system will be upstart.
<ubottu> bug 1732703 in MAAS 1.9 "MAAS does not detect properly if Ubuntu is using upstart/systemd" [Critical,In progress] https://launchpad.net/bugs/1732703
<rbasak> roaksoax: AFAICT, the "correct" way to test for systemd is its process name or something, but I can't find a good reference.
<rbasak> roaksoax: so I'm not really sure what is correct. I'll happily accept whatever a systemd-type person here says.
<cjwatson> There should be something in one of the init script layers
<cjwatson> /lib/lsb/init-functions.d/40-systemd
<cjwatson> if [ -d /run/systemd/system ]; then
<rbasak> Ah
<cjwatson> I believe that's the canonical method
<rbasak> I recalled something about something in /run but was unable to find it.
<rbasak> Thanks
<cjwatson> rbasak: Found the documentation for that - sd_booted(3)
<cjwatson> under NOTES
<rbasak> Perfect!
<roaksoax> rbasak: i dont understand why upgrading from trusty to xenial in the said patch matters ?
<roaksoax> rbasak: the path is for 1.9, not for xenial
<roaksoax> rbasak: the path is for 1.9, which does not run in xenial
<roaksoax> and maas 2.x, in xenial, always uses systemd
<roaksoax> rbasak: that code path no longer exists in 2.x
<roaksoax> that said, MAAS currently checks for "/run/systemd/system", but that's proven not to be effective
<roaksoax> hence, the bug report
<colinl> hello folks :)
<colinl> I'm dropping by to make sure I did everything correctly, regarding a patch I'd like to see backported to Ubuntu : https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1714518
<ubottu> Launchpad bug 1714518 in gtk+3.0 (Ubuntu) "GTK+3 doesn't show FUSE/GVFS, smb (SMB/CIFS), sftp (SFTP/SSH) network shares in file chooser" [Low,In progress]
<colinl> (last comment)
<LocutusOfBorg> jbicha, ^^ :)
<colinl> (ping seb128, IIRC you were interested in that bug)
<colinl> hi LocutusOfBorg and thanks :)
<seb128> colinl, I'm adding it to my queue but I'm currently busy with something else, going to have a look later
<rbasak> roaksoax: sorry, I didn't realise that you were already testing that
<rbasak> Does that mean there's a bug in init-system-helpers because it uses the same test?
<colinl> thanks seb128 :)
<colinl> seb128: if/when it goes in, I'll submit one for 16.04 :)
<cjwatson> I question why testing for /run/systemd/system wouldn't be effective; I've never heard of that existing when systemd isn't the running init system, and I think any such occurrence deserves to be tracked down quite vigorously
 * rbasak is trying to reproduce
<jbicha> colinl: you need to backport to the newer Ubuntu releases (17.10 and 17.04) at the same time or before
<colinl> jbicha: will do, then :)
<rbasak> Installing snapd on Trusty does indeed create /run/systemd/system/
<cjwatson> is this possibly a snapd bug then?
<rbasak> It looks that way. I see snapd.postinst gating on the existence of the directory though, so I don't yet know where it is getting created.
<cjwatson> Since this is the documented method for testing whether systemd is running, I think there's a compelling case for leaving MAAS (and init-system-helpers) the way it is and fixing whatever's breaking it.
<cjwatson> It shouldn't be particularly widespread breakage.
<rbasak> cjwatson: snapd depends on systemd. Installing systemd on Trusty when upstart is running starts a "/lib/systemd/systemd --system" (looks like upstart manages that) and that creates /run/systemd/system.
<rbasak> Is it a bug that snapd depends on systemd?
<rbasak> The systemd package on Trusty ships a /etc/init/systemd.conf
<rbasak> description "run systemd deputy init"
<rbasak> pre-start exec mkdir -p /run/systemd/system
<cjwatson> Hm.  I'm not sure of the documented semantics for the weird deputy systemd thing in trusty
<cjwatson> Foundations may need to work something out there and figure out how it aligns with all the stuff that's following the systemd documentation ...
<cjwatson> I wonder if it's possible to configure the deputy systemd to use some other /run subdirectory (but that may have other problems)
<cjwatson> There are variant "dsystemd" paths used for cgroups
<rbasak> It looks like snapd is using the deputy systemd to manage its daemons
<cjwatson> xnox: ^-
<cjwatson> Yeah, the deputy systemd was introduced specifically for snapd
<cjwatson> https://bugs.launchpad.net/ubuntu/trusty/+source/systemd/+bug/1656280
<ubottu> Launchpad bug 1656280 in systemd (Ubuntu Trusty) "Support installing subordinate systemd on Ubuntu Desktop 14.04.5" [High,Fix released]
<seb128> jbicha, colinl, I wouldn't bother SRUing to zesty at this point
<cjwatson> I think this discovery about its /run/systemd/system behaviour demonstrates that some of the claims in that bug report don't quite hold up
<xnox> rbasak, yes that is all true; one can run snapd and snaps on trusty; with systemd package; and lts-xenial kernel installed; there is a branch for that.
<xnox> cjwatson, rbasak - i believe on trusty we do not create /run/systemd/system and have it patched to use alternative path names.
<rbasak> xnox: that's not true AFAICT. See the upstart snippets I pasted above.
<xnox> ditto on trusty it does _not_ use /lib/systemd/system nor /etc/systemd/system
<xnox> haha
<xnox> well
<rbasak> /etc/init/systemd.conf explicitly creates /run/systemd/system
<xnox> I inherited that code.
<rbasak> What's the right way to fix this?
<xnox> i guess we must create that, as things launched by snapd must detect/think that it is running under systemd as pid 1, but not really.
<rbasak> Do we treat it as a bug in systemd in Trusty, and not in maas then?
<jbicha> seb128: I guess that depends on who on the SRU Team is doing the review :/
<cjwatson> It looks to me like we've patched some of the paths to be different, but not that one
<seb128> jbicha, the requirement to SRU to non-LTS-non-current to upload a fix to the LTS is boggus imho
<cjwatson> If we change maas, I think the change should be confined to trusty rather than leaking to later releases (which don't have this deputy systemd stuff); but hopefully there's some way to change systemd instead to avoid the problem ...
<jbicha> seb128: interestingly, it is not mentioned at https://wiki.ubuntu.com/StableReleaseUpdates as far as I can see
<xnox> rbasak, my hunch is that said path should have been patched; or at least be created in a namespace not visible in the general system. But i fear we cannot use mount namespaces due to classic confiment snaps.
<xnox> rbasak, please open the bug report, and or point me to an existing one, to hack on it. I cannot commit to deliver it before end of year; as I'm end of year on friday.
<xnox> rbasak, cjwatson - the maas check; for the purposes that it needs it for; as indicated in the merge proposal; is adequate.
<rbasak> xnox: thanks. It's bug 1732703. I'll add a systemd task.
<ubottu> bug 1732703 in MAAS 1.9 "MAAS does not detect properly if Ubuntu is using upstart/systemd" [Critical,In progress] https://launchpad.net/bugs/1732703
<xnox> rbasak, commented on the bug report.
<xnox> rbasak, i'd rather see maas ship the proposed fix in https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/334930 or e.g. compile maas on trusty in such a way that does not introduce systemd management code at all.
<xnox> rbasak, e.g. when cloud-init was getting backports, it was excluding systemd support as a compile time / configure option.
<slangasek> cjwatson, xnox, rbasak: I recall that we *did* evaluate moving /run/systemd/system to a different path as part of that SRU, and concluded that it wasn't a viable approach
<xnox> ack, thanks. I have limited history about that thing.
<slangasek> yeah unfortunately that's as much detail as I remember off the top of my head.  If folks think we should be changing the path, I can try to dig into history
<rbasak> xnox: it feels to me that the MAAS fix in the queue is the worst of both worlds right now.
<rbasak> Hardcoding for upstart would be one way, which is essentially what you say.
<rbasak> That would be less error prone I think, as any further disruption to systemd in Trusty wouldn't be able to affect anything.
<rbasak> I think that we need to decide what the "official" way of detecting systemd is. And make that work. Or accept that Trusty is broken. But there should be a general answer for Trusty least, and then MAAS should do that.
<rbasak> If the general answer is "there's no reliable way; always assume upstart on Trusty" then we can hardcode MAAS to do that.
<xnox> rbasak, i think hard-coding to use upstart on trusty is the right way forward; trusty is messed up in many ways with like systemd-services and the deputy systemd as we like migrated to logind but not the rest of it.
<xnox> rbasak, and on things later than trusty, the canonical check is to check for /run/systemd/system directory presense.
<rbasak> xnox: this may have broken tools like puppet on Trusty too :-/
<mwhudson> doko: yes
<doko> LocutusOfBorg: was there a specific reason that you dropped the new b-d's for graphviz instead of proposing main inclusion of these packages?
<bdmurray> mdeslaur: IIRC you wanted me to look at some debdiffs in bug 1574670. Is there any chance you could submit a bionic MP so it'd be easier to comment on?
<ubottu> bug 1574670 in update-manager (Ubuntu Artful) "ubuntu-support-status returns inaccurate information" [High,Confirmed] https://launchpad.net/bugs/1574670
<bdmurray> mdeslaur: ah, nevermind
#ubuntu-devel 2017-12-14
<doko> rbasak, jamespage: please could you give some advice on libapache2-mod-python ? do we need a python3 package in parallel, or can we drop the python2 package?
<doko> rbasak, cpaelzer: is there a need for platform.bionic/supported-misc-servers: * graphviz ?
<cpaelzer> doko: rbasak: graphviz was added long before my time, as far as I can see it is in since the beginning
<cpaelzer> I looked around in bugs and bzr but found no statement why it was added
<cpaelzer> rbasak: do you have more history of this in your memory?
<cpaelzer> it is back from http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.hardy/revision/125
<cpaelzer> and moved several times due to restructures since then
<cpaelzer> it was back then added to Desktop => other
<cpaelzer> I'd assume it was moved incorrectly since then
<cpaelzer> doko: rbasak: your opinion what to do now?
<LocutusOfBorg> doko, ehm... context? graphviz?
<doko> LocutusOfBorg: what else, that was part of the original message here
<LocutusOfBorg>     - Build without gts support since the library is still in universe
<LocutusOfBorg>     - Don't build-depend on libann-dev since it's in universe
<LocutusOfBorg> you mean this, right?
<doko> yes
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/graphviz/2.38.0-15ubuntu1
<LocutusOfBorg> this is the first time gts has been disabled
<LocutusOfBorg> and this the first time libann-dev has been disabled https://launchpad.net/ubuntu/+source/graphviz/2.38.0-16ubuntu1
<LocutusOfBorg> both are jbicha ^^
<doko> ahh, ok, then the question goes to somebody else ...
<doko> cpaelzer: my assumption is that the seed wasn't reviewed after we don't require b-d's in main anymore ...
<cpaelzer> doko: sounds reasonable
<cpaelzer> of the current b-d's to graphvis the following are in main and might have been the old reason it was added apt, corosync, doxygen, dpkg, gcc, imagemagick, pacemaker, schroot
<cpaelzer> none has it as real depends or recommends
<cpaelzer> I'd guess it can be reomved, but then of you rbasak and me I'm clearly the least experienced
<cpaelzer> rbasak: your opinion on the graphviz question by doko?
<JEBjames> Is there an eta on the 18.04 daily server getting fixed (tar extract bug fails install)?
<JEBjames> I have a script I run that can manually work around it when the install errors out but it's kind of a pain.
<jibel> could someone have a look at bug 1723198 ? it's breaking the upgrade from 14.04 to 16.04
<ubottu> bug 1723198 in dpkg (Ubuntu) "upgrade from 14.04 to 16.04 fails with: ca-certificates 20170717~16.04.1 failed to install/upgrade: triggers looping, abandoned" [Critical,Confirmed] https://launchpad.net/bugs/1723198
<eoli3n> Hi
<eoli3n> when using kickstart with netboot of 16.04, it's not possible to use sfdisk in %pre section
<eoli3n> if i understand well, problem is that busybox for netboot install have not be compiled with parted fdisk or sfdisk. Problem is that thoses tools are installed by debian-installer before proceding installation.
<eoli3n> So when %pre is executed, debian-installer has not run yet
<cjwatson> you can't do that sort of thing in %pre, indeed, but you could do it by using the 'preseed' extension directive to set partman/early_command to the text of a script that calls sfdisk
<eoli3n> and sfdisk, etc are not present. is there any way to get sfdisk working in %pre section of a kickstart installation ?
<eoli3n> cjwatson: i did
<cjwatson> since partman/early_command runs somewhat later, just before the partitioner starts
<eoli3n> ahhhh EARLY !
<eoli3n> i didn't found it, lets try
<eoli3n> lets try : http://sprunge.us/eRHH
<cjwatson> I am not sure that a file name will work there.
<cjwatson> Checking.
<eoli3n> cjwatson: you're a god... i'm fighting with kickstart since 5 days...
<eoli3n> it worked
<cjwatson> Oh, yeah, I guess it will, it'll be passed to sh -c and that'll exec it.
<cjwatson> Excellent
<eoli3n> i did set shebang in script
<eoli3n> lets go eating, maybe i will come get a bit more help later
<eoli3n> thx a lot cjwatson
<cjwatson> np
<sil2100> coreycb: hey! Could you make sure LP: #1731595 is verified? I guess the artful openstack stack would be good to release 'all together', but this one neutron bug is not verified
<ubottu> Launchpad bug 1731595 in neutron (Ubuntu Xenial) "L3 HA: multiple agents are active at the same time" [High,Triaged] https://launchpad.net/bugs/1731595
<eoli3n> so cjwatson
<eoli3n> here is my kickstart file : https://ptpb.pw/2fun
<eoli3n> the early partman command works
<eoli3n> problem is that installer still prompting for manual partitionning
<eoli3n> i removed clearpart
<eoli3n> it seems that when no clearpart --all is set, it keeps prompting
<cjwatson> eoli3n: I'm not sure I sufficiently understand what your sfdisk thing is for - you're trying to override some limited bit of the installer's partitioning code, I think?
<eoli3n> cjwatson: i need sfdisk to overwrite the partition table, and let partman use first partition as a windows one, without erasing it
<eoli3n> it that case
<eoli3n> if windows is already there, its not broken
<eoli3n> and if not, partition is initialized
<eoli3n> is there anyway to perform an automatic installation without setting clearpart --all ?
<eoli3n> clearpart --linux dont work too
<eoli3n> doesnt
<cjwatson> clearpart --all basically just turns into preseeding partman-auto/disk, and without that the automatic partitioner won't run
<eoli3n> problem is that it initialize a fake partition table to be sure to destroy all datas
<eoli3n> in redhat documentation
<cjwatson> I think you need --onpart or --usepart to be implemented in our Kickstart implementation, but they're not
<eoli3n> ah ok !
<eoli3n> it is
<eoli3n> but i can't mix --onpart, and part
<eoli3n> maybe
<cjwatson>                         --onpart|--usepart|--ondisk|--ondrive|--start|--end)
<cjwatson> the RH documentation is not necessarily accurate for Ubuntu; we've implemented a compatibility layer
<cjwatson>                                 # TODO: --ondisk/--ondrive supported with LVM
<cjwatson>                                 warn "unsupported restriction '$1'"
<eoli3n> hm, so your point for now, is that i need to write all partition table with sfdiks
<eoli3n> sfdisk
<cjwatson> https://help.ubuntu.com/lts/installation-guide/amd64/ch04s06.html#kickstart documents the differences
<cjwatson> no, I don't think that would work either
<eoli3n> and use only --onpart
<cjwatson> no
<eoli3n> hm
<cjwatson> --onpart is unimplemented
<eoli3n> ah !
<eoli3n> should i use preseed commands here ?
<cjwatson> right, I think you'll need to do that
<cjwatson> figure out the necessary partitioning recipe in preseeding language, and drop down to that
<eoli3n> cjwatson: where can i read that ubuntu kickstart implementation does not support --onpart ?
<cjwatson> mm, it's possible the documentation doesn't say that.  I implemented all this to start with but I no longer work on it ...
<eoli3n> ah so i found the right dev, good point
<cjwatson> I looked it up in the code to refresh my memory
<eoli3n> i don't know how works preseed, it seems a bit harder
<eoli3n> ok so lets preseed
<cjwatson> https://help.ubuntu.com/lts/installation-guide/amd64/apb.html
<cjwatson> in particular https://help.ubuntu.com/lts/installation-guide/amd64/apbs04.html#preseed-partman
<eoli3n> oh thx
<cjwatson> and you may need to refer to https://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=blob;f=doc/devel/partman-auto-recipe.txt;h=bc8b541c59b319147db652f8db01f5c4f427b249;hb=HEAD for detailed recipe syntax
<cjwatson> I probably can't help very much more.  If you still run into trouble you may be able to find other people in #ubuntu-installer who are more current
<coreycb> sil2100: all set i've marked that bug as verified for artful
<eoli3n> cjwatson: just something to clarify, if i use partman preseed, must 'clearpart --all' be set for an automatic install ?
<cjwatson> eoli3n: not if you separately preseed partman-auto/disk
<michael-vb> Afternoon.
<michael-vb> apw: I believe that you are in charge of the vbox* guest modules in the Ubuntu kernel packages?
<michael-vb> I am wondering how easy it would be for you to update the versions in supported Ubuntu distributions.  The newer the better of course, but the versions in the current mainline kernel would do too.  We had an ABI break after 5.1.
<cjwatson> eoli3n: oh and also partman-auto/method will probably need to be preseeded to 'regular'
<cjwatson> sorry, forgot about that bit
<eoli3n> cj i just did, i'm searching for a way to set vars with dialog installer, then get my recipe string
<michael-vb> Of course, our upstream/out-of-tree versions might make your life easier, as the code is intended to build on older kernels.  They carefully stripped that out of the mainline ones.
<eoli3n> cjwatson:
<cjwatson> I don't know what you mean by "set vars with dialog installer"
<eoli3n> install manually with keyboard
<cjwatson> please note that you cannot use the interactive installer to work out a recipe
<eoli3n> not writing the recipe
<eoli3n> ah
<eoli3n> sad :/
<cjwatson> it is a bit unfortunate, but there you go
<eoli3n> thx for information
<jbicha> LocutusOfBorg: vbox discussion ^
<michael-vb> jbicha: he knows.
<michael-vb> Thanks.
<michael-vb> It was follow-up from #vbox-dev.
<eoli3n> cjwatson: its a bit tricky with generators but it still prompt, it should not : https://ptpb.pw/B40N
<eoli3n> cjwatson: oh wait
<eoli3n> sorry for that, didn't read doc until end :/
<cjwatson> gonna have to redirect you to other people in #ubuntu-installer for anything more, I'm afraid
<eoli3n> huhu ok, thx a lot for your help
<cjwatson> (not sure whether anyone else is around at the moment, but should be eventually ...)
<doko> xnox: none of the URL's in amd64-microcode's copyright file are working. are you aware of working links?
<xnox> ha
<michael-vb> apw: have to go.  Would you be able to e-mail regarding the above?  michael dot thayer at oracle.  Thanks!
<coreycb> sil2100: would you have a chance to look at releasing bug 1734990 today? it has some critical fixes, including CVEs.
<ubottu> bug 1734990 in nova (Ubuntu Artful) " [SRU] pike stable releases" [Undecided,Fix committed] https://launchpad.net/bugs/1734990
<sil2100> coreycb: thanks! Yeah, if it's marked as ready then let me release that in a moment
<Laney> apt resolver question...
<Laney> ...given this https://paste.ubuntu.com/26183841/ preferences file (generated by autopkgtest)
<Laney> would you expect to be able to install python3-distutils from bionic + bionic-proposed atm?
<Laney> The following packages have unmet dependencies: python3-distutils : Depends: python3 (>= 3.6.3-2) but 3.6.3-0ubuntu2 is to be installed
<Laney> i.e. it doesn't want to select bionic-proposed's python3
<doko> rbasak: do you agree about dropping graphviz from the seeds?
<coreycb> sil2100: thanks!
<doko> Laney: yes, I would expect that
<Laney> I can install it if I add python3/bionic-proposed explicitly
<Laney> basically, halp
<doko> if it helps, I can lower the python3-distutils : Depends: python3 (>= 3.6.3-2) requirement
<Laney> I suppose it would, or we can queue with an extra trigger on python3-defaults
<Laney> Would like to understand why apt doesn't want to select -proposed's python3 though
<Laney> Broken python3-distutils:amd64 Depends on python3:amd64 < none -> 3.6.3-0ubuntu2 @un puN > (>= 3.6.3-2) Considering python3:amd64 10003 as a solution to python3-distutils:amd64 10004
 * Laney will requeue the tests
<rbasak> dpb1, kirkland: ^ can we drop graphviz from the seeds?
<doko> ok, afk now, maybe upload yourself when needed. it should be safe (tm) ...
<doko> RAOF: are you uploading things for the mir transition?
<jbicha> doko: btw, it looks like you'll need to drop some imagemagick -dev pkgs to universe in order to demote src:graphviz
<doko> jbicha: hmm, where is the dependency?
<doko> I only see it in B-D-I
<rbasak> doko: FTR, I'm fine with dropping graphviz if kirkland and dpb1 are happy.
<doko> ok, let's wait
<jbicha> doko: libmagickcore-6.q16-dev depends on libgraphviz-dev for instance but there are a few more related ones
<doko> wondering why ... I'll have a look. there are no b-d's ...
<dpb1> rbasak: What does it gain in dropping?
<dpb1> doko: any idea why it was in the seed to begin with?  seems like a very odd package to be installed by default
<doko> # libgraphviz-dev, incompatible license against fftw
<doko> dpb1: no, as others noticed, it's a very old seed
<rbasak> dpb1: I can only defer that question to doko really. doko: what does it gain in dropping?
<rbasak> ~ubuntu-server wouldn't have to maintain it once demoted, but I presume there's another reason you're asking?
<dpb1> so, take it out of the seed *and* out of main, I guess you are asking
<jbicha> doko: cool, obsolete dependency then :)
<rbasak> dpb1: that's correct. Though in theory our team declares what we want to explicitly keep in main as part of our product via the seeds. So from our perspective it's both. Do we need it in our product as a top level item?
<rbasak> From my POV that's what doko is asking us.
<jbicha> graphviz showed up in our gtk2 demotion list, also we diverge from Debian because a few graphviz features require universe deps
<doko> rbasak, dpb1: we still need it as a b-d for packages in main, so if things fail we have to fix it anyway. but we don't officially support it. yes, and one more step towards GTK2 demotion
<dpb1> ok, that goal I agree with
<dpb1> doko: +1
<dpb1> doko: kirkland is traveling, might be best to email him so this isn't lost
<sil2100> cpaelzer: hey! Do you plan on merging exim4 in the nearest days again?
<sil2100> cpaelzer: asking since I saw you did the last merge, and the new version in Debian removes the lynx-cur dependency that is needed to get rid of an NBS
<sil2100> It's always best to just fix this with a merge to have two birds with one stone
<mdeslaur> so what's the latest with debug packages? If I have a package that has a delta to generate a -dbg, do I drop that and do the --dbgsym-migration ?
<mdeslaur> or do I just carry the delta and keep the -dbg?
<slashd> slangasek, infinity o/ I've been told you might be able to help or at least get me started on how to approach the following bug : LP: #1733018. (dpkg: cycle found while processing triggers:) thanks in advance.
<ubottu> Error: Launchpad bug 1733018 could not be found
<slashd> sorry ^ LP: #1723198
<ubottu> Launchpad bug 1723198 in dpkg (Ubuntu) "upgrade from 14.04 to 16.04 fails with: ca-certificates 20170717~16.04.1 failed to install/upgrade: triggers looping, abandoned" [Critical,Confirmed] https://launchpad.net/bugs/1723198
<slangasek> slashd: infinity is out.  I can give you general pointers wrt trigger cycles, but I don't know what all we have or haven't done to resolve this in later releases - for that, best to look at the history of the relevant packages, or ask doko or tdaitx
<slangasek> slashd: basically the main change that fixes trigger cycles is to change them into noawait triggers; those keywords should be enough to let you find details e.g. how to implement in a package, minimum version of dpkg required in order to support them
<slashd> slangasek, ack will look at this, thanks much it definitely unblock my troubleshoot
<slangasek> slashd: I would also suggest investigating why ca-certificates-java is being removed on upgrade, considering it was manually installed
<slashd> slangasek, ack
<slashd> slashd, much appreciated thank you
<slashd> slangasek, ^
<slangasek> n/p
<slashd> slangasek, yeah I see that 1.16 should suffice to have the implementation (considering nothing after is needed) I'll look at this too thanks  "cf6b98d dpkg: implement "interest-noawait" and "activate-noawait" trigger commands"
<slangasek> slashd: ok, I couldn't resist digging a little more.  the root cause of the removal is ca-certificates-java in xenial Depends: openjdk-7-jre-headless (>= 7~u3-2.1.1~pre1-1) | java7-runtime-headless; java7-runtime-headless is provided by openjdk-8-jre-headless, but this will not cause apt to install openjdk-8-jre-headless on upgrade when openjdk-7-jre-headless is already installed;
<slangasek> openjdk-7-jre-headless is only available in trusty, and has a dependency chain on an obsolete version of tzdata, so apt forces removal of tzdata-java -> openjdk-7-jre-headless -> ca-certificates-java
<slangasek> slashd: sruing ca-certificates-java in xenial to explicitly prefer openjdk-8-jre-headless as the first alternative may be sufficient hint to the package manager for this upgrade to work correctly
<slangasek> the circular trigger dep will still be there, but side-stepped
<slashd> slangasek, looking
<slashd> slashd, I see what you mean
<slashd> x/ca-certificates-java-20160321/debian/rules:				-Vjre:Depends="openjdk-7-jre-headless (>= 7~u3-2.1.1~pre1-1)"
<slashd> x/ca-certificates-java-20160321/debian/rules:				-Vjre:Depends="openjdk-7-jre-headless"
<slashd> slashd, I check and test that, thanks a lot
<slashd> slangasek, I check and test that, thanks a lot
<RAOF> doko: Ooof. I forgot that we had rdepends ð. Thanks for the ping!
<ahasenack> hm, I'm looking at a PR in github that splits a big shell script into submodules (https://github.com/CanonicalLtd/ubuntu-advantage-script/pull/92#discussion_r157047936 FTR)
<ahasenack> and I made a comment about this change:
<ahasenack> +modules/* usr/share/ubuntu-advantage/modules
<ahasenack> the package name (deb) is ubuntu-advantage-tools
<ahasenack> I asked if that directory should be named ubuntu-advantage-tools instead of just ubuntu-advantage as in the PR
<ahasenack> is there a policy about this?
<rbasak> ahasenack: that's an archive admin question really. I'd say that you should stick to /usr/share/<binary package name> to avoid conflicts.
<rbasak> Though if it's /usr/share/<ubuntu something> then I suppose there's very low likelyhood of a conflict with any other project we're likely to package
<ahasenack> rbasak: did you see his reasoning in the reply?
<JEBjames> is there an ETA on fixing Ubuntu 18.04 server/Lubuntu-alternate (re: busybox/tar glitch since November 30th breaks install)
<JEBjames> I have a work around but it's pretty cludgy and breaks my auto-install testing.
<sarnold> JEBjames: that sounds like https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1737662
<ubottu> Launchpad bug 1737662 in The Ubuntu-power-systems project "Unable to install ubuntu1804 build with Debootstrap warning on witherspoon system" [Critical,Fix committed]
<rbasak> ahasenack: I answered there to save splitting the conversation
<JEBjames> sarnold: That sounds great!
<JEBjames> I'll retest again tomorrow.  Thank you.
<RAOF> doko: Hm. *What* Mir transition? As far as I can tell we no longer have any rdepends?
<RAOF> And it has happily migrated out of proposed...
#ubuntu-devel 2017-12-15
<doko> Laney: do you still need the python3 workaround?
<Laney> doko: do you think we can get it migrated quite soon or not?
<Laney> doko: problem is if somebody clicks retry on these packages it breaks again
<Laney> so maybe it would be useful :(
<doko> ok
<Laney> thanks!
<lapisdecor> How can someone contribute with a wallpaper to the next Ubuntu release?
<jibel> lapisdecor, there is a thread on the community hub https://community.ubuntu.com/t/call-for-feedback-free-culture-showcase-for-ubuntu-18-04/1548
<lapisdecor> jibel, Thanks!
<TJ-> cjwatson: When you have a moment, re: os-prober. I've got menuitem parsing code passing this set of tests so far; can you think of any other permutations it needs to pass? http://iam.tj/gitweb/?p=os-prober.git;a=blob;f=tests/linux-boot-probes/boot/grub/grub.cfg;h=2abf486abe018a30eda1581f09faa6b8ee70e56a;hb=064a7e40c5efd7cdea6fac2b18c7af8156da194d
<cjwatson> TJ-: Maybe some cases of escaping inside double quotes too.
<TJ-> cjwatson: You mean, as in menuentry "title \\escaped slash" ... ?
<cjwatson> Yeah, that kind of thing
<cjwatson> \$ and \" too
<TJ-> cjwatson: OK... after so many I lost track of what I was trying to prove :)
<TJ-> The good news is one  --long-- sed expression will do it, athough I have it broken up into individual lines for now to aid debugging
<eoli3n> cjwatson: a last last question please :) i can no set clearpart, and it works with zerombr, but i need to unset zerombr, without prompting for manual partitionning... is there any way with preseed, to set something which could make automatic install without zerombr in kickstart ?
<eoli3n> i can fix it, by dd of=mbr.bin in %pre, and dd if=mbr.bin in post... but it's dirty
<cjwatson> zerombr does nothing in Ubuntu kickstart
<cjwatson> zerombr_handler () {
<cjwatson>         # partman already initialises partition tables when it needs to do
<cjwatson>         # so.
<cjwatson>         return
<cjwatson> }
<eoli3n> yep but without zerombr, it prompt for manual partitionning
<eoli3n> ah
<eoli3n> forget what i just said
<eoli3n> cjwatson: where is the code of ubuntu kickstart hosted please ?
<cjwatson> eoli3n: apt-get source kickseed
<eoli3n> thx cjwatson
<eoli3n> cjwatson: --log for %pre and %post, seems not implemented too
<cjwatson> maybe, haven't checked
<cjwatson> like I say, I haven't worked on this for years
<cjwatson> so there isn't much point telling me about missing things
<eoli3n> yep, i get it
<crogers> Blah. Line spacing of text in inkscape seems to be at an all-time horrible. :)
<crogers> Can't seem to change the line spacing on thi text no matter what I do: https://www.dropbox.com/s/wwtmtj7y0gixguy/bad_text_behaviour.svg?dl=1
<crogers> Just completely broken.
<crogers> Ah, click the question mark.
<sil2100> cjwatson: hey! Do you know where merge-o-matic is running? On what machine?
<cjwatson> sil2100: shedu
<doko> mdeslaur: https://launchpad.net/ubuntu/+source/subversion/1.9.7-3ubuntu1/+build/13856328
<mdeslaur> doko: thanks
<sil2100> cjwatson: hmmm, is that something one can get easy access to?
<slashd> slangasek, I have found a potential issue with the openjdk-8 depend for ca-certificates-java pkg. Can you please review my comment when you have a chance, I'd like to have your opinion on this --> LP: #1723198 (comment #16) to choose the best approach.
<ubottu> Launchpad bug 1723198 in ca-certificates-java (Ubuntu Zesty) "[SRU] upgrade from 14.04 to 16.04 fails with: ca-certificates 20170717~16.04.1 failed to install/upgrade: triggers looping, abandoned" [Medium,In progress] https://launchpad.net/bugs/1723198
<sil2100> cjwatson: or maybe differently - I wanted to tweak a bit on the stats we get from m-o-m, and just looking into what I should do if I were to get something delpoyed
<cjwatson> sil2100: Happy for you to be added to the relevant team - file an RT and I can follow up acking it
<cjwatson> sil2100: it's the "merge" Unix group
<doko> xnox: is the intel-microcode somewhere seeded like the amd64 one?
<sil2100> cjwatson: thanks! Will poke around :)
<xnox> doko, yes
<xnox> ./ubuntu.bionic/ship-live: * intel-microcode      # needed to update Intel cpu microcode LP #1386257
<xnox> ./ubuntu.bionic/usb-ship-live: * intel-microcode      # needed to update Intel cpu microcode LP #1386257
<xnox> ./ubuntu.bionic/server-ship: * intel-microcode # needed to update Intel cpu microcode LP #1386257
<ubottu> Launchpad bug 1386257 in amd64-microcode (Ubuntu) "intel-microcode should be installed by default, when the CPU is GenuineIntel" [Medium,Confirmed] https://launchpad.net/bugs/1386257
<doko> xnox: I don't see it in component-mismatches
<xnox> doko, because it was in restricted since xenial....
<xnox> doko, and now slangasek is pushing to move it from restricted to main, in a bug report.
<doko> ahh
 * Pharaoh_Atem waves at jbicha
<jbicha> happy Friday!
<Pharaoh_Atem> heh
<Pharaoh_Atem> jbicha: I was surprised to see you pop up in yet another one of my package reviews
<jbicha> oh, sorry
<jbicha> honestly, I don't really get involved in Fedora much, but it was linked to from https://github.com/EmojiTwo/emojitwo/pull/167
<slangasek> slashd: interesting that this is a behavior difference; we actually *would* want it to pull in openjdk-8-jre-headless by default instead of -9- in xenial, since 9 is in universe and 8 is in main.  It is a behavior change that we should call out as part of the SRU (i.e. "regression potential"), but I don't consider it a blocker for the SRU
<slashd> slangasek, thanks for everything
<slashd> slashd, uploaded for Xenial and Zesty. tks
<slashd> slangasek, ^
<smoser> hey. so looking for some sru team member feedback.
<smoser> i have some bugs i'd like to sru for cloud-initramfs-tools.  I basically want to sync what is in bionic to xenial, zesty, artful.  its all SRUable fixes.
<smoser> the one thing that isnt is new package 'rooturl'
<smoser> would sru scoff at that? it makes it easier on my part, basically making all the same, and a new package doesn't easily add any regressions.
<smoser> err... sorry, not rooturl. new package that woudl go in is cloud-initramfs-updateroot
<jbicha> doko: btw, see LP: #1728329
<ubottu> Launchpad bug 1728329 in freetype (Ubuntu) "Update freetype to 2.8.1" [Wishlist,Triaged] https://launchpad.net/bugs/1728329
<jbicha> I set block-proposed weeks ago in case someone updated it early :)
#ubuntu-devel 2017-12-16
<jbicha> tumbleweed: reverse-depends hasn't updated since Wednesday
<clonne101_> hello friends
#ubuntu-devel 2017-12-17
<ahasenack> hi, can a package have a build-dep that's only available in the backports pocket in a particular ubuntu release?
<ahasenack> assuming the package itself is not in backports
<tsimonq2> ahasenack: iirc, no, but I could be wrong.
<rbasak> ahasenack: I agree with tsimonq2.
<tsimonq2> rbasak: Well, I think *should* it is a different question than *can* it. I think the answer should be no on both counts, but I don't remember if backports was enabled even when apt pinned at a lower value on the builders.
<rbasak> tsimonq2: you can build it. For example you can enable backports in a PPA. But it isn't acceptable for the archive.
<tsimonq2> rbasak: Hm, alright. Out of curiosity, was this ever formalized anywhere or is it just an unspoken rule?
<rbasak> I think Launchpad won't permit such a package to end up in the archive unless you're an archive admin.
<tsimonq2> Hm, ok.
<tsimonq2> Would you happen to know if I could test something like this on staging.launchpad.net?
<rbasak> I don't know.
<tsimonq2> Alright, thanks rbasak.
<rbasak> But I'm curious to know the answer :)
<tsimonq2> Same :)
#ubuntu-devel 2018-12-10
<ahasenack> is it acceptable for an ubuntu main package to have a recommends on an universe package?
<ahasenack> in this case, depending on the configuration of the main package, that universe package might or might not be required
<ahasenack> it's a plugin that can only be built and used with the universe package installed
<ahasenack> the main package has many plugins, it's just one of many. All the others link to something in main, but this particular one, if enabled, would need universe
<seb128> no, it's not
<mdeslaur> it can be a suggests, but not a recommends
<mdeslaur> (IIRC)
<ahasenack> debian has it as a recommends
<ahasenack> it's samba-vfs-modules, and the universe package is glusterfs-common
<mdeslaur> you need to either move the plugin to a universe package, or stop building that particular plugin
<ahasenack> https://salsa.debian.org/samba-team/samba/blob/master/debian/control#L304
<ahasenack> right now we don't build it
<ahasenack> but I keep getting bugs asking to enable it
<ahasenack> there is a mir, let me check
<ahasenack> it was nacked
<ahasenack> https://launchpad.net/bugs/1274247
<ubottu> Launchpad bug 1274247 in glusterfs (Ubuntu) "[MIR] Glusterfs" [High,Won't fix]
<mdeslaur> and you can't make it a suggests instead of a recommends?
<ahasenack> I suppose I could change our current delta, which is to not build it, to make it a suggests
<mdeslaur> ie: if you build the module, and glusterfs-common isn't installed, will samba still work?
<mdeslaur> ie: the module is disabled by default anyway, right?
<ahasenack> mdeslaur: it will as long as you don't use the glusterfs module in smb.conf
<ahasenack> yes, it's not loaded by default
<mdeslaur> right, so make it a suggests instead of a recommends
<ahasenack> so our delta would change from "drop gluster support" to "add gluster support as a suggests"
<mdeslaur> right, or "move gluster recommends to suggests as it is in universe"
<mdeslaur> whoever wants to use it just needs to install the missing package, but at least the module is built and availabe
<mdeslaur> available
<ahasenack> well, needs to know about it
<ahasenack> there will be an error in the logs, smbd won't start, that kind of thing
<mdeslaur> better than not having it at all ;)
<ahasenack> I can check these conditions, but would an error be acceptable, if the module is used and gluster isn't installed?
<mdeslaur> add something to the news file
<mdeslaur> I think it's reasonable since the module isn't enabled by default
<seb128> or split it to a new binary which is going to be in universe and have that depends on glusterfs-common?
<mdeslaur> that's another possibility
<ahasenack> yeah, something like samba-vfs-modules-glusterfs
<ahasenack> would be a bigger delta from debian
<ahasenack> thanks for the brainstorm
<mdeslaur> np
<rbasak> cjwatson: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-universe doesn't have the build-depends against universe update.
<rbasak> Would you like a bug filed? :-P
<cjwatson> Sure
<rbasak> Is there a LP project for it?
<cjwatson> rbasak: https://launchpad.net/ubuntu/+source/ubuntu-policy
<cjwatson> I'd be happy for somebody to take it over and merge it up
<cjwatson> Should be gitified too
<rbasak> Thanks!
<ahasenack> tjaalton: hi, the landscape-client sru uploads you rejected, can the new upload with the fix use the same version? I think it can, bceause the package never made it to proposed
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1699179 for an example
<ubottu> Launchpad bug 1699179 in landscape-client (Ubuntu Xenial) "PackageReporter kicks in during do-release-upgrade" [Medium,In progress]
<ahasenack> Laney: that autopkgtest upgrade you mentioned in your email to ubuntu-devel@, does that apply to what bileto is using too?
<Laney> yes, there is but one place
<tjaalton> ahasenack: yeah I think so
#ubuntu-devel 2018-12-11
<RAOF> Grumble grumble, stupid things which build locally but not in launchpad...
<RAOF> Grumble grumble, things which die with unresolved symbols when the thing they're linking with clearly exports that symbolâ¦
<RAOF> ?!?!?!
<RAOF> â¦
<RAOF> /usr/bin/ld: CMakeFiles/OpenColorIO.dir/OCIOYaml.cpp.o: in function `YAML::BadSubscript::BadSubscript()':
<RAOF> /usr/include/yaml-cpp/exceptions.h:122: undefined reference to `vtable for YAML::Exception'
<RAOF> objdump -T libyaml-cpp.so.0.6  | c++filt | rg Exception
<RAOF> â¦
<RAOF> 0000000000068968  w   DO .data.rel.ro	0000000000000028  Base        vtable for YAML::Exception
<LocutusOfBorg> hello
<LocutusOfBorg> [12:13:03] <LocutusOfBorg> question about mariadb, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/ppc64el/m/mariadb-10.1/20181210_180330_7ad79@/log.gz
<LocutusOfBorg> [12:13:22] <LocutusOfBorg> the testsuite is now mostly good, except for ppc64el where this test fails
<LocutusOfBorg> [12:13:39] <LocutusOfBorg> they insert into a table this value: 0.6158
<LocutusOfBorg> [12:13:50] <LocutusOfBorg> and this check fails:  where key1 <= 0.6158 and key2 >= 1.3762;
<LocutusOfBorg> [12:14:00] <LocutusOfBorg> because the stored value is:
<LocutusOfBorg> [12:14:01] <LocutusOfBorg> -0.6158000230789185
<LocutusOfBorg> [12:14:01] <LocutusOfBorg> +0.6157999634742737
<LocutusOfBorg> [12:14:08] <LocutusOfBorg> any clue? should I just don't care?
<LocutusOfBorg> [12:14:22] <LocutusOfBorg> I'm asking here because we have glibc folks :)
<tkamppeter> Any systemd expert could help me on bug 1807930? After an update of cupsd cups-browsed does not get started again.
<ubottu> bug 1807930 in cups (Ubuntu) "cups-daemon upgrades stop cups-browsed and leave it stopped" [Undecided,New] https://launchpad.net/bugs/1807930
<Laney> bdmurray: yo, do you think it'd be possible to not filter out Fix Released bugs for the rls bugs reports?
<Laney> bdmurray: otherwise, I don't know how we can nominate bugs to stable series when they're fixed in devel
<bdmurray> Laney: I'm not following the logic there
<Laney> ok
<Laney> we tagged https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1805444
<Laney> it doesn't show up
<ubottu> Launchpad bug 1805444 in mutter (Ubuntu) "[nvidia] Fail to launch gnome-shell (Wayland) on Ubuntu with EGLDevice backend" [Medium,Fix released]
<Laney> I presume that's because it is Fix Released
<bdmurray> doesn't show up on which report?
<Laney> rls-bb-incoming bugs
<bdmurray> well, its tagged rls-bb-notifixing and not rls-bb-incoming
<Laney> that was 1 minute ago
<bdmurray> okay, I get it. I'll have a look and see how many bugs end up being added to the report.
<Laney> thanks :>
<coreycb> doko: can you remind me in what release will py2.7 will be moved to universe?
<coreycb> doko: there's one lingering project (Swift) that doesn't have py3 support
<coreycb> so just communicating with them
<doko> coreycb: if possible, in 19.04, or latest then 19.10
<coreycb> doko: thanks
<jbicha> bdmurray: could you do a ubuntu-release-upgrader upload for disco (fixes an autopkgtest failure)?
<bdmurray> jbicha: I was working on a host of changes as it is so yes
#ubuntu-devel 2018-12-12
<ahasenack> given these test results from bileto, is there a way to trigger another run with different options? https://bileto.ubuntu.com/excuses/3531/disco.html
<ahasenack> like the retry icon, when it fails, but in this case it didn't fail, so no such icon
<ahasenack> I need to retry symfony/3.4.20+dfsg-1ubuntu2~ppa2 armhf with disco-proposed
<Laney> ahasenack: retry-autopkgtest-regressions --bileto 3531 --state PASS --series disco
<ahasenack> thanks
<Laney> probably should get retry-autopkgtest-regressions to not put stable-phone-overlay in there
<ahasenack> Laney: the "session cookie", is that from bileto.u.c in this case? Or autopkgtest.u.c, even though I'm retrying a bileto run?
<Laney> ahasenack: there's just one, on autopkgtest.ubuntu.com
<ahasenack> ok
<cpaelzer> HIho, this just yesterday built in a ppa, now the build in armhf for d-propsoed says "Chroot problem" and it seems to be a networking issue
<cpaelzer> https://launchpad.net/ubuntu/+source/strongswan/5.7.1-1ubuntu2/+build/15768264
<cpaelzer> is this a "retry and forget" issue or is there something bigger going on?
<ahasenack> hah, just because I just managed to trigger a retry on armhf? :)
<ahasenack> my luck :)
<cpaelzer> I don't want to hit rebuild as it would flush the logs unless someone says that is ok
<cpaelzer> ahasenack: you mean it can only retry for you or build for me
<cpaelzer> well then let me hit rebuild and break yours :-P
<ahasenack> I'll know sometime later today
<cpaelzer> this is the log http://paste.ubuntu.com/p/2KytF4zPd9/ so I can hit rebuild ...
<ahasenack> cpaelzer: hm, I've seen that dns issue a few times in the past few days
<cpaelzer> ahasenack: on armhf in particular, or in general?
<ahasenack> can't remember that detail
<ahasenack> but I saw it in some build log
<cpaelzer> the rebuild seems to have passed that stage, so no permanent issue
<teward> remind me how to run an autopkgtest locally in an lxd environment then enter the environment when it fails so I can better examine what's goin on?
<teward> been a while since I had a regressed autopkgtest :|
<Laney> --shell-fail
<teward> Laney: thank you :)
<teward> huh... so that's weird
<teward> Laney: autopkgtest on the system that runs the tests fails, but local autopkgtest for the same test and package succeeds... should I just retry the tests on the CI system then?
<Laney> teward: dunno, depends on what the failure is and whether it's likely to be flaky tests (which should also be fixed)
<Laney> or if you didn't manage to recreate the conditions that make it happen
<teward> Laney: it's weird because it looks to me like fcgiwrap was working locally, but not up on CI - 502 bad gateway would indicate fcgiwrap didn't work properly :|
<Laney> some kind of race?
<teward> probably.
<teward> trying to diagnose the nginx autopkgtest 'regression' state on fcgiwrap
<teward> and 502 gateway timeout is fcgiwrap being stupid and not replying
<teward> but can't replicate it in local tests
<Laney> you could maybe run it a bunch of times locally to see if it ever happens
<teward> true.
<teward> i also just restarted the test on CI to see if it happens again
<Laney> right, if it goes green that possibly points to a race condition
<teward> and if it's still failing then I'll have to find someone sponsor a modification to the fcgiwrap tests to add a wait period before actually *testing* things to let fcgi finish its startup
<teward> running the same test now, 3 simultaneouls
<teward> y
<teward> to see if it breaks
<teward> all i know is my computer's going to be a bit mad after this lol
<teward> i'll have to wait a while for the autopkgtest I kicked off again to work
<teward> Laney: four simultaneous tests, all succeeded
<teward> so i'm going to *assume* maybe a CI race condition, or something changed in fcgiwrap between the time it ran the autopkgtest with the nginx trigger and now
<teward> *shrugs*
<teward> Laney: well now my computer *is* hating me, I have 10 simultaneous autopkgtests of it now, trying to force a race condition.  do we have more details about how autopkgtests are run in the automated CI?  and what resources are available/assigned for each test?
<Laney> teward: looks like fcgiwrap -12 might have fixed it
<Laney> https://launchpad.net/ubuntu/+source/fcgiwrap/1.1.0-12 sounds like a test fix to me
<teward> ah, indeed, looks like it
<teward> LOL not being in the test dependencies sounds like it's a "WTF Are You Doing" moment xD
<teward> i'll fire off the rest of the requests then so that they'll all succeed, I only fired off amd64 :P
<Laney> sounds like someone didn't run the tests properly
<teward> Laney: or didn't write them proper heh
<teward> Laney: in any case, it does look like -12 may have fixed the failures, which means they should pass now when it reruns for nginx
<teward> then maybe CI can stop complaining to me about it being stuck >.>
<teward> about nginx being stuck*
<Laney> yeh, let's see
<teward> Laney: looks like you were right, redoing the tests against -12 for fcgiwrap shows no regressions now against nginx
<teward> it's slower on two of the test still but once those complete and pass i can stop having the system nag me then :P
#ubuntu-devel 2018-12-14
<ahasenack> hi, possibly dumb question, but is the upload of a no-change rebuild of debian-installer any different than other main packages? I ask because it doesn't sit in the normal main pocket, but main-installer?
<infinity> ahasenack: It's no different.
<ahasenack> infinity: thx
<cjwatson> ahasenack: also main/installer is for udebs not for debian-installer itself
<cjwatson> main/debian-installer rather
<LocutusOfBorg> cyphermox, please merge dkms?
<LocutusOfBorg> I can do it otherwise :)
<LocutusOfBorg> seems a simple task, but we usually blow up the world :p
<cyphermox> err, ok
<cyphermox> probably won't get to it until next week
<LocutusOfBorg> cyphermox, when you drop my one-line patch (res initialization), because fixed upstream, please consider cherry-picking also this commit
<LocutusOfBorg> https://github.com/dell/dkms/commit/6ef1a48eda99ec0d728302830483fd0137174d17
<LocutusOfBorg> cyphermox, aren't patches upstreamable to debian? I'm considering an NMU
<cyphermox> I don't know, I have never really looked at dkms much aside from about automated signing
<ahasenack> does anybody know what's up with systemd 239-7ubuntu15 boot-smoke dep8 tests? http://autopkgtest.ubuntu.com/packages/s/systemd/disco/arm64
<ahasenack> on arm64, specially
<ddstreet> rbasak is there a existing place to report git-ubuntu bugs/requests?  i see https://code.launchpad.net/~usd-import-team/+snap/git-ubuntu but doesn't have a way to open bugs that i can see
<powersj> ddstreet, https://bugs.launchpad.net/usd-importer
<ddstreet> oh, usd-importer handles git-ubuntu bugs, ok
<powersj> old name for the project
#ubuntu-devel 2018-12-15
<doge-doge> ping vorlon are you active?
<vorlon> doge-doge: ish? how can I help?
<doge-doge> I'm a little bit puzzled on your "the default is true" comment in the unattended-upgrades bug report
<doge-doge> https://stuff.mit.edu/afs/athena/system/i386_deb50/os/usr/share/doc/python-apt/html/apt_pkg/cache.html#Configuration.FindB
<doge-doge> never studied python before but this is the class for find_b
<doge-doge> and line 1956 in the UU script is the conditional if
<doge-doge> are you essentially saying that since it was commented out, it was essentially invisible and there was manually set to "True" inside find_b's parameters?
<doge-doge> ah I think I get it, "return default [object]" and since object is there as "True", that condition returns a 1
<doge-doge> default in italics threw me off
<doge-doge> a bit odd that python
<doge-doge> I still wonder why rbalint switched around that and InstallOnShutdown in the script since the current 18.04 package, maybe just so it reads better?
<doge-doge> ...or possibly to make sure there are indeed 2 steps necessary to trigger InstallOnShutdown considering https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade#L2006
#ubuntu-devel 2019-12-09
<cpaelzer> andersk: on checking backlog, the test trigger questions of (my) late friday were all resolved right?
<seb128> vorlon, hey, your 'Make autopkgtests cross-test-friendly.' changes seem to have issues, to pick one https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/g/gdk-pixbuf/20191209_060703_5d3e2@/log.gz
<seb128> vorlon, Package gdk-pixbuf-2.0 was not found in the pkg-config search path.
<seb128> vorlon, it would probably make sense to stop uploading more of the same changes and figure out what's wrong/fix it before continuing
<locutus_> anybody wants to help me figuring out an autopkgtest regression?
<locutus_> basically: kopanocore is regressed in autopkgtests, but I can't figure how (it switched from python to python3, but this is only part of the issue)
<locutus_> I did reproduce locally, even a kopanocore-search --help gives that "magic import" issue in python
<locutus_> and with strace I figured out probably why it fails:
<locutus_> [pid  3172] openat(AT_FDCWD, "/proc/self/fd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
<locutus_> and with pbuilder there is no such failure...
<locutus_> http://autopkgtest.ubuntu.com/packages/k/kopanocore/focal/amd64
<locutus_> any idea about what might cause an AttributeError: /usr/bin/python3: undefined symbol: magic_open
<locutus_> this doesn't happen in Debian, so I suspect some autopkgtest infra "misconfiguration or similar"
<locutus_> [pid  3172] openat(AT_FDCWD, "/sbin/ldconfig", O_RDONLY) = -1 EACCES (Permission denied)
<locutus_> I would say "hey, I need root", but even after sudo su, it fails
<locutus_> and the test is "needs-root"
<locutus_> strange enough:
<locutus_> python3 /usr/sbin/kopano-search --help --> works
<locutus_> kopano-search --help --> doesn't work
<locutus_>  /usr/sbin/kopano-search --help --> doesn't work
<rafaeldtinoco> morning all o/
<rafaeldtinoco> I removed big endian architectures from ocfs2-tools (because it doesn't support) and excuses complain about missing build. What is the step that should be taken for this case ?
<rafaeldtinoco> (s390x in this case)
<xnox> rafaeldtinoco:  open the bug against the package, with RM in the title, explain / ask to remove _binaries only_ on _certain arches_ and which suites (ie. focal-release focal-proposed) and subscribe ubuntu-archive team
<rafaeldtinoco> cool. tks xnox !
<xnox> as it's a partial removal, not a full src+all-debs+all-arches
<rafaeldtinoco> I see
<xnox> also
<xnox> rafaeldtinoco:  open a bug report against ocfs2-tools and ping to jfh to reverse proxy to IBM and ask them to fix it upstream for big endian?
<rafaeldtinoco> no no
<xnox> they have fixed things like that for us before, although with large latency
<xnox> oh ok
<rafaeldtinoco> I have a thread upstream showing
<rafaeldtinoco> the problem
<rafaeldtinoco> maintainer said big endian is a no go for now #)
<rafaeldtinoco> alright, let me open the bug then. tku!
<xnox> well, we have pointed out things like that to IBM in the past, and sometimes they cared and send an squad of programmers to fix an upstream.
<rafaeldtinoco> well, it wont hurt telling them
<rafaeldtinoco> I'll point out the upstream thread
<xnox> and like s390x is available on travis
<rafaeldtinoco> if they have no interest, they can close it
<xnox> tah
<rafaeldtinoco> https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155/comments/14
<ubottu> Launchpad bug 1745155 in ocfs2-tools (Ubuntu Focal) "o2image fails on s390x" [Medium,In progress]
<rafaeldtinoco> done
<xnox> oh that thing
<xnox> urgh
<xnox> *cough* *cough*
 * xnox reaches for cold medicine
<rafaeldtinoco> lol
<vorlon> seb128: the gdk-pixbuf log you pointed to is one for the version of gdk-pixbuf that didn't have the fix
<seb128> vorlon, ah, right, the fixed version migrated now so I retried glib2.0, thx
<seb128> vorlon, also I think gtk+2.0 lacks handling of the -u case that you fixed for others packages
<vorlon> ok, I'll have a look
<seb128> vorlon, thx, I looked at fixing it but I was unsure why you used DEB_HOST_MULTIARCH there vs $DEB_HOST_GNU_TYPE in other packages, and also why you did an export PKG_CONFIG_PATH only in this one
<vorlon> seb128: that was an early iteration of the package
<vorlon> s/package/patch/
<seb128> ah ok
<seb128> so I guess it just need an update with what was used in other sources
<seb128> I can do that if you want?
<vorlon> seb128: sure :)
<seb128> k :)
<seb128> vorlon, I can have a look at doing similar changes to the other desktop ones from the proposed report (but tomorrow at this point) if you want, I can also directly push to salsa while doing so
<seb128> vorlon, feel free to let desktopish .pc ones for me but I would welcome help to resolve the ones which have to do with installability issues
<vorlon> seb128: do you have examples of ones outstanding that have installability issues?
<seb128> vorlon, http://autopkgtest.ubuntu.com/packages/g/gspell/focal/i386
<vorlon> ok I'll look
<seb128> vorlon, http://autopkgtest.ubuntu.com/packages/libi/libical3/focal/i386
<vorlon> seb128: btw there are a number of ftbfs in the packages I've uploaded, which I definitely didn't cause
<vorlon> dconf, pulseaudio, and now poppler
<seb128> vorlon, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/v/vim/20191208_202208_f67e5@/log.gz
<vorlon> looks like you've fixed dconf already, thanks
<seb128> vorlon, I fixed dconf today
<seb128> right
<seb128> I will fix pulseaudio, that's probably my fault
<seb128> and can look to poppler
<seb128> vorlon, http://autopkgtest.ubuntu.com/packages/libv/libvorbis/focal/i386 (installability)
<seb128> vorlon, http://autopkgtest.ubuntu.com/packages/libt/libtheora/focal/i386 looks like a valgrind/multiarch problem, unsure what's the right way to fix that one?
<vorlon> seb128: I'm just checking on that now, I think the easiest way is to just use the i386 valgrind package instead of the amd64 one
<seb128> k, thx
<vorlon> (pulling in the amd64 one was a blind change on my part, I couldn't really test this without first getting a libtheora-doc built that had Multi-Arch: foreign)
<vorlon> seb128: gspell> gobject-introspection is not cross-installable; I'll badtest it
<seb128> vorlon, thx
<rafaeldtinoco> jamespage: Fyio, bionic simplestreams package has finally been released (https://bugs.launchpad.net/bugs/1790904). Based in our last talks, now would be the time to include it in Xenial cloud-archive (so it can benefit from this fix). Should I do something else here to queue this up for u ?
<ubottu> Launchpad bug 1790904 in simplestreams "Glance v2 required by newer versions of OpenStack" [Medium,Fix committed]
<rafaeldtinoco> @freyes ^ fyi as well
<udevbot> Error: "freyes" is not a valid command.
<rafaeldtinoco> and thedac ^.. i think thats it for the highlights
<thedac> rafaeldtinoco: Hi, thanks. I'll mention this to coreycb as well for the UCA update.
<rafaeldtinoco> tks a lot!
<freyes> rafaeldtinoco, thanks for heads up ;-)
<rafaeldtinoco> anytime! =)
<coreycb> rafaeldtinoco: thedac: thanks, we'll discuss more (refresh my memory at least) tomorrow with the team
<rafaeldtinoco> coreycb: alright, ive prepared this fix for xenial (keystone v2 auth) but we all agreed this should go to bionic instead (with a single fix from thedac) and serve xenial from the backport from cloud-archive (bionic)
<rafaeldtinoco> that is what I remember
<coreycb> rafaeldtinoco: ok thanks, that would make sense
<rafaeldtinoco> cool
<ahasenack> xnox: hi, if still around, do you remember the story behind this linking patch? https://git.launchpad.net/ubuntu/+source/freeipmi/commit/?id=8e5fd294968b07d9141e3f1049461383264f25c6
<ahasenack> I'm trying to determine if it's still necessary. It's part of our delta
<xnox> ahasenack:  https://fedoraproject.org/wiki/UnderstandingDSOLinkChange & https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed is the baground
<xnox> ahasenack:  one has to specify libraries in the right order with dependencies listed after something uses it.
<xnox> hence i had to add freeipmi.la library to toolcommon
<xnox> but also build common before libfreeipmi
<xnox> *after
<xnox> ahasenack:  if you drop the patch, and it still builds, it means it is no longer needed
<ahasenack> xnox: is that a good check then?
<xnox> if it fails to build from source, it is still needed, and like should be upstream
<ahasenack> drop && build test?
<xnox> yes
<ahasenack> ok, will try, thanks
<xnox> ensure you do a full clean build
<ahasenack> debian doesn't have it, and it seems to build fine there
<ahasenack> maybe they had it once upon a time, and later dropped, I'll also check that
<ahasenack> or they don't use -Wl,--as-needed
<xnox> at the time, our toolchain was ahead and more strict than theirs
<xnox> i don't know if they are same as us now or not
<vorlon> seb128: fwiw the vim autopkgtest failure was a one-off, no changes required
<seb128> vorlon, ah, good to know, thx
<vorlon> seb128: and gspell, libical3 are both badtested; and I've fixed libvorbis and libtheora
<seb128> vorlon, thanks!
<ahasenack> xnox: it built, all arches: https://launchpad.net/~ahasenack/+archive/ubuntu/freeipmi-merge/+packages
<seb128> vorlon, I will deal with all the .pc not found ones tomorrow
<seb128> well, desktop ones at least
<seb128> but I think that's where the main part of those are
<vorlon> seb128: which of these are currently on your radar for desktop?: graphene json-glib libglib-perl libproxy libsdl2 libsecret libsoup2.4 libssh libwacom mir pyqt5 raqm umockdev upower
<vorlon> seb128: (i.e. do you know which of these are worth me looking at today)
<seb128> vorlon, I'm going to do graphene libproxy libsecrect libsoup2.4 libwacom mir upower at least
<seb128> vorlon, if you want to do at least the binding ones (libglib-perl and pyqt5) that would be nice
<vorlon> right, those are more likely to be untestable anyway :)
<vorlon> and later today I'll run statistics and send another email to ubuntu-devel to give an overview of the status
<xnox> ahasenack:  drop it!
<seb128> vorlon, thx for those status updates emails btw, useful to know where we stand there
<ahasenack> xnox: yay :)
<seb128> vorlon, ah, other installability ones http://autopkgtest.ubuntu.com/packages/c/cheese/focal/i386 , http://autopkgtest.ubuntu.com/packages/g/gnome-shell-pomodoro/focal/i386 http://autopkgtest.ubuntu.com/packages/g/gthumb/focal/i386
<seb128> (blocking cheese)
<seb128> (sorry, dconf)
<vorlon> seb128: right, those are all uninstallable because the packages in question have had their i386 binaries removed - I've badtested, and the next time britney will correctly skip requesting tests for these (this is the britney bug I was just talking with xnox about on #ubuntu-release)
<seb128> k
<xnox> vorlon:  what am i supposed to do with livecd-rootfs? how come it's not installable on i386?
<xnox> in adt
<xnox> i think it can become arch:all package
<xnox> and depend on like qemu-utils:any and the like
<xnox> or even qemu-utils:amd64
<xnox> no?
<xnox> cause the only reason why it is arch:any is because it has a few missing dependencies on i386
<vorlon> xnox: the livecd-rootfs package itself is installable, but the test dependencies may not be
<xnox> vorlon:  hm, don't think so
<vorlon> xnox: so, we need to figure out if those test deps should be annotated (:native), or such
<vorlon> xnox: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt livecd-rootfs is installable :)
<xnox> http://autopkgtest.ubuntu.com/packages/livecd-rootfs/focal/i386
<xnox> vorlon:  livecd-rootfs:i386 is not installable on an amd64 host
<xnox> because it tries to like replace apt:amd64 with apt:i386
<vorlon> no
<vorlon> well
<vorlon> ok yes
<vorlon> anyway
<xnox> FAIL badpkg => means fails to install
<xnox> i guess it should depend on "debootstrap:any"?
<xnox> or like debootstrap:host => is that even a keyword?!
<xnox> on i386
<vorlon> can't
<xnox> sure it can =)
<vorlon> debootstrap needs marked Multi-Arch: foreign
<vorlon> apt-utils needs marked Multi-Arch: foreign
<xnox> urgh
<xnox> can i have like local overrides?! =)
<vorlon> no
<juliank> I don't think apt-utils is M-a foreign
<juliank> -able
<vorlon> juliank: why not?
<vorlon> does it provide any interfaces that aren't exec()?
<juliank> because I think apt-ftparchive has an architecture-dependent database format, so you can't switch it over
<juliank> but not sure that counts
<xnox> vorlon:  i think we should move testing creating i386 things to amd64 arch autopkgtest, and like badtest livecd-rootfs on i386
<vorlon> xnox: we should not move testing creating i386 things to amd64 arch autopkgtest
<vorlon> because that is also still not a valid test of how it will actually be used
<vorlon> the single use of livecd-rootfs in focal now is to build the launchpad-buildd chroots
<vorlon> which are built for i386 on i386
<xnox> but my autopkgtest vm is not that
<vorlon> correct
<xnox> i should on amd64 host, start i386 lxd container, and then use livecd-rootfs:i386 there natively, no?
<vorlon> but a thing we should NOT do is do more work to craft a test which is irrelevant
<vorlon> start i386 lxd container> hhngh
<vorlon> what image are you going to use for the container
<xnox> we can have i386 lxd worker?
<xnox> the buildd i386 container from launchpad =)
<xnox> launchpad-buildd one
<Odd_Bloke> There are currently some people in #ubuntu-meeting hoping for a LoCo council meeting that hasn't happened the last couple of times it was meant to.  Is there anyone I can direct them to to work out what's going on with that?
<vorlon> xnox: are those currently available in streams?
<vorlon> Odd_Bloke: community council?
<vorlon> xnox: tbh I'd much rather do a round two of this that moves the i386 package builds in Launchpad to i386-on-amd64 cross
<vorlon> then the test, run, and build environments would be aligned
<vorlon> and we could reduce the set of sources we need to maintain for i386
<vorlon> but that would be dependent on me demonstrating it's maintainable
<vorlon> and in the meantime we should just badtest livecd-rootfs on i386
<vorlon> xnox: (the latter is done now)
<vorlon> juliank: fwiw if you consider the apt-utils not interchangeable across archs, then Multi-Arch: allowed might be the right answer.  Or, does apt-utils need this versioned dependency on apt?
<vorlon> anyway, no urgency to change anything here
<juliank> Maybe, idk
<juliank> vorlon: The depends I changed so that if you do apt install apt, it upgrades apt, apt-utils, and the libs, to avoid issues
<vorlon> well, ok
<juliank> Ah, but that's the lib depends, i did not add the apt (=) depends specifically I think
<vorlon> juliank: if it only had a strict versioned dep on the lib, it would hopefully still work, and then you could have apt and apt-utils from different archs as needed
<juliank> apt can also Breaks apt-utils (<< ${binary:Version})
<juliank> ugh
<juliank> so
<juliank> apt-utils Depends on apt like this, because apt ships the private library apt-utils uses
<juliank> hence you can't do any multi-arching of it
<juliank> Oh, I mean, we could move libapt-private.so.0 to libapt-private.so.5.90 I guess and move it to libapt-pkg5.90
<juliank> but that would put stronger requirements on apt Depends libapt-pkg than now
<juliank> (= instead of >=)
<cjwatson> vorlon: They're currently available in Launchpad, which is where they get consumed from
<cjwatson> (i386 buildd lxd images)
<xnox> cpaelzer:  i did something naughty, but hey postgresql-common will migrate
<xnox> vorlon:  they were even mentioned during plenary in Vancouver =)
<vorlon> cjwatson: sure, I still think it would be rather baroque to have the livecd-rootfs autopkgtest pull the tarballs from launchpad to feed to lxd to test the i386 build of the launchpad-buildd chroot
<vorlon> xnox: ?
#ubuntu-devel 2019-12-10
<xnox> vorlon:  multipass, snapcraft, buildd images tarballs, lxd, qcow all available in a new path
<xnox> can't remember if it's with or without streams, but to be consumed by things that want to build things
<vorlon> why does libsdl2 have an autopkgtest that rebuilds the entire package, instead of just using Restrictions: build-needed >_<
<vorlon> (which may or not be friendlier; does dh do anything magic with cmake and cross-compilation?)
<cpaelzer> xnox: the remaining 7 test issues were real errors that the upstreams needed to work on
<cpaelzer> xnox: what exactly was "something naughty"?
<cpaelzer> xnox: https://trello.com/c/pBjTM1I8
<cpaelzer> I found postgresql-common being migrated, but no delta on it or postgresql-12 nor did I find a force-badtest for the remaining issues
<cpaelzer> I'm really interested to learn what "something nasty" was when you are back xnox
<cpaelzer> ahasenack: ^^ FYI
<cpaelzer> "Make autopkgtest depend on the postgresql server version this extension is built for"
<cpaelzer> ok I found your changes
<cpaelzer> jamespage: coreycb: the new pytohn-six triggers a bunch of tests in python-oslo.messaging python-oslo.policy python-oslo.serialization python-oslo.service python-pyeclib
<cpaelzer> Those all seem to belong to the openstack context it seems.
<cpaelzer> Part of the Ubuntu Delta are autopkgtests that now fail - it seems mostly for the new python version.
<cpaelzer> Example: http://autopkgtest.ubuntu.com/packages/p/python-oslo.messaging/focal/amd64
<cpaelzer> I wanted to ask if those packages are on your lists to update/merge them and fix up the tests?
<RikMills> seb128: re cmake, they have now backported the harfbuzz fix to the 3.15 branch, in case they happen to have another point release on that
<seb128> RikMills, great
<locutus_> hello cyphermox can you please do an usb-modeswitch merge? it gained some new configuration features the new release, so your patch might need some adjustements
<xnox> cpaelzer:  so yeah, and the "make autopkgtest depend on the matching server" is reported to debian, which is a dupe. It really is pointless to hardcode build against one version, and then test against a moving default version.
<xnox> cpaelzer:  adding / changing the default, shouldn't require removing support for old one. Sure not everything is yet available with 12, and we can't remove 11 yet, but at least all tests pass and don't fake regress.
<xnox> cpaelzer:  and debian maintainer seems to agree.
<xnox> cpaelzer:  also this http://launchpadlibrarian.net/454980669/php-horde-db_2.4.0-4ubuntu2_2.4.0-4ubuntu3.diff.gz
<cpaelzer> xnox: is the latter from https://github.com/horde/Db/pull/4 or just doing it on your own?
<oSoMoN> sil2100, good morning!Â SÃ©b told me you were looking for me yesterday, sorry IÂ was afk sick. the thunderbird SRUÂ in the eoan queue isn't meant to go through security, as it doesn't address any security issues
<cpaelzer> thanks for asking the Debian maintainer on it as well
<cpaelzer> xnox: I have in the meantime found all the Delta and am ok now I guess
<cpaelzer> I was first confused what was going on
<xnox> cpaelzer:  my own..... that pull request seems to be different for the second fallback query, and i have no idea which one is better.
<xnox> the first portion seems the same.
<cpaelzer> I was concerned that this masks real errors at first, but it seems ok to "block PG-11 removal" instead of "block PG-12 appearing"
<cpaelzer> xnox: do you have a link to your discussion with the Debian maintainer(s) ?
<xnox> there is debian bug and irc chat
<xnox> let me find it
<xnox> i filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946462 which got merged into https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944457 and I find only option 1 from that one sensible
<ubottu> Debian bug 946462 in postgresql-common "postgresql-common: autopkgtests should have versioned postgresql deps" [Important,Open]
<ubottu> Debian bug 944457 in postgresql-common "test-dependencies need to be explicit" [Important,Open]
<xnox> then chatted with myon
<xnox> cpaelzer:  what concerned me about php-horde-db, is that seamingly mysqldb is setup, but mysqldb tests are skipped? or do i just not understand phpunit output?
<cpaelzer> I never got into the horde testing, I know bryce looked at some of it recently for the next php
<cpaelzer> But it is so huge, not sure if he can add soem detail - but if you can bryce pelase do so ^^
<cpaelzer> thanks for the links xnox
<cpaelzer> and thnaks for doing this discussion a few hours after my first "WTF has happened grumpy mode"
<cpaelzer> I might have appreciated a ping in advance, but you might have had that with ahasenack and I missed it
<cpaelzer> but ignoring my initial hickup on it, thanks for your help on these packages
<cpaelzer> I read the bugs and like that myon agreed
<cpaelzer> so all of it should resolve sooner or later
<cpaelzer> and as I already mentioned, our TODOs to get all of these ready for PG-12 didn't change
<xnox> sure, cause you do want to either remove them or upload new versions of them with PG-12 support, to remove PG-11 from the archive.
<xnox> it is very odd that adding support for a new postgresql, is done in one step like that. Instead of python compiled extensions style, where support is first dual, then switch default, then mark single supported, remove obsolete extensions.
<xnox> as that decouples things and makes it easier to add and remove support for any given version
<sil2100> oSoMoN: hey! Thanks! Was asking, since this seems to be fixing an upgrade issue, so wouldn't this affect -security enabled people too? Like, shouldn't they get the fix so that they can properly upgrade? Or is it something different?
<sil2100> oSoMoN: like, it's not a security fix, but it sounded to me that without this, some people might have upgrade problems or something?
<oSoMoN> sil2100, right, I didn't consider this
<oSoMoN> chrisccoulson, can you comment on this?Â ^
<chrisccoulson> oSoMoN, if the update fixes a regression introduced in to the security pocket, then it should probably go through security
<chrisccoulson> I don't have the full context though
<chrisccoulson> if it's the issue referenced in https://www.thunderbird.net/en-US/thunderbird/68.2.2/releasenotes/, then it probably should go out in -security
<oSoMoN> chrisccoulson, yes, that's the one
<sil2100> chrisccoulson, oSoMoN: then I guess we'd need this thunderbird upload to be built in a -security enabled PPA and then bin-synced
<chrisccoulson> yeah, we'd publish it just like any other security update
<seb128> vorlon, hey, so libsecret fails to be a candidate because the i386 builds is depwaiting on gjs (which I guess got deleted on i386) ... what's the correct solution in those cases?
<cpaelzer> rbasak: I have mdevctl ready for upload
<cpaelzer> rbasak: this isn't urgent per-se, but I'd see it build and migrate properly before everyone leaves to christmas break
<cpaelzer> I've understood that this might be easy with dput-ng but your setup is on classic dput
<cpaelzer> rbalint: I can ask around for other DDs if you want
<cpaelzer> rbasak: ^^
<cpaelzer> sorry rbalint you just have the wrong name for three-char tabbing with rbasak
<rbasak> rbasak was first :-P
<rbasak> cpaelzer: I can take a look tomorrow if that works for you?
<cpaelzer> that is fine
<cpaelzer> if I catch someone else helping me before that I'll let you know
<cpaelzer> rbasak: I found someone, consider it done
<rbasak> ack
<rbalint> cpaelzer, no problem, i can live with rbasak's popularity :-)
<juliank> I'm considering changing the string 'Cdrom with Ubuntu 20.04 'Focal Fossa'' to "Ubuntu 20.04 'Focal Fossa' Installation Medium"
<juliank> or something like that
<ahasenack> cpaelzer: where did you see that -pie is default in ubuntu? dpkg-buildflags doesn't show it
<ahasenack> it doesn't even show bindnow
<cpaelzer> ahasenack: bindnow appears as -Wl,z,now
<ahasenack> LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro
<ahasenack> hm, but that's eoan
<cpaelzer> and pie is default in the compiler and only shows up as arg if you disable it
 * ahasenack starts focal
<cpaelzer> ahasenack: the build log from your PPA has the Wl,z,now
<ahasenack> well, because of the patch
<cpaelzer> which matches what the hardening page documents
<ahasenack> ah, you want to keep the bindnow delta, ok, got you
<ahasenack> s/want/agree/
<ahasenack> cpaelzer: is it ok to submit this to debian with the ubuntu string in the version? The change was made in debian's version 1.6.3-1.1 (and we got it in our 1.6.3-1.1ubuntu1):
<ahasenack> +rm_conffile /etc/default/ipmidetectd 1.6.3-1.1ubuntu1~ freeipmi-ipmidetect
<ahasenack> I think it's ok, since 1.1ubuntu1 is higher than 1.1
<seb128> vorlon, can you badtest graphene/i386? it relies on the python-gobject stack
<ahasenack> doko: hi, where can I check if, and since when, -pie is a default option in gcc? It's not in the output of dpkg-buildflags
<cpaelzer> ahasenack: strictly speaking it is ok (for the comparison), but I usually change it to the Debian version that is next
<ahasenack> cpaelzer: ah, so that it includes the ubuntu one?
<cpaelzer> if current Debian is 1.6.4-3 I'd set 1.6.4-4
<cpaelzer> clean up conffile if coming from before 1.6.4-4
<seb128> vorlon, libsoup2.4/i386 fails on 'Depends: winbind:i386 but it is not going to be installed', badtest?
<ahasenack> oh, right, they need a higher one
<rbasak> It's common to use 1.6.4-4~ instead, if I follow what you're doing
<ahasenack> rbasak: yep
<cpaelzer> yep with the ~
<cpaelzer> I was only talking about the version itself that is to be used
<ahasenack> ok, I just would like to know how to find out if -pie is default, to point at it when submitting to debian, and also do double check debian has it as a default too
<ahasenack> and isn't -fPIE needed together with that?
<ahasenack> https://wiki.debian.org/Hardening#gcc_-pie_-fPIE
<cpaelzer> ahasenack: gcc -v 2>&1 | grep pie
<cpaelzer> will show --enable-default-pie
<cpaelzer> for us
<cpaelzer> not sure it does in Debian already
<ahasenack> cpaelzer: is that a built-in default, or is some config file checked?
<cpaelzer> that is how gcc was built
<cpaelzer> essentially its configure call
<ahasenack> root@sid-rspamd:~# gcc -v 2>&1|grep -i pie
<ahasenack> root@sid-rspamd:~#
<ahasenack> yep, not in sid
<ahasenack> no pie for debian
<cpaelzer> for many other defaults I use "gcc -Q --help=target | grep ..."
<ahasenack> hm
<ahasenack> it helps if I have gcc installed
<ahasenack> pie is there
<cpaelzer> ok then my assumption on the review was right \O/
<doko> ahasenack: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fPIE  but that looks incorrect. see debian/rules.defs in gcc-9
<doko> seb128: why do you upload all these autopkg fixes as -Nbuild1?
<seb128> doko, because I'm commited to the Debian vcs side as the same time but didn't want to do upload for those and don't want to have to remember doing the manual sync next time there is an upload in Debian
<seb128> commiting*
<seb128> it's a "content is staged in Debian, please override me on next upload" :)
<seb128> unsure if we have a better way to achieve that?
<doko> just looking an libopenmpt, don't see anything in the debian vcs, or in a bug report
<seb128> doko, right, as you see I had to iterate, I'm waiting for things to be green/confirmed to work to press send/push
<seb128> doko, I expect to have things properly sent to Debian by the end of the day
<doko> ok
<doko> coreycb: you dropped xnox's patch for sqlalchemy, python2 now wanting to promote to main again ...
<coreycb> doko: checking
<coreycb> doko: all the patches we were carrying in 1.2.18+ds1-2ubuntu3 are fixed in 1.3.11+ds1-1
<doko> coreycb: no
<doko> $ apt-cache show python-sqlalchemy-doc|grep Recommends
<doko> Recommends: python-sqlalchemy
<coreycb> doko: got it, I'll fix that
<locutus_> tjaalton, I would like to upload the custodia with the pylint3 fix
<locutus_> can you please add me to freeipa-team so I can team upload it?
<tjaalton> locutus_: just send a merge request
<tjaalton> on debian
<vicamo> hi, I just filed https://bugs.launchpad.net/ubuntu/+source/reprotest/+bug/1855891 for reprotest has no installable candidate in focal
<ubottu> Launchpad bug 1855891 in reprotest (Ubuntu Focal) "reprotest has no installable candidate in focal" [Undecided,New]
<vicamo> is it possible to simply copy 0.7.9 from eoan first? There seem to be a 0.7.10build1 in proposed a month ago but failed to build
<locutus_> tjaalton, this? https://salsa.debian.org/freeipa-team/custodia/merge_requests/1
<locutus_> let me know if and when I can upload
<tjaalton> locutus_: and how many packages are there still left using pylint3?
<tjaalton> on debian
<cpaelzer> jamespage: coreycb: did you see my question in regard to six and python-oslo.messaging python-oslo.policy python-oslo.serialization python-oslo.service python-pyeclib this morning?
<locutus_> tjaalton, 3 or 4
<locutus_> I fixed 4 this morning
<locutus_> and I'm fixing the others right now
<tjaalton> fine
<locutus_> I think: gnome-keysign, knack, pathspider, prospector pylint-flask python-trio, ranger, uranium
<locutus_> probably less than that
<coreycb> cpaelzer: yes sorry I didn't reply. I'll take a look at those next.
<cpaelzer> thank you coreycb
<cpaelzer> just wanted to know it is covered
<tjaalton> locutus_: merged
<locutus_> uploaded thanks
<bryce> cpaelzer, xnox yeah I dug into php-horde a bit, the failure doesn't appear to me to be due to the database changes nor to the php 7.3, but to the phpunit 7->8 change in focal.  Googling around shows it's due to a change in the setUp() call's prototype, it needs a void type specified or something.
<bryce> cpaelzer, xnox it's on my todo list to work on at some point (maybe tomorrow?) but definitely feel free to work on it further if you wish
<rafaeldtinoco> coreycb: mind giving me an okay for this change (https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pcs/+git/pcs/+merge/376492) ? cpaelzer requested it as you're working with python3-tornado (6).
<rafaeldtinoco> (can be a +1 or not here, just to make sure its good)
<rafaeldtinoco> we are gonna be using pcs for ubuntu-ha related packages (ubuntu manual, etc) thats why I prefer having a working version now and I can fix it as soon as python-tornado 6 is ready.
<cpaelzer> coreycb: hes asking as you were touching it in the past and didn't want to step on your toes
<cpaelzer> :-)
<coreycb> rafaeldtinoco: james may be better to ask about percona-cluster
<rafaeldtinoco> yep. we've spoken about this in last sprint, quickly.
<vorlon> seb128: hmm I'm very surprised that gjs was removed, it should've been picked up by germinate afaics.  So to bring it back in cases like this, there's an update-i386-whitelist script in lp:ubuntu-archive-tools that can be edited for manual additions; and I'm doing a copy-package of gjs back to focal; I'll look into why it's not gotten picked up
<vorlon> seb128: graphene: badtested.  libsoup2.4 -> winbind: should have the test annotated as winbind:native instead; but glancing at the log I also see python mentioned, so maybe there's no point?
<kanashiro> I've been investigating the cyrus-imapd autopkgtest failure (which is blocking more than dozen of packages in proposed) and I think the failure is happening because the vm used to execute tests is running OOM
<kanashiro> some processes are killed during the tests execution leading to failure
<kanashiro> I've been trying to reproduce it in a vm with more resources and I can't
<kanashiro> what is the best solution in this case?
<rbasak> bryce: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/376593 is the next big MP please. Awaiting official CI results but it passes locally.
<rafaeldtinoco> kanashiro: u know what processes are killed and why ?
<seb128> vorlon, ah, @whitelist, good to know, thanks!
<seb128> vorlon, libsoup2.4 let's badtest then? I will still commit the winbind:native change to the vcs
<seb128> vorlon, I don't remember if I did ping about that one earlier, but speech-dispatcher depends on festival on i386 which is missing ... another case to rescue via the whitelist? or should we rather delete speech-dispatcher/i386?
<seb128> vorlon, http://autopkgtest.ubuntu.com/packages/d/doc-rfc/focal/i386 ... badtest? (it's blocking poppler)
<seb128> vorlon, http://autopkgtest.ubuntu.com/packages/s/sphinxbase/focal/i386 also (blocking pulseaudio)
<seb128> (and enough pings for now, I go for dinner ;-)
<vorlon> seb128: fwiw winbind is tagged Multi-Arch: allowed, so the test dep on it can be winbind:any instead of winbind:native
<vorlon> seb128: speech-dispatcher-festival, I think we should be changing the source to not be generating that uninstallable binary on i386 in Ubuntu, let me take a look at that
<vorlon> seb128: (we can't delete speech-dispatcher as a whole, it's pulled in somewhere)
<bryce> rbasak, til python's floor division operator via your patch, thanks :-)
<rbasak> bryce: yw :)
<rbasak> bryce: I'm not sure why CI failed on my branch. I'll look tomorrow.
<bryce> doing the code review presently, I'll let you know on the MP if I find out
<rbasak> Thanks!
<kanashiro> rafaeldtinoco, the process is smtpd and the why is that we are running OOM, look at one of the logs: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/c/cyrus-imapd/20191207_210616_44af2@/log.gz
<kanashiro> I didn't check all the logs (there are many failures) but at least 7 have the same issue
<rafaeldtinoco> cool gimme 15 and I'll take a look
<kanashiro> by logs I meant log files :)
<vorlon> seb128: doc-rfc> oops sorry, should've already been badtested but I had failed to grab multiverse
<vorlon> seb128: and sphinxbase badtested
<vorlon> seb128: speech-dispatcher: https://paste.ubuntu.com/p/WVdHFZXt9k/
<vorlon> hmm I probably should've had a new dpkg-vendor --is Ubuntu instead of reusing the dpkg-vendor --derives-from Ubuntu block, other downstreams might choose to keep i386
<rafaeldtinoco> kanashiro: make: *** [Makefile:390: all] Error 2
<rafaeldtinoco> make[2]: Entering directory '/srv/imaptest.git/src'
<rafaeldtinoco> kanashiro: i think imaptest.git is broken
<rafaeldtinoco> that is what happened
<rafaeldtinoco> no ?
<kanashiro> rafaeldtinoco, that might be an issue but I don't think this error is the responsible for killing smtpd processes
<rafaeldtinoco> 	Cassandane::Unit::WorkerPool::start(Cassandane::Unit::WorkerPool=HASH(0x2aa12308728)) called at Cassandane/Unit/TestPlan.pm line 889
<rafaeldtinoco> i dont know the unit test but looks like they all died because the test died
<rafaeldtinoco> the "workerpool" could be controlling the smtpd processes
<rafaeldtinoco> but its a guess as I havent read cassandane code
<rafaeldtinoco>  at Cassandane/Unit/TestPlan.pm line 175.
<rafaeldtinoco> you have a mainloop for the unit test
<rafaeldtinoco> and then 	Test::Unit::TestRunner::do_run(Cassandane::Unit::RunnerPretty=HASH(0x2aa0f150eb8), Cassandane::Unit::TestPlan=HASH(0x2aa0f150c78), 0) called at ./testrunner.pl line 132
<rafaeldtinoco> do_run
<rafaeldtinoco> and then an anonymous function being called
<rafaeldtinoco> 	main::__ANON__(Cassandane::Unit::TestPlan=HASH(0x2aa0f150c78), GLOB(0x2aa0f150a80)) called at ./testrunner.pl line 315
<rafaeldtinoco> Running ./testrunner.pl -f pretty -j 4 Cyrus::ImapTest FAILED (at a94b77842b44bb57a73200a4ea66bdd6424c4583)
<rafaeldtinoco> but all the unit test is around Cyrus::ImapTest
<rafaeldtinoco> that did not compile
<rafaeldtinoco> so I'd first look for that and then something else
<rafaeldtinoco> kanashiro: ^
<rafaeldtinoco> hope it helps
<kanashiro> rafaeldtinoco, I also don't have knowledge about the codebase but I still think the TestPlan died because OOM, during my tests in a tiny vm I got similar errors and the vm was running OOM
<kanashiro> and I can't reproduce this imaptest error, it just works fine
<seb128> vorlon, thx, other ones (blocking firefox) that could maybe use a badtest, http://autopkgtest.ubuntu.com/packages/libo/libomxil-bellagio/focal/i386 and http://autopkgtest.ubuntu.com/packages/n/nghttp2/focal/i386
<rafaeldtinoco> kanashiro: could be.. it doesn't say where the compilation error is.. right before it says test -f UnicodeData.txt || wget http://www.unicode.org/Public/UNIDATA/UnicodeData.txt
<rafaeldtinoco> have u seen that ?
<rafaeldtinoco> Proxy request sent, awaiting response... 503 Service Unavailable
<rafaeldtinoco> make[3]: *** [Makefile:2794: UnicodeData.txt] Error 8
<rafaeldtinoco> make[3]: Leaving directory '/srv/dovecot.git/src/lib'
<rafaeldtinoco> it looks the building env is/was in trouble
<kanashiro> yeah I saw that
<rafaeldtinoco> despite those warnings, the makefile error could come from unicodedata.txt not being get
<rafaeldtinoco> causing other issues ahead (killing the unit test , etc)
<cjwatson> Well I mean tests that rely on an external website are inherently unreliable
<rafaeldtinoco> cjwatson: +1
<cjwatson> Make sure it has the file locally so that it doesn't need to fall back to wget
<rafaeldtinoco> im just not seeing oom warnings there
<kanashiro> this test also git clone a bunch of repos
<rafaeldtinoco> yep
<rafaeldtinoco> terrible autopkgtest =)
<rafaeldtinoco> git clone dovecot, cyrusimap/* etc
<rafaeldtinoco> git checkout -q 6264b51bcce8ae98efdcda3e55a765d7a13d15ed
<rafaeldtinoco> at least they are using specific commit
<rafaeldtinoco> and not "master" like i've seen before
<kanashiro> the debian maintainer tried to translate upstream tests with docker to a shell script
<rafaeldtinoco> yes
<kanashiro> upstream should probably use something like travis
<rafaeldtinoco> kanashiro: https://github.com/dovecot/core/blob/master/src/lib/Makefile.am
<rafaeldtinoco> test -f $@ || wget -O $@ https://dovecot.org/res/UnicodeData.txt
<rafaeldtinoco> thats it ^
<rafaeldtinoco> squid failed to give you that file
<rafaeldtinoco> like cjwatson said, this will be a flakky test (by depending on this much external stuff)
<rafaeldtinoco> actually they changed url
<rafaeldtinoco> they're serving the UnicodeData from dovecot.org
<rafaeldtinoco> kanashiro: ^ maybe it was failing too much ? =)
<kanashiro> rafaeldtinoco, this test was triggered yesterday and it failed anyway but who knows
<rafaeldtinoco> kanashiro: want a retry there ?
<rafaeldtinoco> its likely that this UnicodeData.txt retrival is intermittent
<kanashiro> we can but I wish I could be able to reproduce it
<rafaeldtinoco> kanashiro: try setting up a http_proxy
<rafaeldtinoco> and block https://dovecot.org/res/UnicodeData.txt
<rafaeldtinoco> see if you get the same error #)
<rafaeldtinoco> acl blacklist dstdom_regex "/etc/squid/blacklist.txt"
<rafaeldtinoco> http_access deny blacklist
<rafaeldtinoco> in squid.conf
<rafaeldtinoco> might do the trick
<xnox> bryce:  cpaelzer: i fixed the phpunit compat earlier..... just retry tests with newer php-horde-db see http://launchpadlibrarian.net/454918855/php-horde-db_2.4.0-4ubuntu1_2.4.0-4ubuntu2.diff.gz then that was failing again with pg12 compat, which i fixed in the subsequent upload, but not confident about it.
#ubuntu-devel 2019-12-11
<seb128> vorlon, can you badtest fpc/i386?
<seb128> vorlon, doko, Saviq, mir/i386 autopkgtest fails on 'Depends: gcc:i386 but it is not going to be installed' ... is that depends wrong or is that an archive issue?
<rbasak> Does "git ubuntu import-local" work for anyone currently (from the edge snap)? AFAICT, it's broken, so I'm struggling to not break it further when fixing an unrelated bug :-/
<rbasak> If someone has a currently working use case for it, I'd like to know so as not to break it further.
<rbasak> (it's a separate effort to fix and add tests for the broken bits of the CLI; I'm just trying to make some progress)
<ahasenack> rbasak: has never worked for me (import-local)
<rbasak> Thanks
<seb128> vorlon, can you badtest upower/i386, it's failing because it tries to install python/gobject packages and that fails
<gpiccoli> Hi rbasak and sil2100 , good morning/afternoon! Sorry to bother, I've updated LP #1847924 with the modified mdadm patch for SRU, I'd like to ask you to take a look if possible and...maybe sponsor it =))
<ubottu> Launchpad bug 1847924 in mdadm (Ubuntu Eoan) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924
<gpiccoli> Thanks in advance!
<rbalint> cpaelzer, how about forwarding this upstream? https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c05586d9da033bbfd6b6a74e10b87520843c7c48
<cpaelzer> rbalint: did it work relialbly?
<cpaelzer> back then we said we only want to suggest that if it works out to be helpful
<cpaelzer> you look at those tests results more often I guess
<cpaelzer> did this really help?
<rbalint> cpaelzer, i think so, at least we carry this for some time so it is either harmless or working
<rbalint> cpaelzer, i did not run tests without it :-)
<cpaelzer> yeah, back then it was hitting ~50% or more
<cpaelzer> I can submit it, but not today
<cpaelzer> put it on my todo list
<rbalint> thanks!
<seb128> LocutusOfBorg, hey, do you know what's the dela with virtualbox's autopkgtest in focal? it's blocking libnotify but from the log it's pretty consistently failing
<juliank> If anyone sees the new python-apt 1.9.1 in experimental and thinks oooh sync time: please don't, it will regress security. thx!
 * juliank will have a fixed one later today or (probably) tomorrow
<seb128> juliank, hey, could you have a look to bug #1849773 at some point? If not I think I will just drop the patch in a next upload because I've no document to trigger the problem/work on it and the segfault is worth than the weird char issue
<ubottu> bug 1849773 in evince (Ubuntu) "/usr/bin/evince:11:strstr:TextSelectionPainter::hasGlyphLessFont:TextSelectionPainter::endPage:TextPage::drawSelection:poppler_page_render_selection" [High,Confirmed] https://launchpad.net/bugs/1849773
<juliank> seb128: oh yes, thanks for the reminder
<seb128> juliank, thanks for having a look to it :)
<juliank> seb128: But FWIW, if you want a PDF that triggers the rendering issue, you should be able to take any PDF, and just run ocrmypdf on it to reproduce the issue
<juliank> Oh, I noticed that it's not the current patch I sent upstream, that one should not have the crash https://gitlab.freedesktop.org/poppler/poppler/merge_requests/280
<juliank> Because it does not look at the font name
<LocutusOfBorg> seb128, the 6.0.14-dfsg-4 should be good
<LocutusOfBorg> but I don't know why it is not marked as such
<LocutusOfBorg> oh... the kernel has bundled the very same version, so it doesn't get built
<LocutusOfBorg> I suspect you can just add one hint
<LocutusOfBorg> seb128, something to deal with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848788
<ubottu> Launchpad bug 1848788 in linux (Ubuntu Focal) "linux won't build when new virtualbox version is present on the archive" [Undecided,Fix released]
<LocutusOfBorg> cascardo, ^^
<LocutusOfBorg> I suspect we should make dkms fail less badly
<LocutusOfBorg> or hint the test
<vorlon> seb128: hi, so for any package whose tests are currently failing on i386 we *should* badtest them in order to not block other packages, the question is whether we should be badtesting only the current version or badtesting it permanently; so if you could be explicit about whether you're asking for a temporary override or a permanent one, that would help streamline
<vorlon> seb128: mir/i386: test dep on gcc is probably wrong, as opposed to 'build-essential' which we handle.  That test should be fixed and made cross-build-friendly
<vorlon> seb128: upower/i386 hinted (because you gave rationale :)
<seb128> vorlon, thx :)
<seb128> vorlon, I think http://autopkgtest.ubuntu.com/packages/n/nghttp2/focal/i386 also goes down to want python and might be a candidate for badtest?
<seb128> vorlon, unsure about http://autopkgtest.ubuntu.com/packages/libo/libomxil-bellagio/focal/i386 which is the other one blocking firefox
<vorlon> ok looking
<vorlon> seb128: meanwhile, if you happen to know why my latest gst-plugins-bad1.0 upload ftbfs on i386, I'm trying to get that landed to prune opencv, numpy, node, ... from the i386 set
<vorlon> seb128: nghttp2 looks fixable to me, nghttp2-proxy could possibly depend on python3:any instead of python3; I'll add it under 'needs investigation'
<vorlon> seb128: libomxil-bellagio: -doc packages being uninstallable is generally fixed by just marking those packages Multi-Arch: foreign
<vorlon> Depends: [...] binutils, build-essential, [...]
<vorlon> ok then
<vorlon> seb128: had to dig into fpc a bit, but yeah, badtested now (I satisfied myself that a) the i386-specific packages are usable, and b) it's impossible to construct a correct test-dependency field for this package under the current autopkgtest implementation because its test deps conflict with build-essential :P)
<wpk> Could I interest someone in  https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1810154 ? Bug is diagnosed, patch is attached, it just needs to go into the release. It's effects are quite annoying...
<ubottu> Launchpad bug 1810154 in plymouth (Ubuntu) "ply_boot_client_process_incoming_replies: Assertion `request_node != NULL' failed" [Medium,Confirmed]
<sarnold> wpk: oooh, would that let you use zfs native encryption for eg / or /boot or similar?
<wpk> sarnold: I'm using native ZFS encryption for /
<sarnold> nice; I'm using LUKS underneath zfs for that, and ... it works, but it feels brittle
<wpk> sarnold: there were two bugs - one in zfs-initramfs (fixed, fix released), that's the second one - it's still possible to use native ZFS encryption but because of this bug I get dropped to initramfs because plymouth can't ask for password
<wpk> rpool/ROOT/ubuntu on / type zfs (rw,relatime,xattr,posixacl)
<wpk> NAME   PROPERTY    VALUE        SOURCE
<wpk> rpool  encryption  aes-256-gcm  -
<wpk> I've been using it for over a month now, no problems at all with the stability. Installation is annoying, but that's a one time effort
<wpk> sarnold: anyway, it'd be nice for this one to be fixed :)
<sarnold> wpk: heh, yeah, what I've got now has *worked* for a few months, but it wasn't fun to install :)
<sarnold> wpk: did this patch come from upstream plymouth dev? debian? some other distro?
<sarnold> wpk: some links about where it came from might help
<wpk> sarnold: I made it
<sarnold> wpk: cool cool :) getting it into the upstream releases would probably make it more likely to be included in ubuntu
<wpk> sarnold: IIRC it's an ubuntu-only bug - it comes from one of the patches
<wpk> $ cat misc-changes.patch
<wpk> Description: Undocumented changes
<wpk>  This patch contains undocumented changes accumulated during previous
<wpk>  versions of the Ubuntu plymouth package, that have not yet been split up
<wpk>  into individually-documented patches.  Please try not to add further things
<wpk>  to this patch.  Using quilt for new changes is recommended, but if you
<wpk>  don't, they'll end up in a separate debian-changes patch at the end of the
<wpk>  patch series.
<wpk> Last-Update: 2011-01-21
<wpk> riiiight....
<sarnold> oh my
<sarnold> that's some real spelunking there
<cjwatson> Heh, I thought that looked familiar, apparently I wrote that
<sarnold> :)
<cjwatson> Since they were the bits I couldn't understand
<cjwatson> (Don't ask me about them, partly for that very reason, and partly because it was nearly nine years ago and I remember nothing)
#ubuntu-devel 2019-12-12
<xnox> i managed to trace some of them to Keybuk!
<xnox> and understand some other bits
<xnox> many are still quite a puzzle
<vicamo> hi, anyone has some time to help upload https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1855825 to focal?
<vicamo> this contains fix for https://launchpad.net/bugs/1855825, current in -proposed kernel may cause all systems using backport-iwlwifi dkms to hang at connecting to WiFi base stations
<ubottu> Launchpad bug 1855825 in backport-iwlwifi-dkms (Ubuntu Focal) "When connecting to wifi with the proposed linux-oem kernel , the system hangs" [Critical,In progress]
<vicamo> this is quite critical actually
<vicamo> hi, anyone has some time to help upload https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1855825 to focal?
<cpaelzer> rbalint: the patch that you asked only has 2 chunks left that we need for current master
<cpaelzer> rbalint: submitted as https://github.com/systemd/systemd/pull/14323
<seb128> vicamo, hey, I sponsored your iwl fix now, I just changed the priority back to normal since I don't think that change anything for Ubuntu uploads, also would probably be good to get it reviewed/merged upstream before doing the SRU
<vicamo> seb128: thank you
<rbalint> cpaelzer, thanks!
<cpaelzer> np
<cpaelzer> if you have any eta on a 244 upload that would be great
<cpaelzer> not like "please let it be asap" but like "I wonder when it would happen"
<doko> seb128: I see you touched unity-gtk-module to port from py2 to py3 ... are you working on autopilot portage to python3?  asking because foundations thinks it should be just removed
<ahasenack> rbasak: in debian one can file bugs against binary packages, right? What is the best form? In my case, the bug is in the "Depends" of a binary package, but that is of course fixed in the source's d/control
<ahasenack> in other words, is filing bugs against binary packages just something to help beginners?
<rbasak> No filing bugs against binary packages is the norm in Debian
<rbasak> It's a little more granular
<rbasak> I would file against the binary package that has the problem Depends line
<rbasak> And usually I only file against a source package if there is no obvious binary package to file it against
<xnox> ahasenack:  all my life i've been filing bugs against source packages only and nobody ever tried to reassign them from source to binary, and vice versa, or tell me off to file agains binary or source package
<xnox> apart from how bugs.debian.org renders things, it makes no difference for closing them, or operating them by mail =)
<ahasenack> I prever against the source too, it always annoys me when searching for debian bugs that I have to remember and search for bugs against the binary packages
<xnox> well, one can search against source package too, it then renders _all_ bugs for source and all of its binaries
<ahasenack> doesn't it just list the binary package names at the top and you have to click through them?
<cjwatson> No if you go to e.g. bugs.debian.org/src:groff then it aggregates them all
<ahasenack> "you might also want to look for bugs in ....." something like that
<xnox> ie. https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=boost1.67
<xnox> ahasenack:  yes, that english can be misunderstood, it's subfiltered pages
<xnox> strict subsets
<ahasenack> ah, I see
<ahasenack> thanks, saves me some time and removes the annoyance :)
<seb128> doko, no, I'm not, autopilot or autopilot-legacy?
<seb128> doko, I didn't suggest removing because I'm not sure it's not used in the daily iso automated testing job/jenkins, should check with jibel before doing anything
 * xnox ponders to name next project i create one of: autopilot.io autopilot.ng autopilot autopilot-classic autopilot-legacy
<xnox> seb128:  ubiquity might still be using it!
<seb128> xnox, could be yes :)
 * ahasenack hrms landscape used to have an autopilot
<xnox> seb128:  i see it is using python3-autopilot
<xnox> ahasenack:  that's a different product, from us, also called autopilot
<xnox> there is juju/openstack autopilot, there is landscape autopilot, and a11y testing framework autopilot
<ahasenack> I just still twitch when I read "autopilot" in an ubuntu channel
<Laney> core
<juliank> xnox: it's not just canonical, though, eh? - tesla also has one of these
<juliank> I heard that even planes have those things
<rafaeldtinoco> andersk: so
<ahasenack> ahasenack
<rafaeldtinoco> andersk: sorry
<rafaeldtinoco> ahasenack: lol
<bryce> :-)
<rafaeldtinoco> ahasenack: so..
<rafaeldtinoco> im doing a huge rebase now
<rafaeldtinoco> ive done the split and logical
<rafaeldtinoco> using git-ubuntu
<rafaeldtinoco> now im the debian merge phase
<ahasenack> merge onto new/debian, right?
<rafaeldtinoco> my doubt is about doing all the initial merge without dropping the patches
<rafaeldtinoco> ahasenack: yep
<rafaeldtinoco> i think finishing the rebase
<rafaeldtinoco> and revisiting each patch from series
<ahasenack> I find it easier to finish the rebase, and taking notes while doing it (in the commit messages even)
<rafaeldtinoco> might be easier
<ahasenack> and then revisiting things and reorganizing
<rafaeldtinoco> then you drop
<rafaeldtinoco> if neede
<rafaeldtinoco> correct ?
<ahasenack> yes
<rafaeldtinoco> ok
<rafaeldtinoco> sounds good, let me try
<rafaeldtinoco> u said u take notes
<ahasenack> if it needs changing, then I do that during the rebase, ther eis no other way I think
<rafaeldtinoco> i see
<rafaeldtinoco> and then you do a quilt push -af
<rafaeldtinoco> and check failures
<rafaeldtinoco> and go rebasing
<rafaeldtinoco> one by one
<ahasenack> yes
<rafaeldtinoco> ok
<rafaeldtinoco> i was doing the same
<rafaeldtinoco> but i was afraid there was something faster
<rafaeldtinoco> which is not the case
<rafaeldtinoco> lol
<ahasenack> my largest rebase had I think 47 commits
<ahasenack> and each one was conflicting
<rafaeldtinoco> im glad you had snmp before
<ahasenack> I almost lost my hair
<rafaeldtinoco> u had lots of commits already
<rafaeldtinoco> i had to rebase only the last fixes
<rafaeldtinoco> =)
<ahasenack> nice
<rafaeldtinoco> but upstream dropped a bunch of your stuff
<rafaeldtinoco> cause it went upstream
<ahasenack> even better
<rafaeldtinoco> now ill find those
<rafaeldtinoco> yep
<rafaeldtinoco> cool tks!
<ahasenack> more work to find them, but less changes in the end
<rafaeldtinoco> definitely!
<rafaeldtinoco> but sometimes they dont give author
<rafaeldtinoco> to the merge in debian :P
<rafaeldtinoco> you have to track them down
<rafaeldtinoco> I saw some of your pushes losing author in another package
<rafaeldtinoco> tsc tsc
<rafaeldtinoco> tks a lot
<ahasenack> good luck
<kanashiro> mwhudson, re runc test failure: I just added a comment to the bug I filled, when you have some time could you please check it out and see if it rings a bell for you?
<kanashiro> btw I tried to rebuild it in eoan and faced the same problem
<mwhudson> kanashiro: oh you are running the autopkgtest in the lxd backend?
<mwhudson> not completely surprised that doesn't work, i guess
<kanashiro> mwhudson, yes
<mwhudson> time for some isolation-machine in debian/tests/control maybe
<kanashiro> right, let me try to run it in a vm to check if they pass
<kanashiro> mwhudson, you're right, it works fine in a vm and probably in a privileged container. Should I submit a MP for you adding this restriction?
<mwhudson> kanashiro: yes please
<kanashiro> mwhudson, I just figured out the the basic-smoke test it has already have isolation-machine restriction, the one which runs the unit tests is generated by Testsuite: autopkgtest-pkg-go via autodep8
<kanashiro> I am not sure if there is a way to add a restriction to auto generated tests
<mwhudson> kanashiro: ah hm
<mwhudson> kanashiro: i think the deal with autodep8 tests is that if the automatically generated one doesn't work you should just write it by hand
<mwhudson> kanashiro: but i might be wrong about that!
<kanashiro> mwhudson, as reference: https://sources.debian.org/src/autodep8/0.21/support/go/generate/ and https://sources.debian.org/src/dh-golang/1.43/script/dh_golang_autopkgtest/
<kanashiro> we can depend on dh-golang and run dh_golang_autopkgtest as they do and just add isolation-machine restriction
<mwhudson> kanashiro: +1
<kanashiro> mwhudson, should I let the target in d/changelog as UNRELEASED? or do you want to upload it with just this change?
<mwhudson> kanashiro: leave it UNRELEASED for now
<kanashiro> ack
#ubuntu-devel 2019-12-13
<mwhudson> vorlon: do you (or any other core dev) feel like reviewing https://code.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-rootfs/+merge/376544 ?
<vorlon> mwhudson: done
<vicamo> hi, need sponsor for https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1855891 to focal-proposed, which re-add reprotest to Focal
<vicamo> also need to SRU Eoan package in https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1855825 for https://bugs.launchpad.net/ubuntu/+source/backport-iwlwifi-dkms/+bug/1855825
<ubottu> Launchpad bug 1855825 in backport-iwlwifi-dkms (Ubuntu Eoan) "When connecting to wifi with the proposed linux-oem kernel , the system hangs" [Undecided,In progress]
<vicamo> And https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1856024 for bug 1856024 that introduces backport-iwlwifi-dkms to Bionic (already in Eoan/Focal)
<ubottu> bug 1856024 in backport-iwlwifi-dkms (Ubuntu) "[SRU] Need backport-iwlwifi-dkms in Bionic" [Undecided,In progress] https://launchpad.net/bugs/1856024
<seb128> vicamo, hey, that reprotest/focal change, if you add actual diff you need to use an ubuntu<n> version, not a build<n>
<vicamo> seb128: hi, there is no actual diff because there was an no-change-rebuild upload previously by Matthias Klose
<vicamo> he bumped version in debian/changelog, but not in setup.py, and this caused build failure
<seb128> vicamo, so why do you need an upload?
<vicamo> seb128: so that upload was not successful and there is no installable candidate even in focal-proposed
<seb128> vicamo, you edited setup.py?
<seb128> vicamo, so
<vicamo> seb128: ye
<vicamo> seb128: yes
<seb128> 1- that's a change :p
<vicamo> ok, let me update the version to ubuntu1
<seb128> 2- why is that needed?
<seb128> 0.7.10 built in Debian without that version update
<seb128> ah, that's because it's a native package and the version need to match the changelog one?
<seb128> vicamo, don't worry, I can update the version, but yeah in that case build1 seems fine
<seb128> vicamo, I will sponsor it
<vicamo> seb128: ok , thank you
<vicamo> seb128: but I'd still want to know what's the prefered version in this case. Can't find reprotest in the focal queue yet
<seb128> vicamo, build1 seems fine, we don't have actual diff we want to preserver from a debian sync
<seb128> vicamo, uploaded
<vicamo> seb128: but the one I uploaded is "0.7.10build1.1"?
<vicamo> seb128: will check some time later, doesn't appear right away
<seb128> vicamo, that looks fine
<seb128> vicamo, https://launchpad.net/ubuntu/+source/reprotest/0.7.10build1.1
<vicamo> seb128: ha, thank you
<rbalint> doko, can i cherry-pick https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0bc3450e220a4fb29f931ada84b546ce8993e85e to focal or could you please do that to fix LP: #1843479?
<ubottu> Launchpad bug 1843479 in gzip (Ubuntu) "gzip in Ubuntu Eoan results in Exec format error on WSL1" [High,In progress] https://launchpad.net/bugs/1843479
<rbalint> doko, i'm also ready to handle the sru
<doko> rbalint: sure, could you merge -6 as well?
<coreycb> tjaalton: hi, would you be able to take a look at horizon again in the unapproved queue for disco? the last upload was missing an orig tarball.
<tjaalton> coreycb: ok
<coreycb> tjaalton: thanks
<rbalint> doko, ok, will do it
<vicamo> hi, need sponsor for SRU Eoan package in https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1855825 for bug 1855825, which will hang systems with iwlwifi DKMS once eoan-proposed kernel is out
<ubottu> bug 1855825 in backport-iwlwifi-dkms (Ubuntu Eoan) "When connecting to wifi with the proposed linux-oem kernel , the system hangs" [Undecided,In progress] https://launchpad.net/bugs/1855825
<seb128> vicamo, if a kernel SRU needs to go in lock step with that update you should probably comment saying so / set verification-failed on the kernel until that one is ready as well to avoid publishing a regression to updates
<seb128> vicamo, did you talk to the kernel team about it?
<seb128> apw, ^ unsure who is the right person to make aware of that on the kernel side?
<vicamo> seb128: it's kind of complicated. Eoan kernel is out, so this is now a real problem and has seen public bug reported.
<vicamo> seb128: We're planning to land Eoan's version to Bionic in bug 1856024, so OEM platforms can retire those unofficial DKMS packages.
<ubottu> bug 1856024 in backport-iwlwifi-dkms (Ubuntu) "[SRU] Need backport-iwlwifi-dkms in Bionic" [Undecided,In progress] https://launchpad.net/bugs/1856024
<seb128> vicamo, sounds like you should make the kernel team aware still
<seb128> and maybe try to talk to the SRU team to fast track a fix
<seb128> vicamo, also make sure there is bionic kernel SRU landing regressing user, block as verification-failed
<vicamo> seb128: however, for OEM platforms, we have released fix through the old way, and that will be before OEM kernel is released
<vicamo> so, my bad, after checked again, eoan-proposed kernel has been released, and there is no gating problem any more
<coreycb> cpaelzer: I have most of the oslo autopkgtests fixed but looks like the kombu dependency (MIR) on python-importlib-metadata is causing a backup
<seb128> vicamo, so what's needed now?
<vicamo> seb128: to land Eoan SRU in bug 1855825 as soon as possible, so Eoan users suffers less
<ubottu> bug 1855825 in backport-iwlwifi-dkms (Ubuntu Eoan) "When connecting to wifi with the proposed linux-oem kernel , the system hangs" [Undecided,In progress] https://launchpad.net/bugs/1855825
<seb128> vicamo, you need to talk to the kernel team and SRU teams for that
<seb128> try on #ubuntu-release also
<seb128> bdmurray, ^ can you help with that? seems like a kernel SRU in 19.10 regressed XPS users
<vicamo> seb128: I will have to go offline for an hr or so in 10 minutes to catch the last train. My apologies in advance.
<seb128> vicamo, no worry, I'm sponsoring you 19.10 SRU but you need an SRU member to help getting it accepted then
<coreycb> doko: subscribed openstack packagers to the packages for bug 1851393
<ubottu> bug 1851393 in python-zipp (Ubuntu) "[MIR] python-importlib-metadata (required by kombu)" [High,New] https://launchpad.net/bugs/1851393
<seb128> sil2100, bdmurray, vorlon, ^  backport-iwlwifi-dkms in 19.10 SRU queue fixes a pretty important issue for XPS users follow a kernel SRU, might be worth fast tracking if possible
<vicamo> seb128: yes, that's what I need. I got a team member who can review this, but need another person to upload :)
<apw> seb128, ack
<bdmurray> apw: so are you handling this issue?
<apw> bdmurray, oh no i was just admiting i needed to be warned about it
<apw> bdmurray, those kernels are not going out till the new year i believe
<rbasak> Should this new kernel be declaring a Breaks on backport-iwlwifi-dkms then?
<rbasak> Though I know it's a bit weird with kernels because an installed kernel isn't necessarily the one that is running.
<apw> rbasak, though the kernel out there already needed it
<apw> if i am reading this right
<rbasak> I thought it was just the one in proposed?
<rbasak> Anyway, I'd best not add another cook to the broth.
<apw> oh yeah it is out in eoan
<rbasak> I just thought I'd mention Breaks in case that needs considering.
<apw> rbasak, yeah too late for eoan, maybe not for bionic
<rbasak> There might still be some value for Eoan - for users who upgrade infrequently, or do an install and upgrade in the future.
<rbasak> (to add a Breaks in the next update)
<danboid> After months of pain, trial and error etc I've finally got openstack deployed via a juju charm bundle
<danboid> As as result, I've got a few corrections and suggestions for the docs here https://jaas.ai/openstack-base
<danboid> Where do I submit my suggestions?
<danboid> Do I submit them as a bug report against the charm?
<danboid> It's OK! A bug report has been requested by one of the charm devs
<rbalint> doko, i'm doing a test-rebuild of merged binutils, then will upload in ~2 hours
<rbasak> bryce: FWIW, to view previous inline comments in an MP on LP, use the dropdown box just underneath where it says "Preview Diff"
<rafaeldtinoco> rbasak: there is a MR from bryce to autofs
<rafaeldtinoco> rbasak: i can't upload it (no rights), and he is off today
<rafaeldtinoco> would u mind pushing and uploading it ?
<rafaeldtinoco> actually its not from him, its from ahasenac_k but he is also off
<rafaeldtinoco> =)
<rafaeldtinoco> its already approved  but we didnt want to wait until EOY to push it
<rbasak> rafaeldtinoco: link please? It's not listed at https://code.launchpad.net/~canonical-server/+activereviews
<rbasak> rafaeldtinoco: no core devs in our team will be around next week?
<rafaeldtinoco> rbasak: not sure i mean its not urgent or anything
<rafaeldtinoco> rbasak: https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/376722
<rafaeldtinoco> bryce: will be around next week also
<rafaeldtinoco> bryce: ^ for when you're back then
<bryce> okie doke
<rbasak> rafaeldtinoco, bryce: I don't mind doing it next week either, but given it's not urgent I'm EOD now :)
<rafaeldtinoco> rbasak: yes yes ignore me
<rafaeldtinoco> rbasak: have a nice weekend o/
 * gQuigs can't if these are real test failures or not - I'm guessing no, but would love a confirmation
<gQuigs> python-ldap   Regression in autopkgtest for barbican (armhf): test log
<gQuigs> python-ldap
<gQuigs> Regression in autopkgtest for salt (s390x): test log
 * gQuigs can't press the magic retry button
#ubuntu-devel 2019-12-14
<juliank> oh hell, llvm 9 takes ~ 4 hours to build - I won't be installing that toda
<juliank> y
#ubuntu-devel 2019-12-15
<alkisg> Hi, sorry for asking here, but I think my question requires ubuntu-devel tools which aren't common knowledge...
<alkisg> I'm on 18.04 and I want to get the source of e.g. ipxe *from 20.04*. What's the easiest way to do that? (i.e. with a command line tool, not having to manually download it from https://launchpad.net/ubuntu/+source/ipxe/1.0.0+git-20190109.133f4c4-0ubuntu2)
<alkisg> Got it! pull-lp-source ipxe focal
<rbasak> xnox, ahasenack: here you go https://lists.debian.org/debian-devel/2019/10/msg00238.html :-)
<rbasak> "should all bug reports be filed against /source/ packages?"
