[11:57] <Eickmeyer> FYI: I'm going to be out of town this week on a vacation. I might be available, but not as much as usual.
[11:57] <Eickmeyer> This week as in today through next Wednesday.
[16:40] <cjoke> Cheers! Happy hollidays! :)


[00:00] <mok0_> civija: It doesn't look like it -- unless you also change the section to contain "universe"
[00:02] <Laney> fwiw, I just tried it with the hello package and it worked fine
[00:02] <Laney> updated the maintainer to ubuntu-core-dev
[00:03] <mok0_> Laney: try the --section switch...
[00:03] <Laney> mok0_: I just shut down my eee :(
[00:03] <mok0_> Laney:  --section=universe
[00:03] <mok0_> eeek
[00:03] <slangasek> mok0_: update-maintainer *should* change Maintainer to XSBC-Original-Maintainer, any time that it succeeds in doing anything
[00:03] <mok0_> :-)
[00:04] <slangasek> though sometimes you have to tell it which section your package is going to, yes
[00:14] <Adri2000> civija: does the most recent version of the package (ie. the first line in debian/changelog) contain 'ubuntu' ?
[00:16] <civija> Adri2000: no
[00:16] <blueyed> I'd like to change the versioning of a kernel module package to use the kernel ABI in the first part, but the package is currently at version 15 already. Looks like I need an epoche, correct?
[00:16] <Adri2000> civija: that's why it won't change the maintainer then
[00:17] <civija> Adri2000: so i should first run dch -i, write change ..., and then run update-maintainer?
[00:17] <crimsun> blueyed: e.g., or a suffix appended with +
[00:17] <Adri2000> civija: yes
[00:18] <civija> Adri2000: ok, tnx
[00:18] <civija> i'll try that
[00:18] <blueyed> crimsun: i.e. 15+2.6.24-12.1? (15 is the current version)
[00:19] <crimsun> blueyed: that's the idea, though I suppose I tend to match the 12.x portion against the headers, so I think 12.22?
[00:20] <crimsun> blueyed: (though, if you're tweaking it, that's up to you)
[00:25] <blueyed> crimsun: well.. I've thought that it wouldn't be important for the package and therefore I use my revision there at the end.
[00:25] <crimsun> blueyed: fair enough.
[00:26] <blueyed> It should get moved to linux-ubuntu-modules anyway in the long term I think, so..
[01:11] <bddebian> Heya gang
[02:05] <ScottK2> heya bddebian.
[02:08] <bddebian> Hi ScottK2
[02:20] <Hobbsee> Nightrose: ?
[02:21] <Hobbsee> (evolution-jescs given back)
[03:52] <Legendario> hi. Pbuiler is returning me an error message i just can't understand why... It says it can't install libjack-dev
[03:53] <Legendario> does anyone know a possible reason for it?
[03:54] <StevenK> You don't have universe enabled in your pbuilder environment?
[03:55] <Legendario> StevenK, how can I enable it?
[03:55] <emgent> uhm, strange problem.. when i try to edit control and add Maintainer, when i debuild, change Maintainer with original..
[03:55] <emgent> some idea?
[03:56] <StevenK> emgent: There's a debian/control.in file?
[03:56] <emgent> phpmyadmin package..
[03:56] <emgent> uhm just a moment
[03:56] <StevenK> Legendario: Um, add universe to your components and pbuilder update with --overwrite-config
[03:57] <Hobbsee> !pbuilder | Legendario
[03:57] <ubotu> Legendario: pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
[03:57] <Hobbsee> Legendario: actually follow ^&
[03:58] <emgent> StevenK: no only control
[03:58] <Legendario> hum, no. There is only a debian/control file, not a debian/control.in
[03:58] <emgent> trye
[03:58] <emgent> *true*
[03:58] <emgent> StevenK: other idea? :°
[03:58] <StevenK> emgent: Then I'd need to read a build log
[03:59] <emgent> i saw that in debdiff
[03:59] <emgent> when i run debuild, cleaned my edit in debian/control file
[04:00] <emgent> strange..
[04:00] <StevenK> emgent: Yes, so something in the build process is changing it. So I'd need to read a build log to point out what is doing it.
[04:04] <Legendario> ok, so, i had to edit my ~/pbuilderrc file, right? Thanks guys
[04:05] <emgent> StevenK: i think this "yada rebuild control"
[04:06] <StevenK> Nooooooooooooo
[04:06]  * StevenK runs screaming
[04:07] <RAOF> yada has a "Please break my builds in hard to track, near-random ways" option?
[04:07] <StevenK> Yes. That is its default mode of operation
[04:07]  * RAOF shudders
[04:09]  * RAOF gets around to actually _filing_ his "sensors-applet does nothing but segfault" bug.
[04:14] <emgent> uhm...
[04:15] <adorablepuppy> Hi.
[04:18] <emgent> StevenK: some idea to bypass yada rebuild ?
[04:18] <StevenK> emgent: Don't use yada. yada is bad.
[04:19] <LaserJock> I thought it was your favorite?
[04:19] <emgent> StevenK: is in the package, i only applied security patch
[04:19] <emgent> hy cody
[04:20] <cody-somerville> heya emgent :)
[04:21] <ScottK2> emgent: Since it's yada, I'd suggest skip the maintainer mangling, explain to the security team why you did it, and then let them figure it out if they really care.
[04:22] <emgent> i will do, thanks :)
[04:22] <ajmitch> LaserJock: don't wind the poor chap up
[04:24] <ScottK2> Heya ajmitch
[04:24] <ajmitch> good afternoon
[04:24] <LaserJock> ajmitch: heh
[04:24] <ScottK2> Good to seeing you around.  I've been missing your smiling face.
[04:25]  * ajmitch isn't here
[04:26] <ScottK2> ajmitch: While your not here, is your RC bug tracker by chance running elsewhere too?
[04:26] <ajmitch> nope
[04:27]  * ajmitch has no static IP address to serve it from
[04:28] <LaserJock> is ubuntuwire still down??
[04:28] <ScottK2> LaserJock: AFAIK yes.  Still no imbrandon
[04:28]  * ScottK2 has had the flu this week and didn't get around to calling him again.
[04:29]  * ajmitch hasn't seen imbrandon on irc for a long time
[04:29] <ajmitch> partly because I don't usually watch irc now
[04:29] <ScottK2> Well it is nice to see you again even if you aren't here.
[04:29]  * ajmitch is usually in channel, at least
[04:30] <ajmitch> just not often talking to people
[04:30]  * ajmitch would think that the rc bug tracker thing isn't as useful now anyway
[04:31] <LaserJock> ajmitch is a stalker
[04:31] <ajmitch> true story, that
[04:31] <ScottK2> ajmitch: Why not?
[04:32]  * ajmitch has been mercilessly stalking laserjock, watching his every movement
[04:32] <ajmitch> ScottK2: because of other lists of bugs that should say similar things
[04:34] <ScottK2> ajmitch: OK.  Maybe I need to go look around for other lists then.  Your is the one I always used.
[04:35] <ajmitch> that 'really fix-it' list would help a bit, if the bug link has been set in launchpad
[04:35] <rhpot1991> ScottK ScottK2 ping
[04:35]  * ajmitch would need to find somewhere sane to put the rc bugs list
[04:35] <rhpot1991> https://bugs.launchpad.net/gutsy-backports/+bug/202049
[04:35] <ubotu> Launchpad bug 202049 in gutsy-backports "Please backport new MythTV themes from Hardy" [Undecided,New]
[04:36] <rhpot1991> superm1 informed me that you wanted to see those tested seperately
[04:37] <LaserJock> I'm getting the feeling that Hardy's gonna get release without quite a few good new upstream release and bug fixes
[04:37] <LaserJock> things are really moving fast at this point
[04:37] <ajmitch> that's expected
[04:37] <ScottK2> rhpot1991: Yes.  I'd also like to see the depwait for the basic mythtv backport cleared up too.
[04:37] <LaserJock> yeah, just a bit disappointing
[04:37]  * ajmitch is going to wander home now, nice talking to you again :)
[04:38] <LaserJock> cya ajmitch
[04:38] <superm1> ScottK2, sorry i've been busy with some other stuff than to look into the details of why that happened on the non standard arch's
[04:38] <superm1> i'll get to it soon
[04:39] <ScottK2> ajmitch: See ya.  Thanks for stopping in.
[04:39]  * ScottK2 wonders if he highlights on php?
[04:41] <Hobbsee> ajmitch!
[04:41] <Hobbsee> emgent: then fix the package.
[04:42] <emgent> yep
[04:42] <emgent> first I'd like talk with keescook
[04:42] <emgent> then i will do :P
[04:43] <emgent> (hi Hobbsee) :)
[04:43] <Hobbsee> hiya
[04:50] <cody-somerville> Hobbsee, Would you do me a big fat favour and regenerate and upload xubuntu-meta for me? :)
[04:58] <superm1> ScottK2, it looks like they are sorting themselves out some how
[04:59] <superm1> only lpia is failing now
[04:59] <superm1> and its because of missing libx264-dev
[04:59] <superm1> which is in gutsy multiverse...
[04:59] <ajmitch> Hobbsee: yes?
[04:59] <superm1> just not on lpia
[05:00] <slangasek> Hobbsee: I'll take care of the above xubuntu-meta update
[05:00] <cody-somerville> slangasek, thanks :)
[05:02] <ScottK2> superm1: OK.  Well that's progress.  Is libx264-dev actually missing no lpia?
[05:02] <superm1> ScottK2, https://launchpad.net/ubuntu/gutsy/+source/x264/+builds
[05:02] <superm1> it failed to build on lpia
[05:02] <ScottK2> looking
[05:02] <superm1> on gutsy at least
[05:02] <superm1> worked on hardy though
[05:03] <superm1> ah i see why
[05:03] <ScottK2> superm1: Why?
[05:03] <superm1> in hardy it has nasm [i386 lpia] as build depends
[05:03] <Hobbsee> slangasek: thanks
[05:03] <Hobbsee> ajmitch: hello
[05:03] <superm1> failed due to missing nasm in gutsy
[05:04] <superm1> on lpia
[05:04] <ScottK2> superm1: Maybe an SRU then?
[05:05] <superm1> well i guess that really depends on how important mythtv on lpia is to gutsy
[05:05] <ScottK2> Probably not very.
[05:06] <ScottK2> But I like to see things complete.
[05:06] <superm1> i gathered as much :)
[05:06] <ScottK2> It's not such a big deal, but if it's an easy fix it'd be nice.
[05:06] <ScottK2> superm1: Let me know when you think the plugins are ready to go...
[05:07] <superm1> so i'm not sure the extra effort to right that is worth it.  If someone complains that they want their mythtv 0.21 on an lpia gutsy (who has those other than developers for moblin stuff)?, i'll take care of it
[05:07] <superm1> ScottK2, you mean the themes?
[05:07] <ScottK2> Yeah'
[05:07] <ScottK2> That
[05:07] <superm1> the themes look fine to me, rhpot1991 has a gutsy box that i asked him to do the backport to his ppa and install to
[05:07] <superm1> none of them failed to build or anything similar
[05:07] <superm1> so i'd say not a worry there
[05:08] <ScottK2> rhpot1991: Did you finish testing them all?
[05:08]  * ScottK2 notices the time, remembers he has the flu, and decides to go to bed.
[05:08] <ScottK2> Good night all.
[05:09] <superm1> ScottK2, yeah as indicated in the bug, they all built and installed
[05:09] <superm1> see ya though
[05:10] <ScottK2> pm me the bug and I'll look at it tomorrow.
[05:11] <superm1> alrighty
[05:11] <superm1> night
[05:14] <Legendario> i am having the following error message: error: could not create '/usr/lib/python2.5/site-packages/blueman': Permission denied
[05:16] <Legendario> what am i supposed to do?
[05:18] <slangasek> Legendario: what are you *trying* to do?
[05:18] <slangasek> building a package?
[05:18] <Legendario> yes
[05:19] <slangasek> you need to tell the upstream rules to install to a subdirectory of debian/ instead of to the root filesystem
[05:19] <slangasek> I don't know what the convention is for python modules; for stuff that uses autoconf, the convention is make DESTDIR=debian/tmp install
[05:20] <Amaranth> i think it's python setup.py --destdir debian/tmp install
[05:20] <Amaranth> or something
[05:20] <Amaranth> i dunno, python project that use setup.py should die :)
[05:21] <TheMuso> cody-somerville: I can do xubuntu-meta if nobody else has started on it already.
[05:21] <RAOF> The convention for python modules depends on what debhelper you're using, pretty much.
[05:21] <cody-somerville> TheMuso, slangasek said he'd do it.
[05:21] <cody-somerville> slangasek, Have you started on xubuntu-meta yet? :)
[05:21] <TheMuso> oh ok
[05:22] <slangasek> cody-somerville: started dput, yes
[05:22] <cody-somerville> TheMuso, Okay. Thanks anyhow :)
[05:22] <TheMuso> cody-somerville: np
[05:22] <superm1> slangasek, what to do if a package already in gutsy-backports just needs to be rebuilt?  Should I file another backport bug, or can you just press a magical dch -i "no changes, just rebuilding"?
[05:23] <slangasek> superm1: I don't have any magical buttons for that; I think a sourceful upload on your part is going to be the most straightforward
[05:24] <superm1> slangasek, directly to gutsy-backports, or where to?
[05:24] <slangasek> superm1: yes
[05:24] <superm1> slangasek, okay i'll take care of that
[05:24] <superm1> thanks
[05:24] <slangasek> superm1: oh, are you in the backporters group?  If not you probably should clear it with jdong or ScottK first
[05:24] <Legendario> RAOF, what do you mean by the convention for python modules depends on what debhelper you're using?
[05:24] <superm1> slangasek, no i'm not in the backporters group.
[05:25] <superm1> let me do a test build then and put it in a proper bug so that they dont need to think much
[05:25] <slangasek> superm1: right :)
[05:25] <Legendario> should i edit the setup.py file or a file in the debian folder?
[05:26] <Amaranth> I thought backports were automatic copies of hardy source packages
[05:26] <slangasek> there are sourceful backports as well
[05:27] <slangasek> Legendario: normally you should not have to edit setup.py.  I think the suggestion Amaranth gave you first looks most promising
[05:29] <Legendario> slangsek, sorry. but i didn't understand what to do exactly
[05:31] <Legendario> could you please be more specific?
[05:34] <Legendario> slangasek
[05:36] <slangasek> Legendario: you know that debian/rules is the file that controls how packages are built?
[05:36] <slangasek> Legendario: you need to edit that file; either in a straightforward way based on Amaranth's suggestion, or perhaps in a non-obvious way if you're using cdbs
[05:38] <Legendario> slangasek, this is a line in my debia/rules: $(MAKE) DESTDIR=$(CURDIR)/debian/blueman install
[05:39] <Legendario> is this what i was supposed to do?
[05:39] <slangasek> I don't know
[05:39] <Legendario> or do i have to add something else?
[05:39] <slangasek> you haven't given any context about your package, that I can see
[05:39] <slangasek> I can't tell you what's right or not without ever seeing the package in question
[05:40] <Legendario> slangasek, well, it is a python software but it has a make file and a setup.py file
[05:40] <slangasek> I can tell you that line will pass the DESTDIR variable to the upstream makefile when calling 'make install'.  I don't know whether that will do the right thing for this upstream software.
[05:44] <Legendario> should i substitue the $(MAKE) DESTDIR=$(CURDIR)/debian/blueman install, for python setup.py --destdir debian/tmp
[05:46] <Legendario> ?
[05:47] <RAOF> Legendario: What I meant was: where you want the modules to end up depends on whether you're using pysupport or pycentral.
[05:50] <Legendario> RAOF, i don't understand a thing about python, so need straighter directions. Does it help? http://paste.ubuntu-nl.org/59562/
[06:01] <RAOF> Legendario: That doesn't have enough context to be very useful.  debian/rules would be good, as would be information about what you're actually trying to package and how to build it (can you build it without trying to make a package?)
[06:02] <Legendario> ok
[06:05] <Legendario> RAOF, i don't think this is going to help much, since it is a normal debian/rules file
[06:05] <Legendario> http://paste.ubuntu-nl.org/59564/
[06:11] <RAOF> Legendario: Right, so it's practically a dh-make template.
[06:11] <RAOF> Legendario: So, the other question remains.  Can you actually build this program without trying to package it?
[06:12] <RAOF> If you can't do that, you've got no hope of packaging it :)
[06:15] <Legendario> RAOF, i didn't try to build the source. You can take a look on the program site: http://blueman.tuxfamily.org/
[06:16] <RAOF> Legendario: Heh.  So, a fundamental part of packaging is to encapsulate the build processes of the thousands of packages we have.  If you don't know how to build it, you can't package it :)
[06:17] <RAOF> And, that website ( http://blueman.tuxfamily.org/index.php?option=com_content&view=article&id=50&Itemid=60 ) tells me you're building it wrong.
[06:19] <Legendario> RAOF, what am i supposed to do?
[06:19] <RAOF> Well... "to install run sudo python setup.py install".
[06:20] <RAOF> So your debian/rules is going to have to call setup.py at some point :)
[06:21] <RAOF> What you actually want to do is to work out what parameters their setup.py takes, what the build actually does (ie: if it builds any arch-dependent code such as shared libraries, you'll probably need to call setup.py once for each python version, etc)
[06:36] <cody-somerville> slangasek, how is the xubuntu-meta upload going?
[06:38] <slangasek> cody-somerville: well enough, aside from me forgetting to accept it from the queue
[06:38] <cody-somerville> slangasek, :)
[06:39] <Legendario> RAOF, i could do it. thanks RAOF
[06:52] <Legendario> could do it. if someone can review it, i would apreciate it: http://revu.tauware.de/details.py?package=blueman
[09:13] <dholbach> good morning
[09:15] <tonyyarusso> Someone care to remind me of the "right" way to do a diff for a small (like 6-character) change to a source package?  Something like diff -rN somesuch I think.
[09:17] <dholbach> diff -ruN?
[09:17] <tonyyarusso> That's the one.
[09:18] <dholbach> rock! :)
[09:18] <tonyyarusso> I also need a little bit of versioning advice.
[09:19] <tonyyarusso> I'm dealing with nvu --> kompozer, which basically amounts to a renaming as far as our users are concerned, but they have different versioning schemes.  The version of nvu in the repos is 1.0-0ubuntu4 and 1.0final-2ubuntu2 for dapper and edgy, respectively,
[09:20] <tonyyarusso> while the version of kompozer is 0.7.10-0ubuntu3.  I need to make the virtual package 'nvu' provided by the kompozer source package such that any users with nvu installed will be upgraded to kompozer.
[09:22] <tonyyarusso> So basically, I a) need some scheme for making virtual packages have a different version than their source package, and b) need a suggestion for a version higher than 1.0 that I can assign it.
[09:27] <tonyyarusso> dholbach: any idea how to approach that?
[09:27] <dholbach> you'll need to add an epoch
[09:28] <dholbach> (1:0.7.10-0ubuntu3)
[09:28] <dholbach> do we
[09:28] <dholbach> http://www.debian.org/doc/debian-policy/ch-controlfields.html
[09:28] <tonyyarusso> readin'
[09:28] <dholbach> do we get that package from debian?
[09:29] <dholbach> if so we should coordinate the epoch change with debian
[09:29] <dholbach> it might permanently prevent us from syncing if our version is higher than the one in debian
[09:29] <dholbach> 5.6.12 Version
[09:30] <tonyyarusso> dholbach: It does not yet exist in Debian.  (I'm hoping to have a chance to start addressing that next week)
[09:30] <dholbach> right
[09:30] <dholbach> so adding an epoch should be fine
[09:30] <tonyyarusso> So I apply the epoch change to the entire source package I take it?
[09:31] <dholbach> you add it to the version in your debian/changelog entry
[09:31] <tonyyarusso> (do epochs show in things like apt-cache policy?)
[09:31] <tonyyarusso> gotcha
[09:31] <dholbach> daniel@lovegood:~$ LC_ALL=C apt-cache policy gthumb
[09:31] <dholbach> gthumb:
[09:31] <dholbach>   Installed: 3:2.10.6-0ubuntu1.1
[09:31] <dholbach>   Candidate: 3:2.10.6-0ubuntu1.1
[09:31] <dholbach>   Version table:
[09:31] <dholbach>  *** 3:2.10.6-0ubuntu1.1 0
[09:31] <dholbach> ...
[09:31] <tonyyarusso> so 1:0.7* > [presumed 0:]1.0*
[09:32] <dholbach> yes
[09:32] <tonyyarusso> It never ceases to amaze me how many things the dpkg people already thought of.
[09:32] <dholbach> daniel@lovegood:~$ dpkg --compare-versions 1:0.7 gt 1.0 && echo true
[09:32] <dholbach> true
[09:32] <dholbach> daniel@lovegood:~$
[09:32] <dholbach> yeah, that's right :-)
[09:33] <dholbach> the shoulders of giants :)
[09:33] <tonyyarusso> hehe
[09:42] <elmargol> Does a printing JOB run as user?
[09:42] <elmargol> If i try to print something i get D [14/Mar/2008:10:33:21 +0100] [Job 35] Error: /usr/Brother/inf/brFAX1940CNrc :cannot open file !!
[09:51] <tonyyarusso> dholbach: So do I need to touch _anything_ other than debian/changelog for this?
[09:52] <dholbach> do the normal update you intended to do, make all the changes necessary, then add the epoch
[09:52] <dholbach> that should be it
[09:53] <tonyyarusso> The epoch issue is the only thing I'm addressing today, so yeah.
[09:54] <tonyyarusso> dholbach: oh, one thing though - should I bump the ubuntu version, ie 1:0.7.10-0ubuntu4, or leave it as 1:0.7.10-0ubuntu3?
[09:56] <dholbach> as it's a new upstream version, I'd say 1:0.7.10-0ubuntu1
[09:57] <tonyyarusso> Oh.  I guess that makes sense.
[09:58] <dholbach> ROCK
[09:59] <tonyyarusso> Paper?
[10:01] <tonyyarusso> So something like "diff -ruN kompozer-0.7.10/ sourced_for_diff/kompozer-0.7.10/ > debdiff.txt", and attach debdiff.txt to the bug?
[10:05] <dholbach> you can use     debdiff old.dsc new.dsc
[10:08] <tonyyarusso> And iirc, that's since I only made changes to debian/, but diff -ruN would be needed if there were any changes in the actual source - is that right?
[10:08] <tonyyarusso> or same thing both ways?
[10:14] <dholbach> you don't need to keep two directories if you run debdiff on the .dsc files
[10:15] <dholbach> but you can use diff -ruN too
[10:16] <tonyyarusso> gotcha
[10:17] <tonyyarusso> All righty, "should" all be set to go at Bug #200349.
[10:17] <ubotu> Launchpad bug 200349 in kompozer "Versioning for nvu virtual package wrong" [Undecided,New] https://launchpad.net/bugs/200349
[10:28] <dholbach> tonyyarusso: errrrm
[10:28] <tonyyarusso> dholbach: crud, what'd I do wrong?
[10:29] <dholbach> ahhhhh, now I understand
[10:29] <dholbach> excusez-moi :)
[10:29] <tonyyarusso> yay!
[10:29] <tonyyarusso> Does that mean I'm not getting ratted out today?  :P
[10:33] <dholbach> tonyyarusso: uploaded
[10:33] <tonyyarusso> dholbach: sweetness - thanks a bunch!
[10:33]  * tonyyarusso checks off one of the todo items, goes to test the bugs he has "needs info"
[10:44] <dholbach> tonyyarusso: weird... upload was rejected - I'l try again
[10:45] <tonyyarusso> dholbach: odd
[10:45] <tonyyarusso> any kind of useful message?
[10:46] <dholbach> "MD5 sum of uploaded file does not match existing file in archive...."
[10:47] <dholbach> tonyyarusso: I'll try ubuntu4 instead and see if that works
[10:47] <tonyyarusso> that might be it
[10:47] <dholbach> but that'd be weird
[10:55] <dholbach> tonyyarusso: seems the right thing to do is the ubuntu4 upload
[10:56] <tonyyarusso> dholbach: all righty then.  Not quite sure why, but whatever works.
[10:56] <dholbach> look at the generated dsc file
[10:56] <dholbach> it says:
[10:56] <dholbach> Files:
[10:56] <dholbach>  42e0d7dddb19a7db5315906ea7c29cbd 806 web optional kompozer_0.7.10-0ubuntu1.dsc
[10:56] <dholbach>  b387cd9e1328c8c11517cd59d9b2be32 23882 web optional kompozer_0.7.10-0ubuntu1.diff.gz
[10:56] <Fujitsu> tonyyarusso: Colons aren't always safe to use in filenames.
[10:56] <dholbach> these files already were accepted by the buildd with different md5sums
[10:56] <Fujitsu> Epochs aren't present in the filenames.
[10:57] <tonyyarusso> I see.
[11:03] <jsgotangco> hey dholbach long time no chat
[11:04] <dholbach> hey jsgotangco
[11:04] <dholbach> jsgotangco: how are you doing?
[11:04] <jsgotangco> not bad just busy lately with all these travels and deadlines
[11:05] <dholbach> I can imagine
[11:05]  * dholbach hugs jsgotangco
[11:06] <jsgotangco> heh
[11:37] <Iulian> Hey
[11:39]  * Hobbsee waves
[11:40]  * Hobbsee points at jsgotangco - it's spam!
[11:45] <jsgotangco> lol
[11:55] <zul> ,prmomg
[11:55] <zul> ugh...morning
[11:56] <\sh> moins zul
[12:09] <sistpoty|work> hi folks
[12:09] <theseinfeld> hi
[12:09] <Hobbsee> hi sistpoty|work
[12:09] <sistpoty|work> hi Hobbsee
[12:16] <sistpoty|work> Hobbsee, ScottK, TheMuso: bug 201962 for gfortran transition... opinions?
[12:16] <ubotu> Launchpad bug 201962 in petsc "gfortran transition" [Undecided,In progress] https://launchpad.net/bugs/201962
[12:34] <sistpoty|work> ScottK: all packages in the bug need to be transitioned, but I cannot really remember how many new upstream versions there are (nor did I look out for these too hard).
[12:42] <mok0> sistpoty|work: The gfortran transition is a LOT of work, because it might entail more than just changing the packaging. I've sometimes had to work hard to get a program to compile under gfortran.
[12:43] <Fujitsu> mok0: Debian has done the vast majority already.
[12:43] <Fujitsu> That's where I've got most of the bits that I've done (which was just finishing stuff that doko had started).
[12:43] <mok0> Well, the list on LP is still very long
[12:43] <sistpoty|work> mok0: yes, there should be only 2-3 packages not done in debian left
[12:43] <Fujitsu> It was made more difficult by the fact that they all FTBFS due to one of doko's other changes.
[12:43] <mok0> sistpoty|work: so it's mostly merging?
[12:44] <sistpoty|work> mok0: I hope mostly syncing :)
[12:44] <mok0> ok... phew
[12:44] <cody-somerville> sistpoty|work, The test builds were successful.
[12:44] <Fujitsu> sistpoty|work: Are there any more than mopac7 and its rdepends (libghemical, so also ghemical) that aren't done in Debian?
[12:44] <cody-somerville> sistpoty|work, ghc6 is ready for upload :)
[12:44] <sistpoty|work> cody-somerville: excellent! I'll look in sponsoring ghc6 tonight, once I'm home
[12:45]  * sistpoty|work looks
[12:47] <sistpoty|work> Fujitsu: libextutils-f77-perl w.o. patch, some more with a patch in BTS (5-8, depends on if we want to follow unstable removals as well)
[12:49] <Fujitsu> sistpoty|work: Still, not too bad, and they might have fixed them within a couple of weeks.
[12:49] <sistpoty|work> Fujitsu: yes
[12:53] <cody-somerville> jono, ping
[12:53] <jono> cody-somerville: hey
[12:53] <jono> cody-somerville: skype?
[12:54] <cody-somerville> jono, Sounds good.
[12:54] <cody-somerville> jono, Just let me do a sound test
[12:55]  * cody-somerville sighs.
[12:55] <cody-somerville> I get it to work last night and ofcourse it stops working today. One second, a reboot should fix it
[13:09] <hellboy195> dholbach: around?
[13:09] <mok0> How do you make use of the crash_report that is attached to some bugs?
[13:09] <dholbach> hellboy195: yes
[13:10] <hellboy195> dholbach: I edited the debdiff. And it seems that it's only a newline missing, right? electricsheep
[13:11] <dholbach> hellboy195: searching the bug
[13:11] <hellboy195> dholbach: bug #201417
[13:11] <ubotu> Launchpad bug 201417 in electricsheep "Merge electricsheep 2.6.8-9 from Debian(Unstable)" [Undecided,Confirmed] https://launchpad.net/bugs/201417
[13:12] <dholbach> hellboy195: alright
[13:12] <hellboy195> dholbach: I added a newline after line 214 and it seems to work
[13:13] <hellboy195> dholbach: make a new debdiff or will you try at you own?
[13:13] <dholbach> I tried it and it seems to work
[13:13] <hellboy195> dholbach: ok. sry again. I edited the debdiff and removed the useless entries ,...
[13:17] <dholbach> hellboy195: uploaded
[13:17] <hellboy195> dholbach: thank you :)
[13:18] <dholbach> brb
[13:19] <bddebian> Heya gang
[13:20] <jpatrick> bddebian: hey
[13:20] <bddebian> Hello jpatrick
[13:29] <\sh> if anyone is interessted, I uploaded php5-amfext to my ppa....
[13:30] <elmargol> I have an application who gives this message "Can't find xulrunner-xpcom, mozilla-xpcom or firefox-xpcom"
[13:30] <elmargol> I can not find a xpcom pakage :(
[13:31] <Lamego> firefox-dev or libxul-dev ?
[13:32] <elmargol> ahh libxul-dev
[13:32] <elmargol> thx a lot
[13:32] <Lamego> np, is just a guess
[13:33] <\sh> oh hell...I just hacked the best memory profiling tool ever
[13:35] <\sh> nixternal: lol...chatting over twitter is even more sick ;)
[13:35] <nixternal> hahaha
[13:35] <nixternal> it took me a second to realize just who you were :)
[13:35] <nixternal> then you said bad old Germany and I knew right away
[13:36] <\sh> nixternal: lol...
[13:37] <\sh> nixternal: but there is a bed waiting for you ;)
[13:37] <nixternal> I have been watching these shows on PBS here where they go through and talk about different countries in Europe..there is a person talking about the different things, but the video is nothing more than high definition flyover from a helicoptor
[13:37] <nixternal> Germany, the countryside, is exactly what I invision as my dream location for living
[13:37] <nixternal> the countryside of France is beautiful too
[13:39] <\sh> nixternal: oh good to know...french frontier is just less then an hour drive from my place ;) actually it's only 2 km to the Rhine and you can see france already ;)
[13:40] <\sh> nixternal: if you have a motorized boat, you could be there in less then 10 mins ;)
[13:40] <nixternal> I gotta get away from mansions, SUVs, and O'Hare airport :)
[13:41] <nixternal> right now, I live 30 minutes outside of the city (Chicago), and when we moved here back in the 80s, it was all country...now it is all part of the city/suburb life and it isn't my cup of tea anymore
[13:58] <slytherin> dholbach: I was trying to fix the evolution-scalix package. I have patched the configure.in and configure script and it goes past configuration problem. But it fails in actual compilation. I am not able to figure out what the problem is as I am not very good with C. Do you think you can take it further if you have got time?
[14:03] <Ubulette> in case someone missed it: "Policy checker linda removed from testing/unstable". See http://permalink.gmane.org/gmane.linux.debian.devel.announce/1187
[14:06] <slytherin> I wonder why. :-)
[14:14] <Ubulette> maybe because of the previous article: http://permalink.gmane.org/gmane.linux.debian.devel.announce/1186 "Lintian has been under fairly active development for the past couple of years"
[14:23] <slytherin> Ok I found the answer in the article itself
[14:31] <mok0> ScottK: ping
[15:01] <huats> ScottK: ping too :)
[15:01] <DktrKranz2> geser: I had the chance to test new dietlibc on amd64, it worked fine and I uploaded new revision. I'm going to manage rebuilds soon, please tell me if you want to proceed with bglibs.
[15:04] <geser> DktrKranz2: good to hear. I'll look at bglibs.
[15:06] <DktrKranz2> There are two bugs related to bglibs, 184625 and 163774. They will hopefully be solved.
[15:07] <nxvl> happy Âpi day!
[15:07] <nxvl> i mean, good morning
[15:08] <geser> yes, both could be fixed with it
[15:08] <geser> nxvl: Hi
[15:08] <nxvl> geser: :D
[15:09] <geser> you too a happy π day
[15:09] <nxvl> DktrKranz2: dod you take a look at Bug #179790 ? i have merged with other 2 bugs as you requested
[15:09] <ubotu> Launchpad bug 179790 in tinyerp-server "postgresql listens on :5432" [Undecided,Confirmed] https://launchpad.net/bugs/179790
[15:10] <DktrKranz2> nxvl: thanks for merging. I haven't had a look at it yet, yesterday I was mostly out, but I'll probably have a look in the weekend after set up VMs again on Sid.
[15:11] <geser> nxvl: does the logfile from tinyerp get rotated?
[15:14] <nxvl> DktrKranz2: ok, thnx
[15:21] <nxvl> geser: dunno, i just apply a patch someone send
[15:22] <nxvl> geser: but, that's syslog work
[15:22] <nxvl> geser: not tinyerp ones
[15:22] <nxvl> one*
[15:22] <nxvl> i haven't tested that far
[15:24] <geser> nxvl: syslog doesn't do the logrotation, bug logrotate and only for those logfiles it's configured for
[15:25] <geser> without some logrotation the logfile may increase in size till the partition is full
[15:27] <\sh> anyone working on pushing anjuta 2.4.x into universe?
[15:28] <huats> \sh: actually pochu and I are going to work on it
[15:28] <\sh> huats: cool :)
[15:29] <huats> but if you want to ask the sync yourself I have no objections :)
[15:29] <\sh> huats: na I just saw that debian had already a new version....and we had 2.3.5 packaged ourselfs :)
[15:29] <\sh> huats: is it already usable as python ide? ,)
[15:29] <huats> \sh: don't know...
[15:30] <\sh> that reminds me to file a FFe for claws-mail still
[15:30] <huats> but it was on my ToTRY list :)
[15:30] <huats> I am planning to work on it on monday
[16:00] <jroes_> is the lighttpd package up to date for the latest security patches released in the feisty repos?
[16:00] <jroes_> the version tag is an older version, but I don't know if it was just patched without updating the version number or something...
[16:00] <\sh> jroes_: lighttpd is patched with the latest security patches...don't think 1.4.19 is better then our 1.4.xx version in feisty :)
[16:01] <\sh> jroes_: emgent is the dude who does all those shiny security things for lighttpd :)
[16:01] <jroes_> ok, just checking :)
[16:01] <\sh> jroes_: you can always read the changelog
[16:01] <\sh> jroes_: if something is missing, we are a) working on it, or b) we are busy with other security stuff/new funny stuff...it's universe ;)
[16:02] <jroes_> good point, I should have googled for the changelog (or is there even a way to see the changelog in apt?  I bet there is and I'll find it here shortly :))
[16:02] <\sh> jroes_: it's on da launchpad
[16:02] <jroes_> excellent, thanks \sh :)
[16:02] <\sh> jroes_: https://edge.launchpad.net/ubuntu/+source/lighttpd/
[16:03] <\sh> jroes_: https://launchpad.net/ubuntu/+source/lighttpd/
[16:03] <\sh> much betrter
[16:03] <\sh> jroes_: and if you need new crack for lighty ... just use 1.4.19 from hardy on a test system
[16:05] <jroes_> thankya \sh, you have been too helpful :)
[16:05] <hellboy195> dholbach: may you can help me with bug #201088 ?
[16:07] <\sh> jroes_: yeah...my mistake ;)
[16:07] <dholbach> hellboy195: it seem like it still needs update-inetd, no?
[16:07] <hellboy195> dholbach: it was introduced because installation failed on feisty. but on hardy it installs fine ,..
[16:08] <dholbach> but only if it's update-inted is installed, right?
[16:08] <hellboy195> dholbach: if you install ubuntu it will also be installed ^^ you do you mean if I remove it and then install ckermit?
[16:09] <dholbach> yep
[16:10] <hellboy195> dholbach: hmm damn it. :(  But a merge isn't really worth it now
[16:11] <dholbach> maybe we should just forward that change to debian, then sync it with intrepid?
[16:12] <hellboy195> dholbach: great idea. I never think about such a possibility -.-  thx
[16:12] <dholbach> :)
[16:12]  * dholbach hugs hellboy195
[16:12]  * hellboy195 hugs back and is asking why ^^
[16:12] <effie_jayx> hellboy195,  it's a motu custom
[16:13] <effie_jayx> you hug when fix a bug
[16:13] <hellboy195> effie_jayx: fix ,.. ^^
[16:13]  * hellboy195 contacts now debian folks :)
[16:17] <hellboy195> dholbach: time for another bug?
[16:19] <dholbach> hellboy195: shoot
[16:19] <LaserJock> sistpoty|work: ping
[16:20] <sistpoty|work> LaserJock: pong
[16:20] <hellboy195> dholbach: you perhaps no the python-xml removal thing. I try to do it with skencil. The problem and the solution is here: bug #81567
[16:20] <ubotu> Launchpad bug 81567 in skencil "skencil crashes on startup with a SIGSEGV in free()" [Medium,Confirmed] https://launchpad.net/bugs/81567
[16:20] <LaserJock> sistpoty|work: regarding gfortran, I've got 5 done in upstream
[16:20] <sistpoty|work> LaserJock: excellent, what do you recommend?
[16:20] <LaserJock> sistpoty|work: well, *I* didn't do the work, but debichem just uploaded the last of the set
[16:21] <LaserJock> sistpoty|work: let's tackle em' ;-)
[16:21] <sistpoty|work> LaserJock: ok, can you add that to the bug report please?
[16:21] <LaserJock> will do
[16:21] <sistpoty|work> thanks!
[16:22] <dholbach> hellboy195: hum... so you want to merge http://launchpadlibrarian.net/11839538/skencil.debdiff with a remove-python-xml change?
[16:22] <dholbach> hellboy195: best to suggest that on the bug report and get it into the sponsoring queue (and close the other bug with that upload too)
[16:23] <hellboy195> dholbach: k, thanks :)
[16:23] <dholbach> anytime
[16:48] <slytherin> What are these universe derivative CDs?
[16:50] <protonchris> Anyone willing to take a look at a FFE: https://bugs.launchpad.net/ubuntu/+source/glom/+bug/201385 ?
[16:50] <ubotu> Launchpad bug 201385 in glom "Hardy: Please update glom to latest version" [Undecided,New]
[17:04] <adorablepuppy> I've got a launchpad account, who do I ask to join the MOTU team?
[17:05] <jpatrick> adorablepuppy: https://wiki.ubuntu.com/MOTU/GettingStarted
[17:11] <adorablepuppy> jpatrick: Thanks. Already read the package guide and stuff, just didn't see the MOTU/Contact part.
[17:12] <jpatrick> adorablepuppy: you don't just join it, you have to work on packages and later join
[17:12] <slytherin> adorablepuppy: You can not just join MOTU team. You have to do some contribution first.
[17:14] <adorablepuppy> Understood.
[18:07]  * sistpoty|work heads home
[18:07] <sistpoty|work> cya
[18:07]  * \sh too ... not home but the next pub :)
[18:08] <hellboy195> \sh: hrhr, hf
[18:13] <POX_> "Remove build dependency on python-xml, useless since it depends on python-all-dev" - please don't do that, not all modules from python-xml are in python package; you have to check if app. is using these modules or not
[18:14] <POX_> removing python-xml without checking is not a fix!
[18:14] <slytherin> POX_: Who is doing it without checking?
[18:14] <POX_> Christophe Sauthier for example
[18:15] <POX_> see conduit or imgseek package
[18:17] <slytherin> POX_: did any of those package break?
[18:17] <POX_> don't know
[18:23] <POX_> conduit is using xml.dom.minidom and xmlrpclib only, so it's ok
[18:25] <slytherin> has anyone already tried building and using epiphany with webkit backend?
[18:26] <POX_> same with imgseek so false alarm, anyway, please test it instead "removing since package depends on python-all-dev"
[18:27] <slytherin> POX_: I think the bug description already has that note. If there isn't then please add it. :-)
[18:29] <POX_> is that so hard to add in changelog something like: ... and imgseek is using modules available in Python >= 2.4
[18:30] <POX_> this way I would know one tested it
[19:18] <LaserJock> ScottK: ping
[19:19] <ScottK2> LaserJock: Pong
[19:19] <LaserJock> ScottK2: do you want a FFe bug filed for psicode for the gfortran transition?
[19:20] <hellboy195> Would here anybody grant a FFe for monodevelop 1.0 final if debian would have it in the next 1-2 days?
[19:20] <LaserJock> I think it's fairly straightforward but I can file one if you think we should have the paper trail ;-)
[19:21] <ScottK2> LaserJock: I'd say not.  Reading the gfortran bug, sistpoty suggested a blanket FFe for the transition, and I said OK, so if you want to you can interpret that as being pre-approved.
[19:21] <ScottK2> hellboy195: The key question is bugfix or new features?
[19:22] <hellboy195> ScottK: both. ubuntu has beta2 ( beta3, RC, now final)
[19:22] <ScottK2> hellboy195: If there's new features between beta2 and final, then we need an FFe.
[19:23] <hellboy195> ScottK: Yeah I said Would here anybody grant a *FFe* for monodevelop 1.0 final
[19:24] <ScottK2> hellboy195: I'd have to read it first.
[19:24] <ScottK2> hellboy195: I'd say probably though
[19:24] <hellboy195> ^^
[19:24] <hellboy195> I love MD and I would take care for filing a FFe and providing the needed things ,..
[19:27] <hellboy195> DktrKranz: buona sera :)
[19:27] <DktrKranz> hey hellboy195
[19:39] <pochu> hey DktrKranz
[19:39] <pochu> DktrKranz: seen bluekuja recently?
[19:39] <DktrKranz> pochu, !
[19:39] <DktrKranz> pochu, via mobile, a couple of days ago
[19:40] <pochu> ah, hope he's fine
[19:40] <DktrKranz> he is, trust me :P
[19:40] <pochu> it's been a long time I don't see him, and I mailed him a few weeks ago and he didn't answer
[19:40] <pochu> nice :)
[19:40] <pochu> DktrKranz: so how are you doing? :)
[19:40] <DktrKranz> his girlfriend is draining resources :P
[19:51] <pochu> DktrKranz: heh
[19:57] <DktrKranz> MOTU meeting is in 5 minutes, any attendees?
[19:57] <ScottK2> There's still a dozen and a half packages that need touching for Bug #199014 if anyone is looking for easy work.
[19:57] <ubotu> Launchpad bug 199014 in emesene "python-xml removal: please drop/replace (build) dependencies" [Medium,In progress] https://launchpad.net/bugs/199014
[19:58] <ScottK2> DktrKranz: Thanks for the reminder
[19:58] <DktrKranz> you're welcome
[20:04] <LaserJock> hmm, I guess I'll be there
[20:33] <sistpoty> hi folks
[20:34] <siretart> hey sistpoty! :)
[20:34] <siretart> sistpoty: how are you?
[20:34] <sistpoty> hi siretart
[20:34] <sistpoty> siretart: I'm fine, thanks... how are you?
[20:34] <sistpoty> we got new boxes at uni this week, very, very cool :)
[20:34] <siretart> finally started my desktop computer, just dist-upgrading hardy :)
[20:35] <sistpoty> good luck ;)
[20:35] <siretart> sistpoty: the new frasch computers?
[20:35] <sistpoty> siretart: yes :)
[20:35] <siretart> quad-core with 8BG ram :)
[20:35] <siretart> yes, the specs read pretty nice
[20:35] <siretart> juk ordered 70 of them :)
[20:35] <sistpoty> yes, very fast (but debian/stable doesn't have graphics, so we installed ubuntu *g*)
[20:35] <sistpoty> heh
[20:38] <RainCT> hi
[20:38] <hellboy195> hio RainCT
[20:41] <jussi01> hi peoples, Ive uploaded a few bug fixes and subscribd UUS, just wondering what is the go with those now? can I poke to get them uploaded? does the beta freeze affect it?
[20:41] <jussi01> bug 201471 and bug 201480
[20:41] <ubotu> Launchpad bug 201471 in genpo "Genpo Missing Icon" [Undecided,New] https://launchpad.net/bugs/201471
[20:41] <ubotu> Launchpad bug 201480 in alsa-tools "Icon has no transparency/white background. " [Undecided,New] https://launchpad.net/bugs/201480
[20:42] <sistpoty> jussi01: motu meeting currently going on, maybe you'd like to join #ubuntu-meeting?
[20:42] <jussi01> sistpoty: ahh, didnt know, thanks
[20:42] <sistpoty> jussi01: others than that, yes, these can get uploaded, but need a manual shove through by an archive admin afterwards
[20:43] <jussi01> sistpoty: great, thanks
[20:45] <siretart> how can I mark a bug in http://daniel.holba.ch/really-fix-it/ as invalid patch? I found a patch that a) isn't a debdiff, b) against an older version and c) probably fixed upstream in a different way
[20:46] <siretart> LaserJock: btw, grats for DM-ship :)
[20:47] <LaserJock> siretart: danke
[20:47] <siretart> :)
[20:47] <geser> siretart: my guess would be to uncheck the patch checkbox for the attachment
[20:48] <siretart> geser: will try that then
[20:51] <geser> DktrKranz: looking at bglibs right now, do I need to add -fno-stack-protector for sparc and powerpc? the only way to test the build on those archs would be to upload and see
[20:52] <DktrKranz> geser, you can try on sparky (if bglibs is not heavy). I can test on ppc on a friend of mine
[20:53] <geser> bglibs is small, will try on sparky and hope that if it builds on sparc then also on powerpc
[20:54] <DktrKranz> it FTBFS the same way, so I guess it will build
[20:54] <DktrKranz> in the meantime, I'm testing the other packages
[21:06] <siretart> ajmitch: could you please join in #ubuntuwire? I'd like to find a home for you RC bug tracker
[21:13] <cody-somerville> Is anyone working on the ubuntu-universe-sponsors queue?
[21:13] <cody-somerville> I have 7 items in it
[21:13] <hellboy195> cody-somerville: I have > 10 ^^
[21:13] <cody-somerville> hellboy195, The pythom-xml stuff?
[21:13] <hellboy195> cody-somerville: no other ones
[21:13] <geser> I will try to look at the queue later, but can't promise
[21:14] <sistpoty> oh that reminds me of ghc6, cody-somerville ;)I
[21:14] <cody-somerville> sistpoty, :)
[21:14]  * geser needs to hug a reset button of a server first :(
[21:15] <cody-somerville> hellboy195, Clearly I need to catch up then
[21:15] <geser> sistpoty: another ghc6 transition?
[21:15] <sistpoty> geser: no, only a bug fix release, solving the split_obj problem
[21:16] <geser> good as we just finished the last one (at least I hope it's complete now)
[21:16] <sistpoty> geser: I've looked over the debian patch for the issue, it imho should be completely abi compatible (except for cases, which are borked from wrong object-splitting code anyways)
[21:16] <sistpoty> geser: but if you want to double-check, I'd welcome that ;)
[21:17] <geser> my haskell knowledge is not sufficient for this
[21:18] <sistpoty> geser: the object splitter is a perl script, producing/mangling assembly
[21:18] <hellboy195> cody-somerville: true :)
[21:18] <cody-somerville> hellboy195, Okay, that makes eight (8) :)
[21:18] <hellboy195> hrhr
[21:18] <sistpoty> (actually a collection of perl scripts for different architectures, only i386 being bitten by a bug)
[21:21] <cody-somerville> :)
[21:23] <cody-somerville> hellboy195, Okay. I'm a little too intoxicated now to do anything more safely :)
[21:24] <hellboy195> cody-somerville: Don't worry. I'm doing today/tomorrow a more *difficult* one. so you can reach my record ^^
[21:24] <cody-somerville> hellboy195, What are you doing?
[21:24] <hellboy195> cody-somerville: some kind of python-xml removal but with additional patching because of a seg fault
[21:25] <cody-somerville> hellboy195, fun :)
[21:25] <hellboy195> ^^
[21:25] <hellboy195> We'll see
[21:33] <Nafallo> hehe. just installed adblockplus, and it's not compatible with the current firefox :-P
[21:33] <Nafallo> though
[21:33] <Nafallo> dooh even
[21:38] <LaserJock> ScottK2: I'm assuming a separate sync bug is the way to go for packages in the gfortran transition, correct?
[21:39] <ScottK2> LaserJock: Probably.  It'd be confusing for the archive admins to get syncs against the main transition bug
[21:39] <sistpoty> LaserJock: that would be good, not to clutter up the huge transition bug, I guess
[21:39] <LaserJock> that's what I was thinking
[21:40] <sistpoty> LaserJock: though that needs manual closing of the bug's task in the FFe :/
[21:41] <LaserJock> sistpoty: I think that's an OK thing though
[21:41] <LaserJock> I'm not very fond of the "changelog closes bugs" feature anyway ;-)
[21:42] <sistpoty> heh
[21:42] <sistpoty> LaserJock: since vi has syntax highlighting for it, even I can do it :P
[21:43] <LaserJock> I always forget to add it to the changelog
[21:43] <RainCT> Nafallo: what do you mean by "current"?
[21:43] <RainCT> Nafallo: I tested it with 3.0, and it should work with 2 too
[21:44] <Nafallo> RainCT: the one in hardy.
[21:44] <RainCT> btw, REVU Coordinator election -> #ubuntu-meeting
[21:44] <Nafallo> RainCT: "Not compatible with Firefox 3.0b4"
[21:44] <Nafallo> :-)
[21:44] <RainCT> Nafallo: oh, might be. I've 3.0b3
[21:45] <Nafallo> I have to say I was surprised to have b4 :-P
[21:55] <slytherin> Anyone working on updating elisa?
[22:00] <cody-somerville> sistpoty, how goes it?
[22:02] <sistpoty> cody-somerville: the debdiff looks fine, I'm just test-building and about to review the debdiff between current ubuntu and new version
[22:02] <sistpoty> (to see changes in the splitter)
[22:05] <persia> cody-somerville: Good call on starfighter :)
[22:06] <cody-somerville> :)
[22:07] <slytherin> persia: got any bugs for me to work over weekend? :-)
[22:07] <sistpoty> cody-somerville: oh, undocumented changes: build-depends (gcc, versioned), and depends (version of gcc)
[22:09] <cody-somerville> sistpoty, I don't see that in the debdiff
[22:09] <persia> slytherin: I've not a prepared list.  really-fix-it, NBS, FTBFS, and RC merges would be my recommendations
[22:09] <slytherin> persia: I was trying an FTBFS of evolution-scalix. I am stuck
[22:10] <slytherin> apart from that, I am planning to update bluez-gnome and try elisa
[22:10] <sistpoty> cody-somerville: right, was looking at debian changes, sorry
[22:10] <cody-somerville> sistpoty, :)
[22:13] <sistpoty> cody-somerville: ok, all changes are fine, only needing to wait until my build finishes (I guess 1 hour or so), then I'll upload it. Thanks!
[22:14] <cody-somerville> sistpoty, It takes an hour to build for you?
[22:14] <sistpoty> cody-somerville: on my old box, it took 7-9 hours (6.6 though)
[22:14] <cody-somerville> oh wow
[22:15] <sistpoty> cody-somerville: from the last build on this box, I only remember that it was amazingly fast instead, compared to 7-9 hours *g*
[22:15] <cody-somerville> ghc6 is a long-ish build
[22:15] <sistpoty> cody-somerville: see the other bugs, how long a build took on spooky :(
[22:16] <Ssam`> i need a dummys guide to debian packaging
[22:17] <sistpoty> !packagingguide
[22:17] <ubotu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[22:17] <sistpoty> Ssam`: ^^
[22:18] <Ssam`> which ones the dummys guide?
[22:18] <Ssam`> i mean which would u recomend
[22:19] <slytherin> Ssam`: I suggest you start with fixing bugs in existing packages. You will learn more and faster.
[22:19] <sistpoty> Ssam`: the first link (it should hopefully contain links to lots of other good documentation as well)
[22:19] <Ssam`> one silly question......are all packages created the same or similar way?
[22:20] <Ssam`> like debian , rpm, tars?
[22:20] <Ssam`> will i learn them differntly?
[22:20] <poningru> Ssam`: essentially.. read the packaging guide
[22:20] <sistpoty> Ssam`: kind of... all packages are created from a (debian) source package, where debian/rules (a makefile), target binary is run to produce a deb
[22:21] <Ssam`> so u can learn debian packaging and rpms would be an auto or simpler?
[22:21] <Ssam`> ahh kewl
[22:21] <Ssam`> i ma read through packaging thanks
[22:21] <sistpoty> Ssam`: no, rpm is done differently
[22:21] <Ssam`> lol
[22:21] <sistpoty> (though I've forgotten the details)
[22:21] <Ssam`> u had to say that?
[22:21] <Ssam`> u couldent wait till i left
[22:21] <Ssam`> :P
[22:21] <civija> Ssam`: maybe this will be helpfull too https://wiki.ubuntu.com/UbuntuDeveloperWeek
[22:21] <sistpoty> heh
[22:22] <civija> read the packaging sessions
[22:22] <Ssam`> i will
[22:22] <Ssam`> i wanna learn all packaging
[22:22] <Ssam`> thanks mate
[22:31] <cody-somerville> 0o0... persia: Are you going to sponsor *hic* starfighter? :D
[22:31] <persia> cody-somerville: As soon as I get to sponsoring, if it is still there
[22:31] <cody-somerville> persia, Okay, thanks :)
[22:34] <Adri2000> ScottK, ScottK2: I see you uploaded mok0's wxwidgets2.6 debdiff for python-xml removal. but you didn't upload wxwidgets2.8. is it just because of lack of time or something, or is there anything wrong in it?
[22:39] <ScottK> Adri2000: Just lack of time
[22:42] <Adri2000> ScottK: okay
[22:57] <geser> DktrKranz2: just to let you know: the diet wrapper around gcc eats -fno-stack-protector when called as diet -Os gcc ...
[23:14] <RainCT> good night
[23:15]  * jdong is floored by ff3b4
[23:15] <jdong> to say that it's fast is a gross understatement.
[23:15]  * RAOF hates on intltool
[23:18] <RAOF> There's presumably some tool for populating po/POTFILES.in with all the files with translatable strings in them... but none of the intltool-* tools seem to do this, and google is silent on intltool documentation!
[23:22] <slytherin> I am facing very weird problem with FF, yelp, devhelp. Some fonts are so large that I can not read the page. Can anyone help debug this issue?
[23:22] <emgent> 1/join #ubuntu-it-chat
[23:22] <emgent> ups, sorry
[23:26] <Fujitsu> jdong: Compared to Fx3b3, or compared to Fx2?
[23:31] <slytherin> Please someone help me, it is making my browsing experience very bad. :-(
[23:33] <jdong> Fujitsu: compared to even Fx3b3
[23:33] <jdong> Fujitsu: it feels like fx2->fx3b3 all over again.
[23:33] <sistpoty> cody-somerville: ghc6 uploaded :)
[23:33] <jdong> webpages just simply seem to render instaneously
[23:33] <Fujitsu> jdong: Oh, nice.
[23:34] <jdong> so much so that I'm working on a backport already :D
[23:34] <Fujitsu> sistpoty: Thanks for the ack on the gfortran stuff, I'm working on uploading the bits I've prepared now.
[23:34] <pochu> slytherin: sounds like bug 178558
[23:34] <ubotu> Launchpad bug 178558 in xulrunner-1.9 "Firefox 3.0 makes everything annoyingly huge" [High,Fix committed] https://launchpad.net/bugs/178558
[23:34] <sistpoty> Fujitsu: excellent, thanks!
[23:35] <slytherin> pochu: Can read the bug. Even launchpad is borked. :-(
[23:35] <slytherin> s/Can/Can't
[23:35] <Fujitsu> sistpoty: One thing... petsc introduced a new build-dep on spooles, which is a new package that we don't have. Should I drop the build-dependency and configure flags?
[23:38] <sistpoty> Fujitsu: hm, not too sure... maybe bringing in spooles might also be an option. I couldn't say which I'd choose right now... I guess you should just decide on this
[23:38] <Fujitsu> sistpoty: I dropped the build-dependency for my PPA, but I'm not sure what to do in Ubuntu.
[23:39] <sistpoty> Fujitsu: maybe you could try to figure what spooles is needed for and make a decision based on this? If it's merely enabling a feature, I guess I'd drop the b-d
[23:39] <Fujitsu> It's just a feature, right.
[23:39] <Fujitsu> That's why I dropped it.
[23:56] <cody-somerville> :)


[13:44] <brobostigon> afternoonings everyone.
[17:08] <brobostigon> bye all, have a good evening.
[20:07] <brobostigon> evening everyone.


[00:00] <mwhudson> is there a way a snap can suppress the app awareness?
[00:09] <mwhudson> oh ignore-running: true
[00:32] <mup> PR snapcraft#3835 closed: Fix gnome extension g-ir-scanner PYTHONPATH <Created by diddledani> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3835>
[03:19] <mup> PR snapd#11963 closed: tests: make more robust the files check in preseed-core20 test <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11963>
[03:24] <mup> PR snapd#11849 closed: tests: enable centos-9 <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11849>
[07:59] <LetoThe2nd> howdy! just trying to look into UC, but can't get beyond snapcraft login. already following the troubleshooting according to https://snapcraft.io/docs/snapcraft-authentication, but gnome-keyring-daemon --unlock just silently blocks forever. any pointers? dev box is a headleass 22.04 on amd64
[09:51] <mncheckm> I want to override an environment variable of a snap application
[09:51] <mncheckm> without rebuilding it?
[11:41] <mardy> mncheckm: hi! I think you can use unsquashfs to unpack it, then modify the meta/snap.yaml file and repack it using "snap pack"
[13:44] <diddledani> mardy: mncheckm: while yes you can unsquash a snap and edit it before repacking it and installing it with --dangerous but that will kill automatic updating from the store when the developer updates there - if it's your own snap then I'd suggest to just rebuild it with snapcraft but you can do it with unsquash+edit+resquash
[14:01] <mncheckm> diddledani, thanks
[14:02] <mncheckm> so there is no way to pass environment variables into snap run?
[14:02] <mncheckm> or equivalent
[14:03] <diddledani> if the variable you want to set isn't overridden by the snap itself then it should pick it up from the host - e.g. via exporting it into a shell's environment first or using the `env` command to set it as part of the commandline
[15:12] <mup> PR snapd#11951 closed: tests: add executions for ubuntu 22.04 <Squash-merge> <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11951>
[15:17] <mup> PR snapd#11965 opened: tests: use overlayfs for interfaces-opengl-nvidia test <Created by mvo5> <https://github.com/snapcore/snapd/pull/11965>
[15:17] <mup> PR snapd#11966 opened: tests: update fake-netplan-apply test for 22.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/11966>
[18:43] <mup> PR snapcraft#3839 closed: elf: add elf file handler class <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3839>
[23:18] <mup> PR snapcraft#3840 opened: elf: add handling and patching helpers <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3840>


[05:33] <SpamapS> slangasek: note I just pinged you in #debian-devel, but I'll ask here in case you ignore that one
[05:33] <SpamapS> vorlon: Hey, say I was totally insane and wanted to have a Debian box that used upstart..
[05:33] <SpamapS> slangasek: Hey, say I was totally insane and wanted to have a Debian box that used upstart..
[05:33] <SpamapS> slangasek: specifically a VM... how might I get that upstart to be verbose and spray things to the console?
[18:00] <SpamapS> slangasek: have you experienced any issues with startpar and upstart on sid?
[18:01] <SpamapS> slangasek: for me, rc RUNLEVEL=2 never returns when using startpar
[19:29] <slangasek> SpamapS: not specifically, though certainly there have been scattered reports of broken init scripts preventing startpar from doing the right thing
[19:29] <SpamapS> What seems to happen..
[19:29] <SpamapS> is startpar never returns
[19:29] <SpamapS> so rc RUNLEVEL=2 never finishes.. and tty1 never starts
[19:30] <SpamapS> slangasek: I have a really minimal set of software installed
[19:30] <SpamapS> slangasek: anyway, I'm filing a bug against sysvinit-utils .. upstart seems to be doing the right thing.. /etc/init.d/rc or startpar seems more likely as the problem.
[19:34] <slangasek> SpamapS: ok, well, I can't reproduce that in a basic sid VM here
[19:38] <SpamapS> slangasek: I'm building the VM myself using debootstrap and diskimage-builder (OpenStack image builder)
[19:38] <SpamapS> slangasek: so perhaps we're missing a dep somewhere?
[19:38] <slangasek> SpamapS: I don't see how a missing dep would cause any upstart-specific problems
[19:39] <slangasek> SpamapS: have you turned up the debugging on startpar, to see where it gets stuck?
[19:39] <slangasek> er... or does startpar have any debugging
[19:40] <SpamapS> I don't know how to do that :(
[19:40] <SpamapS> yeah I don't see anything in the manpage
[19:41] <SpamapS> slangasek: I can work around it by just diverting startpar...
[19:41] <SpamapS> slangasek: I'm using upstart specifically because I want upstarty things to keep working.. don't care much about speed of /etc/rc2.d/* :)
[19:42] <slangasek> SpamapS: hah - so I just dist-upgraded my vm, pulling in new versions of udev and ifupdown, and the VM hasn't come back up
[19:42] <SpamapS> slangasek: could it be a bug in the cloud-init packages? I see that cloud-init ships /etc/init/cloud-config.conf _and_ I have /etc/rc2.d/S03cloud-config
[19:43] <slangasek> SpamapS: diverting startpar doesn't work, upstart relies on startpar integration to force skipping of init scripts that duplicate upstart jobs
[19:43] <SpamapS> slangasek: mine dies after cron says it started
[19:45] <SpamapS> slangasek: so it 'works' but not really :)
[19:45] <slangasek> SpamapS: it 'works' except that it doesn't work after I update, so something changed in sid recently
[19:46] <SpamapS> slangasek: ok so it is normal to have an S03cloud-config and /etc/init/cloud-config.conf ?
[19:46] <slangasek> SpamapS: yep
[19:50] <slangasek> SpamapS: ah, my boot failure is unrelated, EC2 console shows that the kernel config explodeded :P
[19:56] <SpamapS> slangasek: one other problem I'm having is that I"m not able to just add --verbose to kernel command line and get lots of init: stuff on console
[20:18] <SpamapS> slangasek: startpar appears to only have debugging printing stuff if you compile with -DDEBUG


[18:38] <R33D3M33R> hi, i'm searching for Ubuntu promotional material which we could use on our LoCo site: material which would convince people to install and use Ubuntu on daily basis.
[18:44] <R33D3M33R> something like it was done for 11.04
[18:44] <R33D3M33R> but updated