[12:13] <Evaso2> a sort of commit rollout + dependecies etc. 
[12:14] <Evaso2> when the trasaction is stable in testing and compilant with the policies it will bel applied to the stable "trunk"
[12:14] <Evaso2> s/bel/be
[12:14] <LaserJock> seems like it requires a lot of "policing"
[12:15] <LaserJock> and I'm not seeing a clear advantage to a time-based release
[12:15] <Evaso2> not a lot of policiing somthing like in the wiki stub are already good
[12:15] <Evaso2> the trasaction is only a concept for loking packages with dependencies
[12:17] <Evaso2> you could not upload a new upstream release if the upload broke the trasaction already in testing (for example abi changes)
[12:17] <LaserJock> it would just seem to me that a constantly moving target would not be as stable, as supportable, nor able to make changes as well
[12:17] <LaserJock> at least to a "release" level
[12:17] <LaserJock> for development or "unstable" purposes it seem to make some sense
[12:18] <LaserJock> basically like what unstable is for the most part
[12:18] <Evaso2> probably but this work around many problem about backporting upstream bugs
[12:18] <Evaso2> we need an extra work for backporting upstream bug fixing in stable release
[12:19] <Evaso2> without a proper "stable" release we could try to itroduce slowly new upstream version in the trasaction
[12:19] <HrdwrBoB> I don't think people want that
[12:20] <Evaso2> HrdwrBob: probably :) we could talking also about this
[12:20] <HrdwrBoB> "I am running Ubuntu X.XX
[12:20] <HrdwrBoB> is a lot easier than
[12:20] <HrdwrBoB> "oh I last updated foo and bar, here is my complete system version list"
[12:21] <Evaso2> mhh... the alterative is I'am running Ubuntu without any X.XX
[12:21] <LaserJock> Evaso2: your idea is similar to Gentoo it would seem
[12:21] <LaserJock> Evaso2: but you have no idea what package versions you are running with that
[12:21] <LaserJock> what if a person doesn't have internet access
[12:21] <LaserJock> or limited access
[12:21] <TheMuso> 
[12:21] <TheMuso> 
[12:22] <LaserJock> they may still have whatever version was on the "snapshot"
[12:22] <ajmitch> TheMuso: I agree
[12:22] <TheMuso> ajmitch: lol
[12:22] <Evaso2> LaserJock the problem of internet access is relative also at security fix
[12:22] <TheMuso> speakup decided to screw with sticking keys again after switching to this box using a kvm
[12:22] <LaserJock> Evaso2: yes it is
[12:23] <Evaso2> LaserJock : or also at stable upgrade that fix bugs
[12:23] <LaserJock> sure
[12:23] <LaserJock> but if you have no internet wouldn't you rather have a tested, stabilized distro then the latest "daily"
[12:24] <Evaso2> we could simply have a checksum to know if we run the actual sistem
[12:24] <Evaso2> probably updates could will come 1 time at week 
[12:24] <Evaso2> so trasaction will be committed to stable one time at week
[12:24] <Evaso2> when ready
[12:25] <LaserJock> well, I doubt that Debian or Ubuntu would be good fits for this system
[12:25] <LaserJock> but perhaps some derivatives might want to try it
[12:25] <LaserJock> it might have some advantages
[12:25] <LaserJock> for us I think the time based release also provide timelines for development
[12:25] <Evaso2> it is an alternative concept about not to compleetly break the upstream flow
[12:26] <LaserJock> it has both technical and social consequences
[12:27] <Evaso2> but the time based release will be relative to meet the periodical trasaction clock for prepare the trasaction from the devel system
[12:27] <Evaso2> the time based release could be fragmentated and not so monolitich
[12:29] <Evaso2> for example on the next transaction clock in the meeting we coiche to complete and polish the python x.x trasaction
[12:30] <Evaso2> naturally this transaction must be well tested in the dev system  (no rc or important bug) before could be committed
[12:31] <Evaso2> this could let also to us to shorting the time we could integrate upstream bugfixing instead to try to backporting it
[12:37] <Evaso2> LaserJock: There is still a some kind of weekly or monthly or clock time oriented goals
[12:38] <popey> if I want to report a bug in the gnome doofer that comes up when i press the volume control soft keys on my laptop, what would that be?
[12:38] <popey> hmm, hotkey-setup?
[12:43] <jdub> wow, just doing an upgrade and suddenly everything is totally gouging the cpu
[12:43] <jdub> like, gconftool-2 suching 80% over at least a minute
[12:44] <jdub> hrm, no, longer
[12:46] <cjwatson> Evaso2: you're free to start an Ubuntu derivative which works that way and try it out, but I'm pretty confident that Ubuntu isn't going to make that sort of change. Sorry.
[12:48] <Evaso2> cjwatson: it is only for talking about an issue i doesn't want to create a fork for a derivate only for test an idea
[12:48] <cjwatson> I'm sorry, but we're not going to do it within Ubuntu
[12:48] <jdub> Evaso2: i tend to think that method will eventually take over, but it would require an enormous amount of work right now
[12:49] <Evaso2> jdub: what do u mean for "take over"?
[12:50] <jdub> Evaso2: it will become the 'normal' way free software is delivered
[12:50] <Evaso2> jdub: really or are u joking? :)
[12:50] <cjwatson> it would not be compatible with Canonical's commercial processes without serious (and expensive) reengineering of those processes
[12:50] <cjwatson> it's much easier to do this sort of thing when you're starting a project
[12:51] <cjwatson> once the project is up and running, change at that sort of fundamental level is difficult and expensive
[12:51] <cjwatson> and once people's jobs are depending on success, there's more resistance to untried ideas
[12:51] <Evaso2> cjwatson: sure i'm also sure that it has too many reengineering 
[12:51] <Evaso2> cjwatson: i agree with u on this two issues
[12:52] <jdub> Evaso2: no, i'm not joking; but that's just my take on what the future may bring
[12:53] <cjwatson> I'm not really convinced that it can supply coherent enough support commitments and user messaging
[12:53] <Evaso2> jdub: yes my was only a teoric discussion i doesn't think really that ubuntu or debian could really partical try somthing like this
[12:53] <cjwatson> but this is the wrong forum to go into it in detail
[12:54] <Evaso2> there are already support problem in ubuntu because it cannot control time freeze release for all the foss apps
[12:55] <Evaso2> this is issue was already in a Mark post on his blog
[12:56] <Evaso2> mainly the ubuntu choiche is to sync with gnome time release clock
[12:56] <cjwatson> "the current system is imperfect" does not imply "any other possible choice is better"
[12:56] <cjwatson> I was not arguing that the current system was perfect
[12:57] <cjwatson> but, within the context of Ubuntu, efforts are better spent on minor tweaks than on total scorched-earth release process redesign, at this point
[12:57] <Evaso2> i think that no one system is perfect and mainly is not perfect forever for an evolving word :)
[12:57] <cjwatson> by necessity, the latter will essentially produce no useful results except for possibly the founding of a new project to experiment with it
[12:57] <cjwatson> warty was when we were free to experiment :)
[12:58] <jdub> within the context of "we release in six months... starting from before X people were even here" ;-)
[12:58] <Evaso2> i think that probably could be experimented only with a little number of packages to try to test the system
[12:58] <cjwatson> I'm aware that the current process has its trade-offs; I was there (and argued about them) when it was set up
[12:58] <cjwatson> (as was jdub)
[12:59] <cjwatson> but you need to recognise that every process has its trade-offs, and you would simply be exchanging one set of disadvantages for another
[12:59] <Evaso2> i think that actually the problem is every distro is overloaded on distro vs upstream issue
[01:00] <cjwatson> pages about release processes need to explicitly acknowledge the disadvantages as well as the advantages, otherwise they're just advocacy
[01:00] <Evaso2> yes for my stub i see problem with debian (but less with ubuntu)
[01:01] <Evaso2> for debian a see a problem to try to put in a good state a trasaction that keep too many time
[01:01] <Evaso2> so begin to missing many upstream releases
[01:02] <Evaso2> and this problem could be the same with the universe side of ubuntu
[01:02] <jdub> brr, this cpu hogging business is bizaare
[01:03] <Evaso2> upstream has its work time but if you are to slow to but dependecies trasaction in a good shape you begin to miss upstream release while you fix package with dependecies (what i call a trasaction ecosystem)
[01:04] <Evaso2> s/too slow to put
[01:06] <cyberix> https://bugs.launchpad.net/gnome-panel/+bug/81205
[01:06] <Ubugtu> Malone bug 81205 in gnome-panel "Clock applet doesn't allow me to choose Monday as the starting day of the week" [Unknown,Unknown]  
[01:07] <popey> hmm, do only *some* bugs appear here?
[01:07] <popey> oh, sorry, that's ubunu-bugs isn't i
[01:07] <mdke> popey: only ones which people call. Such as bug 12345
[01:07] <Ubugtu> Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]  https://launchpad.net/bugs/12345
[01:07] <popey>  /ignore popey
[01:07] <Evaso2> but probably in the future the  new linuxfoundation (osdl + fsg) with the lsb a linux kernell could try to begin to define a universal linux syncro clock to sync all the major linux distro (and problably many little opensource project begin to sync releases to this clock)
[01:09] <Evaso2> so we will have a sort of universal timeline to sync (the opposit of tha actual FOSS asyncro system)
[04:15] <Hobbsee> any core dev people around?  i'm looking for a sponsor
[09:11] <dholbach> good morning
[09:13] <cjwatson> pitti: you're in ubuntu-archive in LP now too, so you should be a full archive admin; let me know if there's anything you can't do
[09:13] <Mithrandir> pitti: you want to subscribe to ubuntu-archive@lists.ubuntu.com, probably.
[09:14] <pitti> cjwatson: just checked, account seems to be ok; thanks
[09:14] <pitti> Mithrandir: alright
[09:17] <pitti> ah, thanks for adding me to the team, just appeared
[09:21] <Keybuk> pitti: what's wrong with this picture? -- http://people.ubuntu.com/~scott/feisty-20070123-7.png
[09:22] <Mithrandir> Keybuk: your machine seems to be bored for a while while booting.
[09:22] <Treenaks> Mithrandir: bored with S08loopback even
[09:22] <Mithrandir> yeah, seems like it can't resolve its own hostname
[09:23] <Mithrandir> "host" is running for exactly ten seconds.
[09:25] <Keybuk> Mithrandir: yes
[09:25] <Keybuk> it's not unusual to have no DNS server when you're only bringing up lo :p
[09:26] <Keybuk> it's not trying to resolve its hostname, but looking for a local SOA
[09:26] <Treenaks> Keybuk: ifrename... ;)
[09:27] <Keybuk> Treenaks: ?
[09:28] <Treenaks> Keybuk: isn't it possible to rename the 'lo' device to something else?
[09:28] <Treenaks> Or will that break other things horribly too?
[09:28] <Keybuk> I don't think it's possible
[09:28] <Treenaks> ok, nevermind then
[09:28] <pitti> Keybuk: yup, there's a bug about it
[09:29] <pitti> Keybuk: bug 80268
[09:29] <Ubugtu> Malone bug 80268 in avahi "Avahi daemon should not try to resolve hostnames during bootup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80268
[09:30] <Mithrandir> seb128: if you could come over here afterwards and I'll fix up the rest of the bits of the greasemonkey script for you.
[09:31] <seb128> Mithrandir: now or after the debhelper demo?
[09:32] <Mithrandir> seb128: whenever you want. :-)
[09:32] <seb128> ok, after the demo then ;)
[09:33] <Hobbsee> hey Mithrandir, seb128, and Keybuk 
[09:33] <seb128> hi Hobbsee
[09:33] <Mithrandir> morning, Hobbsee
[09:34] <Hobbsee> ;)
[09:37] <Mithrandir> Riddell: do you want to add knetwork-manager to your -desktop seed yourself or should I do it?
[09:37] <pitti> lifeless: look at bug 81237, that's a funny one
[09:37] <Ubugtu> Malone bug 81237 in apport "Errors from python interpreter give apport crash dialog!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81237
[09:38] <pitti> lifeless: (just to amuse you, I'll fix it)
[09:41] <lifeless> pitti: ah yeah, jamesh and I had a fix for it
[09:42] <lifeless> pitti: its not trivial to fix. I'll dig up the log about the right way later
[09:42] <pitti> lifeless: oh, I thought about something like 'InterpreterPath == ExecutablePath -> ignore'
[09:42] <lifeless> pitti: 'python foo.py' -> foo.py may be packaged
[09:43] <pitti> lifeless: check the arguments then, too? hmm
[09:43] <lifeless> there are a couple of variables we can cross check though
[09:43] <lifeless> its in my irc logs from las year somewhere ;)'
[09:46] <pitti> lifeless: if I run python in /usr/lib, I get ExecutablePath == /usr/lib
[09:50] <Keybuk> you don't exclude /usr/local from that?
[09:50] <Keybuk> I've had that dialog at least once for a python script in /usr/local/bin
[09:50] <pitti> Keybuk: I do
[09:50] <pitti> Keybuk: ah, probably not for interpreted scripts
[09:51] <lifeless> Keybuk: this is about interactive python, but if you get a dialog when you shouldn't, file a bug with some details ;)
[09:52] <Keybuk> lifeless: bug #81244
[09:52] <Ubugtu> Malone bug 81244 in apport "Is run for programs in /usr/local" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81244
[09:52] <pitti> Keybuk: thanks
[09:53] <cjwatson> dholbach: does <or> work yet?
[09:54] <dholbach> cjwatson: yes
[09:54] <cjwatson> hmm
[09:54] <dholbach> cjwatson: 'not' too
[09:54] <cjwatson> can't get 79029 to match "no active autopartitioning choice"
[09:54] <dholbach> do you have the clue file for that somewhere so I can try myself?
[09:54] <dholbach> cjwatson: ^
[09:55] <cjwatson> (that would be a false positive as it happens, but still)
[09:55] <\sh> moins
[09:55] <cjwatson> dholbach: http://people.ubuntu.com/~cjwatson/tmp/ubiquity.info
[09:56] <cjwatson> I'd suggest hacking bughelper to limit to just bug 79029 or it'll take forever
[09:56] <Ubugtu> Malone bug 79029 in ubiquity "Feisty Herd2 - Installer crashed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79029
[09:56] <\sh> sabdfl, thank you for your mail :) 
[09:56] <dholbach> cjwatson: i'll give it a special bug list url but thanks for the hint
[09:57] <Riddell> Mithrandir: it's already in
[09:57] <Mithrandir> Riddell: coolie
[09:59] <dholbach> cjwatson: working on it
[10:04] <dholbach> cjwatson: can you try  http://daniel.holba.ch/temp/possiblefix.patch ?
[10:06] <cjwatson> trying
[10:08] <dholbach> cjwatson: does   ./bughelper -A -l http://tinyurl.com/2ykot4   work for you?
[10:57] <\sh> doko: if you have time, can you look at http://librarian.launchpad.net/5720669/buildlog_ubuntu-feisty-i386.ldaptor_0.0.43-0.4ubuntu2_FAILEDTOBUILD.txt.gz and tell me how can we fix it (e.g. setting it back to python2.4)
[11:00] <StevenK> I note the command that fails is dia -t png-libart --export=ldap-is-a-tree.dia.png.tmp ldap-is-a-tree.dia
[11:01] <\sh> oh my god...right..i didn't see the glibc warning...
[11:04] <StevenK> There's no bug against it, either.
[11:05] <fabbione> *** glibc detected *** dia: free(): invalid pointer: 0x09392ea0 ***
[11:05] <fabbione> fix dia :)
[11:05] <Treenaks> StevenK: there is a bug against dia for that..
[11:06] <StevenK> Treenaks: Oh? I must of missed it.
[11:06] <Treenaks> StevenK: https://bugs.launchpad.net/ubuntu/+source/dia/+bug/79188
[11:06] <Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]  
[11:06] <StevenK> Ah, I was looking for bugs mentioning glibc
[11:06] <Treenaks> StevenK: well, it does mention it.. in the description text
[11:07] <StevenK> So, which lucky person gets to valgrind dia? :-)
[11:07] <seb128> fabbione: what about you fixing bugs instead of just pointing them? ;)
[11:07] <Treenaks> StevenK: seb128 ;)
[11:08] <StevenK> Actually, doko touched it last. :-)
[11:08] <seb128> StevenK: the upstream SVN has the required changes, that's a "work with new python" change
[11:08] <seb128> it's trivial to backport probably
[11:08] <StevenK> seb128: Point me at the patch, and I'm happy to throw you a debdiff?
[11:08] <seb128> the problem is that it has been commited to CVS and touch like 15 files, and there is not an unique changeset
[11:09] <seb128> you need to look at every file change and collect the diffs, which I've been to busy or lazy to do
[11:09] <seb128> wait
[11:09] <seb128> http://svn.gnome.org/viewcvs/dia/trunk/plug-ins/python/
[11:09] <seb128> "	* plug-ins/python/*.c : don't mix PyObject_NEW() with PyMem_DEL()"
[11:10] <seb128> grab that diff for every file
[11:10] <seb128> that will probably work
[11:15] <fabbione> seb128: because it's part of my new job to just point them out :)
[11:15] <seb128> that's not support request
[11:15] <seb128> what other new job did you get?
[11:16] <fabbione> seb128: handing over all my stuff to you ;)
[11:16] <seb128> I don't think so
[11:17] <fabbione> seb128: it's fun tho :)
[11:18] <seb128> I don't doubt of it :p
[11:22] <StevenK> Come on librarian, send me data slower.
[11:22] <saispo> hi
[11:23] <doko> \sh, StevenK: reverting to 2.4 is not an option; better fix the 2.5 bugs
[11:24] <StevenK> doko: Doing so now
[11:24] <doko> StevenK: thanks
[11:24] <StevenK> doko: I shall bug either you or seb128 when I have a debdiff for dia
[11:24] <seb128> StevenK: attach it to the bug, I'll do the upload
[11:24] <StevenK> seb128: Aye. I'll poke you here when I've done so
[11:24] <seb128> cool
[11:27] <tkamppeter> I have a question about getting new packages from universe to main. I have made the appropriate reports and added the packages to the queue, but when I announce it on ubuntu-devel, I get messages that my postings await moderator approval because I am not a developer. Where should I announce my main inclusion requests?
[11:27] <kylem> ubuntu-devel-discuss is the open list and probably the best place.
[11:29] <tkamppeter> Then I think the instructions on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements should be appropriately changed.
[11:29] <\sh> doko, thx :)
[11:29] <seb128> mdke: around?
[11:29] <mdke> seb128: (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)
[11:30] <seb128> mdke: have your changes for the help menu been approved and need to be applied?
[11:30] <tkamppeter> Like: 3. #
[11:30] <tkamppeter> The request and the link to the report are sent to ubuntu-devel@lists.ubuntu.com or ubuntu-devel-discuss@lists.ubuntu.com.
[11:38] <cjwatson> tkamppeter: I think ubuntu-devel is appropriate.
[11:38] <cjwatson> although there is an open question of whether it makes sense to post MIRs to a mailing list at all
[11:40] <lifeless> sfllaw: I have the edit back.ping me when you want this meeting
[11:41] <tkamppeter> cjwatson, then we should really change the instructions on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements. Which address do you like should I send the announcements of main inlusion requests to?
[11:41] <cjwatson> tkamppeter: I have updated the process following a brief discussion here
[11:42] <cjwatson> tkamppeter: you do not need to announce it anywhere; Martin Pitt (the primary reviewer) gets notified via a wiki subscription
[11:43] <cjwatson> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements fixed
[11:44] <tkamppeter> cjwatson, thanks.
[11:56] <pitti> lifeless: seems that sys.argv == ['']  for interactive python sessions even if I run 'python -O -E'
[11:57] <pitti> lifeless: that's why your binary = os.path.join(cwd,argv[0] ) produces '/usr/local'
[12:14] <StevenK> seb128: Bug 79188 updated with my debdiff. I have tested that I can reproduce the problem, and also that my fix does indeed fix the problem.
[12:14] <Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]  https://launchpad.net/bugs/79188
[12:14] <seb128> StevenK: good, I'll have a look now, thank you
[12:15] <StevenK> seb128: Great, thanks. And no problem. :-)
[12:19] <ogra> seb128, StevenK, i'm just trying to get the dia from experimental building ... i'd assume that patch is included
[12:19] <seb128> right
[12:20] <seb128> ogra: let me know if it works fine, otherwise I'll upload the patched package
[12:20] <ogra> yep
[12:20] <Hobbsee> Mithrandir: or another archive admin, ping?
[12:20] <ogra> only finishing the tuxtype build ...
[12:27] <Mithrandir> Hobbsee: humm?
[12:27] <Hobbsee> Mithrandir: i think there were two uploads of murrine today?   can you make sure the last one gets uploaded please?  :)
[12:29] <Mithrandir>   159376 | S- | murrine              | 0.41-0ubuntu1        | 7 hours 30 minutes
[12:29] <Mithrandir>   | * murrine/0.41-0ubuntu1 Component: main Section: gnome
[12:29] <Mithrandir>   159377 | S- | murrine              | 0.41-0ubuntu1        | 7 hours 20 minutes
[12:29] <Mithrandir>   | * murrine/0.41-0ubuntu1 Component: main Section: gnome
[12:29] <Mithrandir> so yes, two uploads. :-P
[12:30] <Mithrandir> I'm merging casper now, I can do it afterwards.
[12:32] <Hobbsee> Mithrandir: :(  realised after i'd uploaded the first one, went "bugger"
[12:32] <Hobbsee> cool, thanks :)
[12:40] <frennkie> Hello, does anybody know how likely it is that there will be a backport of libc6-xen for Dapper Drake LTS (6.06) (see: https://launchpad.net/ubuntu/+source/glibc/+bug/50331/+viewstatus)
[12:40] <Ubugtu> Malone bug 50331 in glibc "Please backport libc6-xen" [Wishlist,Unconfirmed]  
[12:42] <frennkie> okay, so what does unconfirmed mean ?
[12:48] <mneptok> what is the nature of the breakage on Dapper? does it affect security?
[12:51] <Mithrandir> frennkie: not going to happen.
[12:51] <frennkie> *cry* why not, do you know?
[12:51] <Hobbsee> Mithrandir: well, the backporters might decide to smoke their crack pipe, again...
[12:52] <Mithrandir> Hobbsee: well, I just rejected it and I would be really, really surprised if any other archive admin though it was a good idea.
[12:52] <Mithrandir> frennkie: because we don't backport core libraries like, glibc.
[12:53] <Hobbsee> Mithrandir: heh, yes, i know.  i thougth the ubuntu backporters were separate to you guys - jdong's team
[12:53] <Mithrandir> Hobbsee: they're still subject to ubuntu-archive approval.
[12:53] <Hobbsee> ah :)
[12:54] <frennkie> ok, thats a point.. but as dapper, will be around and used for another 4 Years maybe it would be good to have proper xen supoort in it..
[12:54] <Hobbsee> frennkie: i believe you just got told by one of the 3 archive admins "no" - that's very very unlikely to change...
[12:54] <Mithrandir> frennkie: sure, that would be nice.  Unfortunately, as long as that means backporting glibc, it's not going to happen.
[12:56] <frennkie> okay, got it now. thx!
[01:02] <StevenK> ogra: Any news, re: dia?
[01:03] <ogra> StevenK, seems 0.96-pre1 is gone ... seb128 will apply your patch
[01:03] <ogra> (i got it from alioth some weeks ago ... it ftbfs'ed ... seems they didnt get it fixed)
[01:03] <StevenK> ogra: Great, thanks
[01:04] <seb128> ogra: you can also grab the new tarball and do the update if you want ;)
[01:04] <ogra> after lunch then :)
[01:56] <h4writer> (gnome) can I ask here how come that a list of anything sometimes shows white places? Like the user list in Gaim. Or the list of menus in "menu layout". If I'm not wrong those are created with python: treeview (treestore)
[01:57] <cjwatson> does anyone here have moderator privileges on the "Installation and Upgrades" forum on ubuntuforums.org? I need a comment marked sticky
[01:57] <h4writer> But it is annoying and I need to be fixed
[01:57] <h4writer> *it
[01:58] <Treenaks> h4writer: this is not a support channel
[01:58] <Treenaks> h4writer: also, use launchpad.net to file bugs
[01:58] <h4writer> ok
[01:58] <h4writer> thanks
[02:38] <ogra> StevenK, seb128, do we have a bug for the dia segfault ? i just uploaded
[02:38] <seb128> ogra: uploaded what?
[02:38] <ogra> dia
[02:38] <seb128> what version?
[02:39] <ogra> 0.95.0-4.1ubuntu3
[02:39] <seb128> grumpf
[02:39] <ogra> the patched one with StevenK's patch ...
[02:39] <seb128> I had that ready
[02:39] <ogra> i told you i'D do it after lunch when you asked
[02:40] <seb128> ogra: https://launchpad.net/ubuntu/+source/dia/+bug/79188
[02:40] <Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]  
[02:40] <ogra> thx
[02:40] <seb128> np
[02:41] <Stargazers> Hi. I have a question about Python and Feisty. Is there problems with Feisty locales or something, cause jBrout should add IPTC as UTF-8, but it won't do it on Feisty?
[02:42] <Stargazers> And always I get errormessage in Feisty, I paste a url of errormessage, moment.
[02:42] <Stargazers> http://stargazers.kapsi.fi/screenshots/errormessage.jpg <-- This kind. This won't appear on Dapper or Edgy.
[02:44] <Stargazers> I mean, if I write IPTC-tags with DigiKam 0.9.0 and then look in jBrout, scandinavian chars won't work. And same if I add tags with jBrout and then look them DigiKam, scandinavian chars won't work. But it seems that problem is on jBrout that writes tags without UTF-8, but programmer said that it does. So, is there problem in Python packages in Feisty now?
[03:06] <alex-weej> grr
[03:06] <alex-weej> every time i try to install build dependencies
[03:06] <alex-weej> i just get a message like
[03:06] <alex-weej> E: Build-dependencies for gossip could not be satisfied.
[03:06] <alex-weej> i have no idea what's going on, anyone got an idea?
[03:06] <Hobbsee> alex-weej: not enough info
[03:06] <Hobbsee> alex-weej: means that one of the build deps is broken
[03:06] <seb128> alex-weej: that's not an user support chan
[03:06] <Hobbsee> ie, not installable
[03:07] <Hobbsee> and it's the wrong channel
[03:07] <alex-weej> seb128: i'm trying to "develop"
[03:07] <seb128> alex-weej: still not the right chan, that's not a chan to ask how to build a package
[03:07] <alex-weej> whatever
[03:07] <Hobbsee> heh
[03:15] <cjwatson> mvo: you can close bug 81225
[03:15] <Ubugtu> Malone bug 81225 in realplayer "realplay requires libc6 2.5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81225
[03:23] <erdinc> crimsun got a sec?
[03:29] <alsaberk> hi erdinc
[03:41] <ogra> seb128, http://people.ubuntu.com/~ogra/dia/
[03:48] <erdinc> cliebow use this: http://cekirdek.pardus.org.tr/~ismail/dist/bcm43xx-firmware-3.130.20.0.tar.bz2
[03:54] <bddebian> Heya
[03:56] <jdong> are you guys aware that libc6-dev from archive.ubuntu.com main is unfetchable...
[03:57] <jdong> http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dev_2.4-1ubuntu12.2_i386.deb
[03:57] <jdong> that URL
[03:57] <jdong> generates 403/forbidden
[03:57] <elmo> yes, it's deliberate
[03:58] <jdong> ah
[03:58] <jdong> recalling an update?
[03:58] <lifeless> elmo: is it listed in Packages at all ?
[03:58] <elmo> lifeless: yes
[03:58] <lifeless> meep. analyzer fall down go boom
[03:59] <elmo> jdong: yes
[04:00] <jdong> is this related to the libc6 update not liking libpthread.so.20 thing?
[04:00] <Mithrandir> yes
[04:01] <jdong> ah, ok
[04:01] <jdong> lovely :)
[04:01] <lifeless> and the toe bone is conneted to the foot bone
[04:01] <bddebian> hehe
[04:02] <lifeless> jdong: dont you mean .20 questions ?
[04:02] <jdong> LOL
[04:02] <jdong> BOO
[04:05] <Keybuk> or why anyone would have a /usr/lib/libc.so.6 symlink
[04:06] <Mithrandir> Keybuk: it gets pulled in by gnupg-agent, for instance.
[04:06] <Mithrandir> hmm, no
[04:06] <Mithrandir> that's libpth2
[04:06] <Keybuk> Mithrandir: no, that's libpth20
[04:06] <jdong> Mithrandir: I can't find anything that rdepends libpthread20....
[04:06] <jdong> but I have come across 3 users that experienced the update problem
[04:06] <lifeless> perhaps its installed from $old-version
[04:07] <jdong> perhaps
[04:07] <jdong> what is the officially sane workaround for this, BTW
[04:08] <lifeless> wait
[04:08] <jdong> mmm :)
[04:13] <Mithrandir> ogra: I can accept python-ltsp on the condition that you clean up debian/ ; you're shipping effectively empty post- and preinsts (remove them), same goes for README.Debian, your debian/rules file has a configure target, but the package has no configure program, so it's useless.
[04:14] <ogra> Mithrandir, python-central rewrites the postinst files during build
[04:15] <ogra> but i'm fine dropping README.Debian and cleaning rules
[04:15] <ogra> (python-central through dh_pycentral)
[04:16] <Mithrandir> ogra: yes, it replaces the #DEBHELPER# token.  If you don't have any live code in there yourself, remove the file.
[04:17] <ogra> does it still create it ? i thought it needs a skeleton ...
[04:17] <ogra> but if that works i'll remove it
[04:19] <Keybuk> *confused*
[04:20] <froud> whose the best person to speak to about packaging of docbook and docbook-xsl?
[04:20] <jdong> cjwatson: ping; did you find the moderators you were looking for?
[04:23] <_MMA_> Mithrandir: Have you had a chance to look at the ubuntustudio-meta package again or will someone else be looking at it?
[04:24] <Mithrandir> _MMA_: it was accepted half an hour ago.
[04:24] <froud> Over at docbook project we're trying to contact all package maintainers for DocBook. How can I discover who is doing this for Ubuntu?
[04:24] <_MMA_> Thank you. Ill let my team know. ;)
[04:26] <MikeSmith> I do the docbook-xsl builds and releases
[04:26] <MikeSmith> the upstream ones
[04:27] <MikeSmith> I'd like to help get the edgy docbook-xsl package more up-to-date/synced up with the Debian one
[04:27] <ogra> Mithrandir, all fixed, want me to upload the fixed one before you approve ? 
[04:27] <Mithrandir> ogra: nah, I put it in, but please upload the new one.
[04:27] <MikeSmith> Debian docbook-xsl is at 1.71.0.dfsg.1-1.1
[04:27] <ogra> Mithrandir, will do as soon as the accepted mail is here ... thansk a lot
[04:27] <ogra> *thanks
[04:27] <MikeSmith> edgy one is at 1.68.1.dfsg.1-0.2
[04:28] <MikeSmith> which is very very old now
[04:28] <MikeSmith> 18 months or more old
[04:29] <froud> MikeSmith: apt-cache show says Adam Di Carlo <aph@debian.org>
[04:29] <froud> for docbook
[04:29] <froud> and Mark Johnson <mrj@debian.org> for docbook-xsl
[04:30] <Mithrandir> MikeSmith: docbook-xsl in feisty is 1.71.0.dfsg.1-1.1
[04:30] <froud> Mithrandir: yes, but dapper ppl what repository updated ... what to do?
[04:31] <Mithrandir> froud: nothing?  We're not introducing new upstream versions in released distributions.
[04:31] <MikeSmith> froud - DocBook stylesheet package is docbook-xsl
[04:31] <MikeSmith> and I know the Debian packager for it quite well
[04:32] <MikeSmith> my concern is just about making sure that Ubuntu users have easy access to the latest
[04:32] <MikeSmith> Mithrandir - thanks
[04:32] <froud> MikeSmith: seams they must install manual or dist-upgrade :-)
[04:33] <ogra> Mithrandir, hmm, i had the accepted message from soyuz ... but get a NEW message for the next upload ... seems i had a little race condition here ... sorry
[04:33] <MikeSmith> froud, Mithrandir - OK. So updated package don't get backported to dapper and edgy?
[04:34] <Mithrandir> MikeSmith: correct.  That is, they can be requested, but they're not automatically backported.
[04:34] <Mithrandir> (requested into -backports, not into the normal repo)
[04:34] <froud> Mithrandir: who does that?
[04:35] <Mithrandir> froud: https://wiki.ubuntu.com/BackportsHowto
[04:36] <Keybuk> jdong: ping ping ping ping ping
[04:36] <jdong> Keybuk: pong pong pong pong pong pong?
[04:36] <jdong> -1
[04:36] <Keybuk> jdong: don't suppose you have a record of when you installed libpthread20 ?
[04:36] <Keybuk> e.g. in /var/log/dpkg.log* ?
[04:36] <jdong> Keybuk: I was not affected....
[04:37] <MikeSmith> Mithrandir - so I guess I should file a bug if I want to request it be backported?
[04:37] <Keybuk> jdong: oh, bah
[04:37] <Mithrandir> MikeSmith: correct.
[04:37] <jdong> Keybuk: some people who were affected came to me :(
[04:37] <Keybuk> jdong: do you know of them?
[04:37] <MikeSmith> Mithrandir, froud - big thanks
[04:37] <jdong> Keybuk: wildtangent on #ubuntuforums (currently not on there; he had this problem yesterday), and a forum search can yield quite some more :)
[04:38] <Keybuk> jdong: can't find why anyone would have that installed though
[04:39] <jdong> Keybuk: heh, I'm just as puzzled
[04:42] <jdong> Keybuk: when the fixed libc6 package is released, will that automatically apply OK for people who already attempted applying the broken update?
[04:43] <jdong> i.e. will any apt-get -f install coercing be necessary?
[04:43] <Keybuk> jdong: the fix will automatically apply; assuming users haven't tried to force the issue themselves
[04:45] <jdong> ok
[04:46] <popey> who looks after planet.ubuntu.com?
[04:47] <popey> I have moved my domain but the rss planet doofer is still going to the wrong host for updates
[04:47] <Spads> popey: Any ubuntu-member can update it
[04:47] <Spads> popey: see https://wiki.ubuntu.com/PlanetUbuntu
[04:47] <popey> no, you don't understand
[04:47] <popey> the entry is correct
[04:48] <popey> but their box is doing incorrect dns lookup
[04:48] <popey> caching the old IP
[04:48] <lifeless> how long  ago did you move host ?
[04:48] <popey> last week
[04:48] <popey> its the only thing still hitting my apache logs
[04:48] <lifeless> what was your TTL before you moved ?
[04:48] <popey> good question
[04:48] <popey> i don't know
[04:49] <Spads> what's the hostname in question?
[04:49] <Spads> I can take a look
[04:49] <popey> popey.com
[04:49] <lifeless> planet runs a new process each time, so any caching is oming from the datacentre NS servers
[04:49] <popey> it is of course not a big deal, but I want to shut that apache down
[04:52] <lifeless> popey: what ip should it resolve to ?
[04:52] <jdong> Keybuk: I've posted a forumwide announcement urging people not to try their own ways of "fixing" the problem; also quoted your post asking for grepping of dpkg.log -- will ping you if any meaningful replies show up :)
[04:52] <popey> 212.13.198.80
[04:52] <lifeless> Spads: ^
[04:52] <Spads> popey: is there another FQDN for the IP in question you could use?
[04:52] <popey> bishop.popey.com
[04:53] <Spads> bishop.popey.com has address 212.13.198.80
[04:53] <Spads> that's on the planet host
[04:53] <Spads> so if you change it to that it should fix your problem for now
[04:53] <popey> that wont work
[04:54] <popey> apache will send that request elsewhere
[04:54] <Spads> I see.
[04:54] <popey> different virtual host
[05:00] <Spads> popey: I've put in a bit of a workaround.  /msg me if you still see hits from the planet system on the wrong host over the next hour
[05:00] <popey> thanks Spads 
[05:02] <lifeless> Spads: bind is over enthusiastic ?
[05:03] <Spads> lifeless: it's a little more complicated than that
[05:03] <lifeless> Spads: ah well. over a beer sometime perhaps
[05:17] <seb128> ogra: the upstream build works fine, the debian build call "xmlto -o doc/en/manual html doc/en/dia.xml" though
[05:18] <seb128> ogra: change doc/en/usage-layers.xml to be valid UTF-8 (quotes around the background word to change) and it builds fine
[05:18] <ogra> seb128, oh, then its a leftover from the old packaging
[05:18] <seb128> or drop the xmlto call
[05:18] <ogra> right ... do we need it at all ? 
[05:18] <ogra> hmm, well, if i drop it it will be a delta ... i'll rather do the quoting
[05:19] <seb128> ogra: doesn't look like
[05:19] <seb128> ok
[05:20] <seb128> ogra: from the changelog previous version lacked that xml, maybe that's why they built it with the package
[05:21] <seb128> ogra: the current tarball ships it though
[05:21] <ogra> ah
[05:21] <seb128> I would just comment the xmlto calls for the moment
[05:21] <seb128> we will adapt when syncing with Debian next time
[05:25] <ogra> yep, already testbuilding
[05:26] <AnAnt> I got a question about python: why isn't there a /usr/lib/python.so that can be set using /etc/alternatives/ ?
[05:29] <AnAnt> hello 
[05:29] <AnAnt> ?
[05:38] <\sh> Mithrandir, can you give-back again ldaptor? :) thx 
[05:47] <\sh> StevenK, doko, ldaptor compiles fine now with the StevenKs dia fix :) 
[05:47] <\sh> StevenK, thx for that :) 
[06:13] <kylem> morning kees.
[06:13] <keescook> hiya kylem
[06:13] <ogra> hey keescook 
[06:13] <keescook> hiya ogra
[06:19] <pitti> hey keescook 
[06:22] <jdong> keybuk... argh, come back :)
[06:22] <jdong> http://ubuntuforums.org/showpost.php?p=2057950&postcount=2
[06:22] <jdong> ^^ you've got one person whose dpkg.log shows a libpthread20 being installed
[06:23] <cjwatson> jdong: no, I didn't
[06:24] <jdong> cjwatson: I've posted a forum-wide announcement regarding not trying workarounds for the libc6 thing
[06:24] <jdong> hope that suffices
[06:24] <cjwatson> jdong: yeah, I saw - I think that will suffice, thanks
[06:24] <jdong> np :)
[06:24] <cjwatson> jdong: a rebuild is in progress that removes the check
[06:24] <jdong> good to hear
[06:25] <cjwatson> jdong: regarding http://ubuntuforums.org/showpost.php?p=2057950&postcount=2, the entire dpkg.log would be useful
[06:25] <cjwatson> jdong: Keybuk will be travelling for a while now, so I'd better take that over
[06:26] <lifeless> mdz: cjwatson: http://people.ubuntu.com/~robertc/possible-conflicts/
[06:26] <jdong> cjwatson: yeah, just told the guy to attach the log to the LP bug report
[06:27] <cjwatson> jdong: thanks, much appreciated
[06:27] <jdong> not a problem, glad to help
[06:27] <mdz> lifeless: greatly improved!
[06:27] <mdz> lifeless: can we collapse the cases which are identical across architectures into a single line?
[06:40] <lifeless> mdz: yes, that will happen another day though, as it does not currently buffer - which is needed to detect that
[06:45] <cjwatson> pitti: I was wondering if it'd be possible for ubiquity to use its own crash handler iff apport won't be around to catch the crash
[06:45] <cjwatson> pitti: do you think just skipping the crash handler if apport can be imported would do the job?
[06:45] <seb128> cjwatson: stop reassigning bugs to GNOME packages :p
[06:45] <cjwatson> seb128: hey, they were yours :-)
[06:45] <cjwatson> seb128: you can always get revenge by finding unassigned installer bugs
[06:46] <pitti> cjwatson: either that, or just checking whether apport-gtk package is installed, or /usr/share/apport/apport-gtk exists?
[06:46] <seb128> looks like indeed :p
[06:46] <cjwatson> pitti: or maybe apport to be frontend-agnostic
[06:46] <cjwatson> /usr/share/apport/apport?
[06:46] <pitti> cjwatson: right, just mentioning that people can uninstall apport-gtk but have apport installed
[06:46] <pitti> cjwatson: right
[06:46] <cjwatson> mm
[06:46] <cjwatson> right, I see your point
[06:46] <pitti> cjwatson: however, that shouldn't be an issue in the live system
[06:47] <cjwatson> I guess the gtk frontend can check for apport-gtk and the kde frontend can do similarly when there's a kde frontend
[06:47] <pitti> cjwatson: I can add Provides: apport-frontend if it helps
[06:47] <pitti> or that
[06:47] <cjwatson> I'm happier with checking a file than the dpkg database, as it'll be faster
[06:47] <pitti> right
[06:47] <mdz> lifeless: if you fix the '-' delimiter and remove the header ('possible conflict:') I think we can get what we need by post-processing against a whitelist
[06:47] <cjwatson> plus I prefer to do as little work as possible in an exception handler
[06:48] <pitti> cjwatson: I think in general, checking for /u/s/a/apport is equivalent to checking for import apport; the latter doesn't check for GUI existance either
[06:48] <lifeless> sabdfl: this was fun
[06:48] <cjwatson> mkay, I'll check for /usr/share/apport/apport-gtk I think
[07:13] <ogra> seb128, g-p-m uploaded
[07:14] <seb128> cool
[07:14] <ogra> my pbuilder took nearly 2h to resolve the deps ... something is wrong here
[09:44] <Mithrandir> \sh_away: given-back
[11:12] <RememberPOL> ffmpeg in mainstream repo is outtdated causing a lack of support for video is FLV files (audio works, [in VLC] )
[11:14] <Burgwork> RememberPOL: ffmpeg in which distro?
[11:15] <RememberPOL> well
[11:15] <RememberPOL> I'm running Xubuntu 6.10
[11:15] <RememberPOL> but it uses the mainstream ubntu distro
[11:15] <RememberPOL> *mainstream ubuntu repo
[11:15] <RememberPOL> http://slexy.org/paste/1074
[11:17] <Burgwork> ffmpeg is updated for the upcomign 7.04
[11:18] <RememberPOL> yes but can't it be put into the existing repo so i don't have to wait three months and upgrade my OS, or compile ffmpeg myself?
[11:19] <RememberPOL> or maybe i can find a fiesty deb instead of compiling
[11:19] <RememberPOL> heh
[11:20] <Burgwork> the issue is that newer ffmpeg breaks api/abi, so you need to recompile a bunch of other things
[11:20] <Burgwork> that being said, it may be backported
[11:21] <RememberPOL> abi?
[11:21] <Burgwork> application binary interface
[11:21] <LaserJock> I don't think libraries are that likely to be backported
[11:21] <RememberPOL> so installing a fiesty ffmpeg deb won't really help here?
[11:21] <Burgwork> not unless you have all of the depends of ffmpeg from feisty as well
[11:22] <Burgwork> the issue is not Ubuntus. It is that the ffmpeg upstream doesn't understand how ffmpeg is really used
[11:22] <RememberPOL> so all non-fiesty ubuntu users have to upgrade to fiesty before being able to play flv files.
[11:22] <RememberPOL> :x
[11:23] <LaserJock> well, software progresses. Sometimes you have to upgrade to get what you want
[11:23] <Burgwork> yes
[11:23] <RememberPOL> k
[11:23] <lamont> so how come my phone will pair  with my home machine, but not with my laptop?
[11:23] <Burgwork> I would write the ffmpeg people and complain to them about how they cannot keep api/abi stability
[11:23] <RememberPOL> i guess i'll just install vlc/flash on my windows vm
[11:23] <Burgwork> and what it hell is causes end users
[11:23] <lamont> Burgwork: or at least learn about sonames
[11:24] <LaserJock> RememberPOL: we would have to also update every package that is built using ffmpeg
[11:24] <Burgwork> lamont: anything at all, besides "install from cvs"
[11:24] <lamont> that is, they can change the abi if they must,  but they should version the soname
[11:24] <lamont> right
[11:24] <lamont> certain distros are prone to produce "what's an soname?" type questions from the developers... kinda scary
[12:03] <RememberPOL> Sweet I solved my issue (of FLV video not playing in Xubuntu 6.10 due to outdated ffmpeg [fixed in fiesty-7.04, not being backported because ffmpeg breaks api/abi] ) by downloading http://download.macromedia.com/pub/flashplayer/updaters/9/flash_player_9_linux_dev.tar.gz then extracting libflashplayer.so and flashplayer.xpt from /flash_player_9_linux_dev/plugin/debugger/install_flash_player_9_linux.tar.gz/install_flash_player_9_linu