=== yofel_ is now known as yofel [00:58] is there a tool for mass-closing bugs? i think it's probably about time to clean out the dapper-backports bug queue [01:00] ...also feisty-backports, it turns out === EvilJackyAlcine is now known as JackyAlcine [04:45] * State: Failed to build [04:45] * Duration: 18 hours [04:45] *sigh* === calc is now known as Guest39737 [04:52] O.o that sucks.. :/ [04:54] SpamapS: are you fixing gnash or should I add it back to my list? === mfisch` is now known as mfisch === mfisch is now known as Guest24696 [05:28] micahg: I am leaving failures like that to the end.. so if you want to handle gnash.. have at it. [05:29] SpamapS: ok, it's the same failure as I had for the original merge which is why I haven't fixed it yet, but will try to get to it soon (it's due to Firefox 8+) [05:33] micahg: ok thanks! [06:59] SpamapS: Ugh, why is MySQL still building with gcc-4.5? [07:00] SpamapS: Oh, nevermind. Looking at the bug from the changelog. [09:13] SpamapS: akonadi-backend-mysql still depends on mysql-server-core-5.1, mysql-client-core-5.1, by the looks of things; I guess the transition tracker doesn't show that [09:14] SpamapS: (breaks Kubuntu image builds) [09:20] test 1082...OK (556 out of 628, remaining: 01:08) [09:20] ^-- Counting is hard. [09:26] 2618kB 17kB/s - Uploading data to master branch - Stage:Fetching revisions:Inserting stream:Estimate 322/108 [09:26] infinity: ^- ditto [09:27] * infinity snickers. [09:31] Also... [09:31] 09:31:19 up 8 days, 13:41, 7 users, load average: 5.13, 4.47, 4.87 [09:31] ^-- Does this mean my Panda passes the "server-class" test. It hasn't died in over a week! [09:32] cjwatson: will fix akonadi [09:50] SpamapS: thanks === yofel_ is now known as yofel [11:29] * infinity apologises to the buildds. === kk is now known as Guest1327 === Guest1327 is now known as blackbug === Quintasan_ is now known as Quintasan === stalcup is now known as what === what is now known as v [16:48] hi, i'm trying to assign a version number to a binary package that is different from the source package's. [16:48] can someone help me or point me to something? [16:50] ockham_: it's doable by passing options to dpkg-gencontrol, but obviously this is a very weird thing to do, so be careful with it :) [16:51] tumbleweed: hi, thx for your reply. it's because of my pysolfc package (which you might recall) -- it's version 2.0, but it's superseding pysol 4.82 or so... [16:51] tumbleweed: so if i want my pysolfc control file to provide a dummy pysol package for transition, i'd need to assign in a version number > 4.82. [16:51] ockham_: how about just Replaces + Breaks ? [16:52] ah, ok [16:52] tumbleweed: i know; but does that provide a reliable upgrade path, given that version numbers issue? [16:52] tumbleweed: could you elaborate at what point to pass options to dpkg-gc? [16:52] it has a manpage [16:53] tumbleweed: hm, i checked it, but i couldn't really figure it out. [16:59] tumbleweed: do you think any other way would be preferrable? so far, i've even had separate source packages for the dummies, but i guess that's even worse. [17:10] is it your own package, or a modification of one from elsewhere (e.g. Debian)? [17:43] cjwatson: sry, been afk for a while. it's my package -- been in ubuntu since lucid, and searching for debian sponsorss since then :-/ [17:44] hrm... [17:44] aolserver's build process seems... almost totally nuts [18:08] SpamapS: I always wondered if anybody still uses that? ☺ [18:45] ockham_: so if you're the original packager, then TBH, I'd consider just adding a 1: epoch to the source package as the path of least resistance; only if you're certain the transition is permanent, though [18:45] ockham_: (I wouldn't suggest this if the package had a prior existence somewhere else, as that would mean you'd never be able to merge again unless you convinced the packaging-upstream to add the epoch as well) [18:49] cjwatson: thx. i was considering that, but http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519752#35 suggested the other way. but i think i'll probably really use the epoch approach. [18:49] Debian bug 519752 in wnpp "ITP: pysolfc -- A Python solitaire game collection" [Wishlist,Open] [18:49] cjwatson: btw: TBH=? [18:49] TBH = to be honest [18:50] ockham_: ^^^ [18:52] yes [18:53] ockham_: although it's technically an abuse of epochs, I think it's overall less confusing than using dpkg-gencontrol -v to fiddle with the version of a single binary package, so I respectfully disagree with Ariel [18:54] although not enough to fight about it [18:55] or I suppose you could add an epoch just for that binary package, which might be less confusing than adding some fixed integer to the version [18:55] that might be a reasonable compromise position [18:55] we've got an example of that in the thunderbird source [18:55] on rereading I guess that's actually Ariel's second choice [18:56] micahg: thx, i'll take a look into that. [18:57] cjwatson: i'm a bit confused. so i'd end up using the epoch field only for that transitional binary package? not the entire source package? [18:57] yeah [18:58] VERSION := $(shell dpkg-parsechangelog | awk '/^Version:/ { print $$2 }') [18:58] near the top of debian/rules [18:58] then: [18:58] override_dh_gencontrol: [18:58] dh_gencontrol -Npysolfc [18:59] dh_gencontrol -ppysolfc -- -v"1:$(VERSION)" [18:59] assuming you're using dh, anyway [18:59] * tumbleweed likes that approach [19:00] cjwatson: yup, using dh. thx, sounds good. [19:21] cjwatson: just to make sure i'm doing this correctly: this will make the pysolfc binary package version 1:2.0-1, which is greater than pysol's 4.8.something [19:21] but my dummy pysol will then be 2.0-1 which is less than 4.8. [19:22] so don't i have to use dh_gencontrol for pysol (not pysolfc)? [19:29] ockham_: yes [19:30] tumbleweed: and what about breaks/replaces/conflicts? [19:33] ockham_: Breaks + Replaces, yes [19:36] anyone have any ideas why a machine with a clean Xubuntu install to a dedicated / while preserving an exisiting /home from a previous version fails to allow a login? [19:36] credentials are correct, but supplying them just returns to the LightDM login screen [19:37] (also, it seems Xubuntu took it upon itself to encrypt that existing /home, without ever asking if it was OK to manipulate the data. Bad. very, very Bad) [19:37] no bikkie for xubuntu [19:38] amen [19:38] do NOT encrypt my data without my permission. it's mine. i'll decide. [19:39] mneptok: What installation iso did you use? I didn't have that problem while testing xubuntu. [19:39] alt-i386 [19:39] mneptok: I'd check the .xsession-errors of the user you're trying to log in as for errors and the lightdm logs [19:42] alt-F2 is not getting me an alternate TTY [19:44] and i cannot seem to get a GRUB menu :( [19:44] mneptok: Have you ever noticed there are some days when computers just don't want to work with you? [19:45] penguin42: not really. Debian is fairly predictable. >:) [19:46] it's very clear that the existing $HOME was encyoted without permission [19:47] YAY! GRUB menu at last! [19:47] mneptok: Might be worth checking the logs from the installer - they should be somewhere [19:50] the only thing left in this user's $HOME is "Access-Your-Private-Data.desktop" and "README.txt" [19:51] and yet df -h reports the partition as 20GB used. so the data is there, it's just the installer decided to encrypt it without permission [19:53] is there an easy way to reverse this encryption? [19:58] kirkland: hjalp? [19:59] mneptok: what sort of encrpyiotn? [19:59] mneptok: should be a simple unmount to get back to the original data [19:59] lifeless: ecryptfs $HOME [20:00] lifeless: /home/$USERNAME that exisated from a previous install was encrypted with ecryptfs without prompting. to say i am disappointed is a massive understatement. [20:02] * mneptok tries to find out how to decrypt this from a command line [20:02] ockham_: sorry, yeah, I mixed up pysol and pysolfc [20:02] cjwatson: np. just got a little confused... [20:02] mneptok: can you post /var/log/installer/cdebconf/questions.dat somewhere? [20:03] i'm building it right now... [20:03] cjwatson: can try [20:03] /var/log/syslog wouldn't hurt either but is secondary [20:04] brb. need USB key [20:10] cjwatson: http://birdhouse.org/~mnep/cjwatson [20:10] bleh. fixing perms [20:11] fixed. [20:13] mneptok: its not really encrypted [20:13] mneptok: the existing data is just masked by the ecryptfs layer [20:13] mneptok: um, sorry, I meant /var/log/installer/syslog not /var/log/syslog [20:13] cjwatson: oh, of course you did. my bad. brain fart. [20:14] IRC scrollback suggests my bad, in fact ;-) [20:15] cjwatson: but i should have interpreted it [20:16] my pysolfc build failed: [20:16] dpkg-genchanges: error: badly formed line in files list file, line 2 [20:16] dpkg-buildpackage: error: dpkg-genchanges gave error exit status 25 [20:16] E: Failed autobuilding of package [20:16] cjwatson: the correct syslog is now there [20:17] lifeless: the "ecryptfs layer" should not even exist unless i was asked if i wanted it at *all* [20:17] btw, what does the -N arg to dh_gencontrol do? couldn't find it in the manpage. [20:17] mneptok: 403 [20:17] ockham_: man debhelper === micahg_ is now known as micahg [20:18] cjwatson: grah. fixed. [20:19] that is very odd. as best as I can tell, the installer did nothing with ecryptfs at all, and should have configured it off [20:19] mneptok: I agree; I"m not arguing that. I'm noting that recovery should be easy. [20:19] cjwatson: and yet the user's existing $HOME is devoid of anything that was there before [20:19] no trace in the logs, and it didn't hit the ecryptfs paths in user-setup [20:19] I believe you, I'm just trying to figure out *how* [20:20] as lifeless said, though, a umount should correct this at least temporarily? [20:20] cjwatson: this happened on 2 subsequent installs, too. [20:20] installs of what version of ubuntu? [20:20] are these logs from the first such install? [20:20] kirkland: it's all in the logs [20:21] cjwatson: second [20:21] do logs from the first exist? [20:21] cjwatson: sadly, no [20:22] in fact, the installer AFAICT didn't even install ecryptfs-utils here [20:22] is there an easy way for me to decrypt this dir from a shell, rsync the data to another location, and see if i can login as a new user? my ecryptfs experience is limited [20:22] can I see the output of 'mount'? [20:22] cjwatson: correct, the -utils pkg was not installed [20:22] any clue what's the reason for those errors? ^^^ [20:22] ockham_: hard to say without the full og [20:22] *log [20:22] and preferably a copy of the source package for reference [20:23] cjwatson: i'll pastebin the log [20:23] mneptok: I'm wondering if a finger-fumble selected encryption on the first install, but then not on the second install [20:23] is that at all possible? [20:23] the bug is then that you get left in a confusing intermediate state [20:24] cjwatson: neither install ever asked me about encrypting homes [20:24] cjwatson: output of "mount" now in that same dir [20:24] hmm [20:25] so it deliberately doesn't ask if a home directory already exists [20:25] but AFAICT it then doesn't configure encryption [20:25] is it possible that the prior state of the system, before this sequence of installs, in fact had an encrypted home directory there? [20:25] that would explain the symptoms [20:25] /home is/was a separate partition. i told debian-installer to use that partition as /home, but not format it [20:25] log is at http://pastebin.com/erF4K6ha [20:26] mneptok: understood; is it possible that ecryptfs was in use beforehand? [20:26] I do see a bug here that in that situation we don't arrange for ecryptfs-utils to be installed so that it can decrypt the home directory [20:26] not likely [20:27] but possible? it does explain things perfectly [20:27] and i just created a new user, who also gets thrown back to a GUI login after entering credentials [20:27] because in that case, you'd have /home/$USER/.ecryptfs and no arrangements for mounting it in the new system [20:28] I just can't find any other way this could have arisen [20:29] if that is the case, then installing ecryptfs-utils and ensuring that the user has the same password as before should be enough [20:30] OK, i'll try it [20:31] I'm not sure why the new user login doesn't work; it's not entirely obvious to me that that has the same cause [20:31] might be worth trying from a console to reduce possibilities [20:33] cjwatson: installing ecryptfs-utils allowed me to login [20:34] cjwatson: my deep and abiding affection for you has somehow become deeper [20:34] :) [20:34] * mneptok backs up to an external drive and prepares to do a 100% clean install [20:36] :-) [20:36] I don't know how to convert from an encrypted home to an unencrypted home [20:36] except of course by rsyncing everything off and back on again [20:37] cjwatson: exactly what i'm doing. rsync to an external. do a complete re-partiton of the disk, re-install and NOT use ecryptfs. [20:37] and this is definitely a bug in user-setup for failing to install ecryptfs-utils when /home/$USER/.ecryptfs exists, which at the very least was true in the second and subsequent installs [20:37] one of my new personal rules is "Never send FUSE to do dm-crypt's job." [20:38] though my hypothesis about the original cause is probably unprovable either way at this point [20:44] cjwatson: i would always cover my tracks sufficiently to ensure PEBKAC can only be a theory ;) [20:50] mneptok: fyi, ecryptfs is not FUSE [20:50] mneptok: its an in-kernel filesystem [20:50] encfs == fuse [20:50] encfs != ecryptfs [20:57] kirkland: when i was a whippersnapper we configured dm-crypt by hand. in a blizzard. while walking 25 miles to vote against Hoover. AND WE LIKED IT! [20:57] kids these days .... [20:57] :) [21:03] could i get somebody to accept the sru nominations for bug #629646? [21:03] Launchpad bug 629646 in libgweather "Locations using bom.gov.au for forecast data no longer can no longer retrieve forecast data" [Medium,Fix released] https://launchpad.net/bugs/629646 [21:06] broder: doing it [21:06] thanks === tkamppeter_ is now known as tkamppeter [21:38] cjwatson: about pysolfc... ^^^ [21:40] cjwatson: can you take a look at the log? [22:01] ockham_: the error looks unrelated [22:01] tumbleweed: really? i don't think it's been there before [22:01] dpkg-genchanges: error: badly formed line in files list file, line 2 [22:02] ockham_: sorry, can't be any more help without the source [22:03] tumbleweed: one moment... [22:05] tumbleweed: would you suggest i just push this faulty state of affairs to the games team git repo? [22:05] tumbleweed: or is that a bad idea? [22:11] ok, i'll just do it... === EvilJackyAlcine is now known as JackyAlcine === Guest89395 is now known as Zic