[00:39] i need help getting ati propriatary drivers to work on an ubuntu 9.10 desktop [00:40] nad_: You want to ask in #ubuntu for that [00:40] Then you want #ubuntu or ubuntuforums.org, most likely. [01:08] Hi everyone! Anyone up to advocate qt-shutdown-p? - It is a Qt program to shutdown the system at a certain time or after x minutes. It uses qdbus to send a shutdown request to the Gnome- and KDE-SessionManager or to HAL (as a last resort 'sudo shutdown -P now' will be used). http://revu.ubuntuwire.com/p/qt-shutdown-p [03:21] Greetings, folks! [03:21] hey zooko [03:27] hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me? [03:27] anyone have some time for a revu? [04:03] persia: any chance you will get some time to take a second look at mangler sometime? :) [04:32] hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me? [04:40] hi [04:40] !foo [04:40] bar [04:40] test [04:41] suji11: You mean, the “native package” comment? [04:41] RAOF: yes [04:43] hi im reading https://wiki.ubuntu.com/PackagingGuide/Basic but seems it only explain how to package/build on packages that already are on ubuntu repo,I.E. it uses apt-get source,i want a guide for packages that are not on ubuntu repo,any link??? [04:46] suji11: Normally, you get the code from the upstream developers in a .tar.gz file. The debian/ directory is then added as a patch (the .diff.gz). [04:46] RAOF: oh! [04:46] suji11: You've got what is called a “native package” - the code and the packaging are both in the .tar.gz. This is wrong, because it makes it harder to update the packaging. [04:47] RAOF: ok, what i should i do now? [04:48] im in the right place or i need to join #ubuntu ? [04:51] suji11: Generally, what this means you need to do is to copy the upstream code tarball - which is likely to be “iok-1.3.9.tar.gz” - to iok_1.3.9.orig.tar.gz, and put it in the directory above your unpacked source (the directory containing the debian/ directory). [04:51] Then debuild should pick up the original tarball, and do the right thing. [04:54] suji11: Upstream in this case means "original author": asking if you are the creator of the program. Secondly about the debian directory. The .tar.gz archive that comes with the package should (aside from in very special circumstances) be _unmodified_. In this case the original source archive (.tar.gz) should be simply the same as the archeve at https://fedorahosted.org/releases/i/o/iok/iok-1.3.9.tar.gz, all the changes to make it into an ubun [04:54] RAOF: i think before i made a mistake. i named the orig tarball as iok_1.3.9_orig.tar.gz , but now i changed it as iok_1.3.9.orig.tar.gz then build it again and sent to revu.ubuntuwire.com [04:55] suji11: ^ In response to your question in #-devel [05:00] arand: i'm not an upstream author. [05:01] arand: what should i change in iok-1.3.9.tar.gz.? [05:04] suji11: Nothing. It should be exactly the same file you got from fedorahosted. [05:06] RAOF: ok. now the problem is fixed. i'm right? [05:07] http://twitter.com/zooko/status/8884301983 [05:07] ^-- "Tahoe-LAFS v1.6 has been accepted into Ubuntu 10.04 Long-Term-Support "Lucid"! http://allmydata.org/trac/tahoe-lafs" [05:08] suji11: Yup, that looks right. [05:08] RAOF: ok:) [05:09] Okay, time for sleep. [05:11] RAOF: Can you review/advocate my package. [05:18] suji11: Sorry, no. I'm busy. [05:19] RAOF: It's ok. Thanks for your help yet. [05:41] arand: Can you review/advocate my package. [05:44] suji11: I'm afraid not, since I'm not a reviewer, or even part of ubuntu MOTU, one thing to note, is that this time of the day seems to be very much an off-hours time for all ubuntu channels, you might have better luck at some other time . [05:45] arand: ok fine. [05:45] arand: Thanks for your help. [06:13] is it good or bad practice to change version from 0. (for example 0.20090101) to directly date (that is 20090101) if upstream version is the date? [06:16] Is the upstream version ever going to be something that's not the date? [06:19] if you can future-proof versioning, it's a good idea to do so. I would leave the "0." there. [06:20] then again, there's an epoch, so it really isn't that big a deal. [06:34] this is the versioning scheme of upstream since 3 years, so I suppose it's a kind of 'stable'. Just for keeping it simple and thanks to epoch, I think I'll sponsor the debdiff with this version (without 0.) [06:34] thanks RAOF and crimsun ! [06:41] np === ttx_ is now known as ttx [07:13] james_w and/or other motu's: 'squid' is not up to date in "bzr branch lp:ubuntu/squid". It is actually two revisions stale, which caused the person who checked in the latest revision to accidentally trash the one previous to that, causing bug 519664. [07:13] Launchpad bug 519664 in squid "squid FTBFS: dh_installinit: command not found" [Undecided,Confirmed] https://launchpad.net/bugs/519664 [07:37] kamalmostafa: technically, squid isn't in the set of stuff we can upload, so this isn't the right channel (although you've highlighted the right person to investigate I think). If you can untangle it, I suspect a bug subscribed to ubuntu-main-sponsors would be appreciated. [07:39] persia: Okay, its already untangled (I've attached the simple debdiff to re-apply the missing fix to that bug). I will subscribe u-m-s. Thanks for the redirection. [07:40] persia: and maybe you could unsubscribe u-u-s for me? [07:43] kamalmostafa: Sure. Running rmadison can help you determine the component for any package. [07:45] persia: I knew it was in main -- just got distracted when I realized i should notify james_w and did my usual "u-u-s" procedure without paying attention. Thanks for the rmadison tip anyway. [08:48] www.search2.net [08:48] Um, please stop posting that in various places. [09:37] is there any way to get a totaly broken package in ubuntu fixed before release/freeze/etc? I have a complete patch and several independend test results of it, so you only need to get the tar.gz and diff.gz, create an changelog entry, push it out and it would be done. [09:38] package name:openct. fixed package here: www.opensc-project.org/debian/ (upstream website). [09:38] import from debian wont' work - debian didn't fix the package either (still using "hal" setup - which won't work on ubuntu, as hal was dropped) [09:38] anyone? [09:44] tolonuga: File a bug against the openct package in Ubuntu, describing the issue (or find one if it is already filed). Attach the patch. [09:45] If you want to wear an Ubuntu Developer hat, which might make it happen faster, add the patch and changelog entry, etc., build a new source package, and attach the debdiff. The revision for the new entry should be -1ubuntu1. [09:45] Subscribe the bug with the debdiff to ubuntu-universe-sponsors. If you have questions during the process, ask here. [10:00] is there a manual way of making a binary package(not using pbuilder) [10:01] make -f debian/rules binary [10:01] sistpoty|work, thanks will try [10:05] sorry, keyb broken, had to reboot. [10:05] persia:thanks for the help! [10:05] done - added my diff.gz, or an interdiff if that is preferered, and added ubuntu-universe-sponsor to cc: [10:06] The orig.tar.gz differs? [10:08] no, only the diff.gz [10:08] well, new version of orig.tar.gz (version 0.6.17 -> 0.6.19) [10:10] keep "unstable" in debian/changelog or replace it with "lucid"? (with "lucid" I get an error/warning form debuild -S...) [10:11] tolonuga: lucid is correct [10:13] hmm, how does an debdiff file help? in it I see all the upstream changes 0.6.17 to 0.6.19 - guess that isn't much help. [10:17] ok, everything implemented as suggested. can anyone look at bug 519713 and push the fixes into ubuntu? [10:17] Launchpad bug 519713 in openct "package outdated" [Undecided,New] https://launchpad.net/bugs/519713 [10:19] hmm, a better title would be "package outdated and totaly broken" ... [10:20] tolonuga: When working on new upstream version .diff.gz needs to be attached. But if you are working on a new Ubuntu revision then .debdiff is preferred. [10:21] ok. the diff.gz is the first attachment, so that is already there. it has "-0" in it, but you can easily change that and push it out? [10:21] also I'm looking for someone to import latest opensc package from debian into ubuntu. the ubuntu changes to the older package can be dropped (a fix that is included in the new upstream and thus no longer needed). can anyone do that too? [10:23] tolonuga: for requesting syncs, the easiest method is to use requestsync tool. It fetches the changelog entries and you can provide reason to drop ubuntu changes. [10:24] ok,will have a look === ogra_ is now known as ogra [10:39] ok, sync request send with that tool. [10:42] where are the .deb file created [10:43] hmm. is that a regression? an important bug has been fixed in opensc 0.11.8-1ubuntu2 in karmic, but the lucid package 0.11.9-2ubuntu1 does not contain the fix. [10:43] if unchanged, lucid would be a regression compared karmic with fix. [10:44] That would be a regression. If the patch isn't in Debian already, go catch your sync bug before it gets ACKed, and change it to a merge bug. [10:45] For merges, we prefer a debdiff against the revision in Debian (as we'd use the Debian orig.tar.gz) [10:45] debian testing has the new version and thus can be imported without any change - the ubuntu fix was a backport from the official 0.11.12 which fixed the issue. [10:47] So a sync would make it not a regression, and the other stuff added to 11.9-2 is also in 11.12? [10:47] om26er: one directory above [10:51] yes, the sync will remove the regression and fix other things and add the latest features from 0.11.12. a win for everyone! [10:53] Cool. [10:58] Hello, when's the next sync ? [10:58] whenever the archive-admin-of-the-day happens to run the autosync script. [10:59] persia: how frequent is that ? [11:01] Depends on the day. Sometimes once a day, sometimes twice, sometimes not at all. [11:01] well, swt-gtk has entered testing few days ago, yet it isn't in lucid yet [11:02] swt-gtk 3.5 that is [11:02] Maybe it's stuck in the NEW queue. Have you checked that? [11:03] No, that's not it. Just a matter of not having a sync run. [11:03] Well, there should be a sync run that happens before DIF, so I wouldn't worry. [11:03] If it still isn't present by Friday, file a bug. [11:04] DIF is on friday ? [11:04] No, DIF is on Thursday, but there are archive admins all over the world, so to avoid getting into an argument about which day of the week is the right day, best to leave some slack. [11:06] persia: ok, regarding LP #511069, should I set this to confirmed again , since swt-gtk 3.5 should get sync'ed ? [11:06] Launchpad bug 511069 in zekr "Sync zekr 0.7.5~beta3+repack-1 (multiverse) from Debian unstable (non-free)" [Wishlist,In progress] https://launchpad.net/bugs/511069 [11:07] AnAnt: Wait until it's actually present. [11:08] DIF doesn't mean we can't sync, it only means that it won't happen automatically. [11:08] ok [11:14] isn't FF already next week? [11:16] Yes. The 18th. [11:16] I have a deep suspicion that after the demand over the next week, the archive-admins will never again agree to such a close relation between DIF and FF. [11:18] * Laney is going to be going sync crazy with the new GHC transition :) [11:19] (if it is oked) [11:19] Laney: Why do you need OK, will it not start until after DIF? [11:19] Otherwise I'd expect something to slip in, so that we didn't have a choice. [11:20] it won't, and it will bleed over into FF [11:20] Oh, lovely. [11:20] Laney: is that haskell ? [11:20] yes [11:20] I tried to prepare a haskell package once, and failed [11:21] you should come to #debian-haskell [11:21] too many dependancies, flavors [11:21] Laney: I did [11:21] Laney: and they removed debhelper support [11:21] that was sad [11:21] right, cdbs is the normal way [11:21] just copy an existing library [11:23] persia: When is the final sync freeze? I think I need to request another one for ejabberd, fixing a CVE. [11:23] bug fix uploads are almost always OK [11:24] up to final freeze, then they need to be serious and minimal (security will still be alright) [11:26] Laney: … "up to the final freeze" which is when? :) [11:26] errrrrrr [11:26] https://wiki.ubuntu.com/LucidReleaseSchedule <- april 15th [11:26] Alright, I look it up myself [11:27] (maybe later for universe) [11:27] Thought you'd know it out of the head, sorry for making you hunt for it. [11:27] it's alright, the release schedule is in my history [11:29] Laney: Did you see the build log I sent yesterday [11:30] slytherin: yes, thank you. Unfortunately the interesting part was just after that step :) [11:31] but no worries, somebody else tried it on a ppc porterbox for me [11:32] great [11:36] slytherin: do you know if could/should sync jabref? from a quick look at the changelog it looks like the ubuntu delta got included in the debian package (in unstable) [11:37] but as the version string contains beta I'm not sure if we should sync or not (a sync would also allow to move it into universe) [11:37] geser: I am not very keen on syncing beta version. [11:38] ok, so we keep then 2.5 [12:00] <\sh> dholbach: when do you update http://qa.ubuntu.com/reports/sponsoring/ ? every hour or once a day? [12:01] \sh: every 15 minutes [12:01] <\sh> dholbach: cool. thx :) [12:01] once the list is smaller again I can update it more often ;-) [12:02] <\sh> dholbach: working on it ;) [12:02] ROCK! [12:10] hi, I have a problem with debconf (db_subst). This setup: http://pastebin.com/mb1f7802 doesn't work (suggested value is "${default}") [12:10] it seems to be done according to the debconf manual... [12:42] dholbach: Did you get my message in #ubuntu-kernel? My IRC client is giving weird error. [12:43] never mind found the problem [12:44] slytherin: nope, didn't get it [12:44] my nick was not identified. :-) [12:48] <\sh> dholbach: could you sponsor bug #506908 for torsten spindler? (provided an updated debdiff, so it follows our standards) (it's main, as it was wrongly added to universe sponsor queue it seems) [12:48] Launchpad bug 506908 in pcsc-lite "Upstart job for pcscd" [Undecided,In progress] https://launchpad.net/bugs/506908 [12:49] \sh: I'd prefer if somebody would sponsor it who has actually looked at an upstart job before because I haven't :) [12:50] <\sh> dholbach: for me the upstart job looks very much ok and very clean :) but I'm not keybuk ;) [12:50] <\sh> anyways subscribe main sponsors [12:50] <\sh> +d [12:51] thanks \sh [12:53] <\sh> dholbach: your expertise, should we fix those debdiffs, or just unsubscribe sponsors and waiting for bugfixer coming back with a correct debdiff ? (bug #368017) [12:53] Launchpad bug 368017 in fet "Wrong description" [Wishlist,Confirmed] https://launchpad.net/bugs/368017 [12:54] \sh: I'd prefer if we would just add the changelog entry, upload and be done with it - extra points for a small message saying "this is how I produced a debdiff" [12:55] * persia would prefer that the sponsors queue wasn't so strongly recommended to all and sundry arbitrary patch authors, and that we had a better way to catch patches. [12:55] ? [12:55] why less recommended? [12:56] Because I don't think there should be any expectation of any relation between people who submit patches to launchpad and people who care about uploading to Ubuntu. [12:56] what does that mean? [12:56] The "right way" to get something into Ubuntu shouldn't have to involve making a debdiff, although I think the "right way" for someone to do sponsored uploads to Ubnutu should. [12:56] if we would put more work into getting all the bugs with patches closed, we wouldn't need the sponsoring process [12:57] I disagree vehemently with that statement. [12:57] To me, the sponsoring process is a way that those who wish to become Ubuntu Developers can demonstrate their skills before being granted upload access. [12:57] I don't think it really matters [12:58] we should be better at spotting fixes and making Ubuntu better [12:58] I see no relation between this and any activities related to processing patches that fix bugs, except insofar as I expect Ubuntu Developers (both current and prospective) to look for patches and get them uploaded. [12:58] if somebody wishes to apply, they're happy to do that [12:58] and I encourage them [12:58] <\sh> I do understand persia... [12:59] \sh: Thanks. Sometimes it seems that nobody bothers to think about what I write :) [12:59] it's a distinction which doesn't make the world exactly easier - the bigger problem we have is that there's not enough people willing to get the 2000 bugs with patches reviewed [12:59] <\sh> the problem with debdiffs from "non wanna ubuntu devs" is that they are on the merger list for the next cycle and nobody will take care until DIF and sometimes it's too late [13:00] \sh: There's that. There's also that patch submitters get annoyed with the frustrating processes and complain about us. [13:00] ... and I didn't disagree with that [13:00] * persia doesn't want to bother spending effort training anyone to follow Ubuntu processes unless they have an interest in being part of Ubuntu, rather than just submitting bugfix patches [13:00] persia: and I didn't say you should [13:01] dholbach: No, but my argument is that conflating "sponsoring" with "patch review" implicitly makes it awkward to distinguish between the two classes of patches. [13:02] So I'd much rather see random folk told "attach a patch in a bug in LP", and have developers (both current and prospective) hounded to get those patches in. [13:02] right, it's just that the distinction between to me is much less important than getting the 2000 bugs with patches closed or tended to :) [13:02] And I think that's separate from supporting people who can do the work but just can't upload yet. [13:03] in both cases it's stuff we want to get into the distro to make it better [13:03] dholbach: I understand. I even agree that it's less important. I'd just prefer that there was more focus on looking for the patches, and less focus on telling people to use the sponsoring process. [13:04] ok, good - I probably should have said "in an ideal world we wouldn't have 2000 bugs with patches to tend to and wouldn't have to have a process which makes getting patches looked at more complicated than it should be" [13:05] in the meantime, until we can tell patch submitters apart from each other (willing to learn more about ubuntu development or not), I'd suggest attaching your debdiff to the bug, so they can take a look at it, but not block on "attaching a debdiff" [13:05] That's close to my view, but if you don't consider the sponsoring process to me the process for getting patches looked at, then you don't have that issue. [13:06] So, I7d rather say that the sponsoring process is *only* for prospective and current Ubuntu developers, and have the patch submisison process be as simple as ticking a checkmark on LP. [13:07] If you want to get more people looking at these 2000 patches, have them look there, rather than fussing with the sponsorship process in a way that makes it harder to train new developers. [13:08] we don't even cope well with the n+1 sponsoring items we have [13:09] Sure, but tossing those into the mass of unlooked-at patches only makes it worse, in my opinion. [13:09] If the sponsoring queue only contained stuff that was written by people who are now, or are seeking to be Ubuntu Developers, the quality should rise, and that should make it less annoying to sponsor stuff. [13:10] I wasn't saying "let's get rid of the sponsoring queue" [13:10] ... now [13:10] That said, we *do* need an active team to be chasing the 2000 patches, but I don't think any of them should be subscribed to the sponsors queue: that just complicates the process for submitters and frustrates sponsors. [13:12] Realistically, the sponsoring queue is where 90-95% of patches/branches from LP come from. [13:12] I don't think so. Only about 10% of patches are currently shown on your list. [13:13] But even were that true, I'd argue that we should be focusing on making that not true, rather than trying to push more patches through that mechanism. [13:13] sorry, I was unclear [13:14] I meant to say that 90-95% of the branches/patches form LP that go into Ubuntu come through the sponsorship process [13:14] Right. My argument is that this represents a failure of Ubuntu Developers to dig up patches properly. [13:14] yes, I'd very much like to see a solution to that problem [13:15] I'd much rather see strong focus on getting more developers to be proactively searching for patches than to push more patches into the sponsorship queues. [13:15] Do something! [13:15] Because lots of developers don't need to get sponsored, and so it is wasteful to push it in the queue. [13:15] eh? [13:16] So, if we say that the process for getting a patch reviewed is to stick it in the sponsors queue we 1) make the process complicated and 2) don't tell developers to go hunt patches. [13:17] If we say that the process for getting a patch reviewed is to attach it to a bug in launchpad, we 1) make the process easy, and 2) are in a stronger position to tell developers to go hunt patches. [13:17] were you in the fixing-bugs-with-patches session at uds? [13:17] If some developer fixes something and can't upload, we can fall back to the sponsors queue. [13:17] I've tried to attend that session for the past 4 UDSs. [13:17] I don't know if I was in the one you mean now. [13:18] that blueprint is the best place to discuss this :) [13:18] What7s the URL? [13:18] <\sh> last uds was usa now this time of the year is back in europe ? [13:18] \sh: Probably. It seems to mostly swap between those two and never come here :) [13:19] https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-qa-fixing-bugs-with-patches [13:19] and I think you were [13:19] but anyway, I need to head out now [13:19] see you later [13:21] dholbach: I agree with just about everything on that blueprint except that I don't think it's related to sponsoring :) [13:24] As an outsider looking in, from what I've read I'd expect the sponsorship queue to be for people that don't have upload rights to a particular component, mostly likely because they're a prospective developer but also possibly because they want to fix something in main and only have universe rights. [13:26] oojah: It's also important for people working on the edges of package-sets. [13:26] oojah: yes, but also enables better peer review. [13:27] Daviey: Well, except we've historically rejected submissions by those who could upload :) [13:27] :) [13:27] For peer review, we tend to just ask in IRC for someone to look at a debdiff or something. [13:27] which is less than ideal IMHO [13:28] Daviey: Well, I think the idea was that peer-review happened post-upload :) [13:29] which is much much less than ideal :) [13:29] We can generally fix each other's mistakes, and sometimes changelogs end up looking interesting (ubuntu-dev-tools for the security/deprecated schroot.conf lines, or the old nvidia-settings package were two cases I was involved with) [13:30] I guess, but with the package:developer ratio being as high as it is, it tends to be faster (as most of us ask if we need and don't make too many mistakes otherwise) [13:30] Right, ok on both counts. [13:53] <_stink_> hey folks. i have an upstream package that has its source split into directories named client/, server/, utils/, etc. I want my rules files to only build what's in client/. Manually I can cd client/; make and it works fine, but it seems that no matter what i try in the rules file, it *always* tries to make everything. any idea how I build only one subdirectory in a source package? [13:55] _stink_: "make -C client" instead of calling "make" in rules? [13:55] <_stink_> ahhh yes. -C. duh me [13:55] <_stink_> sistpoty|work: thanks! [13:55] yw [13:58] Using dh(1), one can also pass --sourcedir client to dh to acheive a similar result. [14:06] Hi All, I have a simple question for you. I'm working on packaging of new software which depend from avr-libc. Meanwhile I'm working on my stuff I have noticed that avr-libx seems don't be FHS compliant. Is it possible? [14:08] Could header files be placed into /usr/lib/avr/include ? [14:08] Don't should be /usr/include/avr a better place? ? [14:11] Changing stuff to be FHS compliant is always good. That said, one has to look at all the rdepends to make sure they won't break (and reverse-build-depends for libraries). [14:11] This often ends up being a fairly sizable transition, and is often best coordinated also with any Debian maintainers and upstream. [14:24] Don't suppose anyone has the command to hand to sign a .changes file? (Mind's gone blank on me :( .) [14:25] kmdm: debsign? [14:26] jpds: Perfect, thanks ;) [14:29] siretart, ping [14:40] yes? [14:40] please avoid contentless pings. I don't like them [14:41] siretart, is ffmpeg fixed upstream? when i refreshed it and installed the packages, it broke everything [14:41] i'm sure it was from the master branch [14:41] please be more specific. what breaks exactly? [14:42] mplayer complains about not being able to find libavutil shared libs, and the gstreamer ffmpeg package loses track of the codecs it needs [14:43] mplayer: really libavutil and not libswscale? pastebin please. [14:44] gstreamer: no idea, please ping slomo and/or bilboed [14:44] alright, hold on aminute i'll have to reinstall the stuff [14:46] mplayer: error while loading shared libraries: libavutil.so.49: cannot open shared object... === dholbach_ is now known as dholbach [14:47] mplayer depends on libavutil49 which provides that lib. if you removed it, then your packages and/or system are broken [14:47] libavutil-extra-49 is installed here [14:48] then check why mplayer fails to find libavutil.so.49 [14:50] well, the library version is no lnger 49, it's named 50 [14:50] do i have to rebuild everything that might possibly use ffmpeg for this to realistically work? [14:50] i planned on refreshing mplayer, but not necessarily much else [14:50] if you are using the mplayer package from lucid, then it depends on libavutil49 and that must be installed [14:51] depends declares a hard dependency. period [14:52] this should actually be renamed to libavutil50. i can't have my cake and eat it too where both 49 and 50 are there at the same time can i? [14:52] the point of the excercise of soname handling is that you can have both libavutil49 and libavutil50 installed at the same time [14:52] It's much preferred not to provide eaten cake, as this requires significantly more maintenance overhead. [14:53] persia: shared libraries must be made to coexist, otherwise bad things happen. [14:53] then if i renamed all of my ffmpeg packages, so they didn't upgrade over the karmic ones, this would work [14:53] persia: just assume libc7 would conflict with libc6 ;) [14:54] sistpoty|work: I agree that foo.so.1 and foo.so.2 should be in the libfoo1 and libfoo2 packages, but I'd prefer to just have libfoo-dev, and tell everyone to rebuild the world :) [14:54] you'd still have to change the SONAME of all libs (which is nontrivial) and change shlibs file to match that change (trivial) [14:54] siretart, how do you mean change the SONAME? [14:54] persia: that's what happening with ffmpeg, BTW. [14:56] siretart: Right. My comment about eaten cake was an argument against providing libavutil49-dev and libavutil50-dev, but apparently insufficiently clear. [14:56] bjsnider: sorry, please read up on that yourself. Try levine's book Linkers and Loaders, chapter 10. I'm currently at work [14:56] persia: agreed === RoAk is now known as RoAkSoAx [15:03] oh, i see what you mean by soname. but that's already changed int he -49 packages. they've already been bumped to 50 [15:05] siretart, thanks for the help. sorry for being a pest. [15:05] bjsnider: sorry for being so rude, I'm as said at work and your question are quite confusing to me TBH [15:11] i have to invent my own terminology because i don't have a programming background [15:12] bjsnider: The encouraged alternative is to ask lots of stupid questions in appropriate fora until you are using the same terminology :) [15:12] Err, s/stupid/potentially apparently stupid/ [15:13] persia, yes, that's exactly it... [15:14] what i don't understand is, if a package is looking for a shared lib version 49 for instance, but version 50 is there instead, why doesn't it pick that up and talk to version 50? [15:18] bjsnider: You might find running nm against your binaries to be instructive, or review any of the MOTU/School library packaging sessions documented on the wiki. === asac_ is now known as asac [15:33] bjsnider: from where should the app know how to talk to version 50 if it only knows how to talk to version 49? [15:34] Might be clearer if we remember that the differences here aren't just arbitrary versions, but rather represent differing ABIs [15:36] persia, but would the abi be so different that breakage would result? [15:37] geser, why does it only know to talk to -49? why can't it look for any version to talk to? [15:37] bjsnider: imagine the app provides a 32bit int and the lib expects a 64bit one at that location [15:37] or is it that th abi is so different that it wouldn't matter [15:37] bjsnider: from the headers for the lib it was compiled with [15:38] bjsnider: the difference might be small or big depending on what exactly has changed [15:39] bjsnider: The ABI breakage is sufficient that applications compiled against the old version will experience some problems. The nature of these problems depends on the nature of the change. [15:39] There are many ways to change ABI without changing SONAME, but when SONAME changes, there's usually no going back. [16:40] howdy, #ubuntu-motu. does upstart support running daemons under uid/gid other than root? [16:42] kreuter: I *think* so, but it might require trickery. [16:42] You might ask in #ubuntu-server: they tend to try to put stuff in chroot jails *and* use upstart. [16:44] hm. okay. thanks! [16:45] Can I get a MOTU to look at http://revu.ubuntuwire.com/p/python-nltk? I believe it's ready to go into Lucid now, it just needs advocates. [16:47] rmunn: DEP5 calls for a separated License: stanza when using the same license in multiple Files: stanzas (PSF-2) [16:47] And I've not seen debian/clean before. Nifty :) [16:50] persia, What do you mean by a separated License: stanza? I don't quite follow. [16:51] http://dep.debian.net/deps/dep5/ : see the bit about "Standalone License Section" [16:51] persia, I wanted to do "Files: nltk/a.py, nltk/b.py, nltk/c.py \n License: PSF-2" but didn't read the spec as allowing that. [16:52] <\sh> hmm..well...the universe taggeed sponsor queue looks more empty now regarding dholbachs new page [16:52] persia, Ah, I understand now. So basically, I just need to add a single newline and a new "License: PSF-2" line that's standalone. [16:52] rmunn: I think you can do that, for the same license and copyright, etc. [16:52] e.g. Files: "Program Files/*", manual[english].txt [16:53] persia, Should I do that now and re-upload, or wait until you're done looking at the rest of the revu entry so there's only a single new upload? [16:53] But I don't think you can do it for this source, because the Copyright lists differ [16:53] persia, Ah yes, that was the problem -- different copyrights. [16:53] Oh, just reupload it. I don't see anything else obvious, except that I would have used rules.tiny and debhelper 7 [16:54] persia, Been a week since I started working on this, so I'm forgetting some of the details of what I did at first. :-) [16:54] persia, It's my first package, I used CDBS because it seemed easier to get started with than debhelper. Never heard of rules.tiny -- where can I read about it? [16:55] /usr/share/doc/debhelper/examples/rules.tiny and `man dh`. [16:55] But actually, you need to patch it, so you'd have to do something like --with-quilt, and then reformat the patches, etc. [16:55] Just leave it CDBS. [16:56] <\sh> bddebian: ping mush you filed a removal request in debian for this package :) [16:56] <\sh> bddebian: dead upstream, dead maintainer, dead what? [16:57] persia: rmunn or you upgrade to debsrc3.0 so you also don't have to worry about patching ;) [16:57] persia, Uploading, should show up on REVU in 5 minutes [16:57] sebner: Well, kinda. [16:57] oh, while I remember, does anyone know of a way to specify arch-indep build rules with DH7? [16:58] I don't know of a convenient way to have my docs only built when building the arch:all package [16:58] Laney: What are you trying to accomplish? [16:58] sebner, Is debsrc3.0 available on Karmic, or should I switch to my Lucid virtual machine for building packages from now on? [16:58] rmunn: debsrc3.0 is only available for lucid and newer [16:58] \sh: NPOASR (Never part of a stable release) :) [16:58] huhu bddebian := [16:58] :) [16:58] So far the only downside I've found to building packages on Karmic is that lintian thinks "lucid" is an invalid Ubuntu version name. [16:58] persia: some processing is required to generate html documentation, but it's wasteful to do it everywhere [16:59] rmunn: you can upgrade to lucid lintian version [16:59] Laney: Compare `dh binary-arch --no-act` to `dh binary-indep --no-act` in your source package. The sequences should differ slightly, and this may help you figure out how to make it work. [17:00] hey guys anyone know if dput to PPA's is broken? [17:00] RoAkSoAx: Ask in #launchpad [17:00] persia, will do :) [17:01] persia, New upload is up at http://revu.ubuntuwire.com/p/python-nltk, thanks for the feedback on DEP5 [17:02] <\sh> bddebian: well, the whole package is horse-dung ;) [17:02] lintian still warns me about "build-depends-without-arch-dep python-yaml", but python-yaml is required for the "clean" operation (because setup.py ends up importing something that imports it) so I can't get rid of that warning. [17:03] persia: Actually, they differ in that -a is passed for the arch build, and -i for the indep, and that dh_strip, dh_makeshlibs, dh_shlibdeps are not invoked in the indep case [17:03] so I don't see anywhere to hook in there :( [17:04] Laney: Do you have different targets available in the upstream build system? You could do something with override_dh_auto_build: [17:05] No, I don't use their buildsys [17:05] How do you build it? [17:05] I just have to run agda on one file [17:06] Could you point me at your debian/rules? That might make it easier for me to critique it :) [17:06] \sh: Agreed :) [17:07] yes, I'm getting to it... git.d.o is being slow [17:07] persia: http://git.debian.org/?p=collab-maint/agda-stdlib.git;a=blob;f=debian/rules;h=b23dfc54e31fab28f5087290350b11bb5c556557;hb=HEAD [17:09] <\sh> rmunn: did you try Build-Depends-Indep, you don't build any arch dependend stuff in it...topic 7.7 in http://www.debian.org/doc/debian-policy/ch-relationships.html [17:12] Haven't tried yet, but 7.7 says Build-Depend must be satisfied when clean is invoked. Running clean runs "python setup.py clean", and upstream's setup.py does "import nltk", which in turn does "import yaml" -- so if yaml isn't around, "setup.py clean" fails with an ImportError. [17:12] <\sh> rmunn: or you find a linitan bug... [17:13] So since python-yaml is required for the clean step, I followed policy and put it in Build-Depends. [17:13] <\sh> "The matrix is based on rules, you can't break the rules, but you can bend them" ;) [17:13] <\sh> in the end, you found a lintian bug ;) [17:17] rmunn: iirc build-depends-indep aren't installed on clean, even though policy says otherwise [17:17] Laney: Sorry. Got distracted. [17:18] no worries [17:18] <\sh> sistpoty|work: I think lintian is right, because python-yaml (the module) is not actually seen by linitian but python is...false positive [17:19] Laney: If you use sbuild, you might try showing the environment variables in override_dh_auto_build with and without -A and see if you can find a useful difference. [17:19] * persia suspects there's a way to do this with pbuilder, but doesn't know the details. [17:20] I fear that we get into the realm of "more trouble than it's worth" [17:20] I could just make a binary-indep target and do my building in there [17:20] Laney: Fine. I'll get the variable :p [17:20] before "dh binary-indep" [17:21] \sh: sounds like it, yeah [17:23] persia: Something like this — http://paste.ubuntu.com/373360/ [17:24] Laney: I'm not convinced that works with dh: man dh [17:24] Oh, "binary-indep" rather than "build-indep". Right, yes. [17:25] I'd probably do it with an override_dh_binary_indep: rule that depended on a documentation: rule and called dh_binary_indep internally. [17:25] * Laney knows not about dh_binary_indep [17:25] Err, except that wouldn't work, and I'd end up doing it your way :) [17:28] let's fire off a test build [17:28] Laney: The most palatable way I've found is to put the conditional in shell: if dh_listpackages | grep -q '^mybinaryindeppkg$$'; then ..... [17:29] I like manually defining build-indep: better than that. [17:29] * Laney too [17:29] Laney: I'm wondering about your (old) --before --after stuff too [17:29] sebner: how would you do it? [17:30] bear in mind that the binary-indep target runs the whole debhelper sequence [17:30] Laney: I don't know about that indep stuff but we also had this --before and --after stuff with old debhelper (e.g configure) so I'm wondering if you can just make ist like the new way [17:31] I don't know how. And there are bound to be cases where defining the targets is still useful... maybe this is one of them [17:32] Laney: I'll give it a try later too [17:32] <\sh> I thought dh7 should make lifes easier ;) [17:32] this --before and --after stuff is really just a condensed way of writing out all of the dh_* commands in a pre-dh7 style rules file [17:33] \sh: I do think this is easier than the old way really [17:34] <\sh> Laney: depending on your training imho.. [17:34] of course, some people don't use debhelper at all :) [17:35] Grr. echo ${ENV} didn't do what I wanted. [17:36] <\sh> Laney: actually cdbs is also a black hole for me...people should know what the tools are doing so they understand the whole system...without knowing the old school you don't understand the new school ;) [17:36] \sh: ha, when using cdbs I end up reading the source more often than not [17:37] trading surface simplicity for below-the-surface complexity [17:38] <\sh> Laney: well...beginners don't and even when they do that, they wouldn't understand much ;) [17:39] Well, moving python-yaml into Build-Depends-Indep: instead of Build-Depends: seemed to make no difference as far as pbuilder was concerned... should I re-upload http://revu.ubuntuwire.com/p/python-nltk with a new debian/control even though that seems to be against (my reading of) Debian policy section 7.7? [17:39] for a lesson, I tried to package completely without helpers. funnily I almost got it right on the first try [17:40] rmunn: pbuilder always builds arch-indep afaik [17:41] <\sh> sistpoty|work: do you remember ajmitch' lesson when we opened ubuntu-motu-school long time ago? :) [17:41] Right. The make manual fails me. If anyone has a good command that prints out the entirery of the environment from within make, I'm happy to test to see if there's an arch-indep solution. [17:41] \sh: right, probably I got the idea from him ;) [17:41] This is my first "real" package (as opposed to following along with the exercises during ubuntu-classroom sessions) so I've reached the limit of my knowledge so far. [17:42] hmm [17:42] <\sh> rmunn: as said, you hit a false positive..for linitian python-yaml is not existent, but setup.py which is executed during clean needs it ... for linitian only python is a needed build-dep...file a bug on linitian ;) [17:42] from reading /usr/bin/dh, I don't think that binary-indep even does any building [17:42] so I don't know if --before dh_auto_build will work [17:43] It seems like http://revu.ubuntuwire.com/p/python-nltk is almost ready, and I'd like to get it into Lucid before Feature Freeze -- but I don't know the right answer to this Build-Depends/Build-Depends-Indep problem. [17:43] I could just build the docs and then dh $@ [17:43] is there any reason why 'dh_install --fail-missing' wouldn't report error on i386 buildd but reports problem everywhere else. [17:43] \sh, Okay, so no changes needed to debian/control? Great, that means I *might* be finished with repeatedly re-uploading to REVU now... :-) [17:44] Unless another MOTU comes along and points out yet another newbie mistake of mine... :-) [17:44] slytherin: something to do with b-d-i? [17:44] <\sh> rmunn: please document this "behaviour" somewhere in revu and file a bug against lintian (debian + ubuntu) [17:45] <\sh> slytherin: arch indep files? which are only build on i386? [17:45] Already mentioned it in one part of one of my REVU comments, but I'll put it in a separate comment so it's easier to see. [17:45] that's not a lintian bug [17:45] <\sh> james_w: then? [17:45] it should be an override in the package if you care about it [17:45]