[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...


[01:06] <josharenson> robert_ancell: Hey, I updated the bug with the results of changing the seat type to unity
[01:06] <robert_ancell> josharenson, thanks
[12:57] <dandrader> dednick, I think you forgot https://code.launchpad.net/~dandrader/qtmir/fixFirstChangedOnPrepend/+merge/296313
[13:44] <dednick>  dandrader: done. although i now noticed there is "emptyChanged" missing in the mock.
[13:44] <dandrader> dednick, this property exists only in qtmir I htink
[13:45] <dednick> dandrader: ah. k
[13:45] <dednick> dandrader: confirmed
[14:24] <josharenson> kgunn: Do you want be to backport the fix for https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1435923 ? Its a 2 liner and I only made it dependent on the existing greeter branches as motivation to land them
[14:24]  * josharenson has been working with robert_ancell lately to get them landed as well
[14:25] <kgunn> josharenson: yeah, if it's easy enough
[14:26] <kgunn> it is annoying...when i saw popey's bug that got duped, i was reminded how annoying it was
[14:26] <popey> :)
[14:26] <popey> sorry
[14:26] <kgunn> not at all...it is annoying :)
[14:26] <josharenson> kgunn: I don't want to annoy people :-p
[14:26] <popey> \o/
[14:27] <popey> Minimum level of development: Don't annoy people. I like it.
[14:27] <kgunn> josharenson: and popey will buy you an adult frosted malted beverage
[14:27] <popey> \o/
[14:27] <josharenson> kgunn: oooOOooOoo
[14:27]  * kgunn wonders if we put beer-bounties on bugs how fast things would get fixed
[14:28] <josharenson> its an interesting idea
[14:29] <mterry> josharenson, you never replied to my review comment.  :)  We could have landed that a long time ago
[14:29] <josharenson> mterry: I also thought the other branches would land a long time ago :-/
[14:29] <josharenson> sorry
[14:29] <mterry> josharenson, yeah  :(
[14:30] <mterry> josharenson, last I remember, the other ones were going through some fix ups, and they weren't ready for me to review again, correct?
[14:30] <josharenson> mterry: yeah wait till robert and I get everything sorted out w/ USC
[14:30] <josharenson> mterry: I will let you know when they are ready
[14:31] <mterry> josharenson, cool cool
[14:31] <mterry> josharenson, surprisingly hard to land these branches
[14:32] <mterry> josharenson, robert_ancell is working on in-session lightdm, which should in theory let us drop our IntegratedLightDM stuff and always use liblightdm
[14:32] <josharenson> mterry: oh cool
[14:32] <mterry> josharenson, that will let us drop a couple layers of abstraction  :P


[00:24] <valorie> fenris[m]: ^^^ - coordinate with Eickmeyer if possible
 i don't have permission 😏 : https://irc-attachments.kde.org/1625a630/Screenshot_from_2023_08_04_12_28_07.png
 happened on edge but not firefox
 is this problem resolved? (re @IrcsomeBot: <santa_> - you access this samba share with kio, which would have an smb:// url)
 not working in dolphin but working in nautilus : https://irc-attachments.kde.org/957d989d/image_2023_08_04_19_18_18.png
[11:45] <BluesKaj> Hi all
[20:26] <valorie> hmmm, who set up the kubuntu-devel matrix room? and how to find out
[22:50] <Eickmeyer> valorie: We're going to have to hold-off on any plumbing for now. Per the global notice: The Matrix bridge is experiencing continued stability and privacy issues; we have requested it be shut down until they are resolved. Matrix have agreed to shut down the bridge no later than 1400UTC on Saturday. Feel free to ask further questions in
[22:50] <Eickmeyer> #libera-matrix.
[22:51] <valorie> got it
[22:51] <Eickmeyer> valorie: #kubuntu-devel:matrix.org doesn't exist, so nobody?
[22:52] <valorie> maybe by then we'll figure out who owns the existing kubuntu-devel room
[22:52] <Eickmeyer> (only matrix.org rooms can be plumbed)
[22:52] <valorie> did you see myfenris' image?
[22:52] <Eickmeyer> kde.org rooms cannot be plumbed unless Libera enables a bridge to do so.
[22:53] <valorie> aha
[22:53] <Eickmeyer> He's using the portalled room. That won't work.
[22:53] <Eickmeyer> Portalled rooms in Matrix are (in this case) #kubuntu-devel:libera.chat
[22:53] <valorie> ok - there is #kde-ops in IRC
[22:54] <valorie> and Kenny there will know much more than me
[22:54] <Eickmeyer> Yeah, they are plumbed but I don't know how, that's their business.
[22:54] <Eickmeyer> Pretty sure it's a matrix.org room bridged to kde.org.
[22:54] <Eickmeyer> OR...
[22:54] <Eickmeyer> Most likely it's the same room in kde.org set-up with alternate addresses.
[22:55] <valorie> ok, maybe we don't need to worrry
[22:55] <Eickmeyer> Not yet, at least, not until Libera reactivates the bridge after the outage staring at 1400 UTC Saturday (tomorrow).
[22:55] <Eickmeyer> s/staring/starting
[22:56] <Eickmeyer> But yeah, I'd just worry about the Kubuntu rooms for now, but not a huge priority as there's nothing to be done until the bridge comes back.