[00:17] how can I restore ssh private key? [00:18] ...restore? as in you lost it? [00:20] define restore... restore from backup? [00:37] ebroder, psusi: after change gnome -> kde, any software couldn't find my ssh key [00:37] e.g. filezilla [00:37] now bzr always asks me for password :/ [00:37] ari-tczew: your private key is in ~/.ssh/id_rsa. you just need to get the password into kwallet, presumbly [00:39] I always get prompted for my key pass... I don't use ssh-agent or anything [00:44] ebroder: it seems to normal software to store of password, not for handle passwords for bzr, or am I wrong? [00:45] ari-tczew: it's not a bzr password. it's an ssh key password that bzr uses. and it does store those [00:45] ebroder: and kwalletmanager will remember my password for ssh? [00:45] i don't know that for sure, but i believe so. certainly gnome-keyring can [00:47] err, note that it's not storing an ssh password, it's storing an ssh *key* password [00:58] ebroder: I don't see a way to set ssh pass in kwalletmanager :/ [00:59] ari-tczew: sorry, then. i can't really guess any more about how kde works. maybe ask in #kubuntu or something? === Amaranth_ is now known as Amaranth [04:24] 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] i'm having trouble adding the generated deb packages with reprepro as the sha values are different.. specifically create packages for nginx [05:59] james_w, are you online?? === hanska is now known as dapal === yofel_ is now known as yofel [12:13] is it possible to know the version of a previous package before upgrading ? .. i need it in my postinst script [12:14] $2 afaik [12:14] ok [12:14] http://wiki.debian.org/MaintainerScripts [12:19] Laney, isn't $2 the new version to install ? [12:24] possibly [12:24] check those diagrams === kgnomelogger is now known as apachelogger [12:42] hmm, dh_link does not support symlinks of directories ? [12:42] http://dpaste.com/300237/ [12:43] man dh_link does not specify a specific option or rules i should use to avoid such a problem === menesis1 is now known as menesis === apachelogger is now known as fedoraloggr === fedoraloggr is now known as fedoralogger [13:14] is it OK to add new patch system to package to use new patch? [13:14] IIRC we should patch files directly if there is no patch system [13:15] ari-tczew: this rule applies only to SRU afair in which case you are to prepare the minimal possible diff. [13:15] kklimonda: is it clear on any wiki? [13:16] 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] is similar* [13:16] 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] it's prefered to not add a patch system if not already in use [13:18] especially when the package is already patched (directly) which causes only a mix [13:21] 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] clean = unchanged [13:26] 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] 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] it means that Canonical like don't respect rules [13:35] 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] I don't remember seeing it written down somewhere either [13:37] it also depends on the size of the patches [13:37] 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] there is https://wiki.ubuntu.com/PackagingGuide/PatchSystems#Patching%20other%20people%27s%20packages but it's ambiguos imo. [13:38] but if you e.g. need to autoreconf then adding a patch system is a good idea [13:39] geser: autoreconf runs via debian/rules [13:39] so there is no place for 99_* patch. [13:44] 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] starting a discussion on u-d* [13:57] lfaraone: great! First applicant means you'll have the energy to drive my NM application thorugh in record time, right? :) [14:01] tumbleweed: maybe you could give a feedback: what do you think about adding patch systems? [14:01] ari-tczew: I'd say it depends on the complexity of the patch. I wouldn't add one for a simple patch [14:02] tumbleweed: case: https://code.launchpad.net/~barry/ubuntu/natty/libfso-glib/618809-ftbfs/+merge/45579 [14:05] 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] his changelog entries could be a little more complete [14:06] tumbleweed: as you can read comments, I pinged him to improve d/changelog, he added info about d/rules. [14:07] I think that he should add also information about libtool [14:07] tumbleweed: so you agree with adding patch system? [14:08] 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] re libtool: yeah, probably, it'll help future mergers. re patch sys: I don't mind it. [14:09] lfaraone: it wasn't signed? /me slaps mutt [14:09] lfaraone: the version in my Sent box is signed [14:09] tumbleweed: wait, nevermind, my mail client was munging the siggy. [14:10] aha, I reloaded the message and now it works. [14:14] 42 [14:14] 43 [14:14] hrm, there was supposed to be /ws before that, sorry. [14:14] :P === lucas__ is now known as lucas [14:39] kklimonda: that wiki is pretty clear, don't change the patch system [14:40] micahg: not change, add [14:40] ari-tczew: it's in the first line (or lack thereof) [14:41] 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] kklimonda: huh? what's the difference between that and what I said? [14:42] micahg: in the mentioned merge there is no patch system, and there are no patches applied to the source. [14:43] yes, barry want to add patch system and small patch on unmodified packages [14:51] micahg: what about uploads where patch system has been added? [15:00] tumbleweed: P&P 1 mailed, your move. :P [15:04] new chess game? :) [15:04] 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] 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] ari-tczew: reference the wiki WRT the patch system situation [15:26] hopefully that patch system issue will go away soon with source format 3 after squeeze releases [15:29] well, source format 3 isn't mandatory [15:29] micahg: not all packages will switch to 3.0 source format [15:29] hopefully most will switch [15:30] most will, the only thing blocking that at the moment is the squeeze freeze, about 1/3 of Debian has converted [15:30] 3.0 native packages will still have the same problems, though [15:30] tumbleweed: which problems> [15:30] ari-tczew: no built in patch system [15:32] micahg: do you will file a report about breaking policy by tumbleweed? [15:32] ari-tczew: eh? [15:34] tumbleweed: I didn't say that you're breaking a policy - adding patch system. === fedoralogger is now known as phononlogger [17:41] hello again, i try to build a package and I got everytime the same error [17:41] dh_usrlocal debian/foobar/test.jpg is not a dicrectory [17:43] contrary to popular belief, when computers are concerned, repeating steps do not yield different results every time you try ;) [17:43] it only works if i dont use my files ;D [17:51] Any reviewer who uses GNOME please have a look at: http://revu.ubuntuwire.com/p/wallch Thank you [17:58] RainCT: are you able to upload gbrainy 1.61 to Debian? unstable/experimental? [17:58] ari-tczew: Yes [17:58] RainCT: great thanks! [17:59] ari-tczew: I uploaded 1.60 yesterday. Where did you get a 1.61? [17:59] RainCT: ah this it only NEWS file, sorry for my fire. http://git.gnome.org/browse/gbrainy/commit/?id=d232e6056bec15105162dff2924494fc61ecc87f [18:08] is anybody interested in taking some items from https://wiki.ubuntu.com/DesktopTeam/Specs/Natty/Firefox4/XULRunner20Transition ? [18:08] it's the cause of a few build failures on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi [18:12] chrisccoulson: would be nice if you give a tutorial how to do transition [18:12] 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] however, there is a lot of mozilla documentation that helps already [18:13] eg, https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0 [18:14] I'd like to help with that. However, I have no free time. :( === Lutin is now known as Guest31339 === Guest31339 is now known as Lutin [21:06] evaluate: ping? :) [21:06] evaluate: since we haven't uploaded cmsmadesimple yet, why -2 instead of re-doing -1? ;) [21:08] 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] 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] evaluate: sure it does -- it'll just complain about an "existing orig.tar.gz", but it's just a warning ;) [21:09] ok. So should I repackage it again as -1? [21:10] no need for now. If the package is ok, I could just "mangle" it to only show -1 [21:10] I'll send the diff of my changes, so you can include them in your $vcs ;) [21:10] dapal, cool. [21:11] 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] also, just FTR, I have installed it and made a couple of changes, and it worked fine for me. [21:12] ok, what changes were those? [21:12] logged into admin, changed some contents, text, basic stuff like that [21:14] 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] 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] ok, so, a couple of comments [21:16] it's ok if you provide a symlink like the one you did, in the package (debian/links or debian/cmsmadesimple.links) [21:17] the patch seems OK-ish [21:17] tumbleweed: P&P II in your inbox. [21:17] i.e. maybe there's a better way to do it [21:18] 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] 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] 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] hmm. I'd still have to do the chmod and chown stuff in the postinst though, wouldn't I? [21:19] evaluate: nope, you can in rules [21:20] 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] dapal, yeah, that makes sense. [21:21] 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] (at least, I've seen those kind of files more or less named like that) [21:22] 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] 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] lfaraone: I see :) [21:23] 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] lfaraone: there goes that movie I intended watching tonight... [21:24] tumbleweed: relax, it'll be there in the morning. [21:24] 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] lfaraone: :) [21:24] evaluate: let me check :) [21:25] sure :-) [21:26] evaluate: (also remove postrm, obviously) [21:26] evaluate: mmhh. The apache2 | httpd dependency. [21:27] evaluate: ok, nothing, it just needs httpd, not httpd-cgi :) [21:27] 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] evaluate: uhm, ok [21:28] evaluate: for the patch, there's DEP-3 ;) [21:29] I'm not sure what you mean [21:29] 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] evaluate: the patch description, http://dep.debian.net/deps/dep3/ [21:30] ok, will change the patch [21:31] evaluate: then it's just fine. [21:32] 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] evaluate: that's a non-issue ;) -- the files that aren't in any package could just be removed before installing [21:33] however, that's ok, no problem. Please go :) [21:35] ok, let's see :p [21:40] dapal, btw, do I have to build-depend on quilt if I have patches? [21:41] evaluate: nope, source format 3.0 (quilt) will take care of that [21:41] ok, cool :-) [21:46] 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] dapal, ^ [21:47] (yes, I was thinking) [21:47] ok :-) [21:48] I'm taking a smoke, brb in 5 [21:48] evaluate: ok, go for the postinst :) [21:48] evaluate: smoking is bad. :P [21:59] yes, I know that... [21:59] anyway, should I leave the postinst file like it is then? [22:03] evaluate: /etc/cmsmadesimple/, put it in debian/dirs [22:04] evaluate: also, chmod to 660, no need to make them executable :) [22:04] evaluate: and the for loop, you can move that in rules [22:04] well, the folders need to be executable, don't they? [22:05] evaluate: config.php isn't a folder :D [22:05] yes, the folders 770 [22:05] I mean the folders in the for loop [22:05] ok [22:05] heh, before I meant "chmod config.php to 660" [22:05] ;) [22:13] dapal, ok, done. Link is the same [22:14] dapal, btw, I guess you noticed that clipit got uploaded :-D [22:14] 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] sure, no hurry :-) [22:15] I'll read you tomorrow then. Have a good night! [22:15] thanks, you too :)