=== dudus_ is now known as dudus [00:31] What is the right way of preparing diff for new upstream version? Interdiff or debdiff? [00:47] Jazzva: afaik should be interdiff. debdiff is used for the same upstream version [00:48] ruiboon: Thanks [00:55] Jazzva: We no longer use interdiff. The approach now is to use a .diff.gz, and somehow give a link to the upstream tarball, preferably with either a debian/watch file or a debian/rules get-orig-source rule. [00:57] TheMuso: Hmm, ok. I have already uploaded the interdiff, but I'll prepare diff.gz. I couldn't remember if that was the process in the last upload for this package, but it looks like it was. Thanks for the help :) === fale_ is now known as fale [02:15] someone know if its possible to dist-upgrade from debian lenny to ubuntu hardy? [02:15] its a dom0 machine [02:15] No [02:16] some reasonsable way to do this/ [02:16] Reinstall. [02:16] It's the only option. [02:16] hell... [02:17] What you're asking is to both crossgrade and downgrade. [02:17] another to get out: its possible to install ubuntu into a promise S150 TX4 raid? [02:17] because its a softraid controller... so i dunno if i can do this [02:18] Also, this isn't a support channel. You want #ubuntu. [02:18] ok, np [02:18] wgrant: thanks! [02:18] * ajmitch did once do a crossgrade from sid to hoary, about a month after warty released [02:19] of course at the time there weren't quite so many ubuntu modifications [02:20] And Hoary was months older than sid... [02:20] *wasn't [02:20] Changing at release time to the next dev release would be a bumpy ride for six months, but might be least painful. [02:20] right, it was during the autosync phase [02:21] Changing from a dev non-release to an earlier release would be very, very difficult. [02:22] wgrant: Yes, indeed. Nearly impossible, given how dpkg does things. [02:30] * ScottK almost succeeded once in upgrading an old Xandros 3.0 (based on Sarge) install to Dapper. [02:31] almost? [02:31] ScottK: Also, that's release to later release, which is easier than pre-release to older release [02:31] It was going very nicely until I did a bad thing. [02:31] Yes. [02:32] my sid->hoary install lasted well until dapper, when the hardware died & I did a fresh amd64 install [02:32] ajmitch: You didn't want to try the i386 -> amd64 upgrade? ;) [02:33] couldn't be bothered :) [02:34] ScottK: What was the "bad thing"? [02:34] the fresh install gave me a chance to setup lvm on raid properly from the installer, rather than trying to do an in-place upgrade [02:34] * persia has been waiting for a good excuse to do that [02:34] I've never crossgraded from Debian, but I do have a Warty/Hoary (I forget which) installation which has been upgraded through every release and is now on Hardy. [02:35] that's just working as intended [02:35] But our upgrades don't work, remember? [02:35] I'm still in the process of upgrading that amd64 install to hardy [02:35] a few packages at a time [02:39] persia: I thought I had successfully booted into the new kernel (I hadn't - lilo got me and I hadn't given enough attention to exactly what happened) and I deleted some critical kernel modules from the old kernel. [02:39] ScottK: Ah. That can hurt. === evalles_ is now known as recover [02:43] Yeah. === recover is now known as effie_jayx === asac_ is now known as asac [03:48] Is the addition of the Vcs-Svn field in debian/control considered too significant to be dropped? [03:53] nhandler: How do you mean? For a merge? [03:54] persia: Yeah. One of the Ubuntu changes was adding a Vcs-Svn field to debian/control. I don't know if this is significant or not [03:54] Very much so. [03:54] nhandler: It might be, depends on the Vcs-Svn entry. [03:55] If Ubuntu added it for an Ubuntu-dedicated VCS, than it's essential. [03:55] * RAOF lets persia take this one :) [03:55] If Ubuntu added it because Debian happens to keep something somewhere, maybe less so. [03:55] If Debian updated and removed it for internal Debian purposes, it's critical that we drop it, even though it might look like outstanding Ubuntu variation. [03:56] These cases need a bit more investigation, and the automated tools can't help very much. [03:57] persia: It doesn't look like the field was ever present in Debian. It points to: vn://svn.debian.org/utnubu/packages/gtimelog. [03:57] nhandler: Hmm.. That's a somewhat odd case. [03:58] Does that repo have the existing package? [03:58] Generally, I think the Utnubu changes are worth keeping, but the team is less active these days :( [03:59] persia: I'm not the familiar with svn, but when I attempted to go to svn.debian.org/utnubu/packages/gtimelog in firefox, I got a 404 error [03:59] nhandler: How about svn co svn://svn.debian.org/utnubu/packages/gtimelog [03:59] persia: Do you think this is because utnubu is no longer the maintainer? [04:00] "utnubu" was never the maintainer. That's just a Debian team that helped reduce the Debian/Ubuntu variation (somewhat like DCT, but from the other side) [04:01] persia: The svn co command downloaded an older version, 0.0+svn65. The version I am merging is 0.0+svn88-2 [04:01] nhandler: Then you want to drop it, as it is clearly inaccurate. [04:02] persia: Ok, I'll drop it. Just out of curiosity, what does that field do? [04:02] nhandler: It tells the package management tools to tell the user that the source is maintained in a VCS. [04:02] This makes it easier for collaborative maintenance, as people can just update the VCS. [04:03] persia: Ok, but it doesn't actually download anything from the VCS, right? [04:05] nhandler: It can, it depends on which tools you use. apt-get source doesn't. [04:05] Good examples of how this works are for the Python Applications Packaging Team or the Games team. [04:05] In the vast majority of cases, both teams sync all the time, as when there are Ubuntu changes, Ubuntu members of the team commit them to the VCS, and they are in the next Debian release. [04:06] persia: Ok, I think I get it now. Thanks for all of your help (once again ;) ). I'm going to go and finish up the bug report. Then I'm going to get some sleep [04:07] nhandler: Glad to explain. Thanks for asking, and good luck with the merge. [04:07] persia: Actually, now that I can drop the Vcs-Svn addition, it is a sync ;) [04:09] nhandler: Even better :) [04:31] TheMuso: So, what do I have to do to get an SRU approved? :-) [04:31] beg? beer? [04:32] StevenK: I assume you've followed https://wiki.ubuntu.com/StableReleaseUpdates [04:32] StevenK: If so, bug number please. :) [04:32] * StevenK peers at the wiki page [04:33] TheMuso: Bug 195260 [04:34] Launchpad bug 195260 in mailscanner "MailScanner won't start due to variable $FIELD_NAME" [Undecided,Confirmed] https://launchpad.net/bugs/195260 [04:36] StevenK: looking. [04:37] Heh. MailScanner in Intrepid is caught up by the Perl transition. [04:38] StevenK: ACK. Noted in the bug also. [04:38] TheMuso: Hm. Do I still need two acks? [04:38] I would say get into intrepid first but since it will affected in the perl transition things should sort themselves out. [04:39] StevenK: No just one. [04:39] TheMuso: Right, since the version of MailScanner in Intrepid is a sync, I seriously doubt it has the same problem. [04:40] StevenK: Indeed. [07:14] good morning [08:35] white: You're killing off 915resolution, I see. === POX__ is now known as POX_ [08:49] is it still needed? i've been able to get proper behaviour without 915resolution and just a few xorg.conf tweaks since hoary [08:52] directhex: Um, you can't have needed it in the first place, then... [08:52] The X driver changes needed to work around it only appeared in -i810-modesetting, which later became -intel, which only appeared in the last couple of Ubuntu releases. [08:53] hm, i'm confusing 915resolution with i855-crt [08:53] Ah, that makes sense. [08:53] But you're right, 915resolution is no longer required. [08:55] i had terrible trouble with the -intel driver, which forced purchase of a bunch of geforces [08:55] but ho hum [08:57] When was this? [08:57] I have found -intel to be the best driver I've worked with. [09:00] hm... i think i was using a hardy alpha, and a release version didn't help [09:00] it strongly objected to the widescreen 20" HP monitors i was using [09:44] would anyone be interested in pushing https://bugs.launchpad.net/ubuntu/+source/totem/+bug/217301 for SRU. Sebastien Bacher has commented that it is simple and worth it. it has been fixed in debian and intrepid [09:44] Launchpad bug 217301 in gst-plugins-ugly0.10 "Real Player stream is garbled on BBC radio" [Medium,Fix released] [09:55] oh, that's not just me then [09:55] i'd say it's worth an SRU, not that my word counts for anything [10:10] ssam: it seems a good SRU candidate. please, nominate for hardy and subscribe motu-sru. If you can prepare a debdiff for hardy-proposed and provide a good TEST CASE, it would be great. [10:10] can the debdiff by pulled out of the debian or intrepid update? [10:11] does the intrepid update change anything other than fixing that bug? [10:12] directhex, i dont think so https://launchpad.net/ubuntu/+source/gst-plugins-ugly0.10 its the 0.10.7.4-1 version [10:13] ssam: since there is a new upstream version, you should simply apply patch from upstream and prepare a new revision in hardy. [10:14] it is not probably worth backporting a whole release, unless it fixed only this bug [10:14] the version number HAS changed, so you should check the upstream changelog to see what changed from 0.10.7.3 to 0.10.7.4 [10:14] ok [10:15] i have already put a patch on the bugreport that just makes the changes needed https://bugs.launchpad.net/ubuntu/+source/totem/+bug/217301/comments/11 [10:15] Launchpad bug 217301 in gst-plugins-ugly0.10 "Real Player stream is garbled on BBC radio" [Medium,Fix released] [10:16] I see, is it the one provided by gnome 529359 ? [10:16] Gnome bug 529359 in gst-plugins-bad "BBC Real Audio stream is just noise" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=529359 [10:17] its from gnomes SVN server [10:17] looks like it to me, DktrKranz [10:18] i mean the freedesktop svn [10:19] good, then. Just apply in gst-plugins-ugly0.10 source package and prepare a debdiff. If you need guidance, you can ping me or ask here :) [10:22] DktrKranz, are these https://wiki.ubuntu.com/MOTU/Contributing the right instructions? [10:26] Hey guys, I am trying to build a source package but I seem to get an error when doing so. it complains about ": or ::" in the target file 'clean', it is basically in the clean section of debian/rules. I am sure I did not touch there and the file just reads 'clean:' to state the clean section. [10:27] DktrKranz, is it ok to just apply the patch, or do i need to put it in debian/patches [10:27] ssam: yes. They're not a complete set, but they include basic steps. Since SRUs are a bit different from regular uploads, feel free to ping if you need assistance. [10:29] effie_jayx: hi, does the package use cdbs? [10:29] and is it ok, that i dont know exactly how the patch works. just that it does work for me, and that upstream have committed it [10:29] * effie_jayx checks [10:30] james_w, yes [10:30] Is there a problem creating intrepid chroots (pbuilder) atm? [10:30] effie_jayx: with cdbs targets should use '::', let me see if this is explained somewhere. [10:31] james_w, thanks [10:31] http://pastebin.ubuntu.com/16822/ [10:31] effie_jayx: no, the docs don't explain this well. If you change "clean:" to "clean::" does it work? [10:32] james_w, worked [10:33] james_w, strange. as I did not touch that section of debian/rules [10:33] asac: ping [10:33] james_w, thanks for the tip :D [10:34] effie_jayx: are you doing a merge? [10:34] james_w, yes [10:34] effie_jayx: was it changed in Debian? [10:35] james_w, basically it was a package that was not in debian and the debian/rules is a lot different [10:35] devfil: hey. [10:35] james_w, my guess is that mom messed up with the :'s from the package === propp1 is now known as proppy [10:36] hi asac, we didn't speak [10:36] effie_jayx: ah, ok. It's possible the merge caused this them. what's the package, I'd like to take a quick look? [10:36] devfil: yeah sorry. [10:36] DktrKranz, do i need to have gpg keys set up to do this [10:36] james_w, bakery2.4 [10:36] asac: np [10:36] devfil: do you have any preferences on the areas you would like to learn/contribute? [10:36] ssam: it is not strictly required [10:37] so can i skip the debuild -S stage, or tell it not to look for a key [10:38] ssam: "debuild -S -uc -us" tells it not to sign [10:38] asac: no, I don't have preferences [10:38] james_w: you're quick ;) [10:39] thanks [10:40] devfil: did you use vcs systems in the past? [10:41] asac: I don't know what is a vcs system [10:41] devfil: cvs, svn, git, bzr? [10:41] effie_jayx: yeah, Debian switched to cdbs so the merge would have been a bit confused. It says debian/rules was conflicted, so did you have to remove conflict markers from the file? [10:41] asac: then no [10:42] devfil: ok. do you know what patches are? [10:42] james_w, yes I did, but I may have forgoten only clean then [10:42] asac: yes [10:42] james_w, I will double check. [10:46] devfil: ok, then I guess you qualify to start doing merges [10:47] asac: I already merged different packages [10:47] devfil: ah. ok, then what do you want to learn? [10:48] asac: SRU and how to fix bugs more difficult than doesn't contain desktop file [10:49] james_w, another interesting issue is the naming conventions for libbakery-common [10:50] james_w, dholbach suggest we keep the name for it at least until next LTS [10:50] effie_jayx: ah, I'd listen to dholbach then :-) [10:50] effie_jayx: I didn't suggest that - I just said we need to bear in mind that there's a naming change :) [10:51] dholbach, ohhh [10:51] my bad then [10:51] effie_jayx: we'd need an additional conflicts/replaces then at least [10:51] effie_jayx: the generally preferred thing to do its to follow Debian, but make sure to transition existing users properly. [10:51] (that's the only thing I discovered we need to make sure - but I didn't look at it too closely) [10:51] the debian changes look very good so the closer we get, the better [10:52] DktrKranz, i am trying to use pbuilder to build the unmodified version but i get dependency errors http://pastebin.ubuntu.com/16828/ [10:52] That's waht I did [10:52] well I am building taking all big changes from the debian packages [10:53] i have "deb-src http://gb.archive.ubuntu.com/ubuntu/ hardy restricted main multiverse universe" in my source.list [10:53] mostly documentation stuff. placing the files where they should be in terms of hierarchy [10:54] so I am waiting for the build to quick check with a dpkg --contents and see if it keeps things in place [10:54] * effie_jayx crosses fingers [10:55] devfil: ha ;) [10:56] asac: and more important is how to triage, I've read wiki pages but I don't know hot to start etc... [10:56] dholbach, so I will check to see if the package moves docs like the debian package suggests and then I shall go with the package, shal make sure it conflict and replaces the current ubuntu package [10:57] dholbach and james_w , thanks [10:57] s/hot/how [10:57] ssam: do you have universe enabled inside the chroot? [10:57] effie_jayx: you ROCK [10:57] dholbach, and you DJ [10:57] :D [10:58] hahahaha [10:58] effie_jayx: I take that as a compliment :) [10:58] james_w DJs too and he was just awesome [10:58] devfil: to start, pick out a few important packages with a decent bug load [10:58] and monitor them. [10:59] * james_w hugs dholbach [10:59] devfil: the other way is to find bugs that are milestoned, targetted for hardy [10:59] ssam: be sure to put COMPONENTS="main restricted universe multiverse" in your pbuilderrc [10:59] or milestoned for intrepid [11:00] * dholbach hugs james_w back :) [11:00] asac: this is how to do a SRU? [11:00] dholbach: mind spending some nights in northern italy as DJ? They pay well on Garda Lake :P [11:00] devfil: depends on what oyu mean by SRU [11:00] devfil: SRU basically just means that you want to bring a fix to a stable release [11:01] devfil: that is not a security issue [11:01] DktrKranz: let's see if we can combine that with some kind of Ubuntu meeting :-) [11:01] heh [11:01] asac: ok [11:01] devfil: if you want to identify bugs that are already more or less approved to be suitable to be fixed in a stable update you should look at the "hardy", "gutsy" buglist [11:02] https://bugs.edge.launchpad.net/ubuntu/hardy [11:04] asac: ok [11:05] devfil: if you finnd important bugs on your own, you can nominate that bug and once you get a dev approve it for "hardy", you can work on it. [11:06] ok [11:06] devfil: usually only important bugs get approved for a stable update. But having a good patch at hand can help to better understand the risk/benefit ratio [11:07] and thus might lead to approval for bugs that wouldnt have been approved without a patch [11:08] asac: uhm ok [11:09] Can someone help me with this error setting up an intrepid pbuilder? http://pastebin.ubuntu.com/16822/ === cprov is now known as cprov-lunch [11:20] asac: and how to triage? [11:22] wgrant: jip, i requested the removal. Do you still have a usecase for it or were you just noticing it? [11:22] devfil: hard to give general rule. i think we would need specific bugs to look at [11:24] <\sh> wgrant, damn...what I was thinking [11:24] asac: for example this: https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/237302 [11:24] Launchpad bug 237302 in epiphany-browser "Epiphany crashes on using the zoom function" [Undecided,New] [11:25] devfil: first step is figuring if its reproducible [11:25] devfil: if you can, you should do a backtrace [11:26] asac: ehm...backtrace? [11:26] devfil: take a look at the backtrace, look in code and see if the information in the backtrace makes sense. [11:27] if so forward upstream and if you feel good enough to fix it, start to work on it [11:27] devfil: https://wiki.ubuntu.com/DebuggingProgramCrash [11:28] devfil: there are three ways mentioned to get an idea about the crash: Backtrace, valgrind, strace [11:28] try to get used how they work, what the output means and so on [11:28] asac: if the backtrace makes no sense? [11:30] DktrKranz, i have attached a debdiff, added a test case, nominated for hardy, and subscribed motu-sru https://bugs.launchpad.net/ubuntu/+source/totem/+bug/217301 [11:30] Launchpad bug 217301 in gst-plugins-ugly0.10 "Real Player stream is garbled on BBC radio" [Medium,Fix released] [11:30] does it look ok [11:31] white: Noticing, sorry. [11:31] Somewhat glad to see that hack go, I guess. [11:31] Though it was invaluable in its time. [11:38] jip, it had its moments :) [11:44] hi folks [11:45] <\sh> moins siretart [11:45] <\sh> hmm [11:45] <\sh> crap tabcomp [11:45] <\sh> moins sistpoty|work i meant [11:45] hi \sh [11:48] hey \sh! [11:48] * siretart highfives sistpoty! [11:49] hi siretart [11:49] sistpoty|work: great job on the cirrus beast! :) [11:49] thanks [11:57] hm... looks like there are no daily images built atm, right? [11:59] sistpoty|work: AFAIUI cjwatson or evand maintain the daily builds. you might want to ask them? [12:00] sistpoty|work: but anyway, the package is not in -updates yet, is it? [12:01] siretart: no, but I promised bryce to test his new dexconf with kvm today [12:01] sistpoty|work, https://bugs.launchpad.net/ubuntu/+bug/236544 see colins comment [12:01] Launchpad bug 236544 in ubuntu "Daily cds not being preduced for PowerPC" [High,Invalid] [12:01] sistpoty|work: ah, I see [12:01] thanks ssam [12:03] directhex: finally you got mono updated. congratulations ;) [12:05] oh, did i? must've been slomo__, i was poking him earlier this morning [12:16] directhex: of course he uploaded it but you prepared the necessary diff ;) Now you are responsible for it (bugs ,..) =) [12:18] i will take on every responsibility required to pass the buck to meebey@debian.org [12:18] directhex: self fixing :P [12:20] it's called delegation! it's like a management job. the employees (debian developers) do the hard work in packaging and bug reporting. the rest of us wear cool hats, and drink all the champagne at the shareholders' meetings [12:20] i should go through old mono bugs & see if they still apply [12:21] directhex: if your aren't a MOTU you can't delegate ^^ [12:21] hi all [12:22] poot. and it's in main, too, so that wouldn't help [12:22] huhu norsetto [12:22] huhu sebner [12:23] ^^ === thekorn_ is now known as thekorn === elky is now known as elkbuntu [12:35] sebner: weather looks horrible in hermagor: http://www.webcams.travel/map/#lat=46.626571&lng=13.371906&z=14&t=h [12:36] Would a kind MOTU please help me with bug 236717. After additional correspondence with the submitter, the discribed behavior was actually due to a bonked PHP install. Should I "assign" the bug to myself and set the "status" to "invalid"? [12:36] Launchpad bug 236717 in ampache "ampache package install never completes" [Undecided,New] https://launchpad.net/bugs/236717 [12:46] sebner, so is it my job to close the merge bug, or the guy who uploaded it? [12:47] <\sh> porthose, can you make the correspondence a part of the bug? [12:47] <\sh> porthose, if yes, please attach it, and just invalid the bug...no need to assign it to you... [12:48] sure [12:48] k thx [12:48] <\sh> porthose, welcome :) [12:51] directhex: it is your job to mention the merge bug in debian/changelog, and the job of the sponsor to verify that you did so [12:52] * Merge with Debian (LP: #225426), remaining Ubuntu changes: [12:53] directhex: in that case the bug should be closed when it hits the archive [12:53] automatcally by soyuz [12:54] Published in intrepid-release 2 hours ago [12:58] directhex: it seems the changes file hasn't been created on an ubuntu but on a debian system [12:59] directhex: at least the changesfile does not have a bug closing directive. [12:59] hey, I think we found some developer packages (cxxtest and csockets) that require packaging. They're at https://edge.launchpad.net/~gama/+archive . I'll ask Gama to follow up with the instructions at the Contributing doc . [12:59] directhex: who did create that changes file? [12:59] siretart, which changes file? i just made a debdiff! [13:00] directhex: who did sponsor you? [13:01] siretart, probably slomo__, since i was poking him this morning [13:02] slomo__: if you upload stuff to ubuntu, please use an ubuntu chroot even for creating the source packages, or make sure that you manually close the launchpad bugs by hand. As seen on bug #225426 [13:02] Launchpad bug 225426 in mono "[wishlist]please update mono to 1.9.1" [Undecided,Confirmed] https://launchpad.net/bugs/225426 [13:02] directhex: for this upload, the bug must be closed manually [13:02] gpg: Good signature from "Sebastian Dröge " [13:03] siretart, i'll close it then. "fix released"? [13:03] yes [13:03] yes [13:10] hehe killed my first bug, thx again \sh :) [13:30] I got this, while `sudo apt-get purge packagename`-ing my package: [13:30] Removing ueagle-setup ... [13:30] update-rc.d: /etc/init.d/ueagle-startup exists during rc.d purge (use -f to force) [13:30] dpkg: error processing ueagle-setup (--remove): [13:30] subprocess post-removal script returned error exit status 1 [13:31] Why? What did go wrong? [13:32] Why does /etc/init.d/ueagle-startup exist? Why did it not get removed before postrm was executed? [13:32] amikrop: You didn't use dh_installinit [13:32] What is it? [13:32] It's a special helper to install init scripts. [13:32] man dh_installinit [13:33] persia: By the way, thanks to your yesterday course on #ubuntu-classroom, I managed to create a Ubuntu-valid Debian package :) [13:33] amikrop: Well, almost. It doesn't purge cleanly yet :) [13:34] persia: I am sure it will soon do ;-) [13:36] persia: And how can I remove the "badly-purged" package now? :-/ [13:36] amikrop: BY hand [13:36] amikrop: Just purge the package, and then delete the files it complains about, and then hunt down any leftovers. [13:38] Aha. [13:39] ssam: a couple of notes regarding bug 217301, your debdiff require some adjustments, first of all target must be hardy-proposed (as per policy), you should also adjust maintainer field as per wiki.ubuntu.com/DebianMaintainerField. Last one: patch should be managed with simple-patchsys. [13:39] Launchpad bug 217301 in gst-plugins-ugly0.10 "Real Player stream is garbled on BBC radio" [Medium,Fix released] https://launchpad.net/bugs/217301 [13:39] Hi * [13:39] patch-systems are explained here https://wiki.ubuntu.com/PackagingGuide/PatchSystems [13:40] Hello geser :-) [13:40] persia: I handled my rules install section like that: http://paste.ubuntu.com/16863/ [13:42] amikrop: I think that's overkill, and possibly wrong (as it's not compressed), but then I'm a CDBS fan. [13:43] persia: Compressed? What should I compress? [13:44] dh_compress [13:49] persia: I uncommented dh_installinit. I created `debian/ueagle-startup.init`. Should I remove ueagle-startup from being manually copied to /etc/init.d/ueagle-startup (by `debian/rules`)? [13:49] Should I left postinst and postrm, as are? [13:50] (`debian/postinst` and `debian/postrm`) [13:52] I mean, I uncommented dh_installinit in `debian/rules`. [13:52] (and gave it the -r argument, too) [13:54] amikrop: I'd need to be looking at your package in considerably more detail to answer that. [13:54] Your best bet is to try it, and see what works for you. [13:54] It doesn't work. [13:54] linitan -iIv can help, although carefully reading all the debhelper manpages will also be informative. [13:59] persia: I want to have a simple posinst and a simple postrm. Is it necessary to use dh_installinit? [14:01] amikrop: it's not required to use dh_*, but it makes it easier [14:02] geser: So, I can have a postinst and a postrm without dh_installinit. [14:02] Is that correct? [14:03] yes [14:03] dh_installinit is only a helper so every package does it the same way and doesn't repeat the common problems [14:03] amikrop: The key part is that you have to handle everything in /etc carefully, and especially so the init scripts, to ensure that you preserve the user changes. [14:05] OK. So, what do I do with 4 things: 1) postinst 2) postrm 3) rules 4) the startup script? [14:05] Where do I place each, in order to have a correct init script that installs and gets removed correctly? [14:06] I bet these things: 1) place postinst in debian/ 2) place postrm in debian/ 3) uncomment dh_installinit 4) rename it to startup-script.init and place it to debian/ [14:07] Please, correct me where I am wrong. [14:08] amikrop: looks good [14:10] OK. Before trying it out, what about the manual copy of startup-script to /etc/init.d/startup-script? Should I skip it? [14:10] (I mean, the cp command in debian/rules.) [14:11] Will dh_installinit copy my startup-script automatically and I should skip doing it manually? [14:11] if I understand the man page for dh_installinit correctly it will install the init-script for you [14:12] So, I should comment out that line in my rules file: "cp $(CURDIR)/start/* $(CURDIR)/debian/ueagle-setup/etc/init.d"? [14:15] yes, you can comment it out [14:16] OK. Again, before trying it out, should I also remove etc/init.d from my debian/dirs file? [14:17] Or is it necessary, even if I use dh_installinit? [14:17] iirc it should get created automagically so you don't need to list it in debian/dirs [14:18] Hi sebner [14:18] geser: Alright. Let me try all these out, and I will let you know the results :-) [14:19] hoi geser =) [14:23] geser: I ran dpkg-buildpackage and created the .deb. But I extracted it, and I also extracted data.tar.gz only to find out that there was no etc/init.d/startup-script :-( [14:24] geser: So, it seems it didn't work. [14:25] how did you call the init script and how is your package named? [14:26] Hey [14:28] geser: ueagle-startup.init [14:28] geser: My package is named ueagle-setup. [14:29] try to use the same name for both, i.e rename your init script to ueagle-setup.init [14:29] geser: OK [14:33] geser: Worked. Thank you. [14:33] \sh, did it happen to you to request some p-a-s adjustments? [14:35] <\sh> DktrKranz, yes for wine on lpia [14:37] \sh, who did you ask to do the adjustment? infinity? [14:37] <\sh> DktrKranz, infinity/elmo/and theres another one mentioned in the p-a-s file... [14:38] \sh, is publicily available in Ubuntu? Or should I take Debian's ? [14:39] <\sh> DktrKranz, it's one for all :) [14:39] <\sh> DktrKranz, it's shared :) [14:39] ah, new thing learned :) [14:40] \sh: thanks [14:40] <\sh> and it happens to be a good thing, that the responsible people are involved or paid by ubuntu/canonical ;) [14:40] <\sh> I think lamont was the third man :) [14:41] yessir :) [14:42] ok, I'll drop a mail to them [14:44] <\sh> DktrKranz, hehe :) [14:44] geser: I examined the .deb manually and found out that everything was OK, but a prerm was added by dh_installinit. Also, when I tried to remove my package, I got this error: http://paste.ubuntu.com/16880/ [14:46] amikrop: prerm is ok, as you want to stop what you started before removing it [14:46] It seems dh_installinit did well to copy /etc/init.d/ueagle-startup but neglected to remove it, before postrm was ran. === ember_ is now known as ember [14:48] amikrop: why does it talk about /etc/init.d/ueagle-startup? didn't you renamed it to ueagle-setup? [14:48] geser: No, I just used dh_installinit -r --name=ueagle-startup [14:48] ah [14:49] And renamed ueagle-setup.init to ueagle-setup.ueagle-startup.init as the man page said. [14:49] hmm [14:50] doko, I've just added a comment to bug #204594, about line 90 and 91 of the init-functions file. I think it needs to be combined with a || as well to transfer the status from $? if set -e is set. [14:50] Launchpad bug 204594 in lsb "UVF exception for lsb-3.2" [Undecided,Fix released] https://launchpad.net/bugs/204594 [14:51] kirkland: This is the issue we discussed last week about the set -e. [14:51] DktrKranz, thanks for the comments, where can i find information about simple-patchsys. it will try to do a better patch this evening. [14:52] geser: It seems I must somehow tell dh_installinit to remove /etc/init.d/ueagle-startup before postrm executes. [14:52] DktrKranz, oops, you already ansered that :-) [14:54] persia: Does dh_installinit normally remove the init script it installed? [14:55] amikrop: It should insert some logic in postrm. You might need to add #DEBHELPER# [14:56] owh: hey [14:56] kirkland: Hiya, nearly off to bed. I just pinged you about the comments we made last week on the set -e. [14:56] owh: right [14:57] kirkland: I just poked the person who submitted the patch, suspecting it might be simpler, rather than me starting a new bug and patch cycle. [14:57] owh: good idea [14:57] kirkland: If we keep this up we might make the functions work yet :) [14:58] persia: postrm is manually created by me. dh_installinit just generated a prerm. Where should I add #DEBHELPER#? [14:58] kirkland: See you in a couple of hours for the u-s meeting. [14:58] owh: k [14:59] amikrop: At the bottom of your maintainer scripts. [14:59] Both postinst and postrm? [15:00] owh: I think you're looking for doko [15:00] persia: The truth is that dh_installinit also generated ueagle-setup.postinst.debhelper, ueagle-setup.postrm.debhelper and ueagle-setup.prerm.debhelper. [15:01] about what? [15:01]