| === bmk789 is now known as bmk789_sick_bed | ||
| === bigon is now known as bigon` | ||
| dholbach | MOTU Q&A session in 8 minutes | 12:52 |
|---|---|---|
| Hobbsee | dholbach: can i have a pony? | 12:52 |
| dholbach | that depends.... ;-) | 12:53 |
| Hobbsee | on? | 12:53 |
| dholbach | :-) | 12:53 |
| * dholbach right now needs to find out what we covered last time | 12:53 | |
| rzr | dholbach: what to not do i think | 12:53 |
| rzr | $ ./hello * | 12:54 |
| dholbach | yeah, I have a list of the other items on my box, but don't recall which bits we covered and which we didn't | 12:54 |
| dholbach | ah found it... great | 12:54 |
| dholbach | Welcome to another MOTU Q&A Session! | 12:59 |
| dholbach | Who's here for some MOTU Q&A action? | 12:59 |
| * warp10 raises his hand | 12:59 | |
| * rzr _o/ | 12:59 | |
| dholbach | Let's start with another round of introductions.... :-) | 13:00 |
| === bigon` is now known as bigon | ||
| * dholbach is Daniel Holbach, member of the MOTU team and tries to make the MOTU journey as pleasant and straight-forward as possible :) | 13:00 | |
| mruiz | _0/ | 13:00 |
| * Hobbsee is the looney one | 13:00 | |
| * warp10 is Andrea Colangelo, MOTU helpful, getting a lot of fun :) | 13:01 | |
| * slytherin is a motu hopeful with special interest in java related packages | 13:01 | |
| dholbach | rock on warp10, slytherin! :-) | 13:01 |
| * rzr recently joined MOTU an maintains some packages also debian side ... | 13:01 | |
| dholbach | great | 13:02 |
| rzr | slytherin: java , we need to do a Q&A session about this i fell | 13:02 |
| dholbach | do we have some questions already? | 13:02 |
| * warp10 has a question | 13:02 | |
| dholbach | warp10: fire away | 13:02 |
| rzr | slangasek: someday at least | 13:02 |
| warp10 | I would like to request syncs for some packages in contrib and non-free. Since they are not in Ubuntu yet, what's the best way to find out if such packages can land in universe or need to stay in mutilverse? | 13:02 |
| * Hobbsee wants to become a MOTU | 13:03 | |
| dholbach | warp10: sometimes the changelog or copyright of the debian package already points out why it was moved to non-free or contrib in the first place | 13:03 |
| dholbach | the archive admins will check the package carefully, when it is in non-free/contrib in Debian | 13:04 |
| dholbach | if all fails, you need to check the license texts in the package yourself | 13:04 |
| dholbach | (and the headers of source files, etc) | 13:04 |
| dholbach | any other questions? | 13:04 |
| warp10 | dholbach: Ok, great. And for the procedural side, it is enough to report a bug (maybe using requestsync) or is there any special procedure? | 13:05 |
| dholbach | warp10: no, that's exactly the process | 13:05 |
| warp10 | Cool. Thank you :) | 13:05 |
| dholbach | it helps to point out explicitly what you know about the package, when you file the bug, but that's all there is about it | 13:06 |
| dholbach | ok... if we don't have questions right now I'm sure we'll have some later on :) | 13:06 |
| rzr | as suggested can we fix a java Q&A session date , since icedtea is on good way .. | 13:06 |
| rzr | I can help about gcj too | 13:06 |
| dholbach | some of you might know, last session we answered the question "how do we make the most awful package ever?" | 13:06 |
| dholbach | we still have some proposals on the list we didn't talk about last time | 13:07 |
| dholbach | if nobody has other questions, I think we'll just chat a bit about the other items on the list | 13:07 |
| Hobbsee | dholbach: we use yada | 13:07 |
| Hobbsee | ! | 13:07 |
| Hobbsee | oh, no...no, no.... | 13:07 |
| dholbach | Hobbsee: yeah, that was one of the proposals | 13:07 |
| * Hobbsee has one better than that | 13:07 | |
| Hobbsee | where's steve? | 13:07 |
| dholbach | in bed? :) | 13:07 |
| dholbach | <Amaranth> interactive builds | 13:07 |
| dholbach | <Amaranth> an interactive build took out the buildds recently, didn't it? | 13:07 |
| Hobbsee | no, he's still awake | 13:07 |
| Hobbsee | yeah, it did | 13:08 |
| dholbach | what amaranth proposed is quite effective for a bad package :-) | 13:08 |
| TuxCrafter | hello all I will join this session | 13:08 |
| dholbach | welcome TuxCrafter | 13:08 |
| TuxCrafter | were is the agenda? | 13:08 |
| dholbach | TuxCrafter: if you have any questions, be sure to just ask them - right now we're discussing how to really produce packages | 13:08 |
| Hobbsee | dholbach: try a debian/rules file building the .deb by hand. | 13:08 |
| dholbach | (and clarify how best not to do that) | 13:08 |
| dholbach | Hobbsee: we had that too | 13:08 |
| rzr | TuxCrafter: see topic | 13:08 |
| dholbach | hang on | 13:08 |
| Hobbsee | oh, you saw that? | 13:08 |
| Hobbsee | pity | 13:08 |
| dholbach | http://daniel.holba.ch/temp/qa-negative | 13:09 |
| dholbach | that's the answers we got last time | 13:09 |
| dholbach | we're at this one right now: | 13:09 |
| dholbach | <Amaranth> interactive builds | 13:09 |
| dholbach | <Amaranth> an interactive build took out the buildds recently, didn't it? | 13:09 |
| Hobbsee | dholbach: you also got the packages that require sun java to build, which require a licence agreement, or programs that attempt to download from the internet? | 13:09 |
| * slytherin has a suggestion | 13:09 | |
| dholbach | Hobbsee raises a good point | 13:10 |
| dholbach | if you install sun-java* it will ask you to accept a license agreement | 13:10 |
| dholbach | on a build daemon this manual interaction is impossible | 13:10 |
| dholbach | slytherin: fire away | 13:10 |
| rzr | dholbach: it is there are some hack to | 13:10 |
| slytherin | dholbach: you finish first. I have suggestion regarding java packages | 13:10 |
| rzr | dholbach: let me find this out ... | 13:10 |
| Hobbsee | rzr: the buildd admins have to do it manually | 13:10 |
| Hobbsee | dholbach: you haven't mentioned the hardcoded dependancies either | 13:11 |
| dholbach | Hobbsee: on things like libsomething12 ? | 13:12 |
| Hobbsee | dholbach: as in, lack of understanding about shlibdeps, and so hardcoding all the packages it needs to depend on in Depends: | 13:12 |
| Hobbsee | including libraries like that, yes | 13:12 |
| dholbach | yeah good point - I've seen that a couple of times | 13:12 |
| * Hobbsee has seen that more than a couple | 13:12 | |
| dholbach | does everybody understand what Hobbsee is referring to? | 13:12 |
| TuxCrafter | *** got a question for Q&A: If i look at the fedora process they have a very nice structured system with cody, will there come a similar system for ubuntu? | 13:12 |
| Hobbsee | TuxCrafter: what's cody? | 13:13 |
| Hobbsee | TuxCrafter: got a URL or something? | 13:13 |
| dholbach | TuxCrafter: I'm afraid I don't know anything about cody - can you elaborate? | 13:13 |
| TuxCrafter | Hobbsee: my firefox is down i have to restart internet for it so i can find the info brb | 13:13 |
| slytherin | TuxCrafter: please raise your hand first before asking question so that you don't interupt the current discussion. :-) | 13:13 |
| dholbach | slytherin: you wanted to raise another point? | 13:14 |
| slytherin | dholbach: Can you please explain what Hobbsee was saying | 13:14 |
| dholbach | ok | 13:14 |
| dholbach | most packages (for example those written in C or C++) have something similar to this in their depends line: | 13:14 |
| rzr | Hobbsee: I noted how to workaround the "ask licence" blocker : http://rzr.online.fr/q/pbuilder | 13:14 |
| dholbach | Depends ${shlibs:Depends}, some-other-package | 13:14 |
| dholbach | Depends: ${shlibs:Depends}, some-other-package | 13:14 |
| dholbach | the package build system will check which libraries the binaries are actually linked against, and then substitute ${shlibs:Depends} automatically | 13:15 |
| dholbach | so it's wrong to have a fixed Depends: libsomething12 | 13:15 |
| dholbach | this is important for example in cases of library transitions (libsomething12 -> libsomething13) | 13:16 |
| dholbach | if you use ${shlibs:Depends} a simple rebuild will probably suffice | 13:16 |
| dholbach | slytherin: does that make more sense now? | 13:16 |
| slytherin | dholbach: Yes it does. Thanks. | 13:16 |
| dholbach | ok great | 13:17 |
| dholbach | I hope the "interactive" item was clear too | 13:17 |
| TuxCrafter | *** has a question | 13:17 |
| dholbach | TuxCrafter: fire away | 13:17 |
| TuxCrafter | *** my dns is down and cant connect to web-pages on this moment and is sorry for this | 13:17 |
| * Hobbsee didn't find any object named "cody" when searching for fedora and cody, where cody was not a person. | 13:18 | |
| dholbach | Hobbsee: same here | 13:18 |
| TuxCrafter | I have compared some debian packages with ubuntu and some of the ubuntu packages have far more dependecies than the ones in ubuntu, what can we do about this? | 13:18 |
| Hobbsee | dholbach: you forgot packages requring scons. | 13:18 |
| TuxCrafter | what procedures to follow | 13:18 |
| Hobbsee | TuxCrafter: reread, and correct your statement :) | 13:18 |
| dholbach | Hobbsee: that's not necessarily a problem | 13:18 |
| Hobbsee | dholbach: if it is written well, sure | 13:19 |
| Hobbsee | dholbach: still, i guess there's not that much you can do if upstream decides to use it | 13:19 |
| TuxCrafter | s/ones in ubuntu/ones in debian/ | 13:19 |
| dholbach | TuxCrafter: do you have examples? | 13:19 |
| TuxCrafter | dholbach: i believe last time I checked it was pidgin | 13:20 |
| dholbach | I noticed for example GNOME packages that use different linker options nowadays which should resolve that | 13:20 |
| dholbach | I think it was wl,as-needed that they used for that | 13:21 |
| dholbach | but I can't really comment on that, I'm no expert there | 13:21 |
| Hobbsee | TuxCrafter: debian's pidgin and ubuntu's pidgin don't tend to overlap | 13:21 |
| dholbach | I think the summary was "it should be all good now" :-) | 13:21 |
| Hobbsee | or didn't, last i checked | 13:21 |
| slytherin | dholbach: Now the suggestion I have to make is ; We should make some policy that when new java apps/libs are being added in Ubuntu (not present in Debian), we should prefer GCJ as compiler (java-gcj-compat-dev) | 13:22 |
| dholbach | I'm looking at packages.debian.org and launchpad.net right now | 13:22 |
| dholbach | slytherin: that's something the Debian / Ubuntu Java Team should decide - I can't really comment on the fitness of any compiler | 13:23 |
| slytherin | Ok. | 13:24 |
| TuxCrafter | but the problem behind it was that there were some people thing of creating a distribution spin of ubuntu or debian for the eeepc, and choice for debian because the dependecy were better and there for the total install size was much smaller for the same functionality. To bad i cant give exact examples because of my current dns problem. | 13:24 |
| dholbach | TuxCrafter: to me it seems like there's only liblaunchpad-integration0 which is in addition to the debian depends | 13:24 |
| TuxCrafter | s/thing/thinking/ | 13:24 |
| rzr | talking about that, when a java app can be built as native code, should it be ? what is the policy ? | 13:24 |
| dholbach | rzr: we absolutely prefer that | 13:25 |
| dholbach | there are packages in multiverse that ship pre-built .jar files, but we try to avoid it | 13:25 |
| rzr | I plan to do this on my packages, provide a -native and -java packages from the same source | 13:25 |
| TuxCrafter | *** is going to reset its modem to see if the dns problem resolves | 13:25 |
| dholbach | TuxCrafter: I can't comment on that - it'd be nice to see the results of an investigation - at the moment I see no points indicating that | 13:26 |
| dholbach | TuxCrafter: good luck | 13:26 |
| rzr | TuxCrafter: using other dns server may help | 13:26 |
| dholbach | TuxCrafter: does adding "nameserver 141.1.1.1" to /etc/resolv.conf help or is it more complicated than that? | 13:26 |
| slytherin | rzr: native may not be prefered. But I am not sure if there is any policy for/against that | 13:26 |
| Kmos | TuxCrafter: opendns.com | 13:26 |
| dholbach | Kmos: might be a bit hard to look it up without working DNS :) | 13:27 |
| rzr | slangasek: what are the reason to prefer jvm to native for applications ? | 13:27 |
| Kmos | dholbach: right... | 13:27 |
| slytherin | rzr: will they run with all the VMs? | 13:27 |
| slytherin | rzr: oops, please excuse me if I don't understand the concept of native code | 13:28 |
| rzr | TuxCrafter: btw : nslookup opendns.com = 208.67.219.99 | 13:28 |
| Kmos | 208.67.222.222 ; 208.67.220.220 -> opendns | 13:28 |
| TuxCrafte1 | *** everything working again | 13:28 |
| dholbach | great | 13:28 |
| dholbach | ok... any other questions? | 13:28 |
| dholbach | (moving on while we have no real Java expert around) | 13:28 |
| dholbach | (doko in #ubuntu-devel and man-di are the most knowledgeable people I know) | 13:29 |
| slytherin | dholbach: I plan to become one before hardy. :-) | 13:29 |
| dholbach | slytherin: excellent - that's highly appreciated :) | 13:29 |
| rzr | slytherin: i think it's a bit out topic, we'll talk about it the java q+a day :) | 13:29 |
| dholbach | ok... anything else? if not we'll continue with our "how to make a BAD package" discussion :) | 13:30 |
| slytherin | rzr: sure if we have one | 13:30 |
| dholbach | <rulus> missing .desktop file for a graphical application | 13:31 |
| dholbach | https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles has a lot of information on the topic of .desktop files | 13:31 |
| dholbach | it's generally a good idea to add them (preferrably in upstream land) | 13:31 |
| dholbach | <txwikinger2> icons in wrong places | 13:32 |
| dholbach | is a similar point | 13:32 |
| dholbach | <dholbach> missing files in the package | 13:32 |
| dholbach | is a really interesting one | 13:32 |
| dholbach | if you have a source package that is split up in several binary packages this mistake is very easy to make | 13:32 |
| rzr | talking about icons, can we just automatize missing icons from screenshots of apps ? | 13:32 |
| TuxCrafte1 | *** got a other question | 13:33 |
| dholbach | rzr: it's a lot of work :) | 13:33 |
| dholbach | TuxCrafte1: fire away | 13:33 |
| rzr | dholbach: for a human , not a script shell , I'll note this down :) | 13:33 |
| TuxCrafte1 | were is the defined behaviour for the remove --purge options on packages, because some times they remove for example an init script and sometimes they dont. what are the rules for this and were can you find them and who is makeing them | 13:34 |
| dholbach | as far as I know conf files are not to be removed, just if you purge the package | 13:36 |
| dholbach | debian/conffiles is the file where they are registered | 13:37 |
| dholbach | coming back to the "missing files in a package" item | 13:37 |
| dholbach | one of the easiest ways to avoid this is running | 13:37 |
| dholbach | debuild -us -uc && dh_install --list-missing | 13:38 |
| dholbach | which will (of the built source tree) make a list of files that the upstream build system wants to install, but are not installed into one of the binary packages | 13:38 |
| warp10 | Cool... | 13:38 |
| dholbach | also it's annoying if the upstream tarball ships example code or documentation, which never makes it into /usr/share/doc/<package> | 13:39 |
| dholbach | users should not have to download the upstream source to do that :) | 13:39 |
| dholbach | if necessary you can split out documentation into a separate -doc package | 13:39 |
| dholbach | <dholbach> software without active upstream | 13:39 |
| dholbach | <amarillion> dholbach, but what if the software is finished? | 13:39 |
| dholbach | * persia likes software without active upstream, if it is stable and well written. | 13:39 |
| dholbach | <rulus> (software is never finished?) | 13:39 |
| dholbach | we often receive packages of new software where the last updates were made in 2004 | 13:40 |
| dholbach | if you plan to maintain such a package, think twice if you really want to take care of bugs of this package, if there's nobody you can escalate problems to | 13:40 |
| dholbach | a good relationship to the upstream maintainer (and maintainers of other distros) is really important | 13:41 |
| dholbach | the next point on the list is somewhat similar: | 13:41 |
| dholbach | <dholbach> inactive maintainer, no bug triage | 13:41 |
| dholbach | if you plan to maintain a package, make sure that you plan to read bug reports of your users :-) | 13:41 |
| dholbach | you don't need to fix them all yourself, but you somehow need to take care of them | 13:42 |
| dholbach | any questions? | 13:42 |
| TuxCrafte1 | maybe indicate that a package has no active maintainer | 13:42 |
| TuxCrafte1 | both on the ubuntu side as upstream | 13:42 |
| dholbach | TuxCrafte1: can you elaborate? | 13:42 |
| TuxCrafte1 | as part of the Q&A | 13:42 |
| dholbach | I'm afraid I don't understand | 13:43 |
| TuxCrafte1 | dholbach: it can happen that people sent in bug reports and nothing happends to them, it would be nice for people the be able to see in lets say launcepad that the package has no active maintainers | 13:44 |
| TuxCrafte1 | this way you give some information about the quality/state of the used package | 13:44 |
| dholbach | right, but I think no user should have to worry about that, that's why it's important to bear that in mind when you start packaging new software | 13:44 |
| dholbach | a lot of packages have maintenance teams and not a dedicated maintainer | 13:45 |
| TuxCrafte1 | true | 13:45 |
| dholbach | any other questions? | 13:45 |
| dholbach | the session ended there last time, but persia had some items he encountered during reviews of packages | 13:46 |
| dholbach | Changelog in debian/docs | 13:46 |
| dholbach | debian/docs is the file where you specify which files of the source should go into /usr/share/doc/<...> | 13:46 |
| effie_jayx | dholbach, how can one help with watchfiles? | 13:46 |
| dholbach | the Changelog is different and should be installed by using dh_installchangelogs | 13:47 |
| dholbach | effie_jayx: are you referring to http://qa.ubuntuwire.com/uehs/no_watch.php ? | 13:47 |
| effie_jayx | dholbach, yes... where could I find usefull info on watchfiles and how can I help? | 13:48 |
| dholbach | ah right | 13:48 |
| dholbach | https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch is a good tutorial on writing watch files | 13:48 |
| dholbach | the manpage of uscan(1) has more information too | 13:49 |
| dholbach | does everybody know what a watch file is? | 13:49 |
| effie_jayx | dholbach, trying to learn about them | 13:50 |
| dholbach | debian/watch specifies where to get new upstream releases of the software you're packaging | 13:50 |
| effie_jayx | uscan can be found in what package? | 13:50 |
| dholbach | effie_jayx: devscripts | 13:50 |
| dholbach | this is important as with uscan you can "automatically update a package" it does not fix all issues with it, but it simplifies the task a lot | 13:50 |
| dholbach | also it's easy for others to see if your package it up to date | 13:51 |
| dholbach | we could even automate the process and have a list of packages in the archive that are not up to date | 13:51 |
| dholbach | ok... persia had another item on the list:; | 13:51 |
| dholbach | - Patching upstream makefile to install extra stuff | 13:51 |
| dholbach | where he notes: Use dh_install instead | 13:52 |
| dholbach | does that make sense? | 13:52 |
| * rzr hides :) | 13:52 | |
| dholbach | ok... any questions? | 13:53 |
| TuxCrafte1 | dholbach: isn't it better to let upstream include the extra stuff | 13:53 |
| dholbach | TuxCrafte1: sure, sometimes that works | 13:53 |
| dholbach | in some cases the upstream maintainer and you might disagree | 13:54 |
| dholbach | or you have user contributions like a new icons, etc | 13:54 |
| dholbach | but in general you're right: the more work that goes upstream, the better | 13:54 |
| TuxCrafte1 | dholbach: is't it better then to create two packages one that is mainstream and one with ubuntu enhancements | 13:54 |
| dholbach | if you add a package-extras package that just contains the additions that's probably fine | 13:55 |
| dholbach | if you re-package everything the archive admins might be a bit unhappy :) | 13:55 |
| dholbach | for reasons like: having to apply security fixes to two packages instead of one, disk space, etc etc :) | 13:55 |
| TuxCrafte1 | yea but in the spirit of bug tracking it is a lot better | 13:55 |
| dholbach | let's just say that "getting the stuff upstream" is the best solution :) | 13:56 |
| TuxCrafte1 | *** got a question about motu/packaging training | 13:56 |
| dholbach | TuxCrafte1: fire away | 13:56 |
| TuxCrafte1 | are there video tutorials for moto packaging, because there is o much info about this topic that when you start reading you dont now how much time it takes before you can build a good package | 13:57 |
| dholbach | http://wiki.ubuntu.com/PackagingGuide | 13:57 |
| TuxCrafte1 | and I want to start packaging but the guide is so big | 13:57 |
| dholbach | has a couple of "recipes" that are tutorials | 13:57 |
| dholbach | which should be easy to follow | 13:58 |
| dholbach | I don't know of any videos yet | 13:58 |
| dholbach | ok... we're at the end of our session | 13:58 |
| TuxCrafte1 | dholbach: i see the guide is starting to get organized, nice to see this | 13:59 |
| dholbach | I hope to see you all next week again | 13:59 |
| dholbach | TuxCrafte1: thanks for the flowers - I put a lot of work into it :) | 13:59 |
| TuxCrafte1 | thanks for all the info | 13:59 |
| rzr | see ya thx dholbach it's always apreciated | 13:59 |
| dholbach | thanks a lot for attending | 13:59 |
| dholbach | see you all in #ubuntu-motu :-) | 13:59 |
| TuxCrafte1 | bye and thanks daniel | 13:59 |
| warp10 | Thank you dholbach! :) | 13:59 |
| dholbach | http://wiki.ubuntu.com/MOTU/GettingStarted (if you haven't read it yet) | 13:59 |
| rzr | dholbach: what do you think about joining the java team and make a special q&a on this topic ? | 14:00 |
| dholbach | rzr: I'm afraid I'm not the right person to join the team | 14:00 |
| dholbach | rzr: but I'll try to organise a session on the topic | 14:00 |
| dholbach | I'll keep you updated | 14:00 |
| * dholbach is out to walk the dog - see you guys around! :) | 14:00 | |
| rzr | nice | 14:01 |
| rzr | later | 14:01 |
| === bigon is now known as bigon` | ||
| === bigon` is now known as bigon | ||
| === \sh_away is now known as \sh | ||
| === Pricey is now known as PriceChild | ||
| === bigon is now known as bigon` | ||
| === bigon` is now known as bigon | ||
| === bigon is now known as bigon` | ||
| === bigon` is now known as bigon | ||
| === bigon is now known as bigon` | ||
| === bigon` is now known as bigon | ||
| === bigon is now known as bigon` | ||
| === bigon` is now known as bigon | ||
| sistpoty | hi everyone, sorry for being late | 20:05 |
| warp10 | hi sistpoty | 20:05 |
| sistpoty | hi warp10 | 20:06 |
| sistpoty | so who's around for part 2 of the library packaging session? | 20:06 |
| albert23 | hello sistpoty | 20:06 |
| sistpoty | hi albert23 | 20:06 |
| sistpoty | first off, there is an excellent guide about debian library packaging. We'll use this one as a reference for this session: | 20:07 |
| sistpoty | http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html | 20:07 |
| nixternal | thanks sistpoty for the wakeup call :) | 20:09 |
| sistpoty | hi nixternal :) | 20:09 |
| nixternal | well howdy | 20:09 |
| sistpoty | ok, in part 1, we hopefully learned all the basic stuff about shared objects. | 20:09 |
| ScottK | You wouldn't have a link to the log for that would you? | 20:10 |
| nixternal | I was just gonna ask, I have a lib I gotta package up :) | 20:10 |
| albert23 | http://irclogs.ubuntu.com/2008/01/17/%23ubuntu-classroom.html | 20:10 |
| sistpoty | ScottK: sorry.. no idea if this is publically logged somewhere | 20:10 |
| sistpoty | thanks albert23 | 20:10 |
| ScottK | albert23: Thanks | 20:11 |
| sistpoty | now in part 2, we'll be packaging a library by example, and will discuss a few of the caveats | 20:11 |
| sistpoty | since I'm lazy, let's take libmyhello again from part 1 | 20:12 |
| sistpoty | http://www.potyra.de/library_packaging/libmyhello-1.0.1.tar.gz | 20:12 |
| sistpoty | everyone got it? | 20:13 |
| warp10 | y | 20:13 |
| hellboy195 | y | 20:13 |
| albert23 | yep | 20:13 |
| sistpoty | ok, let's start with debianization... unpack it, rename the tarball so that we've got a valid .orig.tar.gz | 20:13 |
| sistpoty | let's take a look, we'll always need a few files in there, let's start with debian/copyright | 20:14 |
| sistpoty | put in the usual stuff there (this is not really important for the technical bits of library packaging) | 20:16 |
| sistpoty | what else do we need... I guess we'll be using debhelper, so let's create a compat in debian/ | 20:17 |
| sistpoty | everyone got it so far? | 20:17 |
| hellboy195 | y | 20:17 |
| warp10 | y | 20:17 |
| albert23 | y | 20:18 |
| sistpoty | ok, now let's start with the interesting bits | 20:18 |
| sistpoty | the control-file | 20:18 |
| sistpoty | First off comes the usual stuff (I'll pastebin this) | 20:19 |
| sistpoty | hm... pastebin is kinda slow today :( | 20:19 |
| sistpoty | ok, I'll paste it right here... pastebin doesn't like me *g* | 20:20 |
| sistpoty | Source: libmyhello | 20:21 |
| sistpoty | Section: libdevel | 20:21 |
| sistpoty | Priority: optional | 20:21 |
| sistpoty | Maintainer: Your Name <youraddress@bla.org> | 20:21 |
| sistpoty | Build-Depends: debhelper (>> 5.0.0) | 20:21 |
| sistpoty | Standards-Version: 3.7.2.0 | 20:21 |
| sistpoty | for a library, we'll always end up with two packages | 20:22 |
| sistpoty | two binary packages even | 20:22 |
| sistpoty | one package contains the shared object(s) | 20:22 |
| sistpoty | and another one, the -dev package will contain everything you need to develop applications with the shared object | 20:23 |
| sistpoty | i.e. header-files, eventually a statically linked library, eventually pkconfig files (which specify what to pass to the compiler/linker to link against this library) | 20:24 |
| sistpoty | so let's create an entry for the -dev package | 20:25 |
| sistpoty | Package: libmyhello-dev | 20:25 |
| sistpoty | Architecture: any | 20:25 |
| sistpoty | Description: myhello library headers | 20:25 |
| sistpoty | This package contains the development headers | 20:25 |
| sistpoty | for libmyhello. | 20:25 |
| * ScottK notes sistpoty needs to update to the current standards version... | 20:26 | |
| sistpoty | ScottK: hehe, I'm not up to date | 20:26 |
| sistpoty | the package containing the shared object will need to be named in a special way: | 20:27 |
| sistpoty | it must be related to the soname. | 20:28 |
| sistpoty | the library packaging guide I mentioned contains the rules how it should be named | 20:28 |
| sistpoty | chapter 5, section 3 | 20:29 |
| sistpoty | remember the soname of libmyhello yet? | 20:29 |
| sistpoty | anyone? | 20:30 |
| warp10 | mmm... libmyhello.so.1, maybe? | 20:30 |
| sistpoty | warp10: exactly | 20:30 |
| sistpoty | if you wouldn't have remembered, you could of course always use objdump -p <shared object> to find out | 20:31 |
| sistpoty | so in this case, the name of the library would be libmyhello1 | 20:33 |
| sistpoty | if you've got a library, that contains more than one shared object | 20:33 |
| sistpoty | you'll need to create a binary package for each of these | 20:33 |
| sistpoty | let's add an entry for the binary package | 20:33 |
| sistpoty | Package: libmyhello1 | 20:34 |
| sistpoty | Architecture: any | 20:34 |
| sistpoty | Depends: ${shlibs:Depends} | 20:34 |
| sistpoty | Description: myhello library | 20:34 |
| sistpoty | This package contains the hello library. | 20:34 |
| sistpoty | ok. anyone got a clue, why the name of this binary must be related to the SONAME? | 20:35 |
| sistpoty | this binary package... | 20:35 |
| sistpoty | anoyne` | 20:36 |
| sistpoty | +? | 20:36 |
| albert23 | we want to be able to install multiple versions of the library, when ABI changes | 20:36 |
| sistpoty | albert23: excellent | 20:36 |
| sistpoty | so does anyone have an idea why this could be needed? | 20:37 |
| warp10 | sistpoty: maybe different packages may need different versions of the library? | 20:38 |
| sistpoty | warp10: this would be one argument, but not the main one. | 20:38 |
| sistpoty | let's just consider that a very essential library (maybe libc) will get updated | 20:38 |
| sistpoty | currently, I've got libc6 installed, and I guess almost all packages I've got installed will depend on libc6 | 20:39 |
| sistpoty | suddenly, a new libc7 appears | 20:39 |
| sistpoty | if it couldn't be installed side-by-side to libc6, that would mean that I had to remove *all* installed programs | 20:40 |
| sistpoty | or that all programs would immediately break if libc6 were removed by force | 20:40 |
| sistpoty | that's pretty bad, hm? | 20:40 |
| sistpoty | (I tried this once when I didn't have a clue... wasn't so funny back then *g*) | 20:41 |
| warp10 | :) | 20:41 |
| sistpoty | any questions so far? | 20:41 |
| warp10 | I have one | 20:42 |
| warp10 | Why the -dev package doesn't need any Depends: field? | 20:42 |
| sistpoty | warp10: excellent question... it needs one :) | 20:42 |
| sistpoty | so, as I wrote earlier, the -dev package is what you install if you want to build programs using this library | 20:43 |
| sistpoty | so we need to make it depend at least on the library package | 20:44 |
| sistpoty | let's add the depends line there | 20:44 |
| sistpoty | the header files in question should always match what's in the shared object | 20:45 |
| sistpoty | hence we'll need to restrict the version for this dependency | 20:45 |
| sistpoty | Depends: libmyhello1 (= ${binary:Version}) | 20:46 |
| sistpoty | however often you'll need additional libraries to compile a program with a specific library | 20:47 |
| sistpoty | so you'll need to add the corresponding -dev packages there as well. | 20:47 |
| sistpoty | a good indication should give you the NEEDED entries of the shared object | 20:48 |
| sistpoty | so you'll just need to find the corresponding -dev package that contains these shared objects | 20:49 |
| sistpoty | so, what do we need here? | 20:50 |
| albert23 | NEEDED libc.so.6 | 20:51 |
| sistpoty | great. | 20:51 |
| sistpoty | so let's find out in which package this is (we'll see a better method later) | 20:52 |
| sistpoty | just use dpkg -S libc.so.6 | 20:52 |
| sistpoty | hooray, it's libc6 :)... so we'll want libc6-dev | 20:53 |
| sistpoty | (libc6-dev is often ommitted, since build-essential already depends on it. however it's not wrong to add it) | 20:54 |
| sistpoty | as you might have noticed, in the case of libc6, the -dev package is not named like the source package | 20:55 |
| sistpoty | but instead it is named like the binary package + -dev | 20:55 |
| sistpoty | this is useful, if you want to have more than just one version of the library in the archive | 20:56 |
| sistpoty | (e.g. because one application needs the old one, and won't build with the new version) | 20:56 |
| sistpoty | then you'll need to be able to select which -dev package you want | 20:56 |
| ScottK | There's a very recent thread on adding libc6 on debian-devel that came down pretty strongly in favor of adding it. | 20:57 |
| sistpoty | if you do this, you should have the -dev package(s) of the different versoin Provide and Conflict to libmyhello-dev package | 20:57 |
| sistpoty | ScottK: ah, haven't read that one yet | 20:58 |
| sistpoty | (or maybe I have but forgot *g*) | 20:58 |
| sistpoty | ok, does everyone have the control file so far? | 20:59 |
| albert23 | y | 20:59 |
| warp10 | y | 20:59 |
| sistpoty | hehe, mine is still missing the depends line *g* | 21:00 |
| sistpoty | ok | 21:01 |
| sistpoty | what else do we need... a changelog file. just create one with dch | 21:01 |
| sistpoty | dch --create | 21:03 |
| sistpoty | (needed to look this up, thought it always was -c) | 21:03 |
| sistpoty | everyone got it filled in? | 21:04 |
| warp10 | y | 21:04 |
| albert23 | y | 21:05 |
| sistpoty | ok, then let's start with the rules file | 21:05 |
| sistpoty | let's see what targets we need to adhere to the policy: clean, build, binary, binary-arch, binary-indep | 21:06 |
| sistpoty | did I miss one? | 21:06 |
| warp10 | install? | 21:07 |
| ScottK | configure? | 21:07 |
| slangasek | not required by policy :) | 21:07 |
| sistpoty | yep | 21:07 |
| warp10 | configure should be optional, right? | 21:07 |
| sistpoty | hi slangasek btw. | 21:07 |
| * slangasek waves | 21:07 | |
| warp10 | install is optional too? | 21:08 |
| sistpoty | warp10: libmyhello fortunately doesn't need to be configured, as it doesn't use autotools | 21:08 |
| sistpoty | warp10: yes | 21:08 |
| sistpoty | let's start with clean, should be easiest | 21:09 |
| sistpoty | since we'll use debhelper, we'll first call dh_clean | 21:09 |
| sistpoty | and then: make clean | 21:09 |
| sistpoty | to cleanup libmyhello stuff | 21:09 |
| sistpoty | or, if you prefer make distclean | 21:09 |
| sistpoty | (which won't make a difference *here*) | 21:10 |
| sistpoty | then let's get a shot at the build rule | 21:12 |
| james_w | sistpoty: dh_testroot to start clean as well? | 21:12 |
| sistpoty | james_w: right, makes sense | 21:13 |
| sistpoty | ok, build should be easy as well. | 21:14 |
| sistpoty | just a call to make | 21:14 |
| sistpoty | any questions so far? | 21:14 |
| warp10 | n | 21:15 |
| albert23 | n | 21:15 |
| sistpoty | ok, then let's go to the binary target | 21:15 |
| sistpoty | since this is an arch:any package, we'll use the binary-arch target for the job, and have the binary target depend on it | 21:16 |
| sistpoty | let's add some debhelper stuff | 21:17 |
| sistpoty | dh_testdir | 21:18 |
| sistpoty | dh_testroot | 21:18 |
| sistpoty | dh_installchangelogs | 21:18 |
| sistpoty | dh_installdocs | 21:18 |
| sistpoty | dh_install | 21:19 |
| sistpoty | dh_strip | 21:19 |
| sistpoty | dh_compress | 21:19 |
| sistpoty | dh_fixperms | 21:19 |
| sistpoty | and now an interesting one: dh_makeshlibs | 21:20 |
| sistpoty | (we'll have a look at it in a few minutes) | 21:20 |
| sistpoty | dh_shlibdeps | 21:20 |
| sistpoty | dh_installdeb | 21:20 |
| sistpoty | dh_gencontrol | 21:20 |
| sistpoty | dh_md5sums | 21:20 |
| sistpoty | dh_builddeb | 21:20 |
| sistpoty | since we'll need to build s.th. before we can install it, we'll add a dependency to build for binary-arch | 21:21 |
| sistpoty | (a nicer way is to use stamps, but that's a different topic) | 21:22 |
| sistpoty | now what does dh_makeshlibs do... | 21:22 |
| sistpoty | as you may have noticed, whenever you put ${shlibs:Depends} in the control file, it will get resolved to the library packages during build | 21:23 |
| sistpoty | this is done via the shlibs-mechanism | 21:23 |
| sistpoty | if you've been here in part 1, I guess you could build one yourself | 21:23 |
| sistpoty | if you look at /var/lib/dpkg/info, you'll find a number of shlibs-files | 21:24 |
| sistpoty | let's take a look at one | 21:25 |
| sistpoty | the format is: library-name soname-version dependencies | 21:26 |
| sistpoty | let's look at /usr/lib/dpkg/info/libgnome2-0.shlibs | 21:27 |
| sistpoty | compare this to the SONAME of /usr/lib/libgnome-2.so.0 | 21:28 |
| sistpoty | this explains the first two fields | 21:28 |
| sistpoty | the third one is the package where this shared object can be found in | 21:29 |
| sistpoty | the job of dh_makeshlibs is to generate such a file for us | 21:29 |
| warp10 | cool... | 21:29 |
| sistpoty | and at this point, we can try to answer mok0's question of part 1, what to do if upstream released a new abi compatible version, but programs use this one | 21:31 |
| sistpoty | since the shlibs file can specify a version string (just look at the gnome shlibs file again) | 21:31 |
| sistpoty | we can request to have a minimum version of the library | 21:31 |
| sistpoty | this will get replaced for all packages that use ${shlibs:Depends} and build against our library | 21:32 |
| sistpoty | so we only need to tell dh_makeshlibs, that a new feature landed in the library, so that it will set version field in the shlibs file right | 21:33 |
| sistpoty | you can do this with dh_makeshlibs -V<version> | 21:33 |
| sistpoty | now if anyone has installed an older version of the library, and wants to use the program that needs the new cool features | 21:33 |
| sistpoty | he will have to upgrade the library via apt | 21:34 |
| sistpoty | any questions so far? | 21:34 |
| albert23 | How can we know which library version was the first providing a specific ABI version? | 21:34 |
| albert23 | Isn't there a risk we set version to high in dh_makeshlibs -V<version>? | 21:35 |
| sistpoty | albert23: pretty much through the same means that we can find out if the ABI is broken | 21:35 |
| albert23 | ok | 21:35 |
| sistpoty | albert23: there is no real risk in Ubuntu to set the version to high | 21:36 |
| sistpoty | however setting the version not high enough can lead to problems | 21:36 |
| albert23 | It would make backports more difficult? | 21:36 |
| sistpoty | not too sure... I don't think so | 21:37 |
| sistpoty | a backport gets compiled to whatever is in gutsy or feisty | 21:37 |
| sistpoty | so it will get built against the feisty/gutsy version of the library, which has a different version requirement | 21:37 |
| ScottK | So if you set it correctly and there isn't a sufficient ABI available, the backport build will, correctly, fail. | 21:37 |
| sistpoty | well... it doesn't really relate to building, but rather to installin | 21:38 |
| sistpoty | +g | 21:38 |
| sistpoty | in order to build against a library, the version (and ABI) is irrelevant. | 21:39 |
| sistpoty | what matters to build against it is the API | 21:39 |
| sistpoty | the version rather enforces that users *need* to upgrade the library to a minimum ABI version | 21:39 |
| ScottK | I guess I meant API then. | 21:39 |
| sistpoty | so if the API changed, the field won't really be much of a problem, since this means a new ABI in almost all cases | 21:40 |
| sistpoty | and hence a new SONAME, and a different library package | 21:40 |
| sistpoty | this version is only relevant if the ABI/API stay the same, but new features got added | 21:41 |
| ScottK | Ah. RIght. | 21:41 |
| sistpoty | any further questions? | 21:41 |
| warp10 | n | 21:42 |
| albert23 | n | 21:42 |
| sistpoty | ok, then let's try to fix the rules file and finish the package, shall we? | 21:42 |
| sistpoty | since we use dh_install, we still need to install the files into debian/tmp/ | 21:43 |
| sistpoty | let's use PREFIX=$(pwd)/debian/tmp make install for this | 21:43 |
| sistpoty | if you want, you can put this right at the beginning of binary-arch | 21:44 |
| sistpoty | or you could add an install rule and have binary-arch depend on it... whatever you prefer | 21:44 |
| sistpoty | now we'll need to sort which files go into which package | 21:46 |
| sistpoty | so we want libmyhello1.install and libmyhello-dev.install | 21:47 |
| sistpoty | the header files will go into the -dev package | 21:47 |
| sistpoty | bah... back a few lines... (recalled the Makefile wrongly)... PREFIX should of course be $(pwd)/debian/tmp/usr | 21:49 |
| sistpoty | I guess I should have added DESTDIR or s.th. to libmyhello's makefile | 21:49 |
| sistpoty | in case we'd have a statically linked library (libmyhello.a), that would go into the -dev package as well. | 21:50 |
| sistpoty | (only useful if you want to link s.th. statically against it) | 21:51 |
| sistpoty | what else do we need in the -dev pacakge | 21:52 |
| sistpoty | the .so symlink should go in there as well | 21:52 |
| sistpoty | btw: the .so symlink is what the linker will look for if you give the -l parameter | 21:53 |
| sistpoty | more specifically, if you'd call -lmyhello, it would prepand a lib and add an .so and look for this file (libmyhello.so) | 21:53 |
| sistpoty | in case there are any other files for development purposes (pkconfig files for example), these should also go in the -dev package | 21:54 |
| sistpoty | luckily we don't have these | 21:54 |
| sistpoty | in the library package should be the shared object (of course) and the symlink that's named like the soname | 21:56 |
| sistpoty | while the symlink itself would also be recreated by ldconfig | 21:56 |
| sistpoty | including it in the library package has the advantage that it will get deleted if the library is removed | 21:57 |
| sistpoty | because it's a file of the package | 21:57 |
| sistpoty | everyone got the .install files? | 21:58 |
| albert23 | y | 21:58 |
| warp10 | y | 21:58 |
| sistpoty | ok, let's give it a shot, and see if it works | 21:59 |
| sistpoty | just use | 21:59 |
| sistpoty | fakeroot make -f debian/rules binary | 21:59 |
| sistpoty | to fix the errors | 22:00 |
| sistpoty | (like my install files, that where wrong *g*) | 22:00 |
| albert23 | mine too | 22:00 |
| warp10 | argh... :-S | 22:00 |
| sistpoty | did you fix the PREFIX=... make install? | 22:01 |
| albert23 | y | 22:01 |
| warp10 | sistpoty: just a wrong install for me too :) | 22:01 |
| sistpoty | warp10: hehe | 22:01 |
| albert23 | I think $(pwd) did not work | 22:04 |
| albert23 | make tried to install in /debian | 22:04 |
| sistpoty | it should install into debian/tmp/usr/ | 22:05 |
| albert23 | I got this: PREFIX=/debian/tmp/usr make install | 22:05 |
| sistpoty | heh, I've got the same which doesn't work as well. but the answer is one line above | 22:06 |
| sistpoty | PREFIX=debian/tmp/usr make install | 22:06 |
| sistpoty | those nasty slashes *g* | 22:06 |
| warp10 | grrrr | 22:06 |
| albert23 | Yep, just removed the pwd part, that works | 22:06 |
| sistpoty | hm... I guess I'll need to read the make manual again, I was so sure that $(PWD) exists (or $(pwd)) | 22:09 |
| albert23 | $(CURDIR) ? | 22:09 |
| slangasek | $(PWD) exists only if it's set in the environment by the invoking shell | 22:09 |
| slangasek | $(shell pwd) execs out to call the pwd command, so is rather inefficient | 22:10 |
| slangasek | $(CURDIR) is the make builtin variable you should use | 22:10 |
| sistpoty | thanks... I guess I confused this with $(pwd), which I often type in the shell *g* | 22:11 |
| slangasek | :) | 22:11 |
| sistpoty | so does everyone's build succeed now? | 22:11 |
| albert23 | yep, package looks good | 22:12 |
| warp10 | looks fine! | 22:12 |
| sistpoty | damn, only mine doesn't build yet *g* | 22:12 |
| sistpoty | ok, so you've got a source package and a binary | 22:13 |
| sistpoty | let's run lintian at the binary packages. it will take a second look that we've got the files sorted out correctly | 22:13 |
| albert23 | clean | 22:14 |
| sistpoty | excellent! | 22:15 |
| sistpoty | any questions so far? | 22:15 |
| albert23 | no, that's pretty clear | 22:16 |
| warp10 | it's fine. Just wondering if it would be so easy in the real-world packaging :) | 22:17 |
| albert23 | I guess that strongly depends on upstream | 22:18 |
| sistpoty | ok, so now what would you do if the ABI of a library changed, but the SONAME didn't? | 22:18 |
| * slangasek smiles | 22:18 | |
| albert23 | complain at upstream | 22:19 |
| sistpoty | albert23: great, that should always be the first choice | 22:19 |
| sistpoty | can you imagine, while it's a bad idea, if you bump the SONAME on your own? | 22:19 |
| sistpoty | (as a packager)? | 22:20 |
| albert23 | could be risky, as it might conflict with new upstream versions? | 22:20 |
| sistpoty | that's one argument | 22:21 |
| sistpoty | but you could append a debian or ubuntu somewhere and change the build scripts, so you could circumvent this | 22:22 |
| sistpoty | any other arguments against this? | 22:22 |
| slangasek | it leads to binary incompatibility with other distros | 22:22 |
| slangasek | but that shouldn't outweigh the problems caused by binary incompatibility with previous releases | 22:22 |
| sistpoty | also, it leads to binary incompatibility for binary only software | 22:23 |
| sistpoty | (just imaging to change the SONAME of libc, and look at what breaks in multiverse) | 22:23 |
| slangasek | well, a workaround for such binary-only software would be to instruct users to create their own local symlinks for the wrong soname | 22:24 |
| sistpoty | heh | 22:25 |
| sistpoty | ok, what other interesting points do we have... | 22:25 |
| slangasek | like I said, the alternative is that you have to break all the /free/ software using the old version on upgrade :) | 22:25 |
| sistpoty | yeah, it's either bad or worse *g* | 22:25 |
| sistpoty | ok, what should you do when you upgrade a library? | 22:26 |
| slangasek | by "upgrade", you mean "package a new version"? | 22:26 |
| sistpoty | yes | 22:26 |
| sistpoty | we already learned that we should look out for ABI compatibility, so let's look at the case where we *do* have a new SONAME | 22:27 |
| sistpoty | and hence a new library package | 22:27 |
| sistpoty | anyone any ideas? | 22:28 |
| slangasek | grep -r $oldsover debian/ :) | 22:28 |
| albert23 | I think we are going to have a problem with the -dev package | 22:28 |
| sistpoty | albert23: what do you think could get problematic? | 22:29 |
| albert23 | packages requiring the old ABI will get the new ABI when we would want to rebuild? | 22:29 |
| sistpoty | exactly (but it's API in this case... compiling *P*rograms->aPi, binaries->aBi) | 22:30 |
| sistpoty | so you should check which packages actually build-depend on the -dev package. | 22:31 |
| sistpoty | if there is a large number, you could do local test-builds and see which fail | 22:31 |
| sistpoty | in case you cannot live yet with the new version alone, you could for example make a different source package and hence have two version of the library in the archive | 22:32 |
| sistpoty | one thing you might stumble over when dealing with libraries is a lintian warning about rpath | 22:33 |
| sistpoty | when you link against a library, that has an rpath set, it will tell the loader to look for the shared object only in that very directory | 22:34 |
| sistpoty | so you can specify -Wl,-rpath=/somewhere and link hello_prog against it | 22:34 |
| sistpoty | then the loader will look for libmyhello only in /somewhere when hello_prog is started | 22:35 |
| sistpoty | can anyone imagine, why using rpath for a library is a bad idea? | 22:35 |
| albert23 | well, software would break if for some reason the library is moved to another directory.... | 22:38 |
| sistpoty | exactly | 22:38 |
| sistpoty | and one use-case for moving a library is for example the ia32-libs package on amd64 | 22:38 |
| sistpoty | ok, any questions? | 22:39 |
| slangasek | (and multiarch! whoo!) | 22:39 |
| slangasek | albert23, sistpoty: I would note that the general case is that we don't want to continue supporting an old API for a library, even if it means some work has to be done to get the applications ported | 22:40 |
| slangasek | so it's /usually/ better to have the new library version take over the source package name and the -dev package name, and only reintroduce an oldlibs package as a last resort | 22:40 |
| sistpoty | thanks for clarifying | 22:41 |
| albert23 | Well, one question: what would be the best place to look for bugs / qa issues to practice what we learned? | 22:41 |
| sistpoty | hm... that's a good question indeed | 22:42 |
| sistpoty | well, one thing is that you could review library packages on REVU | 22:42 |
| sistpoty | or get your hands dirty and package a library | 22:43 |
| sistpoty | ok, I guess we're through with the session... slangasek: anything important I forgot or you'd like to add? | 22:44 |
| slangasek | sistpoty: I only had half an eye on the channel today; I guess you didn't talk about techniques maintainers can use to automatically detect ABI breakage when moving to a new upstream version? | 22:45 |
| sistpoty | slangasek: nope | 22:45 |
| slangasek | the dpkg in hardy includes the new dpkg-gensymbols code developed by Raphaël Hertzog in Debian; it basically creates a manifest, declaring which symbols were added in which version of the package | 22:46 |
| slangasek | the /side/ benefit of this is that if you already know which symbols are supposed to be present, you know if any have gone missing | 22:46 |
| slangasek | so http://qa.debian.org/cgi-bin/mole/seedsymbols is a site that includes automatically generated symbol manifests for all libs in the archive | 22:47 |
| slangasek | (the Debian archive, that is; most will be applicable to Ubuntu too, obviously) | 22:47 |
| slangasek | http://wiki.debian.org/UsingSymbolsFiles is a general description of this | 22:48 |
| slangasek | I still need to use this on my own packages, so I can only give you theoretical insight into this stuff, not much practical :) | 22:48 |
| slangasek | and everyone's eyes glaze over again ;) | 22:49 |
| albert23 | Yeah, I guess I will first do some attempts to do the work manually. | 22:50 |
| albert23 | I have bookmarked those links for later use... | 22:50 |
| slangasek | one example of this in practice is the zlib1g package | 22:51 |
| slangasek | which the maintainer, Mark Brown, blogged about as well (syndicated on planet.d.o) | 22:51 |
| sistpoty | heh, I skipped this post, and wanted to read it later (which I then forgot *g*) | 22:52 |
| sistpoty | ok, anything else? | 22:52 |
| sistpoty | then thanks everyone for coming :) | 22:53 |
| albert23 | No, not for me. I have learned a lot these two sessions! | 22:53 |
| sistpoty | and thanks very much slangasek for your expert help! | 22:53 |
| albert23 | sistpoty and slangasek many thanks for these sessions! | 22:53 |
| warp10 | Thank you sistpoty and slangasek, they have been two great sessions | 22:54 |
| sistpoty | and now I'm falling in my bed :) | 22:54 |
| sistpoty | good night everyone | 22:54 |
| warp10 | I hope the wiki has room for logs, they would be really useful :) | 22:54 |
| albert23 | good night | 22:55 |
| sistpoty | sure, I'll find a place | 22:55 |
| === bigon is now known as bigon` | ||
| === bigon` is now known as bigon | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!