[00:01] <sistpoty> hi folks
[00:01] <geser> Hi sistpoty
[00:01] <sistpoty> hi geser
[00:02] <sistpoty> hm... ghc6 is building now for over 20 hours on spooky
[00:02] <hellboy195> hoi sistpoty
[00:02] <sistpoty> hi hellboy195
[00:02] <hellboy195> sistpoty: congratulation to the new *working* sensors release ;)
[00:02] <sistpoty> hellboy195: thanks... took me some time to figure that LDFLAGS were in the way to make it work *g+
[00:03] <hellboy195> sistpoty: ^^
[00:04] <emgent> heya
[00:05] <hellboy195> good night :)
[00:05] <sistpoty> gn8 hellboy195
[00:09] <geser> slangasek: thanks for the rebuild and http://members.ping.de/~mb/buildstatus_hardy/ has now a list without hppa (and a cronjob)
[00:12] <slangasek> geser: cheers
[00:51] <soto> How do I easily get apt to look in a particular directory for debs? Or any other way to install a deb whilst looking in a given directory for debs that provide needed dependencies.
[00:56] <persia> soto: There's no simple way.  Creating a local repository is likely easiest.  I used apt-ftparchive last time I did that, but dpkg-scanpackages or dpkg-scansources may do as well.
[00:57] <soto> persia: Can you tell me the directory structure I need and what files (Packages.gz, Release.gz, Contents.gz?)
[00:58] <persia> soto: I don't remember the structure exactly, but the docs for either apt-ftparchive or dpkg-scanpackages should help.  Both of those would generate Packages.gz, which is what you want.
[00:58]  * sistpoty uses mini-dinstall, but setting that up was quite some time ago
[01:00] <james_w> soto: http://blog.madism.org/index.php/2006/06 is quite an easy way to set this up for pbuilder if that is what you are doing.
[01:00] <nixternal> go into the directory where you local .deb files are, and run ->  dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
[01:00] <nixternal> then edit your sources.list and add ->   deb file:///where/ever/the/dir/is ./
[01:00] <nixternal> had to search my history for that one
[01:01] <soto> nixternal: Thanks
[01:01] <nixternal> james_w: thanks for that linke...I just got all of that through history, now I can bookmark it for the future :)
[01:01] <james_w> nixternal: no problem
[01:01] <geser> soto: if you want to use it inside a pbuilder make sure that the dir gets bind-mounted in your pbuilder
[01:02] <soto> geser, james_w  It's not for pbuilder
[01:04] <soto> Thanks though
[01:59] <ScottK> siretart: Yes it should, but I was on my phone and couldn't remember the proper LP email incantation for that.
[02:35] <Toadstool> heya everybody
[02:36] <sistpoty> hi Toadstool
[02:37] <Toadstool> hi sistpoty!
[02:37] <Toadstool> how's it going?
[02:37]  * sistpoty is plaing^W testing ufoai *g+
[02:38] <Toadstool> :)
[02:51] <macd> does anyone has sporatic problems with ppa rejecting uploads due to a key mismatch (although its obviously not) ?
[02:59] <sistpoty> macd: no... but I don't use PPA... maybe you could try asking on #launchpad?
[03:01] <macd> thats my next stop :)
[03:19] <sistpoty> oh... ufoai is sooo buggy... I lost yet anoher round *g*
[05:15] <YokoZar> DktrKranz2: Hey
[06:20] <slomo> superm1: any news for packaging gmyth-*
[06:20] <slomo> superm1: ? :)
[08:07] <proppy> oy
[08:59] <DktrKranz> YokoZar, ping
[09:07] <Iulian> Hi
[09:10] <YokoZar> DktrKranz: pong
[09:12] <DktrKranz> YokoZar, I've a solution for bug 185513. I thought it solved bug 191575 too (since I didn't notice any segfault after the build), but additional tests showed me I was wrong.
[09:12] <ubotu> Launchpad bug 185513 in wine "Wine packages overly large" [Low,Confirmed] https://launchpad.net/bugs/185513
[09:12] <ubotu> Launchpad bug 191575 in wine "wine segfaults on winecfg" [High,Confirmed] https://launchpad.net/bugs/191575
[09:13] <DktrKranz> have you a amd64 box to test it out?
[09:13] <YokoZar> DktrKranz: Yeah
[09:14] <DktrKranz> Good, I'll publish on my PPA since I've only a i386 builder here and point you to them once ready
[09:15] <DktrKranz> mh... PPA is bad... no pkg-create-dbgsym
[09:22] <YokoZar> DktrKranz: hmmm
[09:24] <DktrKranz> YokoZar, source package is here: http://packages.linuxdc.it/. Mind give it a build test in pbuilder with pkg-create-dbgsym installed?
[09:24] <DktrKranz> I'm doing it for i386
[09:25] <YokoZar> DktrKranz: Sure, but I need to go to sleep now.  Give me like 16 hours or so when I get back tomorrow.
[09:25] <DktrKranz> no worry
[11:04] <HighNo> hi everybody.
[11:05] <HighNo> Anyone around who could explain my package's depends line on me? :-) It's a python thinggy...
[11:17] <geser> HighNo: I could try
[11:33] <HighNo> geser: thanks. I was wondering why my package 'blueproximity' does have  a dependency on python-support (>=0.7.1) while it only has a build dep on it and only on version 0.5.3...
[11:33] <HighNo> geser: https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=3&queue_text=blueproximity
[11:36] <geser> HighNo: because it was build with python-support 0.7.5 which puts it into ${Depends:Python}
[11:51] <HighNo> geser: hm, so if backports-team will try to debuild it it will work out of the box?
[11:52] <geser> yes, as the python-support from the other versions will fill in the correct dependency for it
[11:53] <HighNo> cool
[11:53] <geser> unless you want to backport to dapper where the python-support is too old to satisfy your versioned build-dependency on python-support
[11:56] <HighNo> geser: yes, I know. For dapper the dependency must be fixed but feisty and gutsy won't need a single change - that should speed things up
[11:57] <HighNo> could someone please give me the backporting guide wiki please?
[11:58] <geser> https://help.ubuntu.com/community/UbuntuBackports
[11:58] <HighNo> thx
[12:01] <HighNo> geser: one more... where can I find Prevu?
[12:02] <jeromeg> HighNo: in the archive
[12:08] <HighNo> jeromeg: thx
[12:09] <jeromeg> HighNo: np
[12:10] <RainCT> Hey
[12:14] <jpatrick> RainCT: hey
[12:41] <torkel> root@mupp:~# lsb_release -c
[12:41] <torkel> Codename:	hardy
[12:59] <HighNo> if debhelper>=5 then echo 5 > debian/compat ?
[13:00] <Hobbsee> use 6
[13:00] <Hobbsee> we have debhelper 6 now
[13:00] <HighNo> even though it is a backport for feisty?
[13:00]  * persia notes that this doesn't help with backporting
[13:00] <Hobbsee> ah, right
[13:00] <Hobbsee> then 5
[13:00] <HighNo> ok
[13:00] <HighNo> is gutsy 5 or 6?
[13:01] <persia> 5
[13:01] <persia> (6 came during hardy, so even lots of hardy is 5)
[13:01] <HighNo> so 5 doesn't really hurt, it's just old?
[13:02] <persia> HighNo: Check the changelog.  6 introduces a few new features and behaviour changes that are not available under 5.
[13:03] <slicer> Someone should introduce a deb-traffic which highlights new changes to the packaging system. There's a lot of undocumented things in there which become black magic.
[13:05] <persia> slicer: Most of it is in the dpkg, debhelper, and CDBS changelogs.
[13:06] <slicer> Hm. Is there a service to subscribe to changelog changes? :)
[13:06] <persia> apt-listchangelogs?
[13:06] <persia> hardy-changes@l.u.c?
[13:06] <StevenK> Subscribe to hardy-changes? :-P
[13:06]  * StevenK high fives persia 
[13:07] <persia> There's also some RSS feed, but I don't remember the address.
[13:07]  * slicer goes to investigate :)
[13:07] <persia> Does LP have a changelog subscription feature in the style of packages.qa.debian.org?
[13:08] <Fujitsu> persia: No.
[13:08] <persia> Fujitsu: Thanks.
[13:08] <Adri2000> RSS feed for hardy-changes: http://media.ubuntu-nl.org/rss/hardy.xml
[13:08] <persia> slicer: If the options above don't meet your needs, please file a feature request to enable a changelog subscription feature in LP.
[13:08] <HighNo> when doing a backport, I have to add another changelog entry, right? If all I did was to change the deps - and of course the according files like debian/compat - what of all this should I enter at the changelog entry? and should I include the backport bug entry?
[13:10] <HighNo> I try to find that in the backports wiki but couldn't...
[13:10]  * RainCT doesn't understand the hurry to switch to compat level 6 if even level 4 isn't deprecated yet
[13:11]  * persia recommends selecting the minimum supported compat level that provides the desired feature set
[13:11] <pochu> RainCT: I think it is now with the introduction of 6 :)
[13:12] <RainCT> pochu: 'man debhelper'; it isn't, only 1, 2 and 3
[13:13] <emgent> heya
[13:13] <pochu> RainCT: right. then I can stick with v4 in aMule :)
[13:14] <persia> pochu: You may safely.  I suspect 4 will become deprecated in Debian right around the lenny release (as sooner is a lot of package bumps), so you are likely looking at a loss of support for intrepid+1 (depending on freeze cycles, etc.)
[13:14] <HighNo> hm, no backporter arround that could help me on my changelog entry?
[13:15] <persia> bddebian: I hate circular dependencies, and you should too :p
[13:16] <james_w> HighNo: if there is a backport bug then I expect that you include that yes.
[13:16] <james_w> HighNo: you should also explain everything that you did in order to do the backport.
[13:18] <HighNo> james_w: that's what the wiki says - but does that include every tiny change to files in debian/ dir or just the 'source' (or is the original debian/ also considered source here?)
[13:23] <james_w> HighNo: every change, so that someone looking back can easily see what changes were necessary.
[13:27] <Hobbsee> persia: how many acks are required for a uvfe?
[13:28] <pochu> persia: ffe? 2 for now
[13:29] <HighNo> james_w: hm, I'm puzzled. I did rebuild the new backported package with prevu which creates a nice new .deb file that installs perfectly on feisty. I changed the changelog and so on. I now should upload a debdiff, right? If I debdiff both binary packages, I only get differences in the control file ?!
[13:30] <RainCT> Is "old version only builds on i386 and new one should work on all" a good rationale for a FFe?
[13:30] <james_w> HighNo: you should debdiff the source package, not the binary.
[13:30] <geser> HighNo: debdiff the .dsc files
[13:30] <StevenK> RainCT: Depends if it's in Packages-arch-specific, and if it has FTBFS on the other arches
[13:30] <HighNo> hm, where does prevu generate them?
[13:31] <RainCT> StevenK: it was "architecture: i386", but had a RC bug in Debian because of this
[13:32] <StevenK> Which means it could be either, and needs you to check. :-)
[13:32] <RainCT> what do you mean?
[13:33] <geser> RainCT: which package is it?
[13:33] <StevenK> Okay, so check if the package is in Packages-arch-specific, or if just FTBFS on the other arches
[13:33] <RainCT> StevenK: it didn't FTBFS as it has "architecture: i386" (and not any) in debian/control
[13:33] <RainCT> s/has/had
[13:34] <RainCT> (well, has in Ubuntu and had in Debian :P)
[13:34] <StevenK> RainCT: It didn't FTBFS on i386. amd64 would have refused to build it
[13:34] <StevenK> If there are no amd64 builds at all, it's in Packages-arch-specific.
[13:34] <RainCT> geser: open-invaders
[13:34] <HighNo> geser: james_w: do you know where prevu creates the dsc file?
[13:36] <james_w> HighNo: don't know, try /var/cache/pbuilder/result, or somewhere else under there if it uses pbuilder.
[13:37] <geser> RainCT: is it already fixed in Debian? because http://packages.qa.debian.org/o/open-invaders.html still lists i386 only
[13:37] <RainCT> geser: it's in NEW because arch independent stuff has been moved into a -data package now
[13:38] <geser> ah
[13:38] <geser> RainCT: open-invaders isn't listed in P-a-s
[13:39] <james_w> HighNo: /var/cache/prevu/source/package/result/ by looking at the script.
[13:39] <geser> RainCT: so the buildds should pick it up with the new arch line
[13:39] <james_w> HighNo: actually not /package/ /some-pid/
[13:41] <HighNo> find /var/cache/prevu/ -iname \*.dsc  -> no files
[13:42] <geser> HighNo: I don't know prevu but you give it only the package name you want backported?
[13:45] <HighNo> geser: I had to change some files (in debian/ dir) so I got the source via apt-get source blueproximity and then changed into that directory, changed my files and did a 'prevu' call. That is what the wiki tells me to do. But all I get is the complete package built in /var/cache/prevu/feisty-debs
[13:46] <HighNo> it does not seem to use pbuilder as /var/cache/pbuilder/result/ only shows those packages I had built with pbuilder
[13:46] <geser> HighNo: try then to build a new source package with debuild -S
[13:47] <geser> you should then have the "old" and the "new" source package which you can debdiff
[13:47] <HighNo> geser - I'll try but then i will still have the problem when doing the backport for gutsy as I don't have it installed...
[13:47] <RainCT> hm.. has Ubuntu popcon stats?
[13:47] <StevenK> RainCT: Yup
[13:48] <geser> RainCT: http://popcon.ubuntu.com/
[13:48] <RainCT> thanks
[13:53] <RainCT> uh.. but those are for Dapper or what?
[13:54] <mok0_> RainCT: I was also disappointed when looking at popcon
[13:54] <mok0_> RainCT: there's nothing interesting there to see
[13:56]  * RainCT is not sure if he wants open-invaders in Hardy
[13:59] <HighNo> mok0_: there isn't ? one can see how often people install certain packages and how often (approx.) the are using it. What else do you want to see from a popcon?
[14:00] <mok0_> HighNo: I am just disappointed at the lack of a UI to browse the data. There's no meaningful statistics, all you can do it click and download the raw data
[14:01] <HighNo> mok0_: ok, that's a point
[14:01] <HighNo> mok0_: who's in charge? I guess building one is not that hard...
[14:02] <mok0_> HighNo: I'd expect to find info on the popularity of a certain package, how it develops in time, etc.
[14:02] <mok0_> HighNo: I don't know.
[14:03] <mok0_> HighNo: I guess you could wget all the data files and give it a go :-)
[14:03] <HighNo> mok0_: OK, the time frame seems to be a nice thing - therefore one is to have a database with timestamps.
[14:03] <mok0_> HighNo: ... and perhaps even geographical location? That would require access to the server logs of course
[14:03] <HighNo> mok0_: hehe - tried to find a person in charge for it - README and FAQ are 404's
[14:04] <mok0_> HighNo: yeah, popcon is in a sorry state... could do with some love and affection :-)
[14:05] <HighNo> mok0_: OK, another good point - looks like it should be possible though, as it states 'each day the server anonymizes and publishes' so the results on the serve rare not anonymized and could be useful for such things...
[14:06] <mok0_> HighNo: interesting
[14:07] <mok0_> HighNo: I wonder how you vote
[14:08] <RainCT> mok0_: you don't vote; it's explained below. vote means that the user uses the package regularly
[14:09] <HighNo> mok0_: funny thing - my package is in the 'raw popularity contest results' but in none of the other results as far as I can see it
[14:11] <HighNo> mok0_: hm, ok, it is in the 'all' list but not in one of the section lists...
[14:11] <mok0_> HighNo: Hmm
[14:12] <HighNo> RainCT: thanks for asking for these stats - I didn't even know they were online somewhere. It looks nice as one can have a litte more insight in how many people are actually using your stuff...
[14:13]  * mok0_ wonders how to interpret these numbers
[14:14] <mok0_> HighNo: blueproximity, right?
[14:14] <HighNo> mok0_: right
[14:15] <mok0_> 540 inst, 76 vote
[14:16] <HighNo> mok0_: I would say 540 people were interested and at least 76 really use it. 383 people are either not running it via session manager and therefore not regularly or they disabled atimes on they filesystems which could be some as it is probably used more on laptops than on desktops.
[14:16] <hellboy195> persia: still around?
[14:17] <mok0_> 383 old, 80 old ???
[14:17] <HighNo> mok0_: one could map that up to a userbase IF one knew how many users are using ubuntu totally...
[14:17] <mok0_> HighNo: You could normalize using one of the mandated packages
[14:17] <HighNo> mok0_:  80 is the number that made an update on it
[14:18] <mok0_> HighNo: that number is identical for a lot of the packages
[14:18] <HighNo> mok0_: that only gives a relation on how many are using it, not a total number as we don't know how many of the users are really voting.
[14:19] <mok0_> HighNo: true
[14:19] <mok0_> HighNo: we must know how many have install popcon
[14:20] <RainCT> in what order are the numbers in all-popcon-results.tar.gz?
[14:20] <HighNo> mok0_: hm, not really, as we can guess how many that would be from the topmost package. what we really need is the secret number: the total ubuntu user base
[14:21] <HighNo> RainCT: they have an order? :-
[14:21] <HighNo> )
[14:21] <RainCT> Package: gbrainy                          245   463   282     2
[14:22] <HighNo> RainCT: actually they are: use regularly, don't use regularly (both should sume up to the installed base), updated recently, no-files
[14:22] <RainCT> ok, thanks
[14:23]  * HighNo thinks of actually activating his popcon - statistics are interesting for maintainers
[14:25] <RainCT> Package: open-invaders  117   745    96     0              hm.. open-invaders has some more users in Ubuntu than in Debian (850 installs vs 30) :P
[14:26] <HighNo> RainCT: that could mean anything - like debian's popcon is much less demanding or inviting for users...
[14:27] <RainCT> HighNo: true, or just that people haven't used it because it isn't in testing
[14:27] <HighNo> RainCT: that's what I was discussing with mok0_ - you don't get absolute values unless you know how many users are there in total
[14:27] <HighNo> RainCT: that would still imply less users...
[14:28] <RainCT> HighNo: well, Debian's popcon page at least gives a %
[14:28] <HighNo> are there statistics for the update servers as with fedora?
[14:28] <HighNo> RainCT: % on what? people who use popcon or total install base?
[14:28] <RainCT> (above amount of users with popcon activate)
[14:29] <HighNo> RainCT: see - now the question is - since you know on how many people use popcon - you still don't use the ratio of total users/ popcon users
[14:29] <HighNo> RainCT: the update server stats could give at least a hint on that
[14:31] <RainCT> sabdfl said an aprox. amount of users some time ago.. I think it was 5 million or something like that
[14:31]  * RainCT is not sure though
[14:33] <RainCT> ok, from Wikipedia: "Mark Shuttleworth indicates that there were at least 8 million Ubuntu users at the end of 2006"
[14:36] <hellboy195> RainCT: that means now ~10 million? at least after hardy release :)
[14:37] <HighNo> RainCT: ok, so if you think about 10mio people using ubuntu and about 500000 entries in popcon you could multiply your results with 20 to get an absolute value with is very vague. (Due to the absence of exact number of users and popcon users not being statistically representative...)
[14:38] <HighNo> I guess they count all installed packages, not only official ones. (I think that because I found packages like blueproximity-kde and blueproximity-gtk which are not part of ubuntu)
[14:39] <proppy> oy
[14:42] <geser> Hi bddebian
[14:45] <bddebian> Heya geser
[14:46] <proppy> anyone @fosdem ?
[14:46] <lucas> yes, me, debian room
[14:46] <RainCT> how can I check if a package is in a certain distribution from the command line (ie, if it's in gutsy/hardy/etc.)?
[14:46] <proppy> lucas: accessibility talk ?
[14:47] <lucas> yup
[14:47] <jeromeg> RainCT: apt-cache madison package_name ?
[14:47] <jeromeg> RainCT: with the deb-src lines in your sources.list
[14:48] <proppy> lucas: @crossdesktop, hearing about GEGL, and about basic debian packaging soon
[14:48] <lucas> oh, they are late? I think deb packaging was earlier
[14:48] <emgent> bye people, later.
[14:48] <RainCT> jeromeg: ah, right. thanks :)
[14:48] <proppy> lucas: seems that they have switched the schedul
[14:48] <jeromeg> RainCT: np :)
[14:54] <geser> RainCT: rmadison from devscripts
[14:57] <Laney> When are uploaded packages actually rebuilt?
[14:58] <geser> Laney: what do you mean?
[14:59] <Laney> geser: I had a patch accepted a few days ago and launchpad still says "Not yet built" on my +packages page
[14:59] <Laney> s/a few/2
[14:59] <geser> Laney: which package is it?
[14:59] <Laney> geser: darcs
[15:00] <geser> Laney: https://edge.launchpad.net/ubuntu/hardy/+source/darcs/+builds
[15:00] <Laney> geser: Aha. I wonder why +packages doesn't show this..
[15:00] <bddebian> persia: New newpki-client patch sent to BTS...
[15:01] <geser> Laney: the +packages is not accurate when the package didn't build on one arch
[15:01] <Laney> Hm, ok
[15:01] <geser> Laney: I use always the page for the source package
[15:03] <Laney> geser: Right. What about in the official repos then? Does it have to build on all arches to get there?
[15:05] <geser> Laney: no, it gets published on the archs where it build (but ideally it should build on every arch)
[15:05] <Laney> geser: Oh, well it doesn't seem to have updated yet. I guess that takes a while longer?
[15:07] <geser> Laney: packages.ubuntu.com reports the last uploaded version for hardy
[15:08] <Laney> Oh, whoops. Must just be my mirror then
[15:08] <Laney> Sorry!
[15:08] <hellboy195> geser: well but it's not always up to date
[15:09] <geser> hellboy195: have you examples?
[15:09] <geser> Laney: you can also check if the files are on archive.ubuntu.com
[15:10] <hellboy195> geser: no, I mean in generel. It takes some time to update the entries.
[15:11] <geser> hellboy195: true
[15:15] <hellboy195> geser: have a second for me?
[15:15] <geser> it depends
[15:15] <hellboy195> geser: on?
[15:16] <geser> on what you want to know
[15:18] <hellboy195> geser: ^^, k. so I'm mergin wxwidgets and now I have a debdiff but I think it can delete the things under line 256. what do you think? http://pastebin.com/m6830e444
[15:20] <jpatrick> can someone remind what '101' means? As in 'Packaging 101'?
[15:21] <bobbo> jpatrick: i think its like a starter class/course
[15:21] <hellboy195> Packaging 101 is your entry point to the world of packaging.
[15:21] <HighNo> 101 are beginner classes
[15:21] <geser> hellboy195: yes, you can drop the translation changes if there are done on purpose
[15:21] <hellboy195> geser: k, thx :)
[15:21] <jpatrick> thanks guys
[15:21] <bobbo> Could a MOTU with some spare time check my fix for Bug #195068
[15:21] <ubotu> Launchpad bug 195068 in dx "[typo] in package description: Currently Exploror" [Undecided,In progress] https://launchpad.net/bugs/195068
[15:22] <hellboy195> geser: btw, I forgot you are german. nice ^^
[15:22] <geser> hellboy195: check lines 281-288 if it needs to be kept
[15:23] <hellboy195> geser: I suppose so because latest ubuntu deleted line and debian evidently not
[15:23] <geser> hellboy195: small note: I wouldn't undo the line wrapping in Build-Depends and simply add bc to the last line. This makes the diff a little bit smaller and also easier to check what exactly have changed in Build-Depends
[15:24] <hellboy195> geser: well, Debian did it so also grab-merge. but I'll do it :)
[15:24] <geser> hellboy195: argh, happens to often that I forget the 'not'
[15:25] <hellboy195> geser: ??
[15:26] <geser> hellboy195: "hellboy195: yes, you can drop the translation changes if there are done on purpose", there is a 'not' missing. It should be: ... if there are not done on purpose
[15:26] <hellboy195> geser: ah. didn't noticed that :)
[15:26] <geser> s/there/they/ too
[15:26] <hellboy195> geser: no stress ^^
[15:27] <hellboy195> geser: ah stupid question. adjust the build-deps in control file or is it enough to do it in the debdiff
[15:28] <afflux> it would break the debdiff if you'd do it there directly
[15:28] <hellboy195> afflux: :)
[15:28] <geser> hellboy195: if you know how to edit a diff that it doesn't break, you can do it there, but I guess in debian/control and regenerate the debdiff is easier
[15:29] <afflux> now my stupid question: is there a reason to merge after FF? Maybe the changelog should reference a LP bug
[15:29]  * geser should re-read what he types before hitting the Enter-key
[15:31] <geser> afflux: it's also a good idea to merge important bug fixes from Debian that aren't reported in LP yet
[15:31] <afflux> right. Didn't check them
[15:33] <geser> afflux: me neither, I hope hellboy195 checked before starting to work on the merge
[15:33] <hellboy195> geser: wxwidgets?
[15:33] <RainCT> persia: will you take care of bug #181494?
[15:33] <ubotu> Launchpad bug 181494 in xnetcardconfig "Depends on obsolete xsu package" [Undecided,In progress] https://launchpad.net/bugs/181494
[15:34] <geser> hellboy195: yes
[15:35] <geser> but also in general case
[15:35] <hellboy195> geser: well mostly I do merges because they are *worth* it
[15:35] <RainCT> bobbo: was the Maintainer already MOTU in dx?
[15:36] <bobbo> RainCT: ill just check
[15:37] <bobbo> RainCT: the maintainer (Daniel Kobras) doesnt use Launchpad (no account) so im guessing no
[15:40] <RainCT> bobbo: you have to set the MOTU Team as the maintainer and move the Debian Maintainer to a XSBC-Original-Maintainer field (running update-maintainer -from package ubuntu-dev-tools- in the source directory will do it automatically)
[15:40] <bobbo> RainCT: ok, thought you would ask me to do that :)
[15:42] <RainCT> bobbo: heh. Ping me when there's a new debdiff.
[15:42] <bobbo> RainCT: what should i add to the changelog for that change?
[15:43] <RainCT> bobbo: if you use update-maintainer it'll add an entry to the changelog automatically
[15:43] <RainCT> bobbo: if not: "Update Maintainer field to match the DebianMaintainerField specification." or something like that
[15:44] <james_w> bobbo: sorry, didn't refresh that page, so I have just submitted a debdiff for the same issue.
[15:45] <bobbo> RainCT: The debian standards is 3.6.2, should i bump it aswell?
[15:45] <james_w> bobbo: you also need to use a ubuntu version number to avoid the autosync overriding your changes.
[15:46] <bobbo> james_w: thanks :D, so thats ubuntu1 instead of build1?
[15:46] <RainCT> right
[15:47] <RainCT> bobbo: about the standards version, do what you want. I'm happy with bumping it but other sponsors might not be.
[15:50] <jpatrick> RainCT: you should always keep SV up-to-date
[15:51] <RainCT> jpatrick: I said I'm happy with it, but I found sponsors who didn't like such changes
[15:51] <jpatrick> RainCT: :/
[15:51] <RainCT> as in, unecessary diff to Debian
[15:51] <bobbo> RainCT: thats the new debdiff up
[15:52] <geser> RainCT: xnetcardconfig was never in Debian, so there is no unnessary diff to Debian
[15:52] <jpatrick> RainCT: Debian should update to then (file bug) :)
[15:52] <geser> I guess the package could use a overhaul
[15:53] <geser> xnetcardconfig was uploaded in Dec 2005 and never touched since then
[15:54] <RainCT> geser: xnetcardconfig?
[15:54] <geser> are we talking about an other package?
[15:55] <RainCT> geser: ah. I ment bobbo's bug now :)
[15:55] <emgent> heya people :)
[15:55] <RainCT> bug #195068 in dx
[15:55] <ubotu> Launchpad bug 195068 in dx "[typo] in package description: Currently Exploror" [Undecided,In progress] https://launchpad.net/bugs/195068
[15:56] <geser> ah
[15:57] <RainCT> argh.. I always use dget when I want to download a debdiff -.-
[15:57]  * RainCT is thinking about creating a function that chooses between wget and dget depending on the extension and aliasing both to it :P
[15:58] <geser> RainCT: does dget work on a debdiff?
[15:58] <geser> RainCT: doesn't dget work on a debdiff?
[15:59] <RainCT> oh, it works :P
[15:59]  * RainCT blames Ctrl+C :P
[15:59] <RainCT> thanks geser
[16:03] <RainCT> bobbo: you could also add a Homepage field
[16:04] <RainCT> http://www.opendx.org
[16:06] <bobbo> RainCT: building now :D
[16:08] <RainCT> >>> v = subprocess.Popen('apt-cache show firefox-3.0 | grep -m 1 ^Depends', shell=True, stdout=subprocess.PIPE).stdout.read()
[16:08] <RainCT> E: Handler silently failed
[16:08] <RainCT> anyone has an idea on why this sometimes fails (Python)?
[16:09] <bobbo> RainCT: new debdiff: http://launchpadlibrarian.net/12173715/dx_4.4.0-3ubuntu1.debdiff
[16:09] <pochu> RainCT: no idea, but you can use the python apt module to do that, can't you?
[16:09] <RainCT> pochu: do you know if there are examples somewhere?
[16:09] <pochu> RainCT: sec
[16:10] <pochu> RainCT: there are at /usr/share/doc/python-apt
[16:11] <pochu> RainCT: >>> c = apt.Cache()
[16:11] <pochu> >>> c.__getitem__('firefox-3.0').candidateDependencies
[16:13] <RainCT> apt.Cache() is slow :/
[16:14] <RainCT> well, thanks pochu
[16:15]  * RainCT will look at it once he finishes exams
[16:20] <james_w> bobbo: if you bump standards version it is preferred to say what changed, and if nothing then "No changes required".
[16:21] <james_w> bobbo: could you also forward the homepage change to Debian please?
[16:22] <bobbo> james_w: how would i go about forwarding to debian? Only ever worked on a few small Ubuntu bugs so far
[16:23] <james_w> bobbo: you can either use submittodebian in ubuntu-dev-tools (though I think that may fail here due to a bug I need to fix there).
[16:24] <james_w> bobbo: or you can use reportbug -B Debian and attach the patch.
[16:24] <james_w> bobbo: or you can just compose a mail to submit@bugs.debian.org and include some headers.
[16:24] <bobbo> james_w: ok thanks
[16:25] <james_w> bobbo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467301 shows you what I did for the typo change.
[16:25] <ubotu> Debian bug 467301 in libdx4 "libdx4: Typo in short desription" [Minor,Open]
[16:25] <james_w> You might find that a simple diff has the maintainer change and homepage addition in the same hunk, so you might have to do a little more to get a clean patch.
[16:26] <james_w> or you could omit the patch, and just ask them to add a header, and point to the page.
[16:26] <james_w> if you do that omit the patch tag and the ubuntu-patch usertag.
[16:26]  * RainCT doesn't think it's necessary to forward the patch, just reporting the issue is enough
[16:28] <bobbo> james_w, RainCT will just report, pretty new to Ubuntu/Debian
[16:30] <bobbo> RainCT: is my debdiff going to be uploaded?
[16:30] <james_w> yeah, for something like this just reporting it is enough, as if you add a patch they will probably still just do it by hand.
[16:30] <RainCT> bobbo: I'm uploading it :)
[16:30] <james_w> I like to include patches most of the time, just for the image of it.
[16:34] <Ahmuck> hi, is there a way to get projectm included in *buntu hardy
[16:34] <jdong> Ahmuck: currently, no, we are under feature freeze and new packages are no longer accepted
[16:34] <Ahmuck> :-(
[16:35] <Ahmuck> is there someone that might be willing to create a *buntu-deb for it?
[16:35] <RainCT> E: dx source: build-depends-on-obsolete-package build-depends: xlibs-dev
[16:35] <RainCT> will this fail to build?
[16:36] <jdong> RainCT: yes, at least on my gutsy system it does
[16:36] <jdong> E: Package xlibs-dev has no installation candidate
[16:37] <geser> in hardy too
[16:37] <RainCT> do you know what package replaces it?
[16:37] <geser> RainCT: it got split in several packages
[16:37] <xhaker> hey guys. i'm having some problems i had never run into. dput hangs uploading at the last kb
[16:38] <james_w> RainCT: there's a new upload of dx in Debian
[16:39] <james_w> RainCT: it fixes the xlibs-dev dependency, and also the typo.
[16:45] <james_w> RainCT: want me to prepare a debdiff that backports the stuff from the new upload to the current hardy upstream?
[16:45] <james_w> or would a sync be better?
[16:47] <highvoltage> nixternal: heh, I might as well talk to you here
[16:47] <highvoltage> (less noise on twitter)
[16:47] <bobbo> james_w: has #195068 been fixed in Debian?
[16:48] <james_w> bobbo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=195068 ?
[16:48] <ubotu> Debian bug 195068 in uw-imapd-ssl "mutt-1.5.4i: imap in config file generates errors" [Normal,Open]
[16:49] <bobbo> Nah our Bug #195068 ;) dx, you submitted it to debian
[16:49] <ubotu> Launchpad bug 195068 in dx "[typo] in package description: Currently Exploror" [Wishlist,In progress] https://launchpad.net/bugs/195068
[16:49] <RainCT> hm, it won't fail to build
[16:49] <james_w> ah, sorry, yeah, it was fixed in the same upload.
[16:49] <jpatrick> bonjour Zic
[16:50] <RainCT> as xlibs-dev is an alternative dependency
[16:50] <james_w> bobbo: http://packages.qa.debian.org/d/dx/news/20080216T210206Z.html
[16:50] <james_w> bobbo: it doesn't add the homepage though by the look of it.
[16:51] <bobbo> james_w: Hardy crashed when i was about to submit the bug to debian, its up there now though but they musnt have seen it before upload
[16:52] <james_w> bobbo: the upload was about a week ago, so that's not surprising :). I should have looked a little harder before filing.
[16:52] <bobbo> james_w: ah! ok
[16:54]  * xhaker tries dput -P
[16:55] <RainCT> bobbo, james_w: hm.. So should I upload bobbo's changes, or will you request a sync and a feature freeze exception?
[16:56] <james_w> RainCT: I don't care enough to request an FFe. I also think the severity of the bug we started with doesn't warrant much effort on this package before release.
[16:57] <james_w> However, the other changes in the upload look like they may be worthwhile, but I don't really want to pick through them.
[16:57] <Ahmuck> nm, i see projectm is in the hardy repositiories
[16:57] <james_w> I'd be in favour of just letting them add the Homepage field, and then taking the autosync after hardy. However, bobbo may be interested in doing the work, I'm not sure.
[16:58] <bobbo> james_w, RainCT: I wouldnt have a clue how to do a sync and get an FFe
[16:59] <bobbo> i learnt how to do a debdiff about a month ago :)
[16:59] <james_w> bobbo: syncs are easy. FFe, not so, but we can help you to do it if you are interested.
[17:00] <james_w> Though just doing it for the learning experience may not be the best use of your time.
[17:01] <bobbo> it looks like RainCT's suggestion of uploading my debdiff then getting the Autosync for Ibex would be simpler and less time consuming for everyone
[17:01]  * RainCT thinks that it isn't a great idea to request a FFe *only* for packaging changes, as it might introduce new problems
[17:02] <bobbo> i dont really know, im brand new to all this stuff :s
[17:03] <RainCT> so, as you don't have any interest in the new version, bobbo: do you want to add some of the packaging changes from Debian or are you happy with the current debdiff?
[17:03] <bobbo> RainCT: do you mean create a new debdiff with some more changes from http://packages.qa.debian.org/d/dx/news/20080216T210206Z.html or something else?
[17:04] <RainCT> bobbo: exactly
[17:04]  * bobbo goes to check whats on that list
[17:05] <bobbo> RainCT: Yeah i could probably do most of the stuff on that, not so sure about the new upstream though, never done anything like that before
[17:05] <RainCT> bobbo: ignore the 4 first points
[17:05] <bobbo> Yeah i can definately give those a go
[17:06] <james_w> and the last one I expect.
[17:07] <bobbo> james_w: dont have a clue what the last one even means :)
[17:07] <RainCT> bobbo: cool, ping me when you have a new debdiff ready :)
[17:07] <RainCT> heh
[17:07]  * bobbo remembers how he though fixing that bug was going to be easy :)
[17:08] <james_w> RainCT: do you want to unsubscribe u-u-s while it is being worked on so that no-one else looks at it?
[17:08] <james_w> RainCT: sorry if you have already done this.
[17:09] <RainCT> Already done this :). Ah, and there's no need to re-subscribe later if I'm still around
[17:10] <bobbo> james_w, RainCT: Sorry, hardys moodswings made me miss the xlibs-dev conversation, can i just remove it?
[17:10] <james_w> RainCT: great. thanks.
[17:10] <RainCT> the first thing I do when I look at a debdiff is unsubscribing u-u-s :)
[17:10] <james_w> that's sensible.
[17:10] <RainCT> bobbo: yes, remove those
[17:11] <RainCT> (it's many times in the build depends)
[17:11]  * bobbo goes on a deletion spree
[17:12] <bobbo> libdx4-dev suggests xlibs-dev, remove those mentions too?
[17:12] <RainCT> eg, "libx11-dev | xlibs-dev, x-dev | xlibs-dev, libxt-dev | xlibs-dev" should become "libx11-dev, x-dev, libxt-dev"
[17:12] <RainCT> bobbo: yes
[17:22] <geser> has someone checked if the new dx is a bugfix-only release?
[17:29] <crimsun_> 4.4.4 vice 4.4.0?  It doesn't seem to be bugfix-only.
[17:30] <RainCT> geser: there have been 4 releases, and the last one says "important changes" or something like this iirc
[17:32] <crimsun_> geser: i.e., 10 fixes vice 7 feature additions
[17:33] <crimsun_> the diffstat is fairly reasonable IMO
[17:34] <bobbo> RainCT: New debdiff (if its still needed): http://launchpadlibrarian.net/12174141/dx_4.4.0-3ubuntu1.debdiff
[17:43] <RainCT> bobbo: have you tried building it?
[17:43] <RainCT> $(MAKE) prefix=`$(CURDIR)`/debian/tmp/usr/lib install
[17:43] <RainCT> I think this will fail
[17:43] <bobbo> ive only made a source build
[17:44]  * bobbo goes to make a binary build
[17:50]  * bobbo now fully understands the meaning of http://xkcd.com/303/
[17:52] <RainCT> rofl
[17:53] <toresbe> bobbo: I hung that up on the wall at work, with the headline "WHY WE REALLY SHOULD STOP USING PYTHON"
[17:54] <hellboy195> toresbe: and? success? ^^
[17:54] <bobbo> haha :D
[17:54] <toresbe> naw :(
[17:54] <pochu> bobbo: but before compiling check your pointers! http://xkcd.com/371/
[17:55] <Nafallo> tss
[17:55] <Nafallo> just get faster buildboxes ;-)
[17:55] <bobbo> gotta love xkcd
[17:56] <toresbe> my PDP-11 actually has an identifiable pin on the backplane which briefly goes high when the MMU sends a segfault error to the CPU.
[17:56] <toresbe> I have been playing with the thought of wiring that pin to a physical bell
[17:56] <toresbe> ./a.out
[17:56] <toresbe> *ding*
[17:57] <Nafallo> :-)
[17:58] <james_w> you get 1 point
[17:59] <RainCT> btw, someone wants to check ubuntu-dev-tools before I upload a new version?
[17:59] <james_w> RainCT: what are the changes?
[18:00] <RainCT> james_w: http://paste.ubuntu.com/4955/plain/
[18:01] <bobbo> RainCT: you are right, it does fai
[18:01] <bobbo> s/fai/fail
[18:02] <james_w> $(MAKE) prefix="$(CURDIR)/debian/tmp/usr/lib" install
[18:03] <james_w> is what you want if it is that line that is the problem.
[18:03]  * RainCT is reading the pbuilder-dist changes he wrote and is confused :P
[18:04] <bobbo> james_w: it fails with http://pastebin.ubuntu.com/4956/
[18:04]  * geser likes http://xkcd.com/386/
[18:05] <bobbo> geser: Its funny because its so true :)
[18:05] <james_w> bobbo: it looks like that may be the problem then.
[18:06] <bobbo> ok thanks
[18:06] <james_w> bobbo: the line RainCT quoted above, with backticks around $(CURDIR) will definitely break something.
[18:06] <RainCT> bobbo: indeed. remove the `'s around it and try if it build now pls
[18:06] <james_w> RainCT: it does need quotes though.
[18:07] <james_w> the failures caused by missing quotes there are rare, especially on buildds, but it is still a problem.
[18:07] <RainCT> james_w: *http://paste.ubuntu.com/4957/plain/
[18:07] <james_w> if the build dir has spaces in the path the make command gets mangled, and usually causes FTBFS, or worse.
[18:09] <james_w> RainCT: I can have a look for you, but I won't be able to test that thoroughly, as I don't know many of the tools.
[18:09] <james_w> I know pbuilder-dist, but full testing of that is tiresome.
[18:10] <james_w> hmm, "alias pbuilder=echo" might help.
[18:13] <bobbo> now it wont make clean, i think i have totally messed up debian/rules
[18:17]  * bobbo reverts rules changes
[18:27]  * HighNo wonders if anybody else feels described properly by this one: http://www.randsinrepose.com/archives/2007/11/11/the_nerd_handbook.html
[18:37] <pascal80> join #launchpad
[18:37] <LucidFox> Oh, I already love Transmission.
[18:37] <LucidFox> It's lightweight, HIG-friendly, and FAST.
[18:38] <jdong> LucidFox: yeah it's a beautiful client
[18:38] <jdong> LucidFox: and under the hood is nice too -- transmission-cli, transmission-daemon, transmission-remote
[18:38] <HighNo> LucidFox: I don't even know it - I guess I'll have to look for it...
[18:39] <hellboy195> LucidFox: true :)
[18:45] <RainCT> persia: wow, you were right. open-invaders-data has just been accepted in Debian :)
[18:46] <james_w> pochu: I think you may have misdirected your bzr-eclipse mails just now.
[18:48] <pochu> james_w: it wasn't sent to pkg-bazaar-maint, due to Thunderbird splitting that in two lines, if that's what you mean
[18:49] <james_w> pochu: no, I might be wrong but I think either you meant ITP rather than RFS, or it should have been -mentors rather than -devel.
[18:49] <james_w> pochu: are you a member of pkg-bazaar?
[18:50] <mok0_> python-storm should be upgraded for hardy, a large number of bugs were fixed in the latest release 0.12. Anyone on that?
[18:51] <crimsun_> mok0_: you could update bug 156100
[18:51] <ubotu> Launchpad bug 156100 in storm "Please package upstream version 0.11" [Undecided,New] https://launchpad.net/bugs/156100
[18:52]  * mok0_ looks
[18:52] <tsmithe> i've just patched mscore to default to using the fluid soundfont (which is now available in hardy universe via the fluid-soundfont package). now, my question is, and i've really already made up my mind in favour of the latter, do i depend on fluid-soundfont (it functions, albeit uselessly without it), or do i recommend it?
[18:52] <pochu> james_w: oh crap, it should have been RFP :)
[18:52] <tsmithe> if i recommend it, should i leave in the notification that's currently there regarding installation of soundfonts?
[18:52] <james_w> pochu: aha :)
[18:52] <mok0_> crimsun_: By "update" you mean changing the bug description?
[18:53] <crimsun_> mok0_: converting it into a FF exception request, but essentially, yes.
[18:53] <james_w> tsmithe: may someone install another soundfont from elsewhere and not want fluid?
[18:53] <bobbo> RainCT: How important are the debian/rules changes for bug #195068 (http://pastebin.ubuntu.com/4958/plain/)
[18:53] <ubotu> Launchpad bug 195068 in dx "[typo] in package description: Currently Exploror" [Wishlist,In progress] https://launchpad.net/bugs/195068
[18:54] <bobbo> RainCT: I cant get them to work properly
[18:54] <mok0_> crimsun_: ok, will do that, and attach the list of bug fixes from Canonical. It seems if we are critical of them not releasing their stuff, we should be on top of it when they _do_ make a release.
[18:54] <RainCT> bobbo: looking at debian/rules from Debian might help
[18:54] <crimsun_> mok0_: concur.
[18:54] <james_w> bobbo: the first only fails on arches that use sudo for root on the buildds, not fakeroot, which is only a couple of smaller arches on Debian I believe, so that shouldn't be an issue.
[18:55] <crimsun_> tsmithe: mscore's source is patched to depend on fluid-soundfont-foo?
[18:55] <tsmithe> that is a possibility, yes. however, i'm sure it applies to other situations, and i never know if we assume that the user only ever uses the repository, and that the rest of the world doesn't exist or if we understand that the rest of the world does. (if we take the latter view in the extreme, then it destroys the idea of a centralised repository: why include this, when they could get it from elsewhere)
[18:55] <james_w> bobbo: the make distclean change may lead to some problems no longer being hidden, but one more upload shouldn't harm too much there.
[18:55] <tsmithe> crimsun_, well, it is currently working to depend on a file that is not included. i have patched it to depend on fluid, but without either, it still loads and runs. in fact, i'm just building to test this.
[18:56] <bobbo> james_w: its the make distclean one im having the problems with at the moment
[18:56] <james_w> bobbo: the last one I'm not really sure about, but I *think* it will stop some compile errors, so if it compiles with it then all the better.
[18:56] <james_w> bobbo: would you like to pastebin the error?
[18:56] <mok0_> crimsun_: I am wary of changing the history of bugs.... isn't it better just to create a new one?
[18:57] <bobbo> james_w: im pretty sure i had that one working, the make distclean one i copied and pasted from Debian and is just going wrong all the time
[18:58] <bobbo> james_w: sorry deleted the terminal session (clever me) so i cant pastebin the error, im going to try rewriting the rules stuff from a fresh current copy
[18:58] <james_w> tsmithe: I don't think a dependency here is harmful, but now recommends are installed by default it's just a question of how likely it is.
[18:58] <crimsun_> tsmithe: if the source code is currently patched to depend directly on the existence of such a soundfont, then I would revert that change.  Recommending fluid-soundfont-foo seems fine, since removing it doesn't disable mscore.
[18:58] <james_w> bobbo: good luck :)
[18:58] <tsmithe> crimsun_, "depend" is not such a good work. it is coded to look for a soundfont, but if it cannot load one, then it just doesn't produce any sound.
[18:58] <crimsun_> mok0_: however you wish to proceed.
[18:59] <mok0_> crimsun_: good
[18:59] <tsmithe> james_w, i think i'll leave the notification and use recommends
[18:59] <james_w> mok0_: yours supercedes that request, so go ahead and change it
[19:00] <james_w> tsmithe: that's fair enough. One question, does the notification suggest that installing the fluid package is one solution?
[19:00] <tsmithe> yes
[19:00] <mok0_> james_w: but it's part of the documentation of past bugs (?)
[19:00] <tsmithe> (or at least, it will do)
[19:00] <james_w> mok0_: I wouldn't worry about it, the history is still there in the activity log of that bug.
[19:00] <james_w> tsmithe: great.
[19:00] <mok0_> james_w: ok, I'll try that, then
[19:20] <RainCT> bobbo: well, isn't that important if you don't get all the changes from Debian working
[19:21] <bobbo> RainCT: i have everything except the rules stuff going
[19:22] <bobbo> would it be good to get my debdiff with the changes so far (debian - rules) and file a bug on Launchpad for the other stuff?
[19:24] <RainCT> bobbo: Upload what you have and for the debian/rules stuff never mind it. Ubuntu hasn't strange buildd's/arch's like Debian
[19:24] <bobbo> RainCT: will do :D
[19:39] <cyberix> What should happen to "needs-packaging" bug once the package hits the repositories?
[19:39] <geser> if the package is in the archive set the bug to "Fix released"
[19:39] <mok0_> Who is "Valyander"?
[19:40] <mok0_> besides being subscribed to all bugs in Ubuntu...
[19:41] <cyberix> geser: Should I set the bug to be a bug in the package released?
[19:41] <geser> if you want
[19:42] <tsmithe> does anyone here know if ftp-masters@debian.org is the address i want when i want to reach the debian archive admins?
[19:43] <hellboy195> mok0_: thats a really good question https://edge.launchpad.net/~ken-paulsen
[19:43] <mok0_> hellboy195: a blank entry
[19:44] <hellboy195> mok0_: but why is he subscribed everywhere? LP test dummy?
[19:44] <mok0_> Perhaps he's a spambot
[19:44] <tsmithe> hmm. maybe it's ftp-master@debian.org...
[19:44] <mok0_> hellboy195: great way to harvest active email accounts
[19:45] <pochu> I thought subscribing to ubuntu bugmail was discouraged, and that subscribing to ubuntu-bugs@l.u.c should be done instead
[19:46] <hellboy195> mok0_: ^^
[19:48] <hellboy195> LP should be opensource :\
[19:51] <tsmithe> hellboy195, why? is your supermarket open source? at least you can get a recipe to make most of the stuff they sell, so in that sense the products are open source. just as they are on lp
[19:52] <hellboy195> tsmithe: true, but if it would be someone could fork it without spambots ^^
[19:53] <tsmithe> it's good they don't: the whole point of LP is that it is a singular instance, without competing forks.
[19:53] <tsmithe> otherwise it would negate its useful centralisation.
[19:54] <hellboy195> tsmithe: also true
[19:55] <mok0_> hellboy195: I agree, they should opensource it asap
[19:55] <emgent> heya people
[19:56] <bobbo> is RainCT still around?
[19:56] <tsmithe> mok0_, parts of it, that wouldn't decentralise it, are. like Storm
[19:56] <RainCT> bobbo: pong :)
[19:56] <bobbo> RainCT: hey, i got another debdiff for you to look at :) http://launchpadlibrarian.net/12174886/dx_4.4.0-3ubuntu1.debdiff
[19:56] <hellboy195> tsmithe: what if the opensource it and ubuntu folks accept it as platform for ubuntu. so there isn't a decentralising
[19:56] <mok0_> tsmithe: that's a minute part of it
[19:57] <tsmithe> mok0_, true. but hopefully it'll continue it like that
[19:57] <tsmithe> hellboy195, but it's most useful when other projects use it as a platform too.
[19:57] <mok0_> tsmithe: are you against open source?
[19:58] <tsmithe> no. but i understand their reasons for keeping it closed. open source is not necessarily, in every case, the best solution.
[19:58] <hellboy195> tsmithe: well. very few projects use that platform so this isn't an argument
[19:58] <mok0_> Canonical makes a business of open source, they should live as they preach
[19:58] <tsmithe> mok0_, they don't preach anything.
[19:58] <hellboy195> We should ask Richard Stallman ^^
[19:58] <mok0_> tsmithe: I disagree
[19:59] <tsmithe> ok. this is off-topic anyway.
[20:03] <ScottK> tsmithe: It's an important point.
[20:04] <ScottK> Persnally I've yet to hear an argument for not freeing it that makes sense.
[20:04] <ScottK> But it's sabfl's money to spend how he likes.
[20:04] <tsmithe> what doesn't make sense in not wanting extraneous instances?
[20:06] <ScottK> Why should they care?
[20:06] <ScottK> It's the data that matters for the integration work they want to do.
[20:06] <ScottK> Properly structured all multiple instances would do is relieve the burden on their servers
[20:07] <tsmithe> right, i agree with that totally. preference would go to open sourcing it, but also opening the protocols to access the singular instance's data
[20:07] <ScottK> There are plenty of people that believe using proprietary tools to develop FOSS is a bad and dangerous idea.
[20:07] <tsmithe> as they haven't done the latter, they can't do the former
[20:07] <ScottK> They've chosen not to do that latter.
[20:08] <ScottK> LP doesn't live in a sinlge box, so the protocols exist.
[20:08] <ScottK> sinlge/single
[20:08] <tsmithe> ScottK, right, and i really can't see any reason why they shouldn't. *that* is my qualm; not the current necessity that it is closed.
[20:08] <tsmithe> i feel this way about a number of web services
[20:09] <tsmithe> (and it is why i believe that open standards are more important than open sources, per se)
[20:09] <ScottK> Personally I'm more worried about the side effects of it being a proprietary effort than I am the code.
[20:09] <tsmithe> well, that too
[20:09] <ScottK> Currently it's a Canonical project that if you act nice they might be willing to let you test.
[20:10] <ScottK> As an example of the kind of abitrary and capricious behaviour this approach tends to engender, if you don't set a real name in your LP profile, they will kick you out of the beta testers group.
[20:11] <tsmithe> that, i agree, is totally ridiculous. but that's up to the team owners, not the developers.
[20:11] <ScottK> Changes don't get announce in advance, so users get blindsided
[20:11] <ScottK> tsmithe: The LP beta team owners are the developers
[20:11] <ScottK> Testers don't have a good idea what to test.
[20:11] <tsmithe> (ie; it could happen in any team, though, if open source, the project could be forked to bypass the difficulties)
[20:12] <tsmithe> ScottK, that's a side issue. it isn't necessarily the case, and the case (of separation) is portable across projects
[20:12] <ScottK> The difference IMO is that in closed proprietary development who you are tends to be important.  In open source what you accomplish tends to become important.
[20:12] <tsmithe> meritocracy vs aristocracy, i suppose
[20:12] <ScottK> So it just wouldn't even come up in a normal open source environment.
[20:12] <ScottK> Yes.
[20:13] <ScottK> That and by being proprietary they lose potential input.
[20:13] <ScottK> Personally, I'm unwilling to work on design of someone else's proprietary system as a volunteer.
[20:13] <ScottK> I'll file bugs and complain, but that's as far as it goes.
[20:13] <tsmithe> ScottK, may not in a normal open source environment, but i have heard of projects with weird criteria on what external patches to accept (that have not been forked)
[20:14] <tsmithe> ScottK, that's a stance i should adopt
[20:14] <ScottK> Sure and if it's painful enough then the project forks.
[20:15] <ScottK> Generally though open source projects welcome additional competent help.
[20:15] <tsmithe> true
[20:16] <ScottK> BTW, my maximum length LP should be free and we should care about it not being free as Ubuntu people is 4 hours, so don't think you're going to wear me out.
[20:18] <tsmithe> ScottK, but that's not my opinion! i think that, whilst the protocols are closed, i understand why they keep it closed. however, what i cannot fathom is /why/ those protocols are closed (and thus why they *should* not open it).
[20:18] <tsmithe> but, 4 hours?? christ.
[20:19] <ScottK> It was more about should Ubuntu people care if they use proprietary tools or not and should be just use whatever LP feeds us for tools and be happy or work on rolling our own.
[20:21] <hellboy195> ScottK: if they would care, they would use debian or something similiar
[20:21] <hellboy195> *similar
[20:22] <ScottK> hellboy195: Depends.  I care and I use Ubuntu because it's release cycle suits me better than Debian's.
[20:26] <hellboy195> ScottK: well but only if you don't want to use Sid
[20:27] <ScottK> Yes.  I like using releases and not just the latest collection of whatever someone happened to upload.
[20:29] <hellboy195> ScottK: you are the complete opposite to me ^^
[20:29] <ScottK> hellboy195: I use my computers for $WORK that keeps my family in food, clothing, and shelter.
[20:30] <hellboy195> ScottK: yeah that's something different
[20:30] <persia> Hobbsee: My memory says 2, but you've a say in the actual value, whereas I'm just guessing :)
[20:30] <persia> bddebian: Excellent.  Grabbing now...
[20:31] <ScottK> persia: It's 2.
[20:32] <hellboy195> persia: you already noticed my debdiff?
[20:33] <persia> hellboy195: Yes, although my build system can't build that package.
[20:33] <bddebian> Heya gang
[20:33] <hellboy195> persia: generelly or with my debdiff?
[20:33] <geser> Hi bddebian
[20:33] <persia> hellboy195: Generally.
[20:33] <bddebian> Hi geser
[20:34] <hellboy195> persia: /here it's building fine
[20:34] <persia> Hey bddebian.  Thanks for newpkt-client.  attal looks like an SDL problem to me, but I've not tracked it down specifically yet.
[20:34] <bddebian> persia: NP, did it apply this time?
[20:34]  * persia is about to try
[20:38] <persia> bddebian: I can't find it :(  bug modified 32 days ago.
[20:38] <RainCT> bobbo: sorry for the wait
[20:39] <RainCT> bobbo: you've tried if it build, right?
[20:39] <bobbo> RainCT: yeah i've tried a binary build and it worked
[20:39] <bddebian> Gah, wtf
[20:40] <RainCT> bobbo: -DEB_DX_FLAGS = -Wall -g -fsigned-char      +DEB_DX_FLAGS = -Wall -g -fsigned-char -fno-strict-aliasing          this isn't documented in the changelog
[20:40] <bobbo> it is, the no strict aliasing part
[20:40] <RainCT> bobbo: ah right
[20:40] <bddebian> Hmm, it's in my sent items..
[20:40] <RainCT> -.-
[20:40] <ScottK2> RainCT: Thanks for the ubuntu-dev-tools cleanup.
[20:41] <bobbo> RainCT: ( * debian/rules: Disable strict aliasing.)
[20:41] <jdong> ScottK2: hey you have a sec to sponsor something into main?
[20:41] <jdong> bug 191691, debdiff is attached
[20:41] <ubotu> Launchpad bug 191691 in xchat-gnome "To prevent dcc exploit, default port should be 8001 for irc.ubuntu.com" [Medium,Confirmed] https://launchpad.net/bugs/191691
[20:43]  * ScottK2 looks
[20:44] <persia> bddebian: It's bug number 460748, right?
[20:44] <RainCT> ScottK2: np, thanks for the reports
[20:44] <bddebian> persia: Yeah
[20:46] <persia> Hmm.  Something odd with SMTP then :(
[20:47] <macd> a backport from hardy that requires an update to libc6 form hardy also, most likely won't happen right?
[20:47] <ScottK2> jdong: Looking at Bug 97253 - If you change it, will it stay changed?
[20:47] <ubotu> Launchpad bug 97253 in xchat-gnome "xchat reconnects on the wrong port number" [Low,Confirmed] https://launchpad.net/bugs/97253
[20:47] <persia> macd: That's a safe bet.
[20:47] <bddebian> persia: What's your e-mail, I'll mail it to you
[20:47] <persia> bddebian: persia@u.c works
[20:47] <RainCT> bobbo: uploaded :)
[20:47] <bddebian> Ah, OK
[20:47] <ScottK2> macd: Guaranteed not to happen, although you might find it depends on a different version when built against the Gutsy toolchain.
[20:47] <bobbo> RainCT: thanks :D
[20:48] <macd> yeah, Im going to try and build it in a gutsy env, and see what happens, if it were to build successfully, then it wouldnt be a backport, what are the chances of that getting into gutsy?
[20:48] <macd> its in universe, the package in question is imagemagick
[20:48] <ScottK2> jdong: I think someone on the desktop team should upload that one.
[20:48] <xhaker> hey, my ppa just spit, Chroot problem, how can I rebuild?
[20:48] <pochu> geser: python-babel FTBFS fixed in Debian
[20:49] <ScottK2> xhaker: Ask PPA questions in #launchpad
[20:49] <geser> pochu: nice
[20:49] <ScottK2> pochu: Fixed with source changes of by a binary upload?
[20:49] <tsmithe> could someone upload the new revision of mscore, as in bug 195179, please?
[20:49] <ubotu> Launchpad bug 195179 in mscore "Please update mscore to 0.9.1d+dfsg-0ubuntu2 (debdiff attached)" [Undecided,New] https://launchpad.net/bugs/195179
[20:50] <ScottK2> tsmithe: FFe approved for that one?
[20:50] <geser> pochu: it was a missing build-dependency on python-setuptools?
[20:50] <tsmithe> ScottK2, it doesn't provide new features.
[20:50] <persia> hellboy195: Looking at the diff, it seems clean.  If nobody else gets to it in a while, I'll see about making a special build-environment that can handle a package of that size.
[20:50] <ScottK2> Ah.  OK
[20:50] <xhaker> ScottK2: it's not certainly something exclusive of ppa archives. but i understand it's easier for you if i just split to #launchpad
[20:51] <hellboy195> persia: no stress. It was weekend. there are still ~5 other merges/syncs from me in the sponsering queue ,.. :)
[20:53] <nhaines> I have a couple packaging questions if anyone here has time.
[20:53] <hellboy195> nhaines: just ask. somebody will answer
[20:54] <pochu> geser: looks like
[20:54] <pochu> ScottK2: adding python-setuptools to Build-Depends
[20:54] <nhaines> I'm working on packaging PyRoom for Ubuntu.  I'm about to just give up and write an install/uninstall script.  But I need to grasp packaging eventually.  :)  PyRoom is a simple, standalone Python application.
[20:55] <mok0_> ScottK: I filed a FFE  on python-storm without first creating the package, please take a look
[20:55] <pochu> ScottK2: with binary upload do you mean a binNMU?
[20:55] <nhaines> I have my orig.tar.gz, and to this I added an icon and a .desktop file, and renamed pyroom.py to pyroom
[20:55] <hellboy195> persia: btw, the debdiff was 84kb big ^^ I deleted the diff entries for the *.po files ,..
[20:56] <nhaines> When I try debbuild, among the errors I get are that executable bit to pyroom cannot be represented, file rename can't be represented, binary icon data can't be represented...
[20:56] <ScottK2> pochu: No.  There are times when a package that won't build on the buildd's gets uploaded to Debian and works because they upload one arch as binary.  This can mask problems.  Sounds like it's not applicable this case.
[20:57] <persia> hellboy195: That was the right choice.  We generally don't want to have different .po files (although there are a couple exceptions, but these should be noted in the previous changelog).
[20:57] <pochu> ScottK2: well, this is arch:all so the binary was uploaded with the first upload.
[20:57] <hellboy195> persia: thank geser. He adviced it to me though I also supposed that this is the right decision ^^
[20:58] <ScottK2> pochu: Which is exactly where builds locally, but won't build in the buildd problems show up.
[20:58] <ScottK2> mok0_: I need to run out.  I'll try and look later tonight.
[20:58] <mok0_> ScottK2: thx
[20:59] <persia> nhaines: You're being very ambitious in your changes.  For a file move, consider applying the move in the clean rule each time, or finding another way to work around it.  For the executable bit, try setting this in the install: rule.  For the icon, common practice is to uuencode, and uudecode during build: (remember to build-depend on sharutils)
[21:01] <nhaines> persia: I didn't consider adding a launcher and an icon to be very ambitious.  :)
[21:01] <nhaines> But that's the trouble: there is no build or clean rule or phase because the entire program is interpreted.
[21:02] <nhaines> uue/uudecode seems simple enough, though.
[21:03] <persia> nhaines: For the icon, you're really limited to svg, xpm, or uuencoding, although some people like using sng (but you need to build the .png in the build: rule).  For the launcher, you want the move and execution bits in the install rule, rather than in the source package.
[21:03] <bddebian> persia: Did you get that?
[21:04] <nhaines> persia: I already put the move in the rules file.  So I can as easily change the move line to rename the file.  chmod can happen then, I understand.
[21:06] <persia> bddebian: Yes, but I got all the same errors :(  Maybe I'm just not applying it correctly.  I have to go real soon now, but I'll try to dig it apart tonight.
[21:06] <bddebian> I sent _4.debdiff right?
[21:08] <hellboy195> persia: hf, and no stress with the wxwidgets merge ;)
[21:08] <persia> bddebian: newpki_wx26_4.debdiff is the file I tried to apply.
[21:08] <bddebian> Yeah, it applies fine for me, wtf
[21:09] <persia> bddebian: mkdir newpki-client; cd new-pkit-client; apt-get source newpki-client; cp /tmp/newpki_wx26_4.debdiff; patch -p0 < newpki_wx26_4.debdiff ?
[21:10] <persia> err.  s/diff; patch/diff .; patch/
[21:11] <bddebian> -p1 but yeah
[21:11] <persia> -p1?  That's likely it then...
[21:13] <persia> Nope.  Still gets lots of issues :(
[21:13] <bddebian> persia: Well I stuck it up on mentors if you want to try to diff it yourself.  http://mentors.debian.net/debian/pool/main/n/newpki-client/newpki-client_2.0.0+rc1-3.dsc
[21:13] <persia> bddebian: Assuming you have a working source, and it compiles for you, maybe you could just upload it?
[21:14] <bddebian> Well, I have "building" source. ;-)
[21:16] <persia> bddebian: That's better than the current source.  This is likely especially true as newpki-server didn't build on hardy last I checked.
[21:18] <bddebian> OK, I'll build it in a hardy pbuilder and if it works I'll upload
[21:18] <persia> Hurrah!
[21:18] <tsmithe> slomo_, are you there?
[21:32] <persia> bddebian: survex now building cleanly (bashisms), and uploaded.
[21:33] <bddebian> w00t
[21:34] <persia> What do you think, should we drop ctsim for hardy, or is there a solution (perhaps with 2.8) on the way?
[21:35] <bddebian> I think he wants to wait for 3.0 but I don't know for sure
[21:36] <persia> bddebian: Hmm..  OK.  I'll wait a couple weeks before asking for removal then, just in case.  I just want to ask to drop wx24 byy betafreeze.
[21:50] <bddebian> persia: Unless you want to build it with 2.8 ;-)
[21:52] <hellboy195> gn8 folks :)
[21:52] <nhaines> persia: It looks like your suggestions have helped me to sucessfully build pyroom package!
[21:53] <nhaines> persia: the next hurdle is to figure out how to push them to my PPA, but I really appreciate your help.
[22:00] <james_w> bobbo_afk: nice work on dx
[22:01] <RainCT> nhaines: https://help.launchpad.net/PPAQuickStart
[22:03] <bobbo_afk> james_w: thanks :D
[22:03] <bobbo_afk> james_w, RainCT: thanks for all the help with DX
[22:15] <nhaines> RainCT: Yes, I simply didn't understand any of it (because I didn't have a successfully built package before now).  I will know in a few seconds if the instructions help me or not.
[22:16] <neversfelde> Hello all. How can I force a package to go in universe?
[22:16] <RainCT> Hi neversfelde. What do you mean?
[22:17] <RainCT> nhaines: well, they are pretty straightforward, but ask if you have some problem
[22:18] <neversfelde> RainCT: I packaged something and now it is in ppa's main section, but it should be in universe, or not?
[22:19] <pochu> neversfelde: ppas override all packages to main. And that's a question for #launchpad anyway
[22:19] <neversfelde> pochu: thx, thought I have to add something special to debian/control
[22:21] <LaserJock> RainCT: ping
[22:21] <RainCT> LaserJock: pong
[22:21] <LaserJock> RainCT: I was just looking at the dx upload you just sponsored
[22:21] <LaserJock> seems like an aweful lot of diff
[22:22] <RainCT> LaserJock: most of it is taken from Debian, it can be synced in Intrepid
[22:22] <LaserJock> why not sync it now?
[22:22] <RainCT> (most of it means everything except the manpage)
[22:22] <RainCT> LaserJock: because there is a new upstream release in Debian, which would require a FFe
[22:23] <RainCT> (a new upstream release which is 4 releases later than that one in Ubuntu, and seems to have significant changes)
[22:23] <LaserJock> but would it be worth getting?
[22:24] <RainCT> *manpage=homepage
[22:24] <LaserJock> are there important changes?
[22:24] <RainCT> I don't know the application so I can really say
[22:24] <RainCT> *can't
[22:35] <RainCT> LaserJock: also, the "keep the diff to Debian small" topic is arguable :)
[22:35] <LaserJock> ummm, it really shouldn't be :-)
[22:36] <LaserJock> I would argue that that upload was totally unnecessary
[22:36] <RainCT> heh
[22:36] <LaserJock> a large diff has been created (and which we'll have to maintain) over a *typo*
[22:37] <RainCT> LaserJock: as I said above, the changes were taken from Debian, so the package can be synced in Intrepid
[22:37] <LaserJock> which somebody will have to spend time doing
[22:38] <LaserJock> and may not do right if there's "Ubuntu changes" that are different from Debian's
[22:38]  * RainCT plans to go through all the stuff he has uploaded once it's MoM time
[22:39] <LaserJock> excellent :-)
[22:40] <LaserJock> in the case of dx I doubt it's a big deal
[22:40] <LaserJock> but really the typo should have been reported to Debian (and still should of course) and that's it
[22:41] <bobbo_afk> LaserJock: the typo has been reported, along with the lack of a Homepage field
[22:41] <RainCT> LaserJock: it's fixed in Debian :)
[22:42] <RainCT> (the typo)
[22:42] <LaserJock> *sigh* :-)
[22:42] <LaserJock> then why did we duplicate all the work in Ubuntu?
[22:43] <RainCT> to close the bug in Hardy
[22:43] <RainCT> and I guess bobbo_afk gathered some experience on the way :)
[22:43]  * bobbo_afk apologizes for making extra work :)
[22:44] <bddebian> Jesus Christ, bad md5sums on newpki-client.  I give up on this fscking package
[22:44] <LaserJock> well, I'm not exactly sure the experience we want actually
[22:44] <LaserJock> bobbo_afk: no need to apologize, I'm glad you're wanting to help out, it's much appreciated
[22:44] <bobbo_afk> LaserJock: thanks
[22:46] <LaserJock> it's just that, IMO at least, "fixing" this bug means reporting it to Debian, no more
[22:46] <pochu> go bobbo_afk go! :)
[22:46] <pochu> bobbo_afk: now that it's fixed in Debian you can do a merge too ;)
[22:47] <slangasek> except in Debian, it's fixed in a new upstream version of the package, so FF
[22:47] <pochu> oh
[22:47] <pochu> slangasek: you make me feel sad :(
[22:48] <bobbo_afk> im just confused :D
[22:48] <slangasek> just by mentioning a new upstream version in Debian? :)
[22:48] <LaserJock> heh
[22:48] <LaserJock> FF shouldn't keep people from looking to see if we *should* sync though
[22:48] <RainCT> LaserJock: that's another topic :)
[22:49] <slangasek> pochu: would you be happier if I changed the subject instead to monodoc and bug #194536? :)
[22:49] <ScottK> So far about 90% of FFe get approved.
[22:51] <bobbo_afk> ScottK: in that case can someone look at Bug #195065 as i've been waiting ages to play Fungaloids ;)
[22:53] <RainCT> ubotu!! :P
[22:57] <bobbo_afk> heh, ive spent one day in this channel and someone's already sent me a mentorship offer :)
[22:58] <LaserJock> hehe
[22:58] <ScottK> bobbo_afk: If motu-release is subscribed, I'll get to it eventually.
[22:58] <ubotu> Launchpad bug 194536 in monodoc "FTBFS in latest archive rebuild test" [High,New] https://launchpad.net/bugs/194536
[22:58] <ubotu> Launchpad bug 195065 in ubuntu "Please sync ogre-plugins-cgprogrammanager from debian sid" [Undecided,New] https://launchpad.net/bugs/195065
[22:58] <ubotu> Sorry, I don't know anything about p - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[23:03]  * bobbo_afk goes to bed, school in morning. Thanks RainCT for his help today
[23:04] <RainCT> bobbo_afk: you're welcome, thanks for your patches :)
[23:04] <RainCT> good night
[23:05] <superm1> slomo_, ping :)
[23:05]  * RainCT goes to bed too
[23:07] <pochu> slangasek: sure :) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458698
[23:08] <ubotu> Debian bug 458698 in monodoc "monodoc: FTBFS: error CS0006: cannot find metadata file `ICSharpCode.SharpZipLib.dll'" [Serious,Fixed]
[23:08] <pochu> slangasek: you don't happen to be an archive admin, do you?
[23:08] <superm1> slomo_, well if you come back and i'm not here, i've got two uploads: http://mentors.debian.net/debian/pool/main/g/gmyth/ http://mentors.debian.net/debian/pool/main/g/gmyth-upnp/
[23:08] <slangasek> pochu: that's not the same bug.
[23:08] <pochu> slangasek: oh really? I thought it was
[23:08] <pochu> slangasek: I havent checked it though
[23:08] <slangasek> no, completely different
[23:08] <slangasek> and monodoc's autoconfage is crack
[23:09] <pochu> hmm, "no, command not found"
[23:09] <pochu> that's crack :)
[23:09] <slangasek> currently, I can't get a buildable package with dpkg-buildpackage because the upstream 'clean' target is removing a file that it can't regenerate in the build target
[23:09] <tbf> slangasek: guess they'll say "patches welcome", if you tell them
[23:09] <tbf> ;-)
[23:09] <slangasek> pochu: yes, that's a combination of a) /usr/bin/mcs isn't installed (missing build-dep), and b) configure.in looks at the wrong variable name so fails to notice it broke
[23:10] <slangasek> tbf: but then I would be thanked as a contributor to a C# package and I would never bear the shame... :)
[23:10] <slangasek> pochu: so, that part I actually already have a fix for
[23:10] <tbf> slangasek: good point.
[23:37] <alex_mayorga> hi, can anyone take a look at bug 195247 and let me know if I did anything wrong, please?
[23:37] <ubotu> Launchpad bug 195247 in wine "[needs-packaging] wine 0.9.56" [Undecided,New] https://launchpad.net/bugs/195247
[23:38] <pochu> hrm, wine is surely in the archive?
[23:38] <LaserJock> alex_mayorga: well, we already have wine
[23:39] <alex_mayorga> the current version segfaults
[23:39] <LaserJock> ok, well, you filed the wrong kind of bug there
[23:39] <pochu> alex_mayorga: that should be an update, and not a needs-packaging bug
[23:40] <alex_mayorga> :(
[23:40] <pochu> and I think it is known that it's segfaulting
[23:40] <LaserJock> a "needs-packaging" bug is for packages that are not already in Ubuntu
[23:40] <alex_mayorga> sorry
[23:40] <LaserJock> alex_mayorga: no problem
[23:40] <LaserJock> thanks for coming in and asking about it
[23:40] <alex_mayorga> can you guys pick it up from there?
[23:40] <alex_mayorga> how is one supposed to request an update then?
[23:41] <pochu> alex_mayorga: 191575
[23:42] <pochu> bug 191575
[23:42] <ubotu> Launchpad bug 191575 in wine "wine segfaults on winecfg" [High,Confirmed] https://launchpad.net/bugs/191575
[23:42] <LaserJock> alex_mayorga: is that the bug you're seeing ^^ ?
[23:44] <alex_mayorga> yes sr.
[23:44] <LaserJock> ok
[23:44] <LaserJock> then let's close your bug
[23:44] <pochu> slangasek: monodoc 1.2.6-1ubuntu1 FTBFS in my hardy pbuilder, whereas 1.2.6-3 builds. I'll request a sync.
[23:44] <alex_mayorga> ??
[23:45] <LaserJock> alex_mayorga: a bug already exists
[23:45] <LaserJock> we can close yours
[23:45] <alex_mayorga> oh! didn't see it under wine
[23:45] <alex_mayorga> thanks anyway
[23:46] <alex_mayorga> and sorry for the inconvenience
[23:46] <LaserJock> alex_mayorga: no problem
[23:49] <pochu> slangasek: err, it's a merge, not a sync :) I'll take care of it.