[00:25] <bdrung_> porthose: what are the tasks of a mentor?
[00:36] <porthose> bdrung, help new contributors to become familiar with ubuntu processes, answer questions, introduce and help new contributors to get involved with the community etc https://wiki.ubuntu.com/MOTU/Mentoring/Junior_Contributor :)
=== roaksoax_ is now known as roak
=== roak is now known as RoAkSoAx
[01:27] <RoAkSoAx> Can a security update be combined with bugfixes in the same upload?
[01:27] <bdrung_> RoAkSoAx: for which release?
[01:28] <RoAkSoAx> bdrung_, for karmic
[01:28] <bdrung_> RoAkSoAx: then yes
[01:29] <RoAkSoAx> bdrung_, if version is: 0.7.61-1ubuntu1, will it end up beign 0.7.61-1ubuntu1.1 or 0.7.61-1ubuntu2.1
[01:29] <bdrung_> 0.7.61-1ubuntu2
[01:30] <RoAkSoAx> bdrung_, If it's only a security fix it will end up being 0.7.61-1ubuntu1.1
[01:30] <ScottK> RoAkSoAx: Use regular revision numbers for Karmic even if it's a security fix
[01:31] <RoAkSoAx> ScottK, oh ok! I was following the doc from the security team
[01:31] <ScottK> RoAkSoAx: RE your earlier question, we do care about Sparc.  The thing about Sparc is it's up to the community to support it.
[01:31] <ScottK> RoAkSoAx: Yes, thats for post-release stuff.  For development release, you just do it normally.
[01:32] <bdrung_> ScottK: you are faster :)
[01:32] <RoAkSoAx> ScottK, oh ok, and this is actually a bug in packaging that I've just found few minutes ago while testing the package (and it seems this comes from debian)
[01:33] <ScottK> They aren't perfect either.
[01:37] <crimsun> jdstrand: would appreciate feedback on the fix for your sound issue
[01:53] <desrt> how do i control if debuild -S includes the orig.tar.gz in the .changes or not?
[01:53] <Hobbsee> -sa or -sd
[01:53] <ScottK> -sa includes it
[01:53] <desrt> nice.  thanks.
[01:54] <desrt> oh pain.
[01:55] <desrt> launchpad rejected my upload due to missing source tarball but now it refuses to take the new upload because i already did the old one
[01:55] <ScottK> rm the .upload file
[01:55] <desrt> ahah
[01:55] <desrt> that's not launchpad :p
[01:55] <desrt> thanks :)
[01:55] <ScottK> np
[01:56] <desrt> i love my magnet!
=== LucidFox is now known as Adam_Savage
=== Adam_Savage is now known as LucidFox
[04:47]  * LucidFox chuckles at the new ubuntu-motu mail
[04:51] <Hobbsee> that's a fail.
[06:17] <dholbach> #canonical-2009-09-17-07h16
[06:20] <dholbach> mruiz: so regarding the patch-system-but-direct-changes-in-diff warning
[06:20] <dholbach> mruiz: in some cases it might just be enough to run      patch -p1 -R < debian/patches/bla-something.patch
[06:20] <mruiz> dholbach, then some files were modified during the build
[06:21] <dholbach> mruiz: because the source is already patched AND the patch is going to get applied during the build
[06:21] <dholbach> the regular patch system (cdbs-simple-patchsys, dpatch, quilt, dbs) should take care of that
[06:22] <dholbach> mruiz: that should normally help out
[06:23] <mruiz> dholbach, but my patch only modified the Makefile and another files seem to be changed
[06:24] <dholbach> mruiz: probably automake is called during the build?
[06:25] <mruiz> my debian/rules file is the following: http://paste.debian.net/46738/
[06:26] <mruiz> and I'm using quilt
[06:27] <dholbach> can you run     zcat <...>.diff.gz | diffstat
[06:27] <dholbach> and see which files are modified?
[06:27] <mruiz> mruiz@karmic:~/bzr/stone$ zcat stone_2.3.e-1ubuntu1.diff.gz |diffstat
[06:28] <mruiz>  debian/README.source                           |    5
[06:28] <mruiz>  debian/changelog                               |   97 +++++++++++++
[06:28] <mruiz>  debian/compat                                  |    1
[06:28] <mruiz>  debian/control                                 |   20 ++
[06:28] <mruiz>  debian/copyright                               |   50 +++++++
[06:28] <mruiz>  debian/dirs                                    |    1
[06:28] <mruiz>  debian/docs                                    |    2
[06:28] <mruiz>  debian/patches/01_incomplete_type_pointer.diff |   13 +
[06:28] <mruiz>  debian/patches/series                          |    1
[06:28] <mruiz>  debian/postinst                                |   28 +++
[06:28] <mruiz>  debian/postrm                                  |   18 ++
[06:28] <mruiz>  debian/rules                                   |   72 ++++++++++
[06:28] <mruiz>  stone.1                                        |  178 +++++++++++++++++++++++++
[06:28] <mruiz>  stone.1.ja                                     |  178 +++++++++++++++++++++++++
[06:28] <mruiz>  14 files changed, 664 insertions(+)
[06:28] <dholbach> there you go
[06:28] <dholbach> it's the *.1.* files
[06:28] <dholbach> they seem to get added during the build
[06:28] <dholbach> or you added them
[06:29] <mruiz> I only modified debian/{changelog, README.source, control, rules, patches*}
[06:29] <dholbach> that's weird then
[06:30] <dholbach> stone.1* is what the lintian warning complains about
[06:30] <dholbach> maybe they were added to the .diff.gz by the debian maintainer already
[06:30] <zooko> ScottK-desktop: by the way, I was just reminded of another reason why Tahoe-LAFS is a cool Cloud thing.  It can serve as a backend for bzr.
[06:30] <dholbach> in that case, and if you're just fixing something small in Ubuntu, you probably don't need to fix this too
[06:30] <mruiz> mruiz@karmic:~/bzr/stone$ zcat stone_2.3.e-1.diff.gz |diffstat
[06:30] <mruiz>  debian/changelog |   83 +++++++++++++++++++++++++
[06:30] <mruiz>  debian/compat    |    1
[06:30] <mruiz>  debian/control   |   19 +++++
[06:30] <mruiz>  debian/copyright |   50 +++++++++++++++
[06:31] <mruiz>  debian/dirs      |    1
[06:31] <mruiz>  debian/docs      |    2
[06:31] <zooko> Someone just mentioned on #tahoe how they are happy storing their bzr repo in a Tahoe-LAFS grid.  :-)
[06:31] <mruiz>  debian/postinst  |   28 ++++++++
[06:31] <mruiz>  debian/postrm    |   18 +++++
[06:31] <mruiz>  debian/rules     |   70 +++++++++++++++++++++
[06:31] <mruiz>  stone.1          |  178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
[06:31] <mruiz>  stone.1.ja       |  178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
[06:31] <mruiz>  11 files changed, 628 insertions(+)
[06:31] <zooko> DVCS in the Cloud.  :-)
[06:31] <dholbach> mruiz: better not scroll the channel too much :)
[06:31] <zooko> Okay, I'm going too bed.
[06:31] <dholbach> zooko: good night
[06:31] <zooko> Oops, I'm obviously tooo tired to count the o's in my words.
[06:31] <zooko> :-)
[06:31] <zooko> Goodnight dholbach.
[06:34] <mruiz> dholbach, OK.
[06:39] <mruiz> dholbach, it seems that debian packaging includes the same changes by default :-)
[06:40] <dholbach> alright, then don't worry
[06:40] <dholbach> (only if you want to fix it and send the fix to Debian too)
[06:41] <mruiz> dholbach, sure!
[06:41] <dholbach> super
[06:57] <mruiz> bye all
[06:57] <dholbach> hang on
[06:57] <dholbach> regarding bug 430960
[06:57] <ubottu> Launchpad bug 430960 in hildon-desktop "FTBFS" [Undecided,Confirmed] https://launchpad.net/bugs/430960
[06:57] <dholbach> can you please follow https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines ?
[06:58] <dholbach> if you don't have the time now or just want to go to bed that's fine :)
[06:59] <kklimonda> any idea what is the right way of fixing bug 42293 or at least some documentation for language-pack builders?
[06:59] <ubottu> Launchpad bug 42293 in coreutils "coreutils.mo are dangling symlinks" [Low,Confirmed] https://launchpad.net/bugs/42293
[06:59] <dholbach> kklimonda: hang on
[06:59] <kklimonda> I want to get piuparts to work at last..
[06:59] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation
[07:00] <dholbach> and https://wiki.ubuntu.com/MeetingLogs/devweek0909/Translations
[07:00] <dholbach> that's all I have
[07:00] <dholbach> arnegoetje, dpm and pitti also are people you can talk to about it
[07:00] <kklimonda> ok, thanks - I'll dig into it and speak to them
[07:00] <mruiz> dholbach, I will use it for my future patches
[07:01] <dholbach> mruiz: ok, I'll update it in the hildon-desktop case myself then
[07:01] <mruiz> dholbach, thanks ... it too late here :-).
[07:01] <dholbach> alrightie
[07:02] <dholbach> sleep tight
[07:02] <mruiz> :D
[07:02] <mruiz> dholbach, bye!
[08:54] <slytherin> geser: there?
[09:04] <siretart> debfx: I see that you have already packaged 0.4.1 and are doing a great job on launchpad bugs in keepassx. would you like to co-maintain the package in debian?
[09:05] <siretart> debfx: if yes, and we could agree on a packaging branch in a VCS like bzr or git, I'd be happy to sponsor upload to debian for you!
[09:05] <siretart> debfx: about the new version, it seems the sf.net redirector for uscan is reporting 0.4.0 was up-to-date. not sure why, though...
[09:07] <slytherin> Are the previous uploaders of jack-audio-connection-kit present here?
[09:09] <siretart`> slytherin: I think I sponsored one of the last uploads to debian, if that helps
[09:11] <slytherin> siretart`: I am about to upload a no-change rebuild in Ubuntu. Fixes NBS of libffado
[09:11] <debfx> siretart: yeah sure, I would like to
[09:11] <siretart`> slytherin: sounds like a no-brainer. why do you ask?
[09:12] <siretart`> debfx: cool. would you like to continue my bzr branch on lp, or do you prefer git? or something else?
[09:12] <slytherin> siretart`: In case someone is going to upload a revision for any other reason, no point in uploading n-change rebuild.
[09:12] <siretart`> slytherin: oh, right. no I don't plan any update here
=== asac_ is now known as asac
[09:15] <debfx> siretart`: I'm more familiar with git, but I don't mind using the bzr branch
[09:16] <siretart`> debfx: I use both bzr-buildpackage and git-buildpackage and have packages maintained by both. I really don't mind either, but keepassx is currently maintained in bzr
[09:17] <debfx> siretart`: ok then I'll just continue the bzr branch
[09:18] <geser> slytherin: yes
[09:19] <slytherin> geser: regarding ooo-thumbnailer. Currently it produces thumbnails only for ODF files. Doesn't it work for MS Office formats?
[09:19] <geser> slytherin: sorry don't know, I only fixed a FTBFS
[09:20] <slytherin> Ok. I will check myself.
[09:23] <debfx> siretart`: I'm not sure about uscan either but i'll probably move away from sourceforge anyway
[09:24] <siretart`> debfx: ah ok. - sorry, I had a collegue in my office
[09:25] <siretart`> debfx: okay, in the case that you intend to continue my branch, may I suggest that you publish your updated branch on lp in ~keepassx (the keepassx developer team) and add me to that team?
[09:25] <siretart`> so we can work together on the branch
=== dholbach_ is now known as dholbach
[09:48] <debfx> siretart`: ok, I pushed the brnahc to ~keepassx and added you to the team
[09:49] <debfx> s/brnahc/branch/
[09:55] <siretart`> debfx: it seems you haven't updated the debian/* packaging yet. did you perhaps forget to push that revision?
[10:20] <sebner> huhu sistpoty|work :D
[10:20] <sistpoty|work> hi sebner
[10:25] <alourie|work> hello
[10:25] <alourie|work> dholbach: would it work here?
[10:25] <alourie|work> :-)
[10:25] <dholbach> yes
[10:26] <alourie|work> If I'm trying to split a package in 2. I've set 2 .install files. But second package finishes empty, and the original still contains the files
[10:26] <dholbach> is dh_install run some time during the build? did you specify both packages in debian/control?
[10:26] <alourie|work> yes on both questions
[10:27] <dholbach> are you sure the paths are correct in debian/*.install?
[10:27] <alourie|work> yes. There is a step in rules, that processes a list of files and copies them into the required directory. But this directory finished in original package, not new.
[10:28] <alourie|work> so I'm doing something wrong, I just can't catch it
[10:28] <Laney> you should export DH_VERBOSE=1 in your rules file to see what's going on in more dtail
[10:29] <slytherin> alourie|work: paste your rules file on pastebin
[10:32] <debfx> siretart`: I will push the packaging files in a minute, if you don't mind I would like to switch to dh 7
[10:33] <alourie|work> slytherin: http://pastebin.com/f2477aa40
[10:35] <slytherin> alourie|work: "There is a step in rules, that processes a list of files and copies them into the required directory. " I don't see any such step in rules file.
[10:35] <slytherin> alourie|work: And I would also like to see your .install files.
[10:38] <AnAnt> dholbach: Hello
[10:38] <dholbach> hiya AnAnt
[10:39] <dholbach> AnAnt: I have that email still sitting in my inbox (from the sl-modem bug)
[10:39] <dholbach> I didn't get around to answering
=== ogra_ is now known as ogra
[10:40] <AnAnt> dholbach: git-buildpackage was acked by 2 MOTUs
[10:40] <AnAnt> dholbach: he reminds me of my previous boss
[10:40] <dholbach> AnAnt: I'll take a look at git-buildpackaging in a sec again
[10:41] <alourie|work> slytherin: the for loop that takes .po files and transforms them into .mo files into other directory
[10:41] <slytherin> alourie|work: And what the names of the packages?
[10:42] <AnAnt> actually regarding sl-modem, this package has a number of problems
[10:42] <slytherin> and please paste your install files as well
[10:42] <alourie|work> slytherin: the original I left as wordpress, a new one is wordpress-l10n
[10:42] <AnAnt> I just got an email from an upstream maintainer from linmodems.org, saying that no one in Jaunty is able to use it even with ALSA driver
[10:43] <slytherin> alourie|work: .mo files should go into l10n package right?
[10:43] <AnAnt> and that the only person (from Brasil) who was able to get it working in Jaunty, actually used a kernel from Debian
[10:43] <dholbach> AnAnt: don't worry - nobody is blaming you in the slightest
[10:43] <dholbach> AnAnt: might be worth talking to dtchen (about alsa) and stuff
[10:43] <alourie|work> slytherin: yes, that's what I'm trying to do
[10:43] <dholbach> maybe to the #ubuntu-kernel folks to
[10:44] <slytherin> alourie|work: then shouldn't this line - msgfmt $$i -o debian/wordpress/usr/share/wordpress/wp-content/languages/$$OUT - be like this - msgfmt $$i -o debian/wordpress-l10n/usr/share/wordpress/wp-content/languages/$$OUT
[10:44] <AnAnt> I just layed my hands on a laptop with a smartlink modem here, but it uses Hardy, so I'll test with a jaunty live DVD
[10:44] <alourie|work> slytherin: oh god
[10:44] <alourie|work> I knew I'm missing something simple
[10:45] <alourie|work> thanks a lot :-)
[10:45] <AnAnt> the other problem of sl-modem (which I've mailed about months ago on ubuntu-devel ML) is that it is non-free, hence it cannot use class_dunnowhat functions to create dynamic device nodes
[10:46] <AnAnt> those functions can only be called by GPL modules
[10:46] <AnAnt> and sl-modem is BSD licensed
[10:46] <alourie|work> dholbach: it really helped, thanks to you too :-)
[10:46] <AnAnt> since Ubuntu is against static devices, that could be a problem
[10:46] <dholbach> no worries
[10:47] <dholbach> argh :/
[10:47] <dholbach> AnAnt: did you speak to keybuk about that?
[10:47] <dholbach> he might know what's to do
[10:47] <AnAnt> now a third issue,is that another maintainer (from linmodems) just emailed a couple of days ago saying that slmodem's modules don't seem to be working with 2.6.31 kernels
[10:47] <AnAnt> so that's 3 problems :)
[10:48] <AnAnt> dholbach: yeah I talked to him during jaunty cycle
[10:48] <AnAnt> dholbach: but we got no where
[10:48] <AnAnt> dholbach: Ubuntu is against static devices
[10:48] <AnAnt> dholbach: the only solution that I know (and I've done here on my laptop but didn't test yet) is probably illegal !
[10:48] <dholbach> is there a workaround of some sort?
[10:49] <AnAnt> dholbach: actually the previous maintainer did that to slmodem's USB module , he changed the license to Dual BSD/GPL
[10:49] <AnAnt> so I did the same to the AMR module
[10:49] <AnAnt> and enabled the class* functions (he disabled them with some patch)
[10:50] <AnAnt> so that compiles, but I'm not sure if it works or not
[10:50] <dholbach> hm
[10:50] <dholbach> that sounds like it should live in a testing ppa and we should do a broader call for testing
[10:51] <sistpoty|work> didrocks: for clutter-1.0, is gobject-introspection-repository required at version 0.6.3 or does 0.6.1-2 suffice? (because we don't have that on sparc yet, and there seems to be a dependency cycle :/)
[10:51] <AnAnt> there is something in my PPA I think
[10:53] <AnAnt> regarding legality/illegality , debian bug 354216 has a long discussion about the matter
[10:53] <ubottu> Debian bug 354216 in sl-modem-source "upstream license patched in debian package" [Unknown,Closed] http://bugs.debian.org/354216
[10:54] <AnAnt> brb
[11:15] <slytherin> Does anyone know any particular reason why libffado is not build for lpia anymore? https://edge.launchpad.net/ubuntu/karmic/+source/libffado/+builds
[11:16] <slytherin> hmm probably TheMuso knows
[11:23] <AnAnt> back
[11:31] <geser> slytherin: Architecture: i386 amd64 powerpc
[11:31] <slytherin> geser: I know, but at some point of time it was built for lpia. Also jack-audio-connection-kit has this build dependency - libffado-dev (>= 1.999) [amd64 i386 lpia powerpc]
[11:32] <slytherin> geser: It looks like change was lost between merges. Since Debian doesn't have lpia arch they removed it. And the package was simply synced from Debian.
[11:34] <geser> looking at the changes it went from arch: any -> i386 amd64 powerpc
[11:34] <geser> looks like it was forgotten to add lpia
[11:35] <slytherin> right
=== cjwatson_ is now known as cjwatson
=== dyfet` is now known as dyfet
[12:01] <TheMuso> geser, slytherin, I'd say thats what happened.
[12:10] <siretart`> debfx: no, dh7 sounds great!
[12:10] <slytherin> TheMuso: So what do you suggest? Should I add lpia to arch?
[12:21] <TheMuso> slytherin: Sure if you want to take care of it, go ahead.
[12:23] <slytherin> TheMuso: I was just trying to fix this NBS - http://people.canonical.com/~ubuntu-archive/NBS/libffado0 If we don't want libffado on lpia then those packages should be removed from lpia.
[12:29] <didrocks> sistpoty|work: IIRC, 0.6.3 is needed. Let me check this evening
[12:29] <sistpoty|work> didrocks: ok, thanks
[12:30] <sistpoty|work> didrocks: of course if you've got a better idea how to break the build-dep cycle for sparc ... ;)
=== ogra_ is now known as ogra
[12:33] <didrocks> sistpoty|work: 0.6.4 is needed in fact
[12:33] <didrocks> (on last clutter as a new release just happened)
[12:34] <sistpoty|work> hm...
[12:35] <loic-m> Would a kind archive admin have the time to sponsor a sync for a new program (Bug #430024)?
[12:35] <ubottu> Launchpad bug 430024 in ubuntu "[FFE] Please sync mupen64plus 1.5+dfsg1-4 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/430024
[12:36] <loic-m> (would fix a few bug request in LP ;) )
[12:36] <Laney> no need to ask, they will get to it
[12:37] <sistpoty|work> it will need to go through new, so the question should rather be if an archive admin would want to denew it ;)
[12:37] <loic-m> Laney: sistpoty asked me to check if an AA would be ok to new it before he ACKed it
[12:38] <loic-m> sistpoty|work: right, I shouldn't have said sponsor. I'll try to remember the denew word...
[12:38]  * sistpoty|work doesn't even know if denew is a word :P
[12:39] <sebner> sistpoty|work: ahahah! I used mupen64plus myself a long time :D
[12:42] <sebner> sistpoty|work: another chance to play mario kart/ ehh to test this application carefully before giving a ACK
[12:43] <sistpoty|work> sebner: heh
[12:43] <sistpoty|work> sebner: too bad, I already gave my +1 :P
[12:43] <sebner> sistpoty|work: there is no "MOTU or universe sponsors ACK" so it's a release ACK :P
[12:44] <sistpoty|work> :)
[12:55] <sebner> sistpoty|work: +1, I can't say no when it uses dh7 and quilt, even less when it's something to play *g*
[12:55] <sistpoty|work> haha
[12:58] <eni23> hello everyone. i've got a question: someone i know created a programm callled vsxu. it works fine with ubuntu but it's not packed. now i've created a deb. what i have to do to gei it in the repos?
[12:58] <sebner> !revu | eni23
[12:58] <ubottu> eni23: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[12:59] <sebner> eni23: we are in Feature Freeze for karmic now so it won't appear until the next ubuntu release
[13:00] <eni23> i see it, that's no problem. thanks, this "revu" is all i need!
[13:01] <sebner> :)
[13:02] <sebner> sistpoty|work: nexuiz seems to be pretty b0rken currently. Any ETA how long we can push it it?
=== ogra_ is now known as ogra
[13:24] <AnAnt> dholbach: I reported the first sl-modem problem on LP 431799
[13:24] <ubottu> Launchpad bug 431799 in sl-modem "sl-modem users cannot establish a connection using ALSA mode" [Undecided,New] https://launchpad.net/bugs/431799
[13:25] <AnAnt> regarding this bug ^ , since it has been reported to me by upstream (who said that several users reported this problem to him), and since I confirmed that this bug exists, should I set the status to Confirmed ?
[13:26] <dholbach> AnAnt: sounds good
[13:26] <dholbach> even though I don't know how I could help out with that! :)
[13:27] <AnAnt> dholbach: I think I should set it to Confirmed
[13:27] <dholbach> *nod*
[13:28] <AnAnt> done
[13:37] <quadrispro> any release manager around?
[13:37] <quadrispro> hi dholbach
[13:37] <dholbach> quadrispro: I'm not on the release team
[13:37] <dholbach> quadrispro: but hi! :)
[13:37] <quadrispro> dholbach: yeah, I know, I just wanted to tell you "hi"! :D
[13:37]  * dholbach hugs quadrispro
[13:38]  * quadrispro hugs dholbach, too
[13:38] <debfx> siretart`: how did you import new releases? something like bzr merge-upstream --version 0.4.1 ../keepassx-0.4.1.tar.gz ?
[13:49] <sistpoty|work> sebner: not too sure, let's see how long it'll take
[13:49] <siretart`> debfx: yes, when the branch has the correct tags, that's what I mostly do
[13:50] <siretart`> debfx: I used to do that by hand using 'bzr import' on some package, not sure if keepassx is one of them (I hope not)
[13:50] <sebner> sistpoty|work: we might see -data tomorrow but the rest takes more time as upstream b0rked the sources
[13:50] <siretart`> no, doesn't seem so
[13:50] <debfx> siretart`: that command is failing with an AssertionError
[13:51] <sistpoty|work> sebner: yeah, have heard about it
[13:52] <sebner> sistpoty|work: anyways, I'll keep track of it, just wanted to give an progress update
[13:53] <sistpoty|work> sebner: alrighty :)
[13:54] <siretart`> debfx: oh, that's a bug then :(
[13:55] <siretart`> need to run
[13:55] <debfx> siretart`: yeah it's failing even with a newly created branch
[13:56] <siretart`> debfx: perhaps james_w can help you with that? - anyway, I'll be back online this evening. cu!
[13:57] <debfx> siretart`: bye
[14:44] <quadrispro> DktrKranz: non uppare nulla
[14:50] <slytherin> TheMuso: I am not personally interested in taking care of 'libffado'. Is there anyone else who cares personally for this package?
[15:03] <bddebian> Heya gang
[15:04] <sistpoty|work> hi bddebian
[15:04] <bddebian> Heya sistpoty|work
[15:10] <ScottK> slytherin: I don't think so, we just need to work as a team to get the transition done (I've done some of that one already)
[15:12] <slytherin> ScottK: The problem is that the lpia got dropped form arch somewhere between the merges and syncs. And now we have a outdated libffado on lpia and a libjack0 that depends on it. So I was wondering if I should add lpia again to libffado.
[15:12] <ScottK> I would say yes.
[15:12] <ScottK> We need to get the old one out of the archive, so that's probably the best approach
[15:13] <slytherin> Ok. I will check if it still builds in lpia (with help of PPA) and then upload it.
[15:13] <sistpoty|work> ScottK: what do you think about mupen64plus (bug #430024)?
[15:13] <ubottu> Launchpad bug 430024 in ubuntu "[FFE] Please sync mupen64plus 1.5+dfsg1-4 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/430024
[15:13] <ScottK> I haven't had a chance to consider it.
[15:14] <sistpoty|work> k
[15:42] <slytherin> Our buildd have hardy running, right?
[16:16] <maxb> slytherin: I think it's "latest supported LTS". Apparently the powerpc ones are running Dapper
[16:17] <slytherin> maxb: I know about powerpc. There is a particular build failure which is seen only on buildd using old kernels. I am not sure how old. It succeeded on armel.
[16:55] <RainCT> kirkland: does your advocation on http://revu.ubuntuwire.com/p/tahoe-lafs also count for the last upload?
[16:55] <kirkland> RainCT: i haven't had a chance to look at the last upload
[16:56] <kirkland> RainCT: the one i did look at was good, though
[16:57] <RainCT> kirkland: OK, the changes look OK (other than the addition of a new entry in debian/changelog). I'll upload it then
[16:57] <kirkland> RainCT: thanks a bunch
[17:07] <RainCT> kirkland: uhm.. doesn't that FTB? http://paste.ubuntu.com/272937/ (the line after the commented out one)
[17:09] <kirkland> RainCT: yeah, that should be one <tab>
=== nxvl_ is now known as nxvl
[17:09] <kirkland> RainCT: make hates on whitespace incongruencies
[17:10] <RainCT> kirkland: ah yeah well, my point was more about the line not being commented out too, though ;)
[17:10] <RainCT> anyway, nevermind :P
[17:10] <RainCT> kirkland: Now that I remember, did you see my message in #ubuntu-devel about the postinst failure I got with byobu?
[17:12] <kirkland> RainCT: oh, no i haven't
[17:12] <kirkland> RainCT: where's this?
[17:13] <kirkland> RainCT: is there a bug?
[17:15] <RainCT> kirkland: Well, it's rather corner-case one but still would be good to be fixed. Basically, I had a user with which I used screen but then removed that user; after doing that the directory for it in /var/run/screen remained there and byobu chocked on that during installation, as it couldn't do the chmod
[17:16] <RainCT> so I'd say either check for the user's existance or make that chunk of code non-fatal
[17:16] <kirkland> RainCT: i'll just make sure that the dir is writable
[17:16] <kirkland> RainCT: nonfatal if not
[17:17] <kirkland> RainCT: all it's doing is trying to put the <F5> tag at the bottom of any running sessions
[17:17] <kirkland> RainCT: so that you know to refresh your profile
[17:17] <ejat> where should i check if the splash wont show up while booting ?
[17:22] <RainCT> Just found a problem with tahoe-lafs's debian/copyright, btw.
[17:23] <RainCT> (Unless I'm outdated on the current requriements. Stuff not in common-licenses/ must be copied into debian/copyright, and not in a separate file, right?)
[17:25] <sistpoty|work> RainCT: that's what 12.5 says
[17:25] <sistpoty|work> (policy)
[17:26] <RainCT> sistpoty|work: Right, just asking to be sure :)
[17:26] <RainCT> Thanks
[17:26] <sistpoty|work> np ;)
[17:27]  * sistpoty|work admits to needed to look it up again, as he only recalled that policy does say it somewhere
[17:32]  * sistpoty|work heads home... cya
[17:57] <debfx> siretart: keepassx 0.4.1-1 should be ready to be uploaded to debian
[17:58] <siretart> debfx: I'm currently building and testing it
[17:59] <siretart> oh, it talks german again to me :-)
[18:00] <sebner> siretart: german ftw! *g*
[19:21] <siretart> debfx: did you receive the ACCEPTED mail?
[20:02] <debfx> siretart: yeah got the mail
=== pochu_ is now known as pochu
[20:56] <bddebian> siretart: I just accepted rumor, it's back again already? :)
[21:03] <jdong> *strangles git*
[21:04] <jdong> grrrr pushing a repo over ssh to expose over plain http should NOT be this tough :-/
[21:09] <jdong> lol whoops, help if I name the post-update hook correctly
[21:09] <jdong> I retract that complaint about git ;-)
=== cprov is now known as cprov-afk
[21:17] <RoAkSoAx> ScottK, could you take a look to bug #430913 please? Thank you :)
[21:17] <ubottu> Launchpad bug 430913 in jaunty-backports "Please backport nginx 0.6.39 to Hardy, Intrepid, Jaunty" [Undecided,In progress] https://launchpad.net/bugs/430913
[21:17] <ScottK> Sure
[21:19] <ScottK> RoAkSoAx: Looks like a good start.  Now you need some test results (builds can be got from the PPA, but need installs/runs).  Alse, were these no change backports?  If not, we need a debdiff.  We don't need the diff.gz.
[21:22] <RoAkSoAx> ScottK, ok, I've installed everything and see if they wererunning, and they did. So I'll add a comment. and I'll put the debdiff them I took the package from jaunty, updated the upstream version, and created different entries for intrepid, and for jaunty
[21:22] <ScottK> Sounds good.
[21:23] <RoAkSoAx> ok then, I'll attach the debdiffs
[21:37] <RoAkSoAx> ScottK, done
[21:39] <ScottK> RoAkSoAx: Need the debdiff from karmic to what you want to backport, not from what's in hardy/intrepid/jaunty
[21:43] <RoAkSoAx> ScottK, in karmic we have nginx 0.7.61-1ubuntu1. What I did is take the jaunty package 0.6.35-0ubuntu1 and update it to 0.6.39-0ubuntu1, because that release is the one that contains the security fix on the nginx 0.6.x series. In karmic we have 0.7.x series and the fix is on 0.7.62. So, what would I need to do then?
[21:44] <ScottK> OK, let me think about that.
[21:59] <RoAk> ScottK, ok, just PM cause I have to go. Later
[22:21]  * warner makes changes to the tahoe package, as suggested on REVU
[22:22] <warner> for a new package, should I set urgency=low ? I think I copied that from something else originally.. not sure if it's appropriate or not
[22:44] <warner> ok, new tahoe package is up on REVU