[00:36] smoser: I guess bug #567392 is the one causing you eucalyptus problems? how fast does libvirtd run out of fds? [00:36] Launchpad bug 567392 in libvirt "__virExec:362 : cannot create pipe: Too many open files" [High,In progress] https://launchpad.net/bugs/567392 [00:36] ttx: ^^ kirkland asked this fix to be considered for RC; that means respins of ubuntu-server, and ubuntu and kubuntu DVDs [00:38] slangasek, well, its not the only thing. [00:38] but it leaks 1 per start/stop [00:38] so 1000 instances ends up hitting the default fd limit [00:39] (of 1024) [00:39] and are users are going to go through 1000 instances between the time it takes us to release RC and the time it takes us to push the fixed libvirt for final? [00:41] slangasek: the canonical UEC instance probably will [00:44] slangasek, i think probably not. [00:44] slangasek, its also extremely easy to fix [00:45] if you just 'sudo restart libvirt-bin' on the node controllers [00:45] the limit is per-node-controller, yes? [00:46] right [00:46] thats why dustin (with 3) or the UEC in our data center (with a more than that) never saw it, but i did with my measly 1 node controller [00:46] lifeless: ^^ 1000 instances on a single NC, in 2 days? [00:48] my guess is that number would be high for a single phsyical node even on amazon. [00:48] to me its unrealistic other than testing [00:48] slangasek: well, the dx hudson does lots of fairly short builds, and its only one user. I may be being alarmist. [00:51] lifeless: ok; I still think we're better off just pushing it immediately post-RC, rather than eating up another 10 tester-hours of time to revalidate [00:52] slangasek: works for me; was just adding data. [00:52] lifeless: appreciated :) === blueyed_ is now known as blueyed [01:17] directhex: should I be expecting to see that indicator-application upload in the freeze queue? [01:20] slangasek, someone else uploaded it, whereupon it built but failed to upload [01:20] Subject: [Build #1699116] i386 build of indicator-application 0.0.19-0ubuntu4 in ubuntu lucid RELEASE (directhex PPA) [01:20] Date: 19/04/10 13:12:58 [01:20] directhex: eh, I meant to the Lucid archive, not to a PPA [01:21] was that a PPA upload? i must've gotten confused [01:21] it says PPA in the subject, so I assume so :) [01:21] ah, so it was. serves me right for not naming PPA uploads with a ppa version number [01:21] so "oops" [01:21] i'll upload now [01:22] cheers :) [01:28] dputted [01:28] now i should go to bed [01:28] Keybuk: bug #507881> what changed your mind about a blacklist of /proc/bus/usb in mountall being viable? [01:28] Launchpad bug 507881 in plymouth "Plymouth doesn't show messages sent before the splash screen is visible" [High,Fix committed] https://launchpad.net/bugs/507881 [01:35] Rejected: [01:35] Signer is not permitted to upload to the component 'main'. [01:35] slangasek, ^^ [01:43] anyway, bed [01:50] directhex: ah; put it somewhere for sponsorship? [01:51] hopefully it's the one in his PPA now [02:00] ajmitch: hmm; probably, but I'm not going to guess - it can wait till he's back [02:03] slangasek, seems like you might know this ... [02:03] is there a way we can get a list of "stuff" in Ubuntu that uses /usr/lib/libglitz-glx.so.1 [02:03] ? [02:04] rickspencer3_: apt-cache rdepends libglitz-glx1 [02:04] thanks slangasek [02:05] rickspencer3_: that works because /usr/lib/libglitz-glx.so.1 is shipped in the aptly-named libglitz-glx1 package; if it had been in a package with other libraries, acquiring a precise count would be more involved [02:08] Do we have any kind of policy that suggests one should replace Vcs-foo fields in debian/control with XS-Debian-Vcs-foo fields? [02:09] I'm not aware of a policy [02:09] I'm wondering because the topgit upload in the queue has such a change. [02:10] It seems to me something we shouldn't just randomly do. [02:10] I think it's good /practice/ to move the fields aside when they don't point at something corresponding to the package in question [02:10] Corresponding exactly or generally? [02:10] but since there's no policy on the name to change it to, and practice has varied, I always fail to do it myself [02:10] ScottK: exactly, IMHO [02:11] OK. [02:11] if I can't find the current package revision in the referenced Vcs-*, the field shouldn't be there [02:11] Perhaps then update-maintainer should also remove such fields. [02:12] it's something that's happened for awhile on some packages [02:12] I think that would be good [02:12] * ScottK makes a bug. [02:12] it won't have the desired result for Vcs-Git if Debian and Ubuntu share a git repository, but the Vcs-Git fields are inappropriately underspecified anyway [02:12] I suspect it's done from a desire that 'apt-get source' not give the wrong information [02:13] Seems like overkill for minor deviations to me, but OK. [02:16] well, I'd like it to be automatable via update-maintainer, and in the absence of such automation haven't been doing it :) [02:16] Bug filed. [02:17] Maybe someone will feel inspired. [02:17] Making it point to the proper ubuntu branch could be done [02:18] e.g. Vcs-Bzr: http://code.launchpad.net/ubuntu/+source/apache2 [02:21] requestsync isn't liking me today, is the job that updates the version of debian packages in LP having a bad day? [02:23] Doesn't requestsync use rmadison? [02:24] I didn't check what it uses for looking up the version of packages in sid [02:25] it's just a new debian revision of gpt that I want synced to fix a FTBFS, nothing major [02:27] looks like it does use the information on LP for the version (which is out-of-date) [02:31] Nice. [02:32] I should just create the bug the old-fashioned way, I tested that it built [02:43] ajmitch: unless devs are explicitly committing to the ubuntu bzr branch, I don't think it makes sense to tag it in debian/control; debcheckout et al could just be modified to look there by default [02:58] slangasek: huh? [02:58] I've never thought a blacklist of usbfs is viable [02:58] I think that's stupid [02:59] adding any workaround just for that means we're basically working around bad advice given on ubuntu forums [02:59] and that sets a dangerous precedence :P [03:02] Keybuk, I just got e2defrag working with extents ;) [03:03] Keybuk, also I was looking at the ureadhead code today... I need to go test it now because I decided to try converting the hda readahead to multithread like ssd.. that should put a stop to that big block of zero IO during all the sequential open() calls [03:04] oh, interesting [03:04] would love to see the before/after blktrace of that! [03:05] well, combined with defrag it should be one gigantic sequential read ;) [03:06] even with the threads sending down requests a bit out of order, they should get combined and ordered in the queue by the elevator [03:07] and if a thread has to block waiting on a directory or indirect block read, the others can queue up a few more reads to be batched [03:54] slangasek: i concur that that upload can be pushed post RC [03:54] slangasek: basically ttx and I decided to leave that one in the hands of the release team [03:54] slangasek: as such, it was only a "proposal" for RC inclusion [03:59] How odd. When trying to stream mpegs with Firefox and libtotem-cone-plugin.so I get the codecs needed dialogue and then when I click search for codecs it tries searching for the "text/html" codec, lol. [04:00] Probably not included due to patents. [04:00] ;-) [04:39] slangasek, hello [05:32] Keybuk: oh; well, you certainly were /discussing/ a blacklist of usbfs, apparently I misunderstood your position on it. I guess that brings me back to my assertion that blocking virtual-filesystems on unknown nodev mounts doesn't make sense [05:33] kirkland: hmm, but you marked it for -updates; I was thinking we would still want to grab that in post-RC, no? [05:33] (between RC and final) [05:33] slangasek: if that were acceptable, yes [05:34] slangasek: i assumed we wanted to keep as much unchanged as possible between RC and GA [05:34] slangasek: so i started prepping these as SRUs [05:34] we do, but that seems like a case where the risks and rewards are well scoped [05:34] slangasek: libvirt -- yes, i think so; very clear fix, IMHO [05:36] slangasek: in this case, shall I re-target at 10.04? [05:36] kirkland: yes, please [05:36] slangasek: cheers [05:45] slangasek: I can't remember why it does [05:45] mountall needs a test suite [05:46] because apparently I didn't add that line of code [05:46] ion did ;) [05:47] ah [05:47] ion: ping [05:48] I think it's more that it's a creeping thing [05:48] it was added to avoid filesystem checks [05:48] and crept up to mean more as the code changed [05:48] What did i break? :-P [05:48] oh, nothing [05:49] was just trying to work out why "none" in the device column makes a filesystem hold up "virtual-filesystems" [05:50] ion: right, ^^ that - since any problem with such an fstab entry means you can never boot, because of a circular dep between plymouth-splash up to skip the broken fs, and virtual-filesystems [05:51] but yeah [05:51] looks like it just crept up the code [05:51] it'll probably break something to remove it of course [05:51] but it's that kind of code [05:53] Keybuk: can you think of any specific bugs you would expect us to need to guard against if changing that, or is it just general nervousness about a late change? [05:53] nervousness [05:53] though the worst that should happen is that anything with "none" as a device becomes local [05:53] so it just means it won't hold up virtual-filesystems [05:54] and appear on plymouth [05:54] so it's probably ok [05:54] I think there are few possible bugs that would both escape notice during testing *and* be worse than a boot hang that can only be resolved with init=/bin/sh [05:54] but I keep saying that [05:54] and the world burns [05:54] last time I patched mountall, Iceland exploded [05:55] oh, I thought Iceland exploded as a pre-consequence of you and jiboumans inventing teleportation to get home [05:57] I did a tech talk on Monday [05:57] pfft, that volcano has nothing on jono after eating white castle [05:57] I started off with "thankyou for inviting me to be here, and thank you for setting off a Volcano in Iceland to make sure I could do it" [05:58] (tech talk at Google) [05:58] heh [06:02] slangasek: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mountall/lucid/revision/320 [06:02] knock yourself out [06:02] if the world burns, I'll deny all knowledge and claim you forged the commit message to make it look like it came from me [06:03] right :) [06:03] irc logs are like cockroaches though, they will survive [06:03] still need to fix the plymouth flush code so we can do that final mountall upload [06:04] nixternal: those can be edited [06:04] the only thing I can't do is get home [06:04] that would be a lot of editing though.... [06:04] * nixternal locks down rsh and ssh [06:04] can't edit mine! [06:04] hahahahaha [06:04] i can edit your logs, i just can't get home! [06:04] nixternal: Don't say that to the guy that writes your boot loader [06:05] nixternal: init --version [06:05] see where it says "Written by" ? :) [06:05] * slangasek grins [06:05] doesn't say Written by anywhere [06:05] so foo on you :D [06:05] Keybuk: btw, bug #567592 doesn't look very nice; I thought this was fixed in mountall 2.13 [06:05] Launchpad bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New] https://launchpad.net/bugs/567592 [06:06] slangasek: that's fixed [06:06] a [06:06] oops [06:07] Keybuk: hggdh reports it with a uec image that has mountall 2.13 in it [06:07] keybuk: The r87 commit message says ‘don’t queue filesystem check when device is "none"’ but the code checks whether type is "none". My r100 actually adds the line to make the change r87 appears to have intended. I can’t seem to remember what specific case of device being "none" caused a problem. [06:07] yeah [06:07] slangasek: Keybuk: that was today's image [06:07] but I reckon that log is "conveniently edited" [06:07] where today = yesterday now [06:07] ion: yeah, I just propogated that behaviour up [06:07] latest at the time, anyway [06:07] I would expect that it's *failed* to mount / [06:08] e.g. mount or fsck returned an error [06:08] rather than got bored [06:09] mmk [06:09] the bit at the end of the comment implies that [06:09] in that case, it has to either skip or start a shell [06:10] it doesn't start a shell, since then it might overlap with X or getty or stuff [06:10] Keybuk: at the end of which comment? [06:10] #3 [06:11] "and mountall refused to mount / (more correctly, refused to remount it rw)." [06:11] well, that's just a restatement of the log line: | mountall: Skipping mounting / since Plymouth is not available [06:11] that to me sounds more like Scott is trying to tell us mount failed, not mountall didn't try [06:11] yes, but what I mean is that there's mount errors missing here [06:11] --debug might be telling (since it will tell us the exit codes) [06:11] but I'm pretty convinced this is a case where mount -o remount,rw / has failed [06:11] not a case of mountall got bored [06:12] ok [06:12] nothing mountall can do there ;) [06:12] that's why we have plymouth - to ask the user [06:12] going to be nontrivial to confirm that this is the case, I guess [06:12] --debug should prove it [06:12] it's non-trivial to edit an upstart job to set --debug in the UEC image [06:13] they should make that trivial ;-) [06:13] heh === ara_ is now known as ara === ara is now known as Guest45645 === Guest45645 is now known as ara_ === ara_ is now known as ara === radoe_ is now known as radoe [08:14] mvo: morning [08:14] hi [08:15] mvo: I signed up to the software-center+pkgcon sprint on UDS [08:15] I'm looking forward to that :-) [08:18] Good morning [08:21] good morning [08:24] good morning [08:25] hey dholbach [08:25] hey mvo [08:30] slangasek: have you had a chance to look at bug 563618? [08:30] Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618 [08:37] amitk: no; that's going to have to be post-rc, regardless [08:37] amitk: and I'm still trying to fight my way up through the stack of plymouth/mountall bugs [08:42] slangasek: ack, thanks. [08:52] Keybuk: so, that change seems to make mountall fail at mounting /tmp [08:53] What would be a good place to find someone knowledgeable about empathy to ask the meaning of some strings? [08:55] slangasek, about the vboxsf issue, it might affect other packages providing filesystems support via kernel modules, maybe a warning message should be sent ? [08:56] joaopinto: a warning message where to whom? The vboxsf init script was clearly buggy anyway, even before mountall it would be running way later than the mount scripts [08:59] slangasek, to -motu or something like that :) I assuming there are other packages providing such modules, which were working on karmic's boot order and will fail now [09:03] joaopinto: frankly, if there are other packages like that (and I don't know why there would be), either the people who care about them have already noticed or there are no people that care about them so I wouldn't expect broadcasting to the developers to have any effect [09:04] ok :\ [09:15] Testing Alternate CD for PowerPC (2010-04-19), installer reports failure during "Install and Setup software" but I can find no mention of errors in the logs, and running the next step (install yaboot) continues on without apparent problems (so far). Are there any logs I should capture to investigate this in either the chroot /target or the installer ? [09:17] /var/log/syslog (outside the chroot) is often interesting [09:17] Thanks, I'll save that into the /target/ to look at later [09:18] I'm just testing a boot from the installed system now, to find out if anything did mess up [09:18] IntuitiveNipple: There's a "Save Debug information" option from the main menu, which will save all the files you need. [09:18] Oh yeah! thanks for reminding me :) [09:19] Keybuk: hmm - this code already special cases fuse mounts? === almaisan-away is now known as al-maisan [09:21] persia: OK, looking at the running installed system, it looks as if the failed step was where the choice of meta flavour (ubuntu-desktop, etc.) should have been offered. The installed system only has ubuntu-minimal. Nothing in the logs to give a clue though. I'll repeat the install to see if it is reproducible, and report a bug if so. [09:32] hi [09:33] my PPA seems be locked. all build failed by uploading failed [09:33] Here is one build. https://launchpad.net/~shawn-p-huang/+archive/ppa/+build/1701077 [09:33] anyone can help me? [09:34] phuang, Not here. Go to #launchpad for help with PPAs. [09:34] cody-somerville, thanks [09:43] wgrant: HAPPY BIRTHDAY! :) [09:43] dholbach: Thanks! [09:44] slangasek, i uploaded the final indicator-application package to one of my PPAs, but i'm getting more "failed to upload"s following successful builds - "Lockfile /var/lock/process-upload-buildd.lock in use" [09:45] directhex: That should be OK now. [09:45] directhex: When did it fail? [09:45] LP had a couple of crises over the past hour or so. [09:45] wgrant, few minutes ago [09:45] 2010-04-21 08:37:29 DEBUG Lockfile /var/lock/process-upload-buildd.lock in use [09:45] Hmmmmm. Concerning. [09:46] Build #1701095 and #1701096 [09:46] happy birthday wgrant [09:47] directhex: Which PPA? Build IDs are only useful if I also know the archive. [09:47] Thanks james_w. [09:48] samarium and iridium for 96 [09:48] osmium for 95 [09:54] directhex: should be OK now. [09:54] Cascading failures FTW. [09:55] wgrant, can you rescore the builds? [09:55] Keybuk: ok, /tmp sorted - needed to poke a bit so the placeholder handling code was still happy [09:57] directhex: I have no privileges beyond MOTU. [09:57] So, no. [09:58] boo [09:58] i386 build seems to be happening now anyway [10:26] hi! I have python-specific packaging question [10:27] free: Which one? [10:28] I have a package whose postinst depends on python-pycurl, and that fails when upgrading from hardy to lucid because the python-pycurl package in hardy is compiled against Python 2.4 and APT decide to upgrade it *after* my package [10:28] persia: ^^^ [10:28] so one solution would be to explicitely depend on a specific python version like Depends: python2.6-pycurl [10:28] Or depend on python-pycurl (> (Hardy's version)) [10:28] but having a lot of python dependencies that seem a bit sub-optimal, I was wondering if there is a better alternative [10:29] * persia likes StevenK's suggestion [10:29] StevenK, persia: yeah, the only thing is that I have to do that manually for all my python dependencies [10:29] and maintain that [10:29] The other option is to adjust the maintainer script to work also with python2.4-pycurl [10:31] StevenK, persia: I see, I think I'll eat the bullet and go for versions thanks! [10:40] free: isn't that exactly what Pre-Depends is for? [10:40] no, it is not [10:40] Chipzz: you Pre-Depends if you need a package to be fully installed and configured even before APT tries to unpack your package [10:41] I think Bob the Angry Flower needs to get his gimp on and speak out about Pre-Depends [10:41] use a trigger! [10:48] free: does the package depend on python-pycurl at all currently? [10:49] james_w: it does [10:49] james_w: more details on bug #563063 [10:49] Launchpad bug 563063 in landscape-client "Problem with pycurl dependency during upgrade from hardy to lucid" [High,In progress] https://launchpad.net/bugs/563063 [10:53] free: I don't have that call in my copy of the postinst, is it not in the lucid package yet? [10:55] james_w: it is, but that is kicked in EC2 instances when starting the service from the postinst script [12:00] pitti, slangasek: any opinions on bug #567699 and #567690 ? [12:00] Launchpad bug 567699 in nvidia-graphics-drivers "Ensure nvidia package works in future for PAE kernel installs" [Undecided,New] https://launchpad.net/bugs/567699 [12:00] Launchpad bug 567690 in fglrx-installer "Ensure fglrx package work in future for PAE kernel installs" [Undecided,New] https://launchpad.net/bugs/567690 [12:05] tseliot: hm, getting the right kernel headers indeed has always been a problem; I just don't understand why adding another alternative makes any difference here? [12:05] tseliot: If you7re doing that, could you consider all the *other* available flavours? [12:05] doesn't linux-headers-generic-pae provide linux-headers? [12:05] persia: that's my point [12:05] pitti: yes, I think it does [12:06] * tseliot doubts that there's a way to get this right [12:06] There isn't a way to get it right. [12:07] The closest would be to catch when the available headers and the running kernel differ, and offer to install the matching headers for the user. [12:07] (this is also true for all dkms-based packages) [12:07] can you add some comments in the bug report, please? [12:12] then I don't really understand how that could help in the slightest [12:12] tseliot: no, there isn't; we can't express "we need the same kernel header flavour as the installed kernel" in dependencies [12:12] we could only check that in dkms/jockey at most [12:12] *nod* [12:12] tseliot: commented; I guess we should duplicate the bugs and reassign to jockey/dkms [12:12] bah, except that LP times out on me [12:12] ah, it's my backup rsync run of doom, which makes my internet connection useless [12:12] pitti: thanks [12:13] (comment went through now) [12:13] persia, pitti: thanks for your comments [12:15] short question: how do you tell upstart to boot to runlevel 3? [12:16] (from grub if possible) === MacSlow is now known as MacSlow|lunch [12:21] yofel, guessing from reading /etc/init.d/rc-sysinit.conf, you can use the runlevel number on the linux kernel line [12:22] ops, init, not init.d [12:22] ah, thanks for finding that [12:26] yofel: you know runlevel 3 isn't what it means on RH-based systems, right? [12:27] yofel: on Debian-based systems, runlevels 2, 3, 4, and 5 are identical by default, and left to the sysadmin to customise; in particular runlevel 3 does not mean "boot without graphics" by default [12:27] cjwatson: I know, but I wanted to test something later and couldn't find if that's still possible [12:28] ok, it's just a common confusion so I thought I'd mention it [12:31] slangasek: hm, I think I need a second opinion about bug 566046 [12:31] Launchpad bug 566046 in gnome-keyring "the login password is stored in the user's keyring" [High,In progress] https://launchpad.net/bugs/566046 [12:32] slangasek: I now have a patch which stops adding the user's password to the keyring, and removes it on upgrade as well; but it potentially breaks this "user.keystore" feature (which I haven't found out how to use it at all) [12:33] slangasek: so the question is whether we put it into lucid final to stop spreading cleartext passwords and sort out the possible breakage later in SRU, or whether we do one big and upstream approved fix later on in -updates [12:33] slangasek: upstream didn't respond at all yet, and at this point I need his input [12:34] pitti: is the password stored encrypted or decrypted on disk? [12:34] I tested it thoroughly on new users, existing users with and without the password, and normal keyring operations (passwords for empathy accounts, and the like) [12:35] slangasek: encrypted [12:35] slangasek: but since the keyring gets unlocked during login, every process can retrieve the cleartext through g-keyring [12:35] * slangasek nods [12:36] but in practice that's only a problem if you have a malicious process running as the user, right? [12:36] it's not _such_ a big deal, given that every other password for your web accounts, wifi networks, etc. can also be gotten from the keyring c [12:36] but the security team seems to be quite eager about it [12:36] slangasek: correct [12:36] if the user isn't logged in, there's no way to get the passphrase [12:36] pitti: then I think I would prefer SRU [12:37] slangasek: ok, my feeling as well, thanks; I'll get an ack from security team for this, too [12:38] Keybuk: bug 554009 seems to be a regression from your wait-for-root work [12:38] Launchpad bug 554009 in initramfs-tools "Resume from disk (swapfile) fails" [Medium,Triaged] https://launchpad.net/bugs/554009 [13:26] I'm creating a Ubuntu package and I am currently using .install files to copy some files on install. There is one file though that I ONLY want to install if it doesn't exist (otherwise, just leave the original file be), can someone point me in the right direction to do this? [13:27] (sorry if this is the wrong channel, redirect me elsewhere if possible) [13:27] simmel: erm - you mean, only if it doesn't exist on the user's system when they come to install the .deb? [13:27] simmel: Adding a conditional to debian/rules is likely easiest ([ ! -f foo ] && install -m ...) [13:28] simmel: if so that sounds like an odd requirement. Could you go into specifics? [13:30] cjwatson: No, only install one of the files in the package if the files doesn't exist. [13:31] simmel: At package creation time, or at package install time? [13:31] doesn't exist where? [13:31] specifics would help if you can :) [13:31] persia: Ok, but then I would have to remove it too when the package is uninstalled, right? package install time. [13:31] isn't that what I said, and you said no? [13:31] simmel: Why do you want to do this? Which file? [13:32] the reason we're asking these questions is that there are various possibilities and the best one depends on why you're trying to do this. [13:33] It's a post-install configuration file. For host specific configurations that that is applied to configurations of certain applications (think: user/passord/server to connect to) [13:33] make it a conffile, then? [13:33] Or don't ship it, and then create it in the postinst (e.g. postfix main.cf) [13:34] if it's a conffile, dpkg will prompt the user if there's a conflict. if you don't want that (although consider the consequences of your configuration file never being upgraded unless you go to some effort ...), then creating it in the postinst would work [13:37] interesting. postfix {main,master}.cf aren't registered as conffiles... something tells me I should fix that [13:37] Is the conffiles like package-name.install? [13:37] I mean, do they behave in the same way? [13:37] just wondering; isn't #ubuntu-motu normally used for packaging questions? [13:37] lamont: Should main.cf be a conffile? Depending on what one does with the postinst, it may never be generated (No Configuation). [13:38] persia: if generated, it should confess [13:38] cjwatson: Can I somehow in the package specify that dpkg never should prompt? (like always use the one that the user already has or such) [13:38] Chipzz: The answering of packaging questions was distributed to all development teams as part of Archive Reorganisation. #ubuntu-packaging exists as a catch-all for random packaging that any team doesn't want to support (e.g. PPA work, work on derivatives, etc.) [13:39] oh, when did that happen? [13:39] Early February or so. [13:40] I recall users being redirected to #ubuntu-motu up to a couple of months ago [13:40] Yeah, that matches my timeframes :) [13:40] s/users/packaging questions/ [13:43] Chipzz: motu meaning what? [13:43] simmel: conffiles is just a way of marking certain configuration. If you install stuff to /etc it gests marked as conffiles by default. There's no way short of maintainer scripts to never bother the user. If it's host specific data, I'd recommending finding a formal you know will work for all eternity, and then separating that from the rest of the configuration, to ease updates of the non-host-specific configuration. === MacSlow|lunch is now known as MacSlow [13:46] persia: It is seperated (in a seperate file and folder atleast). [13:48] Thank you persia and cjwatson for your time and answers. I will take this information up with my colleges and chose which one of the two suggested solutions we will take. Next time I will ask in #ubuntu-packaging [13:49] err, choose [13:49] Then create it in postinst based on user's answers to questions *OR* ship an empty config as a conffile and detail how to add to it in a README (depending on the risks/implications of having it just run with the install-time supplied credentials) [13:50] (or even, ship an empty config as conffile and modify it in postinst) === ogra_ is now known as ogra === DrPepperKid is now known as MacSlow === sconklin-gone is now known as sconklin [14:23] pitti: take a look at bug #567879 [14:23] Launchpad bug 567879 in gnome-keyring "gnome-keyring no longer enforces application permissions" [Undecided,New] https://launchpad.net/bugs/567879 [14:31] urg, the new gnome-keyring is a fail, we should have stayed away from it for lucid [14:32] sad face [14:36] pitti: actually, never mind, I just closed the bug. [14:38] mdeslaur, was that the prompt which was judged confusing rather than useful and dropped upstream due to that? [14:39] seb128: well, the security value of it was doubtful, and I kind of agree now. [14:40] seb128: is Stef Walter the only upstream on gnome-keyring? [14:40] right, this was totally worthless [14:40] any application could have faked such a dialog [14:40] mdeslaur, yes [14:40] it was worthless as gnome-keyring should probably be a root process and access granted with policykit, etc. [14:40] mdeslaur, I've been mailing "flooding" him for 1.5 months now [14:41] he got a baby like 2 months ago and doesn't have too much hacking time atm, he sent an email before that saying he would probably not read all bugzilla traffict but to contact him by email for issues that need to be looked at [14:42] seb128: so, no chance of meeting with him at UDS? :P [14:42] he has been looking at the bugs I mentioned via email but not on a very responsive timeline [14:42] once we know what this user.keystore is for, I think we can just upload the patch that we have [14:42] mdeslaur, I doubt it [14:42] pitti: I was under the impression it was the pkcs11 cert store, but I may be mistaken [14:56] seb128, heh, i'm back to stuttering ... [14:56] ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects|grep "object bytes" [14:56] -169566208 object bytes [14:56] fun [14:56] so RAOF was apparently right with his assumption [14:57] ogra: right, read #ubuntu-desktop discussion [15:02] * zyga has a company now, woot :-) [15:04] zyga: oh, congrats! building a new empire? :-) [15:07] Keybuk, http://pastebin.com/NVWXUS7Y, any idea why /lap is never attempted to be mounted ? [15:08] joaopinto: run mountall --debug? [15:09] joaopinto: and according to the last line, all filesystems *were* mounted [15:09] slangasek, because he opened an hacked tty and did the manual mount :) [15:10] joaopinto: the 'manual intervention here' is shown three lines after the last mountall message [15:11] ops, right, it was after mountall after all [15:11] joaopinto: anyway, if something didn't mount right, we'll need mountall --debug to sift through [15:11] ok, I am trying to convince him to open a bug report :P [15:12] joaopinto: bug #567910? [15:12] Launchpad bug 567910 in mountall "filesystem not getting mounted" [Undecided,New] https://launchpad.net/bugs/567910 [15:12] ugh, "nodev"? [15:12] oh, great :) [15:13]