=== itnet7 is now known as itnet7_meetup
=== itnet7_meetup is now known as itnet7|meetup
[02:43] <pucko-> can someone help me with this build error http://pastebin.com/d1421fbca ? It compiles fine with configure && make. and worked fine with debuild a minute ago. don't know what I've changed.
=== itnet7|meetup is now known as itnet7
[03:48] <tgm4883> I'd like some input on this subject. There is a configuration utility that among other things, allows the adding of additional third party repos. ATM, it currently adds the repo, refreshes, adds the repo key, refreshes again, then you can install codecs. Would it be possible to have the repo key included in the configuration utility which would cut down on one of the repo refreshes?
[03:49] <tgm4883> technically I know that is possible, I want to know if that would be allowed in Universe
[03:49] <RAOF> Is the configuration tool available in Universe?  What is it?
[03:54] <superm1> RAOF, he's referring to mythbuntu-control-centre.  one of the plugins has support to turn on medibuntu for the user, so it basically just does the same steps that the wiki currently advertises
[03:55] <RAOF> Ah, right.
[03:55] <superm1> so the thought is to just pack the gpg key in with the plugin so that step is skipped
[03:55] <RAOF> I don't, personally, see why including the repository key in the mythbuntu-control-centre package would be frowned upon.
[03:56] <superm1> it just feels like one of those gray areas
[03:56] <RAOF> You're already doing essentially that; it's no less secure to ship the key (and add it to the apt-keyring just before doing the update).
[03:57] <superm1> yeah, and it's all entirely opt in /optional anyway
[03:57] <RAOF> In fact, it's *more* secure - there's not the possibility of someone hijacking medibuntu, adding their own repository key, and then going to town with malware.
[03:58] <superm1> if only libdvdcss2 wasn't so useful for dvd playback :]
[04:07] <ScottK> As a rule we don't allow packages to download from external repositories.
[04:09] <superm1> ScottK, reference?
[04:10] <ScottK> We have a trust boundary that includes upstreams, Debian, and the Ubuntu archive.
[04:11] <ScottK> Medibuntu is outside of it.
[04:11] <superm1> you do realize that libdvdread4 includes something just like that though, /usr/share/doc/libdvdread4/install-css.sh
[04:11] <ScottK> I don't have a specific reference, but it's a pretty basic security principle.
[04:12] <ScottK> Right, so we have bugs.
[04:12] <ScottK> The first upload of Envy was almost removed from the archive because it downloaded drivers from a PPA.
[04:12] <ScottK> It got fixed to not do that, so it stayed.
[04:14] <ScottK> Bug #220385 for reference
[04:14] <ubottu> Launchpad bug 220385 in envyng-core "envy needs to pull drivers from multiverse, not PPA" [Medium,Fix released] https://launchpad.net/bugs/220385
[04:14] <ScottK> Note who filed it.
[04:16] <superm1> kees, could you weigh in on this then?
[04:24] <superm1> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=223961 provides some history on the tool for enabling css
[04:24] <ubottu> Debian bug 223961 in libdvdread3 "libdvdread3: makes download of possibly illegal libdvdcss too easy" [Critical,Fixed]
[04:26] <kamalmostafa> ScottK: Hi Scott.  Reminder - libtifiles/libticalcs still awaits your review.
[04:27] <ScottK> kamalmostafa: Yes.  It's still on my list.  For tonight or tomorrow depending on how long before I pass out and if any new work crisis arises.
[04:27] <ScottK> (still on the [hopefully] last work crisis of the day)
[04:28] <kamalmostafa> Very good - thanks.
=== v is now known as vorian
[06:12] <nigel_nb> maco, got a min? need a little hand with figuring out dependencies
[06:12] <maco> sure sure
[06:13] <nigel_nb> its lernid..its missing a dependency
[06:13] <maco> ooh shiny
[06:13] <nigel_nb> though not in packages yet, I want to branch and fix the bug I had in my system
[06:14] <nigel_nb> so, all I have to do it make the edit in debian/control?
[06:14] <maco> yep
[06:14] <maco> and of course add to the debian/changelog
[06:14] <nigel_nb> ah, yes
[06:15] <nigel_nb> that needs to be done even for bzr packages?
[06:16] <maco> yes
[06:17] <maco> you can add to the debian changelog and then debcommit and your bzr commit will include the debian changelog entry as the bzr commit log entry
[06:18] <nigel_nb> isn't there a command for that or should i do it manually?
[06:18] <maco> dch -i
[06:18] <maco> will give you a skeleton for your changelog
[06:19] <nigel_nb> jono has changelog modified only for version releases
[06:19] <nigel_nb> which makes me nervous whether to change it
[06:19] <maco> is that the Changelog or debian/changelog ?
[06:19] <nigel_nb> debian/changelog
[06:19] <maco> oh!~
[06:20] <maco> i see. you're working on the upstream bit, not on an in-ubuntu's-repos package?
[06:20] <nigel_nb> maco, um, lernid is still in PPA
[06:20] <maco> i havent been paying that close attention...it's gkt
[06:20] <maco> *gtk
[06:20] <maco> if you're just gonna do a merge request on the project, dont worry about debian/changelog
[06:20] <nigel_nb> ah
[06:20] <nigel_nb> whts gtk?
[06:21] <maco> just making a joke since its written with the same libraries as gnome, and i use kde ;)
[06:21] <nigel_nb> maco, boo!
[06:21] <nigel_nb> lernid works on kde too I think
[06:22] <nigel_nb> I'm on xfce and I had trouble getting it working, thats the dependency i'm fixing
[06:22] <maco> what was the missing dependency?
[06:22] <nigel_nb> back on topc, when doing bzr commit like that, I dont have to leave bug number and stuff right? LP takes care of it I believe
[06:22] <nigel_nb> telepathy-idle
[06:23] <maco> bzr commit --fixes ... i think?
[06:23] <maco> bzr commit -m "adding dependency in debian/control" --fixes 12345
[06:24] <nigel_nb> oh, thats pretty cool
[06:30] <nigel_nb> maco, thanks.  I pushed that branch :)
[06:31] <maco> i think you still have to go into launchpad and manually do the merge request though
[06:31] <nigel_nb> yeah, I do.  but thats familiar territory
[06:32]  * nigel_nb works with bzr for uclp
[06:32] <nigel_nb> but not the bug fixing part
[06:33] <nigel_nb> maco, LP shows the bug connection (which is cool)
[06:39] <nigel_nb> maco, is there a way to know for sure what packages get shipped in the Live CD without putting one in? I mean I want to compare package in ubuntu and xubuntu.
[06:39] <maco> the ubuntu-desktop and xubuntu-desktop meta-packages should tell you what varies
[06:40] <Flannel> nigel_nb: the .manifest files list the packages compiled into the casper image: http://releases.ubuntu.com/9.10/ubuntu-9.10-desktop-i386.manifest
[06:40] <nigel_nb> Flannel, thanks
[06:40] <nigel_nb> maco, um? a little longer explanation
[06:41] <nigel_nb> Flannel, is there somethin similar for xubuntu?
[06:42] <Flannel> nigel_nb: http://mirror.anl.gov/pub/ubuntu-iso/CDs-Xubuntu/9.10/release/xubuntu-9.10-desktop-i386.manifest
[06:43] <nigel_nb> Flannel, thank you.  I finally did find it on http://cdimage.ubuntu.com/xubuntu/releases/karmic/release/ :)
[06:44] <nigel_nb> anyway the bug is confirmed at least.  telepathy-idle package is on ubuntu by default and not xubuntu
[06:53] <kees> superm1: I'd rather css got installed somehow with a verified key, but this is a long standing exception, afaiu.
[06:54] <superm1> kees, is this maybe worth raising to the tech board to add css to multiverse?
[06:55]  * kees whistles
[06:56] <kees> I would rather a a sha512 was distributed with the package, easier to deal with it legal-wise.
[06:56] <superm1> as in sha512 and wget a'la flashplugin-installer?
[06:57] <kees> yeah.  I think it fetches source and builds it?  I really haven't looked at it in a while now.
[06:57]  * kees has to run; I'll read scroll-back
[06:57] <tgm4883> party on kees
[06:58] <superm1> it fetches the source package and builds that from what it looks (install-css.sh)
[07:26] <fabrice_sp> in a fakesync, we just substitute the debian directory from ubuntu with the debian one, without keeping any history from ubuntu in the changelog, right?
[07:34] <superm1> kees, well lets talk this through to come up with a good happy medium to keep in mcc for users when you get a chance then
[07:36] <ScottK> fabrice_sp: Yes.
[07:37] <ScottK> fabrice_sp: It should be just like a sync, but using the Ubuntu tarball.
[07:37] <fabrice_sp> ScottK, what should be the version? ubuntuX or buildX? My feeling is that with buildx , it will be autosynced
[07:38] <ScottK> fabrice_sp: It would be and you don't want that.
[07:38] <ScottK> Use ubuntu1 and then once there's a new version Debian, file for a regular sync
[07:38] <fabrice_sp> ohh, in case there is a new debian/non upstream version, right
[07:38] <fabrice_sp> ok
[07:38] <fabrice_sp> thanks
[07:40] <ScottK> Exactly
[07:46] <AnAnt> Hello, can I set a bug to be blocked by another bug in LP ?
[07:47] <ScottK> No
[07:48] <AnAnt> ScottK: how then can I deal with LP 511069 , which cannot be solved unless LP 491880 is solved ?
[07:48] <ubottu> Launchpad bug 511069 in zekr "Sync zekr 0.7.5~beta3+repack-1 (multiverse) from Debian unstable (non-free)" [Wishlist,Incomplete] https://launchpad.net/bugs/511069
[07:48] <ubottu> Launchpad bug 491880 in eclipse "eclipse source package provides libswt* binary packages that would conflict with swt-gtk" [High,In progress] https://launchpad.net/bugs/491880
[07:48] <AnAnt> add a remote bug watch ?
[07:48] <ScottK> Not sure.
[07:48]  * ScottK just knows LP doesn't support it.
[07:49] <AnAnt> ok
[07:49] <fabrice_sp_> AnAnt, usualy, I subscribed myself to the 'blocking bug' and let the other one as In progress
[07:49] <AnAnt> fabrice_sp_: ok, you received my reply that I just sent ?
[07:50] <fabrice_sp_> not yet :-)
[07:50] <fabrice_sp_> (I have some lag)
[07:51] <AnAnt> ok
[08:00] <fabrice_sp_> AnAnt, just keep the sync on hold, then
[08:00] <AnAnt> fabrice_sp_: I set it to In progress
[08:01] <fabrice_sp_> ok
=== vish is now known as mac_v
=== mac_v is now known as vish
[09:24] <randomaction> If I'm not mistaken, new TexLive means libkpathsea4 -> libkpathsea5 transition, so I opened bug 511502 for that.
[09:24] <ubottu> Launchpad bug 511502 in xdvik-ja "TeXLive 2009 transition: libkpathsea5" [Undecided,New] https://launchpad.net/bugs/511502
[09:30] <hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - There are no lintian warnings or other errors. The debian/rules will be okay like that, I hope (since the Makefile has a install rule). http://revu.ubuntuwire.com/p/qt-shutdown-p
[10:59] <geser> randomaction: looks like the easy case from bug #511502 are done: 3 packages from main wait sponsoring, I've left evince for the desktop team
[10:59] <ubottu> Launchpad bug 511502 in xdvik-ja "TeXLive 2009 transition: libkpathsea5" [Undecided,In progress] https://launchpad.net/bugs/511502
[11:00] <randomaction> geser: thank you for your help
[11:00] <randomaction> there's also cjk which FTBFS, dunno why, it's ok in my pbuilder
[11:01] <geser> dvi2dvi and dvipsk-ja have a FTBFS bug open in Debian, dvi2ps and important bug about the transition
[11:01] <geser> and texfam needs a removal bug filed (it got removed from Debian but not yet from lucid)
[11:04] <randomaction> tmvew also FTBFS in Debian and Ubuntu
[11:04] <ahe> i get a MOD_PYTHON ERROR on http://revu.ubuntuwire.com/
[11:05] <ahe> http://pastebin.com/m763955b7
[11:06] <geser> randomaction: re cjk: I guess it's because of "texlive-base-bin". it's a provided now by texlive-binaries but as the old (real) debs didn't got removed yet (they are listed in NBS) the dependency doesn't get resolved always correctly
[11:07] <randomaction> so binary should be removed to make way for that build?
[11:07] <geser> cjk should build properly once texlive-base-bin gets removed from NBS (most of the listed package there have an unversioned dependency on it, so they continue to work with texlive-binaries, no work needed)
[11:07] <geser> yes
[11:08] <geser> we have currently the real but uninstallable texlive-base-bin and the installable texlive-binaries providing texlive-base-bin
[11:36]  * sistpoty gives a shot at ktoon
[12:36] <c_korn> where can I find information why pysol has been removed from the repos ? http://packages.ubuntu.com/jaunty/pysol
[12:39] <randomaction> c_korn: https://launchpad.net/ubuntu/+source/pysol/+changelog
[12:40] <c_korn> randomaction: thanks, and sorry I did not find it. it was quote obvious to have a look there :/
[12:41] <randomaction> np :)
[13:03] <hakaishi> Hey, what happend to revu.ubuntuwire.com?
[13:03]  * persia huns
[13:03] <persia> hunts!
[13:05] <persia> hakaishi: I can't tell right now.  Seems there's some issue connecting to postgres, except postgres claims to be running.
[13:05] <persia> I'll report to someone who has a chance of fixing it :)
[13:06] <hakaishi> I just hope it'll be fixed soon ^^
[13:06] <persia> Indeed.  That being down is annoying.
[13:07] <hakaishi> okay, bye bye
[13:07] <sistpoty> hmpf, I installed a postgres update tomorrow, but it did work then :/
[13:07] <persia> hakaishi: By the way, your qt-shutdown-p 1.6-all~karmic1 upload was rejected.
[13:08] <persia> sistpoty: Everything always works tomorrow :)
[13:08] <sistpoty> heh
[13:08] <persia> (and may I borrow your time machine?)
[13:08] <sistpoty> *g*
[13:08]  * sistpoty restarts apache
[13:09] <persia> Lovely.  Works great now.
[13:09] <sistpoty> that was easy :)
[13:10]  * persia digs through the rejected queue and cleans up
[13:15] <ahe> could someone please take a look at my package of rubyripper (a CD ripper that can handle intentionally crippled audio CDs) at http://revu.ubuntuwire.com/p/rubyripper ?
[13:17] <persia> ahe: There are some control file bits mentioned by lintian that are worth fixing.
[13:17] <persia> ahe: Are you using a VCS to maintain this package?
[13:18] <ahe> persia: is there a reason why lintian didn't mention those problems when i built the package with debuild on my local system?
[13:19] <ahe> persia: i have a bazaar branch but i don't build directly from it but just build the working copy manually with debuild
[13:19] <persia> I don't think the lintian run by debuild checks very much.
[13:20] <persia> ahe: Well, you've patches to the source outside debian/ without a patch system.  That's OK, as long as you're using a VCS to manage the patches, but if you're not intended for a VCS to be used to manage patches, it would be better to use a patch system.
[13:20] <persia> Otherwise it becomes just a monumental pain to merge the changes every new upstream release.
[13:21] <sistpoty> ahe, persia: the lintian notes are only informational, and I'd rather not move things from build-dep to build-dep-indep, as sbuild disagrees with policy when to install build-dep-indep
[13:21] <ahe> persia: ok so does that mean that bzr will replace traditional patch systems?
[13:21] <persia> sistpoty: Hrm?  sbuild doesn't usually give me issues.  I run with -A for i386, and without -A for other architectures (as we do in Ubuntu).
[13:22] <persia> ahe: That depends on the relative success of Format 3.0(bzr) :)
[13:23] <persia> ahe: But more generally, if one is using a VCS, a patch system can seem annoying, and if one is using a patch system, a VCS can seem like duplicate overhead.  They both represent ways of handling variations to a source.
[13:23] <persia> Doing one or the other is good.  Doing both is fine.  Doing neither leads to pain.
[13:24] <sistpoty> persia: iirc, build-depends-indep aren't installed for binary or binary-arch (e.g. debian bug 478524)
[13:24] <ubottu> Debian bug 478524 in sbuild "debian/rules build target requires installing B-D-I" [Normal,Open] http://bugs.debian.org/478524
[13:26] <ahe> persia: is there a "official" bzr repo to put packages? currently i have it in https://code.launchpad.net/~aheck/+junk/packages
[13:27] <persia> ahe: That gets complicated.  There's an "offical" location where bzr repos get put, but I don't believe the converse currently exists.
[13:27] <persia> Plus, unless you can upload, you wouldn't be able to commit to those branches anyway.
[13:28] <ahe> i also have the problem that i build this package for my ppa and to upload to revu i "cleaned" the histroy from all ppa entries because i'm not sure if its better to have them in for completeness or make the history look "cleaner"
[13:28] <ahe> so i guess its ok to use a junk repo on launchpad?
[13:30] <persia> sistpoty: Hrm.  I'm not convinced that it's not better to use b-d-i, but I can see that it might have issues with some packages, although I'd consider those package bugs (not that it isn't easier to fix it in the build system).
[13:30] <persia> ahe: Go ahead and use a junk repo, but I'll change the nature of my complaint based on the fact you're using a VCS :)
[13:33] <ahe> :)
=== ryanakca_ is now known as ryanakca
[13:56] <freeflying> this channel is for identified users only?
[13:59] <persia> freeflying: Apparently it currently is.  I believe that's intended as a limit to the current spambots.
[13:59] <persia> I would expect it to go away at some point.
[14:02] <persia> Hrm.  I was just looking at libpam-slurm, and a simple s/libslrum20-dev/libslrum21-dev/ in debian/control makes it build on amd64, but it fails to build on i386 with that same change, with undefined reference to `__stack_chk_fail_local' .  Anyone know what that means?
[14:03] <acicula> try with -fno-stack-protector
[14:03] <acicula> mind you that removes the stack canary protection system
[14:03] <persia> acicula: But why would I only see this on i386 and not on amd64?
[14:04] <acicula> persia: linking against precompiled code?
[14:04] <acicula> or precompiled objects?
[14:04] <persia> Against whatever's in the archive right now.
[14:05] <acicula> with a feshly unpacked archive or did you use make clean or whatever
[14:05] <freeflying> persia: thanks dude
[14:07] <persia> acicula: I've called, in parallel `sbuild -A -d lucid-i386 libpam-slurm_1.6-2ubuntu1.dsc`  `sbuild -d lucid libpam-slurm_1.6-2ubuntu1.dsc` on an amd64 system.  The schroots were constructed by mk-sbuild-lv from karmic, and the pat-caches are fairly up-to-date.
[14:08] <persia> I don't see any binaries in the source package, so any precompiled stuff I'd be linking against would be freshly downloaded build-deps, or build-essential stuff (which was last refreshed within the day)
[14:09] <acicula> persia: well my understanding on the subject is a bit rustic. As i understand the compiled object code is trying to call that function, which is injected because of the stack protection(goverened by that flag i mentioned earlier) and the linker cant find it
[14:10] <persia> Could it be the -nostdlib argument being passed to gcc?
[14:10] <acicula> well what does nostdlib do?
[14:12] <acicula> NOTE: In Ubuntu 6.10 and later versions this option is enabled by default for C, C++, ObjC, ObjC++, if neither -fno-stack-protector nor -nostdlib are found.
[14:12] <sistpoty> persia: yes, that should be it
[14:12] <acicula> in relation to stack-protector
[14:12] <persia> But I'm *also* passing -nostdlib on amd64.  Do we not do stack smashing protection for amd64?
[14:12] <acicula> ah found in the man page, -nostdlib could definitly be it, heh
[14:14] <sistpoty> persia: you'll need to specify -nostdlib already as compiler flag, that will turn off stack-protector. if it's only in ldflags, you'll get the undefined reference (at least that's how I figure from looking at the invaders source package, and what I did there)
[14:16] <acicula> RELRO           STACK CANARY      NX            PIE                     FILE
[14:16] <acicula> Partial RELRO   Canary found      NX enabled    Dynamic Shared Object   /lib/libc.so.6
[14:16] <acicula> compiled with canary on amd64 it seems?
[14:17] <persia> http://paste.ubuntu.com/361265/ is what I got.  Do I need to patch Makefile to pass -nostdlib more agressively?
[14:18] <sistpoty> persia: yes: gcc -Wall -O2   -fPIC -c pam_slurm.c
[14:19] <sistpoty> persia: you'll need a -nostdlib there already, otherwise gcc will insert calls to __stk_chk_fail when compiling
[14:19] <persia> Should be `gcc -Wall -O2 -nostdlib -fPIC -c pam_slurm.c` ?
[14:19] <sistpoty> persia: yes
[14:20] <persia> Ah, right.  Be nice if the behaviour was cross-arch.
[14:20] <sistpoty> yeah, that's still a little bit puzzling, no clue why it works on amd64 ;)
[14:21]  * persia is checking powerpc right now, and might just ignore i386 out of cussedness
[14:21]  * sistpoty is still fighting against ktoon
[14:23] <persia> Odd.  Works on amd64, fails for i386 & powerpc.
[14:40] <persia> MANUALDEPWAIT just takes care of itself once satisfied, right?
[14:49] <geser> yes
[14:58] <persia> Then I won't worry about them, except where they can't be satisfied.
[15:00] <pucko-> Ok. so I have created a ubuntu package. fixed all errors. how do I get it into ubuntu? I haven't signed it yet, because I'm not sure how.
[15:04] <persia> pucko-: Put it somewhere and get two ubuntu developers to review it.
[15:04] <persia> REVU can be a handy tool for this.
=== Nafallo_ is now known as Nafallo
[15:58] <sistpoty> christoph_debian: I saw that you have been working on fixing ktoon build breakage? I've added a few more hunks, so that it works now: http://paste.ubuntu.com/361323/ in case you're interested
[16:07] <pucko-> persia, thanks. it's finally uploaded now.
[16:08] <pucko-> but I can't see it in revu.ubuntuwire.com :-(
[16:09] <pucko-> can I assume it's just slow?
[16:11] <RainCT> pucko-: have you uploaded it more than 5 minutes ago?
[16:12] <pucko-> something like that
[16:13] <RainCT> pucko-: OK, I can check if you want. What's the package's name?
[16:13] <pucko-> libtodos-agmii
[16:15] <RainCT> pucko-: It was rejected because REVU couldn't recognize your signature. Is your GPG linked to Launchpad and have you logged into REVU before the upload?
[16:23] <jariq> Got question about my package ipwatchd - http://revu.ubuntuwire.com/p/ipwatchd - I entered section "network" in control file and revu did not complain about it during upload. I uploaded this package to PPA and it kept refusing the package until I changed section to "net". Which value is correct for universe and where can I find the list of sections?
[16:23] <pucko-> yes I have. but I guess I did something wrong there.
[16:27] <pucko-> oh. my email (in the key) wasn't validated in launchpad
[16:28] <sistpoty> jariq: rejecting the package due to the section is news to me, but you can use e.g. aptitude to find out about sections
[16:29] <pucko-> not sure if that would fix it. how do I tell dput to let me upload again?
[16:29] <sebner> sistpoty: I already stumbled myself over an interesting section error: "No section "-" known" , after some hours(!) of investigation I noticed that the section was missing entirely in control ^^
[16:30] <sistpoty> sebner: ah, well, missing might be an entirely different case ;)
[16:30] <sistpoty> sebner: however afaik the section is set by archive admins anyways, but I wouldn't exactly know by which means
[16:31] <sebner> sistpoty: My experience is reject of the upload so archive admins don't even get in contact with it
[16:31] <sistpoty> heh
[16:32] <sebner> sistpoty: btw, I failed hard at the "Grunzüge der Informatik" test, doing again in march. *being ashamed in front of sistpoty * :P
[16:33] <sistpoty> sebner: I took 7 semesters for my grundstudium, which is about the maximum I could do, so don't worry :P
[16:33] <sebner> sistpoty: haha, fine then :) .. also because I was only too lazy to really learn xD
[16:33] <pucko-> woo! accepted
[16:34] <RainCT> jariq: http://packages.ubuntu.com/lucid/ has a list of categories. Looking at the URL you can see what the name for debian/control is, in the cse for Network "net"
[16:34] <RainCT> *cse=case
[16:50] <ScottK> elementtree and celementtree have been removed from Debian Testing.  It would be good if someone could look at what we needed to do the same.
[16:51] <DktrKranz> (ctypes will follow soon)
=== yofel_ is now known as yofel
[17:16] <ahe> i just uploaded a new package on revu and on the packages page there is the following message: "Warning! This package could not be extracted; there's no browsable directory for it on REVU."
[17:16] <ahe> what does that mean?
[17:16] <ahe> shouldn't revu reject my package if there is something wrong with it?
[17:17] <sistpoty> ahe: source format 3?
[17:18] <sistpoty> (others than that, the package name might help to take a close look)
[17:18] <sistpoty> closer even
[17:18] <ahe> sistpoty: http://revu.ubuntuwire.com/p/rubyripper
[17:18] <jariq> ahe: did you wait 5 minutes after upload ?
[17:19] <ahe> jariq: yes, but i guess not much more ;)
[17:20] <sistpoty> ahe: ah, I see, you'll need to upload with .orig.tar.gz (-sa argument to dpkg-buildpackage/debuild), otherwise revu doesn't know where the .orig.tar.gz is
[17:20] <jariq> ahe: i think i had the same problem with my package.. but it was just temporary right after upload
[17:20] <sistpoty> ahe: let me see if I can find the .orig.tar.gz from a previous upload, then you don't need to reupload
[17:22] <sistpoty> ahe: found and extracted
[17:22] <ahe> sistpoty: thx i already reuploaded
[17:23] <sebner> sistpoty: Is Revu already 3.0 compatible?
[17:23] <ahe> strange i would have sworn i only used 'debuild -S' the last time
[17:23] <ahe> thx for the help
[17:23] <sistpoty> np
[17:23] <sistpoty> sebner: revu is, but spooky isn't
[17:24] <sistpoty> sebner: revu only calls dpkg-source -x... however spooky is (still) running hardy. dpkg there doesn't understand 3.0 yet
[17:25] <sistpoty> sebner: sad thing is, that there's no official sparc support after hardy, and I've been told that it's not a too good idea to upgrade a sparc box bexond hardy
[17:25] <sistpoty> beyond even
[17:26] <jariq> When will be lucid repos frozen for new packages ?
[17:26] <sebner> sistpoty: arghh. I suppose there isn't really a plan to fix this issue somehow?
[17:26] <ScottK> sistpoty: I know that Karmic sparc is a REALLY bad idea.
[17:26] <ScottK> sebner: It's a community maintained port so ....
[17:26] <sebner> sistpoty: install lucid then!
[17:27] <ScottK> sebner: Not on sparc.  Utterly broken.
[17:27] <sebner> ScottK: sparc is br0ken, replace the server with something sane :P
[17:27] <sistpoty> the best plan so far seems to be the one from ncommander: have dpkg backported
[17:28] <sistpoty> others than that, migrating revu (hopefully w.o. having me to do it) would also sound pretty good
[17:28] <sistpoty> *shrug*
[17:28] <sebner> heh
[17:28] <sistpoty> I'm really a bit clueless how to proceed best, to be honest
[17:29] <ahe> sistpoty: now revu can't find orig.tar.gz for all my uploads http://revu.ubuntuwire.com/u/aheck
[17:29] <ahe> guess it was a bad idea to upload it again
[17:29] <sistpoty> ahe: /me looks
[17:29] <ScottK> sistpoty: I don't think a backported dpkg in hardy-backports would fly.
[17:29] <ahe> sistpoty: thx
[17:30] <sistpoty> ScottK: as I wrote, good ideas are needed :)
[17:31] <ScottK> sistpoty: Could you backport it locally and build it just for that box?
[17:32] <sistpoty> ScottK: that might be an option, however iirc there was some libc <-> dpkg thingy which I'm quite afraid of.
[17:33] <ScottK> Could be.
[17:33]  * ScottK hasn't been tracking it.
[17:33]  * sistpoty isn't too sure if that's an issue in the first place though
[17:35] <sistpoty> ahe: still no .orig.tar.gz in the upload (I'll fix it locally in revu). you can verify if an .orig.tar.gz is included by looking at the .changes file prior to uploading
[17:36] <sistpoty> ahe: done
[17:36] <ahe> sistpoty: its present in the changes file as well as in the *.revu.upload file
[17:36] <ahe> sistpoty: ah thank you very much
[17:37] <sistpoty> ahe: no, it's not in the .changes file
[17:37] <sistpoty> (at least the one you uploaded to revu ;))
[17:38] <ahe> strange
[17:38] <ahe>  5a095e5a22743f224f73bd9312274e3c997c2e6e 144044 rubyripper_0.5.7.orig.tar.gz
[17:38] <sistpoty> there's a stale .orig.tar.gz lying around in incoming though
[17:40] <sistpoty> ahe: http://paste.ubuntu.com/361367/, that's the latest .changes file I can find (I stripped the signature for security reasons)
[17:42] <ahe> sistpoty: that is mine: http://pastebin.com/m69f46ef6
[17:43] <sistpoty> ahe: did you run debuild -S -sa again after the upload? that'll overwrite your .changes file
[17:44] <sistpoty> (the Date: is directly taken from changelog, so that would remain the same)
[17:44] <ahe> after the first upload and then i did the last upload so far
[17:48] <sistpoty> gpg: Signature made Sat Jan 23 18:06:23 2010 CET using DSA key ID 7F49A63D
[17:48] <sistpoty> ahe: ^^ that's the date gpg --verify *changes tells me, I assume you have a different one?
[17:52] <ahe> sistpoty: 18:21 ah of course ! it couldn't overwrite some files during the second upload and so i guess it uploaded the orig.tar.gz but didn't know it was there *doh*
[17:52] <sistpoty> heh, ok, mystery solved :)
[18:00] <geser> anyone familiar with vim and its python command?
[18:01] <sistpoty> geser: I only know that james_w told me about ctrl-o ctrl-p (python-omni-complete), which I find quite helpful
[18:02] <geser> I wanted to upgrade the omnicomplete for LP bugs (as it's still uses python-launchpad-bugs) but fail already at importing launchpadlib inside python
[18:02] <geser> or more exactly the import of hashlib causes problems
[18:03] <sistpoty> sorry, -ENOCLUE
[18:05] <jariq> Could anyone pls review ultimate :) package ipwatchd ? - http://revu.ubuntuwire.com/p/ipwatchd - I resolved all persia's comments and now it builds without problem in my PPA.
[18:38] <sistpoty> jariq: looking... as I was curious, I took a glimpse at the code of ipwatchd. Haven't seen such cleaned up code for some time ;)
[18:39] <jariq> sistpoty: clean code makes many things much quicker
[18:40] <sistpoty> *nod* (from own, hard-gathered experience)
[18:40] <sebner> jariq: /me recommends using dh7 also in rules
[18:42] <sistpoty> jariq: what about ipwatchd-script? that calls (if present) ipwatchd-gnotify (not found in the package)?
[18:43] <sistpoty> jariq: anything else appears to be top-notch!
[18:45] <ahe> would be great if someone would like to review my new rubyripper package http://revu.ubuntuwire.com/p/rubyripper too
[18:46] <jariq> sistpoty: IPwatchD is daemon that does not require X-window. But it can run user-defined script and that script can run any desktop notification app. I separated desktop notification code into standalone package ipwatchd-gnotify (bubble notifications for Gnome environment). It is also in revu waiting for review.
[18:47] <jariq> sistpoty: this way user on server can install just ipwatchd package and user on desktop can install also ipwatchd-gnotify and both packages work together without any manual configuration needed.
[18:48] <sistpoty> jariq: oh, I see
[18:48] <sistpoty> jariq: actually I didn't see the suggests in the first place, sorry for that
[18:52] <jariq> sistpoty: thanx for advocation
[18:52] <sistpoty> jariq: thanks for the package!
[18:53] <sistpoty> sebner: btw.: I still haven't switched my packages to dh7 :P
[18:55] <sebner> sistpoty: bah :P I'm already switching to debsrc3 :P
[18:55] <sistpoty> haha
[18:56] <sebner> sistpoty: dh7 + quilt -> debsrc3 = packaging heaven ;)
[18:57] <sistpoty> sebner: at least I've managed quilt now (long time mystery to me)
[18:57] <sebner> sistpoty: quilt is just great an superior :) It's not that difficult imho
[18:58] <sistpoty> sebner: if you know how it's working, it's not... until then it is, at least for me :P
[18:58] <sistpoty> (though it's completely strange that export QUILT_PATCHES=debian/patches is the magic key)
[18:59] <sebner> sistpoty: ACK! I just put it once in my bashrc and it's fine but it's really strange indeed
[19:04] <geser> I put the quilt recipe from the quilt README into my .quiltrc
[19:05] <ScottL> hello?
[19:06] <ScottL> sorry, just making sure I registered correctly
[19:06] <geser> ScottL: Hi
[19:06] <ScottL> I'm trying to backport Ardour 2.8.4 to Hardy but my pbuilder environment will not find and install libcurl4-openssl-dev as a dependency of libraptor1-dev, anyone have any ideas?
[19:06] <ScottL> geser, hi :)
[19:06] <ScottL> I can login into my pbuilder environment and install it though....real weird
[19:07] <ScottL> i have hardy-updates enabled (main, restriced, universe and multiverse)
[19:07] <sistpoty> btw: !ops, is the registerd user requirement still needed atm? doesn't seem to make much sense for the entry point in ubunu development, *if* there aren't too many spam attacks
[19:07] <geser> have you tried to install libraptor1-dev too
[19:07] <jariq> sistpoty: could you please review also ipwatchd-gnotify ? it same clean codebase, much smaller app.. should be an easy one :)
[19:07] <geser> or even all build-depends?
[19:08] <ScottL> geser: you mean install libraptor1-dev in the pbuilder environment first?
[19:08] <sistpoty> jariq: queued, reviewing another package atm (and trying to watch a movie since about 5 hours *g*)
[19:08] <geser> sometimes packages are installable itself but not in combinataion because of a conflict somewhere down the dependency chain
[19:08] <sistpoty> (my !ops didn't seem to have effect, ubottu?)
[19:09] <ScottL> geser: yes, I had that happen the other day...had trouble with libcurl
[19:09] <geser> ScottL: login into your pbuilder environment and check if you can install all the build-depends for the package you want to build
[19:09] <niko> sistpoty: try to use it at first word
[19:09] <ScottL> geser, okay try installing all by hand and find where the problem is....good idea, thanks  :)
[19:10] <ScottL> geser, it's always a bit of trouble backporting but this one has been particularly troublesome    lol
[19:10] <sistpoty> !ops: is it still required to be a registered user for #ubuntu-motu? doesn't make much sense imho for the entry point in ubuntu development *if* the spam attacks have gone down (your call)
[19:10] <niko> works
[19:10] <sistpoty> yes, thanks niko!
[19:13] <sistpoty> ahe: you license the packaging under GPL (w.o. version), can you make the version more clear please? (upstream is gpl-3+, so iirc packaging should not exlude later versions, but I may be wrong there)
[19:14] <ahe> sistpoty: ok
[19:15] <sistpoty> ahe: others than that, looking at the source only is good with me. let's see what the binaries will provide
[19:17] <ahe> any idea why revu complains that it can't find the license?
[19:20] <ahe> ok pushed GPL-3+ change to my launchpad branch
[19:20] <sistpoty> ahe: no idea actually, maybe RainCT knows the details (called GPL-3.txt)
[19:21] <sistpoty> ahe: probably doesn't fit a regexp in revu
[19:23] <sistpoty> ahe: looks quite good, I guess only lintian isn't satisfied: please don't exceed 80 cols in debian/changelog, and please provide a manpage for at least rrip_cli
[19:25] <ahe> a complete manpage or just a dummy one?
[19:26] <sistpoty> ahe: the parse_options function should give you a clue
[19:26] <sistpoty> (it's no help to have a manpage that tells: "there are options, figure them")
[19:27] <sistpoty> as I'm no ruby expert, maybe help2man will do (no idea what will happen if called with --help)
[19:28]  * ScottK hints at apachelogger for Ruby expertise.
[19:29] <sistpoty> well, I could just try --help here :P
[19:30] <sistpoty> haha, it doesn't work if extracted to a local path :)
[19:38] <ahe> help2man yields quite usable output
[19:38] <ahe> i think i will just rework it a bit and i have a nice little manpage
[19:41] <sistpoty> excellent, ahe!
[19:52] <RainCT> sistpoty: Yeah, the license check is pretty basic (it just looks for some common file names)
[19:53] <sistpoty> RainCT: ah, I see... maybe add GPL-3.txt to it?
[19:57] <crimsun> sistpoty: did you still need me to look at a vtk rdep issue?
[19:57] <sistpoty> any DD's around who could sponsor the NMU at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527721? (DktrKranz, siretart`, ajmitch, christoph_debian, white_ just to highlight a few)
[19:57] <ubottu> Debian bug 527721 in ktoon "ktoon: FTBFS: ioapi.c:13:18: error: zlib.h: No such file or directory" [Serious,Open]
[19:58] <sistpoty> crimsun: as I wrote, I worked around it, but I think it's still broken (haven't checked debian though if there are news)
[19:58] <DktrKranz> sistpoty: _o/
[19:58] <sistpoty> crimsun: so it's wishlist priority for me
[19:58] <sistpoty> hey DktrKranz :)
[20:02] <geser> crimsun: Hi, just curious (no hurry), how does the testing/review of the fuse merge go?
[20:03] <crimsun> geser: it works fine for me; I'd like to ping cjwatson and pitti on it
[20:09] <geser> crimsun: I talked to pitti (to ¼ of him, the other part was mentally at the sprint) about the .fdi file in our current fuse delta when I did the merge
[20:11] <crimsun> geser: what was his take on it?
[20:11] <geser> that the .fdi file doesn't work since karmic anyway so it can be dropped
[20:13] <geser> crimsun: http://irclogs.ubuntu.com/2010/01/13/%23ubuntu-devel.html starting at 12:12
[20:15]  * sistpoty goes to bed... gn8 everone
[20:29] <crimsun> geser: ok, it seems mergeable to me, then. Any outstanding issues?
[20:30] <geser> crimsun: I don't know of any
[20:30] <ahe> i get mod_python errors on revu again :(
[20:45] <crimsun> geser: uploaded, thanks!
[22:05] <mr_pouit> siretart: (ffmpeg-extra) I've added locally some macros in debian/confflags to autodetect opencore-amr and pass --enable-version3 to configure script (in the same manner as --enable-nonfree). If you're interested, I can provide a patch.
[22:48] <RainCT> ScottK: Hey. Is there still some point for having the python-pyclamd package?
[23:03] <ScottK> RainCT: Sure.  it's a useful thing.  I think it still needs to be sync'ed from debian.
[23:07] <RainCT> ScottK: Okay, just checking :). No need to sync it, there are no real changes between Debian and Ubuntu.
[23:16] <perberos> gentlemens