[00:16] hi. [00:16] i was wondering if you guys knew how i could take a .deb [00:17] and make a .dsc [00:19] The dsc is a part of the source package; it's not possible in general to go backwards from a binary package to a source package. [00:21] RAOF, oh, ok. [00:48] How can I see sections available for a package? [00:48] I'm not entirely sure where it should wind up [00:54] I'm guess a clock that sits in your dock should be in the x11 section.. [00:54] MTecknology: The canonical list of sections is in debian policy. Let me grab the link for you. [00:58] RAOF: I'm guessing this - http://www.debian.org/doc/debian-policy/ch-controlfields.html [00:58] It might depend on what dock, but x11 seems safe. [00:58] thanks :) [00:59] http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections is what I was thinking of. [00:59] thanks :) [01:00] only two files left to figure out - changelog and one other, the other is going to be the hard one.. [01:00] for now, break time :) [01:15] MTecknology: changelog is trivial. dch --create for a new one, dch to edit the current one, or dch -i to add an entry. [01:16] MTecknology, the hard one is debian/copyright. the rest have a much faster turnaround on discovering issues [01:18] Well, depends. I've seen lurking issues in debian/control as well :) [01:19] or a debian/rules more complex than the source it's for [01:20] ajmitch, i've done difficult rules and difficult copyright. copyright is far more infuriating [01:21] the openjdk maintainers might benefit from looking at debian/copyright in ikvm, since it's got a mostly-complete DEP5 for openjdk in it [01:22] Why? Is there that much source duplication? Could it be avoided? [01:22] it's not feasible to avoid it [01:22] ajmitch: There's very few packages that really need complex debian/rules: I'd rather see use of dh(1) (or even CDBS) to avoid manual mistakes. [01:23] directhex: Hrm? Why not. Worst case, openjdk could generate openjdk-source on which ikvm could build-depend. [01:23] persia: I have seen a few complex examples, but they're usually for fairly large packages [01:23] persia, the openjdk-source package misses some of the more esoteric bits & pieces, and the whole thing is mildly forked here & there [01:23] Generally, although sometimes they seem to be because the maintainer is trying to fit into something they aren't. sendmail is a lovely example of that. [01:24] now there's a dirty word [01:24] directhex: Missing bits are bugs in openjdk. Forked bits can be handled with build-time patching. [01:24] Which? Sendmail? [01:24] yes [01:24] * persia remembers lovely afternoons spent pondering rule 3 [01:24] persia, you're free to take a look, but you're proposing a maintenance nightmare [01:25] directhex: Short-term, yes. My actual proposal is for deeper coordination to avoid build-time patching. [03:04] hi all, I just finished a merge, and am about to upload it, so in the patch there are a lot of po files, should I keep that in the diff or remove it, I think its just some noise so it should be removed [03:04] Generally we prefer Debian translations. [03:05] The exceptions being when we've deliberately changed something, but this should appear in the changelog. [03:05] If something is deliberately changed, please only merge those msgids in the .po files. [03:06] persia: so here: http://paste.ubuntu.com/362997/ i should remove all the .po changes right [03:06] Well, I think you're merging too much there :) [03:07] persia: really ? this package had a lot of changes, especially the .po stuff, but if that's going to be removed then its not that much really [03:07] Firstly, I think the update to debhelper 7 is worthless: I don't think we should be fixing lintian issues in stuff maintained in Debian. [03:07] Standards-Version too. [03:08] persia: they updated it to 7 and same for standards, so I should just change them and not mention that in the changelog [03:08] Standard version is something Ubuntu Policy says specifically not to touch [03:08] Just revert to Debian, and drop it from the "Remaining changes" [03:08] persia: alright :) [03:08] Same with overrides, in my opinion. [03:09] persia: this is from the debian's control file: Standards-Version: 3.8.3 so I just put that there, but will remove it [03:09] persia: so remove the overrides too, that file was renamed to a different one, so I didn't know how to put that down in words [03:10] dhillon-v10: You want to use whatever Debian has for Standards-Version, debhelper compatibility, and lintian overrides *UNLESS* the package has an unlikely bug like some dh7 feature being used with declared compat level of 5. [03:10] What is this diff anyway? It doesn't appear to be a Debian->candidate or Ubnutu->Ubuntu. [03:11] For Debian->candidate it doesn't have enough old changelog entries. For Ubuntu->Ubuntu it includes some old Ubuntu changelogs. [03:11] persia: alright :) my mentor told me to document *every* single change I make so I did so but i will remove that, this one was done using bzr diff --old lp:debian/squeeze/ssl-cert [03:11] persia: why is that patch wrong, that's what the wiki page said [03:12] persia: I have actually had a couple of wrong ones like this, but don't know what to do [03:12] dhillon-v10: I'm not saying the patch is wrong, just that it doesn't match either of the patches I'm used to reviewing. [03:13] As a result, I'm uncertain about everything. [03:13] But I know that we're not supposed to change Standards-Version and lintian stuff Ubuntu-local unless it makes some significant user-visible difference. [03:16] persia: alright, so I'll remove that stuff, so what can i do to fix my patch, sorry I am taking a lot of your time [03:16] I choose to spend my time answering questions in this channel, in hopes that it makes up for not uploading enough. Don't worry about that :) [03:17] I don't know how to tell you what to do with your patch. I usually compare my candidate to both the package in Debian and the package in Ubuntu. [03:17] Comparing against Debian lets me confirm that I included all the changelog entries and all the related patches. [03:17] Comparing against Ubuntu lets me confirm that I included all the improvements from Debian. [03:17] And back at it.. I know I've been told this before.. so- is there any wiki that describes how packages should be named? mostly just the piece after app_version*** [03:18] MTecknology: You should never do anything manually that affects that unless you have a very special case and already know how to do it. [03:18] persia: so I should debuild the package and then compare the two candidates [03:18] persia: new package that will be in a ppa [03:18] Just worry about the "app" part, and accept the dfaults for everything else. [03:18] persia: then try to make it into the repos [03:19] dhillon-v10: I build source packages and compare those, but that's the idea. [03:19] What I have is this - lal (1.0-1) karmic; urgency=low [03:19] MTecknology: Right. Doesn't matter. Accept the defaults. Anything else is going to cause you more problems than you want to understand how to fix. [03:20] I'd recommend lal (1.0-0Mtecknology1) for a ppa, and 1.0-0ubuntu1 for Ubuntu. [03:20] persia: ok, I've just always seen thins like ubuntu# or ppa# [03:20] Ah, you want the revision number :) [03:20] I thought you were talking about the architecture ID strings and the like. [03:20] oh [03:20] no thanks, I don't want to play with that :P [03:21] Doesn't matter what you use. Just pick something lower than -0ubuntu1 if you're out of repo, and -0ubuntu1 if you're in repo. [03:21] ok, there's actually no package yet :P [03:21] dpkg --compare-versions lets you check various strings. [03:22] ok - two more things... I want to create a man page before going any further with this.. [03:23] help2man can be a useful way to get started, depending on the package. [03:23] persia: E: ssl-cert_1.0.25ubuntu1_source.changes: bad-ubuntu-distribution-in-changes-file lucid [03:23] There's also txt2man, rst2man, info2man, djbdoc2man, docbook-utils, podulators-perl, etc. Depends how you want to write the docs in the first place. [03:23] extremely simple; right now it's one .c that builds one binary [03:23] persia: what does that mean? [03:24] dhillon-v10: It means you're not using the lintian from lucid. [03:24] More specifically, it means that the lintian you're running doesn't know about lucid. [03:24] Upgrade lintian. [03:24] persia: alright :) [03:25] persia: care if I pm you a political question? [03:26] I prefer to just receive /queries without being asked. Depending on the topic, I can't promise to discuss at length. [03:37] persia: I tried txt2man and that gave some really ugly output :P [03:37] as in, an ugly man page [03:37] Right. Now fix it :) [03:38] But it's easier than creating a manpage from scratch (at least for me) [03:43] "Fear. Run. Save yourself. No user-serviceable parts." <-- comment from a man page nroff preamble. [03:43] Heh. [03:44] persia: so.. html2man won't help because this app continues if it doesn't recognize --version :P [03:45] MTecknology: Feel free to draft from scratch. I just find that getting the framework from a tool (especially if it there are already convertible upstream docs) is easier to start. [03:46] persia: thanks [04:05] persia: jsut talked to the maintainer; they're excited [04:05] I'm going to just write this file from scratch :P [04:14] this isn't that hard... I'm kind of amazed [04:16] just not dure what .RE and .RS are for yet.. [04:16] I think I get that part now too :) === \vish is now known as vish [04:46] Greetings, folks! [04:47] zooko: hi [04:49] persia: You going to be around a little bit longer? [04:51] Heya zooko. How's the release going? [04:52] Hi! I decided today to stop trying to finish the last feature and start packaging and documenting and all that. [04:52] My goal is to release Tahoe-LAFS v1.6 this week and upload it to Ubuntu on Thursday. [04:52] http://allmydata.org/pipermail/tahoe-dev/2010-January/003664.html [04:53] I'm excited! Cory Doctorow invited me to submit a news item about Tahoe-LAFS to Boing Boing. [05:07] ScottK: how is Lucid coming? [05:07] Hard to say. Lots of good stuff done, lots more to do. [05:13] Hm, this reminds me to mark a ticket in Nevow as review-needed... [05:13] Because I want the version of Nevow in Lucid to stop emitting DeprecationWarning... [05:14] Oh I suppose that picky exarkun will ask me to submit a unit test showing that it doesn't emit a DeprecationWarning! [05:17] ScottK: what are the sorts of things you're thinking of when you say "lots more to do"? [05:18] Quite a number of features still being implemented, tons of bugs, lots of packages to merge from Debian. [05:18] zooko: It might be worth it for you to look and see if any of the tahoe build depends/depends need updating. [05:21] * zooko checks http://allmydata.org/trac/tahoe/log/_auto_deps.py [05:22] We haven't changed the Tahoe-LAFS dependencies since v1.5.0 of Tahoe-LAFS. [05:23] * zooko looks at https://bugs.launchpad.net/ubuntu/lucid/+source/linux-mvl-dove/+bug/505772 [05:23] Ubuntu bug 505772 in linux-mvl-dove "Some python scripts trigger system hang" [Critical,Confirmed] [05:33] Do I 'need' a ./configure script? [05:33] The app doesn't have any options to be passed to it.. [05:43] MTecknology, no, it's not mandatory === fabrice_sp_ is now known as fabrice_sp [06:04] fabrice_sp: thanks [06:27] Hello motu's... Is there a problem with openssl in Lucid? Various packages (e.g. libavg) FTBFS with "ld: cannot find -lssl". [06:32] Do they build-depends on libssl-dev? [06:34] well, not directly at least, but I imagine that libssl-dev is supposed to get pulled in by some dependency -- only because several unrelated packages are showing the same "cannot find -lssl" failure. [06:35] Here is libavg's build-deps [06:35] Build-Depends: cdbs, debhelper (>= 5), libavcodec-dev, libavformat-dev, [06:35] libboost-python-dev (>= 1.34.1-8), libboost-thread-dev, libdc1394-22-dev, [06:35] libgraphicsmagick++1-dev, libpango1.0-dev, libsdl1.2-dev, libswscale-dev, [06:35] libtool, libxml2-dev, libxxf86vm-dev, python-all-dev, python-central (>= 0.5), [06:35] quilt [06:35] If packages were depending on an indirect depends to get the libssl headers, that's a bug in the package. [06:36] If adding libssl-dev to the build-depends fixes it, then that's a correct fix in almost all cases. [06:41] ScottK: Ok, that's easy to try anyway. But it doesn't look to me like the libavg actually refers to "ssl" directly at all. Isn't it possible that it is pulling in "-lssl" from some build-time thing (pkgconfig of one its dependencies?) so that libavg wouldn't actually know that it needs libssl-dev? [06:41] In that case it should be a depends of that dependency. [06:43] ScottK: That's what I meant by "supposed to get pulled in by some dependency". Maybe one of its deps recently accidentally dropped its (required) dependency on libssl? How can I trace that? [06:43] If it did, it wouldn't have built. [06:44] Alternatively it can be an actual bug in the package. [06:45] a bug in which package? [06:48] Could be libavg in this case. [06:48] Here's an example of another package that had this problem: http://git.quassel-irc.org/?p=quassel.git;a=commit;h=ab66db150c3eadf225fab28af591ba74093950f6 [06:51] ScottK: Eight unrelated packages on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi get the same failure. Can they all be buggy? ;-) [06:51] kamalmostafa: If they all made the same incorrect, but common, assumption: Yes. [06:56] https://bugs.launchpad.net/bugs/512509 feel free to sponsor :D [06:56] Ubuntu bug 512509 in burn "ftbfs in Lucid" [Undecided,New] [06:56] kamalmostafa: As an example, the Quassel bug was exposed by the qt4-x11 dev package dropping libssl-dev as a build-dep for this exact reason. It wouldn't suprise me if there were several packages that broke just because of that. [07:00] ScottK: But Quassel (if I understand correctly) actually itself cares whether ssl is or isn't present, right? Certainly its source refers to "ssl". But libavg doesn't refer to "ssl". Anyway -- lets set libavg aside for a moment... [07:01] Right, I'm just speaking in general. [07:01] In libavg's case it may be bug that it tries to build against it when it doesn't need to. No idea. [07:02] Consider package 'dia' which shows a clean ubuntu build months ago, but recently FTBFS with the "cannot find -lssl" error in the udd.debian list. Could we do a retry build on 'dia' now and see what happens? [07:02] Is it FTBFS in the archive, or just in the rebuild test? [07:02] Or wait -- I could just pbuilder that myself. [07:03] Yes. [07:03] Then if it fails, add libssl-dev to the build-deps and see what happens. [07:05] ScottK: Okay, I will try that -- but I expect that in all cases, it would fix the build problem -- but still might not be the "right" fix. Anyway -- it'll be informational. [07:05] "Right" is one of two possibilities: Either that's right, or the package is buggy and looking for somethig it shouldn't during build. [07:06] relying on indirect depends is a bug. [07:07] In many cases where there's an indirect dependency on libSSL, it may be worth checking if there is a gnutls solution also available. [07:07] (just because of the license checking requirements when linking against SSL) [07:08] I think the primary question (for e.g. libavg) is *why* is -lssl appearing in its link line at all? [07:10] Probable a pkgconfig thing. Dig through the ./configure output [07:33] does libavg build a python extension? [07:34] if yes, it might use LOCALMODLIBS (which contains -lssl) which it shouldn't use [07:35] geser: I do see a reference to "LOCALMODLIBS" in its configure script. [07:35] libavg's control file is here: http://pastebin.ubuntu.com/363080/ [07:37] "LOCALMODLIBS is a macro used to link the python binary against libaries needed for the binary. It must not used to link extensions." [07:38] so you need to patch configure to not use LOCALMODLIBS [07:38] good morning [07:38] good morning dholbach [07:38] geser: Bingo. I do see the reference to -lssl in the definition of LOCALMODLIBS. Thanks geser! [07:40] kamalmostafa: I had a similar issue to fix yesterday. you might want to look at http://bugzilla-attachments.gnome.org/attachment.cgi?id=147050 to get an idea how to fix it and adapt this then on libavg [07:41] geser: Excellent -- thank you. Note that libavg isn't the only package showing this problem. Did something recently change in python that exposed this issue? [07:43] if "recently" == "since lucid", then yes. As far as I understand it LOCALMODLIBS was never intended to by used outside the python interpreter itself. === __ruben__ is now known as _ruben [08:21] is there a way to set like 'depend on python-docutils (>6.3) or on (python-docutils <= 6.3 and docutils-writer-manpage) ? [08:22] Not trivially. [08:22] One *could* set up some dummy packages and then depend on the disjuction of the dummies, but that would be annoying. [08:22] Why not just depend on python-docutils > 6.3 [08:23] what about "python-docutils, python-docutils (>>6.3) | docutils-writer-manpage" ? [08:23] Alternately, if python-docutils > 6.3 provides docutils-writer-manpage, then it should say so in the package declaration. [08:24] randomaction: I don't think versioned dependencies and disjunctions work well together (although I could be wrong). [08:24] Anyway, I think one should never have to do this. One should depend on python-docutils, docutils-writer-manpage, and if python-docutils supplies docutil-writer-manpage it should Conflict/Replaces/Provides. [08:25] at some point the transition will be considered complete (docutils-writer-manpage is not a package in any supported release), at which point one can drop the Provides from python-docutils. [08:25] That will trigger NBS updates of thngs that depend on it. [08:28] persia: that sounds more maintainable in the long run [08:29] I think so :) [08:30] my suggestion was only based on formal logic anyway :) [08:32] randomaction: Theoretically, it should work. I have a feeling it might not in practice, just from the set of apt bugs I've heard about. [08:33] I imagine the various package management tool maintainers would appreciate patches to make the dependency logic formally correct, but I also presume there are better ways for anyone capable of doing that to spend their time :) [08:35] dkpg design must have been base on the fact that there's a disjunctive normal form for any logical expression :) [08:38] randomaction: I'm not convinced it was that fancy. I suspect it started with just foo, bar, baz [08:38] And then someone said "But either of these things could work" and filed a bug, so we got [08:39] foo, bar, baz | quux [08:39] And then someone said "But it only works with version 1.4!", and filed a bug, and so on. [08:43] randomaction: For an extended example of how complex it has become: see http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/ :) [08:52] that's great :) [09:06] tseliot, looks like vdpau works for me in both mythtv and mplayer w/ a fresh install [09:06] so if someone has a problem with an old upgrade, then you probably just need c/r on an old package (if that package is present) [09:06] superm1: what happens if the old vdpau is installed? [09:07] superm1: did you already fix the package wrt libvdpau-dev build dependency in lucid by chance? [09:07] other than not working? I'm not really sure [09:07] siretart`, no i didn't want to go trumping on your stuff since you maintain it all in debian [09:08] superm1: no worries, I need to be able to git-import-dsc ubuntu uploads anyway [09:08] a proper git-format-patch would be of course ideal to preserve attribution and commit messages in our git properly [09:09] bjsnider might actually already have a diff ready. i dont currently [09:09] superm1: do you think I need to take care of the vdpau-dev package too (with c/r) or would vdpau be enough? [09:10] tseliot, it wouldn't hurt to do it on the -dev too i suppose [09:10] superm1: ok [09:10] although, you know wait a min? why is this even necessary? [09:11] i thought that it's the exact same library that's in libvdpau1 [09:11] so it shouldn't be installable side by side [09:11] so when mplayer grows the proper depends, there will be an error at that time too [09:12] superm1: we install libraries in their own directories now [09:12] but i'm saying /usr/lib/libvdpau.so.1 [09:12] there may still be a link in /usr/lib though [09:12] the one that comes from the package libvdpau1 [09:13] since mplayer doesn't yet have a depend on it, there wasn't an error for having the old package in place [09:15] superm1: are you suggesting that we don't use c/r? [09:16] Hi there, Im wondering about licensing for upstream, its a practical matter [09:16] tseliot, lets get the new mplayer sorted out first, and see if this problem is persisting for upgraders [09:16] How should I license 3D models that have no header? [09:16] I was told that I had to license every file [09:16] there's still plenty of time to add the c/r if it's necessary [09:17] superm1: but still that would break the alternatives system [09:17] they are all creative commons, but does each file need to explicitly state this somehow? [09:17] ideasman42: In what format are the models? [09:17] blend [09:17] tseliot, which would? the c/r? [09:17] * persia hunts up file format specs [09:17] blender-3d [09:17] superm1: not having c/r [09:17] ideasman42, are the copyright owners and specific CC version clearly defined in a file accompanying the models in the source distribution? [09:18] tseliot, i'm not entirely familiar enough with how the alternatives system is working, can you elaborate why it would break it by not having it? [09:18] directhex, when we distributed the DVD yes, from our SVN repo its not so clear [09:19] * persia doesn't really understand why it's not listed at http://wiki.blender.org/index.php/Dev:Ref/File_Formats [09:19] persia, its an internal file format - basically a memory dump [09:20] ideasman42: Well, my general recommendation is that if the format supports internal tags, to have the tag contain at least the license name. It the format is text-based, include the license information has a comment, and if the format restricts comments reference it in a README file. [09:20] superm1: /usr/lib/libvdpau_nvidia.so is installed by the old vdpau and it's a link in the nvidia package. Even if the latter overwrites the link from the former, when you remove the former you break alternatives (as that file is removed) [09:21] persia, ok, thanks. will add some README / COPYING file [09:21] Ah, because a real file trumps a symlink in terms of a package - and the alternative happens postinst, it's not owned by a package [09:21] as downstream requires [09:21] superm1: right [09:21] ideasman42: tags or comments are best though, if possible. When using tags or comments, also reference in the README, and don't forget to include a copy of the license with the upstream source so that people who download can be confident they are reading the same text the authors read. [09:21] ideasman42, if it's a binary format then a README of some kind should be fine. and you really want "svn export" to pick up on it if downstream is meant to package frmo svn [09:21] so yeah, definitely need a c/r if there is an old package that is providing that file in karmic [09:22] No, just needs replaces. [09:22] ideasman42, i think there's a #debian-games on oftc too [09:22] directhex, have a makefile for svn export and fedora use this [09:22] c/r is only needed if in addition to overwriting that file, the rest of the files need to be removed from the system. [09:23] In face, #debian-games@oftc is where many of those who maintain games in Ubuntu hang out. [09:23] s/face/fact/ [09:23] thanks guys. back to bugfixing :D [09:23] (yo frankie discussion on planet/reddit) [09:24] (pabs & runa seemingly both gave up on it) [09:24] licensing issues? [09:24] ah, that one [09:24] persia: yes [09:24] oh, a runasand! [09:24] heh. That keeps more stuff out of the archive than just about anything else. [09:25] well now i feel like i'm talking about people behind their back [09:25] At one point there were about 40 games that were well-packaged in d-g svn that were under license negotiation. [09:25] directhex: :) [09:25] i'm happy to do packaging for tricky packages, as i enjoy a challenge - but that excludes debian/copyright which isn't challenging, it's just unfun [09:26] directhex: that's what I figured as well [09:26] I usually do debian/copyright first, so that I know I don't want to package something before I get too excited about making it work. [09:26] persia: that's one of things I learned :) [09:26] (of course, this fact also helps keep me from packaging new stuff much) === white_ is now known as white [11:44] q. how do i know the content of a .deb ? all the files in it i mean [11:44] persia: sounds familiar to me *ehehehehe*, huhu btw :) [11:46] jetienne, dpkg -c /path/to/file.deb [11:46] directhex: thx [11:59] is it possible to copy a package from lucid to karmic-proposed? [11:59] say podsleuth for example. [12:01] no nevermind, it isn't possible for podsleuth's case due to a transition [13:57] Is there a mentoring scheme for packaging? [14:00] Also this "Quickly" thing, is it usable for packaging anything? [14:00] um, kinda sorta. [14:00] It does have a module that creates a package wrapper. [14:00] And you can start from that to have a package. [14:01] Hmm [14:01] There isn't really a mentoring scheme, although lots of people are always happy to explain. [14:01] Did the recipe I gave you before not work sufficiently for something? [14:02] hi, I have a strange problem; if this is the wrong channel please tell me a better one… [14:02] I need to package a TTF (OTF, actually) font for hardy. [14:02] defoma segfaults on me. [14:02] persia: I'll be honest I got really annoyed with it. I'm not sure if packaging is my thing, it's too damn difficult, and there's too many things to do with the rules file (poorly documented). Its a real shame, because I think that's the reason why there are very few new packagers :( [14:02] There is Debian #477435 but I did install libft-perl [14:02] Debian bug 477435 in defoma "defoma-hints crashes on some OTF files" [Important,Open] http://bugs.debian.org/477435 [14:03] does anyone have a solution? debian seems to have dropped defoma, but that was post-hardy AFAICT [14:03] xteejx: As I tell nearly everyone at some point, despite packaging being deceptively easy, the best way to learn is really to debug existing packages and get a feel for how things work :) [14:03] persia: You want to check out the man page and let me know what you think? [14:04] MTecknology: Please ask generally. I'm a bit busy now, and surely someone else can help. [14:05] persia: Easy!? I know what *needs* to be done, I just don't know how to do it. I know what goes where, and how it *should* all tie in. [14:06] Anyone up for letting me know what they think of this man page I made up? Nit picking welcome :) http://paste.ubuntu.com/363246/ [14:07] xteejx: Just ask for each problem, but again, looking at other examples can help give you ideas. [14:08] I think MOTU should have a school or session on how to create a package from scratch. Just pick an unpackaged upstream from ...wherever really... show the complications that can arise, how to effectively write a rules file, using debhelper and the dh_** things in the rules file, etc. [14:08] xteejx: I've offered to teach such a class to the developer training group. Watch their wiki to see when it gets schedule. [14:08] d [14:08] I'd be surprised if after reading something like that, we wouldn't have new packagers, this is probably one of the main problems they face as I am :( [14:09] persia: This Dev OpenWeek? [14:09] No. [14:09] DEveloper Training is compeltely separate from Open Week. [14:09] ok [14:09] xteejx: I'm packaging something that was never packaged before using the complete guide - so far I don't think I've been stuck (help from here too) [14:10] MTecknology: Did you have any previous experience? [14:10] is there maybe a more appropriate channel for font packaging related issues? [14:10] The wiki page keeps moving, but I *think* it's currently https://wiki.ubuntu.com/Packaging/Training [14:10] Every Thursday? [14:11] xteejx: not really [14:11] Well, assuming there is sufficient faculty, yes. [14:11] <\sh> grmpf... [14:12] MTecknology: Don't you have problems with debhelper and all the commands in debian/rules as well? It's doing my head in! lol [14:12] <\sh> regarding this http://www.mail-archive.com/debian-devel@lists.debian.org/msg230777.html discussion, dpkg --purge / apt-get remove --purge shouldn't delete the /opt dir, but somehow it does exactly that, because of exactly the reasoning the threads tells us [14:12] <\sh> how can someone avoid that? [14:12] persia: If you do a session for something like that I can guarantee I'll be there!! [14:12] xteejx: I tried to work on existing packages but I coudln't figure it out - I'm hoping that a new app will be easier to package and a good place to start [14:13] \sh create opt.deb that contains only /opt as an empty directory and pin it? [14:13] That's my thought, and then I can see the whole process too [14:13] xteejx: debian/rules - last thing I think I have left; this part could use more explanation [14:13] New packages are really harder. [14:13] <\sh> persia: or we include /opt in base-files and not creating it in base-files postinst? [14:13] Because there's so much that can go wrong. [14:14] 95% of new packages I see from new packagers are wrong in several ways, and even after all the issue are corrected fail to follow best practices. [14:14] just touch /opt/blah :) [14:14] \sh: No idea. [14:14] \sh: It's optional in FHS, so failing to provide it isn't wrong. [14:14] dpkg wont delete non empty dirs [14:14] <\sh> ogra: it will... [14:14] thats a bug [14:14] <\sh> ogra: it already has in my test [14:14] ogra: I think the problem is not deletion on removal, but deletion on purge. [14:15] persia: will lintain help me with that? [14:15] oh, purge [14:15] i messed that [14:15] *missed [14:15] MTecknology: Not really, no. [14:15] persia: oh.. [14:15] lintain clean != cleanly packaged. [14:16] MTecknology: I got up to that point, and started hitting my head on the wall... and then the files/folders have to comply with the set /usr/bin/ /usr/share/ directory structure! [14:16] So, that's why it's nice to work with existing packages. [14:16] They already work, except for something that's wrong. [14:16] Yeah, but chances are that will lead to coding.... [14:17] So one can adjust packaging issues, or apply patches, or similar in an isolated fashion within a working framework. [14:17] persia: actually, that should be an implication: linitan clean <= cleanly packaged [14:17] xteejx: actually.. I did some coding on this :P [14:17] heh... [14:17] mok0: Hard to do, because there are many unclean but correct ways to package. Better to have another tool for that. [14:18] persia: I was just commenting on your statment containing the != unequality :-) [14:18] Right. I think it *should* be an unequality. [14:18] I think there is huge value in having something that validates policy and common practices. [14:18] Uhm, no. A clean package will also be lintian clean [14:18] But I think that's a different tool than something that validates style. [14:19] Not necessarily. [14:19] mok0: Generally, yes, but not always. [14:19] There's lots of times you want to do something lintian doesn't like, but you know it to be correct. [14:19] Lintian documents general best practice. It's not always appropriate. [14:19] Assuming the tool works [14:19] Not all of these are bugs in lintian. [14:19] In Debian the now autoreject uploads for some issues that lintian flags. [14:20] My favorite so far was the autorejection of zlib for containing an embedded copy of zlib. [14:20] heh :) [14:20] Does autorejection ignore overrides? [14:20] Depends on the tag. [14:20] Oh my. [14:21] Some are over-rideable, some aren't. [14:21] Nice way to limit the size of the archive :-) [14:21] Well, no. It doesn't do that. [14:21] It's possible to construct many huge lintian-clean packages. [14:21] But it may not be possible to construct a lintian-clean distribution. [14:21] Right. It limits the growth in the size of the archive [14:21] Is that correct, we don't *actually* build the .deb files, and that the autobuilders do that for us from the source and the rules file? [14:21] (or at least it puts a huge load on the installer and image building tools) [14:22] I'm OK with that in general, although I think delegating to the lintian authors is probably not the best way to do it. [14:22] xteejx: Most of us build .deb files for testing and throw them away, and then the autobuilders make trusted ones. [14:22] Is that the debuild -sa ? [14:23] mok0: It *doesn't* limit the growth. Like I said, it's possible to construct lots of large lintian-clean packages. [14:23] xteejx: No. -sa makes sure that the orig.tar.gz is listed in the .changes file. [14:23] Ohhh, it's just debuild on its own :P [14:23] xteejx: I use sbuild for building .debs. Some people use pbuilder. Other tools are cowbuilder, qemubuilder, dpkg-buildpackage, etc. [14:23] No. That builds source *and* binary. [14:24] alrighty; the rules file has me lost [14:24] ahhhh [14:24] debuild -b builds a binary. [14:24] But any binary built locally is suspect because the build-depends haven't been validated. [14:24] that's why we use pbuilder right? [14:24] MTecknology: 90% of the time /usr/share/doc/debhelper/rules.tiny should do 90% of what you need. [14:24] Right. [14:24] woohoo I'm learning :) [14:25] But understanding what you are doing is still recommended even if rules.tiny works. [14:25] OK. So lets fix some bugs. [14:25] persia: I have one man page that wasn't there when I started and there's one file.c that produces one binary. [14:25] Who? [14:26] MTecknology: Hrm. You probably need special stuff then. [14:26] (or create a Makefile) [14:26] xteejx: You. Me. Someone else :) [14:26] persia: sorry, there's a Makefile there, also README and COPYING [14:26] Ohhh hehe I do enough triage as it is ;) I wanna get my hands dirty with packaging and then I can work through both [14:27] Then it probably works for you. [14:27] Makefile should be easier ./configure make make install thing [14:27] xteejx: OK. go pick a bug that you've triaged (so you understand it) on a package in universe, and let's fix it. [14:27]