| slangasek | smoser: I guess bug #567392 is the one causing you eucalyptus problems? how fast does libvirtd run out of fds? | 00:36 |
|---|---|---|
| ubottu | Launchpad bug 567392 in libvirt "__virExec:362 : cannot create pipe: Too many open files" [High,In progress] https://launchpad.net/bugs/567392 | 00:36 |
| slangasek | ttx: ^^ kirkland asked this fix to be considered for RC; that means respins of ubuntu-server, and ubuntu and kubuntu DVDs | 00:36 |
| smoser | slangasek, well, its not the only thing. | 00:38 |
| smoser | but it leaks 1 per start/stop | 00:38 |
| smoser | so 1000 instances ends up hitting the default fd limit | 00:38 |
| smoser | (of 1024) | 00:39 |
| slangasek | 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:39 |
| lifeless | slangasek: the canonical UEC instance probably will | 00:41 |
| smoser | slangasek, i think probably not. | 00:44 |
| smoser | slangasek, its also extremely easy to fix | 00:44 |
| smoser | if you just 'sudo restart libvirt-bin' on the node controllers | 00:45 |
| slangasek | the limit is per-node-controller, yes? | 00:45 |
| smoser | right | 00:46 |
| smoser | 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 |
| slangasek | lifeless: ^^ 1000 instances on a single NC, in 2 days? | 00:46 |
| smoser | my guess is that number would be high for a single phsyical node even on amazon. | 00:48 |
| smoser | to me its unrealistic other than testing | 00:48 |
| lifeless | slangasek: well, the dx hudson does lots of fairly short builds, and its only one user. I may be being alarmist. | 00:48 |
| slangasek | 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:51 |
| lifeless | slangasek: works for me; was just adding data. | 00:52 |
| slangasek | lifeless: appreciated :) | 00:52 |
| === blueyed_ is now known as blueyed | ||
| slangasek | directhex: should I be expecting to see that indicator-application upload in the freeze queue? | 01:17 |
| directhex | slangasek, someone else uploaded it, whereupon it built but failed to upload | 01:20 |
| directhex | Subject: [Build #1699116] i386 build of indicator-application 0.0.19-0ubuntu4 in ubuntu lucid RELEASE (directhex PPA) | 01:20 |
| directhex | Date: 19/04/10 13:12:58 | 01:20 |
| slangasek | directhex: eh, I meant to the Lucid archive, not to a PPA | 01:20 |
| directhex | was that a PPA upload? i must've gotten confused | 01:21 |
| slangasek | it says PPA in the subject, so I assume so :) | 01:21 |
| directhex | ah, so it was. serves me right for not naming PPA uploads with a ppa version number | 01:21 |
| directhex | so "oops" | 01:21 |
| directhex | i'll upload now | 01:21 |
| slangasek | cheers :) | 01:22 |
| directhex | dputted | 01:28 |
| directhex | now i should go to bed | 01:28 |
| slangasek | Keybuk: bug #507881> what changed your mind about a blacklist of /proc/bus/usb in mountall being viable? | 01:28 |
| ubottu | 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:28 |
| directhex | Rejected: | 01:35 |
| directhex | Signer is not permitted to upload to the component 'main'. | 01:35 |
| directhex | slangasek, ^^ | 01:35 |
| directhex | anyway, bed | 01:43 |
| slangasek | directhex: ah; put it somewhere for sponsorship? | 01:50 |
| ajmitch | hopefully it's the one in his PPA now | 01:51 |
| slangasek | ajmitch: hmm; probably, but I'm not going to guess - it can wait till he's back | 02:00 |
| rickspencer3_ | slangasek, seems like you might know this ... | 02:03 |
| rickspencer3_ | is there a way we can get a list of "stuff" in Ubuntu that uses /usr/lib/libglitz-glx.so.1 | 02:03 |
| rickspencer3_ | ? | 02:03 |
| slangasek | rickspencer3_: apt-cache rdepends libglitz-glx1 | 02:04 |
| rickspencer3_ | thanks slangasek | 02:04 |
| slangasek | 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:05 |
| ScottK | 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:08 |
| slangasek | I'm not aware of a policy | 02:09 |
| ScottK | I'm wondering because the topgit upload in the queue has such a change. | 02:09 |
| ScottK | It seems to me something we shouldn't just randomly do. | 02:10 |
| slangasek | 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 |
| ScottK | Corresponding exactly or generally? | 02:10 |
| slangasek | 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 |
| slangasek | ScottK: exactly, IMHO | 02:10 |
| ScottK | OK. | 02:11 |
| slangasek | if I can't find the current package revision in the referenced Vcs-*, the field shouldn't be there | 02:11 |
| ScottK | Perhaps then update-maintainer should also remove such fields. | 02:11 |
| ajmitch | it's something that's happened for awhile on some packages | 02:12 |
| slangasek | I think that would be good | 02:12 |
| * ScottK makes a bug. | 02:12 | |
| slangasek | 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 |
| ajmitch | I suspect it's done from a desire that 'apt-get source' not give the wrong information | 02:12 |
| ScottK | Seems like overkill for minor deviations to me, but OK. | 02:13 |
| slangasek | 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 |
| ScottK | Bug filed. | 02:16 |
| ScottK | Maybe someone will feel inspired. | 02:17 |
| ajmitch | Making it point to the proper ubuntu branch could be done | 02:17 |
| ajmitch | e.g. Vcs-Bzr: http://code.launchpad.net/ubuntu/+source/apache2 | 02:18 |
| ajmitch | requestsync isn't liking me today, is the job that updates the version of debian packages in LP having a bad day? | 02:21 |
| ScottK | Doesn't requestsync use rmadison? | 02:23 |
| ajmitch | I didn't check what it uses for looking up the version of packages in sid | 02:24 |
| ajmitch | it's just a new debian revision of gpt that I want synced to fix a FTBFS, nothing major | 02:25 |
| ajmitch | looks like it does use the information on LP for the version (which is out-of-date) | 02:27 |
| ScottK | Nice. | 02:31 |
| ajmitch | I should just create the bug the old-fashioned way, I tested that it built | 02:32 |
| slangasek | 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:43 |
| Keybuk | slangasek: huh? | 02:58 |
| Keybuk | I've never thought a blacklist of usbfs is viable | 02:58 |
| Keybuk | I think that's stupid | 02:58 |
| Keybuk | adding any workaround just for that means we're basically working around bad advice given on ubuntu forums | 02:59 |
| Keybuk | and that sets a dangerous precedence :P | 02:59 |
| psusi | Keybuk, I just got e2defrag working with extents ;) | 03:02 |
| psusi | 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:03 |
| Keybuk | oh, interesting | 03:04 |
| Keybuk | would love to see the before/after blktrace of that! | 03:04 |
| psusi | well, combined with defrag it should be one gigantic sequential read ;) | 03:05 |
| psusi | 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:06 |
| psusi | 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:07 |
| kirkland | slangasek: i concur that that upload can be pushed post RC | 03:54 |
| kirkland | slangasek: basically ttx and I decided to leave that one in the hands of the release team | 03:54 |
| kirkland | slangasek: as such, it was only a "proposal" for RC inclusion | 03:54 |
| cody-somerville | 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. | 03:59 |
| ScottK | Probably not included due to patents. | 04:00 |
| ScottK | ;-) | 04:00 |
| rickspencer3 | slangasek, hello | 04:39 |
| slangasek | 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:32 |
| slangasek | kirkland: hmm, but you marked it for -updates; I was thinking we would still want to grab that in post-RC, no? | 05:33 |
| slangasek | (between RC and final) | 05:33 |
| kirkland | slangasek: if that were acceptable, yes | 05:33 |
| kirkland | slangasek: i assumed we wanted to keep as much unchanged as possible between RC and GA | 05:34 |
| kirkland | slangasek: so i started prepping these as SRUs | 05:34 |
| slangasek | we do, but that seems like a case where the risks and rewards are well scoped | 05:34 |
| kirkland | slangasek: libvirt -- yes, i think so; very clear fix, IMHO | 05:34 |
| kirkland | slangasek: in this case, shall I re-target at 10.04? | 05:36 |
| slangasek | kirkland: yes, please | 05:36 |
| kirkland | slangasek: cheers | 05:36 |
| Keybuk | slangasek: I can't remember why it does | 05:45 |
| Keybuk | mountall needs a test suite | 05:45 |
| Keybuk | because apparently I didn't add that line of code | 05:46 |
| Keybuk | ion did ;) | 05:46 |
| slangasek | ah | 05:47 |
| slangasek | ion: ping | 05:47 |
| Keybuk | I think it's more that it's a creeping thing | 05:48 |
| Keybuk | it was added to avoid filesystem checks | 05:48 |
| Keybuk | and crept up to mean more as the code changed | 05:48 |
| ion | What did i break? :-P | 05:48 |
| Keybuk | oh, nothing | 05:48 |
| Keybuk | was just trying to work out why "none" in the device column makes a filesystem hold up "virtual-filesystems" | 05:49 |
| slangasek | 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:50 |
| Keybuk | but yeah | 05:51 |
| Keybuk | looks like it just crept up the code | 05:51 |
| Keybuk | it'll probably break something to remove it of course | 05:51 |
| Keybuk | but it's that kind of code | 05:51 |
| slangasek | 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 |
| Keybuk | nervousness | 05:53 |
| Keybuk | though the worst that should happen is that anything with "none" as a device becomes local | 05:53 |
| Keybuk | so it just means it won't hold up virtual-filesystems | 05:53 |
| Keybuk | and appear on plymouth | 05:54 |
| Keybuk | so it's probably ok | 05:54 |
| slangasek | 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 |
| Keybuk | but I keep saying that | 05:54 |
| Keybuk | and the world burns | 05:54 |
| Keybuk | last time I patched mountall, Iceland exploded | 05:54 |
| slangasek | oh, I thought Iceland exploded as a pre-consequence of you and jiboumans inventing teleportation to get home | 05:55 |
| Keybuk | I did a tech talk on Monday | 05:57 |
| nixternal | pfft, that volcano has nothing on jono after eating white castle | 05:57 |
| Keybuk | 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:57 |
| Keybuk | (tech talk at Google) | 05:58 |
| slangasek | heh | 05:58 |
| Keybuk | slangasek: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mountall/lucid/revision/320 | 06:02 |
| Keybuk | knock yourself out | 06:02 |
| Keybuk | 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:02 |
| slangasek | right :) | 06:03 |
| nixternal | irc logs are like cockroaches though, they will survive | 06:03 |
| slangasek | still need to fix the plymouth flush code so we can do that final mountall upload | 06:03 |
| Keybuk | nixternal: those can be edited | 06:04 |
| Keybuk | the only thing I can't do is get home | 06:04 |
| nixternal | that would be a lot of editing though.... | 06:04 |
| * nixternal locks down rsh and ssh | 06:04 | |
| nixternal | can't edit mine! | 06:04 |
| nixternal | hahahahaha | 06:04 |
| nixternal | i can edit your logs, i just can't get home! | 06:04 |
| ScottK | nixternal: Don't say that to the guy that writes your boot loader | 06:04 |
| Keybuk | nixternal: init --version | 06:05 |
| Keybuk | see where it says "Written by" ? :) | 06:05 |
| * slangasek grins | 06:05 | |
| nixternal | doesn't say Written by anywhere | 06:05 |
| nixternal | so foo on you :D | 06:05 |
| slangasek | Keybuk: btw, bug #567592 doesn't look very nice; I thought this was fixed in mountall 2.13 | 06:05 |
| ubottu | 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:05 |
| Keybuk | slangasek: that's fixed | 06:06 |
| lucas | a | 06:06 |
| lucas | oops | 06:06 |
| slangasek | Keybuk: hggdh reports it with a uec image that has mountall 2.13 in it | 06:07 |
| ion | 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 |
| Keybuk | yeah | 06:07 |
| kirkland | slangasek: Keybuk: that was today's image | 06:07 |
| Keybuk | but I reckon that log is "conveniently edited" | 06:07 |
| kirkland | where today = yesterday now | 06:07 |
| Keybuk | ion: yeah, I just propogated that behaviour up | 06:07 |
| kirkland | latest at the time, anyway | 06:07 |
| Keybuk | I would expect that it's *failed* to mount / | 06:07 |
| Keybuk | e.g. mount or fsck returned an error | 06:08 |
| Keybuk | rather than got bored | 06:08 |
| slangasek | mmk | 06:09 |
| Keybuk | the bit at the end of the comment implies that | 06:09 |
| Keybuk | in that case, it has to either skip or start a shell | 06:09 |
| Keybuk | it doesn't start a shell, since then it might overlap with X or getty or stuff | 06:10 |
| slangasek | Keybuk: at the end of which comment? | 06:10 |
| Keybuk | #3 | 06:10 |
| Keybuk | "and mountall refused to mount / (more correctly, refused to remount it rw)." | 06:11 |
| slangasek | well, that's just a restatement of the log line: | mountall: Skipping mounting / since Plymouth is not available | 06:11 |
| Keybuk | that to me sounds more like Scott is trying to tell us mount failed, not mountall didn't try | 06:11 |
| Keybuk | yes, but what I mean is that there's mount errors missing here | 06:11 |
| Keybuk | --debug might be telling (since it will tell us the exit codes) | 06:11 |
| Keybuk | but I'm pretty convinced this is a case where mount -o remount,rw / has failed | 06:11 |
| Keybuk | not a case of mountall got bored | 06:11 |
| slangasek | ok | 06:12 |
| Keybuk | nothing mountall can do there ;) | 06:12 |
| Keybuk | that's why we have plymouth - to ask the user | 06:12 |
| slangasek | going to be nontrivial to confirm that this is the case, I guess | 06:12 |
| Keybuk | --debug should prove it | 06:12 |
| slangasek | it's non-trivial to edit an upstart job to set --debug in the UEC image | 06:12 |
| Keybuk | they should make that trivial ;-) | 06:13 |
| slangasek | heh | 06:13 |
| === 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 | ||
| zyga | mvo: morning | 08:14 |
| mvo | hi | 08:14 |
| zyga | mvo: I signed up to the software-center+pkgcon sprint on UDS | 08:15 |
| zyga | I'm looking forward to that :-) | 08:15 |
| pitti | Good morning | 08:18 |
| joaopinto | good morning | 08:21 |
| dholbach | good morning | 08:24 |
| mvo | hey dholbach | 08:25 |
| dholbach | hey mvo | 08:25 |
| amitk | slangasek: have you had a chance to look at bug 563618? | 08:30 |
| ubottu | 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:30 |
| slangasek | amitk: no; that's going to have to be post-rc, regardless | 08:37 |
| slangasek | amitk: and I'm still trying to fight my way up through the stack of plymouth/mountall bugs | 08:37 |
| amitk | slangasek: ack, thanks. | 08:42 |
| slangasek | Keybuk: so, that change seems to make mountall fail at mounting /tmp | 08:52 |
| trijntje | What would be a good place to find someone knowledgeable about empathy to ask the meaning of some strings? | 08:53 |
| joaopinto | slangasek, about the vboxsf issue, it might affect other packages providing filesystems support via kernel modules, maybe a warning message should be sent ? | 08:55 |
| slangasek | 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:56 |
| joaopinto | 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 | 08:59 |
| slangasek | 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:03 |
| joaopinto | ok :\ | 09:04 |
| IntuitiveNipple | 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:15 |
| persia | /var/log/syslog (outside the chroot) is often interesting | 09:17 |
| IntuitiveNipple | Thanks, I'll save that into the /target/ to look at later | 09:17 |
| IntuitiveNipple | I'm just testing a boot from the installed system now, to find out if anything did mess up | 09:18 |
| persia | IntuitiveNipple: There's a "Save Debug information" option from the main menu, which will save all the files you need. | 09:18 |
| IntuitiveNipple | Oh yeah! thanks for reminding me :) | 09:18 |
| slangasek | Keybuk: hmm - this code already special cases fuse mounts? | 09:19 |
| === almaisan-away is now known as al-maisan | ||
| IntuitiveNipple | 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:21 |
| phuang | hi | 09:32 |
| phuang | my PPA seems be locked. all build failed by uploading failed | 09:33 |
| phuang | Here is one build. https://launchpad.net/~shawn-p-huang/+archive/ppa/+build/1701077 | 09:33 |
| phuang | anyone can help me? | 09:33 |
| cody-somerville | phuang, Not here. Go to #launchpad for help with PPAs. | 09:34 |
| phuang | cody-somerville, thanks | 09:34 |
| dholbach | wgrant: HAPPY BIRTHDAY! :) | 09:43 |
| wgrant | dholbach: Thanks! | 09:43 |
| directhex | 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:44 |
| wgrant | directhex: That should be OK now. | 09:45 |
| wgrant | directhex: When did it fail? | 09:45 |
| wgrant | LP had a couple of crises over the past hour or so. | 09:45 |
| directhex | wgrant, few minutes ago | 09:45 |
| directhex | 2010-04-21 08:37:29 DEBUG Lockfile /var/lock/process-upload-buildd.lock in use | 09:45 |
| wgrant | Hmmmmm. Concerning. | 09:45 |
| directhex | Build #1701095 and #1701096 | 09:46 |
| james_w | happy birthday wgrant | 09:46 |
| wgrant | directhex: Which PPA? Build IDs are only useful if I also know the archive. | 09:47 |
| wgrant | Thanks james_w. | 09:47 |
| directhex | samarium and iridium for 96 | 09:48 |
| directhex | osmium for 95 | 09:48 |
| wgrant | directhex: should be OK now. | 09:54 |
| wgrant | Cascading failures FTW. | 09:54 |
| directhex | wgrant, can you rescore the builds? | 09:55 |
| slangasek | Keybuk: ok, /tmp sorted - needed to poke a bit so the placeholder handling code was still happy | 09:55 |
| wgrant | directhex: I have no privileges beyond MOTU. | 09:57 |
| wgrant | So, no. | 09:57 |
| directhex | boo | 09:58 |
| directhex | i386 build seems to be happening now anyway | 09:58 |
| free | hi! I have python-specific packaging question | 10:26 |
| persia | free: Which one? | 10:27 |
| free | 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 |
| free | persia: ^^^ | 10:28 |
| free | so one solution would be to explicitely depend on a specific python version like Depends: python2.6-pycurl | 10:28 |
| StevenK | Or depend on python-pycurl (> (Hardy's version)) | 10:28 |
| free | but having a lot of python dependencies that seem a bit sub-optimal, I was wondering if there is a better alternative | 10:28 |
| * persia likes StevenK's suggestion | 10:29 | |
| free | StevenK, persia: yeah, the only thing is that I have to do that manually for all my python dependencies | 10:29 |
| free | and maintain that | 10:29 |
| persia | The other option is to adjust the maintainer script to work also with python2.4-pycurl | 10:29 |
| free | StevenK, persia: I see, I think I'll eat the bullet and go for versions thanks! | 10:31 |
| Chipzz | free: isn't that exactly what Pre-Depends is for? | 10:40 |
| cjwatson | no, it is not | 10:40 |
| free | Chipzz: you Pre-Depends if you need a package to be fully installed and configured even before APT tries to unpack your package | 10:40 |
| slangasek | I think Bob the Angry Flower needs to get his gimp on and speak out about Pre-Depends | 10:41 |
| directhex | use a trigger! | 10:41 |
| james_w | free: does the package depend on python-pycurl at all currently? | 10:48 |
| free | james_w: it does | 10:49 |
| free | james_w: more details on bug #563063 | 10:49 |
| ubottu | 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:49 |
| james_w | free: I don't have that call in my copy of the postinst, is it not in the lucid package yet? | 10:53 |
| free | james_w: it is, but that is kicked in EC2 instances when starting the service from the postinst script | 10:55 |
| tseliot | pitti, slangasek: any opinions on bug #567699 and #567690 ? | 12:00 |
| ubottu | 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 |
| ubottu | Launchpad bug 567690 in fglrx-installer "Ensure fglrx package work in future for PAE kernel installs" [Undecided,New] https://launchpad.net/bugs/567690 | 12:00 |
| pitti | 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 |
| persia | tseliot: If you7re doing that, could you consider all the *other* available flavours? | 12:05 |
| pitti | doesn't linux-headers-generic-pae provide linux-headers? | 12:05 |
| tseliot | persia: that's my point | 12:05 |
| tseliot | pitti: yes, I think it does | 12:05 |
| * tseliot doubts that there's a way to get this right | 12:06 | |
| persia | There isn't a way to get it right. | 12:06 |
| persia | 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 |
| persia | (this is also true for all dkms-based packages) | 12:07 |
| tseliot | can you add some comments in the bug report, please? | 12:07 |
| pitti | then I don't really understand how that could help in the slightest | 12:12 |
| pitti | tseliot: no, there isn't; we can't express "we need the same kernel header flavour as the installed kernel" in dependencies | 12:12 |
| pitti | we could only check that in dkms/jockey at most | 12:12 |
| pitti | *nod* | 12:12 |
| pitti | tseliot: commented; I guess we should duplicate the bugs and reassign to jockey/dkms | 12:12 |
| pitti | bah, except that LP times out on me | 12:12 |
| pitti | ah, it's my backup rsync run of doom, which makes my internet connection useless | 12:12 |
| tseliot | pitti: thanks | 12:12 |
| pitti | (comment went through now) | 12:13 |
| tseliot | persia, pitti: thanks for your comments | 12:13 |
| yofel | short question: how do you tell upstart to boot to runlevel 3? | 12:15 |
| yofel | (from grub if possible) | 12:16 |
| === MacSlow is now known as MacSlow|lunch | ||
| joaopinto | yofel, guessing from reading /etc/init.d/rc-sysinit.conf, you can use the runlevel number on the linux kernel line | 12:21 |
| joaopinto | ops, init, not init.d | 12:22 |
| yofel | ah, thanks for finding that | 12:22 |
| cjwatson | yofel: you know runlevel 3 isn't what it means on RH-based systems, right? | 12:26 |
| cjwatson | 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 |
| yofel | cjwatson: I know, but I wanted to test something later and couldn't find if that's still possible | 12:27 |
| cjwatson | ok, it's just a common confusion so I thought I'd mention it | 12:28 |
| pitti | slangasek: hm, I think I need a second opinion about bug 566046 | 12:31 |
| ubottu | 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:31 |
| pitti | 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:32 |
| pitti | 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 |
| pitti | slangasek: upstream didn't respond at all yet, and at this point I need his input | 12:33 |
| slangasek | pitti: is the password stored encrypted or decrypted on disk? | 12:34 |
| pitti | 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:34 |
| pitti | slangasek: encrypted | 12:35 |
| pitti | slangasek: but since the keyring gets unlocked during login, every process can retrieve the cleartext through g-keyring | 12:35 |
| * slangasek nods | 12:35 | |
| slangasek | but in practice that's only a problem if you have a malicious process running as the user, right? | 12:36 |
| pitti | 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 |
| pitti | but the security team seems to be quite eager about it | 12:36 |
| pitti | slangasek: correct | 12:36 |
| pitti | if the user isn't logged in, there's no way to get the passphrase | 12:36 |
| slangasek | pitti: then I think I would prefer SRU | 12:36 |
| pitti | slangasek: ok, my feeling as well, thanks; I'll get an ack from security team for this, too | 12:37 |
| cjwatson | Keybuk: bug 554009 seems to be a regression from your wait-for-root work | 12:38 |
| ubottu | Launchpad bug 554009 in initramfs-tools "Resume from disk (swapfile) fails" [Medium,Triaged] https://launchpad.net/bugs/554009 | 12:38 |
| simmel | 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:26 |
| simmel | (sorry if this is the wrong channel, redirect me elsewhere if possible) | 13:27 |
| cjwatson | simmel: erm - you mean, only if it doesn't exist on the user's system when they come to install the .deb? | 13:27 |
| persia | simmel: Adding a conditional to debian/rules is likely easiest ([ ! -f foo ] && install -m ...) | 13:27 |
| cjwatson | simmel: if so that sounds like an odd requirement. Could you go into specifics? | 13:28 |
| simmel | cjwatson: No, only install one of the files in the package if the files doesn't exist. | 13:30 |
| persia | simmel: At package creation time, or at package install time? | 13:31 |
| cjwatson | doesn't exist where? | 13:31 |
| cjwatson | specifics would help if you can :) | 13:31 |
| simmel | persia: Ok, but then I would have to remove it too when the package is uninstalled, right? package install time. | 13:31 |
| cjwatson | isn't that what I said, and you said no? | 13:31 |
| persia | simmel: Why do you want to do this? Which file? | 13:31 |
| cjwatson | 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:32 |
| simmel | 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 |
| cjwatson | make it a conffile, then? | 13:33 |
| persia | Or don't ship it, and then create it in the postinst (e.g. postfix main.cf) | 13:33 |
| cjwatson | 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:34 |
| lamont | interesting. postfix {main,master}.cf aren't registered as conffiles... something tells me I should fix that | 13:37 |
| simmel | Is the conffiles like package-name.install? | 13:37 |
| simmel | I mean, do they behave in the same way? | 13:37 |
| Chipzz | just wondering; isn't #ubuntu-motu normally used for packaging questions? | 13:37 |
| persia | lamont: Should main.cf be a conffile? Depending on what one does with the postinst, it may never be generated (No Configuation). | 13:37 |
| lamont | persia: if generated, it should confess | 13:38 |
| simmel | 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 |
| persia | 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:38 |
| Chipzz | oh, when did that happen? | 13:39 |
| persia | Early February or so. | 13:39 |
| Chipzz | I recall users being redirected to #ubuntu-motu up to a couple of months ago | 13:40 |
| persia | Yeah, that matches my timeframes :) | 13:40 |
| Chipzz | s/users/packaging questions/ | 13:40 |
| simmel | Chipzz: motu meaning what? | 13:43 |
| persia | 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. | 13:43 |
| === MacSlow|lunch is now known as MacSlow | ||
| simmel | persia: It is seperated (in a seperate file and folder atleast). | 13:46 |
| simmel | 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:48 |
| simmel | err, choose | 13:49 |
| persia | 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:49 |
| persia | (or even, ship an empty config as conffile and modify it in postinst) | 13:50 |
| === ogra_ is now known as ogra | ||
| === DrPepperKid is now known as MacSlow | ||
| === sconklin-gone is now known as sconklin | ||
| mdeslaur | pitti: take a look at bug #567879 | 14:23 |
| ubottu | Launchpad bug 567879 in gnome-keyring "gnome-keyring no longer enforces application permissions" [Undecided,New] https://launchpad.net/bugs/567879 | 14:23 |
| seb128 | urg, the new gnome-keyring is a fail, we should have stayed away from it for lucid | 14:31 |
| tfried2001 | sad face | 14:32 |
| mdeslaur | pitti: actually, never mind, I just closed the bug. | 14:36 |
| seb128 | mdeslaur, was that the prompt which was judged confusing rather than useful and dropped upstream due to that? | 14:38 |
| mdeslaur | seb128: well, the security value of it was doubtful, and I kind of agree now. | 14:39 |
| mdeslaur | seb128: is Stef Walter the only upstream on gnome-keyring? | 14:40 |
| pitti | right, this was totally worthless | 14:40 |
| pitti | any application could have faked such a dialog | 14:40 |
| seb128 | mdeslaur, yes | 14:40 |
| mdeslaur | it was worthless as gnome-keyring should probably be a root process and access granted with policykit, etc. | 14:40 |
| seb128 | mdeslaur, I've been mailing "flooding" him for 1.5 months now | 14:40 |
| seb128 | 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:41 |
| mdeslaur | seb128: so, no chance of meeting with him at UDS? :P | 14:42 |
| seb128 | he has been looking at the bugs I mentioned via email but not on a very responsive timeline | 14:42 |
| pitti | once we know what this user.keystore is for, I think we can just upload the patch that we have | 14:42 |
| seb128 | mdeslaur, I doubt it | 14:42 |
| mdeslaur | pitti: I was under the impression it was the pkcs11 cert store, but I may be mistaken | 14:42 |
| ogra | seb128, heh, i'm back to stuttering ... | 14:56 |
| ogra | ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects|grep "object bytes" | 14:56 |
| ogra | -169566208 object bytes | 14:56 |
| ogra | fun | 14:56 |
| ogra | so RAOF was apparently right with his assumption | 14:56 |
| seb128 | ogra: right, read #ubuntu-desktop discussion | 14:57 |
| * zyga has a company now, woot :-) | 15:02 | |
| pitti | zyga: oh, congrats! building a new empire? :-) | 15:04 |
| joaopinto | Keybuk, http://pastebin.com/NVWXUS7Y, any idea why /lap is never attempted to be mounted ? | 15:07 |
| slangasek | joaopinto: run mountall --debug? | 15:08 |
| slangasek | joaopinto: and according to the last line, all filesystems *were* mounted | 15:09 |
| joaopinto | slangasek, because he opened an hacked tty and did the manual mount :) | 15:09 |
| slangasek | joaopinto: the 'manual intervention here' is shown three lines after the last mountall message | 15:10 |
| joaopinto | ops, right, it was after mountall after all | 15:11 |
| slangasek | joaopinto: anyway, if something didn't mount right, we'll need mountall --debug to sift through | 15:11 |
| joaopinto | ok, I am trying to convince him to open a bug report :P | 15:11 |
| slangasek | joaopinto: bug #567910? | 15:12 |
| ubottu | Launchpad bug 567910 in mountall "filesystem not getting mounted" [Undecided,New] https://launchpad.net/bugs/567910 | 15:12 |
| slangasek | ugh, "nodev"? | 15:12 |
| joaopinto | oh, great :) | 15:12 |
| slangasek | so, this looks like it might be a duplicate of the many reports of LVM+mountall problems that I haven't been able to reproduce | 15:13 |
| joaopinto | slangasek, he is at #ubuntu+1, might help | 15:15 |
| slangasek | probably not; I've already asked all the questions I've been able to think of regarding those bugs | 15:16 |
| joaopinto | ok :\ | 15:17 |
| joaopinto | hum | 15:20 |
| joaopinto | /* Check through the known filesystems, if this is a nodev | 15:21 |
| joaopinto | * filesystem then mark the mount as such so we don't wait | 15:21 |
| joaopinto | * for any device to be ready. | 15:21 |
| joaopinto | they should still be mounted right ? just having a nobootwait behavior | 15:21 |
| joaopinto | I mean, there should still be an attempt to mount | 15:22 |
| slangasek | joaopinto: no, that's nothing like nobootwait | 15:26 |
| slangasek | if you mark it 'nodev', mountall will try to mount it *immediately*, without first waiting for the device | 15:26 |
| slangasek | so if it needs a device in order to mount, and the device isn't there yet, --> fail | 15:27 |
| slangasek | I have no idea why anyone would mark their LVs 'nodev' | 15:27 |
| slangasek | unless they thought it was analogous to 'nosuid', I guess | 15:28 |
| joaopinto | but from the log there is no attempt to mount that filesystem | 15:28 |
| slangasek | the log is also uselessly incomplete. Need a debugging log | 15:28 |
| jdong | if I've got a struct {char* a; int b};, what Ubuntu security feature is causing a SIGABORT when a strcpy into "a" attempts to overwrite "b"? | 15:29 |
| jdong | is that -fstack-protector at work? | 15:29 |
| slangasek | oh, wait - that *is* what the 'nodev' mount option does, sigh | 15:29 |
| slangasek | keyword overload bad for brane | 15:29 |
| zyga | pitti: I hope that's the ubuntu empire :-) | 15:29 |
| hyperair | jdong: you shouldn't get a sigabrt at all, afaik. | 15:30 |
| hyperair | jdong: in the first place, doesn't char * a point somewhere else, so you won't overflow onto b? | 15:30 |
| slangasek | jdong: -fstack-protector might have something to do with it, but fyi, it's not 'b' that would be overwritten in an overflow | 15:30 |
| hyperair | jdong: unless you meant char a[something] | 15:30 |
| jdong | hyperair: yeah sorry for the lazy notation, I meant char a[something] | 15:30 |
| jdong | I've got someone's bot simulator here that contains such a vulnerability... | 15:31 |
| hyperair | afaik if it's in a struct it's all part of the same memory so you can just overflow over with no issues? =\ | 15:31 |
| hyperair | or maybe i'm wrong | 15:31 |
| jdong | on Ubuntu I was unable to even go 1 character beyond the end without the program blowing up | 15:31 |
| jdong | but on RHEL it can be exploited as expected | 15:32 |
| hyperair | jdong: i can't seem to reproduce that. | 15:34 |
| sistpoty|work | jdong: I doubt that a security feature can prevent overwriting b during runtime w.o. violating the c standard (though it's been some time since I a last poked at the standard) | 15:35 |
| sistpoty|work | jdong: however it might be that overwriting is already visible at compile time from -Dfortify_sources, so... | 15:35 |
| jdong | ah, whoops | 15:35 |
| jdong | wrong test case | 15:36 |
| jdong | incorrectly simplified test case | 15:36 |
| jdong | the two resources in the struct are malloced | 15:36 |
| jdong | they seem to be coincidentally adjacent in RHEL though | 15:36 |
| sistpoty|work | heh, everything malloc'ed is a different corner ;) | 15:37 |
| jdong | indeed it is | 15:37 |
| jdong | and ok, that actually makes sense why it's possible | 15:37 |
| joaopinto | slangasek, I was misreading both the source and the mount manual, "nodev" mount option is not related to the "nodev" property from /proc/filesystems | 15:53 |
| slangasek | right | 15:53 |
| slangasek | which I knew, then forgot :) | 15:53 |
| slangasek | pitti: confused by your email; the 114 patch was introduced Mar 31, not Apr 15? | 16:01 |
| === doko_ is now known as doko | ||
| pitti | slangasek: oops, yes | 16:02 |
| * pitti fixes wiki page | 16:03 | |
| dawning | Question: Is there going to be a 10.04 Beta 3? Is there any point? | 16:39 |
| pitti | dawning: the Release Candidate is due tomorrow, and next Thursday is the final | 16:40 |
| dawning | Sounds good, thanks pitti | 16:40 |
| === icarus901 is now known as stevemaresca | ||
| === stevemaresca is now known as icarus901 | ||
| === bjf is now known as bjf[afk] | ||
| zyga | doko: ping | 16:58 |
| === bjf[afk] is now known as bjf | ||
| Keybuk | cjwatson: I don't see why that's a regression | 17:28 |
| Keybuk | his resume= and root= are identical | 17:28 |
| Keybuk | that's clearly not going to work | 17:28 |
| doko | zyga: ? | 17:34 |
| Keybuk | slangasek: argh, your -r 323 is *WRONG* | 17:34 |
| zyga | doko: here or in private? | 17:34 |
| doko | cjwatson: http://people.canonical.com/~doko/tmp/ ppa1 built without multiarch, ppa2 with normal glibc and -fno-strict-aliasing, ppa3 without opt | 17:35 |
| Keybuk | slangasek: reverted in 324 with explanation | 17:39 |
| Keybuk | slangasek: Re: #553745 - I don't have any handle on it, I've been unable to replicate | 17:45 |
| Keybuk | my only theory had been the patch you tried | 17:45 |
| === beuno is now known as beuno-lunch | ||
| * hyperair wishes that the window manager would retain control even when applications have menus open | 18:04 | |
| hyperair | every time liferea hangs, i have to switch to a vt to kill it. | 18:05 |
| hyperair | i mean every time it hangs while i'm either right clicking or drag dropping | 18:05 |
| cjwatson | Keybuk: as I interpreted it, the point of that bug was that resume_offset isn't implemented in wait-for-root | 18:12 |
| cjwatson | I didn't debug whether the rest of his setup was sane | 18:12 |
| Keybuk | cjwatson: it doesn't need to be implemented in wait-for-root ? | 18:12 |
| cjwatson | oh, maybe I misunderstood the bug then | 18:12 |
| hyperair | resume_offset? are we supporting swap files for resume now? | 18:12 |
| Keybuk | no, i think the reporter has misunderstood that resume from swap files *doesn't work* | 18:12 |
| Keybuk | and never has | 18:12 |
| hyperair | ah | 18:13 |
| cjwatson | he explicitly claimed that his setup worked in karmic; perhaps he was lucky | 18:14 |
| Keybuk | I tend to assume they lie | 18:14 |
| hyperair | but you can never get them to admit that. | 18:14 |
| Keybuk | wait-for-root simply replaces the bad loop that looked for nodes in /dev and kept running blkid and udevadm settle | 18:15 |
| Keybuk | instead actually listening to uevents | 18:15 |
| Keybuk | comparing the hardy and lucid local-premount/resume scripts, they've changed quite a bit otherwise | 18:16 |
| kklimonda | hyperair: when liferea hangs try alt+f - it helps here to unblock it | 18:16 |
| hyperair | kklimonda: what's that supposed to do? | 18:17 |
| hyperair | kklimonda: but anyway i think the real problem is that X is to susceptible to being hijacked by a hanging application =\ | 18:17 |
| === dendrobates is now known as dendro-afk | ||
| hyperair | kklimonda: in the first place, why does liferea hang so much? firefox uses sqlite, banshee uses sqlite. i don't see them hanging like this. | 18:18 |
| Keybuk | cjwatson: in fact, looking at the current version, it flat out doesn't support resuming from files ;) | 18:20 |
| kklimonda | hyperair: when I drag and drop in applications and I get locked (I can't do anything in X because I'm locked in drag&drop mode) opening application menu tends to help.. and I have no idea why does liferea hang so much.. I've hoped that 1.7 would help but no luck :/ | 18:20 |
| hyperair | kklimonda: the worst part is that there is nothing better >_> | 18:20 |
| hyperair | kklimonda: so i'm stuck with either crap, or crappier crap. | 18:21 |
| kklimonda | hyperair: heh, true - that's the only reason I use liferea :/ | 18:21 |
| hyperair | kklimonda: the best part is that upstream is either ignorant to the whole liferea-suckiness, or not seeing the issue at all. | 18:23 |
| dylan-m | kklimonda: Hey, drag+drop hanging used to happen to me reallly often with Liferea, too! That was a year ago, though :o | 18:30 |
| dylan-m | It taught me one thing: mouse grabs are terrible, evil things and we really need a "release mouse grabs" key | 18:30 |
| dylan-m | (Since then I've used Feedly, but I'm just surprised it still happens after all the refactoring) | 18:31 |
| hyperair | feedly? | 18:31 |
| hyperair | ah feedly. | 18:32 |
| hyperair | the whole point for me to use an rss reader is so i don't have to open firefox | 18:32 |
| hyperair | that bl**dy mem hog | 18:32 |
| dylan-m | hyperair: Cute web service + Firefox / Chrome extension that plugs in to Google Reader, but is sadly not open source so we can't borrow their secrets :) | 18:32 |
| hyperair | dylan-m: heh. | 18:33 |
| hyperair | dylan-m: i'm betting that giving liferea a multithreaded interface would do the job. | 18:33 |
| hyperair | dylan-m: like I/O, one thread. UI, one thread. | 18:33 |
| hyperair | then yay no more hangs. | 18:33 |
| hyperair | afaik liferea's hangs are caused by sqlite doing blocking writes followed by syncs. | 18:34 |
| dylan-m | hyperair: everything that ever performs a grab should be doing it in a separate thread. It's an insanely risky operation | 18:34 |
| hyperair | dylan-m: i agree. | 18:34 |
| hyperair | dylan-m: well, even then menus suck. | 18:34 |
| hyperair | dylan-m: especially when you open a menu and liferea chooses to hang at that point. | 18:35 |
| === yofel_ is now known as yofel | ||
| kees | jdong: /me is curious to see your sigabrt reproducer | 18:36 |
| === beuno-lunch is now known as beuno | ||
| matgeek | Serious boot problem - mountall still does not handle >=4 LVM logical volumes. | 18:53 |
| matgeek | This is to do with lucid. | 18:54 |
| Keybuk | mountall doesn't handle LVM at all | 18:54 |
| Keybuk | if you're experiencing problems with LVM, you're experiencing problems with LVM | 18:54 |
| matgeek | Keybuk: Definitely not. I have been triaging this one for the last few days. My LVM volumes are perfectly fine. | 18:55 |
| Keybuk | if you're convinced it's a mountall issue, do you have a patch? | 18:56 |
| joaopinto | there was another person reporting LVM problems today, with mountall | 18:56 |
| matgeek | Keybuk: I am working on it. It is early in boot process - therefore harder to debug and get at with gdb etc. | 18:56 |
| Keybuk | I think that LVM is busted in Lucid | 18:56 |
| Keybuk | my hunch is that a recent kernel broke it | 18:56 |
| Keybuk | I've seen people report things like "volumes not activated" etc. | 18:56 |
| Keybuk | and it's clear from the debugging that no uevents for them are generated | 18:56 |
| Keybuk | enough to make me convinced that it's not a mountall problem | 18:57 |
| matgeek | I am running kernel.org 2.6.33.2. LVM utils are fine. | 18:57 |
| joaopinto | he was able to "resume" mountall by doing a manual mount | 18:57 |
| Keybuk | that doesn't really mean much | 18:57 |
| matgeek | Yes, that is what I have been doing. I have noticed udev creating the symlinks in /dev/<volume_name> | 18:57 |
| matgeek | I suspect that udev is working correctly, and that there is a race in mountall. | 18:58 |
| joaopinto | I am refering to bug 567910 | 18:58 |
| ubottu | Launchpad bug 567910 in mountall "filesystem not getting mounted" [Undecided,New] https://launchpad.net/bugs/567910 | 18:58 |
| Keybuk | first debugging step - add --debug to the exec line in /etc/init/mountall.conf and grab /var/log/boot.log when done | 18:58 |
| matgeek | The plymouht integration seems to have created problems. | 18:58 |
| Keybuk | matgeek: sorry, but I disagree; there is no race in mountall | 18:58 |
| Keybuk | all the debugging I've seen shows that mountall never gets told that the LVM devices are ready | 18:58 |
| matgeek | Well, do you watn to come and see it on my laptop??? | 18:58 |
| Keybuk | sure | 18:58 |
| matgeek | I am a DM with considerable Sys admin experience. I know what I am talking about. | 18:59 |
| Keybuk | that's nice | 18:59 |
| matgeek | I am here raisning the problem as even with the latest software it still persists. | 18:59 |
| Keybuk | no, you're here bitching and being unhelpful | 19:00 |
| Keybuk | <Keybuk> first debugging step - add --debug to the exec line in /etc/init/mountall.conf and grab /var/log/boot.log when done | 19:00 |
| Keybuk | ^ that would be helpful and helping prove there's a problem | 19:00 |
| Keybuk | right now, there is no proof of any bug | 19:00 |
| matgeek | OK, I am trying to prevent a release with a serious mount probelm on boot. | 19:00 |
| zyga | matgeek: which arch are you running | 19:00 |
| Keybuk | matgeek: if you want to do that, you need to prove there's a serious problem | 19:01 |
| matgeek | Keybuk: Don't just easily write me off as venting. | 19:01 |
| matgeek | I do not have that much time to debug and patch. | 19:01 |
| zyga | several days ago slangasek tracked a kernel bug where LVM drivers were not part of the kernel and ppc systems would not boot | 19:01 |
| Keybuk | matgeek: and don't just easily write us off as being idiotic enough to ship with something not working | 19:01 |
| joaopinto | matgeek, calm down, the problem is known, is being worked, if you can please provide more info on the bug I have mentioned above | 19:01 |
| Keybuk | joaopinto: the problem is not known and is not being worked | 19:01 |
| Keybuk | matgeek: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html | 19:02 |
| matgeek | OK: I will go and do the hard yards on Saturday. I will attempt to get boot logs loaded today against relevant bug. | 19:02 |
| joaopinto | Keybuk, the bug is known, was reported a few hours ago, and I have done some work on it, please calm down | 19:02 |
| Keybuk | Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than | 19:02 |
| Keybuk | less. | 19:02 |
| Keybuk | matgeek: Saturday will be too late to hold up the release | 19:03 |
| Keybuk | joaopinto: I'm quite calm; like I said, I'm convinced there is an LVM bug somewhere - not a mountall bug | 19:03 |
| matgeek | Keybuk: Understand. This bug is hard to find as it involves >= 4 lvm logical volumes coming up. early boot process debug is difficult. I can understand how it has been missed. | 19:03 |
| rye | Hello, all. Question - i did dput file.sources w/o specifying ppa:rye/ppa - it said "Uploading to ubuntu", should I notify anybody to prevent this package into going anywhere? | 19:03 |
| joaopinto | Keybuk, there is a problem, for the user it is irrelevant for the exact package, and you tend to ignore there is more than mountall on Ubuntu | 19:03 |
| Keybuk | joaopinto: yes, that's because I ignore anything outside of my lines of responsibility ;-) | 19:04 |
| joaopinto | he is not arguing about mountall, he is just reporting a problem with his LVM setup, which I believed to be mountall related | 19:04 |
| rye | The package in question is "henplus_0.9.8.ds1-0ubuntu1~ppa2~lucid" | 19:04 |
| matgeek | FYI, i have been using Linux since kernel 0.99. | 19:04 |
| arand | rye: it will just get rejected, unless you do have uploade rights to ubuntu main. | 19:04 |
| joaopinto | Keybuk, right, but that is not nice when you do it pushing people for helping with other problems | 19:05 |
| Keybuk | this is not a channel for reporting bugs, this is a channel for assisting in the development of Ubuntu - I expect anyone reporting problems here to also be willing to work on the fixes | 19:05 |
| joaopinto | I mean, for not helping | 19:05 |
| arand | rye: No need to do anything. Just make sure to delete the *upload file if you want to upload it again. | 19:05 |
| rye | i hope i don't... Ok, is the current topic about failure to mount LVM volumes during boot ? | 19:05 |
| joaopinto | matgeek, just update the bug report, some will check it depending on how much people it affects and how important it is compared to other known and being worked problems | 19:06 |
| Keybuk | so if someone comes in saying they have problems with LVM, I'll help point at where I think the current problem is to help them continue to work the problem | 19:06 |
| kees | doko: are you able to trivially reproduce 393022 ? | 19:06 |
| joaopinto | Keybuk, could you tell me the LVM related package I should assign the bug to ? | 19:07 |
| Keybuk | joaopinto: lvm2 | 19:08 |
| joaopinto | Keybuk, ok, I am going to reassign the bug based on your input | 19:08 |
| Keybuk | joaopinto: I've just done that | 19:08 |
| Keybuk | if you're referring to bug #567910 | 19:08 |
| ubottu | Launchpad bug 567910 in mountall "filesystem not getting mounted" [Undecided,New] https://launchpad.net/bugs/567910 | 19:08 |
| joaopinto | grr, ok | 19:08 |
| joaopinto | yes, that one | 19:09 |
| Keybuk | the debug log there shows no try_udev_device for laplv | 19:09 |
| hyperair | kklimonda: http://launchpadlibrarian.net/27733951/fsyncbegone.c \o/ | 19:15 |
| gbear14275 | anyone here able to talk to power management (specifically battery management)? I have questions about setting charging thresholds for my new li-ion battery. | 19:15 |
| Keybuk | joaopinto: an interesting debugging technique might be | 19:15 |
| Keybuk | let mountall fail and go to a maintenance shell | 19:16 |
| Keybuk | then run "mountall --debug" and get *that* output | 19:16 |
| Keybuk | (from the maintenance shell) | 19:16 |
| joaopinto | mountall did not fail | 19:16 |
| Keybuk | -v | 19:17 |
| gbear14275 | are there any gui's available to help set charging profiles for my battery? If not, how can I set my charging profiles? | 19:17 |
| zyga | hyperair: what are you doing with those functions? | 19:17 |
| hyperair | zyga: doing nothing. | 19:17 |
| zyga | gbear14275: try #ubuntu please | 19:17 |
| zyga | hyperair: they looked nice for LD_PRELOAD, right? | 19:17 |
| hyperair | zyga: making them no-op. i don't really need that much data integrity with liferea, since ext4's journalling fine. | 19:18 |
| hyperair | zyga: yes, correct. | 19:18 |
| === animAgus is now known as _silentAssassin | ||
| Keybuk | joaopinto: what do you mean by "did not fail" ? | 19:18 |
| jdong | kees: ah, the backtrace comes from 14:14 < temugen> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb72fded8] | 19:26 |
| jdong | kees: ah, -O2 and higher enables that check. | 19:27 |
| jdong | hyperair: ^^^ | 19:27 |
| hyperair | jdong: eh? | 19:27 |
| jdong | hyperair: strcpy is hardened at -O2 and above by default | 19:28 |
| hyperair | jdong: ah that's cool. | 19:28 |
| jdong | hyperair: so if you strcpy 11 chars into a char[10] it'll bork at -O2+ | 19:28 |
| hyperair | interesting. | 19:28 |
| jdong | the software I was trying to exploit was indeed -O3 | 19:28 |
| hyperair | but isn't -O supposed to optimize things, rather than add more sanity checks? | 19:28 |
| hyperair | i'm curious as to how it did the sanity check, as well. | 19:29 |
| jdong | hyperair: no I think -O means "don't assume instructions are executed as written" | 19:29 |
| hyperair | ah. | 19:29 |
| jdong | and that excuses the use of a replacement magical strcpy and such | 19:29 |
| jdong | again, kees could give us the real answer :) | 19:29 |
| hyperair | jdong: actually -O in the manpage is documented as Optimize. | 19:30 |
| jdong | http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html | 19:31 |
| kees | jdong: yes, it detects buffer overflows when it knows the size of the buffer. | 19:34 |
| kees | jdong: https://wiki.ubuntu.com/CompilerFlags | 19:34 |
| jdong | kees: cool. I didn't know DFORTIFY_SOURCE involved runtime checks, and I also didn't know it was tied into -O flags. | 19:34 |
| kees | jdong: i.e. gcc+glibc believe the code is doing something unsafe. | 19:34 |
| jdong | kees: surely enough, compiling with the right CFLAGS in RHEL produced an identical result | 19:35 |
| kees | jdong: yup, lots of runtimes checks. all documented in above wiki (including the -O2 and higher bit) | 19:35 |
| jdong | *nods* | 19:35 |
| jdong | that's pretty cool | 19:35 |
| kees | jdong: this is why Ubuntu is safer than RHEL -- we changed the defaults in our compiler. :) | 19:35 |
| jdong | yeah, I really like that. | 19:35 |
| kees | RHEL just uses those flags for their package builds. | 19:35 |
| jdong | heh I always ASSumed that RHEL would be more proactively secure than Ubuntu | 19:36 |
| jdong | not the case :) | 19:36 |
| kees | not since intrepid. :) | 19:37 |
| jdong | kees: you'll love the backstory. For a friend's final project in a programming course, grading was done via an automatic server, assumed to be on RHEL.... | 19:37 |
| jdong | kees: it had a filename[80] and a blind strcpy, kids tried to exploit that | 19:37 |
| jdong | unfortunately the grading was done on an Ubuntu box. people who tried to exploit that didn't score very high. | 19:37 |
| kees | hah | 19:37 |
| kees | real-world success! | 19:37 |
| jdong | yep! | 19:38 |
| Nafai | jdong: Nice! | 19:38 |
| jdong | always cool to see these features doing something useful in the real world | 19:39 |
| hyperair | now time to publicise this =p | 19:40 |
| hyperair | and get it dugg, slashdotted and the like =p | 19:40 |
| jdong | kees: any guesses as to why RHEL wouldn't turn these features on by default? Is compatibility a huge issue? | 19:41 |
| jdong | I mean, RHEL is pretty aggressively marketed for its security technologies; it'd seem like that's a priority for them | 19:41 |
| hyperair | not to mention the patch seems to come from redhat in the first place | 19:42 |
| jdong | oh yeah, most of this hardened toolchain stuff originated from RedHat/Fedora | 19:44 |
| kees | jdong: they're too timid. | 19:45 |
| kees | jdong: since it catches a lot of actual problems, people like the whine. "but it _used_ to compile and run fine!" | 19:45 |
| jdong | the irony is, I'd expect their SELinux-by-default to be even a worse offender at "gah it worked before!" | 19:46 |
| jdong | especially with LAMP apps | 19:46 |
| jcastro | lool, you still have an X200? How's your wireless? Mine started going to sleep. | 19:46 |
| kees | jdong: but I (and others) demanded it be done in Ubuntu, since it improves code quality so much. that said, there are rare cases when gcc gets it wrong. (usually via insane by valid tricks in source code) | 19:46 |
| elmo | jdong: it's easy to turn SELinux off | 19:46 |
| elmo | jdong: it's less easy to recompile everything | 19:46 |
| jdong | elmo: ah, that's true indeed | 19:46 |
| jdong | and so many sysadmins do seem to turn it off | 19:46 |
| kees | jdong: they did develop a lot of it (especially fortify), but stack protector was bounced around for ages before. | 19:47 |
| jdong | *nods* | 19:48 |
| kees | a lot of credit goes to OpenWall and solar designer, actually. | 19:49 |
| doko | kees: no | 19:49 |
| kees | doko: okay. I commented on the python upstream bug, trying to add any missing information. sounds like they're just popping a stack | 19:49 |
| doko | kees: thanks | 19:53 |
| doko | kees: the *link* with -O1 | 19:54 |
| doko | they even | 19:54 |
| * Keybuk hugs -Wl,-O1 | 19:54 | |
| kees | doko: oh! okay, I misunderstood. | 19:54 |
| Keybuk | joaopinto: ooooooh, I've just noticed something! | 19:57 |
| Keybuk | are you able to replicate the "LVM doesn't mount" bug? | 19:57 |
| joaopinto | Keybuk, nope, I was just proxying a support request from #ubuntu+1, I just known it was a XFS filesystem using LVM | 20:01 |
| Keybuk | joaopinto: damn | 20:02 |
| Keybuk | I have a theory | 20:02 |
| Keybuk | if I'm right, it actually turns out to be a mountall bug after all | 20:02 |
| Keybuk | there's a line of code missing | 20:02 |
| Keybuk | and this sounds a lot like a different bug we had | 20:02 |
| === animAgus is now known as _silentAssassin | ||
| Keybuk | I'll build a package and get them to try it | 20:04 |
| === kusum1 is now known as kusum | ||
| === al-maisan is now known as almaisan-away | ||
| joaopinto | how is the default timezone on the installer selected ? | 20:59 |
| TMKCodes | Is anywhere in ubuntu needed help from "new" c developer? | 21:12 |
| cjwatson | doko: belatedly - thanks, will try those | 21:13 |
| cjwatson | doko: I should test busybox-udeb ppa1 with the libc6-udeb from your PPA, right? | 21:14 |
| sabdfl | TMKCodes: lots to do - check out the "how to contribute" page on the wiki | 21:14 |
| TMKCodes | sabdfl i did read it already. | 21:15 |
| sabdfl | ok | 21:15 |
| cjwatson | TMKCodes: in my experience, it's better to find a problem that's annoying you personally and try to solve it (then repeat lots and lots of times!), than to try to filter it in advance by the language | 21:17 |
| cjwatson | joaopinto: geoip | 21:17 |
| cjwatson | joaopinto: fallback from that to a language-specific value | 21:18 |
| TMKCodes | cjwatson my problem is i dont have any problems with ubuntu atm | 21:18 |
| cjwatson | not trying hard enough ... ;-) | 21:18 |
| TMKCodes | Well i have some boot issues, have not looked into it. | 21:18 |
| cjwatson | there are some bugs tagged 'bitesize', although not as many as there should be | 21:19 |
| TMKCodes | Damn at last i found the bug tracker at launchpad.. Really hate that site. | 21:19 |
| cjwatson | and actually it's possible those are more trivial packaging kinds of bugs rather than anything that involves C | 21:19 |
| TMKCodes | Well.. C problems would be nice, but packaging problems are ok too xD | 21:20 |
| TMKCodes | packaging is the place where most start contributing. | 21:20 |
| cjwatson | seriously though - I got seriously into Debian development back in the day by way of somebody posting a message of the form "<this really important program> really sucks, can somebody fix it?" | 21:20 |
| TMKCodes | :P | 21:20 |
| cjwatson | and it was a program I used, and I could replicate a fair bit of the suckage, so I did | 21:20 |
| TMKCodes | Yeah i can understand that. | 21:21 |
| cjwatson | I'd done some packaging before that, but it's really just a means to an end | 21:21 |
| joaopinto | the default for my country seems far from ideal, an island is the default instead of the mainland | 21:21 |
| joaopinto | should I file a bug for ubiquity ? | 21:22 |
| cjwatson | anyway, point is, this worked because I had a personal interest in fixing the problems - it probably wouldn't have done otherwise | 21:22 |
| cjwatson | joaopinto: like I say, the defaults often come from geoip ... | 21:22 |
| TMKCodes | I have used ubuntu for several years, but there's been much problems with me so i've just waited bit for someone to fix the problem. | 21:22 |
| cjwatson | joaopinto: what country? | 21:22 |
| ogra_cmpc | joaopinto, likely because your provider routes through that island | 21:22 |
| cjwatson | ogra_cmpc: not necessarily, some of the geoip server's defaults are dubious | 21:22 |
| ogra_cmpc | ah | 21:22 |
| joaopinto | cjwatson, Portugal | 21:22 |
| cjwatson | else if ( strcmp (country, "PT") == 0 ) { | 21:23 |
| cjwatson | timezone = "Atlantic/Azores"; | 21:23 |
| cjwatson | } | 21:23 |
| * cjwatson hits geoip with a wet fish | 21:23 | |
| cjwatson | joaopinto: bug on geoip, please | 21:23 |
| joaopinto | uhh | 21:23 |
| ogra_cmpc | lol | 21:23 |
| joaopinto | :) | 21:23 |
| TMKCodes | i found the bug that i need to fix. | 21:23 |
| TMKCodes | bug number 1.. | 21:24 |
| ogra_cmpc | TMKCodes, thats rather a yeam effort :) | 21:24 |
| ogra_cmpc | *team | 21:24 |
| TMKCodes | :P | 21:24 |
| joaopinto | cjohnston, geoip-database <- ? | 21:24 |
| cjohnston | :-P | 21:24 |
| joaopinto | grrr, cjwatson | 21:24 |
| cjwatson | sadly, while geoip figures out the country accurately and sometimes an accurate region within it, the timezone it returns is hardcoded really stupidly | 21:24 |
| cjwatson | joaopinto: no, geoip. it's hardcoded. don't ask. :-( | 21:25 |
| joaopinto | cjwatson, where did you paste that code from ? the code is wrong... | 21:25 |
| cjwatson | from the geoip source package | 21:25 |
| cjwatson | libGeoIP/timeZone.c | 21:25 |
| ogra_cmpc | joaopinto, yes thats why he pasted it :) | 21:25 |
| cjwatson | I agree it's wrong, but I'd want to send it upstream | 21:25 |
| ogra_cmpc | use it in your bug report | 21:26 |
| cjwatson | and we'd need to backport the fix to our servers | 21:26 |
| cjwatson | it's the geoip package *on the server* that matters | 21:26 |
| joaopinto | what, geoip uses source code for the translation ? | 21:26 |
| cjwatson | yes | 21:26 |
| cjwatson | it's not pretty | 21:26 |
| cjwatson | I was kind of horrified when I found that, when dealing with a previous bug of the same form for another country | 21:26 |
| cjwatson | (bug 517621) | 21:27 |
| ubottu | Launchpad bug 517621 in ubiquity "Default setting of zh_CN locale incorrect" [Undecided,Fix released] https://launchpad.net/bugs/517621 | 21:27 |
| ogra_cmpc | over time it will be great though if we use it by default | 21:27 |
| ogra_cmpc | was probably a bit risky to include it now ... we should have done that in karmic already | 21:27 |
| tormod | pitti, I have a fix for the broken -dbg/-dbgsym packages in bug 562418 | 21:28 |
| ubottu | Launchpad bug 562418 in xorg-server "many -dbg packages have debug symbols mismatch" [Undecided,Confirmed] https://launchpad.net/bugs/562418 | 21:28 |
| Sarvatt | \o/ \o/ \o/ thanks tormod! | 21:29 |
| joaopinto | done, bug 568067, I guess it doesn't need a patch from me :P | 21:30 |
| ubottu | Launchpad bug 568067 in geoip "Default timezone for the country 'PT' is wrong, should be 'Europe/Lisbon'" [Undecided,New] https://launchpad.net/bugs/568067 | 21:30 |
| joaopinto | I guess it's low importance to be fixed before final :\ | 21:32 |
| tormod | Sarvatt, simple fix but a bitch to hunt down :) | 21:32 |
| cjwatson | joaopinto: because the operative code is on the server, it doesn't matter if it makes final | 21:35 |
| lool | jcastro: I have a X301; wireless is okay-ish, but had some issues during the cycle | 21:35 |
| lool | would disconnect at random | 21:35 |
| lool | it's decent now | 21:35 |
| cjwatson | joaopinto: we can fix it whenever, and all users will get the fix instantly on deployment | 21:35 |
| joaopinto | ah, server side geoip ok, much better :) | 21:35 |
| cjwatson | so we should focus on things that don't have that property | 21:35 |
| mvo | ccheney: hi, if you could review https://code.edge.launchpad.net/~mvo/openoffice/3.2.0-lucid/+merge/23875 that would be nice. I will go to bed now so no rush | 21:36 |
| barry | james_w: any chance you're still around? | 22:13 |
| james_w | barry: I am | 22:13 |
| james_w | so, yes I guess | 22:13 |
| barry | james_w: :) can we talk about lazr.restfulclient? | 22:13 |
| james_w | yup | 22:14 |
| barry | james_w: so, i'm trying to get a branch for lucid up to 0.9.13 or .14. iiuc, there is no lp:debian branch for it even though it's in testing: | 22:14 |
| barry | http://packages.debian.org/source/squeeze/lazr.restfulclient | 22:14 |
| barry | james_w: but it also looks like we have an ubuntu specific patch, so bzr import-dsc didn't do what i expected it to do | 22:15 |
| barry | james_w: and of course, i can't just merge in lp:lazr.restfulclient | 22:15 |
| barry | (no common ancestor) | 22:15 |
| barry | james_w: it also looks like debian svn has 0.9.14 in it though no source package yet | 22:16 |
| barry | afaict | 22:16 |
| barry | james_w: so i'm wondering, what is the best way to update the package for lucid? | 22:16 |
| james_w | barry: the sid branch has it I think? | 22:16 |
| barry | james_w: let's see if i can find that :) | 22:17 |
| james_w | lp:debian/sid/lazr.restfulclient | 22:17 |
| barry | thanks | 22:18 |
| barry | james_w: yep, that looks more sane | 22:18 |
| james_w | the reason that the squeeze branch doesn't have it yet is that gina hasn't picked it up yet | 22:19 |
| barry | james_w: conflict on the Maintainer and Uploaders fields, but that should be easily resolved | 22:19 |
| james_w | yeah, jelmer filed a bug about smarter merging of debian/control | 22:19 |
| barry | james_w: cool, this is exactly what i was looking for, thanks. do you want to review the branch when i push it? | 22:20 |
| james_w | sure | 22:20 |
| barry | james_w: cool, thanks | 22:20 |
| james_w | it would be tomorrow for me though | 22:20 |
| barry | yep, no worries | 22:20 |
| doko | cjwatson: yes, the libc6 udeb from the ppa | 22:25 |
| === sconklin is now known as sconklin-gone | ||
| kees | doko: that python issue is from an already-fixed kernel bug | 23:37 |
| doko | kees: fixed in which version? | 23:37 |
| kees | doko: all. it was fixed when karmic released, and went into stable kernels on mar 16th. | 23:38 |
| kees | doko: I put all the details in the upstream python bug | 23:39 |
| kees | doko: I might be able to find all the bug reports in LP that are dups of this kernel issue, actually. they stand out when you examine the ProcMaps.txt file | 23:40 |
| doko | kees: cool, thanks! | 23:41 |
| kees | doko: sure thing :) | 23:41 |
| cjwatson | doko: neither (libc6-udeb/ppa + busybox ppa1) nor busybox ppa2 makes any difference | 23:56 |
| cjwatson | trying 3 now | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!