[00:01] <slangasek> ogra: there are occasionally alphas being offered on the debian-alpha mailing list that are located much closer to you :)
[00:01] <ogra> yeah, i'm not running after one, if i stumble over it i'll take it ...
[00:01] <ogra> but alpha is defiately one i want in the collection :)
[00:03] <slangasek> anyway, if you want one that /runs/, the one I'm using as a doorstop doesn't qualify
[00:03] <slangasek> it's my spare parts chassis
[00:03] <liw> ogra, my local favorite computer store has no less than three alphas on their list... I don't know what shipping from Finland would cost, but if you want one, it might be possible to arrange it
[00:03] <slangasek> but for fun, I could bring it with me as a checked luggage item to London
[00:03] <slangasek> through Heathrow
[00:04] <slangasek> no-fee computer recycling, just take it to Heathrow and let them lose it
[00:04] <ogra> slangasek, i wont be in london :(
[00:04] <slangasek> oh, right
[00:04] <slangasek> well then I could make kees take it ;)
[00:04]  * ogra is already missing everyone
[00:05] <kees> eek.
[00:05] <kees> I bet I have suitcase big enough, it just needs to be under 50lbs
[00:06] <slangasek> :-)
[00:06] <slangasek> why use a suitcase, that takes all the fun out of it
[00:06] <slangasek> just use one of the luggage-baling machines at the airport
[00:06] <kees> ooh, this is reaaaly good.  intrepid chroot: quilt ok.  my intrepid host: quilt freaky
[00:07] <ogra> its a hardware issue :P
[00:07] <kees> heh
[00:10]  * TheMuso had an alpha for a while, but it died a slow death.
[00:11] <pochu> doko: ok, so let's keep with the current solution. thanks for the info
[00:59] <slangasek> superm1: I see that we have a pending mythbuntu-control-centre SRU that appears to account for most of the on-ISO delta between the 8.04.1 test images and the -updates pocket
[00:59] <slangasek> superm1: can we finalize this SRU today?
[01:00] <slangasek> superm1, Daviey: oh, speaking of which, those alternate images are at http://cdimage.ubuntu.com/mythbuntu/hardy/daily/current/ :)
[01:19] <slangasek> TheMuso: there are a couple of ubuntustudio-related SRUs to finish as well; #175536 and #221382, do you have time to follow up on these or is there someone else you can prod about them?
[01:20] <slangasek> superm1: also bug #220087, an SRU for mythplugins, needs to be closed out
[01:36] <TheMuso> slangasek: I'll have a look at them now.
[02:04] <slangasek> laga: have any tests been done to confirm that the mythbuntu-control-centre in the archive fixes bug #221921?
[05:42] <dholbach> good morning
[05:42] <dholbach> bdmurray: could you figure out which patch of thekorn fixed the problem?
[05:43] <dholbach> at http://people.ubuntu.com/~dholbach/sponsoring/ I pull from .main, but it's not working :-/
[05:44] <ion_> Hi
[05:45] <bdmurray> dholbach: what revno are you on now?
[05:45] <dholbach> 107
[05:46] <bdmurray> and with which branch does it work?
[05:47] <dholbach> I don't know - it works with the package in PPA, thekorn mentioned "intrepid.merge"
[05:47] <dholbach> I'm not on top of things in pylpbugs land
[05:47] <bdmurray> well, we merged intrepid.merge with .main today so that's why I'm confused
[05:48] <dholbach> hmhmhm
[05:48] <bdmurray> and printing bug.summary with rev 107 works for me
[05:49] <dholbach> ok, let me try to run the script again
[05:49] <bdmurray> okay, let me know
[05:50]  * dholbach hugs bdmurray
[05:51] <dholbach> ah, different crash
[05:52] <bdmurray> that's interesting
[05:52] <dholbach>     for bug in BugList(link):
[05:52] <dholbach>   File "/home/dholbach/public_html/sponsoring/launchpadbugs/connector.py", line 117, in __call__
[05:52] <dholbach>     progress_hook=self.__progress_hook)
[05:52] <dholbach> TypeError: set() does not take keyword arguments
[05:54] <dholbach> maybe it's a python2.4 vs python2.5 thing?
[05:54] <dholbach> rookery still has 2.4
[05:54] <bdmurray> oh, right
[05:55] <bdmurray> it doesn't look like it
[05:56] <dholbach> no, I'm having the same problem with 2.5 too
[05:57] <bdmurray> well, thats good
[05:57] <bdmurray> can you pastebin the code again?
[05:57] <dholbach> if you  bzr branch http://people.ubuntu.com/~dholbach/sponsoring/  you have an example
[05:58] <dholbach> python2.4 seems to have a different error than python2.5 has
[05:58] <dholbach> I can pester thekorn about it too, if you like :)
[05:59] <bdmurray> it is late here but I'll give it a shot
[06:00] <dholbach> don't worry - I'll pester thekorn about it
[06:00]  * dholbach hugs bdmurray
[06:31] <cody-somerville> Can someone please process this merge request? :)
[06:31] <cody-somerville> https://code.edge.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.intrepid/+merge/405
[06:53] <pitti> Good morning
[06:53] <dholbach> hi pitti
[06:54] <pitti> kees: libapparmor-perl> just a MIR bug is fine
[06:55] <pitti> kees: oh, right, what cjwatson says; binary-only promotion is fine
[06:57] <Hobbsee> hey pitti!
[07:11] <tjaalton> hi, could someone help with sed.. I need to change 's%.*/%%' to match "until the second /", not last
[07:12] <slangasek> s%[^/]/%% ?
[07:12] <slangasek> sorry, s%[^/]*/%%
[07:12] <pitti> tjaalton: [^/]*/[^/]*/
[07:12] <slangasek> oh, second one, then probably pitti's
[07:13] <pitti> tjaalton: erm, without the final /, sorry
[07:13] <pitti> tjaalton: anyway, [^/] means "any character except /"
[07:13] <slangasek> also, that fails in the case that there are no / in the string, if that's an issue
[07:13] <tjaalton> thanks! 's%[^/]*/[^/]*/%%' works
[07:14] <pitti> tjaalton: if you need "at most two", you need to enclose the second one in ()?
[07:14] <tjaalton> mesa configure.ac is buggy btw ;)
[07:15] <tjaalton> since I wanted to have --libdir=/usr/lib/foo, and it would use /usr/foo
[07:15] <slangasek> curious
[07:17] <tjaalton> ok, then if I had /foo, the result should be foo
[07:18] <dholbach> that reminds me of http://regex.info/blog/2006-09-15/247 :)
[07:20] <tkamppeter> Any Python library expert here?
[07:21] <tkamppeter> I am packaging the new system-config-printer and it contains a Pythong library for general use now.
[07:21] <tjaalton> dholbach: indeed :)
[07:22] <ScottK> pitti: Is what I have in Bug #245096 sufficient for the removal?
[07:22] <tkamppeter> It puts .py files into /usr/lib/python2.5/site-packages/cupshelpers/
[07:23] <tkamppeter> So I add a rule to the debian/rules file to execute "dh_pysupport -ppython-cupshelpers /usr/lib/python*/*/cupshelpers/"
[07:24] <tkamppeter> And let these files go into a package named python-cupshelpers
[07:24] <tkamppeter> Problem is now that the byte-compiler complains about
[07:24] <tkamppeter> from .cupshelpers import parseDeviceID
[07:24] <tkamppeter> and
[07:25] <tkamppeter> from . import _debugprint
[07:25] <tkamppeter> in the .py files when I install python-cupshelpers
[07:26] <tkamppeter> It says "Syntax error" on these.
[07:26] <tkamppeter> Running system-config-printer with these files works.
[07:27] <dholbach> hi mvo
[07:28] <pitti> tkamppeter: nice, you are packaging the cupshelpers?
[07:28] <tkamppeter> pitti, I am doing so as they are part of the source tarball of system-config-printer
[07:29] <tkamppeter> So python-cupshelpers is a binary package created from the source package s-c-p.
[07:29] <pitti> tkamppeter: I had a look at it last week, works nicely
[07:30] <pitti> tkamppeter: why the path for dh_pysupport?
[07:30] <tkamppeter> Perhaps Tim Waugh is not much familiar with the Python library policy of Debian
[07:30] <pitti> tkamppeter: it shuold just work with no arguments
[07:30] <pitti> tkamppeter: he shouldn't need to know about it
[07:31] <tkamppeter> pitti, does dh_pysupport find /usr/lib/python*/*/PACKAGE by itself? It is not documented in the man page.
[07:31] <pitti> tkamppeter: it's supposed to, at least
[07:31] <ScottK> tkamppeter: Generally it does.
[07:31] <tkamppeter> pitti. Can it be that
[07:31] <tkamppeter> from .cupshelpers import parseDeviceID
[07:31]  * ScottK notices the time and heads to bed.
[07:31] <tkamppeter> and
[07:31] <ScottK> Good night all.
[07:31] <pitti> I'm not sure, dh_py{centrla,support} is still somewhat black magic to me
[07:31] <tkamppeter> from . import _debugprint
[07:31] <pitti> ScottK: looking at your bug
[07:31] <StevenK> pitti: Only somewhat?
[07:32] <tkamppeter> is something new of Python 2.5?
[07:32] <ScottK> pitti: I'll wait up then.
[07:32] <pitti> ScottK: looks obvious to me
[07:32] <ScottK> pitti: OK.  It seemed so to me, but thought I'd make sure.
[07:32] <ScottK> It's late and I'm tired, so who knows how well I'm thinking.
[07:33] <pitti> ScottK: I'll remove and update the bug
[07:33] <tkamppeter> The mentioned error mentions also Python 2.4, and the default Python under which s-c-p is running is 2.5.
[07:33] <ScottK> pitti: Thanks.  And thanks for getting libmilter promoted quickly so this particular problem could go away.
[07:33] <tkamppeter> Is there a way to run dh_pysupport with Python 2.4 excluded?
[07:34] <ScottK> tkamppeter: Yes.  If you were using pycentral you could set XS/XB-Python-Versions:current
[07:35] <ScottK> You can do it in pysupport too, but it's not obvious. You use pyversions and set it to 2.5 there.
[07:35] <mvo> dholbach: hello!
[07:35] <ScottK> Of course it's 2:35AM here, so I could be completely full of it.
[07:35] <dholbach> hi thekorn
[07:36] <ScottK> Good night.
[07:36] <tkamppeter> So pycentral and pysupport are two different programs for the same task, like vi and emacs?
[07:36] <thekorn> dholbach, hi
[07:37] <tkamppeter> ScottK, How do I use "pyversions"?
[07:37] <ScottK> tkamppeter: As I said, I'm headed to bed, but it's just another file in debian.  As compat may have '5' in it, make pyverssion with '2.5' in it.
[07:37]  * ScottK really going to bed now.
[07:39] <slytherin> any archive admins around?
[07:44] <Hobbsee> slytherin: -v
[07:44] <Hobbsee> slytherin: (there are always some here, but may not be watchnig the screen)
[07:44] <persia> Also, they tend to be more likely to respond when asked a specific question :)
[07:45] <slytherin> A package needs to be moved to multiverse. A bug was fixed recently which added build dep on sun jdk. bug 189125
[07:48] <slytherin> Hobbsee: ^^
[07:49] <Hobbsee> pitti: do you want to demote that without a bug, or?
[07:50] <Hobbsee> (it's fallen into depwait)
[07:51] <pitti> xmlgraphics-commons?
[07:51] <Hobbsee> yes
[07:52] <slytherin> I was going to file bug. But geser suggested yesterday to just bug some archive admin. :-)
[07:53] <pitti> hm, it's in Debian contrib
[07:53] <pitti> moved
[07:54] <slytherin> pitti: thanks.
[07:55] <tjaalton> ... how to make autoreconf not to strip []'s from the sed script?-)
[08:08] <slangasek> tjaalton: hard to say without context, but [ is a magic character in the m4 language used for autoconf preprocessing
[08:08] <slangasek> tjaalton: so [[] []], I think?
[08:08] <slangasek> (or maybe just the first)
[08:11] <tjaalton> slangasek: thanks, I'll try that
[08:15] <tkamppeter> pitti, ScottK, thank you very much, now my first Python library package works.
[08:16] <pitti> tkamppeter: \o/
[08:16] <pitti> tkamppeter: fun, today I was just going to ask you about packaging cupshelpers :)
[08:16] <pitti> tkamppeter: (since I need it for integrating it into jockey for printer driver management)
[08:21] <tkamppeter> pitti, it is nearly ready to upload, one quick test and I will dput it
[08:22] <tjaalton> slangasek: adding both of them worked :)
[08:22] <slangasek> cool
[08:25] <tkamppeter> pitti, "lintian python-cupshelpers*.deb" says
[08:25] <tkamppeter> W: python-cupshelpers: old-versioned-python-dependency depends: python (<< 2.6)
[08:26] <tkamppeter> but on my up-to-date (as of yesterday) intrepid there is only Python 2.5.
[08:26] <tkamppeter> Is Debian already on 2.6
[08:28] <slangasek> haha, good one ;)
[08:28] <slangasek> what does lintian -i give as an explanation?
[08:30] <tkamppeter> lintian tells that if the package requires a ceratin Python version that I have to add a Python-Version control field.
[08:30] <tkamppeter> What is a Python-Version control field
[08:30] <tkamppeter> I have
[08:30] <tkamppeter> XS-Python-Version: current
[08:30] <tkamppeter> in debian/control.
[08:31] <slangasek> is the python (<< 2.6) written verbatim in debian/control?
[08:31] <tkamppeter> And in general, my package should work with any Python of version 2.5 or higher, it does not work with 2.4 or lower.
[08:32] <tkamppeter> slangasek, no, it is inserted by dh_pysupport.
[08:32] <slangasek> ok, I have no idea what that lintian warning means then.
[08:41] <dholbach> bdmurray: thekorn fixed it in .main!!! :)
[09:03] <tkamppeter> slangasek, thanks, I will leave it alone for now. For Intrepid it works
[09:11] <tkamppeter> pitti, new s-c-p with python-cupshelpers is on the way to the archive...
[09:11] <pitti> tkamppeter: nice, thanks! it'll land in binary NEW, I'll have a look at it
[09:27] <cjwatson> cody-somerville: pulled, sorry for the delay
[09:32] <MacSlow> where's the upstream of libpam?
[09:33] <jengelh> kernel.org
[09:34] <MacSlow> jengelh, taking a look... thanks!
[09:34] <nightwish> hi! is anyone of the kernel team available? i'd like to know wether and when bug #199934 will be fixed. a working patch is already attached, and i think the icp vortex support is still critical for many people running ubuntu on servers...
[09:35] <jengelh> i think this got fixed in 2.6.25
[09:36] <nightwish> yes, correct. however, i doubt we'll get 2.6.25 in 8.04
[09:36] <jengelh> what a pity :p
[09:39] <nightwish> indeed. this means if i want to stay with lts, i will either have to build my own kernels until the next lts arrives or will have to revert back to 6.06? or is there any chance to get that patch included in the 8.04 kernel somewhen?
[09:39]  * jengelh happily runs a distro with 2.6.25 by default.
[09:41] <james_w> nightwish: there's a -kernel channel
[09:42] <nightwish> ah
[09:42] <nightwish> ok
[09:42] <MacSlow> I assume there are no plans to move to libpam 1.x fore Intrepid, right?
[09:44] <pitti> MacSlow: anything is possible in intrepid at this stage
[09:45] <MacSlow> pitti, ok... atm I've trouble getting upstream gdm compiled as it is using a struct form libpam, which is only part of the newer libpam-1.x
[09:46] <mvo> pitti: I updated the package-groups-discssion document, I think its good for sending now
[09:49] <tkamppeter> pitti, I have a problem with using my new python-cupshelpers now
[09:49] <tkamppeter> After installing it I have
[09:49] <ogra> pitti, do you know any replacement for time-admin ? seems to be the only g-s-t app we use in mobile
[09:50]  * ogra wouldnt like to see g-s-t persist just for that
[09:50] <seb128> ogra: do you use gnome-panel there?
[09:50] <pitti> ogra: the gnome panel already handles that nowadays, AFAIUI?
[09:50] <ogra> seb128, we might in the future
[09:51] <MacSlow> pitti, to be more precise the new sturct was introduced with libpam-0.99.10.0
[09:51] <ogra> nono, we need something that sets timezone on system level and the like
[09:51] <tkamppeter> ls /var/lib/python-support/python2.5/cupshelpers/
[09:51] <tkamppeter> cupshelpers.py   __init__.py   openprinting.py   ppds.py
[09:51] <tkamppeter> cupshelpers.pyc  __init__.pyc  openprinting.pyc  ppds.pyc
[09:51] <ogra> does the panel go that deep down ?
[09:51] <seb128> ogra: gnome-panel uses policykit to set the system timezone
[09:51] <ogra> oh, cool
[09:52] <pitti> seb128: hm, it looks like "set date/time" actually just calls time-admin?
[09:52] <pitti> yep, it does
[09:52] <tkamppeter> pitti, now I want to use functions in cupshelpers.py and in ppds.py
[09:52] <ogra> in hardy for sure
[09:52] <tkamppeter> I do
[09:52] <pitti> right, on hardy
[09:52]  * ogra doesnt have any intrepid and likely wont before the sprint
[09:52] <pitti> tkamppeter: after installing the package, "import cupshelpers" should work
[09:52] <seb128> pitti: yes, we changed before hardy to use this one because the gnome-panel had no ntp sync option and quite some users complained
[09:52] <tkamppeter> import cupshelpers
[09:52] <seb128> pitti: should be fixed this cycle
[09:52] <pitti> seb128: aah, nice
[09:53] <tkamppeter> and it does not find the functions in ppds.py
[09:53] <tkamppeter> pitti, __init__.py contains "import ppds"
[09:54] <ogra> seb128, right, ntp is essential on UME
[09:56] <pitti> tkamppeter: "import ppds" in __init__.py doesn't make sense
[09:56] <pitti> tkamppeter: (AFAIK)
[09:56] <pitti> tkamppeter: you need to explicitly "import cupshelpers.ppds"
[09:56] <tkamppeter> pitti, so there is perhaps a problem in the upstream code?
[09:56] <pitti> in the program where you want to use it
[09:56] <pitti> tkamppeter: well, I might misunderstand __init__.py's special magic
[09:59] <tkamppeter> "import cupshelpers.ppds" does not work, too. Same error.
[10:01] <tkamppeter> pitti, how does a multiple-file Python library work? Is "import cupshelpers" running __init__.py in the cupshelpers directory or is it running cupshelpers.py whereever it finds a file with this name?
[10:06] <tkamppeter> pitti, I have found the solution:
[10:07] <tkamppeter> "import cupshelper" is enough, but all function calls "ppd. ..." have to be changed to "cupshelpers.ppd. ...".
[10:08] <tkamppeter> pitti, is this normal or should something need to be changed in the upstream code?
[10:11] <pitti> tkamppeter: this sounds pretty normal
[10:11] <slangasek> ok wtf; as if thunderstorms in western oregon aren't weird enough, now we're getting hail too?
[10:11] <pitti> tkamppeter: ah, so the import in __init__.py makes "import cupshelpers" suffice
[10:11] <pitti> instead of "import cupshelpers.ppd"
[10:17] <bigon> infinity, still not around?
[10:20] <ogra> slangasek, you did a lot in grub in the past, do you have any idea if we can switch to grub2 in intrepid ?
[10:21] <slangasek> ogra: the things I've done in grub don't qualify me to have an opinion on that; what I know from the Debian side is that lenny, which is due in the same timeframe, doesn't look like it will use grub2 by default
[10:21] <ogra> the mobile team is just discussing merges and there is one grub merge thats not in ubuntu .... grub2 would make that obsolete
[10:21] <slangasek> (the grub maintainers wanted this, but it doesn't appear to have coalesced yet)
[10:21] <ogra> well, i remember we discussed it pre release, but dont remember the outcome ...
[10:22] <slangasek> I think we last discussed it at UDS Boston
[10:22] <ogra> apart from that "fast-resume" sounds like a patch ubuntu might like to have as well :)
[10:23] <ogra> so we could probably just merge it in general and not have it as separate mobile patch
[10:25] <slangasek> hmm?
[10:26] <ogra> there is a patch thats called fast-resume thats only used on lpia atm
[10:27] <ogra> preferably those mobile patches should go into te main ap where possible so the mobile team doesnt have to carry all that ... there are way to many custom changes in mobile so each oe that can go to the normal package counts :)
[10:40] <Keybuk> slangasek: are there any known 8.04.1 issues?
[10:40] <slangasek> Keybuk: care to limit the scope of that query any? :)
[10:40] <Keybuk> slangasek: I'm running hardy+proposed+updates and in the last week or so, my machine is behaving very strangely
[10:40] <Keybuk> random hangs, failing to launch apps, etc.
[10:41] <slangasek> hrm
[10:41] <slangasek> no, I haven't heard of anything like that
[10:41] <Keybuk> Jul  2 14:24:25 quest kernel: [68849.261370] gnome-terminal[6744] general protection rip:7fe5d7305f58 rsp:7fffe2253460 error:0
[10:41] <ogra> uuuh
[10:41] <Keybuk> seeing lots of things like that in dmesg
[10:42] <slangasek> well, the kernel itself hasn't been updated in the past week, that I recall
[10:42] <slangasek> only lrm
[10:43] <slangasek> and that just to drop a pre-built driver
[10:43] <cjwatson> Keybuk: have you attempted to rule out hardware trouble?
[10:43] <cjwatson> particularly if the set of things that's failing does not seem especially consistent
[10:44] <Keybuk> cjwatson: not yet, it's hard to rule out
[10:44] <Keybuk> but it strikes me as suspicious
[10:45] <Keybuk> it was about  week ago I installed linux-image-2.6.24-19.34
[10:46] <persia> Keybuk: Downgrade and see if it goes away?
[10:46] <Keybuk> persia: that's what I'm just doing
[10:47] <cjwatson> certainly wouldn't hurt to compare your hardware against the set of things changed in that kernel
[10:48] <Keybuk> cjwatson: there were a few hits of that
[10:50] <Keybuk> I'm pretty sure I saw an updated nvidia driver
[10:50] <Keybuk> which would usually be the first thing I'd blame
[11:00] <Keybuk> ok, rebooting to downgrade
[11:02] <Keybuk> not for the fortieth time, I wish that session management worked properly ;)
[11:03] <StevenK> Keybuk: Four-hundredth, perhaps? :-)
[11:03] <Keybuk> StevenK: I don't reboot that often
[11:04] <Keybuk> which is why having to reboot several times this last week has been such a trauma ;)
[11:05] <MacSlow> Does someone know if Jamie Strandboge is around here?
[11:05] <StevenK> Keybuk: Haha
[11:05] <pitti> MacSlow: jdstrand, but unlikely to be awake at this hour
[11:06] <pitti> StevenK: I certainly cursed broken session management that often :)
[11:06] <MacSlow> pitti, ah ok... well I've issues getting Linux-PAM (upstream and the 1.0.1 release compiled)
[11:06] <StevenK> Note to self: Storing a backup in /tmp and then rebooting did not work as planned.
[11:06] <pitti> StevenK: undelete /tmp/* ... oh, wait
[11:06] <MacSlow> pitti, I'm just looking for somebody who's a bit experienced with pam and related things to help me get it to compile
[11:07] <pitti> MacSlow: jdstrand and slangasek are your best bets, I think; but particularly for slangasek, you shuold rather mail him instead of IRC
[11:07] <MacSlow> pitti, btw... I also contacted one of the upstream devs, but don't know how fast they will responsd
[11:08] <StevenK> pitti: Meh, it's just a backup, I'll just wait for the cron job I wrote. :-)
[11:12] <slangasek> MacSlow: why are you trying to compile 1.0.1? :/
[11:14] <MacSlow> slangasek, oh... ehm email is just on it's way.
[11:14] <MacSlow> slangasek, well... I need it because of the new gdm
[11:14] <slangasek> um
[11:15] <MacSlow> slangasek, it uses a new struct from PAM introduced with Linux-PAM 0.99.10.0
[11:15] <MacSlow> slangasek, it's the pam_xauth_data structure
[11:16] <MacSlow> slangasek, in Linux-PAM it was added december last year... in gdm the use of this new Linux-PAM feature was added just last week :/
[11:16] <slangasek> well, merging such a critical security lib straight to the new upstream without some inspection of the changes is... imprudent
[11:17] <slangasek> I intend to get pam updated for the intrepid cycle, but yeesh at upstreams depending on non-portable features of Linux-PAM 0.99.10 and above
[11:17] <MacSlow> slangasek, I feared something like that... and always ask myself why such things have to happen to me :/
[11:17]  * ogra wonders how that will affect remote commections again ... 
[11:17] <ogra> it took me nearly a month to get xauth right for everything in ltsp ...
[11:18] <slangasek> I guess that means GNOME doesn't care so much about Solaris anymore? :)
[11:18] <ogra> i hope they dont break backwards compatibility
[11:18]  * MacSlow is so "happy" to have to show something working next week
[11:18] <MacSlow> atm my best idea to get "around" this it to revert that gdm-patch and use an older version
[11:18] <ogra> but pam is woven into many many things in the distro ... updating that ill be a major task for all teams from server to mobile
[11:19] <Ng> slangasek: does anyone? ;)
[11:19]  * MacSlow feels that something in this universe hates him
[11:19] <slangasek> MacSlow: unless the xauth feature is relevant to what you're showing, I would strongly recommend selectively backing out that upstream change rather than fighting to build PAM and then fighting to understand why your whole authentication system has subtly changed
[11:20] <MacSlow> slangasek, ogra: well your comments are indication enough for me to not try to push for this just yet
[11:20] <slangasek> MacSlow: I mean, if you really *want* to be my guinea pig for testing the new upstream version with the Debian/Ubuntu patch set, be my guest ;)
[11:20] <MacSlow> slangasek, no way... I've far too little experience with such security-related libraries and tools to be wanting this battle
[11:21] <slangasek> ogra: not to worry, I have a great martyr complex and am happy to bear the task of updating PAM on my own ;-)
[11:21] <ogra> MacSlow, it doesnt need to be a bad thing .... i for one would appreciate if i could drop my xauth handling in lts *if* pam_xauth_* would handle remote auth data properly
[11:21] <ogra> i just say it wont be a small transition and affect all teams :)
[11:22] <ogra> *ltsp
[11:22] <slangasek> hah, that pam_xauth thing is the thing that I objected to as being bad design when they committed it upstream, isn't it :P
[11:22] <ogra> heh
[11:22] <slangasek> and unfortunately I lacked the time to follow through, so now we're saddled with unnecessary vendor divergence from the PAM spec, ohwell
[11:23] <MacSlow> slangasek, ogra: thanks for the insight sofar... I'm fine with reverting to an older gdm
[11:26]  * slangasek waves buh-bye to east Portland as the storm knocks it off the network
[11:29]  * ogra still waits for the announced one in germany to approach
[11:31] <slangasek> MacSlow: btw, your build failure appears to be because you're building with -DDEBUG; I don't think you want to do that anyway...
[11:32] <MacSlow> slangasek, I explicitly added --disable-debug to configure... so I'm surprised it still does define DEBUG
[11:33] <slangasek> right, well, I guess that just confirms that you don't want to be touching this without proper protective clothing :)
[11:35] <pitti> oh, nice: https://code.edge.launchpad.net/~nderkach/apport/opensuse
[11:38] <MacSlow> slangasek, the cheap solution is of course to comment out that particular line
[11:59] <cjwatson> pitti: re yesterday's conversation about libelf, demoting libelf means that bug-buddy is uninstallable in intrepid, which is pretty inconvenient. Could I promote it back and file a targeted bug instead?
[12:01] <pitti> cjwatson: works for me
[12:05] <cjwatson> done
[12:50] <laga> slangasek: i asked people to test #221921 but nobody bothered :( i'll ask again later
[13:04] <zul> morning
[13:08] <emgent> hi zul :)
[13:09] <zul> hi emgent
[14:24] <Riddell> kees: what did you make of libzip?
[14:32] <tedg> Riddell: I can't imagine that kees is awake yet, it's 630 his time.
[14:44] <tjaalton> is it valid to upload -0build1?
[14:44] <ion_> There has been a -0 uploaded?
[14:44] <tjaalton> no
[14:45] <tjaalton> I mean that it would then sync with -1 automatically
[14:45] <tjaalton> maybe I'll just do -0ubuntu1..
[14:45] <sistpoty|work> tjaalton: not right now (since past DIF), but iirc in theory yes
[14:45] <tjaalton> sistpoty|work: right, good point
[14:46] <geser> tjaalton: are you sure that debian will contain all changes you did to the package?
[14:47] <tjaalton> geser: there are no changes. it's the same as current -1 candidate
[14:47] <tjaalton> so if -1 will end up with more changes it wouldn't matter
[14:47] <geser> ah, then it should be ok to upload as -0build1
[14:48] <tjaalton> but since I don't expect these to hit unstable before intrepid is close to being released it doesn't matter
[14:49] <tjaalton> but.. just curious :)
[14:49] <geser> tjaalton: but as you need to file a sync request either way it doesn't really matter if it's -0build1 or -0ubuntu1
[14:50] <geser> in that case -0build1 will get auto-synced in intrepid+1
[14:50] <tjaalton> heck, let's see how it goes. if we need to change it the it can be renamed
[14:51] <tjaalton> *then
[14:53] <tjaalton> there, libdrm uploaded
[15:04] <sistpoty|work> tjaalton: does your upload mean we might get nouveau for intrepid soon? *g*
[15:05] <tjaalton> sistpoty|work: 2.3.1 is not enough for nouveau :/
[15:05] <sistpoty|work> :(
[15:05] <tjaalton> experimental has drm-snapshot & nouveau
[15:06] <ogra> oooh
[15:06] <ogra> Riddell, switched KDE to g-p-m as well now :)
[15:07] <Riddell> ogra: as an acronym, yes
[15:07] <ogra> (even though the first word seems a bit mistyped in the name there :) )
[15:19] <BenC> Would someone mind NEWing linux 2.6.26-3.9, please?
[15:19] <jengelh> newing?
[15:20] <BenC> jengelh: processing it into the archive now that it's built
[15:20] <jengelh> what archive
[15:20] <jengelh> kernels come in source form generally
[15:20] <ogra> BenC, is there a spec or something about the future of the different flavours that are gone now ?
[15:20] <BenC> ogra: it's on the kernelteam UDS discussion wiki
[15:20] <ogra> jengelh, the package archive
[15:20] <ogra> BenC, gracias :)
[15:21] <BenC> jengelh: the people that can help me will know what I mean
[15:21] <jengelh> oh nuts
[15:21] <jengelh> -EWRONGCHANNEL
[15:21] <BenC> hehe
[15:21] <jengelh> kinda felt like ##kernel
[15:22] <ogra> yeah, thast the aura BenC carries with him
[15:23] <Nafallo> jengelh: he was in the office and it felt like ##kernel ;-)
[15:23] <Nafallo> the rest of the kernel team might have influenced that though :-P
[15:27] <milosz> hey all
[15:27] <milosz> how can i determine whether a package has a maintainer?
[15:27] <milosz> i'd like to take over maintainership (in code and maybe packaging) for an app that seems unmaintained
[15:28] <Riddell> milosz: we don't typically have formal maintainers.  but look at the changelog and see who's been working on it
[15:28] <milosz> Riddell, the source package changelog?
[15:28] <Riddell> yes
[15:28] <milosz> or an Ubuntu-specific one?
[15:28] <milosz> ah ok
[15:28] <Riddell> in debian/changelog
[15:28] <milosz> ok allright
[15:30] <milosz> there's no debian/ directory in the source tarball (which i got from packages.ubuntu.com)
[15:30] <jengelh> these debian/ dirs seem quite obstructive
[15:30] <ogra> if you have it installed look in /usr/share/doc/<packagename>/
[15:30] <ogra> there you usually got the debian changelog
[15:30] <milosz> oh yeah there it is
[15:31] <milosz> hmm the last change is from 2006
[15:31] <ogra> deb packages consist of three files, not only the source tarball
[15:31] <milosz> the dsc file and the .diff file?
[15:32] <ogra> right
[15:32] <milosz> sorry i'm just really a noob at .deb packaging
[15:32] <milosz> i guess i'll ask
[15:32] <ogra> #ubuntu-motu is a good school :)
[15:32] <milosz> ask a friend of mine to do the packaging, i just want to mostly take over maintainership of code
[15:32] <milosz> ah
[15:32] <pochu> milosz: for code maintainership you likely want to contact/become upstream maintainer
[15:32] <ogra> for the code you should contact upstream
[15:33] <milosz> yeah i was going to mail the guy anyway
[15:33] <milosz> what's the formal procedure?
[15:33] <milosz> what if i don't get any response (the website at least is gone)?
[15:33] <milosz> can i just assume upstream maintainership in that case?
[15:33] <ogra> we're mainly doing the packaging ... only rarely changing the upstream code
[15:34] <ogra> the upstream tarball should have an AUTHORS file or some such
[15:34] <pochu> milosz: if it's open source, you likely can fork it
[15:34] <ogra> and an upstream ChangeLog file as well
[15:34] <persia> milosz: If upstream is gone, and you can't find them, you can create a new website.  In that case, you likely want to chat with the Original-Maintainer to determine where/what is good.
[15:34] <milosz> ok
[15:34] <ogra> either of these files should have a mail adress in it
[15:35] <ogra> to contact the last upstream maintainer
[15:35] <persia> Shouldn't all the core upstream people be listed in debian/copyright anyway?
[15:36] <milosz> there's one person listed in the debian copyright file but it's not the upstream maintainer
[15:36] <persia> Which package is this?
[15:37] <Riddell> asac: I got knetworkmanager 0.7 working to the extent that it shows itself and which wifi networks it can see, but can't connect to anything
[15:37] <Riddell> asac: however that's better than nm-applet which doesn't even show itself
[15:38] <asac> Riddell: haha
[15:38] <asac> Riddell: works here ;)
[15:38] <asac> intrepid not yet done though
[15:38]  * ogra thought there were standards for system tray implementations ... doesnt nm-applet respect them ? 
[15:38] <ogra> i thought systray apps were interchangeable by design
[15:38] <Riddell> ogra: yes, it seems to be a gtk issue Gtk-CRITICAL **: gtk_notebook_set_tab_label: assertion `GTK_IS_WIDGET (child)' failed
[15:38] <ogra> bah
[15:39] <Riddell> asac: is intrepid being worked on?
[15:39] <ogra> doesnt find the tab to apply the label to it seems ...
[15:39] <asac> Riddell: obviously yes.
[15:39] <asac> Riddell: my main system is just stuck on hardy. ... but ill upgrade any day
[15:45] <milosz> persia, "dlume"
[15:45] <milosz> it's a simple address book app
[15:45] <milosz> i started to u se it but the UI is terrible
[15:45] <milosz> let's say at least it could use improvement
[15:45] <milosz> also i want to make it use a standard format like vCard or something
[15:47] <BenC> cjwatson: Do you have a moment to NEW the latest linux build?
[15:48] <milosz> there's also contacts from openedhand but i don't see it being much better, maybe the code is
[15:49] <persia> milosz: http://changelogs.ubuntu.com/changelogs/pool/universe/d/dlume/dlume_0.2.4-5/copyright has 5 people.  Try contacting those listed under "upstream author" if you want to significantly change the code.
[15:49] <milosz> persia, allright, thanks
[15:49] <cjwatson> BenC: yep, give me a sec
[16:00] <james_w> pitti: http://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html
[16:01] <BenC> cjwatson: thanks
[16:02] <cjwatson> BenC: done
[16:02] <cjwatson> just in time for this publisher cycle too
[16:54] <pitti> james_w: oh, nice!
[17:00] <dholbach> Ubuntu Java team meeting in #ubuntu-meeting now
[17:18] <mathiaz> james_w: I've been experimenting with bzr looms with the openldap package and went through a merge from debian. I was wondering about the commit messages when doing up-thread. Here is what the recent history looks like - http://paste.ubuntu.com/24755/
[17:19] <zul> I take it proposed is open again
[17:19] <pitti> zul: yep :)
[17:19] <zul> pitti: great! thanks..
[17:19] <james_w> hi mathiaz
[17:19] <james_w> mathiaz: what's your "bzr show-loom"?
[17:20] <mathiaz> james_w: http://paste.ubuntu.com/24756/
[17:20] <mathiaz> james_w: I was wondering if there was a better I should use in place of "Merge down-thread."
[17:20] <mathiaz> james_w: which doesn't really carry any meaning full content
[17:21] <james_w> mathiaz: you did those commits after a "down-thread", or an "up-thread"?
[17:21] <mathiaz> james_w: up-thread
[17:22] <mathiaz> james_w: my workflow is - bzr up-thread, bzr st, bzr ci -m "Merge down-thread.", ...
[17:22] <mathiaz> james_w: So you can see that there is the debian thread at the very bottom
[17:22] <james_w> yeah, that looks sensible to me.
[17:23] <james_w> I'm not sure what to put for the commit message.
[17:23] <mathiaz> james_w: I've started there, by doing a bzr merge ../debian, where ../debian is the debian svn branch
[17:23] <james_w> I guess you could use the same message at each thread.
[17:23] <mathiaz> james_w: and then made my way up-thread up to changelog where I can do a bzr bd -S
[17:24] <MacSlow> pitti, ogra: I think I can get away without needing a new libpam for the new gdm.
[17:24] <mathiaz> james_w: right - I think it makes more sense to do that, because when I get to the changelog thread, I need to figure what has been done in order to document it correclty
[17:24] <MacSlow> pitti, ogra: so no need for discussing it on the -devel ml
[17:24] <pitti> MacSlow: nice; that's better for not blocking you
[17:25] <mathiaz> james_w: one issue I ran into was the usage of combine-thread
[17:26] <mathiaz> james_w: once I had merge the new debian revision, there were some thread that were no longer needed
[17:26] <mathiaz> james_w: so I'd arrive to such a thread after an up-thread
[17:27] <ogra> MacSlow, great :)
[17:27] <mathiaz> james_w: bzr st would show a stack of merges waiting for being commited
[17:27] <mathiaz> james_w: then I would do a bzr combine-thread, since this thread is no longer needed
[17:28] <mathiaz> james_w: however, when I moved to the next up-thread, the changes would be carried over there
[17:28] <mathiaz> james_w: so I'm not sure I fully understand what combine-thread is meant for
[17:29] <james_w> the changes from below, or including the changes from the thread you just got rid of/
[17:29] <mathiaz> james_w: changes from the thread I just got rid of
[17:29] <mathiaz> james_w: it may have been an operational error though - or something I didn't grasp in the merge process
[17:30] <mathiaz> james_w: I got bitten a couple of times whith changes that were part of a combined thread would still show up in the thread above it
[17:31] <james_w> did you revert after the combine-thread?
[17:32] <mathiaz> james_w: hm - I'm not sure... I think that's the part I didn't get
[17:32] <mathiaz> james_w: it seems that somewhere I have to do a revert
[17:32] <james_w> I'm not sure, but that might be important.
[17:33] <james_w> I haven't spent enough time working with looms.
[17:33] <mathiaz> james_w: ok - I came to the conclusion to that combine-thread wasn't enough to get rid of a thread - you also had to do a revert somewhere along the line.
[17:35] <mathiaz> james_w: anyway - it was the first time I went through a merge from debian with a bzr loom branch
[17:36] <james_w> happy with it otherwise?
[17:36] <mathiaz> james_w: I still need to wrap my head around the whole process and tweak it - but in the end I made it
[17:36] <mathiaz> james_w: another issue I have is when I need to review if the current thread still applies to the merge
[17:36] <mathiaz> james_w: openldap bzr branch has the full source code in it
[17:37] <mathiaz> james_w: I merge a new upstream revision, so there was a lot of code changes
[17:37] <mathiaz> james_w: I haven't found a way to figure out if the current thread still applies to the pending merges
[17:37] <james_w> what were you using to judge that? bzr diff?
[17:38] <james_w> "bzr diff -rthread:" might be what you are after
[17:38] <mathiaz> james_w: I was using bzr diff -r thread: to figure out what was the patch about
[17:38] <mathiaz> james_w: but then bzr diff would show me a huge diff
[17:38] <james_w> yeah, that will be the diff of everything new underneath.
[17:39] <james_w> is there a way that this could be made better?
[17:39] <mathiaz> james_w: so figuring out if the thread change was still needed for the new merge was kind of difficult
[17:40] <mathiaz> james_w: well - I ended up using filterdiff and lsdiff - bzr diff -r thread: would give a list of files that are changed
[17:40] <mathiaz> james_w: then using filterdiff to extract only the changes related to the files would help a little bit
[17:41] <james_w> ah, so you want the "bzr diff" output, but only for files that are part of the "bzr diff -rthread:" output?
[17:42] <mathiaz> james_w: yes - I want to know if the changes that were part of the current thread are still relevant for the code that is being merged from the down-thread
[17:43] <mathiaz> james_w: IIUC doing an up-thread will use bzr merge algorithm to try to merge the current thread changes in the new down-thread
[17:43] <mathiaz> james_w: in this  case the new down-thread has *a lot* of changes since it's an new upstream revision
[17:44] <mathiaz> james_w: so I wasn't sure which changes were related to the new down-thread and which ones where the result of the current thread applied to the new down-thread
[17:46] <james_w> mathiaz: interesting. I'd advise you to bug lifeless about that ;-)
[17:46] <mathiaz> james_w: As you can see, I'm not sure I've totally understand the process to go through when merging an new upstream revision
[17:47] <james_w> mathiaz: are you in the US for the sprint?
[17:47] <mathiaz> james_w: I may miss something in the whole picture and don't take the correct approach
[17:47] <mathiaz> james_w: yes :/
[17:47] <james_w> ah, shame, it would have been good to go through this with you.
[17:47] <james_w> it seems like you are doing good though.
[17:47] <pitti> asac: seems that bug 244439 is not really fixed in -proposed, it shouldn't be necessary to purge/reinstall the package
[17:48] <mathiaz> james_w: well - I'm happy with the result - I got what I wanted
[18:00] <darkfile> hi
[18:00] <darkfile> I just wanted to ask if you ever plan to upgrade libpurple
[18:00] <darkfile> so we can use ICQ again
[18:00] <pitti> darkfile: already in hardy-proposed
[18:02] <darkfile> ah cool
[18:02] <darkfile> but i'm using the previous version
[18:02] <darkfile> 7.10
[18:02] <darkfile> hope it will be fixed as well?
[18:04] <persia> darkfile: Quite likely, although hardy is the primary QA target, 7.10 will probably be a little later.
[18:05] <Laney> darkfile: It's in gutsy-proposed too ;)
[18:10] <darkfile> cool, now ICQ works again
[18:10] <darkfile> but jabber stopped working ;)
[18:10] <darkfile> SSL certificate error
[18:11] <robertknight> Can someone point me to the script that starts console-kit-daemon?
[18:11] <ogra> /etc/X11/Xsession.d/90-console-kit ?
[18:12] <kees> Riddell: it's not a trivial audit, and I'm still very busy with a bunch of stuff.  I've started poking at it.  jdstrand, have you had a chance to look at it at all?
[18:12] <ogra> ah, no thats not the daemon
[18:12] <jdstrand> kees: not yet, I am getting to a place where I can start. I can take it if you wish
[18:12] <slangasek> laga: well, "later" doesn't help so much for trying to release images with 8.04.1 today :)
[18:13] <laga> slangasek: where today is UTC?
[18:14] <james_w> robertknight: I think it's started by dbus activation
[18:14] <ogra> yeah
[18:14] <laga> slangasek: has someone actually verified the mythbuntu images (apart from that mythbuntu-control-centre SRU)? obviously it'll be pointless to push for that SRU if 8.04.1 is not going to happen for mythbuntu.
[18:14] <laga> i'm out of the loop
[18:14] <laga> mario_limonciell: ^^
[18:15] <ogra> robertknight, /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service
[18:16] <robertknight> james_w: I am looking for a memory leak in console-kit-daemon so I need to restart it under valgrind with the same arguments used to start it on startup/login
[18:17] <james_w> robertknight: it's started the first time something tries to use it. The file ogra pointed you to shows that it gets no arguments.
[18:18] <james_w> if you launch it from a terminal, dbus probably won't try to start it for you.
[18:19] <slangasek> laga: today is US/Pacific, actually
[18:20] <slangasek> laga: I haven't gotten any feedback on the mythbuntu images as a whole either; I can certainly hold back the mythbuntu images until someone can verify them, if that's what needs to happen...
[18:20] <robertknight> james_w: Do you know how I can find out what other processes interact with console-kit via DBus?
[18:20] <laga> slangasek: well, they can't be released unless someone tried them. :) lets wait for mario_limonciell
[18:20] <laga> i'll ping our RM
[18:20] <james_w> robertknight: dbus-monitor?
[18:21] <ogra> robertknight, read up about dbus-monitor
[18:21] <ogra> :)
[18:21] <laga> when he comes online
[18:21] <ogra> robertknight, d-.feet is also a cool tool to inspect dubs stuff (not the traffic though)
[18:21] <ogra> *d-feet
[18:24] <Le_Vert> I'm looking for a cowbuilder gui. I read one planet ubuntu that someone created one but I can't remember it's name
[18:24] <Le_Vert> could you help me ? ;)
[18:31] <slangasek> soren: around?
[18:32] <soren> slangasek: ish
[18:32] <soren> presence -> 0 for time -> in a bit
[18:32] <slangasek> soren: we have a JeOS test case for ISO testing that didn't get covered
[18:32] <slangasek> soren: none of the testers have access to VMWare ESX
[18:33] <soren> Ah.
[18:33] <slangasek> do we need a separate test for that, if we have VMware server covered?
[18:33] <soren> Yes.
[18:33] <soren> they're wildly different beasts.
[18:33] <soren> nijaba: I don't suppose you have time/opportunity to do a ESX JeOS test?
[18:34] <ScottK> Didn't someone say earlier that nijaba was off in the south of France at a conference?
[18:34] <soren> That was me.
[18:34] <soren> ...who said it.
[18:35] <soren> He's aroundish now, it seems.
[18:35] <soren> Ah, except he's away.
[18:35] <soren> well, I suppose he'll notice eventually.
[18:35] <soren> Otherwise...
[18:35] <soren> tjaalton: I don't suppose you have time/opportunity to do a ESX JeOS test?
[18:38] <soren> slangasek: Sorry, but I have to run now. The only two people I know who can do ESX testing are tjaalton and nijaba.
[18:40] <Riddell> asac: if you approve my membership of ~network-manager I'll look to upload packages
[18:41] <slangasek> tjaalton: hmm, do you have time to test JeOS on ESX?
[18:42] <\sh> soren: what needs to be done?
[18:43]  * \sh can still grab a coffee and work with his ESX 3.5 here...
[18:48]  * \sh 's gone now
[18:49] <jdstrand> kees: eek, I'm not as close to being able to review that as I'd hoped
[18:49] <jdstrand> (libzip)
[18:53] <jdstrand> cjwatson: hi! I seem to remember you saying that you could no longer boot your kvm intrepid guests. is this with a hardy host?
[19:18] <luisbg> slangasek: ping
[19:18] <slangasek> luisbg: hi
[19:18] <luisbg> hi
[19:18] <luisbg> did the ubuntu studio cd got built for hardy.1?
[19:20] <slangasek> luisbg: there are ubuntustudio images being vetted for .1, yes
[19:26] <luisbg> slangasek: awesome, thanks! :)
[19:38] <tm512> What's the chance that a suggestion for the devlopment of Ubuntu would be listened to?
[19:41] <stdin> !brainstorm
[19:41] <stdin> tm512: post it there ^
[19:50] <macd> Any file browse selection dialog takes forever to come up regardless of application triggering it, ideas?
[19:50] <slangasek> luisbg, TheMuso: we still have an UbuntuStudio SRU that no one's been able to verify yet, and I can't figure out how to even get a test case out of this... genpo, bug #221518
[19:51] <slangasek> luisbg, TheMuso: do you want to try to verify this fix, or should I re-roll the image dropping this package from -proposed?
[19:52] <persia> slangasek: I'll test it now: I've genpo installed on hardy.
[19:52] <slangasek> persia: well, I can't figure out where to even find the Debian menu in hardy after installing the 'menu' package :/
[19:53] <persia> slangasek: Did you install menu-xdg?
[19:53] <slangasek> no, the test case didn't say to do that
[19:53] <persia> Yeah, the test case is bad, but menu alone doesn't generate a menu for GNOME: one needs menu-xdg
[19:53] <slangasek> persia: but if you can verify this, that'd be awesome
[19:54] <persia> slangasek: I can't verify the behavioural issue, as my menu works, but I can verify that the .menu file is malformed.  checking for regression and validation of fix only.
[19:55] <slangasek> your Debian menu works, and shows other items that are after genpo in the list?
[19:55] <persia> It did before and after the update.  Applying the SRU gave genpo an icon, and genpo still runs (although I only tried one note)
[19:56] <persia> Is this sufficient validation of the bug for a comment and validation, or is maybe the bug questionable?
[19:57] <luisbg> thanks persia
[19:58] <ogra> slangasek, you need to enable it in alacarte
[19:58] <ogra> its disabled by default .... then it will show up in your gnome menu
[19:58] <slangasek> persia: is it possible that the problem is specifically if you try to install another package, its menu entry won't show up?
[19:58] <slangasek> ogra: no, I did that
[19:58] <ogra> hmm
[19:58] <ogra> weird
[19:58] <slangasek> ogra: it's almost certainly the menu-xdg package
[19:59] <persia> slangasek: Except that I've had genpo installed for months, and installed bunches of other stuff that show in my Debian menu.
[19:59] <slangasek> persia: sigh
[20:00] <slangasek> persia: ok, please comment your findings to the bug, and I'll copy it over since it doesn't regress, trusting that the submitter wasn't just blowing smoke
[20:01] <persia> slangasek: weaselly comment committed.
[20:02] <slangasek> right :)
[20:07] <infinity> Meh.
[20:07] <infinity> Do we want mingw32 in main, or do we want to mangle gzip to not build gzip-win32 on Ubuntu?
[20:20] <kees> doko: what behavior exactly did you want for the "nohardening" stuff?
[20:32] <slangasek> laga: how about the fix for bug #220087?  Anyone tested this one?
[20:37] <soren> jdstrand: Intrepid guests on hardy hosts will probably not work. I know what's wrong, and I'll fix it real soon.
[20:38] <jdstrand> soren: well, if it helps any, they used to work until I updated the guest
[20:39] <jdstrand> soren: right now, I have an updated amd64 guest, and it's broken. I have an i386 guest I haven't updated, and it still works fine
[20:40] <soren> jdstrand: That's.. odd. Could I please see the kernel config for the i386 guest?
[20:40] <jdstrand> soren: hold on...
[20:40]  * soren holds on
[20:43] <jdstrand> soren: linux-image-2.6.24-16-386
[20:43] <jdstrand> soren: (and I'm getting the config now)
[20:43] <soren> jdstrand: Oh.
[20:43] <soren> jdstrand: Yeah, that would work.
[20:43] <jdstrand> soren: so you don't need the config?
[20:43] <soren> jdstrand: The problem is in >2.6.24
[20:43] <soren> Nope.
[20:43] <soren> thanks anyway.
[20:44] <jdstrand> sure
[20:44] <soren> I expected it to be a working 2.6.26, which would have surprised me greatly.
[21:34] <laga> slangasek: i guess not if nobody answered on the bug report.
[21:35] <laga> slangasek: i'm not being very helpful, i know, just somewhat busy right now.
[21:35] <laga> i'll take a look at the forum thread in a minute
[21:47] <slangasek> laga, mario_limonciell: ok; since these two SRUs account for a significant portion of mythbuntu proper and haven't completed SRU verification yet, and I need to move forward with .1 today, I think the best option is to hold back the mythbuntu images for the moment and push them out a little later
[21:48] <laga> slangasek: thank you.
[21:49] <laga> i'll go bug some people to test the SRU bugs
[21:50] <laga> no replies in the forum thread either. so yeah, we need to wait.
[21:51] <mkrufky> mario_limonciell: ping?
[21:51] <mkrufky> ...or anybody else --  anybody know anything about packaging xine?
[21:52] <mkrufky> i just did debuild, got 12 debs
[21:52] <mkrufky> dunno which one does what :-/
[21:53] <mkrufky> im sorry -- i mean libxine
[21:53] <laga> what debs did you get?
[21:53] <mkrufky> these: http://rafb.net/p/rLwI7n28.html
[21:54] <mkrufky> basically...  i did a patch to make the xine engine more forgiveable to loss of signal lock, or stream errors
[21:54] <mkrufky> ...so that it can recover a broken DVB stream rather than dropping it all on the floor
[21:54] <mkrufky> ...but this is just a test, ive no idea if it will work.  i dont know which package of the above needs to be installed
[21:55] <laga> well, use dpkg -l libxine* do find out what you have installed currently.
[21:55] <laga> and then install those
[21:55] <mkrufky> ah, that's great -- thanks
[21:55] <laga> installed packages will have 'ii' at the beginning of the line
[21:56] <mkrufky> ok, it *seems* like this is the one:
[21:56] <mkrufky> libxine1_1.1.11.1-1ubuntu3_i386.deb
[21:56] <mkrufky> i'll try it
[21:57] <ScottK> Wow.  An actual lawyer commenting on a legal related discussion.  I don't think I've ever seen that happen before.
[21:59] <calc> "BTW is there any chance that you can call the next release or so of
[21:59] <calc> UBUNTU "The Dog's Bollocks?" - I assume you are in the States but just
[21:59] <calc> in case you think I'm being abusive - the Dog's is Northern English
[21:59] <calc> slang for the best thing since sliced bread - why, I don't know... as
[21:59] <calc> Edmund Hillary should perhaps have said "Because they're there"?"
[21:59] <calc> lol
[22:15] <bdmurray> calc: hehe
[23:06] <cjwatson> jdstrand: yes, intrepid guest on hardy host
[23:07] <cjwatson> infinity: I remember taking mingw32 out from syslinux, so I assume it should be ripped out of gzip too
[23:16] <tjaalton> slangasek: is it too late to test?
[23:17] <slangasek> tjaalton: it sounds like we got the case covered, thanks though
[23:17] <tjaalton> slangasek: cool
[23:21] <anthony> slangasek: Meaning that testing's done or that enough people are working on it already?
[23:21] <slangasek> anthony: testing is done
[23:29] <anthony> slangasek: Oh, sweet!  No e-mail yet though - must be waiting for mirror syncing as usual I take it?
[23:29] <slangasek> anthony: correct
[23:37] <TheMuso> I hope to verify that SRU this morning, unless there is a deadline here.