[00:58] <broder> 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] <broder> ...also feisty-backports, it turns out
[04:45] <SpamapS>  * State: Failed to build
[04:45] <SpamapS>  * Duration: 18 hours
[04:45] <SpamapS> *sigh*
[04:52] <JackyAlcine> O.o that sucks.. :/
[04:54] <micahg> SpamapS: are you fixing gnash or should I add it back to my list?
[05:28] <SpamapS> micahg: I am leaving failures like that to the end.. so if you want to handle gnash.. have at it.
[05:29] <micahg> 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] <SpamapS> micahg: ok thanks!
[06:59] <infinity> SpamapS: Ugh, why is MySQL still building with gcc-4.5?
[07:00] <infinity> SpamapS: Oh, nevermind.  Looking at the bug from the changelog.
[09:13] <cjwatson> 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] <cjwatson> SpamapS: (breaks Kubuntu image builds)
[09:20] <infinity> test 1082...OK (556 out of 628, remaining: 01:08)
[09:20] <infinity> ^-- Counting is hard.
[09:26] <cjwatson>   2618kB    17kB/s - Uploading data to master branch - Stage:Fetching revisions:Inserting stream:Estimate 322/108
[09:26] <cjwatson> infinity: ^- ditto
[09:27]  * infinity snickers.
[09:31] <infinity> Also...
[09:31] <infinity>  09:31:19 up 8 days, 13:41,  7 users,  load average: 5.13, 4.47, 4.87
[09:31] <infinity> ^-- Does this mean my Panda passes the "server-class" test.  It hasn't died in over a week!
[09:32] <SpamapS> cjwatson: will fix akonadi
[09:50] <cjwatson> SpamapS: thanks
[11:29]  * infinity apologises to the buildds.
[16:48] <ockham_> hi, i'm trying to assign a version number to a binary package that is different from the source package's.
[16:48] <ockham_> can someone help me or point me to something?
[16:50] <tumbleweed> 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] <ockham_> 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] <ockham_> 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] <tumbleweed> ockham_: how about just Replaces + Breaks ?
[16:52] <tumbleweed> ah, ok
[16:52] <ockham_> tumbleweed: i know; but does that provide a reliable upgrade path, given that version numbers issue?
[16:52] <ockham_> tumbleweed: could you elaborate at what point to pass options to dpkg-gc?
[16:52] <tumbleweed> it has a manpage
[16:53] <ockham_> tumbleweed: hm, i checked it, but i couldn't really figure it out.
[16:59] <ockham_> 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] <cjwatson> is it your own package, or a modification of one from elsewhere (e.g. Debian)?
[17:43] <ockham_> 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] <SpamapS> hrm...
[17:44] <SpamapS> aolserver's build process seems... almost totally nuts
[18:08] <JanC> SpamapS: I always wondered if anybody still uses that?  ☺
[18:45] <cjwatson> 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] <cjwatson> 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] <ockham_> 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] <ockham_> cjwatson: btw: TBH=?
[18:49] <JanC> TBH = to be honest
[18:50] <JanC> ockham_: ^^^
[18:52] <cjwatson> yes
[18:53] <cjwatson> 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] <cjwatson> although not enough to fight about it
[18:55] <cjwatson> 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] <cjwatson> that might be a reasonable compromise position
[18:55] <micahg> we've got an example of that in the thunderbird source
[18:55] <cjwatson> on rereading I guess that's actually Ariel's second choice
[18:56] <ockham_> micahg: thx, i'll take a look into that.
[18:57] <ockham_> 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] <cjwatson> yeah
[18:58] <cjwatson> VERSION := $(shell dpkg-parsechangelog | awk '/^Version:/ { print $$2 }')
[18:58] <cjwatson> near the top of debian/rules
[18:58] <cjwatson> then:
[18:58] <cjwatson> override_dh_gencontrol:
[18:58] <cjwatson>         dh_gencontrol -Npysolfc
[18:59] <cjwatson>         dh_gencontrol -ppysolfc -- -v"1:$(VERSION)"
[18:59] <cjwatson> assuming you're using dh, anyway
[18:59]  * tumbleweed likes that approach
[19:00] <ockham_> cjwatson: yup, using dh. thx, sounds good.
[19:21] <ockham_> 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] <ockham_> but my dummy pysol will then be 2.0-1 which is less than 4.8.
[19:22] <ockham_> so don't i have to use dh_gencontrol for pysol (not pysolfc)?
[19:29] <tumbleweed> ockham_: yes
[19:30] <ockham_> tumbleweed: and what about breaks/replaces/conflicts?
[19:33] <tumbleweed> ockham_: Breaks + Replaces, yes
[19:36] <mneptok> 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] <mneptok> credentials are correct, but supplying them just returns to the LightDM login screen
[19:37] <mneptok> (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] <lifeless> no bikkie for xubuntu
[19:38] <mneptok> amen
[19:38] <mneptok> do NOT encrypt my data without my permission. it's mine. i'll decide.
[19:39] <Ampelbein> mneptok: What installation iso did you use? I didn't have that problem while testing xubuntu.
[19:39] <mneptok> alt-i386
[19:39] <penguin42> 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] <mneptok> alt-F2 is not getting me an alternate TTY
[19:44] <mneptok> and i cannot seem to get a GRUB menu :(
[19:44] <penguin42> mneptok: Have you ever noticed there are some days when computers just don't want to work with you?
[19:45] <mneptok> penguin42: not really. Debian is fairly predictable. >:)
[19:46] <mneptok> it's very clear that the existing $HOME was encyoted without permission
[19:47] <mneptok> YAY! GRUB menu at last!
[19:47] <penguin42> mneptok: Might be worth checking the logs from the installer - they should be somewhere
[19:50] <mneptok> the only thing left in this user's $HOME is "Access-Your-Private-Data.desktop" and "README.txt"
[19:51] <mneptok> 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] <mneptok> is there an easy way to reverse this encryption?
[19:58] <mneptok> kirkland: hjalp?
[19:59] <lifeless> mneptok: what sort of encrpyiotn?
[19:59] <lifeless> mneptok: should be a simple unmount to get back to the original data
[19:59] <mneptok> lifeless: ecryptfs $HOME
[20:00] <mneptok> 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] <cjwatson> ockham_: sorry, yeah, I mixed up pysol and pysolfc
[20:02] <ockham_> cjwatson: np. just got a little confused...
[20:02] <cjwatson> mneptok: can you post /var/log/installer/cdebconf/questions.dat somewhere?
[20:03] <ockham_> i'm building it right now...
[20:03] <mneptok> cjwatson: can try
[20:03] <cjwatson> /var/log/syslog wouldn't hurt either but is secondary
[20:04] <mneptok> brb. need USB key
[20:10] <mneptok> cjwatson: http://birdhouse.org/~mnep/cjwatson
[20:10] <mneptok> bleh. fixing perms
[20:11] <mneptok> fixed.
[20:13] <lifeless> mneptok: its not really encrypted
[20:13] <lifeless> mneptok: the existing data is just masked by the ecryptfs layer
[20:13] <cjwatson> mneptok: um, sorry, I meant /var/log/installer/syslog not /var/log/syslog
[20:13] <mneptok> cjwatson: oh, of course you did. my bad. brain fart.
[20:14] <cjwatson> IRC scrollback suggests my bad, in fact ;-)
[20:15] <mneptok> cjwatson: but i should have interpreted it
[20:16] <ockham_> my pysolfc build failed:
[20:16] <ockham_> dpkg-genchanges: error: badly formed line in files list file, line 2
[20:16] <ockham_> dpkg-buildpackage: error: dpkg-genchanges gave error exit status 25
[20:16] <ockham_> E: Failed autobuilding of package
[20:16] <mneptok> cjwatson: the correct syslog is now there
[20:17] <mneptok> lifeless: the "ecryptfs layer" should not even exist unless i was asked if i wanted it at *all*
[20:17] <ockham_> btw, what does the -N arg to dh_gencontrol do? couldn't find it in the manpage.
[20:17] <cjwatson> mneptok: 403
[20:17] <cjwatson> ockham_: man debhelper
[20:18] <mneptok> cjwatson: grah. fixed.
[20:19] <cjwatson> 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] <lifeless> mneptok: I agree; I"m not arguing that. I'm noting that recovery should be easy.
[20:19] <mneptok> cjwatson: and yet the user's existing $HOME is devoid of anything that was there before
[20:19] <cjwatson> no trace in the logs, and it didn't hit the ecryptfs paths in user-setup
[20:19] <cjwatson> I believe you, I'm just trying to figure out *how*
[20:20] <cjwatson> as lifeless said, though, a umount should correct this at least temporarily?
[20:20] <mneptok> cjwatson: this happened on 2 subsequent installs, too.
[20:20] <kirkland> installs of what version of ubuntu?
[20:20] <cjwatson> are these logs from the first such install?
[20:20] <cjwatson> kirkland: it's all in the logs
[20:21] <mneptok> cjwatson: second
[20:21] <cjwatson> do logs from the first exist?
[20:21] <mneptok> cjwatson: sadly, no
[20:22] <cjwatson> in fact, the installer AFAICT didn't even install ecryptfs-utils here
[20:22] <mneptok> 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] <cjwatson> can I see the output of 'mount'?
[20:22] <mneptok> cjwatson: correct, the -utils pkg was not installed
[20:22] <ockham_> any clue what's the reason for those errors? ^^^
[20:22] <cjwatson> ockham_: hard to say without the full og
[20:22] <cjwatson> *log
[20:22] <cjwatson> and preferably a copy of the source package for reference
[20:23] <ockham_> cjwatson: i'll pastebin the log
[20:23] <cjwatson> mneptok: I'm wondering if a finger-fumble selected encryption on the first install, but then not on the second install
[20:23] <cjwatson> is that at all possible?
[20:23] <cjwatson> the bug is then that you get left in a confusing intermediate state
[20:24] <mneptok> cjwatson: neither install ever asked me about encrypting homes
[20:24] <mneptok> cjwatson: output of "mount" now in that same dir
[20:24] <cjwatson> hmm
[20:25] <cjwatson> so it deliberately doesn't ask if a home directory already exists
[20:25] <cjwatson> but AFAICT it then doesn't configure encryption
[20:25] <cjwatson> 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] <cjwatson> that would explain the symptoms
[20:25] <mneptok>  /home is/was a separate partition. i told debian-installer to use that partition as /home, but not format it
[20:25] <ockham_> log is at http://pastebin.com/erF4K6ha
[20:26] <cjwatson> mneptok: understood; is it possible that ecryptfs was in use beforehand?
[20:26] <cjwatson> 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] <mneptok> not likely
[20:27] <cjwatson> but possible?  it does explain things perfectly
[20:27] <mneptok> and i just created a new user, who also gets thrown back to a GUI login after entering credentials
[20:27] <cjwatson> because in that case, you'd have /home/$USER/.ecryptfs and no arrangements for mounting it in the new system
[20:28] <cjwatson> I just can't find any other way this could have arisen
[20:29] <cjwatson> 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] <mneptok> OK, i'll try it
[20:31] <cjwatson> 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] <cjwatson> might be worth trying from a console to reduce possibilities
[20:33] <mneptok> cjwatson: installing ecryptfs-utils allowed me to login
[20:34] <mneptok> cjwatson: my deep and abiding affection for you has somehow become deeper
[20:34] <mneptok> :)
[20:34]  * mneptok backs up to an external drive and prepares to do a 100% clean install
[20:36] <cjwatson> :-)
[20:36] <cjwatson> I don't know how to convert from an encrypted home to an unencrypted home
[20:36] <cjwatson> except of course by rsyncing everything off and back on again
[20:37] <mneptok> 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] <cjwatson> 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] <mneptok> one of my new personal rules is "Never send FUSE to do dm-crypt's job."
[20:38] <cjwatson> though my hypothesis about the original cause is probably unprovable either way at this point
[20:44] <mneptok> cjwatson: i would always cover my tracks sufficiently to ensure PEBKAC can only be a theory ;)
[20:50] <kirkland> mneptok: fyi, ecryptfs is not FUSE
[20:50] <kirkland> mneptok: its an in-kernel filesystem
[20:50] <kirkland> encfs == fuse
[20:50] <kirkland> encfs != ecryptfs
[20:57] <mneptok> 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] <mneptok> kids these days ....
[20:57] <mneptok> :)
[21:03] <broder> could i get somebody to accept the sru nominations for bug #629646?
[21:06] <tumbleweed> broder: doing it
[21:06] <broder> thanks
[21:38] <ockham_> cjwatson: about pysolfc... ^^^
[21:40] <ockham_> cjwatson: can you take a look at the log?
[22:01] <tumbleweed> ockham_: the error looks unrelated
[22:01] <ockham_> tumbleweed: really? i don't think it's been there before
[22:01] <tumbleweed> dpkg-genchanges: error: badly formed line in files list file, line 2
[22:02] <tumbleweed> ockham_: sorry, can't be any more help without the source
[22:03] <ockham_> tumbleweed: one moment...
[22:05] <ockham_> tumbleweed: would you suggest i just push this faulty state of affairs to the games team git repo?
[22:05] <ockham_> tumbleweed: or is that a bad idea?
[22:11] <ockham_> ok, i'll just do it...