[00:31] <Jazzva> What is the right way of preparing diff for new upstream version? Interdiff or debdiff?
[00:47] <ruiboon> Jazzva: afaik should be interdiff. debdiff is used for the same upstream version
[00:48] <Jazzva> ruiboon: Thanks
[00:55] <TheMuso> 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] <Jazzva> 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 :)
[02:15] <leleobhz> someone know if its possible to dist-upgrade from debian lenny to ubuntu hardy?
[02:15] <leleobhz> its a dom0 machine
[02:15] <Laney> No
[02:16] <leleobhz> some reasonsable way to do this/
[02:16] <wgrant> Reinstall.
[02:16] <wgrant> It's the only option.
[02:16] <leleobhz> hell...
[02:17] <wgrant> What you're asking is to both crossgrade and downgrade.
[02:17] <leleobhz> another to get out: its possible to install ubuntu into a promise S150 TX4 raid?
[02:17] <leleobhz> because its a softraid controller... so i dunno if i can do this
[02:18] <wgrant> Also, this isn't a support channel. You want #ubuntu.
[02:18] <leleobhz> ok, np
[02:18] <leleobhz> wgrant: thanks!
[02:18]  * ajmitch did once do a crossgrade from sid to hoary, about a month after warty released
[02:19] <ajmitch> of course at the time there weren't quite so many ubuntu modifications
[02:20] <wgrant> And Hoary was months older than sid...
[02:20] <wgrant> *wasn't
[02:20] <persia> Changing at release time to the next dev release would be a bumpy ride for six months, but might be least painful.
[02:20] <ajmitch> right, it was during the autosync phase
[02:21] <wgrant> Changing from a dev non-release to an earlier release would be very, very difficult.
[02:22] <persia> 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] <ajmitch> almost?
[02:31] <persia> ScottK: Also, that's release to later release, which is easier than pre-release to older release
[02:31] <ScottK> It was going very nicely until I did a bad thing.
[02:31] <ScottK> Yes.
[02:32] <ajmitch> my sid->hoary install lasted well until dapper, when the hardware died & I did a fresh amd64 install
[02:32] <persia> ajmitch: You didn't want to try the i386 -> amd64 upgrade? ;)
[02:33] <ajmitch> couldn't be bothered :)
[02:34] <persia> ScottK: What was the "bad thing"?
[02:34] <ajmitch> 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] <wgrant> 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] <ajmitch> that's just working as intended
[02:35] <wgrant> But our upgrades don't work, remember?
[02:35] <ajmitch> I'm still in the process of upgrading that amd64 install to hardy
[02:35] <ajmitch> a few packages at a time
[02:39] <ScottK> 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] <persia> ScottK: Ah.  That can hurt.
[02:43] <ScottK> Yeah.
[03:48] <nhandler> Is the addition of the Vcs-Svn field in debian/control considered too significant to be dropped?
[03:53] <persia> nhandler: How do you mean?  For a merge?
[03:54] <nhandler> 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] <RAOF> Very much so.
[03:54] <persia> nhandler: It might be, depends on the Vcs-Svn entry.
[03:55] <persia> If Ubuntu added it for an Ubuntu-dedicated VCS, than it's essential.
[03:55]  * RAOF lets persia take this one :)
[03:55] <persia> If Ubuntu added it because Debian happens to keep something somewhere, maybe less so.
[03:55] <persia> 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] <persia> These cases need a bit more investigation, and the automated tools can't help very much.
[03:57] <nhandler> 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] <persia> nhandler: Hmm..  That's a somewhat odd case.
[03:58] <persia> Does that repo have the existing package?
[03:58] <persia> Generally, I think the Utnubu changes are worth keeping, but the team is less active these days :(
[03:59] <nhandler> 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] <persia> nhandler: How about svn co svn://svn.debian.org/utnubu/packages/gtimelog
[03:59] <nhandler> persia: Do you think this is because utnubu is no longer the maintainer?
[04:00] <persia> "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] <nhandler> persia: The svn co command downloaded an older version, 0.0+svn65. The version I am merging is 0.0+svn88-2
[04:01] <persia> nhandler: Then you want to drop it, as it is clearly inaccurate.
[04:02] <nhandler> persia: Ok, I'll drop it. Just out of curiosity, what does that field do?
[04:02] <persia> nhandler: It tells the package management tools to tell the user that the source is maintained in a VCS.
[04:02] <persia> This makes it easier for collaborative maintenance, as people can just update the VCS.
[04:03] <nhandler> persia: Ok, but it doesn't actually download anything from the VCS, right?
[04:05] <persia> nhandler: It can, it depends on which tools you use.  apt-get source doesn't.
[04:05] <persia> Good examples of how this works are for the Python Applications Packaging Team or the Games team.
[04:05] <persia> 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] <nhandler> 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] <persia> nhandler: Glad to explain.  Thanks for asking, and good luck with the merge.
[04:07] <nhandler> persia: Actually, now that I can drop the Vcs-Svn addition, it is a sync ;)
[04:09] <persia> nhandler: Even better :)
[04:31] <StevenK> TheMuso: So, what do I have to do to get an SRU approved? :-)
[04:31] <ajmitch> beg? beer?
[04:32] <TheMuso> StevenK: I assume you've followed https://wiki.ubuntu.com/StableReleaseUpdates
[04:32] <TheMuso> StevenK: If so, bug number please. :)
[04:32]  * StevenK peers at the wiki page
[04:33] <StevenK> TheMuso: Bug 195260
[04:36] <TheMuso> StevenK: looking.
[04:37] <StevenK> Heh. MailScanner in Intrepid is caught up by the Perl transition.
[04:38] <TheMuso> StevenK: ACK. Noted in the bug also.
[04:38] <StevenK> TheMuso: Hm. Do I still need two acks?
[04:38] <TheMuso> I would say get into intrepid first but since it will affected in the perl transition things should sort themselves out.
[04:39] <TheMuso> StevenK: No just one.
[04:39] <StevenK> TheMuso: Right, since the version of MailScanner in Intrepid is a sync, I seriously doubt it has the same problem.
[04:40] <TheMuso> StevenK: Indeed.
[07:14] <dholbach> good morning
[08:35] <wgrant> white: You're killing off 915resolution, I see.
[08:49] <directhex> 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] <wgrant> directhex: Um, you can't have needed it in the first place, then...
[08:52] <wgrant> 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] <directhex> hm, i'm confusing 915resolution with i855-crt
[08:53] <wgrant> Ah, that makes sense.
[08:53] <wgrant> But you're right, 915resolution is no longer required.
[08:55] <directhex> i had terrible trouble with the -intel driver, which forced purchase of a bunch of geforces
[08:55] <directhex> but ho hum
[08:57] <wgrant> When was this?
[08:57] <wgrant> I have found -intel to be the best driver I've worked with.
[09:00] <directhex> hm... i think i was using a hardy alpha, and a release version didn't help
[09:00] <directhex> it strongly objected to the widescreen 20" HP monitors i was using
[09:44] <ssam> 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:55] <directhex> oh, that's not just me then
[09:55] <directhex> i'd say it's worth an SRU, not that my word counts for anything
[10:10] <DktrKranz> 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] <ssam> can the debdiff by pulled out of the debian or intrepid update?
[10:11] <directhex> does the intrepid update change anything other than fixing that bug?
[10:12] <ssam> directhex, i dont think so https://launchpad.net/ubuntu/+source/gst-plugins-ugly0.10 its the 0.10.7.4-1 version
[10:13] <DktrKranz> ssam: since there is a new upstream version, you should simply apply patch from upstream and prepare a new revision in hardy.
[10:14] <DktrKranz> it is not probably worth backporting a whole release, unless it fixed only this bug
[10:14] <directhex> 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] <ssam> ok
[10:15] <ssam> 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:16] <DktrKranz> I see, is it the one provided by gnome 529359 ?
[10:17] <ssam> its from gnomes SVN server
[10:17] <directhex> looks like it to me, DktrKranz
[10:18] <ssam> i mean the freedesktop svn
[10:19] <DktrKranz> 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] <ssam> DktrKranz, are these https://wiki.ubuntu.com/MOTU/Contributing the right instructions?
[10:26] <effie_jayx> 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] <ssam> DktrKranz, is it ok to just apply the patch, or do i need to put it in debian/patches
[10:27] <DktrKranz> 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] <james_w> effie_jayx: hi, does the package use cdbs?
[10:29] <ssam> 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] <effie_jayx> james_w,  yes
[10:30] <Laney> Is there a problem creating intrepid chroots (pbuilder) atm?
[10:30] <james_w> effie_jayx: with cdbs targets should use '::', let me see if this is explained somewhere.
[10:31] <effie_jayx> james_w,  thanks
[10:31] <Laney> http://pastebin.ubuntu.com/16822/
[10:31] <james_w> effie_jayx: no, the docs don't explain this well. If you change "clean:" to "clean::" does it work?
[10:32] <effie_jayx> james_w,  worked
[10:33] <effie_jayx> james_w,  strange. as I did not touch that section of debian/rules
[10:33] <devfil> asac: ping
[10:33] <effie_jayx> james_w,  thanks for the tip :D
[10:34] <james_w> effie_jayx: are you doing a merge?
[10:34] <effie_jayx> james_w,  yes
[10:34] <james_w> effie_jayx: was it changed in Debian?
[10:35] <effie_jayx> james_w,  basically it was a package that was not in debian and the debian/rules is a lot different
[10:35] <asac> devfil: hey.
[10:35] <effie_jayx> james_w,  my guess is that mom messed up with the :'s from the package
[10:36] <devfil> hi asac, we didn't speak
[10:36] <james_w> 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] <asac> devfil: yeah sorry.
[10:36] <ssam> DktrKranz, do i need to have gpg keys set up to do this
[10:36] <effie_jayx> james_w, bakery2.4
[10:36] <devfil> asac: np
[10:36] <asac> devfil: do you have any preferences on the areas you would like to learn/contribute?
[10:36] <DktrKranz> ssam: it is not strictly required
[10:37] <ssam> so can i skip the debuild -S stage, or tell it not to look for a key
[10:38] <james_w> ssam: "debuild -S -uc -us" tells it not to sign
[10:38] <devfil> asac: no, I don't have preferences
[10:38] <DktrKranz> james_w: you're quick ;)
[10:39] <ssam> thanks
[10:40] <asac> devfil: did you use vcs systems in the past?
[10:41] <devfil> asac: I don't know what is a vcs system
[10:41] <asac> devfil: cvs, svn, git, bzr?
[10:41] <james_w> 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] <devfil> asac: then no
[10:42] <asac> devfil: ok. do you know what patches are?
[10:42] <effie_jayx> james_w,  yes I did, but I may have forgoten only clean then
[10:42] <devfil> asac: yes
[10:42] <effie_jayx> james_w,  I will double check.
[10:46] <asac> devfil: ok, then I guess you qualify to start doing merges
[10:47] <devfil> asac: I already merged different packages
[10:47] <asac> devfil: ah. ok, then what do you want to learn?
[10:48] <devfil> asac: SRU and how to fix bugs more difficult than <package> doesn't contain desktop file
[10:49] <effie_jayx> james_w,  another interesting issue is the naming conventions for libbakery-common
[10:50] <effie_jayx> james_w,  dholbach suggest we keep the name for it at least until next LTS
[10:50] <james_w> effie_jayx: ah, I'd listen to dholbach then :-)
[10:50] <dholbach> effie_jayx: I didn't suggest that - I just said we need to bear in mind that there's a naming change :)
[10:51] <effie_jayx> dholbach, ohhh
[10:51] <effie_jayx> my bad then
[10:51] <dholbach> effie_jayx: we'd need an additional conflicts/replaces then at least
[10:51] <james_w> effie_jayx: the generally preferred thing to do its to follow Debian, but make sure to transition existing users properly.
[10:51] <dholbach> (that's the only thing I discovered we need to make sure - but I didn't look at it too closely)
[10:51] <dholbach> the debian changes look very good so the closer we get, the better
[10:52] <ssam> DktrKranz, i am trying to use pbuilder to build the unmodified version but i get dependency errors http://pastebin.ubuntu.com/16828/
[10:52] <effie_jayx> That's waht I did
[10:52] <effie_jayx> well I am building taking all big changes from the debian packages
[10:53] <ssam> i have "deb-src http://gb.archive.ubuntu.com/ubuntu/ hardy restricted main multiverse universe" in my source.list
[10:53] <effie_jayx> mostly documentation stuff. placing the files where they should be in terms of hierarchy
[10:54] <effie_jayx> 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] <asac> devfil: ha ;)
[10:56] <devfil> asac: and more important is how to triage, I've read wiki pages but I don't know hot to start etc...
[10:56] <effie_jayx> 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] <effie_jayx> dholbach and james_w , thanks
[10:57] <devfil> s/hot/how
[10:57] <james_w> ssam: do you have universe enabled inside the chroot?
[10:57] <dholbach> effie_jayx: you ROCK
[10:57] <effie_jayx> dholbach,  and you DJ
[10:57] <effie_jayx> :D
[10:58] <dholbach> hahahaha
[10:58] <dholbach> effie_jayx: I take that as a compliment :)
[10:58] <dholbach> james_w DJs too and he was just awesome
[10:58] <asac> devfil: to start, pick out a few important packages with a decent bug load
[10:58] <asac> and monitor them.
[10:59]  * james_w hugs dholbach 
[10:59] <asac> devfil: the other way is to find bugs that are milestoned, targetted for hardy
[10:59] <DktrKranz> ssam: be sure to put COMPONENTS="main restricted universe multiverse" in your pbuilderrc
[10:59] <asac> or milestoned for intrepid
[11:00]  * dholbach hugs james_w back :)
[11:00] <devfil> asac: this is how to do a SRU?
[11:00] <DktrKranz> dholbach: mind spending some nights in northern italy as DJ? They pay well on Garda Lake :P
[11:00] <asac> devfil: depends on what oyu mean by SRU
[11:00] <asac> devfil: SRU basically just means that you want to bring a fix to a stable release
[11:01] <asac> devfil: that is not a security issue
[11:01] <dholbach> DktrKranz: let's see if we can combine that with some kind of Ubuntu meeting :-)
[11:01] <DktrKranz> heh
[11:01] <devfil> asac: ok
[11:01] <asac> 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] <asac> https://bugs.edge.launchpad.net/ubuntu/hardy
[11:04] <devfil> asac: ok
[11:05] <asac> 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] <devfil> ok
[11:06] <asac> 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] <asac> and thus might lead to approval for bugs that wouldnt have been approved without a patch
[11:08] <devfil> asac: uhm ok
[11:09] <Laney> Can someone help me with this error setting up an intrepid pbuilder? http://pastebin.ubuntu.com/16822/
[11:20] <devfil> asac: and how to triage?
[11:22] <white> wgrant: jip, i requested the removal. Do you still have a usecase for it or were you just noticing it?
[11:22] <asac> 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] <devfil> asac: for example this: https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/237302
[11:25] <asac> devfil: first step is figuring if its reproducible
[11:25] <asac> devfil: if you can, you should do a backtrace
[11:26] <devfil> asac: ehm...backtrace?
[11:26] <asac> devfil: take a look at the backtrace, look in code and see if the information in the backtrace makes sense.
[11:27] <asac> if so forward upstream and if you feel good enough to fix it, start to work on it
[11:27] <asac> devfil: https://wiki.ubuntu.com/DebuggingProgramCrash
[11:28] <asac> devfil: there are three ways mentioned to get an idea about the crash: Backtrace, valgrind, strace
[11:28] <asac> try to get used how they work, what the output means and so on
[11:28] <devfil> asac: if the backtrace makes no sense?
[11:30] <ssam> 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] <ssam> does it look ok
[11:31] <wgrant> white: Noticing, sorry.
[11:31] <wgrant> Somewhat glad to see that hack go, I guess.
[11:31] <wgrant> Though it was invaluable in its time.
[11:38] <white> jip, it had its moments :)
[11:44] <sistpoty|work> 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] <sistpoty|work> hi \sh
[11:48] <siretart> hey \sh!
[11:48]  * siretart highfives sistpoty! 
[11:49] <sistpoty|work> hi siretart
[11:49] <siretart> sistpoty|work: great job on the cirrus beast! :)
[11:49] <sistpoty|work> thanks
[11:57] <sistpoty|work> hm... looks like there are no daily images built atm, right?
[11:59] <siretart> sistpoty|work: AFAIUI cjwatson or evand maintain the daily builds. you might want to ask them?
[12:00] <siretart> sistpoty|work: but anyway, the package is not in -updates yet, is it?
[12:01] <sistpoty|work> siretart: no, but I promised bryce to test his new dexconf with kvm today
[12:01] <ssam> sistpoty|work, https://bugs.launchpad.net/ubuntu/+bug/236544 see colins comment
[12:01] <siretart> sistpoty|work: ah, I see
[12:01] <sistpoty|work> thanks ssam
[12:03] <sebner> directhex: finally you got mono updated. congratulations ;)
[12:05] <directhex> oh, did i? must've been slomo__, i was poking him earlier this morning
[12:16] <sebner> directhex: of course he uploaded it but you prepared the necessary diff ;) Now you are responsible for it (bugs ,..) =)
[12:18] <directhex> i will take on every responsibility required to pass the buck to meebey@debian.org
[12:18] <sebner> directhex: self fixing :P
[12:20] <directhex> 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] <directhex> i should go through old mono bugs & see if they still apply
[12:21] <sebner> directhex: if your aren't a MOTU you can't delegate ^^
[12:21] <norsetto> hi all
[12:22] <directhex> poot. and it's in main, too, so that wouldn't help
[12:22] <sebner> huhu norsetto
[12:22] <norsetto> huhu sebner
[12:23] <sebner> ^^
[12:35] <norsetto> sebner: weather looks horrible in hermagor: http://www.webcams.travel/map/#lat=46.626571&lng=13.371906&z=14&t=h
[12:36] <porthose> 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:46] <directhex> 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] <porthose> sure
[12:48] <porthose> k thx
[12:48] <\sh> porthose, welcome :)
[12:51] <siretart> 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] <directhex>   * Merge with Debian (LP: #225426), remaining Ubuntu changes:
[12:53] <siretart> directhex: in that case the bug should be closed when it hits the archive
[12:53] <siretart> automatcally by soyuz
[12:54] <directhex> Published in intrepid-release 2 hours ago
[12:58] <siretart> directhex: it seems the changes file hasn't been created on an ubuntu but on a debian system
[12:59] <siretart> directhex: at least the changesfile does not have a bug closing directive.
[12:59] <dhart> 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] <siretart> directhex: who did create that changes file?
[12:59] <directhex> siretart, which changes file? i just made a debdiff!
[13:00] <siretart> directhex: who did sponsor you?
[13:01] <directhex> siretart, probably slomo__, since i was poking him this morning
[13:02] <siretart> 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] <siretart> directhex: for this upload, the bug must be closed manually
[13:02] <directhex> gpg: Good signature from "Sebastian Dröge <slomo@circular-chaos.org>"
[13:03] <directhex> siretart, i'll close it then. "fix released"?
[13:03] <siretart> yes
[13:03] <siretart> yes
[13:10] <porthose> hehe killed my first bug, thx again \sh :)
[13:30] <amikrop> I got this, while `sudo apt-get purge packagename`-ing my package:
[13:30] <amikrop> Removing ueagle-setup ...
[13:30] <amikrop> update-rc.d: /etc/init.d/ueagle-startup exists during rc.d purge (use -f to force)
[13:30] <amikrop> dpkg: error processing ueagle-setup (--remove):
[13:30] <amikrop>  subprocess post-removal script returned error exit status 1
[13:31] <amikrop> Why? What did go wrong?
[13:32] <amikrop> Why does /etc/init.d/ueagle-startup exist? Why did it not get removed before postrm was executed?
[13:32] <persia> amikrop: You didn't use dh_installinit
[13:32] <amikrop> What is it?
[13:32] <persia> It's a special helper to install init scripts.
[13:32] <persia> man dh_installinit
[13:33] <amikrop> persia: By the way, thanks to your yesterday course on #ubuntu-classroom, I managed to create a Ubuntu-valid Debian package :)
[13:33] <persia> amikrop: Well, almost.  It doesn't purge cleanly yet :)
[13:34] <amikrop> persia: I am sure it will soon do ;-)
[13:36] <amikrop> persia: And how can I remove the "badly-purged" package now? :-/
[13:36] <persia> amikrop: BY hand
[13:36] <persia> amikrop: Just purge the package, and then delete the files it complains about, and then hunt down any leftovers.
[13:38] <amikrop> Aha.
[13:39] <DktrKranz> 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] <geser> Hi *
[13:39] <DktrKranz> patch-systems are explained here https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[13:40] <amikrop> Hello geser :-)
[13:40] <amikrop> persia: I handled my rules install section like that: http://paste.ubuntu.com/16863/
[13:42] <persia> amikrop: I think that's overkill, and possibly wrong (as it's not compressed), but then I'm a CDBS fan.
[13:43] <amikrop> persia: Compressed? What should I compress?
[13:44] <persia> dh_compress
[13:49] <amikrop> 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] <amikrop> Should I left postinst and postrm, as are?
[13:50] <amikrop> (`debian/postinst` and `debian/postrm`)
[13:52] <amikrop> I mean, I uncommented dh_installinit in `debian/rules`.
[13:52] <amikrop> (and gave it the -r argument, too)
[13:54] <persia> amikrop: I'd need to be looking at your package in considerably more detail to answer that.
[13:54] <persia> Your best bet is to try it, and see what works for you.
[13:54] <amikrop> It doesn't work.
[13:54] <persia> linitan -iIv can help, although carefully reading all the debhelper manpages will also be informative.
[13:59] <amikrop> persia: I want to have a simple posinst and a simple postrm. Is it necessary to use dh_installinit?
[14:01] <geser> amikrop: it's not required to use dh_*, but it makes it easier
[14:02] <amikrop> geser: So, I can have a postinst and a postrm without dh_installinit.
[14:02] <amikrop> Is that correct?
[14:03] <geser> yes
[14:03] <geser> dh_installinit is only a helper so every package does it the same way and doesn't repeat the common problems
[14:03] <persia> 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] <amikrop> OK. So, what do I do with 4 things: 1) postinst 2) postrm 3) rules 4) the startup script?
[14:05] <amikrop> Where do I place each, in order to have a correct init script that installs and gets removed correctly?
[14:06] <amikrop> 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] <amikrop> Please, correct me where I am wrong.
[14:08] <geser> amikrop: looks good
[14:10] <amikrop> 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] <amikrop> (I mean, the cp command in debian/rules.)
[14:11] <amikrop> Will dh_installinit copy my startup-script automatically and I should skip doing it manually?
[14:11] <geser> if I understand the man page for dh_installinit correctly it will install the init-script for you
[14:12] <amikrop> So, I should comment out that line in my rules file: "cp $(CURDIR)/start/* $(CURDIR)/debian/ueagle-setup/etc/init.d"?
[14:15] <geser> yes, you can comment it out
[14:16] <amikrop> OK. Again, before trying it out, should I also remove etc/init.d from my debian/dirs file?
[14:17] <amikrop> Or is it necessary, even if I use dh_installinit?
[14:17] <geser> iirc it should get created automagically so you don't need to list it in debian/dirs
[14:18] <geser> Hi sebner
[14:18] <amikrop> geser: Alright. Let me try all these out, and I will let you know the results :-)
[14:19] <sebner> hoi geser =)
[14:23] <amikrop> 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] <amikrop> geser: So, it seems it didn't work.
[14:25] <geser> how did you call the init script and how is your package named?
[14:26] <Iulian> Hey
[14:28] <amikrop> geser: ueagle-startup.init
[14:28] <amikrop> geser: My package is named ueagle-setup.
[14:29] <geser> try to use the same name for both, i.e rename your init script to ueagle-setup.init
[14:29] <amikrop> geser: OK
[14:33] <amikrop> geser: Worked. Thank you.
[14:33] <DktrKranz> \sh, did it happen to you to request some p-a-s adjustments?
[14:35] <\sh> DktrKranz, yes for wine on lpia
[14:37] <DktrKranz> \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] <DktrKranz> \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] <DktrKranz> ah, new thing learned :)
[14:40] <DktrKranz> \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] <DktrKranz> yessir :)
[14:42] <DktrKranz> ok, I'll drop a mail to them
[14:44] <\sh> DktrKranz,  hehe :)
[14:44] <amikrop> 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] <geser> amikrop: prerm is ok, as you want to stop what you started before removing it
[14:46] <amikrop> It seems dh_installinit did well to copy /etc/init.d/ueagle-startup but neglected to remove it, before postrm was ran.
[14:48] <geser> amikrop: why does it talk about /etc/init.d/ueagle-startup? didn't you renamed it to ueagle-setup?
[14:48] <amikrop> geser: No, I just used dh_installinit -r --name=ueagle-startup
[14:48] <geser> ah
[14:49] <amikrop> And renamed ueagle-setup.init to ueagle-setup.ueagle-startup.init as the man page said.
[14:49] <geser> hmm
[14:50] <owh> 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:51] <owh> kirkland: This is the issue we discussed last week about the set -e.
[14:51] <ssam> 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] <amikrop> geser: It seems I must somehow tell dh_installinit to remove /etc/init.d/ueagle-startup before postrm executes.
[14:52] <ssam> DktrKranz, oops, you already ansered that :-)
[14:54] <amikrop> persia: Does dh_installinit normally remove the init script it installed?
[14:55] <persia> amikrop: It should insert some logic in postrm.  You might need to add #DEBHELPER#
[14:56] <kirkland> owh: hey
[14:56] <owh> kirkland: Hiya, nearly off to bed. I just pinged you about the comments we made last week on the set -e.
[14:56] <kirkland> owh: right
[14:57] <owh> 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] <kirkland> owh: good idea
[14:57] <owh> kirkland: If we keep this up we might make the functions work yet :)
[14:58] <amikrop> persia: postrm is manually created by me. dh_installinit just generated a prerm. Where should I add #DEBHELPER#?
[14:58] <owh> kirkland: See you in a couple of hours for the u-s meeting.
[14:58] <kirkland> owh: k
[14:59] <persia> amikrop: At the bottom of your maintainer scripts.
[14:59] <amikrop> Both postinst and postrm?
[15:00] <kirkland> owh: I think you're looking for doko
[15:00] <amikrop> persia: The truth is that dh_installinit also generated ueagle-setup.postinst.debhelper, ueagle-setup.postrm.debhelper and ueagle-setup.prerm.debhelper.
[15:01] <doko> about what?
[15:01] <persia> amikrop: All your maintainer scripts
[15:01] <amikrop> persia: dh_installinit also generated ueagle-setup.postinst.debhelper, ueagle-setup.postrm.debhelper and ueagle-setup.prerm.debhelper.
[15:01] <kirkland> doko: bug #204594
[15:02] <kirkland> doko: owh left, but I've been helping him with this
[15:02] <kirkland> ubottu: thanks.  doko: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/204594
[15:07] <kirkland> doko: basically, we have another patch that needs the pidof() function to be "set -e safe"
[15:07] <kirkland> doko: owh is suggesting a change to make it so
[15:08] <kirkland> doko: if you agree with his change, I'll attach another debdiff to that bug, perhaps you can sponsor
[15:08] <DktrKranz> ssam: thank *you* for fixing that :) If you need assistance, it's probable I'll be around this eve.
[15:08] <doko> kirkland: fine with me.
[15:14] <amikrop> persia: How can I fix this?
[15:14] <amikrop> gpg: skipped "Aristotelis Mikropoulos <amikrop@gmail.com>": secret key not available
[15:14] <amikrop> gpg: [stdin]: clearsign failed: secret key not available
[15:15] <amikrop> persia: Beacause the package is ready for REVU, and I need a gpg key to log in to the REVU website.
[15:15] <norsetto> amikrop: is it? Hmmmm, I suppose its lintian clean?
[15:16] <persia> amikrop: gpg --gen-key.  Also, best to ask questions generally: the more I get pinged, the less likely I am to respond happily.
[15:16] <persia> I almost always respond happily to unaimed questions :)
[15:16] <persia> (when I am around and have time)
[15:16] <amikrop> OK, sorry :P
[15:16] <amikrop> But I already have a gpg key.
[15:17] <amikrop> And I formatted my pc. Can I recover my gpg key?
[15:17] <Hobbsee> ...no
[15:17] <mok0> amikrop: maybe the anti-terror police can help
[15:18] <persia> amikrop: You can retype it from the hardcopy of your secret key :)
[15:18] <amikrop> I don't remember it :P
[15:18] <amikrop> It looks like I am going to generate a new one, but I wil have to update it on Launchpad.
[15:19] <mok0> amikrop: don't ever loose your gpg key if you want to be taken seriously in this forum ;-)
[15:19] <Hobbsee> or give it out
[15:19] <persia> Or let it get in a position where someone else has access
[15:20]  * Hobbsee wonders what on earth she was going to do.
[15:20] <amikrop> OK. From now on, I will backup my ~/.gpg directory before I format.
[15:20] <amikrop> mok0: Got it :)
[15:21] <\sh> Hobbsee, when you are loosing your secret key?
[15:22] <Hobbsee> \sh: losing?  i didn't lose it.
[15:22] <Hobbsee> \sh: i had it on brandon's machine, though, as i didn't know about debsign -r
[15:23] <mok0> amikrop: amikrop, you really should read the gpg documentation. There is a whole chapter devoted to how you secure your private key
[15:24] <Hobbsee> \sh: entire effect was null, as brandon and i have the same upload powers, and i didn't have motu at the time, and he did.  but still.
[15:24] <amikrop> mok0: OK ;)
[15:24] <mok0> amikrop: http://www.gnupg.org/gph/en/manual.html#AEN513
[15:25] <amikrop> Real name: Aristotelis Mikropoulos <amikrop@gmail.com>
[15:25] <amikrop> Invalid character in name
[15:25] <amikrop> What is going on?
[15:25] <amikrop> Where is the invalid character?
[15:26] <mok0> amikrop: I don't think your real name includes an email address?
[15:26] <james_w> <
[15:26] <Hobbsee> yeesh.  security is very slow
[15:26] <mok0> amikrop: ... or maybe you mother and father were very foresighted
[15:30] <amikrop> How can I see my "key id"?
[15:30] <amikrop> (Launchpad requires so)
[15:31] <mok0> amikrop, gpg --list-keys
[15:31] <amikrop> Yes, but what of all these is called the id?
[15:31] <mok0> amikrop: the key id is an 8 digit hex number
[15:31] <amikrop> alright
[15:32] <mok0> amikrop: mine says "1024D/404825E7"
[15:32] <mok0> amikrop: yours will look something similar, it's the 8 digits after the /
[15:32] <amikrop> ok, ok
[15:32] <amikrop> Now, I need to set a keyserver. Any help?
[15:33] <schmiedc> launchpad itself has doku for import your key
[15:34] <amikrop> schmiedc: I know, I am following that.
[15:34] <schmiedc> ok
[15:34] <schmiedc> step 12 then
[15:37] <amikrop> schmiedc: Wait, I thought you meant the 3-steps guide in the user page. Where is the doku you are talking about?
[15:37] <schmiedc> https://help.launchpad.net/YourAccount/ImportingYourPGPKey?action=show&redirect=ImportingYourOpenPGPKey
[15:38] <amikrop> schmiedc: thanks
[15:38] <schmiedc> np
[15:38] <cprov-lunch> hi guys, can someone help this guy with his PPA package -> https://answers.edge.launchpad.net/soyuz/+question/35261 ?
[15:40] <bddebian> Heya gang
[15:40] <kirkland> doko: okay, patch attached to https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/204594 ... only question, though, is if lsb should be merged first?
[15:40] <persia> cprov-lunch: Without deep investigation, it's likely broken because of toolchain changes.  We've had issues with a number of backports for that reason.
[15:40] <sistpoty|work> hi bddebian
[15:40] <geser> Hi bddebian
[15:41] <bddebian> Hi sistpoty|work, geser
[15:41] <schmiedc> hi bddebian
[15:41] <bddebian> Hello schmiedc
[15:42] <doko> kirkland: well, send a patch to do the merge and the fix?
[15:42] <lukehasnoname> hello ubottu
[15:42] <lukehasnoname> :(
[15:42] <cprov-lunch> persia: yes, that's what I've imagined. Can you comment that in the question, please ? (it's good for you karma)
[15:42] <kirkland> doko: okey doke, i'll do the merge first
[15:43] <kirkland> doko: upload to chinstrap, and you can upload there, then apply the set-e patch?
[15:44] <persia> cprov: If someone else doesn't get to it before I have time to think about it in a little depth :)
[15:46] <cprov> persia: great, that will do for me, thanks.
[15:52] <sistpoty|work> cprov: maybe you have an answer for my question? https://answers.launchpad.net/soyuz/+question/34821
[15:56] <cprov> sistpoty|work: uhm, very strange, did you try talking to adam (infinity) he might know why sbuild is not behaving as expected.
[15:57] <sistpoty|work> cprov: no, not yet
[15:58] <cprov> sistpoty|work: I will point him to the question, no worries.
[15:58] <sistpoty|work> cprov: ok, thanks... you don't happen to know what build target sbuild actually invokes there?
[15:59] <sistpoty|work> (as it might be a bug in the package, though everything looks right on first glimpse)
[15:59] <cprov> sistpoty|work: not by heart.
[15:59] <sistpoty|work> kk
[15:59] <leleobhz> its safe usa libc6-xen with xen or its better move /lib/tls ?
[15:59] <leleobhz> *use
[16:02] <lukehasnoname> What does "triage" mean in server/bugspeak?
[16:02] <amikrop> Why I am getting this? $ dput revu package_version_source.changes
[16:02] <amikrop> Can't open /home/indy/Desktop/hacking/sandbox/ueagle-setup-1.0/package_version_source.changes
[16:03] <amikrop> Oh, OK. I am really sorry.
[16:03] <amikrop> Never mind.
[16:06] <amikrop> I uploaded it and press "Recover Password" (on REVU). But it says there isn't such account, yet. Do I need to wait?
[16:07] <mok0> amikrop: yes, it takes a while for revu to update it's keyring.
[16:07] <wgrant> amikrop: Give it about 2.5 minutes from now.
[16:07] <wgrant> Uploads are currently processed every 10 minutes.
[16:08] <mok0> wgrant: I think he's waiting for his gpg public key to be recognized
[16:08] <wgrant> mok0: No, accounts are created on upload processing.
[16:10] <kirkland> doko: doing the merge, there's one strange conflict between the Ubuntu and Debian versions
[16:10] <sistpoty|work> amikrop: I'm just doing a resync of the keyring. is uegle-setup from you?
[16:10] <kirkland> doko: ubuntu ->     if [ -n "$sig" -o "$sig" = 15 -o "$sig" = TERM ]; then
[16:10] <kirkland> doko: debian     if [ -z "$sig" -o "$sig" = 15 -o "$sig" = TERM ]; then
[16:10] <sistpoty|work> (+a somewhere)
[16:11] <amikrop> sistpoty|work: yes
[16:11] <kirkland> doko: -n and -z are opposites of one another, so I'd think that one of these is objectively correct, and the other incorrect
[16:12] <sistpoty|work> amikrop: did you intent to have it as a native package? (just saw that while checking the queue)
[16:12] <amikrop> sistpoty|work: What do you mean "native"?
[16:13] <sistpoty|work> amikrop: that it doesn't have an orig.tar.gz (usually, if you downloaded s.th. from somewhere and package it, you don't want a native package)
[16:13] <amikrop> Then I don't want a native package.
[16:14] <amikrop> My package includes some downloaded stuff.
[16:15] <sistpoty|work> amikrop: then I suggest to check how you named the tarball that you downloaded (should be <packaganame>_<upstreamversion>.orig.tar.gz)
[16:16] <amikrop> OK. And do what with the name?
[16:17] <sistpoty|work> amikrop: just name the tarball you downloaded like this. if dpkg-source finds such a tarball in the parent directory to the extracted package, it will create a non-native package, otherwise a native
[16:17] <amikrop> sistpoty|work: OK. Should I re-package and re-send, then?
[16:18] <sistpoty|work> amikrop: yes please... I'll remove that upload then, ok?
[16:18] <amikrop> sistpoty|work: OK
[16:18] <schmiedc> so for by non-native packages there is no upstream inlcuded?
[16:20] <amikrop> sistpoty|work: But the upstream is a very small part of my package. Should I still make that .orig.tar.gz?
[16:20] <sistpoty|work> schmiedc: a non-native package consists of 3 files, the .orig.tar.gz (which is what you downloaded from upstream), the .diff.gz (unified patch against that) and the .dsc (information like checksums etc.)
[16:20] <sistpoty|work> schmiedc: a native package is just a tarball and the .dsc
[16:20] <sistpoty|work> amikrop: yes
[16:20] <amikrop> OK, then.
[16:20] <sistpoty|work> amikrop: otherwise noone knows what you downloaded, and what you added as packaging
[16:20] <sistpoty|work> (and a few other things)
[16:21] <schmiedc> sistpoty|work: thx
[16:21] <amikrop> sistpoty|work: I got it.
[16:21] <norsetto> dholbach, geser, soren, persia, nixternal : can anyone in the power close the motu-sru affair? Everybody is happy to have 6 people in the team, bless them and lets move on
[16:22] <DktrKranz> yay!
[16:23] <sistpoty|work> thanks for following up norsetto! :)
[16:23] <norsetto> sistpoty|work: ;-)
[16:23] <DktrKranz> I prepared a small recap for new members, just to inform them what they agreed to do... you fools :P
[16:23]  * persia notes that the MC meeting is running over-time, and so it may be a bit before there is a serious response
[16:24] <\sh> did I miss something?
[16:24] <norsetto> persia: then overrule the MC meeting, we elect you dictator-for-life
[16:25] <persia> norsetto: I'd decline.  2 years will be a very long time, and that's not even as dictator :)
[16:26] <amikrop> sistpoty|work: The upstream version is completely different from my package's version, and nowhere in my package there is any upstream info. Is that right?
[16:26] <norsetto> persia: wise decision, all dicators-for-life have a very short life ...
[16:26] <\sh> but one
[16:26] <persia> \sh: The key difference is benevolence :)
[16:26] <sistpoty|work> amikrop: hm...?
[16:27] <amikrop> sistpoty|work: I mean, the version of the upstream program, is not the same version an the version of my package.
[16:28] <amikrop> Neither, I refer the updtream version anywhere in my package (e.g. in the control file).
[16:28] <amikrop> *upstream
[16:28] <amikrop> Is that normal?
[16:29] <mok0> amikrop: the upstream version is defined in debian/changelog
[16:29] <\sh> persia, oh this guy...no I didn't mean this guy ;)
[16:29] <sistpoty|work> amikrop: actually debian/changelog should contain the upstream version number as a part of the version (it's <upstreamversion-debianrevision>)
[16:29] <directhex> upstreamversion-debianrevisionubuntuubunturevision
[16:30] <amikrop> OK. I will update that info and then upload :-)
[16:31] <amikrop> You mean that everywhere, I use the upstream version?
[16:31] <sistpoty|work> amikrop: no, only in debian/changelog and in the name of your orig-tarball
[16:31] <amikrop> E.g. my .deb will be called package_upstreamversion_arch.deb?
[16:32] <sistpoty|work> amikrop: yes
[16:32] <sistpoty|work> (well, there's the debian-revision in there as well)
[16:33] <amikrop> Upstream version is 1.1. Package version is 1.0. In changelog it says 1.0-1. What should I fix/change?
[16:33] <sistpoty|work> amikrop: debian/changelog
[16:33] <sistpoty|work> (you're packaging version 1.1, don't you?)
[16:33] <amikrop> yes
[16:33] <sistpoty|work> so don't lie about it then :P
[16:34] <directhex> if you're  building a package for ubuntu (not debian) of version 1.1 of an app, it should be 1.1-0ubuntu1
[16:34] <directhex> incrementing the last number when the package (but not upstream) changes
[16:34] <amikrop> Oh, OK.
[16:34] <amikrop> And what about the number before "ubuntu"/
[16:34] <amikrop> ?
[16:34] <amikrop> (e.g. 0)
[16:34] <directhex> that's the debian package version. 0 means "not in debian yet"
[16:35] <amikrop> Or, in ubuntu in our case.
[16:35] <directhex> so if you were taking a debian package 1.1-7, the first ubuntu-modified version of that would be 1.1-7ubuntu1
[16:36] <amikrop> Excuse me for being repeated, but only 5% of the code in my package is from upstream. Should I still give that a version?
[16:36] <amikrop> I mean, the package is nearly native.
[16:37] <directhex> unless you're the upstream, i'd stick to the convention
[16:38] <mok0> amikrop: have you forked the software?
[16:39] <amikrop> mok0: No.
[16:39] <amikrop> directhex: OK.
[16:40] <amikrop> Here: http://paste.ubuntu.com/16908/ "Version:" refers to the upstream version?
[16:41] <mok0> amikrop: what file is that?
[16:41] <mok0> output of dh_make perhaps
[16:42] <amikrop> yes
[16:42] <mok0> amikrop: the "1.1" will be found in debian/changelog
[16:42] <amikrop> OK
[16:42] <mok0> amikrop: you need to put -0ubuntu1 after it
[16:42] <kirkland> doko: okay, I have a merged, built lsb package for Intrepid
[16:43] <amikrop> mok0: In changelog?
[16:43] <mok0> amikrop: yes
[16:43] <amikrop> So, the .orig.tar.gz which was generated by dh_make is a copy of my .tar.gz (5% upstream code, 95% mine code). Is that OK? Should I proceed?
[16:44] <mok0> amikrop: are your changes a whole bunch of patches?
[16:44] <mok0> amikrop: or 1 patch
[16:44] <mok0> ?
[16:45] <amikrop> They are not changes. They are code which import the upstream code.
[16:46] <mok0> amikrop: do you distribute the code from a homepage somewhere?
[16:46] <amikrop> mok0: Not yet.
[16:46] <mok0> amikrop: you need to do that
[16:46] <amikrop> Anyway, what should I replace #nnnn in changelog, with?
[16:46] <amikrop> mok0: OK, I will.
[16:47] <mok0> amikrop: the number of the needs-packaging bug you file in Launchpad
[16:47] <amikrop> There is no such a bug.
[16:47] <mok0> amikrop: right. You file one
[16:47] <amikrop> OK.
[16:48] <amikrop> Now?
[16:48] <mok0> amikrop: you have a LP account, yes?
[16:49] <amikrop> Yes. How do I file s need-packaging bug?
[16:49] <amikrop> *a
[16:49] <amikrop> *needs
[16:49] <mok0> amikrop: goto launchpad.net -> ubuntu
[16:49] <warp10> Heya all!
[16:49] <mok0> amikrop: press the "Bugs" tab
[16:50] <mok0> amikrop: press the brown button "Report a bug"
[16:50] <amikrop> mok0: OK ...
[16:50] <mok0> amikrop: see bug 200783 as a guide
[16:52] <mok0> amikrop: In summary, write "[needs-packaging] ueagle-setup"
[16:52] <amikrop> ok
[16:52] <amikrop> tags: needs-packaging
[16:52] <amikrop> ?
[16:53] <mok0> amikrop: you add that tag in the pink menu, top left
[16:53] <mok0> amikrop: give a little blurp about the program in the bug description
[16:54] <mok0> amikrop: set status to -> In progress, and assign yourself to the bug
[16:55] <amikrop> ok
[16:55] <mok0> amikrop: easy, huh?
[16:56] <amikrop> yep :P
[16:58] <mok0> amikrop: so, in changelog, put this: (LP: #237385)
[16:58] <persia> norsetto: https://lists.ubuntu.com/archives/ubuntu-motu/2008-June/003990.html
[16:59] <amikrop> mok0: Oops, I uploaded while having this: * Initial release (Closes: #237385)
[17:00] <amikrop> mok0: Should I re-upload?
[17:00] <mok0> amikrop: don't worry about it, you can fix it in the next upload
[17:00] <mok0> amikrop: the sponsors will likely have other comments
[17:01] <amikrop> OK :P
[17:01] <mok0> amikrop: now, be patient, inclusion of new packages is not yet high on the sponsors' priority list...
[17:01] <norsetto> DktrKranz: in layman term https://lists.ubuntu.com/archives/ubuntu-motu/2008-June/003990.html means start working and we bless you later
[17:01] <mok0> amikrop: atm, we focus on merging packages from Debian
[17:01] <amikrop> mok0: How do I re-package while informing for updating the version?
[17:01] <amikrop> mok0: I see.
[17:02] <amikrop> I mean, should I manually change the package version? Or, should the version be updated at all for trivial changes?
[17:02] <mok0> amikrop: you don't need to update the version every upload. Just leave it at -0ubuntu1
[17:03] <DktrKranz> norsetto: oooh... I can go on holiday now \o/
[17:03] <DktrKranz> :)
[17:03] <mok0> amikrop: revu tags each upload with date and time
[17:03] <sebner> hio siretart
[17:03] <sebner> hio sistpoty|work ^^
[17:03]  * sebner waves
[17:03] <mok0> amikrop: it doesn't care about version-release
[17:03] <sistpoty|work> hi sebner
[17:03] <mok0> sebner!!!
[17:03] <amikrop> mok0: You mean, I should change 1.1-1 to 1.1-0ubuntu1 ?
[17:04] <mok0> amikrop: yes
[17:04] <sebner> mok0: :) :) :)
[17:04] <amikrop> manually?
[17:04] <schmiedc> hi sebner
[17:04] <norsetto> DktrKranz: we will chase you whenever you go, to the alps or to the sea!
[17:04] <mok0> amikrop: eerrr? how else would you do it?
[17:04] <amikrop> Manually and only in the chanelog?
[17:04] <mok0> amikrop: yes
[17:04] <amikrop> I don't know, maybe by renaming the .tar.gz.
[17:04] <mok0> amikrop: that's the only place where the version and release is defined
[17:04] <amikrop> And re-running dh_make.
[17:05] <mok0> amikrop: no
[17:05] <amikrop> mok0: OK.
[17:05] <mok0> amikrop: from now on, you just edit the files. You can happily forget all about dh_make
[17:05] <mok0> (that piece of crap)
[17:05] <DktrKranz> norsetto: you won't find me, and if you do, I'll have heavy weapons to persuade you
[17:05] <mok0> ooops, forgot CoC
[17:06] <amikrop> mok0: Cool. When the sponsors tell me to make some changes, should I alter anything in the changelog?
[17:06] <DktrKranz> mok0: ask for a CoC exception, it's useful in these cases :)
[17:06] <mok0> amikrop: no
[17:06] <amikrop> (Like, the version, or some notes)
[17:06] <amikrop> OK
[17:07] <mok0> amikrop: there will be feedback on REVU
[17:07] <amikrop> OK.
[17:07] <amikrop> I will re-upload, for correction the version and the LP thing.
[17:07] <amikrop> * of the
[17:08] <mok0> DktrKranz: try: curse(); except CurseException: print "oops, sorry"
[17:09] <DktrKranz> heh
[17:09] <amikrop> mok0: Another thing (and sorry for the many questions): In debian/copyright, the "Copyright:" section needs mine copyright, or th upstream's?
[17:09] <amikrop> *the
[17:09] <mok0> amikrop: hang on
[17:11] <mok0> amikrop: all copyrights must be acknowledges, including your own. See here:
[17:11] <mok0> http://wiki.debian.org/Proposals/CopyrightFormat?highlight=(Copyright)
[17:26] <amikrop> mok0: I got some warnings this time. Are things alright? http://paste.ubuntu.com/16916/
[17:27] <mok0> !maintainer | amikrop
[17:28] <mok0> amikrop: line 21-22 you can ignore
[17:28] <amikrop> mok0: OK. What aboutthe uninitiazlied value?
[17:28] <amikrop> mok0: Should I make those files non-executable?
[17:29] <mok0> amikrop: I don't know where that comes from, probably a bug in dpkg-source. Just ignore it
[17:29] <amikrop> sistpoty|work: Please, if there are any ueagle-setup uploads up there, delete them. I will start real uploading from now on. Thank you.
[17:29] <amikrop> mok0: Should I make those files non-executable?
[17:30] <sistpoty|work> amikrop: any motu can delete these btw. ;)
[17:30] <mok0> amikrop: it doesn't matter, you can if you want to get rid of the warnings
[17:30] <amikrop> sistpoty|work: Oh, OK :-)
[17:31]  * sistpoty|work heads home now.
[17:31] <sistpoty|work> cya
[17:32] <amikrop> mok0: OK. So, I should use MOTU as Maintainter?
[17:33] <mok0> amikrop: the motu mailing list
[17:33] <mok0> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[17:33] <amikrop> kk
[17:42] <schmiedc> cya
[17:44] <amikrop> mok0: My package takes ages to install. Perhaps the fact that I made the maintainer scripts non-executable, is to blame?
[17:50] <mok0> amikrop: no that has nothing to do with it
[17:58] <mok0> \sh: I saw your terminator post & decided to try it out. How do you set the font?
[17:59] <amikrop> mok0: OK. How can I set my init script not to start after the installation?
[18:00] <amikrop> (I use dh_installinit)
[18:00] <mok0> amikrop: hmm. I don't know
[18:00] <amikrop> mok0: OK. Thanks for everything :-)
[18:01] <mok0> amikrop: np!
[18:01] <mok0> amikrop: man dh_installinit says to use --no-start
[18:03] <amikrop> mok0: kk ;)
[18:03] <pmartren> hi, I have got an issu while packaging something : I can't create a directory in /home/toto/
[18:03] <pmartren> I don't know what to write in debian/dirs
[18:06] <pmartren> I would like to create /home/($LOGIN)/.mypackage actually
[18:09] <persia> pmartren: You really don't.
[18:09] <persia> You want to have your package create user preferences if they don't already exist the first time it launches.
[18:10] <persia> If it doesn't do this natively (and can't easily be patched to so do), use a wrapper script to do it, and then launch the binary (with a quick launch if the preferences are already there)
[18:15] <amikrop> Where do I have to keep the .orig.tar.gz for my package not to be considered as native?
[18:16] <amikrop> Also, can someone sync, please?
[18:16] <amikrop> No, it's OK.
[18:16] <amikrop> But where do I have to keep the .orig.tar.gz? In which directory?
[18:19] <amikrop> mok0: Any ideas?
[18:19] <persia> amikrop: Don't poke people.  Also, above the package directory.
[18:20] <persia> Or if you are in the directory with debian/, you should have ../(package).orig.tar.gz
[18:22] <amikrop> persia: And then build source (sorry)?
[18:37] <amikrop> Why a native package was created? I do have a .orig.tar.gz http://paste.ubuntu.com/16926/
[18:38] <slytherin> amikrop: where is it located?
[18:39] <amikrop> slytherin: In the parent directory.
[18:39] <slytherin> amikrop: what is the name of .orig.tar.gz file?
[18:39] <amikrop> There is the directory ueagle-setup. Inside, there are ueagle-setup-1.1 and ueagle-setup-1.1.orig.tar.gz.
[18:40] <amikrop> Inside ueagle-setup-1.1 there is debian/ and other stuff.
[18:40] <slytherin> amikrop: the file name should be package_version.orig.tar.gz, note underscore _
[18:40] <amikrop> I execute dpkg-buildpackage inside ueagle-setup-1.1.
[18:40] <amikrop> Ooh. OK. Thank you.
[18:42] <ssam> DktrKranz, i think i have made all the needed changes to my debdiff at https://bugs.launchpad.net/ubuntu/+source/totem/+bug/217301
[18:42] <Jazzva> norsetto: I uploaded the fixed diff.gz for gecko-mediaplayer...
[18:43] <norsetto> Jazzva: thanks!
[18:43] <Jazzva> No problem :)...
[18:44] <DktrKranz> ssam, so it seems, I'll review a bit, test it and, if good, sponsor to hardy-proposed. thanks :)
[18:44] <ssam> thanks :-)
[18:45] <DktrKranz> ssam, anyway... pretty difficult task for a "noob", good job ;)
[18:46] <amikrop> When I build the binary package, I get a warning about the user-defined field "Original Maintainer".
[18:46] <amikrop> Is there a problem somewhere?
[18:48] <slytherin> amikrop: nope, looks like lintian doesn't know about original-maintainer which is specific to Ubuntu.
[18:50] <amikrop> slytherin: alright
[18:57] <norsetto> Jazzva: uploaded
[18:57] <Jazzva> norsetto: Thanks :)
[18:57] <norsetto> Jazzva: np, you may want to keep your eyes open for the next update, kevin usually does it every month
[18:58] <Jazzva> norsetto: Ok. Thanks for the tip :)
[19:16] <mohbana> hi
[19:17] <mohbana> how long does getting a package accepted take?
[19:24] <persia> mohbana: Between a day and a year, depending on the package, the packaging, the interest of the packager and reviewers, and the attention of an archive admin.
[19:24]  * persia hasn't seen longer than a year with a single packager, but may be mistaken
[19:52] <DktrKranz> ssam, reviewed, ACKed and sponsored, thanks :)
[20:07] <ssam> DktrKranz, many thanks :-)
[20:07] <DktrKranz> you're welcome
[20:08] <Kopfgeldjaeger> could somebody maybe have a look at my 20-line-debdiff in bug #147058? it's just correcting the maintainer field and a .desktop file
[20:09] <persia> Kopfgeldjaeger: lynx is in main, so it may take a bit to get reviewed.
[20:10] <Kopfgeldjaeger> persia: that's ok, as we have enough time till intrepid. but i just don't want it to be lost.
[20:30] <Kopfgeldjaeger> persia: so i can't do anything? i mean, i should just wait.
[20:31] <persia> Kopfgeldjaeger: Yes, you should just wait.  You might track down why lynx is in main: it's not the best curses browser, so it's likely pulled by a dependency.  If you can pull it to universe, it gets easier to update.
[20:31] <Kopfgeldjaeger> OK
[20:50] <Q-FUNK> hm. is something wrong with the PPA builders?  I've had a small package marked as "building" for the last hour.
[20:56] <geser> Q-FUNK: your xserver-xorg-video-nsc 1:2.8.3-2ubuntu2 upload? it's only queue
[20:56] <stgraber> Q-FUNK: 22 packages in the amd64 queue, 23 in the i386 one
[20:57] <stgraber> Q-FUNK: some kernels are building, so you'll have to wait :)
[20:57] <geser> and right now a wine build started
[20:57] <Q-FUNK> kernels, in PPA?
[20:57] <geser> why not
[21:01] <aDmos> hi to all. i'm new here but I want to get involved too.
[21:04] <Q-FUNK> ompaul: hiya there :)
[21:05] <ompaul> Q-FUNK, hit here
[21:05] <ompaul> hi there even
[21:05] <Q-FUNK> heh
[21:05] <Q-FUNK> ompaul: how was the return trip from UDS?
[21:05] <ompaul> Q-FUNK, uneventful only 1hour 20 longer in the airport on the departing side more than I had to be
[21:06] <Q-FUNK> oh?
[21:06] <ompaul> typical delay
[21:09] <Q-FUNK> ah yes
[21:43] <LaserJock> DktrKranz, jdong: around?
[21:43] <DktrKranz> LaserJock, yep
[21:44] <LaserJock> DktrKranz: how does http://laserjock.us/files/ubuntu/sru_todo.html look to you?
[21:44] <DktrKranz> LaserJock, nice :)
[21:45] <LaserJock> DktrKranz: does it seem helpful? anything that you'd want to have when doing SRUs?
[21:46] <DktrKranz> LaserJock, since we have > 80 bugs in our page, having a tool that sort them and attracts our attention is simply great.
[21:47] <geser> LaserJock: how comes that apache2-mpm-itk is listed below "Needing Verification" and "Verification Done"?
[21:48] <LaserJock> one sec
[21:49] <LaserJock> geser: ah, I know why, it's a bug ;-)
[21:50] <geser> LaserJock: what about some sorting? perhaps sort after source package name
[21:52] <LaserJock> geser: it's possible
[21:54] <geser> LaserJock: besides this the page looks really good
[21:55] <ScottK> superm1: Do you plan on continuing to use guidance-backends for Intrepid?  If so, can I talk you out of it?
[21:55] <mario_limonciell> yes please talk me out of it
[21:56] <ScottK> mario_limonciell: Don't do it.
[21:56] <mario_limonciell> eg another solution would be nice :P
[21:56] <DktrKranz> linux source pakcage? on motu-sru list? mmmh...
[21:56] <ScottK> mario_limonciell: What do you use it for?
[21:56] <DktrKranz> ah... subscribed erroneously :)
[21:56] <mario_limonciell> ScottK, turning on an extra X module for VNC
[21:57] <laga> mario_limonciell: i thought that was broken?
[21:57] <ScottK> mario_limonciell: So you're modifying the xorg.conf with it?
[21:57] <mario_limonciell> ScottK, yex
[21:57] <mario_limonciell> yes
[21:57] <mario_limonciell> laga, yeah well i'm under the assumption that part is fixed (the module causing segfaults)
[21:57] <mario_limonciell> s/is/gets/
[21:58] <sebner> ScottK: We haven't set a jackpot for our courier bet or?
[21:58] <ScottK> mario_limonciell: It looks pretty trivial to script with xrandr (reading man xrandr).  I suggest that.
[21:58] <mario_limonciell> honestly starting using it because pitti was using it for jockey at that time.  what's the solution he is ending up with?
[21:59] <ScottK> mario_limonciell: Dunno.  I'm hoping to talk him out of it too, but he didn't answer so fast.
[21:59] <mario_limonciell> ScottK, well consider me already talked out of it, but if it stays i'll keep using it
[22:00] <tseliot> ﻿ScottK: xrandr is ok but sometimes (especially with proprietary drivers) editing xorg.conf is still necessary :-(
[22:00] <ScottK> I can't remove it if it has rdepends ...
[22:01] <LaserJock> DktrKranz: that's part of why I did the page, so we can catch mistaken subscriptions or people not setting the status correctly
[22:01] <ScottK> tseliot: How does one know when xorg.conf editing is needed?
[22:01] <mario_limonciell> ScottK, well i mean if pitti comes up with another solution for jockey, i'll just switch to his solution, so i'll remove the rdepend in that case
[22:01] <DktrKranz> so, we need to set status carefully. if I understand well, it works on bug statuses
[22:02] <DktrKranz> (and tagging at a later stage)
[22:02] <ScottK> mario_limonciell: OK.  Sounds fair.
[22:02] <mario_limonciell> well wait i should have bargained here.  i'll do everything i said i'd do if you look over a backport ;)
[22:03] <LaserJock> DktrKranz: exactly
[22:03] <tseliot> ﻿ScottK: it depends on what you're trying to do. You're talking about developers using guidance's xorgconfig.py to set up the xorg.conf, right?
[22:03] <ScottK> tseliot: Yes.
[22:03] <LaserJock> DktrKranz: it's both easy to do and it helps enforce the policy so people are consistent
[22:03] <DktrKranz> LaserJock, we missed that. many thanks!
[22:03] <ScottK> tseliot: My goal is to remove all of kde-guidance for Intrepid if possible.
[22:04] <sebner> ScottK: ok I also accept hugs :P
[22:04] <tseliot> ﻿ScottK: I'm working on a new parser which should be able to replace guidance
[22:04] <ScottK> sebner: You're on the list.  I've had about 0 Ubuntu time since I got back from UDS.
[22:04] <ScottK> tseliot: Excellent.
[22:04] <ajmitch> hi
[22:05] <sebner> ScottK: no no, We had a bet who is faster. the debian maintainer or you and you loose so I won ;)
[22:05] <ScottK> tseliot: Will it be ready so that others can try it soon (and it's a good alternative to Guidance)?
[22:05] <ScottK> sebner: OK.  Did he do another upload?
[22:05] <sebner> ScottK: exactly. currently in incoming but my debdiff also works with it since only 2-3 files were updated with copyright things or something like that
[22:05] <tseliot> ScottK: sure, since I will need it for this spec: https://blueprints.launchpad.net/ubuntu/+spec/xorg-options-editor
[22:06] <ScottK> tseliot: Great.  I'd encourage you to work with mario_limonciell and pitti to make sure it meets their needs too.
[22:06] <ScottK> ajmitch: Hello.
[22:07] <tseliot> ﻿ScottK: and if you have a look at the wiki you will also find a link to my bazaar branch with the code of its first experimental release. Of course bryce, pitti and mvo will review the code since I want to be sure that the code is good enough.
[22:07] <mario_limonciell> ScottK, the bug i was hoping  to bargain would be bug 237085 if you could
[22:08]  * ScottK looks
[22:15] <DktrKranz> any sponsors for main around?
[22:22] <\sh> DktrKranz: -> -devel?
[22:24] <DktrKranz> \sh, I didn't see any interaction, but I'll try there :)
[22:45] <sebner> gn8 folks
[22:46] <siretart> hey folks
[22:47] <siretart> ScottK: did I miss something important in the serverteam meeting so far?
[22:47] <ScottK> siretart: Just that tomorrow is the deadline for spec drafting.
[22:47] <ScottK> Most of it was whether or not to update openldap in Hardy.
[22:47] <siretart> ScottK: interesting. seems they don't want contributors to work on specs?
[22:49] <siretart> or maybe I just missed the announcment somehow
[22:49] <ScottK> siretart: I think it was just sort of assumed we would.
[22:58] <andrew_sayers> Are there any good ways of drumming up more interest in this remote help assistant idea?
[22:59] <andrew_sayers> I really need people to test it out, but I don't know how to do that without seeming like I'm spamming places.