=== yofel_ is now known as yofel | ||
broder | is there a tool for mass-closing bugs? i think it's probably about time to clean out the dapper-backports bug queue | 00:58 |
---|---|---|
broder | ...also feisty-backports, it turns out | 01:00 |
=== EvilJackyAlcine is now known as JackyAlcine | ||
SpamapS | * State: Failed to build | 04:45 |
SpamapS | * Duration: 18 hours | 04:45 |
SpamapS | *sigh* | 04:45 |
=== calc is now known as Guest39737 | ||
JackyAlcine | O.o that sucks.. :/ | 04:52 |
micahg | SpamapS: are you fixing gnash or should I add it back to my list? | 04:54 |
=== mfisch` is now known as mfisch | ||
=== mfisch is now known as Guest24696 | ||
SpamapS | micahg: I am leaving failures like that to the end.. so if you want to handle gnash.. have at it. | 05:28 |
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:29 |
SpamapS | micahg: ok thanks! | 05:33 |
infinity | SpamapS: Ugh, why is MySQL still building with gcc-4.5? | 06:59 |
infinity | SpamapS: Oh, nevermind. Looking at the bug from the changelog. | 07:00 |
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:13 |
cjwatson | SpamapS: (breaks Kubuntu image builds) | 09:14 |
infinity | test 1082...OK (556 out of 628, remaining: 01:08) | 09:20 |
infinity | ^-- Counting is hard. | 09:20 |
cjwatson | 2618kB 17kB/s - Uploading data to master branch - Stage:Fetching revisions:Inserting stream:Estimate 322/108 | 09:26 |
cjwatson | infinity: ^- ditto | 09:26 |
* infinity snickers. | 09:27 | |
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:31 |
SpamapS | cjwatson: will fix akonadi | 09:32 |
cjwatson | SpamapS: thanks | 09:50 |
=== yofel_ is now known as yofel | ||
* infinity apologises to the buildds. | 11:29 | |
=== 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 | ||
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:48 |
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:50 |
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:51 |
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:52 |
ockham_ | tumbleweed: hm, i checked it, but i couldn't really figure it out. | 16:53 |
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. | 16:59 |
cjwatson | is it your own package, or a modification of one from elsewhere (e.g. Debian)? | 17:10 |
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:43 |
SpamapS | hrm... | 17:44 |
SpamapS | aolserver's build process seems... almost totally nuts | 17:44 |
JanC | SpamapS: I always wondered if anybody still uses that? ☺ | 18:08 |
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:45 |
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 |
ubottu | Debian bug 519752 in wnpp "ITP: pysolfc -- A Python solitaire game collection" [Wishlist,Open] | 18:49 |
ockham_ | cjwatson: btw: TBH=? | 18:49 |
JanC | TBH = to be honest | 18:49 |
JanC | ockham_: ^^^ | 18:50 |
cjwatson | yes | 18:52 |
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:53 |
cjwatson | although not enough to fight about it | 18:54 |
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:55 |
ockham_ | micahg: thx, i'll take a look into that. | 18:56 |
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:57 |
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:58 |
cjwatson | dh_gencontrol -ppysolfc -- -v"1:$(VERSION)" | 18:59 |
cjwatson | assuming you're using dh, anyway | 18:59 |
* tumbleweed likes that approach | 18:59 | |
ockham_ | cjwatson: yup, using dh. thx, sounds good. | 19:00 |
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:21 |
ockham_ | so don't i have to use dh_gencontrol for pysol (not pysolfc)? | 19:22 |
tumbleweed | ockham_: yes | 19:29 |
ockham_ | tumbleweed: and what about breaks/replaces/conflicts? | 19:30 |
tumbleweed | ockham_: Breaks + Replaces, yes | 19:33 |
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:36 |
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:37 |
mneptok | amen | 19:38 |
mneptok | do NOT encrypt my data without my permission. it's mine. i'll decide. | 19:38 |
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:39 |
mneptok | alt-F2 is not getting me an alternate TTY | 19:42 |
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:44 |
mneptok | penguin42: not really. Debian is fairly predictable. >:) | 19:45 |
mneptok | it's very clear that the existing $HOME was encyoted without permission | 19:46 |
mneptok | YAY! GRUB menu at last! | 19:47 |
penguin42 | mneptok: Might be worth checking the logs from the installer - they should be somewhere | 19:47 |
mneptok | the only thing left in this user's $HOME is "Access-Your-Private-Data.desktop" and "README.txt" | 19:50 |
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:51 |
mneptok | is there an easy way to reverse this encryption? | 19:53 |
mneptok | kirkland: hjalp? | 19:58 |
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 | 19:59 |
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:00 |
* 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:02 |
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:03 |
mneptok | brb. need USB key | 20:04 |
mneptok | cjwatson: http://birdhouse.org/~mnep/cjwatson | 20:10 |
mneptok | bleh. fixing perms | 20:10 |
mneptok | fixed. | 20:11 |
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:13 |
cjwatson | IRC scrollback suggests my bad, in fact ;-) | 20:14 |
mneptok | cjwatson: but i should have interpreted it | 20:15 |
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:16 |
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:17 |
=== micahg_ is now known as micahg | ||
mneptok | cjwatson: grah. fixed. | 20:18 |
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:19 |
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:20 |
mneptok | cjwatson: second | 20:21 |
cjwatson | do logs from the first exist? | 20:21 |
mneptok | cjwatson: sadly, no | 20:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
cjwatson | I just can't find any other way this could have arisen | 20:28 |
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:29 |
mneptok | OK, i'll try it | 20:30 |
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:31 |
mneptok | cjwatson: installing ecryptfs-utils allowed me to login | 20:33 |
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:34 | |
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:36 |
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:37 |
cjwatson | though my hypothesis about the original cause is probably unprovable either way at this point | 20:38 |
mneptok | cjwatson: i would always cover my tracks sufficiently to ensure PEBKAC can only be a theory ;) | 20:44 |
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:50 |
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 | :) | 20:57 |
broder | could i get somebody to accept the sru nominations for bug #629646? | 21:03 |
ubottu | 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:03 |
tumbleweed | broder: doing it | 21:06 |
broder | thanks | 21:06 |
=== tkamppeter_ is now known as tkamppeter | ||
ockham_ | cjwatson: about pysolfc... ^^^ | 21:38 |
ockham_ | cjwatson: can you take a look at the log? | 21:40 |
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:01 |
tumbleweed | ockham_: sorry, can't be any more help without the source | 22:02 |
ockham_ | tumbleweed: one moment... | 22:03 |
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:05 |
ockham_ | ok, i'll just do it... | 22:11 |
=== EvilJackyAlcine is now known as JackyAlcine | ||
=== Guest89395 is now known as Zic |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!