=== CarlFK1 is now known as CarlFK === _neversfelde is now known as neversfelde [00:35] Riddell: He's iefremov [00:35] Doesn't look like it. [00:36] mok0 and I reviewed his package. What's up? [00:36] Since he's in .ru it's even more middle of the night than it is for you... === nhandler_ is now known as nhandler [04:12] what are the odds that a package from revu builds in a local pbuilder, and two motus' pbuilder, but ftbfs on launchpad? [04:12] no wait, it fails here too [04:12] wtf [04:13] So something changed ... [04:14] hmmm [04:15] which change could have broken it? [04:15] hmm [04:15] dh_install is missing files usr/lib/*.so.* [04:15] which is pretty ridiculous [04:18] ah figures. i need to specify debian/tmp/usr/lib/*.so.* [04:18] because i lowered the compat [04:19] hyperair: An, in general, there's a non-zero probability of that happening because the pbuilder environment is different to the buildd environment. [04:19] it is? [04:20] Yes. Obvious candidates are lack of internet access on the buildds, followed by differences between sbuild and pbuilder, followed by craziness (see mono-on-PPA) [04:23] (Help with working out what's making mono segfault on the amd64 PPA buildds welcome) [04:24] That's mono-on-xen, isn't it? [04:25] Yes. Known bug? [04:26] pochu: turns out sigx _was_ using debhelper compat 7 specific stuff. it ftbfs'd in the buildd [04:26] No it's not as simple as mono-on-amd64-xen, because the exact same version of mono _didn't_ segfault on the PPA buildds before December last year. [05:02] Quite a stack of packages looking for a 2nd advocate on REVU. [05:07] http://revu.ubuntuwire.com/details.py?package=metakit would like just one :) [05:49] I'm building up a pile of ruby packages on revu (LP: 321772 321354 322161), is there a good place to reach the motu-ruby team about reviewing them? [05:50] Is there a motu-ruby team? [05:51] ScottK: https://launchpad.net/~moturuby/ [05:52] btm: AFAIK none of those people are currently active in Ubuntu. [05:53] I noticed lucas is in channel. [05:53] * ajmitch thought \sh would have been interested in that as well [05:53] So far mostly Ruby (and particularly RoR/Gems) devs seem to be insane from a distro persprective. [05:53] I'm sure the reverse is true too. [05:53] btm: He hangs around, but is mostly active in Debian these days. [05:54] apachelogger is big on Ruby. [05:54] I know that. [05:55] ScottK: I'm an SA, who doesn't like gems, but develops for chef/ohai ( http://wiki.opscode.com/display/chef ) so I'd like to get debs in. I'm happy to do all the work but of course I need reviewers. I have multiple debian sponsors so if it comes to that I'll just wait for the them to be imported in 9.10, but I use ubuntu primary so I'd prefer to find some likeminded folks here. [05:57] btm: If you can work in parallel, I'll personally volunteer to review anything that's uploaded to Debian while it's still in Debian New and upload it here so you don't have to wait. [05:57] Then you just ask for a sync the next release. [05:58] Personally, I'm very glad to have packages here if they are going to Debian and we, as a relatively small team, aren't going to get stuck with them. [05:59] ScottK: I'm happy to build parallel packages. Because you mention MOTU being a small team, are you saying you prefer to sync the debian packages rather than having ubuntu packages (with motu as the maintainer)? [06:00] Absolutely. [06:00] There are an order of magnitude more Deiban developers than Ubuntu. [06:00] Also a stronger Debian is good for Ubuntu. [06:01] I don't mind having them here for a bit, but in the long run the more than gets maintained in Debian, we all win. [06:01] btm: Is http://wiki.opscode.com/display/chef/Installation+on+Ubuntu+8.10+with+debs your creation? [06:02] That's no problem at all. I got another impression about debian<->ubuntu from a number of ubuntu-core people when I was trying to get some patches applied to SRU. [06:02] ScottK: Yeah. I braindumped the ppa stuff this morning there. [06:02] If so you get bonus points in my book for giving the instructions to install the PPA key so the packages get cryptographically verified. [06:03] Debian and Ubuntu each have different bits with different personalities. [06:03] Some core parts of the distro are pretty well forked or totally so (Ubuntu rolls it's own kernel for example). Out here on the fringes it's less divergent and the less divergent the better for us. [06:04] ScottK: Can you still sync specific packages from debian now that DIF is past, or are we looking at 9.10? [06:04] Up to Feature Freeze which is the 19th of Feb (or something close to that) [06:04] DIF just means the auto sync is turned off. [06:05] At the rate New is going in Debian, you won't get out of New in time if stuff gets uploaded. [06:05] ... to Debian first [06:05] good morning [06:05] So I'm glad to upload it here. [06:05] Good morning. [06:07] dholbach: So it turns out I can get on the top of the sponsorship uploaders list on HoF even without the bug you fixed. All I had to do was sponsor an entire KDE upload last night. [06:07] ScottK: ROCK ON! [06:07] is it all uploaded now? [06:07] Yep. [06:07] ScottK: great. should I find you on irc when packages hit new or can I just email you via your address on LP? [06:07] All the core stuff. [06:08] IRC is good. [06:08] * dholbach needs to try it out in a vm - some screenshots really looked cool [06:08] ScottK: okay. what's your timezone? [06:08] -0500 [06:08] (Yes - It's late here) [06:08] I need to clean the kitchen and I'm procrastinating. [06:09] dholbach: Yeah, it's pretty cool. I'm trying it out here, and it now works. [06:10] JontheEchidna: congratulation!! :-) [06:10] ScottK: Thanks. We're making daily process so I'll dig you up again Wed or Thu. I'm originally from Maine, not much else to do at that temperature at this hour anyways ;) [06:11] btm: Where in Maine? [06:11] ScottK: Grew up in Surry, went to high school in Ellsworth (btw Bangor and Bar Harbor) [06:12] Right. I lived in Bath one winter and Portland another. [06:12] * dholbach does some sponsoring now too [06:21] <_stochastic_> anyone feel like taking a REVU of my package? http://revu.ubuntuwire.com/details.py?package=calf [06:22] G'morning. [06:32] morning iulian ! [06:33] Hiya fabrice_sp. [06:33] and good morning dholbach (I missed your god morning ;-) ) [06:33] s/god/good/ [06:34] hiya fabrice_sp, hi iulian [06:35] 'ey [06:56] any python folks around? I need some packaging advice [06:56] I'll bite. [06:57] LaserJock: What're you after? [06:59] RAOF: I've got a C++ app that has python bindings and things [06:59] RAOF: in the end the install a .so in /usr/lib/python2.5/site-packages/ [07:00] I'm not exactly sure what to do with it === ara_ is now known as ara [07:02] Stick it in a python-foo package. [07:02] really? I was hoping to avoid that :-) [07:02] Ideally building it against multiple versions of python. [07:03] Why wouldn't you split the python bindings out into a separate package, besides laziness? :) [07:04] RAOF: because it's 1 file [07:04] RAOF: and right now it's not useful to anything but the app I'm packaging [07:04] I'm ending up with a lot of overhead for an app [07:05] Is it going to be useful to anything but the app you're packaging? You could just ship it as a private module, then. [07:05] I'm not sure how to ship it as a private module, but that's sort of what I was thinking [07:06] but since I've already had to split out a lib and -dev I guess I could also bite the bullet and do a python-foo [07:06] just kinda sucks to have so many packages for 1 app [07:06] Python policy: http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html says that you can just throw the private module in /usr/lib/packagename, and then you'd want to set PYTHONPATH. [07:07] right, I just don't if the program will handle that [07:07] Worst case would be a wrapper script setting PYTHON_PATH. Unless it's terminally wierd. [07:07] eventually after the next release (1.0) there might be apps using the library [07:08] Which is why you're building a -dev, etc. OK. [07:08] If you're building a -dev you might as well build a python-foo, too. [07:09] btm: who is going to sponsor you? [07:10] LaserJock: But you could always just split it out later. [07:11] lucas: in debian? thom is helping me now and micah offered to. [07:11] micah is into ruby, I think? [07:12] lucas: yes, and puppet. my end goal atm is a chef package, which is configuration management similar to puppet. [07:12] lucas: thom is involved with chef a bit, so he offerred. [07:15] RAOF: I'm not sure how these external modules work exactly. Is the .so enough or does it need the libfoo as well? [07:15] btm: ok ; you might want to take a look at the pkg-ruby-extras team, too [07:16] LaserJock: It'll almost certainly need libfoo as well; the library (python extension module, to be exact) is just going to be a shim between the python interpreter and libfoo. [07:17] RAOF: right, that's what I was thinking [07:18] It's not neccesarily so, but I'd be surprised if they wanted to duplicate libfoo in the python bindings :) [07:18] lucas: I did actually. When I sent an email to list offering to help a month ago I didn't get an enthusiastic response so I'm going to stick with the people who offered to help until that dries up. [07:20] RAOF: luckily I just uploaded this thing to Debian experimental [07:20] RAOF: I'm feeling a little silly for uploading it without the python module [07:20] And your software needs the python module? That's a little bit silly, yes :) [07:21] well, yeah [07:21] see I apparently had an old version of the python module on my machine when I tested the .deb [07:21] so it kinda worked [07:21] Heh. [07:22] btm: we don't have enough sponsors in the team [07:22] I was tracking down why it didn't work all the way when I started with a fresh Ubuntu install [07:22] nor enough active people [07:22] which is a reason for becoming active in the team ;) [07:22] and that's how I figured out why it wasn't working correctly [07:23] hi iulian! bug 321364 [07:23] Launchpad bug 321364 in rosegarden "Please merge rosegarden 1:1.7.2-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/321364 [07:26] quadrispro: OK, thanks. I'll have a look at it in a minute. [07:27] iulian: for a buildlog, quadr-o-matic is working hard -> http://home.alessiotreglia.com/jaunty/result/rosegarden_1.7.2-2ubuntu1/ :) [07:31] lucas: in debian? I'm certainly geared up to help with whatever anyone asks of me. There's just that gap in getting that communicated to people who need help. [07:32] I was looking at doing some more in Debian, but there are some unfriendly social aspects that make it a bit hard. I think perhaps they use email too much. [07:33] LaserJock: Join the mono team, they're nice and friendly, and always on IRC. [07:34] hmm, mono, not sure about that [07:34] I don't know any C# [07:34] I do like some mono apps though :-) [07:34] It's not actually very hard. I didn't know any C# a year or so ago. [07:35] it's just kinda frustrating to be going along and then have a flamewar break out all of a sudden [07:35] Maybe stay away from Mono then. We do seem to attract flamewars. [07:35] Debian people seem to not like each other much sometimes [07:35] sort of unfortunate, but I guess it sort of goes with the territory [07:45] morning [07:48] quadrispro: I'm building it now. [08:05] I think debian's use of email is fine, just need more of when I say "I'll help" someone say "do my crap work! go!" === BugMaN1 is now known as BugMaN [08:22] iulian: if you would use my debomatic machine for build packages -> http://home.alessiotreglia.com/dput_configuration [08:23] I've added your key, so you shouldn't have any problem [08:26] quadrispro: Thanks. rosegarden has just been uploaded. [08:28] thank you, iulian [08:32] iulian: do you have the time for this? bug 321504 [08:32] Launchpad bug 321504 in macchanger-gtk "Small typo in debian/control" [Low,Confirmed] https://launchpad.net/bugs/321504 [08:33] it's a small typo in debian/control === mcasadevall is now known as NCommander === thekorn_ is now known as thekorn [08:44] I'm trying to update a package (bibledit) that is already in Ubuntu. My new package works fine, but running licencecheck on the latest stable tarball found some copyright warnings. Upstream was very cooperatinve and fixed them right away in their git repo... how should I proceed -- do I need to grab my orig source from git (and so get other changes which may not be well tested)? Or use the stable tarball and patch [08:44] the copyright fixes using a file in debian/patches generated from the git code? [08:53] * iulian wonders why rosegarden got rejected. [08:53] File rosegarden_1.7.2.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. [08:54] Files specified in DSC are broken or missing, skipping package unpack verification. [08:54] Am I missing something? [08:55] iulian: Sounds like it thinks you are uploading an orig.tar.gz that is different from the file of that name which it already has... if you debuild -S (not -S -sa) and then dput, does it work then? [08:55] No, I didn't use -sa. [08:56] Hmm. Somehow it thinks you uploaded an orig.tar.gz... at least, that what that message is saying. [08:56] * iulian used debuild -S -k [08:57] Hmm [08:57] Is there any way the orig.tar.gz on your machine could be different from the "real" one? [08:58] Nop. [09:08] Ahh, forgot the -v arg. [09:09] could anyone take a look here? http://revu.ubuntuwire.com/details.py?package=w-scan [09:09] iulian: it rejects when you don't do that? [09:09] wow [09:09] Yeah. [09:09] * iulian tries again. [09:10] iulian: Maybe you can do apt-get source rosegarden from the jaunty universe repo and then comapre the checksums for that file in its .dsc with the checksum lines in the .dsc you are uploading?? [09:16] jmarsden: Yup, the checksums are not the same. [09:16] The current Jaunty version has: 6e140e55617dc5da8f1fd56a4274850e8a38d8b3 8465642 rosegarden_1.7.2.orig.tar.gz [09:17] And the updated one has: 643d9a179d25d0b8355ef09a9c52628bba667c94 8404178 rosegarden_1.7.2.orig.tar.gz [09:17] OK, now diff the two actual files, yours and the one you just downloaded with the apt-get source... ? [09:17] Maybe they really are different. [09:17] seem there are differences between the orig.tar.gz, how is it possibile? [09:17] Guess I will have to use the orig from Ubuntu. [09:17] jmarsden: Oh, I used the .orig from Debian. [09:17] Could be they have the same content but were comrpessed differentl (different architechture machines doing the gzip... ah. [09:18] Anyway... we've found your issue :) [09:19] Indeed, I still wonder why they don't have the same orig. [09:19] I got the orig tarball from Debian, as usually I do [09:19] quadrispro: Yeah, but it seems that it didn't like it so much. [09:19] OK, I will try again and use the orig from Ubuntu this time. [09:20] I see [09:22] It would be good to get that straightened out in the Ubuntu archive, otherwise long term you won't be able to sync from Debian, I think. SOmeone with way more experience than me should probably investigate and (ideally, IMO) grab the Debian one and put *it* into the Ubuntu archive. [09:24] when repacking the tarball it's enough to do it with a different timestamp [09:24] that's why it's good to give the Debian maintainer a heads-up about the tarball that you used or let them do the upload first [09:24] there's no fix for the situation, we need to do a "fake sync" [09:24] and keep using our tarball until there's a new one [09:24] yes, it's true [09:25] OK, it was finally accepted. [09:25] I have to go to school now. [09:26] C'ya. [09:26] iulian: have a great day [09:26] You too. [10:03] hi motus, [10:04] is there a way to sync a package with debian's repository ? [10:04] the sync will fix a bug: actually, for now, the package fails to build [10:05] LP:322047 [10:05] mehdid, https://wiki.ubuntu.com/SyncRequestProcess [10:12] ok thanks ... done [10:13] thanks! :) [10:30] hi all [10:33] can anyone please guide me in packaging a sw.. === asac_ is now known as asac [11:10] csrealized7: Just ask, if you have any problems. [11:43] soren: tks for ur rep..am starting with https://help.ubuntu.com/ubuntu/packagingguide/C/basic-chap.html [12:07] dholbach: I have to remember to test my patches first :) [12:09] lfaraone: which bug? [12:10] dholbach: bug 320440 [12:10] Launchpad bug 320440 in abiword "Sugar needs abiword built with libabiword" [Medium,In progress] https://launchpad.net/bugs/320440 [12:10] ah, right [12:30] What's the difference between arch: any and arch: all? [12:34] lfaraone: For any, different binaries will be built for all of the architectures. For arch all, only one binary will be built that can run on all architectures [12:35] nhandler: understood [12:37] nhandler: do you have the time to re-review ecm at http://revu.ubuntuwire.com/details.py?package=ecm ? [12:37] nhandler: especially the rules at http://revu.ubuntuwire.com/revu1-incoming/ecm-0901240627/ecm-1.00/debian/rules [12:38] nhandler: I'm using the source directory to dl the zip, then create a directory in it to modify the archive [12:38] nhandler: I'd like to know if it's ok, or if i should do that in the debian directory instead [12:39] loic-m: I actually have to leave for school in a few minutes. I can re-review it when I get back [12:40] nhandler: thanks [12:41] Do all packages _need_ an extended description? [12:42] Yes. [12:42] Yes [12:42] Meanwhile, does anyone know if the get-orig-source target in debian/rules can use the source directory (one lever up debian) or the debian directory? [12:43] (I need to delete some exe from the original archive, and repack it) [12:43] StevenK: is it _ever_ appropreate to put an emoticon in a description? (libabiword is punny, sorry :) [12:43] StevenK: (it's an ABI for AbiWord) [12:43] lfaraone: I seriously doubt it [12:43] loic-m: I think you should download the source, and then remove whatever you need [12:44] StevenK: that's what I thought. [12:44] loic-m: because you may have branched the debian/ folder and not have the upstream tarball [12:44] loic-m: you can use the watch file to get the sources though [12:45] pochu: that's what I'm doing, but can I dl it in the folder above debian, or do I dl the source in debian/ ? [12:45] Whilst get-orig-source is being discussed - I'm accustomed to relying on $(CURDIR) in debian/rules but I recently found out that that's not necessarily the case for get-orig-source - is there documentation of a standard idiom of how to refer to the package's own source dir in debian/rules? [12:45] pochu: the watch file get the source, the get-orig-source target uses uscan [12:46] maxb: in g-o-s `pwd` is assumed to contain your debian/ folder [12:46] s/get/gets/ [12:46] loic-m: folder above debian. [12:46] lfaraone: huh. Interesting. I've seen people writing their debian/rules on the assumtion that you can't rely on that [12:47] lfaraone: so what I'm doing should be ok [12:47] loic-m: yes [12:47] loic-m: mhm [12:47] lfaraone: And in fact debian-policy-manual says get-orig-source may be invoked in any directory [12:48] Can one of you please look at http://paste.ubuntu.com/110827/ ? it's just an extract from rules [12:48] maxb: well, it _may_, but for most uses it will be. [12:48] *will not [12:48] lfaraone: Not an assumption you can make if you desire to be policy-conformant === LucidFox_ is now known as LucidFox [12:49] maxb: gos should download a copy of the source to the current directory. [12:49] maxb: in that case, it _can_ be executed from any dir, but it'll do exactly what it says. [12:58] wb, dholbach [12:58] * dholbach takes the dog for a walk [12:59] Anybody here familiar with git-buildpackage [12:59] *? [13:07] hello. i have a question about pbuilder's workflows. does pbuilder support creating a more than one package in the same "session"? example. if i want to compile few packages, then i have to run pbuilder build package1.dsc, and then it compiled, i run pbuilder build package2.dsc, and it creates another session. so, does it possible to run something like "pbuilder build package1.dsc package2.dsc" and to get compiled packages from the same temp chroot env? [13:09] ia: im not sure (not a pbuilder expert), but the point of pbuilder is from a clean install, does your package install the necessary deps and build correctly, and remove. by installing more than one, you might run the risk of contaminating that test... [13:11] dholbach: I really have no clue how to properly separate libabiword from abiword. Moreover, I don't get why it isn't being included in the binary. [13:12] lfaraone: what's the problem exactly? [13:12] dholbach: when I enable the flag there is a libabiword.pc file added to build/, but I guess it isn't actually being built. [13:13] pochu: ok, I'm trying to get abiword to build libabiword as well, but it seems --enable-libabiword in the ./configure command alone won't do it :) [13:13] lfaraone: --enable-libabiword builds the necessary bits just fine (I guess) [13:13] lfaraone: you just need to make sure they get installed into the packages [13:14] dholbach: oh? I thought you said there were no .so files in the binary debdiff? [13:14] dholbach: ah. [13:14] lfaraone: also it might be necessary to separate the library into a separate package [13:14] just take a look at a simple library package to see how it is done: apt-get source libsexy [13:15] dholbach: well, the different library versions won't work with any other abiword version due to ABI breakage. [13:15] then run debuild && dh_install --list-missing to see which files are not installed into packages [13:15] lfaraone: I'm not sure I understand the last sentence [13:15] dholbach: nevermind. [13:15] alright [13:16] * dholbach now REALLY takes the dog for a walk :) [13:21] dholbach: ubuntu-qa-tools is now in the REVU queue [13:21] that will make the world a better place - will check it out later on [13:22] ara_: ooh, what tools does the package contain? [13:22] lfaraone: those at lp:ubuntu-qa-tools [13:26] ara_: cool. === DktrKranz is now known as DktrKranz_nobrow === DktrKranz_nobrow is now known as NoBrowser [13:36] dholbach: Thanks :) [13:40] hi, i have question about Packaging for Ubuntu [13:40] i found a nice tool that is like GNU Screen but the Packaging-Process failed with an Error i cant explain === quadrispro is now known as quadrispra [13:43] no one out who can may help? [13:53] riot_le: If you cannot explain, then by definition, no one is able to help you [13:53] :-) [13:54] The obvious additional question is "Why not screen itself?" [13:54] i've made the dsc by pbuilder create with no problem but pbuilder build fails with error 1 in debian/rules [13:56] i saw tmux (terminal multiplexer, http://sourceforge.net/projects/tmux) in a review in a Linux Magazine here in Germany and try it, it looks good for me so i decide why don't make a Debian-Package to share this with others [14:00] here you can take a look at: http://pastebin.com/m69256faf [14:02] tty-term.c:21:21: error: ncurses.h: No such file or directory [14:02] tty-term.c:23:18: error: term.h: No such file or directory [14:03] there are your immediate problems [14:03] Sounds like you need to add appropriate Build-Dependencies [14:03] ok, i will give a try [14:03] riot_le: try adding ncurses-dev to your Build-Depends in debian/control [14:04] Piratenaapje:thanks for this hint [14:05] riot_le: If you're missing a header file like that, it's a good idea to search package contents at packages.ubuntu.com for them. [14:06] dose anybody know where i can get my hands on an ia64 buildd? [14:06] s/dose/does/ [14:06] i didn't realize that it was a build-dependency that wasn't correct [14:07] other question about debian/copyright === quadrispra is now known as quadrispro [14:07] this Tool is BSD Licensed, do i have to put the whole BSD-Licence in debian/copyright or is the Header of it just enough [14:08] riot_le: Just the header should do it. [14:08] jpds: thanks [14:09] (But then again, isn't the BSD license short anyway?) [14:09] whats the difference between Upstream Author and Copyright Author or is it still the same? [14:11] riot_le: Upstream author(s) are usually listed in the AUTHORS file of the package. [14:11] riot_le: And Copyright holders are the copyright specified in the source files. [14:11] They can be the same, yes. [14:12] there is no Authors-File so i use them both === NoBrowser is now known as DktrKranz [14:25] http://revu.ubuntuwire.com/details.py?package=sabnzbdplus (popular binary newsreader, written in python) needs a second advocate - please consider for review. [14:28] Who do I ping to get motu-status on revu? [14:28] JontheEchidna: Me. [14:28] ...or a REVU admin. [14:29] jpds: ping :P [14:29] hi folks [14:29] Hey sistpoty|work. [14:29] hi jpds [14:29] JontheEchidna: LP ID? [14:29] jpds: echidnaman [14:30] JontheEchidna: "User's permissions have been changed successfully." [14:30] so i give a try and got a new error: http://pastebin.com/m17957602 [14:30] jpds: Thanks! [14:30] No problem. [14:31] riot_le: Looks like the same error to me [14:32] still no ncurses.h and term.h [14:32] maxb: no the last time it was error 1 now its error 2, i added ncurses-dev to debian/control [14:33] riot_le: You need to be focussing on where the first error occurs, all the rest are just layers of the build process acknowledging something broke as they stop [14:51] persia: thanks for the pointer to the key teams member process :) [14:52] sistpoty|work, Thanks for the call for applicants. It's nice to see the team operating effectively when undergoing changes. [14:52] well, this time I want to have the organisational stuff done *before* feature freeze *g* [14:53] That's an excellent plan. Are you planning to have designates for flavours again? [14:53] I think so, yes. I guess that'll be up for discussion at the meeting next Tuesday [14:53] It's just early enough that I'd like to suggest you guys determine a process for the delegates, rather than just picking random people at the meeting. [14:54] I'm thinking that as ArchiveReorganisation proceeds, you'll want to have some way to coordinate with the various teams handling layers, etc. [14:54] Probably doesn't affect this release, but likely to affect the next cycle. [14:55] hm... *shrug*, not too sure about that [14:55] Well, if my guess is correct, you've six months to think about it :) [14:55] heh :) [14:56] Still, it's fiendishly complex, so any advance insight that might affect the coordination of the implementation would be appreciated, I'm sure. [14:56] hm... looking at the spec is still on my list [14:57] heh :) [15:01] What am I supposed to do with the debian/watch file if the source is only available via svn? They only release the compiled package with a version number. Just put a comment in it specifying why it doesn't work? [15:03] Piratenaapje: don't create it at all, but create a get-orig-source target in debian/rules [15:03] Piratenaapje, Yes. Also make sure you have a good get-orig-source rule, and detail which SVN revision you pulled in README.source [15:03] and ask politely upstream about creating source packages with their releases :) [15:04] Alright, thanks [15:04] pochu, lintian complains if the watch file doesn't exist. One that is entirely comments causes uscan to complain, but doesn't break it. [15:05] persia: lintian warning? [15:06] I prefer a lintian warning than a useless watch file, but YMMV [15:07] Add a lintian override, if its genuinely impossible to create an appropriate watch [15:08] Well, lots of packages in Debian seem to have useless watch files, which is why I suggest that procedure. [15:08] Anyway, doesn't really matter: the important thing is to get the get-orig-source right. Even if the warning is displayed, with the correct README.source, it shouldn't affect anything. [15:15] * hyperair attempts to use qemubuilder with ia64 [15:17] Hmm the program I'm trying to package depends on something that isn't yet packaged, I should package that first I guess? [15:18] Piratenaapje: Yes. [15:19] And that relies on 3 unpackaged programs, aargh [15:24] Piratenaapje: One step at a time. [15:24] jpds: I'm still a newbie, so I'm going to try to find something easier to package :p [15:25] Piratenaapje, Unless you already use something unpackaged, or otherwise find it essential, I'd recommend not packaging something new. [15:26] It's a lot of work, one of the harder ways to learn, and won't have much benefit if you're not going to use it (or you don't have several users clamouring, who you need to support). [15:26] persia: Well, there is still one package I currently use, and which isn't packaged yet [15:26] That's the one to chase then :) [15:26] persia: the one I was trying to package wasn't something I used though :p [15:26] That's usually just a waste of time then. === _neversfelde is now known as neversfelde [15:50] persia: Just found out it has an unofficial repository, so no need for me to package it :p [15:50] I wonder why there's a need-packaging bug though [15:51] persia: What would you recommend me to do to start out? [15:51] hey, I've got a quick question for dcsharp at revu: http://revu.ubuntuwire.com/details.py?upid=4756 - There's a legal issue for two files: http://revu.ubuntuwire.com/report.py/legal?upid=4756 [15:51] Unofficial is unofficial: if you'd like to work the maintainers of the unofficial repo to make it official, that's useful. [15:51] is that issue minor? [15:54] savvas, The generatepot.sh issue is probably minor, but worth an upstream bug. The run_uninstalled.sh matters if it gets included in the binary, but can probably be overlooked if it's only in the source (but also deserves a minor upstream bug). === ssweeny_ is now known as ssweeny [15:54] thanks! :) [15:55] persia: so (for future issues) all files with +x have to include a license? [15:55] savvas: actually both files are 4 line shell scripts, so don't worry about these [15:55] persia: Hmm, guess I'll mail the maintainer of the repo, but where would you recommend me to start now? [15:56] savvas, No. All files need to be licensed. How a file is licensed depends on the type of file, and the license of the source, and the language used in overview licenses, etc. [15:56] ok, thank you both :) [15:56] Loose rule of thumb is to complain to upstream for each file for which you're not sure of the license, and only really care about any source files that end up being part of the distributed binary. [15:57] on my way, I'll let upstream deal with it :P [15:57] persia: erm, nope [15:57] persia: debian/copyright applies to source + binary package [15:58] persia: you can't have indistributable files in the source package [15:58] however licensecheck output doesn't necessarily mean indistributable [15:58] sistpoty|work: so your suggestion is to ignore the legal warning at revu? [15:58] sistpoty|work, Find me more than 4 .png files in the Ubuntu archive with appropriate copyright attribution and licensing information. [15:58] savvas: yep, licensecheck is a tool that can *help* you check for problems, it doesn't do the job on its own though ;) [15:59] savvas: The 'Legal' thing at revu is just a very rough cut. It needs intelligence applied to it's output. [15:59] sistpoty|work, In principle, I agree, but there are many cases where small, unused files are not considered (but are still worth upstream bugs). [15:59] persia: indistributable != no copyright attribution (in the file) [15:59] persia: e.g. if upstream provides a readme that says "all .png files are (C) bla bla and can be distributed..." that's ok [16:00] sistpoty|work, Ah, right. Yes. Every file must be distributable, but having copyright attribution in the file or license information in the file isn't so important. I agree. I still think copyright attribution and license information ought be in every source file that ends up in the binary (either directly or a compiled result) just as a rough guide to making sure it's safe. [16:01] This is the debian/copyright file of dcsharp package, for reference: http://paste.ubuntu.com/110890/ [16:02] persia: from a legal POV, it's completely enough if a disclaimer is in a readme or so, however it's a great win for anyone reusing some source code, if the attribution is in the file itself [16:03] (as I've been doing nothing else to chase every single file from FAUmachine for it's origin for the last two weeks, and I'm that tired of diffing files now *g*) [16:03] sistpoty|work, Yeah, that's why I care about stuff that gets used :) [16:04] persia: there's no distinction between gets used and just in the source package :P [16:04] persia: so to sum up, ideally, to make licensecheck happy, it would require a license like GPL on the header of the .sh scripts? [16:04] sistpoty|work, From a legal POV, not at all. From the POV of someone pulling a bit of code that does something useful, probably, as unused code is often forgotten. [16:05] savvas, Indeed. I usually even ask for GPL headers on .xml files that provide critical configuration or build instructions or similar functions. [16:07] savvas, But the point isn't to make licensecheck happy. The points are 1) to ensure that the contents of the package are properly attributed and licensed, and 2) to make it easy to reuse portions of the code when such reuse is permitted by the license. [16:08] #1 is a legal requirement, and #2 is the "win" sistpoty|work mentioned before (and for some licenses may be a license requirement: the "How to use the GPL" section of the GPL is a useful read) [16:11] persia: for what licenses is #2 a requirement? [16:13] sistpoty|work, GPL requires at least copyright attribution at the start of each source file. [16:13] persia: where does the GPL say that? [16:13] I don't happen to know of other cases offhand, but I can imagine them. [16:14] In the "How to Apply These Terms to Your New Programs" section. [16:14] persia: these are *not* part of the license! [16:15] sistpoty|work, OK. [16:15] * persia plans to continue to be annoying about detailing attribution for source files, but won't claim it's a GPL requirement anymore [16:16] persia: if you can manage to convince upstreams, you'd definitely make me very happy :) [16:17] Well, it's generally by proxy, but I've seen a number of upstreams produce full GPL headers for all source, random shell snippets, .xml files, and other random bits as a result of requesting them on REVU. [16:18] :) [16:18] From what I've heard, most upstreams are happy to apply a provided patch including the headers against their VCS, as long as someone else does the work [16:19] This may have issues when the source of the code is unclear, but for small projects that haven't borrowed much, it's often a good route. [16:22] sent upstream: http://code.google.com/p/dcsharp/issues/detail?id=17 [16:23] savvas, If you can lower the priority, and include a patch with the relevant GPL header and copyright attribution based on the Vcs history, you'd get faster adoption. [16:24] (e.g. run svn blame or bzr blame, and look up their names) [16:25] persia: I don't actually know how to lower the priority on google - I can't see an option for it either, it's probably reserved for the authors [16:25] I can do the patch however :) [16:25] savvas, Fair enough. The second part oughtn't be reserved though. There's apparently also a git-blame (I don't use git much). === dholbach_ is now known as dholbach [16:32] does anyone know how to send patches to googlecode ? [16:33] I suppose I can just copy/paste it as a comment [16:34] ah wait, found it! [16:35] when you click on the comment text field, it shows "attach a file" below :) [16:47] quadrispro: You've asked for sponsorship of another bug, what was the bug #? [16:48] could someone sponsor bug #322377 for me please? [16:48] iulian: mmm perhaps it was macchanger-gtk... [16:48] Launchpad bug 322377 in sigx "sigx FTBFS on all platforms" [Undecided,New] https://launchpad.net/bugs/322377 [16:49] jmarsden: ping [16:50] quadrispro: What is the bug #? [16:50] iulian: ? [16:51] iulian: you've uploaded rosegarden this morning... [16:51] #321364 [16:53] hyperair: I'll do it [16:53] the other bug was #321504 (I hope I've understood well), it has just been fixed [16:53] quadrispro: I was talking about bug #321504. I see it's already fixed. [16:53] Launchpad bug 321504 in macchanger-gtk "Small typo in debian/control" [Low,Fix released] https://launchpad.net/bugs/321504 [16:53] iulian: yes! :D [16:53] mok0: thanks [16:53] Heh, OK then. [16:54] iulian: but.. if you have some spare time... there's w-scan, which needs a sponsor :) [16:54] iulian: http://revu.ubuntuwire.com/details.py?package=w-scan === azeem_ is now known as azeem [16:57] quadrispro: OK, I see that mok0 already advocated it. I will review it this evening. If it's OK I'll upload it. [16:57] * pochu plays a bit with piuparts for the first time [16:58] thank you iulian [16:58] Ahh, the homepage is written in German. [16:58] * iulian doesn't understand German :( [17:03] iulian, Thanks for stepping up. You've started the clock :) [17:04] Excellent. [17:08] iulian: yes, only in gemrna [17:08] german * [17:09] * ScottK notes that JontheEchidna is now a MOTU and fair game for reviews. [17:09] * JontheEchidna waves [17:09] JontheEchidna: congrats! [17:09] thanks! [17:10] JontheEchidna: Congratulations! [17:10] JontheEchidna: congrats [17:10] iulian: that application is very useful, as I said to mok0, I use it at work for scanning DVB-T channels information [17:10] ^_^ [17:10] iulian: way to step up! [17:10] quadrispro: Cool, just out of curiosity, is upstream active? [17:11] LaserJock: :) [17:11] iulian: yes, he seems active [17:11] quadrispro: Or did you have the chance to get in touch with it? [17:11] Oh, OK, cool. [17:11] quadrispro, wasn't there a wnpp bug filed in debian about it? [17:11] i coulda sworn someone did the packaging for it already [17:12] superm1: not yet [17:12] Debian bug #426390 [17:12] Debian bug 426390 in wnpp "ITP: w-scan -- Scans DVB-T and DVB-C transponders for channels" [Wishlist,Closed] http://bugs.debian.org/426390 [17:12] ah! [17:12] lol [17:13] look in their svn. they should have packaging all ready to go too [17:13] i don't know what eventually happened [17:14] It seems that the ITP is closed. IMHO, they don't seem to be interested in packaging it anymore. Altought I might be wrong. [17:14] superm1: you're right [17:15] it has been closed due to inactivity [17:15] quadrispro, http://svn.debian.org/wsvn/pkg-vdr-dvb/dvb/w-scan/?rev=0&sc=0 [17:16] superm1: then, why that bug has been closed?? [17:16] quadrispro: You might want to get in touch with him to see if he's still interested in. [17:17] quadrispro, i actually had some email conversation about this with Tobias Grimm. let me dig it up [17:17] ok === warp10_ is now known as warp10 [17:18] quadrispro, it looks like the package didn't actually have a gpl license in it's latest binary at the time that the packaging was made. i apparently sent an email to the author and latest binaries are fixed [17:18] so i'd say ping tobias grimm and see if he is going to release the package to experimental at least, and maybe offer to help finish the ITP? [17:20] I can give my help, if needed [17:20] quadrispro, if nothing comes of that, i'd say further pursue your revu package, but it's much more preferable to get it into debian (especially since most of the hard lifting is done) [17:21] I'd like to see that in Debian as well. [17:21] superm1: sure [17:22] superm1: I use almost everyday w_scan and I will work on future syncs/merge from debian [17:23] let me know! [17:23] :) [17:24] quadrispro: Rather, you can be the one to do the updates in Debian [17:24] (!) [17:25] quadrispro, i sent an email to Tobias with you CC'ed, so hopefully between the two of you this can get done [17:27] perfect! thanks [17:27] superm1: Could I talk you into looking into some residual bluetooth problems we're still having in KDE? [17:28] going away, bye! [17:28] ScottK, perhaps, what types of problems? [17:29] ScottK, mind you, i've not been close to the code for a while, so my utility might not be spectacular, upstream may be better depending on the problems [17:29] superm1: If you look at Bug 280997 there is a lot of "It works" and "It doesn't work". I was hoping you could sort through it a bit and see where there are real bugs. [17:29] Launchpad bug 280997 in kdebase-workspace "solid-bluetooth needs update for bluez 4.x" [High,Fix committed] https://launchpad.net/bugs/280997 [17:29] superm1: Way better than mine. [17:30] ScottK, are you referring to looking on jaunty or intrepid? [17:31] superm1: I'm primarily worried about Jaunty. For Intrepid the situation is definitely better than it was. [17:31] If we get some patches we can backport, great, but I'm not so worried. [17:31] If solid-bluetooth still has broken bits I want to get actionable bug reports upstream ASAP. [17:31] ScottK, so on jaunty, what would I need to add to an ubuntu install to evaluate the situation? [17:32] Maybe they fix it for 4.2.1.... [17:32] superm1: The fixes are in the standard Kubuntu packages for Jaunty. [17:32] So I'd guess sudo apt-get install kubuntu-desktop would do it. [17:32] ScottK, yeah but i'd prefer not to pull a whole kubuntu-desktop, so what's the subset i'd need? [17:32] kdebluetooth4 i'd guess [17:33] yeah [17:33] mok0: A new version of the package you advocated is available in upstream, should I wait with uploading it to revu? [17:33] Not sure what else or if that'll pull in whatever you need (it should, at least in theory). [17:34] Piratenaapje: yes, you may introduce new problems [17:35] mok0: Ok, I'll just wait and try to get another advocate then :) [17:35] Piratenaapje: yes, then worry about upgrading later [17:49] Any MOTUs available to give the second adovation to osm-gps-map, a GTK widget to embed openstreetmap? http://revu.ubuntuwire.com/details.py?package=osm-gps-map - Thanks! :) [18:01] * sistpoty|work calls it a day... cya [18:09] AndrewGee, your get-orig-source will always get the freshest source from git, this is it correct for get-orig-source but unfortunately, you name your tarball according to debian/changelog, this is incorrect, it should match the fresh sources instead. [18:10] fta: I'll get that changed now... [18:10] AndrewGee, working with snapshots means that get-orig-source should have enough intelligence to figure out the upstream version and (if possible) something to identify the particular snapshot that has been fetched. [18:11] AndrewGee, is 0.1 an existing upstream release? [18:11] fta: Yeah. [18:11] ok, so 0.1+ is fine [18:11] Okay. [18:14] i would personally use 0.1+gitYYYYMMDDrXXXXXX where XXXXXX is a part of the tip revision id but 0.1+gitYYYYMMDD is acceptable too if upstream is a small project [18:15] I'd rather make get-orig-source get the revision pointed out by debian/changelog, but that's just my personal opinion [18:15] I go with dates for compiz since not a lot tends to change there [18:16] Well, it does change but all at once [18:16] pochu: but bpp says otherwise [18:16] bpp? [18:16] pochu, iirc, the debian policy says get-orig-source must take the freshest [18:16] that's weird [18:17] pochu: best packaging practices [18:17] if I want to sponsor someone's package, and I need to get the tarball using get-orig-source, mine won't necessarily be the same as my sponsoree [18:17] hyperair: are those written somewhere? :) [18:17] http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-origtargz [18:17] my bad. it wasn't bpp [18:17] it was the debian/rules spec [18:18] pochu: http://www.debian.org/doc/debian-policy/ch-source.html <-- see here under get-orig-source [18:18] pochu, http://paste.ubuntu.com/110956/ [18:19] fta: where did you get that from? [18:19] fta: copy pasted from the url? [18:19] yes [18:19] thanks folks [18:19] still, my use case isn't solved by that :) [18:19] fta: ah damn, i was hoping there would be a local copy somewhere in some package [18:19] hyperair: there is, developers-reference package [18:19] pochu: then write a get-current-orig-source or something =p [18:19] heh [18:20] ooh [18:20] hyperair: debian-policy in this case actually [18:20] developers-reference eh [18:20] cool [18:20] pochu, i add get-current-source in the packages i create or maintain [18:20] fta: I add debian/watch ;) [18:20] pochu, i like packaging snapshots [18:20] pochu: if debian/watch worked, you wouldn't need get-orig-source ;) [18:20] pochu, you do releases ;) [18:21] fta: snapshots meaning? [18:21] hyperair: $vcs snapshot [18:21] random commits from the upstream VCS tree [18:21] fta: but how dyou identify which commits to take? [18:22] but right, I usually package tarballs [18:22] I've actually only packaged snapshots for one package (emesene) for which I wrote a get-orig-source [18:22] but it took the revision to retrieve by parsing changelog on request of my sponsor IIRC [18:22] hyperair, i usually do that dynamically with info from $vcs log --limit 1 [18:23] fta: basically the most current snapshot? [18:23] it was this one: http://svn.debian.org/viewsvn/python-apps/packages/emesene/tags/1.0~r1137-1/debian/rules?rev=759&view=auto [18:23] hyperair, yes, because that's what you fetched [18:23] speaking of packaging snapshots, i wonder if something similar could be done in the case of stackswitch. [18:24] pochu, yep, but it's obviously not what the debian policy wants [18:25] pochu: in which case fta's get-current-source would come in handy =p [18:25] yeah, I didn't know that back in the time [18:25] policy doesn't mention get-current-source though does it [18:25] i added such a rule to gwibber, hold on [18:25] hyperair: it doesn't [18:26] even get-orig-source is optional [18:26] which doesn't mean you can't implement it [18:26] right [18:26] pochu: true, but since there isn't such a standard, different people might come up with different names [18:26] ah, sure [18:26] like when i said get-current-orig-source [18:26] hyperair, http://bazaar.launchpad.net/~gwibber-team/gwibber/packaging/annotate/head%3A/debian/rules [18:27] but if I create it, I'm doing so for myself mostly ;) [18:27] it's using bzr, not git [18:28] Laney: could gtk2hs needs a no-change rebuild? [18:28] maybe [18:28] need * [18:28] is it installable? [18:28] Laney: i'm doing some test [18:28] fta: DEBIAN_NAME := $(shell dpkg-parsechangelog | sed -n 's/^Source: *\(.*\)$$/\1/ p') <-- does this work from any directory? [18:29] hyperair, it's smart to let me do things like: debian/rules get-orig-source DEBIAN_TAG=RELEASE_1_2_3RC1=1.2.3~rc1 to create foo_1.2.3~rc1.orig.tar.gz in addition to random snapshots [18:29] that's pretty cool. [18:29] s/smart/smart enough/ [18:30] dpkg-parsechangelog expects debian/ in the current directory [18:30] fta: which will fail if you call from any other directory than the top directory [18:30] fta: the spec mentioned that get-orig-source is required to be able to function from any directory [18:31] well, you're right but no one ever complained about that [18:32] heh yeah. quite a few MOTUs don't seem to notice either while reviewing packages. =p [18:32] and i do a lot of snapshots: https://edge.launchpad.net/~fta/+archive/ppa/+index?batch=150 [18:32] fta: i know, i use your ppa. firefox-3.1 stuff [18:32] :) [18:33] oh yeah, would you know where i can get my hands on an ia64 buildd? [18:33] qemubuilder doesn't support ia64 [18:33] nope, sorry [18:33] sigh [18:33] debian, maybe [18:33] i've got a ftbfs issue, and i'd like to test a fix before i propose a debdiff to be sponsored [18:34] package is codelite. works on everything but ia64 [18:36] AndrewGee, your debian/libosmgpsmap0.symbols is wrong too [18:36] quadrispro: Why do you think it might need one? [18:37] AndrewGee, http://paste.ubuntu.com/110959/ [18:37] Laney: it's installable [18:37] yep [18:38] w.r.t. get-orig-source working in any directory: dpkg-parsechangelog -l$(dir $(firstword $(MAKEFILE_LIST)))/changelog [Relies on you using it in debian/rules directly, not an included thing somewhere else] [18:39] maxb: that looks interesting [18:39] firstword? [18:40] ls [18:40] uh whoops [18:40] maxb, i tend to think it's not worth it, there's always a case that fails. the place it has to work it where the debian/ dir is, everything else is just bonus [18:40] -it+is [18:41] I agree it's quirky that policy sets different requirements for that one target [18:41] i wish DPKG_GENSYMBOLS_CHECK_LEVEL was set to 4 by default so people would really care about symbols in libs === ivoks_ is now known as ivoks [18:42] fta: why? [18:43] fta: in the case of C++ libs, the *.symbols file is a pita due to name mangling [18:43] so it will FTBFS if symbols appear or disappear, that usually requires attention, check for ABI stability, etc. [18:44] OT, Does someone know how to run a custom command each time the lid is opened/closed? [18:46] ah, found it (/etc/acpi/lid.sh) [18:48] AndrewGee, do something like: dpkg-gensymbols -plibosmgpsmap0 -Odebian/libosmgpsmap0.symbols -v0.1 === paul_ is now known as Elbrus [19:03] how do I find out who built a package? [19:03] I found a bug with the package secpanel. [19:07] quentusrex: I think the build daemons are the only ones who build packages. [19:08] quentusrex: However you should be able to find out who last uploaded the package by looking in /usr/share/doc/secpanel/changelog.Debian.gz [19:13] Hmm I have a problem: There isn't a location I can put in the debian/watch file, and there isn't a svn for the program. Can I get away with just providing the current original tarball? [19:14] LaserJock: (very delayed) ack... I was out at a client site, just got back to my office... Hi! [19:14] Where did you get it from then? [19:15] ScottK: from their site, but I get a 403 error with uscan if i try to look into the directory [19:15] Ah. [19:17] ScottK: isn't it linked from the homepage? [19:17] * ScottK didn't read all the backscroll. [19:17] * ScottK goes back to his kdepim SRU. [19:19] Piratenaapje: that intended for you [19:19] ScottK: nvm [19:19] pochu: Hmm yes [19:20] pochu: Am I supposed to parse the homepage? :s [19:20] Piratenaapje: it's easy [19:20] Piratenaapje: see uscan(1) [19:21] ah ofcourse, I see [19:21] silly me [19:28] ScottK, well the GUI tool in KDE isn't even showing devices for me in jaunty, whereas the gnome tool is [19:28] OK. I only have Intrepid here, so my ability to mess with it is limited. [19:28] does kubuntu do daily live disks? [19:28] Yes. [19:29] That and I have a sum total of one week experience messing with bluetooth. [19:29] That was the week between when I upgraded to Intrepid and then bluez4 got uploaded. [19:29] well it's pretty clear when it either "Works" or "doesn't work" [19:30] My experience with Intrepid is 'works about like it did with bluez3'. [19:30] Which for Intrepid, is, I think, a win. [19:33] can something evil running in a chroot break your system? [19:33] yes [19:33] if it has or gets root access within the chroot, it can escape [19:35] I thought they were secure... [19:36] and builds are done with root [19:36] pochu: builds aren't done as root [19:36] pochu: there's a user called buildd i think [19:36] hyperair: pbuilder? [19:36] pochu: think so [19:36] pochu: regarding chroot breaking, you can do it with perl [19:36] i'm not sure if it's doable with sh though [19:36] do what? [19:37] break out of a chroot [19:37] Hmm, I still can't figure out how to do it with uscan, manual wasn't too much of help :s [19:38] pochu: root access is needed because in order to break out of a chroot you need to chroot twice more [19:38] Piratenaapje: it's basically: http://homepage.com/ http://homepage.com/page/where/the/package/is/package-(.*)\.tar\.gz [19:38] hyperair: so if the build isn't done as root, it's safe? [19:39] for builds [19:39] pochu: yes it is, unless there's some SUID binary somewhere [19:39] pochu: make that exploitable SUID binary [19:39] Piratenaapje: if you can't still make it work, tell me the link and I'll try [19:39] hyperair: oh [19:39] hyperair: I hope there's not those things in the archive :-) [19:40] (those malicious things) [19:40] probably not [19:40] mok0 uploaded a virus to the archive yesterday. [19:41] heh [19:41] Of course it was a representation of the SARS virus, not the computer kind. [19:41] hello people [19:41] ScottK: as long as he doesn't upload it to Debian I'm safe :) [19:41] hey hey emgent! [19:41] LTNS [19:41] That would expain why upload.u.c is down. [19:41] * pochu prepares an SRU for intrepid [19:42] hey emgent [19:44] pochu: I feel a bit stupid, but still haven't figured it out yet. [19:44] "https://www.getdropbox.com/downloading?os=lnx https://www.getdropbox.com/download?dl=packages/nautilus-dropbox-(.*)\.tar\.bz2" is what I'm trying with now, but it doesn't find any hrefs that match :s === hyperair_ is now known as hyperair [19:47] Piratenaapje: try removing https://www.getdropbox.com from the second url [19:48] Piratenaapje: if you look at the html source, the url for the tar.bz2 link is relative to the domain [19:48] Piratenaapje: so that's why uscan was failing, I suppose [19:48] pochu: No change :s [19:49] ok, let me try [19:50] Piratenaapje: just some strange idea, does the ? need escaping? [19:50] pochu: Ok, thank you [19:50] Elbrus: Yes, that was it, it works now :D [19:55] dpkg-source seemingly doesn't look at .tar.bz2 files, so I have to make a .tar.gz myself? [19:56] pochu: http://pastebin.com/f1a87abec [19:56] shit wrong paste [19:56] pochu: http://pastebin.com/f48ec404c [19:58] Piratenaapje: I think so, but the support for bz2 is supposed to come, but until then, rezipping the tar file. [19:59] Elbrus: alright, thank you [19:59] Piratenaapje: yes, but don't unpack the tar, just bunzip and gzip -9 the resulting tar [19:59] http://pastebin.com/d5cbf8341 <-- this works too [19:59] hyperair: looking [19:59] pochu: in debian/rules I suppose? [20:01] Piratenaapje: nope, DIY [20:01] Piratenaapje: you can also tell uscan to repackage it [20:01] pochu: basically you need to get an fd for a directory, then chroot to something within that particular directory. then you do an fchdir() onto the said fd, and then keep chdir("..")-ing for a while until you think you've reached the correct root, then chroot to it. [20:01] it has a --repack option or so [20:01] pochu: ok, back to reading the manual [20:02] hyperair: interesting. and perl looks easier than I thought :) [20:02] pochu: heh. a lot of functions are similar to C. i think i can make that script in python too [20:03] my programming fu is rather low, but I'm improving :) [20:04] hmm [20:04] * pochu wonders if he can manually modify a .dsc and later debsign it [20:04] hyperair: But, fundamentally, all these chroot escapes rely on the code that enters the chroot not doing a complete job, right? [20:04] pochu: "debsign" is a command :-) [20:05] maxb: complete job meaning setuid(non-zero)? [20:05] maxb: exactly :) [20:05] hyperair: Even if you are root inside the chroot, you still need an fd to a directory outside to escape, by the methods shown so far [20:06] actually I want to modify the .changes, which is better as I won't have to fiddle with the checksums [20:06] maxb: no, all you need is to chroot deeper [20:06] Oh! [20:06] maxb: by carrying out an incomplete chroot on your own, you can carry out the breaking operation [20:06] hyperair: This is why the grsec chroot restrictions exist. [20:06] oojah: what restrictions? [20:07] like denying chroot() within a chroot(). [20:07] like denying chroot() within a chroot. [20:07] ah [20:07] yes [20:07] if that's possible it would prevent breaking out [20:09] Is this the right channel to ask packaging questions? [20:09] vadi2: Provided they are Ubuntu packaging questions :-) [20:09] vadi2: but of course [20:09] what time does the REVU day start?\ [20:10] http://pastebin.com/f1645a593 <-- chroot breaking script in python [20:10] hyperair: This is what I have: http://pastebin.com/d2e1214a2 [20:10] It's things like that that need to be merged before grsec disappears. [20:10] I have this as my postinst script http://paste.ubuntu.com/110983, however the package fails to install if the command does not exist [20:10] Is there a more proper way to check? [20:11] vadi2: I think you want ` ` around the which app-foo [20:11] oojah: ouch. i can't break out of that [20:11] i.e. if `which update-app-install` ... [20:12] vadi2: and &> is a bashism AFAIK [20:12] pochu: I don't think that's correct [20:12] http://paste.ubuntu.com/110985/ ? [20:12] you should do > /dev/null 2>&1 instead [20:12] sure [20:12] The point is to test the exit status, not the the textual output [20:12] hyperair: http://pastebin.com/d6a61903b :) [20:12] maxb: ah [20:12] oojah: hahah [20:13] http://paste.ubuntu.com/110986/ ? [20:13] I don't know why it's not in the kernel by default. [20:13] Ooh, late for beer. Bye! [20:15] maxb: both work, with and without `` [20:16] vadi2: you're missing a ';' after /dev/null [20:16] ok, thank you [20:17] vadi2: I suggest looking at the postinst of the app-install-data-partner package for an example of how an existing ubuntu package does exactly what you are doing [20:17] maxb: hey thanks [20:17] I didn't know which package to look for, so started on my own [20:18] vadi2: If you have the package installed, you can see its postinst at /var/lib/dpkg/info/app-install-data-partner.postinst [20:18] hm, I don't, and can't find it [20:18] ScottK: libextlib-ruby, libstomp-ruby in debian new [20:19] Is it okay to call the tarball created in a get-orig-source rule, to grab from a git repo, PACKAGE_latest.orig.tar.gz? [20:21] AndrewGee, absolutely not [20:22] directhex: Okay. I'll try and work out what version it's downloading then... :) [20:22] maxb: where can I get this package from? [20:22] AndrewGee, how would you tell the difference between PACKAGE_latest.orig.tar.gz and PACKAGE_latest.orig.tar.gz? [20:23] directhex: Right. [20:29] superm1: great work! I hope to see w_scan entering in experimental as soon as possibile :) [20:30] cody-somerville, jdong, nxvl: hi, mind having a look at bug 287158 for an SRU ACK? The debdiff is quite trivial [20:30] Launchpad bug 287158 in wesnoth "wesnoth crashed with SIGSEGV in malloc()" [Medium,Confirmed] https://launchpad.net/bugs/287158 [20:33] pochu, acked [20:34] cody-somerville: thanks! [20:36] anybody running intrepid and liferea? [20:39] i am [20:41] vadi2: mind trying liferea from intrepid-proposed and telling me if it runs fine? [20:42] Ok, sure [20:45] vadi2: thanks [20:49] pochu: 1.4.18-0ubuntu2.1 ? [20:49] vadi2: yes [20:53] pochu: seems to work fine. I did have some inconsistency in unread items / bolded headlines, but it always does that, so it's ok [20:53] vadi2: good, mind saying so in bug 295490? [20:53] Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Fix committed] https://launchpad.net/bugs/295490 [20:53] vadi2: thanks for testing :-) [20:54] oh, well it definitely started. np [20:58] maxb: any idea on how can I get the app-install-data-partner package? [21:00] Uploading wesnoth_1.4.5.orig.tar.gz: 3233k/169579k [21:00] ouch! [21:00] I don't need to upload the orig.tar.gz if it's already in the archive, do I? [21:01] btm: I'll need access to the package as uploaded. I can't get them from Debian New. [21:01] Anyone know what the limit of versions are for Universe? For example is RC1 software allowed? [21:02] Chris`: It is, but generally we prefer to stay with releases. [21:02] pochu: my script still errors out with the `'s added :\ [21:03] vadi2: can you pastebin it? [21:03] http://pastebin.com/m1c6d4f19 [21:07] vadi2: and can you pastebin the error? [21:07] vadi2: does running `/bin/bash postinst` error out too? [21:08] bad &> [21:08] especially when sh is dash [21:08] right [21:09] and the test may fail miserably if gnome-app-install is not installed [21:09] (no idea if that could happen for that package) [21:12] i would use "if [ -x /usr/sbin/update-app-install ] ; then" [21:18] mok0: codelite ftbfs on ia64. is there any way i can test a fix for it? [21:20] fta: the point is to check for it [21:20] I'll try that, thank you [21:22] ScottK: they're on mentors.debian.org [21:22] Am trying to build kvm-83 with "debuild -S -sa". Problem is that it complains about not having any rules to setup config-host.mak. That file is created when running configure on the program manually. How can I make debuild build it? What have I missed? I have followed the guides on wiki about package upgrade. So I have everything in debian/ folder from last build.. [21:23] btm: OK. Thanks. Who sponsored them? [21:23] vadi2: if [ -x /usr/sbin/update-app-install ]; then (newline) update-app-install || true (newline) fi is what app-install-data-partner does [21:23] btm: Also my box that's set up for uploading just died, so my schedule is a bit delayed... [21:24] maxb: thank you very much [21:24] Here is the output from debian -S -sa http://blinkiz.pastebin.com/d3ba05a09 [21:24] ScottK: thom uploaded those two. [21:28] ScottK: I don't know how much he looked them over, but the binary changes is lintian 2.2.0 clean on etch and pbuilder clean on lenny. If you have any comments I'd appreciate them of course. [21:31] OK. [21:31] After I get done figuring out why my laptop insists the hard drive is full when it is not. [22:48] anyone on bug #322513? [22:48] Launchpad bug 322513 in mpd "Please merge mpd 0.14.1-1 (universe) from Debian unstable (main)." [Undecided,Confirmed] https://launchpad.net/bugs/322513 [22:49] quadrispro: is it urgent? [22:50] james_w: it isn't at all [22:50] k [22:51] I was trying to know if there's some one who haven't nothin to do at the moment :D [22:51] seems like there's no need to bring it up on IRC if it's in the sponsor queue then? [22:51] ah, ok :-) [22:52] * james_w also advertises http://people.ubuntu.com/~dholbach/sponsoring/ for anyone without anything to do :-) [22:52] james_w: Are you handling it, or do you want me to? [22:52] what does SAUCE: mean in ubuntu kernel update context ? [22:52] nhandler: I was just heading to bed, so please go ahead [22:52] (hi) [22:52] proppy: [22:52] #ubuntu-kernel will know better than us [22:52] :) [22:52] james_w: thanks for pointing that out [22:53] I know it's something to do with the intent of the patch, but I can't remember the rules [22:53] i'm going to sleep [22:53] by james_w [22:53] bye * [22:53] night quadrispro [22:55] If anyone has a minute to review http://revu.ubuntuwire.com/details.py?package=wxbanker I would greatly appreciate it, I'd love to get it into Jaunty :) It is a fairly simple cdbs package of a python-distutils app === hggdh_ is now known as hggdh [22:57] I feel sad, upstream is hostile =```( [22:59] <_16aR_> Hello [23:00] Hi _16aR_ [23:03] xnox, which upstream? there's a scale of hostility [23:03] and strangely, "slomo can choke on a bucket of cocks" is only halfway up that scale [23:04] directhex: Hm... I forget. Which upstream was that? It was something gstreamer-related, IIRC :) [23:04] directhex: www.crosswire.org [23:05] RAOF, http://bugs.debian.org/477454 [23:05] xnox, oh, right, bible stuff. i'd expect hostility by nature [23:05] Ah, yes. That one. [23:05] xnox: it's being worked on [23:06] lots of frustrations and misunderstandings, it happens [23:06] directhex: yeah they don't want me to package bibles along with the bible software. But they complain that the software is old in the repos to the ubuntu-motu [23:07] xnox, i think scientology has the right idea - don't let anyone see your doctrines without forking out fat cash [23:07] It's just I saw this as an opportunity to work on packaging, since there was need and noone was doing it. I'm not even religious. [23:07] xnox: it's not exactly that straightforward, but it's somewhat frustating yes [23:07] They were just here recently to start working on updating it [23:07] the problem is that the bible reading software already has module management built in [23:07] ScottK: I'm one of those =D launchpad.net/~pkgcrosswire and we have alioth as well [23:07] that kinda gets messed up when we do system-wide installs via apt [23:07] Ah [23:08] so it's not simply "don't package our stuff" [23:08] I've made a really nice proposal. Which will solve that and it will not require any changes from their side. [23:08] They said:"No. No modules should be in the repo's." and then like three more emails "No. No. No." [23:09] xnox: right, just keep reading [23:10] My idea was to make the packaged modules generate a local repository in their format in eg /usr/share/crosswire. So that their management can install from there [23:10] <_16aR_> Is it possible to have 2 original maintainers ? [23:10] _16aR_, sorta [23:10] _16aR_, but in debian/control, no [23:10] you can have Uploaders [23:10] which is like co-maintainer [23:11] all the cool kids are Uploaders [23:11] LaserJock: english is not my mother tongue by "right, just keep reading" do you mean sort of "hang in there...." [23:11] * xnox wants to be a cool kid :````( [23:11] which, ironically, doesn't mean you can upload the package, it means you can sign off a changelog entry without it being an NMU [23:12] * xnox lol [23:12] xnox: I mean they've also sent emails apologizing for some of that and explaining why a bit more [23:12] directhex: for DM's it does mean you can upload the package [23:12] LaserJock: I'll have to reread then [23:13] LaserJock, yeah, and for those of us with only decades left to live, the paperwork for DM or DD or IDDQD status is too much hastle [23:13] DM is quite fast [23:13] I think it took me about 2 weeks total [23:14] though i guess the rules have changes a bit since I became one [23:14] but still, it's not nearly like DD I don't think [23:15] <_16aR_> directhex: my reason is to modify a package on revu not adopted because of some missing remarks. So my job will be minimal. But I think that since I willsign the package, it must be me the XSBC-Original-Maintainer ? [23:16] _16aR_, generally. acknowledge the other guy in debian/copyright [23:17] that whole Original-Maintainer for REVU thing is awfully weird [23:17] <_16aR_> directhex: yes of course [23:18] <_16aR_> I don't want to put out his name. I want this package in ubuntu 9.04, that's all :) [23:18] <_16aR_> I will update the upstream package I think, since 2 version have come out [23:18] LaserJock, welcome to computers in general! [23:19] directhex: heh, yeah [23:20] it'd be some much easier if we used .spec files ;-) [23:20] spec files are shit [23:20] i say this as someone with 2 million quid of suse boxes [23:24] Just a question about multiverse what rules apply? cause my google-fu produced vague results. [23:26] xnox: "Is it redistributable" is AFAIK the only absolute question. Then you just need to actually find someone who wants to care. [23:27] http://www.ubuntu.com/community/ubuntustory/licensing talks about main and restricted - universe and multiverse are just the same, but without Canonical's pledge of a defined maintenance period? [23:27] RAOF: ok cool. That's what I need. [23:28] maxb: that's "sorta" how it works [23:28] IMO it's still very ill-defined and the only hope of making it easier is to get rid of Main/Universe [23:29] Surely there will always be a need for the distinction of which software Canonical does/does not choose to commit to paying people to support? [23:30] the user discrimination, what if it is for non-commercial will it get veto by MOTU's??? (or is it build farm dictators?) [23:31] can you even host "non-commercial-only" things on a canonical server? it's terribly ill-defined [23:33] maxb: well, but the problem is that Main has never been that definition exactly [23:33] and what is "support"? [23:33] directhex: non-commercial usage doesn't always put those distinctions on distribution, but it's a murky area [23:33] morning ajmitch! [23:33] in Intrepids Add/Remove it says that Canonical "maintains" all apps in Main, which is untrue [23:34] directhex: pfft, it's afternoon here, unless you happen to use UGT :) [23:34] LaserJock: "support" is the thing you can buy from canocical. So that trained experts from vancuover will give you email/web/phone based help ONLY for LTS releases. [23:34] if "support" means "you can buy commercial support for this app" then I believe Main is also not the "canonical" definition [23:34] LaserJock, if canonical want to pay me to maintain my styff in main... :p [23:34] xnox: no, LTS is different [23:34] LaserJock: and only main I think [23:35] ok, but if you look at the ubuntu.com definiton of "Main" it never once uses the term "Canonical" [23:35] support I think has also meant security fixes [23:35] Hmm, yeah, it's hopelessly ill defined, isn't it :-/ [23:36] but I don't think SRUs are garaunteed for Main [23:36] Canonical doesn't hire people to look after every package in Main [23:36] it's generally supposed to be a team effort by the Core Devs and Canonical tends to hire a lot of them :-) [23:37] * xnox wants to see the day Canonical hiring Debian =D [23:37] xnox: what do you mean? [23:37] all of Debian? that'd be interesting [23:38] xnox, a lot of the core devs are debian people [23:38] http://www.ubuntu.com/community/ubuntustory/components clearly says universe has no guarantee of security updates - but on the other hand it doesn't actually say that such a guarantee exists for main... just leaves you to assume that [23:38] maxb: right, traditionally they do say though that Canonical provides security updates [23:39] ... of course they also say they maintain all of Main [23:39] :-) [23:41] I assumed that "maintain all of Main" meant that if, up to EOL, something really really needed doing to something in main and the community weren't getting it done, then Canonical would arrange developer time. [23:41] maxb: that would be a giant assumption [23:41] and on a practical level, not true [23:42] Well, if they're not going even that far, then synaptic's description of the components is an outright lie :-) [23:42] I think so, but I doubt an intentional one [23:42] sounds more like marketing to me [23:43] but it did make me want to say "wow, assume, I don't have to maintain anything in Main anymore" ;-) [23:43] s/assume,// [23:45] so my guess is that when the archive get's reorganized it'll be better [23:46] unless Canonical claims that everything in the main Ubuntu lobes are maintained by them [23:50] i'd really rather they didn't claim that, some things are better maintained by the community that knows it [23:52] directhex: well, claim != do so ;-)