[00:17] <ari-tczew> how can I restore ssh private key?
[00:18] <ebroder> ...restore? as in you lost it?
[00:20] <psusi> define restore... restore from backup?
[00:37] <ari-tczew> ebroder, psusi: after change gnome -> kde, any software couldn't find my ssh key
[00:37] <ari-tczew> e.g. filezilla
[00:37] <ari-tczew> now bzr always asks me for password :/
[00:37] <ebroder> ari-tczew: your private key is in ~/.ssh/id_rsa. you just need to get the password into kwallet, presumbly
[00:39] <psusi> I always get prompted for my key pass... I don't use ssh-agent or anything
[00:44] <ari-tczew> ebroder: it seems to normal software to store of password, not for handle passwords for bzr, or am I wrong?
[00:45] <ebroder> ari-tczew: it's not a bzr password. it's an ssh key password that bzr uses. and it does store those
[00:45] <ari-tczew> ebroder: and kwalletmanager will remember my password for ssh?
[00:45] <ebroder> i don't know that for sure, but i believe so. certainly gnome-keyring can
[00:47] <ebroder> err, note that it's not storing an ssh password, it's storing an ssh *key* password
[00:58] <ari-tczew> ebroder: I don't see a way to set ssh pass in kwalletmanager :/
[00:59] <ebroder> ari-tczew: sorry, then. i can't really guess any more about how kde works. maybe ask in #kubuntu or something?
[04:24] <pting> is there a way to use debuild to build multiple architectures in one go? passing in -a multiple times doens't seem to have the desired effect
[04:25] <pting> i'm having trouble adding the generated deb packages with reprepro as the sha values are different.. specifically create packages for nginx
[05:59] <lajjr> james_w, are you online??
[12:13] <paissad> is it possible to know the version of a previous package before upgrading ? .. i need it in my postinst script
[12:14] <Laney> $2 afaik
[12:14] <paissad> ok
[12:14] <Laney> http://wiki.debian.org/MaintainerScripts
[12:19] <paissad> Laney, isn't $2 the new version to install ?
[12:24] <Laney> possibly
[12:24] <Laney> check those diagrams
[12:42] <paissad> hmm, dh_link does not support symlinks of directories ?
[12:42] <paissad> http://dpaste.com/300237/
[12:43] <paissad> man dh_link does not specify a specific option or rules i should use to avoid such a problem
[13:14] <ari-tczew> is it OK to add new patch system to package to use new patch?
[13:14] <ari-tczew> IIRC we should patch files directly if there is no patch system
[13:15] <kklimonda> ari-tczew: this rule applies only to SRU afair in which case you are to prepare the minimal possible diff.
[13:15] <ari-tczew> kklimonda: is it clear on any wiki?
[13:16] <kklimonda> ari-tczew: I don't know but adding a patch system is not more intrusive than making an update. The risk of diverging from debian package are similar.
[13:16] <kklimonda> is similar*
[13:16] <ari-tczew> I'm pretty sure that we shouldn't add patch system. It's a place for Debian maintainer. I'm just making sure, so waiting for an answer from several devs.
[13:18] <geser> it's prefered to not add a patch system if not already in use
[13:18] <geser> especially when the package is already patched (directly) which causes only a mix
[13:21] <ari-tczew> geser: I'm reviewing several barry's patches and he is adding patch system for one small patch. Packages are clean from Debian.
[13:21] <ari-tczew> clean = unchanged
[13:26] <kklimonda> imo the cost of additional delta is a low price to pay for advantages of not applying patches directly -- more verbose patch description (with tags like Forwarded, and Bug-*) plus easier maintainance (but that may be just my preference).
[13:33] <ari-tczew> barry don't want change his branches to patch files directly. if I won't sponsor his changes, someone else from Canonical will do it tomorrow.
[13:34] <ari-tczew> it means that Canonical like don't respect rules
[13:35] <kklimonda> I don't think this particular rule has been written in stone. I haven't seen it anywhere (other than mentioning that you shouldn't add patch system if the package is already patching files directly)
[13:36] <geser> I don't remember seeing it written down somewhere either
[13:37] <geser> it also depends on the size of the patches
[13:37] <geser> for a simple one-line change introducing a patch system is IMHO overkill as the addition of the patch system is bigger than the change itself
[13:38] <kklimonda> there is https://wiki.ubuntu.com/PackagingGuide/PatchSystems#Patching%20other%20people%27s%20packages but it's ambiguos imo.
[13:38] <geser> but if you e.g. need to autoreconf then adding a patch system is a good idea
[13:39] <ari-tczew> geser: autoreconf runs via debian/rules
[13:39] <ari-tczew> so there is no place for 99_* patch.
[13:44] <kklimonda> ari-tczew: anyway, as you have said, the merge is going to accepted anyway so, if it's the only reservation you have about it, I see no reason to hold it. imo it's not big enough issue (actually, imo it's not an issue at all) to discuss at this time -- you may consider starting a discussion to get the policy straight in this regard.
[13:44] <kklimonda> starting a discussion on u-d*
[13:57] <tumbleweed> lfaraone: great! First applicant means you'll have the energy to drive my NM application thorugh in record time, right? :)
[14:01] <ari-tczew> tumbleweed: maybe you could give a feedback: what do you think about adding patch systems?
[14:01] <tumbleweed> ari-tczew: I'd say it depends on the complexity of the patch. I wouldn't add one for a simple patch
[14:02] <ari-tczew> tumbleweed: case: https://code.launchpad.net/~barry/ubuntu/natty/libfso-glib/618809-ftbfs/+merge/45579
[14:05] <tumbleweed> ari-tczew: I accepted a previous similar fix by barry that was done like that. It's a very trivial patch, but adding simple-patchsys is about as invasive as putting the patch in debian/applied-patches.
[14:05] <tumbleweed> his changelog entries could be a little more complete
[14:06] <ari-tczew> tumbleweed: as you can read comments, I pinged him to improve d/changelog, he added info about d/rules.
[14:07] <ari-tczew> I think that he should add also information about libtool
[14:07] <ari-tczew> tumbleweed: so you agree with adding patch system?
[14:08] <lfaraone> tumbleweed: of course. can you please re-send that mail GPG-signed? (all the mail during the NM process should be signed, see my welcome mail)
[14:08] <tumbleweed> re libtool: yeah, probably, it'll help future mergers. re patch sys: I don't mind it.
[14:09] <tumbleweed> lfaraone: it wasn't signed? /me slaps mutt
[14:09] <tumbleweed> lfaraone: the version in my Sent box is signed
[14:09] <lfaraone> tumbleweed: wait, nevermind, my mail client was munging the siggy.
[14:10] <lfaraone> aha, I reloaded the message and now it works.
[14:14] <nigelb> 42
[14:14] <ari-tczew> 43
[14:14] <nigelb> hrm, there was supposed to be /ws before that, sorry.
[14:14] <ari-tczew> :P
[14:39] <micahg> kklimonda: that wiki is pretty clear, don't change the patch system
[14:40] <ari-tczew> micahg: not change, add
[14:40] <micahg> ari-tczew: it's in the first line (or lack thereof)
[14:41] <kklimonda> micahg: I disagree - I read it as "don't change the patch system if there is one in place, or if there isn't one in place (i.e. pathes are applied directly)"
[14:41] <micahg> kklimonda: huh? what's the difference between that and what I said?
[14:42] <kklimonda> micahg: in the mentioned merge there is no patch system, and there are no patches applied to the source.
[14:43] <ari-tczew> yes, barry want to add patch system and small patch on unmodified packages
[14:51] <ari-tczew> micahg: what about uploads where patch system has been added?
[15:00] <lfaraone> tumbleweed: P&P 1 mailed, your move. :P
[15:04] <DktrKranz> new chess game? :)
[15:04] <micahg> ari-tczew: leave it I guess, but it should be dropped at the next merge unless there's a good reason like geser suggested
[15:05] <micahg> ari-tczew: don't sponsor something you're not comfortable with, if someone else wants to do something that goes against policy, that's their problem, not yours
[15:09] <micahg> ari-tczew: reference the wiki WRT the patch system situation
[15:26] <micahg> hopefully that patch system issue will go away soon with source format 3 after squeeze releases
[15:29] <tumbleweed> well, source format 3 isn't mandatory
[15:29] <ari-tczew> micahg: not all packages will switch to 3.0 source format
[15:29] <tumbleweed> hopefully most will switch
[15:30] <micahg> most will, the only thing blocking that at the moment is the squeeze freeze, about 1/3 of Debian has converted
[15:30] <tumbleweed> 3.0 native packages will still have the same problems, though
[15:30] <ari-tczew> tumbleweed: which problems>
[15:30] <tumbleweed> ari-tczew: no built in patch system
[15:32] <ari-tczew> micahg: do you will file a report about breaking policy by tumbleweed?
[15:32] <tumbleweed> ari-tczew: eh?
[15:34] <ari-tczew> tumbleweed: I didn't say that you're breaking a policy - adding patch system.
[17:41] <cybertron> hello again, i try to build a package and I got everytime the same error
[17:41] <cybertron> dh_usrlocal debian/foobar/test.jpg is not a dicrectory
[17:43] <kklimonda> contrary to popular belief, when computers are concerned, repeating steps do not yield different results every time you try ;)
[17:43] <cybertron> it only works if i dont use my files ;D
[17:51] <hakermania> Any reviewer who uses GNOME please have a look at: http://revu.ubuntuwire.com/p/wallch    Thank you
[17:58] <ari-tczew> RainCT: are you able to upload gbrainy 1.61 to Debian? unstable/experimental?
[17:58] <RainCT> ari-tczew: Yes
[17:58] <ari-tczew> RainCT: great thanks!
[17:59] <RainCT> ari-tczew: I uploaded 1.60 yesterday. Where did you get a 1.61?
[17:59] <ari-tczew> RainCT: ah this it only NEWS file, sorry for my fire. http://git.gnome.org/browse/gbrainy/commit/?id=d232e6056bec15105162dff2924494fc61ecc87f
[18:08] <chrisccoulson> is anybody interested in taking some items from https://wiki.ubuntu.com/DesktopTeam/Specs/Natty/Firefox4/XULRunner20Transition ?
[18:08] <chrisccoulson> it's the cause of a few build failures on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[18:12] <ari-tczew> chrisccoulson: would be nice if you give a tutorial how to do transition
[18:12] <chrisccoulson> ari-tczew, that's pretty difficult due to the amount of changes. the best way is to look at some of the packages that i've already ported
[18:13] <chrisccoulson> however, there is a lot of mozilla documentation that helps already
[18:13] <chrisccoulson> eg, https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0
[18:14] <ari-tczew> I'd like to help with that. However, I have no free time. :(
[21:06] <dapal> evaluate: ping? :)
[21:06] <dapal> evaluate: since we haven't uploaded cmsmadesimple yet, why -2 instead of re-doing -1? ;)
[21:08] <evaluate> dapal, hello. Well, I don't know actually, I thought it might be good to see that there is a new version. If you want I can redo a -1 though...
[21:08] <evaluate> dapal, I'm used to this since working with mentors.d.o, caus it wouldn't let me upload the same version again...
[21:09] <dapal> evaluate: sure it does -- it'll just complain about an "existing orig.tar.gz", but it's just a warning ;)
[21:09] <evaluate> ok. So should I repackage it again as -1?
[21:10] <dapal> no need for now. If the package is ok, I could just "mangle" it to only show -1
[21:10] <dapal> I'll send the diff of my changes, so you can include them in your $vcs ;)
[21:10] <evaluate> dapal, cool.
[21:11] <evaluate> btw, I have also set up some stuff in the postinst file, to change the user/group and permissions of some files that need to be writable by the scripts
[21:11] <evaluate> also, just FTR, I have installed it and made a couple of changes, and it worked fine for me.
[21:12] <dapal> ok, what changes were those?
[21:12] <evaluate> logged into admin, changed some contents, text, basic stuff like that
[21:14] <evaluate> and I don't mean installed as in apt-get install, but I created a symlink from /var/www/cmsms to /usr/share/cmsmadesimple and then went to localhost/cmsms and installed the script itself...
[21:15] <evaluate> the only stuff I'm not really sure about is that postinst file and the patch (not sure if that is the preffered way, as it's a bit ugly...)
[21:15] <dapal> ok, so, a couple of comments
[21:16] <dapal> it's ok if you provide a symlink like the one you did, in the package (debian/links or debian/cmsmadesimple.links)
[21:17] <dapal> the patch seems OK-ish
[21:17] <lfaraone> tumbleweed: P&P II in your inbox.
[21:17] <dapal> i.e. maybe there's a better way to do it
[21:18] <dapal> evaluate: I'm dubious about the postinst. You could just add /etc/cmsmadesimple to debian/dirs, and touch the file in debian/rules
[21:18] <evaluate> thing is, the only two ways I can think of to make Smarty find that file is either this way, changing it to an absolute path, or including the path into the php PATH, and I think this is much prettier...
[21:19] <dapal> evaluate: the same holds for the rest of postinst. Please do all that inside debian/rules, overriding the install target (doing everything _after_ files have been installed in debian/tmp/...)
[21:19] <evaluate> hmm. I'd still have to do the chmod and chown stuff in the postinst though, wouldn't I?
[21:19] <dapal> evaluate: nope, you can in rules
[21:20] <dapal> evaluate: www-data is a system user, and its uid is well defined, so there's no chance your uid could be different from mine ;)
[21:20] <evaluate> dapal, yeah, that makes sense.
[21:21] <dapal> evaluate: and, the apache.conf.. I thought it was an actual snippet, not a tutorial :) -- it would be better if you called it /usr/share/doc/cmsmadesimple/README.apache, or kinda
[21:22] <dapal> (at least, I've seen those kind of files more or less named like that)
[21:22] <evaluate> Although I'm not sure about that symlink (if you referred to the /var/www/cmsms) one. I don't think anyone would bother installing this on a machine that's not a server that can be publicly accessed. And when they do that, they'd have to configure apache.conf anyway, so I'm not sure the symlink would be of any benefit...
[21:22] <evaluate> dapal, well, that's what I seen the wordpress guys do, so I thought it was ok to name it like that. I'll rename it though if you want.
[21:23] <tumbleweed> lfaraone: I see :)
[21:23] <dapal> re the symlink: sure, it's just a "bonus", you're choice really :) -- re the filename, it's clearer, seeing a file named "apache.conf" I'd be tempted to cp it ;)
[21:23] <tumbleweed> lfaraone: there goes that movie I intended watching tonight...
[21:24] <lfaraone> tumbleweed: relax, it'll be there in the morning.
[21:24] <evaluate> dapal, yup, makes sense. Ok then, so to sum it up: move postinst stuff to dirs and rules, rename apache.conf, rename it to -1. Anything else? :-)
[21:24] <tumbleweed> lfaraone: :)
[21:24] <dapal> evaluate: let me check :)
[21:25] <evaluate> sure :-)
[21:26] <dapal> evaluate: (also remove postrm, obviously)
[21:26] <dapal> evaluate: mmhh. The apache2 | httpd dependency.
[21:27] <dapal> evaluate: ok, nothing, it just needs httpd, not httpd-cgi :)
[21:27] <evaluate> well, the thing is that the user might also create other files in that folder (like .htaccess or stuff like that) and then when he does "apt-get purge" that folder wouldn't get removed. I've created the postrm file to assure that the folders get deleted when the user does purge the package...
[21:28] <dapal> evaluate: uhm, ok
[21:28] <dapal> evaluate: for the patch, there's DEP-3 ;)
[21:29] <evaluate> I'm not sure what you mean
[21:29] <dapal> evaluate: ah, all those things you're removing in debian/rules -- you can just list them in debian/clean (it doesn't work for removing directories though)
[21:29] <dapal> evaluate: the patch description, http://dep.debian.net/deps/dep3/
[21:30] <evaluate> ok, will change the patch
[21:31] <dapal> evaluate: then it's just fine.
[21:32] <evaluate> re moving the stuff from rules to clean, I see that clean runs before dh_install runs. I need to run dh_install so that it puts my files in the respective folders, so that I have what to remove
[21:33] <dapal> evaluate: that's a non-issue ;) -- the files that aren't in any package could just be removed before installing
[21:33] <dapal> however, that's ok, no problem. Please go :)
[21:35] <evaluate> ok, let's see :p
[21:40] <evaluate> dapal, btw, do I have to build-depend on quilt if I have patches?
[21:41] <dapal> evaluate: nope, source format 3.0 (quilt) will take care of that
[21:41] <evaluate> ok, cool :-)
[21:46] <evaluate> The thing that I liked about the postinst file though, was that it wouldn't bug the user if he wants to overwrite his config.php file with my empty one (because I would only "touch" it), whereas if I do this in the rules file, there would be this issue, wouldn't it?
[21:47] <evaluate> dapal, ^
[21:47] <dapal> (yes, I was thinking)
[21:47] <evaluate> ok :-)
[21:48] <evaluate> I'm taking a smoke, brb in 5
[21:48] <dapal> evaluate: ok, go for the postinst :)
[21:48] <dapal> evaluate: smoking is bad. :P
[21:59] <evaluate> yes, I know that...
[21:59] <evaluate> anyway, should I leave the postinst file like it is then?
[22:03] <dapal> evaluate: /etc/cmsmadesimple/, put it in debian/dirs
[22:04] <dapal> evaluate: also, chmod to 660, no need to make them executable :)
[22:04] <dapal> evaluate: and the for loop, you can move that in rules
[22:04] <evaluate> well, the folders need to be executable, don't they?
[22:05] <dapal> evaluate: config.php isn't a folder :D
[22:05] <dapal> yes, the folders 770
[22:05] <evaluate> I mean the folders in the for loop
[22:05] <evaluate> ok
[22:05] <dapal> heh, before I meant "chmod config.php to 660"
[22:05] <dapal> ;)
[22:13] <evaluate> dapal, ok, done. Link is the same
[22:14] <evaluate> dapal, btw, I guess you noticed that clipit got uploaded :-D
[22:14] <dapal> evaluate: yup :) -- I'm a bit tired for today, almost going to bed. To avoid mistakes, I'd prefer having a last look tomorrow :)
[22:15] <evaluate> sure, no hurry :-)
[22:15] <evaluate> I'll read you tomorrow then. Have a good night!
[22:15] <dapal> thanks, you too :)